From owner-freebsd-stable@FreeBSD.ORG Sun Jul 8 02:22:53 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 675AA106564A for ; Sun, 8 Jul 2012 02:22:53 +0000 (UTC) (envelope-from freebsd-stable@m.gmane.org) Received: from plane.gmane.org (plane.gmane.org [80.91.229.3]) by mx1.freebsd.org (Postfix) with ESMTP id 2288D8FC0A for ; Sun, 8 Jul 2012 02:22:52 +0000 (UTC) Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1Snh8z-0004KN-Cd for freebsd-stable@freebsd.org; Sun, 08 Jul 2012 04:22:41 +0200 Received: from cpe-188-129-77-73.dynamic.amis.hr ([188.129.77.73]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 08 Jul 2012 04:22:41 +0200 Received: from ivoras by cpe-188-129-77-73.dynamic.amis.hr with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 08 Jul 2012 04:22:41 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-stable@freebsd.org From: Ivan Voras Date: Sun, 08 Jul 2012 04:22:22 +0200 Lines: 22 Message-ID: Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@dough.gmane.org X-Gmane-NNTP-Posting-Host: cpe-188-129-77-73.dynamic.amis.hr User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 Subject: apache hangs in wait4 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 08 Jul 2012 02:22:53 -0000 Hello, I have a very embarrassing problem where apache22-worker, running mod_fcgid with php, perl and python fastcgi processes, hangs daliy in wait4: # procstat -k 54688 PID TID COMM TDNAME KSTACK 54688 101355 httpd - mi_switch sleepq_catch_signals sleepq_wait_sig _sleep kern_wait sys_wait4 amd64_syscall Xfast_syscall The only suspicious things in logs is this: [Sat Jul 07 20:00:01 2012] [notice] SIGUSR1 received. Doing graceful restart [Sat Jul 07 20:00:10 2012] [error] FastCGI process 41228 still did not exit, terminating forcefully The 41228 process is a Perl FastCGI web application using p5-FCGI (wwsympa), and it is in the accept wchan. Any ideas? From owner-freebsd-stable@FreeBSD.ORG Sun Jul 8 02:39:17 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id D533D106564A; Sun, 8 Jul 2012 02:39:16 +0000 (UTC) (envelope-from amvandemore@gmail.com) Received: from mail-we0-f182.google.com (mail-we0-f182.google.com [74.125.82.182]) by mx1.freebsd.org (Postfix) with ESMTP id 41FBC8FC08; Sun, 8 Jul 2012 02:39:16 +0000 (UTC) Received: by werp13 with SMTP id p13so6931576wer.13 for ; Sat, 07 Jul 2012 19:39:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=tN6yhZNP/iAOVioZeL/HlFmRQLFMt+orupl1WIDQYOw=; b=c31k35GDDyiAogSR0TaPMA1oNnd48g3kMi9Zkl3Y7pOPTs7MEHVZCIriTL2f/va5Io M3sCdAMzPn0eWFKOU94iE+NFbj5YTnQeKu5PiILF8umt8p+5LuBLtd9VG1Cty9MLbu7W vioTDGDdzwyiJ42O30P2KQq0LfbbT4FmDpuKzTVvXGFh/MeqVgHU1gWnYuoeQM0PAd2z YSDrYBmrQgGI4c4N3XdOPiIbXFGJedVwFSU+0xtgI5vBMZtYLuQtIHjtMTvNCmE+vGyR kU42VnIIxV5zxkSsGCxWT62iZaE0C2g1Frao0+AHFn6mxhmjjJEIVZ3/GJUw0X1qBFri N0iA== MIME-Version: 1.0 Received: by 10.216.50.140 with SMTP id z12mr9878949web.11.1341715155194; Sat, 07 Jul 2012 19:39:15 -0700 (PDT) Received: by 10.223.88.155 with HTTP; Sat, 7 Jul 2012 19:39:15 -0700 (PDT) In-Reply-To: References: Date: Sat, 7 Jul 2012 21:39:15 -0500 Message-ID: From: Adam Vande More To: Ivan Voras Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-stable@freebsd.org Subject: Re: apache hangs in wait4 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 08 Jul 2012 02:39:17 -0000 On Sat, Jul 7, 2012 at 9:22 PM, Ivan Voras wrote: > Hello, > > I have a very embarrassing problem where apache22-worker, running > mod_fcgid with php, perl and python fastcgi processes, hangs daliy in > wait4: > > # procstat -k 54688 > PID TID COMM TDNAME KSTACK > 54688 101355 httpd - mi_switch > sleepq_catch_signals sleepq_wait_sig _sleep kern_wait sys_wait4 > amd64_syscall Xfast_syscall > > The only suspicious things in logs is this: > > [Sat Jul 07 20:00:01 2012] [notice] SIGUSR1 received. Doing graceful > restart > [Sat Jul 07 20:00:10 2012] [error] FastCGI process 41228 still did not > exit, terminating forcefully > > The 41228 process is a Perl FastCGI web application using p5-FCGI > (wwsympa), and it is in the accept wchan. > > Any ideas? > Is it the same time? newsyslog perhaps? -- Adam Vande More From owner-freebsd-stable@FreeBSD.ORG Sun Jul 8 06:08:59 2012 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 8AFFC106564A for ; Sun, 8 Jul 2012 06:08:59 +0000 (UTC) (envelope-from jhellenthal@dataix.net) Received: from mail-ob0-f182.google.com (mail-ob0-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id 024648FC16 for ; Sun, 8 Jul 2012 06:08:58 +0000 (UTC) Received: by obbun3 with SMTP id un3so22164628obb.13 for ; Sat, 07 Jul 2012 23:08:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=dataix.net; s=rsa; h=date:from:to:cc:subject:message-id:reply-to:mime-version :content-type:content-disposition; bh=eI3IBevTuT2/45BJO+zD8YDUNztJuT/jAv4qMMI+b60=; b=NWJbCbG4grhQ+wnr2+JxQ8O1rMnCTbHKe+YFM3bDOCsu2+SZgrqhZVa8W/gTeMSCAo ZBSf/vGUZ8gox1UINOtKICSXNr73hAx+VYbUWTeBPe1pBWvOyuLtdGiUSUthU+IU4GP4 4Gk67zfspptmvFTO67qkw4Y0FF9fIlG84DXMo= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=date:from:to:cc:subject:message-id:reply-to:mime-version :content-type:content-disposition:x-gm-message-state; bh=eI3IBevTuT2/45BJO+zD8YDUNztJuT/jAv4qMMI+b60=; b=EBz+FHlUtXXVAByS8wvXvu6Ar1y2Kb8Vftw05RjzdbixZiD5U4/gZ6KpY4gPD9kSYk 9KD+/lAuwv1NoQR1b5+YQqh1Elg+PK6DinzmHixK/kpHi8eMi4kWJtV7/CmIHjuYRcBf Cpv0NSUNNHAutzGi0DMsZgAK5Kfp1l7saBNYb9VGTkF8i5RpH4olQss60JB+7/gXQRKh ul3UCo2+B8FZ5abCw2nVGkdnB3dcJkJ6WQZwhirlFjyUtlOLt3hmmWVxWtB2XVxsl4f3 qOj0HhV3Qvc9Bf2D9y9qoBBFECRqQ/tOuEVn5Mxh0AXyxZJqxTRBrQP0lMvFcMsbeNTZ YlNg== Received: by 10.50.40.193 with SMTP id z1mr5937303igk.0.1341727738298; Sat, 07 Jul 2012 23:08:58 -0700 (PDT) Received: from DataIX.net ([99.109.126.183]) by mx.google.com with ESMTPS id k6sm6269783igz.9.2012.07.07.23.08.57 (version=TLSv1/SSLv3 cipher=OTHER); Sat, 07 Jul 2012 23:08:57 -0700 (PDT) Received: from DataIX.net (localhost [127.0.0.1]) by DataIX.net (8.14.5/8.14.5) with ESMTP id q6868rr7048878 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 8 Jul 2012 02:08:54 -0400 (EDT) (envelope-from jhellenthal@DataIX.net) Received: (from jh@localhost) by DataIX.net (8.14.5/8.14.5/Submit) id q6868rUm048877; Sun, 8 Jul 2012 02:08:53 -0400 (EDT) (envelope-from jhellenthal@DataIX.net) Date: Sun, 8 Jul 2012 02:08:53 -0400 From: Jason Hellenthal To: stable@freebsd.org Message-ID: <20120708060853.GA44046@DataIX.net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="uAKRQypu60I7Lcqm" Content-Disposition: inline X-Gm-Message-State: ALoCoQkfEqFX5fAYWYr2LwC6QbEWC0zoWKGCqMwALIQ3tHjft3jM8U7fUa3sfqxgkHx/dw0V8q9v Cc: hackers@freebsd.org Subject: mtree(8) reservation of 16 -1 char[] in mtree files... X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: stable@freebsd.org List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Jul 2012 06:08:59 -0000 --uAKRQypu60I7Lcqm Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable I was just going through mtree(8) and happen to notice that mtree while populating a mtree file by the following [1] reference that it suffixes spaces as some sort of way to either reserve or pad the result for every value. Has anyone else see this behavior in Xterm or cons2* terminals from stable/8 i386 @ r238072 ? I tested this with /bin/sh /bin/csh /bin/bash /bin/ksh on cons25 cons50 xterm logged in directly as either a user or root through ssh and local. I looked over the mtree files in /etc/mtree and they do not exhibit the same thing so it now has me curious if something snuck in that would have changed this behavior. I have not had time to see if this repeats on other arch's 1). mtree -c -d -i -n -k uname,gname,mode,nochange >mtree.out Thanks to anyone that hits me with the clue bat if I have missed something. --=20 - (2^(N-1)) --uAKRQypu60I7Lcqm Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- iQEcBAEBAgAGBQJP+SP1AAoJEBSh2Dr1DU7WI3IH/0XyxmqX94g1KRj1kjRjIsIO fSyjIvMMEb3DTDfZWXdAuS4JXINjHG13XQhwqM7YJxGe9Ibp8TjUm/AbLWQGFjp7 ZeKzXZC3//F03fq1/wM15LC2y48IMXnDC+dm3CdGAoLUBs8OdfKsYW/zDy4rnaes DhCYnPNuEWPRQTcp/6AePyp3Gtd6U+9yXA/T3sfEI+uULTKxCywPywfg+VRrrp0b wGSWmlhkl//cdOjxKEzS+EDTB9i8ShSNo/b4J96yyBFGAIusJ+bPCtgR6ESqdy8D PrmVPFp3WgG7x9FK0L6iTdN/kLAMHbym7IpwsQdOmJgRm2aDfwk+B0JLYvIAte8= =khoY -----END PGP SIGNATURE----- --uAKRQypu60I7Lcqm-- From owner-freebsd-stable@FreeBSD.ORG Sun Jul 8 14:00:24 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 60FC7106564A for ; Sun, 8 Jul 2012 14:00:23 +0000 (UTC) (envelope-from george+freebsd@m5p.com) Received: from mailhost.m5p.com (ip-2-1-0-2.r03.asbnva02.us.ce.gin.ntt.net [IPv6:2001:418:0:5000::16]) by mx1.freebsd.org (Postfix) with ESMTP id CFC978FC0C for ; Sun, 8 Jul 2012 14:00:22 +0000 (UTC) Received: from wonderland.m5p.com (localhost [IPv6:::1]) by mailhost.m5p.com (8.14.4/8.14.4) with ESMTP id q68E0GLZ042214 for ; Sun, 8 Jul 2012 10:00:22 -0400 (EDT) (envelope-from george+freebsd@m5p.com) Message-ID: <4FF99270.9010002@m5p.com> Date: Sun, 08 Jul 2012 10:00:16 -0400 From: George Mitchell User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:13.0) Gecko/20120623 Thunderbird/13.0.1 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 passed SPF test, not delayed by milter-greylist-4.2.7 (mailhost.m5p.com [IPv6:::1]); Sun, 08 Jul 2012 10:00:22 -0400 (EDT) X-Scanned-By: MIMEDefang 2.72 on 10.100.0.3 Subject: Odd ttyvN TERM settings X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 08 Jul 2012 14:00:24 -0000 Up through FreeBSD 8.x, the ttyvN consoles had a TERM setting of cons25. On FreeBSD 9.n, it appears to be xterm for ttyv0, but it's still cons25 for ttyv1-ttyv8 (even though they all appear to act like xterms). Not surprisingly, this leads to less than desirable results when trying to run vi (or other such programs) on ttyv1 through ttyv8, unless you remember to setenv TERM xterm. Why did we change from cons25 to xterm? How can we get all the ttyvNs to get the correct TERM setting? -- George Mitchell From owner-freebsd-stable@FreeBSD.ORG Sun Jul 8 14:11:19 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 55499106566B for ; Sun, 8 Jul 2012 14:11:19 +0000 (UTC) (envelope-from imb@protected-networks.net) Received: from sarah.protected-networks.net (sarah.protected-networks.net [IPv6:2001:470:1f07:4e1::1]) by mx1.freebsd.org (Postfix) with ESMTP id 1ECE08FC14 for ; Sun, 8 Jul 2012 14:11:19 +0000 (UTC) Received: from toshi.auburn.protected-networks.net (toshi.auburn.protected-networks.net [202.12.127.84]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "Iain Butler", Issuer "RSA Class 2 Personal CA" (not verified)) (Authenticated sender: imb@protected-networks.net) by sarah.protected-networks.net (Postfix) with ESMTPSA id 093A86194; Sun, 8 Jul 2012 10:11:11 -0400 (EDT) DomainKey-Signature: a=rsa-sha1; s=200509; d=protected-networks.net; c=nofws; q=dns; h=message-id:date:from:user-agent:mime-version:to:cc:subject: references:in-reply-to:x-enigmail-version:openpgp:content-type:content-transfer-encoding; b=FuBOL+5ozxy1KHKLxGYg8Fh2yjWdW2yfh5MMvwIWNiNlCoR+l4OFB/2JwDtanqLFR bOW0aX0cKN/h8C+o+0b6QuR0PynQT/S4eWpodyWfF8cTLLIj5OpYofdnS88AtVW Message-ID: <4FF994FE.5040605@protected-networks.net> Date: Sun, 08 Jul 2012 10:11:10 -0400 From: Michael Butler User-Agent: Mozilla/5.0 (X11; FreeBSD i386; rv:13.0) Gecko/20120619 Thunderbird/13.0.1 MIME-Version: 1.0 To: George Mitchell References: <4FF99270.9010002@m5p.com> In-Reply-To: <4FF99270.9010002@m5p.com> X-Enigmail-Version: 1.4.2 OpenPGP: id=0442D492 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org Subject: Re: Odd ttyvN TERM settings X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 08 Jul 2012 14:11:19 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 07/08/12 10:00, George Mitchell wrote: > Up through FreeBSD 8.x, the ttyvN consoles had a TERM setting of cons25. > On FreeBSD 9.n, it appears to be xterm for ttyv0, but it's still cons25 > for ttyv1-ttyv8 (even though they all appear to act like xterms). Not > surprisingly, this leads to less than desirable results when trying to > run vi (or other such programs) on ttyv1 through ttyv8, unless you > remember to setenv TERM xterm. > > Why did we change from cons25 to xterm? How can we get all the ttyvNs > to get the correct TERM setting? -- George Mitchell The console driver has been replaced/updated. You likely missed updating your /etc/ttys, imb -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (FreeBSD) iEYEARECAAYFAk/5lP0ACgkQQv9rrgRC1JKkLQCeLzOuP1oCaplYpBAQIgFsU82r jwMAoKgHFQvdvSBK81Pf1wrOCuEJmkVD =YADR -----END PGP SIGNATURE----- From owner-freebsd-stable@FreeBSD.ORG Sun Jul 8 14:14:35 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 40BCE1065675 for ; Sun, 8 Jul 2012 14:14:35 +0000 (UTC) (envelope-from ronald-freebsd8@klop.yi.org) Received: from smarthost1.greenhost.nl (smarthost1.greenhost.nl [195.190.28.78]) by mx1.freebsd.org (Postfix) with ESMTP id E26D48FC22 for ; Sun, 8 Jul 2012 14:14:34 +0000 (UTC) Received: from smtp.greenhost.nl ([213.108.104.138]) by smarthost1.greenhost.nl with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from ) id 1SnsFk-0007fW-Rf for freebsd-stable@freebsd.org; Sun, 08 Jul 2012 16:14:25 +0200 Received: from dhcp-077-251-052-224.chello.nl ([77.251.52.224] helo=pinky) by smtp.greenhost.nl with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1SnsFl-0005Qu-6R for freebsd-stable@freebsd.org; Sun, 08 Jul 2012 16:14:25 +0200 Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes To: freebsd-stable@freebsd.org References: <4FF99270.9010002@m5p.com> Date: Sun, 08 Jul 2012 16:14:23 +0200 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit From: "Ronald Klop" Message-ID: In-Reply-To: <4FF99270.9010002@m5p.com> User-Agent: Opera Mail/12.00 (Win32) X-Virus-Scanned: by clamav at smarthost1.samage.net X-Spam-Level: / X-Spam-Score: 0.8 X-Spam-Status: No, score=0.8 required=5.0 tests=BAYES_50 autolearn=disabled version=3.3.1 X-Scan-Signature: 964c6a2bc69af72888bec91466701c23 Subject: Re: Odd ttyvN TERM settings X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 08 Jul 2012 14:14:35 -0000 On Sun, 08 Jul 2012 16:00:16 +0200, George Mitchell wrote: > Up through FreeBSD 8.x, the ttyvN consoles had a TERM setting of cons25. > On FreeBSD 9.n, it appears to be xterm for ttyv0, but it's still cons25 > for ttyv1-ttyv8 (even though they all appear to act like xterms). Not > surprisingly, this leads to less than desirable results when trying to > run vi (or other such programs) on ttyv1 through ttyv8, unless you > remember to setenv TERM xterm. > > Why did we change from cons25 to xterm? How can we get all the ttyvNs > to get the correct TERM setting? -- George Mitchell What is in your /etc/ttys? This is the ttys file on 9-STABLE on amd64: http://svnweb.freebsd.org/base/stable/9/etc/etc.amd64/ttys?revision=225736&view=markup&pathrev=238244 Regards, Ronald. From owner-freebsd-stable@FreeBSD.ORG Sun Jul 8 14:20:31 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4ABE6106566B for ; Sun, 8 Jul 2012 14:20:31 +0000 (UTC) (envelope-from george@m5p.com) Received: from mailhost.m5p.com (ip-2-1-0-2.r03.asbnva02.us.ce.gin.ntt.net [IPv6:2001:418:0:5000::16]) by mx1.freebsd.org (Postfix) with ESMTP id F26E48FC08 for ; Sun, 8 Jul 2012 14:20:30 +0000 (UTC) Received: from wonderland.m5p.com (localhost [IPv6:::1]) by mailhost.m5p.com (8.14.4/8.14.4) with ESMTP id q68EKOd4042329 for ; Sun, 8 Jul 2012 10:20:29 -0400 (EDT) (envelope-from george@m5p.com) Message-ID: <4FF99728.6040207@m5p.com> Date: Sun, 08 Jul 2012 10:20:24 -0400 From: George Mitchell User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:13.0) Gecko/20120623 Thunderbird/13.0.1 MIME-Version: 1.0 To: freebsd-stable@freebsd.org References: <4FF99270.9010002@m5p.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.2.7 (mailhost.m5p.com [IPv6:::1]); Sun, 08 Jul 2012 10:20:29 -0400 (EDT) X-Scanned-By: MIMEDefang 2.72 on 10.100.0.3 Subject: Re: Odd ttyvN TERM settings X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 08 Jul 2012 14:20:31 -0000 On 07/08/12 10:14, Ronald Klop wrote: > On Sun, 08 Jul 2012 16:00:16 +0200, George Mitchell > wrote: > >> Up through FreeBSD 8.x, the ttyvN consoles had a TERM setting of cons25. >> On FreeBSD 9.n, it appears to be xterm for ttyv0, but it's still cons25 >> for ttyv1-ttyv8 (even though they all appear to act like xterms). Not >> surprisingly, this leads to less than desirable results when trying to >> run vi (or other such programs) on ttyv1 through ttyv8, unless you >> remember to setenv TERM xterm. >> >> Why did we change from cons25 to xterm? How can we get all the ttyvNs >> to get the correct TERM setting? -- George Mitchell > > What is in your /etc/ttys? > > This is the ttys file on 9-STABLE on amd64: > http://svnweb.freebsd.org/base/stable/9/etc/etc.amd64/ttys?revision=225736&view=markup&pathrev=238244 > > > Regards, > Ronald. > _______________________________________________ > 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" Apparently I raced through mergemaster too fast (on two different machines, as well). That's where the problem was. Thanks for the help! -- George From owner-freebsd-stable@FreeBSD.ORG Sun Jul 8 14:34:08 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EA114106566B; Sun, 8 Jul 2012 14:34:08 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from mx1.sbone.de (mx1.sbone.de [IPv6:2a01:4f8:130:3ffc::401:25]) by mx1.freebsd.org (Postfix) with ESMTP id AA48C8FC12; Sun, 8 Jul 2012 14:34:08 +0000 (UTC) Received: from dhcp-128-232-132-170.eduroam.csx.cam.ac.uk (dhcp-128-232-132-170.eduroam.csx.cam.ac.uk [128.232.132.170]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mx1.sbone.de (Postfix) with ESMTPSA id B50BE25D37D1; Sun, 8 Jul 2012 14:34:07 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1084) From: "Bjoern A. Zeeb" Date: Sun, 8 Jul 2012 14:34:06 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: To: FreeBSD-Stable ML X-Mailer: Apple Mail (2.1084) Cc: FreeBSD Networking Mailing List Subject: Disturbance in IPv6 force in stable/9 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: FreeBSD Networking Mailing List List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Jul 2012 14:34:09 -0000 Hey, after some back and forth and quite a few people asking me for it and = having asked re@ I have merged the IPv6 offload changes to stable/9 today = rather than after 9.1 as I had planned. I did not merge driver changes and I am expecting that one or two might = follow-up, as will SCTP be following most likely. I'd be very happy if people = could test this the next days (this week) if using IPv6 to make sure nothing = breaks for them. The changes have been in HEAD for more than a month but who = knows:) In case you find something broke due to these MFCs please yell at me, = loudly! Thanks, Bjoern --=20 Bjoern A. Zeeb You have to have visions! It does not matter how good you are. It matters what good you do! From owner-freebsd-stable@FreeBSD.ORG Mon Jul 9 05:41:32 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 51DF2106564A; Mon, 9 Jul 2012 05:41:32 +0000 (UTC) (envelope-from mnln.l4@gmail.com) Received: from mail-gh0-f182.google.com (mail-gh0-f182.google.com [209.85.160.182]) by mx1.freebsd.org (Postfix) with ESMTP id F20B18FC08; Mon, 9 Jul 2012 05:41:31 +0000 (UTC) Received: by ghbz22 with SMTP id z22so11261931ghb.13 for ; Sun, 08 Jul 2012 22:41:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=AadiKdSkvJLnQFAlGdhzeirKq1kdzxDBtg8MJS4osLU=; b=hiRVIg5VdGEbNCyqJ7eAo2saMsdy7cAvhXSRjnrNGKxTi6CyC8SD6t8OQUKl9FWiTu eeY9HFUsOGyPz+C/wiRhoNgxMC9R7GH7uisN9cKZacxbOqQhlLCf+GaJcnbwDyA+AnBK /IECHsTMiNVn/SeYsYG69vvwjIWz+WdOVajAluctOs4uJQpHjwAq+V08RgDponjwTMQN XCuryMG51m5kD3ENVrAVKfLbLeeA/9cI0qF/m+wGq5JjNrl7nQWpFrUZB708U76WTvgz yVz6ETflR3rAloFXsc35OEdL7o3hggIi14u7qivq3yAyhjdCT/zPTZ0Ottbic+Suf5Wy SxpQ== MIME-Version: 1.0 Received: by 10.50.17.226 with SMTP id r2mr7496270igd.47.1341812491194; Sun, 08 Jul 2012 22:41:31 -0700 (PDT) Received: by 10.231.69.5 with HTTP; Sun, 8 Jul 2012 22:41:31 -0700 (PDT) Date: Sun, 8 Jul 2012 22:41:31 -0700 Message-ID: From: "mnln.l4" To: freebsd-drivers@freebsd.org, freebsd-stable@freebsd.org Content-Type: text/plain; charset=UTF-8 Cc: Subject: Doesn't LAPIC timer stop when CPU goes to sleep state? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 09 Jul 2012 05:41:32 -0000 I have FreeBSD 9.0-STABLE r237285, In my systl -a output, I see kern.eventimer.et.LAPIC.flags: 7 I am under the impression LAPIC timer may stop when CPU goes to sleep state. Shouldn't the flag be 15 as the example in EVENTTIMERS(4) man page? I have H67MA-E35 motherboard with Intel H67 chipset, and G840 dual core CPU. Thanks. From owner-freebsd-stable@FreeBSD.ORG Mon Jul 9 10:59:34 2012 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 16D9D1065672; Mon, 9 Jul 2012 10:59:34 +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 0E3968FC16; Mon, 9 Jul 2012 10:59:29 +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 NAA02773; Mon, 09 Jul 2012 13:59:21 +0300 (EEST) (envelope-from avg@FreeBSD.org) Message-ID: <4FFAB988.6050209@FreeBSD.org> Date: Mon, 09 Jul 2012 13:59:20 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:13.0) Gecko/20120625 Thunderbird/13.0.1 MIME-Version: 1.0 To: "mnln.l4" References: In-Reply-To: X-Enigmail-Version: 1.4.2 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: freebsd-stable@FreeBSD.org, freebsd-drivers@FreeBSD.org Subject: Re: Doesn't LAPIC timer stop when CPU goes to sleep state? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 09 Jul 2012 10:59:34 -0000 on 09/07/2012 08:41 mnln.l4 said the following: > I have FreeBSD 9.0-STABLE r237285, In my systl -a output, I see > > kern.eventimer.et.LAPIC.flags: 7 > > I am under the impression LAPIC timer may stop when CPU goes to sleep > state. Shouldn't the flag be 15 as the example in EVENTTIMERS(4) man > page? You don't have to be under an impression when you can get the facts from publicly available specifications and code. > I have H67MA-E35 motherboard with Intel H67 chipset, and G840 dual core CPU. > > Thanks. -- Andriy Gapon From owner-freebsd-stable@FreeBSD.ORG Mon Jul 9 17:34:49 2012 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 022A91065670; Mon, 9 Jul 2012 17:34:49 +0000 (UTC) (envelope-from seanbru@yahoo-inc.com) Received: from mrout2-b.corp.bf1.yahoo.com (mrout2-b.corp.bf1.yahoo.com [98.139.253.105]) by mx1.freebsd.org (Postfix) with ESMTP id BBF558FC08; Mon, 9 Jul 2012 17:34:48 +0000 (UTC) Received: from [IPv6:::1] (rideseveral.corp.yahoo.com [10.73.160.231]) by mrout2-b.corp.bf1.yahoo.com (8.14.4/8.14.4/y.out) with ESMTP id q69HYLc1087839; Mon, 9 Jul 2012 10:34:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=yahoo-inc.com; s=cobra; t=1341855263; bh=B19uXt6HAWqhO1eVf+J4CLVE8qf9HPtmFj+9hXFFb58=; h=Subject:From:Reply-To:To:Cc:In-Reply-To:References:Content-Type: Date:Message-ID:Mime-Version:Content-Transfer-Encoding; b=qfush16PoRSVi/asNSmVyXhPIJ8d5HMBC1SfpG5LzBgrSRrYELdvJSYcUSSfYi3oe Gdt9YffXvRNPlqy9K3Mp1OpCWq5xCJbFXsMc4djaeIl+XBsjHHe7I7B+X2o/H3dMUG CICOffl8C7K6LvtKqLBsu19jdY0d2f3SUBhasjxg= From: Sean Bruno To: "pyunyh@gmail.com" In-Reply-To: <20120705010136.GA3218@michelle.cdnetworks.com> References: <20120703185704.GA81296@fupp.net> <20120705010136.GA3218@michelle.cdnetworks.com> Content-Type: text/plain; charset="UTF-8" Date: Mon, 09 Jul 2012 10:34:21 -0700 Message-ID: <1341855261.6064.5.camel@powernoodle.corp.yahoo.com> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit X-Milter-Version: master.31+4-gbc07cd5+ X-CLX-ID: 855262000 Cc: Anders Nordby , "stable@freebsd.org" Subject: Re: bge problems in RELENG_9, bge0: watchdog timeout -- resetting X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: sbruno@freebsd.org List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jul 2012 17:34:49 -0000 On Wed, 2012-07-04 at 18:01 -0700, YongHyeon PYUN wrote: > here is a WIP version at the following URL. > http://people.freebsd.org/~yongari/bge/if_bge.c > http://people.freebsd.org/~yongari/bge/if_bgereg.h > http://people.freebsd.org/~yongari/bge/brgphy.c > > I have a couple of positive feedbacks but it seems it still has > some issues. Let me know whether it makes any difference on your > box. I grabbed these updates and applied them cleanly to stable/9 on a Dell R620 with a quad port BCM5720, I still see watchdog timeouts and reset indications. I am able to ping out of the box for a short amount of time before the device hangs and times out. -bash-4.2# ping XXX.XXX.XXX.1 PING XXX.XXX.XXX.1 (XXX.XXX.XXX.XXX): 56 data bytes ping: sendto: Network is down ping: sendto: Network is down ping: sendto: Network is down ping: sendto: Network is down ping: sendto: Network is down Jul 9 17:31:41 x89 kernel: bge2: watchdog timeout -- resetting Jul 9 17:31:41 x89 kernel: bge2: link state changed to DOWN Jul 9 17:31:41 x89 kernel: bge2: link state changed to DOWN ping: sendto: No route to host ping: sendto: No route to host ping: sendto: No route to host ping: sendto: No route to host 64 bytes from XXX.XXX.XXX.1: icmp_seq=9 ttl=64 time=1.408 ms Jul 9 17:31:45 x89 kernel: bge2: link state changed to UP Jul 9 17:31:45 x89 kernel: bge2: link state changed to UP 64 bytes from 10.73.149.1: icmp_seq=10 ttl=64 time=1.697 ms 64 bytes from XXX.XXX.XXX.1: icmp_seq=11 ttl=64 time=1.835 ms 64 bytes from XXX.XXX.XXX.1: icmp_seq=12 ttl=64 time=1.390 ms 64 bytes from XXX.XXX.XXX.1: icmp_seq=13 ttl=64 time=1.392 ms 64 bytes from XXX.XXX.XXX.1: icmp_seq=14 ttl=64 time=1.392 ms 64 bytes from XXX.XXX.XXX.1: icmp_seq=15 ttl=64 time=1.848 ms 64 bytes from XXX.XXX.XXX.1: icmp_seq=16 ttl=64 time=1.389 ms 64 bytes from XXX.XXX.XXX.1: icmp_seq=17 ttl=64 time=1.541 ms 64 bytes from XXX.XXX.XXX.1: icmp_seq=18 ttl=64 time=1.575 ms The stats counters don't really show much here, but here they are regardless. dev.bge.2.%desc: Broadcom NetXtreme Gigabit Ethernet, ASIC rev. 0x5720000 dev.bge.2.%driver: bge dev.bge.2.%location: slot=0 function=0 handle=\_SB_.PCI0.PE1C.NDX0 dev.bge.2.%pnpinfo: vendor=0x14e4 device=0x165f subvendor=0x1028 subdevice=0x1f5b class=0x020000 dev.bge.2.%parent: pci1 dev.bge.2.forced_collapse: 0 dev.bge.2.msi: 1 dev.bge.2.forced_udpcsum: 0 dev.bge.2.stats.FramesDroppedDueToFilters: 0 dev.bge.2.stats.DmaWriteQueueFull: 0 dev.bge.2.stats.DmaWriteHighPriQueueFull: 0 dev.bge.2.stats.NoMoreRxBDs: 0 dev.bge.2.stats.InputDiscards: 0 dev.bge.2.stats.InputErrors: 0 dev.bge.2.stats.RecvThresholdHit: 0 Jul 9 17:33:35 x89 kernel: bge2: link state changed to DOWN dev.bge.2.stats.rx.ifHCInOctets: 109580 dev.bge.2.stats.rx.Fragments: 0 dev.bge.2.stats.rx.UnicastPkts: 212 dev.bge.2.stats.rx.MulticastPkts: 282 dev.bge.2.stats.rx.BroadcastPkts: 543 dev.bge.2.stats.rx.FCSErrors: 0 dev.bge.2.stats.rx.AlignmentErrors: 0 dev.bge.2.stats.rx.xonPauseFramesReceived: 0 dev.bge.2.stats.rx.xoffPauseFramesReceived: 0 dev.bge.2.stats.rx.ControlFramesReceived: 0 dev.bge.2.stats.rx.xoffStateEntered: 0 dev.bge.2.stats.rx.FramesTooLong: 0 dev.bge.2.stats.rx.Jabbers: 0 dev.bge.2.stats.rx.UndersizePkts: 0 dev.bge.2.stats.tx.ifHCOutOctets: 30916 dev.bge.2.stats.tx.Collisions: 0 dev.bge.2.stats.tx.XonSent: 0 dev.bge.2.stats.tx.XoffSent: 0 dev.bge.2.stats.tx.InternalMacTransmitErrors: 0 dev.bge.2.stats.tx.SingleCollisionFrames: 0 dev.bge.2.stats.tx.MultipleCollisionFrames: 0 dev.bge.2.stats.tx.DeferredTransmissions: 0 dev.bge.2.stats.tx.ExcessiveCollisions: 0 dev.bge.2.stats.tx.LateCollisions: 0 dev.bge.2.stats.tx.UnicastPkts: 203 dev.bge.2.stats.tx.MulticastPkts: 0 dev.bge.2.stats.tx.BroadcastPkts: 3 From owner-freebsd-stable@FreeBSD.ORG Mon Jul 9 20:47:49 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id AEDA0106566B for ; Mon, 9 Jul 2012 20:47:49 +0000 (UTC) (envelope-from traveling08@cox.net) Received: from fed1rmfepi104.cox.net (fed1rmfepi104.cox.net [68.230.241.135]) by mx1.freebsd.org (Postfix) with ESMTP id 7F02B8FC08 for ; Mon, 9 Jul 2012 20:47:49 +0000 (UTC) Received: from fed1rmimpo110.cox.net ([68.230.241.159]) by fed1rmfepo201.cox.net (InterMail vM.8.01.04.00 201-2260-137-20101110) with ESMTP id <20120709204431.PLBH29577.fed1rmfepo201.cox.net@fed1rmimpo110.cox.net> for ; Mon, 9 Jul 2012 16:44:31 -0400 Received: from dell64 ([72.220.103.209]) by fed1rmimpo110.cox.net with bizsmtp id YLkX1j0054X51K403LkXzX; Mon, 09 Jul 2012 16:44:31 -0400 X-CT-Class: Clean X-CT-Score: 0.00 X-CT-RefID: str=0001.0A02020A.4FFB42AF.00BB,ss=1,re=0.000,fgs=0 X-CT-Spam: 0 X-Authority-Analysis: v=1.1 cv=VHAEUwC36PFTgqwLp7jeMWQF3V+lIkKEtKzfmasc/LU= c=1 sm=1 a=ZtsjS-0zHTUA:10 a=G8Uczd0VNMoA:10 a=kj9zAlcOel0A:10 a=9eRLpXbTwyrdKc8or95E8w==:17 a=zR_ZBHi0PIgc_l4SPCEA:9 a=CjuIK1q_8ugA:10 a=9eRLpXbTwyrdKc8or95E8w==:117 X-CM-Score: 0.00 Authentication-Results: cox.net; none Date: Mon, 9 Jul 2012 13:44:26 -0700 From: Robert To: freebsd-stable@freebsd.org Message-ID: <20120709134426.7f01dd96@dell64> X-Mailer: Claws Mail 3.8.1 (GTK+ 2.24.6; amd64-portbld-freebsd8.3) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: Build failure xorg-drivers with Clang X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 09 Jul 2012 20:47:49 -0000 Greetings I am trying to build a 9.0 Stable system and am getting this error when building xorg meta port. I have clang set up as follows make.conf cat /etc/make.conf CC=clang CXX=clang++ CPP=clang-cpp # added by use.perl 2012-07-09 07:23:29 PERL_VERSION=5.16.0 src.conf CC=clang CXX=clang++ CPP=clang-cpp uname -a FreeBSD pita9bsd.shasta204.local 9.0-STABLE FreeBSD 9.0-STABLE #0: Sun Jul 8 18:52:16 PDT 2012 root@pita9bsd.shasta204.local:/usr/obj/usr/src/sys/GENERIC i386 The error: In file included from xf86Helper.c:54: In file included from ../../../hw/xfree86/os-support/xf86_OSlib.h:451: ./compiler.h:1104:24: error: invalid operand in inline asm: 'in${0:B} ($1)' __asm__ __volatile__("in%B0 (%1)" : ^ ./compiler.h:1104:24: error: unknown use of instruction mnemonic without a size suffix :1:2: note: instantiated into assembly here in (%dx) ^ In file included from xf86Helper.c:54: In file included from ../../../hw/xfree86/os-support/xf86_OSlib.h:451: ./compiler.h:1104:24: error: invalid operand in inline asm: 'in${0:B} ($1)' __asm__ __volatile__("in%B0 (%1)" : ^ ./compiler.h:1104:24: error: unknown use of instruction mnemonic without a size suffix :1:2: note: instantiated into assembly here in (%dx) In file included from xf86Helper.c:54: In file included from ../../../hw/xfree86/os-support/xf86_OSlib.h:451: ./compiler.h:1104:24: error: invalid operand in inline asm: 'in${0:B} ($1)' __asm__ __volatile__("in%B0 (%1)" : ^ ./compiler.h:1104:24: error: unknown use of instruction mnemonic without a size suffix :1:2: note: instantiated into assembly here in (%dx) ^ In file included from xf86Helper.c:54: In file included from ../../../hw/xfree86/os-support/xf86_OSlib.h:451: ./compiler.h:1104:24: error: invalid operand in inline asm: 'in${0:B} ($1)' __asm__ __volatile__("in%B0 (%1)" : ^ fatal error: too many errors emitted, stopping now [-ferror-limit=] 20 errors generated. gmake[5]: *** [xf86Helper.lo] Error 1 gmake[4]: *** [all] Error 2 gmake[3]: *** [all-recursive] Error 1 gmake[2]: *** [all] Error 2 gmake[1]: *** [all-recursive] Error 1 gmake: *** [all-recursive] Error 1 *** [do-build] Error code 1 I just retrieved the ports this morning with portsnap fetch extract. Any help appreciated. Robert From owner-freebsd-stable@FreeBSD.ORG Mon Jul 9 22:01:26 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id DBEF5106566B for ; Mon, 9 Jul 2012 22:01:26 +0000 (UTC) (envelope-from arno@heho.snv.jussieu.fr) Received: from shiva.jussieu.fr (shiva.jussieu.fr [134.157.0.129]) by mx1.freebsd.org (Postfix) with ESMTP id 8AB888FC0C for ; Mon, 9 Jul 2012 22:01:26 +0000 (UTC) Received: from heho.snv.jussieu.fr (heho.snv.jussieu.fr [134.157.184.22]) by shiva.jussieu.fr (8.14.4/jtpda-5.4) with ESMTP id q69M0rxH029382 ; Tue, 10 Jul 2012 00:01:06 +0200 (CEST) X-Ids: 165 Received: from heho.snv.jussieu.fr (localhost [127.0.0.1]) by heho.snv.jussieu.fr (8.14.3/8.14.3) with ESMTP id q69M0O8E070483; Tue, 10 Jul 2012 00:00:24 +0200 (CEST) (envelope-from arno@heho.snv.jussieu.fr) Received: (from arno@localhost) by heho.snv.jussieu.fr (8.14.3/8.14.3/Submit) id q69M0NMC070480; Tue, 10 Jul 2012 00:00:23 +0200 (CEST) (envelope-from arno) To: Vincent Hoffman From: "Arno J. Klaassen" References: <4FF7055D.9000507@unsane.co.uk> <4FF76066.1000401@unsane.co.uk> Date: Tue, 10 Jul 2012 00:00:23 +0200 In-Reply-To: <4FF76066.1000401@unsane.co.uk> (Vincent Hoffman's message of "Fri\, 06 Jul 2012 23\:02\:14 +0100") Message-ID: User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.3 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Miltered: at jchkmail.jussieu.fr with ID 4FFB5495.002 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 4FFB5495.002/134.157.184.22/heho.snv.jussieu.fr/heho.snv.jussieu.fr/ Cc: freebsd-stable@freebsd.org Subject: Re: nfs-bug when server for 9-Stable becomes client as well ? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 09 Jul 2012 22:01:27 -0000 Vincent Hoffman writes: > On 06/07/2012 18:51, Arno J. Klaassen wrote: >> Vincent Hoffman writes: >> >>> On 06/07/2012 14:19, Arno J. Klaassen wrote: >>>> Hello, >>>> >>>> looks like I discouvered a probable bug in the nfs-code, very >>>> easy to reproduce in my setup : >>>> >>>> >>>> Machine-1 : Today's 9-stable, exporting /files (ufs) and /z2 (zfs) >>>> >>>> Machine-2 : 8-stable as of April the 10th exporting /raid1 >>>> >>>> On Machine-1 I mount /raid1 (rw,nfsv3,intr,tcp,rsize=32768,wsize=32768) >>>> and start a script on this mount looping something like : >>>> >>>> dd if=/dev/random of=BIG bs=1048576 count=${SIZE} >>>> cp -fp BIG BIG2 >>>> cmp -x BIG BIG2 >>>> >>>> I let this run for 24 hours (from time to time stressing Machine-1 with >>>> other scripts, including provoking heavy swapping), no problem at all. >>>> >>>> However, then I mount /z2 (rw,nfsv3,intr,tcp,rsize=32768,wsize=32768) >>>> on Machine-2, and *immediately* the above loop on Machine-1 fails : >>>> >>>> Copying file ...cp: BIG: Permission denied >>>> >>>> No console messages this time, last time I got >>>> >>>> kernel: nfs_getpages: error 13 >>>> kernel: vm_fault: pager read error, pid 87803 (cmp) >>>> >>>> on Machine-1. >>>> >>>> I repeated this scenario by replacing Machine-2 with a good old >>>> 6-4-stable one, same outcome. >>>> >>>> Please tell me what I could do to nail this down a bit more. >>> Its possible (although not definite) that you have hit the a mountd bug >>> as documented in PRs >>> >>> kern/131342 >>> kern/136865 >> especially kern/131342 looks similar and quite old; funny I never hit >> this before, I basically do the same tests since 'ages' on each new box. >> Could be that faster network/cpu unreveals some race condition; I notice >> as well that this server is the first (IIRC) who uses 3 different IRQs >> for network interrupts (em(4) Intel(R) PRO/1000). > Certainly possible and seems reasonable enough. just my $0.02, I glanced kern/131342, looks like the culprit should be something like a 'non-atomic'-operation in-between invalidating old /etc/exports and validating new /etc/exports. Wonder if just verifying /var/run/mountd.pid is newer than /etc/exports and if true just skip that operation would be an acceptable band-aid (if I understood correctly, a rewrite of mountd correcting this (amongst others) is close to hit -current (?)) >>> I've recently asked on -CURRENT about this and had a patch to try from >>> Rick, I'm testing it now but it doesnt seem to fix it for me, just >>> improve it alothough I'm trying to get enough runs to be a valid sample. >>> (see >>> http://docs.freebsd.org/cgi/getmsg.cgi?fetch=377627+0+archive/2012/freebsd-current/20120701.freebsd-current >>> ) >>> >>> What I did for my production nas was edit mount.c so it didnt send a >>> SIGHUP to mountd as suggested by rick, as it was easy to do and non >>> intrusive. >> hmm, this means I should patch each fbsd-client, no? May be easier to >> patch mountd to ignore SIHGUP and use some non-standard signal to force >> re-init? > No just patch /sbin/mount on the nfs server so it doesnt send the SIGHUP > to mountd. [In my case] it's the mount on a client which causes the server to fail, I don't see how patching /sbin/mount on the nfs server should fix this? As I don't remember if it's possible to discriminate a -1 signal send from a process against one sent from terminal, if so, another bandaid, one sent from a process could be ignored at all? Merci Arno > you can manually HUP mountd if needed. >> >> Arno >> >> >>> Vince >>> >>>> Thanx in advance, >>>> >>>> Best, Arno > > > _______________________________________________ > 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" > -- Arno J. Klaassen SCITO S.A. 8 rue des Haies F-75020 Paris, France http://scito.com From owner-freebsd-stable@FreeBSD.ORG Tue Jul 10 01:11:25 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E3D45106564A; Tue, 10 Jul 2012 01:11:25 +0000 (UTC) (envelope-from mnln.l4@gmail.com) Received: from mail-gg0-f182.google.com (mail-gg0-f182.google.com [209.85.161.182]) by mx1.freebsd.org (Postfix) with ESMTP id 78F6F8FC08; Tue, 10 Jul 2012 01:11:25 +0000 (UTC) Received: by ggnm2 with SMTP id m2so12404138ggn.13 for ; Mon, 09 Jul 2012 18:11:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=0YIrb+CI94IB4buwP38U/SvLEaAHzqMX+4XhderFdr4=; b=R4jKIqfYYkbNcd8+AmKNX6LftQBYwSHViz6kglf/wVyNYXUuLObWdQFa9CflcIDuFh x6kDG7lSqutJQIpByDfI++C3367ZoR4mNyBai6i4GPNq/ftbXeJ9FNj78a41xFvbrhaR R+LjgKCZHrF8ulx7rD2QrsDxW4nyrWaaMiQgXtGb7JUIjSkY2bTMkjpVWPgUrOuTn7V8 VqZf7Jcmb1JXQQ+4XVpB/vd4BWqKEj52U1JfdDKRSZQug4cKoKnGodVLMWVnuz8Hirp0 6MCnedCW70WRl7WshK/8jNOCzgwlZh6AoKAqTxt/miztYMtUdmYdmtkEk6FCoVlw3Ted mYbQ== MIME-Version: 1.0 Received: by 10.42.189.138 with SMTP id de10mr21579840icb.38.1341882678849; Mon, 09 Jul 2012 18:11:18 -0700 (PDT) Received: by 10.231.69.5 with HTTP; Mon, 9 Jul 2012 18:11:18 -0700 (PDT) In-Reply-To: <4FFAB988.6050209@FreeBSD.org> References: <4FFAB988.6050209@FreeBSD.org> Date: Mon, 9 Jul 2012 18:11:18 -0700 Message-ID: From: "mnln.l4" To: Andriy Gapon Content-Type: text/plain; charset=UTF-8 Cc: freebsd-stable@freebsd.org, freebsd-drivers@freebsd.org Subject: Re: Doesn't LAPIC timer stop when CPU goes to sleep state? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 10 Jul 2012 01:11:26 -0000 http://wiki.freebsd.org/TuningPowerConsumption/ says LAPIC timer stops when CPU in C3, while I saw the flag is set to 7. Of course, I can read full spec and code (http://fxr.watson.org/fxr/source/x86/x86/local_apic.c?im=bigexcerpts#L251) to find out some processor's LAPIC timer runs in C3, but mailing list could be helpful to get some quick answer. On Mon, Jul 9, 2012 at 3:59 AM, Andriy Gapon wrote: > on 09/07/2012 08:41 mnln.l4 said the following: >> I have FreeBSD 9.0-STABLE r237285, In my systl -a output, I see >> >> kern.eventimer.et.LAPIC.flags: 7 >> >> I am under the impression LAPIC timer may stop when CPU goes to sleep >> state. Shouldn't the flag be 15 as the example in EVENTTIMERS(4) man >> page? > > You don't have to be under an impression when you can get the facts from publicly > available specifications and code. > >> I have H67MA-E35 motherboard with Intel H67 chipset, and G840 dual core CPU. >> >> Thanks. > > -- > Andriy Gapon > From owner-freebsd-stable@FreeBSD.ORG Tue Jul 10 04:44:36 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 24189106566B; Tue, 10 Jul 2012 04:44:36 +0000 (UTC) (envelope-from cowens@greatbaysoftware.com) Received: from ecbiz102.inmotionhosting.com (ecbiz102.inmotionhosting.com [70.39.235.94]) by mx1.freebsd.org (Postfix) with ESMTP id C75538FC0A; Tue, 10 Jul 2012 04:44:35 +0000 (UTC) Received: from c-50-136-23-27.hsd1.nh.comcast.net ([50.136.23.27]:64776 helo=jack.bspruce.com) by ecbiz102.inmotionhosting.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1SoRch-0003bv-50; Tue, 10 Jul 2012 00:00:27 -0400 Message-ID: <4FFBA8D8.3040604@greatbaysoftware.com> Date: Tue, 10 Jul 2012 00:00:24 -0400 From: Charles Owens Organization: Great Bay Software User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 MIME-Version: 1.0 To: John Baldwin References: <4FDABA0B.5030702@greatbaysoftware.com> <201206150804.46341.jhb@freebsd.org> <4FE3DA14.9090506@greatbaysoftware.com> <201206221022.57632.jhb@freebsd.org> In-Reply-To: <201206221022.57632.jhb@freebsd.org> X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ecbiz102.inmotionhosting.com X-AntiAbuse: Original Domain - freebsd.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - greatbaysoftware.com Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-stable@freebsd.org Subject: Re: ? IO performance regression, post 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: Tue, 10 Jul 2012 04:44:36 -0000 Charles Owens Great Bay Software, Inc. v: 603.617.4844 m: 603.866.0860 On 6/22/12 10:22 AM, John Baldwin wrote: > On Thursday, June 21, 2012 10:36:04 pm Charles Owens wrote: >> On 6/15/12 8:04 AM, John Baldwin wrote: >>> On Friday, June 15, 2012 12:28:59 am Charles Owens wrote: >>>> Hello FreeBSD folk, >>>> >>>> We're seeing what appears to be a storage performance regression as we >>>> try to move from 8.1 (i386) to 8.3. We looked at 8.2 also and it >>>> appears that the regression happened between 8.1 and 8.2. >>>> >>>> Our system is an Intel S5520UR Server with 12 GB RAM, dual 4-core CPUs. >>>> Storage is a LSI MegaSAS 1078 controller (mfi) in a RAID-10 >>>> configuration, using UFS + geom_journal for filesystem. >>>> >>>> Postgresql performance, as seen via pgbench, dropped by approx 20%. >>>> This testing was done with our usual PAE-enabled kernels. We then went >>>> back to GENERIC kernels and did comparisons using "bonnie", results >>>> below. Following that is a kernel boot log. >>>> >>>> Notably, we're seeing this regression only with our RAID mfi(4) based >>>> systems. Notably, from looking at FreeBSD source changelogs it appears >>>> that the mfi(4) code has seen some changes since 8.1. >>> Between 8.1 and 8.2 mfi has not had any significant changes. The only changes >>> made to sys/dev/mfi were to add a new constant: >>> >>>> svn diff svn+ssh://svn.freebsd.org/base/releng/8.1/sys/dev/mfi >>> svn+ssh://svn.freebsd.org/base/releng/8.2/sys/dev/mfi >>> Index: mfireg.h >>> =================================================================== >>> --- mfireg.h (.../8.1/sys/dev/mfi) (revision 237134) >>> +++ mfireg.h (.../8.2/sys/dev/mfi) (revision 237134) >>> @@ -975,7 +975,9 @@ >>> MFI_PD_STATE_OFFLINE = 0x10, >>> MFI_PD_STATE_FAILED = 0x11, >>> MFI_PD_STATE_REBUILD = 0x14, >>> - MFI_PD_STATE_ONLINE = 0x18 >>> + MFI_PD_STATE_ONLINE = 0x18, >>> + MFI_PD_STATE_COPYBACK = 0x20, >>> + MFI_PD_STATE_SYSTEM = 0x40 >>> }; >>> >>> union mfi_ld_ref { >>> >>> The difference in write performance must be due to something else. You >>> mentioned you are using UFS + gjournal. I think gjournal uses BIO_FLUSH, so I >>> wonder if this is related: >>> >>> ------------------------------------------------------------------------ >>> r212939 | gibbs | 2010-09-20 19:39:00 -0400 (Mon, 20 Sep 2010) | 61 lines >>> >>> MFC 212160: >>> >>> Correct bioq_disksort so that bioq_insert_tail() offers barrier semantic. >>> Add the BIO_ORDERED flag for struct bio and update bio clients to use it. >>> >>> The barrier semantics of bioq_insert_tail() were broken in two ways: >>> >>> o In bioq_disksort(), an added bio could be inserted at the head of >>> the queue, even when a barrier was present, if the sort key for >>> the new entry was less than that of the last queued barrier bio. >>> >>> o The last_offset used to generate the sort key for newly queued bios >>> did not stay at the position of the barrier until either the >>> barrier was de-queued, or a new barrier (which updates last_offset) >>> was queued. When a barrier is in effect, we know that the disk >>> will pass through the barrier position just before the >>> "blocked bios" are released, so using the barrier's offset for >>> last_offset is the optimal choice. >>> >>> sys/geom/sched/subr_disk.c: >>> sys/kern/subr_disk.c: >>> o Update last_offset in bioq_insert_tail(). >>> >>> o Only update last_offset in bioq_remove() if the removed bio is >>> at the head of the queue (typically due to a call via >>> bioq_takefirst()) and no barrier is active. >>> >>> o In bioq_disksort(), if we have a barrier (insert_point is non-NULL), >>> set prev to the barrier and cur to it's next element. Now that >>> last_offset is kept at the barrier position, this change isn't >>> strictly necessary, but since we have to take a decision branch >>> anyway, it does avoid one, no-op, loop iteration in the while >>> loop that immediately follows. >>> >>> o In bioq_disksort(), bypass the normal sort for bios with the >>> BIO_ORDERED attribute and instead insert them into the queue >>> with bioq_insert_tail(). bioq_insert_tail() not only gives >>> the desired command order during insertion, but also provides >>> barrier semantics so that commands disksorted in the future >>> cannot pass the just enqueued transaction. >>> >>> sys/sys/bio.h: >>> Add BIO_ORDERED as bit 4 of the bio_flags field in struct bio. >>> >>> sys/cam/ata/ata_da.c: >>> sys/cam/scsi/scsi_da.c >>> Use an ordered command for SCSI/ATA-NCQ commands issued in >>> response to bios with the BIO_ORDERED flag set. >>> >>> sys/cam/scsi/scsi_da.c >>> Use an ordered tag when issuing a synchronize cache command. >>> >>> Wrap some lines to 80 columns. >>> >>> sys/cddl/contrib/opensolaris/uts/common/fs/zfs/vdev_geom.c >>> sys/geom/geom_io.c >>> Mark bios with the BIO_FLUSH command as BIO_ORDERED. >>> >>> Sponsored by: Spectra Logic Corporation >>> ------------------------------------------------------------------------ >>> >>> Can you try perhaps commenting out the 'bp->bio_flags |= BIO_ORDERED' line >>> changed in geom_io.c in 8.2? That would be effectively reverting this >>> portion of the diff: >>> >>> Index: geom_io.c >>> =================================================================== >>> --- geom_io.c (.../8.1/sys/geom) (revision 237134) >>> +++ geom_io.c (.../8.2/sys/geom) (revision 237134) >>> @@ -265,6 +265,7 @@ >>> g_trace(G_T_BIO, "bio_flush(%s)", cp->provider->name); >>> bp = g_alloc_bio(); >>> bp->bio_cmd = BIO_FLUSH; >>> + bp->bio_flags |= BIO_ORDERED; >>> bp->bio_done = NULL; >>> bp->bio_attribute = NULL; >>> bp->bio_offset = cp->provider->mediasize; >>> >> John... thanks for the suggestion. I've built and tested a kernel with >> this change made. Result: no change (same performance as with >> 8.2-GENERIC). Any thoughts as to where to go next? > Hmm. That seemed the most plausible candidate when I looked at this. > > Do you use quotas (there is one change in UFS related to quotas)? > > There are 5 changes that involve sys/kern/vfs_bio.c in 8.2: > 209459, 212229, 212562, 212583, and 213890. > > Can you possibly test out kernels from stable/8 at those revisions on an 8.1 > world and see if you can narrow it down futher? > > Barring that, can you do a binary search of kernels from stable/8 between 8.1 > and 8.2 on an 8.1 world to see which commit caused the change in write > performance? > I've been sidetracked for a bit... and am now starting to work through the revisions you've suggested. Ahead of that, I've reinstalled the system with filesystems configured *without* geom_journal and repeated tests with both 8.1 and 8.2 kernels. Finding: no issue -- in fact 8.2 performs slightly better than 8.1, as we might hope for in general. (bonnie output below) Not sure if this really helps us narrow things down, but geom_journal is certainly part of the story. I'll have more results in the next day or so. 8.1 GENERIC -------Sequential Output-------- ---Sequential Input-- --Random-- -Per Char- --Block--- -Rewrite-- -Per Char- --Block--- --Seeks--- Machine MB K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU /sec %CPU 100 196050 99.9 344414 43.4 535679 43.2 152666 99.7 3233854 100.0 251145.9 215.2 8.2 GENERIC -------Sequential Output-------- ---Sequential Input-- --Random-- -Per Char- --Block--- -Rewrite-- -Per Char- --Block--- --Seeks--- Machine MB K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU /sec %CPU 100 190687 97.8 436428 43.0 537990 42.9 155766 98.3 4268089 100.0 231347.6 240.6 From owner-freebsd-stable@FreeBSD.ORG Tue Jul 10 07:51:57 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 80C06106566C for ; Tue, 10 Jul 2012 07:51:57 +0000 (UTC) (envelope-from vince@unsane.co.uk) Received: from unsane.co.uk (unsane-pt.tunnel.tserv5.lon1.ipv6.he.net [IPv6:2001:470:1f08:110::2]) by mx1.freebsd.org (Postfix) with ESMTP id E952D8FC15 for ; Tue, 10 Jul 2012 07:51:56 +0000 (UTC) Received: from vincemacbook.unsane.co.uk (vincemacbook.unsane.co.uk [10.10.10.20]) (authenticated bits=0) by unsane.co.uk (8.14.5/8.14.5) with ESMTP id q6A7Bw0d051960 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Tue, 10 Jul 2012 08:13:00 +0100 (BST) (envelope-from vince@unsane.co.uk) Message-ID: <4FFBD5BD.7010905@unsane.co.uk> Date: Tue, 10 Jul 2012 08:11:57 +0100 From: Vincent Hoffman User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 MIME-Version: 1.0 To: "Arno J. Klaassen" References: <4FF7055D.9000507@unsane.co.uk> <4FF76066.1000401@unsane.co.uk> In-Reply-To: X-Enigmail-Version: 1.4.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org Subject: Re: nfs-bug when server for 9-Stable becomes client as well ? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 10 Jul 2012 07:51:57 -0000 On 09/07/2012 23:00, Arno J. Klaassen wrote: > Vincent Hoffman writes: > >> On 06/07/2012 18:51, Arno J. Klaassen wrote: >>> Vincent Hoffman writes: >>> >>>> On 06/07/2012 14:19, Arno J. Klaassen wrote: >>>>> Hello, >>>>> >>>>> looks like I discouvered a probable bug in the nfs-code, very >>>>> easy to reproduce in my setup : >>>>> >>>>> >>>>> Machine-1 : Today's 9-stable, exporting /files (ufs) and /z2 (zfs) >>>>> >>>>> Machine-2 : 8-stable as of April the 10th exporting /raid1 >>>>> >>>>> On Machine-1 I mount /raid1 (rw,nfsv3,intr,tcp,rsize=32768,wsize=32768) >>>>> and start a script on this mount looping something like : >>>>> >>>>> dd if=/dev/random of=BIG bs=1048576 count=${SIZE} >>>>> cp -fp BIG BIG2 >>>>> cmp -x BIG BIG2 >>>>> >>>>> I let this run for 24 hours (from time to time stressing Machine-1 with >>>>> other scripts, including provoking heavy swapping), no problem at all. >>>>> >>>>> However, then I mount /z2 (rw,nfsv3,intr,tcp,rsize=32768,wsize=32768) >>>>> on Machine-2, and *immediately* the above loop on Machine-1 fails : >>>>> >>>>> Copying file ...cp: BIG: Permission denied >>>>> >>>>> No console messages this time, last time I got >>>>> >>>>> kernel: nfs_getpages: error 13 >>>>> kernel: vm_fault: pager read error, pid 87803 (cmp) >>>>> >>>>> on Machine-1. >>>>> >>>>> I repeated this scenario by replacing Machine-2 with a good old >>>>> 6-4-stable one, same outcome. >>>>> >>>>> Please tell me what I could do to nail this down a bit more. >>>> Its possible (although not definite) that you have hit the a mountd bug >>>> as documented in PRs >>>> >>>> kern/131342 >>>> kern/136865 >>> especially kern/131342 looks similar and quite old; funny I never hit >>> this before, I basically do the same tests since 'ages' on each new box. >>> Could be that faster network/cpu unreveals some race condition; I notice >>> as well that this server is the first (IIRC) who uses 3 different IRQs >>> for network interrupts (em(4) Intel(R) PRO/1000). >> Certainly possible and seems reasonable enough. > just my $0.02, I glanced kern/131342, looks like the culprit should be > something like a 'non-atomic'-operation in-between invalidating old > /etc/exports and validating new /etc/exports. > Wonder if just verifying /var/run/mountd.pid is newer than /etc/exports > and if true just skip that operation would be an acceptable band-aid (if > I understood correctly, a rewrite of mountd correcting this (amongst > others) is close to hit -current (?)) I dont know how close it (nfse) is to hitting -current. It certainly looked good from my quick look over but there are a few minor incompatibilities in the exports syntax even in compatibility mode that seem to be stopping acceptance (I'm hoping the problem is a little more complex but thats all I understand it to be.) In the mean time I'm testing a second patch from rick to see if that helps. > >>>> I've recently asked on -CURRENT about this and had a patch to try from >>>> Rick, I'm testing it now but it doesnt seem to fix it for me, just >>>> improve it alothough I'm trying to get enough runs to be a valid sample. >>>> (see >>>> http://docs.freebsd.org/cgi/getmsg.cgi?fetch=377627+0+archive/2012/freebsd-current/20120701.freebsd-current >>>> ) >>>> >>>> What I did for my production nas was edit mount.c so it didnt send a >>>> SIGHUP to mountd as suggested by rick, as it was easy to do and non >>>> intrusive. >>> hmm, this means I should patch each fbsd-client, no? May be easier to >>> patch mountd to ignore SIHGUP and use some non-standard signal to force >>> re-init? >> No just patch /sbin/mount on the nfs server so it doesnt send the SIGHUP >> to mountd. > [In my case] it's the mount on a client which causes the server to fail, > I don't see how patching /sbin/mount on the nfs server should fix this? > As I don't remember if it's possible to discriminate a -1 signal send > from a process against one sent from terminal, if so, another bandaid, > one sent from a process could be ignored at all? Your message above seemed to say that you were running the test on machine-1 on an export from machine-2, you then mounted an export from machine-1 on machine-2 (ran the mount command on machine-2, the original NFS server) which caused the test machine-1 was running to fail, as machine-2 sent a "permission denied" If i understood this incorrectly my guess at your problem could be completely off track. Vince > Merci > > Arno > > >> you can manually HUP mountd if needed. >>> Arno >>> >>> >>>> Vince >>>> >>>>> Thanx in advance, >>>>> >>>>> Best, Arno >> >> _______________________________________________ >> 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 Tue Jul 10 10:23:33 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2E499106566C for ; Tue, 10 Jul 2012 10:23:33 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from tensor.andric.com (tensor.andric.com [87.251.56.140]) by mx1.freebsd.org (Postfix) with ESMTP id D8F0C8FC14 for ; Tue, 10 Jul 2012 10:23:32 +0000 (UTC) Received: from [IPv6:2001:7b8:3a7:0:f5a1:37a7:b01a:4353] (unknown [IPv6:2001:7b8:3a7:0:f5a1:37a7:b01a:4353]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id 0F3CC5C37; Tue, 10 Jul 2012 12:23:32 +0200 (CEST) Message-ID: <4FFC02A2.8010303@FreeBSD.org> Date: Tue, 10 Jul 2012 12:23:30 +0200 From: Dimitry Andric Organization: The FreeBSD Project User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:14.0) Gecko/20120619 Thunderbird/14.0 MIME-Version: 1.0 To: Robert References: <20120709134426.7f01dd96@dell64> In-Reply-To: <20120709134426.7f01dd96@dell64> X-Enigmail-Version: 1.5a1pre Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "freebsd-stable@freebsd.org" Subject: Re: Build failure xorg-drivers with Clang X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 10 Jul 2012 10:23:33 -0000 On 2012-07-09 22:44, Robert wrote: > I am trying to build a 9.0 Stable system and am getting this error when > building xorg meta port. I have clang set up as follows ... > The error: > > In file included from xf86Helper.c:54: > In file included from ../../../hw/xfree86/os-support/xf86_OSlib.h:451: > ./compiler.h:1104:24: error: invalid operand in inline asm: 'in${0:B} > ($1)' __asm__ __volatile__("in%B0 (%1)" : > ^ > ./compiler.h:1104:24: error: unknown use of instruction mnemonic > without a size suffix > :1:2: note: instantiated into assembly here > in (%dx) > ^ Are you sure this is a failure in xorg-drivers? This looks more like xorg-server code. Also, are you using WITH_NEW_XORG or not? Last but not least, what does "clang -v" print? In any case, it would be enlightening if you post the full build log somewhere. From owner-freebsd-stable@FreeBSD.ORG Tue Jul 10 13:41:53 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id A2530106566C; Tue, 10 Jul 2012 13:41:53 +0000 (UTC) (envelope-from traveling08@cox.net) Received: from fed1rmfepo102.cox.net (fed1rmfepo102.cox.net [68.230.241.144]) by mx1.freebsd.org (Postfix) with ESMTP id 675468FC16; Tue, 10 Jul 2012 13:41:53 +0000 (UTC) Received: from fed1rmimpo305.cox.net ([68.230.241.173]) by fed1rmfepo102.cox.net (InterMail vM.8.01.04.00 201-2260-137-20101110) with ESMTP id <20120710134147.TWPG4155.fed1rmfepo102.cox.net@fed1rmimpo305.cox.net>; Tue, 10 Jul 2012 09:41:47 -0400 Received: from dell64 ([72.220.103.209]) by fed1rmimpo305.cox.net with bizsmtp id Ydhm1j00L4X51K403dhmxl; Tue, 10 Jul 2012 09:41:46 -0400 X-CT-Class: Clean X-CT-Score: 0.00 X-CT-RefID: str=0001.0A02020B.4FFC311A.01C4,ss=1,re=0.000,fgs=0 X-CT-Spam: 0 X-Authority-Analysis: v=1.1 cv=7DTXskVBSpuAR/MBl5itprnUq89zrLWEwH6mAWzvx2I= c=1 sm=1 a=zZLVAf7QdekA:10 a=G8Uczd0VNMoA:10 a=kj9zAlcOel0A:10 a=9eRLpXbTwyrdKc8or95E8w==:17 a=6I5d2MoRAAAA:8 a=fGO4tVQLAAAA:8 a=DTN0EbfbPkj773lLHrYA:9 a=CjuIK1q_8ugA:10 a=_1wnFc8Z8u8A:10 a=SV7veod9ZcQA:10 a=9eRLpXbTwyrdKc8or95E8w==:117 X-CM-Score: 0.00 Authentication-Results: cox.net; none Date: Tue, 10 Jul 2012 06:41:41 -0700 From: Robert To: Dimitry Andric Message-ID: <20120710064141.060aa4f6@dell64> In-Reply-To: <4FFC02A2.8010303@FreeBSD.org> References: <20120709134426.7f01dd96@dell64> <4FFC02A2.8010303@FreeBSD.org> X-Mailer: Claws Mail 3.8.1 (GTK+ 2.24.6; amd64-portbld-freebsd8.3) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: "freebsd-stable@freebsd.org" Subject: Re: Build failure xorg-drivers with Clang X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 10 Jul 2012 13:41:53 -0000 On Tue, 10 Jul 2012 12:23:30 +0200 Dimitry Andric wrote: > On 2012-07-09 22:44, Robert wrote: > > I am trying to build a 9.0 Stable system and am getting this error > > when building xorg meta port. I have clang set up as follows > ... > > The error: > > > > In file included from xf86Helper.c:54: > > In file included > > from ../../../hw/xfree86/os-support/xf86_OSlib.h:451: ./compiler.h:1104:24: > > error: invalid operand in inline asm: 'in${0:B} ($1)' __asm__ > > __volatile__("in%B0 (%1)" : ^ > > ./compiler.h:1104:24: error: unknown use of instruction mnemonic > > without a size suffix > > :1:2: note: instantiated into assembly here > > in (%dx) > > ^ > > Are you sure this is a failure in xorg-drivers? This looks more like > xorg-server code. Also, are you using WITH_NEW_XORG or not? Last but > not least, what does "clang -v" print? > > In any case, it would be enlightening if you post the full build log > somewhere. Dimitry Thanks for responding. You are right, the error is when building xorg-server. I am not using WITH_NEW_XORG as this is an older P4 computer. I am not sure if I should be using NEW XORG. Here is my video card. vgapci0@pci0:1:0:0: class=0x030000 card=0x00000000 chip=0x004810de rev=0xa1 hdr=0x00 vendor = 'nVidia Corporation' device = 'NV40 [GeForce 6800 XT]' class = display subclass = VGA CPU: Intel(R) Pentium(R) 4 CPU 2.60GHz (2595.00-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0xf29 Family = f Model = 2 Stepping = 9 Features=0xbfebfbff Features2=0x4400 real memory = 2147483648 (2048 MB) avail memory = 2086125568 (1989 MB) root@pita9bsd:/root # clang -v FreeBSD clang version 3.1 (branches/release_31 156863) 20120523 Target: i386-unknown-freebsd9.0 Thread model: posix Complete attempt at build (xorg-drivers.log) can be viewed at pastebin.com/u/traveling08 Thanks again. Robert From owner-freebsd-stable@FreeBSD.ORG Tue Jul 10 17:33:05 2012 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 39EA3106564A for ; Tue, 10 Jul 2012 17:33:05 +0000 (UTC) (envelope-from seanbru@yahoo-inc.com) Received: from mrout1-b.corp.bf1.yahoo.com (mrout1-b.corp.bf1.yahoo.com [98.139.253.104]) by mx1.freebsd.org (Postfix) with ESMTP id D50438FC15 for ; Tue, 10 Jul 2012 17:33:04 +0000 (UTC) Received: from [IPv6:::1] (rideseveral.corp.yahoo.com [10.73.160.231]) by mrout1-b.corp.bf1.yahoo.com (8.14.4/8.14.4/y.out) with ESMTP id q6AHWiWX023058; Tue, 10 Jul 2012 10:32:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=yahoo-inc.com; s=cobra; t=1341941566; bh=yXwL9qjvSHX/RW2BZMou1C+Y0P0kNix5n9B0riNZDNI=; h=Subject:From:To:Cc:In-Reply-To:References:Content-Type:Date: Message-ID:Mime-Version:Content-Transfer-Encoding; b=izcVz2IE7Pf3A47jTNNcjtXjdQongovZmolb9nuDPwGG8h4ecNDhDfhrDemWpoNPE pMS3kVFDLF/Rj+BuMgXXn8dtKZ1WXDLBAOAOgNlhB0soG23qajlPgydtlZHSD4tbIU P5VKYtdKgx51bHjF1CnB9KzsWpvDhSbWr4v8ZlGI= From: Sean Bruno To: Pete French In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Date: Tue, 10 Jul 2012 10:32:44 -0700 Message-ID: <1341941564.2573.13.camel@powernoodle.corp.yahoo.com> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit X-Milter-Version: master.31+4-gbc07cd5+ X-CLX-ID: 941565001 Cc: "stable@freebsd.org" Subject: Re: Recommendation for Hyervisor to host FreeBSD X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jul 2012 17:33:05 -0000 On Thu, 2012-07-05 at 04:43 -0700, Pete French wrote: > So, my work surprise for a Thursday morning is an urgent requirement to > see if we can run a set of FreeBSD machines under virtualised servers. > I have not done this before personally, but I notice from post here > that it doesnt seem uncommon, and I see Xen related commits flowing > past, so I am guessing it is doable. > > So, for running 8 or 9 STABLE can anyone recommend which hypervisor > works best, and is 8 or 9 better as the OS to run ? Am doing a bit > of research myself, but nothing beats persoanl experience in these > matters! > > cheers, > > -pete. Just a few notes from clusteradm@ about this. I've been running a CentOS 5 machine with xen3 pretty successfully with PV 32 bit and 64 bit HVM vms for a while now. I install CentOS 5 and then go to the gitco repo here: http://www.gitco.de/repo/ Pretty straight forward stuff. I install the VMs in full HVM mode using VNC redirection and then switch them over to PV or HVM mode and setup serial consoles. If you have any questions, let me know. I can dump some of the configurations to help you out if you wish. Sean From owner-freebsd-stable@FreeBSD.ORG Tue Jul 10 17:52:29 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 6081E106564A for ; Tue, 10 Jul 2012 17:52:29 +0000 (UTC) (envelope-from serguey-grigoriev@yandex.ru) Received: from forward3h.mail.yandex.net (forward3h.mail.yandex.net [84.201.187.148]) by mx1.freebsd.org (Postfix) with ESMTP id 063358FC1B for ; Tue, 10 Jul 2012 17:52:29 +0000 (UTC) Received: from web30h.yandex.ru (web30h.yandex.ru [84.201.187.164]) by forward3h.mail.yandex.net (Yandex) with ESMTP id 94A4E1361959 for ; Tue, 10 Jul 2012 21:51:51 +0400 (MSK) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1341942711; bh=78RjAc4pPiOR2Kqj+tTN/o+QWOKWgQCu8ov/E0PsOrs=; h=From:To:In-Reply-To:References:Subject:MIME-Version:Message-Id: Date:Content-Transfer-Encoding:Content-Type; b=n6tVzCG2lXYT2VglB/EFy35f7q+xUvx6kWMkFKEIGG/MKNFduqHUutKRulHfs5K6q 7Yf03wfIp7X3PttrIomqAcS+uDNTh3z1zICczciFSRh0eXDom3B06IbWlyEG3VKX5C RCErUkyn4AE/EFfJCuKuwFggdLrrjEy4u/i3hoJE= Received: from 127.0.0.1 (localhost.localdomain [127.0.0.1]) by web30h.yandex.ru (Yandex) with ESMTP id 59EEE30C82A0; Tue, 10 Jul 2012 21:51:51 +0400 (MSK) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1341942711; bh=78RjAc4pPiOR2Kqj+tTN/o+QWOKWgQCu8ov/E0PsOrs=; h=From:To:In-Reply-To:References:Subject:MIME-Version:Message-Id: Date:Content-Transfer-Encoding:Content-Type; b=n6tVzCG2lXYT2VglB/EFy35f7q+xUvx6kWMkFKEIGG/MKNFduqHUutKRulHfs5K6q 7Yf03wfIp7X3PttrIomqAcS+uDNTh3z1zICczciFSRh0eXDom3B06IbWlyEG3VKX5C RCErUkyn4AE/EFfJCuKuwFggdLrrjEy4u/i3hoJE= Received: from [188.134.22.116] ([188.134.22.116]) by web30h.yandex.ru with HTTP; Tue, 10 Jul 2012 21:51:51 +0400 From: S.N.Grigoriev To: FreeBSD Stable In-Reply-To: <1567991339565808@web23h.yandex.ru> References: <201206121325.q5CDPNnt078479@freefall.freebsd.org> <33681339512137@web15h.yandex.ru> <4FD7AFA8.8030807@FreeBSD.org> <1567991339565808@web23h.yandex.ru> MIME-Version: 1.0 Message-Id: <800211341942711@web30h.yandex.ru> Date: Tue, 10 Jul 2012 21:51:51 +0400 X-Mailer: Yamail [ http://yandex.ru ] 5.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain Subject: LibreOffice crashes after buildworld X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 10 Jul 2012 17:52:29 -0000 Hi list, I've rebuilt world (9-stable amd64) from fresh sources and found out that the LibreOffice Calc application crashes with core dump during start. LibreOffice worked fine with my previous system (dated June 27). Any tips? Thanks, Serguey. From owner-freebsd-stable@FreeBSD.ORG Tue Jul 10 18:45:36 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F148F106564A; Tue, 10 Jul 2012 18:45:35 +0000 (UTC) (envelope-from kensmith@buffalo.edu) Received: from localmailA.acsu.buffalo.edu (localmaila.acsu.buffalo.edu [128.205.5.196]) by mx1.freebsd.org (Postfix) with ESMTP id BF6768FC15; Tue, 10 Jul 2012 18:45:35 +0000 (UTC) Received: from localmailA.acsu.buffalo.edu (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 1B145B574; Tue, 10 Jul 2012 14:45:35 -0400 (EDT) Received: from localmailA.acsu.buffalo.edu (localhost [127.0.0.1]) by localmailA.acsu.buffalo.edu (Postfix) with ESMTP id 5E549D79A; Tue, 10 Jul 2012 14:45:34 -0400 (EDT) Received: from smtp2.acsu.buffalo.edu (smtp2.acsu.buffalo.edu [128.205.5.254]) by localmailA.acsu.buffalo.edu (Prefixe) with ESMTP id 46816B574; Tue, 10 Jul 2012 14:45:34 -0400 (EDT) Received: from [128.205.32.76] (bauer.cse.buffalo.edu [128.205.32.76]) (Authenticated sender: kensmith@buffalo.edu) by smtp2.acsu.buffalo.edu (Postfix) with ESMTPSA id 1E65C4BD7A; Tue, 10 Jul 2012 14:45:34 -0400 (EDT) From: Ken Smith To: freebsd-stable Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-a+lsa6sf7ixdu4Uqk0Js" Date: Tue, 10 Jul 2012 14:45:33 -0400 Message-ID: <1341945933.79098.58.camel@bauer.cse.buffalo.edu> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port X-PM-EL-Spam-Prob: : 8% Cc: re Subject: WARNING: stable/9 -> 9.1-BETA1... X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 10 Jul 2012 18:45:36 -0000 --=-a+lsa6sf7ixdu4Uqk0Js Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Through time we learned to try and avoid ever having a "stable branch" call itself BETA-anything. The reality is during every release the BETA builds do get built from what's in the stable branch (we typically don't create the releng/* branches until we hit the RC phase). But past experiences have shown us that not everybody knows that, and/or aren't paying attention to the fact a release is under way. And sorry to be so blunt but... Some people really freak out when they see BETA in anything. So, despite stable branches actually being what BETA builds get built from in the past we've avoided having BETA appear in the source code repositories. Instead we have named it PRERELEASE, and used a "build knob" to have the release build call itself the BETA. The new build infrastructure that got phased in as part of 9.0 doesn't have that build knob. So, I'm about to do what we've tried to avoid before which is do a commit that makes stable/9 call itself 9.1-BETA1. After we complete the BETA1 builds (likely 2 to 3 days for all of them to complete) I'll shift stable/9 to PRERELEASE and it should stay that way until the release process is over (the next scheduled build is RC1 and we'll create releng/9.1 as part of doing that...). --=20 Ken Smith - From there to here, from here to | kensmith@buffalo.edu there, funny things are everywhere. | - Theodor Geisel | --=-a+lsa6sf7ixdu4Uqk0Js Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (FreeBSD) iEYEABECAAYFAk/8eE0ACgkQ/G14VSmup/YY7wCfbl+syty+/CNWIiLZvSgr9Bqp hSAAoJLHn2evGR1yuMZmwxKJc3n+8ae5 =8Xbt -----END PGP SIGNATURE----- --=-a+lsa6sf7ixdu4Uqk0Js-- From owner-freebsd-stable@FreeBSD.ORG Tue Jul 10 19:59:09 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 104EA106564A for ; Tue, 10 Jul 2012 19:59:09 +0000 (UTC) (envelope-from nickolasbug@gmail.com) Received: from mail-we0-f182.google.com (mail-we0-f182.google.com [74.125.82.182]) by mx1.freebsd.org (Postfix) with ESMTP id 966978FC17 for ; Tue, 10 Jul 2012 19:59:08 +0000 (UTC) Received: by weyx56 with SMTP id x56so312303wey.13 for ; Tue, 10 Jul 2012 12:59:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=wTsAAjCPNLOaaWVvfbWxjhiSQHL1nbyQJW4oXtjLjTE=; b=DvpaD2Cx315kW5VAW3zpBzBRjpg9XgFfzbYR5RZnG/+0u9lcXAbLxFCvytDc0EL+44 Xd386pdOMwDknaBm6FFbFhEz3rlaS1mSsuJ8NQp1YOlBAwEltzlY0FR2tBibEXs23r5y YHC6mO5bt9n1sXMOWefCMZ7XDSbzZEiMU90Z6k8A/JVPCp5cjvauw0RFqy5UYziXkKEy 0p41ge0ARuin7jcaXv+KaXlAlggmWowP+YtZBZz7btJN97M3a0chWWA9wrLANCjEArks GedF4da4xfmE4idQ2kA67ZMSJhxhO7ouGuxqG1pUw1qc7UmreLmER1T6mv+VQXKFiDAP XV8w== MIME-Version: 1.0 Received: by 10.180.84.104 with SMTP id x8mr40818202wiy.20.1341950341955; Tue, 10 Jul 2012 12:59:01 -0700 (PDT) Received: by 10.194.56.163 with HTTP; Tue, 10 Jul 2012 12:59:01 -0700 (PDT) In-Reply-To: <800211341942711@web30h.yandex.ru> References: <201206121325.q5CDPNnt078479@freefall.freebsd.org> <33681339512137@web15h.yandex.ru> <4FD7AFA8.8030807@FreeBSD.org> <1567991339565808@web23h.yandex.ru> <800211341942711@web30h.yandex.ru> Date: Tue, 10 Jul 2012 22:59:01 +0300 Message-ID: From: nickolasbug@gmail.com To: "S.N.Grigoriev" Content-Type: text/plain; charset=ISO-8859-1 Cc: FreeBSD Stable Subject: Re: LibreOffice crashes after buildworld X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 10 Jul 2012 19:59:09 -0000 > I've rebuilt world (9-stable amd64) from fresh sources and found out that the LibreOffice Calc application crashes with core dump during start. LibreOffice worked fine with my previous system (dated June 27). Any tips? Sometimes you should rebuild all your ports after rebuilding world. Try to debug core dump and get backtrace. ------- wbr, Nickolas From owner-freebsd-stable@FreeBSD.ORG Tue Jul 10 20:22:39 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8E8351065670 for ; Tue, 10 Jul 2012 20:22:39 +0000 (UTC) (envelope-from nonesuch@longcount.org) Received: from mail-lb0-f182.google.com (mail-lb0-f182.google.com [209.85.217.182]) by mx1.freebsd.org (Postfix) with ESMTP id 0D66F8FC08 for ; Tue, 10 Jul 2012 20:22:38 +0000 (UTC) Received: by lbon10 with SMTP id n10so952133lbo.13 for ; Tue, 10 Jul 2012 13:22:37 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:date :message-id:subject:from:to:content-type:content-transfer-encoding :x-gm-message-state; bh=IGH+ach52bsZNu+ete0VAx+MrKvBjupTer9hVeqhiNk=; b=pRNCWC6GMrdVxG8D3ZogPeMjjSPdsMzxHNfyFUAJ+A0s6xNeKpRp75M/bp2WidvDXE RpKNyh4IXBmEpFoDUy8ej3iBRKCrAlhwnc0AcME8SCeKUl65e61O4CFTmQJA23V1ihTk FwVtBoDZSUOdnBpajOzDo/BDf2ZkrJJ5CuMJdxP27ul3cE6+QFVrkZnhpmPQYN29HIqQ v7c7ArkLpigQDl0LeiDCVcO+vUWrJcAudWMFcaTh5Sl/wpQw/h+MxpcYea2d97zOtUxo kznFGD+SVdG0zDnHMSJvRo7xxYHqkoD3FNU7jNgjeeWImjocy21oRDr3ah86wE8Cf5sA OhMA== MIME-Version: 1.0 Received: by 10.152.103.109 with SMTP id fv13mr46273027lab.33.1341951757884; Tue, 10 Jul 2012 13:22:37 -0700 (PDT) Received: by 10.112.32.6 with HTTP; Tue, 10 Jul 2012 13:22:37 -0700 (PDT) X-Originating-IP: [209.66.78.50] In-Reply-To: References: <589E6EDB-9250-4AEE-9F8F-92A7386C261E@longcount.org> Date: Tue, 10 Jul 2012 16:22:37 -0400 Message-ID: From: Mark Saad To: freebsd-stable@freebsd.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQnJS6AZMTXxzHPL5mKv09rrVKOGoPVExNH2bDuNxDvpuX9RE81KaDbiR9FTjcrcRZK+3eP2 Subject: Re: Recommendation for Hyervisor to host FreeBSD X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jul 2012 20:22:39 -0000 On Fri, Jul 6, 2012 at 11:44 AM, Ivan Voras wrote: > On 05/07/2012 14:21, Mark Saad wrote: > >> I am using VMware esxi v4.01 with no issues for 6, 7, 8 and 9 . Esxi w= ill happily host amd64 installs and i386 provider the underlying hardware s= upports it. The older esx 3.5 works as well on 32bit hardware but I am no l= onger using it. Also I use virtualbox 4 hosted on a Mac and a 9-stable amd6= 4 box with little issue . > > Hello, > > Which type of workload do you run on FreeBSD under VMWare ESXi? e.g. web > server, database, e-mail...? > Ivan We mainly use it to run development and testing instances of services before re roll it out to real hardware. The majority of this would be web servers and database servers, content replication, ldap, and email . As well as some windows vm for some vendor specific specialized tasks . In all I have 95 FreeBSD VMs on 3x HP DL380G6, 2x DL 360G5 and 1x ML370G5 servers and about 120 total vm's give or take a few depending on where people are in their cycle of using a vm. --=20 mark saad | nonesuch@longcount.org From owner-freebsd-stable@FreeBSD.ORG Wed Jul 11 06:35:22 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 01BAB1065672 for ; Wed, 11 Jul 2012 06:35:22 +0000 (UTC) (envelope-from mueller23@insightbb.com) Received: from mail.insightbb.com (smtp1.insight.synacor.com [208.47.185.23]) by mx1.freebsd.org (Postfix) with ESMTP id AA4F28FC15 for ; Wed, 11 Jul 2012 06:35:21 +0000 (UTC) X_CMAE_Category: 0,0 Undefined,Undefined X-CNFS-Analysis: v=1.1 cv=MrqQvws7dyPMukFlhemGyJ7m3hgj01S26zN05OzRz48= c=1 sm=0 a=f4iCGHsY0t4A:10 a=jLN7EqiLvroA:10 a=CR6AKAaqq6ce4B0fhQQA:9 a=Q/oqmR4JO1zR3vNQamCQeQ==:117 X-CM-Score: 0 X-Scanned-by: Cloudmark Authority Engine Authentication-Results: smtp01.insight.synacor.com header.from=mueller23@insightbb.com; sender-id=softfail Authentication-Results: smtp01.insight.synacor.com smtp.mail=mueller23@insightbb.com; spf=softfail; sender-id=softfail Received-SPF: softfail (smtp01.insight.synacor.com: transitional domain insightbb.com does not designate 74.134.26.53 as permitted sender) Received: from [74.134.26.53] ([74.134.26.53:35185] helo=localhost) by mail.insightbb.com (envelope-from ) (ecelerity 2.2.2.40 r(29895/29896)) with ESMTP id 91/59-10780-1AE1DFF4; Wed, 11 Jul 2012 02:35:14 -0400 Date: Wed, 11 Jul 2012 02:35:13 -0400 Message-ID: <91.59.10780.1AE1DFF4@smtp01.insight.synacor.com> From: "Thomas Mueller" To: freebsd-stable@freebsd.org Cc: Ken Smith Subject: Re: WARNING: stable/9 -> 9.1-BETA1... X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 11 Jul 2012 06:35:22 -0000 from Ken Smith : > Through time we learned to try and avoid ever having a "stable branch" > call itself BETA-anything. The reality is during every release the BETA > builds do get built from what's in the stable branch (we typically don't > create the releng/* branches until we hit the RC phase). But past > experiences have shown us that not everybody knows that, and/or aren't > paying attention to the fact a release is under way. And sorry to be so > blunt but... Some people really freak out when they see BETA in > anything. So, despite stable branches actually being what BETA builds > get built from in the past we've avoided having BETA appear in the > source code repositories. Instead we have named it PRERELEASE, and used > a "build knob" to have the release build call itself the BETA. > The new build infrastructure that got phased in as part of 9.0 doesn't > have that build knob. So, I'm about to do what we've tried to avoid > before which is do a commit that makes stable/9 call itself 9.1-BETA1. > After we complete the BETA1 builds (likely 2 to 3 days for all of them > to complete) I'll shift stable/9 to PRERELEASE and it should stay that > way until the release process is over (the next scheduled build is RC1 > and we'll create releng/9.1 as part of doing that...). I'm on RELENG_9, and just to know what path I will be on with this csup supfile tag, will this go to the 9.1 betas, then 9.1 PRERELEASE up to 9.1-RELEASE, then 9.1-STABLE? I suppose RELENG_9_1 will be patches and security updates to 9.1-RELEASE? Tom From owner-freebsd-stable@FreeBSD.ORG Wed Jul 11 07:08:15 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 2C06A106564A for ; Wed, 11 Jul 2012 07:08:15 +0000 (UTC) (envelope-from shen.elf@gmail.com) Received: from mail-vc0-f182.google.com (mail-vc0-f182.google.com [209.85.220.182]) by mx1.freebsd.org (Postfix) with ESMTP id D3A6B8FC12 for ; Wed, 11 Jul 2012 07:08:14 +0000 (UTC) Received: by vcbf1 with SMTP id f1so531711vcb.13 for ; Wed, 11 Jul 2012 00:08:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=UJ38MIul49vW+QV/PBKSY231K2Z4jVP0GVt5QsfXbpk=; b=dKmUhddWjlBPHznxhKMrQJS5zy4yk3CnYrGZU3+QUHxTRyniovn8CTVRxcsnYEdQea Y5aIWzBNW2tX4Bx4+SNicxnM8FQJ8PcniRyiL7+V5EKy8QnBAfKomWS7wLOtnE29FbS+ uKEHAizKgAyvKw+f75r0MqjaAQB5pGmC1Hno9A7SuKV99pKcGAwCmgyVTw/eGfbqYhOS KA1obAu37ZWw41nKOnzu4aWcgLkA//YpNwUmr8MShhfNhGyyamYsg7lzuYHEiY/fvzEn aMyM4RGGfUla/oz/fldEzdoOMpR2lymFHfnfnpa2HpbeG+2FJzsQFhRBN1TfVKNPkQBd W+fA== MIME-Version: 1.0 Received: by 10.220.228.193 with SMTP id jf1mr22470686vcb.73.1341990494015; Wed, 11 Jul 2012 00:08:14 -0700 (PDT) Received: by 10.58.114.97 with HTTP; Wed, 11 Jul 2012 00:08:13 -0700 (PDT) Date: Wed, 11 Jul 2012 15:08:13 +0800 Message-ID: From: Yanhui Shen To: freebsd-stable@freebsd.org Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: error message "CPU0: local APIC error 0x40" X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 11 Jul 2012 07:08:15 -0000 Hi, As titled, I can find that error message in dmesg everytime my laptop boots. Any ideas? Or is this a hw/sw bug? model: ThinkPad R400 278225C dmesg: http://pastebin.com/GiHG9U35 kernel config: http://pastebin.com/0ftRdBp1 kernel modules: http://pastebin.com/qQQBSBfA uname -a > FreeBSD ThinkPad 9.0-STABLE FreeBSD 9.0-STABLE #24: Sat Jul 7 20:37:56 > CST 2012 root@ThinkPad:/usr/obj/usr/src/sys/ThinkPad amd64 part of /var/log/messages: > Jul 11 13:10:51 ThinkPad kernel: Event timer "LAPIC" quality 400 > Jul 11 13:10:51 ThinkPad kernel: ACPI APIC Table: > Jul 11 13:10:51 ThinkPad kernel: FreeBSD/SMP: Multiprocessor System > Detected: 2 CPUs > Jul 11 13:10:51 ThinkPad kernel: FreeBSD/SMP: 1 package(s) x 2 core(s) > Jul 11 13:10:51 ThinkPad kernel: cpu0 (BSP): APIC ID: 0 > Jul 11 13:10:51 ThinkPad kernel: cpu1 (AP): APIC ID: 1 > Jul 11 13:10:51 ThinkPad kernel: ioapic0: Changing APIC ID to 1 > Jul 11 13:10:51 ThinkPad kernel: ioapic0 irqs 0-23 on > motherboard > Jul 11 13:10:51 ThinkPad kernel: kbd1 at kbdmux0 > Jul 11 13:10:51 ThinkPad kernel: acpi0: on motherboard > Jul 11 13:10:51 ThinkPad kernel: *CPU0: local APIC error 0x40 > *Jul 11 13:10:51 ThinkPad kernel: acpi_ec0: 0x11, ECDT> port 0x62,0x66 on acpi0 > Jul 11 13:10:51 ThinkPad kernel: acpi0: Power Button (fixed) > Jul 11 13:10:51 ThinkPad kernel: *acpi0: reservation of 0, a0000 (3) > failed > *Jul 11 13:10:51 ThinkPad kernel: *acpi0: reservation of 100000, 9ff00000 > (3) failed* Jul 11 13:10:51 ThinkPad kernel: cpu0: on acpi0 > Jul 11 13:10:51 ThinkPad kernel: cpu1: on acpi0 part of kenv: > smbios.bios.reldate="12/13/2011" > smbios.bios.vendor="LENOVO" > smbios.bios.version="7VET94WW (3.24 )" > smbios.planar.maker="LENOVO" > smbios.planar.product="278225C" > smbios.system.version="ThinkPad R400" > smbios.version="2.4" -- Best regards, Yanhui Shen From owner-freebsd-stable@FreeBSD.ORG Wed Jul 11 11:19:45 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 4B12D106566B for ; Wed, 11 Jul 2012 11:19:45 +0000 (UTC) (envelope-from freebsd-stable@m.gmane.org) Received: from plane.gmane.org (plane.gmane.org [80.91.229.3]) by mx1.freebsd.org (Postfix) with ESMTP id 002F58FC16 for ; Wed, 11 Jul 2012 11:19:44 +0000 (UTC) Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1SouxG-00018W-Dv for freebsd-stable@freebsd.org; Wed, 11 Jul 2012 13:19:38 +0200 Received: from lara.cc.fer.hr ([161.53.72.113]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 11 Jul 2012 13:19:38 +0200 Received: from ivoras by lara.cc.fer.hr with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 11 Jul 2012 13:19:38 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-stable@freebsd.org From: Ivan Voras Date: Wed, 11 Jul 2012 13:19:27 +0200 Lines: 69 Message-ID: References: <4FF734CD.9070401@rpi.edu> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig8F0474A2E8E32C433B598958" X-Complaints-To: usenet@dough.gmane.org X-Gmane-NNTP-Posting-Host: lara.cc.fer.hr User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:10.0) Gecko/20120213 Thunderbird/10.0 In-Reply-To: <4FF734CD.9070401@rpi.edu> X-Enigmail-Version: 1.3.5 Subject: Re: Problems with crashing IBM X3630 M3/ZFS X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jul 2012 11:19:45 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig8F0474A2E8E32C433B598958 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 06/07/2012 20:56, Bob Healey wrote: > Hello. I've got a quartet of IBM x3630 M3 with one that is frequently > hard locking under heavy NFS load. I am running 9.0-RELEASE with all > the patches from freebsd-update. >=20 > My problem machine has 8 16 core clients, each doing IO intensive tasks= > connected to it via a Procurve and the onboard igb0 interface. Mostly > network reads, typically 10MB read per MB written. > When the machine locks under load, none of the consoles respond, nor ca= n > I reach the machine via ethernet. I can break into DDB via the serial > over lan interface, and am running a debug/witness kernel at the moment= > (I was running GENERIC previously). During the boot sequence, witness > tosses me into DDB ~10 times before I get a login prompt. Prior to this= > machine acting up, it had multiple 802.1q vlans, and ran 9K packets on > its private network to the compute clients. >=20 > A dmesg can be found at http://boyle.che.rpi.edu/~healer/boomer/dmesg > /etc/rc.conf can be found at > http://boyle.che.rpi.edu/~healer/boomer/rc.conf > A listing of installed ports can be found at > http://boyle.che.rpi.edu/~healer/boomer/pkg_info > The output of psauxwwo wchan against my two crash dumps can be found at= > http://boyle.che.rpi.edu/~healer/boomer/crash1-psaux-wchan and > http://boyle.che.rpi.edu/~healer/boomer/crash2-psaux-wchan >=20 > I'm not entire convinced this is software, but I've run out of local > experts to ask, and can't prove its hardware. Hi, I tested a recent IBM machine similar to yours recently (I don't know if it was exactly the same model, but it was probably an M3), and observed a number of lockups which seemed to be related to the RAID card (IBM's ServeRAID, re-branded LSI). I don't know if this has anything to do with your problems, but IIRC in my case there were some kernel messages on the console relating to the driver and/or PCI bus errors on the slot with the RAID controller prior to the lockups - maybe you can check for these. I have other bad experiences with IBM's hardware and have given up on them for running FreeBSD. --------------enig8F0474A2E8E32C433B598958 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk/9YT8ACgkQ/QjVBj3/HSwl+wCgiXX702ufpDZq8OszYNMC0pAe TIMAoJ1spaHw4VRUpotf/j9AIuC8n+NZ =qJYJ -----END PGP SIGNATURE----- --------------enig8F0474A2E8E32C433B598958-- From owner-freebsd-stable@FreeBSD.ORG Wed Jul 11 12:05:03 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C2443106564A for ; Wed, 11 Jul 2012 12:05:03 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigknife-pt.tunnel.tserv9.chi1.ipv6.he.net [IPv6:2001:470:1f10:75::2]) by mx1.freebsd.org (Postfix) with ESMTP id 93A228FC14 for ; Wed, 11 Jul 2012 12:05:03 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 0802EB911; Wed, 11 Jul 2012 08:05:03 -0400 (EDT) From: John Baldwin To: freebsd-stable@freebsd.org Date: Wed, 11 Jul 2012 07:57:14 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p17; KDE/4.5.5; amd64; ; ) References: In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <201207110757.14789.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Wed, 11 Jul 2012 08:05:03 -0400 (EDT) Cc: Yanhui Shen Subject: Re: error message "CPU0: local APIC error 0x40" X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 11 Jul 2012 12:05:03 -0000 On Wednesday, July 11, 2012 3:08:13 am Yanhui Shen wrote: > Hi, > > As titled, I can find that error message in dmesg everytime my laptop boots. > Any ideas? Or is this a hw/sw bug? Oh, hmm. It seems it happens as a side effect of something in ACPI. Error bit 0x40 means an interrupt message was sent to the CPU with an illegal vector (< 32). It is most likely a harmless bug in your BIOS. Can you get a verbose dmesg to narrow down when the error occurs? -- John Baldwin From owner-freebsd-stable@FreeBSD.ORG Thu Jul 12 05:59:21 2012 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 13EC8106564A; Thu, 12 Jul 2012 05:59:21 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from mail-pb0-f54.google.com (mail-pb0-f54.google.com [209.85.160.54]) by mx1.freebsd.org (Postfix) with ESMTP id C9D1E8FC14; Thu, 12 Jul 2012 05:59:20 +0000 (UTC) Received: by pbbro2 with SMTP id ro2so3551332pbb.13 for ; Wed, 11 Jul 2012 22:59:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:date:to:cc:subject:message-id:reply-to:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=SeB/j3rt5CSYFJ5zVJpEPvUO9wJzrjOktbLjB0HnWi8=; b=jyH60SOLh7T4ewP6c7wm/yROB9HvQNURbLvJ1650HNDN2WwTFYUQFBDEoHytRKzFKq 6NJXkGPe1UuC/VbzcX5I//ytFiyP+urRlQc5AC8//DFpWvPL2YwFKxPdH8+U9mnz1zBS ztVvw9Bnb/laZjcEk80Svn8fOXXXq3ImIEiXLjvfcrcHzhgliZ9QGb7C3/YK/XaJICVu olt5CxzQVFEK7pV7wMUXHdYRJT3dzaoQT0SeOeRa1mJmNETw2VKUThUNeRu/Z7FY3lQq EdcQ/0Hv8QShsXcmuevpFWwVyv2mxIBeZdQP4prxwPqn6lGGL0xta1bHaR7eCK1dAguK zFbQ== Received: by 10.68.219.166 with SMTP id pp6mr2601041pbc.35.1342072760521; Wed, 11 Jul 2012 22:59:20 -0700 (PDT) Received: from pyunyh@gmail.com (lpe4.p59-icn.cdngp.net. [114.111.62.249]) by mx.google.com with ESMTPS id pe8sm3174829pbc.76.2012.07.11.22.59.17 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 11 Jul 2012 22:59:19 -0700 (PDT) Received: by pyunyh@gmail.com (sSMTP sendmail emulation); Thu, 12 Jul 2012 14:59:12 -0700 From: YongHyeon PYUN Date: Thu, 12 Jul 2012 14:59:12 -0700 To: sbruno@freebsd.org Message-ID: <20120712215912.GA1456@michelle.cdnetworks.com> References: <20120703185704.GA81296@fupp.net> <20120705010136.GA3218@michelle.cdnetworks.com> <1341855261.6064.5.camel@powernoodle.corp.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1341855261.6064.5.camel@powernoodle.corp.yahoo.com> User-Agent: Mutt/1.4.2.3i Cc: Anders Nordby , "stable@freebsd.org" Subject: Re: bge problems in RELENG_9, bge0: watchdog timeout -- resetting 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, 12 Jul 2012 05:59:21 -0000 On Mon, Jul 09, 2012 at 10:34:21AM -0700, Sean Bruno wrote: > On Wed, 2012-07-04 at 18:01 -0700, YongHyeon PYUN wrote: > > here is a WIP version at the following URL. > > http://people.freebsd.org/~yongari/bge/if_bge.c > > http://people.freebsd.org/~yongari/bge/if_bgereg.h > > http://people.freebsd.org/~yongari/bge/brgphy.c > > > > I have a couple of positive feedbacks but it seems it still has > > some issues. Let me know whether it makes any difference on your > > box. > > I grabbed these updates and applied them cleanly to stable/9 on a Dell > R620 with a quad port BCM5720, I still see watchdog timeouts and reset > indications. I am able to ping out of the box for a short amount of > time before the device hangs and times out. > Sean, sorry for late reply. Given that I have no problems on sample 5720 controller I still have no clue yet. > > > -bash-4.2# ping XXX.XXX.XXX.1 > PING XXX.XXX.XXX.1 (XXX.XXX.XXX.XXX): 56 data bytes > ping: sendto: Network is down > ping: sendto: Network is down > ping: sendto: Network is down > ping: sendto: Network is down > ping: sendto: Network is down > Jul 9 17:31:41 x89 kernel: bge2: watchdog timeout -- > resetting > Jul 9 17:31:41 x89 kernel: bge2: link state changed to > DOWN > Jul 9 17:31:41 x89 kernel: bge2: link state changed to Two link state change message indicates there is an issue in state tracking. I'm experimenting a different approach but it seems it takes too long due to lack of time. Any way, I've uploaded updated bge(4)(URL is the same as before). > DOWN > ping: sendto: No route to host > ping: sendto: No route to host > ping: sendto: No route to host > ping: sendto: No route to host > 64 bytes from XXX.XXX.XXX.1: icmp_seq=9 ttl=64 time=1.408 ms > Jul 9 17:31:45 x89 kernel: bge2: link state changed to UP > Jul 9 17:31:45 x89 kernel: bge2: link state changed to UP [...] From owner-freebsd-stable@FreeBSD.ORG Thu Jul 12 15:18:41 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 9ADE31065670 for ; Thu, 12 Jul 2012 15:18:40 +0000 (UTC) (envelope-from actnow@gmail.com) Received: from mail19a.g19.rapidsite.net (mail19a.g19.rapidsite.net [204.202.242.24]) by mx1.freebsd.org (Postfix) with SMTP id 58FA38FC0C for ; Thu, 12 Jul 2012 15:18:40 +0000 (UTC) Received: from mx83.stngva01.us.mxservers.net (204.202.242.49) by mail19a.g19.rapidsite.net (RS ver 1.0.95vs) with SMTP id 4-0261776319 for ; Thu, 12 Jul 2012 11:18:39 -0400 (EDT) Received: from unknown [199.239.254.58] (HELO w3w19011) by va1-mx83.stngva01.us.mxservers.net (mxl_mta-3.1.0-05) with SMTP id fcaeeff4.2242599840.461332.00-006.va1-mx83.stngva01.us.mxservers.net (envelope-from ); Thu, 12 Jul 2012 11:18:39 -0400 (EDT) thread-index: Ac1gQZ1hCLbRCulWQNyRRDHzVhFmhQ== Thread-Topic: Karen Hill Recommends Advanced Sports to you From: To: Date: Thu, 12 Jul 2012 11:18:39 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Microsoft CDO for Windows 2000 Content-Class: urn:content-classes:message Importance: normal Priority: normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.4913 X-Spam: [F=0.5000000000; S=0.200(2010122901); MH=0.800(2012071211)] X-MAIL-FROM: X-SOURCE-IP: [199.239.254.58] X-SF-Loop: 1 Subject: Karen Hill Recommends Advanced Sports to you X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 12 Jul 2012 15:18:41 -0000 >From :Karen Hill Email :actnow@gmail.com Friend Name :Friend Friend Email :freebsd-stable@freebsd.org comment :Hi Friend, Congratulations: Get $925 Commission Now!!! We Start putting 25 referral members everyday in your team start July-07--14-2012 Cut Off Date. YOU ALREADY HAVE 388 Pre-Enrollee\'s and 25 PAID Member\'s everyday in your TEAM. And Still Growing AND IT IS STILL Waiting the $925 Commissions. IMPORTANT: APPLY NOW or Before July.14,2012 is the Cut-Off date!To lock in your Position! Was Price $197 (today It's only $37 Promo until July-14-2012) Lifetime Membership to secure $925 Commission Send on July-30/2012 Direct to your Paypal Account or A.T.M.. So we understand what's the Power of our Team so don't wasting your time act now!!!.so If you advance member join before cut-off you are early recieved commissions.. Secure your position in the fast growing Powerline above all the people below you! Get Positioned Immediately with Priority Placement in the Fastest Growing TEAM Secure Here:==>> http://tinyurl.com/6ln3ryg Secure Here:==>> http://tinyurl.com/88k4up2 , TYPE = Date & Time == New PAID Members ====== Country's M JULY.11 @ 11:19 PM = Shelly Marquez ===== United States M JULY.11 @ 11:19 PM == Rolldan Pacson ===== United States M JULY.11 @ 06:23 PM === Stephen Harris ===== Canada M JULY.11 @ 11:19 PM ==== Jackie Parkers ===== United States M JULY.11 @ 11:19 PM ===== Rowena Harison ===== United States M JULY.11 @ 06:23 PM ====== Geralden Roses ===== New Zealand M JULY.11 @ 08:26 AM ======= Renee Jenkinse ===== Australia P JULY.11 @ 02:31 PM ======== Elizabeth Rios ===== Singapore M JULY.11 @ 02:37 PM ========= Karen Schiller ===== United Kingdom M JULY.11 @ 04:21 PM ========== Analou Roddman ===== Germany P JULY.11 @ 09:38 PM =========== Karen Stephens ===== Sri Lanka P JULY.11 @ 10:45 PM ============ Josephen Coper ===== United States M JULY.11 @ 10:19 AM ============= Vecky Camptons ===== United States P JULY.11 @ 08:32 PM ============ Gaynell Bailey ===== South Africa M JULY.11 @ 09:40 PM =========== Barbara Thunder ===== Netherlands P JULY.11 @ 10:21 AM ========== James Williams ===== North Carolina P JULY.11 @ 11:08 PM ========= David Robinson ===== United States M JULY.11 @ 12:39 AM ======== Carolyn Smiths ===== Hungary M JULY.11 @ 02:30 AM ======= Andrew Stocton ===== New Zealand P JULY.11 @ 02:42 AM ====== Matthew Evander ===== Portugal M JULY.11 @ 08:18 AM ===== Steven Hopekin ===== United States P JULY.11 @ 02:38 AM ==== Jenny Hamilton ===== United States P JULY.11 @ 02:53 AM === Stefany Gibson ===== Italy P JULY.11 @ 02:38 AM == Amie Stephenson ===== United States Therefore, you have a GUARANTEED $925 Commission every month from now on!. Earn $37 Per Process! Each $37 x 25 =$925 Commission will be yours...! Be Sure to Copy the link below & Paste into your browser and press enter: To Secure your $925 commission! Secure Here:==>> http://tinyurl.com/6ln3ryg Secure Here:==>> http://tinyurl.com/88k4up2 Once your membership is approved .all referral members under your name.all of the fallowing sales DIRECTLY Deposit to your Paypal account.And also members join on July 2012. all coming Commissions will be yours. Date: July 11, 2012 >From the Desk of: Karen Hill Director Of Human Resources United States P.P.S. This one-time, limited offer will not last much longer. Don't let the chance of a lifetime pass you by. This is the opportunity you may have been waiting your entire life for.Don't delay any longer,click " " and join now and start making money online today. From owner-freebsd-stable@FreeBSD.ORG Thu Jul 12 19:06:52 2012 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 38BE4106564A; Thu, 12 Jul 2012 19:06:52 +0000 (UTC) (envelope-from seanbru@yahoo-inc.com) Received: from mrout2-b.corp.bf1.yahoo.com (mrout2-b.corp.bf1.yahoo.com [98.139.253.105]) by mx1.freebsd.org (Postfix) with ESMTP id D530E8FC12; Thu, 12 Jul 2012 19:06:51 +0000 (UTC) Received: from [IPv6:::1] (rideseveral.corp.yahoo.com [10.73.160.231]) by mrout2-b.corp.bf1.yahoo.com (8.14.4/8.14.4/y.out) with ESMTP id q6CJ6T4b069292; Thu, 12 Jul 2012 12:06:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=yahoo-inc.com; s=cobra; t=1342119991; bh=BJrNIjP5WNjLHCG7WBlTWreAuZlAnl0t1QpBFYAvhMU=; h=Subject:From:To:Cc:In-Reply-To:References:Content-Type:Date: Message-ID:Mime-Version:Content-Transfer-Encoding; b=k6l+gbLbToEc4jE4eL5pBSGoiNSn+kzHOd2IqxIB8cBd02SL/JbgAj7OsZYdycbPY 5R1TOQwsFfNnED+fJndTnZZ51peFieQWp+Ej2zfhUtwDgefwB54wrGNG1Bhu6/3SPT QrO43Ns9GYnZUl3xBXJghTQ2SbIod6x9f2MDGNwA= From: Sean Bruno To: "pyunyh@gmail.com" In-Reply-To: <20120712215912.GA1456@michelle.cdnetworks.com> References: <20120703185704.GA81296@fupp.net> <20120705010136.GA3218@michelle.cdnetworks.com> <1341855261.6064.5.camel@powernoodle.corp.yahoo.com> <20120712215912.GA1456@michelle.cdnetworks.com> Content-Type: text/plain; charset="UTF-8" Date: Thu, 12 Jul 2012 12:06:29 -0700 Message-ID: <1342119989.2524.5.camel@powernoodle.corp.yahoo.com> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit X-Milter-Version: master.31+4-gbc07cd5+ X-CLX-ID: 119990000 Cc: "stable@freebsd.org" , Anders Nordby Subject: Re: bge problems in RELENG_9, bge0: watchdog timeout -- resetting X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 12 Jul 2012 19:06:52 -0000 On Thu, 2012-07-12 at 14:59 -0700, YongHyeon PYUN wrote: > > I grabbed these updates and applied them cleanly to stable/9 on a > Dell > > R620 with a quad port BCM5720, I still see watchdog timeouts and > reset > > indications. I am able to ping out of the box for a short amount of > > time before the device hangs and times out. > > > > Sean, sorry for late reply. > Given that I have no problems on sample 5720 controller I still > have no clue yet. > No problems ... :-) > > > > > > -bash-4.2# ping XXX.XXX.XXX.1 > > PING XXX.XXX.XXX.1 (XXX.XXX.XXX.XXX): 56 data bytes > > ping: sendto: Network is down > > ping: sendto: Network is down > > ping: sendto: Network is down > > ping: sendto: Network is down > > ping: sendto: Network is down > > Jul 9 17:31:41 x89 kernel: bge2: watchdog timeout -- > > resetting > > Jul 9 17:31:41 x89 kernel: bge2: link state changed > to > > DOWN > > Jul 9 17:31:41 x89 kernel: bge2: link state changed > to > > Two link state change message indicates there is an issue in state > tracking. I'm experimenting a different approach but it seems it > takes too long due to lack of time. Any way, I've uploaded updated > bge(4)(URL is the same as before). I see a bunch of firmware updates for this host along with an update to the BCM firmware package for this Dell box. I'll update my system's driver first, validate pass/fail, if fail, then I'll update the firmware bits and validate some more. sean From owner-freebsd-stable@FreeBSD.ORG Thu Jul 12 20:34:19 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id D9405106564A; Thu, 12 Jul 2012 20:34:19 +0000 (UTC) (envelope-from smccoy@greatbaysoftware.com) Received: from ecbiz102.inmotionhosting.com (ecbiz102.inmotionhosting.com [70.39.235.94]) by mx1.freebsd.org (Postfix) with ESMTP id 944108FC08; Thu, 12 Jul 2012 20:34:19 +0000 (UTC) Received: from c-71-233-85-132.hsd1.nh.comcast.net ([71.233.85.132]:50618 helo=smccoy-mbp.local) by ecbiz102.inmotionhosting.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1SpQ5L-0001Rq-Gs; Thu, 12 Jul 2012 16:34:09 -0400 Message-ID: <4FFF34BA.9030002@greatbaysoftware.com> Date: Thu, 12 Jul 2012 16:34:02 -0400 From: Steve McCoy User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 MIME-Version: 1.0 To: jhb@freebsd.org References: <4FDABA0B.5030702@greatbaysoftware.com> <201206150804.46341.jhb@freebsd.org> <4FE3DA14.9090506@greatbaysoftware.com> <4FFF301E.30603@greatbaysoftware.com> In-Reply-To: <4FFF301E.30603@greatbaysoftware.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ecbiz102.inmotionhosting.com X-AntiAbuse: Original Domain - freebsd.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - greatbaysoftware.com Cc: Charles Owens , freebsd-stable@freebsd.org Subject: Re: mfi(4) IO performance regression, post 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: Thu, 12 Jul 2012 20:34:19 -0000 On 7/12/12 4:14 PM, Charles Owens wrote: > On Thursday, June 21, 2012 10:36:04 pm Charles Owens wrote: >> >> On 6/15/12 8:04 AM, John Baldwin wrote: >> > On Friday, June 15, 2012 12:28:59 am Charles Owens wrote: >> >> Hello FreeBSD folk, >> >> >> >> We're seeing what appears to be a storage performance regression as we >> >> try to move from 8.1 (i386) to 8.3. We looked at 8.2 also and it >> >> appears that the regression happened between 8.1 and 8.2. >> >> >> >> Our system is an Intel S5520UR Server with 12 GB RAM, dual 4-core >> CPUs. >> >> Storage is a LSI MegaSAS 1078 controller (mfi) in a RAID-10 >> >> configuration, using UFS + geom_journal for filesystem. >> >> >> >> Postgresql performance, as seen via pgbench, dropped by approx 20%. >> >> This testing was done with our usual PAE-enabled kernels. We then >> went >> >> back to GENERIC kernels and did comparisons using "bonnie", results >> >> below. Following that is a kernel boot log. >> >> >> >> Notably, we're seeing this regression only with our RAID mfi(4) based >> >> systems. Notably, from looking at FreeBSD source changelogs it >> appears >> >> that the mfi(4) code has seen some changes since 8.1. >> > Between 8.1 and 8.2 mfi has not had any significant changes. The >> only changes >> > made to sys/dev/mfi were to add a new constant: >> > >> >> svn diff svn+ssh://svn.freebsd.org/base/releng/8.1/sys/dev/mfi >> > svn+ssh://svn.freebsd.org/base/releng/8.2/sys/dev/mfi >> > Index: mfireg.h >> > =================================================================== >> > --- mfireg.h (.../8.1/sys/dev/mfi) (revision 237134) >> > +++ mfireg.h (.../8.2/sys/dev/mfi) (revision 237134) >> > @@ -975,7 +975,9 @@ >> > MFI_PD_STATE_OFFLINE = 0x10, >> > MFI_PD_STATE_FAILED = 0x11, >> > MFI_PD_STATE_REBUILD = 0x14, >> > - MFI_PD_STATE_ONLINE = 0x18 >> > + MFI_PD_STATE_ONLINE = 0x18, >> > + MFI_PD_STATE_COPYBACK = 0x20, >> > + MFI_PD_STATE_SYSTEM = 0x40 >> > }; >> > >> > union mfi_ld_ref { >> > >> > The difference in write performance must be due to something else. You >> > mentioned you are using UFS + gjournal. I think gjournal uses >> BIO_FLUSH, so I >> > wonder if this is related: >> > >> > >> ------------------------------------------------------------------------ >> > r212939 | gibbs | 2010-09-20 19:39:00 -0400 (Mon, 20 Sep 2010) | 61 >> lines >> > >> > MFC 212160: >> > >> > Correct bioq_disksort so that bioq_insert_tail() offers barrier >> semantic. >> > Add the BIO_ORDERED flag for struct bio and update bio clients to >> use it. >> > >> > The barrier semantics of bioq_insert_tail() were broken in two ways: >> > >> > o In bioq_disksort(), an added bio could be inserted at the head of >> > the queue, even when a barrier was present, if the sort key for >> > the new entry was less than that of the last queued barrier bio. >> > >> > o The last_offset used to generate the sort key for newly queued bios >> > did not stay at the position of the barrier until either the >> > barrier was de-queued, or a new barrier (which updates last_offset) >> > was queued. When a barrier is in effect, we know that the disk >> > will pass through the barrier position just before the >> > "blocked bios" are released, so using the barrier's offset for >> > last_offset is the optimal choice. >> > >> > sys/geom/sched/subr_disk.c: >> > sys/kern/subr_disk.c: >> > o Update last_offset in bioq_insert_tail(). >> > >> > o Only update last_offset in bioq_remove() if the removed >> bio is >> > at the head of the queue (typically due to a call via >> > bioq_takefirst()) and no barrier is active. >> > >> > o In bioq_disksort(), if we have a barrier (insert_point is >> non-NULL), >> > set prev to the barrier and cur to it's next element. >> Now that >> > last_offset is kept at the barrier position, this change >> isn't >> > strictly necessary, but since we have to take a decision >> branch >> > anyway, it does avoid one, no-op, loop iteration in the >> while >> > loop that immediately follows. >> > >> > o In bioq_disksort(), bypass the normal sort for bios with the >> > BIO_ORDERED attribute and instead insert them into the queue >> > with bioq_insert_tail(). bioq_insert_tail() not only gives >> > the desired command order during insertion, but also >> provides >> > barrier semantics so that commands disksorted in the future >> > cannot pass the just enqueued transaction. >> > >> > sys/sys/bio.h: >> > Add BIO_ORDERED as bit 4 of the bio_flags field in struct bio. >> > >> > sys/cam/ata/ata_da.c: >> > sys/cam/scsi/scsi_da.c >> > Use an ordered command for SCSI/ATA-NCQ commands issued in >> > response to bios with the BIO_ORDERED flag set. >> > >> > sys/cam/scsi/scsi_da.c >> > Use an ordered tag when issuing a synchronize cache command. >> > >> > Wrap some lines to 80 columns. >> > >> > sys/cddl/contrib/opensolaris/uts/common/fs/zfs/vdev_geom.c >> > sys/geom/geom_io.c >> > Mark bios with the BIO_FLUSH command as BIO_ORDERED. >> > >> > Sponsored by: Spectra Logic Corporation >> > >> ------------------------------------------------------------------------ >> > >> > Can you try perhaps commenting out the 'bp->bio_flags |= >> BIO_ORDERED' line >> > changed in geom_io.c in 8.2? That would be effectively reverting this >> > portion of the diff: >> > >> > Index: geom_io.c >> > =================================================================== >> > --- geom_io.c (.../8.1/sys/geom) (revision 237134) >> > +++ geom_io.c (.../8.2/sys/geom) (revision 237134) >> > @@ -265,6 +265,7 @@ >> > g_trace(G_T_BIO, "bio_flush(%s)", cp->provider->name); >> > bp = g_alloc_bio(); >> > bp->bio_cmd = BIO_FLUSH; >> > + bp->bio_flags |= BIO_ORDERED; >> > bp->bio_done = NULL; >> > bp->bio_attribute = NULL; >> > bp->bio_offset = cp->provider->mediasize; >> > >> >> John... thanks for the suggestion. I've built and tested a kernel with >> this change made. Result: no change (same performance as with >> 8.2-GENERIC). Any thoughts as to where to go next? > > Hmm. That seemed the most plausible candidate when I looked at this. > > Do you use quotas (there is one change in UFS related to quotas)? > > There are 5 changes that involve sys/kern/vfs_bio.c in 8.2: > 209459, 212229, 212562, 212583, and 213890. > > Can you possibly test out kernels from stable/8 at those revisions on an > 8.1 > world and see if you can narrow it down futher? > > Barring that, can you do a binary search of kernels from stable/8 > between 8.1 > and 8.2 on an 8.1 world to see which commit caused the change in write > performance? > Hi John, I'm working with Charles to narrow this down. Looks like revision 212229 is the culprit, or at least around the same time to it, if this change isn't what slowed things down. The change to sys/kern/vfs_bio.c modifies some synchronization in dev_strategy(): --- stable/8/sys/kern/vfs_bio.c 2010/06/23 10:06:57 209459 +++ stable/8/sys/kern/vfs_bio.c 2010/09/05 14:27:55 212229 @@ -3195,6 +3195,7 @@ { struct cdevsw *csw; struct bio *bip; + int ref; if ((!bp->b_iocmd) || (bp->b_iocmd & (bp->b_iocmd - 1))) panic("b_iocmd botch"); @@ -3216,7 +3217,7 @@ KASSERT(dev->si_refcount > 0, ("dev_strategy on un-referenced struct cdev *(%s)", devtoname(dev))); - csw = dev_refthread(dev); + csw = dev_refthread(dev, &ref); if (csw == NULL) { g_destroy_bio(bip); bp->b_error = ENXIO; @@ -3225,7 +3226,7 @@ return; } (*csw->d_strategy)(bip); - dev_relthread(dev); + dev_relthread(dev, ref); } /* This is in line with the following changes to dev_refthread and dev_relthread, but it's not obvious to me how these alone would impact performance. Do you have any thoughts? --- stable/8/sys/kern/kern_conf.c 2010/07/03 18:19:59 209668 +++ stable/8/sys/kern/kern_conf.c 2010/09/05 14:27:55 212229 @@ -177,12 +177,16 @@ } struct cdevsw * -dev_refthread(struct cdev *dev) +dev_refthread(struct cdev *dev, int *ref) { struct cdevsw *csw; struct cdev_priv *cdp; mtx_assert(&devmtx, MA_NOTOWNED); + if ((dev->si_flags & SI_ETERNAL) != 0) { + *ref = 0; + return (dev->si_devsw); + } dev_lock(); csw = dev->si_devsw; if (csw != NULL) { @@ -193,36 +197,59 @@ csw = NULL; } dev_unlock(); + *ref = 1; return (csw); } … void -dev_relthread(struct cdev *dev) +dev_relthread(struct cdev *dev, int ref) { mtx_assert(&devmtx, MA_NOTOWNED); + if (!ref) + return; dev_lock(); KASSERT(dev->si_threadcount > 0, ("%s threadcount is wrong", dev->si_name)); From owner-freebsd-stable@FreeBSD.ORG Fri Jul 13 03:47:32 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id ACEFD106566B; Fri, 13 Jul 2012 03:47:32 +0000 (UTC) (envelope-from smccoy@greatbaysoftware.com) Received: from ecbiz102.inmotionhosting.com (ecbiz102.inmotionhosting.com [70.39.235.94]) by mx1.freebsd.org (Postfix) with ESMTP id 5AAFB8FC08; Fri, 13 Jul 2012 03:47:32 +0000 (UTC) Received: from c-71-233-85-132.hsd1.nh.comcast.net ([71.233.85.132]:52858 helo=smccoy-mbp.local) by ecbiz102.inmotionhosting.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1SpWqm-0000j3-Mh; Thu, 12 Jul 2012 23:47:28 -0400 Message-ID: <4FFF9A50.40006@greatbaysoftware.com> Date: Thu, 12 Jul 2012 23:47:28 -0400 From: Steve McCoy User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 MIME-Version: 1.0 To: jhb@freebsd.org References: <4FDABA0B.5030702@greatbaysoftware.com> <201206150804.46341.jhb@freebsd.org> <4FE3DA14.9090506@greatbaysoftware.com> <4FFF301E.30603@greatbaysoftware.com> <4FFF34BA.9030002@greatbaysoftware.com> In-Reply-To: <4FFF34BA.9030002@greatbaysoftware.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ecbiz102.inmotionhosting.com X-AntiAbuse: Original Domain - freebsd.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - greatbaysoftware.com Cc: Charles Owens , freebsd-stable@freebsd.org Subject: Re: mfi(4) IO performance regression, post 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, 13 Jul 2012 03:47:32 -0000 On 7/12/12 4:34 PM, Steve McCoy wrote: > On 7/12/12 4:14 PM, Charles Owens wrote: >> On Thursday, June 21, 2012 10:36:04 pm Charles Owens wrote: >>> >>> On 6/15/12 8:04 AM, John Baldwin wrote: >>> > On Friday, June 15, 2012 12:28:59 am Charles Owens wrote: >>> >> Hello FreeBSD folk, >>> >> >>> >> We're seeing what appears to be a storage performance regression >>> as we >>> >> try to move from 8.1 (i386) to 8.3. We looked at 8.2 also and it >>> >> appears that the regression happened between 8.1 and 8.2. >>> >> >>> >> Our system is an Intel S5520UR Server with 12 GB RAM, dual 4-core >>> CPUs. >>> >> Storage is a LSI MegaSAS 1078 controller (mfi) in a RAID-10 >>> >> configuration, using UFS + geom_journal for filesystem. >>> >> >>> >> Postgresql performance, as seen via pgbench, dropped by approx 20%. >>> >> This testing was done with our usual PAE-enabled kernels. We then >>> went >>> >> back to GENERIC kernels and did comparisons using "bonnie", results >>> >> below. Following that is a kernel boot log. >>> >> >>> >> Notably, we're seeing this regression only with our RAID mfi(4) based >>> >> systems. Notably, from looking at FreeBSD source changelogs it >>> appears >>> >> that the mfi(4) code has seen some changes since 8.1. >>> > Between 8.1 and 8.2 mfi has not had any significant changes. The >>> only changes >>> > made to sys/dev/mfi were to add a new constant: >>> > >>> >> svn diff svn+ssh://svn.freebsd.org/base/releng/8.1/sys/dev/mfi >>> > svn+ssh://svn.freebsd.org/base/releng/8.2/sys/dev/mfi >>> > Index: mfireg.h >>> > =================================================================== >>> > --- mfireg.h (.../8.1/sys/dev/mfi) (revision 237134) >>> > +++ mfireg.h (.../8.2/sys/dev/mfi) (revision 237134) >>> > @@ -975,7 +975,9 @@ >>> > MFI_PD_STATE_OFFLINE = 0x10, >>> > MFI_PD_STATE_FAILED = 0x11, >>> > MFI_PD_STATE_REBUILD = 0x14, >>> > - MFI_PD_STATE_ONLINE = 0x18 >>> > + MFI_PD_STATE_ONLINE = 0x18, >>> > + MFI_PD_STATE_COPYBACK = 0x20, >>> > + MFI_PD_STATE_SYSTEM = 0x40 >>> > }; >>> > >>> > union mfi_ld_ref { >>> > >>> > The difference in write performance must be due to something else. >>> You >>> > mentioned you are using UFS + gjournal. I think gjournal uses >>> BIO_FLUSH, so I >>> > wonder if this is related: >>> > >>> > >>> ------------------------------------------------------------------------ >>> > r212939 | gibbs | 2010-09-20 19:39:00 -0400 (Mon, 20 Sep 2010) | 61 >>> lines >>> > >>> > MFC 212160: >>> > >>> > Correct bioq_disksort so that bioq_insert_tail() offers barrier >>> semantic. >>> > Add the BIO_ORDERED flag for struct bio and update bio clients to >>> use it. >>> > >>> > The barrier semantics of bioq_insert_tail() were broken in two ways: >>> > >>> > o In bioq_disksort(), an added bio could be inserted at the head of >>> > the queue, even when a barrier was present, if the sort key for >>> > the new entry was less than that of the last queued barrier bio. >>> > >>> > o The last_offset used to generate the sort key for newly queued >>> bios >>> > did not stay at the position of the barrier until either the >>> > barrier was de-queued, or a new barrier (which updates >>> last_offset) >>> > was queued. When a barrier is in effect, we know that the disk >>> > will pass through the barrier position just before the >>> > "blocked bios" are released, so using the barrier's offset for >>> > last_offset is the optimal choice. >>> > >>> > sys/geom/sched/subr_disk.c: >>> > sys/kern/subr_disk.c: >>> > o Update last_offset in bioq_insert_tail(). >>> > >>> > o Only update last_offset in bioq_remove() if the removed >>> bio is >>> > at the head of the queue (typically due to a call via >>> > bioq_takefirst()) and no barrier is active. >>> > >>> > o In bioq_disksort(), if we have a barrier (insert_point is >>> non-NULL), >>> > set prev to the barrier and cur to it's next element. >>> Now that >>> > last_offset is kept at the barrier position, this change >>> isn't >>> > strictly necessary, but since we have to take a decision >>> branch >>> > anyway, it does avoid one, no-op, loop iteration in the >>> while >>> > loop that immediately follows. >>> > >>> > o In bioq_disksort(), bypass the normal sort for bios with >>> the >>> > BIO_ORDERED attribute and instead insert them into the >>> queue >>> > with bioq_insert_tail(). bioq_insert_tail() not only gives >>> > the desired command order during insertion, but also >>> provides >>> > barrier semantics so that commands disksorted in the future >>> > cannot pass the just enqueued transaction. >>> > >>> > sys/sys/bio.h: >>> > Add BIO_ORDERED as bit 4 of the bio_flags field in struct >>> bio. >>> > >>> > sys/cam/ata/ata_da.c: >>> > sys/cam/scsi/scsi_da.c >>> > Use an ordered command for SCSI/ATA-NCQ commands issued in >>> > response to bios with the BIO_ORDERED flag set. >>> > >>> > sys/cam/scsi/scsi_da.c >>> > Use an ordered tag when issuing a synchronize cache command. >>> > >>> > Wrap some lines to 80 columns. >>> > >>> > sys/cddl/contrib/opensolaris/uts/common/fs/zfs/vdev_geom.c >>> > sys/geom/geom_io.c >>> > Mark bios with the BIO_FLUSH command as BIO_ORDERED. >>> > >>> > Sponsored by: Spectra Logic Corporation >>> > >>> ------------------------------------------------------------------------ >>> > >>> > Can you try perhaps commenting out the 'bp->bio_flags |= >>> BIO_ORDERED' line >>> > changed in geom_io.c in 8.2? That would be effectively reverting this >>> > portion of the diff: >>> > >>> > Index: geom_io.c >>> > =================================================================== >>> > --- geom_io.c (.../8.1/sys/geom) (revision 237134) >>> > +++ geom_io.c (.../8.2/sys/geom) (revision 237134) >>> > @@ -265,6 +265,7 @@ >>> > g_trace(G_T_BIO, "bio_flush(%s)", cp->provider->name); >>> > bp = g_alloc_bio(); >>> > bp->bio_cmd = BIO_FLUSH; >>> > + bp->bio_flags |= BIO_ORDERED; >>> > bp->bio_done = NULL; >>> > bp->bio_attribute = NULL; >>> > bp->bio_offset = cp->provider->mediasize; >>> > >>> >>> John... thanks for the suggestion. I've built and tested a kernel with >>> this change made. Result: no change (same performance as with >>> 8.2-GENERIC). Any thoughts as to where to go next? >> >> Hmm. That seemed the most plausible candidate when I looked at this. >> >> Do you use quotas (there is one change in UFS related to quotas)? >> >> There are 5 changes that involve sys/kern/vfs_bio.c in 8.2: >> 209459, 212229, 212562, 212583, and 213890. >> >> Can you possibly test out kernels from stable/8 at those revisions on an >> 8.1 >> world and see if you can narrow it down futher? >> >> Barring that, can you do a binary search of kernels from stable/8 >> between 8.1 >> and 8.2 on an 8.1 world to see which commit caused the change in write >> performance? >> > > Hi John, I'm working with Charles to narrow this down. > > Looks like revision 212229 is the culprit, or at least around the same > time to it, if this change isn't what slowed things down. The change to > sys/kern/vfs_bio.c modifies some synchronization in dev_strategy(): > Actually, hold that thought. I had a hunch that I wasn't thorough enough, so I decided to try 212228 — the performance is the same as with 212229, so vfs_bio seems to be out of the picture. I'm going to binary search between 209459 and 212229, and see what I find. From owner-freebsd-stable@FreeBSD.ORG Fri Jul 13 14:42:09 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EAF7D1065675 for ; Fri, 13 Jul 2012 14:42:09 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigknife-pt.tunnel.tserv9.chi1.ipv6.he.net [IPv6:2001:470:1f10:75::2]) by mx1.freebsd.org (Postfix) with ESMTP id 7829F8FC18 for ; Fri, 13 Jul 2012 14:42:09 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id E6CA1B9A5; Fri, 13 Jul 2012 10:42:08 -0400 (EDT) From: John Baldwin To: freebsd-stable@freebsd.org Date: Fri, 13 Jul 2012 09:39:54 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p17; KDE/4.5.5; amd64; ; ) References: <4FDABA0B.5030702@greatbaysoftware.com> <4FFF34BA.9030002@greatbaysoftware.com> <4FFF9A50.40006@greatbaysoftware.com> In-Reply-To: <4FFF9A50.40006@greatbaysoftware.com> MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Message-Id: <201207130939.54311.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Fri, 13 Jul 2012 10:42:09 -0400 (EDT) Cc: Charles Owens , Steve McCoy Subject: Re: mfi(4) IO performance regression, post 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, 13 Jul 2012 14:42:10 -0000 On Thursday, July 12, 2012 11:47:28 pm Steve McCoy wrote: > On 7/12/12 4:34 PM, Steve McCoy wrote: > > On 7/12/12 4:14 PM, Charles Owens wrote: > >> On Thursday, June 21, 2012 10:36:04 pm Charles Owens wrote: > >>> > >>> On 6/15/12 8:04 AM, John Baldwin wrote: > >>> > On Friday, June 15, 2012 12:28:59 am Charles Owens wrote: > >>> >> Hello FreeBSD folk, > >>> >> > >>> >> We're seeing what appears to be a storage performance regression > >>> as we > >>> >> try to move from 8.1 (i386) to 8.3. We looked at 8.2 also and it > >>> >> appears that the regression happened between 8.1 and 8.2. > >>> >> > >>> >> Our system is an Intel S5520UR Server with 12 GB RAM, dual 4-core > >>> CPUs. > >>> >> Storage is a LSI MegaSAS 1078 controller (mfi) in a RAID-10 > >>> >> configuration, using UFS + geom_journal for filesystem. > >>> >> > >>> >> Postgresql performance, as seen via pgbench, dropped by approx 20%. > >>> >> This testing was done with our usual PAE-enabled kernels. We then > >>> went > >>> >> back to GENERIC kernels and did comparisons using "bonnie", results > >>> >> below. Following that is a kernel boot log. > >>> >> > >>> >> Notably, we're seeing this regression only with our RAID mfi(4) ba= sed > >>> >> systems. Notably, from looking at FreeBSD source changelogs it > >>> appears > >>> >> that the mfi(4) code has seen some changes since 8.1. > >>> > Between 8.1 and 8.2 mfi has not had any significant changes. The > >>> only changes > >>> > made to sys/dev/mfi were to add a new constant: > >>> > > >>> >> svn diff svn+ssh://svn.freebsd.org/base/releng/8.1/sys/dev/mfi > >>> > svn+ssh://svn.freebsd.org/base/releng/8.2/sys/dev/mfi > >>> > Index: mfireg.h > >>> > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > >>> > --- mfireg.h (.../8.1/sys/dev/mfi) (revision 237134) > >>> > +++ mfireg.h (.../8.2/sys/dev/mfi) (revision 237134) > >>> > @@ -975,7 +975,9 @@ > >>> > MFI_PD_STATE_OFFLINE =3D 0x10, > >>> > MFI_PD_STATE_FAILED =3D 0x11, > >>> > MFI_PD_STATE_REBUILD =3D 0x14, > >>> > - MFI_PD_STATE_ONLINE =3D 0x18 > >>> > + MFI_PD_STATE_ONLINE =3D 0x18, > >>> > + MFI_PD_STATE_COPYBACK =3D 0x20, > >>> > + MFI_PD_STATE_SYSTEM =3D 0x40 > >>> > }; > >>> > > >>> > union mfi_ld_ref { > >>> > > >>> > The difference in write performance must be due to something else. > >>> You > >>> > mentioned you are using UFS + gjournal. I think gjournal uses > >>> BIO_FLUSH, so I > >>> > wonder if this is related: > >>> > > >>> > > >>> ---------------------------------------------------------------------= =2D-- > >>> > r212939 | gibbs | 2010-09-20 19:39:00 -0400 (Mon, 20 Sep 2010) | 61 > >>> lines > >>> > > >>> > MFC 212160: > >>> > > >>> > Correct bioq_disksort so that bioq_insert_tail() offers barrier > >>> semantic. > >>> > Add the BIO_ORDERED flag for struct bio and update bio clients to > >>> use it. > >>> > > >>> > The barrier semantics of bioq_insert_tail() were broken in two ways: > >>> > > >>> > o In bioq_disksort(), an added bio could be inserted at the head = of > >>> > the queue, even when a barrier was present, if the sort key for > >>> > the new entry was less than that of the last queued barrier bio. > >>> > > >>> > o The last_offset used to generate the sort key for newly queued > >>> bios > >>> > did not stay at the position of the barrier until either the > >>> > barrier was de-queued, or a new barrier (which updates > >>> last_offset) > >>> > was queued. When a barrier is in effect, we know that the disk > >>> > will pass through the barrier position just before the > >>> > "blocked bios" are released, so using the barrier's offset for > >>> > last_offset is the optimal choice. > >>> > > >>> > sys/geom/sched/subr_disk.c: > >>> > sys/kern/subr_disk.c: > >>> > o Update last_offset in bioq_insert_tail(). > >>> > > >>> > o Only update last_offset in bioq_remove() if the removed > >>> bio is > >>> > at the head of the queue (typically due to a call via > >>> > bioq_takefirst()) and no barrier is active. > >>> > > >>> > o In bioq_disksort(), if we have a barrier (insert_point is > >>> non-NULL), > >>> > set prev to the barrier and cur to it's next element. > >>> Now that > >>> > last_offset is kept at the barrier position, this change > >>> isn't > >>> > strictly necessary, but since we have to take a decision > >>> branch > >>> > anyway, it does avoid one, no-op, loop iteration in the > >>> while > >>> > loop that immediately follows. > >>> > > >>> > o In bioq_disksort(), bypass the normal sort for bios with > >>> the > >>> > BIO_ORDERED attribute and instead insert them into the > >>> queue > >>> > with bioq_insert_tail(). bioq_insert_tail() not only gi= ves > >>> > the desired command order during insertion, but also > >>> provides > >>> > barrier semantics so that commands disksorted in the fut= ure > >>> > cannot pass the just enqueued transaction. > >>> > > >>> > sys/sys/bio.h: > >>> > Add BIO_ORDERED as bit 4 of the bio_flags field in struct > >>> bio. > >>> > > >>> > sys/cam/ata/ata_da.c: > >>> > sys/cam/scsi/scsi_da.c > >>> > Use an ordered command for SCSI/ATA-NCQ commands issued in > >>> > response to bios with the BIO_ORDERED flag set. > >>> > > >>> > sys/cam/scsi/scsi_da.c > >>> > Use an ordered tag when issuing a synchronize cache comman= d. > >>> > > >>> > Wrap some lines to 80 columns. > >>> > > >>> > sys/cddl/contrib/opensolaris/uts/common/fs/zfs/vdev_geom.c > >>> > sys/geom/geom_io.c > >>> > Mark bios with the BIO_FLUSH command as BIO_ORDERED. > >>> > > >>> > Sponsored by: Spectra Logic Corporation > >>> > > >>> ---------------------------------------------------------------------= =2D-- > >>> > > >>> > Can you try perhaps commenting out the 'bp->bio_flags |=3D > >>> BIO_ORDERED' line > >>> > changed in geom_io.c in 8.2? That would be effectively reverting t= his > >>> > portion of the diff: > >>> > > >>> > Index: geom_io.c > >>> > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > >>> > --- geom_io.c (.../8.1/sys/geom) (revision 237134) > >>> > +++ geom_io.c (.../8.2/sys/geom) (revision 237134) > >>> > @@ -265,6 +265,7 @@ > >>> > g_trace(G_T_BIO, "bio_flush(%s)", cp->provider->name); > >>> > bp =3D g_alloc_bio(); > >>> > bp->bio_cmd =3D BIO_FLUSH; > >>> > + bp->bio_flags |=3D BIO_ORDERED; > >>> > bp->bio_done =3D NULL; > >>> > bp->bio_attribute =3D NULL; > >>> > bp->bio_offset =3D cp->provider->mediasize; > >>> > > >>> > >>> John... thanks for the suggestion. I've built and tested a kernel wi= th > >>> this change made. Result: no change (same performance as with > >>> 8.2-GENERIC). Any thoughts as to where to go next? > >> > >> Hmm. That seemed the most plausible candidate when I looked at this. > >> > >> Do you use quotas (there is one change in UFS related to quotas)? > >> > >> There are 5 changes that involve sys/kern/vfs_bio.c in 8.2: > >> 209459, 212229, 212562, 212583, and 213890. > >> > >> Can you possibly test out kernels from stable/8 at those revisions on = an > >> 8.1 > >> world and see if you can narrow it down futher? > >> > >> Barring that, can you do a binary search of kernels from stable/8 > >> between 8.1 > >> and 8.2 on an 8.1 world to see which commit caused the change in write > >> performance? > >> > > > > Hi John, I'm working with Charles to narrow this down. > > > > Looks like revision 212229 is the culprit, or at least around the same > > time to it, if this change isn't what slowed things down. The change to > > sys/kern/vfs_bio.c modifies some synchronization in dev_strategy(): > > >=20 > Actually, hold that thought. I had a hunch that I wasn't thorough=20 > enough, so I decided to try 212228 =E2=80=94 the performance is the same = as with=20 > 212229, so vfs_bio seems to be out of the picture. I'm going to binary=20 > search between 209459 and 212229, and see what I find. Ok. Please let me know what you find. Thanks! =2D-=20 John Baldwin From owner-freebsd-stable@FreeBSD.ORG Fri Jul 13 16:42:06 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2EB491065673 for ; Fri, 13 Jul 2012 16:42:06 +0000 (UTC) (envelope-from seanbru@yahoo-inc.com) Received: from mrout1-b.corp.bf1.yahoo.com (mrout1-b.corp.bf1.yahoo.com [98.139.253.104]) by mx1.freebsd.org (Postfix) with ESMTP id EB8AE8FC1C for ; Fri, 13 Jul 2012 16:42:05 +0000 (UTC) Received: from [IPv6:::1] (rideseveral.corp.yahoo.com [10.73.160.231]) by mrout1-b.corp.bf1.yahoo.com (8.14.4/8.14.4/y.out) with ESMTP id q6DGVMuh040290 for ; Fri, 13 Jul 2012 09:31:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=yahoo-inc.com; s=cobra; t=1342197083; bh=G4+nIYQ6eAQXw6z6wOd/H6FpXJVALP527mqdJmdXL40=; h=Subject:From:Reply-To:To:Content-Type:Date:Message-ID: Mime-Version:Content-Transfer-Encoding; b=FoC5MXmLI/Bw7tp7CchIDmvnXcqyy9nhXnbjMy2Spb/OSHDsK+2pcNQ0IKjmSaSZU kdynheyIjfTuY30BI2yonAAvaNzRNoAmRWmetipxxXZwv8VtH+rwMHr6L2aAi++eiC iNa76XUHYJODIx740AMbXV738L1zNupT/R9nTzd0= From: Sean Bruno To: "freebsd-stable@freebsd.org" Content-Type: text/plain; charset="UTF-8" Date: Fri, 13 Jul 2012 09:31:22 -0700 Message-ID: <1342197082.2664.4.camel@powernoodle.corp.yahoo.com> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit X-Milter-Version: master.31+4-gbc07cd5+ X-CLX-ID: 197082004 Subject: stable/9 panic Bad tailq NEXT(0xffffffff80e52660->tqh_last) != NULL X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: sbruno@freebsd.org List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jul 2012 16:42:06 -0000 Well this is new. I haven't a clue what Dell has done on this R620, but this popped up today after I did a boat load of BIOS updates and tried to install stable/9 from our yahoo tree. If anyone sees the obvious solution here, I'd love to figure it out. found-> vendor=0x14e4, dev=0x165f, revid=0x00 domain=0, bus=2, slot=0, func=1 class=02-00-00, hdrtype=0x00, mfdev=1 cmdreg=0x0006, statreg=0x0010, cachelnsz=16 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=b, irq=6 powerspec 3 supports D0 D3 current D0 MSI supports 8 messages, 64 bit MSI-X supports 17 messages in map 0x20 map[10]: type Prefetchable Memory, range 64, base 0xd50d0000, size 16, enabled pcib1: allocated prefetch range (0xd50d0000-0xd50dffff) for rid 10 of pci0:2:0:1 map[18]: type Prefetchable Memory, range 64, base 0xd50e0000, size 16, enabled pcib1: allocated prefetch range (0xd50e0000-0xd50effff) for rid 18 of pci0:2:0:1 map[20]: type Prefetchable Memory, range 64, base 0xd50f0000, size 16, enabled pcib1: allocated prefetch range (0xd50f0000-0xd50fffff) for rid 20 of pci0:2:0:1 pcib1: matched entry for 2.0.INTB pcib1: slot 0 INTB hardwired to IRQ 36 bge0: mem 0xd50a0000-0xd50affff,0xd50b0000-0xd50bffff,0xd50c0000-0xd50cffff irq 34 at device 0.0 on pci2 bge0: APE FW version: NCSI v1.0.80.0 bge0: attempting to allocate 1 MSI vectors (8 supported) msi: routing MSI IRQ 264 to local APIC 0 vector 59 bge0: using IRQ 264 for MSI bge0: CHIP ID 0x05720000; ASIC REV 0x5720; CHIP REV 0x57200; PCI-E bge0: Disabling fastboot bge0: Disabling fastboot miibus0: on bge0 brgphy0: PHY 1 on miibus0 brgphy0: OUI 0x001be9, model 0x0036, rev. 0 brgphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-master, 1000baseT-FDX, 1000baseT-FDX-master, auto, auto-flow bge0: bpf attached bge0: Ethernet address: 18:03:73:fd:9e:36 bge1: mem 0xd50d0000-0xd50dffff,0xd50e0000-0xd50effff,0xd50f0000-0xd50fffff irq 36 at device 0.1 on pci2 bge1: APE FW version: NCSI v1.0.80.0 bge1: attempting to allocate 1 MSI vectors (8 supported) msi: routing MSI IRQ 265 to local APIC 0 vector 60 bge1: using IRQ 265 for MSI bge1: CHIP ID 0x05720000; ASIC REV 0x5720; CHIP REV 0x57200; PCI-E bge1: Disabling fastboot bge1: Disabling fastboot miibus1: on bge1 brgphy1: PHY 2 on miibus1 brgphy1: OUI 0x001be9, model 0x0036, rev. 0 brgphy1: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-master, 1000baseT-FDX, 1000baseT-FDX-master, auto, auto-flow bge1: bpf attached bge1: Ethernet address: 18:03:73:fd:9e:37 pcib2: irq 53 at device 1.1 on pci0 pcib0: allocated type 3 (0xd8800000-0xd8ffffff) for rid 20 of pcib2 pcib0: allocated type 3 (0xd5100000-0xd51fffff) for rid 24 of pcib2 pcib2: domain 0 pcib2: secondary bus 1 pcib2: subordinate bus 1 pcib2: memory decode 0xd8800000-0xd8ffffff pcib2: prefetched decode 0xd5100000-0xd51fffff pci1: on pcib2 pci1: domain=0, physical bus=1 found-> vendor=0x14e4, dev=0x165f, revid=0x00 domain=0, bus=1, slot=0, func=0 class=02-00-00, hdrtype=0x00, mfdev=1 cmdreg=0x0006, statreg=0x0010, cachelnsz=16 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=15 powerspec 3 supports D0 D3 current D0 MSI supports 8 messages, 64 bit MSI-X supports 17 messages in map 0x20 map[10]: type Prefetchable Memory, range 64, base 0xd51a0000, size 16, enabled pcib2: allocated prefetch range (0xd51a0000-0xd51affff) for rid 10 of pci0:1:0:0 map[18]: type Prefetchable Memory, range 64, base 0xd51b0000, size 16, enabled pcib2: allocated prefetch range (0xd51b0000-0xd51bffff) for rid 18 of pci0:1:0:0 map[20]: type Prefetchable Memory, range 64, base 0xd51c0000, size 16, enabled pcib2: allocated prefetch range (0xd51c0000-0xd51cffff) for rid 20 of pci0:1:0:0 pcib2: matched entry for 1.0.INTA pcib2: slot 0 INTA hardwired to IRQ 35 found-> vendor=0x14e4, dev=0x165f, revid=0x00 domain=0, bus=1, slot=0, func=1 class=02-00-00, hdrtype=0x00, mfdev=1 cmdreg=0x0006, statreg=0x0010, cachelnsz=16 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=b, irq=6 powerspec 3 supports D0 D3 current D0 MSI supports 8 messages, 64 bit MSI-X supports 17 messages in map 0x20 map[10]: type Prefetchable Memory, range 64, base 0xd51d0000, size 16, enabled pcib2: allocated prefetch range (0xd51d0000-0xd51dffff) for rid 10 of pci0:1:0:1 map[18]: type Prefetchable Memory, range 64, base 0xd51e0000, size 16, enabled pcib2: allocated prefetch range (0xd51e0000-0xd51effff) for rid 18 of pci0:1:0:1 map[20]: type Prefetchable Memory, range 64, base 0xd51f0000, size 16, enabled pcib2: allocated prefetch range (0xd51f0000-0xd51fffff) for rid 20 of pci0:1:0:1 pcib2: matched entry for 1.0.INTB pcib2: slot 0 INTB hardwired to IRQ 38 bge2: mem 0xd51a0000-0xd51affff,0xd51b0000-0xd51bffff,0xd51c0000-0xd51cffff irq 35 at device 0.0 on pci1 bge2: APE FW version: NCSI v1.0.80.0 bge2: attempting to allocate 1 MSI vectors (8 supported) msi: routing MSI IRQ 266 to local APIC 0 vector 61 bge2: using IRQ 266 for MSI bge2: CHIP ID 0x05720000; ASIC REV 0x5720; CHIP REV 0x57200; PCI-E bge2: Disabling fastboot bge2: Disabling fastboot miibus2: on bge2 brgphy2: PHY 1 on miibus2 brgphy2: OUI 0x001be9, model 0x0036, rev. 0 brgphy2: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-master, 1000baseT-FDX, 1000baseT-FDX-master, auto, auto-flow bge2: bpf attached bge2: Ethernet address: 18:03:73:fd:9e:34 bge3: mem 0xd51d0000-0xd51dffff,0xd51e0000-0xd51effff,0xd51f0000-0xd51fffff irq 38 at device 0.1 on pci1 bge3: APE FW version: NCSI v1.0.80.0 bge3: attempting to allocate 1 MSI vectors (8 supported) msi: routing MSI IRQ 267 to local APIC 0 vector 62 bge3: using IRQ 267 for MSI bge3: CHIP ID 0x05720000; ASIC REV 0x5720; CHIP REV 0x57200; PCI-E bge3: Disabling fastboot bge3: Disabling fastboot miibus3: on bge3 brgphy3: PHY 2 on miibus3 brgphy3: OUI 0x001be9, model 0x0036, rev. 0 brgphy3: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-master, 1000baseT-FDX, 1000baseT-FDX-master, auto, auto-flow bge3: bpf attached bge3: Ethernet address: 18:03:73:fd:9e:35 pcib3: irq 53 at device 2.0 on pci0 pcib3: domain 0 pcib3: secondary bus 4 pcib3: subordinate bus 4 pcib3: no prefetched decode pci4: on pcib3 pci4: domain=0, physical bus=4 pcib4: irq 53 at device 2.2 on pci0 pcib0: allocated type 4 (0xf000-0xffff) for rid 1c of pcib4 pcib0: allocated type 3 (0xd9000000-0xd9ffffff) for rid 20 of pcib4 pcib4: domain 0 pcib4: secondary bus 3 pcib4: subordinate bus 3 pcib4: I/O decode 0xf000-0xffff pcib4: memory decode 0xd9000000-0xd9ffffff pcib4: no prefetched decode pci3: on pcib4 pci3: domain=0, physical bus=3 found-> vendor=0x1000, dev=0x005b, revid=0x01 domain=0, bus=3, slot=0, func=0 class=01-04-00, hdrtype=0x00, mfdev=0 cmdreg=0x0007, statreg=0x0010, cachelnsz=16 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=15 powerspec 3 supports D0 D1 D2 D3 current D0 MSI supports 1 message, 64 bit MSI-X supports 16 messages in map 0x14 map[10]: type I/O Port, range 32, base 0xfc00, size 8, enabled pcib4: allocated I/O port range (0xfc00-0xfcff) for rid 10 of pci0:3:0:0 map[14]: type Memory, range 64, base 0xd9ffc000, size 14, enabled pcib4: allocated memory range (0xd9ffc000-0xd9ffffff) for rid 14 of pci0:3:0:0 map[1c]: type Memory, range 64, base 0xd9f80000, size 18, enabled pcib4: allocated memory range (0xd9f80000-0xd9fbffff) for rid 1c of pci0:3:0:0 pcib4: matched entry for 3.0.INTA pcib4: slot 0 INTA hardwired to IRQ 42 mfi0: port 0xfc00-0xfcff mem 0xd9ffc000-0xd9ffffff,0xd9f80000-0xd9fbffff irq 42 at device 0.0 on pci3 mfi0: attempting to allocate 1 MSI vectors (1 supported) msi: routing MSI IRQ 268 to local APIC 0 vector 63 mfi0: using IRQ 268 for MSI mfi0: Using MSI mfi0: Megaraid SAS driver Ver 4.23 mfi0: MaxCmd = 3f0 MaxSgl = 46 state = b73c03f0 mfi0: Max fw cmds= 1008, sizing driver pool to 128 mfip0: on mfi0 pcib5: irq 53 at device 3.0 on pci0 pcib0: allocated type 4 (0xe000-0xefff) for rid 1c of pcib5 pcib0: allocated type 3 (0xda000000-0xdaffffff) for rid 20 of pcib5 pcib5: domain 0 pcib5: secondary bus 5 pcib5: subordinate bus 5 pcib5: I/O decode 0xe000-0xefff pcib5: memory decode 0xda000000-0xdaffffff pcib5: no prefetched decode pci5: on pcib5 pci5: domain=0, physical bus=5 found-> vendor=0x8086, dev=0x105e, revid=0x06 domain=0, bus=5, slot=0, func=0 class=02-00-00, hdrtype=0x00, mfdev=1 cmdreg=0x0007, statreg=0x0010, cachelnsz=16 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=15 powerspec 2 supports D0 D3 current D0 MSI supports 1 message, 64 bit map[10]: type Memory, range 32, base 0xdaf80000, size 17, enabled pcib5: allocated memory range (0xdaf80000-0xdaf9ffff) for rid 10 of pci0:5:0:0 map[14]: type Memory, range 32, base 0xdafa0000, size 17, enabled pcib5: allocated memory range (0xdafa0000-0xdafbffff) for rid 14 of pci0:5:0:0 map[18]: type I/O Port, range 32, base 0xecc0, size 5, enabled pcib5: allocated I/O port range (0xecc0-0xecdf) for rid 18 of pci0:5:0:0 pcib5: matched entry for 5.0.INTA pcib5: slot 0 INTA hardwired to IRQ 48 found-> vendor=0x8086, dev=0x105e, revid=0x06 domain=0, bus=5, slot=0, func=1 class=02-00-00, hdrtype=0x00, mfdev=1 cmdreg=0x0007, statreg=0x0010, cachelnsz=16 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=b, irq=6 powerspec 2 supports D0 D3 current D0 MSI supports 1 message, 64 bit map[10]: type Memory, range 32, base 0xdafc0000, size 17, enabled pcib5: allocated memory range (0xdafc0000-0xdafdffff) for rid 10 of pci0:5:0:1 map[14]: type Memory, range 32, base 0xdafe0000, size 17, enabled pcib5: allocated memory range (0xdafe0000-0xdaffffff) for rid 14 of pci0:5:0:1 map[18]: type I/O Port, range 32, base 0xece0, size 5, enabled pcib5: allocated I/O port range (0xece0-0xecff) for rid 18 of pci0:5:0:1 pcib5: matched entry for 5.0.INTB pcib5: slot 0 INTB hardwired to IRQ 52 em0: port 0xecc0-0xecdf mem 0xdaf80000-0xdaf9ffff,0xdafa0000-0xdafbffff irq 48 at device 0.0 on pci5 em0: attempting to allocate 1 MSI vectors (1 supported) msi: routing MSI IRQ 269 to local APIC 0 vector 64 em0: using IRQ 269 for MSI em0: Using an MSI interrupt em0: bpf attached em0: Ethernet address: 00:15:17:78:89:dc em1: port 0xece0-0xecff mem 0xdafc0000-0xdafdffff,0xdafe0000-0xdaffffff irq 52 at device 0.1 on pci5 em1: attempting to allocate 1 MSI vectors (1 supported) msi: routing MSI IRQ 270 to local APIC 0 vector 65 em1: using IRQ 270 for MSI em1: Using an MSI interrupt em1: bpf attached em1: Ethernet address: 00:15:17:78:89:dd pci0: at device 4.0 (no driver attached) pci0: at device 4.1 (no driver attached) pci0: at device 4.2 (no driver attached) pci0: at device 4.3 (no driver attached) pci0: at device 4.4 (no driver attached) pci0: at device 4.5 (no driver attached) pci0: at device 4.6 (no driver attached) pci0: at device 4.7 (no driver attached) pci0: at device 5.0 (no driver attached) pci0: at device 5.2 (no driver attached) pcib6: irq 16 at device 17.0 on pci0 pcib6: domain 0 pcib6: secondary bus 6 pcib6: subordinate bus 6 pcib6: no prefetched decode pci6: on pcib6 pci6: domain=0, physical bus=6 pci0: at device 22.0 (no driver attached) pci0: at device 22.1 (no driver attached) ehci0: mem 0xdc8fd000-0xdc8fd3ff irq 23 at device 26.0 on pci0 ioapic0: routing intpin 23 (PCI IRQ 23) to lapic 0 vector 66 usbus0: EHCI version 1.0 usbus0 on ehci0 pcib7: at device 28.0 on pci0 pcib7: domain 0 pcib7: secondary bus 7 pcib7: subordinate bus 7 pcib7: no prefetched decode device_attach: pcib7 attach returned 6 pcib7: irq 19 at device 28.7 on pci0 panic: Bad tailq NEXT(0xffffffff80e52660->tqh_last) != NULL cpuid = 0 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2a kdb_backtrace() at kdb_backtrace+0x37 panic() at panic+0x1d8 rman_init() at rman_init+0x17c pcib_alloc_window() at pcib_alloc_window+0x9f pcib_attach_common() at pcib_attach_common+0x457 acpi_pcib_pci_attach() at acpi_pcib_pci_attach+0x1c device_attach() at device_attach+0x72 bus_generic_attach() at bus_generic_attach+0x1a acpi_pci_attach() at acpi_pci_attach+0x164 device_attach() at device_attach+0x72 bus_generic_attach() at bus_generic_attach+0x1a acpi_pcib_attach() at acpi_pcib_attach+0x1a7 acpi_pcib_acpi_attach() at acpi_pcib_acpi_attach+0x1f6 device_attach() at device_attach+0x72 bus_generic_attach() at bus_generic_attach+0x1a acpi_attach() at acpi_attach+0xbc1 device_attach() at device_attach+0x72 bus_generic_attach() at bus_generic_attach+0x1a nexus_acpi_attach() at nexus_acpi_attach+0x69 device_attach() at device_attach+0x72 bus_generic_new_pass() at bus_generic_new_pass+0xd6 bus_set_pass() at bus_set_pass+0x7a configure() at configure+0xa mi_startup() at mi_startup+0x77 btext() at btext+0x2c Uptime: 1s Automatic reboot in 15 seconds - press a key on the console to abort --> Press a key on the console to reboot, --> or switch off the system now. From owner-freebsd-stable@FreeBSD.ORG Fri Jul 13 16:51:50 2012 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 37AEE106564A; Fri, 13 Jul 2012 16:51:50 +0000 (UTC) (envelope-from seanbru@yahoo-inc.com) Received: from mrout1-b.corp.bf1.yahoo.com (mrout1-b.corp.bf1.yahoo.com [98.139.253.104]) by mx1.freebsd.org (Postfix) with ESMTP id DA51A8FC14; Fri, 13 Jul 2012 16:51:49 +0000 (UTC) Received: from [IPv6:::1] (rideseveral.corp.yahoo.com [10.73.160.231]) by mrout1-b.corp.bf1.yahoo.com (8.14.4/8.14.4/y.out) with ESMTP id q6DGoK8M046695; Fri, 13 Jul 2012 09:50:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=yahoo-inc.com; s=cobra; t=1342198222; bh=SAA63lnYMtyuZn44uNFl2kTAQRvsY4/pTPsfHYIXslw=; h=Subject:From:To:Cc:In-Reply-To:References:Content-Type:Date: Message-ID:Mime-Version:Content-Transfer-Encoding; b=SEMeuSKT3EqKYZ4FrCZ4xTH4xSiQSfDCBVsN+5gWQgLxMZFh/sVtWRR6Pzcjps8rk usnV5ava3nu24ni6wTm4gz7BMH7SprtyQ8VjWVjoUxunGglbJEBieWxld9/ChgKwwG +r0a1KgQ3aYG3ME2MvATfpuW9FSFdSvNVtNyxp9U= From: Sean Bruno To: "pyunyh@gmail.com" In-Reply-To: <1342119989.2524.5.camel@powernoodle.corp.yahoo.com> References: <20120703185704.GA81296@fupp.net> <20120705010136.GA3218@michelle.cdnetworks.com> <1341855261.6064.5.camel@powernoodle.corp.yahoo.com> <20120712215912.GA1456@michelle.cdnetworks.com> <1342119989.2524.5.camel@powernoodle.corp.yahoo.com> Content-Type: text/plain; charset="UTF-8" Date: Fri, 13 Jul 2012 09:50:20 -0700 Message-ID: <1342198220.2664.5.camel@powernoodle.corp.yahoo.com> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit X-Milter-Version: master.31+4-gbc07cd5+ X-CLX-ID: 198221003 Cc: "stable@freebsd.org" , Anders Nordby Subject: Re: bge problems in RELENG_9, bge0: watchdog timeout -- resetting X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 13 Jul 2012 16:51:50 -0000 On Thu, 2012-07-12 at 12:06 -0700, Sean Bruno wrote: > On Thu, 2012-07-12 at 14:59 -0700, YongHyeon PYUN wrote: > > > I grabbed these updates and applied them cleanly to stable/9 on a > > Dell > > > R620 with a quad port BCM5720, I still see watchdog timeouts and > > reset > > > indications. I am able to ping out of the box for a short amount of > > > time before the device hangs and times out. > > > > > > > Sean, sorry for late reply. > > Given that I have no problems on sample 5720 controller I still > > have no clue yet. > > > > No problems ... :-) > > > > > > > > > > -bash-4.2# ping XXX.XXX.XXX.1 > > > PING XXX.XXX.XXX.1 (XXX.XXX.XXX.XXX): 56 data bytes > > > ping: sendto: Network is down > > > ping: sendto: Network is down > > > ping: sendto: Network is down > > > ping: sendto: Network is down > > > ping: sendto: Network is down > > > Jul 9 17:31:41 x89 kernel: bge2: watchdog timeout -- > > > resetting > > > Jul 9 17:31:41 x89 kernel: bge2: link state changed > > to > > > DOWN > > > Jul 9 17:31:41 x89 kernel: bge2: link state changed > > to > > > > Two link state change message indicates there is an issue in state > > tracking. I'm experimenting a different approach but it seems it > > takes too long due to lack of time. Any way, I've uploaded updated > > bge(4)(URL is the same as before). > > I see a bunch of firmware updates for this host along with an update to > the BCM firmware package for this Dell box. > > I'll update my system's driver first, validate pass/fail, if fail, then > I'll update the firmware bits and validate some more. > > sean > No real change. I suspect something else is going on here that I don't understand. I note that when the system malfunctions now, the system cannot boot and requires me to enter the bios to check my settings. Sean From owner-freebsd-stable@FreeBSD.ORG Fri Jul 13 17:10:30 2012 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id B49C3106564A; Fri, 13 Jul 2012 17:10:30 +0000 (UTC) (envelope-from prvs=15415f271b=killing@multiplay.co.uk) Received: from mail1.multiplay.co.uk (mail1.multiplay.co.uk [85.236.96.23]) by mx1.freebsd.org (Postfix) with ESMTP id 104408FC28; Fri, 13 Jul 2012 17:10:29 +0000 (UTC) X-Spam-Processed: mail1.multiplay.co.uk, Fri, 13 Jul 2012 18:10:23 +0100 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on mail1.multiplay.co.uk X-Spam-Level: X-Spam-Status: No, score=-5.0 required=6.0 tests=USER_IN_WHITELIST shortcircuit=ham autolearn=disabled version=3.2.5 Received: from r2d2 ([188.220.16.49]) by mail1.multiplay.co.uk (mail1.multiplay.co.uk [85.236.96.23]) (MDaemon PRO v10.0.4) with ESMTP id md50020756595.msg; Fri, 13 Jul 2012 18:10:21 +0100 X-MDRemoteIP: 188.220.16.49 X-Return-Path: prvs=15415f271b=killing@multiplay.co.uk X-Envelope-From: killing@multiplay.co.uk Message-ID: <87E165352F634CDEACFE51EA0268F3A0@multiplay.co.uk> From: "Steven Hartland" To: "Sean Bruno" , References: <20120703185704.GA81296@fupp.net><20120705010136.GA3218@michelle.cdnetworks.com><1341855261.6064.5.camel@powernoodle.corp.yahoo.com><20120712215912.GA1456@michelle.cdnetworks.com><1342119989.2524.5.camel@powernoodle.corp.yahoo.com> <1342198220.2664.5.camel@powernoodle.corp.yahoo.com> Date: Fri, 13 Jul 2012 18:10:23 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 Cc: stable@freebsd.org, Anders Nordby Subject: Re: bge problems in RELENG_9, bge0: watchdog timeout -- resetting X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 13 Jul 2012 17:10:30 -0000 ----- Original Message ----- From: "Sean Bruno" > No real change. I suspect something else is going on here that I don't > understand. I note that when the system malfunctions now, the system > cannot boot and requires me to enter the bios to check my settings. We've had a machine which was having watchdog timeouts on a bge which turned out to be a hardware failure. Not exactly sure exactly what but disabling cores of the second CPU solved the problem. Regards Steve ================================================ This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. In the event of misdirection, illegible or incomplete transmission please telephone +44 845 868 1337 or return the E.mail to postmaster@multiplay.co.uk. From owner-freebsd-stable@FreeBSD.ORG Sat Jul 14 13:28:43 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 7287C106566B for ; Sat, 14 Jul 2012 13:28:43 +0000 (UTC) (envelope-from marek_sal@wp.pl) Received: from mx4.wp.pl (mx4.wp.pl [212.77.101.8]) by mx1.freebsd.org (Postfix) with ESMTP id EEA5F8FC08 for ; Sat, 14 Jul 2012 13:28:42 +0000 (UTC) Received: (wp-smtpd smtp.wp.pl 3158 invoked from network); 14 Jul 2012 15:28:36 +0200 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=wp.pl; s=1024a; t=1342272516; bh=D/IOHJKLvd0AMYmwzadYKiwFptuk/3mfmZkEEBnKuEk=; h=From:To:Subject; b=qMcDFRrAFOL7MBVhp6TAukiEV9dSKanB6MmDye828u7ebYxUJoCFdLlqTsEHzhLsl NUKy8g6ocnE0DBc0X/lw0UZl2hO9DXV+84T4O+Un6KzXItmSMD6V4c1durVo1TI9r/ ZqBv8RliWnMGC1aysAjWAD883ORlaZVTk72JxICw= Received: from nat.misal.pl (HELO [127.0.0.1]) (marek_sal@[83.19.131.171]) (envelope-sender ) by smtp.wp.pl (WP-SMTPD) with AES256-SHA encrypted SMTP for ; 14 Jul 2012 15:28:36 +0200 Message-ID: <50017400.3030702@wp.pl> Date: Sat, 14 Jul 2012 15:28:32 +0200 From: Marek Salwerowicz User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 MIME-Version: 1.0 To: freebsd-stable@freebsd.org Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 120714-1, 2012-07-14), Outbound message X-Antivirus-Status: Clean X-WP-AV: skaner antywirusowy poczty Wirtualnej Polski S. A. X-WP-SPAM: NO 0000000 [4ZP0] Subject: video issue - Intel Atom based motherboard D2500HN X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 14 Jul 2012 13:28:43 -0000 Hi all, I recently bought a Intel D2500HN motherboard with Intel GMA 3600 video card. I want to install FreeBSD 9-Release on it via PXE, but after booting the system, it seems that video card driver doesn't work properly. Have a look at this picture: http://img703.imageshack.us/img703/5648/20120714393.jpg I've tried the # vidcontrol 80x25 but unfortunately it doesn't help. Do you have any idea how to deal with taht graphics? Regards, -- Marek From owner-freebsd-stable@FreeBSD.ORG Sat Jul 14 13:36:21 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B16091065670 for ; Sat, 14 Jul 2012 13:36:21 +0000 (UTC) (envelope-from alonsoschaich@fastmail.fm) Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) by mx1.freebsd.org (Postfix) with ESMTP id 72CBA8FC08 for ; Sat, 14 Jul 2012 13:36:21 +0000 (UTC) Received: from compute1.internal (compute1.nyi.mail.srv.osa [10.202.2.41]) by gateway1.nyi.mail.srv.osa (Postfix) with ESMTP id D317D207AD for ; Sat, 14 Jul 2012 09:36:20 -0400 (EDT) Received: from frontend2.nyi.mail.srv.osa ([10.202.2.161]) by compute1.internal (MEProxy); Sat, 14 Jul 2012 09:36:20 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=fastmail.fm; h= from:to:subject:date:references:in-reply-to:mime-version :content-type:content-transfer-encoding:message-id; s=mesmtp; bh=rrjRnsnfHBKVeRniV7ML5OXy25I=; b=ODgYgzbdyuUxgRF84sv8eiRv5oLl iI0GaBoSLUEj0ei00JK97Anbk/dONwUe8jDqXEMFbw0dcj9CbionEP85UJj51ahh tpZc6WX/pHzI4iqqWXrKri5pJZjThZDIE3RBJ+vdYs219kr3ZKo+ayx7k+XoOotz /MPZWuTCqL9RR5I= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=from:to:subject:date:references :in-reply-to:mime-version:content-type:content-transfer-encoding :message-id; s=smtpout; bh=rrjRnsnfHBKVeRniV7ML5OXy25I=; b=Au3cC zt7gSAz4GGDsHxTxepVRs9Tb+GSyeCK+W7FGruIlI9QnkYwWlbIUX0I3KIzR0fFX rDgVP/xnLBlekC9My6MktadXmO9MG0J8MFQTdce93mcs+JnqgeDIiPzJoU7zglzo BHRI4l/xfPh1Nq1H+M63YYDnsn04Ueyju5NKhc= X-Sasl-enc: jhkmep3kHHDdLsbMZQcb3ckpzWBU0xU7eGozry7TmmN3 1342272980 Received: from harmony.localnet.edu (unknown [141.87.213.55]) by mail.messagingengine.com (Postfix) with ESMTPA id 60AD34837F2 for ; Sat, 14 Jul 2012 09:36:20 -0400 (EDT) From: Schaich Alonso To: freebsd-stable@freebsd.org Date: Sat, 14 Jul 2012 13:36:05 +0000 User-Agent: KMail/1.13.7 (FreeBSD/9.0-STABLE; KDE/4.8.4; amd64; ; ) References: <50017400.3030702@wp.pl> In-Reply-To: <50017400.3030702@wp.pl> MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <201207141336.05406.alonsoschaich@fastmail.fm> Subject: Re: video issue - Intel Atom based motherboard D2500HN X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 14 Jul 2012 13:36:21 -0000 On 2012-07-14 (Saturday) 13:28:32 Marek Salwerowicz wrote: > Hi all, > > I recently bought a Intel D2500HN motherboard with Intel GMA 3600 video > card. > I want to install FreeBSD 9-Release on it via PXE, but after booting the > system, it seems that video card driver doesn't work properly. > > Have a look at this picture: > http://img703.imageshack.us/img703/5648/20120714393.jpg > > I've tried the > # vidcontrol 80x25 > > but unfortunately it doesn't help. > > Do you have any idea how to deal with taht graphics? > > Regards, That is probably a broken BIOS, firmware or hardware. Can you try booting a different operating system? (USB rescue discs or so) Alonso From owner-freebsd-stable@FreeBSD.ORG Sat Jul 14 15:08:29 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5EEE01065697 for ; Sat, 14 Jul 2012 15:08:29 +0000 (UTC) (envelope-from marek_sal@wp.pl) Received: from mx3.wp.pl (mx3.wp.pl [212.77.101.7]) by mx1.freebsd.org (Postfix) with ESMTP id 676668FC1A for ; Sat, 14 Jul 2012 15:08:28 +0000 (UTC) Received: (wp-smtpd smtp.wp.pl 5856 invoked from network); 14 Jul 2012 17:08:20 +0200 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=wp.pl; s=1024a; t=1342278507; bh=DpI4i6La+Px5GZPJUUR49DT8TzsNM+XiFS7Sj+2//IE=; h=From:To:CC:Subject; b=JdpLxzyF60FK/KRY8Eua92+uprTgQE5fNepeH25ZwNIJiChsvYjG9TmbubCZ6S0Sq wqvsuXyBxVRS+b0ungctBT9MdYYabfOcxfvDa9N0fiaNo8Z/bzxhaeVHzsQZrr+ebn 1n+pwglrknc8KCZaER0vnmyJtiG1F3e9pPMz3FL8= Received: from nat.misal.pl (HELO [127.0.0.1]) (marek_sal@[83.19.131.171]) (envelope-sender ) by smtp.wp.pl (WP-SMTPD) with AES256-SHA encrypted SMTP for ; 14 Jul 2012 17:08:20 +0200 Message-ID: <50018B54.7060006@wp.pl> Date: Sat, 14 Jul 2012 17:08:04 +0200 From: Marek Salwerowicz User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 MIME-Version: 1.0 To: Schaich Alonso References: <50017400.3030702@wp.pl> <201207141336.05406.alonsoschaich@fastmail.fm> In-Reply-To: <201207141336.05406.alonsoschaich@fastmail.fm> Content-Type: multipart/mixed; boundary="------------040808090609000001010409" X-Antivirus: avast! (VPS 120714-1, 2012-07-14), Outbound message X-Antivirus-Status: Clean X-WP-AV: skaner antywirusowy poczty Wirtualnej Polski S. A. X-WP-SPAM: NO 0000000 [UeNk] Cc: freebsd-stable@freebsd.org Subject: Re: video issue - Intel Atom based motherboard D2500HN X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 14 Jul 2012 15:08:29 -0000 This is a multi-part message in MIME format. --------------040808090609000001010409 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit W dniu 2012-07-14 15:36, Schaich Alonso pisze: > That is probably a broken BIOS, firmware or hardware. Can you try booting a > different operating system? (USB rescue discs or so) Yes, I've successfully booted System Rescue CD (based on Gentoo Linux) 2.3.1 Uname, dmesg and lspci are attached. Right now I am trying to install Debian i386 into USB stick (the installer works fine) Regards, -- Marek --------------040808090609000001010409 Content-Type: text/plain; charset=windows-1250; name="dmesg.txt" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="dmesg.txt" WyAgICAwLjAwMDAwMF0gSW5pdGlhbGl6aW5nIGNncm91cCBzdWJzeXMgY3B1c2V0ClsgICAg MC4wMDAwMDBdIEluaXRpYWxpemluZyBjZ3JvdXAgc3Vic3lzIGNwdQpbICAgIDAuMDAwMDAw XSBMaW51eCB2ZXJzaW9uIDIuNi4zOC1zdGQyMzEtaTU4NiAocm9vdEBjYXRhbHlzdCkgKGdj YyB2ZXJzaW9uIDQuNC41IChHZW50b28gNC40LjUgcDEuMiwgcGllLTAuNC41KSApICMyIFNN UCBUdWUgQXVnIDIzIDE3OjQ2OjU5IFVUQyAyMDExClsgICAgMC4wMDAwMDBdIEJJT1MtcHJv dmlkZWQgcGh5c2ljYWwgUkFNIG1hcDoKWyAgICAwLjAwMDAwMF0gIEJJT1MtZTgyMDogMDAw MDAwMDAwMDAwMDAwMCAtIDAwMDAwMDAwMDAwOGYwMDAgKHVzYWJsZSkKWyAgICAwLjAwMDAw MF0gIEJJT1MtZTgyMDogMDAwMDAwMDAwMDA4ZjAwMCAtIDAwMDAwMDAwMDAwOTAwMDAgKHJl c2VydmVkKQpbICAgIDAuMDAwMDAwXSAgQklPUy1lODIwOiAwMDAwMDAwMDAwMDkwMDAwIC0g MDAwMDAwMDAwMDA5ZTgwMCAodXNhYmxlKQpbICAgIDAuMDAwMDAwXSAgQklPUy1lODIwOiAw MDAwMDAwMDAwMDllODAwIC0gMDAwMDAwMDAwMDBhMDAwMCAocmVzZXJ2ZWQpClsgICAgMC4w MDAwMDBdICBCSU9TLWU4MjA6IDAwMDAwMDAwMDAwZTAwMDAgLSAwMDAwMDAwMDAwMTAwMDAw IChyZXNlcnZlZCkKWyAgICAwLjAwMDAwMF0gIEJJT1MtZTgyMDogMDAwMDAwMDAwMDEwMDAw MCAtIDAwMDAwMDAwY2VlOTgwMDAgKHVzYWJsZSkKWyAgICAwLjAwMDAwMF0gIEJJT1MtZTgy MDogMDAwMDAwMDBjZWU5ODAwMCAtIDAwMDAwMDAwY2VlYmYwMDAgKHJlc2VydmVkKQpbICAg IDAuMDAwMDAwXSAgQklPUy1lODIwOiAwMDAwMDAwMGNlZWJmMDAwIC0gMDAwMDAwMDBjZWYw ZjAwMCAodXNhYmxlKQpbICAgIDAuMDAwMDAwXSAgQklPUy1lODIwOiAwMDAwMDAwMGNlZjBm MDAwIC0gMDAwMDAwMDBjZWZiZjAwMCAoQUNQSSBOVlMpClsgICAgMC4wMDAwMDBdICBCSU9T LWU4MjA6IDAwMDAwMDAwY2VmYmYwMDAgLSAwMDAwMDAwMGNlZmYyMDAwICh1c2FibGUpClsg ICAgMC4wMDAwMDBdICBCSU9TLWU4MjA6IDAwMDAwMDAwY2VmZjIwMDAgLSAwMDAwMDAwMGNl ZmZmMDAwIChBQ1BJIGRhdGEpClsgICAgMC4wMDAwMDBdICBCSU9TLWU4MjA6IDAwMDAwMDAw Y2VmZmYwMDAgLSAwMDAwMDAwMGNmMDAwMDAwICh1c2FibGUpClsgICAgMC4wMDAwMDBdICBC SU9TLWU4MjA6IDAwMDAwMDAwY2YwMDAwMDAgLSAwMDAwMDAwMGQwMDAwMDAwIChyZXNlcnZl ZCkKWyAgICAwLjAwMDAwMF0gIEJJT1MtZTgyMDogMDAwMDAwMDBlMDAwMDAwMCAtIDAwMDAw MDAwZTQwMDAwMDAgKHJlc2VydmVkKQpbICAgIDAuMDAwMDAwXSAgQklPUy1lODIwOiAwMDAw MDAwMGZmZTAwMDAwIC0gMDAwMDAwMDEwMDAwMDAwMCAocmVzZXJ2ZWQpClsgICAgMC4wMDAw MDBdICBCSU9TLWU4MjA6IDAwMDAwMDAxMDAwMDAwMDAgLSAwMDAwMDAwMTMwMDAwMDAwICh1 c2FibGUpClsgICAgMC4wMDAwMDBdIE5vdGljZTogTlggKEV4ZWN1dGUgRGlzYWJsZSkgcHJv dGVjdGlvbiBjYW5ub3QgYmUgZW5hYmxlZDogbm9uLVBBRSBrZXJuZWwhClsgICAgMC4wMDAw MDBdIERNSSAyLjcgcHJlc2VudC4KWyAgICAwLjAwMDAwMF0gRE1JOiAgICAgICAgICAgICAg ICAgIC9EMjUwMEhOLCBCSU9TIE1VQ0RUMTBOLjg2QS4wMDcxLjIwMTIuMDYxMi4xNDU5IDA2 LzEyLzIwMTIKWyAgICAwLjAwMDAwMF0gZTgyMCB1cGRhdGUgcmFuZ2U6IDAwMDAwMDAwMDAw MDAwMDAgLSAwMDAwMDAwMDAwMDEwMDAwICh1c2FibGUpID09PiAocmVzZXJ2ZWQpClsgICAg MC4wMDAwMDBdIGU4MjAgcmVtb3ZlIHJhbmdlOiAwMDAwMDAwMDAwMGEwMDAwIC0gMDAwMDAw MDAwMDEwMDAwMCAodXNhYmxlKQpbICAgIDAuMDAwMDAwXSBsYXN0X3BmbiA9IDB4Y2YwMDAg bWF4X2FyY2hfcGZuID0gMHgxMDAwMDAKWyAgICAwLjAwMDAwMF0gTVRSUiBkZWZhdWx0IHR5 cGU6IHVuY2FjaGFibGUKWyAgICAwLjAwMDAwMF0gTVRSUiBmaXhlZCByYW5nZXMgZW5hYmxl ZDoKWyAgICAwLjAwMDAwMF0gICAwMDAwMC05RkZGRiB3cml0ZS1iYWNrClsgICAgMC4wMDAw MDBdICAgQTAwMDAtQkZGRkYgdW5jYWNoYWJsZQpbICAgIDAuMDAwMDAwXSAgIEMwMDAwLURG RkZGIHdyaXRlLXByb3RlY3QKWyAgICAwLjAwMDAwMF0gICBFMDAwMC1GRkZGRiB1bmNhY2hh YmxlClsgICAgMC4wMDAwMDBdIE1UUlIgdmFyaWFibGUgcmFuZ2VzIGVuYWJsZWQ6ClsgICAg MC4wMDAwMDBdICAgMCBiYXNlIDAwMDAwMDAwMCBtYXNrIEY4MDAwMDAwMCB3cml0ZS1iYWNr ClsgICAgMC4wMDAwMDBdICAgMSBiYXNlIDA4MDAwMDAwMCBtYXNrIEZDMDAwMDAwMCB3cml0 ZS1iYWNrClsgICAgMC4wMDAwMDBdICAgMiBiYXNlIDBDMDAwMDAwMCBtYXNrIEZGMDAwMDAw MCB3cml0ZS1iYWNrClsgICAgMC4wMDAwMDBdICAgMyBiYXNlIDBDRjAwMDAwMCBtYXNrIEZG RjAwMDAwMCB1bmNhY2hhYmxlClsgICAgMC4wMDAwMDBdICAgNCBiYXNlIDEwMDAwMDAwMCBt YXNrIEZDMDAwMDAwMCB3cml0ZS1iYWNrClsgICAgMC4wMDAwMDBdICAgNSBiYXNlIDBGRkUw MDAwMCBtYXNrIEZGRkUwMDAwMCB3cml0ZS1wcm90ZWN0ClsgICAgMC4wMDAwMDBdICAgNiBk aXNhYmxlZApbICAgIDAuMDAwMDAwXSB4ODYgUEFUIGVuYWJsZWQ6IGNwdSAwLCBvbGQgMHg3 MDQwNjAwMDcwNDA2LCBuZXcgMHg3MDEwNjAwMDcwMTA2ClsgICAgMC4wMDAwMDBdIGZvdW5k IFNNUCBNUC10YWJsZSBhdCBbYzAwZmJlMzBdIGZiZTMwClsgICAgMC4wMDAwMDBdIGluaXRp YWwgbWVtb3J5IG1hcHBlZCA6IDAgLSAwMTgwMDAwMApbICAgIDAuMDAwMDAwXSBpbml0X21l bW9yeV9tYXBwaW5nOiAwMDAwMDAwMDAwMDAwMDAwLTAwMDAwMDAwMzZmZmUwMDAKWyAgICAw LjAwMDAwMF0gIDAwMDAwMDAwMDAgLSAwMDAwNDAwMDAwIHBhZ2UgNGsKWyAgICAwLjAwMDAw MF0gIDAwMDA0MDAwMDAgLSAwMDM2YzAwMDAwIHBhZ2UgMk0KWyAgICAwLjAwMDAwMF0gIDAw MzZjMDAwMDAgLSAwMDM2ZmZlMDAwIHBhZ2UgNGsKWyAgICAwLjAwMDAwMF0ga2VybmVsIGRp cmVjdCBtYXBwaW5nIHRhYmxlcyB1cCB0byAzNmZmZTAwMCBAIDE3ZjkwMDAtMTgwMDAwMApb ICAgIDAuMDAwMDAwXSBSQU1ESVNLOiA3ZjdhODAwMCAtIDdmZmZmMDAwClsgICAgMC4wMDAw MDBdIEFsbG9jYXRlZCBuZXcgUkFNRElTSzogMzY3YTcwMDAgLSAzNmZmZDhjOApbICAgIDAu MDAwMDAwXSBNb3ZlIFJBTURJU0sgZnJvbSAwMDAwMDAwMDdmN2E4MDAwIC0gMDAwMDAwMDA3 ZmZmZThjNyB0byAzNjdhNzAwMCAtIDM2ZmZkOGM3ClsgICAgMC4wMDAwMDBdIEFDUEk6IFJT RFAgMDAwZjIzOTAgMDAwMjQgKHYwMiBJTlRFTCApClsgICAgMC4wMDAwMDBdIEFDUEk6IFhT RFQgY2VmZmUxMjAgMDAwNEMgKHYwMSBJTlRFTCAgVElBTk8gICAgMDAwMDAwNDcgICAgICAw MTAwMDAxMykKWyAgICAwLjAwMDAwMF0gQUNQSTogRkFDUCBjZWZmNjAwMCAwMDBGNCAodjAz IElOVEVMICBUSUFOTyAgICAwMDAwMDA0NyBNU0ZUIDAxMDAwMDBEKQpbICAgIDAuMDAwMDAw XSBBQ1BJOiBEU0RUIGNlZmY4MDAwIDA1QjM4ICh2MDIgSU5URUwgIFRJQU5PICAgIDAwMDAw MDQ3IE1TRlQgMDEwMDAwMEQpClsgICAgMC4wMDAwMDBdIEFDUEk6IEZBQ1MgY2VmOTUwMDAg MDAwNDAKWyAgICAwLjAwMDAwMF0gQUNQSTogU1NEVCBjZWZmNzAwMCAwMDQzRSAodjAxIElO VEVMICBUSUFOTyAgICAwMDAwMDA0NyBNU0ZUIDAxMDAwMDBEKQpbICAgIDAuMDAwMDAwXSBB Q1BJOiBBUElDIGNlZmY1MDAwIDAwMDg0ICh2MDIgSU5URUwgIFRJQU5PICAgIDAwMDAwMDQ3 IE1TRlQgMDEwMDAwMEQpClsgICAgMC4wMDAwMDBdIEFDUEk6IE1DRkcgY2VmZjQwMDAgMDAw M0MgKHYwMSBJTlRFTCAgVElBTk8gICAgMDAwMDAwNDcgTVNGVCAwMTAwMDAwRCkKWyAgICAw LjAwMDAwMF0gQUNQSTogSFBFVCBjZWZmMzAwMCAwMDAzOCAodjAxIElOVEVMICBUSUFOTyAg ICAwMDAwMDA0NyBNU0ZUIDAxMDAwMDBEKQpbICAgIDAuMDAwMDAwXSBBQ1BJOiBMb2NhbCBB UElDIGFkZHJlc3MgMHhmZWUwMDAwMApbICAgIDAuMDAwMDAwXSAyNDMyTUIgSElHSE1FTSBh dmFpbGFibGUuClsgICAgMC4wMDAwMDBdIDg3OU1CIExPV01FTSBhdmFpbGFibGUuClsgICAg MC4wMDAwMDBdICAgbWFwcGVkIGxvdyByYW06IDAgLSAzNmZmZTAwMApbICAgIDAuMDAwMDAw XSAgIGxvdyByYW06IDAgLSAzNmZmZTAwMApbICAgIDAuMDAwMDAwXSBab25lIFBGTiByYW5n ZXM6ClsgICAgMC4wMDAwMDBdICAgRE1BICAgICAgMHgwMDAwMDAxMCAtPiAweDAwMDAxMDAw ClsgICAgMC4wMDAwMDBdICAgTm9ybWFsICAgMHgwMDAwMTAwMCAtPiAweDAwMDM2ZmZlClsg ICAgMC4wMDAwMDBdICAgSGlnaE1lbSAgMHgwMDAzNmZmZSAtPiAweDAwMGNmMDAwClsgICAg MC4wMDAwMDBdIE1vdmFibGUgem9uZSBzdGFydCBQRk4gZm9yIGVhY2ggbm9kZQpbICAgIDAu MDAwMDAwXSBlYXJseV9ub2RlX21hcFs2XSBhY3RpdmUgUEZOIHJhbmdlcwpbICAgIDAuMDAw MDAwXSAgICAgMDogMHgwMDAwMDAxMCAtPiAweDAwMDAwMDhmClsgICAgMC4wMDAwMDBdICAg ICAwOiAweDAwMDAwMDkwIC0+IDB4MDAwMDAwOWUKWyAgICAwLjAwMDAwMF0gICAgIDA6IDB4 MDAwMDAxMDAgLT4gMHgwMDBjZWU5OApbICAgIDAuMDAwMDAwXSAgICAgMDogMHgwMDBjZWVi ZiAtPiAweDAwMGNlZjBmClsgICAgMC4wMDAwMDBdICAgICAwOiAweDAwMGNlZmJmIC0+IDB4 MDAwY2VmZjIKWyAgICAwLjAwMDAwMF0gICAgIDA6IDB4MDAwY2VmZmYgLT4gMHgwMDBjZjAw MApbICAgIDAuMDAwMDAwXSBPbiBub2RlIDAgdG90YWxwYWdlczogODQ3NTI5ClsgICAgMC4w MDAwMDBdIGZyZWVfYXJlYV9pbml0X25vZGU6IG5vZGUgMCwgcGdkYXQgYzBjOGUyODAsIG5v ZGVfbWVtX21hcCBmNGRjNjIwMApbICAgIDAuMDAwMDAwXSAgIERNQSB6b25lOiAzMiBwYWdl cyB1c2VkIGZvciBtZW1tYXAKWyAgICAwLjAwMDAwMF0gICBETUEgem9uZTogMCBwYWdlcyBy ZXNlcnZlZApbICAgIDAuMDAwMDAwXSAgIERNQSB6b25lOiAzOTQ5IHBhZ2VzLCBMSUZPIGJh dGNoOjAKWyAgICAwLjAwMDAwMF0gICBOb3JtYWwgem9uZTogMTcyOCBwYWdlcyB1c2VkIGZv ciBtZW1tYXAKWyAgICAwLjAwMDAwMF0gICBOb3JtYWwgem9uZTogMjE5NDU0IHBhZ2VzLCBM SUZPIGJhdGNoOjMxClsgICAgMC4wMDAwMDBdICAgSGlnaE1lbSB6b25lOiA0ODY1IHBhZ2Vz IHVzZWQgZm9yIG1lbW1hcApbICAgIDAuMDAwMDAwXSAgIEhpZ2hNZW0gem9uZTogNjE3NTAx IHBhZ2VzLCBMSUZPIGJhdGNoOjMxClsgICAgMC4wMDAwMDBdIFVzaW5nIEFQSUMgZHJpdmVy IGRlZmF1bHQKWyAgICAwLjAwMDAwMF0gQUNQSTogUE0tVGltZXIgSU8gUG9ydDogMHg0MDgK WyAgICAwLjAwMDAwMF0gQUNQSTogTG9jYWwgQVBJQyBhZGRyZXNzIDB4ZmVlMDAwMDAKWyAg ICAwLjAwMDAwMF0gQUNQSTogTEFQSUMgKGFjcGlfaWRbMHgwMV0gbGFwaWNfaWRbMHgwMF0g ZW5hYmxlZCkKWyAgICAwLjAwMDAwMF0gQUNQSTogTEFQSUMgKGFjcGlfaWRbMHgwMl0gbGFw aWNfaWRbMHgwMV0gZW5hYmxlZCkKWyAgICAwLjAwMDAwMF0gQUNQSTogTEFQSUMgKGFjcGlf aWRbMHgwM10gbGFwaWNfaWRbMHgwMl0gZGlzYWJsZWQpClsgICAgMC4wMDAwMDBdIEFDUEk6 IExBUElDIChhY3BpX2lkWzB4MDRdIGxhcGljX2lkWzB4MDNdIGRpc2FibGVkKQpbICAgIDAu MDAwMDAwXSBBQ1BJOiBMQVBJQ19OTUkgKGFjcGlfaWRbMHgwMV0gaGlnaCBsZXZlbCBsaW50 WzB4MV0pClsgICAgMC4wMDAwMDBdIEFDUEk6IExBUElDX05NSSAoYWNwaV9pZFsweDAyXSBo aWdoIGxldmVsIGxpbnRbMHgxXSkKWyAgICAwLjAwMDAwMF0gQUNQSTogTEFQSUNfTk1JIChh Y3BpX2lkWzB4MDNdIGhpZ2ggbGV2ZWwgbGludFsweDFdKQpbICAgIDAuMDAwMDAwXSBBQ1BJ OiBMQVBJQ19OTUkgKGFjcGlfaWRbMHgwNF0gaGlnaCBsZXZlbCBsaW50WzB4MV0pClsgICAg MC4wMDAwMDBdIEFDUEk6IElPQVBJQyAoaWRbMHgwOF0gYWRkcmVzc1sweGZlYzAwMDAwXSBn c2lfYmFzZVswXSkKWyAgICAwLjAwMDAwMF0gSU9BUElDWzBdOiBhcGljX2lkIDgsIHZlcnNp b24gMzIsIGFkZHJlc3MgMHhmZWMwMDAwMCwgR1NJIDAtMjMKWyAgICAwLjAwMDAwMF0gQUNQ STogSU5UX1NSQ19PVlIgKGJ1cyAwIGJ1c19pcnEgMCBnbG9iYWxfaXJxIDIgZGZsIGRmbCkK WyAgICAwLjAwMDAwMF0gQUNQSTogSU5UX1NSQ19PVlIgKGJ1cyAwIGJ1c19pcnEgOSBnbG9i YWxfaXJxIDkgaGlnaCBsZXZlbCkKWyAgICAwLjAwMDAwMF0gQUNQSTogSVJRMCB1c2VkIGJ5 IG92ZXJyaWRlLgpbICAgIDAuMDAwMDAwXSBBQ1BJOiBJUlEyIHVzZWQgYnkgb3ZlcnJpZGUu ClsgICAgMC4wMDAwMDBdIEFDUEk6IElSUTkgdXNlZCBieSBvdmVycmlkZS4KWyAgICAwLjAw MDAwMF0gVXNpbmcgQUNQSSAoTUFEVCkgZm9yIFNNUCBjb25maWd1cmF0aW9uIGluZm9ybWF0 aW9uClsgICAgMC4wMDAwMDBdIEFDUEk6IEhQRVQgaWQ6IDB4ODA4NmEyMDEgYmFzZTogMHhm ZWQwMDAwMApbICAgIDAuMDAwMDAwXSBTTVA6IEFsbG93aW5nIDQgQ1BVcywgMiBob3RwbHVn IENQVXMKWyAgICAwLjAwMDAwMF0gbnJfaXJxc19nc2k6IDQwClsgICAgMC4wMDAwMDBdIFBN OiBSZWdpc3RlcmVkIG5vc2F2ZSBtZW1vcnk6IDAwMDAwMDAwMDAwOGYwMDAgLSAwMDAwMDAw MDAwMDkwMDAwClsgICAgMC4wMDAwMDBdIFBNOiBSZWdpc3RlcmVkIG5vc2F2ZSBtZW1vcnk6 IDAwMDAwMDAwMDAwOWUwMDAgLSAwMDAwMDAwMDAwMDlmMDAwClsgICAgMC4wMDAwMDBdIFBN OiBSZWdpc3RlcmVkIG5vc2F2ZSBtZW1vcnk6IDAwMDAwMDAwMDAwOWYwMDAgLSAwMDAwMDAw MDAwMGEwMDAwClsgICAgMC4wMDAwMDBdIFBNOiBSZWdpc3RlcmVkIG5vc2F2ZSBtZW1vcnk6 IDAwMDAwMDAwMDAwYTAwMDAgLSAwMDAwMDAwMDAwMGUwMDAwClsgICAgMC4wMDAwMDBdIFBN OiBSZWdpc3RlcmVkIG5vc2F2ZSBtZW1vcnk6IDAwMDAwMDAwMDAwZTAwMDAgLSAwMDAwMDAw MDAwMTAwMDAwClsgICAgMC4wMDAwMDBdIEFsbG9jYXRpbmcgUENJIHJlc291cmNlcyBzdGFy dGluZyBhdCBlNDAwMDAwMCAoZ2FwOiBlNDAwMDAwMDoxYmUwMDAwMCkKWyAgICAwLjAwMDAw MF0gQm9vdGluZyBwYXJhdmlydHVhbGl6ZWQga2VybmVsIG9uIGJhcmUgaGFyZHdhcmUKWyAg ICAwLjAwMDAwMF0gc2V0dXBfcGVyY3B1OiBOUl9DUFVTOjY0IG5yX2NwdW1hc2tfYml0czo2 NCBucl9jcHVfaWRzOjQgbnJfbm9kZV9pZHM6MQpbICAgIDAuMDAwMDAwXSBQRVJDUFU6IEVt YmVkZGVkIDEyIHBhZ2VzL2NwdSBAZjQ4MDAwMDAgczI4MTYwIHIwIGQyMDk5MiB1MTA0ODU3 NgpbICAgIDAuMDAwMDAwXSBwY3B1LWFsbG9jOiBzMjgxNjAgcjAgZDIwOTkyIHUxMDQ4NTc2 IGFsbG9jPTEqNDE5NDMwNApbICAgIDAuMDAwMDAwXSBwY3B1LWFsbG9jOiBbMF0gMCAxIDIg MyAKWyAgICAwLjAwMDAwMF0gQnVpbHQgMSB6b25lbGlzdHMgaW4gWm9uZSBvcmRlciwgbW9i aWxpdHkgZ3JvdXBpbmcgb24uICBUb3RhbCBwYWdlczogODQwOTA0ClsgICAgMC4wMDAwMDBd IEtlcm5lbCBjb21tYW5kIGxpbmU6IHNjYW5kZWxheT0xIGluaXRyZD1pbml0cmFtLmlneiBC T09UX0lNQUdFPXJlc2N1ZWNkIApbICAgIDAuMDAwMDAwXSBQSUQgaGFzaCB0YWJsZSBlbnRy aWVzOiA0MDk2IChvcmRlcjogMiwgMTYzODQgYnl0ZXMpClsgICAgMC4wMDAwMDBdIERlbnRy eSBjYWNoZSBoYXNoIHRhYmxlIGVudHJpZXM6IDEzMTA3MiAob3JkZXI6IDcsIDUyNDI4OCBi eXRlcykKWyAgICAwLjAwMDAwMF0gSW5vZGUtY2FjaGUgaGFzaCB0YWJsZSBlbnRyaWVzOiA2 NTUzNiAob3JkZXI6IDYsIDI2MjE0NCBieXRlcykKWyAgICAwLjAwMDAwMF0gSW5pdGlhbGl6 aW5nIENQVSMwClsgICAgMC4wMDAwMDBdIGFsbG9jYXRlZCAxNjk1NzEyMCBieXRlcyBvZiBw YWdlX2Nncm91cApbICAgIDAuMDAwMDAwXSBwbGVhc2UgdHJ5ICdjZ3JvdXBfZGlzYWJsZT1t ZW1vcnknIG9wdGlvbiBpZiB5b3UgZG9uJ3Qgd2FudCBtZW1vcnkgY2dyb3VwcwpbICAgIDAu MDAwMDAwXSBJbml0aWFsaXppbmcgSGlnaE1lbSBmb3Igbm9kZSAwICgwMDAzNmZmZTowMDBj ZjAwMCkKWyAgICAwLjAwMDAwMF0gTWVtb3J5OiAzMzIxNzQ4ay8zMzkxNDg4ayBhdmFpbGFi bGUgKDU3MjBrIGtlcm5lbCBjb2RlLCA2ODM2OGsgcmVzZXJ2ZWQsIDMwOTlrIGRhdGEsIDYx MDBrIGluaXQsIDI0ODk0NjRrIGhpZ2htZW0pClsgICAgMC4wMDAwMDBdIHZpcnR1YWwga2Vy bmVsIG1lbW9yeSBsYXlvdXQ6ClsgICAgMC4wMDAwMDBdICAgICBmaXhtYXAgIDogMHhmZjU3 NDAwMCAtIDB4ZmZmZmYwMDAgICAoMTA3OTYga0IpClsgICAgMC4wMDAwMDBdICAgICBwa21h cCAgIDogMHhmZjAwMDAwMCAtIDB4ZmY0MDAwMDAgICAoNDA5NiBrQikKWyAgICAwLjAwMDAw MF0gICAgIHZtYWxsb2MgOiAweGY3N2ZlMDAwIC0gMHhmZWZmZTAwMCAgICggMTIwIE1CKQpb ICAgIDAuMDAwMDAwXSAgICAgbG93bWVtICA6IDB4YzAwMDAwMDAgLSAweGY2ZmZlMDAwICAg KCA4NzkgTUIpClsgICAgMC4wMDAwMDBdICAgICAgIC5pbml0IDogMHhjMGM5ZTAwMCAtIDB4 YzEyOTMwMDAgICAoNjEwMCBrQikKWyAgICAwLjAwMDAwMF0gICAgICAgLmRhdGEgOiAweGMw OTk2MzI5IC0gMHhjMGM5ZDE0MCAgICgzMDk5IGtCKQpbICAgIDAuMDAwMDAwXSAgICAgICAu dGV4dCA6IDB4YzA0MDAwMDAgLSAweGMwOTk2MzI5ICAgKDU3MjAga0IpClsgICAgMC4wMDAw MDBdIENoZWNraW5nIGlmIHRoaXMgcHJvY2Vzc29yIGhvbm91cnMgdGhlIFdQIGJpdCBldmVu IGluIHN1cGVydmlzb3IgbW9kZS4uLk9rLgpbICAgIDAuMDAwMDAwXSBTTFVCOiBHZW5zbGFi cz0xNSwgSFdhbGlnbj02NCwgT3JkZXI9MC0zLCBNaW5PYmplY3RzPTAsIENQVXM9NCwgTm9k ZXM9MQpbICAgIDAuMDAwMDAwXSBIaWVyYXJjaGljYWwgUkNVIGltcGxlbWVudGF0aW9uLgpb ICAgIDAuMDAwMDAwXSAJUkNVIGR5bnRpY2staWRsZSBncmFjZS1wZXJpb2QgYWNjZWxlcmF0 aW9uIGlzIGVuYWJsZWQuClsgICAgMC4wMDAwMDBdIAlSQ1UtYmFzZWQgZGV0ZWN0aW9uIG9m IHN0YWxsZWQgQ1BVcyBpcyBkaXNhYmxlZC4KWyAgICAwLjAwMDAwMF0gTlJfSVJRUzoyMzA0 ClsgICAgMC4wMDAwMDBdIENQVSAwIGlycXN0YWNrcywgaGFyZD1mMzAyMDAwMCBzb2Z0PWYz MDIyMDAwClsgICAgMC4wMDAwMDBdIEV4dGVuZGVkIENNT1MgeWVhcjogMjAwMApbICAgIDAu MDAwMDAwXSBDb25zb2xlOiBjb2xvdXIgVkdBKyA4MHgyNQpbICAgIDAuMDAwMDAwXSBjb25z b2xlIFt0dHkwXSBlbmFibGVkClsgICAgMC4wMDAwMDBdIGhwZXQgY2xvY2tldmVudCByZWdp c3RlcmVkClsgICAgMC4wMDAwMDBdIEZhc3QgVFNDIGNhbGlicmF0aW9uIHVzaW5nIFBJVApb ICAgIDAuMDAxMDAwXSBEZXRlY3RlZCAxODY2Ljk5OSBNSHogcHJvY2Vzc29yLgpbICAgIDAu MDAwMDA1XSBDYWxpYnJhdGluZyBkZWxheSBsb29wIChza2lwcGVkKSwgdmFsdWUgY2FsY3Vs YXRlZCB1c2luZyB0aW1lciBmcmVxdWVuY3kuLiAzNzMzLjk5IEJvZ29NSVBTIChscGo9MTg2 Njk5OSkKWyAgICAwLjAwMDIxM10gcGlkX21heDogZGVmYXVsdDogMzI3NjggbWluaW11bTog MzAxClsgICAgMC4wMDA1NDFdIFNlY3VyaXR5IEZyYW1ld29yayBpbml0aWFsaXplZApbICAg IDAuMDAwNjQyXSBTRUxpbnV4OiAgRGlzYWJsZWQgYXQgYm9vdC4KWyAgICAwLjAwMDg1Nl0g TW91bnQtY2FjaGUgaGFzaCB0YWJsZSBlbnRyaWVzOiA1MTIKWyAgICAwLjAwMTg1MF0gSW5p dGlhbGl6aW5nIGNncm91cCBzdWJzeXMgbnMKWyAgICAwLjAwMTk1MF0gbnNfY2dyb3VwIGRl cHJlY2F0ZWQ6IGNvbnNpZGVyIHVzaW5nIHRoZSAnY2xvbmVfY2hpbGRyZW4nIGZsYWcgd2l0 aG91dCB0aGUgbnNfY2dyb3VwLgpbICAgIDAuMDAyMTI4XSBJbml0aWFsaXppbmcgY2dyb3Vw IHN1YnN5cyBjcHVhY2N0ClsgICAgMC4wMDIzMDRdIEluaXRpYWxpemluZyBjZ3JvdXAgc3Vi c3lzIG1lbW9yeQpbICAgIDAuMDAyNDM1XSBJbml0aWFsaXppbmcgY2dyb3VwIHN1YnN5cyBk ZXZpY2VzClsgICAgMC4wMDI1MzBdIEluaXRpYWxpemluZyBjZ3JvdXAgc3Vic3lzIGZyZWV6 ZXIKWyAgICAwLjAwMjYyNV0gSW5pdGlhbGl6aW5nIGNncm91cCBzdWJzeXMgbmV0X2Nscwpb ICAgIDAuMDAyNzE4XSBJbml0aWFsaXppbmcgY2dyb3VwIHN1YnN5cyBibGtpbwpbICAgIDAu MDAyOTA5XSBDUFU6IFBoeXNpY2FsIFByb2Nlc3NvciBJRDogMApbICAgIDAuMDAzMDAzXSBD UFU6IFByb2Nlc3NvciBDb3JlIElEOiAwClsgICAgMC4wMDMxMTNdIG1jZTogQ1BVIHN1cHBv cnRzIDUgTUNFIGJhbmtzClsgICAgMC4wMDMyMThdIENQVTA6IFRoZXJtYWwgbW9uaXRvcmlu ZyBlbmFibGVkIChUTTEpClsgICAgMC4wMDMzMTZdIHVzaW5nIG13YWl0IGluIGlkbGUgdGhy ZWFkcy4KWyAgICAwLjAwNTEyNV0gQUNQSTogQ29yZSByZXZpc2lvbiAyMDExMDExMgpbICAg IDAuMDEyMTk2XSBFbmFibGluZyBBUElDIG1vZGU6ICBGbGF0LiAgVXNpbmcgMSBJL08gQVBJ Q3MKWyAgICAwLjAxMjY1Ml0gLi5USU1FUjogdmVjdG9yPTB4MzAgYXBpYzE9MCBwaW4xPTIg YXBpYzI9LTEgcGluMj0tMQpbICAgIDAuMDIyNzQwXSBDUFUwOiBJbnRlbChSKSBBdG9tKFRN KSBDUFUgRDI1MDAgICBAIDEuODZHSHogc3RlcHBpbmcgMDEKWyAgICAwLjEyMzk4MV0gUGVy Zm9ybWFuY2UgRXZlbnRzOiBQRUJTIGZtdDArLCBnZW5lcmljIGFyY2hpdGVjdGVkIHBlcmZt b24sIEludGVsIFBNVSBkcml2ZXIuClsgICAgMC4xMjQyMTZdIC4uLiB2ZXJzaW9uOiAgICAg ICAgICAgICAgICAzClsgICAgMC4xMjQzMDZdIC4uLiBiaXQgd2lkdGg6ICAgICAgICAgICAg ICA0MApbICAgIDAuMTI0Mzk3XSAuLi4gZ2VuZXJpYyByZWdpc3RlcnM6ICAgICAgMgpbICAg IDAuMTI0NDg3XSAuLi4gdmFsdWUgbWFzazogICAgICAgICAgICAgMDAwMDAwZmZmZmZmZmZm ZgpbICAgIDAuMTI0NTc5XSAuLi4gbWF4IHBlcmlvZDogICAgICAgICAgICAgMDAwMDAwMDA3 ZmZmZmZmZgpbICAgIDAuMTI0NjcwXSAuLi4gZml4ZWQtcHVycG9zZSBldmVudHM6ICAgMwpb ICAgIDAuMTI0NzYwXSAuLi4gZXZlbnQgbWFzazogICAgICAgICAgICAgMDAwMDAwMDcwMDAw MDAwMwpbICAgIDAuMTI1NDc2XSBOTUkgd2F0Y2hkb2cgZW5hYmxlZCwgdGFrZXMgb25lIGh3 LXBtdSBjb3VudGVyLgpbICAgIDAuMTI1ODcxXSBDUFUgMSBpcnFzdGFja3MsIGhhcmQ9ZjMw ZjAwMDAgc29mdD1mMzBmMjAwMApbICAgIDAuMTI1ODgzXSBCb290aW5nIE5vZGUgICAwLCBQ cm9jZXNzb3JzICAjMQpbICAgIDAuMTM1OTY3XSBJbml0aWFsaXppbmcgQ1BVIzEKWyAgICAw LjIxNjAzNV0gTk1JIHdhdGNoZG9nIGVuYWJsZWQsIHRha2VzIG9uZSBody1wbXUgY291bnRl ci4KWyAgICAwLjIxNjM1Ml0gQnJvdWdodCB1cCAyIENQVXMKWyAgICAwLjIxNjQ0OF0gVG90 YWwgb2YgMiBwcm9jZXNzb3JzIGFjdGl2YXRlZCAoNzQ2Ny4yMiBCb2dvTUlQUykuClsgICAg MC4yMTY4NDNdIHNpemVvZih2bWEpPTg4IGJ5dGVzClsgICAgMC4yMTY4NDhdIHNpemVvZihw YWdlKT0zMiBieXRlcwpbICAgIDAuMjE2ODUxXSBzaXplb2YoaW5vZGUpPTM2MCBieXRlcwpb ICAgIDAuMjE2ODU0XSBzaXplb2YoZGVudHJ5KT0xMjggYnl0ZXMKWyAgICAwLjIxNjg1N10g c2l6ZW9mKGV4dDNpbm9kZSk9NTE2IGJ5dGVzClsgICAgMC4yMTY4NjBdIHNpemVvZihleHQ0 aW5vZGUpPTYwOCBieXRlcwpbICAgIDAuMjE2ODY0XSBzaXplb2YoYnVmZmVyX2hlYWQpPTU2 IGJ5dGVzClsgICAgMC4yMTY4NjddIHNpemVvZihza2J1ZmYpPTE5MiBieXRlcwpbICAgIDAu MjE2ODcwXSBzaXplb2YodGFza19zdHJ1Y3QpPTMyMTIgYnl0ZXMKWyAgICAwLjIxNzM2MF0g ZGV2dG1wZnM6IGluaXRpYWxpemVkClsgICAgMC4yMjA0NzhdIGF0b21pYzY0IHRlc3QgcGFz c2VkIGZvciBpMzg2KyBwbGF0Zm9ybSB3aXRoIENYOCBhbmQgd2l0aCBTU0UKWyAgICAwLjIy MDYyNV0gVGltZTogMTY6NTg6NTMgIERhdGU6IDA3LzE0LzEyClsgICAgMC4yMjA5MjVdIE5F VDogUmVnaXN0ZXJlZCBwcm90b2NvbCBmYW1pbHkgMTYKWyAgICAwLjIyMTQ0N10gQUNQSSBG QURUIGRlY2xhcmVzIHRoZSBzeXN0ZW0gZG9lc24ndCBzdXBwb3J0IFBDSWUgQVNQTSwgc28g ZGlzYWJsZSBpdApbICAgIDAuMjIxNjA4XSBBQ1BJOiBidXMgdHlwZSBwY2kgcmVnaXN0ZXJl ZApbICAgIDAuMjIyMDc0XSBQQ0k6IE1NQ09ORklHIGZvciBkb21haW4gMDAwMCBbYnVzIDAw LTNmXSBhdCBbbWVtIDB4ZTAwMDAwMDAtMHhlM2ZmZmZmZl0gKGJhc2UgMHhlMDAwMDAwMCkK WyAgICAwLjIyMjIzOF0gUENJOiBNTUNPTkZJRyBhdCBbbWVtIDB4ZTAwMDAwMDAtMHhlM2Zm ZmZmZl0gcmVzZXJ2ZWQgaW4gRTgyMApbICAgIDAuMjIyMzM1XSBQQ0k6IFVzaW5nIE1NQ09O RklHIGZvciBleHRlbmRlZCBjb25maWcgc3BhY2UKWyAgICAwLjIyMjQyOV0gUENJOiBVc2lu ZyBjb25maWd1cmF0aW9uIHR5cGUgMSBmb3IgYmFzZSBhY2Nlc3MKWyAgICAwLjIyNjMxMF0g YmlvOiBjcmVhdGUgc2xhYiA8YmlvLTA+IGF0IDAKWyAgICAwLjIyODc1OF0gQUNQSTogRUM6 IExvb2sgdXAgRUMgaW4gRFNEVApbICAgIDAuMjMwODMyXSBBQ1BJOiBFeGVjdXRlZCAxIGJs b2NrcyBvZiBtb2R1bGUtbGV2ZWwgZXhlY3V0YWJsZSBBTUwgY29kZQpbICAgIDAuMjM5OTAz XSBbRmlybXdhcmUgQnVnXTogQUNQSTogQklPUyBfT1NJKExpbnV4KSBxdWVyeSBpZ25vcmVk ClsgICAgMC4yNDA2NDJdIEFDUEk6IEludGVycHJldGVyIGVuYWJsZWQKWyAgICAwLjI0MDc0 MV0gQUNQSTogKHN1cHBvcnRzIFMwIFMzIFM0IFM1KQpbICAgIDAuMjQwOTg3XSBBQ1BJOiBV c2luZyBJT0FQSUMgZm9yIGludGVycnVwdCByb3V0aW5nClsgICAgMC4yNTYxMDBdIEFDUEk6 IE5vIGRvY2sgZGV2aWNlcyBmb3VuZC4KWyAgICAwLjI1NjIwMF0gSEVTVDogVGFibGUgbm90 IGZvdW5kLgpbICAgIDAuMjU2Mjk3XSBQQ0k6IFVzaW5nIGhvc3QgYnJpZGdlIHdpbmRvd3Mg ZnJvbSBBQ1BJOyBpZiBuZWNlc3NhcnksIHVzZSAicGNpPW5vY3JzIiBhbmQgcmVwb3J0IGEg YnVnClsgICAgMC4yNTY5MzVdIFxfU0JfLlBDSTA6X09TQyBpbnZhbGlkIFVVSUQKWyAgICAw LjI1NjkzOV0gX09TQyByZXF1ZXN0IGRhdGE6MSA4IDFmIApbICAgIDAuMjU2OTQ5XSBBQ1BJ OiBQQ0kgUm9vdCBCcmlkZ2UgW1BDSTBdIChkb21haW4gMDAwMCBbYnVzIDAwLWZmXSkKWyAg ICAwLjI1NzY3NV0gcGNpX3Jvb3QgUE5QMEEwODowMDogaG9zdCBicmlkZ2Ugd2luZG93IFtp byAgMHgwMDAwLTB4MGNmN10KWyAgICAwLjI1Nzc3NV0gcGNpX3Jvb3QgUE5QMEEwODowMDog aG9zdCBicmlkZ2Ugd2luZG93IFtpbyAgMHgwZDAwLTB4ZmZmZl0KWyAgICAwLjI1Nzg4NV0g cGNpX3Jvb3QgUE5QMEEwODowMDogaG9zdCBicmlkZ2Ugd2luZG93IFttZW0gMHgwMDBhMDAw MC0weDAwMGJmZmZmXQpbICAgIDAuMjU4MDQyXSBwY2lfcm9vdCBQTlAwQTA4OjAwOiBob3N0 IGJyaWRnZSB3aW5kb3cgW21lbSAweDAwMGMwMDAwLTB4MDAwZGZmZmZdClsgICAgMC4yNTgy MDBdIHBjaV9yb290IFBOUDBBMDg6MDA6IGhvc3QgYnJpZGdlIHdpbmRvdyBbbWVtIDB4MDAw ZTAwMDAtMHgwMDBlZmZmZl0KWyAgICAwLjI2MDAzNF0gcGNpX3Jvb3QgUE5QMEEwODowMDog aG9zdCBicmlkZ2Ugd2luZG93IFttZW0gMHgwMDBmMDAwMC0weDAwMGZmZmZmXQpbICAgIDAu MjYwMTkzXSBwY2lfcm9vdCBQTlAwQTA4OjAwOiBob3N0IGJyaWRnZSB3aW5kb3cgW21lbSAw eGNmODAwMDAwLTB4Y2ZmZmZmZmZdClsgICAgMC4yNjAzNTJdIHBjaV9yb290IFBOUDBBMDg6 MDA6IGhvc3QgYnJpZGdlIHdpbmRvdyBbbWVtIDB4ZDAwMDAwMDAtMHhmZWJmZmZmZl0KWyAg ICAwLjI2MDUxMV0gcGNpX3Jvb3QgUE5QMEEwODowMDogaG9zdCBicmlkZ2Ugd2luZG93IFtt ZW0gMHhmZWQ0MDAwMC0weGZlZDQ0ZmZmXQpbICAgIDAuMjYwNjg5XSBwY2kgMDAwMDowMDow MC4wOiBbODA4NjowYmY1XSB0eXBlIDAgY2xhc3MgMHgwMDA2MDAKWyAgICAwLjI2MDc0OF0g cGNpIDAwMDA6MDA6MDIuMDogWzgwODY6MGJlMV0gdHlwZSAwIGNsYXNzIDB4MDAwMzAwClsg ICAgMC4yNjA3NjVdIHBjaSAwMDAwOjAwOjAyLjA6IHJlZyAxMDogW21lbSAweGQwMTAwMDAw LTB4ZDAxZmZmZmZdClsgICAgMC4yNjA3NzRdIHBjaSAwMDAwOjAwOjAyLjA6IHJlZyAxNDog W2lvICAweDIwZDAtMHgyMGQ3XQpbICAgIDAuMjYwODc1XSBwY2kgMDAwMDowMDoxYi4wOiBb ODA4NjoyN2Q4XSB0eXBlIDAgY2xhc3MgMHgwMDA0MDMKWyAgICAwLjI2MDg5OF0gcGNpIDAw MDA6MDA6MWIuMDogcmVnIDEwOiBbbWVtIDB4ZDAzMDAwMDAtMHhkMDMwM2ZmZiA2NGJpdF0K WyAgICAwLjI2MDk3Ml0gcGNpIDAwMDA6MDA6MWIuMDogUE1FIyBzdXBwb3J0ZWQgZnJvbSBE MCBEM2hvdCBEM2NvbGQKWyAgICAwLjI2MDk4MF0gcGNpIDAwMDA6MDA6MWIuMDogUE1FIyBk aXNhYmxlZApbICAgIDAuMjYxMDExXSBwY2kgMDAwMDowMDoxYy4wOiBbODA4NjoyN2QwXSB0 eXBlIDEgY2xhc3MgMHgwMDA2MDQKWyAgICAwLjI2MTA4OF0gcGNpIDAwMDA6MDA6MWMuMDog UE1FIyBzdXBwb3J0ZWQgZnJvbSBEMCBEM2hvdCBEM2NvbGQKWyAgICAwLjI2MTA5NV0gcGNp IDAwMDA6MDA6MWMuMDogUE1FIyBkaXNhYmxlZApbICAgIDAuMjYxMTM0XSBwY2kgMDAwMDow MDoxZC4wOiBbODA4NjoyN2M4XSB0eXBlIDAgY2xhc3MgMHgwMDBjMDMKWyAgICAwLjI2MTE5 OV0gcGNpIDAwMDA6MDA6MWQuMDogcmVnIDIwOiBbaW8gIDB4MjBhMC0weDIwYmZdClsgICAg MC4yNjEyNDhdIHBjaSAwMDAwOjAwOjFkLjE6IFs4MDg2OjI3YzldIHR5cGUgMCBjbGFzcyAw eDAwMGMwMwpbICAgIDAuMjYxMzE0XSBwY2kgMDAwMDowMDoxZC4xOiByZWcgMjA6IFtpbyAg MHgyMDgwLTB4MjA5Zl0KWyAgICAwLjI2MTM2NF0gcGNpIDAwMDA6MDA6MWQuMjogWzgwODY6 MjdjYV0gdHlwZSAwIGNsYXNzIDB4MDAwYzAzClsgICAgMC4yNjE0MjhdIHBjaSAwMDAwOjAw OjFkLjI6IHJlZyAyMDogW2lvICAweDIwNjAtMHgyMDdmXQpbICAgIDAuMjYxNDc4XSBwY2kg MDAwMDowMDoxZC4zOiBbODA4NjoyN2NiXSB0eXBlIDAgY2xhc3MgMHgwMDBjMDMKWyAgICAw LjI2MTU0Ml0gcGNpIDAwMDA6MDA6MWQuMzogcmVnIDIwOiBbaW8gIDB4MjA0MC0weDIwNWZd ClsgICAgMC4yNjE2MDFdIHBjaSAwMDAwOjAwOjFkLjc6IFs4MDg2OjI3Y2NdIHR5cGUgMCBj bGFzcyAweDAwMGMwMwpbICAgIDAuMjYxNjI5XSBwY2kgMDAwMDowMDoxZC43OiByZWcgMTA6 IFttZW0gMHhkMDIwNDQwMC0weGQwMjA0N2ZmXQpbICAgIDAuMjYxNzIxXSBwY2kgMDAwMDow MDoxZC43OiBQTUUjIHN1cHBvcnRlZCBmcm9tIEQwIEQzaG90IEQzY29sZApbICAgIDAuMjYx NzI4XSBwY2kgMDAwMDowMDoxZC43OiBQTUUjIGRpc2FibGVkClsgICAgMC4yNjE3NTZdIHBj aSAwMDAwOjAwOjFlLjA6IFs4MDg2OjI0NDhdIHR5cGUgMSBjbGFzcyAweDAwMDYwNApbICAg IDAuMjYxODQxXSBwY2kgMDAwMDowMDoxZi4wOiBbODA4NjoyN2JjXSB0eXBlIDAgY2xhc3Mg MHgwMDA2MDEKWyAgICAwLjI2MTkzOF0gcGNpIDAwMDA6MDA6MWYuMDogW0Zpcm13YXJlIEJ1 Z106IFRpZ2VyUG9pbnQgTFBDLkJNX1NUUyBjbGVhcmVkClsgICAgMC4yNjIwODFdIHBjaSAw MDAwOjAwOjFmLjI6IFs4MDg2OjI3YzFdIHR5cGUgMCBjbGFzcyAweDAwMDEwNgpbICAgIDAu MjYyMTA0XSBwY2kgMDAwMDowMDoxZi4yOiByZWcgMTA6IFtpbyAgMHgyMGM4LTB4MjBjZl0K WyAgICAwLjI2MjExOV0gcGNpIDAwMDA6MDA6MWYuMjogcmVnIDE0OiBbaW8gIDB4MjBkYy0w eDIwZGZdClsgICAgMC4yNjIxMzJdIHBjaSAwMDAwOjAwOjFmLjI6IHJlZyAxODogW2lvICAw eDIwYzAtMHgyMGM3XQpbICAgIDAuMjYyMTQ1XSBwY2kgMDAwMDowMDoxZi4yOiByZWcgMWM6 IFtpbyAgMHgyMGQ4LTB4MjBkYl0KWyAgICAwLjI2MjE1OF0gcGNpIDAwMDA6MDA6MWYuMjog cmVnIDIwOiBbaW8gIDB4MjAyMC0weDIwMmZdClsgICAgMC4yNjIxNzFdIHBjaSAwMDAwOjAw OjFmLjI6IHJlZyAyNDogW21lbSAweGQwMjA0MDAwLTB4ZDAyMDQzZmZdClsgICAgMC4yNjIy MTFdIHBjaSAwMDAwOjAwOjFmLjI6IFBNRSMgc3VwcG9ydGVkIGZyb20gRDNob3QKWyAgICAw LjI2MjIxOF0gcGNpIDAwMDA6MDA6MWYuMjogUE1FIyBkaXNhYmxlZApbICAgIDAuMjYyMjQy XSBwY2kgMDAwMDowMDoxZi4zOiBbODA4NjoyN2RhXSB0eXBlIDAgY2xhc3MgMHgwMDBjMDUK WyAgICAwLjI2MjMwNV0gcGNpIDAwMDA6MDA6MWYuMzogcmVnIDIwOiBbaW8gIDB4MjAwMC0w eDIwMWZdClsgICAgMC4yNjI0MzNdIHBjaSAwMDAwOjAxOjAwLjA6IFs4MDg2OjEwZDNdIHR5 cGUgMCBjbGFzcyAweDAwMDIwMApbICAgIDAuMjYyNDY0XSBwY2kgMDAwMDowMTowMC4wOiBy ZWcgMTA6IFttZW0gMHhkMDAyMDAwMC0weGQwMDNmZmZmXQpbICAgIDAuMjYyNDg2XSBwY2kg MDAwMDowMTowMC4wOiByZWcgMTQ6IFttZW0gMHhkMDAwMDAwMC0weGQwMDFmZmZmXQpbICAg IDAuMjYyNTA4XSBwY2kgMDAwMDowMTowMC4wOiByZWcgMTg6IFtpbyAgMHgxMDAwLTB4MTAx Zl0KWyAgICAwLjI2MjUzMV0gcGNpIDAwMDA6MDE6MDAuMDogcmVnIDFjOiBbbWVtIDB4ZDAw NDAwMDAtMHhkMDA0M2ZmZl0KWyAgICAwLjI2MjY0M10gcGNpIDAwMDA6MDE6MDAuMDogUE1F IyBzdXBwb3J0ZWQgZnJvbSBEMCBEM2hvdCBEM2NvbGQKWyAgICAwLjI2MjY1M10gcGNpIDAw MDA6MDE6MDAuMDogUE1FIyBkaXNhYmxlZApbICAgIDAuMjYyNzA0XSBwY2kgMDAwMDowMDox Yy4wOiBQQ0kgYnJpZGdlIHRvIFtidXMgMDEtMDFdClsgICAgMC4yNjI4MDJdIHBjaSAwMDAw OjAwOjFjLjA6ICAgYnJpZGdlIHdpbmRvdyBbaW8gIDB4MTAwMC0weDFmZmZdClsgICAgMC4y NjI4MTBdIHBjaSAwMDAwOjAwOjFjLjA6ICAgYnJpZGdlIHdpbmRvdyBbbWVtIDB4ZDAwMDAw MDAtMHhkMDBmZmZmZl0KWyAgICAwLjI2MjgyMF0gcGNpIDAwMDA6MDA6MWMuMDogICBicmlk Z2Ugd2luZG93IFttZW0gMHhmZmYwMDAwMC0weDAwMGZmZmZmIHByZWZdIChkaXNhYmxlZCkK WyAgICAwLjI2MjkxM10gcGNpIDAwMDA6MDA6MWUuMDogUENJIGJyaWRnZSB0byBbYnVzIDAy LTAyXSAoc3VidHJhY3RpdmUgZGVjb2RlKQpbICAgIDAuMjYzMDE1XSBwY2kgMDAwMDowMDox ZS4wOiAgIGJyaWRnZSB3aW5kb3cgW2lvICAweGYwMDAtMHgwMDAwXSAoZGlzYWJsZWQpClsg ICAgMC4yNjMwMjNdIHBjaSAwMDAwOjAwOjFlLjA6ICAgYnJpZGdlIHdpbmRvdyBbbWVtIDB4 ZmZmMDAwMDAtMHgwMDBmZmZmZl0gKGRpc2FibGVkKQpbICAgIDAuMjYzMDM0XSBwY2kgMDAw MDowMDoxZS4wOiAgIGJyaWRnZSB3aW5kb3cgW21lbSAweGZmZjAwMDAwLTB4MDAwZmZmZmYg cHJlZl0gKGRpc2FibGVkKQpbICAgIDAuMjYzMDQwXSBwY2kgMDAwMDowMDoxZS4wOiAgIGJy aWRnZSB3aW5kb3cgW2lvICAweDAwMDAtMHgwY2Y3XSAoc3VidHJhY3RpdmUgZGVjb2RlKQpb ICAgIDAuMjYzMDQ2XSBwY2kgMDAwMDowMDoxZS4wOiAgIGJyaWRnZSB3aW5kb3cgW2lvICAw eDBkMDAtMHhmZmZmXSAoc3VidHJhY3RpdmUgZGVjb2RlKQpbICAgIDAuMjYzMDUyXSBwY2kg MDAwMDowMDoxZS4wOiAgIGJyaWRnZSB3aW5kb3cgW21lbSAweDAwMGEwMDAwLTB4MDAwYmZm ZmZdIChzdWJ0cmFjdGl2ZSBkZWNvZGUpClsgICAgMC4yNjMwNTldIHBjaSAwMDAwOjAwOjFl LjA6ICAgYnJpZGdlIHdpbmRvdyBbbWVtIDB4MDAwYzAwMDAtMHgwMDBkZmZmZl0gKHN1YnRy YWN0aXZlIGRlY29kZSkKWyAgICAwLjI2MzA2NV0gcGNpIDAwMDA6MDA6MWUuMDogICBicmlk Z2Ugd2luZG93IFttZW0gMHgwMDBlMDAwMC0weDAwMGVmZmZmXSAoc3VidHJhY3RpdmUgZGVj b2RlKQpbICAgIDAuMjYzMDcxXSBwY2kgMDAwMDowMDoxZS4wOiAgIGJyaWRnZSB3aW5kb3cg W21lbSAweDAwMGYwMDAwLTB4MDAwZmZmZmZdIChzdWJ0cmFjdGl2ZSBkZWNvZGUpClsgICAg MC4yNjMwNzddIHBjaSAwMDAwOjAwOjFlLjA6ICAgYnJpZGdlIHdpbmRvdyBbbWVtIDB4Y2Y4 MDAwMDAtMHhjZmZmZmZmZl0gKHN1YnRyYWN0aXZlIGRlY29kZSkKWyAgICAwLjI2MzA4M10g cGNpIDAwMDA6MDA6MWUuMDogICBicmlkZ2Ugd2luZG93IFttZW0gMHhkMDAwMDAwMC0weGZl YmZmZmZmXSAoc3VidHJhY3RpdmUgZGVjb2RlKQpbICAgIDAuMjYzMDkwXSBwY2kgMDAwMDow MDoxZS4wOiAgIGJyaWRnZSB3aW5kb3cgW21lbSAweGZlZDQwMDAwLTB4ZmVkNDRmZmZdIChz dWJ0cmFjdGl2ZSBkZWNvZGUpClsgICAgMC4yNjMxMDhdIHBjaV9idXMgMDAwMDowMDogb24g TlVNQSBub2RlIDAKWyAgICAwLjI2MzExNV0gQUNQSTogUENJIEludGVycnVwdCBSb3V0aW5n IFRhYmxlIFtcX1NCXy5QQ0kwLl9QUlRdClsgICAgMC4yNjMyNjFdIEFDUEk6IFBDSSBJbnRl cnJ1cHQgUm91dGluZyBUYWJsZSBbXF9TQl8uUENJMC5QMFAxLl9QUlRdClsgICAgMC4yNjM1 MzFdIEFDUEk6IFBDSSBJbnRlcnJ1cHQgUm91dGluZyBUYWJsZSBbXF9TQl8uUENJMC5SUDAx Ll9QUlRdClsgICAgMC4yNjM3NDRdIFxfU0JfLlBDSTA6X09TQyBpbnZhbGlkIFVVSUQKWyAg ICAwLjI2Mzc0N10gX09TQyByZXF1ZXN0IGRhdGE6MSAxZiAxZiAKWyAgICAwLjI2Mzc1Nl0g IHBjaTAwMDA6MDA6IFJlcXVlc3RpbmcgQUNQSSBfT1NDIGNvbnRyb2wgKDB4MWQpClsgICAg MC4yNjM5NTZdIFxfU0JfLlBDSTA6X09TQyBpbnZhbGlkIFVVSUQKWyAgICAwLjI2Mzk1OV0g X09TQyByZXF1ZXN0IGRhdGE6MSAwIDFkIApbICAgIDAuMjcwNjQ3XSBBQ1BJOiBQQ0kgSW50 ZXJydXB0IExpbmsgW0xOS0FdIChJUlFzIDEgMyA0IDUgNiA3IDEwIDEyIDE0IDE1KSAqMTEK WyAgICAwLjI3MTI2NV0gQUNQSTogUENJIEludGVycnVwdCBMaW5rIFtMTktCXSAoSVJRcyAx IDMgNCA1IDYgNyAxMSAxMiAxNCAxNSkgKjAsIGRpc2FibGVkLgpbICAgIDAuMjcxOTA2XSBB Q1BJOiBQQ0kgSW50ZXJydXB0IExpbmsgW0xOS0NdIChJUlFzIDEgMyA0IDUgNiA3IDEwIDEy IDE0IDE1KSAqOQpbICAgIDAuMjcyNDQ1XSBBQ1BJOiBQQ0kgSW50ZXJydXB0IExpbmsgW0xO S0RdIChJUlFzIDEgMyA0IDUgNiA3ICoxMSAxMiAxNCAxNSkKWyAgICAwLjI3Mjk3M10gQUNQ STogUENJIEludGVycnVwdCBMaW5rIFtMTktFXSAoSVJRcyAxIDMgNCA1IDYgNyAxMCAxMiAx NCAxNSkgKjAsIGRpc2FibGVkLgpbICAgIDAuMjczNjAwXSBBQ1BJOiBQQ0kgSW50ZXJydXB0 IExpbmsgW0xOS0ZdIChJUlFzIDEgMyA0IDUgNiA3IDExIDEyIDE0IDE1KSAqMCwgZGlzYWJs ZWQuClsgICAgMC4yNzQyNDBdIEFDUEk6IFBDSSBJbnRlcnJ1cHQgTGluayBbTE5LR10gKElS UXMgMSAzIDQgNSA2IDcgMTAgMTIgMTQgMTUpICo5ClsgICAgMC4yNzQ3ODJdIEFDUEk6IFBD SSBJbnRlcnJ1cHQgTGluayBbTE5LSF0gKElSUXMgMSAzIDQgNSA2IDcgMTEgMTIgMTQgMTUp ICoxMApbICAgIDAuMjc1NDcwXSB2Z2FhcmI6IGRldmljZSBhZGRlZDogUENJOjAwMDA6MDA6 MDIuMCxkZWNvZGVzPWlvK21lbSxvd25zPWlvK21lbSxsb2Nrcz1ub25lClsgICAgMC4yNzU2 NDNdIHZnYWFyYjogbG9hZGVkClsgICAgMC4yNzYwMTldIFNDU0kgc3Vic3lzdGVtIGluaXRp YWxpemVkClsgICAgMC4yNzYyNTBdIGxpYmF0YSB2ZXJzaW9uIDMuMDAgbG9hZGVkLgpbICAg IDAuMjc2Mzc1XSB1c2Jjb3JlOiByZWdpc3RlcmVkIG5ldyBpbnRlcmZhY2UgZHJpdmVyIHVz YmZzClsgICAgMC4yNzY1MDddIHVzYmNvcmU6IHJlZ2lzdGVyZWQgbmV3IGludGVyZmFjZSBk cml2ZXIgaHViClsgICAgMC4yNzY2NjNdIHVzYmNvcmU6IHJlZ2lzdGVyZWQgbmV3IGRldmlj ZSBkcml2ZXIgdXNiClsgICAgMC4yNzY5ODVdIFBDSTogVXNpbmcgQUNQSSBmb3IgSVJRIHJv dXRpbmcKWyAgICAwLjI3NzA4Ml0gUENJOiBwY2lfY2FjaGVfbGluZV9zaXplIHNldCB0byA2 NCBieXRlcwpbICAgIDAuMjc3MTY1XSByZXNlcnZlIFJBTSBidWZmZXI6IDAwMDAwMDAwMDAw OGYwMDAgLSAwMDAwMDAwMDAwMDhmZmZmIApbICAgIDAuMjc3MTcxXSByZXNlcnZlIFJBTSBi dWZmZXI6IDAwMDAwMDAwMDAwOWU4MDAgLSAwMDAwMDAwMDAwMDlmZmZmIApbICAgIDAuMjc3 MTc2XSByZXNlcnZlIFJBTSBidWZmZXI6IDAwMDAwMDAwY2VlOTgwMDAgLSAwMDAwMDAwMGNm ZmZmZmZmIApbICAgIDAuMjc3MTgyXSByZXNlcnZlIFJBTSBidWZmZXI6IDAwMDAwMDAwY2Vm MGYwMDAgLSAwMDAwMDAwMGNmZmZmZmZmIApbICAgIDAuMjc3MTg4XSByZXNlcnZlIFJBTSBi dWZmZXI6IDAwMDAwMDAwY2VmZjIwMDAgLSAwMDAwMDAwMGNmZmZmZmZmIApbICAgIDAuMjc3 MTkzXSByZXNlcnZlIFJBTSBidWZmZXI6IDAwMDAwMDAwY2YwMDAwMDAgLSAwMDAwMDAwMGNm ZmZmZmZmIApbICAgIDAuMjc3NDY0XSBOZXRMYWJlbDogSW5pdGlhbGl6aW5nClsgICAgMC4y Nzc1NThdIE5ldExhYmVsOiAgZG9tYWluIGhhc2ggc2l6ZSA9IDEyOApbICAgIDAuMjc3NjUx XSBOZXRMYWJlbDogIHByb3RvY29scyA9IFVOTEFCRUxFRCBDSVBTT3Y0ClsgICAgMC4yNzc3 NjZdIE5ldExhYmVsOiAgdW5sYWJlbGVkIHRyYWZmaWMgYWxsb3dlZCBieSBkZWZhdWx0Clsg ICAgMC4yNzc4ODNdIGhwZXQwOiBhdCBNTUlPIDB4ZmVkMDAwMDAsIElSUXMgMiwgOCwgMApb ICAgIDAuMjc4MDgzXSBocGV0MDogMyBjb21wYXJhdG9ycywgNjQtYml0IDE0LjMxODE4MCBN SHogY291bnRlcgpbICAgIDAuMjgwMjEwXSBTd2l0Y2hpbmcgdG8gY2xvY2tzb3VyY2UgaHBl dApbICAgIDAuMjgwODI5XSBTd2l0Y2hlZCB0byBOT0h6IG1vZGUgb24gQ1BVICMwClsgICAg MC4yODA5NTZdIFN3aXRjaGVkIHRvIE5PSHogbW9kZSBvbiBDUFUgIzEKWyAgICAwLjI5ODA1 N10gcG5wOiBQblAgQUNQSSBpbml0ClsgICAgMC4yOTgxOTVdIEFDUEk6IGJ1cyB0eXBlIHBu cCByZWdpc3RlcmVkClsgICAgMC4yOTg2NjRdIHBucCAwMDowMDogW2J1cyAwMC1mZl0KWyAg ICAwLjI5ODY3MF0gcG5wIDAwOjAwOiBbaW8gIDB4MDAwMC0weDBjZjcgd2luZG93XQpbICAg IDAuMjk4Njc1XSBwbnAgMDA6MDA6IFtpbyAgMHgwY2Y4LTB4MGNmZl0KWyAgICAwLjI5ODY4 MV0gcG5wIDAwOjAwOiBbaW8gIDB4MGQwMC0weGZmZmYgd2luZG93XQpbICAgIDAuMjk4Njg2 XSBwbnAgMDA6MDA6IFttZW0gMHgwMDBhMDAwMC0weDAwMGJmZmZmIHdpbmRvd10KWyAgICAw LjI5ODY5Ml0gcG5wIDAwOjAwOiBbbWVtIDB4MDAwYzAwMDAtMHgwMDBkZmZmZiB3aW5kb3dd ClsgICAgMC4yOTg2OTddIHBucCAwMDowMDogW21lbSAweDAwMGUwMDAwLTB4MDAwZWZmZmYg d2luZG93XQpbICAgIDAuMjk4NzAzXSBwbnAgMDA6MDA6IFttZW0gMHgwMDBmMDAwMC0weDAw MGZmZmZmIHdpbmRvd10KWyAgICAwLjI5ODcwOF0gcG5wIDAwOjAwOiBbbWVtIDB4Y2Y4MDAw MDAtMHhjZmZmZmZmZiB3aW5kb3ddClsgICAgMC4yOTg3MTRdIHBucCAwMDowMDogW21lbSAw eGQwMDAwMDAwLTB4ZmViZmZmZmYgd2luZG93XQpbICAgIDAuMjk4NzE5XSBwbnAgMDA6MDA6 IFttZW0gMHhmZWQ0MDAwMC0weGZlZDQ0ZmZmIHdpbmRvd10KWyAgICAwLjI5ODg0Nl0gcG5w IDAwOjAwOiBQbHVnIGFuZCBQbGF5IEFDUEkgZGV2aWNlLCBJRHMgUE5QMGEwOCBQTlAwYTAz IChhY3RpdmUpClsgICAgMC4yOTg4ODddIHBucCAwMDowMTogW2lvICAweDAwMDAtMHgwMDFm XQpbICAgIDAuMjk4ODkyXSBwbnAgMDA6MDE6IFtpbyAgMHgwMDgxLTB4MDA5MV0KWyAgICAw LjI5ODg5N10gcG5wIDAwOjAxOiBbaW8gIDB4MDA5My0weDAwOWZdClsgICAgMC4yOTg5MDJd IHBucCAwMDowMTogW2lvICAweDAwYzAtMHgwMGRmXQpbICAgIDAuMjk4OTA3XSBwbnAgMDA6 MDE6IFtkbWEgNF0KWyAgICAwLjI5ODk3MV0gcG5wIDAwOjAxOiBQbHVnIGFuZCBQbGF5IEFD UEkgZGV2aWNlLCBJRHMgUE5QMDIwMCAoYWN0aXZlKQpbICAgIDAuMjk4OTkzXSBwbnAgMDA6 MDI6IFttZW0gMHhmZjAwMDAwMC0weGZmZmZmZmZmXQpbICAgIDAuMjk5MDU2XSBwbnAgMDA6 MDI6IFBsdWcgYW5kIFBsYXkgQUNQSSBkZXZpY2UsIElEcyBJTlQwODAwIChhY3RpdmUpClsg ICAgMC4yOTkyMjZdIHBucCAwMDowMzogW21lbSAweGZlZDAwMDAwLTB4ZmVkMDAzZmZdClsg ICAgMC4yOTkzNDRdIHN5c3RlbSAwMDowMzogW21lbSAweGZlZDAwMDAwLTB4ZmVkMDAzZmZd IGhhcyBiZWVuIHJlc2VydmVkClsgICAgMC4yOTk0NTBdIHN5c3RlbSAwMDowMzogUGx1ZyBh bmQgUGxheSBBQ1BJIGRldmljZSwgSURzIFBOUDAxMDMgUE5QMGMwMSAoYWN0aXZlKQpbICAg IDAuMjk5NDc4XSBwbnAgMDA6MDQ6IFtpbyAgMHgwMGYwXQpbICAgIDAuMjk5NDk0XSBwbnAg MDA6MDQ6IFtpcnEgMTNdClsgICAgMC4yOTk1NjFdIHBucCAwMDowNDogUGx1ZyBhbmQgUGxh eSBBQ1BJIGRldmljZSwgSURzIFBOUDBjMDQgKGFjdGl2ZSkKWyAgICAwLjI5OTU4OV0gcG5w IDAwOjA1OiBbaW8gIDB4MDAyZS0weDAwMmZdClsgICAgMC4yOTk1OTRdIHBucCAwMDowNTog W2lvICAweDAwNGUtMHgwMDRmXQpbICAgIDAuMjk5NTk4XSBwbnAgMDA6MDU6IFtpbyAgMHgw MDYxXQpbICAgIDAuMjk5NjAzXSBwbnAgMDA6MDU6IFtpbyAgMHgwMDYzXQpbICAgIDAuMjk5 NjA3XSBwbnAgMDA6MDU6IFtpbyAgMHgwMDY1XQpbICAgIDAuMjk5NjEyXSBwbnAgMDA6MDU6 IFtpbyAgMHgwMDY3XQpbICAgIDAuMjk5NjE2XSBwbnAgMDA6MDU6IFtpbyAgMHgwMDcwXQpb ICAgIDAuMjk5NjIwXSBwbnAgMDA6MDU6IFtpbyAgMHgwMDgwXQpbICAgIDAuMjk5NjI1XSBw bnAgMDA6MDU6IFtpbyAgMHgwMDkyXQpbICAgIDAuMjk5NjI5XSBwbnAgMDA6MDU6IFtpbyAg MHgwMGIyLTB4MDBiM10KWyAgICAwLjI5OTYzNF0gcG5wIDAwOjA1OiBbaW8gIDB4MDY4MC0w eDA2OWZdClsgICAgMC4yOTk2MzldIHBucCAwMDowNTogW2lvICAweGZmZmZdClsgICAgMC4y OTk2NDNdIHBucCAwMDowNTogW2lvICAweGZmZmZdClsgICAgMC4yOTk2NDddIHBucCAwMDow NTogW2lvICAweGZmZmZdClsgICAgMC4yOTk2NTJdIHBucCAwMDowNTogW2lvICAweDA0MDAt MHgwNDdmXQpbICAgIDAuMjk5NjU3XSBwbnAgMDA6MDU6IFtpbyAgMHgwNTAwLTB4MDU3Zl0K WyAgICAwLjI5OTY2MV0gcG5wIDAwOjA1OiBbaW8gIDB4MDYwMC0weDA2MWZdClsgICAgMC4y OTk3NzNdIHN5c3RlbSAwMDowNTogW2lvICAweDA2ODAtMHgwNjlmXSBoYXMgYmVlbiByZXNl cnZlZApbICAgIDAuMjk5ODcxXSBzeXN0ZW0gMDA6MDU6IFtpbyAgMHhmZmZmXSBoYXMgYmVl biByZXNlcnZlZApbICAgIDAuMjk5OTY3XSBzeXN0ZW0gMDA6MDU6IFtpbyAgMHhmZmZmXSBo YXMgYmVlbiByZXNlcnZlZApbICAgIDAuMzAwMDYzXSBzeXN0ZW0gMDA6MDU6IFtpbyAgMHhm ZmZmXSBoYXMgYmVlbiByZXNlcnZlZApbICAgIDAuMzAwMTY3XSBzeXN0ZW0gMDA6MDU6IFtp byAgMHgwNDAwLTB4MDQ3Zl0gaGFzIGJlZW4gcmVzZXJ2ZWQKWyAgICAwLjMwMDI2NF0gc3lz dGVtIDAwOjA1OiBbaW8gIDB4MDUwMC0weDA1N2ZdIGhhcyBiZWVuIHJlc2VydmVkClsgICAg MC4zMDAzNzZdIHN5c3RlbSAwMDowNTogW2lvICAweDA2MDAtMHgwNjFmXSBoYXMgYmVlbiBy ZXNlcnZlZApbICAgIDAuMzAwNDc0XSBzeXN0ZW0gMDA6MDU6IFBsdWcgYW5kIFBsYXkgQUNQ SSBkZXZpY2UsIElEcyBQTlAwYzAyIChhY3RpdmUpClsgICAgMC4zMDA1NDFdIHBucCAwMDow NjogW2lvICAweDA2YTAtMHgwNmFmXQpbICAgIDAuMzAwNTQ3XSBwbnAgMDA6MDY6IFtpbyAg MHgwNmIwLTB4MDZmZl0KWyAgICAwLjMwMDYzNF0gc3lzdGVtIDAwOjA2OiBbaW8gIDB4MDZh MC0weDA2YWZdIGhhcyBiZWVuIHJlc2VydmVkClsgICAgMC4zMDA3MzNdIHN5c3RlbSAwMDow NjogW2lvICAweDA2YjAtMHgwNmZmXSBoYXMgYmVlbiByZXNlcnZlZApbICAgIDAuMzAwODMz XSBzeXN0ZW0gMDA6MDY6IFBsdWcgYW5kIFBsYXkgQUNQSSBkZXZpY2UsIElEcyBQTlAwYzAy IChhY3RpdmUpClsgICAgMC4zMDA4NTZdIHBucCAwMDowNzogW2lvICAweDAwNzAtMHgwMDc3 XQpbICAgIDAuMzAwODY3XSBwbnAgMDA6MDc6IFtpcnEgOF0KWyAgICAwLjMwMDkzNF0gcG5w IDAwOjA3OiBQbHVnIGFuZCBQbGF5IEFDUEkgZGV2aWNlLCBJRHMgUE5QMGIwMCAoYWN0aXZl KQpbICAgIDAuMzAxMDE1XSBwbnAgMDA6MDg6IFtpbyAgMHgwMDYwXQpbICAgIDAuMzAxMDIw XSBwbnAgMDA6MDg6IFtpbyAgMHgwMDY0XQpbICAgIDAuMzAxMDMwXSBwbnAgMDA6MDg6IFtp cnEgMV0KWyAgICAwLjMwMTEwMV0gcG5wIDAwOjA4OiBQbHVnIGFuZCBQbGF5IEFDUEkgZGV2 aWNlLCBJRHMgUE5QMDMwMyBQTlAwMzBiIChhY3RpdmUpClsgICAgMC4zMDE0MTddIHBucCAw MDowOTogW2lvICAweDAzNzgtMHgwMzdmXQpbICAgIDAuMzAxNDI4XSBwbnAgMDA6MDk6IFtp cnEgN10KWyAgICAwLjMwMTU3NF0gcG5wIDAwOjA5OiBQbHVnIGFuZCBQbGF5IEFDUEkgZGV2 aWNlLCBJRHMgUE5QMDQwMCAoYWN0aXZlKQpbICAgIDAuMzAxOTI2XSBwbnAgMDA6MGE6IFtp byAgMHgwM2Y4LTB4MDNmZl0KWyAgICAwLjMwMTkzMl0gcG5wIDAwOjBhOiBJUlEgNCBvdmVy cmlkZSB0byBlZGdlLCBoaWdoClsgICAgMC4zMDIwMzRdIHBucCAwMDowYTogW2lycSA0XQpb ICAgIDAuMzAyMTc2XSBwbnAgMDA6MGE6IFBsdWcgYW5kIFBsYXkgQUNQSSBkZXZpY2UsIElE cyBQTlAwNTAxIChhY3RpdmUpClsgICAgMC4zMDI0NjhdIHBucCAwMDowYjogW2lvICAweDAy ZjgtMHgwMmZmXQpbICAgIDAuMzAyNDc0XSBwbnAgMDA6MGI6IElSUSAzIG92ZXJyaWRlIHRv IGVkZ2UsIGhpZ2gKWyAgICAwLjMwMjU3NF0gcG5wIDAwOjBiOiBbaXJxIDNdClsgICAgMC4z MDI3MTJdIHBucCAwMDowYjogUGx1ZyBhbmQgUGxheSBBQ1BJIGRldmljZSwgSURzIFBOUDA1 MDEgKGFjdGl2ZSkKWyAgICAwLjMwMjk3NF0gcG5wIDAwOjBjOiBbbWVtIDB4ZmVkMWMwMDAt MHhmZWQxZmZmZl0KWyAgICAwLjMwMjk4MF0gcG5wIDAwOjBjOiBbbWVtIDB4MDAwMDAwMDAt MHgwMDAwM2ZmZl0KWyAgICAwLjMwMjk4NV0gcG5wIDAwOjBjOiBbbWVtIDB4MDAwMDAwMDAt MHgwMDAwMGZmZl0KWyAgICAwLjMwMjk5MF0gcG5wIDAwOjBjOiBbbWVtIDB4MDAwMDAwMDAt MHgwMDAwMGZmZl0KWyAgICAwLjMwMjk5NV0gcG5wIDAwOjBjOiBbbWVtIDB4MDAwMDAwMDAt MHhmZmZmZmZmZiBkaXNhYmxlZF0KWyAgICAwLjMwMzAwMV0gcG5wIDAwOjBjOiBbbWVtIDB4 ZmVkNDUwMDAtMHhmZWQ4ZmZmZl0KWyAgICAwLjMwMzExN10gc3lzdGVtIDAwOjBjOiBbbWVt IDB4ZmVkMWMwMDAtMHhmZWQxZmZmZl0gaGFzIGJlZW4gcmVzZXJ2ZWQKWyAgICAwLjMwMzIx Nl0gc3lzdGVtIDAwOjBjOiBbbWVtIDB4MDAwMDAwMDAtMHgwMDAwM2ZmZl0gY291bGQgbm90 IGJlIHJlc2VydmVkClsgICAgMC4zMDMzMzJdIHN5c3RlbSAwMDowYzogW21lbSAweDAwMDAw MDAwLTB4MDAwMDBmZmZdIGNvdWxkIG5vdCBiZSByZXNlcnZlZApbICAgIDAuMzAzNDMxXSBz eXN0ZW0gMDA6MGM6IFttZW0gMHgwMDAwMDAwMC0weDAwMDAwZmZmXSBjb3VsZCBub3QgYmUg cmVzZXJ2ZWQKWyAgICAwLjMwMzUzMl0gc3lzdGVtIDAwOjBjOiBbbWVtIDB4ZmVkNDUwMDAt MHhmZWQ4ZmZmZl0gaGFzIGJlZW4gcmVzZXJ2ZWQKWyAgICAwLjMwMzYzM10gc3lzdGVtIDAw OjBjOiBQbHVnIGFuZCBQbGF5IEFDUEkgZGV2aWNlLCBJRHMgUE5QMGMwMiAoYWN0aXZlKQpb ICAgIDAuMzAzOTMwXSBwbnA6IFBuUCBBQ1BJOiBmb3VuZCAxMyBkZXZpY2VzClsgICAgMC4z MDQwMjZdIEFDUEk6IEFDUEkgYnVzIHR5cGUgcG5wIHVucmVnaXN0ZXJlZApbICAgIDAuMzQz Nzc1XSBwY2kgMDAwMDowMDoxYy4wOiBCQVIgMTU6IGFzc2lnbmVkIFttZW0gMHhkMDQwMDAw MC0weGQwNWZmZmZmIDY0Yml0IHByZWZdClsgICAgMC4zNDM5NDNdIHBjaSAwMDAwOjAwOjFj LjA6IFBDSSBicmlkZ2UgdG8gW2J1cyAwMS0wMV0KWyAgICAwLjM0NDA0MV0gcGNpIDAwMDA6 MDA6MWMuMDogICBicmlkZ2Ugd2luZG93IFtpbyAgMHgxMDAwLTB4MWZmZl0KWyAgICAwLjM0 NDE0Ml0gcGNpIDAwMDA6MDA6MWMuMDogICBicmlkZ2Ugd2luZG93IFttZW0gMHhkMDAwMDAw MC0weGQwMGZmZmZmXQpbICAgIDAuMzQ0MjQxXSBwY2kgMDAwMDowMDoxYy4wOiAgIGJyaWRn ZSB3aW5kb3cgW21lbSAweGQwNDAwMDAwLTB4ZDA1ZmZmZmYgNjRiaXQgcHJlZl0KWyAgICAw LjM0NDQyMF0gcGNpIDAwMDA6MDA6MWUuMDogUENJIGJyaWRnZSB0byBbYnVzIDAyLTAyXQpb ICAgIDAuMzQ0NTE2XSBwY2kgMDAwMDowMDoxZS4wOiAgIGJyaWRnZSB3aW5kb3cgW2lvICBk aXNhYmxlZF0KWyAgICAwLjM0NDYxNV0gcGNpIDAwMDA6MDA6MWUuMDogICBicmlkZ2Ugd2lu ZG93IFttZW0gZGlzYWJsZWRdClsgICAgMC4zNDQ3MTJdIHBjaSAwMDAwOjAwOjFlLjA6ICAg YnJpZGdlIHdpbmRvdyBbbWVtIHByZWYgZGlzYWJsZWRdClsgICAgMC4zNDQ4MzJdIHBjaSAw MDAwOjAwOjFjLjA6IFBDSSBJTlQgQSAtPiBHU0kgMTYgKGxldmVsLCBsb3cpIC0+IElSUSAx NgpbICAgIDAuMzQ0OTMyXSBwY2kgMDAwMDowMDoxYy4wOiBzZXR0aW5nIGxhdGVuY3kgdGlt ZXIgdG8gNjQKWyAgICAwLjM0NDk0NV0gcGNpIDAwMDA6MDA6MWUuMDogc2V0dGluZyBsYXRl bmN5IHRpbWVyIHRvIDY0ClsgICAgMC4zNDQ5NTNdIHBjaV9idXMgMDAwMDowMDogcmVzb3Vy Y2UgNCBbaW8gIDB4MDAwMC0weDBjZjddClsgICAgMC4zNDQ5NThdIHBjaV9idXMgMDAwMDow MDogcmVzb3VyY2UgNSBbaW8gIDB4MGQwMC0weGZmZmZdClsgICAgMC4zNDQ5NjRdIHBjaV9i dXMgMDAwMDowMDogcmVzb3VyY2UgNiBbbWVtIDB4MDAwYTAwMDAtMHgwMDBiZmZmZl0KWyAg ICAwLjM0NDk2OV0gcGNpX2J1cyAwMDAwOjAwOiByZXNvdXJjZSA3IFttZW0gMHgwMDBjMDAw MC0weDAwMGRmZmZmXQpbICAgIDAuMzQ0OTc1XSBwY2lfYnVzIDAwMDA6MDA6IHJlc291cmNl IDggW21lbSAweDAwMGUwMDAwLTB4MDAwZWZmZmZdClsgICAgMC4zNDQ5ODBdIHBjaV9idXMg MDAwMDowMDogcmVzb3VyY2UgOSBbbWVtIDB4MDAwZjAwMDAtMHgwMDBmZmZmZl0KWyAgICAw LjM0NDk4Nl0gcGNpX2J1cyAwMDAwOjAwOiByZXNvdXJjZSAxMCBbbWVtIDB4Y2Y4MDAwMDAt MHhjZmZmZmZmZl0KWyAgICAwLjM0NDk5Ml0gcGNpX2J1cyAwMDAwOjAwOiByZXNvdXJjZSAx MSBbbWVtIDB4ZDAwMDAwMDAtMHhmZWJmZmZmZl0KWyAgICAwLjM0NDk5N10gcGNpX2J1cyAw MDAwOjAwOiByZXNvdXJjZSAxMiBbbWVtIDB4ZmVkNDAwMDAtMHhmZWQ0NGZmZl0KWyAgICAw LjM0NTAwM10gcGNpX2J1cyAwMDAwOjAxOiByZXNvdXJjZSAwIFtpbyAgMHgxMDAwLTB4MWZm Zl0KWyAgICAwLjM0NTAwOV0gcGNpX2J1cyAwMDAwOjAxOiByZXNvdXJjZSAxIFttZW0gMHhk MDAwMDAwMC0weGQwMGZmZmZmXQpbICAgIDAuMzQ1MDE1XSBwY2lfYnVzIDAwMDA6MDE6IHJl c291cmNlIDIgW21lbSAweGQwNDAwMDAwLTB4ZDA1ZmZmZmYgNjRiaXQgcHJlZl0KWyAgICAw LjM0NTAyMV0gcGNpX2J1cyAwMDAwOjAyOiByZXNvdXJjZSA0IFtpbyAgMHgwMDAwLTB4MGNm N10KWyAgICAwLjM0NTAyNl0gcGNpX2J1cyAwMDAwOjAyOiByZXNvdXJjZSA1IFtpbyAgMHgw ZDAwLTB4ZmZmZl0KWyAgICAwLjM0NTAzMl0gcGNpX2J1cyAwMDAwOjAyOiByZXNvdXJjZSA2 IFttZW0gMHgwMDBhMDAwMC0weDAwMGJmZmZmXQpbICAgIDAuMzQ1MDM3XSBwY2lfYnVzIDAw MDA6MDI6IHJlc291cmNlIDcgW21lbSAweDAwMGMwMDAwLTB4MDAwZGZmZmZdClsgICAgMC4z NDUwNDNdIHBjaV9idXMgMDAwMDowMjogcmVzb3VyY2UgOCBbbWVtIDB4MDAwZTAwMDAtMHgw MDBlZmZmZl0KWyAgICAwLjM0NTA0OF0gcGNpX2J1cyAwMDAwOjAyOiByZXNvdXJjZSA5IFtt ZW0gMHgwMDBmMDAwMC0weDAwMGZmZmZmXQpbICAgIDAuMzQ1MDU0XSBwY2lfYnVzIDAwMDA6 MDI6IHJlc291cmNlIDEwIFttZW0gMHhjZjgwMDAwMC0weGNmZmZmZmZmXQpbICAgIDAuMzQ1 MDYwXSBwY2lfYnVzIDAwMDA6MDI6IHJlc291cmNlIDExIFttZW0gMHhkMDAwMDAwMC0weGZl YmZmZmZmXQpbICAgIDAuMzQ1MDY1XSBwY2lfYnVzIDAwMDA6MDI6IHJlc291cmNlIDEyIFtt ZW0gMHhmZWQ0MDAwMC0weGZlZDQ0ZmZmXQpbICAgIDAuMzQ1MjE2XSBORVQ6IFJlZ2lzdGVy ZWQgcHJvdG9jb2wgZmFtaWx5IDIKWyAgICAwLjM0NTQ5N10gSVAgcm91dGUgY2FjaGUgaGFz aCB0YWJsZSBlbnRyaWVzOiAzMjc2OCAob3JkZXI6IDUsIDEzMTA3MiBieXRlcykKWyAgICAw LjM0NTk5MV0gVENQIGVzdGFibGlzaGVkIGhhc2ggdGFibGUgZW50cmllczogMTMxMDcyIChv cmRlcjogOCwgMTA0ODU3NiBieXRlcykKWyAgICAwLjM0NzAwMl0gVENQIGJpbmQgaGFzaCB0 YWJsZSBlbnRyaWVzOiA2NTUzNiAob3JkZXI6IDcsIDUyNDI4OCBieXRlcykKWyAgICAwLjM0 NzUxNF0gVENQOiBIYXNoIHRhYmxlcyBjb25maWd1cmVkIChlc3RhYmxpc2hlZCAxMzEwNzIg YmluZCA2NTUzNikKWyAgICAwLjM0NzYyMF0gVENQIHJlbm8gcmVnaXN0ZXJlZApbICAgIDAu MzQ3NzIxXSBVRFAgaGFzaCB0YWJsZSBlbnRyaWVzOiA1MTIgKG9yZGVyOiAyLCAxNjM4NCBi eXRlcykKWyAgICAwLjM0NzgyOV0gVURQLUxpdGUgaGFzaCB0YWJsZSBlbnRyaWVzOiA1MTIg KG9yZGVyOiAyLCAxNjM4NCBieXRlcykKWyAgICAwLjM0ODQ4Ml0gTkVUOiBSZWdpc3RlcmVk IHByb3RvY29sIGZhbWlseSAxClsgICAgMC4zNDg4MjJdIFJQQzogUmVnaXN0ZXJlZCB1ZHAg dHJhbnNwb3J0IG1vZHVsZS4KWyAgICAwLjM0ODkxOV0gUlBDOiBSZWdpc3RlcmVkIHRjcCB0 cmFuc3BvcnQgbW9kdWxlLgpbICAgIDAuMzQ5MDEyXSBSUEM6IFJlZ2lzdGVyZWQgdGNwIE5G U3Y0LjEgYmFja2NoYW5uZWwgdHJhbnNwb3J0IG1vZHVsZS4KWyAgICAwLjM0OTEyNV0gcGNp IDAwMDA6MDA6MDIuMDogQm9vdCB2aWRlbyBkZXZpY2UKWyAgICAwLjM2MTMxNV0gUENJOiBD TFMgNjQgYnl0ZXMsIGRlZmF1bHQgNjQKWyAgICAxLjI5NTM1N10gVHJ5aW5nIHRvIHVucGFj ayByb290ZnMgaW1hZ2UgYXMgaW5pdHJhbWZzLi4uClsgICAgMy4xNDc0ODRdIEZyZWVpbmcg aW5pdHJkIG1lbW9yeTogODU0MGsgZnJlZWQKWyAgICAzLjE1NTIyM10gYXBtOiBCSU9TIG5v dCBmb3VuZC4KWyAgICAzLjE1NTcyN10gYXVkaXQ6IGluaXRpYWxpemluZyBuZXRsaW5rIHNv Y2tldCAoZGlzYWJsZWQpClsgICAgMy4xNTU4MzVdIHR5cGU9MjAwMCBhdWRpdCgxMzQyMjg1 MTM1LjAzNzoxKTogaW5pdGlhbGl6ZWQKWyAgICAzLjE5NDMxOV0gaGlnaG1lbSBib3VuY2Ug cG9vbCBzaXplOiA2NCBwYWdlcwpbICAgIDMuMTk0NDQ4XSBIdWdlVExCIHJlZ2lzdGVyZWQg NCBNQiBwYWdlIHNpemUsIHByZS1hbGxvY2F0ZWQgMCBwYWdlcwpbICAgIDMuMTk5MDk2XSBW RlM6IERpc2sgcXVvdGFzIGRxdW90XzYuNS4yClsgICAgMy4xOTk1MjRdIERxdW90LWNhY2hl IGhhc2ggdGFibGUgZW50cmllczogMTAyNCAob3JkZXIgMCwgNDA5NiBieXRlcykKWyAgICAz LjE5OTgyM10gTG9hZGluZyBSZWlzZXI0LiBTZWUgd3d3Lm5hbWVzeXMuY29tIGZvciBhIGRl c2NyaXB0aW9uIG9mIFJlaXNlcjQuClsgICAgMy4yMDE2NTFdIHNxdWFzaGZzOiB2ZXJzaW9u IDQuMCAoMjAwOS8wMS8zMSkgUGhpbGxpcCBMb3VnaGVyClsgICAgMy4yMDI2MTldIG5mczRm aWxlbGF5b3V0X2luaXQ6IE5GU3Y0IEZpbGUgTGF5b3V0IERyaXZlciBSZWdpc3RlcmluZy4u LgpbICAgIDMuMjAyNzE4XSBOVEZTIGRyaXZlciAyLjEuMzAgW0ZsYWdzOiBSL09dLgpbICAg IDMuMjAzMTM5XSBmdXNlIGluaXQgKEFQSSB2ZXJzaW9uIDcuMTYpClsgICAgMy4yMDM3OTVd IEpGUzogblR4QmxvY2sgPSA4MTkyLCBuVHhMb2NrID0gNjU1MzYKWyAgICAzLjIwNzg3MF0g U0dJIFhGUyB3aXRoIEFDTHMsIHNlY3VyaXR5IGF0dHJpYnV0ZXMsIHJlYWx0aW1lLCBsYXJn ZSBibG9jay9pbm9kZSBudW1iZXJzLCBubyBkZWJ1ZyBlbmFibGVkClsgICAgMy4yMDk0NzNd IFNHSSBYRlMgUXVvdGEgTWFuYWdlbWVudCBzdWJzeXN0ZW0KWyAgICAzLjIxMDA3NV0gQnRy ZnMgbG9hZGVkClsgICAgMy4yMTA1OTRdIGF1ZnMgMi4xLXN0YW5kYWxvbmUudHJlZS0zOC0y MDExMDQxOApbICAgIDMuMjEwNjkyXSBtc2dtbmkgaGFzIGJlZW4gc2V0IHRvIDE2NDIKWyAg ICAzLjIxMTc1NF0gYWxnOiBObyB0ZXN0IGZvciBzdGRybmcgKGtybmcpClsgICAgMy4yMTE4 NjNdIE5FVDogUmVnaXN0ZXJlZCBwcm90b2NvbCBmYW1pbHkgMzgKWyAgICAzLjIxMjAxOV0g QmxvY2sgbGF5ZXIgU0NTSSBnZW5lcmljIChic2cpIGRyaXZlciB2ZXJzaW9uIDAuNCBsb2Fk ZWQgKG1ham9yIDI1MykKWyAgICAzLjIxMjI1MV0gaW8gc2NoZWR1bGVyIG5vb3AgcmVnaXN0 ZXJlZApbICAgIDMuMjEyMzQ0XSBpbyBzY2hlZHVsZXIgZGVhZGxpbmUgcmVnaXN0ZXJlZApb ICAgIDMuMjEyNTExXSBpbyBzY2hlZHVsZXIgY2ZxIHJlZ2lzdGVyZWQgKGRlZmF1bHQpClsg ICAgMy4yMTI3NzhdIHBjaWVwb3J0IDAwMDA6MDA6MWMuMDogc2V0dGluZyBsYXRlbmN5IHRp bWVyIHRvIDY0ClsgICAgMy4yMTI4MzddIHBjaWVwb3J0IDAwMDA6MDA6MWMuMDogaXJxIDQw IGZvciBNU0kvTVNJLVgKWyAgICAzLjIxMzAxN10gcGNpX2hvdHBsdWc6IFBDSSBIb3QgUGx1 ZyBQQ0kgQ29yZSB2ZXJzaW9uOiAwLjUKWyAgICAzLjIxMzE5Nl0gcGNpZWhwOiBQQ0kgRXhw cmVzcyBIb3QgUGx1ZyBDb250cm9sbGVyIERyaXZlciB2ZXJzaW9uOiAwLjQKWyAgICAzLjIx MzI5MV0gYWNwaXBocDogQUNQSSBIb3QgUGx1ZyBQQ0kgQ29udHJvbGxlciBEcml2ZXIgdmVy c2lvbjogMC41ClsgICAgMy4yMTQwMDNdIGludGVsX2lkbGU6IE1XQUlUIHN1YnN0YXRlczog MHgxMApbICAgIDMuMjE0MDA4XSBpbnRlbF9pZGxlOiBkb2VzIG5vdCBydW4gb24gZmFtaWx5 IDYgbW9kZWwgNTQKWyAgICAzLjIxNDI0Ml0gaW5wdXQ6IFBvd2VyIEJ1dHRvbiBhcyAvZGV2 aWNlcy9MTlhTWVNUTTowMC9kZXZpY2U6MDAvUE5QMEMwQzowMC9pbnB1dC9pbnB1dDAKWyAg ICAzLjIxOTM5MV0gQUNQSTogUG93ZXIgQnV0dG9uIFtQV1JCXQpbICAgIDMuMjE5NjIyXSBp bnB1dDogU2xlZXAgQnV0dG9uIGFzIC9kZXZpY2VzL0xOWFNZU1RNOjAwL2RldmljZTowMC9Q TlAwQzBFOjAwL2lucHV0L2lucHV0MQpbICAgIDMuMjE5Nzc5XSBBQ1BJOiBTbGVlcCBCdXR0 b24gW1NMUEJdClsgICAgMy4yMTk5OThdIGlucHV0OiBQb3dlciBCdXR0b24gYXMgL2Rldmlj ZXMvTE5YU1lTVE06MDAvTE5YUFdSQk46MDAvaW5wdXQvaW5wdXQyClsgICAgMy4yMjAxNTNd IEFDUEk6IFBvd2VyIEJ1dHRvbiBbUFdSRl0KWyAgICAzLjIyMDU1NF0gQUNQSTogYWNwaV9p ZGxlIHJlZ2lzdGVyZWQgd2l0aCBjcHVpZGxlClsgICAgMy4yMjM0MDddIEVSU1Q6IFRhYmxl IGlzIG5vdCBmb3VuZCEKWyAgICAzLjIyMzY0N10gaXNhcG5wOiBTY2FubmluZyBmb3IgUG5Q IGNhcmRzLi4uClsgICAgMy41Nzk3OTNdIGlzYXBucDogTm8gUGx1ZyAmIFBsYXkgZGV2aWNl IGZvdW5kClsgICAgMy41ODAwNzJdIFNlcmlhbDogODI1MC8xNjU1MCBkcml2ZXIsIDMyIHBv cnRzLCBJUlEgc2hhcmluZyBlbmFibGVkClsgICAgMy42MDA4MDZdIHNlcmlhbDgyNTA6IHR0 eVMwIGF0IEkvTyAweDNmOCAoaXJxID0gNCkgaXMgYSAxNjU1MEEKWyAgICAzLjYyMTYwOF0g c2VyaWFsODI1MDogdHR5UzEgYXQgSS9PIDB4MmY4IChpcnEgPSAzKSBpcyBhIDE2NTUwQQpb ICAgIDMuNjcyODM3XSAwMDowYTogdHR5UzAgYXQgSS9PIDB4M2Y4IChpcnEgPSA0KSBpcyBh IDE2NTUwQQpbICAgIDMuNjkzNzExXSAwMDowYjogdHR5UzEgYXQgSS9PIDB4MmY4IChpcnEg PSAzKSBpcyBhIDE2NTUwQQpbICAgIDMuNjk0NTQxXSBOb24tdm9sYXRpbGUgbWVtb3J5IGRy aXZlciB2MS4zClsgICAgMy42OTQ2MzZdIExpbnV4IGFncGdhcnQgaW50ZXJmYWNlIHYwLjEw MwpbICAgIDMuNjk5NjkxXSBicmQ6IG1vZHVsZSBsb2FkZWQKWyAgICAzLjcwMTUxMl0gbG9v cDogQUVTIGtleSBzY3J1YmJpbmcgZW5hYmxlZApbICAgIDMuNzAxNjA1XSBsb29wOiBsb2Fk ZWQgKG1heCA4IGRldmljZXMpClsgICAgMy43MDE4NzNdIGFoY2kgMDAwMDowMDoxZi4yOiB2 ZXJzaW9uIDMuMApbICAgIDMuNzAxOTI0XSBhaGNpIDAwMDA6MDA6MWYuMjogUENJIElOVCBC IC0+IEdTSSAxOSAobGV2ZWwsIGxvdykgLT4gSVJRIDE5ClsgICAgMy43MDIwNzRdIGFoY2kg MDAwMDowMDoxZi4yOiBpcnEgNDEgZm9yIE1TSS9NU0ktWApbICAgIDMuNzAyMTI4XSBhaGNp OiBTU1MgZmxhZyBzZXQsIHBhcmFsbGVsIGJ1cyBzY2FuIGRpc2FibGVkClsgICAgMy43MDIy NTVdIGFoY2kgMDAwMDowMDoxZi4yOiBBSENJIDAwMDEuMDEwMCAzMiBzbG90cyA0IHBvcnRz IDMgR2JwcyAweDMgaW1wbCBTQVRBIG1vZGUKWyAgICAzLjcwMjQwOV0gYWhjaSAwMDAwOjAw OjFmLjI6IGZsYWdzOiA2NGJpdCBuY3Egc3RhZyBwbSBsZWQgY2xvIHBpbyBzbHVtIHBhcnQg ClsgICAgMy43MDI1NjZdIGFoY2kgMDAwMDowMDoxZi4yOiBzZXR0aW5nIGxhdGVuY3kgdGlt ZXIgdG8gNjQKWyAgICAzLjcwNDAwMV0gc2NzaTAgOiBhaGNpClsgICAgMy43MDQzNjddIHNj c2kxIDogYWhjaQpbICAgIDMuNzA0NjMwXSBzY3NpMiA6IGFoY2kKWyAgICAzLjcwNDkwNl0g c2NzaTMgOiBhaGNpClsgICAgMy43MDUxMzhdIGF0YTE6IFNBVEEgbWF4IFVETUEvMTMzIGFi YXIgbTEwMjRAMHhkMDIwNDAwMCBwb3J0IDB4ZDAyMDQxMDAgaXJxIDQxClsgICAgMy43MDUy OTRdIGF0YTI6IFNBVEEgbWF4IFVETUEvMTMzIGFiYXIgbTEwMjRAMHhkMDIwNDAwMCBwb3J0 IDB4ZDAyMDQxODAgaXJxIDQxClsgICAgMy43MDU0NDddIGF0YTM6IERVTU1ZClsgICAgMy43 MDU1MzZdIGF0YTQ6IERVTU1ZClsgICAgMy43MDU5NThdIEZpeGVkIE1ESU8gQnVzOiBwcm9i ZWQKWyAgICAzLjcwNjE5OF0gZWhjaV9oY2Q6IFVTQiAyLjAgJ0VuaGFuY2VkJyBIb3N0IENv bnRyb2xsZXIgKEVIQ0kpIERyaXZlcgpbICAgIDMuNzA2MzMxXSBlaGNpX2hjZCAwMDAwOjAw OjFkLjc6IFBDSSBJTlQgQSAtPiBHU0kgMjMgKGxldmVsLCBsb3cpIC0+IElSUSAyMwpbICAg IDMuNzA2NDUwXSBlaGNpX2hjZCAwMDAwOjAwOjFkLjc6IHNldHRpbmcgbGF0ZW5jeSB0aW1l ciB0byA2NApbICAgIDMuNzA2NDU3XSBlaGNpX2hjZCAwMDAwOjAwOjFkLjc6IEVIQ0kgSG9z dCBDb250cm9sbGVyClsgICAgMy43MDY2NzZdIGVoY2lfaGNkIDAwMDA6MDA6MWQuNzogbmV3 IFVTQiBidXMgcmVnaXN0ZXJlZCwgYXNzaWduZWQgYnVzIG51bWJlciAxClsgICAgMy43MDY5 MTldIGVoY2lfaGNkIDAwMDA6MDA6MWQuNzogdXNpbmcgYnJva2VuIHBlcmlvZGljIHdvcmth cm91bmQKWyAgICAzLjcwNzAyNV0gZWhjaV9oY2QgMDAwMDowMDoxZC43OiBkZWJ1ZyBwb3J0 IDEKWyAgICAzLjcxMTAxMV0gZWhjaV9oY2QgMDAwMDowMDoxZC43OiBjYWNoZSBsaW5lIHNp emUgb2YgNjQgaXMgbm90IHN1cHBvcnRlZApbICAgIDMuNzExMDQwXSBlaGNpX2hjZCAwMDAw OjAwOjFkLjc6IGlycSAyMywgaW8gbWVtIDB4ZDAyMDQ0MDAKWyAgICAzLjcyMDg5Ml0gZWhj aV9oY2QgMDAwMDowMDoxZC43OiBVU0IgMi4wIHN0YXJ0ZWQsIEVIQ0kgMS4wMApbICAgIDMu NzIxMDQ3XSB1c2IgdXNiMTogTmV3IFVTQiBkZXZpY2UgZm91bmQsIGlkVmVuZG9yPTFkNmIs IGlkUHJvZHVjdD0wMDAyClsgICAgMy43MjExNDNdIHVzYiB1c2IxOiBOZXcgVVNCIGRldmlj ZSBzdHJpbmdzOiBNZnI9MywgUHJvZHVjdD0yLCBTZXJpYWxOdW1iZXI9MQpbICAgIDMuNzIx Mjk3XSB1c2IgdXNiMTogUHJvZHVjdDogRUhDSSBIb3N0IENvbnRyb2xsZXIKWyAgICAzLjcy MTM5MF0gdXNiIHVzYjE6IE1hbnVmYWN0dXJlcjogTGludXggMi42LjM4LXN0ZDIzMS1pNTg2 IGVoY2lfaGNkClsgICAgMy43MjE0ODRdIHVzYiB1c2IxOiBTZXJpYWxOdW1iZXI6IDAwMDA6 MDA6MWQuNwpbICAgIDMuNzIxODAyXSBodWIgMS0wOjEuMDogVVNCIGh1YiBmb3VuZApbICAg IDMuNzIxOTE3XSBodWIgMS0wOjEuMDogOCBwb3J0cyBkZXRlY3RlZApbICAgIDMuNzIyMTg0 XSBvaGNpX2hjZDogVVNCIDEuMSAnT3BlbicgSG9zdCBDb250cm9sbGVyIChPSENJKSBEcml2 ZXIKWyAgICAzLjcyMjMwOV0gdWhjaV9oY2Q6IFVTQiBVbml2ZXJzYWwgSG9zdCBDb250cm9s bGVyIEludGVyZmFjZSBkcml2ZXIKWyAgICAzLjcyMjQ3Ml0gdWhjaV9oY2QgMDAwMDowMDox ZC4wOiBQQ0kgSU5UIEEgLT4gR1NJIDIzIChsZXZlbCwgbG93KSAtPiBJUlEgMjMKWyAgICAz LjcyMjU3N10gdWhjaV9oY2QgMDAwMDowMDoxZC4wOiBzZXR0aW5nIGxhdGVuY3kgdGltZXIg dG8gNjQKWyAgICAzLjcyMjU4NF0gdWhjaV9oY2QgMDAwMDowMDoxZC4wOiBVSENJIEhvc3Qg Q29udHJvbGxlcgpbICAgIDMuNzI0Mzg1XSB1aGNpX2hjZCAwMDAwOjAwOjFkLjA6IG5ldyBV U0IgYnVzIHJlZ2lzdGVyZWQsIGFzc2lnbmVkIGJ1cyBudW1iZXIgMgpbICAgIDMuNzI0OTI2 XSB1aGNpX2hjZCAwMDAwOjAwOjFkLjA6IGlycSAyMywgaW8gYmFzZSAweDAwMDAyMGEwClsg ICAgMy43MjUwODhdIHVzYiB1c2IyOiBOZXcgVVNCIGRldmljZSBmb3VuZCwgaWRWZW5kb3I9 MWQ2YiwgaWRQcm9kdWN0PTAwMDEKWyAgICAzLjcyNTE4NF0gdXNiIHVzYjI6IE5ldyBVU0Ig ZGV2aWNlIHN0cmluZ3M6IE1mcj0zLCBQcm9kdWN0PTIsIFNlcmlhbE51bWJlcj0xClsgICAg My43MjUzMzZdIHVzYiB1c2IyOiBQcm9kdWN0OiBVSENJIEhvc3QgQ29udHJvbGxlcgpbICAg IDMuNzI1NDI5XSB1c2IgdXNiMjogTWFudWZhY3R1cmVyOiBMaW51eCAyLjYuMzgtc3RkMjMx LWk1ODYgdWhjaV9oY2QKWyAgICAzLjcyNTUyM10gdXNiIHVzYjI6IFNlcmlhbE51bWJlcjog MDAwMDowMDoxZC4wClsgICAgMy43MjU4MjldIGh1YiAyLTA6MS4wOiBVU0IgaHViIGZvdW5k ClsgICAgMy43MjU5NDddIGh1YiAyLTA6MS4wOiAyIHBvcnRzIGRldGVjdGVkClsgICAgMy43 MjYxODFdIHVoY2lfaGNkIDAwMDA6MDA6MWQuMTogUENJIElOVCBCIC0+IEdTSSAxOSAobGV2 ZWwsIGxvdykgLT4gSVJRIDE5ClsgICAgMy43MjYyODNdIHVoY2lfaGNkIDAwMDA6MDA6MWQu MTogc2V0dGluZyBsYXRlbmN5IHRpbWVyIHRvIDY0ClsgICAgMy43MjYyOTBdIHVoY2lfaGNk IDAwMDA6MDA6MWQuMTogVUhDSSBIb3N0IENvbnRyb2xsZXIKWyAgICAzLjcyNjQ3M10gdWhj aV9oY2QgMDAwMDowMDoxZC4xOiBuZXcgVVNCIGJ1cyByZWdpc3RlcmVkLCBhc3NpZ25lZCBi dXMgbnVtYmVyIDMKWyAgICAzLjcyNjkzNV0gdWhjaV9oY2QgMDAwMDowMDoxZC4xOiBpcnEg MTksIGlvIGJhc2UgMHgwMDAwMjA4MApbICAgIDMuNzI3MDk4XSB1c2IgdXNiMzogTmV3IFVT QiBkZXZpY2UgZm91bmQsIGlkVmVuZG9yPTFkNmIsIGlkUHJvZHVjdD0wMDAxClsgICAgMy43 MjcxOTRdIHVzYiB1c2IzOiBOZXcgVVNCIGRldmljZSBzdHJpbmdzOiBNZnI9MywgUHJvZHVj dD0yLCBTZXJpYWxOdW1iZXI9MQpbICAgIDMuNzI3MzQ1XSB1c2IgdXNiMzogUHJvZHVjdDog VUhDSSBIb3N0IENvbnRyb2xsZXIKWyAgICAzLjcyNzQzN10gdXNiIHVzYjM6IE1hbnVmYWN0 dXJlcjogTGludXggMi42LjM4LXN0ZDIzMS1pNTg2IHVoY2lfaGNkClsgICAgMy43Mjc1MzBd IHVzYiB1c2IzOiBTZXJpYWxOdW1iZXI6IDAwMDA6MDA6MWQuMQpbICAgIDMuNzI3ODM1XSBo dWIgMy0wOjEuMDogVVNCIGh1YiBmb3VuZApbICAgIDMuNzI3OTUxXSBodWIgMy0wOjEuMDog MiBwb3J0cyBkZXRlY3RlZApbICAgIDMuNzI4MTg4XSB1aGNpX2hjZCAwMDAwOjAwOjFkLjI6 IFBDSSBJTlQgQyAtPiBHU0kgMTggKGxldmVsLCBsb3cpIC0+IElSUSAxOApbICAgIDMuNzI4 MjkxXSB1aGNpX2hjZCAwMDAwOjAwOjFkLjI6IHNldHRpbmcgbGF0ZW5jeSB0aW1lciB0byA2 NApbICAgIDMuNzI4Mjk3XSB1aGNpX2hjZCAwMDAwOjAwOjFkLjI6IFVIQ0kgSG9zdCBDb250 cm9sbGVyClsgICAgMy43Mjg0ODVdIHVoY2lfaGNkIDAwMDA6MDA6MWQuMjogbmV3IFVTQiBi dXMgcmVnaXN0ZXJlZCwgYXNzaWduZWQgYnVzIG51bWJlciA0ClsgICAgMy43Mjg5MzJdIHVo Y2lfaGNkIDAwMDA6MDA6MWQuMjogaXJxIDE4LCBpbyBiYXNlIDB4MDAwMDIwNjAKWyAgICAz LjcyOTA5Ml0gdXNiIHVzYjQ6IE5ldyBVU0IgZGV2aWNlIGZvdW5kLCBpZFZlbmRvcj0xZDZi LCBpZFByb2R1Y3Q9MDAwMQpbICAgIDMuNzI5MTg3XSB1c2IgdXNiNDogTmV3IFVTQiBkZXZp Y2Ugc3RyaW5nczogTWZyPTMsIFByb2R1Y3Q9MiwgU2VyaWFsTnVtYmVyPTEKWyAgICAzLjcy OTM0MF0gdXNiIHVzYjQ6IFByb2R1Y3Q6IFVIQ0kgSG9zdCBDb250cm9sbGVyClsgICAgMy43 Mjk0MzJdIHVzYiB1c2I0OiBNYW51ZmFjdHVyZXI6IExpbnV4IDIuNi4zOC1zdGQyMzEtaTU4 NiB1aGNpX2hjZApbICAgIDMuNzI5NTI2XSB1c2IgdXNiNDogU2VyaWFsTnVtYmVyOiAwMDAw OjAwOjFkLjIKWyAgICAzLjcyOTg0MF0gaHViIDQtMDoxLjA6IFVTQiBodWIgZm91bmQKWyAg ICAzLjcyOTk1N10gaHViIDQtMDoxLjA6IDIgcG9ydHMgZGV0ZWN0ZWQKWyAgICAzLjczMDIw Nl0gdWhjaV9oY2QgMDAwMDowMDoxZC4zOiBQQ0kgSU5UIEQgLT4gR1NJIDE2IChsZXZlbCwg bG93KSAtPiBJUlEgMTYKWyAgICAzLjczMDMwOV0gdWhjaV9oY2QgMDAwMDowMDoxZC4zOiBz ZXR0aW5nIGxhdGVuY3kgdGltZXIgdG8gNjQKWyAgICAzLjczMDMxNV0gdWhjaV9oY2QgMDAw MDowMDoxZC4zOiBVSENJIEhvc3QgQ29udHJvbGxlcgpbICAgIDMuNzMwNTE4XSB1aGNpX2hj ZCAwMDAwOjAwOjFkLjM6IG5ldyBVU0IgYnVzIHJlZ2lzdGVyZWQsIGFzc2lnbmVkIGJ1cyBu dW1iZXIgNQpbICAgIDMuNzMwOTMzXSB1aGNpX2hjZCAwMDAwOjAwOjFkLjM6IGlycSAxNiwg aW8gYmFzZSAweDAwMDAyMDQwClsgICAgMy43MzEwOTRdIHVzYiB1c2I1OiBOZXcgVVNCIGRl dmljZSBmb3VuZCwgaWRWZW5kb3I9MWQ2YiwgaWRQcm9kdWN0PTAwMDEKWyAgICAzLjczMTE5 MF0gdXNiIHVzYjU6IE5ldyBVU0IgZGV2aWNlIHN0cmluZ3M6IE1mcj0zLCBQcm9kdWN0PTIs IFNlcmlhbE51bWJlcj0xClsgICAgMy43MzEzNDJdIHVzYiB1c2I1OiBQcm9kdWN0OiBVSENJ IEhvc3QgQ29udHJvbGxlcgpbICAgIDMuNzMxNDM0XSB1c2IgdXNiNTogTWFudWZhY3R1cmVy OiBMaW51eCAyLjYuMzgtc3RkMjMxLWk1ODYgdWhjaV9oY2QKWyAgICAzLjczMTUyOF0gdXNi IHVzYjU6IFNlcmlhbE51bWJlcjogMDAwMDowMDoxZC4zClsgICAgMy43MzE4NDBdIGh1YiA1 LTA6MS4wOiBVU0IgaHViIGZvdW5kClsgICAgMy43MzE5NTddIGh1YiA1LTA6MS4wOiAyIHBv cnRzIGRldGVjdGVkClsgICAgMy43MzI5NDldIGk4MDQyOiBQTlA6IFBTLzIgQ29udHJvbGxl ciBbUE5QMDMwMzpQUzJLXSBhdCAweDYwLDB4NjQgaXJxIDEKWyAgICAzLjczMzA0NV0gaTgw NDI6IFBOUDogUFMvMiBhcHBlYXJzIHRvIGhhdmUgQVVYIHBvcnQgZGlzYWJsZWQsIGlmIHRo aXMgaXMgaW5jb3JyZWN0IHBsZWFzZSBib290IHdpdGggaTgwNDIubm9wbnAKWyAgICAzLjcz MzkyMl0gc2VyaW86IGk4MDQyIEtCRCBwb3J0IGF0IDB4NjAsMHg2NCBpcnEgMQpbICAgIDMu NzM0MjAxXSBtb3VzZWRldjogUFMvMiBtb3VzZSBkZXZpY2UgY29tbW9uIGZvciBhbGwgbWlj ZQpbICAgIDMuNzM0NzQ4XSBydGNfY21vcyAwMDowNzogUlRDIGNhbiB3YWtlIGZyb20gUzQK WyAgICAzLjczNDk4Nl0gcnRjX2Ntb3MgMDA6MDc6IHJ0YyBjb3JlOiByZWdpc3RlcmVkIHJ0 Y19jbW9zIGFzIHJ0YzAKWyAgICAzLjczNTExNF0gcnRjMDogYWxhcm1zIHVwIHRvIG9uZSBt b250aCwgeTNrLCAyNDIgYnl0ZXMgbnZyYW0sIGhwZXQgaXJxcwpbICAgIDMuNzM1NDUxXSBk ZXZpY2UtbWFwcGVyOiB1ZXZlbnQ6IHZlcnNpb24gMS4wLjMKWyAgICAzLjczNTc0NF0gZGV2 aWNlLW1hcHBlcjogaW9jdGw6IDQuMTkuMS1pb2N0bCAoMjAxMS0wMS0wNykgaW5pdGlhbGlz ZWQ6IGRtLWRldmVsQHJlZGhhdC5jb20KWyAgICAzLjczNjAzMl0gY3B1aWRsZTogdXNpbmcg Z292ZXJub3IgbGFkZGVyClsgICAgMy43MzYxMjVdIGNwdWlkbGU6IHVzaW5nIGdvdmVybm9y IG1lbnUKWyAgICAzLjczNjY1OF0gdXNiY29yZTogcmVnaXN0ZXJlZCBuZXcgaW50ZXJmYWNl IGRyaXZlciB1c2JoaWQKWyAgICAzLjczNjc1MF0gdXNiaGlkOiBVU0IgSElEIGNvcmUgZHJp dmVyClsgICAgMy43MzY5MDJdIG5mX2Nvbm50cmFjayB2ZXJzaW9uIDAuNS4wICgxNjM4NCBi dWNrZXRzLCA2NTUzNiBtYXgpClsgICAgMy43MzczMjhdIGlwX3RhYmxlczogKEMpIDIwMDAt MjAwNiBOZXRmaWx0ZXIgQ29yZSBUZWFtClsgICAgMy43Mzc0NDZdIFRDUCBjdWJpYyByZWdp c3RlcmVkClsgICAgMy43Mzc1MzZdIEluaXRpYWxpemluZyBYRlJNIG5ldGxpbmsgc29ja2V0 ClsgICAgMy43Mzc2MzhdIE5FVDogUmVnaXN0ZXJlZCBwcm90b2NvbCBmYW1pbHkgMTcKWyAg ICAzLjczNzc3OF0gUmVnaXN0ZXJpbmcgdGhlIGRuc19yZXNvbHZlciBrZXkgdHlwZQpbICAg IDMuNzM3OTIzXSBVc2luZyBJUEkgTm8tU2hvcnRjdXQgbW9kZQpbICAgIDMuNzM4MjU1XSBQ TTogSGliZXJuYXRpb24gaW1hZ2Ugbm90IHByZXNlbnQgb3IgY291bGQgbm90IGJlIGxvYWRl ZC4KWyAgICAzLjczODI3NV0gcmVnaXN0ZXJlZCB0YXNrc3RhdHMgdmVyc2lvbiAxClsgICAg My43Mzg1MDBdIElNQTogTm8gVFBNIGNoaXAgZm91bmQsIGFjdGl2YXRpbmcgVFBNLWJ5cGFz cyEKWyAgICAzLjczODk2OF0gICBNYWdpYyBudW1iZXI6IDQ6MTk4Ojk5NQpbICAgIDMuNzM5 MTgwXSBydGNfY21vcyAwMDowNzogc2V0dGluZyBzeXN0ZW0gY2xvY2sgdG8gMjAxMi0wNy0x NCAxNjo1ODo1NiBVVEMgKDEzNDIyODUxMzYpClsgICAgMy43Mzk0MjFdIEluaXRhbGl6aW5n IG5ldHdvcmsgZHJvcCBtb25pdG9yIHNlcnZpY2UKWyAgICAzLjc2NzMxOV0gaW5wdXQ6IEFU IFRyYW5zbGF0ZWQgU2V0IDIga2V5Ym9hcmQgYXMgL2RldmljZXMvcGxhdGZvcm0vaTgwNDIv c2VyaW8wL2lucHV0L2lucHV0MwpbICAgIDQuMDA5NjExXSBhdGExOiBTQVRBIGxpbmsgZG93 biAoU1N0YXR1cyAwIFNDb250cm9sIDMwMCkKWyAgICA0LjAyMzU5M10gdXNiIDEtNTogbmV3 IGhpZ2ggc3BlZWQgVVNCIGRldmljZSB1c2luZyBlaGNpX2hjZCBhbmQgYWRkcmVzcyAyClsg ICAgNC4xNDQzNzJdIHVzYiAxLTU6IE5ldyBVU0IgZGV2aWNlIGZvdW5kLCBpZFZlbmRvcj0w ZThkLCBpZFByb2R1Y3Q9MTgwNgpbICAgIDQuMTQ0NDg5XSB1c2IgMS01OiBOZXcgVVNCIGRl dmljZSBzdHJpbmdzOiBNZnI9MSwgUHJvZHVjdD0yLCBTZXJpYWxOdW1iZXI9MwpbICAgIDQu MTQ0NTg2XSB1c2IgMS01OiBQcm9kdWN0OiBNVDE4MDYgClsgICAgNC4xNDQ2NzhdIHVzYiAx LTU6IE1hbnVmYWN0dXJlcjogTWVkaWFUZWsgSW5jClsgICAgNC4xNDQ3NzFdIHVzYiAxLTU6 IFNlcmlhbE51bWJlcjogUkw2WDk3NCAKWyAgICA0LjE1NjQ1Ml0gUmVmaW5lZCBUU0MgY2xv Y2tzb3VyY2UgY2FsaWJyYXRpb246IDE4NjYuNzMyIE1Iei4KWyAgICA0LjE1NjU1MV0gU3dp dGNoaW5nIHRvIGNsb2Nrc291cmNlIHRzYwpbICAgIDQuMjQ5MzY1XSB1c2IgMS04OiBuZXcg aGlnaCBzcGVlZCBVU0IgZGV2aWNlIHVzaW5nIGVoY2lfaGNkIGFuZCBhZGRyZXNzIDMKWyAg ICA0LjMxNDI5OV0gYXRhMjogU0FUQSBsaW5rIGRvd24gKFNTdGF0dXMgMCBTQ29udHJvbCAz MDApClsgICAgNC4zMTQ1MzNdIEZyZWVpbmcgdW51c2VkIGtlcm5lbCBtZW1vcnk6IDYxMDBr IGZyZWVkClsgICAgNC4zMTk0NTldIFdyaXRlIHByb3RlY3RpbmcgdGhlIGtlcm5lbCB0ZXh0 OiA1NzI0awpbICAgIDQuMzE5NjE2XSBXcml0ZSBwcm90ZWN0aW5nIHRoZSBrZXJuZWwgcmVh ZC1vbmx5IGRhdGE6IDIzOTJrClsgICAgNC4zNjU2NDVdIHVzYiAxLTg6IE5ldyBVU0IgZGV2 aWNlIGZvdW5kLCBpZFZlbmRvcj0wOTUxLCBpZFByb2R1Y3Q9MTYwNwpbICAgIDQuMzY1NjUz XSB1c2IgMS04OiBOZXcgVVNCIGRldmljZSBzdHJpbmdzOiBNZnI9MSwgUHJvZHVjdD0yLCBT ZXJpYWxOdW1iZXI9MwpbICAgIDQuMzY1NjU4XSB1c2IgMS04OiBQcm9kdWN0OiBEYXRhVHJh dmVsZXIgMi4wClsgICAgNC4zNjU2NjNdIHVzYiAxLTg6IE1hbnVmYWN0dXJlcjogS2luZ3N0 b24KWyAgICA0LjM2NTY2N10gdXNiIDEtODogU2VyaWFsTnVtYmVyOiA4OTk4MDExNjIwMDgw MTE1MTQyNTlFRUQKWyAgICA1LjAwODEwN10gZTEwMDBlOiBJbnRlbChSKSBQUk8vMTAwMCBO ZXR3b3JrIERyaXZlciAtIDEuMi4yMC1rMgpbICAgIDUuMDA4MTEzXSBlMTAwMGU6IENvcHly aWdodChjKSAxOTk5IC0gMjAxMSBJbnRlbCBDb3Jwb3JhdGlvbi4KWyAgICA1LjAwODE3MV0g ZTEwMDBlIDAwMDA6MDE6MDAuMDogUENJIElOVCBBIC0+IEdTSSAxNiAobGV2ZWwsIGxvdykg LT4gSVJRIDE2ClsgICAgNS4wMDgxOTldIGUxMDAwZSAwMDAwOjAxOjAwLjA6IHNldHRpbmcg bGF0ZW5jeSB0aW1lciB0byA2NApbICAgIDUuMDA4NDc5XSBlMTAwMGUgMDAwMDowMTowMC4w OiBpcnEgNDIgZm9yIE1TSS9NU0ktWApbICAgIDUuMDA4NDg3XSBlMTAwMGUgMDAwMDowMTow MC4wOiBpcnEgNDMgZm9yIE1TSS9NU0ktWApbICAgIDUuMDA4NDkzXSBlMTAwMGUgMDAwMDow MTowMC4wOiBpcnEgNDQgZm9yIE1TSS9NU0ktWApbICAgIDUuMDA4NzAxXSBlMTAwMGUgMDAw MDowMTowMC4wOiBEaXNhYmxpbmcgQVNQTSBMMHMgClsgICAgNS4wMjI0NjRdIEluaXRpYWxp emluZyBVU0IgTWFzcyBTdG9yYWdlIGRyaXZlci4uLgpbICAgIDUuMDI1MTEwXSBzY3NpNCA6 IHVzYi1zdG9yYWdlIDEtNToxLjAKWyAgICA1LjAyNTQ0OF0gc2NzaTUgOiB1c2Itc3RvcmFn ZSAxLTg6MS4wClsgICAgNS4wMjU3NDddIHVzYmNvcmU6IHJlZ2lzdGVyZWQgbmV3IGludGVy ZmFjZSBkcml2ZXIgdXNiLXN0b3JhZ2UKWyAgICA1LjAyNTc1MV0gVVNCIE1hc3MgU3RvcmFn ZSBzdXBwb3J0IHJlZ2lzdGVyZWQuClsgICAgNS4wOTM4NTZdIGUxMDAwZSAwMDAwOjAxOjAw LjA6IGV0aDA6IChQQ0kgRXhwcmVzczoyLjVHQi9zOldpZHRoIHgxKSAwMDoyMjo0ZDo3YTpi YzphMApbICAgIDUuMDkzODY0XSBlMTAwMGUgMDAwMDowMTowMC4wOiBldGgwOiBJbnRlbChS KSBQUk8vMTAwMCBOZXR3b3JrIENvbm5lY3Rpb24KWyAgICA1LjA5Mzg4M10gZTEwMDBlIDAw MDA6MDE6MDAuMDogZXRoMDogTUFDOiAzLCBQSFk6IDgsIFBCQSBObzogRkZGRkZGLTBGRgpb ICAgIDYuMDI1MzkwXSBzY3NpIDU6MDowOjA6IERpcmVjdC1BY2Nlc3MgICAgIEtpbmdzdG9u IERhdGFUcmF2ZWxlciAyLjAgMS4wMCBQUTogMCBBTlNJOiAyClsgICAgNi4wMjYzNzZdIHNj c2kgNDowOjA6MDogQ0QtUk9NICAgICAgICAgICAgVFNTVGNvcnAgQ0REVkRXIFNFLTIwOEFC ICBUUzAwIFBROiAwIEFOU0k6IDAKWyAgICA2LjAzNjM1NF0gc3IwOiBzY3NpMy1tbWMgZHJp dmU6IDI0eC8yNHggd3JpdGVyIGR2ZC1yYW0gY2QvcncgeGEvZm9ybTIgY2RkYSB0cmF5Clsg ICAgNi4wMzYzNjJdIGNkcm9tOiBVbmlmb3JtIENELVJPTSBkcml2ZXIgUmV2aXNpb246IDMu MjAKWyAgICA2LjAzNjY2M10gc3IgNDowOjA6MDogQXR0YWNoZWQgc2NzaSBDRC1ST00gc3Iw ClsgICAgNi4wMzY4MzVdIHNyIDQ6MDowOjA6IEF0dGFjaGVkIHNjc2kgZ2VuZXJpYyBzZzAg dHlwZSA1ClsgICAgNi4wMzc1NTRdIHNkIDU6MDowOjA6IEF0dGFjaGVkIHNjc2kgZ2VuZXJp YyBzZzEgdHlwZSAwClsgICAgNi4wMzgxMjBdIHNkIDU6MDowOjA6IFtzZGFdIDE1NzY5NjAw IDUxMi1ieXRlIGxvZ2ljYWwgYmxvY2tzOiAoOC4wNyBHQi83LjUxIEdpQikKWyAgICA2LjAz OTQzNl0gc2QgNTowOjA6MDogW3NkYV0gV3JpdGUgUHJvdGVjdCBpcyBvZmYKWyAgICA2LjAz OTQ0NF0gc2QgNTowOjA6MDogW3NkYV0gTW9kZSBTZW5zZTogMjMgMDAgMDAgMDAKWyAgICA2 LjAzOTQ0OV0gc2QgNTowOjA6MDogW3NkYV0gQXNzdW1pbmcgZHJpdmUgY2FjaGU6IHdyaXRl IHRocm91Z2gKWyAgICA2LjA0Mzk5MF0gc2QgNTowOjA6MDogW3NkYV0gQXNzdW1pbmcgZHJp dmUgY2FjaGU6IHdyaXRlIHRocm91Z2gKWyAgICA2LjA0NDc2N10gIHNkYTogc2RhMQpbICAg IDYuMDQ2NjEyXSBzZCA1OjA6MDowOiBbc2RhXSBBc3N1bWluZyBkcml2ZSBjYWNoZTogd3Jp dGUgdGhyb3VnaApbICAgIDYuMDQ2NjIwXSBzZCA1OjA6MDowOiBbc2RhXSBBdHRhY2hlZCBT Q1NJIHJlbW92YWJsZSBkaXNrClsgICAxMC41MTE4NTNdIG1kOiBsaW5lYXIgcGVyc29uYWxp dHkgcmVnaXN0ZXJlZCBmb3IgbGV2ZWwgLTEKWyAgIDEwLjUxNzE1MV0gbWQ6IG11bHRpcGF0 aCBwZXJzb25hbGl0eSByZWdpc3RlcmVkIGZvciBsZXZlbCAtNApbICAgMTAuNTIxNzQ0XSBt ZDogcmFpZDAgcGVyc29uYWxpdHkgcmVnaXN0ZXJlZCBmb3IgbGV2ZWwgMApbICAgMTAuNTI5 ODExXSBtZDogcmFpZDEgcGVyc29uYWxpdHkgcmVnaXN0ZXJlZCBmb3IgbGV2ZWwgMQpbICAg MTAuNTM0MTc2XSBhc3luY190eDogYXBpIGluaXRpYWxpemVkIChhc3luYykKWyAgIDEwLjUz Njk1OV0geG9yOiBhdXRvbWF0aWNhbGx5IHVzaW5nIGJlc3QgY2hlY2tzdW1taW5nIGZ1bmN0 aW9uOiBwSUlJX3NzZQpbICAgMTAuNTQxMDA0XSAgICBwSUlJX3NzZSAgOiAgNTY0NC4wMDAg TUIvc2VjClsgICAxMC41NDEwMDldIHhvcjogdXNpbmcgZnVuY3Rpb246IHBJSUlfc3NlICg1 NjQ0LjAwMCBNQi9zZWMpClsgICAxMC41NjI5ODhdIHJhaWQ2OiBpbnQzMngxICAgIDIwNyBN Qi9zClsgICAxMC41ODAwOTZdIHJhaWQ2OiBpbnQzMngyICAgIDMwMCBNQi9zClsgICAxMC41 OTcxMzhdIHJhaWQ2OiBpbnQzMng0ICAgIDMyMCBNQi9zClsgICAxMC42MTQxMDVdIHJhaWQ2 OiBpbnQzMng4ICAgIDMyNCBNQi9zClsgICAxMC42MzEwMDddIHJhaWQ2OiBtbXh4MSAgICAg IDQxNyBNQi9zClsgICAxMC42NDc5MjJdIHJhaWQ2OiBtbXh4MiAgICAgIDc2OSBNQi9zClsg ICAxMC42NjUwMjNdIHJhaWQ2OiBzc2UxeDEgICAgIDMzOSBNQi9zClsgICAxMC42ODE5NjFd IHJhaWQ2OiBzc2UxeDIgICAgIDU3OCBNQi9zClsgICAxMC42OTg5MThdIHJhaWQ2OiBzc2Uy eDEgICAgIDY3MSBNQi9zClsgICAxMC43MTU4NzRdIHJhaWQ2OiBzc2UyeDIgICAgMTE0NCBN Qi9zClsgICAxMC43MTU4NzhdIHJhaWQ2OiB1c2luZyBhbGdvcml0aG0gc3NlMngyICgxMTQ0 IE1CL3MpClsgICAxMC43MzM3NjhdIG1kOiByYWlkNiBwZXJzb25hbGl0eSByZWdpc3RlcmVk IGZvciBsZXZlbCA2ClsgICAxMC43MzM3NzRdIG1kOiByYWlkNSBwZXJzb25hbGl0eSByZWdp c3RlcmVkIGZvciBsZXZlbCA1ClsgICAxMC43MzM3NzhdIG1kOiByYWlkNCBwZXJzb25hbGl0 eSByZWdpc3RlcmVkIGZvciBsZXZlbCA0ClsgICAxMC43NDc1OTFdIG1kOiByYWlkMTAgcGVy c29uYWxpdHkgcmVnaXN0ZXJlZCBmb3IgbGV2ZWwgMTAKWyAgIDE0LjMwODUyNF0gSVNPIDk2 NjAgRXh0ZW5zaW9uczogTWljcm9zb2Z0IEpvbGlldCBMZXZlbCAzClsgICAxNC4zNjYzMzJd IElTT0ZTOiBjaGFuZ2luZyB0byBzZWNvbmRhcnkgcm9vdApbICAgMTUuMDQxOTEwXSBVREYt ZnM6IE5vIHBhcnRpdGlvbiBmb3VuZCAoMSkKWyAgIDE1LjE1NTkzOV0gTlRGUyB2b2x1bWUg dmVyc2lvbiAzLjEuClsgICAxNS4yODAxODhdIE5URlMgdm9sdW1lIHZlcnNpb24gMy4xLgpb ICAgMTUuMjg3NDk3XSBhdWZzIHRlc3RfYWRkOjI2Mjptb3VudFszNThdOiB1aWQvZ2lkL3Bl cm0gL3NxdWFzaGZzIDAvMC8wNzU1LCAwLzAvMDE3NzcKWyAgIDE1LjI5MDkzNV0gYXVmcyB0 ZXN0X2FkZDoyNjI6bW91bnRbMzYzXTogdWlkL2dpZC9wZXJtIC9ib290IDAvMC8wNTU1LCAw LzAvMDE3NzcKWyAgIDMxLjAyNDMzMV0gdWRldls3MjZdOiBzdGFydGluZyB2ZXJzaW9uIDE2 NApbICAgMzEuOTQ0NTgwXSBpVENPX3ZlbmRvcl9zdXBwb3J0OiB2ZW5kb3Itc3VwcG9ydD0w ClsgICAzMy42OTQzMDddIGlUQ09fd2R0OiBJbnRlbCBUQ08gV2F0Y2hEb2cgVGltZXIgRHJp dmVyIHYxLjA2ClsgICAzMy42OTU0MDNdIGlUQ09fd2R0OiBGb3VuZCBhIE5NMTAgVENPIGRl dmljZSAoVmVyc2lvbj0yLCBUQ09CQVNFPTB4MDQ2MCkKWyAgIDMzLjY5NjM1MF0gaVRDT193 ZHQ6IGluaXRpYWxpemVkLiBoZWFydGJlYXQ9MzAgc2VjIChub3dheW91dD0wKQpbICAgMzMu ODY2MTkzXSBwYXJwb3J0X3BjIDAwOjA5OiByZXBvcnRlZCBieSBQbHVnIGFuZCBQbGF5IEFD UEkKWyAgIDMzLjg2NjI1Ml0gcGFycG9ydDA6IFBDLXN0eWxlIGF0IDB4Mzc4LCBpcnEgNyBb UENTUFAsVFJJU1RBVEVdClsgICAzNC4zOTY5ODddIGk4MDFfc21idXMgMDAwMDowMDoxZi4z OiBQQ0kgSU5UIEIgLT4gR1NJIDE5IChsZXZlbCwgbG93KSAtPiBJUlEgMTkKWyAgIDM0LjQw MDI2MV0gcHBkZXY6IHVzZXItc3BhY2UgcGFyYWxsZWwgcG9ydCBkcml2ZXIKWyAgIDQ1Ljk0 NzMzOV0gZTEwMDBlOiBldGgwIE5JQyBMaW5rIGlzIFVwIDEwMCBNYnBzIEZ1bGwgRHVwbGV4 LCBGbG93IENvbnRyb2w6IE5vbmUKWyAgIDQ1Ljk0NzM0OV0gZTEwMDBlIDAwMDA6MDE6MDAu MDogZXRoMDogMTAvMTAwIHNwZWVkOiBkaXNhYmxpbmcgVFNPClsgICA0OS4wMTkyOTddIE5F VDogUmVnaXN0ZXJlZCBwcm90b2NvbCBmYW1pbHkgMTAKWyAgIDQ5LjA0OTY0MF0gc3NoZCAo MTE5Nik6IC9wcm9jLzExOTYvb29tX2FkaiBpcyBkZXByZWNhdGVkLCBwbGVhc2UgdXNlIC9w cm9jLzExOTYvb29tX3Njb3JlX2FkaiBpbnN0ZWFkLgpbICAgNTEuOTg1NTQ4XSBtZDogQXV0 b2RldGVjdGluZyBSQUlEIGFycmF5cy4KWyAgIDUxLjk4NTU1NF0gbWQ6IFNjYW5uZWQgMCBh bmQgYWRkZWQgMCBkZXZpY2VzLgpbICAgNTEuOTg1NTU4XSBtZDogYXV0b3J1biAuLi4KWyAg IDUxLjk4NTU2MV0gbWQ6IC4uLiBhdXRvcnVuIERPTkUuClsgICA1OS45ODIxODhdIGV0aDA6 IG5vIElQdjYgcm91dGVycyBwcmVzZW50Cg== --------------040808090609000001010409 Content-Type: text/plain; charset=windows-1250; name="lspci.txt" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="lspci.txt" MDA6MDAuMCBIb3N0IGJyaWRnZTogSW50ZWwgQ29ycG9yYXRpb24gQ2VkYXJ2aWV3IERSQU0g Q29udHJvbGxlciAocmV2IDAzKQowMDowMi4wIFZHQSBjb21wYXRpYmxlIGNvbnRyb2xsZXI6 IEludGVsIENvcnBvcmF0aW9uIENlZGFydmlldyBJbnRlZ3JhdGVkIEdyYXBoaWNzIENvbnRy b2xsZXIgKHJldiAwOSkKMDA6MWIuMCBBdWRpbyBkZXZpY2U6IEludGVsIENvcnBvcmF0aW9u IE4xMC9JQ0ggNyBGYW1pbHkgSGlnaCBEZWZpbml0aW9uIEF1ZGlvIENvbnRyb2xsZXIgKHJl diAwMikKMDA6MWMuMCBQQ0kgYnJpZGdlOiBJbnRlbCBDb3Jwb3JhdGlvbiBOMTAvSUNIIDcg RmFtaWx5IFBDSSBFeHByZXNzIFBvcnQgMSAocmV2IDAyKQowMDoxZC4wIFVTQiBDb250cm9s bGVyOiBJbnRlbCBDb3Jwb3JhdGlvbiBOMTAvSUNIIDcgRmFtaWx5IFVTQiBVSENJIENvbnRy b2xsZXIgIzEgKHJldiAwMikKMDA6MWQuMSBVU0IgQ29udHJvbGxlcjogSW50ZWwgQ29ycG9y YXRpb24gTjEwL0lDSCA3IEZhbWlseSBVU0IgVUhDSSBDb250cm9sbGVyICMyIChyZXYgMDIp CjAwOjFkLjIgVVNCIENvbnRyb2xsZXI6IEludGVsIENvcnBvcmF0aW9uIE4xMC9JQ0ggNyBG YW1pbHkgVVNCIFVIQ0kgQ29udHJvbGxlciAjMyAocmV2IDAyKQowMDoxZC4zIFVTQiBDb250 cm9sbGVyOiBJbnRlbCBDb3Jwb3JhdGlvbiBOMTAvSUNIIDcgRmFtaWx5IFVTQiBVSENJIENv bnRyb2xsZXIgIzQgKHJldiAwMikKMDA6MWQuNyBVU0IgQ29udHJvbGxlcjogSW50ZWwgQ29y cG9yYXRpb24gTjEwL0lDSCA3IEZhbWlseSBVU0IyIEVIQ0kgQ29udHJvbGxlciAocmV2IDAy KQowMDoxZS4wIFBDSSBicmlkZ2U6IEludGVsIENvcnBvcmF0aW9uIDgyODAxIE1vYmlsZSBQ Q0kgQnJpZGdlIChyZXYgZTIpCjAwOjFmLjAgSVNBIGJyaWRnZTogSW50ZWwgQ29ycG9yYXRp b24gTk0xMCBGYW1pbHkgTFBDIENvbnRyb2xsZXIgKHJldiAwMikKMDA6MWYuMiBTQVRBIGNv bnRyb2xsZXI6IEludGVsIENvcnBvcmF0aW9uIE4xMC9JQ0g3IEZhbWlseSBTQVRBIEFIQ0kg Q29udHJvbGxlciAocmV2IDAyKQowMDoxZi4zIFNNQnVzOiBJbnRlbCBDb3Jwb3JhdGlvbiBO MTAvSUNIIDcgRmFtaWx5IFNNQnVzIENvbnRyb2xsZXIgKHJldiAwMikKMDE6MDAuMCBFdGhl cm5ldCBjb250cm9sbGVyOiBJbnRlbCBDb3Jwb3JhdGlvbiA4MjU3NEwgR2lnYWJpdCBOZXR3 b3JrIENvbm5lY3Rpb24K --------------040808090609000001010409 Content-Type: text/plain; charset=windows-1250; name="uname.txt" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="uname.txt" TGludXggc3lzcmVzY2NkIDIuNi4zOC1zdGQyMzEtaTU4NiAjMiBTTVAgVHVlIEF1ZyAyMyAx Nzo0Njo1OSBVVEMgMjAxMSBpNjg2IEludGVsKFIpIEF0b20oVE0pIENQVSBEMjUwMCBAIDEu ODZHSHogR2VudWluZUludGVsIEdOVS9MaW51eAo= --------------040808090609000001010409-- From owner-freebsd-stable@FreeBSD.ORG Sat Jul 14 16:28:02 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id B50A11065670 for ; Sat, 14 Jul 2012 16:28:02 +0000 (UTC) (envelope-from marek_sal@wp.pl) Received: from mx4.wp.pl (mx4.wp.pl [212.77.101.8]) by mx1.freebsd.org (Postfix) with ESMTP id 3A79E8FC0A for ; Sat, 14 Jul 2012 16:28:01 +0000 (UTC) Received: (wp-smtpd smtp.wp.pl 14925 invoked from network); 14 Jul 2012 18:28:00 +0200 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=wp.pl; s=1024a; t=1342283280; bh=le+UGMApOK6TeZluC3enWSy0LFs4adYWJeoKQIQ/BVc=; h=From:To:Subject; b=X1dDO/fC/yNTHE9RU50Pr3/RMLGU/JGTR0sumdsbQSQBF3P2NHwP9BLIDW7UWnE+6 TpG20xXAKX+eFpvZmyfkFibSD4qDMDYmIfb8Oqq9zdMd0WT0wkMhfBGO08fdTXKHJg gjq6P/QaVHjW+irDLsxwomv0MMzNIfiP8sfpmgIg= Received: from nat.misal.pl (HELO [127.0.0.1]) (marek_sal@[83.19.131.171]) (envelope-sender ) by smtp.wp.pl (WP-SMTPD) with AES256-SHA encrypted SMTP for ; 14 Jul 2012 18:28:00 +0200 Message-ID: <50019E0B.9090907@wp.pl> Date: Sat, 14 Jul 2012 18:27:55 +0200 From: Marek Salwerowicz User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 MIME-Version: 1.0 To: Schaich Alonso , freebsd-stable@freebsd.org References: <50017400.3030702@wp.pl> <201207141336.05406.alonsoschaich@fastmail.fm> <50018B54.7060006@wp.pl> In-Reply-To: <50018B54.7060006@wp.pl> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 120714-1, 2012-07-14), Outbound message X-Antivirus-Status: Clean X-WP-AV: skaner antywirusowy poczty Wirtualnej Polski S. A. X-WP-SPAM: NO 0000000 [8eM0] Cc: Subject: Re: video issue - Intel Atom based motherboard D2500HN X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 14 Jul 2012 16:28:02 -0000 W dniu 2012-07-14 17:08, Marek Salwerowicz pisze: > Yes, I've successfully booted System Rescue CD (based on Gentoo Linux) > 2.3.1 > Uname, dmesg and lspci are attached. > > Right now I am trying to install Debian i386 into USB stick (the > installer works fine) Installation went fine, although it took a lot of time (maybe because of poor USB stick performance) I've downloaded the i386 ISO of FreeBSD 9 (previously I was using the amd64) - and it works better, but not very good (at least I am able to install the OS into USB stick): http://img339.imageshack.us/img339/6589/20120714394.jpg -- Marek From owner-freebsd-stable@FreeBSD.ORG Sat Jul 14 18:54:23 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 39F23106564A for ; Sat, 14 Jul 2012 18:54:23 +0000 (UTC) (envelope-from neveld@davidnevel.org) Received: from jenny.davidnevel.org (davidnevel.org [74.218.212.237]) by mx1.freebsd.org (Postfix) with ESMTP id 03BD48FC0A for ; Sat, 14 Jul 2012 18:54:22 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by jenny.davidnevel.org (Postfix) with SMTP id D84AE558 for ; Sat, 14 Jul 2012 14:46:21 -0400 (EDT) Received: from jenny.davidnevel.org (localhost [127.0.0.1]) by jenny.davidnevel.org (Postfix) with ESMTP id 3CB44557; Sat, 14 Jul 2012 14:46:21 -0400 (EDT) Received: from localhost (jenny.davidnevel.org [192.168.0.19]) by jenny.davidnevel.org (Postfix) with ESMTP id B2049556; Sat, 14 Jul 2012 14:46:20 -0400 (EDT) Received: from 192.168.3.11 ([192.168.3.11]) by www.davidnevel.org (Horde Framework) with HTTP; Sat, 14 Jul 2012 14:46:20 -0400 Date: Sat, 14 Jul 2012 14:46:20 -0400 Message-ID: <20120714144620.Horde.xZL3a8236L1QAb58Bg-zS3A@www.davidnevel.org> From: David Nevel To: Marek Salwerowicz References: <50017400.3030702@wp.pl> <201207141336.05406.alonsoschaich@fastmail.fm> <50018B54.7060006@wp.pl> <50019E0B.9090907@wp.pl> In-Reply-To: <50019E0B.9090907@wp.pl> User-Agent: Internet Messaging Program (IMP) H4 (5.0.21) Content-Type: text/plain; charset=ISO-8859-1; format=flowed; DelSp=Yes MIME-Version: 1.0 Content-Disposition: inline X-Virus-Scanned: ClamAV using ClamSMTP Cc: freebsd-stable@freebsd.org Subject: Re: video issue - Intel Atom based motherboard D2500HN X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 14 Jul 2012 18:54:23 -0000 Quoting Marek Salwerowicz : > W dniu 2012-07-14 17:08, Marek Salwerowicz pisze: > >> Yes, I've successfully booted System Rescue CD (based on Gentoo Linux) 2.3.1 >> Uname, dmesg and lspci are attached. >> >> Right now I am trying to install Debian i386 into USB stick (the >> installer works fine) > > Installation went fine, although it took a lot of time (maybe > because of poor USB stick performance) > > I've downloaded the i386 ISO of FreeBSD 9 (previously I was using > the amd64) - and it works better, but not very good (at least I am > able to install the OS into USB stick): > > http://img339.imageshack.us/img339/6589/20120714394.jpg > > -- > Marek > > > _______________________________________________ > 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" Hi Marek, You might try the workaround suggested in kern/166262 (http://www.freebsd.org/cgi/query-pr.cgi?pr=166262&cat=). I believe the DN2800MT uses the same (or similar) video. -- Pretend there's a witty signature here. From owner-freebsd-stable@FreeBSD.ORG Sat Jul 14 20:00:37 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 3AE0A106566B for ; Sat, 14 Jul 2012 20:00:37 +0000 (UTC) (envelope-from wblock@wonkity.com) Received: from wonkity.com (wonkity.com [67.158.26.137]) by mx1.freebsd.org (Postfix) with ESMTP id B1BD18FC08 for ; Sat, 14 Jul 2012 20:00:36 +0000 (UTC) Received: from wonkity.com (localhost [127.0.0.1]) by wonkity.com (8.14.5/8.14.5) with ESMTP id q6EK0Zdc061013; Sat, 14 Jul 2012 14:00:35 -0600 (MDT) (envelope-from wblock@wonkity.com) Received: from localhost (wblock@localhost) by wonkity.com (8.14.5/8.14.5/Submit) with ESMTP id q6EK0Z2H061010; Sat, 14 Jul 2012 14:00:35 -0600 (MDT) (envelope-from wblock@wonkity.com) Date: Sat, 14 Jul 2012 14:00:35 -0600 (MDT) From: Warren Block To: Marek Salwerowicz In-Reply-To: <50017400.3030702@wp.pl> Message-ID: References: <50017400.3030702@wp.pl> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (wonkity.com [127.0.0.1]); Sat, 14 Jul 2012 14:00:36 -0600 (MDT) Cc: freebsd-stable@freebsd.org Subject: Re: video issue - Intel Atom based motherboard D2500HN X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 14 Jul 2012 20:00:37 -0000 On Sat, 14 Jul 2012, Marek Salwerowicz wrote: > I recently bought a Intel D2500HN motherboard with Intel GMA 3600 video card. > I want to install FreeBSD 9-Release on it via PXE, but after booting the > system, it seems that video card driver doesn't work properly. > > Have a look at this picture: > http://img703.imageshack.us/img703/5648/20120714393.jpg > > I've tried the > # vidcontrol 80x25 > > but unfortunately it doesn't help. > > Do you have any idea how to deal with taht graphics? Did you try the changes mentioned here? http://lists.freebsd.org/pipermail/freebsd-current/2012-July/035366.html