From owner-freebsd-stable@FreeBSD.ORG Sun Jan 24 00:20:55 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A319A1065670 for ; Sun, 24 Jan 2010 00:20:55 +0000 (UTC) (envelope-from oberman@es.net) Received: from mailgw.es.net (mail2.es.net [IPv6:2001:400:107:1::2]) by mx1.freebsd.org (Postfix) with ESMTP id 8C7398FC0C for ; Sun, 24 Jan 2010 00:20:55 +0000 (UTC) Received: from ptavv.es.net (ptavv.es.net [IPv6:2001:400:910::29]) by mailgw.es.net (8.14.3/8.14.3) with ESMTP id o0O0KsCJ018929 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sat, 23 Jan 2010 16:20:55 -0800 Received: from ptavv.es.net (localhost [127.0.0.1]) by ptavv.es.net (Tachyon Server) with ESMTP id BACFC1CC13; Sat, 23 Jan 2010 16:20:54 -0800 (PST) To: Steven Friedrich In-reply-to: Your message of "Fri, 22 Jan 2010 22:20:30 EST." <201001222220.31040.freebsd@insightbb.com> Date: Sat, 23 Jan 2010 16:20:54 -0800 From: "Kevin Oberman" Message-Id: <20100124002054.BACFC1CC13@ptavv.es.net> X-Proofpoint-Virus-Version: vendor=fsecure engine=1.12.8161:2.4.5, 1.2.40, 4.0.166 definitions=2010-01-23_03:2010-01-20, 2010-01-23, 2010-01-23 signatures=0 X-Proofpoint-Spam-Reason: safe Cc: freebsd-stable@freebsd.org Subject: Re: 8.0-RELEASE -> -STABLE and size of / X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Jan 2010 00:20:55 -0000 > From: Steven Friedrich > Date: Fri, 22 Jan 2010 22:20:30 -0500 > Sender: owner-freebsd-stable@freebsd.org > > On Friday 22 January 2010 06:32:02 pm Oliver Brandmueller wrote: > > Hi, > > > > On Fri, Jan 22, 2010 at 03:56:31PM -0500, Steven Friedrich wrote: > > > in your /etc/make.conf, do you have a line like: > > > makeoptions DEBUG=-g > > > if so, comment it out. > > > > The GENEREIC kernel by default has the following config: > > > > makeoptions DEBUG=-g # Build kernel with gdb(1) debug > > symbols > > > > You don't need anything special in your make.conf > > > > In fact having the debug symbols is useful in many cases. So raising the > > default size for the / partition might be the better option (OK, doesn't > > help for already installed systems of course). > > > > - Oliver > > > I'm sorry. My response to him should have been more precise. > I was trying to clue him in on how to build a non-debug kernel, but my > answer was in fact wrong. > I said he may have a line in make.conf, but that was a mistake. I > pulled the line from a kernel config file. > If he wants to build a kernel with no symbols, as he stated he does, > he needs to comment out the line and build a kernel. Could buildworld > and installworld, too. > But he and I went off topic. I should have changed the subject line to > start a new thread to discuss building without symbols. He was > complaining that it wasn't in the FAQ or the handbook. It's in > GENERIC, which is required reading if you're ever going to build > custom kernels. > > As for the main topic, I have been making 4GB root partitions for some time. > Our disk requirements have been soaring over the last decade, while cost per > MB have plummeted. I don't want to have to guess what sizes each partition > should be. Just for the record and to avoid further confusion, building a kernel with debug symbols does not take any more space in root. Another copy of the kernel is built but not installed into /kernel. The copy of the kernel in /kernel is always symbol-less. Also, at the start of this thread, the OP said that he did a buildkernel and a buildworld. This is broken and may produce a non-bootable kernel. Always buildworld and then buildkernel so that the new toolchain is used to build the kernel. (This also has nothing to do with the original issue of the amount of space in the root partition being too small for amd64 systems, but I am hoping to avoid future issues.) -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: oberman@es.net Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751 From owner-freebsd-stable@FreeBSD.ORG Sun Jan 24 01:19:12 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 70301106568D for ; Sun, 24 Jan 2010 01:19:12 +0000 (UTC) (envelope-from linimon@lonesome.com) Received: from mail.soaustin.net (lefty.soaustin.net [66.135.55.46]) by mx1.freebsd.org (Postfix) with ESMTP id 50E408FC08 for ; Sun, 24 Jan 2010 01:19:12 +0000 (UTC) Received: by mail.soaustin.net (Postfix, from userid 502) id 09DB98C07E; Sat, 23 Jan 2010 19:19:12 -0600 (CST) Date: Sat, 23 Jan 2010 19:19:12 -0600 From: Mark Linimon To: Adam Vande More Message-ID: <20100124011911.GA22882@lonesome.com> References: <20100123004003.GA97111@icarus.home.lan> <6201873e1001221720m294c3f09tcf6ba88a94fdbfba@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <6201873e1001221720m294c3f09tcf6ba88a94fdbfba@mail.gmail.com> User-Agent: Mutt/1.5.18 (2008-05-17) Cc: freebsd-stable@freebsd.org, Jeremy Chadwick Subject: Re: posting coding bounties, appropriate money amounts? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 24 Jan 2010 01:19:12 -0000 On Fri, Jan 22, 2010 at 07:20:18PM -0600, Adam Vande More wrote: > > I'd be willing to put up a thousand USD or possibly more depending on > > what sort of work was being considered. I suppose a better choice would > > be for someone here to make a list of issues which the community feels > > need attention, and put the pooled donations to whatever things had > > highest priority -- or, if that isn't plausible, then to what interested > > developers wanted to work on. > > To the best of my understanding, that is basically what donating to the > FreeBSD Foundation accomplishes, although it would be nice so see some more > transparency in their decision making process. As stated earlier in this thread, for tax reasons the Foundation can't be in a position to "pass through" specific funds targeted to specific projects. IMHO there's plenty of room for experimenting with different ways to get projects funded, especially for "small specific task xyz needed". I can't really one of the people to try to set up such things, since I want to be one of the people taking advantage of it. A good first task would be for someone (TM) to put up a web page for "tasks that the community would be willing to fund", with a sign-up sheet for volunteer donors, to gauge general interest in # of people who would be willing to contribute to particular tasks. mcl From owner-freebsd-stable@FreeBSD.ORG Sun Jan 24 01:22:11 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EE9C81065692 for ; Sun, 24 Jan 2010 01:22:11 +0000 (UTC) (envelope-from sam@errno.com) Received: from ebb.errno.com (ebb.errno.com [69.12.149.25]) by mx1.freebsd.org (Postfix) with ESMTP id AB2BA8FC08 for ; Sun, 24 Jan 2010 01:22:11 +0000 (UTC) Received: from Macintosh-4.local ([10.0.0.195]) (authenticated bits=0) by ebb.errno.com (8.13.6/8.12.6) with ESMTP id o0O1MAHf026085 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 23 Jan 2010 17:22:10 -0800 (PST) (envelope-from sam@errno.com) Message-ID: <4B5BA0C1.8010901@errno.com> Date: Sat, 23 Jan 2010 17:22:09 -0800 From: Sam Leffler Organization: Errno Consulting User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: Russell Yount References: <4B521FC2.4050402@errno.com> <4B535AAE.3060308@errno.com> In-Reply-To: X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-DCC-sonic.net-Metrics: ebb.errno.com; whitelist Cc: freebsd-stable@freebsd.org Subject: Re: atheros broadcast/multicast corruption with multiple hostap's X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 24 Jan 2010 01:22:12 -0000 Russell Yount wrote: > On Sun, Jan 17, 2010 at 1:45 PM, Sam Leffler > wrote: > > Russell Yount wrote: > > > > On Sat, Jan 16, 2010 at 3:21 PM, Sam Leffler >> wrote: > > Russell Yount wrote: > > It seems AP to client broadcasts/multicasts traffic is > broken when using WPA2/802.11i with multiple hostapds in 8.0. > > Only the SSID associated with the last hostapd to be > started has > AP to client broadcasts/multicasts being delivered correctly. > > The AP and client are 8.0 freebsd systems althought I see > same > problems with windows XP as a client. > > The AP has 4 hostapds configured to use TLS with client > certificates for > authentication. (hostapd recompiled with > HOSTAPD_CFLAGS=-DEAP_SERVER) > The AP and client radio are shown as ath0: AR5212 mac 5.9 > RF5112 > phy 4.3 > in dmesg. > > Client authenticate using client certificates associate > correctly > to all 4 SSIDs. Unicast traffic flows correctly between > clients > and AP > for all for 4 SSIDs. Client to AP broadcast/multicast > traffic works > on of 4 SSIDs. AP to client broadcast/multicast traffic > only works > on 1 of the SSIDs. I have documented this using ARP > broadcasts, > but normal IP broadcasts also observed to corrupted. > > When an ARP request is send through the AP to an > associated client > it seems to be trashed on any of the SSID except the one > associated > with the last hostapd to be started. Here is the output of > client side > tcpdump showing the problems. > > In the first client side tcpdump with the hostapd associated > with the SSID > being associaed with the last hostapd started and the traffic > flowing > normally. > > In the second client side tcpdump with the hostapd associated > with the SSID > being not the last hostapd started the ARP request is resent > multiple times > and appears corrupted. > > I would really like to find a fix for this. > Any help would be greatly appreciated. > > > This sounds like the crypto encap of the frame is clobbering the > mbuf contents. You can verify this by setting up multiple > vaps w/o > WPA. If this is the problem look for the mbuf copy logic for > mcast > frames and make sure a deep copy is done. > > Sam > > The four VAPs broadcast traffic works find without WPA if I > do not start hostapds on them > I have been trying to discovery why broadcast traffic only > works correctly on the VAP associated with the last hostapd to > be started. I have move with VAP has the working broadcast > traffic by restarting the hostapd > associated with it. > It would seem something in the WPA/802.1x layer initialization > remembers which hostapd was started last and that affected the > crypto encap. > I keep looking but do not see any place in the code that could > account for this. > It seems the corrupt crypto encap also happens on broadcast > between stations. > Please correct me if I am wrong: > but when using hostapd normally traffic is bridged withing the card. > So if a station sends to the VAP a broadcast it is actaully > sending a non- broadcast frame to the AP > and the AP sends the frame to all the other stations. > > > I told you waht the likely problem is. Look in the net80211 layer > in the kernel for the problem. > > Sam > > > > > I tried to find problems in mbuf corruption > in ieee80211_output.c by placing > > m = m_unshare(m,M_NOWAIT); > if (m == NULL) { > IEEE80211_DPRINTF(vap, IEEE80211_MSG_OUTPUT, > "%s: cannot get writable mbuf\n", __func__); > return NULL; > } > > at begining ieee80211_mbuf_adjust() and at > beginning of ieee80211_encap() with no change > in the broadcast traffic behaviour. > > I tried then to in ieee80211_crypto.c substituting > > flags |= IEEE80211_KEY_SWCRYPT; > > for the encryption capabilities test code > > if ((ic->ic_cryptocaps & (1< IEEE80211_DPRINTF(vap, IEEE80211_MSG_CRYPTO, > "%s: no h/w support for cipher %s, falling back to s/w\n", > __func__, cip->ic_name); > flags |= IEEE80211_KEY_SWCRYPT; > } > > to force all the encryption to be done in software. > > This fixed the broadcast traffic problem but without > hardware support its very slow and really loads machine. > Enabling in the debug code to ath and net80211 > > and enabled ATH_DEBUG_KEYCACHE in if_ath.c and > IEEE80211_MSG_CRYPTO in net80211 code. > > It seems that all the VAPS sets the broadcast key for > mac ff:ff:ff:ff:ff:ff in the ath device so I assume > they conflict and the last one setting the key is the > working one; that would explain why the last hostapd > started is the only one with working broadcast code > to clients. > > In if_ath.c the code > > if ((k->wk_flags & IEEE80211_KEY_GROUP) && sc->sc_mcastkey) { > /* > * Group keys on hardware that supports multicast frame > * key search use a mac that is the sender's address with > * the high bit set instead of the app-specified address. > */ > IEEE80211_ADDR_COPY(gmac, bss->ni_macaddr); > gmac[0] |= 0x80; > mac = gmac; > } else > mac = k->wk_macaddr; > > seems to indicate that for multiple VAPs the ath chips > needs to be able to distinguish between broadcast keys > by using a permutation of VAPs bssid. > > But in if_athvar.h the code does not seem complete > and sc->sc_mcastkey is also set false. > > #ifdef notyet > #define ath_hal_hasmcastkeysearch(_ah) \ > (ath_hal_getcapability(_ah, HAL_CAP_MCAST_KEYSRCH, 0, NULL) == > HAL_OK) > #define ath_hal_getmcastkeysearch(_ah) \ > (ath_hal_getcapability(_ah, HAL_CAP_MCAST_KEYSRCH, 1, NULL) == > HAL_OK) > #else > #define ath_hal_getmcastkeysearch(_ah) 0 > #endif > > I am using cards with an AR5212 which does seem to have > multiple bssid support working so I hope they should also > support mcastkeysearch capability. Maybe only some > firmware revisions have this? > > Do you know what the status of the HAL code is for > supporting this? Why it is commented out in if_athvar.h? Good work analyzing things; been a long time since I looked at this. I vaguely recall disabling mcastkey searching because of problems with WEP. I'm surprised WPA is broken as that was a standard test case. You can try enabling the notyet code and see if the right thing happens. I don't see any indication of the mac rev for your part but I expect it supports this as it was only very early parts that had issues. If enabling the mcastkey search mechanism doesn't fix this I might've broken things with changes to explicitly mark group keys when hostapd plumbs their contents. I recall doing this for mwl which doesn't have an indexed key table like ath (it uses the mac address of the local bss and/or associated station to find the data structure where crypto keys are stored). I haven't looked at this stuff in a long time and can't setup a system to test but if you keep pushing on this I'll try to help w/ advise. Sam From owner-freebsd-stable@FreeBSD.ORG Sun Jan 24 01:43:17 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1AE9E106566C for ; Sun, 24 Jan 2010 01:43:17 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from qmta07.westchester.pa.mail.comcast.net (qmta07.westchester.pa.mail.comcast.net [76.96.62.64]) by mx1.freebsd.org (Postfix) with ESMTP id B51088FC18 for ; Sun, 24 Jan 2010 01:43:16 +0000 (UTC) Received: from omta13.westchester.pa.mail.comcast.net ([76.96.62.52]) by qmta07.westchester.pa.mail.comcast.net with comcast id ZC731d00917dt5G57DjGBn; Sun, 24 Jan 2010 01:43:16 +0000 Received: from koitsu.dyndns.org ([98.248.46.159]) by omta13.westchester.pa.mail.comcast.net with comcast id ZDjF1d00C3S48mS3ZDjGnB; Sun, 24 Jan 2010 01:43:16 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id 255E41E3033; Sat, 23 Jan 2010 17:43:14 -0800 (PST) Date: Sat, 23 Jan 2010 17:43:14 -0800 From: Jeremy Chadwick To: freebsd-stable@freebsd.org Message-ID: <20100124014314.GA28672@icarus.home.lan> References: <684e57ec1001231226p447ea769q6379c1aa099b0216@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <684e57ec1001231226p447ea769q6379c1aa099b0216@mail.gmail.com> User-Agent: Mutt/1.5.20 (2009-06-14) Subject: Re: Extra keys in multimedia keyboard doesn't work X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 24 Jan 2010 01:43:17 -0000 On Sat, Jan 23, 2010 at 08:26:47PM +0000, Krzysztof Dajka wrote: > Hi, I've recently got a new Microsoft Wireless Keyboard v2.0. I am curios > whether multimedia keyboards work with FreeBSD out of box or should I > configure something or use some quirks to enable extra keys. This keyboard > works fine with Linux 2.6.30 all keys work otb. I tried using xev in FreeBSD > but none of additional keys returned anything after pressing it. Are > multimedia keyboard supported in FreeBSD or am I having bad luck with mine > keyboard and should I send PR. Can you define "extra keys" in this case? I've a feeling you're referring to the multimedia keys and other stuff residing above the Function keys of the keyboard. If so: yes, FreeBSD's USB driver appears to lack support for these. Or, well, it did on RELENG_7 (which is a completely different USB driver), so it sounds like RELENG_8 needs some work in this regard. If someone wants to take up improving the quirks for this capability, let me know and I'll be more than happy to send them a free Microsoft Natural Ergonomic 4000 keyboard. -- | Jeremy Chadwick jdc@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Sun Jan 24 01:45:29 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F05931065672 for ; Sun, 24 Jan 2010 01:45:29 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from qmta01.emeryville.ca.mail.comcast.net (qmta01.emeryville.ca.mail.comcast.net [76.96.30.16]) by mx1.freebsd.org (Postfix) with ESMTP id D22C48FC13 for ; Sun, 24 Jan 2010 01:45:29 +0000 (UTC) Received: from omta09.emeryville.ca.mail.comcast.net ([76.96.30.20]) by qmta01.emeryville.ca.mail.comcast.net with comcast id ZC5h1d00E0S2fkCA1DlWff; Sun, 24 Jan 2010 01:45:30 +0000 Received: from koitsu.dyndns.org ([98.248.46.159]) by omta09.emeryville.ca.mail.comcast.net with comcast id ZDlV1d0073S48mS8VDlVkC; Sun, 24 Jan 2010 01:45:30 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id 6C3551E3033; Sat, 23 Jan 2010 17:45:28 -0800 (PST) Date: Sat, 23 Jan 2010 17:45:28 -0800 From: Jeremy Chadwick To: Ruslan Mahmatkhanov Message-ID: <20100124014528.GB28672@icarus.home.lan> References: <4B5B5D46.3040400@yandex.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4B5B5D46.3040400@yandex.ru> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: freebsd-stable@freebsd.org Subject: Re: Strange symbols in man-pages X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 24 Jan 2010 01:45:30 -0000 On Sat, Jan 23, 2010 at 11:34:14PM +0300, Ruslan Mahmatkhanov wrote: > I'm viewing dd man-page in gnome with gnome-terminal and i see some > strange symbols instead `-`. For example from man dd(1): > http://www.onlinedisk.ru/get_image.php?id=327964 > > The problem is rised only when i on ru_RU.UTF-8 locale. There is no > problem with C-locale. > > Is this known problem and does anybody have a solution? > > Thanks in advance and keep me in Cc: please (i'm not subscribed to > freebsd-stable@). > > PS. Using 8.0-STABLE. http://lists.freebsd.org/pipermail/freebsd-stable/2010-January/053804.html -- | Jeremy Chadwick jdc@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Sun Jan 24 02:35:17 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 46EF91065670 for ; Sun, 24 Jan 2010 02:35:17 +0000 (UTC) (envelope-from torfinn.ingolfsen@broadpark.no) Received: from bgo1smout1.broadpark.no (bgo1smout1.broadpark.no [217.13.4.94]) by mx1.freebsd.org (Postfix) with ESMTP id 049618FC1A for ; Sun, 24 Jan 2010 02:35:16 +0000 (UTC) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=US-ASCII Received: from bgo1sminn1.broadpark.no ([217.13.4.93]) by bgo1smout1.broadpark.no (Sun Java(tm) System Messaging Server 6.3-3.01 (built Jul 12 2007; 32bit)) with ESMTP id <0KWQ00DLYCIR94B0@bgo1smout1.broadpark.no> for freebsd-stable@freebsd.org; Sun, 24 Jan 2010 03:35:15 +0100 (CET) Received: from kg-v2.kg4.no ([80.203.92.186]) by bgo1sminn1.broadpark.no (Sun Java(tm) System Messaging Server 6.3-3.01 (built Jul 12 2007; 32bit)) with SMTP id <0KWQ00BHLCIR3730@bgo1sminn1.broadpark.no> for freebsd-stable@freebsd.org; Sun, 24 Jan 2010 03:35:15 +0100 (CET) Date: Sun, 24 Jan 2010 03:35:15 +0100 From: Torfinn Ingolfsen To: freebsd-stable@freebsd.org Message-id: <20100124033515.4049f625.torfinn.ingolfsen@broadpark.no> In-reply-to: <20100124002054.BACFC1CC13@ptavv.es.net> References: <201001222220.31040.freebsd@insightbb.com> <20100124002054.BACFC1CC13@ptavv.es.net> X-Mailer: Sylpheed 2.7.1 (GTK+ 2.18.6; amd64-portbld-freebsd8.0) X-Face: "t9w2,-X@O^I`jVW\sonI3.,36KBLZE*AL[y9lL[PyFD*r_S:dIL9c[8Y>V42R0"!"yb_zN,f#%.[PYYNq; m"_0v; ~rUM2Yy!zmkh)3&U|u!=T(zyv,MHJv"nDH>OJ`t(@mil461d_B'Uo|'nMwlKe0Mv=kvV?Nh@>Hb<3s_z2jYgZhPb@?Wi^x1a~Hplz1.zH Subject: Re: 8.0-RELEASE -> -STABLE and size of / X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Jan 2010 02:35:17 -0000 On Sat, 23 Jan 2010 16:20:54 -0800 Kevin Oberman wrote: > Just for the record and to avoid further confusion, building a kernel > with debug symbols does not take any more space in root. Another copy of > the kernel is built but not installed into /kernel. The copy of the kernel > in /kernel is always symbol-less. Perhaps my question should be changed to: how do I configure the "make world" procedure so that no files ending in '*symbol' get installed in /boot/kernel? -- Regards, Torfinn Ingolfsen From owner-freebsd-stable@FreeBSD.ORG Sun Jan 24 02:42:02 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5BDF31065670 for ; Sun, 24 Jan 2010 02:42:02 +0000 (UTC) (envelope-from ler@lerctr.org) Received: from thebighonker.lerctr.org (thebighonker.lerctr.org [192.147.25.65]) by mx1.freebsd.org (Postfix) with ESMTP id 2EE5D8FC0C for ; Sun, 24 Jan 2010 02:42:01 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lerctr.org; s=lerami; h=Content-Transfer-Encoding:Content-Type:MIME-Version:Cc:To:From:Subject:Date:References:In-Reply-To:Message-ID; bh=LRWe9jgcnv+nndLKSiliKhdZGa648EKLw6fQZiPiII8=; b=Gr/Kbli6nhOiWxdlg7lwckgEac/F0ZSac+Z0IeDvdwNHckLTNVzlkbkalVTahFnnimvBDUiMwSelQJ44YzFz9a0u8u+7MwN+fjXbhNXpQjiNE1ryQxj8i0JszpX28h7rro92gerQTHc0kxtO7vDOJUbK+kQJmgcpkPiT2OQkHLc=; Received: from localhost.lerctr.org ([127.0.0.1]:58949 helo=webmail.lerctr.org) by thebighonker.lerctr.org with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1NYsQJ-000OXj-L1; Sat, 23 Jan 2010 20:42:00 -0600 Received: from 76.205.169.61 (SquirrelMail authenticated user ler) by webmail.lerctr.org with HTTP; Sat, 23 Jan 2010 20:41:59 -0600 Message-ID: <4591058770175c8eb66b690450ae33ed.squirrel@webmail.lerctr.org> In-Reply-To: <20100124033515.4049f625.torfinn.ingolfsen@broadpark.no> References: <201001222220.31040.freebsd@insightbb.com> <20100124002054.BACFC1CC13@ptavv.es.net> <20100124033515.4049f625.torfinn.ingolfsen@broadpark.no> Date: Sat, 23 Jan 2010 20:41:59 -0600 From: "Larry Rosenman" To: "Torfinn Ingolfsen" User-Agent: SquirrelMail/1.4.20-RC2 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal X-Spam-Score: -4.4 (----) X-LERCTR-Spam-Score: -4.4 (----) X-Spam-Report: SpamScore (-4.4/5.0) ALL_TRUSTED=-1.8,BAYES_00=-2.599 X-LERCTR-Spam-Report: SpamScore (-4.4/5.0) ALL_TRUSTED=-1.8,BAYES_00=-2.599 Cc: freebsd-stable@freebsd.org Subject: Re: 8.0-RELEASE -> -STABLE and size of / X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Jan 2010 02:42:02 -0000 On Sat, January 23, 2010 8:35 pm, Torfinn Ingolfsen wrote: > On Sat, 23 Jan 2010 16:20:54 -0800 > Kevin Oberman wrote: > >> Just for the record and to avoid further confusion, building a kernel >> with debug symbols does not take any more space in root. Another copy of >> the kernel is built but not installed into /kernel. The copy of the >> kernel >> in /kernel is always symbol-less. > > Perhaps my question should be changed to: > how do I configure the "make world" procedure so that no files ending > in '*symbol' get installed in /boot/kernel? add the following to /etc/make.conf: INSTALL_NODEBUG=yes > -- > Regards, > Torfinn Ingolfsen > > _______________________________________________ > 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" > -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 512-248-2683 E-Mail: ler@lerctr.org US Mail: 430 Valona Loop, Round Rock, TX 78681-3893 From owner-freebsd-stable@FreeBSD.ORG Sun Jan 24 07:25:26 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 19D39106568F for ; Sun, 24 Jan 2010 07:25:26 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from mail2.fluidhosting.com (mx21.fluidhosting.com [204.14.89.4]) by mx1.freebsd.org (Postfix) with ESMTP id 9DD8F8FC1F for ; Sun, 24 Jan 2010 07:25:25 +0000 (UTC) Received: (qmail 6394 invoked by uid 399); 24 Jan 2010 07:25:24 -0000 Received: from localhost (HELO foreign.dougb.net) (dougb@dougbarton.us@127.0.0.1) by localhost with ESMTPAM; 24 Jan 2010 07:25:24 -0000 X-Originating-IP: 127.0.0.1 X-Sender: dougb@dougbarton.us Message-ID: <4B5BF5EB.4010306@FreeBSD.org> Date: Sat, 23 Jan 2010 23:25:31 -0800 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.9.1.7) Gecko/20100123 Thunderbird/3.0.1 MIME-Version: 1.0 To: Freddie Cash References: <4B58FE0B.3010001@langille.org> <20100122090102.GF2910@core.byshenk.net> <20100122090900.GG2910@core.byshenk.net> In-Reply-To: X-Enigmail-Version: 1.0 OpenPGP: id=D5B2F0FB Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: FreeBSD Stable Subject: Re: device.hints isn't setting what I want X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 24 Jan 2010 07:25:26 -0000 On 01/22/10 08:57, Freddie Cash wrote: > Just as a side note: does mergemaster or installworld handle the > installation of /boot/device.hints? Easy way to answer this category of questions. Do 'mergemaster -v', then when you get to the prompt for, "*** The following files exist only in the installed ..." hit ^C, then go look at the created temproot directory. If the file is in there, mergemaster will deal with it for you. If it's not there, mergemaster has no knowledge of it. hth, Doug -- Improve the effectiveness of your Internet presence with a domain name makeover! http://SupersetSolutions.com/ Computers are useless. They can only give you answers. -- Pablo Picasso From owner-freebsd-stable@FreeBSD.ORG Sun Jan 24 07:49:51 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3EFE41065693 for ; Sun, 24 Jan 2010 07:49:51 +0000 (UTC) (envelope-from cvs-src@yandex.ru) Received: from forward15.mail.yandex.net (forward15.mail.yandex.net [95.108.130.119]) by mx1.freebsd.org (Postfix) with ESMTP id E17D88FC1B for ; Sun, 24 Jan 2010 07:49:50 +0000 (UTC) Received: from smtp12.mail.yandex.net (smtp12.mail.yandex.net [95.108.131.191]) by forward15.mail.yandex.net (Yandex) with ESMTP id 2ECB6C05DE; Sun, 24 Jan 2010 10:49:49 +0300 (MSK) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1264319389; bh=092MvvrYN+AG/AOjEnIbfODw2QsaQzNNESqxLwr+SMI=; h=Message-ID:Date:From:MIME-Version:To:CC:Subject:References: In-Reply-To:Content-Type:Content-Transfer-Encoding; b=cdq2W1eZHf7s2dWS6Sdnu5ZaH5sJlFqyg2F6jct/SSIfPVQlFg+kbzlcBt3G0utpJ uyzWap6EiD9zeqdZNUqE1a5GpKydwEMbFDymcYPQPTmrMVHjQXEv/1H/8ZYYZVB5AO AlVgLPYNVJt8D/3IBIa8mMC+256eymI09LvPQcQ0= Received: from smeshariki2.local (unknown [77.66.250.137]) by smtp12.mail.yandex.net (Yandex) with ESMTPSA id ECDD34CC0094; Sun, 24 Jan 2010 10:49:48 +0300 (MSK) Message-ID: <4B5BFB8E.4040209@yandex.ru> Date: Sun, 24 Jan 2010 10:49:34 +0300 From: Ruslan Mahmatkhanov User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; ru-RU; rv:1.9.1.7) Gecko/20100122 Thunderbird/3.0.1 MIME-Version: 1.0 To: Jeremy Chadwick References: <4B5B5D46.3040400@yandex.ru> <20100124014528.GB28672@icarus.home.lan> In-Reply-To: <20100124014528.GB28672@icarus.home.lan> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Yandex-TimeMark: 1264319389 X-Yandex-Spam: 1 X-Yandex-Front: smtp12.mail.yandex.net Cc: freebsd-stable@freebsd.org Subject: Re: Strange symbols in man-pages X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 24 Jan 2010 07:49:51 -0000 On 24.01.2010 04:45, Jeremy Chadwick wrote: > On Sat, Jan 23, 2010 at 11:34:14PM +0300, Ruslan Mahmatkhanov wrote: >> I'm viewing dd man-page in gnome with gnome-terminal and i see some >> strange symbols instead `-`. For example from man dd(1): >> http://www.onlinedisk.ru/get_image.php?id=327964 >> >> The problem is rised only when i on ru_RU.UTF-8 locale. There is no >> problem with C-locale. >> >> Is this known problem and does anybody have a solution? >> >> Thanks in advance and keep me in Cc: please (i'm not subscribed to >> freebsd-stable@). >> >> PS. Using 8.0-STABLE. > > http://lists.freebsd.org/pipermail/freebsd-stable/2010-January/053804.html > So i can avoid this by setting alias in .cshrc: alias man env LANG=C man Thanks. From owner-freebsd-stable@FreeBSD.ORG Sun Jan 24 09:43:05 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 286151065670 for ; Sun, 24 Jan 2010 09:43:05 +0000 (UTC) (envelope-from melifaro@ipfw.ru) Received: from no.spam.no.ddos.ru (no.spam.no.ddos.ru [77.73.233.132]) by mx1.freebsd.org (Postfix) with ESMTP id 82B7E8FC1F for ; Sun, 24 Jan 2010 09:43:03 +0000 (UTC) Received: from ws.ipfw.ru (secured.by.ipfw.ru [81.200.11.182]) by no.spam.no.ddos.ru (Postfix) with ESMTPA id 6618437C67A; Sun, 24 Jan 2010 09:25:49 +0000 (UTC) Message-ID: <4B5C11BD.7080103@ipfw.ru> Date: Sun, 24 Jan 2010 12:24:13 +0300 From: "Alexander V. Chernikov" User-Agent: Thunderbird 2.0.0.23 (X11/20091103) MIME-Version: 1.0 To: Harald Schmalzbauer References: <4B56AB6F.9010303@omnilan.de> <86eilhwzbh.fsf@kopusha.onet> <4B5A4A8C.8070707@omnilan.de> In-Reply-To: <4B5A4A8C.8070707@omnilan.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org, Mikolaj Golub Subject: Re: top Segmentation faulting on 8.0p2 amd64 (nss_ldapd problem?) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Jan 2010 09:43:05 -0000 Harald Schmalzbauer wrote: > Mikolaj Golub schrieb am 22.01.2010 23:26 (localtime): >> On Wed, 20 Jan 2010 08:06:23 +0100 Harald Schmalzbauer wrote: >> >>> Dear all, >>> >>> I have no idea why top crashes with segmentation fault on my amd64 >>> machine running FreeBSD 8.0-RELEASE-p2. >>> If someone wants to have a loot at the core dump: >>> http://www.schmalzbauer.de/downloads/top.core >> >> core file is useless without binary and libraries. So it is better to >> run gdb >> on your host, produce backtrace and post here: >> >> gdb /usr/bin/top top.core >> bt >> >> And sure a backtrace from the top built with -g would be much better. >> >> cd /usr/src/usr.bin/top >> CFLAGS=-g make > > Unfortunately nss_ldap seems to be the culprit. There is some strange problem with TLS and gcc optimization I can't localize Please try to rebuild port with post-configure: @${REINPLACE_CMD} -e 's/^\(CFLAGS .*\)-O2 \(.*\)$$/\1 -O0 \2/' ${WRKSRC}/nss/Makefile I'll submit updated port later > > gdb /usr/bin/top top.core > GNU gdb 6.1.1 [FreeBSD] > Copyright 2004 Free Software Foundation, Inc. > GDB is free software, covered by the GNU General Public License, and > you are > welcome to change it and/or distribute copies of it under certain > conditions. > Type "show copying" to see the conditions. > There is absolutely no warranty for GDB. Type "show warranty" for > details. > This GDB was configured as "amd64-marcel-freebsd"... > Core was generated by `top'. > Program terminated with signal 11, Segmentation fault. > Reading symbols from /lib/libncurses.so.8...done. > Loaded symbols for /lib/libncurses.so.8 > Reading symbols from /lib/libm.so.5...done. > Loaded symbols for /lib/libm.so.5 > Reading symbols from /lib/libkvm.so.5...done. > Loaded symbols for /lib/libkvm.so.5 > Reading symbols from /lib/libc.so.7...done. > Loaded symbols for /lib/libc.so.7 > Reading symbols from /usr/local/lib/nss_ldap.so.1...done. > Loaded symbols for /usr/local/lib/nss_ldap.so.1 > Reading symbols from /libexec/ld-elf.so.1...done. > Loaded symbols for /libexec/ld-elf.so.1 > bt: > #0 0x0000000800d08403 in __nss_compat_gethostbyname () from > /usr/local/lib/nss_ldap.so.1 > #0 0x0000000800d08403 in __nss_compat_gethostbyname () from > /usr/local/lib/nss_ldap.so.1 > #1 0x0000000800d0606f in _nss_ldap_getpwent_r () from > /usr/local/lib/nss_ldap.so.1 > #2 0x00000008009ffc54 in __nss_compat_getpwent_r () from /lib/libc.so.7 > #3 0x0000000800a84a3d in nsdispatch () from /lib/libc.so.7 > #4 0x0000000800a50976 in getpwent_r () from /lib/libc.so.7 > #5 0x0000000800a50596 in sysctlbyname () from /lib/libc.so.7 > #6 0x0000000000406c6d in machine_init (statics=0x7fffffffea30, > do_unames=1 '\001') > at /usr/src/usr.bin/top/machine.c:257 > #7 0x0000000000407a10 in main (argc=1, argv=0x7fffffffeb08) > at /usr/src/usr.bin/top/../../contrib/top/top.c:458 > > I'm using nss_ldapd-0.7.2 and there's no way to live without ldap... > > Any help highly appreciated! > > Thanks, > > -Harry > From owner-freebsd-stable@FreeBSD.ORG Sun Jan 24 10:18:14 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 16A5B106566C for ; Sun, 24 Jan 2010 10:18:14 +0000 (UTC) (envelope-from spil.oss@googlemail.com) Received: from mail-px0-f183.google.com (mail-px0-f183.google.com [209.85.216.183]) by mx1.freebsd.org (Postfix) with ESMTP id E5C8D8FC18 for ; Sun, 24 Jan 2010 10:18:13 +0000 (UTC) Received: by pxi13 with SMTP id 13so1813051pxi.3 for ; Sun, 24 Jan 2010 02:18:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:reply-to:date:message-id :subject:from:to:content-type; bh=nsMrk2kw6oK+7tV7JbXCJppRxhnVXJQbE0CTNuMBcms=; b=qMTkzLpwQl/i6FRM1vWRJFqWiCWFODkZFrM8XjSaktGOyTtt5YCumu8nT9pb9tsAZk VgMiwCenV7Da3BmBQMsBXw3cG9qcMNfaxvbWOo2oK5wq090YMNyIZ8LIgYyFQzHP4Qe1 Drxmlxo+hD+WBe9Wd5ANLsejEBT3RIKHV7j5Y= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:reply-to:date:message-id:subject:from:to:content-type; b=eo/kldU6E4lGoHIQwFiGirtI3r7ychSayRptxvn4eUTHXsKWjyYzG3K8MEpY1DS3E9 HMjIN4YB1dv8k5H29XZ2GF7xVXEPhTxpf84tmE7zPoVCgKjDCnVjDpU8/UHjNKwqTxay yWmu5aavyx2RvDqOrFnI6zY0wRZFhrWx4qbIE= MIME-Version: 1.0 Received: by 10.140.55.5 with SMTP id d5mr3038141rva.177.1264326630886; Sun, 24 Jan 2010 01:50:30 -0800 (PST) Date: Sun, 24 Jan 2010 10:50:30 +0100 Message-ID: <5fbf03c21001240150r2064810n744694380ab8913a@mail.gmail.com> From: Spil Oss To: freebsd-stable@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Subject: Problem with alias length in base Sendmail X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: spil.oss@gmail.com List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Jan 2010 10:18:14 -0000 Hi All, Today I ran into the BUG documented in the aliases man-page. If you have compiled sendmail with DBM support instead of NEWDB, you may have encountered problems in dbm(3) restricting a single alias to about 1000 bytes of information. Looking at Sendmail, it is compiled with NEWDB so the restriction would not apply. # sendmail -d0.1 -bv root Version 8.14.3 Compiled with: DNSMAP LOG MAP_REGEX MATCHGECOS MILTER MIME7TO8 MIME8TO7 NAMED_BIND NETINET NETINET6 NETUNIX NEWDB NIS PIPELINING SCANF STARTTLS TCPWRAPPERS USERDB XDEBUG If my alias (including whitespace) exceeds ca. 1000 characters, running `make aliases` will report an error. /etc/mail/aliases: line 320: alias too long Resulting in an aliases.db file without the too long alias 550 5.1.1 ... User unknown Which means to me that the alias is simply skipped and the rest of the aliases database is installed. There is a workaround documented with the bug in the man-page, but I'd very much like to understand why this is failing. FreeBSD gw.example.org 7.2-RELEASE-p1 FreeBSD 7.2-RELEASE-p1 #2: Thu Jun 11 12:58:02 CEST 2009 root@gw.example.org:/usr/obj/usr/src/sys/MYKERNEL i386 Kind regards, Spil From owner-freebsd-stable@FreeBSD.ORG Sun Jan 24 10:45:25 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4E07F106566B for ; Sun, 24 Jan 2010 10:45:25 +0000 (UTC) (envelope-from freebsd@southportcomputers.co.uk) Received: from ted.southportcomputers.co.uk (ted.southportcomputers.co.uk [92.48.124.28]) by mx1.freebsd.org (Postfix) with ESMTP id 0D1EF8FC12 for ; Sun, 24 Jan 2010 10:45:24 +0000 (UTC) Received: from office.southportcomputers.co.uk ([78.105.116.12] helo=[192.168.1.68]) by ted.southportcomputers.co.uk with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1NYzy5-000LYv-5E for freebsd-stable@freebsd.org; Sun, 24 Jan 2010 10:45:21 +0000 Message-ID: <4B5C24C0.10907@southportcomputers.co.uk> Date: Sun, 24 Jan 2010 10:45:20 +0000 From: Colin User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: freebsd-stable@freebsd.org References: <4B596838.9020609@southportcomputers.co.uk> <20100122094546.GB6681@titania.njm.me.uk> <20100122111708.GA67643@icarus.home.lan> <201001221029.43926.jhb@freebsd.org> <4B5B1550.2070906@southportcomputers.co.uk> <20100123183058.GA19836@icarus.home.lan> <4B5B4AA4.5090200@southportcomputers.co.uk> In-Reply-To: <4B5B4AA4.5090200@southportcomputers.co.uk> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ted.southportcomputers.co.uk X-AntiAbuse: Original Domain - freebsd.org X-AntiAbuse: Originator/Caller UID/GID - [26 6] / [26 6] X-AntiAbuse: Sender Address Domain - southportcomputers.co.uk X-Source: X-Source-Args: X-Source-Dir: Subject: Re: make buildkernel failing on zfs - fixed but now everything is slow X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Jan 2010 10:45:25 -0000 Colin wrote: > Thanks for the reply. > I must admit that the ins and outs of paging and interrupts are > something I don't have much expertise in. I've asked the colo company > to look into it but I've put the output of those commands into > pastebin incase anything stands out. > http://www.pastebin.org/81107 > I suspect this is an none issue now as everything is OK. My best guess is that the RAID array was rebuilding itself as there were a few mpt cam events logged overnight and the problem seems to have gone away after that. Now I'm left with one problem which is a bit different so I'll start it on its own topic Cheers for the help folks. From owner-freebsd-stable@FreeBSD.ORG Sun Jan 24 11:03:11 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EF068106566B for ; Sun, 24 Jan 2010 11:03:11 +0000 (UTC) (envelope-from h.schmalzbauer@omnilan.de) Received: from host.omnilan.net (host.omnilan.net [62.245.232.135]) by mx1.freebsd.org (Postfix) with ESMTP id 5C2A28FC1C for ; Sun, 24 Jan 2010 11:03:10 +0000 (UTC) Received: from titan.flintsbach.schmalzbauer.de (titan.flintsbach.schmalzbauer.de [172.21.1.150]) (authenticated bits=0) by host.omnilan.net (8.13.8/8.13.8) with ESMTP id o0OB36am008945 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 24 Jan 2010 12:03:09 +0100 (CET) (envelope-from h.schmalzbauer@omnilan.de) Message-ID: <4B5C28E3.8080006@omnilan.de> Date: Sun, 24 Jan 2010 12:02:59 +0100 From: Harald Schmalzbauer Organization: OmniLAN User-Agent: Thunderbird 2.0.0.23 (X11/20090906) MIME-Version: 1.0 To: "Alexander V. Chernikov" References: <4B56AB6F.9010303@omnilan.de> <86eilhwzbh.fsf@kopusha.onet> <4B5A4A8C.8070707@omnilan.de> <4B5C11BD.7080103@ipfw.ru> In-Reply-To: <4B5C11BD.7080103@ipfw.ru> X-Enigmail-Version: 0.95.6 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigEC32D5916D5D4518B011F971" Cc: freebsd-stable@freebsd.org, Mikolaj Golub Subject: Re: top Segmentation faulting on 8.0p2 amd64 (nss_ldapd problem?) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Jan 2010 11:03:12 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigEC32D5916D5D4518B011F971 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Alexander V. Chernikov schrieb am 24.01.2010 10:24 (localtime): =2E.. >>> gdb /usr/bin/top top.core >>> bt >>> >>> And sure a backtrace from the top built with -g would be much better.= >>> >>> cd /usr/src/usr.bin/top >>> CFLAGS=3D-g make >> >> Unfortunately nss_ldap seems to be the culprit. > There is some strange problem with TLS and gcc optimization I can't=20 > localize >=20 > Please try to rebuild port with >=20 > post-configure: > @${REINPLACE_CMD} -e 's/^\(CFLAGS .*\)-O2 \(.*\)$$/\1 -O0 \2/'=20 > ${WRKSRC}/nss/Makefile >=20 > I'll submit updated port later That indeed fixed the problem. Thank you very much. But I found another point for improovement: When deinstalling/installing nss_ldap.conf gets deleted/overwritten. I=20 think it's better to install nss_ldap.conf.sample like many other ports d= o. I also like the way lighttpd port is managed: @unexec if cmp -s %D/etc/lighttpd.conf %D/etc/lighttpd.conf.sample; then = rm -f %D/etc/lighttpd.conf; fi etc/lighttpd.conf.sample @exec [ -f %B/lighttpd.conf ] || cp %B/%f %B/lighttpd.conf Thanks, -Harry --------------enigEC32D5916D5D4518B011F971 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.13 (FreeBSD) iEYEARECAAYFAktcKOoACgkQLDqVQ9VXb8ii9gCgqkbh03MmbeUDc/+thiLwahBi FdsAn3NcCOoqpyN2xfkjGF+7NDADRS83 =0UBL -----END PGP SIGNATURE----- --------------enigEC32D5916D5D4518B011F971-- From owner-freebsd-stable@FreeBSD.ORG Sun Jan 24 11:15:12 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6299E106566C for ; Sun, 24 Jan 2010 11:15:12 +0000 (UTC) (envelope-from melifaro@ipfw.ru) Received: from no.spam.no.ddos.ru (no.spam.no.ddos.ru [77.73.233.132]) by mx1.freebsd.org (Postfix) with ESMTP id 18DB58FC0C for ; Sun, 24 Jan 2010 11:15:11 +0000 (UTC) Received: from ws.ipfw.ru (secured.by.ipfw.ru [81.200.11.182]) by no.spam.no.ddos.ru (Postfix) with ESMTPA id C7AA737C680; Sun, 24 Jan 2010 11:15:09 +0000 (UTC) Message-ID: <4B5C2B5D.3010301@ipfw.ru> Date: Sun, 24 Jan 2010 14:13:33 +0300 From: "Alexander V. Chernikov" User-Agent: Thunderbird 2.0.0.23 (X11/20091103) MIME-Version: 1.0 To: Harald Schmalzbauer References: <4B56AB6F.9010303@omnilan.de> <86eilhwzbh.fsf@kopusha.onet> <4B5A4A8C.8070707@omnilan.de> <4B5C11BD.7080103@ipfw.ru> <4B5C28E3.8080006@omnilan.de> In-Reply-To: <4B5C28E3.8080006@omnilan.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org, Mikolaj Golub Subject: Re: top Segmentation faulting on 8.0p2 amd64 (nss_ldapd problem?) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Jan 2010 11:15:12 -0000 Harald Schmalzbauer wrote: > Alexander V. Chernikov schrieb am 24.01.2010 10:24 (localtime): > ... >>>> gdb /usr/bin/top top.core >>>> bt >>>> >>>> And sure a backtrace from the top built with -g would be much better. >>>> >>>> cd /usr/src/usr.bin/top >>>> CFLAGS=-g make >>> >>> Unfortunately nss_ldap seems to be the culprit. >> There is some strange problem with TLS and gcc optimization I can't >> localize >> >> Please try to rebuild port with >> >> post-configure: >> @${REINPLACE_CMD} -e 's/^\(CFLAGS .*\)-O2 \(.*\)$$/\1 -O0 \2/' >> ${WRKSRC}/nss/Makefile >> >> I'll submit updated port later > > That indeed fixed the problem. Thank you very much. > But I found another point for improovement: > When deinstalling/installing nss_ldap.conf gets deleted/overwritten. I > think it's better to install nss_ldap.conf.sample like many other > ports do. > I also like the way lighttpd port is managed: > @unexec if cmp -s %D/etc/lighttpd.conf %D/etc/lighttpd.conf.sample; > then rm -f %D/etc/lighttpd.conf; fi > etc/lighttpd.conf.sample > @exec [ -f %B/lighttpd.conf ] || cp %B/%f %B/lighttpd.conf > > Thanks, > > -Harry > Already noticed that, thanks. From owner-freebsd-stable@FreeBSD.ORG Sun Jan 24 11:32:22 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E9C721065672 for ; Sun, 24 Jan 2010 11:32:22 +0000 (UTC) (envelope-from 000.fbsd@quip.cz) Received: from elsa.codelab.cz (elsa.codelab.cz [94.124.105.4]) by mx1.freebsd.org (Postfix) with ESMTP id 64CE08FC1C for ; Sun, 24 Jan 2010 11:32:22 +0000 (UTC) Received: from elsa.codelab.cz (localhost.codelab.cz [127.0.0.1]) by elsa.codelab.cz (Postfix) with ESMTP id C47F319E019; Sun, 24 Jan 2010 12:32:20 +0100 (CET) Received: from [192.168.1.2] (r5bb235.net.upc.cz [86.49.61.235]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by elsa.codelab.cz (Postfix) with ESMTPSA id 2375F19E023; Sun, 24 Jan 2010 12:32:18 +0100 (CET) Message-ID: <4B5C2FC1.9070001@quip.cz> Date: Sun, 24 Jan 2010 12:32:17 +0100 From: Miroslav Lachman <000.fbsd@quip.cz> User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9.1.7) Gecko/20100104 SeaMonkey/2.0.2 MIME-Version: 1.0 To: Garrett Moore References: <7346c5c61001030842r7dc76199y51e4c1c90a3eea6e@mail.gmail.com> <7346c5c61001091706m45a3a2a5k3ca8bb0c4bec5ea8@mail.gmail.com> <7346c5c61001171521w1ca4738w98e8fcca24643cda@mail.gmail.com> <201001180829.48126.npapke@acm.org> <7346c5c61001190840k31466754i32b2ae833390b79b@mail.gmail.com> In-Reply-To: <7346c5c61001190840k31466754i32b2ae833390b79b@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org Subject: Re: ZFS performance degradation over time X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 24 Jan 2010 11:32:23 -0000 Garrett Moore wrote: > I've been watching my memory usage and I have no idea what is consuming > memory as 'Active'. > > Last night I had around 6500MB 'Active' again, 1500MB Wired, no inact, ~30MB > buf, no free, and ~100MB swap used. My performance copying ZFS->ZFS was > again slow (<1MB/s). I tried killing rTorrent and no significant amount of > memory was reclaimed - maybe 100MB. `ps aux` showed no processes using any > significant amount of memory, and I was definitely nowhere near 6500MB > usage. > > I tried running the perl oneliner again to hog a bunch of memory, and almost > all of the Active memory was IMMEDIATELY marked as Free, and my performance > was excellent again. > > I'm not sure what in userland could be causing the issue. The only things > I've installed are rTorrent, lighttpd, samba, smartmontools, vim, bash, > Python, Perl, and SABNZBd. There is nothing that *should* be consuming any > serious amount of memory. Last night I tried ZFS with pool on iSCSI connected Dell MD3000i and I was suprised by too low speed of simple cp -a command (copying from UFS partition to ZFS) The write speed was about 2MB/s only. After looking in to ARC stuff, I realized some weird values: ARC Size: Current Size: 1 MB (arcsize) Target Size (Adaptive): 205 MB (c) Min Size (Hard Limit): 205 MB (zfs_arc_min) Max Size (Hard Limit): 1647 MB (zfs_arc_max) (stats from script http://cuddletech.com/arc_summary/ freebsd version http://bitbucket.org/koie/arc_summary/changeset/dbe14d2cf52b/ ) I don't know why it shows Current Size 1MB. I tried the perl oneliner from this thread. Then I got about 5GB free merory and Target Size and Current Size growed to 1647MB. Write speed increase to about 8MB/s and after few minuts slowly dropped to 2MB/s and ARC Current Size dropped to 1MB again. This server is not in production and was idle. Just copying the data from one partition to another. Today I tried serving the data by Lighttpd. There is impressive iSCSI read performance - because of ZFS prefetch, it can achieve 880Mbits of read from iSCSI, but serving by Lighttpd only about 66Mbits bce0 - internet bce1 - iSCSI to storage MD3000i bce0 bce1 Kbps in Kbps out Kbps in Kbps out 2423.22 65481.56 855970.7 4348.73 2355.26 63911.74 820561.3 4846.08 2424.87 65998.62 848937.1 4312.37 2442.78 66544.95 858019.0 4356.64 iostat -x extended device statistics device r/s w/s kr/s kw/s wait svc_t %b da1 1596.8 3.6 102196.7 22.2 13 7.4 97 da1 1650.2 2.9 105612.7 55.7 16 7.4 103 da1 1647.3 0.0 105422.9 0.0 13 7.2 100 da1 1636.5 2.3 104735.4 20.0 16 7.3 100 da1 1642.9 0.0 105141.1 0.0 13 7.3 100 ~/bin/arcstat.pl -f Time,read,hits,Hit%,miss,miss%,dmis,dm%,mmis,mm%,arcsz,c 30 Time read hits Hit% miss miss% dmis dm% mmis mm% arcsz c 12:18:05 16K 15K 94 838 5 570 3 1 0 16933296 215902720 12:18:36 16K 15K 94 839 5 571 3 0 0 21488288 215902720 12:19:06 16K 15K 94 836 5 569 3 1 0 17228688 215902720 12:19:37 16K 15K 94 839 5 572 3 4 1 22002672 215902720 12:20:07 16K 15K 94 841 5 570 3 1 0 27784960 215902720 12:20:38 16K 15K 94 838 5 569 3 0 0 21839472 215902720 12:21:08 16K 15K 94 837 5 568 3 0 0 28244992 215902720 12:21:39 16K 15K 94 833 5 565 3 1 0 28744416 215902720 12:22:09 16K 15K 94 842 5 576 3 4 1 28646656 215902720 12:22:39 16K 15K 94 840 5 575 3 3 0 28903696 215902720 12:23:10 15K 15K 94 821 5 561 3 0 0 28765904 215902720 12:23:40 16K 15K 94 828 5 566 3 0 0 28395840 215902720 12:24:11 16K 15K 94 828 5 568 3 0 0 32063408 215902720 12:24:41 16K 15K 94 834 5 570 3 0 0 29800976 215902720 12:25:12 15K 15K 94 820 5 562 3 1 0 29066512 215902720 # ~/bin/arc_summary.pl System Memory: Physical RAM: 8169 MB Free Memory : 0 MB ARC Size: Current Size: 22 MB (arcsize) Target Size (Adaptive): 205 MB (c) Min Size (Hard Limit): 205 MB (zfs_arc_min) Max Size (Hard Limit): 1647 MB (zfs_arc_max) ARC Size Breakdown: Most Recently Used Cache Size: 5% 11 MB (p) Most Frequently Used Cache Size: 94% 194 MB (c-p) ARC Efficency: Cache Access Total: 81843958 Cache Hit Ratio: 95% 78525502 [Defined State for buffer] Cache Miss Ratio: 4% 3318456 [Undefined State for Buffer] REAL Hit Ratio: 95% 78418994 [MRU/MFU Hits Only] Data Demand Efficiency: 97% Data Prefetch Efficiency: 10% CACHE HITS BY CACHE LIST: Anon: --% Counter Rolled. Most Recently Used: 2% 2209869 (mru) [ Return Customer ] Most Frequently Used: 97% 76209125 (mfu) [ Frequent Customer ] Most Recently Used Ghost: 1% 965711 (mru_ghost) [ Return Customer Evicted, Now Back ] Most Frequently Used Ghost: 0% 176871 (mfu_ghost) [ Frequent Customer Evicted, Now Back ] CACHE HITS BY DATA TYPE: Demand Data: 97% 76770304 Prefetch Data: 0% 126644 Demand Metadata: 2% 1628528 Prefetch Metadata: 0% 26 CACHE MISSES BY DATA TYPE: Demand Data: 63% 2122089 Prefetch Data: 32% 1063449 Demand Metadata: 4% 132894 Prefetch Metadata: 0% 24 --------------------------------------------- # sysctl kstat.zfs.misc.arcstats kstat.zfs.misc.arcstats.hits: 75409326 kstat.zfs.misc.arcstats.misses: 3144748 kstat.zfs.misc.arcstats.demand_data_hits: 73731356 kstat.zfs.misc.arcstats.demand_data_misses: 2003526 kstat.zfs.misc.arcstats.demand_metadata_hits: 1551917 kstat.zfs.misc.arcstats.demand_metadata_misses: 132730 kstat.zfs.misc.arcstats.prefetch_data_hits: 126027 kstat.zfs.misc.arcstats.prefetch_data_misses: 1008468 kstat.zfs.misc.arcstats.prefetch_metadata_hits: 26 kstat.zfs.misc.arcstats.prefetch_metadata_misses: 24 kstat.zfs.misc.arcstats.mru_hits: 2105758 kstat.zfs.misc.arcstats.mru_ghost_hits: 914887 kstat.zfs.misc.arcstats.mfu_hits: 73197609 kstat.zfs.misc.arcstats.mfu_ghost_hits: 171171 kstat.zfs.misc.arcstats.deleted: 2367973 kstat.zfs.misc.arcstats.recycle_miss: 412788 kstat.zfs.misc.arcstats.mutex_miss: 2865 kstat.zfs.misc.arcstats.evict_skip: 17459 kstat.zfs.misc.arcstats.hash_elements: 2478 kstat.zfs.misc.arcstats.hash_elements_max: 28921 kstat.zfs.misc.arcstats.hash_collisions: 86135 kstat.zfs.misc.arcstats.hash_chains: 25 kstat.zfs.misc.arcstats.hash_chain_max: 3 kstat.zfs.misc.arcstats.p: 14908416 kstat.zfs.misc.arcstats.c: 215902720 kstat.zfs.misc.arcstats.c_min: 215902720 kstat.zfs.misc.arcstats.c_max: 1727221760 kstat.zfs.misc.arcstats.size: 30430560 kstat.zfs.misc.arcstats.hdr_size: 555072 kstat.zfs.misc.arcstats.l2_hits: 0 kstat.zfs.misc.arcstats.l2_misses: 0 kstat.zfs.misc.arcstats.l2_feeds: 0 kstat.zfs.misc.arcstats.l2_rw_clash: 0 kstat.zfs.misc.arcstats.l2_writes_sent: 0 kstat.zfs.misc.arcstats.l2_writes_done: 0 kstat.zfs.misc.arcstats.l2_writes_error: 0 kstat.zfs.misc.arcstats.l2_writes_hdr_miss: 0 kstat.zfs.misc.arcstats.l2_evict_lock_retry: 0 kstat.zfs.misc.arcstats.l2_evict_reading: 0 kstat.zfs.misc.arcstats.l2_free_on_write: 0 kstat.zfs.misc.arcstats.l2_abort_lowmem: 0 kstat.zfs.misc.arcstats.l2_cksum_bad: 0 kstat.zfs.misc.arcstats.l2_io_error: 0 kstat.zfs.misc.arcstats.l2_size: 0 kstat.zfs.misc.arcstats.l2_hdr_size: 0 kstat.zfs.misc.arcstats.memory_throttle_count: 135489 This is on FreeBSD 7.2-STABLE #0: Sun Dec 6 23:21:17 CET 2009 root@dust.hrej.cz:/usr/obj/usr/src/sys/GENERIC amd64 Can somebody tell me, why ARC Current Size is dropping too low? (1-20MB if arc_min is 205MB) The system have 8GB of memory and 8 CPU cores: last pid: 83605; load averages: 0.17, 0.15, 0.10 up 36+10:34:34 12:29:05 58 processes: 1 running, 56 sleeping, 1 zombie CPU: 0.1% user, 0.0% nice, 2.3% system, 1.7% interrupt, 95.8% idle Mem: 237M Active, 6259M Inact, 1154M Wired, 138M Cache, 827M Buf, 117M Free Swap: 8192M Total, 96K Used, 8192M Free I have no loader.conf tunning on this machine. Miroslav Lachman From owner-freebsd-stable@FreeBSD.ORG Sun Jan 24 13:22:40 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9946B1065696 for ; Sun, 24 Jan 2010 13:22:40 +0000 (UTC) (envelope-from 000.fbsd@quip.cz) Received: from elsa.codelab.cz (elsa.codelab.cz [94.124.105.4]) by mx1.freebsd.org (Postfix) with ESMTP id E0CA58FC13 for ; Sun, 24 Jan 2010 13:22:39 +0000 (UTC) Received: from elsa.codelab.cz (localhost.codelab.cz [127.0.0.1]) by elsa.codelab.cz (Postfix) with ESMTP id BA8B419E023; Sun, 24 Jan 2010 14:22:37 +0100 (CET) Received: from [192.168.1.2] (r5bb235.net.upc.cz [86.49.61.235]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by elsa.codelab.cz (Postfix) with ESMTPSA id 2091219E019; Sun, 24 Jan 2010 14:22:35 +0100 (CET) Message-ID: <4B5C499A.1000103@quip.cz> Date: Sun, 24 Jan 2010 14:22:34 +0100 From: Miroslav Lachman <000.fbsd@quip.cz> User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9.1.7) Gecko/20100104 SeaMonkey/2.0.2 MIME-Version: 1.0 To: Garrett Moore References: <7346c5c61001030842r7dc76199y51e4c1c90a3eea6e@mail.gmail.com> <7346c5c61001091706m45a3a2a5k3ca8bb0c4bec5ea8@mail.gmail.com> <7346c5c61001171521w1ca4738w98e8fcca24643cda@mail.gmail.com> <201001180829.48126.npapke@acm.org> <7346c5c61001190840k31466754i32b2ae833390b79b@mail.gmail.com> <4B5C2FC1.9070001@quip.cz> In-Reply-To: <4B5C2FC1.9070001@quip.cz> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Alexander Leidinger , freebsd-stable@freebsd.org Subject: Re: ZFS performance degradation over time X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 24 Jan 2010 13:22:40 -0000 Miroslav Lachman wrote: [...] > Last night I tried ZFS with pool on iSCSI connected Dell MD3000i and I > was suprised by too low speed of simple cp -a command (copying from UFS > partition to ZFS) The write speed was about 2MB/s only. > > After looking in to ARC stuff, I realized some weird values: > > ARC Size: > Current Size: 1 MB (arcsize) > Target Size (Adaptive): 205 MB (c) > Min Size (Hard Limit): 205 MB (zfs_arc_min) > Max Size (Hard Limit): 1647 MB (zfs_arc_max) > > (stats from script http://cuddletech.com/arc_summary/ > freebsd version > http://bitbucket.org/koie/arc_summary/changeset/dbe14d2cf52b/ ) > > I don't know why it shows Current Size 1MB. [...] > Today I tried serving the data by Lighttpd. > There is impressive iSCSI read performance - because of ZFS prefetch, it > can achieve 880Mbits of read from iSCSI, but serving by Lighttpd only > about 66Mbits > > bce0 - internet > bce1 - iSCSI to storage MD3000i > > bce0 bce1 > Kbps in Kbps out Kbps in Kbps out > 2423.22 65481.56 855970.7 4348.73 > 2355.26 63911.74 820561.3 4846.08 > 2424.87 65998.62 848937.1 4312.37 > 2442.78 66544.95 858019.0 4356.64 [...] > ARC Size: > Current Size: 22 MB (arcsize) > Target Size (Adaptive): 205 MB (c) > Min Size (Hard Limit): 205 MB (zfs_arc_min) > Max Size (Hard Limit): 1647 MB (zfs_arc_max) > > ARC Size Breakdown: > Most Recently Used Cache Size: 5% 11 MB (p) > Most Frequently Used Cache Size: 94% 194 MB (c-p) [...] > Can somebody tell me, why ARC Current Size is dropping too low? (1-20MB > if arc_min is 205MB) > > The system have 8GB of memory and 8 CPU cores: > > last pid: 83605; load averages: 0.17, 0.15, 0.10 up 36+10:34:34 12:29:05 > 58 processes: 1 running, 56 sleeping, 1 zombie > CPU: 0.1% user, 0.0% nice, 2.3% system, 1.7% interrupt, 95.8% idle > Mem: 237M Active, 6259M Inact, 1154M Wired, 138M Cache, 827M Buf, 117M Free > Swap: 8192M Total, 96K Used, 8192M Free Hmmm, it seems related to ZFS + Sendfile bug as was pointed in older thread: Performance issues with 8.0 ZFS and sendfile/lighttpd http://lists.freebsd.org/pipermail/freebsd-stable/2009-November/052595.html http://lists.freebsd.org/pipermail/freebsd-stable/2009-November/052629.html I tried the test with Lighttpd again, but with "writev" instead of sendfile in lighttpd.conf (server.network-backend = "writev") and with this settings it triple the performance! Now Lighttpd is serving about 180Mbits instead of 66Mbits and ARC Current Size is constantly on its max size: # ~/bin/arc_summary.pl System Memory: Physical RAM: 8169 MB Free Memory : 0 MB ARC Size: Current Size: 1647 MB (arcsize) Target Size (Adaptive): 1647 MB (c) Min Size (Hard Limit): 205 MB (zfs_arc_min) Max Size (Hard Limit): 1647 MB (zfs_arc_max) ARC Size Breakdown: Most Recently Used Cache Size: 99% 1643 MB (p) Most Frequently Used Cache Size: 0% 3 MB (c-p) ARC Efficency: Cache Access Total: 126994437 Cache Hit Ratio: 94% 119500977 [Defined State for buffer] Cache Miss Ratio: 5% 7493460 [Undefined State for Buffer] REAL Hit Ratio: 93% 118808103 [MRU/MFU Hits Only] Data Demand Efficiency: 97% Data Prefetch Efficiency: 14% CACHE HITS BY CACHE LIST: Anon: --% Counter Rolled. Most Recently Used: 2% 3552568 (mru) [ Return Customer ] Most Frequently Used: 96% 115255535 (mfu) [ Frequent Customer ] Most Recently Used Ghost: 1% 1277990 (mru_ghost) [ Return Customer Evicted, Now Back ] Most Frequently Used Ghost: 0% 464787 (mfu_ghost) [ Frequent Customer Evicted, Now Back ] CACHE HITS BY DATA TYPE: Demand Data: 96% 114958883 Prefetch Data: 0% 713418 Demand Metadata: 3% 3828650 Prefetch Metadata: 0% 26 CACHE MISSES BY DATA TYPE: Demand Data: 40% 3017229 Prefetch Data: 57% 4324961 Demand Metadata: 2% 151246 Prefetch Metadata: 0% 24 # ~/bin/arcstat.pl -f Time,read,hits,Hit%,miss,miss%,dmis,dm%,mmis,mm%,arcsz,c 30 Time read hits Hit% miss miss% dmis dm% mmis mm% arcsz c 14:04:45 5K 4K 87 672 12 53 1 2 0 1727635056 1727221760 14:05:16 5K 4K 86 679 13 48 1 1 0 1727283200 1727221760 14:05:46 5K 5K 88 674 11 55 1 1 0 1727423184 1727221760 14:06:17 5K 4K 87 668 12 51 1 0 0 1727590560 1727221760 14:06:47 5K 5K 88 665 11 56 1 1 0 1727278896 1727221760 14:07:18 5K 5K 88 664 11 53 1 1 0 1727347632 1727221760 # # ifstat -i bce0,bce1 -b 10 bce0 bce1 Kbps in Kbps out Kbps in Kbps out 6673.90 184872.8 679110.0 3768.23 6688.00 185420.0 655232.8 3834.10 7737.68 214640.4 673375.7 3735.96 6993.61 193602.6 671239.3 3737.48 7198.54 198665.0 688677.0 4037.28 8062.61 222400.4 683966.9 3790.40 There is also big change in memory usage: last pid: 92536; load averages: 0.19, 0.16, 0.16 up 36+12:22:26 14:16:57 60 processes: 1 running, 58 sleeping, 1 zombie CPU: 0.0% user, 0.0% nice, 2.5% system, 3.3% interrupt, 94.1% idle Mem: 1081M Active, 172M Inact, 2800M Wired, 3844M Cache, 827M Buf, 8776K Free Swap: 8192M Total, 104K Used, 8192M Free More Active, less Inact (172M instead of 6259M!) more Cache (3844M instead of 138M) Buf and Free are close in both cases. Do somebody know about some fixes of ZFS + Sendfile problem commited in to 8.x or HEAD? How can we test if it is general problem with sendfile or local problem with Lighttpd? Miroslav Lachman From owner-freebsd-stable@FreeBSD.ORG Sun Jan 24 14:38:10 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 32AE2106566C; Sun, 24 Jan 2010 14:38:10 +0000 (UTC) (envelope-from romain.garbage@gmail.com) Received: from mail-iw0-f200.google.com (mail-iw0-f200.google.com [209.85.223.200]) by mx1.freebsd.org (Postfix) with ESMTP id DE7518FC08; Sun, 24 Jan 2010 14:38:09 +0000 (UTC) Received: by iwn38 with SMTP id 38so2283386iwn.11 for ; Sun, 24 Jan 2010 06:38:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=YPvXNvN6wfnrvRxnY66iJvIHVXrKZwA4zVPwoAKDY5g=; b=CergfLSOnBQdM5hR20uF1CRax6vvnrpf02BBkoWcRbI9u2BEoJnsIKmczMLOKevOuX VgajDh1YN9a7MHioCmQBbcg/syUbK0P23s+PIO9c7qglZHaN+evq57+BULVt+YyH5kgi 7GseOpczHYTvqGoHVMW1hDDXewpKlqP1cvBBE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=kwUwjBXSmtDnnSXWbPkWR3ijQlk6JvYIh2qVgRZB9CiWYN4w4RaC2sMDj6e2aO8jzz pubfjwLOmYpBFepmbF7cChoAaUsTW4FTRUL5L8FYvq7jPU9SwJPz1nHxYccPZ/wQu8Ti Idk5ecQAvklc1yR/O3sQYHEY5zFaG07khkMEQ= MIME-Version: 1.0 Received: by 10.231.145.206 with SMTP id e14mr3258613ibv.10.1264343888786; Sun, 24 Jan 2010 06:38:08 -0800 (PST) In-Reply-To: References: <20100122041237.GA22312@gothschlampen.com> Date: Sun, 24 Jan 2010 15:38:08 +0100 Message-ID: <7ab0356e1001240638r6cd56b91h47852cb3591b7446@mail.gmail.com> From: Romain Garbage To: Dan Naumov Content-Type: text/plain; charset=UTF-8 Cc: FreeBSD-STABLE Mailing List , "Thomas K." , freebsd-questions@freebsd.org Subject: Re: Loader, MBR and the boot process X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 24 Jan 2010 14:38:10 -0000 2010/1/22, Dan Naumov : > Putting the swap into it's own slice and then putting FreeBSD into > it's own slice worked fine. So why the hell can't they both coexist in > 1 slice if the swap comes first? Similar problem here: I have a full-zfs system in a bsd slice, but I have the zfs-freebsd partition before the swap one. The problem is that the system doesn't seem to detect the swap partition partition (I see "swapon: /dev/ada0s1b: No such file or directory" during boot) % bsdlabel /dev/ada0s1 # /dev/ada0s1: 8 partitions: # size offset fstype [fsize bsize bps/cpg] a: 53043200 0 ZFS b: 9883342 53043200 swap c: 62926542 0 unused 0 0 # "raw" part, don't edit but to see ada0s1b in /dev/ I have to reload geom_bsd module (loading it at boot time doesn't work). Even though (but this seems to be another problem): % sudo swapon /dev/ada0s1b swapon: /dev/ada0s1b: Operation not permitted Regards, Romain From owner-freebsd-stable@FreeBSD.ORG Sun Jan 24 15:41:46 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7E3881065696 for ; Sun, 24 Jan 2010 15:41:46 +0000 (UTC) (envelope-from john@dexter.starfire.mn.org) Received: from dexter.starfire.mn.org (starfire.skypoint.net [173.8.102.29]) by mx1.freebsd.org (Postfix) with ESMTP id 2D4BA8FC0C for ; Sun, 24 Jan 2010 15:41:45 +0000 (UTC) Received: (from john@localhost) by dexter.starfire.mn.org (8.11.3/8.11.3) id o0OFTlZ72385; Sun, 24 Jan 2010 09:29:47 -0600 (CST) (envelope-from john) Date: Sun, 24 Jan 2010 09:29:47 -0600 From: John To: Dan Naumov Message-ID: <20100124092947.B72039@starfire.mn.org> References: <20100122041237.GA22312@gothschlampen.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: ; from dan.naumov@gmail.com on Fri, Jan 22, 2010 at 07:02:53AM +0200 Cc: FreeBSD-STABLE Mailing List , "Thomas K." , freebsd-questions@freebsd.org Subject: Re: Loader, MBR and the boot process X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 24 Jan 2010 15:41:46 -0000 On Fri, Jan 22, 2010 at 07:02:53AM +0200, Dan Naumov wrote: > On Fri, Jan 22, 2010 at 6:49 AM, Dan Naumov wrote: > > On Fri, Jan 22, 2010 at 6:12 AM, Thomas K. wrote: > >> On Fri, Jan 22, 2010 at 05:57:23AM +0200, Dan Naumov wrote: > >> > >> Hi, > >> > >>> I recently found a nifty "FreeBSD ZFS root installation script" and > >>> been reworking it a bit to suit my needs better, including changing it > >>> from GPT to MBR partitioning. However, I was stumped, even though I > >>> had done everything right (or so I thought), the system would get > >>> stuck at Loader and refuse to go anywhere. After trying over a dozen > >> > >> probably this line is the cause: > >> > >> dd if=/mnt2/boot/zfsboot of=/dev/"${TARGETDISK}"s1a skip=1 seek=1024 > >> > >> Unless by "swap first" you meant the on-disk location, and not the > >> partition letter. If swap is partition "a", you're writing the loader > >> into swapspace. > >> > >> > >> Regards, > >> Thomas > > > > At first you made me feel silly, but then I decided to double-check, I > > uncommented the swap line in the partitioning part again, ensured I > > was writing the bootloader to "${TARGETDISK}"s1b and ran the script. > > Same problem, hangs at loader. Again, if I comment out the swap, > > giving the entire slice to ZFS and then write the bootloader to > > "${TARGETDISK}"s1a, run the script, everything works. > > I have also just tested creating 2 slices, like this: > > gpart create -s mbr "${TARGETDISK}" > gpart add -s 3G -t freebsd "${TARGETDISK}" > gpart create -s BSD "${TARGETDISK}"s1 > gpart add -t freebsd-swap "${TARGETDISK}"s1 > > gpart add -t freebsd "${TARGETDISK}" > gpart create -s BSD "${TARGETDISK}"s2 > gpart add -t freebsd-zfs "${TARGETDISK}"s2 > > gpart set -a active -i 2 "${TARGETDISK}" > gpart bootcode -b /mnt2/boot/boot0 "${TARGETDISK}" > > > and later: > > dd if=/mnt2/boot/zfsboot of=/dev/"${TARGETDISK}"s2 count=1 > dd if=/mnt2/boot/zfsboot of=/dev/"${TARGETDISK}"s2a skip=1 seek=1024 > > > Putting the swap into it's own slice and then putting FreeBSD into > it's own slice worked fine. So why the hell can't they both coexist in > 1 slice if the swap comes first? I know what the answer to this USED to be, but I don't know if it is still true (obviously, I think so, I or wouldn't waste your time). The filesystem code is all carefully written to avoid the very first few sector of the partition. That's because the partition table is there for the first filesystem of the slice (or disk). That's a tiny amout of space wasted, because it's also skipped on all the other filesystems even though there's not actually anything there, but it was a small inefficency, even in the 70's. Swap does not behave that way. SWAP will begin right at the slice boundry, with 0 offset. As long as it's not the first partition, no harm, no foul. If it IS the first partition, you just nuked your partition table. As long as SWAP owns the slice, again, no harm, no foul, but if there were filesystems BEHIND it, you just lost 'em. That's the way it always used to be, and I think it still is. SWAP can only be first if it is the ONLY thing using that slice (disk), otherwise, you need a filesystem first to protect the partition table. -- John Lind john@starfire.MN.ORG From owner-freebsd-stable@FreeBSD.ORG Sun Jan 24 15:59:14 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7629E106568F; Sun, 24 Jan 2010 15:59:14 +0000 (UTC) (envelope-from dan.naumov@gmail.com) Received: from mail-yw0-f197.google.com (mail-yw0-f197.google.com [209.85.211.197]) by mx1.freebsd.org (Postfix) with ESMTP id 18ED18FC1B; Sun, 24 Jan 2010 15:59:13 +0000 (UTC) Received: by ywh35 with SMTP id 35so2143495ywh.7 for ; Sun, 24 Jan 2010 07:59:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=zlZM2cWzVhqN2QvRpv6mWtSDfBXJT9EJPE9cHME4iLI=; b=X/x1QYhj2WtTWehGsJC5GyuS7t3AbBcAhvCevk3xMJeYtnh7X3WZFOxT51P9Eh0Z8+ 5xCMvwoHbg08sgSBPy5RyN3IOmyELptbJDi681Z1a4kQ7GlJXpydFhDwE2WljBV2llTK Qa/ghqKMEHkcIa+wr06/X/Ll9Jx4M8b4UeZaM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=WQR+i7fEge+9Kd4k3DK7auxbn2CNTQJbngPjAQ/8HHGrFUjBEiWxbpuqf2lPMwXkyz G1c6Nw/E1Vd1vkiwioHbp/6tsdNlNm+YY1wxh6HjxPFIsIXNkikLVP1HjjmJYHXoDARc gofNW6BEntk5UmCCzvujNO5pR0+eVoO1DDwrQ= MIME-Version: 1.0 Received: by 10.101.10.24 with SMTP id n24mr6614152ani.78.1264348753300; Sun, 24 Jan 2010 07:59:13 -0800 (PST) In-Reply-To: <20100124092947.B72039@starfire.mn.org> References: <20100122041237.GA22312@gothschlampen.com> <20100124092947.B72039@starfire.mn.org> Date: Sun, 24 Jan 2010 17:59:13 +0200 Message-ID: From: Dan Naumov To: John Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: FreeBSD-STABLE Mailing List , "Thomas K." , freebsd-questions@freebsd.org Subject: Re: Loader, MBR and the boot process X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 24 Jan 2010 15:59:14 -0000 On Sun, Jan 24, 2010 at 5:29 PM, John wrote: > On Fri, Jan 22, 2010 at 07:02:53AM +0200, Dan Naumov wrote: >> On Fri, Jan 22, 2010 at 6:49 AM, Dan Naumov wrote= : >> > On Fri, Jan 22, 2010 at 6:12 AM, Thomas K. wro= te: >> >> On Fri, Jan 22, 2010 at 05:57:23AM +0200, Dan Naumov wrote: >> >> >> >> Hi, >> >> >> >>> I recently found a nifty "FreeBSD ZFS root installation script" and >> >>> been reworking it a bit to suit my needs better, including changing = it >> >>> from GPT to MBR partitioning. However, I was stumped, even though I >> >>> had done everything right (or so I thought), the system would get >> >>> stuck at Loader and refuse to go anywhere. After trying over a dozen >> >> >> >> probably this line is the cause: >> >> >> >> dd if=3D/mnt2/boot/zfsboot of=3D/dev/"${TARGETDISK}"s1a skip=3D1 seek= =3D1024 >> >> >> >> Unless by "swap first" you meant the on-disk location, and not the >> >> partition letter. If swap is partition "a", you're writing the loader >> >> into swapspace. >> >> >> >> >> >> Regards, >> >> Thomas >> > >> > At first you made me feel silly, but then I decided to double-check, I >> > uncommented the swap line in the partitioning part again, ensured I >> > was writing the bootloader to "${TARGETDISK}"s1b and ran the script. >> > Same problem, hangs at loader. Again, if I comment out the swap, >> > giving the entire slice to ZFS and then write the bootloader to >> > "${TARGETDISK}"s1a, run the script, everything works. >> >> I have also just tested creating 2 slices, like this: >> >> gpart create -s mbr "${TARGETDISK}" >> gpart add -s 3G -t freebsd "${TARGETDISK}" >> gpart create -s BSD "${TARGETDISK}"s1 >> gpart add -t freebsd-swap "${TARGETDISK}"s1 >> >> gpart add -t freebsd "${TARGETDISK}" >> gpart create -s BSD "${TARGETDISK}"s2 >> gpart add -t freebsd-zfs "${TARGETDISK}"s2 >> >> gpart set -a active -i 2 "${TARGETDISK}" >> gpart bootcode -b /mnt2/boot/boot0 "${TARGETDISK}" >> >> >> and later: >> >> dd if=3D/mnt2/boot/zfsboot of=3D/dev/"${TARGETDISK}"s2 count=3D1 >> dd if=3D/mnt2/boot/zfsboot of=3D/dev/"${TARGETDISK}"s2a skip=3D1 seek=3D= 1024 >> >> >> Putting the swap into it's own slice and then putting FreeBSD into >> it's own slice worked fine. So why the hell can't they both coexist in >> 1 slice if the swap comes first? > > I know what the answer to this USED to be, but I don't know if it is > still true (obviously, I think so, I or wouldn't waste your time). > > The filesystem code is all carefully written to avoid the very > first few sector of the partition. =A0That's because the partition > table is there for the first filesystem of the slice (or disk). > That's a tiny amout of space wasted, because it's also skipped on > all the other filesystems even though there's not actually anything > there, but it was a small inefficency, even in the 70's. > > Swap does not behave that way. =A0SWAP will begin right at the slice > boundry, with 0 offset. =A0As long as it's not the first partition, no > harm, no foul. =A0If it IS the first partition, you just nuked your parti= tion > table. =A0As long as SWAP owns the slice, again, no harm, no foul, but > if there were filesystems BEHIND it, you just lost 'em. > > That's the way it always used to be, and I think it still is. =A0SWAP can > only be first if it is the ONLY thing using that slice (disk), otherwise, > you need a filesystem first to protect the partition table. > -- > > John Lind > john@starfire.MN.ORG This explanation does sound logical, but holy crap, if this is the case, you'd think there would be bells, whistles and huge red label warnings in EVERY FreeBSD installation / partitioning guide out there warning people to not put swap first (unless given a dedicated slice) under any circumstances. The warnings were nowhere to be seen and lots of pointy hair first greyed and were then lost during the process of me trying to figure out why my system would install but wouldn't boot. - Sincerely, Dan Naumov From owner-freebsd-stable@FreeBSD.ORG Sun Jan 24 16:36:23 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6C1E1106566B; Sun, 24 Jan 2010 16:36:23 +0000 (UTC) (envelope-from dan.naumov@gmail.com) Received: from mail-yw0-f197.google.com (mail-yw0-f197.google.com [209.85.211.197]) by mx1.freebsd.org (Postfix) with ESMTP id 037438FC0C; Sun, 24 Jan 2010 16:36:22 +0000 (UTC) Received: by ywh35 with SMTP id 35so2155988ywh.7 for ; Sun, 24 Jan 2010 08:36:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:content-type; bh=i/+uDXn7ijsjDRMI+huRYoteHW8xWKP71eiWT2QtTwI=; b=XB5DGEvb22DO3uAcGFpTzF8+VqgdyknX3ERVi5zdtuvJajCWjxSwKlv2n1rswFcVlr XZ5OJp0ns7wOrDGTckhxS+jfMOR/Et2iQjUDEBnHQ4D/t+N9nr5SKO98KcYLsARBg0p/ sHZta9cRKYK4BOROZL0bhv8jdoREApwcQJIKI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=SmdO0NyTLyazmK8ukteUiPIdDrSe3JRmt41SOdrf/DH9VvBOpKR1Wwbxn+hup7o9wv jyvG34zoxkjvwFFHzJIl6CtHlu38DBqlij9Bb3CyreeFMGblF1Hf7awFv+GU7wqEpuOO ypaMXtb0imTmte4srJrrS70UPeDZgAKG7RuJ0= MIME-Version: 1.0 Received: by 10.100.235.36 with SMTP id i36mr3795152anh.104.1264350982055; Sun, 24 Jan 2010 08:36:22 -0800 (PST) Date: Sun, 24 Jan 2010 18:36:22 +0200 Message-ID: From: Dan Naumov To: freebsd-fs@freebsd.org, freebsd-questions@freebsd.org, FreeBSD-STABLE Mailing List Content-Type: text/plain; charset=ISO-8859-1 Cc: Subject: 8.0-RELEASE/amd64 - full ZFS install - low read and write disk performance X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Jan 2010 16:36:23 -0000 Note: Since my issue is slow performance right off the bat and not performance degradation over time, I decided to start a separate discussion. After installing a fresh pure ZFS 8.0 system and building all my ports, I decided to do some benchmarking. At this point, about a dozen of ports has been built installed and the system has been up for about 11 hours, No heavy background services have been running, only SSHD and NTPD: ================================================================================== bonnie -s 8192: -------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 8192 23821 61.7 22311 19.2 13928 13.7 25029 49.6 44806 17.2 135.0 3.1 During the process, TOP looks like this: last pid: 83554; load averages: 0.31, 0.31, 0.37 up 0+10:59:01 17:24:19 33 processes: 2 running, 31 sleeping CPU: 0.1% user, 0.0% nice, 14.1% system, 0.7% interrupt, 85.2% idle Mem: 45M Active, 4188K Inact, 568M Wired, 144K Cache, 1345M Free Swap: 3072M Total, 3072M Free Oh wow, that looks low, alright, lets run it again, just to be sure: -------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 8192 18235 46.7 23137 19.9 13927 13.6 24818 49.3 44919 17.3 134.3 2.1 OK, let's reboot the machine and see what kind of numbers we get on a fresh boot: =============================================================== -------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 8192 21041 53.5 22644 19.4 13724 12.8 25321 48.5 43110 14.0 143.2 3.3 Nope, no help from the reboot, still very low speed. Here is my pool: =============================================================== zpool status pool: tank state: ONLINE scrub: none requested config: NAME STATE READ WRITE CKSUM tank ONLINE 0 0 0 mirror ONLINE 0 0 0 ad10s1a ONLINE 0 0 0 ad8s1a ONLINE 0 0 0 =============================================================== diskinfo -c -t /dev/ad10 /dev/ad10 512 # sectorsize 2000398934016 # mediasize in bytes (1.8T) 3907029168 # mediasize in sectors 3876021 # Cylinders according to firmware. 16 # Heads according to firmware. 63 # Sectors according to firmware. WD-WCAVY0301430 # Disk ident. I/O command overhead: time to read 10MB block 0.164315 sec = 0.008 msec/sector time to read 20480 sectors 3.030396 sec = 0.148 msec/sector calculated command overhead = 0.140 msec/sector Seek times: Full stroke: 250 iter in 7.309334 sec = 29.237 msec Half stroke: 250 iter in 5.156117 sec = 20.624 msec Quarter stroke: 500 iter in 8.147588 sec = 16.295 msec Short forward: 400 iter in 2.544309 sec = 6.361 msec Short backward: 400 iter in 2.007679 sec = 5.019 msec Seq outer: 2048 iter in 0.392994 sec = 0.192 msec Seq inner: 2048 iter in 0.332582 sec = 0.162 msec Transfer rates: outside: 102400 kbytes in 1.576734 sec = 64944 kbytes/sec middle: 102400 kbytes in 1.381803 sec = 74106 kbytes/sec inside: 102400 kbytes in 2.145432 sec = 47729 kbytes/sec =============================================================== diskinfo -c -t /dev/ad8 /dev/ad8 512 # sectorsize 2000398934016 # mediasize in bytes (1.8T) 3907029168 # mediasize in sectors 3876021 # Cylinders according to firmware. 16 # Heads according to firmware. 63 # Sectors according to firmware. WD-WCAVY1611513 # Disk ident. I/O command overhead: time to read 10MB block 0.176820 sec = 0.009 msec/sector time to read 20480 sectors 2.966564 sec = 0.145 msec/sector calculated command overhead = 0.136 msec/sector Seek times: Full stroke: 250 iter in 7.993339 sec = 31.973 msec Half stroke: 250 iter in 5.944923 sec = 23.780 msec Quarter stroke: 500 iter in 9.744406 sec = 19.489 msec Short forward: 400 iter in 2.511171 sec = 6.278 msec Short backward: 400 iter in 2.233714 sec = 5.584 msec Seq outer: 2048 iter in 0.427523 sec = 0.209 msec Seq inner: 2048 iter in 0.341185 sec = 0.167 msec Transfer rates: outside: 102400 kbytes in 1.516305 sec = 67533 kbytes/sec middle: 102400 kbytes in 1.351877 sec = 75747 kbytes/sec inside: 102400 kbytes in 2.090069 sec = 48994 kbytes/sec =============================================================== The exact same disks, on the exact same machine, are well capable of 65+ mb/s throughput (tested with ATTO multiple times) with different block sizes using Windows 2008 Server and NTFS. So what would be the cause of these very low Bonnie result numbers in my case? Should I try some other benchmark and if so, with what parameters? - Sincerely, Dan Naumov From owner-freebsd-stable@FreeBSD.ORG Sun Jan 24 16:36:57 2010 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7E547106568B; Sun, 24 Jan 2010 16:36:57 +0000 (UTC) (envelope-from ohartman@mail.zedat.fu-berlin.de) Received: from outpost1.zedat.fu-berlin.de (outpost1.zedat.fu-berlin.de [130.133.4.66]) by mx1.freebsd.org (Postfix) with ESMTP id 3A89B8FC18; Sun, 24 Jan 2010 16:36:56 +0000 (UTC) Received: from inpost2.zedat.fu-berlin.de ([130.133.4.69]) by outpost1.zedat.fu-berlin.de (Exim 4.69) with esmtp (envelope-from ) id <1NZ5SJ-0003pf-Se>; Sun, 24 Jan 2010 17:36:55 +0100 Received: from e178029033.adsl.alicedsl.de ([85.178.29.33] helo=thor.walstatt.dyndns.org) by inpost2.zedat.fu-berlin.de (Exim 4.69) with esmtpsa (envelope-from ) id <1NZ5SJ-0001fK-BU>; Sun, 24 Jan 2010 17:36:55 +0100 Message-ID: <4B5C771C.4040605@mail.zedat.fu-berlin.de> Date: Sun, 24 Jan 2010 17:36:44 +0100 From: "O. Hartmann" User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.1.7) Gecko/20100123 Thunderbird/3.0.1 MIME-Version: 1.0 To: freebsd-questions@freebsd.org, freebsd-stable@FreeBSD.org Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: 85.178.29.33 Cc: Subject: PCIe audio cards: what is tob be preferred with FreeBSD 8.0/9-CURRENT? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 24 Jan 2010 16:36:57 -0000 Well, At this very moment I utilise a M-Audio 5.1 PCI-audio board with which I'm really satisfied. My next box doesn't have PCI slots at all (ASUS P6T6-WS Revolution) and due to the fact I'm using Windows 7 sometimes for recreational gaming, I'd like to have a moderate expensive audio board with the workstation which is supported by FreeBSD 8/9. In the past - means two or three ywars ago, I had problems with Soundblaster PCIe boards, so I was recommended avoiding those and choosing the more elabotrated M-Audio cards for the PCI bus. At this moment, I look for the Soundblaster X-Fi range of PCIe cards, but I'm not sure whether they are supported by FreeBSd 8/9. Any suggestions? Regards, Oliver From owner-freebsd-stable@FreeBSD.ORG Sun Jan 24 16:49:15 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F37CB1065672; Sun, 24 Jan 2010 16:49:14 +0000 (UTC) (envelope-from mavbsd@gmail.com) Received: from mail-fx0-f226.google.com (mail-fx0-f226.google.com [209.85.220.226]) by mx1.freebsd.org (Postfix) with ESMTP id 07B988FC17; Sun, 24 Jan 2010 16:49:13 +0000 (UTC) Received: by fxm26 with SMTP id 26so334084fxm.13 for ; Sun, 24 Jan 2010 08:49:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :x-enigmail-version:content-type:content-transfer-encoding; bh=CO/wPqQnCfpx5JrmnoT+31Rwv8hdZ1euih4gMI6S+WU=; b=lXrW9uQHEPTDEltBSwRoqmEFfg/WcsiZXFOY1RMYU1P5cUdXTC3BUpMcggTrHhuvFh LiJ84/Vzb+NUiFGFH9UTn2bVfee64J+gcjBVzGtZ5eT4fMIfA92xNYe5csB8hoQ0oOcC Svac1k9LqY8zzKXcULo5jAkc+SmYQNWb0W9o0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:content-type :content-transfer-encoding; b=nebP95A5xsak88y9d99hJyl5iiFmXb/IPMofub/E4lthItXXW93dpKjgCl0ZM1Xqwl /qHsB3woKwYxFc4i1VJ9qvJkWUSWCk9WjC1veT/HJjGFBLozw/AsVEbJ5cx0s42Mnm/q S+Bi4f4dXFbHwg1iihR0xmSM66MxwnW2P+XBE= Received: by 10.223.59.3 with SMTP id j3mr98510fah.46.1264351752927; Sun, 24 Jan 2010 08:49:12 -0800 (PST) Received: from mavbook.mavhome.dp.ua (pc.mavhome.dp.ua [212.86.226.226]) by mx.google.com with ESMTPS id 15sm2297269fxm.2.2010.01.24.08.49.11 (version=SSLv3 cipher=RC4-MD5); Sun, 24 Jan 2010 08:49:11 -0800 (PST) Sender: Alexander Motin Message-ID: <4B5C79CF.9070504@FreeBSD.org> Date: Sun, 24 Jan 2010 18:48:15 +0200 From: Alexander Motin User-Agent: Thunderbird 2.0.0.23 (X11/20091212) MIME-Version: 1.0 To: gary.jennejohn@freenet.de References: <4B55D9D4.1000008@FreeBSD.org> <201001231407.o0NE7l8j002620@triton8.kn-bremen.de> <20100123184619.257203d9@ernst.jennejohn.org> In-Reply-To: <20100123184619.257203d9@ernst.jennejohn.org> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: FreeBSD-Current , FreeBSD Stable , Juergen Lock Subject: Re: Pack of CAM improvements X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 24 Jan 2010 16:49:15 -0000 Gary Jennejohn wrote: > I started seeing a problem a few days ago with one of my DVD drives (a > burner at cd0) under 9-current, which makes it impossible to use it even > to simply read a DVD. > > Here the (rather strange IMO) output in dmesg: > > cd0: Removable CD-ROM SCSI-0 device > cd0: 66.700MB/s transfers (UDMA4, PIO size 65534bytes) > cd0: Attempt to query device size failed: UNIT ATTENTION, Power on, reset, > or bus device reset occurred > cd1 at ata0 bus 0 scbus6 target 1 lun 0 > cd1: Removable CD-ROM SCSI-0 device > cd1: 33.300MB/s transfers (UDMA2, PIO size 65534bytes) > cd1: Attempt to query device size failed: NOT READY, Medium not present - > tray closed > > I haven't the foggiest why cd0 behaves diffrently from cd1, which is a > vanilla DVD drive and just works. I am not sure yet what triggered these changes. May be just some timing issue. That UNIT ATTENTION seems reasonable, as reset indeed just happened there. The real problem is that CAM had several limitations in SCSI status handling, when working with ATAPI or USB devices. It made request processing stop in some cases, where retries would be expected. New patch version should handle this and some other problems: http://people.freebsd.org/~mav/cam-ata.20100124.patch Try it please. Thanks. -- Alexander Motin From owner-freebsd-stable@FreeBSD.ORG Sun Jan 24 17:42:23 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 577091065670; Sun, 24 Jan 2010 17:42:23 +0000 (UTC) (envelope-from dan.naumov@gmail.com) Received: from mail-yx0-f171.google.com (mail-yx0-f171.google.com [209.85.210.171]) by mx1.freebsd.org (Postfix) with ESMTP id DFCC28FC1C; Sun, 24 Jan 2010 17:42:22 +0000 (UTC) Received: by yxe1 with SMTP id 1so2275433yxe.3 for ; Sun, 24 Jan 2010 09:42:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type; bh=j88x6XhvR75nuWm2yTKP7/tyUJkjzQo0D5wtSP5t/Gs=; b=NH2HzacZQP2uCFh5RJWrbwrJrlt8RcQ5rex70CUV4KW8vReXnVG0sESFFh6wQBuzA9 r6wIFcX+QUSMFBdbGpZ0FeRer3PQnqsTWp+5PJWXA9VFqD2vszEkVMMlF4CF+oAxLRmM 3y+4TBhF2sxcUyHlYofpJf9ODXk/eF1HMuBN8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=cO7S2cshb89hsDgyAqO9AzCVXz6C+xdAI/1JC1SmD1cESNpsUqHKAPShRTE3cKyGvY VVAv/Ez07pniyN8THgxN+uHSgMxU2vXcbnzqZedZNRztIa4KPo7CyFZzmyv/HMqHAZpf wBTYDvk9GXaO7O7EDLL41VJYTdG8jVszUFebI= MIME-Version: 1.0 Received: by 10.101.6.22 with SMTP id j22mr6557167ani.224.1264354942041; Sun, 24 Jan 2010 09:42:22 -0800 (PST) In-Reply-To: <883b2dc51001240905r4cfbf830i3b9b400969ac261b@mail.gmail.com> References: <883b2dc51001240905r4cfbf830i3b9b400969ac261b@mail.gmail.com> Date: Sun, 24 Jan 2010 19:42:22 +0200 Message-ID: From: Dan Naumov To: Jason Edwards , FreeBSD-STABLE Mailing List , freebsd-fs@freebsd.org, freebsd-questions@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Cc: Subject: Re: 8.0-RELEASE/amd64 - full ZFS install - low read and write disk performance X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Jan 2010 17:42:23 -0000 On Sun, Jan 24, 2010 at 7:05 PM, Jason Edwards wrote: > Hi Dan, > > I read on FreeBSD mailinglist you had some performance issues with ZFS. > Perhaps i can help you with that. > > You seem to be running a single mirror, which means you won't have any speed > benefit regarding writes, and usually RAID1 implementations offer little to > no acceleration to read requests also; some even just read from the master > disk and don't touch the 'slave' mirrored disk unless when writing. ZFS is > alot more modern however, although i did not test performance of its mirror > implementation. > > But, benchmarking I/O can be tricky: > > 1) you use bonnie, but bonnie's tests are performed without a 'cooldown' > period between the tests; meaning that when test 2 starts, data from test 1 > is still being processed. For single disks and simple I/O this is not so > bad, but for large write-back buffers and more complex I/O buffering, this > may be inappropriate. I had patched bonnie some time in the past, but if you > just want a MB/s number you can use DD for that. > > 2) The diskinfo tiny benchmark is single queue only i assume, meaning that > it would not scale well or at all on RAID-arrays. Actual filesystems on > RAID-arrays use multiple-queue; meaning it would not read one sector at a > time, but read 8 blocks (of 16KiB) "ahead"; this is called read-ahead and > for traditional UFS filesystems its controlled by the sysctl vfs.read_max > variable. ZFS works differently though, but you still need a "real" > benchmark. > > 3) You need low-latency hardware; in particular, no PCI controller should be > used. Only PCI-express based controllers or chipset-integrated Serial ATA > cotrollers have proper performance. PCI can hurt performance very badly, and > has high interrupt CPU usage. Generally you should avoid PCI. PCI-express is > fine though, its a completely different interface that is in many ways the > opposite of what PCI was. > > 4) Testing actual realistic I/O performance (in IOps) is very difficult. But > testing sequential performance should be alot easier. You may try using dd > for this. > > > For example, you can use dd on raw devices: > > dd if=/dev/ad4 of=/dev/null bs=1M count=1000 > > I will explain each parameter: > > if=/dev/ad4 is the input file, the "read source" > > of=/dev/null is the output file, the "write destination". /dev/null means it > just goes no-where; so this is a read-only benchmark > > bs=1M is the blocksize, howmuch data to transfer per time. default is 512 or > the sector size; but that's very slow. A value between 64KiB and 1024KiB is > appropriate. bs=1M will select 1MiB or 1024KiB. > > count=1000 means transfer 1000 pieces, and with bs=1M that means 1000 * 1MiB > = 1000MiB. > > > > This example was raw reading sequentially from the start of the device > /dev/ad4. If you want to test RAIDs, you need to work at the filesystem > level. You can use dd for that too: > > dd if=/dev/zero of=/path/to/ZFS/mount/zerofile.000 bs=1M count=2000 > > This command will read from /dev/zero (all zeroes) and write to a file on > ZFS-mounted filesystem, it will create the file "zerofile.000" and write > 2000MiB of zeroes to that file. > So this command tests write-performance of the ZFS-mounted filesystem. To > test read performance, you need to clear caches first by unmounting that > filesystem and re-mounting it again. This would free up memory containing > parts of the filesystem as cached (reported in top as "Inact(ive)" instead > of "Free"). > > Please do make sure you double-check a dd command before running it, and run > as normal user instead of root. A wrong dd command may write to the wrong > destination and do things you don't want. The only real thing you need to > check is the write destination (of=....). That's where dd is going to write > to, so make sure its the target you intended. A common mistake made by > myself was to write dd of=... if=... (starting with of instead of if) and > thus actually doing something the other way around than what i was meant to > do. This can be disastrous if you work with live data, so be careful! ;-) > > Hope any of this was helpful. During the dd benchmark, you can of course > open a second SSH terminal and start "gstat" to see the devices current I/O > stats. > > Kind regards, > Jason Hi and thanks for your tips, I appreciate it :) [jago@atombsd ~]$ dd if=/dev/zero of=/home/jago/test1 bs=1M count=1024 1024+0 records in 1024+0 records out 1073741824 bytes transferred in 36.206372 secs (29656156 bytes/sec) [jago@atombsd ~]$ dd if=/dev/zero of=/home/jago/test2 bs=1M count=4096 4096+0 records in 4096+0 records out 4294967296 bytes transferred in 143.878615 secs (29851325 bytes/sec) This works out to 1GB in 36,2 seconds / 28,2mb/s in the first test and 4GB in 143.8 seconds / 28,4mb/s and somewhat consistent with the bonnie results. It also sadly seems to confirm the very slow speed :( The disks are attached to a 4-port Sil3124 controller and again, my Windows benchmarks showing 65mb/s+ were done on exact same machine, with same disks attached to the same controller. Only difference was that in Windows the disks weren't in a mirror configuration but were tested individually. I do understand that a mirror setup offers roughly the same write speed as individual disk, while the read speed usually varies from "equal to individual disk speed" to "nearly the throughput of both disks combined" depending on the implementation, but there is no obvious reason I am seeing why my setup offers both read and write speeds roughly 1/3 to 1/2 of what the individual disks are capable of. Dmesg shows: atapci0: port 0x1000-0x100f mem 0x90108000-0x9010807f,0x90100000-0x90107fff irq 21 at device 0.0 on pci4 ad8: 1907729MB at ata4-master SATA300 ad10: 1907729MB at ata5-master SATA300 I do recall also testing an alternative configuration in the past, where I would boot off an UFS disk and have the ZFS mirror consist of 2 discs directly. The bonnie numbers in that case were in line with my expectations, I was seeing 65-70mb/s. Note: again, exact same hardware, exact same disks attached to the exact same controller. In my knowledge, Solaris/OpenSolaris has an issue where they have to automatically disable disk cache if ZFS is used on top of partitions instead of raw disks, but to my knowledge (I recall reading this from multiple reputable sources) this issue does not affect FreeBSD. - Sincerely, Dan Naumov From owner-freebsd-stable@FreeBSD.ORG Sun Jan 24 17:54:40 2010 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 97BF81065670; Sun, 24 Jan 2010 17:54:40 +0000 (UTC) (envelope-from gary.jennejohn@freenet.de) Received: from mout5.freenet.de (mout5.freenet.de [IPv6:2001:748:100:40::2:7]) by mx1.freebsd.org (Postfix) with ESMTP id 2896F8FC0C; Sun, 24 Jan 2010 17:54:40 +0000 (UTC) Received: from [195.4.92.15] (helo=5.mx.freenet.de) by mout5.freenet.de with esmtpa (ID gary.jennejohn@freenet.de) (port 25) (Exim 4.70 #1) id 1NZ6fW-0001q6-Tt; Sun, 24 Jan 2010 18:54:38 +0100 Received: from p57ae25fd.dip0.t-ipconnect.de ([87.174.37.253]:32268 helo=ernst.jennejohn.org) by 5.mx.freenet.de with esmtpa (ID gary.jennejohn@freenet.de) (port 25) (Exim 4.69 #94) id 1NZ6fW-0000xk-Mo; Sun, 24 Jan 2010 18:54:38 +0100 Date: Sun, 24 Jan 2010 18:54:35 +0100 From: Gary Jennejohn To: Alexander Motin Message-ID: <20100124185435.54b5fef6@ernst.jennejohn.org> In-Reply-To: <4B5C79CF.9070504@FreeBSD.org> References: <4B55D9D4.1000008@FreeBSD.org> <201001231407.o0NE7l8j002620@triton8.kn-bremen.de> <20100123184619.257203d9@ernst.jennejohn.org> <4B5C79CF.9070504@FreeBSD.org> X-Mailer: Claws Mail 3.7.4 (GTK+ 2.16.2; amd64-portbld-freebsd9.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: FreeBSD-Current , FreeBSD Stable , Juergen Lock Subject: Re: Pack of CAM improvements X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: gary.jennejohn@freenet.de List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Jan 2010 17:54:40 -0000 On Sun, 24 Jan 2010 18:48:15 +0200 Alexander Motin wrote: > Gary Jennejohn wrote: > > I started seeing a problem a few days ago with one of my DVD drives (a > > burner at cd0) under 9-current, which makes it impossible to use it even > > to simply read a DVD. > > > > Here the (rather strange IMO) output in dmesg: > > > > cd0: Removable CD-ROM SCSI-0 device > > cd0: 66.700MB/s transfers (UDMA4, PIO size 65534bytes) > > cd0: Attempt to query device size failed: UNIT ATTENTION, Power on, reset, > > or bus device reset occurred > > cd1 at ata0 bus 0 scbus6 target 1 lun 0 > > cd1: Removable CD-ROM SCSI-0 device > > cd1: 33.300MB/s transfers (UDMA2, PIO size 65534bytes) > > cd1: Attempt to query device size failed: NOT READY, Medium not present - > > tray closed > > > > I haven't the foggiest why cd0 behaves diffrently from cd1, which is a > > vanilla DVD drive and just works. > > I am not sure yet what triggered these changes. May be just some timing > issue. That UNIT ATTENTION seems reasonable, as reset indeed just > happened there. The real problem is that CAM had several limitations in > SCSI status handling, when working with ATAPI or USB devices. It made > request processing stop in some cases, where retries would be expected. > > New patch version should handle this and some other problems: > http://people.freebsd.org/~mav/cam-ata.20100124.patch > > Try it please. Thanks. > This patch works extremely well! Thanks. --- Gary Jennejohn From owner-freebsd-stable@FreeBSD.ORG Sun Jan 24 18:03:47 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C0B4D106568B for ; Sun, 24 Jan 2010 18:03:47 +0000 (UTC) (envelope-from jhellenthal@gmail.com) Received: from qw-out-2122.google.com (qw-out-2122.google.com [74.125.92.25]) by mx1.freebsd.org (Postfix) with ESMTP id 70D048FC13 for ; Sun, 24 Jan 2010 18:03:47 +0000 (UTC) Received: by qw-out-2122.google.com with SMTP id 5so88512qwd.7 for ; Sun, 24 Jan 2010 10:03:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:date:from:to:cc :subject:in-reply-to:message-id:references:user-agent :x-openpgp-key-id:x-openpgp-key-fingerprint:mime-version :content-type; bh=p49iSj/gLCbXj0bRP0UIfeaX0JzTaEAp2mvT/Ioxe7M=; b=UoD+cpSlAnD1pJalI09z+3ByPV+C01KFr+9rcZX5qsgrsTxvZERsxPpzcthjXTUsPG HtrtF4SAvJR/nWilvf3skMlpJ5iuv2lccvQ8hdLOiEm92uwGuJraWT3ixZOgvxlJ/Tms KqLnWswuOl7l8wmxHY4VMR3GZtj+kct4xnprg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:date:from:to:cc:subject:in-reply-to:message-id:references :user-agent:x-openpgp-key-id:x-openpgp-key-fingerprint:mime-version :content-type; b=FD6p7EwmG2Nz+eIpKeyRSlUOlyE6AJj+pTOFL/KIUNjU+dCWSLxDQ+dTrOFRVEwe73 qObUWhBLZdRBkd3Qh43DaZkptHJ3YYXS9IlSuvp2q45YOTv8WlVxut1q7dBq2CLoEhY7 RQZZBL0BSLw5UG4U+FQtcS0Y1b3S/mc8T3Qu0= Received: by 10.224.123.78 with SMTP id o14mr3530502qar.123.1264356226506; Sun, 24 Jan 2010 10:03:46 -0800 (PST) Received: from centel.dataix.local (ppp-23.134.dialinfree.com [209.172.23.134]) by mx.google.com with ESMTPS id 7sm9996811qwf.4.2010.01.24.10.03.41 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sun, 24 Jan 2010 10:03:45 -0800 (PST) Sender: "J. Hellenthal" Date: Sun, 24 Jan 2010 13:03:33 -0500 From: jhell To: spil.oss@gmail.com In-Reply-To: <5fbf03c21001240150r2064810n744694380ab8913a@mail.gmail.com> Message-ID: References: <5fbf03c21001240150r2064810n744694380ab8913a@mail.gmail.com> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) X-OpenPGP-Key-Id: 0x89D8547E X-OpenPGP-Key-Fingerprint: 85EF E26B 07BB 3777 76BE B12A 9057 8789 89D8 547E MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-stable@freebsd.org Subject: Re: Problem with alias length in base Sendmail X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 24 Jan 2010 18:03:47 -0000 On Sun, 24 Jan 2010 04:50, spil.oss@ wrote: > Hi All, > > Today I ran into the BUG documented in the aliases man-page. > > If you have compiled sendmail with DBM support instead of NEWDB, you > may have encountered problems in dbm(3) restricting a single alias to > about 1000 bytes of information. > > Looking at Sendmail, it is compiled with NEWDB so the restriction > would not apply. > > # sendmail -d0.1 -bv root > Version 8.14.3 > Compiled with: DNSMAP LOG MAP_REGEX MATCHGECOS MILTER MIME7TO8 MIME8TO7 > NAMED_BIND NETINET NETINET6 NETUNIX NEWDB NIS PIPELINING SCANF > STARTTLS TCPWRAPPERS USERDB XDEBUG > > If my alias (including whitespace) exceeds ca. 1000 characters, > running `make aliases` will report an error. > /etc/mail/aliases: line 320: alias too long > Resulting in an aliases.db file without the too long alias > 550 5.1.1 ... User unknown > Which means to me that the alias is simply skipped and the rest of the > aliases database is installed. > > There is a workaround documented with the bug in the man-page, but I'd > very much like to understand why this is failing. > > FreeBSD gw.example.org 7.2-RELEASE-p1 FreeBSD 7.2-RELEASE-p1 #2: Thu > Jun 11 12:58:02 CEST 2009 > root@gw.example.org:/usr/obj/usr/src/sys/MYKERNEL i386 > > Kind regards, > > Spil > That's either one hell of a pipe or the owner of that email address can be proud that no-one will ever email him/her ;) Can you post the alias in question ? Maybe there is another way that you could go about doing this if it is not just a test case trying to flaunt the adequate limits of sendmail. -- jhell From owner-freebsd-stable@FreeBSD.ORG Sun Jan 24 18:10:14 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 880791065672 for ; Sun, 24 Jan 2010 18:10:14 +0000 (UTC) (envelope-from spil.oss@googlemail.com) Received: from mail-px0-f183.google.com (mail-px0-f183.google.com [209.85.216.183]) by mx1.freebsd.org (Postfix) with ESMTP id 5CDA78FC1B for ; Sun, 24 Jan 2010 18:10:14 +0000 (UTC) Received: by pxi13 with SMTP id 13so1946021pxi.3 for ; Sun, 24 Jan 2010 10:10:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:reply-to:in-reply-to :references:date:message-id:subject:from:to:content-type :content-transfer-encoding; bh=G117QiQkFmjhgONiJs64FsXDceGvK0Cg3y8u/iHZc9Q=; b=l/5vY6qozZFvrINPCrnzTigEsN73AIo1N85sDn0VB0cGBNiKytS2bcfVpdDLSwa/Vu aRPjt18biy9+dnaAZ9uwniviGQL8vgvbZ30ypXWZbx7ES/kXVxxNczrQrubjWVOWt2IP TaZleKcPE5kAvV1Z0gc2nBdxko+KlqMO/4GxQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:content-type:content-transfer-encoding; b=mX6wSBRXDT1nnHGSqaZREQruSWwmWUjo/oJBF2Y70CxYzILzuCblJuCDstG0mw7FCb MJIkuWTPuNGydEdRVEh+qK29B5creYuM5goR5TbSPUjkeVSX3QLUOs8dE2jBljkbo9z4 VxbJJwsFj2jr0SCmPfbWobb10vklLrVJc8Zqw= MIME-Version: 1.0 Received: by 10.141.187.7 with SMTP id o7mr3141034rvp.35.1264356613755; Sun, 24 Jan 2010 10:10:13 -0800 (PST) In-Reply-To: References: <5fbf03c21001240150r2064810n744694380ab8913a@mail.gmail.com> Date: Sun, 24 Jan 2010 19:10:13 +0100 Message-ID: <5fbf03c21001241010j390d69f4j7c3a6ddb0424aaf8@mail.gmail.com> From: Spil Oss To: jhell , freebsd-stable@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Subject: Re: Problem with alias length in base Sendmail X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: spil.oss@gmail.com List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Jan 2010 18:10:14 -0000 Hi jhell, aliases can be used as mailing-lists........ (remember to also have a -owner alias if you wish to use it that way) And there is a work-around, also documented in the aliases man-page. split it up in multiple parts that are lists again mailinglist: mailinglist-part1, mailinglist-part2, mailinglist-part3 mailinglist-part1: recipient1@example.org, recipient2@example.net mailinglist-part2: recepient3@example.net, recipient4@example.org Still curious as to why the NEWDB in FreeBSD does not support more than ca. 1000-bytes in an alias. Kind regards, Spil. On Sun, Jan 24, 2010 at 7:03 PM, jhell wrote: > > On Sun, 24 Jan 2010 04:50, spil.oss@ wrote: >> >> Hi All, >> >> Today I ran into the BUG documented in the aliases man-page. >> >> =A0 =A0 =A0If you have compiled sendmail with DBM support instead =A0of = =A0NEWDB, >> =A0you >> =A0 =A0 =A0may =A0have =A0encountered problems in dbm(3) restricting a s= ingle alias >> to >> =A0 =A0 =A0about 1000 bytes =A0of =A0information. =A0 >> >> Looking at Sendmail, it is compiled with NEWDB so the restriction >> would not apply. >> >> # sendmail -d0.1 -bv root >> Version 8.14.3 >> Compiled with: DNSMAP LOG MAP_REGEX MATCHGECOS MILTER MIME7TO8 MIME8TO7 >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 NAMED_BIND NETINET NETINET6 NETUNIX NEWDB NI= S PIPELINING >> SCANF >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 STARTTLS TCPWRAPPERS USERDB XDEBUG >> >> If my alias (including whitespace) exceeds ca. 1000 characters, >> running `make aliases` will report an error. >> =A0/etc/mail/aliases: line 320: alias too long >> Resulting in an aliases.db file without the too long alias >> =A0550 5.1.1 ... User unknown >> Which means to me that the alias is simply skipped and the rest of the >> aliases database is installed. >> >> There is a workaround documented with the bug in the man-page, but I'd >> very much like to understand why this is failing. >> >> FreeBSD gw.example.org 7.2-RELEASE-p1 FreeBSD 7.2-RELEASE-p1 #2: Thu >> Jun 11 12:58:02 CEST 2009 >> root@gw.example.org:/usr/obj/usr/src/sys/MYKERNEL =A0i386 >> >> Kind regards, >> >> Spil >> > > That's either one hell of a pipe or the owner of that email address can b= e > proud that no-one will ever email him/her ;) > > Can you post the alias in question ? Maybe there is another way that you > could go about doing this if it is not just a test case trying to flaunt = the > adequate limits of sendmail. > > -- > > =A0jhell > > From owner-freebsd-stable@FreeBSD.ORG Sun Jan 24 18:12:05 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 202C21065679 for ; Sun, 24 Jan 2010 18:12:05 +0000 (UTC) (envelope-from svein-listmail@stillbilde.net) Received: from mail.stillbilde.net (unknown [IPv6:2002:51af:3dc3:0:20c:29ff:fece:79f3]) by mx1.freebsd.org (Postfix) with ESMTP id 9C23C8FC17 for ; Sun, 24 Jan 2010 18:12:04 +0000 (UTC) Received: from [IPv6:2002:51af:3dc3:0:7c6a:950e:1c80:15b0] (unknown [IPv6:2002:51af:3dc3:0:7c6a:950e:1c80:15b0]) (Authenticated sender: svein) by mail.stillbilde.net (Familien Skogens mail) with ESMTPSA id 173A222 for ; Sun, 24 Jan 2010 19:12:09 +0100 (CET) Message-ID: <4B5C8D72.2070003@stillbilde.net> Date: Sun, 24 Jan 2010 19:12:02 +0100 From: "Svein Skogen (Listmail Account)" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.7) Gecko/20100111 Lightning/1.0b1 Thunderbird/3.0.1 MIME-Version: 1.0 To: freebsd-stable@freebsd.org References: <661263379937@webmail51.yandex.ru> In-Reply-To: <661263379937@webmail51.yandex.ru> X-Enigmail-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Subject: Re: sendmail replacement X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 24 Jan 2010 18:12:05 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 13.01.2010 11:52, S.N.Grigoriev wrote: > Hi list, > > I would like to know if there is a way to completely > replace the base sendmail with a ports one. The goal > is to have corresponding files on the traditional places > (not in /usr/local) and to use the system sendmail > startup script but not /usr/local/etc/rc.d/sendmail.sh. > Every once in a while something along these lines pops up. The regular answer seems to be something along the "make.conf" or "src.conf" files, which will stop something from being compiled. Maybe we need a third conf file along the lines of base_remove.conf were we list the disabled stuff in src.conf, and the installworld make A) removes the installed version, and B) then removes/sets false the corresponding line in remove.conf (so versions installed from ports aren't touched). This would (potentially) solve the issue, but I'll be the first to admit it has about the same charm as driving a nail with a wrecking ball, but I'm sure some of the brighter minds can do something about it. //Svein - -- - --------+-------------------+------------------------------- /"\ |Svein Skogen | svein@d80.iso100.no \ / |Solberg Řstli 9 | PGP Key: 0xE5E76831 X |2020 Skedsmokorset | svein@jernhuset.no / \ |Norway | PGP Key: 0xCE96CE13 | | svein@stillbilde.net ascii | | PGP Key: 0x58CD33B6 ribbon |System Admin | svein-listmail@stillbilde.net Campaign|stillbilde.net | PGP Key: 0x22D494A4 +-------------------+------------------------------- |msn messenger: | Mobile Phone: +47 907 03 575 |svein@jernhuset.no | RIPE handle: SS16503-RIPE - --------+-------------------+------------------------------- If you really are in a hurry, mail me at svein-mobile@stillbilde.net This mailbox goes directly to my cellphone and is checked even when I'm not in front of my computer. - ------------------------------------------------------------ Picture Gallery: https://gallery.stillbilde.net/v/svein/ - ------------------------------------------------------------ -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.12 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAktcjXIACgkQODUnwSLUlKRT1ACfVYqGzYTkqinPBEvn/5AJA3Tg n+wAn2vB8seXpV65l8TB1lvv7H6j7mOx =KQ+9 -----END PGP SIGNATURE----- From owner-freebsd-stable@FreeBSD.ORG Sun Jan 24 18:12:31 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8994D106568D; Sun, 24 Jan 2010 18:12:31 +0000 (UTC) (envelope-from dan.naumov@gmail.com) Received: from mail-yw0-f197.google.com (mail-yw0-f197.google.com [209.85.211.197]) by mx1.freebsd.org (Postfix) with ESMTP id 1F9728FC0A; Sun, 24 Jan 2010 18:12:30 +0000 (UTC) Received: by ywh35 with SMTP id 35so2189749ywh.7 for ; Sun, 24 Jan 2010 10:12:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type; bh=Nudg+xoe53eItQvs+LtVZir/9Twc7UMwOIIF8NZIsgM=; b=ZRf6dBnvdGEUdr0v09fxRZJNHAokhpKN/nvlt0N3hnFR9w5DqTPV552wYi5Yat3npp SDYb0DVgP678/UtCaEK5JFyP3daj1nv2/n8uMwHKT3MS9BnEL8Ocfn5lfVDQsE8jvI3Q RVXzXpTbxBI87YPlVNrt5geZ4x877uLiVmfyY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=rUJ/STK6QLdsQzCXy8kDc/qaR25SFK4zcrq2oVZwD0vxqprTFmRcyWUhMaHBNL2O1O u7N6+Vcnje1HN0SNK1VjJXaLq+Zw1lYP20N6ZGCSAznkkWMwQo6HSawNs7N8lnhekRMt VUwO8JVoQQohG/x5eX0yWXkcSk3FYknvPmQYQ= MIME-Version: 1.0 Received: by 10.101.135.23 with SMTP id m23mr6524863ann.222.1264356750021; Sun, 24 Jan 2010 10:12:30 -0800 (PST) In-Reply-To: References: <883b2dc51001240905r4cfbf830i3b9b400969ac261b@mail.gmail.com> Date: Sun, 24 Jan 2010 20:12:29 +0200 Message-ID: From: Dan Naumov To: Jason Edwards , FreeBSD-STABLE Mailing List , freebsd-fs@freebsd.org, freebsd-questions@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Cc: Subject: Re: 8.0-RELEASE/amd64 - full ZFS install - low read and write disk performance X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Jan 2010 18:12:31 -0000 On Sun, Jan 24, 2010 at 7:42 PM, Dan Naumov wrote: > On Sun, Jan 24, 2010 at 7:05 PM, Jason Edwards wrote: >> Hi Dan, >> >> I read on FreeBSD mailinglist you had some performance issues with ZFS. >> Perhaps i can help you with that. >> >> You seem to be running a single mirror, which means you won't have any speed >> benefit regarding writes, and usually RAID1 implementations offer little to >> no acceleration to read requests also; some even just read from the master >> disk and don't touch the 'slave' mirrored disk unless when writing. ZFS is >> alot more modern however, although i did not test performance of its mirror >> implementation. >> >> But, benchmarking I/O can be tricky: >> >> 1) you use bonnie, but bonnie's tests are performed without a 'cooldown' >> period between the tests; meaning that when test 2 starts, data from test 1 >> is still being processed. For single disks and simple I/O this is not so >> bad, but for large write-back buffers and more complex I/O buffering, this >> may be inappropriate. I had patched bonnie some time in the past, but if you >> just want a MB/s number you can use DD for that. >> >> 2) The diskinfo tiny benchmark is single queue only i assume, meaning that >> it would not scale well or at all on RAID-arrays. Actual filesystems on >> RAID-arrays use multiple-queue; meaning it would not read one sector at a >> time, but read 8 blocks (of 16KiB) "ahead"; this is called read-ahead and >> for traditional UFS filesystems its controlled by the sysctl vfs.read_max >> variable. ZFS works differently though, but you still need a "real" >> benchmark. >> >> 3) You need low-latency hardware; in particular, no PCI controller should be >> used. Only PCI-express based controllers or chipset-integrated Serial ATA >> cotrollers have proper performance. PCI can hurt performance very badly, and >> has high interrupt CPU usage. Generally you should avoid PCI. PCI-express is >> fine though, its a completely different interface that is in many ways the >> opposite of what PCI was. >> >> 4) Testing actual realistic I/O performance (in IOps) is very difficult. But >> testing sequential performance should be alot easier. You may try using dd >> for this. >> >> >> For example, you can use dd on raw devices: >> >> dd if=/dev/ad4 of=/dev/null bs=1M count=1000 >> >> I will explain each parameter: >> >> if=/dev/ad4 is the input file, the "read source" >> >> of=/dev/null is the output file, the "write destination". /dev/null means it >> just goes no-where; so this is a read-only benchmark >> >> bs=1M is the blocksize, howmuch data to transfer per time. default is 512 or >> the sector size; but that's very slow. A value between 64KiB and 1024KiB is >> appropriate. bs=1M will select 1MiB or 1024KiB. >> >> count=1000 means transfer 1000 pieces, and with bs=1M that means 1000 * 1MiB >> = 1000MiB. >> >> >> >> This example was raw reading sequentially from the start of the device >> /dev/ad4. If you want to test RAIDs, you need to work at the filesystem >> level. You can use dd for that too: >> >> dd if=/dev/zero of=/path/to/ZFS/mount/zerofile.000 bs=1M count=2000 >> >> This command will read from /dev/zero (all zeroes) and write to a file on >> ZFS-mounted filesystem, it will create the file "zerofile.000" and write >> 2000MiB of zeroes to that file. >> So this command tests write-performance of the ZFS-mounted filesystem. To >> test read performance, you need to clear caches first by unmounting that >> filesystem and re-mounting it again. This would free up memory containing >> parts of the filesystem as cached (reported in top as "Inact(ive)" instead >> of "Free"). >> >> Please do make sure you double-check a dd command before running it, and run >> as normal user instead of root. A wrong dd command may write to the wrong >> destination and do things you don't want. The only real thing you need to >> check is the write destination (of=....). That's where dd is going to write >> to, so make sure its the target you intended. A common mistake made by >> myself was to write dd of=... if=... (starting with of instead of if) and >> thus actually doing something the other way around than what i was meant to >> do. This can be disastrous if you work with live data, so be careful! ;-) >> >> Hope any of this was helpful. During the dd benchmark, you can of course >> open a second SSH terminal and start "gstat" to see the devices current I/O >> stats. >> >> Kind regards, >> Jason > > Hi and thanks for your tips, I appreciate it :) > > [jago@atombsd ~]$ dd if=/dev/zero of=/home/jago/test1 bs=1M count=1024 > 1024+0 records in > 1024+0 records out > 1073741824 bytes transferred in 36.206372 secs (29656156 bytes/sec) > > [jago@atombsd ~]$ dd if=/dev/zero of=/home/jago/test2 bs=1M count=4096 > 4096+0 records in > 4096+0 records out > 4294967296 bytes transferred in 143.878615 secs (29851325 bytes/sec) > > This works out to 1GB in 36,2 seconds / 28,2mb/s in the first test and > 4GB in 143.8 seconds / 28,4mb/s and somewhat consistent with the > bonnie results. It also sadly seems to confirm the very slow speed :( > The disks are attached to a 4-port Sil3124 controller and again, my > Windows benchmarks showing 65mb/s+ were done on exact same machine, > with same disks attached to the same controller. Only difference was > that in Windows the disks weren't in a mirror configuration but were > tested individually. I do understand that a mirror setup offers > roughly the same write speed as individual disk, while the read speed > usually varies from "equal to individual disk speed" to "nearly the > throughput of both disks combined" depending on the implementation, > but there is no obvious reason I am seeing why my setup offers both > read and write speeds roughly 1/3 to 1/2 of what the individual disks > are capable of. Dmesg shows: > > atapci0: port 0x1000-0x100f mem > 0x90108000-0x9010807f,0x90100000-0x90107fff irq 21 at device 0.0 on > pci4 > ad8: 1907729MB at ata4-master SATA300 > ad10: 1907729MB at ata5-master SATA300 > > I do recall also testing an alternative configuration in the past, > where I would boot off an UFS disk and have the ZFS mirror consist of > 2 discs directly. The bonnie numbers in that case were in line with my > expectations, I was seeing 65-70mb/s. Note: again, exact same > hardware, exact same disks attached to the exact same controller. In > my knowledge, Solaris/OpenSolaris has an issue where they have to > automatically disable disk cache if ZFS is used on top of partitions > instead of raw disks, but to my knowledge (I recall reading this from > multiple reputable sources) this issue does not affect FreeBSD. > > - Sincerely, > Dan Naumov To add some additional info, for good measure I decided to check if disk write cache is enabled and sure enough it was: [jago@atombsd /var/log]$ sysctl hw.ata hw.ata.setmax: 0 hw.ata.wc: 1 hw.ata.atapi_dma: 1 hw.ata.ata_dma_check_80pin: 1 hw.ata.ata_dma: 1 Also if you want to see/know the exact way the system was built and installed, here is the build script I used: http://jago.pp.fi/zfsinst.sh The reason me (and this script) use MBR partitioning instead of GPT is because my motherboard cannot reliably boot off GPT, but this should not be really relevant to the performance issues shown. - Sincerely, Dan Naumov From owner-freebsd-stable@FreeBSD.ORG Sun Jan 24 18:17:15 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BB41210656B3 for ; Sun, 24 Jan 2010 18:17:15 +0000 (UTC) (envelope-from cliftonr@lava.net) Received: from outgoing03.lava.net (outgoing03.lava.net [IPv6:2001:1888:0:1:202:b3ff:fe1d:6b98]) by mx1.freebsd.org (Postfix) with ESMTP id 694CE8FC1A for ; Sun, 24 Jan 2010 18:17:15 +0000 (UTC) Received: from malasada.lava.net (malasada.lava.net [64.65.64.17]) by outgoing03.lava.net (Postfix) with ESMTP id 4799A1013F; Sun, 24 Jan 2010 08:17:14 -1000 (HST) Received: by malasada.lava.net (Postfix, from userid 102) id DA6EF153882; Sun, 24 Jan 2010 08:17:13 -1000 (HST) Date: Sun, 24 Jan 2010 08:17:13 -1000 From: Clifton Royston To: jhell Message-ID: <20100124181713.GA28246@lava.net> Mail-Followup-To: jhell , spil.oss@gmail.com, freebsd-stable@freebsd.org References: <5fbf03c21001240150r2064810n744694380ab8913a@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Cc: spil.oss@gmail.com, freebsd-stable@freebsd.org Subject: Re: Problem with alias length in base Sendmail X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 24 Jan 2010 18:17:15 -0000 On Sun, Jan 24, 2010 at 01:03:33PM -0500, jhell wrote: ... > That's either one hell of a pipe or the owner of that email address can be > proud that no-one will ever email him/her ;) staff@example.com: pres@example.com, vp@example.com, employee1@example.com, \ ... sales@example.com: joe@example.com, greg@example.com, \ ... Used to be very common and still might be; it's the traditional old-UNIX way to do organizational mail aliases/mailing lists. -- Clifton -- Clifton Royston -- cliftonr@iandicomputing.com / cliftonr@lava.net President - I and I Computing * http://www.iandicomputing.com/ Custom programming, network design, systems and network consulting services From owner-freebsd-stable@FreeBSD.ORG Sun Jan 24 18:29:54 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1E4B3106568D; Sun, 24 Jan 2010 18:29:54 +0000 (UTC) (envelope-from dan.naumov@gmail.com) Received: from mail-yw0-f197.google.com (mail-yw0-f197.google.com [209.85.211.197]) by mx1.freebsd.org (Postfix) with ESMTP id A40A48FC17; Sun, 24 Jan 2010 18:29:53 +0000 (UTC) Received: by ywh35 with SMTP id 35so2195803ywh.7 for ; Sun, 24 Jan 2010 10:29:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=Jd59GblytqTsj/A2jL+22mSk53JxWa7kKpN2Tgprzag=; b=fJgnzGR/GnQ1t0OKMUyoXZkAoPpLFO3lPDjBTvvAP7Pa/eNs9edsqR+fpAObo7R1s4 TdgieZBAfaiTRbntM5vFqyuj1/+GYRFZa89XQowAgSsUP4JsCwrl66qzILFqjhSuI3vK 7+FWh/UZStxlHbEeByew33jvhYweVqf1S8Nmg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=W9lTWgQ4payHtP/RFPn1cchDjsPrvIwRzSdhPO4wyAQJGnIyVZ+5O0WSGqq4wV/R2e /sKogAa96O7PgkgzNMgIIiLoMzfwbYK+xqpGzZmzFcw5By8iAP+5RTDlaR5FAmzOFK54 Pu6HOpQcJKrlY+ijAA58U6HqgHfE587eKxIOM= MIME-Version: 1.0 Received: by 10.101.12.6 with SMTP id p6mr6559698ani.248.1264357792623; Sun, 24 Jan 2010 10:29:52 -0800 (PST) In-Reply-To: References: <883b2dc51001240905r4cfbf830i3b9b400969ac261b@mail.gmail.com> Date: Sun, 24 Jan 2010 20:29:52 +0200 Message-ID: From: Dan Naumov To: Bob Friesenhahn , sub.mesa@gmail.com Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-fs@freebsd.org, FreeBSD-STABLE Mailing List , freebsd-questions@freebsd.org Subject: Re: 8.0-RELEASE/amd64 - full ZFS install - low read and write disk performance X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Jan 2010 18:29:54 -0000 On Sun, Jan 24, 2010 at 8:12 PM, Bob Friesenhahn wrote: > On Sun, 24 Jan 2010, Dan Naumov wrote: >> >> This works out to 1GB in 36,2 seconds / 28,2mb/s in the first test and >> 4GB in 143.8 seconds / 28,4mb/s and somewhat consistent with the >> bonnie results. It also sadly seems to confirm the very slow speed :( >> The disks are attached to a 4-port Sil3124 controller and again, my >> Windows benchmarks showing 65mb/s+ were done on exact same machine, >> with same disks attached to the same controller. Only difference was >> that in Windows the disks weren't in a mirror configuration but were >> tested individually. I do understand that a mirror setup offers >> roughly the same write speed as individual disk, while the read speed >> usually varies from "equal to individual disk speed" to "nearly the >> throughput of both disks combined" depending on the implementation, >> but there is no obvious reason I am seeing why my setup offers both >> read and write speeds roughly 1/3 to 1/2 of what the individual disks >> are capable of. Dmesg shows: > > There is a mistatement in the above in that a "mirror setup offers roughl= y > the same write speed as individual disk". =A0It is possible for a mirror = setup > to offer a similar write speed to an individual disk, but it is also quit= e > possible to get 1/2 (or even 1/3) the speed. ZFS writes to a mirror pair > requires two independent writes. =A0If these writes go down independent I= /O > paths, then there is hardly any overhead from the 2nd write. =A0If the wr= ites > go through a bandwidth-limited shared path then they will contend for tha= t > bandwidth and you will see much less write performance. > > As a simple test, you can temporarily remove the mirror device from the p= ool > and see if the write performance dramatically improves. Before doing that= , > it is useful to see the output of 'iostat -x 30' while under heavy write > load to see if one device shows a much higher svc_t value than the other. Ow, ow, WHOA: atombsd# zpool offline tank ad8s1a [jago@atombsd ~]$ dd if=3D/dev/zero of=3D/home/jago/test3 bs=3D1M count=3D1= 024 1024+0 records in 1024+0 records out 1073741824 bytes transferred in 16.826016 secs (63814382 bytes/sec) Offlining one half of the mirror bumps DD write speed from 28mb/s to 64mb/s! Let's see how Bonnie results change: Mirror with both parts attached: -------Sequential Output-------- ---Sequential Input-- --Rand= om-- -Per Char- --Block--- -Rewrite-- -Per Char- --Block--- --Seek= s--- Machine MB K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU /sec = %CPU 8192 18235 46.7 23137 19.9 13927 13.6 24818 49.3 44919 17.3 134.3 = 2.1 Mirror with 1 half offline: -------Sequential Output-------- ---Sequential Input-- --Rand= om-- -Per Char- --Block--- -Rewrite-- -Per Char- --Block--- --Seek= s--- Machine MB K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU /sec = %CPU 1024 22888 58.0 41832 35.1 22764 22.0 26775 52.3 54233 18.3 166.0 = 1.6 Ok, the Bonnie results have improved, but only very little. - Sincerely, Dan Naumov From owner-freebsd-stable@FreeBSD.ORG Sun Jan 24 18:40:37 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4ADBF106566C; Sun, 24 Jan 2010 18:40:37 +0000 (UTC) (envelope-from dan.naumov@gmail.com) Received: from mail-yw0-f197.google.com (mail-yw0-f197.google.com [209.85.211.197]) by mx1.freebsd.org (Postfix) with ESMTP id CFA748FC18; Sun, 24 Jan 2010 18:40:36 +0000 (UTC) Received: by ywh35 with SMTP id 35so2199414ywh.7 for ; Sun, 24 Jan 2010 10:40:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type :content-transfer-encoding; bh=cYTS0m2zo4yDD/C80NV/kKNkjUleB0nYq6cDz3m1o8M=; b=E/QHnw9cxELemG6LgKrCQFM00BIeOJXlPkCLLH7bNWlgqbmNLl95XVNSie0qyuFBGt ak510/HzecvrOJg+q7TJpoobuntrIl0o0A+HM+9FIcNC+yrA2AtxSFyfSnUTiatyN2xw QW06WJsoILZcAjyLjPI27iCMpw8JpBftAOuRI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; b=McVl6IfCbStweIGUId0p5GYs2NDRQnZfA1tzwHQ4QcA5KKsoBb4f9oKiWRc3HdXftV 9VRwxZO786iWEOOvqUU3lht82fN4Yts15TFkg4Ghcsm5dfCcGkdhor15ubMc/JrB2HL1 8s/vXLjqqAvey+UrP2bOMluaxJ6sKYt9MUQMw= MIME-Version: 1.0 Received: by 10.101.133.37 with SMTP id k37mr6619685ann.237.1264358436052; Sun, 24 Jan 2010 10:40:36 -0800 (PST) In-Reply-To: <883b2dc51001241034u40c97fdet83eb1e6edb5f4df4@mail.gmail.com> References: <883b2dc51001240905r4cfbf830i3b9b400969ac261b@mail.gmail.com> <883b2dc51001241034u40c97fdet83eb1e6edb5f4df4@mail.gmail.com> Date: Sun, 24 Jan 2010 20:40:36 +0200 Message-ID: From: Dan Naumov To: Jason Edwards , FreeBSD-STABLE Mailing List , freebsd-questions@freebsd.org, freebsd-fs@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Subject: Re: 8.0-RELEASE/amd64 - full ZFS install - low read and write disk performance X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Jan 2010 18:40:37 -0000 On Sun, Jan 24, 2010 at 8:34 PM, Jason Edwards wrote: >> ZFS writes to a mirror pair >> requires two independent writes. =A0If these writes go down independent = I/O >> paths, then there is hardly any overhead from the 2nd write. =A0If the >> writes >> go through a bandwidth-limited shared path then they will contend for th= at >> bandwidth and you will see much less write performance. > > What he said may confirm my suspicion on PCI. So if you could try the sam= e > with "real" Serial ATA via chipset or PCI-e controller you can confirm th= is > story. I would be very interested. :P > > Kind regards, > Jason This wouldn't explain why ZFS mirror on 2 disks directly, on the exact same controller (with the OS running off a separate disks) results in "expected" performance, while having the OS run off/on a ZFS mirror running on top of MBR-partitioned disks, on the same controller, results in very low speed. - Dan From owner-freebsd-stable@FreeBSD.ORG Sun Jan 24 19:08:08 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4A5A5106566C for ; Sun, 24 Jan 2010 19:08:08 +0000 (UTC) (envelope-from zephyrus.271@gmail.com) Received: from mail-fx0-f226.google.com (mail-fx0-f226.google.com [209.85.220.226]) by mx1.freebsd.org (Postfix) with ESMTP id 927398FC08 for ; Sun, 24 Jan 2010 19:08:07 +0000 (UTC) Received: by fxm26 with SMTP id 26so405400fxm.13 for ; Sun, 24 Jan 2010 11:08:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:received:date:from:to:subject :message-id:mime-version:content-type:content-disposition:user-agent; bh=iybwWxg9A5ty8dQ4BZxMmbnfYeCZGgdOfs9QdkYS5AY=; b=ffWXZMkooH3W/0FemGilGjmVyxQoobrV/V5ijUXHFJJX957kDiJqp5IjbFLldvhh0t zKuYBNtssa5TBlPNuW4DyjpDCwsb/RlID18YjqNOCvZX6aNsfUMu4JiFaj/zr9+AeqJa KfTiEjrRGDYrSDsUYUS2xn6Y76Sqwnl2XFDyI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=date:from:to:subject:message-id:mime-version:content-type :content-disposition:user-agent; b=YGRLRtOhzsx65Xd2eLUn0A4QkKoBhJtttXbgTuqvc1cRL4iwmrLnN1ahPqlo+l/7Ln 4tl7TkbhkwyDmJLxdjB53Mu0keFBIVgqX4CXWMOW+bnhpHpp1NR/gCxeD45uTeuV4YXl slbcq0y4vjrpPLv/CYJrm1XRWJ+nE8QB9IzKw= Received: by 10.223.4.22 with SMTP id 22mr5771657fap.97.1264358358036; Sun, 24 Jan 2010 10:39:18 -0800 (PST) Received: from polaris.localdomain (81-174-11-81.static.ngi.it [81.174.11.81]) by mx.google.com with ESMTPS id 19sm5678398fkr.18.2010.01.24.10.39.16 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sun, 24 Jan 2010 10:39:16 -0800 (PST) Received: by polaris.localdomain (Postfix, from userid 1000) id 94661143; Sun, 24 Jan 2010 19:39:11 +0100 (CET) Date: Sun, 24 Jan 2010 19:39:11 +0100 From: "Emanuele A. Bagnaschi" To: FreeBSD-STABLE Mailing List Message-ID: <20100124183911.GA2589@polaris> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="aT9PWwzfKXlsBJM1" Content-Disposition: inline User-Agent: Mutt/1.5.20 (2009-06-14) Subject: Problematic network performance with Marvell 8072 on HP Probook 4710s X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 24 Jan 2010 19:08:08 -0000 --aT9PWwzfKXlsBJM1 Content-Type: multipart/mixed; boundary="i0/AhcQY5QxfSsSZ" Content-Disposition: inline --i0/AhcQY5QxfSsSZ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi, I've been experiencing a troubling issue with a Marvell 8072 NIC on an HP ProBook 4710s.=20 I first noticed that there is a problem while transferring some files through scp to a FreeBSD8-STABLE server: CPUs usage sky-rocketed to 100% (s= ystem) and network performance was awful (about 1.8 MiB/s). I tried and succeeded in reproducing the issue with 'ttcp'. I decided to use this little benchmark because is so simple (it is linked only agains= t libc) that I can be sure that the problem doesn't depend on scp/ssh or other parts of the sy= stem. This is the output of 'uname -a': FreeBSD polaris 8.0-STABLE FreeBSD 8.0-STABLE #24: Sun Jan 17 21:08:02 CET 2010 toor@polaris:/usr/obj/usr/src/sys/POLARIS amd64 Here it's some relevant information to identify the NIC: first from 'dmesg' mskc0: port 0x2000-0x20ff mem 0x90100000-0x90103fff irq 17 at device 0.0 on pci134 msk0: on mskc0 msk0: Ethernet address: 00:25:b3:52:fc:fa miibus0: on msk0 mskc0: [FILTER] msk0: link state changed to DOWN msk0: link state changed to UP and then from 'pciconf -lv' mskc0@pci0:134:0:0: class=3D0x020000 card=3D0x3074103c chip=3D0x436c11ab rev=3D0x10 hdr=3D0x00 vendor =3D 'Marvell Semiconductor (Was: Galileo Technology Ltd)' device =3D 'Marvell 8072 Ethernet Nic (88E8072)' class =3D network subclass =3D ethernet Here it's the output of 'ifconfig': msk0: flags=3D8843 metric 0 mtu 1500 options=3D19b ether 00:25:b3:52:fc:fa inet 192.168.1.4 netmask 0xffffff00 broadcast 192.168.1.255 media: Ethernet autoselect (100baseTX ) satus: active Attached you will find the results of my tests, I hope that the file will be self-explanatory. I'm wondering, are there any other tunable parameters (apart from MSI on/of= f) I should try to modify? Should I file a PR? Are there any other interesting d= ata I should gather? With the proper guide I'm also available to contribute some code myself. Best regards --=20 Emanuele A. Bagnaschi --i0/AhcQY5QxfSsSZ Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=test_results Content-Transfer-Encoding: quoted-printable * notebook - Linux 2.6.32 - hostname: elsinore * * server - FreeBSD8-STABLE - hostname:atlantis *=20 FIRST RUN - elsinore transmits, atlantis receives elsinore --> atlantis (output on elsinore) ttcp -n 12800 -t -s atlantis ttcp-t: buflen=3D8192, nbuf=3D12800, align=3D16384/0, port=3D5001 tcp -> = atlantis ttcp-t: socket ttcp-t: connect ttcp-t: 104857600 bytes in 8.87 real seconds =3D 11538.31 KB/sec +++ ttcp-t: 12800 I/O calls, msec/call =3D 0.71, calls/sec =3D 1442.29 atlantis <-- elsinore (output on atlantis) ttcp -r -s ttcp-r: buflen=3D8192, nbuf=3D2048, align=3D16384/0, port=3D5001 tcp ttcp-r: socket ttcp-r: accept from 192.168.1.4 ttcp-r: 16777216 bytes in 1.43 real seconds =3D 11464.61 KB/sec +++ ttcp-r: 11562 I/O calls, msec/call =3D 0.13, calls/sec =3D 8090.45 ttcp-r: 0.0user 0.0sys 0:01real 3% 14i+1022d 502maxrss 0+2pf 11559+42csw SECOND RUN - elsinore receives, atlantis transmits elsinore <-- atlantis (output on elsinore) ttcp -r -s ttcp-r: buflen=3D8192, nbuf=3D2048, align=3D16384/0, port=3D5001 tcp ttcp-r: socket ttcp-r: accept from 192.168.1.1 ttcp-r: 104857600 bytes in 9.00 real seconds =3D 11372.89 KB/sec +++ ttcp-r: 29235 I/O calls, msec/call =3D 0.32, calls/sec =3D 3246.94 ttcp-r: 0.0user 0.7sys 0:09real 8% 0i+0d 910maxrss 0+2pf 29195+456csw atlantis --> elsinore (output on atlantis) ttcp -t -s -n 12800 elsinore ttcp-t: buflen=3D8192, nbuf=3D12800, align=3D16384/0, port=3D5001 tcp -> = elsinore ttcp-t: socket ttcp-t: connect ttcp-t: 104857600 bytes in 8.99 real seconds =3D 11394.04 KB/sec +++ ttcp-t: 12800 I/O calls, msec/call =3D 0.72, calls/sec =3D 1424.26 ttcp-t: 0.0user 0.2sys 0:08real 3% 15i+1095d 578maxrss 0+2pf 27143+2543csw ----- * notebook - FreeBSD8-STABLE - hostname:polaris - msk with MSI enabled * * server - FreeBSD8-STABLE - hostname:atlantis * FIRST RUN - polaris transmits, atlantis receives polaris --> atlantis (output on polaris) ttcp -t -s -n 12800 atlantis ttcp-t: buflen=3D8192, nbuf=3D12800, align=3D16384/0, port=3D5001 tcp -> = atlantis ttcp-t: socket ttcp-t: connect ttcp-t: 104857600 bytes in 13.63 real seconds =3D 7514.90 KB/sec +++ ttcp-t: 12800 I/O calls, msec/call =3D 1.09, calls/sec =3D 939.36 ttcp-t: 0.1user 10.7sys 0:13real 80% 5i+408d 674maxrss 0+1pf 1004+1525csw atlantis <-- polaris (output on atlantis) ttcp -r -s ttcp-r: buflen=3D8192, nbuf=3D2048, align=3D16384/0, port=3D5001 tcp ttcp-r: socket ttcp-r: accept from 192.168.1.4 ttcp-r: 104857600 bytes in 13.63 real seconds =3D 7512.69 KB/sec +++ ttcp-r: 76875 I/O calls, msec/call =3D 0.18, calls/sec =3D 5640.02 ttcp-r: 0.0user 0.3sys 0:13real 2% 16i+1168d 502maxrss 0+2pf 76849+2128csw SECOND RUN - polaris receives, atlantis transmits polaris <-- atlantis (output on polaris) ttcp -r -s ttcp-r: buflen=3D8192, nbuf=3D2048, align=3D16384/0, port=3D5001 tcp ttcp-r: socket ttcp-r: accept from 192.168.1.1 ttcp-r: 104857600 bytes in 53.68 real seconds =3D 1907.67 KB/sec +++ ttcp-r: 14021 I/O calls, msec/call =3D 3.92, calls/sec =3D 261.21 ttcp-r: 0.0user 14.9sys 0:53real 27% 7i+563d 600maxrss 0+2pf 1176+2765csw atlantis --> polaris (output on polaris) ttcp -t -s -n 12800 elsinore ttcp-t: buflen=3D8192, nbuf=3D12800, align=3D16384/0, port=3D5001 tcp -> = elsinore ttcp-t: socket ttcp-t: connect ttcp-t: 104857600 bytes in 53.59 real seconds =3D 1910.75 KB/sec +++ ttcp-t: 12800 I/O calls, msec/call =3D 4.29, calls/sec =3D 238.84 ttcp-t: 0.0user 0.2sys 0:53real 0% 17i+1207d 576maxrss 0+2pf 40032+473csw ----- * notebook - FreeBSD8-STABLE - hostname:polaris - msk with MSI disabled * * server - FreeBSD8-STABLE - hostname:atlantis * FIRST RUN - polaris transmits, atlantis receives polaris --> atlantis (output on polaris) ttcp -t -s -n 12800 atlantis ttcp-t: buflen=3D8192, nbuf=3D12800, align=3D16384/0, port=3D5001 tcp -> = atlantis ttcp-t: socket ttcp-t: connect ttcp-t: 104857600 bytes in 13.27 real seconds =3D 7716.57 KB/sec +++ ttcp-t: 12800 I/O calls, msec/call =3D 1.06, calls/sec =3D 964.57 ttcp-t: 0.2user 10.3sys 0:13real 79% 5i+419d 674maxrss 0+1pf 823+1938csw atlantis <-- polaris (output on atlantis) ttcp -r -s = = = ~ ttcp-r: buflen=3D8192, nbuf=3D2048, align=3D16384/0, port=3D5001 tcp ttcp-r: socket ttcp-r: accept from 192.168.1.4 ttcp-r: 104857600 bytes in 13.27 real seconds =3D 7713.85 KB/sec +++ ttcp-r: 76800 I/O calls, msec/call =3D 0.18, calls/sec =3D 5785.39 ttcp-r: 0.0user 0.3sys 0:13real 2% 15i+1065d 502maxrss 0+2pf 76778+2373csw SECOND RUN - polaris receives, atlantis transmits polaris <-- atlantis (output on polaris) ttcp -r -s ttcp-r: buflen=3D8192, nbuf=3D2048, align=3D16384/0, port=3D5001 tcp ttcp-r: socket ttcp-r: accept from 192.168.1.1 ttcp-r: 104857600 bytes in 59.32 real seconds =3D 1726.28 KB/sec +++ ttcp-r: 13499 I/O calls, msec/call =3D 4.50, calls/sec =3D 227.57 ttcp-r: 0.0user 13.4sys 0:59real 22% 7i+545d 600maxrss 0+2pf 710+2732csw atlantis --> polaris (output on atlantis) ttcp -t -s -n 12800 elsinore ttcp-t: buflen=3D8192, nbuf=3D12800, align=3D16384/0, port=3D5001 tcp -> = elsinore ttcp-t: socket ttcp-t: connect ttcp-t: 104857600 bytes in 59.22 real seconds =3D 1729.15 KB/sec +++ ttcp-t: 12800 I/O calls, msec/call =3D 4.74, calls/sec =3D 216.14 ttcp-t: 0.0user 0.2sys 0:59real 0% 14i+1029d 576maxrss 0+2pf 41750+287csw --i0/AhcQY5QxfSsSZ-- --aT9PWwzfKXlsBJM1 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.14 (FreeBSD) iEYEARECAAYFAktck88ACgkQrwnEPevYb9UIOQCgqjvhUdhFl5hPM817bQw0pgWt QZwAnRGfVgm8zhd1yue7XYMSpF/B63dW =TDK7 -----END PGP SIGNATURE----- --aT9PWwzfKXlsBJM1-- From owner-freebsd-stable@FreeBSD.ORG Sun Jan 24 19:45:08 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 660441065670 for ; Sun, 24 Jan 2010 19:45:08 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from mail.cksoft.de (mail.cksoft.de [IPv6:2001:4068:10::3]) by mx1.freebsd.org (Postfix) with ESMTP id E945A8FC17 for ; Sun, 24 Jan 2010 19:45:07 +0000 (UTC) Received: from localhost (amavis.fra.cksoft.de [192.168.74.71]) by mail.cksoft.de (Postfix) with ESMTP id E5B5041C69F; Sun, 24 Jan 2010 20:45:06 +0100 (CET) X-Virus-Scanned: amavisd-new at cksoft.de Received: from mail.cksoft.de ([192.168.74.103]) by localhost (amavis.fra.cksoft.de [192.168.74.71]) (amavisd-new, port 10024) with ESMTP id prp-xRuh5oB1; Sun, 24 Jan 2010 20:45:06 +0100 (CET) Received: by mail.cksoft.de (Postfix, from userid 66) id ED75D41C65E; Sun, 24 Jan 2010 20:45:05 +0100 (CET) Received: from maildrop.int.zabbadoz.net (maildrop.int.zabbadoz.net [10.111.66.10]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.int.zabbadoz.net (Postfix) with ESMTP id 4DFFD4448EC; Sun, 24 Jan 2010 19:42:47 +0000 (UTC) Date: Sun, 24 Jan 2010 19:42:47 +0000 (UTC) From: "Bjoern A. Zeeb" X-X-Sender: bz@maildrop.int.zabbadoz.net To: Oliver Brandmueller In-Reply-To: <20100122162155.GG3917@e-Gitt.NET> Message-ID: <20100124185626.M50938@maildrop.int.zabbadoz.net> References: <20100122162155.GG3917@e-Gitt.NET> X-OpenPGP-Key: 0x14003F198FEFA3E77207EE8D2B58B8F83CCF1842 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-stable@FreeBSD.org Subject: Re: 8.0-RELEASE -> -STABLE and size of / X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Jan 2010 19:45:08 -0000 On Fri, 22 Jan 2010, Oliver Brandmueller wrote: Hi, > I just noticed somthing: I setup an 8.0-RELEASE amd64 box, / is default > 512M. First step after setup was to csup to RELENG_8 and buildkernel and > buildworld (no custom kernel, no make.conf). > > Instaling the new kernel failed, since /boot/kernel/ is already well > over 230 MBytes in size. moving that to kernel.old and writing a new one > with about the same size fails due to no space left on device. Replying to the first post in the thread. One first thing to help people to avoid problems with future upgrades could be to just make / 1G: http://people.freebsd.org/~bz/20100124-03-sysinstall-root-1g.diff Another entirely untested patch would compress the symbol files: http://people.freebsd.org/~bz/20100124-04-kernel-compress-symbols.diff It would be interesting to see if (a) they work and (b) how much the latter would safe. /bz -- Bjoern A. Zeeb It will not break if you know what you are doing. From owner-freebsd-stable@FreeBSD.ORG Sun Jan 24 20:55:08 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8FDDF106566C for ; Sun, 24 Jan 2010 20:55:08 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from mail-qy0-f201.google.com (mail-qy0-f201.google.com [209.85.221.201]) by mx1.freebsd.org (Postfix) with ESMTP id 41FFD8FC16 for ; Sun, 24 Jan 2010 20:55:08 +0000 (UTC) Received: by qyk39 with SMTP id 39so1579183qyk.27 for ; Sun, 24 Jan 2010 12:55:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:received:from:date:to:cc :subject:message-id:reply-to:references:mime-version:content-type :content-disposition:in-reply-to:user-agent; bh=uk7cMPVfhIxy3ZS1yZELFJcWtMVaT50cPAuCfle7iME=; b=Mr3o4L0j/0D+4Fe6vCem3ra5/4R1lVjHTBve/92J/m1GPhiHjTumCpCXXfbQux43Zd Oab8OksZ9I/lesG8DB3JgwXFpO5Axs3RvzNDMMM12QoamgsKX5exShg7mXnyaTY2fY8N OdlozdxjzIesVQv8nmEkJj4vcmKWxfLnsqq1I= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:date:to:cc:subject:message-id:reply-to:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; b=ldgzOA/WKfFsuPUQ3RZ29P0ss6jzo5VmaqTGNZUUVVtm2x7s3sFyKuI/nCxynKDQJL vDTatHCYjUf0PnRmUz4GcVrSjWTkb6OoFRb9QKV9fD/H8WfKy6g3K3fCozrGVsPtaR8f SvVswIzH5cDewqJxloeD0oI1uSe+PWcHkEUCQ= Received: by 10.229.102.165 with SMTP id g37mr1695256qco.65.1264366507259; Sun, 24 Jan 2010 12:55:07 -0800 (PST) Received: from pyunyh@gmail.com ([174.35.1.224]) by mx.google.com with ESMTPS id 20sm2248791qyk.1.2010.01.24.12.55.05 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sun, 24 Jan 2010 12:55:06 -0800 (PST) Received: by pyunyh@gmail.com (sSMTP sendmail emulation); Sun, 24 Jan 2010 12:55:05 -0800 From: Pyun YongHyeon Date: Sun, 24 Jan 2010 12:55:05 -0800 To: "Emanuele A. Bagnaschi" Message-ID: <20100124205505.GB1187@michelle.cdnetworks.com> References: <20100124183911.GA2589@polaris> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20100124183911.GA2589@polaris> User-Agent: Mutt/1.4.2.3i Cc: FreeBSD-STABLE Mailing List Subject: Re: Problematic network performance with Marvell 8072 on HP Probook 4710s X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: pyunyh@gmail.com List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Jan 2010 20:55:08 -0000 On Sun, Jan 24, 2010 at 07:39:11PM +0100, Emanuele A. Bagnaschi wrote: > Hi, > I've been experiencing a troubling issue with a Marvell 8072 NIC on an HP > ProBook 4710s. > I first noticed that there is a problem while transferring some files > through scp to a FreeBSD8-STABLE server: CPUs usage sky-rocketed to 100% (system) > and network performance was awful (about 1.8 MiB/s). > I tried and succeeded in reproducing the issue with 'ttcp'. I decided > to use this little benchmark because is so simple (it is linked only against libc) that I can > be sure that the problem doesn't depend on scp/ssh or other parts of the system. > Last time I checked ttcp, it was broken with threading. So you have to build ttcp without threading support or use netperf to check performance numbers. > This is the output of 'uname -a': > > FreeBSD polaris 8.0-STABLE FreeBSD 8.0-STABLE #24: Sun Jan 17 21:08:02 > CET 2010 toor@polaris:/usr/obj/usr/src/sys/POLARIS amd64 > > Here it's some relevant information to identify the NIC: > > first from 'dmesg' > > mskc0: port 0x2000-0x20ff mem > 0x90100000-0x90103fff irq 17 at device 0.0 on pci134 > msk0: on mskc0 > msk0: Ethernet address: 00:25:b3:52:fc:fa > miibus0: on msk0 > mskc0: [FILTER] > msk0: link state changed to DOWN > msk0: link state changed to UP > > and then from 'pciconf -lv' > > mskc0@pci0:134:0:0: class=0x020000 card=0x3074103c chip=0x436c11ab > rev=0x10 hdr=0x00 > vendor = 'Marvell Semiconductor (Was: Galileo Technology Ltd)' > device = 'Marvell 8072 Ethernet Nic (88E8072)' > class = network > subclass = ethernet > > Here it's the output of 'ifconfig': > > msk0: flags=8843 metric 0 mtu > 1500 > options=19b > ether 00:25:b3:52:fc:fa > inet 192.168.1.4 netmask 0xffffff00 broadcast 192.168.1.255 > media: Ethernet autoselect (100baseTX ) > satus: active > > > Attached you will find the results of my tests, I hope that the file > will be self-explanatory. > It seems you have Yukon Extreme controller and its revision is B0 which is known to have various silicon bug. How about disabling TX related offloading?(e.g. ifconfig msk0 -txcsum -tso) Does that make any difference? > I'm wondering, are there any other tunable parameters (apart from MSI on/off) I > should try to modify? Should I file a PR? Are there any other interesting data > I should gather? With the proper guide I'm also available to contribute some > code myself. > Given that high rates of silicon bug of Yukon having a detailed errata information would be great help to analyze the issue. But we still have no access to the information as well as datasheet. From owner-freebsd-stable@FreeBSD.ORG Sun Jan 24 20:57:26 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8BC871065740; Sun, 24 Jan 2010 20:57:26 +0000 (UTC) (envelope-from marka@isc.org) Received: from farside.isc.org (farside.isc.org [IPv6:2001:4f8:3:bb::5]) by mx1.freebsd.org (Postfix) with ESMTP id 6E24D8FC24; Sun, 24 Jan 2010 20:57:26 +0000 (UTC) Received: from drugs.dv.isc.org (drugs.dv.isc.org [IPv6:2001:470:1f00:820:214:22ff:fed9:fbdc]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "drugs.dv.isc.org", Issuer "ISC CA" (not verified)) by farside.isc.org (Postfix) with ESMTP id 4A2E3E60CD; Sun, 24 Jan 2010 20:57:25 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.14.3/8.14.3) with ESMTP id o0OKvHUE089237; Mon, 25 Jan 2010 07:57:17 +1100 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <201001242057.o0OKvHUE089237@drugs.dv.isc.org> To: Dan Naumov From: Mark Andrews References: <20100122041237.GA22312@gothschlampen.com> <20100124092947.B72039@starfire.mn.org> In-reply-to: Your message of "Sun, 24 Jan 2010 17:59:13 +0200." Date: Mon, 25 Jan 2010 07:57:17 +1100 Sender: marka@isc.org Cc: John , "Thomas K." , FreeBSD-STABLE Mailing List , freebsd-questions@freebsd.org Subject: Re: Loader, MBR and the boot process X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 24 Jan 2010 20:57:26 -0000 In message , Dan N aumov writes: > On Sun, Jan 24, 2010 at 5:29 PM, John wrote: > > On Fri, Jan 22, 2010 at 07:02:53AM +0200, Dan Naumov wrote: > >> On Fri, Jan 22, 2010 at 6:49 AM, Dan Naumov wrote= > : > >> > On Fri, Jan 22, 2010 at 6:12 AM, Thomas K. wro= > te: > >> >> On Fri, Jan 22, 2010 at 05:57:23AM +0200, Dan Naumov wrote: > >> >> > >> >> Hi, > >> >> > >> >>> I recently found a nifty "FreeBSD ZFS root installation script" and > >> >>> been reworking it a bit to suit my needs better, including changing = > it > >> >>> from GPT to MBR partitioning. However, I was stumped, even though I > >> >>> had done everything right (or so I thought), the system would get > >> >>> stuck at Loader and refuse to go anywhere. After trying over a dozen > >> >> > >> >> probably this line is the cause: > >> >> > >> >> dd if=3D/mnt2/boot/zfsboot of=3D/dev/"${TARGETDISK}"s1a skip=3D1 seek= > =3D1024 > >> >> > >> >> Unless by "swap first" you meant the on-disk location, and not the > >> >> partition letter. If swap is partition "a", you're writing the loader > >> >> into swapspace. > >> >> > >> >> > >> >> Regards, > >> >> Thomas > >> > > >> > At first you made me feel silly, but then I decided to double-check, I > >> > uncommented the swap line in the partitioning part again, ensured I > >> > was writing the bootloader to "${TARGETDISK}"s1b and ran the script. > >> > Same problem, hangs at loader. Again, if I comment out the swap, > >> > giving the entire slice to ZFS and then write the bootloader to > >> > "${TARGETDISK}"s1a, run the script, everything works. > >> > >> I have also just tested creating 2 slices, like this: > >> > >> gpart create -s mbr "${TARGETDISK}" > >> gpart add -s 3G -t freebsd "${TARGETDISK}" > >> gpart create -s BSD "${TARGETDISK}"s1 > >> gpart add -t freebsd-swap "${TARGETDISK}"s1 > >> > >> gpart add -t freebsd "${TARGETDISK}" > >> gpart create -s BSD "${TARGETDISK}"s2 > >> gpart add -t freebsd-zfs "${TARGETDISK}"s2 > >> > >> gpart set -a active -i 2 "${TARGETDISK}" > >> gpart bootcode -b /mnt2/boot/boot0 "${TARGETDISK}" > >> > >> > >> and later: > >> > >> dd if=3D/mnt2/boot/zfsboot of=3D/dev/"${TARGETDISK}"s2 count=3D1 > >> dd if=3D/mnt2/boot/zfsboot of=3D/dev/"${TARGETDISK}"s2a skip=3D1 seek=3D= > 1024 > >> > >> > >> Putting the swap into it's own slice and then putting FreeBSD into > >> it's own slice worked fine. So why the hell can't they both coexist in > >> 1 slice if the swap comes first? > > > > I know what the answer to this USED to be, but I don't know if it is > > still true (obviously, I think so, I or wouldn't waste your time). > > > > The filesystem code is all carefully written to avoid the very > > first few sector of the partition. =A0That's because the partition > > table is there for the first filesystem of the slice (or disk). > > That's a tiny amout of space wasted, because it's also skipped on > > all the other filesystems even though there's not actually anything > > there, but it was a small inefficency, even in the 70's. > > > > Swap does not behave that way. =A0SWAP will begin right at the slice > > boundry, with 0 offset. =A0As long as it's not the first partition, no > > harm, no foul. =A0If it IS the first partition, you just nuked your parti= > tion > > table. =A0As long as SWAP owns the slice, again, no harm, no foul, but > > if there were filesystems BEHIND it, you just lost 'em. > > > > That's the way it always used to be, and I think it still is. =A0SWAP can > > only be first if it is the ONLY thing using that slice (disk), otherwise, > > you need a filesystem first to protect the partition table. > > -- > > > > John Lind > > john@starfire.MN.ORG > > This explanation does sound logical, but holy crap, if this is the > case, you'd think there would be bells, whistles and huge red label > warnings in EVERY FreeBSD installation / partitioning guide out there > warning people to not put swap first (unless given a dedicated slice) > under any circumstances. The warnings were nowhere to be seen and lots > of pointy hair first greyed and were then lost during the process of > me trying to figure out why my system would install but wouldn't boot. >From "man bsdlabel". offset The offset of the start of the partition from the beginning of the drive in sectors, or * to have bsdlabel calculate the correct offset to use (the end of the previous partition plus one, ignor- ing partition `c'. For partition `c', * will be interpreted as an offset of 0. The first partition should start at offset 16, because the first 16 sectors are reserved for metadata. > - Sincerely, > Dan Naumov > _______________________________________________ > 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" -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From owner-freebsd-stable@FreeBSD.ORG Sun Jan 24 21:26:37 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BD4E5106566B for ; Sun, 24 Jan 2010 21:26:37 +0000 (UTC) (envelope-from freebsd@com.jkkn.dk) Received: from blackbird.jkkn.net (blackbird.home6.jkkn.net [IPv6:2001:16d8:dd04:0:207:e9ff:fe62:64be]) by mx1.freebsd.org (Postfix) with ESMTP id 642DB8FC0A for ; Sun, 24 Jan 2010 21:26:37 +0000 (UTC) Received: from [192.168.2.2] (online.jkkn.net. [83.91.180.61]) (authenticated bits=0) by blackbird.jkkn.net (envelope-from freebsd@com.jkkn.dk) (8.14.3/8.14.3) with ESMTP id o0OLQVt2002718 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Sun, 24 Jan 2010 22:26:31 +0100 (CET) (envelope-from freebsd@com.jkkn.dk) Message-ID: <4B5CBB08.8040602@com.jkkn.dk> Date: Sun, 24 Jan 2010 22:26:32 +0100 From: =?ISO-8859-1?Q?Kristian_Kr=E6mmer_Nielsen?= User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.7) Gecko/20100111 Thunderbird/3.0.1 MIME-Version: 1.0 To: freebsd-stable@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=2.1 required=5.0 tests=RCVD_IN_PBL, RCVD_IN_SORBS_DUL autolearn=no version=3.2.5 X-Spam-Report: * 0.5 RCVD_IN_PBL RBL: Received via a relay in Spamhaus PBL * [83.91.180.61 listed in zen.spamhaus.org] * 1.6 RCVD_IN_SORBS_DUL RBL: SORBS: sent directly from dynamic IP address * [83.91.180.61 listed in dnsbl.sorbs.net] X-Spam-Level: ** X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on blackbird.jkkn.net X-Virus-Scanned: clamav-milter 0.95.3 at blackbird.jkkn.net X-Virus-Status: Clean Subject: ata driver downgrades transfer speed for Intel ICH5 SATA150 in RELENG_8 ? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Jan 2010 21:26:37 -0000 Hey, I just updated my kernel from RELEASE_8_0 to RELENG_8 and by rutine I compare my dmesg -a output to make sure everything still works as expected. I notices that the ata-driver suddently downgraded the speed of my Intel ICH5 SATS150 from SATA150 til UDMA133 - and I am not allowed to change it manually by using atacontrol. Can this have something to do with the recent rewrite of ata-sata.c ? http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/dev/ata/ata-sata.c.diff?r1=1.6.2.2;r2=1.6.2.3 By mav: http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/dev/ata/ata-sata.c Here is the dmesg output compared with RELEASE_8_0 to RELENG_8: ...cut out... atapci0: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xffa0-0xffaf at device 31.1 on pci0 ata0: on atapci0 ata0: [ITHREAD] ata1: on atapci0 ata1: [ITHREAD] atapci1: port 0xec00-0xec07,0xe800-0xe803,0xe400-0xe407,0xe000-0xe003,0xdc00-0xdc0f irq 18 at d evice 31.2 on pci0 atapci1: [ITHREAD] ata2: on atapci1 ata2: [ITHREAD] ata3: on atapci1 ata3: [ITHREAD] ...cut out... -ad4: 305245MB at ata2-master SATA150 +ad4: 305245MB at ata2-master UDMA133 ...cut out... -ad6: 305245MB at ata3-master SATA150 +ad6: 305245MB at ata3-master UDMA133 ...cut out... ar0: 305245MB status: READY ar0: disk0 READY (master) using ad4 at ata2-master ar0: disk1 READY (mirror) using ad6 at ata3-master ...end... Best regards, Kristian Krćmmer Nielsen, Odense, Denmark From owner-freebsd-stable@FreeBSD.ORG Sun Jan 24 21:28:36 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 18BEA106566B for ; Sun, 24 Jan 2010 21:28:36 +0000 (UTC) (envelope-from freebsd@com.jkkn.dk) Received: from blackbird.jkkn.net (blackbird.home6.jkkn.net [IPv6:2001:16d8:dd04:0:207:e9ff:fe62:64be]) by mx1.freebsd.org (Postfix) with ESMTP id 6E4A78FC0C for ; Sun, 24 Jan 2010 21:28:35 +0000 (UTC) Received: from [192.168.2.2] (online.jkkn.net. [83.91.180.61]) (authenticated bits=0) by blackbird.jkkn.net (envelope-from freebsd@com.jkkn.dk) (8.14.3/8.14.3) with ESMTP id o0OLSUaD002744 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Sun, 24 Jan 2010 22:28:31 +0100 (CET) (envelope-from freebsd@com.jkkn.dk) Message-ID: <4B5CBB7F.2010808@com.jkkn.dk> Date: Sun, 24 Jan 2010 22:28:31 +0100 From: =?ISO-8859-1?Q?Kristian_Kr=E6mmer_Nielsen?= User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.7) Gecko/20100111 Thunderbird/3.0.1 MIME-Version: 1.0 To: freebsd-stable@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=2.1 required=5.0 tests=RCVD_IN_PBL, RCVD_IN_SORBS_DUL autolearn=no version=3.2.5 X-Spam-Report: * 0.5 RCVD_IN_PBL RBL: Received via a relay in Spamhaus PBL * [83.91.180.61 listed in zen.spamhaus.org] * 1.6 RCVD_IN_SORBS_DUL RBL: SORBS: sent directly from dynamic IP address * [83.91.180.61 listed in dnsbl.sorbs.net] X-Spam-Level: ** X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on blackbird.jkkn.net X-Virus-Scanned: clamav-milter 0.95.3 at blackbird.jkkn.net X-Virus-Status: Clean Subject: ata driver downgrades transfer speed for Intel ICH5 SATA150 in RELENG_8 ? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Jan 2010 21:28:36 -0000 Hey, I just updated my kernel from RELEASE_8_0 to RELENG_8 and by rutine I compare my dmesg -a output to make sure everything still works as expected. I notices that the ata-driver suddently downgraded the speed of my Intel ICH5 SATS150 from SATA150 til UDMA133 - and I am not allowed to change it manually by using atacontrol. Can this have something to do with the recent rewrite of ata-sata.c ? http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/dev/ata/ata-sata.c.diff?r1=1.6.2.2;r2=1.6.2.3 By mav: http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/dev/ata/ata-sata.c Here is the dmesg output compared with RELEASE_8_0 to RELENG_8: ...cut out... atapci0: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xffa0-0xffaf at device 31.1 on pci0 ata0: on atapci0 ata0: [ITHREAD] ata1: on atapci0 ata1: [ITHREAD] atapci1: port 0xec00-0xec07,0xe800-0xe803,0xe400-0xe407,0xe000-0xe003,0xdc00-0xdc0f irq 18 at d evice 31.2 on pci0 atapci1: [ITHREAD] ata2: on atapci1 ata2: [ITHREAD] ata3: on atapci1 ata3: [ITHREAD] ...cut out... -ad4: 305245MB at ata2-master SATA150 +ad4: 305245MB at ata2-master UDMA133 ...cut out... -ad6: 305245MB at ata3-master SATA150 +ad6: 305245MB at ata3-master UDMA133 ...cut out... ar0: 305245MB status: READY ar0: disk0 READY (master) using ad4 at ata2-master ar0: disk1 READY (mirror) using ad6 at ata3-master ...end... Best regards, Kristian Krćmmer Nielsen, Odense, Denmark From owner-freebsd-stable@FreeBSD.ORG Sun Jan 24 21:45:41 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3EDE21065670; Sun, 24 Jan 2010 21:45:41 +0000 (UTC) (envelope-from mavbsd@gmail.com) Received: from mail-fx0-f226.google.com (mail-fx0-f226.google.com [209.85.220.226]) by mx1.freebsd.org (Postfix) with ESMTP id 9C5188FC08; Sun, 24 Jan 2010 21:45:40 +0000 (UTC) Received: by fxm26 with SMTP id 26so486385fxm.13 for ; Sun, 24 Jan 2010 13:45:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=rcYHoSN/Vq+P+c3cBbd6bi+yJGrFxh5AL3C0k4y/TNE=; b=pstD0Yxa9mWFHNKBZp5lqwxaHArmN/Liig+gQqRORlws/GolG/Xsm7+/Yj0MRNhgi7 iV5HosqcsUIWlmIoFvo7Zk1B84AACKP3V1Zu8MOYCGnWmfv24CekFVI8pLF6/VCFBjpo HFP4BZFnEscNHP4/NZwk3pwjaFG4P3Xh3YiuE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=vRg9UNIANKibgAXXT63R5GHchzTVxU7DMU45OWlqw9N4NujSJ1khjqbz61mwLkLnbC e/DH3flJkR5Lodk5fbBKb4AkEZOshlSQGJMucPkoifm5y94Q3Emrys9mtvjnBk8YZMuA jQ6XwzqowTfH2L+Ml6UCrW0tXRqKkqOPdjrRY= Received: by 10.223.75.66 with SMTP id x2mr4175164faj.7.1264369539445; Sun, 24 Jan 2010 13:45:39 -0800 (PST) Received: from mavbook.mavhome.dp.ua (pc.mavhome.dp.ua [212.86.226.226]) by mx.google.com with ESMTPS id 15sm2407944fxm.14.2010.01.24.13.45.38 (version=SSLv3 cipher=RC4-MD5); Sun, 24 Jan 2010 13:45:38 -0800 (PST) Sender: Alexander Motin Message-ID: <4B5CBF4B.2040205@FreeBSD.org> Date: Sun, 24 Jan 2010 23:44:43 +0200 From: Alexander Motin User-Agent: Thunderbird 2.0.0.23 (X11/20091212) MIME-Version: 1.0 To: "O. Hartmann" References: <1264364581.00211056.1264351201@10.7.7.3> In-Reply-To: <1264364581.00211056.1264351201@10.7.7.3> Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org, freebsd-questions@freebsd.org Subject: Re: PCIe audio cards: what is tob be preferred with FreeBSD 8.0/9-CURRENT? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 24 Jan 2010 21:45:41 -0000 O. Hartmann wrote: > Well, > At this very moment I utilise a M-Audio 5.1 PCI-audio board with which > I'm really satisfied. My next box doesn't have PCI slots at all (ASUS > P6T6-WS Revolution) and due to the fact I'm using Windows 7 sometimes > for recreational gaming, I'd like to have a moderate expensive audio > board with the workstation which is supported by FreeBSD 8/9. In the > past - means two or three ywars ago, I had problems with Soundblaster > PCIe boards, so I was recommended avoiding those and choosing the more > elabotrated M-Audio cards for the PCI bus. > At this moment, I look for the Soundblaster X-Fi range of PCIe cards, > but I'm not sure whether they are supported by FreeBSd 8/9. Any > suggestions? I would first test on-board HDA codec, placed on that motherboard. They are free and usually work with FreeBSD just out of the box, using snd_hda driver. Now snd_hda and snd_uaudio are only two drivers supporting multichannel playback. If you need analog connection, snd_hda can usually provide multichannel 24bit/192kHz playback. But also it supports digital SPDIF I/O, including AC3/DTS pass-through. Together with SPDIF-connected external audio receiver, even simple HDA codec could become very interesting high-quality choice. Personally I am completely fulfilled with combination of simple Realtek HDA codec, digitally connected via SPDIF to Marantz SR4001 receiver, loaded to the full-sized Eltax 7.1 speaker set. Previously I was using Creative Audigy2 ZS, but now it just collecting dust in my table. It works, but I really don't need it. PS: If you want to look cool, you may use optical SPDIF connection. :) -- Alexander Motin From owner-freebsd-stable@FreeBSD.ORG Sun Jan 24 21:54:43 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0578B106566B; Sun, 24 Jan 2010 21:54:43 +0000 (UTC) (envelope-from mavbsd@gmail.com) Received: from mail-fx0-f226.google.com (mail-fx0-f226.google.com [209.85.220.226]) by mx1.freebsd.org (Postfix) with ESMTP id 35F0E8FC1A; Sun, 24 Jan 2010 21:54:41 +0000 (UTC) Received: by fxm26 with SMTP id 26so490877fxm.13 for ; Sun, 24 Jan 2010 13:54:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :user-agent:mime-version:newsgroups:to:cc:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=EsVLB3AoYxVdcmOhg/E17qMGAwiszH33kOdv6DLGnkc=; b=KeZs8mx3sPtgIvFFstTBBUMInJngHEd+n5wrAaq/qEI/euXhjn4bJEgr1+ylmhClRE 9YsrBQduyrTPWC45Ut3EnusLxqw5hyfxuRv0LRrnvINCLKde0Ia1tajIVk/uQiFlXKvm EwXY0pZ0rD8QFyMHoTYuTTD7mT8KJoElhrSts= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:newsgroups:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; b=DG3i9KcESzUrIT7CyydH8AUK9G+opbU/AauE4kC2h4h5vL1F/2q4JqJIg7uZHyTZNF d+Jg2MIF3N1mNz+3nnTobUvW5vI9PvaSejp751QbMx7kp4eNk3DgoxtjiDh9yr/u6Qiu oYflKNK6cosVrMSRCknDJG+YVqe/vFdZH6UzM= Received: by 10.223.92.142 with SMTP id r14mr5880299fam.93.1264370080984; Sun, 24 Jan 2010 13:54:40 -0800 (PST) Received: from mavbook.mavhome.dp.ua (pc.mavhome.dp.ua [212.86.226.226]) by mx.google.com with ESMTPS id 16sm2415845fxm.8.2010.01.24.13.54.39 (version=SSLv3 cipher=RC4-MD5); Sun, 24 Jan 2010 13:54:40 -0800 (PST) Sender: Alexander Motin Message-ID: <4B5CC167.5010604@FreeBSD.org> Date: Sun, 24 Jan 2010 23:53:43 +0200 From: Alexander Motin User-Agent: Thunderbird 2.0.0.23 (X11/20091212) MIME-Version: 1.0 Newsgroups: lucky.freebsd.fs,lucky.freebsd.questions,lucky.freebsd.stable To: Dan Naumov References: <883b2dc51001240905r4cfbf830i3b9b400969ac261b@mail.gmail.com> <1264368182.00211075.1264355402@10.7.7.3> In-Reply-To: <1264368182.00211075.1264355402@10.7.7.3> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-fs@freebsd.org, Jason Edwards , FreeBSD-STABLE Mailing List , freebsd-questions@freebsd.org Subject: Re: 8.0-RELEASE/amd64 - full ZFS install - low read and write disk performance X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Jan 2010 21:54:43 -0000 Dan Naumov wrote: > This works out to 1GB in 36,2 seconds / 28,2mb/s in the first test and > 4GB in 143.8 seconds / 28,4mb/s and somewhat consistent with the > bonnie results. It also sadly seems to confirm the very slow speed :( > The disks are attached to a 4-port Sil3124 controller and again, my > Windows benchmarks showing 65mb/s+ were done on exact same machine, > with same disks attached to the same controller. Only difference was > that in Windows the disks weren't in a mirror configuration but were > tested individually. I do understand that a mirror setup offers > roughly the same write speed as individual disk, while the read speed > usually varies from "equal to individual disk speed" to "nearly the > throughput of both disks combined" depending on the implementation, > but there is no obvious reason I am seeing why my setup offers both > read and write speeds roughly 1/3 to 1/2 of what the individual disks > are capable of. Dmesg shows: > > atapci0: port 0x1000-0x100f mem > 0x90108000-0x9010807f,0x90100000-0x90107fff irq 21 at device 0.0 on > pci4 > ad8: 1907729MB at ata4-master SATA300 > ad10: 1907729MB at ata5-master SATA300 8.0-RELEASE, and especially 8-STABLE provide alternative, much more functional driver for this controller, named siis(4). If your SiI3124 card installed into proper bus (PCI-X or PCIe x4/x8), it can be really fast (up to 1GB/s was measured). -- Alexander Motin From owner-freebsd-stable@FreeBSD.ORG Sun Jan 24 22:48:00 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2E9751065672 for ; Sun, 24 Jan 2010 22:48:00 +0000 (UTC) (envelope-from alteriks@gmail.com) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.159]) by mx1.freebsd.org (Postfix) with ESMTP id B10148FC08 for ; Sun, 24 Jan 2010 22:47:59 +0000 (UTC) Received: by fg-out-1718.google.com with SMTP id 16so675304fgg.13 for ; Sun, 24 Jan 2010 14:47:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:content-type:to:subject :references:date:mime-version:content-transfer-encoding:from :message-id:in-reply-to:user-agent; bh=hVMDWJy4hI/7/XcZ9zeaZjtdv0dfMfokm34a96dQeoI=; b=dnuhJ7b7fibIGQhQN7v8aZO980NP+iYTthSUUU0Bg1cNM68ZyFHGEtjM0xDpv9OyRN 5sHP676eAglPtFS8uGXOTTYc3UJtapKQBZ54pCgI/dCsTLfkSCrjgt9RKTLrBKLHflWc WSFG6TQlnpHWynm7BHJ0yOprBr+H32vtFukv4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=content-type:to:subject:references:date:mime-version :content-transfer-encoding:from:message-id:in-reply-to:user-agent; b=r7KkqS0GtueTRCJr2jen9OTMVLkhcDN/UD877dezac+ZMezxJuX2qxR39lvHsb25fA wuad/8YStobbgaOyXu0T5sHLNnh0D90pA5WgCeVqQd1XPQIu1uk7WzNDQx9dFGzPTW++ 44ch7rh1WYe10K3ORMcIanU9DX+ZZZ0Mtnd2Q= Received: by 10.87.46.12 with SMTP id y12mr271578fgj.47.1264373278632; Sun, 24 Jan 2010 14:47:58 -0800 (PST) Received: from localhost (188.146.125.70.nat.umts.dynamic.eranet.pl [188.146.125.70]) by mx.google.com with ESMTPS id 13sm2427637fxm.13.2010.01.24.14.47.55 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sun, 24 Jan 2010 14:47:58 -0800 (PST) Content-Type: text/plain; charset=utf-8; format=flowed; delsp=yes To: "Jeremy Chadwick" , freebsd-stable@freebsd.org References: <684e57ec1001231226p447ea769q6379c1aa099b0216@mail.gmail.com> <20100124014314.GA28672@icarus.home.lan> Date: Sun, 24 Jan 2010 23:47:46 -0000 MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: "Krzysztof Dajka" Message-ID: In-Reply-To: <20100124014314.GA28672@icarus.home.lan> User-Agent: Opera Mail/10.00 (FreeBSD) Cc: Subject: Re: Extra keys in multimedia keyboard doesn't work X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 24 Jan 2010 22:48:00 -0000 On Sun, 24 Jan 2010 01:43:14 -0000, Jeremy Chadwick wrote: > If so: yes, FreeBSD's USB driver appears to lack support for these. Or, > well, it did on RELENG_7 (which is a completely different USB driver), > so it sounds like RELENG_8 needs some work in this regard. I did check my keyboard with FreeBSD 7.2 and it wasn't supported either. Xev also didn't return anything. From owner-freebsd-stable@FreeBSD.ORG Sun Jan 24 22:55:20 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9D68D1065672 for ; Sun, 24 Jan 2010 22:55:20 +0000 (UTC) (envelope-from aragon@phat.za.net) Received: from mail.geek.sh (decoder.geek.sh [196.36.198.81]) by mx1.freebsd.org (Postfix) with ESMTP id 361C88FC0C for ; Sun, 24 Jan 2010 22:55:19 +0000 (UTC) Received: from igor.geek.sh (unknown [196.209.245.239]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mail.geek.sh (Postfix) with ESMTPSA id 78DC639888 for ; Mon, 25 Jan 2010 00:38:17 +0200 (SAST) Message-ID: <4B5CCBDA.3090403@phat.za.net> Date: Mon, 25 Jan 2010 00:38:18 +0200 From: Aragon Gouveia User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.1.5) Gecko/20100109 Thunderbird/3.0 MIME-Version: 1.0 To: freebsd-stable@freebsd.org References: <4B54C100.9080906@mail.zedat.fu-berlin.de> In-Reply-To: <4B54C100.9080906@mail.zedat.fu-berlin.de> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: immense delayed write to file system (ZFS and UFS2), performance issues X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Jan 2010 22:55:20 -0000 On 01/18/10 22:13, O. Hartmann wrote: > Symptome: All boxes have ZFS and UFS2 filesystems. Since two weeks or > so, sometimes the I/O performance drops massively when doing 'svn > update', 'make world' or even 'make kernel'. It doesn't matter what > memory and how many cpu the box has, it get stuck for several seconds > and freezing. On the UP box, this is sometimes for 10 - 20 seconds. > A very interesting phenomenon is the massively delayed file writing on > ZFS filesystems I realise. Editing a file in 'vi' running on one XTerm > and having in another Xterminal my shell for compiling this file, it > takes sometimes up to 20 seconds to get the file updated after it has > been written. It's like having an old, slow NFS connection with long > cache delays. > These massively delayed file transactions are not necessarely under > heavy load, sometimes they occur in a relaxed situation. They seem to > occur much more often on the UP box than on the SMP boxes, but this > strange phenomenon also occur on the Dell Poweredge II, which has 16GB > RAM and summa summarum 16 cores. This phenomenon does occur on ZFS- and > UFS2 filesystems as well. It is hardly reproducable. I'm experiencing the same thing, except in my case it's most noticeable when writing to a USB flash drive with a FAT32 filesystem. It slows the entire system down, even if the data being written is coming from cache or a memory file system. I don't know if it's related. I'm running 8-STABLE from about 4 December. Regards, Aragon From owner-freebsd-stable@FreeBSD.ORG Sun Jan 24 23:07:15 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A26AA106566B for ; Sun, 24 Jan 2010 23:07:15 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from mail2.fluidhosting.com (mx21.fluidhosting.com [204.14.89.4]) by mx1.freebsd.org (Postfix) with ESMTP id 302268FC08 for ; Sun, 24 Jan 2010 23:07:14 +0000 (UTC) Received: (qmail 24868 invoked by uid 399); 24 Jan 2010 23:07:14 -0000 Received: from localhost (HELO foreign.dougb.net) (dougb@dougbarton.us@127.0.0.1) by localhost with ESMTPAM; 24 Jan 2010 23:07:14 -0000 X-Originating-IP: 127.0.0.1 X-Sender: dougb@dougbarton.us Message-ID: <4B5CD2A0.30305@FreeBSD.org> Date: Sun, 24 Jan 2010 15:07:12 -0800 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.9.1.7) Gecko/20100123 Thunderbird/3.0.1 MIME-Version: 1.0 To: Harald Schmalzbauer References: <4B56AB6F.9010303@omnilan.de> <86eilhwzbh.fsf@kopusha.onet> <4B5A4A8C.8070707@omnilan.de> <4B5C11BD.7080103@ipfw.ru> <4B5C28E3.8080006@omnilan.de> In-Reply-To: <4B5C28E3.8080006@omnilan.de> X-Enigmail-Version: 1.0 OpenPGP: id=D5B2F0FB Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org, Mikolaj Golub , "Alexander V. Chernikov" Subject: Re: top Segmentation faulting on 8.0p2 amd64 (nss_ldapd problem?) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Jan 2010 23:07:15 -0000 On 01/24/10 03:02, Harald Schmalzbauer wrote: > Alexander V. Chernikov schrieb am 24.01.2010 10:24 (localtime): >> Please try to rebuild port with >> >> post-configure: >> @${REINPLACE_CMD} -e 's/^\(CFLAGS .*\)-O2 \(.*\)$$/\1 -O0 \2/' >> ${WRKSRC}/nss/Makefile That should be pre- or post- patch, since it's actually modifying something. hth, Doug -- Improve the effectiveness of your Internet presence with a domain name makeover! http://SupersetSolutions.com/ Computers are useless. They can only give you answers. -- Pablo Picasso From owner-freebsd-stable@FreeBSD.ORG Sun Jan 24 23:12:17 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 362F71065670 for ; Sun, 24 Jan 2010 23:12:17 +0000 (UTC) (envelope-from melifaro@ipfw.ru) Received: from no.spam.no.ddos.ru (no.spam.no.ddos.ru [77.73.233.132]) by mx1.freebsd.org (Postfix) with ESMTP id D7B388FC13 for ; Sun, 24 Jan 2010 23:12:16 +0000 (UTC) Received: from ws.ipfw.ru (secured.by.ipfw.ru [81.200.11.182]) by no.spam.no.ddos.ru (Postfix) with ESMTPA id 158C237601C; Sun, 24 Jan 2010 23:12:15 +0000 (UTC) Message-ID: <4B5CD36F.9010302@ipfw.ru> Date: Mon, 25 Jan 2010 02:10:39 +0300 From: "Alexander V. Chernikov" User-Agent: Thunderbird 2.0.0.23 (X11/20091103) MIME-Version: 1.0 To: Doug Barton References: <4B56AB6F.9010303@omnilan.de> <86eilhwzbh.fsf@kopusha.onet> <4B5A4A8C.8070707@omnilan.de> <4B5C11BD.7080103@ipfw.ru> <4B5C28E3.8080006@omnilan.de> <4B5CD2A0.30305@FreeBSD.org> In-Reply-To: <4B5CD2A0.30305@FreeBSD.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Harald Schmalzbauer , freebsd-stable@freebsd.org, Mikolaj Golub Subject: Re: top Segmentation faulting on 8.0p2 amd64 (nss_ldapd problem?) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Jan 2010 23:12:17 -0000 Doug Barton wrote: > On 01/24/10 03:02, Harald Schmalzbauer wrote: >> Alexander V. Chernikov schrieb am 24.01.2010 10:24 (localtime): >>> Please try to rebuild port with >>> >>> post-configure: >>> @${REINPLACE_CMD} -e 's/^\(CFLAGS .*\)-O2 \(.*\)$$/\1 -O0 \2/' >>> ${WRKSRC}/nss/Makefile > > That should be pre- or post- patch, since it's actually modifying > something. I can't do this before configure - Makefile.in contains only @CFLAGS@ which needs to be substituted from configure and CFLAGS cannot be predicted due to possible environment/make.conf variables > > > hth, > > Doug > From owner-freebsd-stable@FreeBSD.ORG Sun Jan 24 23:15:20 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 95A78106566C for ; Sun, 24 Jan 2010 23:15:20 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from mail2.fluidhosting.com (mx21.fluidhosting.com [204.14.89.4]) by mx1.freebsd.org (Postfix) with ESMTP id 22EE28FC13 for ; Sun, 24 Jan 2010 23:15:19 +0000 (UTC) Received: (qmail 919 invoked by uid 399); 24 Jan 2010 23:15:19 -0000 Received: from localhost (HELO foreign.dougb.net) (dougb@dougbarton.us@127.0.0.1) by localhost with ESMTPAM; 24 Jan 2010 23:15:19 -0000 X-Originating-IP: 127.0.0.1 X-Sender: dougb@dougbarton.us Message-ID: <4B5CD484.5040500@FreeBSD.org> Date: Sun, 24 Jan 2010 15:15:16 -0800 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.9.1.7) Gecko/20100123 Thunderbird/3.0.1 MIME-Version: 1.0 To: "Alexander V. Chernikov" References: <4B56AB6F.9010303@omnilan.de> <86eilhwzbh.fsf@kopusha.onet> <4B5A4A8C.8070707@omnilan.de> <4B5C11BD.7080103@ipfw.ru> <4B5C28E3.8080006@omnilan.de> <4B5CD2A0.30305@FreeBSD.org> <4B5CD36F.9010302@ipfw.ru> In-Reply-To: <4B5CD36F.9010302@ipfw.ru> X-Enigmail-Version: 1.0 OpenPGP: id=D5B2F0FB Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Harald Schmalzbauer , freebsd-stable@freebsd.org, Mikolaj Golub Subject: Re: top Segmentation faulting on 8.0p2 amd64 (nss_ldapd problem?) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Jan 2010 23:15:20 -0000 On 01/24/10 15:10, Alexander V. Chernikov wrote: > Doug Barton wrote: >> On 01/24/10 03:02, Harald Schmalzbauer wrote: >>> Alexander V. Chernikov schrieb am 24.01.2010 10:24 (localtime): >>>> Please try to rebuild port with >>>> >>>> post-configure: >>>> @${REINPLACE_CMD} -e 's/^\(CFLAGS .*\)-O2 \(.*\)$$/\1 -O0 \2/' >>>> ${WRKSRC}/nss/Makefile >> >> That should be pre- or post- patch, since it's actually modifying >> something. > I can't do this before configure - > Makefile.in contains only @CFLAGS@ which needs to be substituted from > configure and CFLAGS cannot be predicted due to > possible environment/make.conf variables um, that's odd, but I'll take your word for it. :) Doug -- Improve the effectiveness of your Internet presence with a domain name makeover! http://SupersetSolutions.com/ Computers are useless. They can only give you answers. -- Pablo Picasso From owner-freebsd-stable@FreeBSD.ORG Mon Jan 25 00:14:28 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 92D251065679; Mon, 25 Jan 2010 00:14:28 +0000 (UTC) (envelope-from dan.naumov@gmail.com) Received: from mail-gx0-f214.google.com (mail-gx0-f214.google.com [209.85.217.214]) by mx1.freebsd.org (Postfix) with ESMTP id 132E78FC16; Mon, 25 Jan 2010 00:14:27 +0000 (UTC) Received: by gxk6 with SMTP id 6so1170273gxk.13 for ; Sun, 24 Jan 2010 16:14:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=3YpQos/pk73Wtl6z7um1EgvYkoli8EkkyMGyYzrDFrI=; b=spW34RSIABu2YFypcGftfCPTkErZI9haz41QGL4j1ytdv26WZK8oMCiXFgEKW3U9SB aeLTtrXwxtyTlV732rXZZGeE9/Yaij/J6EN7/uFMrscbCtl4n2dL+G1tI7xTDQxARxcm 0kuqr2ZydgxS1HzSiAsyygBE0OMNhiMG21YKI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=TqUujur+bzY1vb7yDeTumzF9zpQMrVEkDEq2HL4hCwv+KIK59tEBRCBDxhZ2EA125j FdDIv9gpSzVWY03vXguqD07gXp7R/kWjXHwZ6OsBD7jbjFIZe2ldcDoMOEyHZyBabean swg/9My9JaxZzHL2sJd5BNT1se73+L+BH4irQ= MIME-Version: 1.0 Received: by 10.101.10.24 with SMTP id n24mr7044299ani.78.1264378467375; Sun, 24 Jan 2010 16:14:27 -0800 (PST) In-Reply-To: <4B5CC167.5010604@FreeBSD.org> References: <883b2dc51001240905r4cfbf830i3b9b400969ac261b@mail.gmail.com> <1264368182.00211075.1264355402@10.7.7.3> <4B5CC167.5010604@FreeBSD.org> Date: Mon, 25 Jan 2010 02:14:27 +0200 Message-ID: From: Dan Naumov To: Alexander Motin Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-fs@freebsd.org, Jason Edwards , FreeBSD-STABLE Mailing List , freebsd-questions@freebsd.org Subject: Re: 8.0-RELEASE/amd64 - full ZFS install - low read and write disk performance X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jan 2010 00:14:28 -0000 On Sun, Jan 24, 2010 at 11:53 PM, Alexander Motin wrote: > Dan Naumov wrote: >> This works out to 1GB in 36,2 seconds / 28,2mb/s in the first test and >> 4GB in 143.8 seconds / 28,4mb/s and somewhat consistent with the >> bonnie results. It also sadly seems to confirm the very slow speed :( >> The disks are attached to a 4-port Sil3124 controller and again, my >> Windows benchmarks showing 65mb/s+ were done on exact same machine, >> with same disks attached to the same controller. Only difference was >> that in Windows the disks weren't in a mirror configuration but were >> tested individually. I do understand that a mirror setup offers >> roughly the same write speed as individual disk, while the read speed >> usually varies from "equal to individual disk speed" to "nearly the >> throughput of both disks combined" depending on the implementation, >> but there is no obvious reason I am seeing why my setup offers both >> read and write speeds roughly 1/3 to 1/2 of what the individual disks >> are capable of. Dmesg shows: >> >> atapci0: port 0x1000-0x100f mem >> 0x90108000-0x9010807f,0x90100000-0x90107fff irq 21 at device 0.0 on >> pci4 >> ad8: 1907729MB at ata4-master SATA300 >> ad10: 1907729MB at ata5-master SATA300 > > 8.0-RELEASE, and especially 8-STABLE provide alternative, much more > functional driver for this controller, named siis(4). If your SiI3124 > card installed into proper bus (PCI-X or PCIe x4/x8), it can be really > fast (up to 1GB/s was measured). > > -- > Alexander Motin Sadly, it seems that utilizing the new siis driver doesn't do much good: Before utilizing siis: iozone -s 4096M -r 512 -i0 -i1 random random bkwd record stride KB reclen write rewrite read reread read write read rewrite read fwrite frewrite fread freread 4194304 512 28796 28766 51610 50695 After enabling siis in loader.conf (and ensuring the disks show up as ada): iozone -s 4096M -r 512 -i0 -i1 random random bkwd record stride KB reclen write rewrite read reread read write read rewrite read fwrite frewrite fread freread 4194304 512 28781 28897 47214 50540 I've checked with the manufacturer and it seems that the Sil3124 in this NAS is indeed a PCI card. More info on the card in question is available at http://green-pcs.co.uk/2009/01/28/tranquil-bbs2-those-pci-cards/ I have the card described later on the page, the one with 4 SATA ports and no eSATA. Alright, so it being PCI is probably a bottleneck in some ways, but that still doesn't explain the performance THAT bad, considering that same hardware, same disks, same disk controller push over 65mb/s in both reads and writes in Win2008. And agian, I am pretty sure that I've had "close to expected" results when I was booting an UFS FreeBSD installation off an SSD (attached directly to SATA port on the motherboard) while running the same kinds of benchmarks with Bonnie and DD on a ZFS mirror made directly on top of 2 raw disks. - Sincerely, Dan Naumov From owner-freebsd-stable@FreeBSD.ORG Mon Jan 25 00:16:12 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6F7961065676 for ; Mon, 25 Jan 2010 00:16:12 +0000 (UTC) (envelope-from russell.yount@gmail.com) Received: from qw-out-2122.google.com (qw-out-2122.google.com [74.125.92.27]) by mx1.freebsd.org (Postfix) with ESMTP id 08FEF8FC1A for ; Mon, 25 Jan 2010 00:16:11 +0000 (UTC) Received: by qw-out-2122.google.com with SMTP id 5so138918qwd.7 for ; Sun, 24 Jan 2010 16:16:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=RUcdW7V/XQLZrAxKe4PVWw1sWQ14Cd14PJn791WsiZQ=; b=RBLpMMpGJA7fPEn8XfSMzUauNKImUq5OzvpmUQFW5Wf6o0RIB6UBFRDODdGOr6Kgjf +go138TIsPt5Qr9gmiUSDe756zEhMpt5VUjbPZwPfxwDsp6hzBlp5UKCS168e2Bacrkn 2Fxdz13VhdFBYJiOILPhrrRhvpaoaSvOxnwrA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=t5cnVVYEhBzyTdx9rLxmC5H8DGz9F0v3O2dPt82506ZMSjrnx67BriC9IMIknyH5eL GtJZ7UWKmKiY5q5N38uAJ0jmduJ+RcSdNDSV5Rm7EymaPdm/Utrg1j3Nr5szg51kSPOw q+BC/u9Mc5KnAGOT+l7DJAyAWR8xuK4wZNl/c= MIME-Version: 1.0 Received: by 10.220.121.214 with SMTP id i22mr454390vcr.65.1264378571234; Sun, 24 Jan 2010 16:16:11 -0800 (PST) In-Reply-To: <4B5BA0C1.8010901@errno.com> References: <4B521FC2.4050402@errno.com> <4B535AAE.3060308@errno.com> <4B5BA0C1.8010901@errno.com> Date: Sun, 24 Jan 2010 19:16:11 -0500 Message-ID: From: Russell Yount To: Sam Leffler Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-stable@freebsd.org Subject: Re: atheros broadcast/multicast corruption with multiple hostap's X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 25 Jan 2010 00:16:12 -0000 On Sat, Jan 23, 2010 at 8:22 PM, Sam Leffler wrote: > Russell Yount wrote: > > On Sun, Jan 17, 2010 at 1:45 PM, Sam Leffler > > wrote: > > > > Russell Yount wrote: > > > > > > > > On Sat, Jan 16, 2010 at 3:21 PM, Sam Leffler > > >> wrote: > > > > Russell Yount wrote: > > > > It seems AP to client broadcasts/multicasts traffic is > > broken when using WPA2/802.11i with multiple hostapds in > 8.0. > > > > Only the SSID associated with the last hostapd to be > > started has > > AP to client broadcasts/multicasts being delivered > correctly. > > > > The AP and client are 8.0 freebsd systems althought I see > > same > > problems with windows XP as a client. > > > > The AP has 4 hostapds configured to use TLS with client > > certificates for > > authentication. (hostapd recompiled with > > HOSTAPD_CFLAGS=-DEAP_SERVER) > > The AP and client radio are shown as ath0: AR5212 mac 5.9 > > RF5112 > > phy 4.3 > > in dmesg. > > > > Client authenticate using client certificates associate > > correctly > > to all 4 SSIDs. Unicast traffic flows correctly between > > clients > > and AP > > for all for 4 SSIDs. Client to AP broadcast/multicast > > traffic works > > on of 4 SSIDs. AP to client broadcast/multicast traffic > > only works > > on 1 of the SSIDs. I have documented this using ARP > > broadcasts, > > but normal IP broadcasts also observed to corrupted. > > > > When an ARP request is send through the AP to an > > associated client > > it seems to be trashed on any of the SSID except the one > > associated > > with the last hostapd to be started. Here is the output of > > client side > > tcpdump showing the problems. > > > > In the first client side tcpdump with the hostapd > associated > > with the SSID > > being associaed with the last hostapd started and the > traffic > > flowing > > normally. > > > > In the second client side tcpdump with the hostapd > associated > > with the SSID > > being not the last hostapd started the ARP request is > resent > > multiple times > > and appears corrupted. > > > > I would really like to find a fix for this. > > Any help would be greatly appreciated. > > > > > > This sounds like the crypto encap of the frame is clobbering > the > > mbuf contents. You can verify this by setting up multiple > > vaps w/o > > WPA. If this is the problem look for the mbuf copy logic for > > mcast > > frames and make sure a deep copy is done. > > > > Sam > > > > The four VAPs broadcast traffic works find without WPA if I > > do not start hostapds on them > > I have been trying to discovery why broadcast traffic only > > works correctly on the VAP associated with the last hostapd to > > be started. I have move with VAP has the working broadcast > > traffic by restarting the hostapd > > associated with it. > > It would seem something in the WPA/802.1x layer initialization > > remembers which hostapd was started last and that affected the > > crypto encap. > > I keep looking but do not see any place in the code that could > > account for this. > > It seems the corrupt crypto encap also happens on broadcast > > between stations. > > Please correct me if I am wrong: > > but when using hostapd normally traffic is bridged withing the > card. > > So if a station sends to the VAP a broadcast it is actaully > > sending a non- broadcast frame to the AP > > and the AP sends the frame to all the other stations. > > > > > > I told you waht the likely problem is. Look in the net80211 layer > > in the kernel for the problem. > > > > Sam > > > > > > > > > > I tried to find problems in mbuf corruption > > in ieee80211_output.c by placing > > > > m = m_unshare(m,M_NOWAIT); > > if (m == NULL) { > > IEEE80211_DPRINTF(vap, IEEE80211_MSG_OUTPUT, > > "%s: cannot get writable mbuf\n", __func__); > > return NULL; > > } > > > > at begining ieee80211_mbuf_adjust() and at > > beginning of ieee80211_encap() with no change > > in the broadcast traffic behaviour. > > > > I tried then to in ieee80211_crypto.c substituting > > > > flags |= IEEE80211_KEY_SWCRYPT; > > > > for the encryption capabilities test code > > > > if ((ic->ic_cryptocaps & (1< > IEEE80211_DPRINTF(vap, IEEE80211_MSG_CRYPTO, > > "%s: no h/w support for cipher %s, falling back to s/w\n", > > __func__, cip->ic_name); > > flags |= IEEE80211_KEY_SWCRYPT; > > } > > > > to force all the encryption to be done in software. > > > > This fixed the broadcast traffic problem but without > > hardware support its very slow and really loads machine. > > Enabling in the debug code to ath and net80211 > > > > and enabled ATH_DEBUG_KEYCACHE in if_ath.c and > > IEEE80211_MSG_CRYPTO in net80211 code. > > > > It seems that all the VAPS sets the broadcast key for > > mac ff:ff:ff:ff:ff:ff in the ath device so I assume > > they conflict and the last one setting the key is the > > working one; that would explain why the last hostapd > > started is the only one with working broadcast code > > to clients. > > > > In if_ath.c the code > > > > if ((k->wk_flags & IEEE80211_KEY_GROUP) && sc->sc_mcastkey) { > > /* > > * Group keys on hardware that supports multicast frame > > * key search use a mac that is the sender's address with > > * the high bit set instead of the app-specified address. > > */ > > IEEE80211_ADDR_COPY(gmac, bss->ni_macaddr); > > gmac[0] |= 0x80; > > mac = gmac; > > } else > > mac = k->wk_macaddr; > > > > seems to indicate that for multiple VAPs the ath chips > > needs to be able to distinguish between broadcast keys > > by using a permutation of VAPs bssid. > > > > But in if_athvar.h the code does not seem complete > > and sc->sc_mcastkey is also set false. > > > > #ifdef notyet > > #define ath_hal_hasmcastkeysearch(_ah) \ > > (ath_hal_getcapability(_ah, HAL_CAP_MCAST_KEYSRCH, 0, NULL) == > > HAL_OK) > > #define ath_hal_getmcastkeysearch(_ah) \ > > (ath_hal_getcapability(_ah, HAL_CAP_MCAST_KEYSRCH, 1, NULL) == > > HAL_OK) > > #else > > #define ath_hal_getmcastkeysearch(_ah) 0 > > #endif > > > > I am using cards with an AR5212 which does seem to have > > multiple bssid support working so I hope they should also > > support mcastkeysearch capability. Maybe only some > > firmware revisions have this? > > > > Do you know what the status of the HAL code is for > > supporting this? Why it is commented out in if_athvar.h? > > Good work analyzing things; been a long time since I looked at this. I > vaguely recall disabling mcastkey searching because of problems with > WEP. I'm surprised WPA is broken as that was a standard test case. > > You can try enabling the notyet code and see if the right thing happens. > I don't see any indication of the mac rev for your part but I expect it > supports this as it was only very early parts that had issues. > > If enabling the mcastkey search mechanism doesn't fix this I might've > broken things with changes to explicitly mark group keys when hostapd > plumbs their contents. I recall doing this for mwl which doesn't have > an indexed key table like ath (it uses the mac address of the local bss > and/or associated station to find the data structure where crypto keys > are stored). > > I haven't looked at this stuff in a long time and can't setup a system > to test but if you keep pushing on this I'll try to help w/ advise. > > Sam > Sam, I have the ath working with multiple hostap's and multicast key search and also have the station side working, but I do not like how I got the station side working. Let me explain what I have done and what I am tryinig to figure out now. I would like to submit a patch once I get the last issues resolved. In if_athvar.h I uncommented your macros #define ath_hal_hasmcastkeysearch(_ah) \ (ath_hal_getcapability(_ah, HAL_CAP_MCAST_KEYSRCH, 0, NULL) == HAL_OK) #define ath_hal_getmcastkeysearch(_ah) \ (ath_hal_getcapability(_ah, HAL_CAP_MCAST_KEYSRCH, 1, NULL) == HAL_OK) and added a macro #define ath_hal_setmcastkeysearch(_ah, _v) \ ath_hal_setcapability(_ah, HAL_CAP_MCAST_KEYSRCH, 0, _v, NULL) In if_ath.c I added /* * if multicast key search is supported by device enable it */ if (ath_hal_hasmcastkeysearch(sc->sc_ah)) { if (!ath_hal_getmcastkeysearch(sc->sc_ah)) { ath_hal_setmcastkeysearch(sc->sc_ah,1); } } just before sc->sc_mcastkey = ath_hal_getmcastkeysearch(ah); in ath_attach(). Then in ieee80211_ioctl.c I changed ieee80211_ioctl_setkey() so not to assign a slot when opering in hostap mode by changing /* * Global slots start off w/o any assigned key index. * Force one here for consistency with IEEE80211_IOC_WEPKEY. */ if (wk->wk_keyix == IEEE80211_KEYIX_NONE) wk->wk_keyix = kid; to be /* * Global slots start off w/o any assigned key index. * Force one here for consistency with IEEE80211_IOC_WEPKEY. */ if (vap->iv_opmode != IEEE80211_M_HOSTAP && wk->wk_keyix == IEEE80211_KEYIX_NONE) wk->wk_keyix = kid; to preserve the station mode operation I had to keep the key index assignment when not VAP is not operating in hostapd mode. This seems wrong to me. Now here is the question I am trying to understand. Group keys are special as they are used in only one direction only; sending on hostap and receiving on a station. The multicast key search code when operating in hostap mode permits the lookup of the key for encryption by sending VAP bssid on transmission of multicast traffic. Is there a corresponding station side multicast key search that would let the lookup of the encryption key be done on receive by looking up the sending VAP for received multicast traffic. If so it seems it could enable multiple stations also to work on one device. I noticed in the linux legacy hal ar5212_keycache.c the following code/comment u_int32_t validBit = AR_KEYTABLE_VALID; ...... /* * If upper layers have requested mcast MACaddr lookup, then * signify this to the hw by setting the (poorly named) validBit * to 0. Yes, really 0. The hardware specs, pcu_registers.txt, is * has incorrectly named ValidBit. It should be called "Unicast". * When the Key Cache entry is to decrypt Unicast frames, then this * bit should be '1'; for multicast and broadcast frames, this bit is '0'. */ if (mac[0] & 0x01) { validBit = 0; } ..... OS_KC_WRITE(ah, AR_KEYTABLE_MAC0(entry), macLo); OS_KC_WRITE(ah, AR_KEYTABLE_MAC1(entry), macHi | validBit); where as in the freebsd hal in ar5212_keycache.c the AR_KEYTABLE_VALID is always set OS_REG_WRITE(ah, AR_KEYTABLE_MAC0(entry), macLo); OS_REG_WRITE(ah, AR_KEYTABLE_MAC1(entry), macHi | AR_KEYTABLE_VALID); by not setting the AR_KEYTABLE_VALID bit would the multicast key search code work for station mode? I am just guessing here, but seemed like a likely explaination? -Russ From owner-freebsd-stable@FreeBSD.ORG Mon Jan 25 00:28:07 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DA64C106568D for ; Mon, 25 Jan 2010 00:28:07 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from qmta15.emeryville.ca.mail.comcast.net (qmta15.emeryville.ca.mail.comcast.net [76.96.27.228]) by mx1.freebsd.org (Postfix) with ESMTP id BC0AD8FC0C for ; Mon, 25 Jan 2010 00:28:07 +0000 (UTC) Received: from omta15.emeryville.ca.mail.comcast.net ([76.96.30.71]) by qmta15.emeryville.ca.mail.comcast.net with comcast id ZbLp1d0031Y3wxoAFcU8oc; Mon, 25 Jan 2010 00:28:08 +0000 Received: from koitsu.dyndns.org ([98.248.46.159]) by omta15.emeryville.ca.mail.comcast.net with comcast id ZcU71d0013S48mS8bcU7M4; Mon, 25 Jan 2010 00:28:07 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id D2A6E1E3033; Sun, 24 Jan 2010 16:28:05 -0800 (PST) Date: Sun, 24 Jan 2010 16:28:05 -0800 From: Jeremy Chadwick To: freebsd-stable@freebsd.org Message-ID: <20100125002805.GA88711@icarus.home.lan> References: <684e57ec1001231226p447ea769q6379c1aa099b0216@mail.gmail.com> <20100124014314.GA28672@icarus.home.lan> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) Subject: Re: Extra keys in multimedia keyboard doesn't work X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 25 Jan 2010 00:28:07 -0000 On Sun, Jan 24, 2010 at 11:47:46PM -0000, Krzysztof Dajka wrote: > On Sun, 24 Jan 2010 01:43:14 -0000, Jeremy Chadwick > wrote: > > >If so: yes, FreeBSD's USB driver appears to lack support for these. Or, > >well, it did on RELENG_7 (which is a completely different USB driver), > >so it sounds like RELENG_8 needs some work in this regard. > > I did check my keyboard with FreeBSD 7.2 and it wasn't supported > either. Xev also didn't return anything. My sentence meant: it didn't work on RELENG_7, which used a different USB stack compared to RELENG_8. :-) -- | Jeremy Chadwick jdc@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Mon Jan 25 00:29:59 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A424E1065670; Mon, 25 Jan 2010 00:29:59 +0000 (UTC) (envelope-from dan.naumov@gmail.com) Received: from mail-yw0-f197.google.com (mail-yw0-f197.google.com [209.85.211.197]) by mx1.freebsd.org (Postfix) with ESMTP id 22C368FC18; Mon, 25 Jan 2010 00:29:58 +0000 (UTC) Received: by ywh35 with SMTP id 35so2328435ywh.7 for ; Sun, 24 Jan 2010 16:29:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=I1rTt5+AtkuF3NDO8eiHPav4aNN1MzV8f6fQzMt6M2o=; b=nFlhTdrrGcnTNDP04CbMdgueZF/TVHKYCOVrjUvV6M3mRPZPJ0/r196MVWaVuzBFg6 3RHTPgiiOV8yZYJsOK7cnGYtvs08DSHgNUWuH6a7A9QOZFt3LmPeQJCKnxAthWD+SPmo hsr26e9Duu/8GRoWPTFLzae7X6pO9K2NY2AlA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=RRz4XmYnSpIYQbMaj1fTu0CAk1gV4frh4LkR8pa1zHdsw/IZPK4UBITtNoCxTFpzlC Mt5CyAzj6TNixWqSV6WsL/wZxqfIc/hGECFd7Y9v6Pah7HtkqRWwQ0OBvQhWuq5VpLjI 7bvpH6+MyRP9T/V6vP85ZOYwEfpQKLStuPjWc= MIME-Version: 1.0 Received: by 10.101.186.1 with SMTP id n1mr6994422anp.124.1264379389237; Sun, 24 Jan 2010 16:29:49 -0800 (PST) In-Reply-To: References: <883b2dc51001240905r4cfbf830i3b9b400969ac261b@mail.gmail.com> <1264368182.00211075.1264355402@10.7.7.3> <4B5CC167.5010604@FreeBSD.org> Date: Mon, 25 Jan 2010 02:29:49 +0200 Message-ID: From: Dan Naumov To: Alexander Motin Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-fs@freebsd.org, Jason Edwards , FreeBSD-STABLE Mailing List , freebsd-questions@freebsd.org Subject: Re: 8.0-RELEASE/amd64 - full ZFS install - low read and write disk performance X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jan 2010 00:29:59 -0000 On Mon, Jan 25, 2010 at 2:14 AM, Dan Naumov wrote: > On Sun, Jan 24, 2010 at 11:53 PM, Alexander Motin wrote= : >> Dan Naumov wrote: >>> This works out to 1GB in 36,2 seconds / 28,2mb/s in the first test and >>> 4GB in 143.8 seconds / 28,4mb/s and somewhat consistent with the >>> bonnie results. It also sadly seems to confirm the very slow speed :( >>> The disks are attached to a 4-port Sil3124 controller and again, my >>> Windows benchmarks showing 65mb/s+ were done on exact same machine, >>> with same disks attached to the same controller. Only difference was >>> that in Windows the disks weren't in a mirror configuration but were >>> tested individually. I do understand that a mirror setup offers >>> roughly the same write speed as individual disk, while the read speed >>> usually varies from "equal to individual disk speed" to "nearly the >>> throughput of both disks combined" depending on the implementation, >>> but there is no obvious reason I am seeing why my setup offers both >>> read and write speeds roughly 1/3 to 1/2 of what the individual disks >>> are capable of. Dmesg shows: >>> >>> atapci0: port 0x1000-0x100f mem >>> 0x90108000-0x9010807f,0x90100000-0x90107fff irq 21 at device 0.0 on >>> pci4 >>> ad8: 1907729MB at ata4-master SATA300 >>> ad10: 1907729MB at ata5-master SATA300 >> >> 8.0-RELEASE, and especially 8-STABLE provide alternative, much more >> functional driver for this controller, named siis(4). If your SiI3124 >> card installed into proper bus (PCI-X or PCIe x4/x8), it can be really >> fast (up to 1GB/s was measured). >> >> -- >> Alexander Motin > > Sadly, it seems that utilizing the new siis driver doesn't do much good: > > Before utilizing siis: > > iozone -s 4096M -r 512 -i0 -i1 > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0random > random =A0 =A0bkwd =A0 record =A0 stride > =A0 =A0 =A0 =A0 =A0 =A0 =A0KB =A0reclen =A0 write rewrite =A0 =A0read =A0= =A0reread =A0 =A0read > write =A0 =A0read =A0rewrite =A0 =A0 read =A0 fwrite frewrite =A0 fread = =A0freread > =A0 =A0 =A0 =A0 4194304 =A0 =A0 512 =A0 28796 =A0 28766 =A0 =A051610 =A0 = =A050695 > > After enabling siis in loader.conf (and ensuring the disks show up as ada= ): > > iozone -s 4096M -r 512 -i0 -i1 > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0random > random =A0 =A0bkwd =A0 record =A0 stride > =A0 =A0 =A0 =A0 =A0 =A0 =A0KB =A0reclen =A0 write rewrite =A0 =A0read =A0= =A0reread =A0 =A0read > write =A0 =A0read =A0rewrite =A0 =A0 read =A0 fwrite frewrite =A0 fread = =A0freread > =A0 =A0 =A0 =A0 4194304 =A0 =A0 512 =A0 28781 =A0 28897 =A0 =A047214 =A0 = =A050540 Just to add to the numbers above, exact same benchmark, on 1 disk (detached 2nd disk from the mirror) while using the siis driver: random random bkwd record stride KB reclen write rewrite read reread read write read rewrite read fwrite frewrite fread freread 4194304 512 57760 56371 68867 74047 - Dan From owner-freebsd-stable@FreeBSD.ORG Mon Jan 25 00:32:11 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 99FF1106568D for ; Mon, 25 Jan 2010 00:32:11 +0000 (UTC) (envelope-from gausus@gausus.net) Received: from dagobah.intersec.pl (dagobah.intersec.pl [91.192.226.10]) by mx1.freebsd.org (Postfix) with ESMTP id 52C138FC18 for ; Mon, 25 Jan 2010 00:32:11 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by dagobah.intersec.pl (Postfix) with ESMTP id D44C2254001; Mon, 25 Jan 2010 01:32:08 +0100 (CET) X-Virus-Scanned: amavisd-new at intersec.pl Received: from dagobah.intersec.pl ([127.0.0.1]) by localhost (dagobah.intersec.pl [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dgyjpBX8n4qI; Mon, 25 Jan 2010 01:32:04 +0100 (CET) Received: from loken.local (69-dzi-33.acn.waw.pl [85.222.122.69]) by dagobah.intersec.pl (Postfix) with ESMTP id 23AD2254002; Mon, 25 Jan 2010 01:32:04 +0100 (CET) Message-ID: <4B5CE684.5000508@gausus.net> Date: Mon, 25 Jan 2010 01:32:04 +0100 From: Maciej Jan Broniarz User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; pl; rv:1.9.1.7) Gecko/20100111 Thunderbird/3.0.1 MIME-Version: 1.0 To: freebsd-jail@freebsd.org, freebsd-stable@freebsd.org Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: Subject: ports/packages management in jail X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 25 Jan 2010 00:32:11 -0000 Hi, I am running a server with several jails. They were created using ezjail. What is the best way, to allow jail internal admin to manage ports/packages by himself? By default ezjail shares ports tree between basejail and otherjails. Is there a way for each jail to have a separate ports tree? Best regards, mjb From owner-freebsd-stable@FreeBSD.ORG Mon Jan 25 01:10:12 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5B7FC106566C for ; Mon, 25 Jan 2010 01:10:12 +0000 (UTC) (envelope-from gausus@gausus.net) Received: from dagobah.intersec.pl (dagobah.intersec.pl [91.192.226.10]) by mx1.freebsd.org (Postfix) with ESMTP id 189AB8FC15 for ; Mon, 25 Jan 2010 01:10:11 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by dagobah.intersec.pl (Postfix) with ESMTP id 98DA7254001 for ; Mon, 25 Jan 2010 02:10:09 +0100 (CET) X-Virus-Scanned: amavisd-new at intersec.pl Received: from dagobah.intersec.pl ([127.0.0.1]) by localhost (dagobah.intersec.pl [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4ChcxApDGms9 for ; Mon, 25 Jan 2010 02:10:02 +0100 (CET) Received: from loken.local (69-dzi-33.acn.waw.pl [85.222.122.69]) by dagobah.intersec.pl (Postfix) with ESMTP id C4BBA254002 for ; Mon, 25 Jan 2010 02:10:02 +0100 (CET) Message-ID: <4B5CEF6B.6010507@gausus.net> Date: Mon, 25 Jan 2010 02:10:03 +0100 From: Maciej Jan Broniarz User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; pl; rv:1.9.1.7) Gecko/20100111 Thunderbird/3.0.1 MIME-Version: 1.0 To: freebsd-stable@freebsd.org Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: make installworld failed X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 25 Jan 2010 01:10:12 -0000 Hi, I am trying to installworld: /usr/share/man/man8/bootpgw.8.gz -> /usr/share/man/man8/bootpd.8.gz rm: /usr/share/man/man8/bootpgw.8: Not a directory rm: /usr/share/man/man8/bootpgw.8.gz: Not a directory *** Error code 1 Stop in /usr/src/libexec/bootpd. *** Error code 1 Stop in /usr/src/libexec. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. What might be the problem? My system is 8.0-RELEASE, sources taken from cvs today. All best, mjb From owner-freebsd-stable@FreeBSD.ORG Mon Jan 25 01:13:43 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0DF57106566B for ; Mon, 25 Jan 2010 01:13:43 +0000 (UTC) (envelope-from cyrille.lefevre-lists@laposte.net) Received: from out4.laposte.net (out3.laposte.net [193.251.214.120]) by mx1.freebsd.org (Postfix) with ESMTP id C028F8FC14 for ; Mon, 25 Jan 2010 01:13:42 +0000 (UTC) Received: from out3.laposte.net (lbao93aubmepnpf001-183-pip.meplus.info [10.98.50.10]) by mwinf8310.laposte.net (SMTP Server) with ESMTP id 296811C000AD for ; Mon, 25 Jan 2010 01:55:59 +0100 (CET) Received: from meplus.info (localhost [127.0.0.1]) by mwinf8307.laposte.net (SMTP Server) with ESMTP id ABFDB7000089 for ; Mon, 25 Jan 2010 01:55:56 +0100 (CET) Received: from [192.168.1.133] (137.228.100-84.rev.gaoland.net [84.100.228.137]) by mwinf8307.laposte.net (SMTP Server) with ESMTP id 8088C7000088 for ; Mon, 25 Jan 2010 01:55:56 +0100 (CET) X-ME-UUID: 20100125005556526.8088C7000088@mwinf8307.laposte.net Message-ID: <4B5CEC53.3090402@laposte.net> Date: Mon, 25 Jan 2010 01:56:51 +0100 From: Cyrille Lefevre Organization: ACME User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; fr; rv:1.8.1.3) Gecko/20070326 Thunderbird/2.0.0.0 Mnenhy/0.7.5.666 MIME-Version: 1.0 To: freebsd-stable@freebsd.org Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-me-spamlevel: not-spam X-me-spamrating: 39.200001 X-me-spamcause: OK, (-20)(0000)gggruggvucftvghtrhhoucdtuddrvdeltddrtdehucetggdotefuucfrrhhofhhilhgvmecuoehnohhnvgeqnecuuegrihhlohhuthemuceftddtnecufhhrvggvsghsugdvgiculddqvddtmdenfhhrvggvsghsugdgucdlqddutddmneeuufffvdigucdlqddvtddmnehgvghnvghrihgtjdculdeftddm Subject: su password prompt ti stdout instead of /dev/tty X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 25 Jan 2010 01:13:43 -0000 Hi, su password prompt is displayed to *stdout* instead of */dev/tty*. # su user $ su root -c date > /tmp/date 2>&1 (nothing displayed) $ cat /tmp/date Password:su: Sorry $ uname -a FreeBSD freebsd8.my.domain 8.0-RELEASE FreeBSD 8.0-RELEASE #0: Sat Nov 21 15:48:17 UTC 2009 root@almeida.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC i386 I suppose this is a getpass() problem ? Regards, Cyrille Lefevre -- mailto:Cyrille.Lefevre-lists@laposte.net From owner-freebsd-stable@FreeBSD.ORG Mon Jan 25 02:58:12 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 891001065670; Mon, 25 Jan 2010 02:58:12 +0000 (UTC) (envelope-from rnoland@FreeBSD.org) Received: from gizmo.2hip.net (gizmo.2hip.net [64.74.207.195]) by mx1.freebsd.org (Postfix) with ESMTP id 588158FC0A; Mon, 25 Jan 2010 02:58:12 +0000 (UTC) Received: from [192.168.1.4] (adsl-157-36-161.bna.bellsouth.net [70.157.36.161]) (authenticated bits=0) by gizmo.2hip.net (8.14.3/8.14.3) with ESMTP id o0P2w7kb080850 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Sun, 24 Jan 2010 21:58:09 -0500 (EST) (envelope-from rnoland@FreeBSD.org) From: Robert Noland To: Mark Andrews In-Reply-To: <201001242057.o0OKvHUE089237@drugs.dv.isc.org> References: <20100122041237.GA22312@gothschlampen.com> <20100124092947.B72039@starfire.mn.org> <201001242057.o0OKvHUE089237@drugs.dv.isc.org> Content-Type: text/plain Organization: FreeBSD Date: Sun, 24 Jan 2010 20:41:22 -0600 Message-Id: <1264387282.2869.24.camel@balrog.2hip.net> Mime-Version: 1.0 X-Mailer: Evolution 2.26.3 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-0.5 required=5.0 tests=AWL,BAYES_00, FH_DATE_PAST_20XX,RCVD_IN_PBL,RDNS_DYNAMIC,SPF_SOFTFAIL autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on gizmo.2hip.net Cc: John , "Thomas K." , Dan Naumov , freebsd-questions@freebsd.org, FreeBSD-STABLE Mailing List Subject: Re: Loader, MBR and the boot process X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 25 Jan 2010 02:58:12 -0000 On Mon, 2010-01-25 at 07:57 +1100, Mark Andrews wrote: > In message , Dan N > aumov writes: > > On Sun, Jan 24, 2010 at 5:29 PM, John wrote: > > > On Fri, Jan 22, 2010 at 07:02:53AM +0200, Dan Naumov wrote: > > >> On Fri, Jan 22, 2010 at 6:49 AM, Dan Naumov wrote= > > : > > >> > On Fri, Jan 22, 2010 at 6:12 AM, Thomas K. wro= > > te: > > >> >> On Fri, Jan 22, 2010 at 05:57:23AM +0200, Dan Naumov wrote: > > >> >> > > >> >> Hi, > > >> >> > > >> >>> I recently found a nifty "FreeBSD ZFS root installation script" and > > >> >>> been reworking it a bit to suit my needs better, including changing = > > it > > >> >>> from GPT to MBR partitioning. However, I was stumped, even though I > > >> >>> had done everything right (or so I thought), the system would get > > >> >>> stuck at Loader and refuse to go anywhere. After trying over a dozen > > >> >> > > >> >> probably this line is the cause: > > >> >> > > >> >> dd if=3D/mnt2/boot/zfsboot of=3D/dev/"${TARGETDISK}"s1a skip=3D1 seek= > > =3D1024 > > >> >> > > >> >> Unless by "swap first" you meant the on-disk location, and not the > > >> >> partition letter. If swap is partition "a", you're writing the loader > > >> >> into swapspace. > > >> >> > > >> >> > > >> >> Regards, > > >> >> Thomas > > >> > > > >> > At first you made me feel silly, but then I decided to double-check, I > > >> > uncommented the swap line in the partitioning part again, ensured I > > >> > was writing the bootloader to "${TARGETDISK}"s1b and ran the script. > > >> > Same problem, hangs at loader. Again, if I comment out the swap, > > >> > giving the entire slice to ZFS and then write the bootloader to > > >> > "${TARGETDISK}"s1a, run the script, everything works. > > >> > > >> I have also just tested creating 2 slices, like this: > > >> > > >> gpart create -s mbr "${TARGETDISK}" > > >> gpart add -s 3G -t freebsd "${TARGETDISK}" > > >> gpart create -s BSD "${TARGETDISK}"s1 > > >> gpart add -t freebsd-swap "${TARGETDISK}"s1 > > >> > > >> gpart add -t freebsd "${TARGETDISK}" > > >> gpart create -s BSD "${TARGETDISK}"s2 > > >> gpart add -t freebsd-zfs "${TARGETDISK}"s2 > > >> > > >> gpart set -a active -i 2 "${TARGETDISK}" > > >> gpart bootcode -b /mnt2/boot/boot0 "${TARGETDISK}" > > >> > > >> > > >> and later: > > >> > > >> dd if=3D/mnt2/boot/zfsboot of=3D/dev/"${TARGETDISK}"s2 count=3D1 > > >> dd if=3D/mnt2/boot/zfsboot of=3D/dev/"${TARGETDISK}"s2a skip=3D1 seek=3D= > > 1024 > > >> > > >> > > >> Putting the swap into it's own slice and then putting FreeBSD into > > >> it's own slice worked fine. So why the hell can't they both coexist in > > >> 1 slice if the swap comes first? > > > > > > I know what the answer to this USED to be, but I don't know if it is > > > still true (obviously, I think so, I or wouldn't waste your time). > > > > > > The filesystem code is all carefully written to avoid the very > > > first few sector of the partition. =A0That's because the partition > > > table is there for the first filesystem of the slice (or disk). > > > That's a tiny amout of space wasted, because it's also skipped on > > > all the other filesystems even though there's not actually anything > > > there, but it was a small inefficency, even in the 70's. > > > > > > Swap does not behave that way. =A0SWAP will begin right at the slice > > > boundry, with 0 offset. =A0As long as it's not the first partition, no > > > harm, no foul. =A0If it IS the first partition, you just nuked your parti= > > tion > > > table. =A0As long as SWAP owns the slice, again, no harm, no foul, but > > > if there were filesystems BEHIND it, you just lost 'em. > > > > > > That's the way it always used to be, and I think it still is. =A0SWAP can > > > only be first if it is the ONLY thing using that slice (disk), otherwise, > > > you need a filesystem first to protect the partition table. > > > -- > > > > > > John Lind > > > john@starfire.MN.ORG > > > > This explanation does sound logical, but holy crap, if this is the > > case, you'd think there would be bells, whistles and huge red label > > warnings in EVERY FreeBSD installation / partitioning guide out there > > warning people to not put swap first (unless given a dedicated slice) > > under any circumstances. The warnings were nowhere to be seen and lots > > of pointy hair first greyed and were then lost during the process of > > me trying to figure out why my system would install but wouldn't boot. > > >From "man bsdlabel". > > offset The offset of the start of the partition from the beginning of > the drive in sectors, or * to have bsdlabel calculate the correct > offset to use (the end of the previous partition plus one, ignor- > ing partition `c'. For partition `c', * will be interpreted as > an offset of 0. The first partition should start at offset 16, > because the first 16 sectors are reserved for metadata. Ok, now this has my attention... My gut feeling right now is that this is a bug in geom_part_bsd. I don't understand why the label isn't protected. (Adding -b 16 when adding the swap partition fixes this) Another project to goes on my list... If anyone knows why this is done like this... please share. robert. > > - Sincerely, > > Dan Naumov > > _______________________________________________ > > 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" -- Robert Noland FreeBSD From owner-freebsd-stable@FreeBSD.ORG Mon Jan 25 03:01:14 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2BFB11065694 for ; Mon, 25 Jan 2010 03:01:14 +0000 (UTC) (envelope-from glen.j.barber@gmail.com) Received: from qw-out-2122.google.com (qw-out-2122.google.com [74.125.92.27]) by mx1.freebsd.org (Postfix) with ESMTP id D3E768FC08 for ; Mon, 25 Jan 2010 03:01:13 +0000 (UTC) Received: by qw-out-2122.google.com with SMTP id 5so166477qwd.7 for ; Sun, 24 Jan 2010 19:01:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:date:from:to:cc:subject :message-id:references:mime-version:content-type:content-disposition :in-reply-to:user-agent; bh=ssce4hVDqF+9L+YYLS05kelXa+A8EUmUAL4/7I7HDu0=; b=oz/zwz9YF9anILo8w8ZajWPUrKKAIKSjX/6bCYhc1Qa1TBq+68ojv79lRJROdBSltf 1gijjmxD4sv8dv6yfhhbc1Ux3Rghx2aGhYOHDzlYxh02eK0Usb9G9DDlaPFJK2keb+aj fxLdikspOY8c8gwlQrPjZ/uebIVPsUlm9a/WU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; b=MjRscivbe4tn1x/U3xqd1jdih1A9I+IODyg89+jZCCQ8vpvDNY9SDeCnVUZFT3o03p XRYSu15kebGbZOstZWgMRcuramhVO0pgHp0boB3BihQd6fTpKFNIYYJLVlba9PaDtYHZ 6o9Y47ULFkHecmD294yWtrl4Z7tu0mGcY8hz4= Received: by 10.224.1.37 with SMTP id 37mr3757149qad.325.1264388466354; Sun, 24 Jan 2010 19:01:06 -0800 (PST) Received: from orion.hsd1.pa.comcast.net (c-71-230-240-241.hsd1.pa.comcast.net [71.230.240.241]) by mx.google.com with ESMTPS id 21sm4459512qyk.4.2010.01.24.19.01.04 (version=SSLv3 cipher=RC4-MD5); Sun, 24 Jan 2010 19:01:05 -0800 (PST) Date: Sun, 24 Jan 2010 21:57:44 -0500 From: Glen Barber To: Cyrille Lefevre Message-ID: <20100125025744.GA94378@orion.hsd1.pa.comcast.net> References: <4B5CEC53.3090402@laposte.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4B5CEC53.3090402@laposte.net> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: freebsd-stable@freebsd.org Subject: Re: su password prompt ti stdout instead of /dev/tty X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 25 Jan 2010 03:01:14 -0000 Hi, Cyrille Lefevre wrote: > > Hi, > > su password prompt is displayed to *stdout* instead of */dev/tty*. > > # su user > $ su root -c date > /tmp/date 2>&1 > (nothing displayed) > $ cat /tmp/date > Password:su: Sorry > $ uname -a > FreeBSD freebsd8.my.domain 8.0-RELEASE FreeBSD 8.0-RELEASE #0: Sat Nov > 21 15:48:17 UTC 2009 > root@almeida.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC i386 > > I suppose this is a getpass() problem ? > I cannot reproduce this. In fact, su root -c date > /tmp/date hangs waiting for input. orion % su root -c date > /tmp/date ^C su: Sorry orion % less /tmp/date Password: orion % Also, you appear to be running an unpatched version of FreeBSD 8.0, subject to the rtld exploit (among a few others). I'd suggest upgrading. For what it's worth: orion % uname -a FreeBSD orion 8.0-STABLE FreeBSD 8.0-STABLE #20 r202187: Wed Jan 13 11:51:15 EST 2010 root@orion:/usr/obj/usr/src/sys/ORION amd64 Regards, -- Glen Barber From owner-freebsd-stable@FreeBSD.ORG Mon Jan 25 03:49:12 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 211611065670 for ; Mon, 25 Jan 2010 03:49:12 +0000 (UTC) (envelope-from jhellenthal@gmail.com) Received: from qw-out-2122.google.com (qw-out-2122.google.com [74.125.92.25]) by mx1.freebsd.org (Postfix) with ESMTP id B9A588FC15 for ; Mon, 25 Jan 2010 03:49:11 +0000 (UTC) Received: by qw-out-2122.google.com with SMTP id 5so174729qwd.7 for ; Sun, 24 Jan 2010 19:49:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:date:from:to:cc :subject:in-reply-to:message-id:references:user-agent :x-openpgp-key-id:x-openpgp-key-fingerprint:mime-version :content-type; bh=mRp940PYNrO970YC529oAuOgcMJb32rpR7obzN+sFjk=; b=QgXJz1sbgQM+WH53FFyOh4UhoxeuWJDEki/pDbWUFoRVg8muxWMsjEYDnemOHNNZUw DjmVrfS4t8QF01/I1V/jdpnGPfHmIOgtlgSKbMwyuW6YNeTbV2EJLbFOC4B6+R+Vdyhm Pf9AEeb+L63XG8+eBYIPKsH8jAAIptt8No7zY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:date:from:to:cc:subject:in-reply-to:message-id:references :user-agent:x-openpgp-key-id:x-openpgp-key-fingerprint:mime-version :content-type; b=HJL0lmW95IlPrvERMT1HdL7a2a1syt8kCx4Y71utZNyy0zCBTE+fgjkAIJ7/YjqqzL dHCseEXFAIULwK3m6XFoz4tUQ7p3u+s5l5R0OlyT+b/HmqJIVXkrV2sKapE7YOC5BDQl 6d0l2fiLxRBypAbVtgBizndc90GeIS1JSiJzc= Received: by 10.224.49.10 with SMTP id t10mr2438519qaf.102.1264391350849; Sun, 24 Jan 2010 19:49:10 -0800 (PST) Received: from centel.dataix.local (ppp-21.20.dialinfree.com [209.172.21.20]) by mx.google.com with ESMTPS id 8sm16439858qwj.53.2010.01.24.19.49.04 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sun, 24 Jan 2010 19:49:09 -0800 (PST) Sender: "J. Hellenthal" Date: Sun, 24 Jan 2010 22:48:44 -0500 From: jhell To: Glen Barber In-Reply-To: <20100125025744.GA94378@orion.hsd1.pa.comcast.net> Message-ID: References: <4B5CEC53.3090402@laposte.net> <20100125025744.GA94378@orion.hsd1.pa.comcast.net> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) X-OpenPGP-Key-Id: 0x89D8547E X-OpenPGP-Key-Fingerprint: 85EF E26B 07BB 3777 76BE B12A 9057 8789 89D8 547E MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-stable@freebsd.org Subject: Re: su password prompt ti stdout instead of /dev/tty X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 25 Jan 2010 03:49:12 -0000 On Sun, 24 Jan 2010 21:57, glen.j.barber@ wrote: > Hi, > > Cyrille Lefevre wrote: >> >> Hi, >> >> su password prompt is displayed to *stdout* instead of */dev/tty*. >> >> # su user >> $ su root -c date > /tmp/date 2>&1 >> (nothing displayed) >> $ cat /tmp/date >> Password:su: Sorry >> $ uname -a >> FreeBSD freebsd8.my.domain 8.0-RELEASE FreeBSD 8.0-RELEASE #0: Sat Nov >> 21 15:48:17 UTC 2009 >> root@almeida.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC i386 >> >> I suppose this is a getpass() problem ? >> This is intended operation as su(1) may not always be affiliated with a TTY. This leaves it open for a script to chat with much like what samba does with its passwd chat mechanism. > > I cannot reproduce this. In fact, > > su root -c date > /tmp/date > > hangs waiting for input. > > orion % su root -c date > /tmp/date > ^C > su: Sorry > orion % less /tmp/date > Password: > orion % > This is essentially what the OP stated was happening except you forgot the 2>&1. > Also, you appear to be running an unpatched version of FreeBSD 8.0, > subject to the rtld exploit (among a few others). I'd suggest upgrading. > > For what it's worth: > orion % uname -a > FreeBSD orion 8.0-STABLE FreeBSD 8.0-STABLE #20 r202187: Wed Jan 13 > 11:51:15 EST 2010 root@orion:/usr/obj/usr/src/sys/ORION amd64 > > Regards, > > -- jhell From owner-freebsd-stable@FreeBSD.ORG Mon Jan 25 03:54:10 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1A8471065672 for ; Mon, 25 Jan 2010 03:54:10 +0000 (UTC) (envelope-from jhellenthal@gmail.com) Received: from mail-qy0-f201.google.com (mail-qy0-f201.google.com [209.85.221.201]) by mx1.freebsd.org (Postfix) with ESMTP id BC1798FC15 for ; Mon, 25 Jan 2010 03:54:09 +0000 (UTC) Received: by qyk39 with SMTP id 39so1713177qyk.27 for ; Sun, 24 Jan 2010 19:54:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:date:from:to:cc :subject:in-reply-to:message-id:references:user-agent :x-openpgp-key-id:x-openpgp-key-fingerprint:mime-version :content-type; bh=Je32P3fsBsMhfA8KQIEHoQuBkjr5+ocjgaU1q8sJjPk=; b=kzjXSy3bW+K8CVWi32Ktqb/nkORqp8nyjXCN9Cq/fCgk92sdPy7/H/djNKQ2ShMWIP 0qWzWZ3vItK0lyGUPxjUrpLtrN/OhVIWqnl3To3Vtr8awDdIap6Ym1oekfrCnidB0Lfh TFKXDBb5W5Px4/W0ea7n11lHIvtDw8ya9U0FU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:date:from:to:cc:subject:in-reply-to:message-id:references :user-agent:x-openpgp-key-id:x-openpgp-key-fingerprint:mime-version :content-type; b=vv1kfr5eHvQ1KshjCyIAuIHZT4khf2lJTNqL/KpbCPOhEy1UIAeP9cRCEeMAqnqjH5 PQP0p68gKbDcl64BIRBdGBnxjVRav+A4/9pTlf8hYGbyEQvcuvI7qgPh6Ph+kKdMkHRv BTo8tv6auTIDoJAZGXwAkGVhToKlVwSXvnfvc= Received: by 10.224.7.82 with SMTP id c18mr3049861qac.317.1264391649012; Sun, 24 Jan 2010 19:54:09 -0800 (PST) Received: from centel.dataix.local (ppp-21.20.dialinfree.com [209.172.21.20]) by mx.google.com with ESMTPS id 7sm10933583qwf.4.2010.01.24.19.54.02 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sun, 24 Jan 2010 19:54:07 -0800 (PST) Sender: "J. Hellenthal" Date: Sun, 24 Jan 2010 22:53:47 -0500 From: jhell To: Glen Barber In-Reply-To: Message-ID: References: <4B5CEC53.3090402@laposte.net> <20100125025744.GA94378@orion.hsd1.pa.comcast.net> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) X-OpenPGP-Key-Id: 0x89D8547E X-OpenPGP-Key-Fingerprint: 85EF E26B 07BB 3777 76BE B12A 9057 8789 89D8 547E MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-stable@freebsd.org Subject: Re: su password prompt ti stdout instead of /dev/tty X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 25 Jan 2010 03:54:10 -0000 On Sun, 24 Jan 2010 22:48, jhell@ wrote: > > On Sun, 24 Jan 2010 21:57, glen.j.barber@ wrote: >> Hi, >> >> Cyrille Lefevre wrote: >>> >>> Hi, >>> >>> su password prompt is displayed to *stdout* instead of */dev/tty*. >>> >>> # su user >>> $ su root -c date > /tmp/date 2>&1 >>> (nothing displayed) >>> $ cat /tmp/date >>> Password:su: Sorry >>> $ uname -a >>> FreeBSD freebsd8.my.domain 8.0-RELEASE FreeBSD 8.0-RELEASE #0: Sat Nov >>> 21 15:48:17 UTC 2009 >>> root@almeida.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC i386 >>> >>> I suppose this is a getpass() problem ? >>> > > This is intended operation as su(1) may not always be affiliated with a TTY. > This leaves it open for a script to chat with much like what samba does with > its passwd chat mechanism. > If you mean for the program to appropriately append or overwrite to a file you should ( su user -c 'date >output 2>&1' ) instead >> >> I cannot reproduce this. In fact, >> >> su root -c date > /tmp/date >> >> hangs waiting for input. >> >> orion % su root -c date > /tmp/date >> ^C >> su: Sorry >> orion % less /tmp/date >> Password: >> orion % >> > > This is essentially what the OP stated was happening except you forgot the > 2>&1. > >> Also, you appear to be running an unpatched version of FreeBSD 8.0, >> subject to the rtld exploit (among a few others). I'd suggest upgrading. >> >> For what it's worth: >> orion % uname -a >> FreeBSD orion 8.0-STABLE FreeBSD 8.0-STABLE #20 r202187: Wed Jan 13 >> 11:51:15 EST 2010 root@orion:/usr/obj/usr/src/sys/ORION amd64 >> >> Regards, >> >> > > > > > -- jhell From owner-freebsd-stable@FreeBSD.ORG Mon Jan 25 04:59:15 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 884AF1065672; Mon, 25 Jan 2010 04:59:15 +0000 (UTC) (envelope-from perryh@pluto.rain.com) Received: from agora.rdrop.com (agora.rdrop.com [199.26.172.34]) by mx1.freebsd.org (Postfix) with ESMTP id 6336C8FC08; Mon, 25 Jan 2010 04:59:15 +0000 (UTC) Received: from agora.rdrop.com (66@localhost [127.0.0.1]) by agora.rdrop.com (8.13.1/8.12.7) with ESMTP id o0P4ae7u071142 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sun, 24 Jan 2010 20:36:40 -0800 (PST) (envelope-from perryh@pluto.rain.com) Received: (from uucp@localhost) by agora.rdrop.com (8.13.1/8.12.9/Submit) with UUCP id o0P4aeN3071141; Sun, 24 Jan 2010 20:36:40 -0800 (PST) Received: from fbsd61 by pluto.rain.com (4.1/SMI-4.1-pluto-M2060407) id AA05845; Sun, 24 Jan 10 20:22:09 PST Date: Sun, 24 Jan 2010 20:19:59 -0800 From: perryh@pluto.rain.com To: ohartman@mail.zedat.fu-berlin.de Message-Id: <4b5d1bef.QEz5a8Mvh7OFA7+l%perryh@pluto.rain.com> References: <4B5C771C.4040605@mail.zedat.fu-berlin.de> In-Reply-To: <4B5C771C.4040605@mail.zedat.fu-berlin.de> User-Agent: nail 11.25 7/29/05 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org, freebsd-questions@freebsd.org Subject: Re: PCIe audio cards: what is tob be preferred with FreeBSD 8.0/9-CURRENT? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 25 Jan 2010 04:59:15 -0000 "O. Hartmann" wrote: > At this very moment I utilise a M-Audio 5.1 PCI-audio board with > which I'm really satisfied. My next box doesn't have PCI slots > at all ... I look for the Soundblaster X-Fi range of PCIe cards, It's possible to get an adapter that plugs into a PCIe slot and provides a PCI slot, which might enable you to continue using your current card. I've never actually seen one, so don't know about the mechanics; it could turn out that it can only be used by leaving the cover off of the box :( From owner-freebsd-stable@FreeBSD.ORG Mon Jan 25 05:12:31 2010 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 168F7106566C; Mon, 25 Jan 2010 05:12:31 +0000 (UTC) (envelope-from ncrogers@gmail.com) Received: from mail-pz0-f202.google.com (mail-pz0-f202.google.com [209.85.222.202]) by mx1.freebsd.org (Postfix) with ESMTP id D69338FC12; Mon, 25 Jan 2010 05:12:30 +0000 (UTC) Received: by pzk40 with SMTP id 40so429140pzk.7 for ; Sun, 24 Jan 2010 21:12:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=6W6lCOPMCn0g4THi5g2CRwjOdGyF2rvXpp8DoQgmwcY=; b=gzb9crjqfjlEbXveO/Up3TnS/O5veklLc/Xwd5vOfLQ8wH0ZB1ND9C8wCR4yunuEx+ axnapvuYTsQhtZrwZ79055RBlC1W4UNBnALY5E7KMrrF1skt6Hz50Fzlit5wd3y1qhYn 6lrPjnw9yo/GHGkkzcEzZctCqlDWw2sGVOMnk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=XGoZmRG/+oAX/+9kE8z+scq5x4uiN6feut4RN83Gf9VmhfnoLpTsWx09nFlkOH3Ef6 FAs/hY4JdZEs6sswUqXsawwC6ekkcxxn67Y3d1KnzTPtcpLqJPwF40tJNPH+To8/K16P sRa8OtYJx78jZpmoJHtoymeRUQDxRXEdewvhI= MIME-Version: 1.0 Received: by 10.143.25.1 with SMTP id c1mr4251886wfj.17.1264394849456; Sun, 24 Jan 2010 20:47:29 -0800 (PST) In-Reply-To: <4B43F6EE.3010308@ucla.edu> References: <20091201.102925.218343479.hrs@allbsd.org> <2a41acea0912021249w1aed8e83kf89ceb1e6041edaf@mail.gmail.com> <2a41acea0912021514r2d44dd33n4c364518d7fe1703@mail.gmail.com> <20091203.182931.129751456.hrs@allbsd.org> <4B43F6EE.3010308@ucla.edu> Date: Sun, 24 Jan 2010 20:47:29 -0800 Message-ID: <147432021001242047k659a26d0s44b35164920aeb74@mail.gmail.com> From: Nick Rogers To: Jason Chambers Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: stable@freebsd.org, jfvogel@gmail.com Subject: Re: em interface slow down on 8.0R X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 25 Jan 2010 05:12:31 -0000 I am having similar em interface problems with some of my production machines running older intel 2-port cards, since upgrading from 7.2-RELEASE to 8.0-RELEASE. The problem is basically, everything works fine, but periodically the interface "hangs" (tcpdump shows no frames). A reboot or an ifconfig down followed by an ifconfig up fixes the problem for some time. Traffic peaks at maybe 20mbit per day and its all 802.1Q VLAN tagged traffic (about 10 vlan interfaces). When this happens netstat reports only errors and no packets on the affected interface. Media is set to autoselect. This is happening about 5-10x per day. Heres relevant sysctl and ifconfig info. dev.em.6.%desc: Intel(R) PRO/1000 Network Connection 6.9.14 dev.em.6.%driver: em dev.em.6.%location: slot=3 function=0 dev.em.6.%pnpinfo: vendor=0x8086 device=0x1079 subvendor=0x8086 subdevice=0x1179 class=0x020000 dev.em.6.%parent: pci3 dev.em.6.debug: -1 dev.em.6.stats: -1 dev.em.6.rx_int_delay: 0 dev.em.6.tx_int_delay: 66 dev.em.6.rx_abs_int_delay: 66 dev.em.6.tx_abs_int_delay: 66 dev.em.6.rx_processing_limit: 100 em6: flags=8843 metric 0 mtu 1500 options=9b ether 00:04:23:cd:47:82 media: Ethernet autoselect (1000baseT ) status: active On Tue, Jan 5, 2010 at 6:35 PM, Jason Chambers wrote: > Hiroki Sato wrote: > > Thank you! I have investigated some more details. First, I got > > something wrong with the affected FreeBSD versions; one I tried was > > 8.0-STABLE, not 8.0-RELEASE. So I started to try 8.0R. A summary of > > chips and releases I tried so far is now the following: > > > > 7.2R 8.0R 8.0-STABLE > > 82540EM (chip=0x100e8086, rev=0x02) OK OK too slow[1] > > 82541PI (chip=0x107c8086, rev=0x05) OK ? OK > > > Running 8.0R I've noticed the same problem with this card (0x107c8086). > Duplex and speed are manually set at full/1000. > > > em0@pci0:3:3:0: class=0x020000 card=0x13768086 chip=0x107c8086 rev=0x05 > hdr=0x00 > vendor = 'Intel Corporation' > device = 'Gigabit Ethernet Controller (Copper) rev 5 (82541PI)' > class = network > subclass = ethernet > > > Regards, > > --Jason > _______________________________________________ > 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 Mon Jan 25 05:50:22 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id ABDBF106566B; Mon, 25 Jan 2010 05:50:22 +0000 (UTC) (envelope-from justin@encarnate.com) Received: from ey-out-2122.google.com (ey-out-2122.google.com [74.125.78.24]) by mx1.freebsd.org (Postfix) with ESMTP id 2AA918FC23; Mon, 25 Jan 2010 05:50:21 +0000 (UTC) Received: by ey-out-2122.google.com with SMTP id 9so813596eyd.9 for ; Sun, 24 Jan 2010 21:50:21 -0800 (PST) MIME-Version: 1.0 Received: by 10.216.86.206 with SMTP id w56mr624328wee.1.1264396808687; Sun, 24 Jan 2010 21:20:08 -0800 (PST) In-Reply-To: <4B5CE684.5000508@gausus.net> References: <4B5CE684.5000508@gausus.net> Date: Sun, 24 Jan 2010 23:20:08 -0600 Message-ID: <674b4c931001242120w185d192chbaf4c19492a7548b@mail.gmail.com> From: Justin Head To: Maciej Jan Broniarz Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-jail@freebsd.org, freebsd-stable@freebsd.org Subject: Re: ports/packages management in jail X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 25 Jan 2010 05:50:22 -0000 On 1/24/10, Maciej Jan Broniarz wrote: > Hi, > > I am running a server with several jails. They were created using > ezjail. What is the best way, to allow jail internal admin to manage > ports/packages by himself? > By default ezjail shares ports tree between basejail and otherjails. Is > there a way for each jail to have a separate ports tree? > Inside the jail just rm the symlinked /usr/ports and then recreate /usr/ports as a regular directory. After that a simple portsnap to grab the ports tree. From owner-freebsd-stable@FreeBSD.ORG Mon Jan 25 05:55:06 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2F790106566C; Mon, 25 Jan 2010 05:55:06 +0000 (UTC) (envelope-from bfriesen@simple.dallas.tx.us) Received: from blade.simplesystems.org (blade.simplesystems.org [65.66.246.74]) by mx1.freebsd.org (Postfix) with ESMTP id C80388FC0C; Mon, 25 Jan 2010 05:55:05 +0000 (UTC) Received: from freddy.simplesystems.org (freddy.simplesystems.org [65.66.246.65]) by blade.simplesystems.org (8.13.8+Sun/8.13.8) with ESMTP id o0P5X7BA024156; Sun, 24 Jan 2010 23:33:07 -0600 (CST) Date: Sun, 24 Jan 2010 23:33:07 -0600 (CST) From: Bob Friesenhahn X-X-Sender: bfriesen@freddy.simplesystems.org To: Dan Naumov In-Reply-To: Message-ID: References: <883b2dc51001240905r4cfbf830i3b9b400969ac261b@mail.gmail.com> <1264368182.00211075.1264355402@10.7.7.3> <4B5CC167.5010604@FreeBSD.org> User-Agent: Alpine 2.01 (GSO 1266 2009-07-14) 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.2 (blade.simplesystems.org [65.66.246.90]); Sun, 24 Jan 2010 23:33:07 -0600 (CST) Cc: freebsd-fs@freebsd.org, Alexander Motin , Jason Edwards , FreeBSD-STABLE Mailing List , freebsd-questions@freebsd.org Subject: Re: 8.0-RELEASE/amd64 - full ZFS install - low read and write disk performance X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jan 2010 05:55:06 -0000 On Mon, 25 Jan 2010, Dan Naumov wrote: > > I've checked with the manufacturer and it seems that the Sil3124 in > this NAS is indeed a PCI card. More info on the card in question is > available at http://green-pcs.co.uk/2009/01/28/tranquil-bbs2-those-pci-cards/ > I have the card described later on the page, the one with 4 SATA ports > and no eSATA. Alright, so it being PCI is probably a bottleneck in > some ways, but that still doesn't explain the performance THAT bad, > considering that same hardware, same disks, same disk controller push > over 65mb/s in both reads and writes in Win2008. And agian, I am > pretty sure that I've had "close to expected" results when I was The slow PCI bus and this card look like the bottleneck to me. Remember that your Win2008 tests were with just one disk, your zfs performance with just one disk was similar to Win2008, and your zfs performance with a mirror was just under 1/2 that. I don't think that your performance results are necessarily out of line for the hardware you are using. On an old Sun SPARC workstation with retrofitted 15K RPM drives on Ultra-160 SCSI channel, I see a zfs mirror write performance of 67,317KB/second and a read performance of 124,347KB/second. The drives themselves are capable of 100MB/second range performance. Similar to yourself, I see 1/2 the write performance due to bandwidth limitations. Bob -- Bob Friesenhahn bfriesen@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer, http://www.GraphicsMagick.org/ From owner-freebsd-stable@FreeBSD.ORG Mon Jan 25 07:00:59 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6626D1065676; Mon, 25 Jan 2010 07:00:59 +0000 (UTC) (envelope-from mavbsd@gmail.com) Received: from mail-fx0-f226.google.com (mail-fx0-f226.google.com [209.85.220.226]) by mx1.freebsd.org (Postfix) with ESMTP id 8CAE68FC29; Mon, 25 Jan 2010 07:00:58 +0000 (UTC) Received: by fxm26 with SMTP id 26so689533fxm.13 for ; Sun, 24 Jan 2010 23:00:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :x-enigmail-version:content-type:content-transfer-encoding; bh=p6eu0eZZ0xKVt/XSKpZZv3bpWEX+BO2tnASnZOTfEdI=; b=akjh+F4rYocKFdx5jCLmq8q9J8ADZajKCHIAu1a551RSIutwk4Q4n02bBMA8y4efPE 0NOHAkM5FZLoAsU/doxkAVrOsMw7vMzONTtNfJUpJxbDrwMgXRF81iThvdkZaSWhV2gp Uij9axdqnqu6L29u73Cp334YacXUlQYp05Hs4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:content-type :content-transfer-encoding; b=HWOJBXaf7RbmnT473CpKL2PGOPv+IIvS8mh7560RQ529+PleQ4ENllw317EOMeiRX9 ss03Rv2p7sbIGfRHci6LNMDiUt2FHzcZH/M+jhRIMiinj9qiCNrHV3Ql+vVG7jAnsBHz yvDBYpB/9h+ouYgOu2Sz1zaiyDI09j3uHXUzI= Received: by 10.223.17.155 with SMTP id s27mr6428939faa.13.1264402857645; Sun, 24 Jan 2010 23:00:57 -0800 (PST) Received: from mavbook.mavhome.dp.ua (pc.mavhome.dp.ua [212.86.226.226]) by mx.google.com with ESMTPS id 15sm2542816fxm.6.2010.01.24.23.00.56 (version=SSLv3 cipher=RC4-MD5); Sun, 24 Jan 2010 23:00:57 -0800 (PST) Sender: Alexander Motin Message-ID: <4B5D41A6.5080203@FreeBSD.org> Date: Mon, 25 Jan 2010 09:00:54 +0200 From: Alexander Motin User-Agent: Thunderbird 2.0.0.23 (X11/20091212) MIME-Version: 1.0 To: Dan Naumov References: <883b2dc51001240905r4cfbf830i3b9b400969ac261b@mail.gmail.com> <1264368182.00211075.1264355402@10.7.7.3> <4B5CC167.5010604@FreeBSD.org> In-Reply-To: X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-fs@freebsd.org, Jason Edwards , FreeBSD-STABLE Mailing List , freebsd-questions@freebsd.org Subject: Re: 8.0-RELEASE/amd64 - full ZFS install - low read and write disk performance X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jan 2010 07:00:59 -0000 Dan Naumov wrote: > On Mon, Jan 25, 2010 at 2:14 AM, Dan Naumov wrote: >> On Sun, Jan 24, 2010 at 11:53 PM, Alexander Motin wrote: >>> Dan Naumov wrote: >>>> This works out to 1GB in 36,2 seconds / 28,2mb/s in the first test and >>>> 4GB in 143.8 seconds / 28,4mb/s and somewhat consistent with the >>>> bonnie results. It also sadly seems to confirm the very slow speed :( >>>> The disks are attached to a 4-port Sil3124 controller and again, my >>>> Windows benchmarks showing 65mb/s+ were done on exact same machine, >>>> with same disks attached to the same controller. Only difference was >>>> that in Windows the disks weren't in a mirror configuration but were >>>> tested individually. I do understand that a mirror setup offers >>>> roughly the same write speed as individual disk, while the read speed >>>> usually varies from "equal to individual disk speed" to "nearly the >>>> throughput of both disks combined" depending on the implementation, >>>> but there is no obvious reason I am seeing why my setup offers both >>>> read and write speeds roughly 1/3 to 1/2 of what the individual disks >>>> are capable of. Dmesg shows: >>>> >>>> atapci0: port 0x1000-0x100f mem >>>> 0x90108000-0x9010807f,0x90100000-0x90107fff irq 21 at device 0.0 on >>>> pci4 >>>> ad8: 1907729MB at ata4-master SATA300 >>>> ad10: 1907729MB at ata5-master SATA300 >>> 8.0-RELEASE, and especially 8-STABLE provide alternative, much more >>> functional driver for this controller, named siis(4). If your SiI3124 >>> card installed into proper bus (PCI-X or PCIe x4/x8), it can be really >>> fast (up to 1GB/s was measured). >>> >>> -- >>> Alexander Motin >> Sadly, it seems that utilizing the new siis driver doesn't do much good: >> >> Before utilizing siis: >> >> iozone -s 4096M -r 512 -i0 -i1 >> random >> random bkwd record stride >> KB reclen write rewrite read reread read >> write read rewrite read fwrite frewrite fread freread >> 4194304 512 28796 28766 51610 50695 >> >> After enabling siis in loader.conf (and ensuring the disks show up as ada): >> >> iozone -s 4096M -r 512 -i0 -i1 >> >> random >> random bkwd record stride >> KB reclen write rewrite read reread read >> write read rewrite read fwrite frewrite fread freread >> 4194304 512 28781 28897 47214 50540 > > Just to add to the numbers above, exact same benchmark, on 1 disk > (detached 2nd disk from the mirror) while using the siis driver: > > random > random bkwd record stride > KB reclen write rewrite read reread read > write read rewrite read fwrite frewrite fread freread > 4194304 512 57760 56371 68867 74047 If both parts of mirror uses same controller, it doubles it's bus traffic. That may reduce bandwidth twice. The main benefit of siis(4) is a command queuing. You should receive more benefits on multithread random I/O. -- Alexander Motin From owner-freebsd-stable@FreeBSD.ORG Mon Jan 25 07:34:53 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 83C381065672; Mon, 25 Jan 2010 07:34:53 +0000 (UTC) (envelope-from dan.naumov@gmail.com) Received: from mail-yx0-f171.google.com (mail-yx0-f171.google.com [209.85.210.171]) by mx1.freebsd.org (Postfix) with ESMTP id F408C8FC1A; Mon, 25 Jan 2010 07:34:52 +0000 (UTC) Received: by yxe1 with SMTP id 1so2622784yxe.3 for ; Sun, 24 Jan 2010 23:34:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=JPV6jRzwieQnlULeFbANGq33ETf6qoWOFzZvsS7JwUU=; b=Px0wT+TVXcSQg2pTyl1dwQnGUu4xjUpIb2mwLE8kiWEia9qmnYrHYMR6XS8m/QKwQ0 GBo48VVmQWg8R8sk6ji7Bnp/eGndAL/hfNaDgK85jWk3GTWK7uxQ4Gw5oTmbudWQ14P1 qcjATXHI7zzitK4ZS7mgD41rwVLJiktiAKXOo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=tSAtR80zCR1KORgccYf7rdboVg/kELJ0IKa8LtX6wZETdeRY9O5xS/b+TRbCdADWIo blDYI7JU04wIAJK7ZimMNQ5jzp1eKVghPmyDkKNG2drg6CFphDL4hFhT38/Ap150Cl+P d1PFoV18tWHDfBq22RYDJiLozD0AU+sf5saR4= MIME-Version: 1.0 Received: by 10.101.2.23 with SMTP id e23mr7310095ani.206.1264404892197; Sun, 24 Jan 2010 23:34:52 -0800 (PST) In-Reply-To: References: <883b2dc51001240905r4cfbf830i3b9b400969ac261b@mail.gmail.com> <1264368182.00211075.1264355402@10.7.7.3> <4B5CC167.5010604@FreeBSD.org> Date: Mon, 25 Jan 2010 09:34:52 +0200 Message-ID: From: Dan Naumov To: Bob Friesenhahn Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-fs@freebsd.org, Alexander Motin , Jason Edwards , FreeBSD-STABLE Mailing List , freebsd-questions@freebsd.org Subject: Re: 8.0-RELEASE/amd64 - full ZFS install - low read and write disk performance X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jan 2010 07:34:53 -0000 On Mon, Jan 25, 2010 at 7:33 AM, Bob Friesenhahn wrote: > On Mon, 25 Jan 2010, Dan Naumov wrote: >> >> I've checked with the manufacturer and it seems that the Sil3124 in >> this NAS is indeed a PCI card. More info on the card in question is >> available at >> http://green-pcs.co.uk/2009/01/28/tranquil-bbs2-those-pci-cards/ >> I have the card described later on the page, the one with 4 SATA ports >> and no eSATA. Alright, so it being PCI is probably a bottleneck in >> some ways, but that still doesn't explain the performance THAT bad, >> considering that same hardware, same disks, same disk controller push >> over 65mb/s in both reads and writes in Win2008. And agian, I am >> pretty sure that I've had "close to expected" results when I was > > The slow PCI bus and this card look like the bottleneck to me. Remember t= hat > your Win2008 tests were with just one disk, your zfs performance with jus= t > one disk was similar to Win2008, and your zfs performance with a mirror w= as > just under 1/2 that. > > I don't think that your performance results are necessarily out of line f= or > the hardware you are using. > > On an old Sun SPARC workstation with retrofitted 15K RPM drives on Ultra-= 160 > SCSI channel, I see a zfs mirror write performance of 67,317KB/second and= a > read performance of 124,347KB/second. =A0The drives themselves are capabl= e of > 100MB/second range performance. Similar to yourself, I see 1/2 the write > performance due to bandwidth limitations. > > Bob There is lots of very sweet irony in my particular situiation. Initially I was planning to use a single X25-M 80gb SSD in the motherboard sata port for the actual OS installation as well as to dedicate 50gb of it to a become a designaed L2ARC vdev for my ZFS mirrors. The SSD attached to the motherboard port would be recognized only as a SATA150 device for some reason, but I was still seeing 150mb/s throughput and sub 0.1 ms latencies on that disk simply because of how crazy good the X25-M's are. However I ended up having very bad issues with the Icydock 2,5" to 3,5" converter jacket I was using to keep/fit the SSD in the system and it would randomly drop write IO on heavy load due to bad connectors. Having finally figured out the cause of my OS installations to the SSD going belly up during applying updates, I decided to move the SSD to my desktop and use it there instead, additionally thinking that my perhaps my idea of the SSD was crazy overkill for what I need the system to do. Ironically now that I am seeing how horrible the performance is when I am operating on the mirror through this PCI card, I realize that actually, my idea was pretty bloody brilliant, I just didn't really know why at the time. An L2ARC device on the motherboard port would really help me with random read IO, but to work around the utterly poor write performance, I would also need a dedicaled SLOG ZIL device. The catch is that while L2ARC devices and be removed from the pool at will (should the device up and die all of a sudden), the dedicated ZILs cannot and currently a "missing" ZIL device will render the pool it's included in be unable to import and become inaccessible. There is some work happening in Solaris to implement removing SLOGs from a pool, but that work hasn't yet found it's way in FreeBSD yet. - Sincerely, Dan Naumov - Sincerely, Dan Naumov From owner-freebsd-stable@FreeBSD.ORG Mon Jan 25 08:07:09 2010 Return-Path: Delivered-To: FreeBSD-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B795A106566C for ; Mon, 25 Jan 2010 08:07:09 +0000 (UTC) (envelope-from peterjeremy@acm.org) Received: from mail13.syd.optusnet.com.au (mail13.syd.optusnet.com.au [211.29.132.194]) by mx1.freebsd.org (Postfix) with ESMTP id 42D158FC17 for ; Mon, 25 Jan 2010 08:07:08 +0000 (UTC) Received: from server.vk2pj.dyndns.org (c122-106-232-148.belrs3.nsw.optusnet.com.au [122.106.232.148]) by mail13.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id o0P874no030885 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 25 Jan 2010 19:07:05 +1100 X-Bogosity: Ham, spamicity=0.000000 Received: from server.vk2pj.dyndns.org (localhost.vk2pj.dyndns.org [127.0.0.1]) by server.vk2pj.dyndns.org (8.14.3/8.14.3) with ESMTP id o0P870Ha098030; Mon, 25 Jan 2010 19:07:00 +1100 (EST) (envelope-from peter@server.vk2pj.dyndns.org) Received: (from peter@localhost) by server.vk2pj.dyndns.org (8.14.3/8.14.3/Submit) id o0P870KJ098027; Mon, 25 Jan 2010 19:07:00 +1100 (EST) (envelope-from peter) Date: Mon, 25 Jan 2010 19:07:00 +1100 From: Peter Jeremy To: FreeBSD-stable@freebsd.org Message-ID: <20100125080659.GN31243@server.vk2pj.dyndns.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="37nyS7qXrnu4wN2o" Content-Disposition: inline In-Reply-To: <201001242023.o0OKNj5p044592@server.vk2pj.dyndns.org> X-PGP-Key: http://members.optusnet.com.au/peterjeremy/pubkey.asc User-Agent: Mutt/1.5.20 (2009-06-14) Cc: bzeeb+freebsd+lor@zabbadoz.net Subject: New zfs/bufwait LOR X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 25 Jan 2010 08:07:09 -0000 --37nyS7qXrnu4wN2o Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable I had the following crop up recently in 8-STABLE/amd64 from end of November. It's been reported as kern/143184. lock order reversal: 1st 0xffffff002f7fb270 zfs (zfs) @ /usr/src/sys/kern/vfs_vnops.c:533 2nd 0xffffff80803a26e0 bufwait (bufwait) @ /usr/src/sys/vm/vm_pager.c:311 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2a _witness_debugger() at _witness_debugger+0x2c witness_checkorder() at witness_checkorder+0x66f __lockmgr_args() at __lockmgr_args+0x475 initpbuf() at initpbuf+0xb9 getpbuf() at getpbuf+0xdc swap_pager_getpages() at swap_pager_getpages+0x1aa vm_fault() at vm_fault+0x5f7 trap_pfault() at trap_pfault+0x128 trap() at trap+0x379 calltrap() at calltrap+0x8 --- trap 0xc, rip =3D 0xffffffff8049497b, rsp =3D 0xffffff809a427830, rbp = =3D 0xffffff809a4278b0 --- copyout() at copyout+0x3b dmu_read_uio() at dmu_read_uio+0x98 zfs_freebsd_read() at zfs_freebsd_read+0x56f VOP_READ_APV() at VOP_READ_APV+0x44 vn_read() at vn_read+0x149 dofileread() at dofileread+0xa1 kern_readv() at kern_readv+0x60 read() at read+0x55 syscall() at syscall+0x1ac Xfast_syscall() at Xfast_syscall+0xe1 --- syscall (3, FreeBSD ELF64, read), rip =3D 0x8008ce86c, rsp =3D 0x7fffff= feb718, rbp =3D 0x805b41d18 --- --=20 Peter Jeremy --37nyS7qXrnu4wN2o Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.14 (FreeBSD) iEYEARECAAYFAktdUSMACgkQ/opHv/APuIea7wCgwWav+11QPxmxcrLageDYLqPf Eh0AnRPcXFvCT6kLQuiA2RclyLGKBm51 =L7rK -----END PGP SIGNATURE----- --37nyS7qXrnu4wN2o-- From owner-freebsd-stable@FreeBSD.ORG Mon Jan 25 08:32:21 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 28EB5106566B; Mon, 25 Jan 2010 08:32:21 +0000 (UTC) (envelope-from dan.naumov@gmail.com) Received: from mail-yw0-f197.google.com (mail-yw0-f197.google.com [209.85.211.197]) by mx1.freebsd.org (Postfix) with ESMTP id 966868FC0A; Mon, 25 Jan 2010 08:32:20 +0000 (UTC) Received: by ywh35 with SMTP id 35so2538895ywh.7 for ; Mon, 25 Jan 2010 00:32:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=g5zFN5gisNK7vcHBmsGGkEdHWsTjCP+1nRHAdd6EGCk=; b=ozR3+lulCZ7MWvjNi1AV+lTeXB7JwvwG7U9rGyvl8/VGareW7S9rwNYF72DBHvttdX e0RDM3vnTIoVllZQhrhd0zpw/fHrRdc4qInK8ocaqYE+J8fmmoELncO4Tgz8vnazTw/i uPy9Vs1tfhz6O0ICQguA/wgDOx5DGnKAJlUC4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=VqsNGlty9c/zOBZpkqNtxRFYD7stzBA95/5YhqdMOZp4W/9+6hJKBoF5kOkCsgfQvX RBGtak27CpYRcAFwmNXfXKr/BhIM6onDdyaks6j30qBXv/B1XJKpUFpoAYh3BxoQcbdH jjV5T3hkJM+YH5R1JdMroeuTVa9zpK3FYnTz4= MIME-Version: 1.0 Received: by 10.101.6.22 with SMTP id j22mr7317943ani.224.1264408339787; Mon, 25 Jan 2010 00:32:19 -0800 (PST) In-Reply-To: References: <883b2dc51001240905r4cfbf830i3b9b400969ac261b@mail.gmail.com> <1264368182.00211075.1264355402@10.7.7.3> <4B5CC167.5010604@FreeBSD.org> Date: Mon, 25 Jan 2010 10:32:19 +0200 Message-ID: From: Dan Naumov To: Bob Friesenhahn Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-fs@freebsd.org, Alexander Motin , Jason Edwards , FreeBSD-STABLE Mailing List , freebsd-questions@freebsd.org Subject: Re: 8.0-RELEASE/amd64 - full ZFS install - low read and write disk performance X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jan 2010 08:32:21 -0000 On Mon, Jan 25, 2010 at 9:34 AM, Dan Naumov wrote: > On Mon, Jan 25, 2010 at 7:33 AM, Bob Friesenhahn > wrote: >> On Mon, 25 Jan 2010, Dan Naumov wrote: >>> >>> I've checked with the manufacturer and it seems that the Sil3124 in >>> this NAS is indeed a PCI card. More info on the card in question is >>> available at >>> http://green-pcs.co.uk/2009/01/28/tranquil-bbs2-those-pci-cards/ >>> I have the card described later on the page, the one with 4 SATA ports >>> and no eSATA. Alright, so it being PCI is probably a bottleneck in >>> some ways, but that still doesn't explain the performance THAT bad, >>> considering that same hardware, same disks, same disk controller push >>> over 65mb/s in both reads and writes in Win2008. And agian, I am >>> pretty sure that I've had "close to expected" results when I was >> >> The slow PCI bus and this card look like the bottleneck to me. Remember = that >> your Win2008 tests were with just one disk, your zfs performance with ju= st >> one disk was similar to Win2008, and your zfs performance with a mirror = was >> just under 1/2 that. >> >> I don't think that your performance results are necessarily out of line = for >> the hardware you are using. >> >> On an old Sun SPARC workstation with retrofitted 15K RPM drives on Ultra= -160 >> SCSI channel, I see a zfs mirror write performance of 67,317KB/second an= d a >> read performance of 124,347KB/second. =A0The drives themselves are capab= le of >> 100MB/second range performance. Similar to yourself, I see 1/2 the write >> performance due to bandwidth limitations. >> >> Bob > > There is lots of very sweet irony in my particular situiation. > Initially I was planning to use a single X25-M 80gb SSD in the > motherboard sata port for the actual OS installation as well as to > dedicate 50gb of it to a become a designaed L2ARC vdev for my ZFS > mirrors. The SSD attached to the motherboard port would be recognized > only as a SATA150 device for some reason, but I was still seeing > 150mb/s throughput and sub 0.1 ms latencies on that disk simply > because of how crazy good the X25-M's are. However I ended up having > very bad issues with the Icydock 2,5" to 3,5" converter jacket I was > using to keep/fit the SSD in the system and it would randomly drop > write IO on heavy load due to bad connectors. Having finally figured > out the cause of my OS installations to the SSD going belly up during > applying updates, I decided to move the SSD to my desktop and use it > there instead, additionally thinking that my perhaps my idea of the > SSD was crazy overkill for what I need the system to do. Ironically > now that I am seeing how horrible the performance is when I am > operating on the mirror through this PCI card, I realize that > actually, my idea was pretty bloody brilliant, I just didn't really > know why at the time. > > An L2ARC device on the motherboard port would really help me with > random read IO, but to work around the utterly poor write performance, > I would also need a dedicaled SLOG ZIL device. The catch is that while > L2ARC devices and be removed from the pool at will (should the device > up and die all of a sudden), the dedicated ZILs cannot and currently a > "missing" ZIL device will render the pool it's included in be unable > to import and become inaccessible. There is some work happening in > Solaris to implement removing SLOGs from a pool, but that work hasn't > yet found it's way in FreeBSD yet. > > > - Sincerely, > Dan Naumov OK final question: if/when I go about adding more disks to the system and want redundancy, am I right in thinking that: ZFS pool of disk1+disk2 mirror + disk3+disk4 mirror (a la RAID10) would completely murder my write and read performance even way below the current 28mb/s / 50mb/s I am seeing with 2 disks on that PCI controller and that in order to have the least negative impact, I should simply have 2 independent mirrors in 2 independent pools (with the 5th disk slot in the NAS given to a non-redundant single disk running off the one available SATA port on the motherboard)? - Sincerely, Dan Naumov From owner-freebsd-stable@FreeBSD.ORG Mon Jan 25 09:03:55 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4B614106568F for ; Mon, 25 Jan 2010 09:03:55 +0000 (UTC) (envelope-from zephyrus.271@gmail.com) Received: from mail-fx0-f226.google.com (mail-fx0-f226.google.com [209.85.220.226]) by mx1.freebsd.org (Postfix) with ESMTP id C7E1F8FC18 for ; Mon, 25 Jan 2010 09:03:54 +0000 (UTC) Received: by fxm26 with SMTP id 26so758437fxm.13 for ; Mon, 25 Jan 2010 01:03:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:received:date:from:to:cc :subject:message-id:references:mime-version:content-type :content-disposition:in-reply-to:user-agent; bh=EgXeHIVVVsNSxSU0coEDRfknU7G1b+z8TAY+zN0B/iU=; b=V1gYhlvxy/zHK+Zo6/R4+1Aaqp3YnBDkaZquRHJrw16FoEfadXsatGZkfWMN7ZuRrI 6A7d/7wU85IFFZe/PUOrNxhb37wEylPzncFs9dF9gJJGXoJZ/hioCsGqoQxpY5/IjXh3 vqCfcGZJdg8DG2k46zgd15aFfON7Ip4FC/X88= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; b=CkFGA1rifCcaMXBHpwICpc0mAtMjt6EsFA/JcaU0tt2Vmzkw0jGvuFkWmHwNpO5H4r tfjzVJMRqhWc/O9/SWg5rEp5xcVkTSJcmgNkzEmi1nJynBrZAxa0bjhg+gtaGUtsPacL 7HdLPbvyIdQ7cdbpLixh/p5pBRGlcs+w5UuVg= Received: by 10.223.16.72 with SMTP id n8mr5801886faa.26.1264410233392; Mon, 25 Jan 2010 01:03:53 -0800 (PST) Received: from polaris.localdomain (81-174-11-81.static.ngi.it [81.174.11.81]) by mx.google.com with ESMTPS id 22sm6318120fkq.54.2010.01.25.01.03.51 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 25 Jan 2010 01:03:51 -0800 (PST) Received: by polaris.localdomain (Postfix, from userid 1000) id 248202A; Mon, 25 Jan 2010 10:03:46 +0100 (CET) Date: Mon, 25 Jan 2010 10:03:46 +0100 From: "Emanuele A. Bagnaschi" To: Pyun YongHyeon Message-ID: <20100125090346.GA2039@polaris> References: <20100124183911.GA2589@polaris> <20100124205505.GB1187@michelle.cdnetworks.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="wRRV7LY7NUeQGEoC" Content-Disposition: inline In-Reply-To: <20100124205505.GB1187@michelle.cdnetworks.com> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: FreeBSD-STABLE Mailing List Subject: Re: Problematic network performance with Marvell 8072 on HP Probook 4710s X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 25 Jan 2010 09:03:55 -0000 --wRRV7LY7NUeQGEoC Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 12:55 Sun 24 Jan , Pyun YongHyeon wrote: > Last time I checked ttcp, it was broken with threading. So you have > to build ttcp without threading support or use netperf to check > performance numbers. That's bad, this evening I will try with netperf. > It seems you have Yukon Extreme controller and its revision is B0 > which is known to have various silicon bug. How about disabling TX=20 > related offloading?(e.g. ifconfig msk0 -txcsum -tso) Does that make > any difference? It seems that there are no differences. > Given that high rates of silicon bug of Yukon having a detailed > errata information would be great help to analyze the issue. But we > still have no access to the information as well as datasheet. And I bet that there's no specific release date for that information, isn't there? Should I take a look at the other BDSs (or even Linux) to check, for example, if they use specific workarounds for my NIC? Actually=20 I am sure that on Linux it works. Would be any problems with the GPL2 in th= is case? Best regards --=20 Emanuele A. Bagnaschi --wRRV7LY7NUeQGEoC Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.14 (FreeBSD) iEYEARECAAYFAktdXnIACgkQrwnEPevYb9WT7wCffy6hu+u8VlBKw1fU2IfJWmVg Qw8AoKKcTU70CLmjXH3yTyrH7pqf6+Yl =pjfZ -----END PGP SIGNATURE----- --wRRV7LY7NUeQGEoC-- From owner-freebsd-stable@FreeBSD.ORG Mon Jan 25 09:19:09 2010 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3C437106568D; Mon, 25 Jan 2010 09:19:09 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 0DBC88FC1E; Mon, 25 Jan 2010 09:19:07 +0000 (UTC) Received: from porto.topspin.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id LAA12164; Mon, 25 Jan 2010 11:19:04 +0200 (EET) (envelope-from avg@icyb.net.ua) Received: from localhost.topspin.kiev.ua ([127.0.0.1]) by porto.topspin.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1NZL68-000FFq-60; Mon, 25 Jan 2010 11:19:04 +0200 Message-ID: <4B5D6207.9090105@icyb.net.ua> Date: Mon, 25 Jan 2010 11:19:03 +0200 From: Andriy Gapon User-Agent: Thunderbird 2.0.0.23 (X11/20091128) MIME-Version: 1.0 To: Robert Noland References: <20100122041237.GA22312@gothschlampen.com> <20100124092947.B72039@starfire.mn.org> <201001242057.o0OKvHUE089237@drugs.dv.isc.org> <1264387282.2869.24.camel@balrog.2hip.net> In-Reply-To: <1264387282.2869.24.camel@balrog.2hip.net> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=KOI8-U Content-Transfer-Encoding: 7bit Cc: FreeBSD-STABLE Mailing List , freebsd-questions@FreeBSD.org Subject: Re: Loader, MBR and the boot process X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 25 Jan 2010 09:19:09 -0000 on 25/01/2010 04:41 Robert Noland said the following: > On Mon, 2010-01-25 at 07:57 +1100, Mark Andrews wrote: >> offset The offset of the start of the partition from the beginning of >> the drive in sectors, or * to have bsdlabel calculate the correct >> offset to use (the end of the previous partition plus one, ignor- >> ing partition `c'. For partition `c', * will be interpreted as >> an offset of 0. The first partition should start at offset 16, >> because the first 16 sectors are reserved for metadata. > > Ok, now this has my attention... My gut feeling right now is that this > is a bug in geom_part_bsd. I don't understand why the label isn't > protected. (Adding -b 16 when adding the swap partition fixes this) > Another project to goes on my list... > > If anyone knows why this is done like this... please share. I presume that this is for purely historic reasons. -- Andriy Gapon From owner-freebsd-stable@FreeBSD.ORG Mon Jan 25 09:24:29 2010 Return-Path: Delivered-To: FreeBSD-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7B2461065670 for ; Mon, 25 Jan 2010 09:24:29 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.zoral.com.ua (skuns.zoral.com.ua [91.193.166.194]) by mx1.freebsd.org (Postfix) with ESMTP id E6C0F8FC12 for ; Mon, 25 Jan 2010 09:24:28 +0000 (UTC) Received: from deviant.kiev.zoral.com.ua (root@deviant.kiev.zoral.com.ua [10.1.1.148]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id o0P9OBT3072222 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 25 Jan 2010 11:24:11 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.3/8.14.3) with ESMTP id o0P9OBHo018034; Mon, 25 Jan 2010 11:24:11 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.3/8.14.3/Submit) id o0P9OBoP018033; Mon, 25 Jan 2010 11:24:11 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Mon, 25 Jan 2010 11:24:11 +0200 From: Kostik Belousov To: Peter Jeremy Message-ID: <20100125092411.GK3877@deviant.kiev.zoral.com.ua> References: <201001242023.o0OKNj5p044592@server.vk2pj.dyndns.org> <20100125080659.GN31243@server.vk2pj.dyndns.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="4wkndigzIeYF6Hbg" Content-Disposition: inline In-Reply-To: <20100125080659.GN31243@server.vk2pj.dyndns.org> User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: clamav-milter 0.95.2 at skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-4.4 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua Cc: bzeeb+freebsd+lor@zabbadoz.net, FreeBSD-stable@freebsd.org Subject: Re: New zfs/bufwait LOR X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 25 Jan 2010 09:24:29 -0000 --4wkndigzIeYF6Hbg Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Jan 25, 2010 at 07:07:00PM +1100, Peter Jeremy wrote: > I had the following crop up recently in 8-STABLE/amd64 from end of > November. It's been reported as kern/143184. Basically, page containing the buffer for read(2) is swapped out. This causes page fault in copyout(9) and entry into vm subsystem while zfs vnode lock is held. If the buffer is backed by e.g. UFS vnode instead of anonymous memory, you would get UFS/zfs LOR. The problem is generic, I am working on the solution in collaboration with Peter Holm, basing on the Jeff Roberson idea. >=20 > lock order reversal: > 1st 0xffffff002f7fb270 zfs (zfs) @ /usr/src/sys/kern/vfs_vnops.c:533 > 2nd 0xffffff80803a26e0 bufwait (bufwait) @ /usr/src/sys/vm/vm_pager.c:311 > KDB: stack backtrace: > db_trace_self_wrapper() at db_trace_self_wrapper+0x2a > _witness_debugger() at _witness_debugger+0x2c > witness_checkorder() at witness_checkorder+0x66f > __lockmgr_args() at __lockmgr_args+0x475 > initpbuf() at initpbuf+0xb9 > getpbuf() at getpbuf+0xdc > swap_pager_getpages() at swap_pager_getpages+0x1aa > vm_fault() at vm_fault+0x5f7 > trap_pfault() at trap_pfault+0x128 > trap() at trap+0x379 > calltrap() at calltrap+0x8 > --- trap 0xc, rip =3D 0xffffffff8049497b, rsp =3D 0xffffff809a427830, rbp= =3D 0xffffff809a4278b0 --- > copyout() at copyout+0x3b > dmu_read_uio() at dmu_read_uio+0x98 > zfs_freebsd_read() at zfs_freebsd_read+0x56f > VOP_READ_APV() at VOP_READ_APV+0x44 > vn_read() at vn_read+0x149 > dofileread() at dofileread+0xa1 > kern_readv() at kern_readv+0x60 > read() at read+0x55 > syscall() at syscall+0x1ac > Xfast_syscall() at Xfast_syscall+0xe1 > --- syscall (3, FreeBSD ELF64, read), rip =3D 0x8008ce86c, rsp =3D 0x7fff= fffeb718, rbp =3D 0x805b41d18 --- >=20 > --=20 > Peter Jeremy --4wkndigzIeYF6Hbg Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (FreeBSD) iEYEARECAAYFAktdYzsACgkQC3+MBN1Mb4g2TgCghDryQ12imDm7FSbLDYBWFJK8 yoMAnRy2gJ2KKVwzXLmUM5i1TDl2dEHJ =xCUI -----END PGP SIGNATURE----- --4wkndigzIeYF6Hbg-- From owner-freebsd-stable@FreeBSD.ORG Mon Jan 25 09:29:36 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9A9D9106566B; Mon, 25 Jan 2010 09:29:36 +0000 (UTC) (envelope-from wonslung@gmail.com) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.157]) by mx1.freebsd.org (Postfix) with ESMTP id EDC0A8FC13; Mon, 25 Jan 2010 09:29:35 +0000 (UTC) Received: by fg-out-1718.google.com with SMTP id e12so85570fga.13 for ; Mon, 25 Jan 2010 01:29:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=yILrgnuSr+kV0FohkSJQBB2hXNICQ/BGuFH3nOOhtdk=; b=RwfNgDn9ihjqjNUKyFxs1NznV3Q9lMBxiI0triZUCsk5iKyZ8jYuwy7CIfkbGk/PZx 7P37KRNSFBUNuzZ7+4nNhGXON30uXc7+GU6rRrCQl1CG03HB0ZjItGNg14ytfYzqSlZB gOhJT862QLnK+Xn1WVlvL0itT2h2wlfGe4UUg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=WBr7xcZ5R+ZAslVVAsJzl4cBriv/h2gCislho34tKZ5ruTY+gwFd7jxzbcsZVpxqw0 v7zuO8SJ7qHHJyiUsE8iz8MURXrYfF3vHBj/dl3BwRu1GAICPT9AJDD0cN5+RQahUjQE e2k6Q1BRAy2yCymFkq/br2DtRBjfzrVfsMmoQ= MIME-Version: 1.0 Received: by 10.103.84.15 with SMTP id m15mr3186048mul.43.1264409928645; Mon, 25 Jan 2010 00:58:48 -0800 (PST) In-Reply-To: References: <883b2dc51001240905r4cfbf830i3b9b400969ac261b@mail.gmail.com> <1264368182.00211075.1264355402@10.7.7.3> <4B5CC167.5010604@FreeBSD.org> Date: Mon, 25 Jan 2010 03:58:48 -0500 Message-ID: From: Thomas Burgess To: Dan Naumov Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Jason Edwards , FreeBSD-STABLE Mailing List , Alexander Motin , freebsd-fs@freebsd.org, Bob Friesenhahn , freebsd-questions@freebsd.org Subject: Re: 8.0-RELEASE/amd64 - full ZFS install - low read and write disk performance X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jan 2010 09:29:36 -0000 It depends on the bandwidth of the bus that it is on and the controller itself. I like to use pci-x with aoc-sat2-mv8 cards or pci-e cards....that way you get a lot more bandwidth.. On Mon, Jan 25, 2010 at 3:32 AM, Dan Naumov wrote: > On Mon, Jan 25, 2010 at 9:34 AM, Dan Naumov wrote: > > On Mon, Jan 25, 2010 at 7:33 AM, Bob Friesenhahn > > wrote: > >> On Mon, 25 Jan 2010, Dan Naumov wrote: > >>> > >>> I've checked with the manufacturer and it seems that the Sil3124 in > >>> this NAS is indeed a PCI card. More info on the card in question is > >>> available at > >>> http://green-pcs.co.uk/2009/01/28/tranquil-bbs2-those-pci-cards/ > >>> I have the card described later on the page, the one with 4 SATA ports > >>> and no eSATA. Alright, so it being PCI is probably a bottleneck in > >>> some ways, but that still doesn't explain the performance THAT bad, > >>> considering that same hardware, same disks, same disk controller push > >>> over 65mb/s in both reads and writes in Win2008. And agian, I am > >>> pretty sure that I've had "close to expected" results when I was > >> > >> The slow PCI bus and this card look like the bottleneck to me. Remember > that > >> your Win2008 tests were with just one disk, your zfs performance with > just > >> one disk was similar to Win2008, and your zfs performance with a mirror > was > >> just under 1/2 that. > >> > >> I don't think that your performance results are necessarily out of line > for > >> the hardware you are using. > >> > >> On an old Sun SPARC workstation with retrofitted 15K RPM drives on > Ultra-160 > >> SCSI channel, I see a zfs mirror write performance of 67,317KB/second > and a > >> read performance of 124,347KB/second. The drives themselves are capable > of > >> 100MB/second range performance. Similar to yourself, I see 1/2 the write > >> performance due to bandwidth limitations. > >> > >> Bob > > > > There is lots of very sweet irony in my particular situiation. > > Initially I was planning to use a single X25-M 80gb SSD in the > > motherboard sata port for the actual OS installation as well as to > > dedicate 50gb of it to a become a designaed L2ARC vdev for my ZFS > > mirrors. The SSD attached to the motherboard port would be recognized > > only as a SATA150 device for some reason, but I was still seeing > > 150mb/s throughput and sub 0.1 ms latencies on that disk simply > > because of how crazy good the X25-M's are. However I ended up having > > very bad issues with the Icydock 2,5" to 3,5" converter jacket I was > > using to keep/fit the SSD in the system and it would randomly drop > > write IO on heavy load due to bad connectors. Having finally figured > > out the cause of my OS installations to the SSD going belly up during > > applying updates, I decided to move the SSD to my desktop and use it > > there instead, additionally thinking that my perhaps my idea of the > > SSD was crazy overkill for what I need the system to do. Ironically > > now that I am seeing how horrible the performance is when I am > > operating on the mirror through this PCI card, I realize that > > actually, my idea was pretty bloody brilliant, I just didn't really > > know why at the time. > > > > An L2ARC device on the motherboard port would really help me with > > random read IO, but to work around the utterly poor write performance, > > I would also need a dedicaled SLOG ZIL device. The catch is that while > > L2ARC devices and be removed from the pool at will (should the device > > up and die all of a sudden), the dedicated ZILs cannot and currently a > > "missing" ZIL device will render the pool it's included in be unable > > to import and become inaccessible. There is some work happening in > > Solaris to implement removing SLOGs from a pool, but that work hasn't > > yet found it's way in FreeBSD yet. > > > > > > - Sincerely, > > Dan Naumov > > OK final question: if/when I go about adding more disks to the system > and want redundancy, am I right in thinking that: ZFS pool of > disk1+disk2 mirror + disk3+disk4 mirror (a la RAID10) would completely > murder my write and read performance even way below the current 28mb/s > / 50mb/s I am seeing with 2 disks on that PCI controller and that in > order to have the least negative impact, I should simply have 2 > independent mirrors in 2 independent pools (with the 5th disk slot in > the NAS given to a non-redundant single disk running off the one > available SATA port on the motherboard)? > > - Sincerely, > Dan Naumov > _______________________________________________ > freebsd-fs@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-fs > To unsubscribe, send any mail to "freebsd-fs-unsubscribe@freebsd.org" > From owner-freebsd-stable@FreeBSD.ORG Mon Jan 25 09:33:54 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BD014106566C for ; Mon, 25 Jan 2010 09:33:54 +0000 (UTC) (envelope-from cyrille.lefevre-lists@laposte.net) Received: from out3.laposte.net (out4.laposte.net [193.251.214.121]) by mx1.freebsd.org (Postfix) with ESMTP id 7B2718FC22 for ; Mon, 25 Jan 2010 09:33:54 +0000 (UTC) Received: from meplus.info (localhost [127.0.0.1]) by mwinf8316.laposte.net (SMTP Server) with ESMTP id D13007000570; Mon, 25 Jan 2010 10:33:52 +0100 (CET) Received: from [192.168.1.133] (137.228.100-84.rev.gaoland.net [84.100.228.137]) by mwinf8316.laposte.net (SMTP Server) with ESMTP id 7604C700056D; Mon, 25 Jan 2010 10:33:52 +0100 (CET) X-ME-UUID: 20100125093352483.7604C700056D@mwinf8316.laposte.net Message-ID: <4B5D65BA.5060300@laposte.net> Date: Mon, 25 Jan 2010 10:34:50 +0100 From: Cyrille Lefevre Organization: ACME User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; fr; rv:1.8.1.3) Gecko/20070326 Thunderbird/2.0.0.0 Mnenhy/0.7.5.666 MIME-Version: 1.0 To: Glen Barber References: <4B5CEC53.3090402@laposte.net> <20100125025744.GA94378@orion.hsd1.pa.comcast.net> In-Reply-To: <20100125025744.GA94378@orion.hsd1.pa.comcast.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable X-me-spamlevel: not-spam X-me-spamrating: 30.400000 X-me-spamcause: OK, (-240)(0000)gggruggvucftvghtrhhoucdtuddrvdeltddrtdehucetggdotefuucfrrhhofhhilhgvmecuoehnohhnvgeqnecuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenucdlqddutddtmdenfhhrvggvsghsugefgiculddqfedtmdenfhhrvggvsghsugdgucdlqddutddmneeuuffffeigucdlqdeftddmnehgvghnvghrihgtjdculdeftddm Cc: freebsd-stable@freebsd.org Subject: Re: su password prompt ti stdout instead of /dev/tty X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 25 Jan 2010 09:33:54 -0000 Glen Barber a =E9crit : > Hi, >=20 > Cyrille Lefevre wrote:=20 >> Hi, >> >> su password prompt is displayed to *stdout* instead of */dev/tty*. >> >> # su user >> $ su root -c date > /tmp/date 2>&1 >> (nothing displayed) >> $ cat /tmp/date >> Password:su: Sorry >> $ uname -a >> FreeBSD freebsd8.my.domain 8.0-RELEASE FreeBSD 8.0-RELEASE #0: Sat Nov= =20 >> 21 15:48:17 UTC 2009=20 >> root@almeida.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC i386 >> >> I suppose this is a getpass() problem ? >> >=20 > I cannot reproduce this. In fact, >=20 > su root -c date > /tmp/date >=20 > hangs waiting for input. in fact, you exactly reproduce what I want, su hangs for input bcoz the password prompt is displayed onto stdout, but you don't know it unless you look at the output file. > orion % su root -c date > /tmp/date=20 > ^C > su: Sorry > orion % less /tmp/date=20 > Password: > orion %=20 >=20 > Also, you appear to be running an unpatched version of FreeBSD 8.0, > subject to the rtld exploit (among a few others). I'd suggest upgradin= g. don't care, it's a vmware guest for testing. thanks anyway. Regards, Cyrille Lefevre --=20 mailto:Cyrille.Lefevre-lists@laposte.net From owner-freebsd-stable@FreeBSD.ORG Mon Jan 25 09:37:14 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DC71010656C1 for ; Mon, 25 Jan 2010 09:37:14 +0000 (UTC) (envelope-from cyrille.lefevre-lists@laposte.net) Received: from out3.laposte.net (out4.laposte.net [193.251.214.121]) by mx1.freebsd.org (Postfix) with ESMTP id 97EA28FC13 for ; Mon, 25 Jan 2010 09:37:14 +0000 (UTC) Received: from meplus.info (localhost [127.0.0.1]) by mwinf8309.laposte.net (SMTP Server) with ESMTP id B97287000089; Mon, 25 Jan 2010 10:37:13 +0100 (CET) Received: from [192.168.1.133] (137.228.100-84.rev.gaoland.net [84.100.228.137]) by mwinf8309.laposte.net (SMTP Server) with ESMTP id 650C97000087; Mon, 25 Jan 2010 10:37:13 +0100 (CET) X-ME-UUID: 20100125093713413.650C97000087@mwinf8309.laposte.net Message-ID: <4B5D6682.8040509@laposte.net> Date: Mon, 25 Jan 2010 10:38:10 +0100 From: Cyrille Lefevre Organization: ACME User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; fr; rv:1.8.1.3) Gecko/20070326 Thunderbird/2.0.0.0 Mnenhy/0.7.5.666 MIME-Version: 1.0 To: jhell References: <4B5CEC53.3090402@laposte.net> <20100125025744.GA94378@orion.hsd1.pa.comcast.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable X-me-spamlevel: not-spam X-me-spamrating: 36.000000 X-me-spamcause: OK, (-100)(0000)gggruggvucftvghtrhhoucdtuddrvdeltddrtdehucetggdotefuucfrrhhofhhilhgvmecuoehnohhnvgeqnecuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmd Cc: freebsd-stable@freebsd.org, Glen Barber Subject: Re: su password prompt ti stdout instead of /dev/tty X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 25 Jan 2010 09:37:14 -0000 jhell a =E9crit : >=20 > If you mean for the program to appropriately append or overwrite to a=20 > file you should ( su user -c 'date >output 2>&1' ) instead no, I wanted the log written by the initiator, not the receiver. Regards, Cyrille Lefevre --=20 mailto:Cyrille.Lefevre-lists@laposte.net From owner-freebsd-stable@FreeBSD.ORG Mon Jan 25 09:40:41 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0E3021065672 for ; Mon, 25 Jan 2010 09:40:41 +0000 (UTC) (envelope-from cyrille.lefevre-lists@laposte.net) Received: from out1.laposte.net (out2.laposte.net [193.251.214.119]) by mx1.freebsd.org (Postfix) with ESMTP id BE20B8FC0A for ; Mon, 25 Jan 2010 09:40:40 +0000 (UTC) Received: from meplus.info (localhost [127.0.0.1]) by mwinf8208.laposte.net (SMTP Server) with ESMTP id E8B0E700050A; Mon, 25 Jan 2010 10:40:38 +0100 (CET) Received: from [192.168.1.133] (137.228.100-84.rev.gaoland.net [84.100.228.137]) by mwinf8208.laposte.net (SMTP Server) with ESMTP id 6B46270004F7; Mon, 25 Jan 2010 10:40:38 +0100 (CET) X-ME-UUID: 20100125094038442.6B46270004F7@mwinf8208.laposte.net Message-ID: <4B5D674F.9070903@laposte.net> Date: Mon, 25 Jan 2010 10:41:35 +0100 From: Cyrille Lefevre Organization: ACME User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; fr; rv:1.8.1.3) Gecko/20070326 Thunderbird/2.0.0.0 Mnenhy/0.7.5.666 MIME-Version: 1.0 To: jhell References: <4B5CEC53.3090402@laposte.net> <20100125025744.GA94378@orion.hsd1.pa.comcast.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable X-me-spamlevel: not-spam X-me-spamrating: 32.799999 X-me-spamcause: OK, (-180)(0000)gggruggvucftvghtrhhoucdtuddrvdeltddrtdehucetggdotefuucfrrhhofhhilhgvmecuoehnohhnvgeqnecuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenucdlqddutddtmdenfhhrvggvsghsugefgiculddqfedtmdenfhhrvggvsghsugdgucdlqddutddmneeuufffvdigucdlqddvtddmnehgvghnvghrihgtjdculdeftddmnehtohcutghhrghtucdlhedtmd Cc: freebsd-stable@freebsd.org, Glen Barber Subject: Re: su password prompt ti stdout instead of /dev/tty X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 25 Jan 2010 09:40:41 -0000 jhell a =E9crit : > On Sun, 24 Jan 2010 21:57, glen.j.barber@ wrote: >> Cyrille Lefevre wrote: >>> >>> su password prompt is displayed to *stdout* instead of */dev/tty*. >>> >>> # su user >>> $ su root -c date > /tmp/date 2>&1 >>> (nothing displayed) >>> $ cat /tmp/date >>> Password:su: Sorry >>> $ uname -a >>> FreeBSD freebsd8.my.domain 8.0-RELEASE FreeBSD 8.0-RELEASE #0: Sat No= v >>> 21 15:48:17 UTC 2009 >>> root@almeida.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC i386 >>> >>> I suppose this is a getpass() problem ? >>> >=20 > This is intended operation as su(1) may not always be affiliated with a= =20 > TTY. This leaves it open for a script to chat with much like what samba= =20 > does with its passwd chat mechanism. well, all other oses (netbsd, openbsd, ubuntu at least) don't do it this = way, they all password prompt to /dev/tty instead of stdout. freebsd is the only one which prompt to stdout. Regards, Cyrille Lefevre --=20 mailto:Cyrille.Lefevre-lists@laposte.net From owner-freebsd-stable@FreeBSD.ORG Mon Jan 25 09:45:42 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 83DC61065672; Mon, 25 Jan 2010 09:45:42 +0000 (UTC) (envelope-from m.seaman@infracaninophile.co.uk) Received: from smtp.infracaninophile.co.uk (gate6.infracaninophile.co.uk [IPv6:2001:8b0:151:1::1]) by mx1.freebsd.org (Postfix) with ESMTP id D88A88FC0C; Mon, 25 Jan 2010 09:45:41 +0000 (UTC) Received: from happy-idiot-talk.infracaninophile.co.uk (localhost [IPv6:::1]) (authenticated bits=0) by smtp.infracaninophile.co.uk (8.14.4/8.14.3) with ESMTP id o0P9jWjl084189; Mon, 25 Jan 2010 09:45:33 GMT (envelope-from m.seaman@infracaninophile.co.uk) X-DKIM: Sendmail DKIM Filter v2.8.3 smtp.infracaninophile.co.uk o0P9jWjl084189 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=infracaninophile.co.uk; s=201001-infracaninophile; t=1264412733; bh=6PXE7g/CMqQJaqwG5UkX03GLmxcMsXlHMEt3wgSv39E=; h=Message-ID:Date:From:MIME-Version:To:CC:Subject:References: In-Reply-To:Content-Type:Cc:Content-Type:Date:From:In-Reply-To: Message-ID:Mime-Version:References:To; z=Message-ID:=20<4B5D6833.6050200@infracaninophile.co.uk>|Date:=20M on,=2025=20Jan=202010=2009:45:23=20+0000|From:=20Matthew=20Seaman= 20|Organization:=20Infracaninophi le|User-Agent:=20Thunderbird=202.0.0.23=20(X11/20100114)|MIME-Vers ion:=201.0|To:=20Andriy=20Gapon=20|CC:=20Robert=2 0Noland=20,=20=0D=0A=20FreeBSD-STABLE=20Maili ng=20List=20,=0D=0A=20freebsd-question s@freebsd.org,=20Mark=20Andrews=20|Subject:=20Re:=2 0Loader,=20MBR=20and=20the=20boot=20process|References:=20=09<201001220 41237.GA22312@gothschlampen.com>=09=09=09<20100124092947.B72039@starfire.mn. org>=09=09<201001242057.o0OKvHUE089237@drugs.dv.isc.org>=09<1264387282. 2869.24.camel@balrog.2hip.net>=20<4B5D6207.9090105@icyb.net.ua>|In -Reply-To:=20<4B5D6207.9090105@icyb.net.ua>|X-Enigmail-Version:=20 0.95.6|Content-Type:=20multipart/signed=3B=20micalg=3Dpgp-sha256=3 B=0D=0A=20protocol=3D"application/pgp-signature"=3B=0D=0A=20bounda ry=3D"------------enig92565AFF53C5CD32CB9CF14E"; b=hgxXeTmMviZXjvOPkkUa0fSOcWaJkJvZir1MqbInf+nDOIEgC2Ex+L5m2SWbqhn/h QLqwJ7AI4zaDsf9ZRs31Zh2Q9AlKxf4MxXO4v4v+2cqhS5utk1GVFMHddNXRzEI+XZ S1DY961vLegm9QHllFitVKS07GZG4AjhvmTfR0Z4= X-Authentication-Warning: happy-idiot-talk.infracaninophile.co.uk: Host localhost [IPv6:::1] claimed to be happy-idiot-talk.infracaninophile.co.uk Message-ID: <4B5D6833.6050200@infracaninophile.co.uk> Date: Mon, 25 Jan 2010 09:45:23 +0000 From: Matthew Seaman Organization: Infracaninophile User-Agent: Thunderbird 2.0.0.23 (X11/20100114) MIME-Version: 1.0 To: Andriy Gapon References: <20100122041237.GA22312@gothschlampen.com> <20100124092947.B72039@starfire.mn.org> <201001242057.o0OKvHUE089237@drugs.dv.isc.org> <1264387282.2869.24.camel@balrog.2hip.net> <4B5D6207.9090105@icyb.net.ua> In-Reply-To: <4B5D6207.9090105@icyb.net.ua> X-Enigmail-Version: 0.95.6 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------enig92565AFF53C5CD32CB9CF14E" X-Virus-Scanned: clamav-milter 0.95.3 at happy-idiot-talk.infracaninophile.co.uk X-Virus-Status: Clean X-Spam-Status: No, score=-3.0 required=5.0 tests=AWL,BAYES_00,DKIM_SIGNED, DKIM_VERIFIED,NO_RELAYS autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on happy-idiot-talk.infracaninophile.co.uk Cc: FreeBSD-STABLE Mailing List , freebsd-questions@freebsd.org, Robert Noland Subject: Re: Loader, MBR and the boot process X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 25 Jan 2010 09:45:42 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig92565AFF53C5CD32CB9CF14E Content-Type: text/plain; charset=KOI8-U; format=flowed Content-Transfer-Encoding: quoted-printable Andriy Gapon wrote: > on 25/01/2010 04:41 Robert Noland said the following: >> On Mon, 2010-01-25 at 07:57 +1100, Mark Andrews wrote: >>> offset The offset of the start of the partition from the beginn= ing of >>> the drive in sectors, or * to have bsdlabel calculate th= e correct >>> offset to use (the end of the previous partition plus on= e, ignor- >>> ing partition `c'. For partition `c', * will be interpr= eted as >>> an offset of 0. The first partition should start at off= set 16, >>> because the first 16 sectors are reserved for metadata. >> Ok, now this has my attention... My gut feeling right now is that this= >> is a bug in geom_part_bsd. I don't understand why the label isn't >> protected. (Adding -b 16 when adding the swap partition fixes this) >> Another project to goes on my list... >> >> If anyone knows why this is done like this... please share. >=20 > I presume that this is for purely historic reasons. >=20 I believe this has been known about since 5.x days: http://www.freebsd.org/cgi/query-pr.cgi?pr=3D72812 As far as I recall, sometime around 6.1-RELEASE this should have been fixed. It certainly seems to be the case that it is harmless to have=20 a plain swap partition start at offset 0, but anything else, like encrypt= ed swap or putting a filesystem there needs the 16 sector offset. Cheers, Matthew --=20 Dr Matthew J Seaman MA, D.Phil. 7 Priory Courtyard Flat 3 PGP: http://www.infracaninophile.co.uk/pgpkey Ramsgate Kent, CT11 9PW --------------enig92565AFF53C5CD32CB9CF14E 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.14 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEAREIAAYFAktdaDwACgkQ8Mjk52CukIyGdQCfcUh+FFXVu1qBJOvJS6c+BNLD YaEAnRvo4aW3DSv+eZrW88/TMtt/848q =Q6zY -----END PGP SIGNATURE----- --------------enig92565AFF53C5CD32CB9CF14E-- From owner-freebsd-stable@FreeBSD.ORG Mon Jan 25 10:58:01 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BE76C1065692 for ; Mon, 25 Jan 2010 10:58:01 +0000 (UTC) (envelope-from torfinn.ingolfsen@broadpark.no) Received: from bgo1smout1.broadpark.no (bgo1smout1.broadpark.no [217.13.4.94]) by mx1.freebsd.org (Postfix) with ESMTP id 796948FC08 for ; Mon, 25 Jan 2010 10:58:01 +0000 (UTC) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=US-ASCII Received: from bgo1sminn1.broadpark.no ([217.13.4.93]) by bgo1smout1.broadpark.no (Sun Java(tm) System Messaging Server 6.3-3.01 (built Jul 12 2007; 32bit)) with ESMTP id <0KWS002GRUG8IQ50@bgo1smout1.broadpark.no> for freebsd-stable@freebsd.org; Mon, 25 Jan 2010 11:57:44 +0100 (CET) Received: from kg-v2.kg4.no ([80.203.92.186]) by bgo1sminn1.broadpark.no (Sun Java(tm) System Messaging Server 6.3-3.01 (built Jul 12 2007; 32bit)) with SMTP id <0KWS00JMPUG8LYK0@bgo1sminn1.broadpark.no> for freebsd-stable@freebsd.org; Mon, 25 Jan 2010 11:57:44 +0100 (CET) Date: Mon, 25 Jan 2010 11:57:44 +0100 From: Torfinn Ingolfsen To: freebsd-stable@freebsd.org Message-id: <20100125115744.04a77487.torfinn.ingolfsen@broadpark.no> In-reply-to: References: <684e57ec1001231226p447ea769q6379c1aa099b0216@mail.gmail.com> <20100124014314.GA28672@icarus.home.lan> X-Mailer: Sylpheed 2.7.1 (GTK+ 2.18.6; amd64-portbld-freebsd8.0) X-Face: "t9w2,-X@O^I`jVW\sonI3.,36KBLZE*AL[y9lL[PyFD*r_S:dIL9c[8Y>V42R0"!"yb_zN,f#%.[PYYNq; m"_0v; ~rUM2Yy!zmkh)3&U|u!=T(zyv,MHJv"nDH>OJ`t(@mil461d_B'Uo|'nMwlKe0Mv=kvV?Nh@>Hb<3s_z2jYgZhPb@?Wi^x1a~Hplz1.zH Subject: Re: Extra keys in multimedia keyboard doesn't work X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 25 Jan 2010 10:58:01 -0000 On Sun, 24 Jan 2010 23:47:46 +0000 Krzysztof Dajka wrote: > I did check my keyboard with FreeBSD 7.2 and it wasn't supported either. > Xev also didn't return anything. Di you try this: http://www.freshports.org/misc/hotkeys/ Perhaps it will work? There is also this: http://www.freshports.org/sysutils/usbhotkey/ HTH -- Torfinn From owner-freebsd-stable@FreeBSD.ORG Mon Jan 25 11:04:00 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 68E261065698 for ; Mon, 25 Jan 2010 11:04:00 +0000 (UTC) (envelope-from dalroi@solfertje.student.utwente.nl) Received: from solfertje.student.utwente.nl (solfertje.student.utwente.nl [130.89.167.40]) by mx1.freebsd.org (Postfix) with ESMTP id 1EC1D8FC14 for ; Mon, 25 Jan 2010 11:04:00 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by solfertje.student.utwente.nl (Postfix) with SMTP id 3BB128078 for ; Mon, 25 Jan 2010 12:03:59 +0100 (CET) Received: from hollewijn.internal (hollewijn.internal [10.236.150.4]) by solfertje.student.utwente.nl (Postfix) with ESMTP id 90B388033; Mon, 25 Jan 2010 12:03:55 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii From: Alban Hertroys In-Reply-To: <4B5C771C.4040605@mail.zedat.fu-berlin.de> Date: Mon, 25 Jan 2010 12:03:55 +0100 Content-Transfer-Encoding: 8bit Message-Id: <124D663A-A5EA-429E-85F0-91E479ED081E@solfertje.student.utwente.nl> References: <4B5C771C.4040605@mail.zedat.fu-berlin.de> To: O. Hartmann X-Mailer: Apple Mail (2.1077) X-DSPAM-Result: Innocent X-DSPAM-Processed: Mon Jan 25 12:03:58 2010 X-DSPAM-Confidence: 1.0000 X-DSPAM-Probability: 0.0023 X-DSPAM-Signature: 74,4b5d7a9e10605695025844 X-DSPAM-Factors: 27, In-Reply-To*mail.zedat.fu, 0.40000, To*mail.zedat.fu+berlin.de>, 0.40000, but, 0.40000, but, 0.40000, From*Alban, 0.40000, Subject*tob+be, 0.40000, Mime-Version*Message, 0.40000, don't+have, 0.40000, an, 0.40000, Date*12, 0.40000, I+look, 0.40000, 8/9+Any, 0.40000, Message-Id*85F0, 0.40000, of, 0.40000, of, 0.40000, have+that, 0.40000, Subject*8.0/9, 0.40000, digital+audio, 0.40000, some+kind, 0.40000, some+proprietary, 0.40000, Received*ESMTP, 0.40000, Received*12, 0.40000, of+signals, 0.40000, Content-Transfer-Encoding*8bit, 0.40000, Cc*freebsd+stable, 0.40000, are+supported, 0.40000, Message-Id*429E, 0.40000 Cc: freebsd-stable@freebsd.org, freebsd-questions@freebsd.org Subject: Re: PCIe audio cards: what is tob be preferred with FreeBSD 8.0/9-CURRENT? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 25 Jan 2010 11:04:00 -0000 On 24 Jan 2010, at 17:36, O. Hartmann wrote: > At this moment, I look for the Soundblaster X-Fi range of PCIe cards, but I'm not sure whether they are supported by FreeBSd 8/9. Any suggestions? I'm actually looking for a replacement for my X-Fi (I have the PCI X-Fi Gamer). The sound quality isn't great and it's only supported in Windows. I believe there's an effort going on to get a functioning driver on Linux at the moment. Besides that, the card I have got some proprietary connectors for digital audio that you need to buy some kind of dongle for that dangles outside your case. You can fit a 3.5mm optical jack in the proprietary connector, but the signal isn't SP/DIF - my receiver has no idea what to do with it. The more expensive versions probably don't have that problem, they have plenty of connections for all kinds of signals after all. Alban Hertroys -- Screwing up is the best way to attach something to the ceiling. !DSPAM:74,4b5d7a9e10605695025844! From owner-freebsd-stable@FreeBSD.ORG Mon Jan 25 11:29:25 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 45CA0106566B; Mon, 25 Jan 2010 11:29:25 +0000 (UTC) (envelope-from petefrench@ticketswitch.com) Received: from constantine.ticketswitch.com (constantine.ticketswitch.com [IPv6:2002:57e0:1d4e:1::3]) by mx1.freebsd.org (Postfix) with ESMTP id 012338FC12; Mon, 25 Jan 2010 11:29:25 +0000 (UTC) Received: from dilbert.rattatosk ([10.64.50.6] helo=dilbert.ticketswitch.com) by constantine.ticketswitch.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1NZN87-000GvC-Hy; Mon, 25 Jan 2010 11:29:15 +0000 Received: from petefrench by dilbert.ticketswitch.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1NZN87-000JtL-Gy; Mon, 25 Jan 2010 11:29:15 +0000 Date: Mon, 25 Jan 2010 11:29:15 +0000 Message-Id: To: dan.naumov@gmail.com, wonslung@gmail.com In-Reply-To: From: Pete French Cc: sub.mesa@gmail.com, freebsd-stable@freebsd.org, mav@freebsd.org, freebsd-fs@freebsd.org, bfriesen@simple.dallas.tx.us, freebsd-questions@freebsd.org Subject: Re: 8.0-RELEASE/amd64 - full ZFS install - low read and write disk performance X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jan 2010 11:29:25 -0000 > I like to use pci-x with aoc-sat2-mv8 cards or pci-e cards....that way you > get a lot more bandwidth.. I would goalong with that - I have precisely the same controller, with a pair of eSATA drives, running ZFS mirrored. But I get a nice 100 meg/second out of them if I try. My controller is, however on PCI-X, not PCI. It's a shame PCI-X appears to have gone the way of the dinosaur :-( -pete. From owner-freebsd-stable@FreeBSD.ORG Mon Jan 25 12:20:25 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 353101065692 for ; Mon, 25 Jan 2010 12:20:25 +0000 (UTC) (envelope-from ruben@verweg.com) Received: from erg.verweg.com (erg.verweg.com [IPv6:2a02:898:96::5e8e:f508]) by mx1.freebsd.org (Postfix) with ESMTP id B96928FC24 for ; Mon, 25 Jan 2010 12:20:24 +0000 (UTC) Received: from neon.fritz.box (helium.xs4all.nl [83.163.52.241]) (authenticated bits=0) by erg.verweg.com (8.14.4/8.14.3) with ESMTP id o0PCKBCq045895 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 25 Jan 2010 12:20:21 GMT (envelope-from ruben@verweg.com) X-Authentication-Warning: erg.verweg.com: Host helium.xs4all.nl [83.163.52.241] claimed to be neon.fritz.box Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Apple-Mail-2-499484329" From: Ruben van Staveren In-Reply-To: <4AFCBD9C.1030306@langille.org> Date: Mon, 25 Jan 2010 13:20:09 +0100 Content-Transfer-Encoding: 7bit Message-Id: References: <4AFCBD9C.1030306@langille.org> To: Dan Langille X-Pgp-Agent: GPGMail 1.2.3 X-Mailer: Apple Mail (2.1077) X-Spam-Status: No, score=3.1 required=5.0 tests=DATE_IN_FUTURE_06_12 autolearn=no version=3.2.5 X-Spam-Level: *** X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on erg.verweg.com X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.3 (erg.verweg.com [94.142.245.8]); Mon, 25 Jan 2010 12:20:23 +0000 (UTC) Cc: FreeBSD Stable Subject: Re: hald running 100% X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 25 Jan 2010 12:20:25 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --Apple-Mail-2-499484329 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii On 13 Nov 2009, at 2:59, Dan Langille wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > After upgrading to 8.0-PRERELEASE today, I'm seeing hald at 100% on both > my laptop and my desktop: > > > PID USERNAME THR PRI NICE SIZE RES STATE C TIME WCPU COMMAND > 1500 haldaemon 1 118 0 22944K 4904K CPU1 1 107:44 100.00% hald > > uptime was about 1:50 at this point. > > Seems to be relatively common from the posts I've seen. > Did you try to recompile the hald port ? Regards, Ruben --Apple-Mail-2-499484329 content-type: application/pgp-signature; x-mac-type=70674453; name=PGP.sig content-description: This is a digitally signed message part content-disposition: inline; filename=PGP.sig content-transfer-encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (Darwin) iEYEARECAAYFAktdjHoACgkQZ88+mcQxRw2ylwCdHpZvvY3voJh4PzQBtr2ZbeJB wOgAn2ihD29PkLETG0BFUNWcGARmrjH4 =iSmu -----END PGP SIGNATURE----- --Apple-Mail-2-499484329-- From owner-freebsd-stable@FreeBSD.ORG Mon Jan 25 13:29:35 2010 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1BD96106568B for ; Mon, 25 Jan 2010 13:29:35 +0000 (UTC) (envelope-from lars.eggert@nokia.com) Received: from mgw-mx03.nokia.com (smtp.nokia.com [192.100.122.230]) by mx1.freebsd.org (Postfix) with ESMTP id 807388FC15 for ; Mon, 25 Jan 2010 13:29:33 +0000 (UTC) Received: from mgw-mx09.nokia.com ([192.100.105.134]) by mgw-mx03.nokia.com (Switch-3.3.3/Switch-3.3.3) with ESMTP id o0PDBYF9032232 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Mon, 25 Jan 2010 15:11:36 +0200 Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-mx09.nokia.com (Switch-3.3.3/Switch-3.3.3) with ESMTP id o0PDBBak031103; Mon, 25 Jan 2010 07:11:32 -0600 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 25 Jan 2010 15:10:53 +0200 Received: from mgw-sa01.ext.nokia.com ([147.243.1.47]) by esebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Mon, 25 Jan 2010 15:10:53 +0200 Received: from mail.fit.nokia.com (esdhcp030222.research.nokia.com [172.21.30.222]) by mgw-sa01.ext.nokia.com (Switch-3.3.3/Switch-3.3.3) with ESMTP id o0PDApI6002826 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 25 Jan 2010 15:10:51 +0200 X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.95.3 at fit.nokia.com Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: multipart/signed; boundary=Apple-Mail-17-502408222; protocol="application/pkcs7-signature"; micalg=sha1 From: Lars Eggert In-Reply-To: <147432021001242047k659a26d0s44b35164920aeb74@mail.gmail.com> Date: Mon, 25 Jan 2010 14:08:53 +0100 Message-Id: References: <20091201.102925.218343479.hrs@allbsd.org> <2a41acea0912021249w1aed8e83kf89ceb1e6041edaf@mail.gmail.com> <2a41acea0912021514r2d44dd33n4c364518d7fe1703@mail.gmail.com> <20091203.182931.129751456.hrs@allbsd.org> <4B43F6EE.3010308@ucla.edu> <147432021001242047k659a26d0s44b35164920aeb74@mail.gmail.com> To: Nick Rogers X-Mailer: Apple Mail (2.1077) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.3 (mail.fit.nokia.com [0.0.0.0]); Mon, 25 Jan 2010 15:10:42 +0200 (EET) X-Spam-Status: No, score=-102.1 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00, MISSING_SUBJECT,USER_IN_WHITELIST autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on fit.nokia.com X-OriginalArrivalTime: 25 Jan 2010 13:10:53.0390 (UTC) FILETIME=[D2C4AEE0:01CA9DBF] X-Nokia-AV: Clean X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Jason Chambers , "stable@freebsd.org" , "jfvogel@gmail.com" Subject: Re: em interface slow down on 8.0R X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 25 Jan 2010 13:29:35 -0000 --Apple-Mail-17-502408222 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi, have you tried turning off TCP Segmentation Offloading (net.inet.tcp.tso = sysctl)? That fixed performance issues with some em cards for me. Lars On 2010-1-25, at 5:47, Nick Rogers wrote: > I am having similar em interface problems with some of my production > machines running older intel 2-port cards, since upgrading from = 7.2-RELEASE > to 8.0-RELEASE. The problem is basically, everything works fine, but > periodically the interface "hangs" (tcpdump shows no frames). A reboot = or an > ifconfig down followed by an ifconfig up fixes the problem for some = time. > Traffic peaks at maybe 20mbit per day and its all 802.1Q VLAN tagged = traffic > (about 10 vlan interfaces). When this happens netstat reports only = errors > and no packets on the affected interface. Media is set to autoselect. = This > is happening about 5-10x per day. >=20 > Heres relevant sysctl and ifconfig info. >=20 > dev.em.6.%desc: Intel(R) PRO/1000 Network Connection 6.9.14 > dev.em.6.%driver: em > dev.em.6.%location: slot=3D3 function=3D0 > dev.em.6.%pnpinfo: vendor=3D0x8086 device=3D0x1079 subvendor=3D0x8086 > subdevice=3D0x1179 class=3D0x020000 > dev.em.6.%parent: pci3 > dev.em.6.debug: -1 > dev.em.6.stats: -1 > dev.em.6.rx_int_delay: 0 > dev.em.6.tx_int_delay: 66 > dev.em.6.rx_abs_int_delay: 66 > dev.em.6.tx_abs_int_delay: 66 > dev.em.6.rx_processing_limit: 100 >=20 > em6: flags=3D8843 metric 0 mtu = 1500 > options=3D9b > ether 00:04:23:cd:47:82 > media: Ethernet autoselect (1000baseT ) > status: active >=20 > On Tue, Jan 5, 2010 at 6:35 PM, Jason Chambers = wrote: >=20 >> Hiroki Sato wrote: >>> Thank you! I have investigated some more details. First, I got >>> something wrong with the affected FreeBSD versions; one I tried was >>> 8.0-STABLE, not 8.0-RELEASE. So I started to try 8.0R. A summary = of >>> chips and releases I tried so far is now the following: >>>=20 >>> 7.2R 8.0R 8.0-STABLE >>> 82540EM (chip=3D0x100e8086, rev=3D0x02) OK OK too slow[1] >>> 82541PI (chip=3D0x107c8086, rev=3D0x05) OK ? OK >>=20 >>=20 >> Running 8.0R I've noticed the same problem with this card = (0x107c8086). >> Duplex and speed are manually set at full/1000. >>=20 >>=20 >> em0@pci0:3:3:0: class=3D0x020000 card=3D0x13768086 chip=3D0x107c8086 = rev=3D0x05 >> hdr=3D0x00 >> vendor =3D 'Intel Corporation' >> device =3D 'Gigabit Ethernet Controller (Copper) rev 5 = (82541PI)' >> class =3D network >> subclass =3D ethernet >>=20 >>=20 >> Regards, >>=20 >> --Jason >> _______________________________________________ >> freebsd-stable@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-stable >> To unsubscribe, send any mail to = "freebsd-stable-unsubscribe@freebsd.org" >>=20 > _______________________________________________ > 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" --Apple-Mail-17-502408222-- From owner-freebsd-stable@FreeBSD.ORG Mon Jan 25 13:51:24 2010 Return-Path: Delivered-To: freebsd-stable@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C50AE106566B for ; Mon, 25 Jan 2010 13:51:24 +0000 (UTC) (envelope-from olli@lurza.secnetix.de) Received: from lurza.secnetix.de (lurza.secnetix.de [IPv6:2a01:170:102f::2]) by mx1.freebsd.org (Postfix) with ESMTP id 51DCA8FC0C for ; Mon, 25 Jan 2010 13:51:24 +0000 (UTC) Received: from lurza.secnetix.de (localhost [127.0.0.1]) by lurza.secnetix.de (8.14.3/8.14.3) with ESMTP id o0PDp8gY020727; Mon, 25 Jan 2010 14:51:23 +0100 (CET) (envelope-from oliver.fromme@secnetix.de) Received: (from olli@localhost) by lurza.secnetix.de (8.14.3/8.14.3/Submit) id o0PDp8fe020726; Mon, 25 Jan 2010 14:51:08 +0100 (CET) (envelope-from olli) Date: Mon, 25 Jan 2010 14:51:08 +0100 (CET) Message-Id: <201001251351.o0PDp8fe020726@lurza.secnetix.de> From: Oliver Fromme To: freebsd-stable@FreeBSD.ORG In-Reply-To: <4B5B5669.9080906@quip.cz> X-Newsgroups: list.freebsd-stable User-Agent: tin/1.8.3-20070201 ("Scotasay") (UNIX) (FreeBSD/6.4-PRERELEASE-20080904 (i386)) MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.1.2 (lurza.secnetix.de [127.0.0.1]); Mon, 25 Jan 2010 14:51:23 +0100 (CET) Cc: Subject: Re: 8.0-RELEASE -> -STABLE and size of / X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: freebsd-stable@FreeBSD.ORG List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jan 2010 13:51:24 -0000 Miroslav Lachman <000.fbsd@quip.cz> wrote: > Why you are suggesting /var >= 2*RAM? Is it just for saving crash dumps > or anything else? And why so big /tmp? I am running servers with smaller > sizes for years without any problem. Me too. I usually set up a small memory disk for /tmp. I never experienced any serious problems with that. The machine I'm typing this on right now has this line in /etc/fstab: md /tmp mfs rw,nosuid,-s200m,async 0 0 Best regards Oliver -- Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün- chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd "Life is short (You need Python)" -- Bruce Eckel, ANSI C++ Comitee member, author of "Thinking in C++" and "Thinking in Java" From owner-freebsd-stable@FreeBSD.ORG Mon Jan 25 14:46:45 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B17E0106568F for ; Mon, 25 Jan 2010 14:46:45 +0000 (UTC) (envelope-from mavbsd@gmail.com) Received: from mail-fx0-f226.google.com (mail-fx0-f226.google.com [209.85.220.226]) by mx1.freebsd.org (Postfix) with ESMTP id 419268FC17 for ; Mon, 25 Jan 2010 14:46:44 +0000 (UTC) Received: by fxm26 with SMTP id 26so1086725fxm.13 for ; Mon, 25 Jan 2010 06:46:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=nir4Q9WO3Z2F+5d+vK4+7LUVE0NGLCZ27GUnPKxoDYw=; b=IV0jBI23uZ3M0L0UrTl8p/VioIGmu207bw9b1VGN5mSkYQ7ctfWQJ/N6faNPtUurSo elCuo2hrsrI1xK6mWKXDsjil6Ycp04OkGPgHFO6KP3+RMvw+CY8moCwI5Ft7gyjvXB16 6oV2Atpj9uUOny5sQ5V10Suoi+ua/KOQWIiAU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=o/LJKaj0yBuUG1EratPm85I4ozAzakxAoEnt4KovdbuOfJOYzr7ia421qcd5etPLI7 XWIdEpEMw8ik2Lyg85FiQ8aBAH0UuBMG10QoIVHOrJscIB0LOo5qvEFz0RwyAA6jOTqT eLkDpQw3CxOTZZGAkcpEFoq28Ob0nNy3/oCco= Received: by 10.223.14.140 with SMTP id g12mr6984384faa.50.1264430804150; Mon, 25 Jan 2010 06:46:44 -0800 (PST) Received: from mavbook.mavhome.dp.ua (pc.mavhome.dp.ua [212.86.226.226]) by mx.google.com with ESMTPS id 13sm2733621fxm.5.2010.01.25.06.46.42 (version=SSLv3 cipher=RC4-MD5); Mon, 25 Jan 2010 06:46:43 -0800 (PST) Sender: Alexander Motin Message-ID: <4B5DAED0.4060704@FreeBSD.org> Date: Mon, 25 Jan 2010 16:46:40 +0200 From: Alexander Motin User-Agent: Thunderbird 2.0.0.23 (X11/20091212) MIME-Version: 1.0 To: =?ISO-8859-1?Q?Kristian_Kr=E6mmer_Nielsen?= References: <1264378988.00211131.1264368602@10.7.7.3> In-Reply-To: <1264378988.00211131.1264368602@10.7.7.3> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Cc: freebsd-stable@freebsd.org Subject: Re: ata driver downgrades transfer speed for Intel ICH5 SATA150 in RELENG_8 ? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jan 2010 14:46:45 -0000 Kristian Krćmmer Nielsen wrote: > I just updated my kernel from RELEASE_8_0 to RELENG_8 and by rutine I > compare my dmesg -a output to make sure everything still works as expected. > > I notices that the ata-driver suddently downgraded the speed of my Intel > ICH5 SATS150 from SATA150 til UDMA133 - and I am not allowed to change > it manually by using atacontrol. > > Can this have something to do with the recent rewrite of ata-sata.c ? > http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/dev/ata/ata-sata.c.diff?r1=1.6.2.2;r2=1.6.2.3 > > Here is the dmesg output compared with RELEASE_8_0 to RELENG_8: > > ...cut out... > atapci1: port > 0xec00-0xec07,0xe800-0xe803,0xe400-0xe407,0xe000-0xe003,0xdc00-0xdc0f > irq 18 at device 31.2 on pci0 > ...cut out... > -ad4: 305245MB at ata2-master SATA150 > +ad4: 305245MB at ata2-master UDMA133 > ...cut out... > -ad6: 305245MB at ata3-master SATA150 > +ad6: 305245MB at ata3-master UDMA133 It is only a cosmetic difference. There is no performance degradation. The reason of this, in inability of the controller driver to get SATA connection speed from this hardware. -- Alexander Motin From owner-freebsd-stable@FreeBSD.ORG Mon Jan 25 15:28:22 2010 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 076B4106566B for ; Mon, 25 Jan 2010 15:28:22 +0000 (UTC) (envelope-from lars.eggert@nokia.com) Received: from mgw-mx09.nokia.com (smtp.nokia.com [192.100.105.134]) by mx1.freebsd.org (Postfix) with ESMTP id 77AC48FC14 for ; Mon, 25 Jan 2010 15:28:20 +0000 (UTC) Received: from vaebh106.NOE.Nokia.com (vaebh106.europe.nokia.com [10.160.244.32]) by mgw-mx09.nokia.com (Switch-3.3.3/Switch-3.3.3) with ESMTP id o0PFS34G021417; Mon, 25 Jan 2010 09:28:19 -0600 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by vaebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 25 Jan 2010 17:28:08 +0200 Received: from mgw-sa01.ext.nokia.com ([147.243.1.47]) by esebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Mon, 25 Jan 2010 17:28:08 +0200 Received: from mail.fit.nokia.com (esdhcp030222.research.nokia.com [172.21.30.222]) by mgw-sa01.ext.nokia.com (Switch-3.3.3/Switch-3.3.3) with ESMTP id o0PFS7gL027848 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 25 Jan 2010 17:28:07 +0200 X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.95.3 at fit.nokia.com Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: multipart/signed; boundary=Apple-Mail-1-506999750; protocol="application/pkcs7-signature"; micalg=sha1 From: Lars Eggert In-Reply-To: <147432021001242047k659a26d0s44b35164920aeb74@mail.gmail.com> Date: Mon, 25 Jan 2010 15:25:24 +0100 Message-Id: <95D3CB82-BC44-491D-86E4-5CB82F89C0FC@nokia.com> References: <20091201.102925.218343479.hrs@allbsd.org> <2a41acea0912021249w1aed8e83kf89ceb1e6041edaf@mail.gmail.com> <2a41acea0912021514r2d44dd33n4c364518d7fe1703@mail.gmail.com> <20091203.182931.129751456.hrs@allbsd.org> <4B43F6EE.3010308@ucla.edu> <147432021001242047k659a26d0s44b35164920aeb74@mail.gmail.com> To: Nick Rogers X-Mailer: Apple Mail (2.1077) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.3 (mail.fit.nokia.com [0.0.0.0]); Mon, 25 Jan 2010 17:28:01 +0200 (EET) X-Spam-Status: No, score=-102.1 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00, MISSING_SUBJECT,USER_IN_WHITELIST autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on fit.nokia.com X-OriginalArrivalTime: 25 Jan 2010 15:28:08.0849 (UTC) FILETIME=[FF7C0010:01CA9DD2] X-Nokia-AV: Clean X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Jason Chambers , "stable@freebsd.org" , "jfvogel@gmail.com" Subject: Re: em interface slow down on 8.0R X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 25 Jan 2010 15:28:22 -0000 --Apple-Mail-1-506999750 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi, have you tried turning off TCP Segmentation Offloading (net.inet.tcp.tso = sysctl)? That fixed performance issues with some em cards for me. Lars On 2010-1-25, at 5:47, Nick Rogers wrote: > I am having similar em interface problems with some of my production > machines running older intel 2-port cards, since upgrading from = 7.2-RELEASE > to 8.0-RELEASE. The problem is basically, everything works fine, but > periodically the interface "hangs" (tcpdump shows no frames). A reboot = or an > ifconfig down followed by an ifconfig up fixes the problem for some = time. > Traffic peaks at maybe 20mbit per day and its all 802.1Q VLAN tagged = traffic > (about 10 vlan interfaces). When this happens netstat reports only = errors > and no packets on the affected interface. Media is set to autoselect. = This > is happening about 5-10x per day. >=20 > Heres relevant sysctl and ifconfig info. >=20 > dev.em.6.%desc: Intel(R) PRO/1000 Network Connection 6.9.14 > dev.em.6.%driver: em > dev.em.6.%location: slot=3D3 function=3D0 > dev.em.6.%pnpinfo: vendor=3D0x8086 device=3D0x1079 subvendor=3D0x8086 > subdevice=3D0x1179 class=3D0x020000 > dev.em.6.%parent: pci3 > dev.em.6.debug: -1 > dev.em.6.stats: -1 > dev.em.6.rx_int_delay: 0 > dev.em.6.tx_int_delay: 66 > dev.em.6.rx_abs_int_delay: 66 > dev.em.6.tx_abs_int_delay: 66 > dev.em.6.rx_processing_limit: 100 >=20 > em6: flags=3D8843 metric 0 mtu = 1500 > options=3D9b > ether 00:04:23:cd:47:82 > media: Ethernet autoselect (1000baseT ) > status: active >=20 > On Tue, Jan 5, 2010 at 6:35 PM, Jason Chambers = wrote: >=20 >> Hiroki Sato wrote: >>> Thank you! I have investigated some more details. First, I got >>> something wrong with the affected FreeBSD versions; one I tried was >>> 8.0-STABLE, not 8.0-RELEASE. So I started to try 8.0R. A summary = of >>> chips and releases I tried so far is now the following: >>>=20 >>> 7.2R 8.0R 8.0-STABLE >>> 82540EM (chip=3D0x100e8086, rev=3D0x02) OK OK too slow[1] >>> 82541PI (chip=3D0x107c8086, rev=3D0x05) OK ? OK >>=20 >>=20 >> Running 8.0R I've noticed the same problem with this card = (0x107c8086). >> Duplex and speed are manually set at full/1000. >>=20 >>=20 >> em0@pci0:3:3:0: class=3D0x020000 card=3D0x13768086 chip=3D0x107c8086 = rev=3D0x05 >> hdr=3D0x00 >> vendor =3D 'Intel Corporation' >> device =3D 'Gigabit Ethernet Controller (Copper) rev 5 (82541PI)' >> class =3D network >> subclass =3D ethernet >>=20 >>=20 >> Regards, >>=20 >> --Jason >> _______________________________________________ >> freebsd-stable@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-stable >> To unsubscribe, send any mail to = "freebsd-stable-unsubscribe@freebsd.org" >>=20 > _______________________________________________ > 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" --Apple-Mail-1-506999750-- From owner-freebsd-stable@FreeBSD.ORG Mon Jan 25 15:56:52 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A37E3106568D for ; Mon, 25 Jan 2010 15:56:52 +0000 (UTC) (envelope-from dan@langille.org) Received: from nyi.unixathome.org (nyi.unixathome.org [64.147.113.42]) by mx1.freebsd.org (Postfix) with ESMTP id 759EF8FC23 for ; Mon, 25 Jan 2010 15:56:52 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by nyi.unixathome.org (Postfix) with ESMTP id C5F6650830; Mon, 25 Jan 2010 15:56:51 +0000 (GMT) X-Virus-Scanned: amavisd-new at unixathome.org Received: from nyi.unixathome.org ([127.0.0.1]) by localhost (nyi.unixathome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zpjwezEmKTAv; Mon, 25 Jan 2010 15:56:51 +0000 (GMT) Received: from nyi.unixathome.org (localhost [127.0.0.1]) by nyi.unixathome.org (Postfix) with ESMTP id 4DA4E50823; Mon, 25 Jan 2010 15:56:50 +0000 (GMT) Received: from 68.64.144.211 (SquirrelMail authenticated user dan) by nyi.unixathome.org with HTTP; Mon, 25 Jan 2010 10:56:50 -0500 Message-ID: <327c85b8398333978f642aa5dc2cbec4.squirrel@nyi.unixathome.org> In-Reply-To: References: <4AFCBD9C.1030306@langille.org> Date: Mon, 25 Jan 2010 10:56:50 -0500 From: "Dan Langille" To: "Ruben van Staveren" User-Agent: SquirrelMail/1.4.20-RC2 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Cc: FreeBSD Stable , Dan Langille Subject: Re: hald running 100% X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 25 Jan 2010 15:56:52 -0000 On Mon, January 25, 2010 7:20 am, Ruben van Staveren wrote: > > On 13 Nov 2009, at 2:59, Dan Langille wrote: > >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> >> After upgrading to 8.0-PRERELEASE today, I'm seeing hald at 100% on both >> my laptop and my desktop: >> >> >> PID USERNAME THR PRI NICE SIZE RES STATE C TIME WCPU COMMAND >> 1500 haldaemon 1 118 0 22944K 4904K CPU1 1 107:44 100.00% hald >> >> uptime was about 1:50 at this point. >> >> Seems to be relatively common from the posts I've seen. >> > > Did you try to recompile the hald port ? I do not recall. But that sounds familiar. -- Dan Langille -- http://langille.org/ From owner-freebsd-stable@FreeBSD.ORG Mon Jan 25 16:25:44 2010 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8B465106566C for ; Mon, 25 Jan 2010 16:25:44 +0000 (UTC) (envelope-from ncrogers@gmail.com) Received: from mail-px0-f183.google.com (mail-px0-f183.google.com [209.85.216.183]) by mx1.freebsd.org (Postfix) with ESMTP id 4D6C58FC18 for ; Mon, 25 Jan 2010 16:25:44 +0000 (UTC) Received: by pxi13 with SMTP id 13so2531166pxi.3 for ; Mon, 25 Jan 2010 08:25:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=NCLYA6lfGMUqUitlnPFNkXXBi4L265K/dG8D7JwbjCY=; b=xNdrxLW9m7/fOmR8MlyQpMfTV4xuW6rJSpKsMd9J26xy9t1ZodPe9nf4NU1Q53oksI Dh5459pQVeoLwDHlA6l4JIu1C3/bzJw5xe/3vdFm3Wp+4BYNvfjVfwGOSmQf2pdjrYXC XLKyBF1UejFjYoSMJMnEZkVMP+TCVOTAsTsUc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=jkCKL2qpgbfvrzsl9fnYZRNZ5dmgoqL6Zow+WaU0y2+tQP0HI77RSyga94QGnPaLx+ pBO+wMH0E6AleLHLKbEGjM33R68xoruDqjQoYZzJjAV2SHbTfwIMs7HA5UqJVWW28fEi 1e/M02zxUw65LuCC3fwCJ2eU8jdGXlolLofcI= MIME-Version: 1.0 Received: by 10.143.154.10 with SMTP id g10mr4666322wfo.274.1264436743709; Mon, 25 Jan 2010 08:25:43 -0800 (PST) In-Reply-To: <95D3CB82-BC44-491D-86E4-5CB82F89C0FC@nokia.com> References: <20091201.102925.218343479.hrs@allbsd.org> <2a41acea0912021249w1aed8e83kf89ceb1e6041edaf@mail.gmail.com> <2a41acea0912021514r2d44dd33n4c364518d7fe1703@mail.gmail.com> <20091203.182931.129751456.hrs@allbsd.org> <4B43F6EE.3010308@ucla.edu> <147432021001242047k659a26d0s44b35164920aeb74@mail.gmail.com> <95D3CB82-BC44-491D-86E4-5CB82F89C0FC@nokia.com> Date: Mon, 25 Jan 2010 08:25:43 -0800 Message-ID: <147432021001250825p202914a7ka5a2c1d28d96bac3@mail.gmail.com> From: Nick Rogers To: Lars Eggert Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Jason Chambers , "stable@freebsd.org" , "jfvogel@gmail.com" Subject: Re: em interface slow down on 8.0R X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 25 Jan 2010 16:25:44 -0000 I have not tried toying with any tcp sysctl. I'm not having performance problems so much as the interface just stops working entirely, which I would think has nothing to do with the TCP stack when layer 2 is not functioning? I'll give it a shot if I can. For the moment I have had to switch to a different (lower performance) network card to get things stable and I would like to be aware of a more concrete driver fix in STABLE before switching back my production machines. On Mon, Jan 25, 2010 at 6:25 AM, Lars Eggert wrote: > Hi, > > have you tried turning off TCP Segmentation Offloading (net.inet.tcp.tso > sysctl)? That fixed performance issues with some em cards for me. > > Lars > > From owner-freebsd-stable@FreeBSD.ORG Mon Jan 25 16:26:18 2010 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EDC6E106566B for ; Mon, 25 Jan 2010 16:26:18 +0000 (UTC) (envelope-from lars.eggert@nokia.com) Received: from mgw-mx06.nokia.com (smtp.nokia.com [192.100.122.233]) by mx1.freebsd.org (Postfix) with ESMTP id 5F5958FC19 for ; Mon, 25 Jan 2010 16:26:17 +0000 (UTC) Received: from vaebh105.NOE.Nokia.com (vaebh105.europe.nokia.com [10.160.244.31]) by mgw-mx06.nokia.com (Switch-3.3.3/Switch-3.3.3) with ESMTP id o0PGPuVC015271; Mon, 25 Jan 2010 18:26:16 +0200 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by vaebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 25 Jan 2010 18:26:13 +0200 Received: from mgw-sa01.ext.nokia.com ([147.243.1.47]) by esebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Mon, 25 Jan 2010 18:26:13 +0200 Received: from mail.fit.nokia.com (esdhcp030222.research.nokia.com [172.21.30.222]) by mgw-sa01.ext.nokia.com (Switch-3.3.3/Switch-3.3.3) with ESMTP id o0PGQCPe008029 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 25 Jan 2010 18:26:12 +0200 X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.95.3 at fit.nokia.com Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: multipart/signed; boundary=Apple-Mail-1-506999750; protocol="application/pkcs7-signature"; micalg=sha1 From: Lars Eggert In-Reply-To: <147432021001242047k659a26d0s44b35164920aeb74@mail.gmail.com> Date: Mon, 25 Jan 2010 15:25:24 +0100 Message-Id: <95D3CB82-BC44-491D-86E4-5CB82F89C0FC@nokia.com> References: <20091201.102925.218343479.hrs@allbsd.org> <2a41acea0912021249w1aed8e83kf89ceb1e6041edaf@mail.gmail.com> <2a41acea0912021514r2d44dd33n4c364518d7fe1703@mail.gmail.com> <20091203.182931.129751456.hrs@allbsd.org> <4B43F6EE.3010308@ucla.edu> <147432021001242047k659a26d0s44b35164920aeb74@mail.gmail.com> To: Nick Rogers X-Mailer: Apple Mail (2.1077) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.3 (mail.fit.nokia.com [0.0.0.0]); Mon, 25 Jan 2010 18:26:05 +0200 (EET) X-Spam-Status: No, score=-102.1 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00, MISSING_SUBJECT,USER_IN_WHITELIST autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on fit.nokia.com X-OriginalArrivalTime: 25 Jan 2010 16:26:13.0934 (UTC) FILETIME=[1CC1C4E0:01CA9DDB] X-Nokia-AV: Clean X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Jason Chambers , "stable@freebsd.org" , "jfvogel@gmail.com" Subject: Re: em interface slow down on 8.0R X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 25 Jan 2010 16:26:19 -0000 --Apple-Mail-1-506999750 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi, have you tried turning off TCP Segmentation Offloading (net.inet.tcp.tso = sysctl)? That fixed performance issues with some em cards for me. Lars On 2010-1-25, at 5:47, Nick Rogers wrote: > I am having similar em interface problems with some of my production > machines running older intel 2-port cards, since upgrading from = 7.2-RELEASE > to 8.0-RELEASE. The problem is basically, everything works fine, but > periodically the interface "hangs" (tcpdump shows no frames). A reboot = or an > ifconfig down followed by an ifconfig up fixes the problem for some = time. > Traffic peaks at maybe 20mbit per day and its all 802.1Q VLAN tagged = traffic > (about 10 vlan interfaces). When this happens netstat reports only = errors > and no packets on the affected interface. Media is set to autoselect. = This > is happening about 5-10x per day. >=20 > Heres relevant sysctl and ifconfig info. >=20 > dev.em.6.%desc: Intel(R) PRO/1000 Network Connection 6.9.14 > dev.em.6.%driver: em > dev.em.6.%location: slot=3D3 function=3D0 > dev.em.6.%pnpinfo: vendor=3D0x8086 device=3D0x1079 subvendor=3D0x8086 > subdevice=3D0x1179 class=3D0x020000 > dev.em.6.%parent: pci3 > dev.em.6.debug: -1 > dev.em.6.stats: -1 > dev.em.6.rx_int_delay: 0 > dev.em.6.tx_int_delay: 66 > dev.em.6.rx_abs_int_delay: 66 > dev.em.6.tx_abs_int_delay: 66 > dev.em.6.rx_processing_limit: 100 >=20 > em6: flags=3D8843 metric 0 mtu = 1500 > options=3D9b > ether 00:04:23:cd:47:82 > media: Ethernet autoselect (1000baseT ) > status: active >=20 > On Tue, Jan 5, 2010 at 6:35 PM, Jason Chambers = wrote: >=20 >> Hiroki Sato wrote: >>> Thank you! I have investigated some more details. First, I got >>> something wrong with the affected FreeBSD versions; one I tried was >>> 8.0-STABLE, not 8.0-RELEASE. So I started to try 8.0R. A summary = of >>> chips and releases I tried so far is now the following: >>>=20 >>> 7.2R 8.0R 8.0-STABLE >>> 82540EM (chip=3D0x100e8086, rev=3D0x02) OK OK too slow[1] >>> 82541PI (chip=3D0x107c8086, rev=3D0x05) OK ? OK >>=20 >>=20 >> Running 8.0R I've noticed the same problem with this card = (0x107c8086). >> Duplex and speed are manually set at full/1000. >>=20 >>=20 >> em0@pci0:3:3:0: class=3D0x020000 card=3D0x13768086 chip=3D0x107c8086 = rev=3D0x05 >> hdr=3D0x00 >> vendor =3D 'Intel Corporation' >> device =3D 'Gigabit Ethernet Controller (Copper) rev 5 (82541PI)' >> class =3D network >> subclass =3D ethernet >>=20 >>=20 >> Regards, >>=20 >> --Jason >> _______________________________________________ >> freebsd-stable@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-stable >> To unsubscribe, send any mail to = "freebsd-stable-unsubscribe@freebsd.org" >>=20 > _______________________________________________ > 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" --Apple-Mail-1-506999750-- From owner-freebsd-stable@FreeBSD.ORG Mon Jan 25 17:04:02 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 732B91065672; Mon, 25 Jan 2010 17:04:02 +0000 (UTC) (envelope-from artemb@gmail.com) Received: from mail-iw0-f199.google.com (mail-iw0-f199.google.com [209.85.223.199]) by mx1.freebsd.org (Postfix) with ESMTP id 0BF368FC12; Mon, 25 Jan 2010 17:04:01 +0000 (UTC) Received: by iwn37 with SMTP id 37so3748506iwn.30 for ; Mon, 25 Jan 2010 09:04:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to:cc :content-type; bh=Kwc/e4Cr0JlaU+TkwDYYtG0ZkN6fjBWBKotxxdJN3ng=; b=gbCe6ZursasSKl2MtrjlsnrDUM/V1yUAOzYUEtw9li2wq2Vm7ZoKce2l9wdh88q+Zl 7ybsGpcgsaa6DCgJU9fZl/0h1Gk/mcxZ+zp7IF4CQ/Zrr0OBEB6Uzr1GrpBMyu4r2oJW tSbAGjNyO/eJb/3WOQNSbc8SDAdzdIdT9JUKg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; b=dh/U8VA/Cyw3jhAfRIsFsoqDixTKgn14Sz42ZCBrHQurD9U/n+/sxNFNEZOT5IuFsC Q9E24rkBf1RFjU4IVSAU8RSx45DAMqszD/Q1rvDyy2fX3EY7kNTAp2X1KyaYXHQE0UMJ 2gT0Sc+gewrpLxVNGxN6uBSsljPlxOmBlVBSk= MIME-Version: 1.0 Sender: artemb@gmail.com Received: by 10.231.149.9 with SMTP id r9mr3885943ibv.74.1264439040810; Mon, 25 Jan 2010 09:04:00 -0800 (PST) In-Reply-To: References: Date: Mon, 25 Jan 2010 09:04:00 -0800 X-Google-Sender-Auth: 06ca1031c6b56ef4 Message-ID: From: Artem Belevich To: Pete French Content-Type: text/plain; charset=ISO-8859-1 Cc: sub.mesa@gmail.com, freebsd-stable@freebsd.org, mav@freebsd.org, dan.naumov@gmail.com, freebsd-fs@freebsd.org, wonslung@gmail.com, bfriesen@simple.dallas.tx.us, freebsd-questions@freebsd.org Subject: Re: 8.0-RELEASE/amd64 - full ZFS install - low read and write disk performance X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jan 2010 17:04:02 -0000 aoc-sat2-mv8 was somewhat slower compared to ICH9 or LSI1068 controllers when I tried it with 6 and 8 disks. I think the problem is that MV8 only does 32K per transfer and that does seem to matter when you have 8 drives hooked up to it. I don't have hard numbers, but peak throughput of MV8 with 8-disk raidz2 was noticeably lower than that of LSI1068 in the same configuration. Both LSI1068 and MV2 were on the same PCI-X bus. It could be a driver limitation. The driver for Marvel SATA controllers in NetBSD seems a bit more advanced compared to what's in FreeBSD. I wish intel would make cheap multi-port PCIe SATA card based on their AHCI controllers. --Artem On Mon, Jan 25, 2010 at 3:29 AM, Pete French wrote: >> I like to use pci-x with aoc-sat2-mv8 cards or pci-e cards....that way you >> get a lot more bandwidth.. > > I would goalong with that - I have precisely the same controller, with > a pair of eSATA drives, running ZFS mirrored. But I get a nice 100 > meg/second out of them if I try. My controller is, however on PCI-X, not > PCI. It's a shame PCI-X appears to have gone the way of the dinosaur :-( > > -pete. > _______________________________________________ > 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 Mon Jan 25 17:23:15 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 32EE81065672; Mon, 25 Jan 2010 17:23:15 +0000 (UTC) (envelope-from ohartman@zedat.fu-berlin.de) Received: from outpost1.zedat.fu-berlin.de (outpost1.zedat.fu-berlin.de [130.133.4.66]) by mx1.freebsd.org (Postfix) with ESMTP id E186D8FC12; Mon, 25 Jan 2010 17:23:14 +0000 (UTC) Received: from inpost2.zedat.fu-berlin.de ([130.133.4.69]) by outpost1.zedat.fu-berlin.de (Exim 4.69) with esmtp (envelope-from ) id <1NZSef-00042S-O4>; Mon, 25 Jan 2010 18:23:13 +0100 Received: from telesto.geoinf.fu-berlin.de ([130.133.86.198]) by inpost2.zedat.fu-berlin.de (Exim 4.69) with esmtpsa (envelope-from ) id <1NZSef-0005Ih-MP>; Mon, 25 Jan 2010 18:23:13 +0100 Message-ID: <4B5DD3D4.9020000@zedat.fu-berlin.de> Date: Mon, 25 Jan 2010 17:24:36 +0000 From: "O. Hartmann" User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.1.7) Gecko/20100122 Thunderbird/3.0.1 MIME-Version: 1.0 To: perryh@pluto.rain.com References: <4B5C771C.4040605@mail.zedat.fu-berlin.de> <4b5d1bef.QEz5a8Mvh7OFA7+l%perryh@pluto.rain.com> In-Reply-To: <4b5d1bef.QEz5a8Mvh7OFA7+l%perryh@pluto.rain.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: 130.133.86.198 Cc: ohartman@mail.zedat.fu-berlin.de, freebsd-stable@freebsd.org, freebsd-questions@freebsd.org Subject: Re: PCIe audio cards: what is tob be preferred with FreeBSD 8.0/9-CURRENT? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 25 Jan 2010 17:23:15 -0000 On 01/25/10 04:19, perryh@pluto.rain.com wrote: > "O. Hartmann" wrote: > >> At this very moment I utilise a M-Audio 5.1 PCI-audio board with >> which I'm really satisfied. My next box doesn't have PCI slots >> at all ... I look for the Soundblaster X-Fi range of PCIe cards, >> > It's possible to get an adapter that plugs into a PCIe slot and > provides a PCI slot, which might enable you to continue using > your current card. I've never actually seen one, so don't know > about the mechanics; it could turn out that it can only be used > by leaving the cover off of the box :( > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" > I gues this is he worst scenario I can imagine. I'd ike to spend some money on a new audio card adapted for PCIe, but it should have support both in FreeBSD and Windows. For mplayer/vlc and so forth my M-Audio audio quality was great. This level should be kept in FreeBSD. Regards Oliver From owner-freebsd-stable@FreeBSD.ORG Mon Jan 25 17:40:56 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6EE71106566B; Mon, 25 Jan 2010 17:40:56 +0000 (UTC) (envelope-from mavbsd@gmail.com) Received: from mail-fx0-f227.google.com (mail-fx0-f227.google.com [209.85.220.227]) by mx1.freebsd.org (Postfix) with ESMTP id A0D708FC1C; Mon, 25 Jan 2010 17:40:55 +0000 (UTC) Received: by fxm27 with SMTP id 27so1035750fxm.3 for ; Mon, 25 Jan 2010 09:40:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :x-enigmail-version:content-type:content-transfer-encoding; bh=jyVLdTkQZoMWraDkskVuVR3bPC8wn5sQeuUCWzwb9Q8=; b=S4RSwRySSyrX++8NofKAKsDgLvcnI4jg/4pWfM7m5tgiUKLN0z3C5AYaEZsBYxSzG2 LGSlNxxoVy7q7HPyvULC1PyV7/9SOKqheWIgbbdeypj1c0v7K0jqUOe9YFCWpQal+qpY 0o0rJA6OlSeI4E+iEZtwaXSOL9bi0bmVE4U1I= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:content-type :content-transfer-encoding; b=Hrb7I+C0KBOdAAeBbBOLrVO5EBykitEpMIvD0VaaTjhO/4ikrrimK1hS0Zg2P3Qusy ktWjJmtlNsV43ipa6CPbwVDpnmhsekLE0Wb4j9w/ZpODVC38IVUn2vZvossqPGedNnMm FJGyKw5xVsBsGKH3idE7LtLbullHt8cpNACN8= Received: by 10.223.16.72 with SMTP id n8mr6510981faa.26.1264441254397; Mon, 25 Jan 2010 09:40:54 -0800 (PST) Received: from mavbook.mavhome.dp.ua (pc.mavhome.dp.ua [212.86.226.226]) by mx.google.com with ESMTPS id 16sm2850502fxm.12.2010.01.25.09.40.52 (version=SSLv3 cipher=RC4-MD5); Mon, 25 Jan 2010 09:40:53 -0800 (PST) Sender: Alexander Motin Message-ID: <4B5DD7A2.4000101@FreeBSD.org> Date: Mon, 25 Jan 2010 19:40:50 +0200 From: Alexander Motin User-Agent: Thunderbird 2.0.0.23 (X11/20091212) MIME-Version: 1.0 To: Artem Belevich References: In-Reply-To: X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: sub.mesa@gmail.com, freebsd-stable@freebsd.org, Pete French , dan.naumov@gmail.com, freebsd-fs@freebsd.org, wonslung@gmail.com, bfriesen@simple.dallas.tx.us, freebsd-questions@freebsd.org Subject: Re: 8.0-RELEASE/amd64 - full ZFS install - low read and write disk performance X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jan 2010 17:40:56 -0000 Artem Belevich wrote: > aoc-sat2-mv8 was somewhat slower compared to ICH9 or LSI1068 > controllers when I tried it with 6 and 8 disks. > I think the problem is that MV8 only does 32K per transfer and that > does seem to matter when you have 8 drives hooked up to it. I don't > have hard numbers, but peak throughput of MV8 with 8-disk raidz2 was > noticeably lower than that of LSI1068 in the same configuration. Both > LSI1068 and MV2 were on the same PCI-X bus. It could be a driver > limitation. The driver for Marvel SATA controllers in NetBSD seems a > bit more advanced compared to what's in FreeBSD. I also wouldn't recommend to use Marvell 88SXx0xx controllers now. While potentially they are interesting, lack of documentation and numerous hardware bugs make existing FreeBSD driver very limited there. > I wish intel would make cheap multi-port PCIe SATA card based on their > AHCI controllers. Indeed. Intel on-board AHCI SATA controllers are fastest from all I have tested. Unluckily, they are not producing discrete versions. :( Now, if discrete solution is really needed, I would still recommend SiI3124, but with proper PCI-X 64bit/133MHz bus or built-in PCIe x8 bridge. They are fast and have good new siis driver. > On Mon, Jan 25, 2010 at 3:29 AM, Pete French > wrote: >>> I like to use pci-x with aoc-sat2-mv8 cards or pci-e cards....that way you >>> get a lot more bandwidth.. >> I would goalong with that - I have precisely the same controller, with >> a pair of eSATA drives, running ZFS mirrored. But I get a nice 100 >> meg/second out of them if I try. My controller is, however on PCI-X, not >> PCI. It's a shame PCI-X appears to have gone the way of the dinosaur :-( -- Alexander Motin From owner-freebsd-stable@FreeBSD.ORG Mon Jan 25 18:03:00 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A5B521065679; Mon, 25 Jan 2010 18:03:00 +0000 (UTC) (envelope-from dan.naumov@gmail.com) Received: from mail-yw0-f197.google.com (mail-yw0-f197.google.com [209.85.211.197]) by mx1.freebsd.org (Postfix) with ESMTP id 251B78FC0C; Mon, 25 Jan 2010 18:02:59 +0000 (UTC) Received: by ywh35 with SMTP id 35so2926521ywh.7 for ; Mon, 25 Jan 2010 10:02:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=nZtf3l4PCbMY400oXJwuloFDENM2ZdBfDGqzTYpxpm8=; b=rYZu0wav4efSK1MEUAd3tPW8fI9bFybJCPS2kISQ1m6hRinY1X8wDU7FxgZbA6YeST dNftvcTu0aBtzeH+S1gmiByDcOY+dn9iRcmcH/ZzPw1f+PBWIaT2WpiHgQhem50QuRdQ z3TshhsoiainWblREgVwBnixzWm4q1sSpQYDQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=CRhUR5DCk0bSfYEo88AX2XIqcuJoVI/kjNBON5laZmfQdCz3PPexzXqPcIB4YJXypa MeY/Vjp4SuPfjD4LhlBjxvBytIfLOkzYWClMpThWU5h4eTqClDnR/7WT0n+LPSL4Lsw6 BPhybnwnYJTCzKZTopDB8htoq0o1pl7psznUw= MIME-Version: 1.0 Received: by 10.100.200.9 with SMTP id x9mr8457030anf.76.1264442578767; Mon, 25 Jan 2010 10:02:58 -0800 (PST) In-Reply-To: <4B5DD7A2.4000101@FreeBSD.org> References: <4B5DD7A2.4000101@FreeBSD.org> Date: Mon, 25 Jan 2010 20:02:58 +0200 Message-ID: From: Dan Naumov To: Alexander Motin Content-Type: text/plain; charset=ISO-8859-1 Cc: sub.mesa@gmail.com, freebsd-stable@freebsd.org, Pete French , freebsd-questions@freebsd.org, freebsd-fs@freebsd.org, wonslung@gmail.com, bfriesen@simple.dallas.tx.us, Artem Belevich Subject: Re: 8.0-RELEASE/amd64 - full ZFS install - low read and write disk performance X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jan 2010 18:03:00 -0000 On Mon, Jan 25, 2010 at 7:40 PM, Alexander Motin wrote: > Artem Belevich wrote: >> aoc-sat2-mv8 was somewhat slower compared to ICH9 or LSI1068 >> controllers when I tried it with 6 and 8 disks. >> I think the problem is that MV8 only does 32K per transfer and that >> does seem to matter when you have 8 drives hooked up to it. I don't >> have hard numbers, but peak throughput of MV8 with 8-disk raidz2 was >> noticeably lower than that of LSI1068 in the same configuration. Both >> LSI1068 and MV2 were on the same PCI-X bus. It could be a driver >> limitation. The driver for Marvel SATA controllers in NetBSD seems a >> bit more advanced compared to what's in FreeBSD. > > I also wouldn't recommend to use Marvell 88SXx0xx controllers now. While > potentially they are interesting, lack of documentation and numerous > hardware bugs make existing FreeBSD driver very limited there. > >> I wish intel would make cheap multi-port PCIe SATA card based on their >> AHCI controllers. > > Indeed. Intel on-board AHCI SATA controllers are fastest from all I have > tested. Unluckily, they are not producing discrete versions. :( > > Now, if discrete solution is really needed, I would still recommend > SiI3124, but with proper PCI-X 64bit/133MHz bus or built-in PCIe x8 > bridge. They are fast and have good new siis driver. > >> On Mon, Jan 25, 2010 at 3:29 AM, Pete French >> wrote: >>>> I like to use pci-x with aoc-sat2-mv8 cards or pci-e cards....that way you >>>> get a lot more bandwidth.. >>> I would goalong with that - I have precisely the same controller, with >>> a pair of eSATA drives, running ZFS mirrored. But I get a nice 100 >>> meg/second out of them if I try. My controller is, however on PCI-X, not >>> PCI. It's a shame PCI-X appears to have gone the way of the dinosaur :-( > > -- > Alexander Motin Alexander, since you seem to be experienced in the area, what do you think of these 2 for use in a FreeBSD8 ZFS NAS: http://www.supermicro.com/products/motherboard/ATOM/ICH9/X7SPA.cfm?typ=H http://www.supermicro.com/products/motherboard/ATOM/ICH9/X7SPA.cfm?typ=H&IPMI=Y - Sincerely, Dan Naumov From owner-freebsd-stable@FreeBSD.ORG Mon Jan 25 18:11:15 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F07041065670 for ; Mon, 25 Jan 2010 18:11:14 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from qmta01.westchester.pa.mail.comcast.net (qmta01.westchester.pa.mail.comcast.net [76.96.62.16]) by mx1.freebsd.org (Postfix) with ESMTP id 97B238FC18 for ; Mon, 25 Jan 2010 18:11:14 +0000 (UTC) Received: from omta08.westchester.pa.mail.comcast.net ([76.96.62.12]) by qmta01.westchester.pa.mail.comcast.net with comcast id Znqj1d0020Fqzac51uBEXG; Mon, 25 Jan 2010 18:11:14 +0000 Received: from koitsu.dyndns.org ([98.248.46.159]) by omta08.westchester.pa.mail.comcast.net with comcast id ZuBD1d00Y3S48mS3UuBETT; Mon, 25 Jan 2010 18:11:14 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id 616E11E3033; Mon, 25 Jan 2010 10:11:12 -0800 (PST) Date: Mon, 25 Jan 2010 10:11:12 -0800 From: Jeremy Chadwick To: freebsd-stable@freebsd.org Message-ID: <20100125181112.GA20163@icarus.home.lan> References: <4B5DD7A2.4000101@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) Subject: Re: 8.0-RELEASE/amd64 - full ZFS install - low read and write disk performance X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jan 2010 18:11:15 -0000 On Mon, Jan 25, 2010 at 08:02:58PM +0200, Dan Naumov wrote: > On Mon, Jan 25, 2010 at 7:40 PM, Alexander Motin wrote: > > Artem Belevich wrote: > >> aoc-sat2-mv8 was somewhat slower compared to ICH9 or LSI1068 > >> controllers when I tried it with 6 and 8 disks. > >> I think the problem is that MV8 only does 32K per transfer and that > >> does seem to matter when you have 8 drives hooked up to it. I don't > >> have hard numbers, but peak throughput of MV8 with 8-disk raidz2 was > >> noticeably lower than that of LSI1068 in the same configuration. Both > >> LSI1068 and MV2 were on the same PCI-X bus. It could be a driver > >> limitation. The driver for Marvel SATA controllers in NetBSD seems a > >> bit more advanced compared to what's in FreeBSD. > > > > I also wouldn't recommend to use Marvell 88SXx0xx controllers now. While > > potentially they are interesting, lack of documentation and numerous > > hardware bugs make existing FreeBSD driver very limited there. > > > >> I wish intel would make cheap multi-port PCIe SATA card based on their > >> AHCI controllers. > > > > Indeed. Intel on-board AHCI SATA controllers are fastest from all I have > > tested. Unluckily, they are not producing discrete versions. :( > > > > Now, if discrete solution is really needed, I would still recommend > > SiI3124, but with proper PCI-X 64bit/133MHz bus or built-in PCIe x8 > > bridge. They are fast and have good new siis driver. > > > >> On Mon, Jan 25, 2010 at 3:29 AM, Pete French > >> wrote: > >>>> I like to use pci-x with aoc-sat2-mv8 cards or pci-e cards....that way you > >>>> get a lot more bandwidth.. > >>> I would goalong with that - I have precisely the same controller, with > >>> a pair of eSATA drives, running ZFS mirrored. But I get a nice 100 > >>> meg/second out of them if I try. My controller is, however on PCI-X, not > >>> PCI. It's a shame PCI-X appears to have gone the way of the dinosaur :-( > > > > -- > > Alexander Motin > > Alexander, since you seem to be experienced in the area, what do you > think of these 2 for use in a FreeBSD8 ZFS NAS: > > http://www.supermicro.com/products/motherboard/ATOM/ICH9/X7SPA.cfm?typ=H > http://www.supermicro.com/products/motherboard/ATOM/ICH9/X7SPA.cfm?typ=H&IPMI=Y Any of Supermicro's hardware with an ICH9 will be decent -- but you should remember that there's still a good portion of the I/O transactions which are CPU-bound. The Atom CPU isn't exactly an extensive workhorse. If/once you get one, let me know so I can steal you as a beta tester for getting X7SPA hardware monitoring (fans, external CPU temps, voltages) working in bsdhwmon. :-) -- | Jeremy Chadwick jdc@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Mon Jan 25 18:23:03 2010 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1BCA9106568F for ; Mon, 25 Jan 2010 18:23:03 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from mail-qy0-f174.google.com (mail-qy0-f174.google.com [209.85.221.174]) by mx1.freebsd.org (Postfix) with ESMTP id BAB878FC13 for ; Mon, 25 Jan 2010 18:23:01 +0000 (UTC) Received: by qyk4 with SMTP id 4so357919qyk.7 for ; Mon, 25 Jan 2010 10:23:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:received:from:date:to:cc :subject:message-id:reply-to:references:mime-version:content-type :content-disposition:in-reply-to:user-agent; bh=13hu/jpJS3fIwDhI4QTwf2octCWooOFB4Mqrbv+bD2s=; b=v+LbhIbey6pXfW/CSme+1L1/3LrBHEWuP9Zvqyfq6gRoPrWb2dfpjrd+xReIzDFOlN EjQIeUnB1KFbLGO9dGM4LIXcAHpc7VgxiUKhXCYKVhlvXnyo3fcCGw27zjzhGoQnFmMB PL8WzAgxeVJWjFoVs/Sb6hr22I3aZz8l6MshA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:date:to:cc:subject:message-id:reply-to:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; b=Qzxb6lz/cvwkCovVUHLyCjZa9o4+vkk+5C4hsrt2YLAFgG89x2ELMjJ644pd6MEm+2 KiePK7Ev1xbZBrM6CMtoIPgZrWoVNX6Mw1j+mjIVXI3O1n/qtVdM/TcPm69tErotohqu 5CyrkS6BhltCwlSAL7uccboxCk8CG8pdvgrQk= Received: by 10.224.55.71 with SMTP id t7mr4321305qag.256.1264443780641; Mon, 25 Jan 2010 10:23:00 -0800 (PST) Received: from pyunyh@gmail.com ([174.35.1.224]) by mx.google.com with ESMTPS id 20sm3229823qyk.1.2010.01.25.10.22.57 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 25 Jan 2010 10:22:59 -0800 (PST) Received: by pyunyh@gmail.com (sSMTP sendmail emulation); Mon, 25 Jan 2010 10:22:57 -0800 From: Pyun YongHyeon Date: Mon, 25 Jan 2010 10:22:57 -0800 To: Nick Rogers Message-ID: <20100125182257.GG1187@michelle.cdnetworks.com> References: <20091201.102925.218343479.hrs@allbsd.org> <2a41acea0912021249w1aed8e83kf89ceb1e6041edaf@mail.gmail.com> <2a41acea0912021514r2d44dd33n4c364518d7fe1703@mail.gmail.com> <20091203.182931.129751456.hrs@allbsd.org> <4B43F6EE.3010308@ucla.edu> <147432021001242047k659a26d0s44b35164920aeb74@mail.gmail.com> <95D3CB82-BC44-491D-86E4-5CB82F89C0FC@nokia.com> <147432021001250825p202914a7ka5a2c1d28d96bac3@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <147432021001250825p202914a7ka5a2c1d28d96bac3@mail.gmail.com> User-Agent: Mutt/1.4.2.3i Cc: Jason Chambers , "stable@freebsd.org" , "jfvogel@gmail.com" , Lars Eggert Subject: Re: em interface slow down on 8.0R 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: Mon, 25 Jan 2010 18:23:03 -0000 On Mon, Jan 25, 2010 at 08:25:43AM -0800, Nick Rogers wrote: > I have not tried toying with any tcp sysctl. I'm not having performance > problems so much as the interface just stops working entirely, which I would > think has nothing to do with the TCP stack when layer 2 is not functioning? > I'm not sure you're seeing a checksum offload bug of em(4) but the bug is easily reproducible in VLAN environments. If the issue is gone when you disable TX checksum offloading, see kern/141843 for for more detailed information as well as fix. > I'll give it a shot if I can. For the moment I have had to switch to a > different (lower performance) network card to get things stable and I would > like to be aware of a more concrete driver fix in STABLE before switching > back my production machines. > > On Mon, Jan 25, 2010 at 6:25 AM, Lars Eggert wrote: > > > Hi, > > > > have you tried turning off TCP Segmentation Offloading (net.inet.tcp.tso > > sysctl)? That fixed performance issues with some em cards for me. > > > > Lars > > > > From owner-freebsd-stable@FreeBSD.ORG Mon Jan 25 18:32:39 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 93530106568D; Mon, 25 Jan 2010 18:32:39 +0000 (UTC) (envelope-from mavbsd@gmail.com) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.154]) by mx1.freebsd.org (Postfix) with ESMTP id C24748FC1C; Mon, 25 Jan 2010 18:32:38 +0000 (UTC) Received: by fg-out-1718.google.com with SMTP id e12so305433fga.13 for ; Mon, 25 Jan 2010 10:32:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :x-enigmail-version:content-type:content-transfer-encoding; bh=x52Et8PK7t/Kk68XZ2LAGn4xrdE0aigYg/9K5/J6bTY=; b=QCzegvUd6v1jeoLJErwP7BrHyd/3FD3AxHaR/ptUe5za64cJZCnqsJjBIaZtW82beX 8VymcaNCSpoXZVIBweUkERirdkgD7dYQuceyZLTT2bq7M9lbOqdJJwarkrZIx+Gqxnhg 3CcinNPcFB1DKCkwXU57BSMTcHEiA+8bXSzTg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:content-type :content-transfer-encoding; b=HG7WH0gRwWw9v2f9nAeNpDlXNCmbWhJUjP4maw0fyy97CX9NTBdAJO7NvOpHqdHYUN 1rFH/HLIHYgX4qBgRKjK3J4taZlGwJyvfx9O3SYRD017mG/xPDnhyBTCauk06Ec4IrvT UVQ1WeV9fGbWGNobkbbRwv8PIVwZAMjWboxrI= Received: by 10.87.65.9 with SMTP id s9mr11295928fgk.48.1264444357606; Mon, 25 Jan 2010 10:32:37 -0800 (PST) Received: from mavbook.mavhome.dp.ua (pc.mavhome.dp.ua [212.86.226.226]) by mx.google.com with ESMTPS id 14sm2873540fxm.3.2010.01.25.10.32.35 (version=SSLv3 cipher=RC4-MD5); Mon, 25 Jan 2010 10:32:36 -0800 (PST) Sender: Alexander Motin Message-ID: <4B5DE3C1.4060508@FreeBSD.org> Date: Mon, 25 Jan 2010 20:32:33 +0200 From: Alexander Motin User-Agent: Thunderbird 2.0.0.23 (X11/20091212) MIME-Version: 1.0 To: Dan Naumov References: <4B5DD7A2.4000101@FreeBSD.org> In-Reply-To: X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: sub.mesa@gmail.com, freebsd-stable@freebsd.org, Pete French , freebsd-questions@freebsd.org, freebsd-fs@freebsd.org, wonslung@gmail.com, bfriesen@simple.dallas.tx.us, Artem Belevich Subject: Re: 8.0-RELEASE/amd64 - full ZFS install - low read and write disk performance X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jan 2010 18:32:39 -0000 Dan Naumov wrote: > Alexander, since you seem to be experienced in the area, what do you > think of these 2 for use in a FreeBSD8 ZFS NAS: > > http://www.supermicro.com/products/motherboard/ATOM/ICH9/X7SPA.cfm?typ=H > http://www.supermicro.com/products/motherboard/ATOM/ICH9/X7SPA.cfm?typ=H&IPMI=Y Unluckily I haven't yet touched Atom family close yet, so I can't say about it's performance. But higher desktop level (even bit old) ICH9R chipset there is IMHO a good option. It is MUCH better then ICH7, often used with previous Atoms. If I had nice small Mini-ITX case with 6 drive bays, I would definitely look for some board like that to build home storage. -- Alexander Motin From owner-freebsd-stable@FreeBSD.ORG Mon Jan 25 18:38:29 2010 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4BD751065679 for ; Mon, 25 Jan 2010 18:38:29 +0000 (UTC) (envelope-from ncrogers@gmail.com) Received: from mail-px0-f183.google.com (mail-px0-f183.google.com [209.85.216.183]) by mx1.freebsd.org (Postfix) with ESMTP id 1A0258FC24 for ; Mon, 25 Jan 2010 18:38:28 +0000 (UTC) Received: by pxi13 with SMTP id 13so2624750pxi.3 for ; Mon, 25 Jan 2010 10:38:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=xcm4b38HRp1VUnTaTxGxl+D1sh7zpfCtFq1IGluRoAg=; b=QSPEv6aRlkHE1zd9ewVIWbREBCwqODNRkglLK2+L+GCV2OssDTegeczrvk7z3ULUmW J3ji4JVWBTLIlAFikSGYIrU8rjcnrGe/u+2S3DnxPLkByI+FwQW4W/iRc6lzrZrWL7/n pmd9RTVqTSX50WQ79zh5IYo0YZQIzWFe4ucxY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=eAYIKPxcpXiloq5m5IGQkhbGHkn/oyUXEPUWXEc7yt9nIY6zKOsH4q1z5Mad++r3qF gRfiYDUWIMRVE5uFstoajc7R0PGHB+qdwXB9QJF+zoTrjwcl9YCv/T3LbIq7aGyfarEc 0AoJNGXV8qdxa7rFOgOObODx79Tv9mpJ0X0NY= MIME-Version: 1.0 Received: by 10.142.56.13 with SMTP id e13mr4752367wfa.119.1264444708551; Mon, 25 Jan 2010 10:38:28 -0800 (PST) In-Reply-To: <20100125182257.GG1187@michelle.cdnetworks.com> References: <20091201.102925.218343479.hrs@allbsd.org> <2a41acea0912021249w1aed8e83kf89ceb1e6041edaf@mail.gmail.com> <2a41acea0912021514r2d44dd33n4c364518d7fe1703@mail.gmail.com> <20091203.182931.129751456.hrs@allbsd.org> <4B43F6EE.3010308@ucla.edu> <147432021001242047k659a26d0s44b35164920aeb74@mail.gmail.com> <95D3CB82-BC44-491D-86E4-5CB82F89C0FC@nokia.com> <147432021001250825p202914a7ka5a2c1d28d96bac3@mail.gmail.com> <20100125182257.GG1187@michelle.cdnetworks.com> Date: Mon, 25 Jan 2010 10:38:28 -0800 Message-ID: <147432021001251038r69393ab3m1a797e58f9fa905a@mail.gmail.com> From: Nick Rogers To: pyunyh@gmail.com Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Jason Chambers , "stable@freebsd.org" , "jfvogel@gmail.com" , Lars Eggert Subject: Re: em interface slow down on 8.0R X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 25 Jan 2010 18:38:29 -0000 On Mon, Jan 25, 2010 at 10:22 AM, Pyun YongHyeon wrote: > On Mon, Jan 25, 2010 at 08:25:43AM -0800, Nick Rogers wrote: > > I have not tried toying with any tcp sysctl. I'm not having performance > > problems so much as the interface just stops working entirely, which I > would > > think has nothing to do with the TCP stack when layer 2 is not > functioning? > > > > I'm not sure you're seeing a checksum offload bug of em(4) but the > bug is easily reproducible in VLAN environments. If the issue is > gone when you disable TX checksum offloading, see kern/141843 for > for more detailed information as well as fix. > Good to know, but I am having a similar problem on another em(4) interface that has no VLAN interfaces. > > > I'll give it a shot if I can. For the moment I have had to switch to a > > different (lower performance) network card to get things stable and I > would > > like to be aware of a more concrete driver fix in STABLE before switching > > back my production machines. > > > > On Mon, Jan 25, 2010 at 6:25 AM, Lars Eggert > wrote: > > > > > Hi, > > > > > > have you tried turning off TCP Segmentation Offloading > (net.inet.tcp.tso > > > sysctl)? That fixed performance issues with some em cards for me. > > > > > > Lars > > > > > > > From owner-freebsd-stable@FreeBSD.ORG Mon Jan 25 18:39:05 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6CB5E10656EE; Mon, 25 Jan 2010 18:39:05 +0000 (UTC) (envelope-from dan.naumov@gmail.com) Received: from mail-yx0-f171.google.com (mail-yx0-f171.google.com [209.85.210.171]) by mx1.freebsd.org (Postfix) with ESMTP id 989868FC1F; Mon, 25 Jan 2010 18:39:04 +0000 (UTC) Received: by yxe1 with SMTP id 1so3074706yxe.3 for ; Mon, 25 Jan 2010 10:39:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=QCTb72G72iYvVessua3UeOR1nv/wXzNbeFrePJ64fAM=; b=j5ZN1Xhf1AGy965Hcf1bq4lg8Cui34jMifLHy3BzxYGT5HnXA5vKOzuLsy7XGP7KWX NkFDH1GBU+PqJNvXms1E/YjkFGskS3BCnQqf1E2wAjcdBdRur3cdSReZ9GHZJWlL8A2u t3F4qp/Whbofiqqf91BT+qFtmMRo57SQEWscM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=TeP6Pq0aiLvuPulbRUWW0eRnyII7jmtG66WAcj2IWxCsgXlgHNlfKh+uQMeLRvtfhP cawR3OGk48NAe+q0cDWksQSJ6U1/WkZMzP5Ko9LyNVuwhw4wePqsyN9iXYX4kaQCba0D qZX3VwMfc9/WrYNT2Rl6BDpphjU79qsyJ3CHM= MIME-Version: 1.0 Received: by 10.100.220.13 with SMTP id s13mr5484672ang.101.1264444741488; Mon, 25 Jan 2010 10:39:01 -0800 (PST) In-Reply-To: <4B5DE3C1.4060508@FreeBSD.org> References: <4B5DD7A2.4000101@FreeBSD.org> <4B5DE3C1.4060508@FreeBSD.org> Date: Mon, 25 Jan 2010 20:39:01 +0200 Message-ID: From: Dan Naumov To: Alexander Motin Content-Type: text/plain; charset=ISO-8859-1 Cc: sub.mesa@gmail.com, freebsd-stable@freebsd.org, Pete French , freebsd-questions@freebsd.org, freebsd-fs@freebsd.org, wonslung@gmail.com, bfriesen@simple.dallas.tx.us, Artem Belevich Subject: Re: 8.0-RELEASE/amd64 - full ZFS install - low read and write disk performance X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jan 2010 18:39:05 -0000 On Mon, Jan 25, 2010 at 8:32 PM, Alexander Motin wrote: > Dan Naumov wrote: >> Alexander, since you seem to be experienced in the area, what do you >> think of these 2 for use in a FreeBSD8 ZFS NAS: >> >> http://www.supermicro.com/products/motherboard/ATOM/ICH9/X7SPA.cfm?typ=H >> http://www.supermicro.com/products/motherboard/ATOM/ICH9/X7SPA.cfm?typ=H&IPMI=Y > > Unluckily I haven't yet touched Atom family close yet, so I can't say > about it's performance. But higher desktop level (even bit old) ICH9R > chipset there is IMHO a good option. It is MUCH better then ICH7, often > used with previous Atoms. If I had nice small Mini-ITX case with 6 drive > bays, I would definitely look for some board like that to build home > storage. > > -- > Alexander Motin CPU-performance-wise, I am not really worried. The current system is an Atom 330 and even that is a bit overkill for what I do with it and from what I am seeing, the new Atom D510 used on those boards is a tiny bit faster. What I want and care about for this system are reliability, stability, low power use, quietness and fast disk read/write speeds. I've been hearing some praise of ICH9R and 6 native SATA ports should be enough for my needs. AFAIK, the Intel 82574L network cards included on those are also very well supported? - Sincerely, Dan Naumov From owner-freebsd-stable@FreeBSD.ORG Mon Jan 25 18:49:49 2010 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C958C1065693 for ; Mon, 25 Jan 2010 18:49:49 +0000 (UTC) (envelope-from lars.eggert@nokia.com) Received: from mgw-mx06.nokia.com (smtp.nokia.com [192.100.122.233]) by mx1.freebsd.org (Postfix) with ESMTP id 3D3F38FC0C for ; Mon, 25 Jan 2010 18:49:48 +0000 (UTC) Received: from vaebh105.NOE.Nokia.com (vaebh105.europe.nokia.com [10.160.244.31]) by mgw-mx06.nokia.com (Switch-3.3.3/Switch-3.3.3) with ESMTP id o0PInj8B032305; Mon, 25 Jan 2010 20:49:46 +0200 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by vaebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 25 Jan 2010 20:49:45 +0200 Received: from mgw-sa02.ext.nokia.com ([147.243.1.48]) by esebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Mon, 25 Jan 2010 20:49:45 +0200 Received: from mail.fit.nokia.com (esdhcp030222.research.nokia.com [172.21.30.222]) by mgw-sa02.ext.nokia.com (Switch-3.3.3/Switch-3.3.3) with ESMTP id o0PInhcU005264 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 25 Jan 2010 20:49:44 +0200 X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.95.3 at fit.nokia.com Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: multipart/signed; boundary=Apple-Mail-16-522846224; protocol="application/pkcs7-signature"; micalg=sha1 From: Lars Eggert In-Reply-To: <147432021001251038r69393ab3m1a797e58f9fa905a@mail.gmail.com> Date: Mon, 25 Jan 2010 19:49:31 +0100 Message-Id: <02307620-ECDC-4E8B-A5B1-FF8491E226C4@nokia.com> References: <20091201.102925.218343479.hrs@allbsd.org> <2a41acea0912021249w1aed8e83kf89ceb1e6041edaf@mail.gmail.com> <2a41acea0912021514r2d44dd33n4c364518d7fe1703@mail.gmail.com> <20091203.182931.129751456.hrs@allbsd.org> <4B43F6EE.3010308@ucla.edu> <147432021001242047k659a26d0s44b35164920aeb74@mail.gmail.com> <95D3CB82-BC44-491D-86E4-5CB82F89C0FC@nokia.com> <147432021001250825p202914a7ka5a2c1d28d96bac3@mail.gmail.com> <20100125182257.GG1187@michelle.cdnetworks.com> <147432021001251038r69393ab3m1a797e58f9fa905a@mail.gmail.com> To: Nick Rogers X-Mailer: Apple Mail (2.1077) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.3 (mail.fit.nokia.com [0.0.0.0]); Mon, 25 Jan 2010 20:49:37 +0200 (EET) X-Spam-Status: No, score=-102.2 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00, MISSING_SUBJECT,USER_IN_WHITELIST autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on fit.nokia.com X-OriginalArrivalTime: 25 Jan 2010 18:49:45.0833 (UTC) FILETIME=[29D94590:01CA9DEF] X-Nokia-AV: Clean X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: "pyunyh@gmail.com" , Jason Chambers , "stable@freebsd.org" , "jfvogel@gmail.com" Subject: Re: em interface slow down on 8.0R X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 25 Jan 2010 18:49:49 -0000 --Apple-Mail-16-522846224 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi, On 2010-1-25, at 19:38, Nick Rogers wrote: >> On Mon, Jan 25, 2010 at 10:22 AM, Pyun YongHyeon = wrote: >> I'm not sure you're seeing a checksum offload bug of em(4) but the >> bug is easily reproducible in VLAN environments. If the issue is >> gone when you disable TX checksum offloading, see kern/141843 for >> for more detailed information as well as fix. >>=20 > Good to know, but I am having a similar problem on another em(4) = interface that has no VLAN interfaces.=20 FYI, I also have these issues without using VLANs, and turning off TSO = fixed them. Lars= --Apple-Mail-16-522846224-- From owner-freebsd-stable@FreeBSD.ORG Mon Jan 25 18:53:41 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E35031065693 for ; Mon, 25 Jan 2010 18:53:41 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from qmta15.emeryville.ca.mail.comcast.net (qmta15.emeryville.ca.mail.comcast.net [76.96.27.228]) by mx1.freebsd.org (Postfix) with ESMTP id C6B678FC22 for ; Mon, 25 Jan 2010 18:53:41 +0000 (UTC) Received: from omta16.emeryville.ca.mail.comcast.net ([76.96.30.72]) by qmta15.emeryville.ca.mail.comcast.net with comcast id ZuH81d00F1ZMdJ4AFutiwR; Mon, 25 Jan 2010 18:53:42 +0000 Received: from koitsu.dyndns.org ([98.248.46.159]) by omta16.emeryville.ca.mail.comcast.net with comcast id ZuuV1d0023S48mS8cuucZr; Mon, 25 Jan 2010 18:54:40 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id 296941E3033; Mon, 25 Jan 2010 10:53:24 -0800 (PST) Date: Mon, 25 Jan 2010 10:53:24 -0800 From: Jeremy Chadwick To: freebsd-stable@freebsd.org Message-ID: <20100125185324.GA21007@icarus.home.lan> References: <4B5DD7A2.4000101@FreeBSD.org> <4B5DE3C1.4060508@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) Subject: Re: 8.0-RELEASE/amd64 - full ZFS install - low read and write disk performance X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jan 2010 18:53:42 -0000 On Mon, Jan 25, 2010 at 08:39:01PM +0200, Dan Naumov wrote: > On Mon, Jan 25, 2010 at 8:32 PM, Alexander Motin wrote: > > Dan Naumov wrote: > >> Alexander, since you seem to be experienced in the area, what do you > >> think of these 2 for use in a FreeBSD8 ZFS NAS: > >> > >> http://www.supermicro.com/products/motherboard/ATOM/ICH9/X7SPA.cfm?typ=H > >> http://www.supermicro.com/products/motherboard/ATOM/ICH9/X7SPA.cfm?typ=H&IPMI=Y > > > > Unluckily I haven't yet touched Atom family close yet, so I can't say > > about it's performance. But higher desktop level (even bit old) ICH9R > > chipset there is IMHO a good option. It is MUCH better then ICH7, often > > used with previous Atoms. If I had nice small Mini-ITX case with 6 drive > > bays, I would definitely look for some board like that to build home > > storage. > > > > -- > > Alexander Motin > > CPU-performance-wise, I am not really worried. The current system is > an Atom 330 and even that is a bit overkill for what I do with it and > from what I am seeing, the new Atom D510 used on those boards is a > tiny bit faster. What I want and care about for this system are > reliability, stability, low power use, quietness and fast disk > read/write speeds. I've been hearing some praise of ICH9R and 6 native > SATA ports should be enough for my needs. AFAIK, the Intel 82574L > network cards included on those are also very well supported? That's just the thing -- I/O transactions, not to mention ZFS itself, are CPU-bound. If you start seeing slow I/O as a result of the Atom's limitations, I don't think there's anything that can be done about it. Choose wisely. :-) WRT the Intel 82574 series: em(4) supports this, just please be sure to run RELENG_8 as there's been em(4) fixes and improvements which RELEASE doesn't have. http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/dev/e1000/ If you have issues with the NIC(s), Jack Vogel at Intel can be of great assistance. :-) -- | Jeremy Chadwick jdc@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Mon Jan 25 19:04:22 2010 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DE0E21065676; Mon, 25 Jan 2010 19:04:22 +0000 (UTC) (envelope-from marck@rinet.ru) Received: from woozle.rinet.ru (woozle.rinet.ru [195.54.192.68]) by mx1.freebsd.org (Postfix) with ESMTP id 3E4908FC08; Mon, 25 Jan 2010 19:04:22 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by woozle.rinet.ru (8.14.3/8.14.3) with ESMTP id o0PJ4KKT001961; Mon, 25 Jan 2010 22:04:20 +0300 (MSK) (envelope-from marck@rinet.ru) Date: Mon, 25 Jan 2010 22:04:20 +0300 (MSK) From: Dmitry Morozovsky To: freebsd-stable@FreeBSD.org Message-ID: User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) X-NCC-RegID: ru.rinet X-OpenPGP-Key-ID: 6B691B03 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.3 (woozle.rinet.ru [0.0.0.0]); Mon, 25 Jan 2010 22:04:20 +0300 (MSK) Cc: Pawel Jakub Dawidek Subject: ZFS panic on RELENG_7/i386 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 25 Jan 2010 19:04:22 -0000 Dear colleagues, I had a crash durinc rsync to ZFS today: (kgdb) bt #0 doadump () at pcpu.h:196 #1 0xc050c688 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:418 #2 0xc050c965 in panic (fmt=Variable "fmt" is not available. ) at /usr/src/sys/kern/kern_shutdown.c:574 #3 0xc08e95ce in zfs_fuid_create (zfsvfs=0xc65c4800, id=Unhandled dwarf expression opcode 0x93 ) at /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_fuid.c:591 #4 0xc0910775 in zfs_freebsd_setattr (ap=0xf5baab64) at /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vnops.c:2888 #5 0xc06c6292 in VOP_SETATTR_APV (vop=0xc096e560, a=0xf5baab64) at vnode_if.c:583 #6 0xc05918e5 in setfown (td=0xc834fd80, vp=0xcac4b33c, uid=4294967294, gid=0) at vnode_if.h:315 #7 0xc05919bc in kern_lchown (td=0xc834fd80, path=0xbfbfccc8
, pathseg=UIO_USERSPACE, uid=-2, gid=0) at /usr/src/sys/kern/vfs_syscalls.c:2787 #8 0xc0591a4a in lchown (td=0xc834fd80, uap=0xf5baacfc) at /usr/src/sys/kern/vfs_syscalls.c:2770 #9 0xc06b10f5 in syscall (frame=0xf5baad38) at /usr/src/sys/i386/i386/trap.c:1101 #10 0xc0696b90 in Xint0x80_syscall () at /usr/src/sys/i386/i386/exception.s:262 Any other info needed? Thanks in advance! -- Sincerely, D.Marck [DM5020, MCK-RIPE, DM3-RIPN] [ FreeBSD committer: marck@FreeBSD.org ] ------------------------------------------------------------------------ *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- marck@rinet.ru *** ------------------------------------------------------------------------ From owner-freebsd-stable@FreeBSD.ORG Mon Jan 25 19:10:48 2010 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2DAAA106566B for ; Mon, 25 Jan 2010 19:10:48 +0000 (UTC) (envelope-from pjd@garage.freebsd.pl) Received: from mail.garage.freebsd.pl (chello089077043238.chello.pl [89.77.43.238]) by mx1.freebsd.org (Postfix) with ESMTP id 67D8F8FC15 for ; Mon, 25 Jan 2010 19:10:47 +0000 (UTC) Received: by mail.garage.freebsd.pl (Postfix, from userid 65534) id 10A0D45E86; Mon, 25 Jan 2010 20:10:38 +0100 (CET) Received: from localhost (pdawidek.wheel.pl [10.0.1.1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.garage.freebsd.pl (Postfix) with ESMTP id 2E57645CDC; Mon, 25 Jan 2010 20:10:33 +0100 (CET) Date: Mon, 25 Jan 2010 20:10:30 +0100 From: Pawel Jakub Dawidek To: Dmitry Morozovsky Message-ID: <20100125191030.GG1643@garage.freebsd.pl> References: Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="D6z0c4W1rkZNF4Vu" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i X-PGP-Key-URL: http://people.freebsd.org/~pjd/pjd.asc X-OS: FreeBSD 9.0-CURRENT i386 X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) on mail.garage.freebsd.pl X-Spam-Level: X-Spam-Status: No, score=-5.9 required=4.5 tests=ALL_TRUSTED,BAYES_00 autolearn=ham version=3.0.4 Cc: freebsd-stable@FreeBSD.org Subject: Re: ZFS panic on RELENG_7/i386 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 25 Jan 2010 19:10:48 -0000 --D6z0c4W1rkZNF4Vu Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Jan 25, 2010 at 10:04:20PM +0300, Dmitry Morozovsky wrote: > Dear colleagues, >=20 > I had a crash durinc rsync to ZFS today: Do you have recent 7-STABLE? Not sure if it was the same before MFC, probably not, because what you see is impossible in case of source I'm looking at. At the begining of zfs_fuid_create() function there is a check: if (!zfsvfs->z_use_fuids || !IS_EPHEMERAL(id) || fuid_idx !=3D 0) return (id); And IS_EPHEMERAL() is defined as follows: #define IS_EPHEMERAL(x) (0) So it will always return here. > #3 0xc08e95ce in zfs_fuid_create (zfsvfs=3D0xc65c4800, id=3DUnhandled dw= arf=20 > expression opcode 0x93 > ) > at=20 > /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs= /zfs_fuid.c:591 --=20 Pawel Jakub Dawidek http://www.wheel.pl pjd@FreeBSD.org http://www.FreeBSD.org FreeBSD committer Am I Evil? Yes, I Am! --D6z0c4W1rkZNF4Vu Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4 (FreeBSD) iD8DBQFLXeymForvXbEpPzQRAgHbAKDRD3zf/Kotqw/Fyxz0pFPAa0TvTwCgnEYJ WthKDuJ6KAh1j1vnavcEKN8= =8wo/ -----END PGP SIGNATURE----- --D6z0c4W1rkZNF4Vu-- From owner-freebsd-stable@FreeBSD.ORG Mon Jan 25 19:56:25 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CAFD51065670 for ; Mon, 25 Jan 2010 19:56:25 +0000 (UTC) (envelope-from torfinn.ingolfsen@broadpark.no) Received: from bgo1smout1.broadpark.no (bgo1smout1.broadpark.no [217.13.4.94]) by mx1.freebsd.org (Postfix) with ESMTP id 855038FC0A for ; Mon, 25 Jan 2010 19:56:25 +0000 (UTC) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=US-ASCII Received: from bgo1sminn1.broadpark.no ([217.13.4.93]) by bgo1smout1.broadpark.no (Sun Java(tm) System Messaging Server 6.3-3.01 (built Jul 12 2007; 32bit)) with ESMTP id <0KWT004DZJDL5180@bgo1smout1.broadpark.no> for freebsd-stable@freebsd.org; Mon, 25 Jan 2010 20:56:09 +0100 (CET) Received: from kg-v2.kg4.no ([80.203.92.186]) by bgo1sminn1.broadpark.no (Sun Java(tm) System Messaging Server 6.3-3.01 (built Jul 12 2007; 32bit)) with SMTP id <0KWT003X3JDKR710@bgo1sminn1.broadpark.no> for freebsd-stable@freebsd.org; Mon, 25 Jan 2010 20:56:09 +0100 (CET) Date: Mon, 25 Jan 2010 20:56:08 +0100 From: Torfinn Ingolfsen To: freebsd-stable@freebsd.org Message-id: <20100125205608.c5cc269f.torfinn.ingolfsen@broadpark.no> In-reply-to: <4591058770175c8eb66b690450ae33ed.squirrel@webmail.lerctr.org> References: <201001222220.31040.freebsd@insightbb.com> <20100124002054.BACFC1CC13@ptavv.es.net> <20100124033515.4049f625.torfinn.ingolfsen@broadpark.no> <4591058770175c8eb66b690450ae33ed.squirrel@webmail.lerctr.org> X-Mailer: Sylpheed 2.7.1 (GTK+ 2.18.6; amd64-portbld-freebsd8.0) X-Face: "t9w2,-X@O^I`jVW\sonI3.,36KBLZE*AL[y9lL[PyFD*r_S:dIL9c[8Y>V42R0"!"yb_zN,f#%.[PYYNq; m"_0v; ~rUM2Yy!zmkh)3&U|u!=T(zyv,MHJv"nDH>OJ`t(@mil461d_B'Uo|'nMwlKe0Mv=kvV?Nh@>Hb<3s_z2jYgZhPb@?Wi^x1a~Hplz1.zH Cc: torfinn.ingolfsen@broadpark.no Subject: Re: 8.0-RELEASE -> -STABLE and size of / X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jan 2010 19:56:25 -0000 On Sat, 23 Jan 2010 20:41:59 -0600 Larry Rosenman wrote: > > add the following to /etc/make.conf: > INSTALL_NODEBUG=yes This is useful. Thanks! -- Regards, Torfinn Ingolfsen From owner-freebsd-stable@FreeBSD.ORG Mon Jan 25 20:19:43 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 122F91065670; Mon, 25 Jan 2010 20:19:43 +0000 (UTC) (envelope-from marck@rinet.ru) Received: from woozle.rinet.ru (woozle.rinet.ru [195.54.192.68]) by mx1.freebsd.org (Postfix) with ESMTP id 876FA8FC19; Mon, 25 Jan 2010 20:19:42 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by woozle.rinet.ru (8.14.3/8.14.3) with ESMTP id o0PKJfxV003323; Mon, 25 Jan 2010 23:19:41 +0300 (MSK) (envelope-from marck@rinet.ru) Date: Mon, 25 Jan 2010 23:19:41 +0300 (MSK) From: Dmitry Morozovsky To: Pawel Jakub Dawidek In-Reply-To: <20100125191030.GG1643@garage.freebsd.pl> Message-ID: References: <20100125191030.GG1643@garage.freebsd.pl> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) X-NCC-RegID: ru.rinet X-OpenPGP-Key-ID: 6B691B03 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.3 (woozle.rinet.ru [0.0.0.0]); Mon, 25 Jan 2010 23:19:41 +0300 (MSK) Cc: freebsd-stable@freebsd.org Subject: Re: ZFS panic on RELENG_7/i386 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 25 Jan 2010 20:19:43 -0000 On Mon, 25 Jan 2010, Pawel Jakub Dawidek wrote: PJD> On Mon, Jan 25, 2010 at 10:04:20PM +0300, Dmitry Morozovsky wrote: PJD> > Dear colleagues, PJD> > PJD> > I had a crash durinc rsync to ZFS today: PJD> PJD> Do you have recent 7-STABLE? Not sure if it was the same before MFC, root@woozle:/var/crash# uname -a FreeBSD woozle.rinet.ru 7.2-STABLE FreeBSD 7.2-STABLE #4: Mon Dec 14 12:40:43 MSK 2009 marck@woozle.rinet.ru:/usr/obj/usr/src/sys/WOOZLE i386 I'll update to fresh sources and recheck, thanks. BTW, any thoughts of another topic I started a couple of weeks ago? PJD> probably not, because what you see is impossible in case of source I'm PJD> looking at. At the begining of zfs_fuid_create() function there is a PJD> check: PJD> PJD> if (!zfsvfs->z_use_fuids || !IS_EPHEMERAL(id) || fuid_idx != 0) PJD> return (id); PJD> PJD> And IS_EPHEMERAL() is defined as follows: PJD> PJD> #define IS_EPHEMERAL(x) (0) PJD> PJD> So it will always return here. PJD> PJD> > #3 0xc08e95ce in zfs_fuid_create (zfsvfs=0xc65c4800, id=Unhandled dwarf PJD> > expression opcode 0x93 PJD> > ) PJD> > at PJD> > /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_fuid.c:591 PJD> PJD> -- Sincerely, D.Marck [DM5020, MCK-RIPE, DM3-RIPN] [ FreeBSD committer: marck@FreeBSD.org ] ------------------------------------------------------------------------ *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- marck@rinet.ru *** ------------------------------------------------------------------------ From owner-freebsd-stable@FreeBSD.ORG Mon Jan 25 20:34:58 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 49458106568F; Mon, 25 Jan 2010 20:34:58 +0000 (UTC) (envelope-from mavbsd@gmail.com) Received: from mail-fx0-f227.google.com (mail-fx0-f227.google.com [209.85.220.227]) by mx1.freebsd.org (Postfix) with ESMTP id 76CD48FC1E; Mon, 25 Jan 2010 20:34:57 +0000 (UTC) Received: by fxm27 with SMTP id 27so1227178fxm.3 for ; Mon, 25 Jan 2010 12:34:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :x-enigmail-version:content-type:content-transfer-encoding; bh=oVRY+Su/J/ScL502cZEdc1r1uSa5EvtN93PVQdchD0o=; b=FGTtx1cDTPAeJRDstvzHKdeOkCM3ekxgGXpwWF1xQ80SMxL+gTIHci1KDgM6u25t2q qT4cox8B7nu4N8cbLlBeipX2pcBXUowktMbZ558RjMbf7nv3nTMtvSp7/uAnphN/q0fp mUx/PZhy7GmvVX0jdKdDu6Lke8iPTCv8rHGro= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:content-type :content-transfer-encoding; b=coVQ4Fk86R9Sl0f9yQf5PXg4DpDXRGJlYVgRINB64IgoxeUsMVwL7uq1U0E/kf8CZZ 2oNhyJz4gRyLaRW+EglzVEPDVspd9WwvIUKx1C8Do75VWIbV4LHnqiiHpnfIlYzn7imF 9NvFniMqUnWaV2L9QWUaGT6ItQWZ89TT3g3Ts= Received: by 10.223.3.135 with SMTP id 7mr7452629fan.21.1264451696497; Mon, 25 Jan 2010 12:34:56 -0800 (PST) Received: from mavbook.mavhome.dp.ua (pc.mavhome.dp.ua [212.86.226.226]) by mx.google.com with ESMTPS id 14sm2944360fxm.11.2010.01.25.12.34.55 (version=SSLv3 cipher=RC4-MD5); Mon, 25 Jan 2010 12:34:56 -0800 (PST) Sender: Alexander Motin Message-ID: <4B5E006D.1000302@FreeBSD.org> Date: Mon, 25 Jan 2010 22:34:53 +0200 From: Alexander Motin User-Agent: Thunderbird 2.0.0.23 (X11/20091212) MIME-Version: 1.0 To: Chris Whitehouse References: <4B5DD7A2.4000101@FreeBSD.org> <4B5DE3C1.4060508@FreeBSD.org> <4B5DFE78.3010805@onetel.com> In-Reply-To: <4B5DFE78.3010805@onetel.com> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Mon, 25 Jan 2010 21:53:22 +0000 Cc: sub.mesa@gmail.com, freebsd-stable@freebsd.org, Pete French , Dan Naumov , Artem Belevich , freebsd-fs@freebsd.org, wonslung@gmail.com, bfriesen@simple.dallas.tx.us, freebsd-questions@freebsd.org Subject: Re: 8.0-RELEASE/amd64 - full ZFS install - low read and write disk performance X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jan 2010 20:34:58 -0000 Chris Whitehouse wrote: > Dan Naumov wrote: >> >> CPU-performance-wise, I am not really worried. The current system is >> an Atom 330 and even that is a bit overkill for what I do with it and >> from what I am seeing, the new Atom D510 used on those boards is a >> tiny bit faster. What I want and care about for this system are >> reliability, stability, low power use, quietness and fast disk >> read/write speeds. I've been hearing some praise of ICH9R and 6 native >> SATA ports should be enough for my needs. AFAIK, the Intel 82574L >> network cards included on those are also very well supported? > > These might be interesting then > www.fit-pc.com > The Intel US15W SCH chipset or System Controller Hub as it's called is > mentioned in hardware notes for 8.0R and 7.2R but only for snd_hda, I > don't know if this means other functions are supported or not. This > thread says it is supported > http://mail-index.netbsd.org/port-i386/2010/01/03/msg001695.html Intel US15W (SCH) chipset heavily stripped and tuned for netbooks. It has no SATA, only one PATA channel. It is mostly supported by FreeBSD, but with exception of video, which makes it close to useless. it has only one benefit - low power consumption. -- Alexander Motin From owner-freebsd-stable@FreeBSD.ORG Mon Jan 25 20:38:01 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 566911065676; Mon, 25 Jan 2010 20:38:01 +0000 (UTC) (envelope-from cwhiteh@onetel.com) Received: from woodbine.london.02.net (woodbine.london.02.net [87.194.255.145]) by mx1.freebsd.org (Postfix) with ESMTP id 142208FC12; Mon, 25 Jan 2010 20:37:59 +0000 (UTC) Received: from eco.config (93.97.24.219) by woodbine.london.02.net (8.5.016.1) id 4A2032960754C3CB; Mon, 25 Jan 2010 20:26:32 +0000 Message-ID: <4B5DFE78.3010805@onetel.com> Date: Mon, 25 Jan 2010 20:26:32 +0000 From: Chris Whitehouse User-Agent: Thunderbird 2.0.0.23 (X11/20091212) MIME-Version: 1.0 To: Dan Naumov References: <4B5DD7A2.4000101@FreeBSD.org> <4B5DE3C1.4060508@FreeBSD.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Mon, 25 Jan 2010 21:53:29 +0000 Cc: sub.mesa@gmail.com, freebsd-stable@freebsd.org, Pete French , Alexander Motin , Artem Belevich , freebsd-fs@freebsd.org, wonslung@gmail.com, bfriesen@simple.dallas.tx.us, freebsd-questions@freebsd.org Subject: Re: 8.0-RELEASE/amd64 - full ZFS install - low read and write disk performance X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jan 2010 20:38:01 -0000 Dan Naumov wrote: > > CPU-performance-wise, I am not really worried. The current system is > an Atom 330 and even that is a bit overkill for what I do with it and > from what I am seeing, the new Atom D510 used on those boards is a > tiny bit faster. What I want and care about for this system are > reliability, stability, low power use, quietness and fast disk > read/write speeds. I've been hearing some praise of ICH9R and 6 native > SATA ports should be enough for my needs. AFAIK, the Intel 82574L > network cards included on those are also very well supported? > These might be interesting then www.fit-pc.com The Intel US15W SCH chipset or System Controller Hub as it's called is mentioned in hardware notes for 8.0R and 7.2R but only for snd_hda, I don't know if this means other functions are supported or not. This thread says it is supported http://mail-index.netbsd.org/port-i386/2010/01/03/msg001695.html Chris > - Sincerely, > Dan Naumov > _______________________________________________ > freebsd-questions@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-questions > To unsubscribe, send any mail to "freebsd-questions-unsubscribe@freebsd.org" > From owner-freebsd-stable@FreeBSD.ORG Mon Jan 25 20:57:22 2010 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 211B1106566B; Mon, 25 Jan 2010 20:57:22 +0000 (UTC) (envelope-from cwhiteh@onetel.com) Received: from april.london.02.net (april.london.02.net [87.194.255.143]) by mx1.freebsd.org (Postfix) with ESMTP id 8E6DF8FC12; Mon, 25 Jan 2010 20:57:21 +0000 (UTC) Received: from eco.config (93.97.24.219) by april.london.02.net (8.5.016.1) id 4A23ECF807794BCD; Mon, 25 Jan 2010 20:57:20 +0000 Message-ID: <4B5E05B0.1050807@onetel.com> Date: Mon, 25 Jan 2010 20:57:20 +0000 From: Chris Whitehouse User-Agent: Thunderbird 2.0.0.23 (X11/20091212) MIME-Version: 1.0 To: Alexander Motin References: <4B5DD7A2.4000101@FreeBSD.org> <4B5DE3C1.4060508@FreeBSD.org> <4B5DFE78.3010805@onetel.com> <4B5E006D.1000302@FreeBSD.org> In-Reply-To: <4B5E006D.1000302@FreeBSD.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Mon, 25 Jan 2010 21:53:38 +0000 Cc: sub.mesa@gmail.com, freebsd-stable@freebsd.org, Pete French , Dan Naumov , Artem Belevich , freebsd-fs@freebsd.org, wonslung@gmail.com, bfriesen@simple.dallas.tx.us, freebsd-questions@freebsd.org Subject: Re: 8.0-RELEASE/amd64 - full ZFS install - low read and write disk performance X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jan 2010 20:57:22 -0000 Alexander Motin wrote: > Chris Whitehouse wrote: >> Dan Naumov wrote: >>> CPU-performance-wise, I am not really worried. The current system is >>> an Atom 330 and even that is a bit overkill for what I do with it and >>> from what I am seeing, the new Atom D510 used on those boards is a >>> tiny bit faster. What I want and care about for this system are >>> reliability, stability, low power use, quietness and fast disk >>> read/write speeds. I've been hearing some praise of ICH9R and 6 native >>> SATA ports should be enough for my needs. AFAIK, the Intel 82574L >>> network cards included on those are also very well supported? >> These might be interesting then >> www.fit-pc.com >> The Intel US15W SCH chipset or System Controller Hub as it's called is >> mentioned in hardware notes for 8.0R and 7.2R but only for snd_hda, I >> don't know if this means other functions are supported or not. This >> thread says it is supported >> http://mail-index.netbsd.org/port-i386/2010/01/03/msg001695.html > > Intel US15W (SCH) chipset heavily stripped and tuned for netbooks. It > has no SATA, only one PATA channel. It is mostly supported by FreeBSD, > but with exception of video, which makes it close to useless. it has > only one benefit - low power consumption. > The intel spec sheet does say single PATA but according to the fit-pc website it has SATA and miniSD. Still as you say without video support it's not much use, which is useful to know as I had been looking at these. Ok I will go away now :O Chris From owner-freebsd-stable@FreeBSD.ORG Mon Jan 25 22:16:30 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6EBA6106566B; Mon, 25 Jan 2010 22:16:30 +0000 (UTC) (envelope-from marck@rinet.ru) Received: from woozle.rinet.ru (woozle.rinet.ru [195.54.192.68]) by mx1.freebsd.org (Postfix) with ESMTP id E36028FC19; Mon, 25 Jan 2010 22:16:29 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by woozle.rinet.ru (8.14.3/8.14.3) with ESMTP id o0PMGSA1002428; Tue, 26 Jan 2010 01:16:28 +0300 (MSK) (envelope-from marck@rinet.ru) Date: Tue, 26 Jan 2010 01:16:28 +0300 (MSK) From: Dmitry Morozovsky To: Pawel Jakub Dawidek In-Reply-To: Message-ID: References: <20100125191030.GG1643@garage.freebsd.pl> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) X-NCC-RegID: ru.rinet X-OpenPGP-Key-ID: 6B691B03 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.3 (woozle.rinet.ru [0.0.0.0]); Tue, 26 Jan 2010 01:16:28 +0300 (MSK) Cc: freebsd-stable@freebsd.org Subject: Re: ZFS panic on RELENG_7/i386 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 25 Jan 2010 22:16:30 -0000 On Mon, 25 Jan 2010, Dmitry Morozovsky wrote: DM> PJD> > I had a crash durinc rsync to ZFS today: DM> PJD> DM> PJD> Do you have recent 7-STABLE? Not sure if it was the same before MFC, DM> DM> root@woozle:/var/crash# uname -a DM> FreeBSD woozle.rinet.ru 7.2-STABLE FreeBSD 7.2-STABLE #4: Mon Dec 14 12:40:43 DM> MSK 2009 marck@woozle.rinet.ru:/usr/obj/usr/src/sys/WOOZLE i386 DM> DM> I'll update to fresh sources and recheck, thanks. DM> DM> BTW, any thoughts of another topic I started a couple of weeks ago? Well, after updating to fresh system scrub finished without errors, and now rsync is running, now copied 15G out of 150. Thank you! -- Sincerely, D.Marck [DM5020, MCK-RIPE, DM3-RIPN] [ FreeBSD committer: marck@FreeBSD.org ] ------------------------------------------------------------------------ *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- marck@rinet.ru *** ------------------------------------------------------------------------ From owner-freebsd-stable@FreeBSD.ORG Mon Jan 25 23:16:16 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 28B85106566B; Mon, 25 Jan 2010 23:16:16 +0000 (UTC) (envelope-from doconnor@gsoft.com.au) Received: from cain.gsoft.com.au (cain.gsoft.com.au [203.31.81.10]) by mx1.freebsd.org (Postfix) with ESMTP id 6F14D8FC16; Mon, 25 Jan 2010 23:16:15 +0000 (UTC) Received: from inchoate.gsoft.com.au (ppp121-45-156-224.lns6.adl6.internode.on.net [121.45.156.224]) (authenticated bits=0) by cain.gsoft.com.au (8.13.8/8.13.8) with ESMTP id o0PNG4TQ084912 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Tue, 26 Jan 2010 09:46:05 +1030 (CST) (envelope-from doconnor@gsoft.com.au) From: "Daniel O'Connor" To: freebsd-stable@freebsd.org Date: Tue, 26 Jan 2010 09:45:57 +1030 User-Agent: KMail/1.9.10 References: <4B5DE3C1.4060508@FreeBSD.org> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1284787.2vsuEm6DAF"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <201001260946.01541.doconnor@gsoft.com.au> X-Spam-Score: -1.682 () AWL,BAYES_00,RDNS_DYNAMIC X-Scanned-By: MIMEDefang 2.63 on 203.31.81.10 X-Mailman-Approved-At: Mon, 25 Jan 2010 23:18:36 +0000 Cc: sub.mesa@gmail.com, Pete French , Alexander Motin , Dan Naumov , Artem Belevich , freebsd-fs@freebsd.org, wonslung@gmail.com, bfriesen@simple.dallas.tx.us, freebsd-questions@freebsd.org Subject: Re: 8.0-RELEASE/amd64 - full ZFS install - low read and write disk performance X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jan 2010 23:16:16 -0000 --nextPart1284787.2vsuEm6DAF Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Tue, 26 Jan 2010, Dan Naumov wrote: > CPU-performance-wise, I am not really worried. The current system is > an Atom 330 and even that is a bit overkill for what I do with it and > from what I am seeing, the new Atom D510 used on those boards is a > tiny bit faster. What I want and care about for this system are > reliability, stability, low power use, quietness and fast disk > read/write speeds. I've been hearing some praise of ICH9R and 6 > native SATA ports should be enough for my needs. AFAIK, the Intel > 82574L network cards included on those are also very well supported? You might want to consider an Athlon (maybe underclock it) - the AMD IXP=20 700/800 south bridge seems to work well with FreeBSD (in my=20 experience). These boards (eg Gigabyte GA-MA785GM-US2H) have 6 SATA ports (one may be=20 eSATA though) and PATA, they seem ideal really.. You can use PATA with=20 CF to boot and connect 5 disks plus a DVD drive. The CPU is not fanless however, but the other stuff is, on the plus side=20 you won't have to worry about CPU power :) Also, the onboard video works well with radeonhd and is quite fast. One other downside is the onboard network isn't great (Realtek) but I=20 put an em card in mine. =2D-=20 Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C --nextPart1284787.2vsuEm6DAF Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.12 (FreeBSD) iD8DBQBLXiYx5ZPcIHs/zowRAkB2AJ9XVkRqtWestP2Y3LC+ygn4pqqZUACcDzLz DvH9w9HtCsd2NJKnfFB1wHk= =p8ya -----END PGP SIGNATURE----- --nextPart1284787.2vsuEm6DAF-- From owner-freebsd-stable@FreeBSD.ORG Tue Jan 26 01:34:12 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E72B51065679; Tue, 26 Jan 2010 01:34:12 +0000 (UTC) (envelope-from rnoland@FreeBSD.org) Received: from gizmo.2hip.net (gizmo.2hip.net [64.74.207.195]) by mx1.freebsd.org (Postfix) with ESMTP id 85B8C8FC1A; Tue, 26 Jan 2010 01:34:12 +0000 (UTC) Received: from [192.168.1.4] (adsl-149-142-141.bna.bellsouth.net [70.149.142.141]) (authenticated bits=0) by gizmo.2hip.net (8.14.3/8.14.3) with ESMTP id o0Q1Y9dk091619 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Mon, 25 Jan 2010 20:34:10 -0500 (EST) (envelope-from rnoland@FreeBSD.org) From: Robert Noland To: Matthew Seaman In-Reply-To: <4B5D6833.6050200@infracaninophile.co.uk> References: <20100122041237.GA22312@gothschlampen.com> <20100124092947.B72039@starfire.mn.org> <201001242057.o0OKvHUE089237@drugs.dv.isc.org> <1264387282.2869.24.camel@balrog.2hip.net> <4B5D6207.9090105@icyb.net.ua> <4B5D6833.6050200@infracaninophile.co.uk> Content-Type: text/plain Organization: FreeBSD Date: Mon, 25 Jan 2010 19:34:04 -0600 Message-Id: <1264469644.2869.49.camel@balrog.2hip.net> Mime-Version: 1.0 X-Mailer: Evolution 2.26.3 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=0.2 required=5.0 tests=AWL, BAYES_00, FH_DATE_PAST_20XX, RCVD_IN_PBL,RDNS_DYNAMIC,SPF_SOFTFAIL autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on gizmo.2hip.net Cc: FreeBSD-STABLE Mailing List , Andriy Gapon , freebsd-questions@freebsd.org Subject: Re: Loader, MBR and the boot process X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 26 Jan 2010 01:34:13 -0000 On Mon, 2010-01-25 at 09:45 +0000, Matthew Seaman wrote: > Andriy Gapon wrote: > > on 25/01/2010 04:41 Robert Noland said the following: > >> On Mon, 2010-01-25 at 07:57 +1100, Mark Andrews wrote: > >>> offset The offset of the start of the partition from the beginning of > >>> the drive in sectors, or * to have bsdlabel calculate the correct > >>> offset to use (the end of the previous partition plus one, ignor- > >>> ing partition `c'. For partition `c', * will be interpreted as > >>> an offset of 0. The first partition should start at offset 16, > >>> because the first 16 sectors are reserved for metadata. > >> Ok, now this has my attention... My gut feeling right now is that this > >> is a bug in geom_part_bsd. I don't understand why the label isn't > >> protected. (Adding -b 16 when adding the swap partition fixes this) > >> Another project to goes on my list... > >> > >> If anyone knows why this is done like this... please share. > > > > I presume that this is for purely historic reasons. > > > > I believe this has been known about since 5.x days: > > http://www.freebsd.org/cgi/query-pr.cgi?pr=72812 > > As far as I recall, sometime around 6.1-RELEASE this should have been > fixed. It certainly seems to be the case that it is harmless to have > a plain swap partition start at offset 0, but anything else, like encrypted > swap or putting a filesystem there needs the 16 sector offset. When the first partition (whatever it is), starts at offset 0, if you dd into that partition you wipe out the label entirely, which just doesn't make sense to me. Trying to manage this in the file system code and the swap pager or whatever other consumer might make use of the partition seems like madness to me. robert. > Cheers, > > Matthew > -- Robert Noland FreeBSD From owner-freebsd-stable@FreeBSD.ORG Tue Jan 26 03:01:47 2010 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0ED8410656A8 for ; Tue, 26 Jan 2010 03:01:47 +0000 (UTC) (envelope-from ncrogers@gmail.com) Received: from mail-pz0-f176.google.com (mail-pz0-f176.google.com [209.85.222.176]) by mx1.freebsd.org (Postfix) with ESMTP id D33C28FC1F for ; Tue, 26 Jan 2010 03:01:46 +0000 (UTC) Received: by pzk6 with SMTP id 6so1449509pzk.3 for ; Mon, 25 Jan 2010 19:01:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:content-type; bh=5ZmkDiZhG3Xp247TQUUEC4B+oYu6jXJ9L1Yha8POyyg=; b=rTjjmrk0HZExIFmG15xiFywaHPoIAsuCiONbyyCkOkCXmM7R+1bNe6ik9D1OBilO1O dSoxAbeY5AbS4F4P9JIxTY93HiwG4GxCYSonloI9qJCoYHOzRFfcpvL8sdxI5Vo53cXj OqF0Sh0zPG4RtJ0rQ/zgmdI1UTiAToR1cP7e0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=xnMCbPfstX6R6tQpe3E/a/arfQir8ZIhEN0yQGZPl79TVZVBBNuP/Ey2g4KSoVM+Zy n5T84pRvgmQmlI6P3N/Aa8hvjxUciVFr0mboNuCnGBxkmc7W2rnxoHDz1bRC7BQ+1JwT INdHaTsvw4KJ3R2mS3SGc9FsS8Sr3Ni0mAf9s= MIME-Version: 1.0 Received: by 10.143.153.19 with SMTP id f19mr10814wfo.36.1264474906375; Mon, 25 Jan 2010 19:01:46 -0800 (PST) Date: Mon, 25 Jan 2010 19:01:46 -0800 Message-ID: <147432021001251901u7d56f014n83e834061fd09fec@mail.gmail.com> From: Nick Rogers To: stable@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Subject: netstat output changes in 8.0? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jan 2010 03:01:47 -0000 Before 8.0-RELEASE, if I ran netstat -rn, it listed a separate route for each host on the network, along with its MAC address. For example ... 172.20.172.17 00:02:b3:2f:64:6a UHLW 1 105712 1500 vlan172 595 172.20.172.20 00:1e:c9:bb:7c:a9 UHLW 1 1002 1500 vlan172 598 172.20.172.22 00:14:5e:16:bb:b6 UHLW 1 107 1500 vlan172 491 This behavior seems to have changed in 8.0, where now only the locally-assigned IP addresses and related CIDRs are displayed. Is there any way to get this behavior back, perhaps with a new flag that I am not able to find? Or some sysctl? I have a script that was relying on each host's "expire" flag in the routing table to determine when the MAC address first appeared on the network according to ARP. From owner-freebsd-stable@FreeBSD.ORG Tue Jan 26 04:40:49 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E012B106566B for ; Tue, 26 Jan 2010 04:40:48 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from qmta08.emeryville.ca.mail.comcast.net (qmta08.emeryville.ca.mail.comcast.net [76.96.30.80]) by mx1.freebsd.org (Postfix) with ESMTP id 9A8DD8FC16 for ; Tue, 26 Jan 2010 04:40:46 +0000 (UTC) Received: from omta13.emeryville.ca.mail.comcast.net ([76.96.30.52]) by qmta08.emeryville.ca.mail.comcast.net with comcast id a2bt1d00317UAYkA84gmVE; Tue, 26 Jan 2010 04:40:46 +0000 Received: from koitsu.dyndns.org ([98.248.46.159]) by omta13.emeryville.ca.mail.comcast.net with comcast id a4gj1d0023S48mS8Z4gjVZ; Tue, 26 Jan 2010 04:40:44 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id 024791E3033; Mon, 25 Jan 2010 20:40:42 -0800 (PST) Date: Mon, 25 Jan 2010 20:40:41 -0800 From: Jeremy Chadwick To: freebsd-stable@freebsd.org Message-ID: <20100126044041.GA33624@icarus.home.lan> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.20 (2009-06-14) Subject: Looking for testers: atacontrol SMART support X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 26 Jan 2010 04:40:49 -0000 As mentioned a while back on the list[1], I worked on getting atacontrol to spit out SMART statistics for ATA disks. Specifically, this would be those using the standard ata(4) layer (including ataahci.ko and similar), but not ahci(4) (ahci.ko), which uses ATA/CAM. Output resembles the following: ID# Attribute Name Curr Worst Thrsh Bytes --- ------------------------- ----- ----- ----- ----------------- 1 Raw Read Error Rate 200 200 51 00 00 00 00 00 00 3 Spin Up Time 234 229 21 53 20 00 00 00 00 4 Start/Stop Count 100 100 0 11 00 00 00 00 00 5 Reallocated Sector Count 200 200 140 00 00 00 00 00 00 7 Seek Error Rate 200 200 0 00 00 00 00 00 00 9 Power On Hours Count 95 95 0 9b 0f 00 00 00 00 10 Spin Retry Count 100 253 0 00 00 00 00 00 00 11 Calibration Retry Count 100 253 0 00 00 00 00 00 00 12 Power Cycle Count 100 100 0 0c 00 00 00 00 00 192 Power Off Retract Count 200 200 0 0b 00 00 00 00 00 193 Load Cycle Count 200 200 0 11 00 00 00 00 00 194 Temperature 116 113 0 22 00 00 00 00 00 196 Reallocated Event Count 200 200 0 00 00 00 00 00 00 197 Current Pending Sectors 200 200 0 00 00 00 00 00 00 198 * Uncorrected Sector Count 200 200 0 00 00 00 00 00 00 199 UltraDMA CRC Error Count 200 200 0 00 00 00 00 00 00 200 * Write Error Rate 200 200 0 00 00 00 00 00 00 --- ------------------------- ----- ----- ----- ----------------- * = values only updated after a short/long/offline test Things to note: - I've only been testing on RELENG_8 amd64. The code should work on i386, but if something explodes, let me know. I don't recommend patching RELENG_7 or even a RELEASE tag with this. - I did my best to document the SMART "stuff" throughout the source. Much to my disappointment SMART attributes are not part of the ATA or ACS specification; they're mentioned, but attributes and their interpretation are 100% vendor specific. Decoding them will involve examining the smartmontools source, which takes time. This is why there is no smartmontools "RAW_VALUE" equivalent -- the code for that piece simply hasn't been written. Instead, I display the raw bytes associated with each attribute. This should help with debugging (for the time being). I'll work things out... :-) - I've only tested this with WD2000JD and WD1001FALS disks. Those with Seagate, Maxtor, Hitachi/IBM, Fujitsu, Samsung, and others will probably find many of their attributes names appear as "". See below for how you can help improve this situation. - All operations done are read-only (in fact the device is opened in read-only mode). There may be plans down the road to implement things like inducing SMART short/long/offline tests, but for now I want to get attribute support in there. - All of the code was written by hand; that is to say, there is no code copied/stolen from smartmontools, as it's released under the GPL. I'll be putting diffs/patches up at my site[2] as I work on improvements. I won't be maintaining a CHANGES log for now, unless people really want me to keep one. Methodology I use to test: $ cd /some/other/place $ cp -pR /usr/src/sbin/atacontrol . $ patch -p0 < atacontrol-smart-20100125_01.diff $ cd atacontrol $ make $ ./atacontrol smart Let me know if you're interested in helping improve this, and/or if this feature is at all worth being imported into the standard atacontrol(8) utility. For those wanting to help extend the SMART attribute ID-to-name mapping, this is quite easy: install smartmontools and send me the output from "smartctl -a /dev/adXX". I can work out the rest. Thanks. [1]: http://lists.freebsd.org/pipermail/freebsd-stable/2009-December/053464.html [2]: http://jdc.parodius.com/freebsd/atacontrol/ -- | Jeremy Chadwick jdc@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Tue Jan 26 05:03:07 2010 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EFA6A106566C for ; Tue, 26 Jan 2010 05:03:06 +0000 (UTC) (envelope-from boydjd@jbip.net) Received: from mail-fx0-f227.google.com (mail-fx0-f227.google.com [209.85.220.227]) by mx1.freebsd.org (Postfix) with ESMTP id 8CC7D8FC12 for ; Tue, 26 Jan 2010 05:03:06 +0000 (UTC) Received: by fxm27 with SMTP id 27so1562866fxm.3 for ; Mon, 25 Jan 2010 21:03:05 -0800 (PST) MIME-Version: 1.0 Received: by 10.239.187.132 with SMTP id l4mr851105hbh.87.1264480327170; Mon, 25 Jan 2010 20:32:07 -0800 (PST) In-Reply-To: <02307620-ECDC-4E8B-A5B1-FF8491E226C4@nokia.com> References: <20091201.102925.218343479.hrs@allbsd.org> <2a41acea0912021514r2d44dd33n4c364518d7fe1703@mail.gmail.com> <20091203.182931.129751456.hrs@allbsd.org> <4B43F6EE.3010308@ucla.edu> <147432021001242047k659a26d0s44b35164920aeb74@mail.gmail.com> <95D3CB82-BC44-491D-86E4-5CB82F89C0FC@nokia.com> <147432021001250825p202914a7ka5a2c1d28d96bac3@mail.gmail.com> <20100125182257.GG1187@michelle.cdnetworks.com> <147432021001251038r69393ab3m1a797e58f9fa905a@mail.gmail.com> <02307620-ECDC-4E8B-A5B1-FF8491E226C4@nokia.com> From: Joshua Boyd Date: Mon, 25 Jan 2010 23:31:47 -0500 Message-ID: <33c6b0bc1001252031k508426bfh25fad65e9223d87@mail.gmail.com> To: "stable@freebsd.org" Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Subject: Re: em interface slow down on 8.0R X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 26 Jan 2010 05:03:07 -0000 I've been having a similar problem with my network dropping completely on my 8-STABLE gateway/firewall/fileserver. My setup is a little different, as I have re0 and ral0 bridged for LAN, and em0 for WAN. I've just turned off TX checksum offloading to see if that makes any difference. On Mon, Jan 25, 2010 at 1:49 PM, Lars Eggert wrote: > Hi, > > On 2010-1-25, at 19:38, Nick Rogers wrote: > >> On Mon, Jan 25, 2010 at 10:22 AM, Pyun YongHyeon > wrote: > >> I'm not sure you're seeing a checksum offload bug of em(4) but the > >> bug is easily reproducible in VLAN environments. If the issue is > >> gone when you disable TX checksum offloading, see kern/141843 for > >> for more detailed information as well as fix. > >> > > Good to know, but I am having a similar problem on another em(4) > interface that has no VLAN interfaces. > > FYI, I also have these issues without using VLANs, and turning off TSO > fixed them. > > Lars -- Joshua Boyd JBipNet E-mail: boydjd@jbip.net http://www.jbip.net From owner-freebsd-stable@FreeBSD.ORG Tue Jan 26 05:38:29 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 45434106566B; Tue, 26 Jan 2010 05:38:29 +0000 (UTC) (envelope-from bu7cher@yandex.ru) Received: from forward11.mail.yandex.net (forward11.mail.yandex.net [95.108.130.93]) by mx1.freebsd.org (Postfix) with ESMTP id E9E098FC12; Tue, 26 Jan 2010 05:38:28 +0000 (UTC) Received: from smtp2.mail.yandex.net (smtp2.mail.yandex.net [77.88.46.102]) by forward11.mail.yandex.net (Yandex) with ESMTP id 4C505F49BA1; Tue, 26 Jan 2010 08:38:27 +0300 (MSK) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1264484307; bh=9lFLFDGhHMGhQ23FpybHlpOH6tDAAcLFv9tJ56gW+iM=; h=Message-ID:Date:From:MIME-Version:To:CC:Subject:References: In-Reply-To:Content-Type:Content-Transfer-Encoding; b=nCAAMwwKPvEi/IccG01mW4k/iuDKLALeKyx3lp4Gfayl/nqbqBy5beepAaEY0Djp+ nxfR0N0h9qt+GlAbiDbXAcCfkyw54guMDSrlAJ7mBqzMd2YPqAjmeeIqssygPF4k6d l1vkOx2t5b65A9hp7gaCbqB7c0p64a8OjUdW3uZc= Received: from [127.0.0.1] (ns.kirov.so-cdu.ru [77.72.136.145]) by smtp2.mail.yandex.net (Yandex) with ESMTPSA id 05FDDD181FF; Tue, 26 Jan 2010 08:38:26 +0300 (MSK) Message-ID: <4B5E7FD2.9050601@yandex.ru> Date: Tue, 26 Jan 2010 08:38:26 +0300 From: "Andrey V. Elsukov" User-Agent: Mozilla Thunderbird 1.5 (FreeBSD/20051231) MIME-Version: 1.0 To: Jeremy Chadwick References: <20100126044041.GA33624@icarus.home.lan> In-Reply-To: <20100126044041.GA33624@icarus.home.lan> Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: 7bit X-Yandex-TimeMark: 1264484307 X-Yandex-Spam: 1 X-Yandex-Front: smtp2.mail.yandex.net Cc: Alexander Motin , freebsd-stable@freebsd.org Subject: Re: Looking for testers: atacontrol SMART support X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 26 Jan 2010 05:38:29 -0000 On 26.01.2010 7:40, Jeremy Chadwick wrote: > - All of the code was written by hand; that is to say, there is no code > copied/stolen from smartmontools, as it's released under the GPL. Hi, Jeremy. Some time ago i've began the same work, but did not finish it because ENOTIME.. So, did you look to NetBSD's implementation? As i remember NetBSD has SMART reporting and testing support in atactl. -- WBR, Andrey V. Elsukov From owner-freebsd-stable@FreeBSD.ORG Tue Jan 26 06:29:24 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6652F1065676 for ; Tue, 26 Jan 2010 06:29:24 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from qmta02.emeryville.ca.mail.comcast.net (qmta02.emeryville.ca.mail.comcast.net [76.96.30.24]) by mx1.freebsd.org (Postfix) with ESMTP id 4F73E8FC16 for ; Tue, 26 Jan 2010 06:29:24 +0000 (UTC) Received: from omta03.emeryville.ca.mail.comcast.net ([76.96.30.27]) by qmta02.emeryville.ca.mail.comcast.net with comcast id a0X41d0020b6N64A26VQbT; Tue, 26 Jan 2010 06:29:24 +0000 Received: from koitsu.dyndns.org ([98.248.46.159]) by omta03.emeryville.ca.mail.comcast.net with comcast id a6VQ1d0013S48mS8P6VQ1Z; Tue, 26 Jan 2010 06:29:24 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id ECAE61E3033; Mon, 25 Jan 2010 22:29:22 -0800 (PST) Date: Mon, 25 Jan 2010 22:29:22 -0800 From: Jeremy Chadwick To: freebsd-stable@freebsd.org Message-ID: <20100126062922.GA36656@icarus.home.lan> References: <20100126044041.GA33624@icarus.home.lan> <4B5E7FD2.9050601@yandex.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4B5E7FD2.9050601@yandex.ru> User-Agent: Mutt/1.5.20 (2009-06-14) Subject: Re: Looking for testers: atacontrol SMART support X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 26 Jan 2010 06:29:24 -0000 On Tue, Jan 26, 2010 at 08:38:26AM +0300, Andrey V. Elsukov wrote: > On 26.01.2010 7:40, Jeremy Chadwick wrote: > >- All of the code was written by hand; that is to say, there is no code > >copied/stolen from smartmontools, as it's released under the GPL. > > Hi, Jeremy. > > Some time ago i've began the same work, but did not finish it because ENOTIME.. > So, did you look to NetBSD's implementation? As i remember NetBSD has SMART > reporting and testing support in atactl. Nope, I had no idea they had existing code already in their userland utility; I haven't looked at/used NetBSD since 1993. :-) I'll take a peek and see what I see. Thanks for the tip! -- | Jeremy Chadwick jdc@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Tue Jan 26 07:33:41 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B68401065676 for ; Tue, 26 Jan 2010 07:33:41 +0000 (UTC) (envelope-from peterjeremy@acm.org) Received: from mail34.syd.optusnet.com.au (mail34.syd.optusnet.com.au [211.29.133.218]) by mx1.freebsd.org (Postfix) with ESMTP id 474D88FC17 for ; Tue, 26 Jan 2010 07:33:40 +0000 (UTC) Received: from server.vk2pj.dyndns.org (c122-106-232-148.belrs3.nsw.optusnet.com.au [122.106.232.148]) by mail34.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id o0Q7Xb6G009229 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 26 Jan 2010 18:33:39 +1100 X-Bogosity: Ham, spamicity=0.000000 Received: from server.vk2pj.dyndns.org (localhost.vk2pj.dyndns.org [127.0.0.1]) by server.vk2pj.dyndns.org (8.14.3/8.14.3) with ESMTP id o0Q7Xb20002025 for ; Tue, 26 Jan 2010 18:33:37 +1100 (EST) (envelope-from peter@server.vk2pj.dyndns.org) Received: (from peter@localhost) by server.vk2pj.dyndns.org (8.14.3/8.14.3/Submit) id o0Q7Xbee002024 for freebsd-stable@freebsd.org; Tue, 26 Jan 2010 18:33:37 +1100 (EST) (envelope-from peter) Date: Tue, 26 Jan 2010 18:33:37 +1100 From: Peter Jeremy To: freebsd-stable@freebsd.org Message-ID: <20100126073336.GA1955@server.vk2pj.dyndns.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="Nq2Wo0NMKNjxTN9z" Content-Disposition: inline X-PGP-Key: http://members.optusnet.com.au/peterjeremy/pubkey.asc User-Agent: Mutt/1.5.20 (2009-06-14) Subject: uma_zalloc_arg complaining about non-sleepable locks X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jan 2010 07:33:41 -0000 --Nq2Wo0NMKNjxTN9z Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable I have just upgraded to 8-STABLE/amd64 from about 18 hours ago and am now getting regular (the following pair of messages about every minute) compaints as follows: kernel: uma_zalloc_arg: zone "mbuf" with the following non-sleepable locks = held: kernel: exclusive sleep mutex sp_lock (sp_lock) r =3D 0 (0xffffff000460bb00= ) locked @ /usr/src/sys/rpc/svc.c:1098 kernel: KDB: stack backtrace: kernel: db_trace_self_wrapper() at db_trace_self_wrapper+0x2a kernel: _witness_debugger() at _witness_debugger+0x2c kernel: witness_warn() at witness_warn+0x2c2 kernel: uma_zalloc_arg() at uma_zalloc_arg+0x29d kernel: nfs_realign() at nfs_realign+0x5f kernel: fha_assign() at fha_assign+0x2d8 kernel: svc_run_internal() at svc_run_internal+0x1ee kernel: svc_thread_start() at svc_thread_start+0xb kernel: fork_exit() at fork_exit+0x112 kernel: fork_trampoline() at fork_trampoline+0xe kernel: --- trap 0xc, rip =3D 0x80069e04c, rsp =3D 0x7fffffffe6d8, rbp =3D = 0x5 --- kernel: uma_zalloc_arg: zone "mbuf" with the following non-sleepable locks = held: kernel: exclusive sleep mutex sp_lock (sp_lock) r =3D 0 (0xffffff000460bb00= ) locked @ /usr/src/sys/rpc/svc.c:1098 kernel: KDB: stack backtrace: kernel: db_trace_self_wrapper() at db_trace_self_wrapper+0x2a kernel: _witness_debugger() at _witness_debugger+0x2c kernel: witness_warn() at witness_warn+0x2c2 kernel: uma_zalloc_arg() at uma_zalloc_arg+0x29d kernel: nfs_realign() at nfs_realign+0x5f kernel: fha_assign() at fha_assign+0x2d8 kernel: svc_run_internal() at svc_run_internal+0x1ee kernel: svc_thread_start() at svc_thread_start+0xb kernel: fork_exit() at fork_exit+0x112 kernel: fork_trampoline() at fork_trampoline+0xe kernel: --- trap 0xc, rip =3D 0x80069e04c, rsp =3D 0x7fffffffe6d8, rbp =3D = 0x5 --- It looks like NFS is missing some lock/unlock pairs. Has anyone else seen this? And does anyone have a fix? --=20 Peter Jeremy --Nq2Wo0NMKNjxTN9z Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.14 (FreeBSD) iEYEARECAAYFAktemtAACgkQ/opHv/APuIc6pQCfegJtvPmH2gdGOzU1GyNPZLIu br0AoJt8Xl1fwKDdxL7bpISTKPdpmL9I =XAxq -----END PGP SIGNATURE----- --Nq2Wo0NMKNjxTN9z-- From owner-freebsd-stable@FreeBSD.ORG Tue Jan 26 09:18:56 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 10AF91065672 for ; Tue, 26 Jan 2010 09:18:56 +0000 (UTC) (envelope-from freebsd-stable@m.gmane.org) Received: from lo.gmane.org (lo.gmane.org [80.91.229.12]) by mx1.freebsd.org (Postfix) with ESMTP id BA8B98FC0C for ; Tue, 26 Jan 2010 09:18:55 +0000 (UTC) Received: from list by lo.gmane.org with local (Exim 4.50) id 1NZhZT-0000Ci-6J for freebsd-stable@freebsd.org; Tue, 26 Jan 2010 10:18:51 +0100 Received: from lara.cc.fer.hr ([161.53.72.113]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 26 Jan 2010 10:18:51 +0100 Received: from ivoras by lara.cc.fer.hr with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 26 Jan 2010 10:18:51 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-stable@freebsd.org From: Ivan Voras Date: Tue, 26 Jan 2010 10:18:38 +0100 Lines: 17 Message-ID: References: <4B5DD7A2.4000101@FreeBSD.org> <4B5DE3C1.4060508@FreeBSD.org> <20100125185324.GA21007@icarus.home.lan> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: lara.cc.fer.hr User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.1.5) Gecko/20100118 Thunderbird/3.0 In-Reply-To: <20100125185324.GA21007@icarus.home.lan> Sender: news Subject: Re: 8.0-RELEASE/amd64 - full ZFS install - low read and write disk performance X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jan 2010 09:18:56 -0000 On 01/25/10 19:53, Jeremy Chadwick wrote: > That's just the thing -- I/O transactions, not to mention ZFS itself, > are CPU-bound. If you start seeing slow I/O as a result of the Atom's > limitations, I don't think there's anything that can be done about it. > Choose wisely. :-) It's not *that* terrible. They still do DMA and have more than decent (ICH) controllers so CPU is not really saturated. On my netbook with the 1st gen Atom and ICH7, reading the drive at full speed (cca 60 MB/s) barely even registers in sys and intr time. Unless ZFS compression is used, Atoms are enough for file servers [*] :) [*] Unless they are, like mine, paired with a Realtek NIC, which is the *real* performance bottleneck. From owner-freebsd-stable@FreeBSD.ORG Tue Jan 26 09:39:54 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D4F27106568B; Tue, 26 Jan 2010 09:39:54 +0000 (UTC) (envelope-from mitya@m4-new.master-telecom.ru) Received: from m4-new.master-telecom.ru (m4-new.master-telecom.ru [85.193.64.114]) by mx1.freebsd.org (Postfix) with ESMTP id 53ED28FC08; Tue, 26 Jan 2010 09:39:53 +0000 (UTC) Received: from m4-new.master-telecom.ru (localhost [127.0.0.1]) by m4-new.master-telecom.ru (8.13.8/8.13.8) with ESMTP id o0Q9T55F048593; Tue, 26 Jan 2010 12:29:05 +0300 (MSK) (envelope-from mitya@m4-new.master-telecom.ru) Received: (from mitya@localhost) by m4-new.master-telecom.ru (8.13.8/8.13.8/Submit) id o0Q9T5qD048592; Tue, 26 Jan 2010 12:29:05 +0300 (MSK) (envelope-from mitya) Date: Tue, 26 Jan 2010 12:29:05 +0300 From: Dmitry Sivachenko To: freebsd-stable@freebsd.org Message-ID: <20100126092905.GA47528@m4-new.master-telecom.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline WWW-Home-Page: http://mitya.pp.ru/ X-PGP-Key: http://mitya.pp.ru/mitya.asc User-Agent: Mutt/1.5.18 (2008-05-17) Cc: yongari@freebsd.org Subject: RELENG_7 if_nve panic X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jan 2010 09:39:54 -0000 Hello! I recompiled recent RELENG_7 and I get the following panic after trying to kldload if_nve (interesting stack frames are 12, 13, 14 I guess). Previous version of RELENG_7 (compiled in the middle of December) worked fine. Last few days I was trying to re-cvsup and always get the same panic. I get FreeBSD sources via cvsup (cvsup5.freebsd.org). Any suggestions? Thanks in advance! nve0: port 0xc800-0xc807 mem 0xfe02b000-0xfe02bfff irq 22 at device 20.0 on pci0 nve0: Ethernet address 00:18:f3:f4:73:1c miibus0: on nve0 e1000phy0: PHY 1 on miibus0 Fatal trap 12: page fault while in kernel mode cpuid = 0; apic id = 00 fault virtual address = 0x0 fault code = supervisor read data, page not present instruction pointer = 0x8:0xffffffff803259cd stack pointer = 0x10:0xffffff80210ed3e0 frame pointer = 0x10:0xffffff80210ed3f0 code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 845 (kldload) panic: from debugger cpuid = 0 KDB: stack backtrace: Uptime: 33s (kgdb) bt #0 doadump () at pcpu.h:195 #1 0xffffffff8028b1d8 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:418 #2 0xffffffff8028b63c in panic (fmt=Variable "fmt" is not available. ) at /usr/src/sys/kern/kern_shutdown.c:574 #3 0xffffffff80183567 in db_panic (addr=Variable "addr" is not available. ) at /usr/src/sys/ddb/db_command.c:446 #4 0xffffffff80183bcf in db_command (last_cmdp=0xffffffff806414e8, cmd_table=0x0, dopager=1) at /usr/src/sys/ddb/db_command.c:413 #5 0xffffffff80183de0 in db_command_loop () at /usr/src/sys/ddb/db_command.c:466 #6 0xffffffff801859c9 in db_trap (type=Variable "type" is not available. ) at /usr/src/sys/ddb/db_main.c:228 #7 0xffffffff802bb235 in kdb_trap (type=12, code=0, tf=0xffffff80210ed330) at /usr/src/sys/kern/subr_kdb.c:524 #8 0xffffffff8044a3f0 in trap_fatal (frame=0xffffff80210ed330, eva=Variable "eva" is not available. ) at /usr/src/sys/amd64/amd64/trap.c:772 9 0xffffffff8044a7c4 in trap_pfault (frame=0xffffff80210ed330, usermode=0) at /usr/src/sys/amd64/amd64/trap.c:693 #10 0xffffffff8044b0da in trap (frame=0xffffff80210ed330) at /usr/src/sys/amd64/amd64/trap.c:464 #11 0xffffffff804335fe in calltrap () at /usr/src/sys/amd64/amd64/exception.S:218 #12 0xffffffff803259cd in strcmp (s1=0x0, s2=0xffffffff80496f30 "msk") at /usr/src/sys/libkern/strcmp.c:45 #13 0xffffffff801caa3d in e1000phy_attach (dev=0xffffff0001532900) at /usr/src/sys/dev/mii/e1000phy.c:153 #14 0xffffffff802b54e9 in device_attach (dev=0xffffff0001532900) at device_if.h:178 #15 0xffffffff802b6bca in bus_generic_attach (dev=Variable "dev" is not available. ) at /usr/src/sys/kern/subr_bus.c:2923 #16 0xffffffff801ce1ee in miibus_attach (dev=0xffffff00016a6900) at /usr/src/sys/dev/mii/mii.c:186 #17 0xffffffff802b54e9 in device_attach (dev=0xffffff00016a6900) at device_if.h:178 #18 0xffffffff802b6bca in bus_generic_attach (dev=Variable "dev" is not available. ) at /usr/src/sys/kern/subr_bus.c:2923 From owner-freebsd-stable@FreeBSD.ORG Tue Jan 26 10:07:00 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C16D0106566C for ; Tue, 26 Jan 2010 10:07:00 +0000 (UTC) (envelope-from maurovale@gmail.com) Received: from mail-bw0-f213.google.com (mail-bw0-f213.google.com [209.85.218.213]) by mx1.freebsd.org (Postfix) with ESMTP id 4E3E58FC13 for ; Tue, 26 Jan 2010 10:06:59 +0000 (UTC) Received: by bwz5 with SMTP id 5so3476824bwz.3 for ; Tue, 26 Jan 2010 02:06:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=qAk/9bjnIN2Vxla3gycDqgS5lvo3YmmdAoQdKhg2gZw=; b=iSfWl9KA+XHmM9v22OdJdUNuk3kHBdxtBxWdicatDTV2rFcGxn+DcO9QW8uvOX4Jm8 Yd9Vb2Ur+o3g3NoeLavet4mBysbFvvyicjKj+ZPYe95OiOVK6ap5C/aYbV/uupb/ok7o Jpyz7A0a8AejXER+qxwg/R571eLs3lhlVSKvI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=O07FqCfTPs/DQVjkPd+PQrV0QQyBxxBliVdSwonDIJaXs6+x//+r7OvUS3UcLr4M3P UDhG5IsEKh4LEBwOUDs0J1KSBx9yf2dwU4f5eVOvd4lLnRAsSVaBV61jr8oZzClJBh7s qX6/1crcwwPqa7ljUrwwlJc+q2cKSZUQP7u74= MIME-Version: 1.0 Received: by 10.204.35.75 with SMTP id o11mr1726323bkd.15.1264500419135; Tue, 26 Jan 2010 02:06:59 -0800 (PST) In-Reply-To: <327c85b8398333978f642aa5dc2cbec4.squirrel@nyi.unixathome.org> References: <4AFCBD9C.1030306@langille.org> <327c85b8398333978f642aa5dc2cbec4.squirrel@nyi.unixathome.org> Date: Tue, 26 Jan 2010 10:06:59 +0000 Message-ID: <85d001331001260206l1b8831eei17bfe1f8a83cc566@mail.gmail.com> From: "M. Vale" To: Dan Langille Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: FreeBSD Stable Subject: Re: hald running 100% X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 26 Jan 2010 10:07:00 -0000 2010/1/25 Dan Langille > > On Mon, January 25, 2010 7:20 am, Ruben van Staveren wrote: > > > > On 13 Nov 2009, at 2:59, Dan Langille wrote: > > > >> -----BEGIN PGP SIGNED MESSAGE----- > >> Hash: SHA1 > >> > >> After upgrading to 8.0-PRERELEASE today, I'm seeing hald at 100% on both > >> my laptop and my desktop: > >> > >> > >> PID USERNAME THR PRI NICE SIZE RES STATE C TIME WCPU COMMAND > >> 1500 haldaemon 1 118 0 22944K 4904K CPU1 1 107:44 100.00% hald > >> > >> uptime was about 1:50 at this point. > >> > >> Seems to be relatively common from the posts I've seen. > >> > > > > Did you try to recompile the hald port ? > > I do not recall. But that sounds familiar. > > -- > Dan Langille -- http://langille.org/ > Hi, If you upgrade to FreeBSD 8 you have to remote the package libusb from your system. So remove the libusb package that HAL installs and then rebuild hal, something like: portmaster -rRfp hal-0.5.11_26 After that no more hal eating all your cpu :P Best Regards Mauro vale From owner-freebsd-stable@FreeBSD.ORG Tue Jan 26 11:00:49 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 800BB10656C0; Tue, 26 Jan 2010 11:00:49 +0000 (UTC) (envelope-from alexander@leidinger.net) Received: from mail.ebusiness-leidinger.de (mail.ebusiness-leidinger.de [217.11.53.44]) by mx1.freebsd.org (Postfix) with ESMTP id 250A98FC1E; Tue, 26 Jan 2010 11:00:48 +0000 (UTC) Received: from outgoing.leidinger.net (pD954F11F.dip.t-dialin.net [217.84.241.31]) by mail.ebusiness-leidinger.de (Postfix) with ESMTPSA id B1F55844021; Tue, 26 Jan 2010 12:00:41 +0100 (CET) Received: from webmail.leidinger.net (webmail.leidinger.net [192.168.1.102]) by outgoing.leidinger.net (Postfix) with ESMTP id A74A88BA6A; Tue, 26 Jan 2010 12:00:35 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=Leidinger.net; s=outgoing-alex; t=1264503636; bh=kifOH50GzAtqhidhRu/gQhV/eSLBMz9TA3eQZEnikw4=; h=Message-ID:Date:From:To:Cc:Subject:References:In-Reply-To: MIME-Version:Content-Type:Content-Transfer-Encoding; b=J3fdo1tZ5EXuERSfoIOpffPTgmByvGbbu1FTG64u4relzTCBuWtppKaADoZSMiB+S 70AwmmboT3UcxtD3Y3Jc/FI4iXMOh2aspXaejaPT5fXga5/meBVjGr7rRDXiQugMVw BC8HqVsSgwjR53JAEzCh1qCo4g89jZHG0/GuteqKEEG4mnmVlIXlGxUa5sBZF2vN/x ND13QOcK0O3FOD/LNHQxtRdw7X6xOnP4wVJ0bsO3+K12MWZGQeMF56nb1CW+x0++me jAMANRExdF8sCG5r68gb07X2KmJF9ztMsD9E2lLIk7la+G74u51Tut23hi1WMoJCaF 0OUcI8ZVX/GbQ== Received: (from www@localhost) by webmail.leidinger.net (8.14.3/8.13.8/Submit) id o0QB0VrT065244; Tue, 26 Jan 2010 12:00:31 +0100 (CET) (envelope-from Alexander@Leidinger.net) Received: from pslux.cec.eu.int (pslux.cec.eu.int [158.169.9.14]) by webmail.leidinger.net (Horde Framework) with HTTP; Tue, 26 Jan 2010 12:00:30 +0100 Message-ID: <20100126120030.15496xfctb8icfk8@webmail.leidinger.net> Date: Tue, 26 Jan 2010 12:00:30 +0100 From: Alexander Leidinger To: Dmitry Morozovsky References: <20100125191030.GG1643@garage.freebsd.pl> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; DelSp="Yes"; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: 7bit User-Agent: Dynamic Internet Messaging Program (DIMP) H3 (1.1.4) X-EBL-MailScanner-Information: Please contact the ISP for more information X-EBL-MailScanner-ID: B1F55844021.ECB94 X-EBL-MailScanner: Found to be clean X-EBL-MailScanner-SpamCheck: not spam, spamhaus-ZEN, SpamAssassin (not cached, score=0.521, required 6, autolearn=disabled, ALL_TRUSTED -1.44, DKIM_SIGNED 0.00, DKIM_VERIFIED -0.00, URIBL_BLACK 1.96) X-EBL-MailScanner-From: alexander@leidinger.net X-EBL-MailScanner-Watermark: 1265108444.03519@ejHGpZoEkWXr6H/50efCLg X-EBL-Spam-Status: No Cc: freebsd-stable@freebsd.org, Pawel Jakub Dawidek Subject: Re: ZFS panic on RELENG_7/i386 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 26 Jan 2010 11:00:49 -0000 Quoting Dmitry Morozovsky (from Tue, 26 Jan 2010 01:16:28 +0300 (MSK)): > On Mon, 25 Jan 2010, Dmitry Morozovsky wrote: > > DM> PJD> > I had a crash durinc rsync to ZFS today: > DM> PJD> > DM> PJD> Do you have recent 7-STABLE? Not sure if it was the same before MFC, > DM> > DM> root@woozle:/var/crash# uname -a > DM> FreeBSD woozle.rinet.ru 7.2-STABLE FreeBSD 7.2-STABLE #4: Mon > Dec 14 12:40:43 > DM> MSK 2009 marck@woozle.rinet.ru:/usr/obj/usr/src/sys/WOOZLE i386 > DM> > DM> I'll update to fresh sources and recheck, thanks. > DM> > DM> BTW, any thoughts of another topic I started a couple of weeks ago? > > Well, after updating to fresh system scrub finished without errors, and now > rsync is running, now copied 15G out of 150. You may want to switch the checksum algorithm to fletcher4. It (fletcher4 the default instead of fletcher2) is one of the few changes between 8-stable and 7-stable in ZFS, which I didn't merge. Bye, Alexander. -- Officers' club: We don't know but we've been told, our beer on tap is mighty cold. http://www.Leidinger.net Alexander @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137 From owner-freebsd-stable@FreeBSD.ORG Tue Jan 26 12:15:15 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CBBF3106566C for ; Tue, 26 Jan 2010 12:15:15 +0000 (UTC) (envelope-from Krzysztof.Dajka@agora.pl) Received: from mail.agora.pl (mail.agora.pl [193.42.230.56]) by mx1.freebsd.org (Postfix) with ESMTP id 3A8F58FC15 for ; Tue, 26 Jan 2010 12:15:14 +0000 (UTC) Received: from zcs01.agora.pl (vzcs03.agora.pl [10.205.98.92]) by mail.agora.pl (8.13.8/8.11.1) with ESMTP id o0QBAJco000870; Tue, 26 Jan 2010 12:10:19 +0100 Received: from localhost (localhost.localdomain [127.0.0.1]) by zcs01.agora.pl (Postfix) with ESMTP id 18A45B740; Tue, 26 Jan 2010 12:10:19 +0100 (CET) X-Virus-Scanned: amavisd-new at zcs01.agora.pl Received: from zcs01.agora.pl ([127.0.0.1]) by localhost (zcs01.agora.pl [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zvj+xNVn1WFM; Tue, 26 Jan 2010 12:10:18 +0100 (CET) Received: from t42.localnet (unknown [10.201.55.224]) by zcs01.agora.pl (Postfix) with ESMTPSA id 6B3F49DA1; Tue, 26 Jan 2010 12:10:18 +0100 (CET) From: Krzysztof Dajka Organization: Agora To: freebsd-stable@freebsd.org Date: Tue, 26 Jan 2010 12:10:12 +0100 User-Agent: KMail/1.12.4 (Linux/2.6.30-1-686; KDE/4.3.4; i686; ; ) References: <684e57ec1001231226p447ea769q6379c1aa099b0216@mail.gmail.com> <20100125115744.04a77487.torfinn.ingolfsen@broadpark.no> In-Reply-To: <20100125115744.04a77487.torfinn.ingolfsen@broadpark.no> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201001261210.12475.kdajka@new.agora.pl> Cc: Torfinn Ingolfsen Subject: Re: Extra keys in multimedia keyboard doesn't work X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 26 Jan 2010 12:15:15 -0000 On Monday, 25 of January 2010 11:57:44 Torfinn Ingolfsen wrote: > On Sun, 24 Jan 2010 23:47:46 +0000 > > Krzysztof Dajka wrote: > > I did check my keyboard with FreeBSD 7.2 and it wasn't supported either. > > Xev also didn't return anything. > > Di you try this: http://www.freshports.org/misc/hotkeys/ > Perhaps it will work? > > There is also this: http://www.freshports.org/sysutils/usbhotkey/ > > HTH > Thanks, I'll try that when I'll get home. From owner-freebsd-stable@FreeBSD.ORG Tue Jan 26 12:26:40 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9EE43106566B for ; Tue, 26 Jan 2010 12:26:40 +0000 (UTC) (envelope-from bartosz.stec@it4pro.pl) Received: from mainframe.kkip.pl (kkip.pl [87.105.164.78]) by mx1.freebsd.org (Postfix) with ESMTP id 491E88FC13 for ; Tue, 26 Jan 2010 12:26:39 +0000 (UTC) Received: from mb01.admin.lan.kkip.pl ([10.66.3.254]) by mainframe.kkip.pl with esmtpsa (TLSv1:CAMELLIA256-SHA:256) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1NZk5s-000PZJ-1C; Tue, 26 Jan 2010 13:00:35 +0100 Message-ID: <4B5ED95D.6080601@it4pro.pl> Date: Tue, 26 Jan 2010 13:00:29 +0100 From: Bartosz Stec Organization: IT4Pro User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; pl; rv:1.9.1.7) Gecko/20100111 Lightning/1.0b1 Thunderbird/3.0.1 MIME-Version: 1.0 To: Dmitry Sivachenko References: <20100126092905.GA47528@m4-new.master-telecom.ru> In-Reply-To: <20100126092905.GA47528@m4-new.master-telecom.ru> X-Stationery: 0.5.1 Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: 7bit X-Authenticated-User: bartosz.stec@it4pro.pl X-Authenticator: plain X-Sender-Verify: SUCCEEDED (sender exists & accepts mail) X-Spam-Score: -5.7 X-Spam-Score-Int: -56 X-Exim-Version: 4.71 (build at 09-Dec-2009 19:51:34) X-Date: 2010-01-26 13:00:35 X-Connected-IP: 10.66.3.254:2611 X-Message-Linecount: 37 X-Body-Linecount: 21 X-Message-Size: 1432 X-Body-Size: 726 X-Received-Count: 1 X-Recipient-Count: 2 X-Local-Recipient-Count: 2 X-Local-Recipient-Defer-Count: 0 X-Local-Recipient-Fail-Count: 0 Cc: FreeBSD Stable Subject: Re: RELENG_7 if_nve panic X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jan 2010 12:26:40 -0000 W dniu 2010-01-26 10:29, Dmitry Sivachenko pisze: > Hello! > > I recompiled recent RELENG_7 and I get the following panic after > trying to kldload if_nve (interesting stack frames are 12, 13, 14 I guess). > Previous version of RELENG_7 (compiled in the middle of December) > worked fine. Last few days I was trying to re-cvsup and always get the > same panic. I get FreeBSD sources via cvsup (cvsup5.freebsd.org). > > Any suggestions? > > As well as I know nve driver is based on nvidia binaries (and it's buggy), and that's way it was replaced by nfe driver as default for nvidia based NICs as soon as it was ported from OpenBSD. So my suggestion - if you just need NIC working, use nfe not nve. -- Bartosz Stec From owner-freebsd-stable@FreeBSD.ORG Tue Jan 26 12:32:34 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B25581065670 for ; Tue, 26 Jan 2010 12:32:34 +0000 (UTC) (envelope-from nickolasbug@gmail.com) Received: from mail-bw0-f213.google.com (mail-bw0-f213.google.com [209.85.218.213]) by mx1.freebsd.org (Postfix) with ESMTP id 3F54A8FC22 for ; Tue, 26 Jan 2010 12:32:33 +0000 (UTC) Received: by bwz5 with SMTP id 5so3563310bwz.3 for ; Tue, 26 Jan 2010 04:32:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=i193Lzn7TpJiufrfEBAzqRrixcPSrhwwcElMo0PokhY=; b=bG3FrbTrhplkXro7QolkJBHhs1SqkZNoXRZrf2qVGloStsX5Rw5Gy6n7dmYJHxLHKS fL9WNi8KjbcA5LV+fzBlOTXCCuGhJ5aCgieDu40IRQdyAWzZH0aX/vrOjoqmZBvTuh6/ ybnM1+ZPyVRA11YlBe7iBV3BUUnyxZMW8AE60= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=X5LFJmbckhad785V9hbdYnbAu0JaELvusUor0dj+574LaO7h5JsL0U94VuzCAS3MC8 h4ysX8qXiF13zBeW+/3hAT/81as8tujupYXAN7h01jVwRfvc6aaaBw6bicosh3yU122O Aa42jkDCjbabhNlwDdbI6uxfIuR3jf5EW0vqU= MIME-Version: 1.0 Received: by 10.204.38.84 with SMTP id a20mr4738296bke.39.1264509153055; Tue, 26 Jan 2010 04:32:33 -0800 (PST) In-Reply-To: <20100126044041.GA33624@icarus.home.lan> References: <20100126044041.GA33624@icarus.home.lan> Date: Tue, 26 Jan 2010 14:32:32 +0200 Message-ID: <368117f31001260432h365c762at9c8664e5ccb2310@mail.gmail.com> From: nickolasbug@gmail.com To: Jeremy Chadwick Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-stable@freebsd.org Subject: Re: Looking for testers: atacontrol SMART support X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 26 Jan 2010 12:32:34 -0000 2010/1/26 Jeremy Chadwick : > As mentioned a while back on the list[1], I worked on getting atacontrol > to spit out SMART statistics for ATA disks. =A0Specifically, this would b= e > those using the standard ata(4) layer (including ataahci.ko and > similar), but not ahci(4) (ahci.ko), which uses ATA/CAM. > > Output resembles the following: > > ID# =A0 Attribute Name =A0 =A0 =A0 =A0 =A0 =A0 =A0Curr Worst Thrsh =A0Byt= es > --- =A0 ------------------------- =A0----- ----- ----- =A0---------------= -- > =A01 =A0 Raw Read Error Rate =A0 =A0 =A0 =A0 =A0200 =A0 200 =A0 =A051 =A0= 00 00 00 00 00 00 > =A03 =A0 Spin Up Time =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 234 =A0 229 =A0 =A0= 21 =A053 20 00 00 00 00 > =A04 =A0 Start/Stop Count =A0 =A0 =A0 =A0 =A0 =A0 100 =A0 100 =A0 =A0 0 = =A011 00 00 00 00 00 > =A05 =A0 Reallocated Sector Count =A0 =A0 200 =A0 200 =A0 140 =A000 00 00= 00 00 00 > =A07 =A0 Seek Error Rate =A0 =A0 =A0 =A0 =A0 =A0 =A0200 =A0 200 =A0 =A0 0= =A000 00 00 00 00 00 > =A09 =A0 Power On Hours Count =A0 =A0 =A0 =A0 =A095 =A0 =A095 =A0 =A0 0 = =A09b 0f 00 00 00 00 > =A010 =A0 Spin Retry Count =A0 =A0 =A0 =A0 =A0 =A0 100 =A0 253 =A0 =A0 0 = =A000 00 00 00 00 00 > =A011 =A0 Calibration Retry Count =A0 =A0 =A0100 =A0 253 =A0 =A0 0 =A000 = 00 00 00 00 00 > =A012 =A0 Power Cycle Count =A0 =A0 =A0 =A0 =A0 =A0100 =A0 100 =A0 =A0 0 = =A00c 00 00 00 00 00 > 192 =A0 Power Off Retract Count =A0 =A0 =A0200 =A0 200 =A0 =A0 0 =A00b 00= 00 00 00 00 > 193 =A0 Load Cycle Count =A0 =A0 =A0 =A0 =A0 =A0 200 =A0 200 =A0 =A0 0 = =A011 00 00 00 00 00 > 194 =A0 Temperature =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0116 =A0 113 =A0 = =A0 0 =A022 00 00 00 00 00 > 196 =A0 Reallocated Event Count =A0 =A0 =A0200 =A0 200 =A0 =A0 0 =A000 00= 00 00 00 00 > 197 =A0 Current Pending Sectors =A0 =A0 =A0200 =A0 200 =A0 =A0 0 =A000 00= 00 00 00 00 > 198 * Uncorrected Sector Count =A0 =A0 200 =A0 200 =A0 =A0 0 =A000 00 00 = 00 00 00 > 199 =A0 UltraDMA CRC Error Count =A0 =A0 200 =A0 200 =A0 =A0 0 =A000 00 0= 0 00 00 00 > 200 * Write Error Rate =A0 =A0 =A0 =A0 =A0 =A0 200 =A0 200 =A0 =A0 0 =A00= 0 00 00 00 00 00 > --- =A0 ------------------------- =A0----- ----- ----- =A0---------------= -- > =A0 =A0* =3D values only updated after a short/long/offline test > > Things to note: > > - I've only been testing on RELENG_8 amd64. =A0The code should work on > i386, but if something explodes, let me know. =A0I don't recommend > patching RELENG_7 or even a RELEASE tag with this. > > - I did my best to document the SMART "stuff" throughout the source. > Much to my disappointment SMART attributes are not part of the ATA > or ACS specification; they're mentioned, but attributes and their > interpretation are 100% vendor specific. =A0Decoding them will involve > examining the smartmontools source, which takes time. > > This is why there is no smartmontools "RAW_VALUE" equivalent -- the > code for that piece simply hasn't been written. =A0Instead, I display > the raw bytes associated with each attribute. =A0This should help with > debugging (for the time being). =A0I'll work things out... =A0:-) As I know, there is no decode for raw value (even in smartmontools). So, you can just store this six bytes in 64-bit variable and print it out. > > - All operations done are read-only (in fact the device is opened in > read-only mode). =A0There may be plans down the road to implement things > like inducing SMART short/long/offline tests, but for now I want to > get attribute support in there. Implementation of tests is quite easy. I've wrote nearly the same project for linux some time ago, so I can htlp you with this project. Please, mail me if you're get interested in my help. wbr, Nickolas From owner-freebsd-stable@FreeBSD.ORG Tue Jan 26 12:42:20 2010 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1A86D106566C for ; Tue, 26 Jan 2010 12:42:20 +0000 (UTC) (envelope-from ru@FreeBSD.org) Received: from mail.vega.ru (mail.vega.ru [90.156.167.5]) by mx1.freebsd.org (Postfix) with ESMTP id CCB3F8FC1C for ; Tue, 26 Jan 2010 12:42:19 +0000 (UTC) Received: from [10.100.124.99] (helo=edoofus.dev.vega.ru) by mail.vega.ru with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1NZkkM-0008R2-3F; Tue, 26 Jan 2010 15:42:18 +0300 Date: Tue, 26 Jan 2010 15:41:54 +0300 From: Ruslan Ermilov To: Nick Rogers Message-ID: <20100126124154.GA72180@edoofus.dev.vega.ru> References: <147432021001251901u7d56f014n83e834061fd09fec@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <147432021001251901u7d56f014n83e834061fd09fec@mail.gmail.com> Cc: stable@freebsd.org Subject: Re: netstat output changes in 8.0? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jan 2010 12:42:20 -0000 On Mon, Jan 25, 2010 at 07:01:46PM -0800, Nick Rogers wrote: > Before 8.0-RELEASE, if I ran netstat -rn, it listed a separate route for > each host on the network, along with its MAC address. For example ... > > 172.20.172.17 00:02:b3:2f:64:6a UHLW 1 105712 1500 > vlan172 595 > 172.20.172.20 00:1e:c9:bb:7c:a9 UHLW 1 1002 1500 > vlan172 598 > 172.20.172.22 00:14:5e:16:bb:b6 UHLW 1 107 1500 > vlan172 491 > > This behavior seems to have changed in 8.0, where now only the > locally-assigned IP addresses and related CIDRs are displayed. >From src/UPDATING: : 20081214: : __FreeBSD_version 800059 incorporates the new arp-v2 rewrite. : RTF_CLONING, RTF_LLINFO and RTF_WASCLONED flags are eliminated. : The new code reduced struct rtentry{} by 16 bytes on 32-bit : architecture and 40 bytes on 64-bit architecture. The userland : applications "arp" and "ndp" have been updated accordingly. : The output from "netstat -r" shows only routing entries and : none of the L2 information. > Is there any way to get this behavior back, perhaps with a new flag that I > am not able to find? Or some sysctl? I have a script that was relying on > each host's "expire" flag in the routing table to determine when the MAC > address first appeared on the network according to ARP. If you need to know when a particular ARP entry expires, a variation of the following patch can be used, perhaps hiding this output by the -v (verbose) option. %%% Index: arp.c =================================================================== --- arp.c (revision 203016) +++ arp.c (working copy) @@ -101,7 +101,8 @@ static int nflag; /* no reverse dns lookups */ static char *rifname; -static int expire_time, flags, doing_proxy, proxy_only; +static time_t expire_time; +static int flags, doing_proxy, proxy_only; /* which function we're supposed to do */ #define F_GET 1 @@ -594,6 +595,15 @@ printf(" on %s", ifname); if (rtm->rtm_rmx.rmx_expire == 0) printf(" permanent"); + else { + static struct timeval tv; + if (tv.tv_sec == 0) + gettimeofday(&tv, 0); + if ((expire_time = rtm->rtm_rmx.rmx_expire - tv.tv_sec) > 0) + printf(" expires %d", (int)expire_time); + else + printf(" expired"); + } if (addr->sin_other & SIN_PROXY) printf(" published (proxy only)"); if (rtm->rtm_flags & RTF_ANNOUNCE) %%% Cheers, -- Ruslan Ermilov ru@FreeBSD.org FreeBSD committer From owner-freebsd-stable@FreeBSD.ORG Tue Jan 26 12:48:11 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 58B07106566C for ; Tue, 26 Jan 2010 12:48:11 +0000 (UTC) (envelope-from mitya@m4-new.master-telecom.ru) Received: from m4-new.master-telecom.ru (m4-new.master-telecom.ru [85.193.64.114]) by mx1.freebsd.org (Postfix) with ESMTP id D64C38FC0A for ; Tue, 26 Jan 2010 12:48:10 +0000 (UTC) Received: from m4-new.master-telecom.ru (localhost [127.0.0.1]) by m4-new.master-telecom.ru (8.13.8/8.13.8) with ESMTP id o0QCm8JD069636; Tue, 26 Jan 2010 15:48:08 +0300 (MSK) (envelope-from mitya@m4-new.master-telecom.ru) Received: (from mitya@localhost) by m4-new.master-telecom.ru (8.13.8/8.13.8/Submit) id o0QCm8s0069635; Tue, 26 Jan 2010 15:48:08 +0300 (MSK) (envelope-from mitya) Date: Tue, 26 Jan 2010 15:48:08 +0300 From: Dmitry Sivachenko To: Bartosz Stec Message-ID: <20100126124808.GA69438@m4-new.master-telecom.ru> References: <20100126092905.GA47528@m4-new.master-telecom.ru> <4B5ED95D.6080601@it4pro.pl> MIME-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: <4B5ED95D.6080601@it4pro.pl> WWW-Home-Page: http://mitya.pp.ru/ X-PGP-Key: http://mitya.pp.ru/mitya.asc User-Agent: Mutt/1.5.18 (2008-05-17) Cc: FreeBSD Stable Subject: Re: RELENG_7 if_nve panic X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jan 2010 12:48:11 -0000 On Tue, Jan 26, 2010 at 01:00:29PM +0100, Bartosz Stec wrote: > W dniu 2010-01-26 10:29, Dmitry Sivachenko pisze: > > Hello! > > > > I recompiled recent RELENG_7 and I get the following panic after > > trying to kldload if_nve (interesting stack frames are 12, 13, 14 I guess). > > Previous version of RELENG_7 (compiled in the middle of December) > > worked fine. Last few days I was trying to re-cvsup and always get the > > same panic. I get FreeBSD sources via cvsup (cvsup5.freebsd.org). > > > > Any suggestions? > > > > > As well as I know nve driver is based on nvidia binaries (and it's > buggy), and that's way it was replaced by nfe driver as default for > nvidia based NICs as soon as it was ported from OpenBSD. > So my suggestion - if you just need NIC working, use nfe not nve. > Thanks for reminding me about nfe. I just tried it and it does work. I tried nfe sometime in the summer and it did not work on my hardware. That is why I was sticking to nve. Now it seems I can switch to nfe. (but nve is still broken if someone cares). From owner-freebsd-stable@FreeBSD.ORG Tue Jan 26 13:09:47 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EC10E106566B; Tue, 26 Jan 2010 13:09:47 +0000 (UTC) (envelope-from marck@rinet.ru) Received: from woozle.rinet.ru (woozle.rinet.ru [195.54.192.68]) by mx1.freebsd.org (Postfix) with ESMTP id 3DBC28FC2C; Tue, 26 Jan 2010 13:09:47 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by woozle.rinet.ru (8.14.3/8.14.3) with ESMTP id o0QD9jFD066307; Tue, 26 Jan 2010 16:09:45 +0300 (MSK) (envelope-from marck@rinet.ru) Date: Tue, 26 Jan 2010 16:09:45 +0300 (MSK) From: Dmitry Morozovsky To: Alexander Leidinger In-Reply-To: <20100126120030.15496xfctb8icfk8@webmail.leidinger.net> Message-ID: References: <20100125191030.GG1643@garage.freebsd.pl> <20100126120030.15496xfctb8icfk8@webmail.leidinger.net> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) X-NCC-RegID: ru.rinet X-OpenPGP-Key-ID: 6B691B03 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.3 (woozle.rinet.ru [0.0.0.0]); Tue, 26 Jan 2010 16:09:45 +0300 (MSK) Cc: Pawel Jakub Dawidek , freebsd-stable@freebsd.org Subject: Re: ZFS panic on RELENG_7/i386 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 26 Jan 2010 13:09:48 -0000 On Tue, 26 Jan 2010, Alexander Leidinger wrote: AL> > Well, after updating to fresh system scrub finished without errors, and AL> > now AL> > rsync is running, now copied 15G out of 150. AL> AL> You may want to switch the checksum algorithm to fletcher4. It (fletcher4 AL> the default instead of fletcher2) is one of the few changes between 8-stable AL> and 7-stable in ZFS, which I didn't merge. will do, thank you. is fletcher4 faster? -- Sincerely, D.Marck [DM5020, MCK-RIPE, DM3-RIPN] [ FreeBSD committer: marck@FreeBSD.org ] ------------------------------------------------------------------------ *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- marck@rinet.ru *** ------------------------------------------------------------------------ From owner-freebsd-stable@FreeBSD.ORG Tue Jan 26 13:57:24 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1B2EB1065672 for ; Tue, 26 Jan 2010 13:57:24 +0000 (UTC) (envelope-from gerrit@pmp.uni-hannover.de) Received: from mrelay1.uni-hannover.de (mrelay1.uni-hannover.de [130.75.2.106]) by mx1.freebsd.org (Postfix) with ESMTP id 9922E8FC14 for ; Tue, 26 Jan 2010 13:57:23 +0000 (UTC) Received: from www.pmp.uni-hannover.de (www.pmp.uni-hannover.de [130.75.117.2]) by mrelay1.uni-hannover.de (8.14.2/8.14.2) with ESMTP id o0QDvKfJ015286; Tue, 26 Jan 2010 14:57:21 +0100 Received: from pmp.uni-hannover.de (arc.pmp.uni-hannover.de [130.75.117.1]) by www.pmp.uni-hannover.de (Postfix) with SMTP id 30D5924; Tue, 26 Jan 2010 14:57:20 +0100 (CET) Date: Tue, 26 Jan 2010 14:57:20 +0100 From: Gerrit =?ISO-8859-1?Q?K=FChn?= To: Jeremy Chadwick Message-Id: <20100126145720.ad9115ff.gerrit@pmp.uni-hannover.de> In-Reply-To: <20100119112449.GA73052@icarus.home.lan> References: <4B54C100.9080906@mail.zedat.fu-berlin.de> <4B54C5EE.5070305@pp.dyndns.biz> <201001191250.23625.doconnor@gsoft.com.au> <7346c5c61001181841j3653a7c3m32bc033c8c146a92@mail.gmail.com> <4B557B5A.8040902@pp.dyndns.biz> <20100119095736.GA71824@icarus.home.lan> <20100119110724.ec01a3ed.gerrit@pmp.uni-hannover.de> <20100119112449.GA73052@icarus.home.lan> Organization: Albert-Einstein-Institut (MPI =?ISO-8859-1?Q?f=FCr?= Gravitationsphysik & IGP =?ISO-8859-1?Q?Universit=E4t?= Hannover) X-Mailer: Sylpheed 2.7.1 (GTK+ 2.18.4; i386-portbld-freebsd7.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-PMX-Version: 5.5.9.388399, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2010.1.26.134534 Cc: freebsd-stable@freebsd.org Subject: Re: immense delayed write to file system (ZFS and UFS2), performance issues X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jan 2010 13:57:24 -0000 On Tue, 19 Jan 2010 03:24:49 -0800 Jeremy Chadwick wrote about Re: immense delayed write to file system (ZFS and UFS2), performance issues: JC> So which drive models above are experiencing a continual increase in JC> SMART attribute 193 (Load Cycle Count)? My guess is that some of the JC> WD Caviar Green models, and possibly all of the RE2-GP and RE4-GP JC> models are experiencing this problem. Just to add some more info: I contacted WD support about the problem with RE4 drives and received a firmware update by email today which is supposed to fix the problem. Did not try it yet, though. I am still busy replacing RE2-disks with updated drives. I came across a very strange thing with zfs. Actually I had the following pool layout: mclane# zpool status pool: tank state: ONLINE scrub: none requested config: NAME STATE READ WRITE CKSUM tank ONLINE 0 0 0 raidz1 ONLINE 0 0 0 ad8 ONLINE 0 0 0 ad10 ONLINE 0 0 0 ad12 ONLINE 0 0 0 spares ad14 AVAIL errors: No known data errors All disks still have the firmware bug, so I want to replace them with disks that I already fixed. I put in a updated drive as ad18 and wanted to replace ad12 to get the drive with the broken firmware out: mclane# zpool replace tank /dev/ad12 /dev/ad18 mclane# zpool status pool: tank state: ONLINE status: One or more devices is currently being resilvered. The pool will continue to function, possibly in a degraded state. action: Wait for the resilver to complete. scrub: resilver in progress for 0h0m, 0.01% done, 52h51m to go config: NAME STATE READ WRITE CKSUM tank ONLINE 0 0 0 raidz1 ONLINE 0 0 0 ad8 ONLINE 0 0 0 7.21M resilvered ad10 ONLINE 0 0 0 7.22M resilvered replacing ONLINE 0 0 0 ad12 ONLINE 0 0 0 ad18 ONLINE 0 0 0 10.7M resilvered spares ad14 AVAIL errors: No known data errors However, something must have gone wrong during the resilvering process and it now looks like this: mclane# zpool status pool: tank state: DEGRADED status: One or more devices has experienced an unrecoverable error. An attempt was made to correct the error. Applications are unaffected. action: Determine if the device needs to be replaced, and clear the errors using 'zpool clear' or replace the device with 'zpool replace'. see: http://www.sun.com/msg/ZFS-8000-9P scrub: resilver completed after 2h39m with 0 errors on Tue Jan 26 14:00:00 2010 config: NAME STATE READ WRITE CKSUM tank DEGRADED 0 0 0 raidz1 DEGRADED 0 0 0 ad8 ONLINE 0 0 0 975M resilvered ad10 ONLINE 0 0 142 974M resilvered replacing DEGRADED 0 7.25M 0 ad12 ONLINE 0 0 0 ad18 REMOVED 0 1 0 79.4M resilvered spares ad14 AVAIL errors: No known data errors What is going on here? ad18 obviously detached during the process. /var/log/messages just gives me Jan 26 11:23:33 mclane kernel: ad18: FAILURE - device detached Additionally ad10 obviously produced chksum errors. What do I do about the degraded replacing process? Can I terminate it somehow and maybe replace ad10 first? Any other hints? cu Gerrit From owner-freebsd-stable@FreeBSD.ORG Tue Jan 26 14:30:24 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EF8A11065672 for ; Tue, 26 Jan 2010 14:30:23 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from qmta06.emeryville.ca.mail.comcast.net (qmta06.emeryville.ca.mail.comcast.net [76.96.30.56]) by mx1.freebsd.org (Postfix) with ESMTP id D96F38FC21 for ; Tue, 26 Jan 2010 14:30:22 +0000 (UTC) Received: from omta12.emeryville.ca.mail.comcast.net ([76.96.30.44]) by qmta06.emeryville.ca.mail.comcast.net with comcast id aDH21d0020x6nqcA6EWP6s; Tue, 26 Jan 2010 14:30:23 +0000 Received: from koitsu.dyndns.org ([98.248.46.159]) by omta12.emeryville.ca.mail.comcast.net with comcast id aEWN1d00E3S48mS8YEWNZR; Tue, 26 Jan 2010 14:30:23 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id 5C49D1E3035; Tue, 26 Jan 2010 06:30:21 -0800 (PST) Date: Tue, 26 Jan 2010 06:30:21 -0800 From: Jeremy Chadwick To: Gerrit =?iso-8859-1?Q?K=FChn?= Message-ID: <20100126143021.GA47535@icarus.home.lan> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit User-Agent: Mutt/1.5.20 (2009-06-14) Cc: freebsd-stable@freebsd.org Subject: Re: ZFS "zpool replace" problems X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 26 Jan 2010 14:30:24 -0000 I'm removing the In-Reply-To mail headers for this thread, as you've now hijacked it for a different purpose. Please don't do this; start a new thread altogether. :-) On Tue, Jan 26, 2010 at 02:57:20PM +0100, Gerrit Kühn wrote: > I am still busy replacing RE2-disks with updated drives. I came across a > very strange thing with zfs. Actually I had the following pool layout: > > mclane# zpool status > pool: tank > state: ONLINE > scrub: none requested > config: > > NAME STATE READ WRITE CKSUM > tank ONLINE 0 0 0 > raidz1 ONLINE 0 0 0 > ad8 ONLINE 0 0 0 > ad10 ONLINE 0 0 0 > ad12 ONLINE 0 0 0 > spares > ad14 AVAIL > > errors: No known data errors > > All disks still have the firmware bug, so I want to replace them with > disks that I already fixed. I put in a updated drive as ad18 and > wanted to replace ad12 to get the drive with the broken firmware out: > > mclane# zpool replace tank /dev/ad12 /dev/ad18 > mclane# zpool status > pool: tank > state: ONLINE > status: One or more devices is currently being resilvered. The pool will > continue to function, possibly in a degraded state. > action: Wait for the resilver to complete. > scrub: resilver in progress for 0h0m, 0.01% done, 52h51m to go > config: > > NAME STATE READ WRITE CKSUM > tank ONLINE 0 0 0 > raidz1 ONLINE 0 0 0 > ad8 ONLINE 0 0 0 7.21M resilvered > ad10 ONLINE 0 0 0 7.22M resilvered > replacing ONLINE 0 0 0 > ad12 ONLINE 0 0 0 > ad18 ONLINE 0 0 0 10.7M resilvered > spares > ad14 AVAIL > > errors: No known data errors > > However, something must have gone wrong during the resilvering process and > it now looks like this: > > mclane# zpool status > pool: tank > state: DEGRADED > status: One or more devices has experienced an unrecoverable error. An > attempt was made to correct the error. Applications are > unaffected. action: Determine if the device needs to be replaced, and > clear the errors using 'zpool clear' or replace the device with 'zpool > replace'. see: http://www.sun.com/msg/ZFS-8000-9P > scrub: resilver completed after 2h39m with 0 errors on Tue Jan 26 > 14:00:00 2010 config: > > NAME STATE READ WRITE CKSUM > tank DEGRADED 0 0 0 > raidz1 DEGRADED 0 0 0 > ad8 ONLINE 0 0 0 975M resilvered > ad10 ONLINE 0 0 142 974M resilvered > replacing DEGRADED 0 7.25M 0 > ad12 ONLINE 0 0 0 > ad18 REMOVED 0 1 0 79.4M resilvered > spares > ad14 AVAIL > > errors: No known data errors > > > What is going on here? ad18 obviously detached during the > process. /var/log/messages just gives me > > Jan 26 11:23:33 mclane kernel: ad18: FAILURE - device detached > > Additionally ad10 obviously produced chksum errors. What do I do about the > degraded replacing process? Can I terminate it somehow and maybe replace > ad10 first? Any other hints? I'm not sure how the above is supposed to work (I haven't personally tried it), but: 1) Why didn't you offline the ad10 disk first? zpool offline tank ad10 2) How did you attach ad18? Did you tell the system about it using atacontrol? If so, what commands did you use? 3) Can you please provide uname -a output, as well as relevant dmesg output to show what kind of SATA controller you have, what's attached to what, etc.? -- | Jeremy Chadwick jdc@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Tue Jan 26 15:03:23 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 667EB1065693 for ; Tue, 26 Jan 2010 15:03:23 +0000 (UTC) (envelope-from gerrit@pmp.uni-hannover.de) Received: from mrelay1.uni-hannover.de (mrelay1.uni-hannover.de [130.75.2.106]) by mx1.freebsd.org (Postfix) with ESMTP id EA1F48FC1A for ; Tue, 26 Jan 2010 15:03:22 +0000 (UTC) Received: from www.pmp.uni-hannover.de (www.pmp.uni-hannover.de [130.75.117.2]) by mrelay1.uni-hannover.de (8.14.2/8.14.2) with ESMTP id o0QF3KA2018799; Tue, 26 Jan 2010 16:03:21 +0100 Received: from pmp.uni-hannover.de (arc.pmp.uni-hannover.de [130.75.117.1]) by www.pmp.uni-hannover.de (Postfix) with SMTP id 3FBFA4F; Tue, 26 Jan 2010 16:03:20 +0100 (CET) Date: Tue, 26 Jan 2010 16:03:20 +0100 From: Gerrit =?ISO-8859-1?Q?K=FChn?= To: Jeremy Chadwick Message-Id: <20100126160320.6ed67b92.gerrit@pmp.uni-hannover.de> In-Reply-To: <20100126143021.GA47535@icarus.home.lan> References: <20100126143021.GA47535@icarus.home.lan> Organization: Albert-Einstein-Institut (MPI =?ISO-8859-1?Q?f=FCr?= Gravitationsphysik & IGP =?ISO-8859-1?Q?Universit=E4t?= Hannover) X-Mailer: Sylpheed 2.7.1 (GTK+ 2.18.4; i386-portbld-freebsd7.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-PMX-Version: 5.5.9.388399, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2010.1.26.145416 Cc: freebsd-stable@freebsd.org Subject: Re: ZFS "zpool replace" problems X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 26 Jan 2010 15:03:23 -0000 On Tue, 26 Jan 2010 06:30:21 -0800 Jeremy Chadwick wrote about Re: ZFS "zpool replace" problems: JC> I'm removing the In-Reply-To mail headers for this thread, as you've JC> now hijacked it for a different purpose. Please don't do this; start JC> a new thread altogether. :-) Thanks. You're perfectly right, I should have done that. JC> I'm not sure how the above is supposed to work (I haven't personally JC> tried it), but: JC> JC> 1) Why didn't you offline the ad10 disk first? JC> zpool offline tank ad10 Well, probably because I thought that zfs would simply handle the situation. I just wanted to replace drive A with drive B, so this was quite straight-forward for me. JC> 2) How did you attach ad18? Did you tell the system about it using JC> atacontrol? If so, what commands did you use? Yes. The drives did not appear automatically (verified with atacontrol list). Then I first tried reinit ata9, but that did not work out, so I did a detach/attach for ata9, then the drive was there (with list and also the device node appeared). JC> 3) Can you please provide uname -a output, as well as relevant dmesg JC> output to show what kind of SATA controller you have, what's JC> attached to what, etc.? Of course (dmesg is not there anymore, I use pciconf -vl and atacontrol instead): ATA channel 0: Master: no device present Slave: acd0 ATA/ATAPI revision 0 ATA channel 1: Master: no device present Slave: no device present ATA channel 2: Master: ad4 SATA revision 2.x Slave: no device present ATA channel 3: Master: ad6 SATA revision 2.x Slave: no device present ATA channel 4: Master: ad8 SATA revision 2.x Slave: no device present ATA channel 5: Master: ad10 SATA revision 2.x Slave: no device present ATA channel 6: Master: ad12 SATA revision 2.x Slave: no device present ATA channel 7: Master: ad14 SATA revision 2.x Slave: no device present ATA channel 8: Master: no device present Slave: no device present ATA channel 9: Master: no device present Slave: no device present FreeBSD mclane.rt.aei.uni-hannover.de 7.2-STABLE FreeBSD 7.2-STABLE #0: Mon Sep 7 11:01:56 CEST 2009 root@mclane.rt.aei.uni-hannover.de:/usr/obj/usr/src/sys/MCLANE.72 amd64 The first six drives (up to ad14) are connected onboard (Supermicro dual opteron board with mcp55): atapci1@pci0:0:5:0: class=0x010485 card=0x161115d9 chip=0x037f10de rev=0xa3 hdr=0x00 vendor = 'Nvidia Corp' device = 'MCP55 SATA/RAID Controller (MCP55S)' class = mass storage subclass = RAID atapci2@pci0:0:5:1: class=0x010485 card=0x161115d9 chip=0x037f10de rev=0xa3 hdr=0x00 vendor = 'Nvidia Corp' device = 'MCP55 SATA/RAID Controller (MCP55S)' class = mass storage subclass = RAID atapci3@pci0:0:5:2: class=0x010485 card=0x161115d9 chip=0x037f10de rev=0xa3 hdr=0x00 vendor = 'Nvidia Corp' device = 'MCP55 SATA/RAID Controller (MCP55S)' class = mass storage subclass = RAID The other two (ad16 and ad18, the chassis has 8 slots and the last two were only intended to be used in situtations like the one I have now) are connected to an extra pci card: atapci4@pci0:3:6:0: class=0x010401 card=0x02409005 chip=0x02401095 rev=0x02 hdr=0x00 vendor = 'Silicon Image Inc (Was: CMD Technology Inc)' device = 'SATA/Raid controller(2XSATA150) (SIL3112)' class = mass storage subclass = RAID Meanwhile I took out the ad18 drive again and tried to use a different drive. But that was listed as "UNAVAIL" with corrupted data by zfs. Probably it already branded the disk for resilvering and is looking for exactly this one now. I also put in the disk which caused the problem above again. The resilvering process started again, but very soon the drive got detached again resulting in the same situation I described above. Any help is greatly appreciated. cu Gerrit From owner-freebsd-stable@FreeBSD.ORG Tue Jan 26 15:37:55 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BF56110656AC; Tue, 26 Jan 2010 15:37:55 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 93F5A8FC0C; Tue, 26 Jan 2010 15:37:55 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id 47F6F46B2C; Tue, 26 Jan 2010 10:37:55 -0500 (EST) Received: from jhbbsd.localnet (smtp.hudson-trading.com [209.249.190.9]) by bigwig.baldwin.cx (Postfix) with ESMTPA id 238938A021; Tue, 26 Jan 2010 10:37:54 -0500 (EST) From: John Baldwin To: freebsd-stable@freebsd.org Date: Tue, 26 Jan 2010 09:46:44 -0500 User-Agent: KMail/1.12.1 (FreeBSD/7.2-CBSD-20100120; KDE/4.3.1; amd64; ; ) References: <20100126073336.GA1955@server.vk2pj.dyndns.org> In-Reply-To: <20100126073336.GA1955@server.vk2pj.dyndns.org> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Message-Id: <201001260946.44977.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (bigwig.baldwin.cx); Tue, 26 Jan 2010 10:37:54 -0500 (EST) X-Virus-Scanned: clamav-milter 0.95.1 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-2.6 required=4.2 tests=AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on bigwig.baldwin.cx Cc: marius@freebsd.org, Peter Jeremy Subject: Re: uma_zalloc_arg complaining about non-sleepable locks X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jan 2010 15:37:55 -0000 On Tuesday 26 January 2010 2:33:37 am Peter Jeremy wrote: > I have just upgraded to 8-STABLE/amd64 from about 18 hours ago and am > now getting regular (the following pair of messages about every > minute) compaints as follows: > > kernel: uma_zalloc_arg: zone "mbuf" with the following non-sleepable locks held: > kernel: exclusive sleep mutex sp_lock (sp_lock) r = 0 (0xffffff000460bb00) locked @ /usr/src/sys/rpc/svc.c:1098 > kernel: KDB: stack backtrace: > kernel: db_trace_self_wrapper() at db_trace_self_wrapper+0x2a > kernel: _witness_debugger() at _witness_debugger+0x2c > kernel: witness_warn() at witness_warn+0x2c2 > kernel: uma_zalloc_arg() at uma_zalloc_arg+0x29d > kernel: nfs_realign() at nfs_realign+0x5f > kernel: fha_assign() at fha_assign+0x2d8 > kernel: svc_run_internal() at svc_run_internal+0x1ee > kernel: svc_thread_start() at svc_thread_start+0xb > kernel: fork_exit() at fork_exit+0x112 > kernel: fork_trampoline() at fork_trampoline+0xe > kernel: --- trap 0xc, rip = 0x80069e04c, rsp = 0x7fffffffe6d8, rbp = 0x5 --- > kernel: uma_zalloc_arg: zone "mbuf" with the following non-sleepable locks held: > kernel: exclusive sleep mutex sp_lock (sp_lock) r = 0 (0xffffff000460bb00) locked @ /usr/src/sys/rpc/svc.c:1098 > kernel: KDB: stack backtrace: > kernel: db_trace_self_wrapper() at db_trace_self_wrapper+0x2a > kernel: _witness_debugger() at _witness_debugger+0x2c > kernel: witness_warn() at witness_warn+0x2c2 > kernel: uma_zalloc_arg() at uma_zalloc_arg+0x29d > kernel: nfs_realign() at nfs_realign+0x5f > kernel: fha_assign() at fha_assign+0x2d8 > kernel: svc_run_internal() at svc_run_internal+0x1ee > kernel: svc_thread_start() at svc_thread_start+0xb > kernel: fork_exit() at fork_exit+0x112 > kernel: fork_trampoline() at fork_trampoline+0xe > kernel: --- trap 0xc, rip = 0x80069e04c, rsp = 0x7fffffffe6d8, rbp = 0x5 --- > > It looks like NFS is missing some lock/unlock pairs. Has anyone else > seen this? And does anyone have a fix? I suspect this was caused by the recent alignment fixes to NFS. I've cc'd Marius. -- John Baldwin From owner-freebsd-stable@FreeBSD.ORG Tue Jan 26 15:37:57 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 878451065698; Tue, 26 Jan 2010 15:37:57 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 5BD158FC24; Tue, 26 Jan 2010 15:37:57 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id 0E51846B2A; Tue, 26 Jan 2010 10:37:57 -0500 (EST) Received: from jhbbsd.localnet (smtp.hudson-trading.com [209.249.190.9]) by bigwig.baldwin.cx (Postfix) with ESMTPA id D348E8A024; Tue, 26 Jan 2010 10:37:55 -0500 (EST) From: John Baldwin To: freebsd-stable@freebsd.org Date: Tue, 26 Jan 2010 09:49:45 -0500 User-Agent: KMail/1.12.1 (FreeBSD/7.2-CBSD-20100120; KDE/4.3.1; amd64; ; ) References: <20100126092905.GA47528@m4-new.master-telecom.ru> In-Reply-To: <20100126092905.GA47528@m4-new.master-telecom.ru> MIME-Version: 1.0 Content-Type: Text/Plain; charset="koi8-r" Content-Transfer-Encoding: 7bit Message-Id: <201001260949.46082.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (bigwig.baldwin.cx); Tue, 26 Jan 2010 10:37:56 -0500 (EST) X-Virus-Scanned: clamav-milter 0.95.1 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-2.6 required=4.2 tests=AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on bigwig.baldwin.cx Cc: Dmitry Sivachenko , yongari@freebsd.org Subject: Re: RELENG_7 if_nve panic X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jan 2010 15:37:57 -0000 On Tuesday 26 January 2010 4:29:05 am Dmitry Sivachenko wrote: > Hello! > > I recompiled recent RELENG_7 and I get the following panic after > trying to kldload if_nve (interesting stack frames are 12, 13, 14 I guess). > Previous version of RELENG_7 (compiled in the middle of December) > worked fine. Last few days I was trying to re-cvsup and always get the > same panic. I get FreeBSD sources via cvsup (cvsup5.freebsd.org). > > Any suggestions? > > Thanks in advance! The bug is perhaps in e1000phy in that it expects all callers to have called if_initname() before the miibus is probed. Try this patch: Index: if_nve.c =================================================================== --- if_nve.c (revision 202705) +++ if_nve.c (working copy) @@ -526,14 +526,6 @@ goto fail; } - /* Probe device for MII interface to PHY */ - DEBUGOUT(NVE_DEBUG_INIT, "nve: do mii_phy_probe\n"); - if (mii_phy_probe(dev, &sc->miibus, nve_ifmedia_upd, nve_ifmedia_sts)) { - device_printf(dev, "MII without any phy!\n"); - error = ENXIO; - goto fail; - } - /* Setup interface parameters */ ifp->if_softc = sc; if_initname(ifp, device_get_name(dev), device_get_unit(dev)); @@ -549,6 +541,14 @@ ifp->if_capabilities |= IFCAP_VLAN_MTU; ifp->if_capenable |= IFCAP_VLAN_MTU; + /* Probe device for MII interface to PHY */ + DEBUGOUT(NVE_DEBUG_INIT, "nve: do mii_phy_probe\n"); + if (mii_phy_probe(dev, &sc->miibus, nve_ifmedia_upd, nve_ifmedia_sts)) { + device_printf(dev, "MII without any phy!\n"); + error = ENXIO; + goto fail; + } + /* Attach to OS's managers. */ ether_ifattach(ifp, eaddr); -- John Baldwin From owner-freebsd-stable@FreeBSD.ORG Tue Jan 26 15:53:03 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B979D1065670; Tue, 26 Jan 2010 15:53:03 +0000 (UTC) (envelope-from mitya@m4-new.master-telecom.ru) Received: from m4-new.master-telecom.ru (m4-new.master-telecom.ru [85.193.64.114]) by mx1.freebsd.org (Postfix) with ESMTP id 2651C8FC14; Tue, 26 Jan 2010 15:53:01 +0000 (UTC) Received: from m4-new.master-telecom.ru (localhost [127.0.0.1]) by m4-new.master-telecom.ru (8.13.8/8.13.8) with ESMTP id o0QFr0pC088450; Tue, 26 Jan 2010 18:53:00 +0300 (MSK) (envelope-from mitya@m4-new.master-telecom.ru) Received: (from mitya@localhost) by m4-new.master-telecom.ru (8.13.8/8.13.8/Submit) id o0QFr074088449; Tue, 26 Jan 2010 18:53:00 +0300 (MSK) (envelope-from mitya) Date: Tue, 26 Jan 2010 18:53:00 +0300 From: Dmitry Sivachenko To: John Baldwin Message-ID: <20100126155300.GA87838@m4-new.master-telecom.ru> References: <20100126092905.GA47528@m4-new.master-telecom.ru> <201001260949.46082.jhb@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: <201001260949.46082.jhb@freebsd.org> WWW-Home-Page: http://mitya.pp.ru/ X-PGP-Key: http://mitya.pp.ru/mitya.asc User-Agent: Mutt/1.5.18 (2008-05-17) Cc: freebsd-stable@freebsd.org, yongari@freebsd.org Subject: Re: RELENG_7 if_nve panic X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jan 2010 15:53:03 -0000 On Tue, Jan 26, 2010 at 09:49:45AM -0500, John Baldwin wrote: > On Tuesday 26 January 2010 4:29:05 am Dmitry Sivachenko wrote: > > Hello! > > > > I recompiled recent RELENG_7 and I get the following panic after > > trying to kldload if_nve (interesting stack frames are 12, 13, 14 I guess). > > Previous version of RELENG_7 (compiled in the middle of December) > > worked fine. Last few days I was trying to re-cvsup and always get the > > same panic. I get FreeBSD sources via cvsup (cvsup5.freebsd.org). > > > > Any suggestions? > > > > Thanks in advance! > > The bug is perhaps in e1000phy in that it expects all callers to have called > if_initname() before the miibus is probed. Try this patch: That patch solves the problem, thanks! > > Index: if_nve.c > =================================================================== > --- if_nve.c (revision 202705) > +++ if_nve.c (working copy) > @@ -526,14 +526,6 @@ > goto fail; > } > > - /* Probe device for MII interface to PHY */ > - DEBUGOUT(NVE_DEBUG_INIT, "nve: do mii_phy_probe\n"); > - if (mii_phy_probe(dev, &sc->miibus, nve_ifmedia_upd, nve_ifmedia_sts)) { > - device_printf(dev, "MII without any phy!\n"); > - error = ENXIO; > - goto fail; > - } > - > /* Setup interface parameters */ > ifp->if_softc = sc; > if_initname(ifp, device_get_name(dev), device_get_unit(dev)); > @@ -549,6 +541,14 @@ > ifp->if_capabilities |= IFCAP_VLAN_MTU; > ifp->if_capenable |= IFCAP_VLAN_MTU; > > + /* Probe device for MII interface to PHY */ > + DEBUGOUT(NVE_DEBUG_INIT, "nve: do mii_phy_probe\n"); > + if (mii_phy_probe(dev, &sc->miibus, nve_ifmedia_upd, nve_ifmedia_sts)) { > + device_printf(dev, "MII without any phy!\n"); > + error = ENXIO; > + goto fail; > + } > + > /* Attach to OS's managers. */ > ether_ifattach(ifp, eaddr); > > > -- > John Baldwin From owner-freebsd-stable@FreeBSD.ORG Tue Jan 26 16:03:39 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E674B106566B for ; Tue, 26 Jan 2010 16:03:39 +0000 (UTC) (envelope-from prvs=0642d55c7e=ob@gruft.de) Received: from main.mx.e-gitt.net (service.rules.org [IPv6:2001:1560:2342::2]) by mx1.freebsd.org (Postfix) with ESMTP id 6637D8FC14 for ; Tue, 26 Jan 2010 16:03:39 +0000 (UTC) Received: from ob by main.mx.e-gitt.net with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1NZntC-000CQ8-J2 for freebsd-stable@freebsd.org; Tue, 26 Jan 2010 17:03:38 +0100 Date: Tue, 26 Jan 2010 17:03:38 +0100 From: Oliver Brandmueller To: freebsd-stable@freebsd.org Message-ID: <20100126160338.GN3917@e-Gitt.NET> Mail-Followup-To: freebsd-stable@freebsd.org References: <201001222220.31040.freebsd@insightbb.com> <20100124002054.BACFC1CC13@ptavv.es.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20100124002054.BACFC1CC13@ptavv.es.net> User-Agent: Mutt/1.5.20 (2009-06-14) Sender: Oliver Brandmueller Subject: Re: 8.0-RELEASE -> -STABLE and size of / X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jan 2010 16:03:40 -0000 Hi, On Sat, Jan 23, 2010 at 04:20:54PM -0800, Kevin Oberman wrote: > Also, at the start of this thread, the OP said that he did a buildkernel > and a buildworld. This is broken and may produce a non-bootable > kernel. Always buildworld and then buildkernel so that the new toolchain > is used to build the kernel. (This also has nothing to do with the > original issue of the amount of space in the root partition being too > small for amd64 systems, but I am hoping to avoid future issues.) I did both in the right order (first buildworld, then buildkernel). The kernel was OK and bootable. I hd no problem, just experienced something that in my opinion violates POLA. buildworld + buildkernel + installkernel should not produce an error for a fresh default installation. I think we all agreee on that. You can try this easily with an amd64 8.0-RELEASE. - Oliver -- | Oliver Brandmueller http://sysadm.in/ ob@sysadm.in | | Ich bin das Internet. Sowahr ich Gott helfe. | From owner-freebsd-stable@FreeBSD.ORG Tue Jan 26 16:15:29 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2A8B310656A3 for ; Tue, 26 Jan 2010 16:15:29 +0000 (UTC) (envelope-from cswiger@mac.com) Received: from asmtpout025.mac.com (asmtpout025.mac.com [17.148.16.100]) by mx1.freebsd.org (Postfix) with ESMTP id 15C708FC18 for ; Tue, 26 Jan 2010 16:15:28 +0000 (UTC) MIME-version: 1.0 Content-type: text/plain; charset=iso-8859-1 Received: from [17.151.97.212] by asmtp025.mac.com (Sun Java(tm) System Messaging Server 6.3-8.01 (built Dec 16 2008; 32bit)) with ESMTPSA id <0KWV00MZU3TR2X40@asmtp025.mac.com> for freebsd-stable@freebsd.org; Tue, 26 Jan 2010 08:15:28 -0800 (PST) X-Proofpoint-Spam-Details: rule=notspam policy=default score=6 spamscore=6 ipscore=0 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx engine=5.0.0-0908210000 definitions=main-1001260098 From: Chuck Swiger In-reply-to: <20100126160320.6ed67b92.gerrit@pmp.uni-hannover.de> Date: Tue, 26 Jan 2010 08:15:27 -0800 Content-transfer-encoding: quoted-printable Message-id: References: <20100126143021.GA47535@icarus.home.lan> <20100126160320.6ed67b92.gerrit@pmp.uni-hannover.de> To: =?iso-8859-1?Q?Gerrit_K=FChn?= X-Mailer: Apple Mail (2.1077) Cc: freebsd-stable@freebsd.org Subject: Re: ZFS "zpool replace" problems X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 26 Jan 2010 16:15:29 -0000 Hi-- On Jan 26, 2010, at 7:03 AM, Gerrit K=FChn wrote: [ ... ] > atapci4@pci0:3:6:0: class=3D0x010401 card=3D0x02409005 = chip=3D0x02401095 > rev=3D0x02 hdr=3D0x00 vendor =3D 'Silicon Image Inc (Was: CMD = Technology > Inc)' device =3D 'SATA/Raid controller(2XSATA150) (SIL3112)' > class =3D mass storage > subclass =3D RAID >=20 > Meanwhile I took out the ad18 drive again and tried to use a different > drive. But that was listed as "UNAVAIL" with corrupted data by zfs. There's your problem-- the Silicon Image 3112/4 chips are remarkably = buggy and exhibit data corruption: = http://unix.derkeiler.com/Mailing-Lists/FreeBSD/stable/2005-08/0208.html Regards, --=20 -Chuck From owner-freebsd-stable@FreeBSD.ORG Tue Jan 26 16:25:06 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9435E10656A5 for ; Tue, 26 Jan 2010 16:25:06 +0000 (UTC) (envelope-from gerrit@pmp.uni-hannover.de) Received: from mrelay1.uni-hannover.de (mrelay1.uni-hannover.de [130.75.2.106]) by mx1.freebsd.org (Postfix) with ESMTP id 08A408FC25 for ; Tue, 26 Jan 2010 16:25:05 +0000 (UTC) Received: from www.pmp.uni-hannover.de (www.pmp.uni-hannover.de [130.75.117.2]) by mrelay1.uni-hannover.de (8.14.2/8.14.2) with ESMTP id o0QGP3So025986; Tue, 26 Jan 2010 17:25:04 +0100 Received: from pmp.uni-hannover.de (arc.pmp.uni-hannover.de [130.75.117.1]) by www.pmp.uni-hannover.de (Postfix) with SMTP id 1B81124; Tue, 26 Jan 2010 17:25:03 +0100 (CET) Date: Tue, 26 Jan 2010 17:25:03 +0100 From: Gerrit =?ISO-8859-1?Q?K=FChn?= To: Chuck Swiger Message-Id: <20100126172503.927e1bb5.gerrit@pmp.uni-hannover.de> In-Reply-To: References: <20100126143021.GA47535@icarus.home.lan> <20100126160320.6ed67b92.gerrit@pmp.uni-hannover.de> Organization: Albert-Einstein-Institut (MPI =?ISO-8859-1?Q?f=FCr?= Gravitationsphysik & IGP =?ISO-8859-1?Q?Universit=E4t?= Hannover) X-Mailer: Sylpheed 2.7.1 (GTK+ 2.18.4; i386-portbld-freebsd7.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-PMX-Version: 5.5.9.388399, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2010.1.26.161226 Cc: freebsd-stable@freebsd.org Subject: Re: ZFS "zpool replace" problems X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 26 Jan 2010 16:25:06 -0000 On Tue, 26 Jan 2010 08:15:27 -0800 Chuck Swiger wrote about Re: ZFS "zpool replace" problems: CS> > Meanwhile I took out the ad18 drive again and tried to use a CS> > different drive. But that was listed as "UNAVAIL" with corrupted CS> > data by zfs. CS> There's your problem-- the Silicon Image 3112/4 chips are remarkably CS> buggy and exhibit data corruption: Hm, sure? I would expect the same behaviour (detaching) as with the first drive if the controller was the reason in this case. CS> http://unix.derkeiler.com/Mailing-Lists/FreeBSD/stable/2005-08/0208.html I already thought about replacing the controller to get rid of the detach-problem. However, I cannot do this online and I really would prefer fixing the disk firmware problem first. I could remove the hotspare drive ad14 and use this slot for putting in a replacement disk. Is it possible to get ad18 out of zfs' replacing process? Maybe by detaching the disk from the pool? cu Gerrit From owner-freebsd-stable@FreeBSD.ORG Tue Jan 26 16:27:38 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F28081065693 for ; Tue, 26 Jan 2010 16:27:38 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from qmta13.emeryville.ca.mail.comcast.net (qmta13.emeryville.ca.mail.comcast.net [76.96.27.243]) by mx1.freebsd.org (Postfix) with ESMTP id DA0048FC0C for ; Tue, 26 Jan 2010 16:27:38 +0000 (UTC) Received: from omta20.emeryville.ca.mail.comcast.net ([76.96.30.87]) by qmta13.emeryville.ca.mail.comcast.net with comcast id aEpA1d0041smiN4ADGTfKP; Tue, 26 Jan 2010 16:27:39 +0000 Received: from koitsu.dyndns.org ([98.248.46.159]) by omta20.emeryville.ca.mail.comcast.net with comcast id aGTe1d00M3S48mS8gGTesJ; Tue, 26 Jan 2010 16:27:38 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id 37F9C1E3033; Tue, 26 Jan 2010 08:27:37 -0800 (PST) Date: Tue, 26 Jan 2010 08:27:37 -0800 From: Jeremy Chadwick To: freebsd-stable@freebsd.org Message-ID: <20100126162737.GA49988@icarus.home.lan> References: <20100126143021.GA47535@icarus.home.lan> <20100126160320.6ed67b92.gerrit@pmp.uni-hannover.de> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) Subject: Re: ZFS "zpool replace" problems X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 26 Jan 2010 16:27:39 -0000 On Tue, Jan 26, 2010 at 08:15:27AM -0800, Chuck Swiger wrote: > Hi-- > > On Jan 26, 2010, at 7:03 AM, Gerrit Kühn wrote: > [ ... ] > > atapci4@pci0:3:6:0: class=0x010401 card=0x02409005 chip=0x02401095 > > rev=0x02 hdr=0x00 vendor = 'Silicon Image Inc (Was: CMD Technology > > Inc)' device = 'SATA/Raid controller(2XSATA150) (SIL3112)' > > class = mass storage > > subclass = RAID > > > > Meanwhile I took out the ad18 drive again and tried to use a different > > drive. But that was listed as "UNAVAIL" with corrupted data by zfs. > > There's your problem-- the Silicon Image 3112/4 chips are remarkably buggy and exhibit data corruption: > > http://unix.derkeiler.com/Mailing-Lists/FreeBSD/stable/2005-08/0208.html Well, to be fair, we can't be 100% certain he got bit by that bug. It's possible/likely, but we don't know for certain at this point. We also don't know what brand hard disks he had connected to ad16 and/or ad18. Older Silicon Image controllers are known for..... well, just read the Wikipedia entry for details. http://en.wikipedia.org/wiki/Silicon_Image_Inc.#Product_alerts I don't have any experience with their newer models, but I'm told they're significantly improved (throughput and reliability-wise). But it is amusing, almost ironic, how Silicon Image bought CMD -- the same company who was infamous for their CMD640 IDE controller causing data corruption... back in 1995. As others have stated already: Intel could make a fortune off of a simple PCIe or PCI-X SATA controller card that's ICH9/ICH10-based. I guess there's more money in forcing people to buy motherboards with said southbridge. -- | Jeremy Chadwick jdc@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Tue Jan 26 16:42:06 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9E7801065679 for ; Tue, 26 Jan 2010 16:42:06 +0000 (UTC) (envelope-from gerrit@pmp.uni-hannover.de) Received: from mrelay1.uni-hannover.de (mrelay1.uni-hannover.de [130.75.2.106]) by mx1.freebsd.org (Postfix) with ESMTP id 2B97E8FC16 for ; Tue, 26 Jan 2010 16:42:05 +0000 (UTC) Received: from www.pmp.uni-hannover.de (www.pmp.uni-hannover.de [130.75.117.2]) by mrelay1.uni-hannover.de (8.14.2/8.14.2) with ESMTP id o0QGg3DE027213; Tue, 26 Jan 2010 17:42:04 +0100 Received: from pmp.uni-hannover.de (arc.pmp.uni-hannover.de [130.75.117.1]) by www.pmp.uni-hannover.de (Postfix) with SMTP id 837E124; Tue, 26 Jan 2010 17:42:03 +0100 (CET) Date: Tue, 26 Jan 2010 17:42:03 +0100 From: Gerrit =?ISO-8859-1?Q?K=FChn?= To: Jeremy Chadwick Message-Id: <20100126174203.33499993.gerrit@pmp.uni-hannover.de> In-Reply-To: <20100126162737.GA49988@icarus.home.lan> References: <20100126143021.GA47535@icarus.home.lan> <20100126160320.6ed67b92.gerrit@pmp.uni-hannover.de> <20100126162737.GA49988@icarus.home.lan> Organization: Albert-Einstein-Institut (MPI =?ISO-8859-1?Q?f=FCr?= Gravitationsphysik & IGP =?ISO-8859-1?Q?Universit=E4t?= Hannover) X-Mailer: Sylpheed 2.7.1 (GTK+ 2.18.4; i386-portbld-freebsd7.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-PMX-Version: 5.5.9.388399, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2010.1.26.163330 Cc: freebsd-stable@freebsd.org Subject: Re: ZFS "zpool replace" problems X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 26 Jan 2010 16:42:06 -0000 On Tue, 26 Jan 2010 08:27:37 -0800 Jeremy Chadwick wrote about Re: ZFS "zpool replace" problems: JC> Well, to be fair, we can't be 100% certain he got bit by that bug. JC> It's possible/likely, but we don't know for certain at this point. We JC> also don't know what brand hard disks he had connected to ad16 and/or JC> ad18. The same as on the others (WD RE2GP), just with the updated firmware (02.01B02 that is) to get rid of the lcc problem. JC> Older Silicon Image controllers are known for..... well, just read the JC> Wikipedia entry for details. JC> http://en.wikipedia.org/wiki/Silicon_Image_Inc.#Product_alerts I knew the card is not top of the line, but I didn't know that it is /that/ bad. When I set up the system 1 or 2 years ago, I just thought it might be nice to be able to use the two extra slots in case of any drives having to be replaced or so and the card was just lying aroung (well, maybe I have an idea now why nobody else wanted to use it :-). I guess I will try to offline the hotspare slot (connected to the mcp55 on the motherboard) and plug the replacement disk in there. Maybe zfs recognizes it and picks up the resilvering there. Otherwise I'll have to look into how to get rid of the degraded resilvering process and restart it with the drive in the other slot. JC> As others have stated already: Intel could make a fortune off of a JC> simple PCIe or PCI-X SATA controller card that's ICH9/ICH10-based. Indeed. I use these 8-channel Supermicro-Controller (I think I recommended them some time ago here) with LSI chipset that work really nicely. But the backet does not fit into standard slots and there is no PCI-X version. I would certainly prefer a regular card by Intel. cu Gerrit From owner-freebsd-stable@FreeBSD.ORG Tue Jan 26 16:46:22 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 142F7106566B for ; Tue, 26 Jan 2010 16:46:22 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from qmta01.emeryville.ca.mail.comcast.net (qmta01.emeryville.ca.mail.comcast.net [76.96.30.16]) by mx1.freebsd.org (Postfix) with ESMTP id 72FAE8FC0C for ; Tue, 26 Jan 2010 16:46:20 +0000 (UTC) Received: from omta12.emeryville.ca.mail.comcast.net ([76.96.30.44]) by qmta01.emeryville.ca.mail.comcast.net with comcast id aDkB1d0040x6nqcA1GmMWR; Tue, 26 Jan 2010 16:46:21 +0000 Received: from koitsu.dyndns.org ([98.248.46.159]) by omta12.emeryville.ca.mail.comcast.net with comcast id aGmL1d00D3S48mS8YGmLfn; Tue, 26 Jan 2010 16:46:21 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id 7879D1E3033; Tue, 26 Jan 2010 08:46:19 -0800 (PST) Date: Tue, 26 Jan 2010 08:46:19 -0800 From: Jeremy Chadwick To: freebsd-stable@freebsd.org Message-ID: <20100126164619.GA50461@icarus.home.lan> References: <20100126143021.GA47535@icarus.home.lan> <20100126160320.6ed67b92.gerrit@pmp.uni-hannover.de> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20100126160320.6ed67b92.gerrit@pmp.uni-hannover.de> User-Agent: Mutt/1.5.20 (2009-06-14) Subject: Re: ZFS "zpool replace" problems X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 26 Jan 2010 16:46:22 -0000 On Tue, Jan 26, 2010 at 04:03:20PM +0100, Gerrit Kühn wrote: > On Tue, 26 Jan 2010 06:30:21 -0800 Jeremy Chadwick > wrote about Re: ZFS "zpool replace" problems: > JC> 2) How did you attach ad18? Did you tell the system about it using > JC> atacontrol? If so, what commands did you use? > > Yes. The drives did not appear automatically (verified with atacontrol > list). Then I first tried reinit ata9, but that did not work out, so I did > a detach/attach for ata9, then the drive was there (with list and also > the device node appeared). The procedure -- at least on Intel controllers in AHCI mode -- is: - zpool offline - atacontrol detach ataX (where X = channel associated with disk) - Physically remove bad disk - Physically insert new disk - Wait 15 seconds for stuff to settle - atacontrol attach ataX (where X = previous channel detached) - zpool replace - zpool online "reinit" shouldn't be needed at all -- in fact, I've seen reinit cause some craziness (even on Intel controllers), including a system deadlock, but this was back during the RELENG_6 and RELENG_7 days. Great improvements have been made to ata(4) since then. If you need me to validate the above procedure (it's been a while since I've had to hot-swap a disk), I can do so. I do have a 4-disk Supermicro SuperServer 5015B-MTB (ICH9-based) sitting on my workbench which I can test with. > Meanwhile I took out the ad18 drive again and tried to use a different > drive. But that was listed as "UNAVAIL" with corrupted data by zfs. > Probably it already branded the disk for resilvering and is looking for > exactly this one now. I also put in the disk which caused the problem > above again. The resilvering process started again, but very soon the > drive got detached again resulting in the same situation I described above. It honestly sounds like hot-swapping is causing some chaos on your system. Are all of the controllers involved configured for AHCI? If not, physical removal/insertion should be done only when the system power is off. If so, mav@ or others may be able to help figure out what's going on in the underlying ata(4) layer. -- | Jeremy Chadwick jdc@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Tue Jan 26 16:49:10 2010 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D84DE1065672 for ; Tue, 26 Jan 2010 16:49:10 +0000 (UTC) (envelope-from ncrogers@gmail.com) Received: from mail-px0-f183.google.com (mail-px0-f183.google.com [209.85.216.183]) by mx1.freebsd.org (Postfix) with ESMTP id AE2078FC17 for ; Tue, 26 Jan 2010 16:49:10 +0000 (UTC) Received: by pxi13 with SMTP id 13so3305950pxi.3 for ; Tue, 26 Jan 2010 08:49:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=TAy30rM53wiJ6Cthv5RNg5QV24BSG5auB7sDqbgWEpE=; b=APnYl6skaK9bCtR7/0gDQHCKPFPtY7V1S62l5HhiJuXYom4QHjha4WxTRA6fLAimQA 02hZO912PkPU72O9yAIs/JLWaPy49NyNJUTBVp0t3VlJUICUR3ShQvC2ldmdDHLPW1of J1d6WUD54dlccopfnkx/eAu6kZWoBlhbVNlEU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=sE4TH710a8Ipbjan+ZqRbXIhfrIBx53SvSromQmOktYCyLCOHTdVjyBOndJWWU95HJ SSJSkcFvbJbhgFMjAe6BOqY8pFkoz23clSLtW0S1vQqWIGMIxa4J0ZQLe/hM8VRTQHnn ssMEQNqzR74O9iB2kpHtPSfk+DKJp3B3YjyRk= MIME-Version: 1.0 Received: by 10.142.67.41 with SMTP id p41mr1490489wfa.284.1264524549891; Tue, 26 Jan 2010 08:49:09 -0800 (PST) In-Reply-To: <20100126124154.GA72180@edoofus.dev.vega.ru> References: <147432021001251901u7d56f014n83e834061fd09fec@mail.gmail.com> <20100126124154.GA72180@edoofus.dev.vega.ru> Date: Tue, 26 Jan 2010 08:49:09 -0800 Message-ID: <147432021001260849l7c2e1175gdee26b44fc1191ba@mail.gmail.com> From: Nick Rogers To: Ruslan Ermilov Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: stable@freebsd.org Subject: Re: netstat output changes in 8.0? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jan 2010 16:49:11 -0000 Thanks a lot. Thats a bummer. What are the chances of getting something like that worked into arp(8) permanently? On Tue, Jan 26, 2010 at 4:41 AM, Ruslan Ermilov wrote: > On Mon, Jan 25, 2010 at 07:01:46PM -0800, Nick Rogers wrote: > > Before 8.0-RELEASE, if I ran netstat -rn, it listed a separate route for > > each host on the network, along with its MAC address. For example ... > > > > 172.20.172.17 00:02:b3:2f:64:6a UHLW 1 105712 1500 > > vlan172 595 > > 172.20.172.20 00:1e:c9:bb:7c:a9 UHLW 1 1002 1500 > > vlan172 598 > > 172.20.172.22 00:14:5e:16:bb:b6 UHLW 1 107 1500 > > vlan172 491 > > > > This behavior seems to have changed in 8.0, where now only the > > locally-assigned IP addresses and related CIDRs are displayed. > > From src/UPDATING: > > : 20081214: > : __FreeBSD_version 800059 incorporates the new arp-v2 rewrite. > : RTF_CLONING, RTF_LLINFO and RTF_WASCLONED flags are eliminated. > : The new code reduced struct rtentry{} by 16 bytes on 32-bit > : architecture and 40 bytes on 64-bit architecture. The userland > : applications "arp" and "ndp" have been updated accordingly. > : The output from "netstat -r" shows only routing entries and > : none of the L2 information. > > > Is there any way to get this behavior back, perhaps with a new flag that > I > > am not able to find? Or some sysctl? I have a script that was relying on > > each host's "expire" flag in the routing table to determine when the MAC > > address first appeared on the network according to ARP. > > If you need to know when a particular ARP entry expires, a variation > of the following patch can be used, perhaps hiding this output by the > -v (verbose) option. > > %%% > Index: arp.c > =================================================================== > --- arp.c (revision 203016) > +++ arp.c (working copy) > @@ -101,7 +101,8 @@ > static int nflag; /* no reverse dns lookups */ > static char *rifname; > > -static int expire_time, flags, doing_proxy, proxy_only; > +static time_t expire_time; > +static int flags, doing_proxy, proxy_only; > > /* which function we're supposed to do */ > #define F_GET 1 > @@ -594,6 +595,15 @@ > printf(" on %s", ifname); > if (rtm->rtm_rmx.rmx_expire == 0) > printf(" permanent"); > + else { > + static struct timeval tv; > + if (tv.tv_sec == 0) > + gettimeofday(&tv, 0); > + if ((expire_time = rtm->rtm_rmx.rmx_expire - tv.tv_sec) > > 0) > + printf(" expires %d", (int)expire_time); > + else > + printf(" expired"); > + } > if (addr->sin_other & SIN_PROXY) > printf(" published (proxy only)"); > if (rtm->rtm_flags & RTF_ANNOUNCE) > %%% > > > Cheers, > -- > Ruslan Ermilov > ru@FreeBSD.org > FreeBSD committer > From owner-freebsd-stable@FreeBSD.ORG Tue Jan 26 16:59:42 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2972C1065676 for ; Tue, 26 Jan 2010 16:59:42 +0000 (UTC) (envelope-from cswiger@mac.com) Received: from asmtpout024.mac.com (asmtpout024.mac.com [17.148.16.99]) by mx1.freebsd.org (Postfix) with ESMTP id 123478FC08 for ; Tue, 26 Jan 2010 16:59:41 +0000 (UTC) MIME-version: 1.0 Content-type: text/plain; charset=iso-8859-1 Received: from [10.0.1.46] ([173.200.179.65]) by asmtp024.mac.com (Sun Java(tm) System Messaging Server 6.3-8.01 (built Dec 16 2008; 32bit)) with ESMTPSA id <0KWV0035J5V3JE90@asmtp024.mac.com> for freebsd-stable@freebsd.org; Tue, 26 Jan 2010 08:59:28 -0800 (PST) X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx engine=5.0.0-0908210000 definitions=main-1001260108 From: Chuck Swiger In-reply-to: <20100126172503.927e1bb5.gerrit@pmp.uni-hannover.de> Date: Tue, 26 Jan 2010 08:59:27 -0800 Content-transfer-encoding: quoted-printable Message-id: <5F20B2B6-D75C-4E27-9CC9-85C6E64D13BD@mac.com> References: <20100126143021.GA47535@icarus.home.lan> <20100126160320.6ed67b92.gerrit@pmp.uni-hannover.de> <20100126172503.927e1bb5.gerrit@pmp.uni-hannover.de> To: =?iso-8859-1?Q?Gerrit_K=FChn?= X-Mailer: Apple Mail (2.1077) Cc: freebsd-stable@freebsd.org Subject: Re: ZFS "zpool replace" problems X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 26 Jan 2010 16:59:42 -0000 Hi-- On Jan 26, 2010, at 8:25 AM, Gerrit K=FChn wrote: > CS> There's your problem-- the Silicon Image 3112/4 chips are = remarkably > CS> buggy and exhibit data corruption: >=20 > Hm, sure? I'm sure that the SII 3112 is buggy. I am not sure that it is the primary or only cause of the problems you = describe. [ ... ] > I already thought about replacing the controller to get rid of the > detach-problem. However, I cannot do this online and I really would = prefer > fixing the disk firmware problem first. > I could remove the hotspare drive ad14 and use this slot for putting = in a > replacement disk. Is it possible to get ad18 out of zfs' replacing > process? Maybe by detaching the disk from the pool? I don't know enough about ZFS to provide specific advice for recovery = attempts (aside from the notion of restoring your data from a backup = instead).=20 As a general matter of maintaining RAID systems, however, the approach = to upgrading drive firmware on members of a RAID array should be to take = down the entire container and offline the drives, update one drive, test = it (via SMART self-test and read-only checksum comparison or similar), = and then proceed to update all of the drives (preferably doing the SMART = self-test for each, if time allows) before returning them to the RAID = container and onlining them. Pulling individual drives from a RAID set while live and updating the = firmware one at a time is not an approach I would take-- running with = mixed firmware versions doesn't thrill me, and I know of multiple cases = where someone made a mistake reconnecting a drive with the wrong SCSI id = or something like that, taking out a second drive while the RAID was not = redundant, resulting in massive data corruption or even total loss of = the RAID contents. Regards, --=20 -Chuck From owner-freebsd-stable@FreeBSD.ORG Tue Jan 26 17:00:29 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CE0DC106568D for ; Tue, 26 Jan 2010 17:00:29 +0000 (UTC) (envelope-from gerrit@pmp.uni-hannover.de) Received: from mrelay1.uni-hannover.de (mrelay1.uni-hannover.de [130.75.2.106]) by mx1.freebsd.org (Postfix) with ESMTP id 5BEA38FC1D for ; Tue, 26 Jan 2010 17:00:29 +0000 (UTC) Received: from www.pmp.uni-hannover.de (www.pmp.uni-hannover.de [130.75.117.2]) by mrelay1.uni-hannover.de (8.14.2/8.14.2) with ESMTP id o0QH0Q5f027850; Tue, 26 Jan 2010 18:00:27 +0100 Received: from pmp.uni-hannover.de (arc.pmp.uni-hannover.de [130.75.117.1]) by www.pmp.uni-hannover.de (Postfix) with SMTP id 1209C24; Tue, 26 Jan 2010 18:00:26 +0100 (CET) Date: Tue, 26 Jan 2010 18:00:25 +0100 From: Gerrit =?ISO-8859-1?Q?K=FChn?= To: Jeremy Chadwick Message-Id: <20100126180025.83022d17.gerrit@pmp.uni-hannover.de> In-Reply-To: <20100126164619.GA50461@icarus.home.lan> References: <20100126143021.GA47535@icarus.home.lan> <20100126160320.6ed67b92.gerrit@pmp.uni-hannover.de> <20100126164619.GA50461@icarus.home.lan> Organization: Albert-Einstein-Institut (MPI =?ISO-8859-1?Q?f=FCr?= Gravitationsphysik & IGP =?ISO-8859-1?Q?Universit=E4t?= Hannover) X-Mailer: Sylpheed 2.7.1 (GTK+ 2.18.4; i386-portbld-freebsd7.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-PMX-Version: 5.5.9.388399, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2010.1.26.165121 Cc: freebsd-stable@freebsd.org Subject: Re: ZFS "zpool replace" problems X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 26 Jan 2010 17:00:29 -0000 On Tue, 26 Jan 2010 08:46:19 -0800 Jeremy Chadwick wrote about Re: ZFS "zpool replace" problems: JC> - zpool offline JC> - atacontrol detach ataX (where X = channel associated with disk) JC> - Physically remove bad disk JC> - Physically insert new disk JC> - Wait 15 seconds for stuff to settle JC> - atacontrol attach ataX (where X = previous channel detached) JC> - zpool replace JC> - zpool online JC> "reinit" shouldn't be needed at all -- in fact, I've seen reinit cause JC> some craziness (even on Intel controllers), including a system JC> deadlock, but this was back during the RELENG_6 and RELENG_7 days. JC> Great improvements have been made to ata(4) since then. Thanks for pointing that out. I would have went exactly this way, if I did not have the extra slots or one of the drives was actually faulty. But in this case I just wanted to replace every drive on-by-one and (at least I thought) I had extra slots, so I did not want to give up the redundancy during the replacement (knowing very well that the drives to be replaced are already beyond the specification of wd due to the load-cycle bug). JC> If you need me to validate the above procedure (it's been a while since JC> I've had to hot-swap a disk), I can do so. I do have a 4-disk JC> Supermicro SuperServer 5015B-MTB (ICH9-based) sitting on my workbench JC> which I can test with. I'm quite sure this will work fine. I just don't know how to get rid of the degraded replacement zfs sees. JC> It honestly sounds like hot-swapping is causing some chaos on your JC> system. Are all of the controllers involved configured for AHCI? I think so. How could I verify this? cu Gerrit From owner-freebsd-stable@FreeBSD.ORG Tue Jan 26 17:00:36 2010 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 697E6106568F for ; Tue, 26 Jan 2010 17:00:36 +0000 (UTC) (envelope-from ncrogers@gmail.com) Received: from mail-px0-f183.google.com (mail-px0-f183.google.com [209.85.216.183]) by mx1.freebsd.org (Postfix) with ESMTP id 391478FC1B for ; Tue, 26 Jan 2010 17:00:35 +0000 (UTC) Received: by pxi13 with SMTP id 13so3314044pxi.3 for ; Tue, 26 Jan 2010 09:00:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=MpM64hQp4IA+PCeh7agTRvTqOlkccx9l6k/YHviUmfw=; b=E1+pqJdcGdlMmZAovh6i0xV8Rrp4UhhfPHe0VvZT/Dj4LfcAlrllzR+qnNqJ0PRU+k cvxKMxOZn+9ydPBvmWvSQ/0w/jm6uyMcJ44mofl0s8Z58McRlDUw8/61X0gSRvnu1Pm/ y7lweaPTbzZUBEFff1A9V1KUrbEawejVt0n7E= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=GlXltw3wl0DvIieXYFqdlPD6wWn+//qxJetEaALUaSQgo9pJahWFvMLem31fLMgidg iLcJkXQHNtL46QInoIOivXOeQfcVj8t2mzOgFNa5JoOaPME6PBz/9u9LE6zhaXFuEd50 yV5JoBB3Qh38Ldpw7pVlilyB2P6tKA+xNNq3U= MIME-Version: 1.0 Received: by 10.143.25.29 with SMTP id c29mr5237108wfj.111.1264525235632; Tue, 26 Jan 2010 09:00:35 -0800 (PST) In-Reply-To: <33c6b0bc1001252031k508426bfh25fad65e9223d87@mail.gmail.com> References: <20091201.102925.218343479.hrs@allbsd.org> <20091203.182931.129751456.hrs@allbsd.org> <4B43F6EE.3010308@ucla.edu> <147432021001242047k659a26d0s44b35164920aeb74@mail.gmail.com> <95D3CB82-BC44-491D-86E4-5CB82F89C0FC@nokia.com> <147432021001250825p202914a7ka5a2c1d28d96bac3@mail.gmail.com> <20100125182257.GG1187@michelle.cdnetworks.com> <147432021001251038r69393ab3m1a797e58f9fa905a@mail.gmail.com> <02307620-ECDC-4E8B-A5B1-FF8491E226C4@nokia.com> <33c6b0bc1001252031k508426bfh25fad65e9223d87@mail.gmail.com> Date: Tue, 26 Jan 2010 09:00:35 -0800 Message-ID: <147432021001260900p60ed1804t97392d2dff5cd244@mail.gmail.com> From: Nick Rogers To: Joshua Boyd Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: "stable@freebsd.org" Subject: Re: em interface slow down on 8.0R X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 26 Jan 2010 17:00:36 -0000 Is it advisable to patch 8.0-RELEASE kernel sources with the latest (CURRENT) em driver (i.e., src/sys/dev/e1000)? It looks like there are some updates to the driver since 8.0-RELEASE that may fix some problems? On Mon, Jan 25, 2010 at 8:31 PM, Joshua Boyd wrote: > I've been having a similar problem with my network dropping completely on > my > 8-STABLE gateway/firewall/fileserver. My setup is a little different, as I > have re0 and ral0 bridged for LAN, and em0 for WAN. I've just turned off TX > checksum offloading to see if that makes any difference. > \\ > From owner-freebsd-stable@FreeBSD.ORG Tue Jan 26 17:10:15 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C25CD1065672 for ; Tue, 26 Jan 2010 17:10:15 +0000 (UTC) (envelope-from gerrit@pmp.uni-hannover.de) Received: from mrelay1.uni-hannover.de (mrelay1.uni-hannover.de [130.75.2.106]) by mx1.freebsd.org (Postfix) with ESMTP id 4E72F8FC0A for ; Tue, 26 Jan 2010 17:10:14 +0000 (UTC) Received: from www.pmp.uni-hannover.de (www.pmp.uni-hannover.de [130.75.117.2]) by mrelay1.uni-hannover.de (8.14.2/8.14.2) with ESMTP id o0QHACYp028394; Tue, 26 Jan 2010 18:10:13 +0100 Received: from pmp.uni-hannover.de (arc.pmp.uni-hannover.de [130.75.117.1]) by www.pmp.uni-hannover.de (Postfix) with SMTP id A477924; Tue, 26 Jan 2010 18:10:12 +0100 (CET) Date: Tue, 26 Jan 2010 18:10:12 +0100 From: Gerrit =?ISO-8859-1?Q?K=FChn?= To: Chuck Swiger Message-Id: <20100126181012.4669d417.gerrit@pmp.uni-hannover.de> In-Reply-To: <5F20B2B6-D75C-4E27-9CC9-85C6E64D13BD@mac.com> References: <20100126143021.GA47535@icarus.home.lan> <20100126160320.6ed67b92.gerrit@pmp.uni-hannover.de> <20100126172503.927e1bb5.gerrit@pmp.uni-hannover.de> <5F20B2B6-D75C-4E27-9CC9-85C6E64D13BD@mac.com> Organization: Albert-Einstein-Institut (MPI =?ISO-8859-1?Q?f=FCr?= Gravitationsphysik & IGP =?ISO-8859-1?Q?Universit=E4t?= Hannover) X-Mailer: Sylpheed 2.7.1 (GTK+ 2.18.4; i386-portbld-freebsd7.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-PMX-Version: 5.5.9.388399, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2010.1.26.170039 Cc: freebsd-stable@freebsd.org Subject: Re: ZFS "zpool replace" problems X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 26 Jan 2010 17:10:15 -0000 On Tue, 26 Jan 2010 08:59:27 -0800 Chuck Swiger wrote about Re: ZFS "zpool replace" problems: CS> As a general matter of maintaining RAID systems, however, the approach CS> to upgrading drive firmware on members of a RAID array should be to CS> take down the entire container and offline the drives, update one CS> drive, test it (via SMART self-test and read-only checksum comparison CS> or similar), and then proceed to update all of the drives (preferably CS> doing the SMART self-test for each, if time allows) before returning CS> them to the RAID container and onlining them. Well, I had several spare drives sitting on the shelf. So I updated the firmware of these spare drives and now want to replace the drives with the old firmware by new new ones one-by-one. Taking the system offline for longer than a few minutes is not really an option. I'd rather roll in a new machine to take over the job in that case. CS> Pulling individual drives from a RAID set while live and updating the CS> firmware one at a time is not an approach I would take-- running with CS> mixed firmware versions doesn't thrill me, and I know of multiple CS> cases where someone made a mistake reconnecting a drive with the wrong CS> SCSI id or something like that, taking out a second drive while the CS> RAID was not redundant, resulting in massive data corruption or even CS> total loss of the RAID contents. This scenario was exactly the reason why I plugged in the new drive to an extra slot and asked zfs to replace it with an old one. Well, I did not know what kind of fiasco the controller for this extra slot would turn out to be - otherwise I would have used the hot-spare slot for this in the first place. cu Gerrit From owner-freebsd-stable@FreeBSD.ORG Tue Jan 26 17:14:37 2010 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 521F1106566C for ; Tue, 26 Jan 2010 17:14:37 +0000 (UTC) (envelope-from ncrogers@gmail.com) Received: from mail-pw0-f44.google.com (mail-pw0-f44.google.com [209.85.160.44]) by mx1.freebsd.org (Postfix) with ESMTP id 21F598FC22 for ; Tue, 26 Jan 2010 17:14:36 +0000 (UTC) Received: by pwi15 with SMTP id 15so3362516pwi.3 for ; Tue, 26 Jan 2010 09:14:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=pktIhedpRL2yZTT629XfyjS6prlEPdkp80Bhl+ertyk=; b=cwPj4i2ktomVePXcsShC9VJDlt7UlXqWSmkwzPqP/eFaXv/7duGtDpDNEjH4VURDgT +LAY6Zs6f63nmvkv3BbPoT+4nxwvTTLHeK6YV8x0hM3I6XlxX2TgMxkuLaioLGdcd/x6 Gc4th6LTRI9ilS1t6edekQMWMPNEtYx6LiK3s= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=nW8cwZLW3VKG+oklQ0Nr18iBjE3DbmbCXU9+bNHRkPC2JHuAOQ5Ed4AEIWa4BqzX0r uzsZemsb0zRxNIX2T+0LSkQ85TEMcZRSbukl4PCGOs+GUHbzh8StMt1CLhoQ0j6qo0mK 9JThF7K/Yjzb+wn6qNCWRILNMJw00z/CXIqAU= MIME-Version: 1.0 Received: by 10.142.152.6 with SMTP id z6mr1110340wfd.214.1264526076538; Tue, 26 Jan 2010 09:14:36 -0800 (PST) In-Reply-To: <147432021001260900p60ed1804t97392d2dff5cd244@mail.gmail.com> References: <20091201.102925.218343479.hrs@allbsd.org> <4B43F6EE.3010308@ucla.edu> <147432021001242047k659a26d0s44b35164920aeb74@mail.gmail.com> <95D3CB82-BC44-491D-86E4-5CB82F89C0FC@nokia.com> <147432021001250825p202914a7ka5a2c1d28d96bac3@mail.gmail.com> <20100125182257.GG1187@michelle.cdnetworks.com> <147432021001251038r69393ab3m1a797e58f9fa905a@mail.gmail.com> <02307620-ECDC-4E8B-A5B1-FF8491E226C4@nokia.com> <33c6b0bc1001252031k508426bfh25fad65e9223d87@mail.gmail.com> <147432021001260900p60ed1804t97392d2dff5cd244@mail.gmail.com> Date: Tue, 26 Jan 2010 09:14:36 -0800 Message-ID: <147432021001260914x6e5e1b41n4146904ead9d9108@mail.gmail.com> From: Nick Rogers To: Joshua Boyd Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: "stable@freebsd.org" Subject: Re: em interface slow down on 8.0R X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 26 Jan 2010 17:14:37 -0000 looks like the patch mentioned in kern/141843 has not been applied to the tree? On Tue, Jan 26, 2010 at 9:00 AM, Nick Rogers wrote: > Is it advisable to patch 8.0-RELEASE kernel sources with the latest > (CURRENT) em driver (i.e., src/sys/dev/e1000)? It looks like there are some > updates to the driver since 8.0-RELEASE that may fix some problems? > > From owner-freebsd-stable@FreeBSD.ORG Tue Jan 26 17:21:15 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C4B22106566B; Tue, 26 Jan 2010 17:21:15 +0000 (UTC) (envelope-from artemb@gmail.com) Received: from mail-iw0-f204.google.com (mail-iw0-f204.google.com [209.85.223.204]) by mx1.freebsd.org (Postfix) with ESMTP id 7AD8B8FC1D; Tue, 26 Jan 2010 17:21:15 +0000 (UTC) Received: by iwn42 with SMTP id 42so1778565iwn.9 for ; Tue, 26 Jan 2010 09:21:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to:cc :content-type; bh=yFHOCEkQJ9jgtAe6gTNyZeEgpANI/AW8lWIxfJi+IF4=; b=VZIgharSlb5WoUmZfuh57G8FNhCnvDyeqgEibOMa3p7EdVvqXbNnfXRAuNN8NfD5Wt H6AwtaHYzowcQuAfJG0X9W/i/r29Gh6rGhZzc9cNKZc2Uqk+Q4SsrR7t/YfVwHpPxykh vlzyw17jAw5YujYUBjJRKqfGZD4xuctNO3JnQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; b=YUiNocqyY2H34uDzefhmAABq6sVgFPYyYKEMoMt3YTKz8yTETqYQ4o40XqK1aOXhix Zkim1SJWx1pCj0afCioVx9TB5p2PmLMdzhjneghGAYPEJt9EY1ooRrHUWAghiTkO0074 qrOio8V2OE4wpt3fwN7kJPuadpEuooKOH77bY= MIME-Version: 1.0 Sender: artemb@gmail.com Received: by 10.231.168.136 with SMTP id u8mr406870iby.56.1264526474163; Tue, 26 Jan 2010 09:21:14 -0800 (PST) In-Reply-To: References: <20100125191030.GG1643@garage.freebsd.pl> <20100126120030.15496xfctb8icfk8@webmail.leidinger.net> Date: Tue, 26 Jan 2010 09:21:14 -0800 X-Google-Sender-Auth: 7712a69f59edf37d Message-ID: From: Artem Belevich To: Dmitry Morozovsky Content-Type: text/plain; charset=ISO-8859-1 Cc: Alexander Leidinger , Pawel Jakub Dawidek , freebsd-stable@freebsd.org Subject: Re: ZFS panic on RELENG_7/i386 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 26 Jan 2010 17:21:15 -0000 > will do, thank you. is fletcher4 faster? Not necessarily. But it does work as a checksum much better. See following link for the details. http://bugs.opensolaris.org/bugdatabase/view_bug.do?bug_id=6740597 --Artem From owner-freebsd-stable@FreeBSD.ORG Tue Jan 26 17:41:01 2010 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 563681065692 for ; Tue, 26 Jan 2010 17:41:01 +0000 (UTC) (envelope-from jfvogel@gmail.com) Received: from mail-ew0-f218.google.com (mail-ew0-f218.google.com [209.85.219.218]) by mx1.freebsd.org (Postfix) with ESMTP id D8F8C8FC1A for ; Tue, 26 Jan 2010 17:41:00 +0000 (UTC) Received: by ewy10 with SMTP id 10so224755ewy.3 for ; Tue, 26 Jan 2010 09:40:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=ck84o8JV2wn09O1Ieh28zu197C/LX3o/4QJe5K47ZyQ=; b=m44pznWjEom9y+DcITt7efGidYN8AyJNYdmPFViYHNKECvuVKXhH4eXbZVjB2m2lEc BRlfvz4rZ7xmmW+f1ph68o7vzaZMNUrtA7fF+1Lo/8LSeWokKR5rCSbI0VLDJg0Or/Uo O6A/S+pLpfDALI4n+r706R6s89JlTGegB6Iys= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=ORm7gGxGVbq4NLBIyFiGO63Tzrx1MHy+wN46O2aifCQ1ZLz9Q9LCkP2XbSL4kEc+d5 eZn2ElV9c8DiL+Ya/ERFL8CbqDmDx3IJbNmzrnjVw3YaG9S6HSlKp61LWma1BwVZVvAP 1/J+Cv/xGJUwUXfWfZd16V3jA/BfMreqqXDXM= MIME-Version: 1.0 Received: by 10.216.162.68 with SMTP id x46mr616010wek.2.1264527657404; Tue, 26 Jan 2010 09:40:57 -0800 (PST) In-Reply-To: <147432021001260914x6e5e1b41n4146904ead9d9108@mail.gmail.com> References: <20091201.102925.218343479.hrs@allbsd.org> <147432021001242047k659a26d0s44b35164920aeb74@mail.gmail.com> <95D3CB82-BC44-491D-86E4-5CB82F89C0FC@nokia.com> <147432021001250825p202914a7ka5a2c1d28d96bac3@mail.gmail.com> <20100125182257.GG1187@michelle.cdnetworks.com> <147432021001251038r69393ab3m1a797e58f9fa905a@mail.gmail.com> <02307620-ECDC-4E8B-A5B1-FF8491E226C4@nokia.com> <33c6b0bc1001252031k508426bfh25fad65e9223d87@mail.gmail.com> <147432021001260900p60ed1804t97392d2dff5cd244@mail.gmail.com> <147432021001260914x6e5e1b41n4146904ead9d9108@mail.gmail.com> Date: Tue, 26 Jan 2010 09:40:57 -0800 Message-ID: <2a41acea1001260940sf89512ar5514cee9bb08fd9@mail.gmail.com> From: Jack Vogel To: Nick Rogers Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: "stable@freebsd.org" , Joshua Boyd Subject: Re: em interface slow down on 8.0R X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 26 Jan 2010 17:41:01 -0000 No, it hasn't, I need time to look it over and be convinced of what he was doing. Jack On Tue, Jan 26, 2010 at 9:14 AM, Nick Rogers wrote: > looks like the patch mentioned in kern/141843 has not been applied to the > tree? > > On Tue, Jan 26, 2010 at 9:00 AM, Nick Rogers wrote: > > > Is it advisable to patch 8.0-RELEASE kernel sources with the latest > > (CURRENT) em driver (i.e., src/sys/dev/e1000)? It looks like there are > some > > updates to the driver since 8.0-RELEASE that may fix some problems? > > > > > _______________________________________________ > 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 Jan 26 17:52:00 2010 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BD6311065676; Tue, 26 Jan 2010 17:52:00 +0000 (UTC) (envelope-from marck@rinet.ru) Received: from woozle.rinet.ru (woozle.rinet.ru [195.54.192.68]) by mx1.freebsd.org (Postfix) with ESMTP id D4B128FC19; Tue, 26 Jan 2010 17:51:59 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by woozle.rinet.ru (8.14.3/8.14.3) with ESMTP id o0QHpwa2073569; Tue, 26 Jan 2010 20:51:58 +0300 (MSK) (envelope-from marck@rinet.ru) Date: Tue, 26 Jan 2010 20:51:58 +0300 (MSK) From: Dmitry Morozovsky To: freebsd-stable@FreeBSD.org Message-ID: User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) X-NCC-RegID: ru.rinet X-OpenPGP-Key-ID: 6B691B03 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.3 (woozle.rinet.ru [0.0.0.0]); Tue, 26 Jan 2010 20:51:58 +0300 (MSK) Cc: Pawel Jakub Dawidek Subject: Another ZFS RELENG_7/i386 strangeness: Operation not permitted X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 26 Jan 2010 17:52:00 -0000 Dear colleagues, stable/7 as of yesterday. Operation not permitted errors during `rsync -avH --fileflags' to ZFS. Investigating: root@woozle:/usr/ports# la -io /w/backup/woozle/var/log/www/woozle/.access_log.9.gz.* 73613 -rw-r--r-- 1 root wheel - 1200326 Sep 25 2005 /w/backup/woozle/var/log/www/woozle/.access_log.9.gz.bg9Zcw 73728 -rw-r--r-- 1 root wheel - 1200326 Sep 25 2005 /w/backup/woozle/var/log/www/woozle/.access_log.9.gz.dxux3T 28355 -rw-r--r-- 1 root wheel - 1200326 Sep 25 2005 /w/backup/woozle/var/log/www/woozle/.access_log.9.gz.wxuWSQ root@woozle:/usr/ports# rm -f !$ rm -f /w/backup/woozle/var/log/www/woozle/.access_log.9.gz.* rm: /w/backup/woozle/var/log/www/woozle/.access_log.9.gz.bg9Zcw: Operation not permitted rm: /w/backup/woozle/var/log/www/woozle/.access_log.9.gz.dxux3T: Operation not permitted rm: /w/backup/woozle/var/log/www/woozle/.access_log.9.gz.wxuWSQ: Operation not permitted zfs umount/mount does not fix the problem. turning on vfs.zfs.debug does not reveal anything. WTF? (sorry ;) I'm puzzled. -- Sincerely, D.Marck [DM5020, MCK-RIPE, DM3-RIPN] [ FreeBSD committer: marck@FreeBSD.org ] ------------------------------------------------------------------------ *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- marck@rinet.ru *** ------------------------------------------------------------------------ From owner-freebsd-stable@FreeBSD.ORG Tue Jan 26 17:56:52 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9D9201065694; Tue, 26 Jan 2010 17:56:52 +0000 (UTC) (envelope-from marck@rinet.ru) Received: from woozle.rinet.ru (woozle.rinet.ru [195.54.192.68]) by mx1.freebsd.org (Postfix) with ESMTP id 198D78FC1A; Tue, 26 Jan 2010 17:56:51 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by woozle.rinet.ru (8.14.3/8.14.3) with ESMTP id o0QHuoBb073662; Tue, 26 Jan 2010 20:56:50 +0300 (MSK) (envelope-from marck@rinet.ru) Date: Tue, 26 Jan 2010 20:56:50 +0300 (MSK) From: Dmitry Morozovsky To: Artem Belevich In-Reply-To: Message-ID: References: <20100125191030.GG1643@garage.freebsd.pl> <20100126120030.15496xfctb8icfk8@webmail.leidinger.net> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) X-NCC-RegID: ru.rinet X-OpenPGP-Key-ID: 6B691B03 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.3 (woozle.rinet.ru [0.0.0.0]); Tue, 26 Jan 2010 20:56:50 +0300 (MSK) Cc: Alexander Leidinger , Pawel Jakub Dawidek , freebsd-stable@freebsd.org Subject: Re: ZFS panic on RELENG_7/i386 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 26 Jan 2010 17:56:52 -0000 On Tue, 26 Jan 2010, Artem Belevich wrote: AB> > will do, thank you. is fletcher4 faster? AB> Not necessarily. But it does work as a checksum much better. See AB> following link for the details. AB> AB> http://bugs.opensolaris.org/bugdatabase/view_bug.do?bug_id=6740597 Yes, I already read some articles about fletcher checksums and related. Thanks. -- Sincerely, D.Marck [DM5020, MCK-RIPE, DM3-RIPN] [ FreeBSD committer: marck@FreeBSD.org ] ------------------------------------------------------------------------ *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- marck@rinet.ru *** ------------------------------------------------------------------------ From owner-freebsd-stable@FreeBSD.ORG Tue Jan 26 18:10:51 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AA9561065750 for ; Tue, 26 Jan 2010 18:10:51 +0000 (UTC) (envelope-from dillon@apollo.backplane.com) Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by mx1.freebsd.org (Postfix) with ESMTP id A9AB28FC0C for ; Tue, 26 Jan 2010 18:10:50 +0000 (UTC) Received: from apollo.backplane.com (localhost [127.0.0.1]) by apollo.backplane.com (8.14.2/8.14.1) with ESMTP id o0QI0R01014634; Tue, 26 Jan 2010 10:00:27 -0800 (PST) Received: (from dillon@localhost) by apollo.backplane.com (8.14.2/8.13.4/Submit) id o0QI0QHA014631; Tue, 26 Jan 2010 10:00:26 -0800 (PST) Date: Tue, 26 Jan 2010 10:00:26 -0800 (PST) From: Matthew Dillon Message-Id: <201001261800.o0QI0QHA014631@apollo.backplane.com> To: Aragon Gouveia References: <4B54C100.9080906@mail.zedat.fu-berlin.de> <4B5CCBDA.3090403@phat.za.net> Cc: freebsd-stable@freebsd.org Subject: Re: immense delayed write to file system (ZFS and UFS2), performance issues X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jan 2010 18:10:51 -0000 :I'm experiencing the same thing, except in my case it's most noticeable :when writing to a USB flash drive with a FAT32 filesystem. It slows the :entire system down, even if the data being written is coming from cache :or a memory file system. : :I don't know if it's related. I'm running 8-STABLE from about 4 December. : :Regards, :Aragon I don't know re: the main thread but in regards to writing to a USB flash drive interfering with other operations the most likely cause is that the buffer cache fills up with dirty buffers destined for the (slow) USB drive. This causes other unrelated drive subsystems to block on the buffer cache. There are no easy answers. A poor-man's solution would be to limit dirty buffers in the buffer cache to 80% of the nominal dirty maximum on a per-mount basis so no single mount can kill the buffer cache. (One can't just cut-up the buffer cache as that would leave too few buffers available for each mount to operate efficiently). A per-mount minimum buffer guarantee would also help smooth things out but the value would have to be small (comprise no more than 20% of the buffer cache in aggregate). In the case of UFS the write-behind code is asynchronous, so even though UFS wants to flush the buffers out all that happens in reality when writing to slow media is that the dirty buffers wind up on the I/O queue (which is actually worse then leaving them B_DELWRI in the buffer cache because now the VM pages are all soft-busied). -Matt Matthew Dillon From owner-freebsd-stable@FreeBSD.ORG Tue Jan 26 18:14:19 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 84DD21065670; Tue, 26 Jan 2010 18:14:19 +0000 (UTC) (envelope-from marck@rinet.ru) Received: from woozle.rinet.ru (woozle.rinet.ru [195.54.192.68]) by mx1.freebsd.org (Postfix) with ESMTP id A7A538FC1D; Tue, 26 Jan 2010 18:14:18 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by woozle.rinet.ru (8.14.3/8.14.3) with ESMTP id o0QIEHE9074022; Tue, 26 Jan 2010 21:14:17 +0300 (MSK) (envelope-from marck@rinet.ru) Date: Tue, 26 Jan 2010 21:14:17 +0300 (MSK) From: Dmitry Morozovsky To: freebsd-stable@freebsd.org In-Reply-To: Message-ID: References: User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) X-NCC-RegID: ru.rinet X-OpenPGP-Key-ID: 6B691B03 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.3 (woozle.rinet.ru [0.0.0.0]); Tue, 26 Jan 2010 21:14:17 +0300 (MSK) Cc: Pawel Jakub Dawidek Subject: Re: Another ZFS RELENG_7/i386 strangeness: Operation not permitted X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 26 Jan 2010 18:14:19 -0000 On Tue, 26 Jan 2010, Dmitry Morozovsky wrote: DM> Dear colleagues, DM> DM> stable/7 as of yesterday. Operation not permitted errors during DM> `rsync -avH --fileflags' to ZFS. Investigating: DM> DM> root@woozle:/usr/ports# la -io DM> /w/backup/woozle/var/log/www/woozle/.access_log.9.gz.* DM> 73613 -rw-r--r-- 1 root wheel - 1200326 Sep 25 2005 /w/backup/woozle/var/log/www/woozle/.access_log.9.gz.bg9Zcw DM> 73728 -rw-r--r-- 1 root wheel - 1200326 Sep 25 2005 /w/backup/woozle/var/log/www/woozle/.access_log.9.gz.dxux3T DM> 28355 -rw-r--r-- 1 root wheel - 1200326 Sep 25 2005 /w/backup/woozle/var/log/www/woozle/.access_log.9.gz.wxuWSQ DM> root@woozle:/usr/ports# rm -f !$ DM> rm -f /w/backup/woozle/var/log/www/woozle/.access_log.9.gz.* DM> rm: /w/backup/woozle/var/log/www/woozle/.access_log.9.gz.bg9Zcw: Operation not permitted DM> rm: /w/backup/woozle/var/log/www/woozle/.access_log.9.gz.dxux3T: Operation not permitted DM> rm: /w/backup/woozle/var/log/www/woozle/.access_log.9.gz.wxuWSQ: Operation not permitted DM> DM> zfs umount/mount does not fix the problem. turning on vfs.zfs.debug does not DM> reveal anything. DM> DM> WTF? (sorry ;) I'm puzzled. found the source: it's sunlnk flag on a directory, which behaves differently on UFS and ZFS: on UFS, this flag does not prevent removing files from the directory, only removing and renaming directory itself. Should I file a PR? -- Sincerely, D.Marck [DM5020, MCK-RIPE, DM3-RIPN] [ FreeBSD committer: marck@FreeBSD.org ] ------------------------------------------------------------------------ *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- marck@rinet.ru *** ------------------------------------------------------------------------ From owner-freebsd-stable@FreeBSD.ORG Tue Jan 26 18:19:51 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 295DD106566C for ; Tue, 26 Jan 2010 18:19:51 +0000 (UTC) (envelope-from bruce@cran.org.uk) Received: from muon.cran.org.uk (unknown [IPv6:2001:470:1f09:679::1]) by mx1.freebsd.org (Postfix) with ESMTP id E43698FC0C for ; Tue, 26 Jan 2010 18:19:50 +0000 (UTC) Received: from unknown (client-86-10-3-126.leed.adsl.virginmedia.com [86.10.3.126]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by muon.cran.org.uk (Postfix) with ESMTPSA id B8AEB849F; Tue, 26 Jan 2010 18:20:07 +0000 (UTC) Date: Tue, 26 Jan 2010 18:19:55 +0000 From: Bruce Cran To: Morgan =?ISO-8859-1?Q?Wesstr=F6m?= Message-ID: <20100126181955.000065cb@unknown> In-Reply-To: <4B557B5A.8040902@pp.dyndns.biz> References: <4B54C100.9080906@mail.zedat.fu-berlin.de> <4B54C5EE.5070305@pp.dyndns.biz> <201001191250.23625.doconnor@gsoft.com.au> <7346c5c61001181841j3653a7c3m32bc033c8c146a92@mail.gmail.com> <4B557B5A.8040902@pp.dyndns.biz> X-Mailer: Claws Mail 3.7.2cvs27 (GTK+ 2.16.0; i586-pc-mingw32msvc) Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "O. Hartmann" , freebsd-stable@freebsd.org, Garrett Moore Subject: Re: immense delayed write to file system (ZFS and UFS2), performance issues X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jan 2010 18:19:51 -0000 On Tue, 19 Jan 2010 10:28:58 +0100 Morgan Wesstr=F6m wrote: > Garrett Moore wrote: > > The drives being discussed in my related thread (regarding poor > > performance) are all WD Green drives. I have used wdidle3 to set > > all of my drive timeouts to 5 minutes. I'll see what sort of > > difference this makes for performance. > >=20 > > Even if it makes no difference to performance, thank you for > > pointing it out -- my drives have less than 2,000 hours on them and > > were all over 90,000 load cycles due to this moronic factory > > setting. Since changing the timeout, they haven't parked (which is > > what I would expect). > >=20 >=20 > You're welcome. I just feel as bad for you as for everyone else who > has bought these obviously Windoze optimized harddrives. Unfortunately > neither wdidle3 nor an updated firmware is available or functioning on > the latest models in the Green series. At least that's what I've read > from other people having this issue. WD only claims they don't support > Linux and they probably have never heard of FreeBSD. You might be able to tune the APM settings on the drive using sysutils/ataidle to change the amount of time the drive waits until parking the heads. --=20 Bruce Cran From owner-freebsd-stable@FreeBSD.ORG Tue Jan 26 18:38:01 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3549B106566C; Tue, 26 Jan 2010 18:38:01 +0000 (UTC) (envelope-from marius@alchemy.franken.de) Received: from alchemy.franken.de (alchemy.franken.de [194.94.249.214]) by mx1.freebsd.org (Postfix) with ESMTP id 9A24A8FC26; Tue, 26 Jan 2010 18:38:00 +0000 (UTC) Received: from alchemy.franken.de (localhost [127.0.0.1]) by alchemy.franken.de (8.14.3/8.14.3/ALCHEMY.FRANKEN.DE) with ESMTP id o0QIbug7042165; Tue, 26 Jan 2010 19:37:56 +0100 (CET) (envelope-from marius@alchemy.franken.de) Received: (from marius@localhost) by alchemy.franken.de (8.14.3/8.14.3/Submit) id o0QIbuRV042164; Tue, 26 Jan 2010 19:37:56 +0100 (CET) (envelope-from marius) Date: Tue, 26 Jan 2010 19:37:56 +0100 From: Marius Strobl To: Peter Jeremy Message-ID: <20100126183756.GA40779@alchemy.franken.de> References: <20100126073336.GA1955@server.vk2pj.dyndns.org> <201001260946.44977.jhb@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201001260946.44977.jhb@freebsd.org> User-Agent: Mutt/1.4.2.3i Cc: rmacklem@freebsd.org, dfr@freebsd.org, freebsd-stable@freebsd.org, John Baldwin Subject: Re: uma_zalloc_arg complaining about non-sleepable locks X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jan 2010 18:38:01 -0000 On Tue, Jan 26, 2010 at 09:46:44AM -0500, John Baldwin wrote: > On Tuesday 26 January 2010 2:33:37 am Peter Jeremy wrote: > > I have just upgraded to 8-STABLE/amd64 from about 18 hours ago and am > > now getting regular (the following pair of messages about every > > minute) compaints as follows: > > > > kernel: uma_zalloc_arg: zone "mbuf" with the following non-sleepable locks held: > > kernel: exclusive sleep mutex sp_lock (sp_lock) r = 0 (0xffffff000460bb00) locked @ /usr/src/sys/rpc/svc.c:1098 > > kernel: KDB: stack backtrace: > > kernel: db_trace_self_wrapper() at db_trace_self_wrapper+0x2a > > kernel: _witness_debugger() at _witness_debugger+0x2c > > kernel: witness_warn() at witness_warn+0x2c2 > > kernel: uma_zalloc_arg() at uma_zalloc_arg+0x29d > > kernel: nfs_realign() at nfs_realign+0x5f > > kernel: fha_assign() at fha_assign+0x2d8 > > kernel: svc_run_internal() at svc_run_internal+0x1ee > > kernel: svc_thread_start() at svc_thread_start+0xb > > kernel: fork_exit() at fork_exit+0x112 > > kernel: fork_trampoline() at fork_trampoline+0xe > > kernel: --- trap 0xc, rip = 0x80069e04c, rsp = 0x7fffffffe6d8, rbp = 0x5 --- > > kernel: uma_zalloc_arg: zone "mbuf" with the following non-sleepable locks held: > > kernel: exclusive sleep mutex sp_lock (sp_lock) r = 0 (0xffffff000460bb00) locked @ /usr/src/sys/rpc/svc.c:1098 > > kernel: KDB: stack backtrace: > > kernel: db_trace_self_wrapper() at db_trace_self_wrapper+0x2a > > kernel: _witness_debugger() at _witness_debugger+0x2c > > kernel: witness_warn() at witness_warn+0x2c2 > > kernel: uma_zalloc_arg() at uma_zalloc_arg+0x29d > > kernel: nfs_realign() at nfs_realign+0x5f > > kernel: fha_assign() at fha_assign+0x2d8 > > kernel: svc_run_internal() at svc_run_internal+0x1ee > > kernel: svc_thread_start() at svc_thread_start+0xb > > kernel: fork_exit() at fork_exit+0x112 > > kernel: fork_trampoline() at fork_trampoline+0xe > > kernel: --- trap 0xc, rip = 0x80069e04c, rsp = 0x7fffffffe6d8, rbp = 0x5 --- > > > > It looks like NFS is missing some lock/unlock pairs. Has anyone else > > seen this? And does anyone have a fix? > > I suspect this was caused by the recent alignment fixes to NFS. I've cc'd > Marius. > Could you please give the following patch a try? http://people.freebsd.org/~marius/fha_extract_info_realign2.diff It would also be great if one of the NFS gurus could have a look at the whole issue. Unfortunately, I hadn't received a reply regarding the original patch. Marius From owner-freebsd-stable@FreeBSD.ORG Tue Jan 26 18:45:14 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 24509106566C for ; Tue, 26 Jan 2010 18:45:14 +0000 (UTC) (envelope-from dan.naumov@gmail.com) Received: from mail-yw0-f197.google.com (mail-yw0-f197.google.com [209.85.211.197]) by mx1.freebsd.org (Postfix) with ESMTP id CFBAF8FC16 for ; Tue, 26 Jan 2010 18:45:13 +0000 (UTC) Received: by ywh35 with SMTP id 35so3881150ywh.7 for ; Tue, 26 Jan 2010 10:45:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:content-type; bh=G1WkTGetneKm8+XA63DyBbI8BGbihkIF+js3UBODQnI=; b=PKfIlTQTs1xsLmHwxycqugiQ7LKAjG4oegXmO5FyFwgZNgujF9Cfot+InhZMQa7Cts 4eOk68x+4RXljtdGkEtRTYimmyV9gxno2hA+njN6XsN5Y0OolCiyNlyEjgUwNbsnkzWa gfJ5kXaYqJNgnmThHlVbja9uaIDYgS39D0zOs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=dKs+TZZPyudVQT9ahq0/Em6ouJZhEmsgsSb3um7FRHow4ZA0/gvNsabQrcvNtRVGaJ NCp5OIWHVE/lfMEVOm8Pto9GFYt1C8RN7XYc2X7qS+r8REqgF3ivKkxMepsDJzlo+YCV UCc+vJajj7BebWHsYcycB0e/4qraIaGbdrke8= MIME-Version: 1.0 Received: by 10.101.115.16 with SMTP id s16mr10607298anm.21.1264531510612; Tue, 26 Jan 2010 10:45:10 -0800 (PST) Date: Tue, 26 Jan 2010 20:45:10 +0200 Message-ID: From: Dan Naumov To: FreeBSD-STABLE Mailing List Content-Type: text/plain; charset=ISO-8859-1 Subject: RE: immense delayed write to file system (ZFS and UFS2), performance issues X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jan 2010 18:45:14 -0000 > You're welcome. I just feel as bad for you as for everyone else who > has bought these obviously Windoze optimized harddrives. Unfortunately > neither wdidle3 nor an updated firmware is available or functioning on > the latest models in the Green series. At least that's what I've read > from other people having this issue. WD only claims they don't support > Linux and they probably have never heard of FreeBSD. This discussion made me have a look at my 2tb WD Green disks, one of them is from May 2009, looks pretty reasonable : Device Model: WDC WD20EADS-00R6B0 Serial Number: WD-WCAVY0301430 Firmware Version: 01.00A01 9 Power_On_Hours 0x0032 093 093 000 Old_age Always - 5253 193 Load_Cycle_Count 0x0032 200 200 000 Old_age Always - 55 And another is very recent, from December 2009, this does look a bit worrying in comparison: Device Model: WDC WD20EADS-32R6B0 Serial Number: WD-WCAVY1611513 Firmware Version: 01.00A01 9 Power_On_Hours 0x0032 100 100 000 Old_age Always - 136 193 Load_Cycle_Count 0x0032 199 199 000 Old_age Always - 5908 The disks are of exact same model and look to be same firmware. Should I be worried that the newer disk has, in 136 hours reached a higher Load Cycle count twice as big as on the disk thats 5253 hours old? - Sincerely, Dan Naumov From owner-freebsd-stable@FreeBSD.ORG Tue Jan 26 19:02:49 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C0AC1106568B for ; Tue, 26 Jan 2010 19:02:49 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from mail2.fluidhosting.com (mx21.fluidhosting.com [204.14.89.4]) by mx1.freebsd.org (Postfix) with ESMTP id 4F2318FC0A for ; Tue, 26 Jan 2010 19:02:49 +0000 (UTC) Received: (qmail 7612 invoked by uid 399); 26 Jan 2010 19:02:48 -0000 Received: from localhost (HELO foreign.dougb.net) (dougb@dougbarton.us@127.0.0.1) by localhost with ESMTPAM; 26 Jan 2010 19:02:48 -0000 X-Originating-IP: 127.0.0.1 X-Sender: dougb@dougbarton.us Message-ID: <4B5F3C58.2020706@FreeBSD.org> Date: Tue, 26 Jan 2010 11:02:48 -0800 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.9.1.7) Gecko/20100123 Thunderbird/3.0.1 MIME-Version: 1.0 To: "M. Vale" References: <4AFCBD9C.1030306@langille.org> <327c85b8398333978f642aa5dc2cbec4.squirrel@nyi.unixathome.org> <85d001331001260206l1b8831eei17bfe1f8a83cc566@mail.gmail.com> In-Reply-To: <85d001331001260206l1b8831eei17bfe1f8a83cc566@mail.gmail.com> X-Enigmail-Version: 1.0 OpenPGP: id=D5B2F0FB Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: FreeBSD Stable , Dan Langille Subject: Re: hald running 100% X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 26 Jan 2010 19:02:49 -0000 On 01/26/10 02:06, M. Vale wrote: > If you upgrade to FreeBSD 8 you have to remote the package libusb from your > system. > > So remove the libusb package that HAL installs and then rebuild hal, > something like: > > portmaster -rRfp hal-0.5.11_26 First time through just 'portmaster -r hal-0.5.11_26' is enough. If that stops partway through then 'portmaster -R -r hal-0.5.11_26' will avoid you having to rebuild the dependent ports you rebuilt the first time through (although you will have to build hal again, and yes, I'm working on a solution for that). hth, Doug -- Improve the effectiveness of your Internet presence with a domain name makeover! http://SupersetSolutions.com/ Computers are useless. They can only give you answers. -- Pablo Picasso From owner-freebsd-stable@FreeBSD.ORG Tue Jan 26 19:17:53 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5917F1065704 for ; Tue, 26 Jan 2010 19:17:53 +0000 (UTC) (envelope-from bruce@cran.org.uk) Received: from muon.cran.org.uk (unknown [IPv6:2001:470:1f09:679::1]) by mx1.freebsd.org (Postfix) with ESMTP id 1E4BA8FC1F for ; Tue, 26 Jan 2010 19:17:53 +0000 (UTC) Received: from muon.cran.org.uk (localhost [127.0.0.1]) by muon.cran.org.uk (Postfix) with ESMTP id 601E8843A; Tue, 26 Jan 2010 19:18:08 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on muon.cran.org.uk X-Spam-Level: X-Spam-Status: No, score=0.1 required=8.0 tests=RDNS_DYNAMIC autolearn=no version=3.2.5 Received: from unknown (client-86-10-3-126.leed.adsl.virginmedia.com [86.10.3.126]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by muon.cran.org.uk (Postfix) with ESMTPSA; Tue, 26 Jan 2010 19:18:08 +0000 (UTC) Date: Tue, 26 Jan 2010 19:17:44 +0000 From: Bruce Cran To: Dan Naumov Message-ID: <20100126191744.00000305@unknown> In-Reply-To: References: X-Mailer: Claws Mail 3.7.2cvs27 (GTK+ 2.16.0; i586-pc-mingw32msvc) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: FreeBSD-STABLE Mailing List Subject: Re: immense delayed write to file system (ZFS and UFS2), performance issues X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jan 2010 19:17:53 -0000 On Tue, 26 Jan 2010 20:45:10 +0200 Dan Naumov wrote: > The disks are of exact same model and look to be same firmware. Should > I be worried that the newer disk has, in 136 hours reached a higher > Load Cycle count twice as big as on the disk thats 5253 hours old? There's a similar problem with laptop HDDs and APM settings that cause a high load_cycle_count too. According to https://bugs.launchpad.net/ubuntu/+source/acpi-support/+bug/59695 and many blog entries, parking the heads frequently can shorten the HDD lifetime. -- Bruce Cran From owner-freebsd-stable@FreeBSD.ORG Tue Jan 26 19:20:17 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 94D671065692 for ; Tue, 26 Jan 2010 19:20:17 +0000 (UTC) (envelope-from sty@blosphere.net) Received: from mail-pz0-f176.google.com (mail-pz0-f176.google.com [209.85.222.176]) by mx1.freebsd.org (Postfix) with ESMTP id 40B188FC1D for ; Tue, 26 Jan 2010 19:20:17 +0000 (UTC) Received: by pzk6 with SMTP id 6so174820pzk.3 for ; Tue, 26 Jan 2010 11:20:16 -0800 (PST) MIME-Version: 1.0 Sender: sty@blosphere.net Received: by 10.114.44.9 with SMTP id r9mr2468391war.179.1264532001033; Tue, 26 Jan 2010 10:53:21 -0800 (PST) In-Reply-To: References: Date: Wed, 27 Jan 2010 03:53:20 +0900 X-Google-Sender-Auth: ea9587900e9660a6 Message-ID: From: =?UTF-8?B?VG9tbWkgTMOkdHRp?= To: Dan Naumov Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: FreeBSD-STABLE Mailing List Subject: Re: immense delayed write to file system (ZFS and UFS2), performance issues X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jan 2010 19:20:17 -0000 > =C2=A09 Power_On_Hours =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A00x0032 =C2=A0 10= 0 =C2=A0 100 =C2=A0 000 =C2=A0 =C2=A0Old_age > Always =C2=A0 =C2=A0 =C2=A0 - =C2=A0 =C2=A0 =C2=A0 136 > 193 Load_Cycle_Count =C2=A0 =C2=A0 =C2=A0 =C2=A00x0032 =C2=A0 199 =C2=A0 = 199 =C2=A0 000 =C2=A0 =C2=A0Old_age > Always =C2=A0 =C2=A0 =C2=A0 - =C2=A0 =C2=A0 =C2=A0 5908 > > The disks are of exact same model and look to be same firmware. Should > I be worried that the newer disk has, in 136 hours reached a higher > Load Cycle count twice as big as on the disk thats 5253 hours old? Well AFAIK WD certifies that there's no extra risk involved unless you go over 300.000 park cycles. On the other hand, my 9 month 1.5tb green drive has over 200.000 cycles. Maybe check if you can disable the idle timer using WDIDLE3... works for my drives (although it did some strange things to one out of the 6 drives --> decreased reported sector count and the zfs invalidated the pool :/ ). --=20 br, Tommi From owner-freebsd-stable@FreeBSD.ORG Tue Jan 26 19:23:58 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 586411065679 for ; Tue, 26 Jan 2010 19:23:58 +0000 (UTC) (envelope-from cswiger@mac.com) Received: from asmtpout029.mac.com (asmtpout029.mac.com [17.148.16.104]) by mx1.freebsd.org (Postfix) with ESMTP id 12D658FC1B for ; Tue, 26 Jan 2010 19:23:57 +0000 (UTC) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=us-ascii Received: from cswiger1.apple.com ([17.209.4.71]) by asmtp029.mac.com (Sun Java(tm) System Messaging Server 6.3-8.01 (built Dec 16 2008; 32bit)) with ESMTPSA id <0KWV007KDCJW8S10@asmtp029.mac.com> for freebsd-stable@freebsd.org; Tue, 26 Jan 2010 11:23:57 -0800 (PST) X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx engine=5.0.0-0908210000 definitions=main-1001260147 From: Chuck Swiger In-reply-to: Date: Tue, 26 Jan 2010 11:23:56 -0800 Message-id: <087264FA-3E22-4855-BC38-346ADF22F422@mac.com> References: To: Dan Naumov X-Mailer: Apple Mail (2.1077) Cc: FreeBSD-STABLE Mailing List Subject: Re: immense delayed write to file system (ZFS and UFS2), performance issues X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jan 2010 19:23:58 -0000 Hi-- On Jan 26, 2010, at 10:45 AM, Dan Naumov wrote: > 9 Power_On_Hours 0x0032 100 100 000 Old_age > Always - 136 > 193 Load_Cycle_Count 0x0032 199 199 000 Old_age > Always - 5908 > > The disks are of exact same model and look to be same firmware. Should > I be worried that the newer disk has, in 136 hours reached a higher > Load Cycle count twice as big as on the disk thats 5253 hours old? Yes. Drive actuators are (or used to be) typically rated for at least 50,000 load-cycle counts; at ~1000 events per day, there's about a 50% chance of such a drive dying before two years are up: http://en.wikipedia.org/wiki/Hard_disk_drive#Landing_zones_and_load.2Funload_technology Some models of drives intended for laptops (typically smaller 2.5" form factor w/ single platter) can tolerate many more load-cycles, and newer drives also claim to handle more. Regards, -- -Chuck From owner-freebsd-stable@FreeBSD.ORG Tue Jan 26 19:42:17 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9D6D0106566C for ; Tue, 26 Jan 2010 19:42:17 +0000 (UTC) (envelope-from gerrit@pmp.uni-hannover.de) Received: from mrelay1.uni-hannover.de (mrelay1.uni-hannover.de [130.75.2.106]) by mx1.freebsd.org (Postfix) with ESMTP id 0E0A68FC0A for ; Tue, 26 Jan 2010 19:42:16 +0000 (UTC) Received: from www.pmp.uni-hannover.de (www.pmp.uni-hannover.de [130.75.117.2]) by mrelay1.uni-hannover.de (8.14.2/8.14.2) with ESMTP id o0QJgDIS000759; Tue, 26 Jan 2010 20:42:15 +0100 Received: from pmp.uni-hannover.de (theq.pmp.uni-hannover.de [130.75.117.4]) by www.pmp.uni-hannover.de (Postfix) with SMTP id E20ED24; Tue, 26 Jan 2010 20:42:13 +0100 (CET) Date: Tue, 26 Jan 2010 20:42:13 +0100 From: Gerrit =?ISO-8859-1?Q?K=FChn?= To: Tommi =?ISO-8859-1?Q?L=E4tti?= Message-Id: <20100126204213.033bbebe.gerrit@pmp.uni-hannover.de> In-Reply-To: References: Organization: Albert-Einstein-Institut (MPI =?ISO-8859-1?Q?f=FCr?= Gravitationsphysik & IGP =?ISO-8859-1?Q?Universit=E4t?= Hannover) X-Mailer: Sylpheed 2.4.2 (GTK+ 2.10.12; i386-portbld-freebsd6.1) Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-PMX-Version: 5.5.9.388399, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2010.1.26.193039 Cc: FreeBSD-STABLE Mailing List , Dan Naumov Subject: Re: immense delayed write to file system (ZFS and UFS2), performance issues X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jan 2010 19:42:17 -0000 On Wed, 27 Jan 2010 03:53:20 +0900 Tommi L=E4tti wrote about Re: immense delayed write to file system (ZFS and UFS2), performance issues: TL> Well AFAIK WD certifies that there's no extra risk involved unless you TL> go over 300.000 park cycles. On the other hand, my 9 month 1.5tb green TL> drive has over 200.000 cycles. I think the RE2 drives I have here are certified for 600k cycles. TL> Maybe check if you can disable the idle timer using WDIDLE3... works TL> for my drives (although it did some strange things to one out of the 6 TL> drives --> decreased reported sector count and the zfs invalidated the TL> pool :/ ). I can only encourage everyone having this problem to report to WD's support about this. Today I received an update for the firmware of RE4-drives (which I did not try out yet). IMHO, the more people complain about these issues, the higher is the chance that WD will do something about it. cu Gerrit From owner-freebsd-stable@FreeBSD.ORG Tue Jan 26 19:55:03 2010 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7600F106568D; Tue, 26 Jan 2010 19:55:03 +0000 (UTC) (envelope-from jfvogel@gmail.com) Received: from mail-fx0-f227.google.com (mail-fx0-f227.google.com [209.85.220.227]) by mx1.freebsd.org (Postfix) with ESMTP id CF6BA8FC1C; Tue, 26 Jan 2010 19:55:01 +0000 (UTC) Received: by fxm27 with SMTP id 27so2356729fxm.3 for ; Tue, 26 Jan 2010 11:55:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=wAREsTWkLgVnp83FUOjQjNeJ9U6sRbXalrjMXq/gfMM=; b=C0FS3ggjt5/PrLTtcSHVRrZB8dHOXuuaMU8tDP8/o+xSRybNqrHw2owGRFD6SWsffL 9XyTQyQz5B+mzttszHhoUSftZKQumaWnfPt0j1gkd6qJca53vXfcxWBNJuSl8N89YLsT nP90E3rBfVhjziSnPqLd340x41MEiYt5rHahQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=YDnx5NJDHqtt/Yn7zKrON7ypo8DPVJ+dQBBYpVADFjvusPPV6Hrc1wKbQ2nyOgucMA 2QjvwRMZpTprK278xdVEoa3hvjyeAgvpGMzTAqqs8L739wrg98Wrod+N5vVrcxvuJW0E 3Bm2/7Zb1vjVucGqDkK9yMB/htFmI4MTx4la4= MIME-Version: 1.0 Received: by 10.216.169.201 with SMTP id n51mr294018wel.209.1264535701087; Tue, 26 Jan 2010 11:55:01 -0800 (PST) In-Reply-To: <2a41acea1001260940sf89512ar5514cee9bb08fd9@mail.gmail.com> References: <20091201.102925.218343479.hrs@allbsd.org> <95D3CB82-BC44-491D-86E4-5CB82F89C0FC@nokia.com> <147432021001250825p202914a7ka5a2c1d28d96bac3@mail.gmail.com> <20100125182257.GG1187@michelle.cdnetworks.com> <147432021001251038r69393ab3m1a797e58f9fa905a@mail.gmail.com> <02307620-ECDC-4E8B-A5B1-FF8491E226C4@nokia.com> <33c6b0bc1001252031k508426bfh25fad65e9223d87@mail.gmail.com> <147432021001260900p60ed1804t97392d2dff5cd244@mail.gmail.com> <147432021001260914x6e5e1b41n4146904ead9d9108@mail.gmail.com> <2a41acea1001260940sf89512ar5514cee9bb08fd9@mail.gmail.com> Date: Tue, 26 Jan 2010 11:55:00 -0800 Message-ID: <2a41acea1001261155v20a54d39qdc5ad7b9ac88291d@mail.gmail.com> From: Jack Vogel To: Nick Rogers , Pyun YongHyeon Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: "stable@freebsd.org" , Joshua Boyd Subject: Re: em interface slow down on 8.0R X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 26 Jan 2010 19:55:03 -0000 I've tried this patch, and it completely breaks IPv6 offloads, which DO work btw, our testers have a netperf stress test that does both ipv4 and ipv6, and that test fails 100% after this change. I could go hacking at it myself but as its your code Pyun would you like to resolve this issue? Regards, Jack On Tue, Jan 26, 2010 at 9:40 AM, Jack Vogel wrote: > No, it hasn't, I need time to look it over and be convinced of what he was > doing. > > Jack > > > > On Tue, Jan 26, 2010 at 9:14 AM, Nick Rogers wrote: > >> looks like the patch mentioned in kern/141843 has not been applied to the >> tree? >> >> On Tue, Jan 26, 2010 at 9:00 AM, Nick Rogers wrote: >> >> > Is it advisable to patch 8.0-RELEASE kernel sources with the latest >> > (CURRENT) em driver (i.e., src/sys/dev/e1000)? It looks like there are >> some >> > updates to the driver since 8.0-RELEASE that may fix some problems? >> > >> > >> _______________________________________________ >> 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 Jan 26 20:12:28 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C77A01065672; Tue, 26 Jan 2010 20:12:28 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 8334F8FC14; Tue, 26 Jan 2010 20:12:28 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id 143D346B4C; Tue, 26 Jan 2010 15:12:28 -0500 (EST) Received: from jhbbsd.localnet (smtp.hudson-trading.com [209.249.190.9]) by bigwig.baldwin.cx (Postfix) with ESMTPA id 50D178A021; Tue, 26 Jan 2010 15:12:27 -0500 (EST) From: John Baldwin To: Marius Strobl Date: Tue, 26 Jan 2010 15:10:59 -0500 User-Agent: KMail/1.12.1 (FreeBSD/7.2-CBSD-20100120; KDE/4.3.1; amd64; ; ) References: <20100126073336.GA1955@server.vk2pj.dyndns.org> <201001260946.44977.jhb@freebsd.org> <20100126183756.GA40779@alchemy.franken.de> In-Reply-To: <20100126183756.GA40779@alchemy.franken.de> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201001261510.59667.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (bigwig.baldwin.cx); Tue, 26 Jan 2010 15:12:27 -0500 (EST) X-Virus-Scanned: clamav-milter 0.95.1 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-2.6 required=4.2 tests=AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on bigwig.baldwin.cx Cc: rmacklem@freebsd.org, dfr@freebsd.org, freebsd-stable@freebsd.org, Peter Jeremy Subject: Re: uma_zalloc_arg complaining about non-sleepable locks X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jan 2010 20:12:29 -0000 On Tuesday 26 January 2010 1:37:56 pm Marius Strobl wrote: > On Tue, Jan 26, 2010 at 09:46:44AM -0500, John Baldwin wrote: > > On Tuesday 26 January 2010 2:33:37 am Peter Jeremy wrote: > > > I have just upgraded to 8-STABLE/amd64 from about 18 hours ago and am > > > now getting regular (the following pair of messages about every > > > minute) compaints as follows: > > > > > > kernel: uma_zalloc_arg: zone "mbuf" with the following non-sleepable locks held: > > > kernel: exclusive sleep mutex sp_lock (sp_lock) r = 0 (0xffffff000460bb00) locked @ /usr/src/sys/rpc/svc.c:1098 > > > kernel: KDB: stack backtrace: > > > kernel: db_trace_self_wrapper() at db_trace_self_wrapper+0x2a > > > kernel: _witness_debugger() at _witness_debugger+0x2c > > > kernel: witness_warn() at witness_warn+0x2c2 > > > kernel: uma_zalloc_arg() at uma_zalloc_arg+0x29d > > > kernel: nfs_realign() at nfs_realign+0x5f > > > kernel: fha_assign() at fha_assign+0x2d8 > > > kernel: svc_run_internal() at svc_run_internal+0x1ee > > > kernel: svc_thread_start() at svc_thread_start+0xb > > > kernel: fork_exit() at fork_exit+0x112 > > > kernel: fork_trampoline() at fork_trampoline+0xe > > > kernel: --- trap 0xc, rip = 0x80069e04c, rsp = 0x7fffffffe6d8, rbp = 0x5 --- > > > kernel: uma_zalloc_arg: zone "mbuf" with the following non-sleepable locks held: > > > kernel: exclusive sleep mutex sp_lock (sp_lock) r = 0 (0xffffff000460bb00) locked @ /usr/src/sys/rpc/svc.c:1098 > > > kernel: KDB: stack backtrace: > > > kernel: db_trace_self_wrapper() at db_trace_self_wrapper+0x2a > > > kernel: _witness_debugger() at _witness_debugger+0x2c > > > kernel: witness_warn() at witness_warn+0x2c2 > > > kernel: uma_zalloc_arg() at uma_zalloc_arg+0x29d > > > kernel: nfs_realign() at nfs_realign+0x5f > > > kernel: fha_assign() at fha_assign+0x2d8 > > > kernel: svc_run_internal() at svc_run_internal+0x1ee > > > kernel: svc_thread_start() at svc_thread_start+0xb > > > kernel: fork_exit() at fork_exit+0x112 > > > kernel: fork_trampoline() at fork_trampoline+0xe > > > kernel: --- trap 0xc, rip = 0x80069e04c, rsp = 0x7fffffffe6d8, rbp = 0x5 --- > > > > > > It looks like NFS is missing some lock/unlock pairs. Has anyone else > > > seen this? And does anyone have a fix? > > > > I suspect this was caused by the recent alignment fixes to NFS. I've cc'd > > Marius. > > > > Could you please give the following patch a try? > http://people.freebsd.org/~marius/fha_extract_info_realign2.diff > > It would also be great if one of the NFS gurus could have a look at > the whole issue. Unfortunately, I hadn't received a reply regarding > the original patch. Hmm, the old code was already using M_DONTWAIT, so now I don't see why you were getting the witness warning. -- John Baldwin From owner-freebsd-stable@FreeBSD.ORG Tue Jan 26 20:13:01 2010 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 478B01065701; Tue, 26 Jan 2010 20:13:01 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from mail-qy0-f176.google.com (mail-qy0-f176.google.com [209.85.221.176]) by mx1.freebsd.org (Postfix) with ESMTP id CFEF58FC19; Tue, 26 Jan 2010 20:13:00 +0000 (UTC) Received: by qyk6 with SMTP id 6so2920021qyk.3 for ; Tue, 26 Jan 2010 12:13:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:received:from:date:to:cc :subject:message-id:reply-to:references:mime-version:content-type :content-disposition:in-reply-to:user-agent; bh=KkX/0w3WKGQ+6FespzbK1f++iCA7bzeRQtG2GXd7p/I=; b=u8xJWisu1iddDNCbQcNEDlmOF6Kq5GMQdLVRQcyr5TMT3eFZ+nZfaA3BvUCZyb5IJz x1rpGnO3s6KKeyPc1pZeOtH/dhkHSGrsE9Qn9JlJ9/yhz5I6+Sk3q5rrPAr6500zRH1t VNFDQdwf9LmbCJF3O/HvOIHg4lzkvzRgOZ3oA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:date:to:cc:subject:message-id:reply-to:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; b=g3RJpTRfRsrGHamyZ6YijBur2hzFPSlkcwJ4g4qpCJOfOqr/xWTXWfRNL7HYD6KRut x6kRRZ9KvR/jUP3O8Hv0YNaxU13VleaQteYNESG2hwVNwk3/4MHQohnDZ8zaqYE7vFS0 +ltqxR+U1KdhlpTp5vBqj9ASU0GW9o/C/+I50= Received: by 10.224.126.197 with SMTP id d5mr5081632qas.354.1264536779565; Tue, 26 Jan 2010 12:12:59 -0800 (PST) Received: from pyunyh@gmail.com ([174.35.1.224]) by mx.google.com with ESMTPS id 4sm21617702qwe.15.2010.01.26.12.12.56 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 26 Jan 2010 12:12:58 -0800 (PST) Received: by pyunyh@gmail.com (sSMTP sendmail emulation); Tue, 26 Jan 2010 12:12:58 -0800 From: Pyun YongHyeon Date: Tue, 26 Jan 2010 12:12:58 -0800 To: Jack Vogel Message-ID: <20100126201258.GK1187@michelle.cdnetworks.com> References: <95D3CB82-BC44-491D-86E4-5CB82F89C0FC@nokia.com> <147432021001250825p202914a7ka5a2c1d28d96bac3@mail.gmail.com> <20100125182257.GG1187@michelle.cdnetworks.com> <147432021001251038r69393ab3m1a797e58f9fa905a@mail.gmail.com> <02307620-ECDC-4E8B-A5B1-FF8491E226C4@nokia.com> <33c6b0bc1001252031k508426bfh25fad65e9223d87@mail.gmail.com> <147432021001260900p60ed1804t97392d2dff5cd244@mail.gmail.com> <147432021001260914x6e5e1b41n4146904ead9d9108@mail.gmail.com> <2a41acea1001260940sf89512ar5514cee9bb08fd9@mail.gmail.com> <2a41acea1001261155v20a54d39qdc5ad7b9ac88291d@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <2a41acea1001261155v20a54d39qdc5ad7b9ac88291d@mail.gmail.com> User-Agent: Mutt/1.4.2.3i Cc: Nick Rogers , "stable@freebsd.org" , Joshua Boyd , Pyun YongHyeon Subject: Re: em interface slow down on 8.0R X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: pyunyh@gmail.com List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jan 2010 20:13:01 -0000 On Tue, Jan 26, 2010 at 11:55:00AM -0800, Jack Vogel wrote: > I've tried this patch, and it completely breaks IPv6 offloads, which DO work > btw, > our testers have a netperf stress test that does both ipv4 and ipv6, and > that test > fails 100% after this change. > > I could go hacking at it myself but as its your code Pyun would you like to > resolve this issue? > I wonder how you could test IPv6 checksum offloading/TSO as FreeBSD does not have that capability yet. Do we already have that capability? I vaguely remember there was an effort to bring the support in but I don't know current status. If we have the capability I would have to update all other drivers that can do IPv6 checksum offloading/TSO for IPv6. > Regards, > > Jack > > > On Tue, Jan 26, 2010 at 9:40 AM, Jack Vogel wrote: > > > No, it hasn't, I need time to look it over and be convinced of what he was > > doing. > > > > Jack > > > > > > > > On Tue, Jan 26, 2010 at 9:14 AM, Nick Rogers wrote: > > > >> looks like the patch mentioned in kern/141843 has not been applied to the > >> tree? > >> > >> On Tue, Jan 26, 2010 at 9:00 AM, Nick Rogers wrote: > >> > >> > Is it advisable to patch 8.0-RELEASE kernel sources with the latest > >> > (CURRENT) em driver (i.e., src/sys/dev/e1000)? It looks like there are > >> some > >> > updates to the driver since 8.0-RELEASE that may fix some problems? > >> > > >> > > >> _______________________________________________ > >> 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 Jan 26 20:22:04 2010 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 654401065679; Tue, 26 Jan 2010 20:22:04 +0000 (UTC) (envelope-from jfvogel@gmail.com) Received: from mail-fx0-f227.google.com (mail-fx0-f227.google.com [209.85.220.227]) by mx1.freebsd.org (Postfix) with ESMTP id BB3728FC12; Tue, 26 Jan 2010 20:22:03 +0000 (UTC) Received: by fxm27 with SMTP id 27so2386005fxm.3 for ; Tue, 26 Jan 2010 12:22:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=irAjx5QO8AfGqb9QIs0I2X1z7W2b2kTrADuuVdj6i5M=; b=I6GUuskjFAdxd3o4QGSPB6gSrxaDFyKkyL3gvM6XW37WN3a4nc5Uyq9Ygd0s6Lqg8Q QoZXDFoVq1zGGH1zZ4rc6B2W0LWSr+3iiUkzFD1Y78bDxw3NUZl91wNlEpuJZ6ND6QS5 LQ6nw5ck0G4TzNSMwpKzsa7IpdnyIB1qypVW8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=EtVNy0JUFr1r/70Gv9VA/kDGn87ze8DMmOlYweWDT6ghCrx+L4Pqg9rHTpq65KI9BQ EnNzeOCeskCcZU4B0h8szNtVkdWXkF0FQZ//PBTgp+qt1ilDgFRhGapHOHp0TOS0+s3O acjCdJLJBNeCdotgOgmadk+vfQ13PBPYiSJfE= MIME-Version: 1.0 Received: by 10.216.90.81 with SMTP id d59mr372578wef.29.1264537321575; Tue, 26 Jan 2010 12:22:01 -0800 (PST) In-Reply-To: <20100126201258.GK1187@michelle.cdnetworks.com> References: <95D3CB82-BC44-491D-86E4-5CB82F89C0FC@nokia.com> <20100125182257.GG1187@michelle.cdnetworks.com> <147432021001251038r69393ab3m1a797e58f9fa905a@mail.gmail.com> <02307620-ECDC-4E8B-A5B1-FF8491E226C4@nokia.com> <33c6b0bc1001252031k508426bfh25fad65e9223d87@mail.gmail.com> <147432021001260900p60ed1804t97392d2dff5cd244@mail.gmail.com> <147432021001260914x6e5e1b41n4146904ead9d9108@mail.gmail.com> <2a41acea1001260940sf89512ar5514cee9bb08fd9@mail.gmail.com> <2a41acea1001261155v20a54d39qdc5ad7b9ac88291d@mail.gmail.com> <20100126201258.GK1187@michelle.cdnetworks.com> Date: Tue, 26 Jan 2010 12:22:01 -0800 Message-ID: <2a41acea1001261222v2101f3fbgd095a8f9e9b3e759@mail.gmail.com> From: Jack Vogel To: pyunyh@gmail.com Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Nick Rogers , "stable@freebsd.org" , Joshua Boyd , Pyun YongHyeon Subject: Re: em interface slow down on 8.0R X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 26 Jan 2010 20:22:04 -0000 Well, what our testers do is assign BOTH an ipv4 and ipv6 address to an interface, then netperf runs over both, I don't know the internal details but I assume both TCP and UDP are going over ipv6. Prior to your change there is IPv6 handling code in the tx checksum routine, so I assume the hardware offload for that works. With your patch if I disable TXCSUM on the interface then it will work... but before your change it works with that on. So, am I missing something? Cheers, Jack On Tue, Jan 26, 2010 at 12:12 PM, Pyun YongHyeon wrote: > On Tue, Jan 26, 2010 at 11:55:00AM -0800, Jack Vogel wrote: > > I've tried this patch, and it completely breaks IPv6 offloads, which DO > work > > btw, > > our testers have a netperf stress test that does both ipv4 and ipv6, and > > that test > > fails 100% after this change. > > > > I could go hacking at it myself but as its your code Pyun would you like > to > > resolve this issue? > > > > I wonder how you could test IPv6 checksum offloading/TSO as FreeBSD > does not have that capability yet. Do we already have that > capability? I vaguely remember there was an effort to bring the > support in but I don't know current status. If we have the > capability I would have to update all other drivers that can do > IPv6 checksum offloading/TSO for IPv6. > > > Regards, > > > > Jack > > > > > > On Tue, Jan 26, 2010 at 9:40 AM, Jack Vogel wrote: > > > > > No, it hasn't, I need time to look it over and be convinced of what he > was > > > doing. > > > > > > Jack > > > > > > > > > > > > On Tue, Jan 26, 2010 at 9:14 AM, Nick Rogers > wrote: > > > > > >> looks like the patch mentioned in kern/141843 has not been applied to > the > > >> tree? > > >> > > >> On Tue, Jan 26, 2010 at 9:00 AM, Nick Rogers > wrote: > > >> > > >> > Is it advisable to patch 8.0-RELEASE kernel sources with the latest > > >> > (CURRENT) em driver (i.e., src/sys/dev/e1000)? It looks like there > are > > >> some > > >> > updates to the driver since 8.0-RELEASE that may fix some problems? > > >> > > > >> > > > >> _______________________________________________ > > >> 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 Jan 26 20:33:29 2010 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 567031065670; Tue, 26 Jan 2010 20:33:29 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from mail-qy0-f176.google.com (mail-qy0-f176.google.com [209.85.221.176]) by mx1.freebsd.org (Postfix) with ESMTP id E11C18FC17; Tue, 26 Jan 2010 20:33:28 +0000 (UTC) Received: by qyk6 with SMTP id 6so2929702qyk.3 for ; Tue, 26 Jan 2010 12:33:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:received:from:date:to:cc :subject:message-id:reply-to:references:mime-version:content-type :content-disposition:in-reply-to:user-agent; bh=34jAJ4SnTQYwQ+JChWf6ZJSPlwQpR6tNUwaECIjWQJE=; b=cWiX6bOp0/WJGfVZKWETA04YhxgUr11rCA161o+ef+7JHfrUS1uv8wi+FnTyZWRqJX ab8aHDRVU4qPGpi9Oaacl+iQ4bqlq5LJhSCjGAHyVN0v3tZthMg9JtQ6DkHfH6JI7bhW O2ISyESKjCM4onpPY06WKfrDzmj0OnuFr2pVo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:date:to:cc:subject:message-id:reply-to:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; b=oh6XRRL1EAxEQs15ZSjOn7Ih+wdfqG8VRE47VcdnXw+87CYsl7Z7tQX39jpILyT9cG DLt22vw10+VHvtDS67/J1UhkMLHG5HP+oONJISOI2l4IBPWASXaWteH8tclV+RhCwSeR BCxjKrvzVtd8RI798O9Ne+eyq4LvUTZ2bcPog= Received: by 10.224.109.141 with SMTP id j13mr5141893qap.84.1264538008224; Tue, 26 Jan 2010 12:33:28 -0800 (PST) Received: from pyunyh@gmail.com ([174.35.1.224]) by mx.google.com with ESMTPS id 7sm20156028qwb.32.2010.01.26.12.33.24 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 26 Jan 2010 12:33:27 -0800 (PST) Received: by pyunyh@gmail.com (sSMTP sendmail emulation); Tue, 26 Jan 2010 12:33:22 -0800 From: Pyun YongHyeon Date: Tue, 26 Jan 2010 12:33:22 -0800 To: Jack Vogel Message-ID: <20100126203322.GL1187@michelle.cdnetworks.com> References: <20100125182257.GG1187@michelle.cdnetworks.com> <147432021001251038r69393ab3m1a797e58f9fa905a@mail.gmail.com> <02307620-ECDC-4E8B-A5B1-FF8491E226C4@nokia.com> <33c6b0bc1001252031k508426bfh25fad65e9223d87@mail.gmail.com> <147432021001260900p60ed1804t97392d2dff5cd244@mail.gmail.com> <147432021001260914x6e5e1b41n4146904ead9d9108@mail.gmail.com> <2a41acea1001260940sf89512ar5514cee9bb08fd9@mail.gmail.com> <2a41acea1001261155v20a54d39qdc5ad7b9ac88291d@mail.gmail.com> <20100126201258.GK1187@michelle.cdnetworks.com> <2a41acea1001261222v2101f3fbgd095a8f9e9b3e759@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <2a41acea1001261222v2101f3fbgd095a8f9e9b3e759@mail.gmail.com> User-Agent: Mutt/1.4.2.3i Cc: Nick Rogers , "stable@freebsd.org" , Joshua Boyd , Pyun YongHyeon Subject: Re: em interface slow down on 8.0R X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: pyunyh@gmail.com List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jan 2010 20:33:29 -0000 On Tue, Jan 26, 2010 at 12:22:01PM -0800, Jack Vogel wrote: > Well, what our testers do is assign BOTH an ipv4 and ipv6 address to an > interface, > then netperf runs over both, I don't know the internal details but I assume > both TCP > and UDP are going over ipv6. > > Prior to your change there is IPv6 handling code in the tx checksum > routine, so I > assume the hardware offload for that works. With your patch if I disable > TXCSUM > on the interface then it will work... but before your change it works with > that on. > > So, am I missing something? > Hmm, then I guess there is bug in the patch. Apparently upper stack already computed checksum for IPv6 so the patch should not try to offload IPv6 traffic again. I'll see the patch again. Thanks for valuable input. :-) > Cheers, > > Jack > > > On Tue, Jan 26, 2010 at 12:12 PM, Pyun YongHyeon wrote: > > > On Tue, Jan 26, 2010 at 11:55:00AM -0800, Jack Vogel wrote: > > > I've tried this patch, and it completely breaks IPv6 offloads, which DO > > work > > > btw, > > > our testers have a netperf stress test that does both ipv4 and ipv6, and > > > that test > > > fails 100% after this change. > > > > > > I could go hacking at it myself but as its your code Pyun would you like > > to > > > resolve this issue? > > > > > > > I wonder how you could test IPv6 checksum offloading/TSO as FreeBSD > > does not have that capability yet. Do we already have that > > capability? I vaguely remember there was an effort to bring the > > support in but I don't know current status. If we have the > > capability I would have to update all other drivers that can do > > IPv6 checksum offloading/TSO for IPv6. > > > > > Regards, > > > > > > Jack > > > > > > > > > On Tue, Jan 26, 2010 at 9:40 AM, Jack Vogel wrote: > > > > > > > No, it hasn't, I need time to look it over and be convinced of what he > > was > > > > doing. > > > > > > > > Jack > > > > > > > > > > > > > > > > On Tue, Jan 26, 2010 at 9:14 AM, Nick Rogers > > wrote: > > > > > > > >> looks like the patch mentioned in kern/141843 has not been applied to > > the > > > >> tree? > > > >> > > > >> On Tue, Jan 26, 2010 at 9:00 AM, Nick Rogers > > wrote: > > > >> > > > >> > Is it advisable to patch 8.0-RELEASE kernel sources with the latest > > > >> > (CURRENT) em driver (i.e., src/sys/dev/e1000)? It looks like there > > are > > > >> some > > > >> > updates to the driver since 8.0-RELEASE that may fix some problems? > > > >> > > > > >> > > > > >> _______________________________________________ > > > >> 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 Jan 26 20:36:24 2010 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A2C72106566B; Tue, 26 Jan 2010 20:36:24 +0000 (UTC) (envelope-from jfvogel@gmail.com) Received: from ey-out-2122.google.com (ey-out-2122.google.com [74.125.78.25]) by mx1.freebsd.org (Postfix) with ESMTP id 089A08FC0C; Tue, 26 Jan 2010 20:36:23 +0000 (UTC) Received: by ey-out-2122.google.com with SMTP id 9so1269870eyd.9 for ; Tue, 26 Jan 2010 12:36:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=mPcEzT82vh84lMN50ghFkmFeOXRxyo4+eCT/MQtisro=; b=M0WkYHbEE+mNBEGVKJdOib7mvkb5p+nwZ0q9f55dxadgL7DtUItHlY45+0OyjK4Kpg gmGOws8Yf4QeWfNrxeN58zofo2/hvFygbEV3qeri3rpqvhvpvUgSCTOgg8gPsMFp2b1I d/jR0WeaEDn0Gj235DR/kE1rArKyp0RCtnHIs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=YNGifYD+cbK8QcAoPpCoxpGZUFV6pzQ0OtJ2rlzJmMUhJ1qWuGPVaitXiRNlhwcP9q Ip95hwyUWCtzRtT1IxEIy4yjmR+m47GbRpQA+70dcRa2t9DFjF0ZJ+9X+wyiYj1L2VSz 4nsD1/TxPuCbjA8ZRlhTs2GNMTHlp/ZNCSg20= MIME-Version: 1.0 Received: by 10.216.169.201 with SMTP id n51mr316860wel.209.1264538182158; Tue, 26 Jan 2010 12:36:22 -0800 (PST) In-Reply-To: <20100126203322.GL1187@michelle.cdnetworks.com> References: <20100125182257.GG1187@michelle.cdnetworks.com> <02307620-ECDC-4E8B-A5B1-FF8491E226C4@nokia.com> <33c6b0bc1001252031k508426bfh25fad65e9223d87@mail.gmail.com> <147432021001260900p60ed1804t97392d2dff5cd244@mail.gmail.com> <147432021001260914x6e5e1b41n4146904ead9d9108@mail.gmail.com> <2a41acea1001260940sf89512ar5514cee9bb08fd9@mail.gmail.com> <2a41acea1001261155v20a54d39qdc5ad7b9ac88291d@mail.gmail.com> <20100126201258.GK1187@michelle.cdnetworks.com> <2a41acea1001261222v2101f3fbgd095a8f9e9b3e759@mail.gmail.com> <20100126203322.GL1187@michelle.cdnetworks.com> Date: Tue, 26 Jan 2010 12:36:22 -0800 Message-ID: <2a41acea1001261236h2846787ft756433653e273ecc@mail.gmail.com> From: Jack Vogel To: pyunyh@gmail.com Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Nick Rogers , "stable@freebsd.org" , Joshua Boyd , Pyun YongHyeon Subject: Re: em interface slow down on 8.0R X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 26 Jan 2010 20:36:24 -0000 Great, if you can get the changes to me quickly I'd like to incorporate them. BTW, I have merged your igb changes into my code and its very stable, should see that checked in for 7.3 shortly. Thanks for your hard work Pyun! Jack On Tue, Jan 26, 2010 at 12:33 PM, Pyun YongHyeon wrote: > On Tue, Jan 26, 2010 at 12:22:01PM -0800, Jack Vogel wrote: > > Well, what our testers do is assign BOTH an ipv4 and ipv6 address to an > > interface, > > then netperf runs over both, I don't know the internal details but I > assume > > both TCP > > and UDP are going over ipv6. > > > > Prior to your change there is IPv6 handling code in the tx checksum > > routine, so I > > assume the hardware offload for that works. With your patch if I disable > > TXCSUM > > on the interface then it will work... but before your change it works > with > > that on. > > > > So, am I missing something? > > > > Hmm, then I guess there is bug in the patch. Apparently upper stack > already computed checksum for IPv6 so the patch should not try to > offload IPv6 traffic again. I'll see the patch again. > Thanks for valuable input. :-) > > > Cheers, > > > > Jack > > > > > > On Tue, Jan 26, 2010 at 12:12 PM, Pyun YongHyeon > wrote: > > > > > On Tue, Jan 26, 2010 at 11:55:00AM -0800, Jack Vogel wrote: > > > > I've tried this patch, and it completely breaks IPv6 offloads, which > DO > > > work > > > > btw, > > > > our testers have a netperf stress test that does both ipv4 and ipv6, > and > > > > that test > > > > fails 100% after this change. > > > > > > > > I could go hacking at it myself but as its your code Pyun would you > like > > > to > > > > resolve this issue? > > > > > > > > > > I wonder how you could test IPv6 checksum offloading/TSO as FreeBSD > > > does not have that capability yet. Do we already have that > > > capability? I vaguely remember there was an effort to bring the > > > support in but I don't know current status. If we have the > > > capability I would have to update all other drivers that can do > > > IPv6 checksum offloading/TSO for IPv6. > > > > > > > Regards, > > > > > > > > Jack > > > > > > > > > > > > On Tue, Jan 26, 2010 at 9:40 AM, Jack Vogel > wrote: > > > > > > > > > No, it hasn't, I need time to look it over and be convinced of what > he > > > was > > > > > doing. > > > > > > > > > > Jack > > > > > > > > > > > > > > > > > > > > On Tue, Jan 26, 2010 at 9:14 AM, Nick Rogers > > > wrote: > > > > > > > > > >> looks like the patch mentioned in kern/141843 has not been applied > to > > > the > > > > >> tree? > > > > >> > > > > >> On Tue, Jan 26, 2010 at 9:00 AM, Nick Rogers > > > wrote: > > > > >> > > > > >> > Is it advisable to patch 8.0-RELEASE kernel sources with the > latest > > > > >> > (CURRENT) em driver (i.e., src/sys/dev/e1000)? It looks like > there > > > are > > > > >> some > > > > >> > updates to the driver since 8.0-RELEASE that may fix some > problems? > > > > >> > > > > > >> > > > > > >> _______________________________________________ > > > > >> 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 Jan 26 23:15:18 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2360B106566B for ; Tue, 26 Jan 2010 23:15:18 +0000 (UTC) (envelope-from dan.naumov@gmail.com) Received: from mail-yx0-f171.google.com (mail-yx0-f171.google.com [209.85.210.171]) by mx1.freebsd.org (Postfix) with ESMTP id D8A5B8FC0A for ; Tue, 26 Jan 2010 23:15:17 +0000 (UTC) Received: by yxe1 with SMTP id 1so4208751yxe.3 for ; Tue, 26 Jan 2010 15:15:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:content-type; bh=MXHLCZb2JI2MvNgDbZ4PcBwVJF/yvuysgOkP4q3wLFY=; b=Zwpb8IPshBJbA77iXZyO/IUuqkniEGqI4OuW5Hvqf0FrZxWRli6Fcd9IG8ITxL1RUb nYicFx9RVG2uIl2A6Tf+PByCScWo6skR3tESEmdGiQ1D/JcZqKcGJ9dmFsuuOz3J3pqN ILRUOEFM6ARCP1dKWvk59kAsdpehScHHVDuwM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=MWURamdE9qtJP07B2gf5f+PPDOeAl9YfYgacLGkBwNLgxADjz/O/uMksDuebOLaxPM Abuhbr7vAzo3a761FfeL+0jq2HiPGrT+eTfEtg8OB+uuXs1Lz3NHP66BYe3FCr+F7s7I 9cvRWhJB/f5UkGQquba/9DZY0QWpUd61dbuhU= MIME-Version: 1.0 Received: by 10.101.53.7 with SMTP id f7mr10895360ank.136.1264547717130; Tue, 26 Jan 2010 15:15:17 -0800 (PST) Date: Wed, 27 Jan 2010 01:15:17 +0200 Message-ID: From: Dan Naumov To: FreeBSD-STABLE Mailing List Content-Type: text/plain; charset=ISO-8859-1 Subject: RE: immense delayed write to file system (ZFS and UFS2), performance issues X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jan 2010 23:15:18 -0000 Can anyone confirm that using the WDIDLE3 utility on the 2TB WD20EADS discs will not cause any issues if these disks are part of a ZFS mirror pool? I do have backups of data, but I would rather not spend the time rebuilding the entire system and restoring enormous amounts of data over a 100mbit network unless I absolutely have to :) - Sincerely, Dan Naumov From owner-freebsd-stable@FreeBSD.ORG Tue Jan 26 23:55:01 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 90427106566B for ; Tue, 26 Jan 2010 23:55:01 +0000 (UTC) (envelope-from aw1@swelter.hanley.stade.co.uk) Received: from v-smtp-auth-relay-6.gradwell.net (v-smtp-auth-relay-6.gradwell.net [79.135.125.112]) by mx1.freebsd.org (Postfix) with ESMTP id F16B48FC0A for ; Tue, 26 Jan 2010 23:55:00 +0000 (UTC) Received: from 93-97-22-18.zone5.bethere.co.uk ([93.97.22.18] helo=swelter.hanley.stade.co.uk country=GB ident=postmaster&pop3&stade^co*uk) by v-smtp-auth-relay-6.gradwell.net with esmtpa (Gradwell gwh-smtpd 1.290) id 4b5f80d3.548f.91 for freebsd-stable@freebsd.org; Tue, 26 Jan 2010 23:54:59 +0000 (envelope-sender ) Received: from swelter.hanley.stade.co.uk (localhost [127.0.0.1]) by swelter.hanley.stade.co.uk (8.14.3/8.14.3) with ESMTP id o0QNsxGD012958 for ; Tue, 26 Jan 2010 23:54:59 GMT (envelope-from aw1@swelter.hanley.stade.co.uk) Received: (from aw1@localhost) by swelter.hanley.stade.co.uk (8.14.3/8.14.3/Submit) id o0QNsx6W012957 for freebsd-stable@freebsd.org; Tue, 26 Jan 2010 23:54:59 GMT (envelope-from aw1) Date: Tue, 26 Jan 2010 23:54:59 +0000 From: Adrian Wontroba To: freebsd-stable@freebsd.org Message-ID: <20100126235458.GA12634@swelter.hanley.stade.co.uk> Mail-Followup-To: Adrian Wontroba , freebsd-stable@freebsd.org References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i X-Operating-System: FreeBSD 8.0-STABLE Organization: Oh dear, I've joined one again. X-Virus-Scanned: clamav-milter 0.95.3 at swelter.hanley.stade.co.uk X-Virus-Status: Clean Subject: Re: immense delayed write to file system (ZFS and UFS2), performance issues X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: aw1@stade.co.uk List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jan 2010 23:55:01 -0000 On Wed, Jan 27, 2010 at 01:15:17AM +0200, Dan Naumov wrote: > Can anyone confirm that using the WDIDLE3 utility on the 2TB WD20EADS > discs will not cause any issues if these disks are part of a ZFS > mirror pool? I do have backups of data, but I would rather not spend > the time rebuilding the entire system and restoring enormous amounts > of data over a 100mbit network unless I absolutely have to :) How about using the "write every 5 seconds" python script posted earlier in this thread by erik@tefre.com? Works nicely for me and stops the load cycle count increase. Thank you Erik! To save searching, here is Erik's script as used here. #!/usr/local/bin/python # Author: Erik Stian Tefre #Keeping this python script running prevents Load_Cycle_Count from #incrementing on my WD15EADS drives by forcing a write every 5 seconds (2 #drive zfs mirror pool, average of 2 load cycles per minute when the #script is not running): import time,os mypool = "/tank" # ^^ Change to your pool! fname = os.path.join(mypool, "wd_green_anti_idle.pyfile") c = 0 f = open(fname, "w") while True: if c == 100: f.close() f = open(fname, "w") c = 0 c += 1 time.sleep(5) f.write("a") f.flush() os.fsync(f.fileno()) You might find this handy too: #!/bin/sh # $FreeBSD:$ # PROVIDE: wd_green_anti_idle # REQUIRE: LOGIN . /etc/rc.subr wd_green_anti_idle_enable="${wd_green_anti_idle_enable-NO}" name=wd_green_anti_idle rcvar=`set_rcvar` command="/usr/local/stade/bin/wd_green_anti_idle.py" start_cmd="wd_green_anti_idle_start" wd_green_anti_idle_start() { if ! checkyesno wd_green_anti_idle_enable ; then return 0 fi echo "Starting ${name}." ${command} & } load_rc_config $name run_rc_command $* Adjust command name to suit, put in /usr/local/etc/rc.d, add wd_green_anti_idle_enable="YES" to /etc/rc.conf and the script starts running during startup. A minor bug - it doesn't close down. -- Adrian Wontroba A witty saying proves nothing, but saying something pointless gets people's attention. From owner-freebsd-stable@FreeBSD.ORG Wed Jan 27 00:31:55 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 45BE21065692 for ; Wed, 27 Jan 2010 00:31:55 +0000 (UTC) (envelope-from dgerow@afflictions.org) Received: from out2.smtp.messagingengine.com (out2.smtp.messagingengine.com [66.111.4.26]) by mx1.freebsd.org (Postfix) with ESMTP id 14C198FC14 for ; Wed, 27 Jan 2010 00:31:54 +0000 (UTC) Received: from compute1.internal (compute1.internal [10.202.2.41]) by gateway1.messagingengine.com (Postfix) with ESMTP id F1FEDCE57B for ; Tue, 26 Jan 2010 19:12:57 -0500 (EST) Received: from heartbeat1.messagingengine.com ([10.202.2.160]) by compute1.internal (MEProxy); Tue, 26 Jan 2010 19:12:58 -0500 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=messagingengine.com; h=date:from:to:subject:message-id:references:mime-version:content-type:in-reply-to; s=smtpout; bh=8tzZ8NoKxi8ckXrOZu7nqUL5vgU=; b=EfC6yvC5ebWw0EYxhfOi8U4jWFo82ha6FRZZLCE6SOyX/r6cU1UlFsvqA+gHPb2tcwXZJ4LYAQm+e+jo6sKysdF2t1jt9Pwhx4WFSLgBEihImn6NfmjuZk9xnRRvHf9+9lXnEQla0h5nav306lFXN/FTR9JmVFtVYoR87kUShWA= X-Sasl-enc: pA39PXUy6ut6ztIZ0JstT4jXHFxraeEIhWVLjS70JFiz 1264551177 Received: from plebeian.afflictions.org (CPE000db917e8b9-CM0019475d4056.cpe.net.cable.rogers.com [174.115.162.77]) by mail.messagingengine.com (Postfix) with ESMTPSA id B9C0E49A915 for ; Tue, 26 Jan 2010 19:12:57 -0500 (EST) Received: by plebeian.afflictions.org (Postfix, from userid 1001) id 7348BD2; Tue, 26 Jan 2010 19:12:01 -0500 (EST) Date: Tue, 26 Jan 2010 19:12:01 -0500 From: Damian Gerow To: freebsd-stable@freebsd.org Message-ID: <20100127001201.GE9206@plebeian.afflictions.org> References: <20100126235458.GA12634@swelter.hanley.stade.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20100126235458.GA12634@swelter.hanley.stade.co.uk> User-Agent: Mutt/1.5.20 (2009-06-14) Subject: Re: immense delayed write to file system (ZFS and UFS2), performance issues X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jan 2010 00:31:55 -0000 Adrian Wontroba wrote: : How about using the "write every 5 seconds" python script posted earlier : in this thread by erik@tefre.com? Works nicely for me and stops the load : cycle count increase. I have a WD2003FYPS sitting in a system, to be used for testing. Bought it just before this thread started, and here's what it looks like right now: 9 Power_On_Hours 0x0032 100 100 000 Old_age Always - 508 193 Load_Cycle_Count 0x0032 200 200 000 Old_age Always - 2710 This drive is sitting, unused, with no filesystem, and I've performed approximately zero writes to the disk. Having a script kick off and write to a disk will help so long as that disk is writable; if it's being used as a hot spare in a raidz array, it's not going to help much. From owner-freebsd-stable@FreeBSD.ORG Wed Jan 27 00:39:46 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A38BE106566B for ; Wed, 27 Jan 2010 00:39:46 +0000 (UTC) (envelope-from dan.naumov@gmail.com) Received: from mail-gx0-f218.google.com (mail-gx0-f218.google.com [209.85.217.218]) by mx1.freebsd.org (Postfix) with ESMTP id 657C68FC08 for ; Wed, 27 Jan 2010 00:39:46 +0000 (UTC) Received: by gxk10 with SMTP id 10so4419359gxk.3 for ; Tue, 26 Jan 2010 16:39:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:content-type; bh=5r61WMGqDhT56d2ClTl0dMai6bSf77OzGmg1mw2GHRw=; b=fgiuZXYT/UTkQ1u3UM+2S2s36phgf+lrtZFn4UcV3eA1ScnBGCKFmKuTY0P9cR/g+N jVXdvZ2jGT0hj4x7RlfpoqUwaB+neIec3ZYLCe8L8vSSuDuGnx4+CJfPyBMkL65LaWmS UvvMhMe6yszXv0J1S0+4Y2wez46bV+jUmXdXI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=j76q0KXeEtCZuWPFMPxZcEbTJxfkxKg2+jTQyoygJOvLOKLy6bgPqn+XT0VahNnONl mPkiDCqStDheewrEslo4TsLkykPRx/st+4sqZKJAG2l/cRPWgDeoQBhg4J/zjWv11vsm L9043bYgrIYV1uqqXTre7OAr1gXKJ2MImHKfs= MIME-Version: 1.0 Received: by 10.101.145.27 with SMTP id x27mr11078896ann.77.1264552785628; Tue, 26 Jan 2010 16:39:45 -0800 (PST) Date: Wed, 27 Jan 2010 02:39:45 +0200 Message-ID: From: Dan Naumov To: FreeBSD-STABLE Mailing List , aw1@stade.co.uk, erik@tefre.com Content-Type: text/plain; charset=ISO-8859-1 Cc: Subject: RE: immense delayed write to file system (ZFS and UFS2), performance issues X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jan 2010 00:39:46 -0000 Thank you, thank you, thank you! Now I neither have to worry about premature death of my disks, nor do I have to endure the loud clicking noises (I have a NAS with these in my living room)! If either of you (or both) want me to Paypal you money for a beer, send me details offlist :) - Sincerely, Dan Naumov From owner-freebsd-stable@FreeBSD.ORG Wed Jan 27 00:45:28 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B5E06106566C for ; Wed, 27 Jan 2010 00:45:28 +0000 (UTC) (envelope-from dan.naumov@gmail.com) Received: from mail-yw0-f197.google.com (mail-yw0-f197.google.com [209.85.211.197]) by mx1.freebsd.org (Postfix) with ESMTP id 68C348FC08 for ; Wed, 27 Jan 2010 00:45:28 +0000 (UTC) Received: by ywh35 with SMTP id 35so4162224ywh.7 for ; Tue, 26 Jan 2010 16:45:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:content-type; bh=cvDMmLkPGPPhG9SsfnZs95mQBCtkL2NbRgAxARYxTQQ=; b=iNMxSPeErZIsBmIehfIh06LwA2x1KjiN6QSUsqtOW2RruPtAWZ9X0zZlP8rxdvdFRZ Ne2A1BDHKgXKbgUl/s57mnXVq4onsNv8Sg0g9t67dLxmrEYbAaH/L8xkUjfswq73iM3V p8RQNlw+DnFk6Cxw7JpYgBmHKM9pZdn9O8oKE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=SVqMGCiIwsjGRqU1DvVuA/SebQJII0xYnUP4RkLu95gZZvmL1HMPN5RAHyZcoGcMEU 28SPKH/PhOEN4Rw53iseBzN2AEcvyHDaKedLXpTOYJkOHOy7J+ICzUb8rlSXgin8BQYx hw29+1NKNiXgeV0l7asYBQCY9xmx7VfMdpg9M= MIME-Version: 1.0 Received: by 10.101.2.13 with SMTP id e13mr9605383ani.195.1264553127674; Tue, 26 Jan 2010 16:45:27 -0800 (PST) Date: Wed, 27 Jan 2010 02:45:27 +0200 Message-ID: From: Dan Naumov To: FreeBSD-STABLE Mailing List , dgerow@afflictions.org Content-Type: text/plain; charset=ISO-8859-1 Cc: Subject: RE: immense delayed write to file system (ZFS and UFS2), performance issues X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jan 2010 00:45:28 -0000 >I have a WD2003FYPS sitting in a system, to be used for testing. Bought it >just before this thread started, and here's what it looks like right now: > > 9 Power_On_Hours 0x0032 100 100 000 Old_age Always - 508 >193 Load_Cycle_Count 0x0032 200 200 000 Old_age Always - 2710 > >This drive is sitting, unused, with no filesystem, and I've performed >approximately zero writes to the disk. > >Having a script kick off and write to a disk will help so long as that >disk is writable; if it's being used as a hot spare in a raidz array, it's >not going to help much. I wouldn't worry in your particular case. A value of 2710 in 508 hours is a rate of 5,33/hour. At this rate, it's going to take you 56285 hours or 2345 days to reach 300,000 and most disks will likely function past 400,000 (over 600,000 all bets are off though). The people who need(ed) to worry were people like me, who were seeing the rate increase at a rate of 43+ per hour. - Sincerely, Dan Naumov From owner-freebsd-stable@FreeBSD.ORG Wed Jan 27 00:46:50 2010 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 418AE10656A7; Wed, 27 Jan 2010 00:46:50 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from mail-qy0-f176.google.com (mail-qy0-f176.google.com [209.85.221.176]) by mx1.freebsd.org (Postfix) with ESMTP id CA6358FC0A; Wed, 27 Jan 2010 00:46:49 +0000 (UTC) Received: by qyk6 with SMTP id 6so3030767qyk.3 for ; Tue, 26 Jan 2010 16:46:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:received:from:date:to:cc :subject:message-id:reply-to:references:mime-version:content-type :content-disposition:in-reply-to:user-agent; bh=lFviJj3nDfJCV8ToIiB4VZkeWpH7fIevL0SH1QJ9RxY=; b=mJ/A7DsSyJFu7XJWr3sKXaEHNo9b6MKBDS8sZcfIENTzTmdwmU1Oyh+1I6q8UGnQfk bxTqz8xUgHL1dmpmN9oa75W1dABOqSKU6zKL+2it3xCXEggw4t6xB7MMpMuxATgHZ8Uc hr2sUHiwbrnepFG/0Mm2DQcNa9kPJxCkgKQy0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:date:to:cc:subject:message-id:reply-to:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; b=opjHrSW1drYanDa7aX7NQ9QzRfDU96nUnRFYTGQJl48I5VhCM+OwK6jUldzWayk6vz Bx/OLaSus9QySOgRjvqhHZp2+Lq+IXP1FegN1u1+sLwS/iogW3CDgf0wv0mfC0T5q3q3 9lV7FLihlQZ9cGrllyDSCTvR/Wu6Glnh0J1RY= Received: by 10.224.12.197 with SMTP id y5mr4352718qay.338.1264553208712; Tue, 26 Jan 2010 16:46:48 -0800 (PST) Received: from pyunyh@gmail.com ([174.35.1.224]) by mx.google.com with ESMTPS id 4sm240142qwe.45.2010.01.26.16.46.46 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 26 Jan 2010 16:46:47 -0800 (PST) Received: by pyunyh@gmail.com (sSMTP sendmail emulation); Tue, 26 Jan 2010 16:46:46 -0800 From: Pyun YongHyeon Date: Tue, 26 Jan 2010 16:46:46 -0800 To: Jack Vogel Message-ID: <20100127004646.GM1187@michelle.cdnetworks.com> References: <02307620-ECDC-4E8B-A5B1-FF8491E226C4@nokia.com> <33c6b0bc1001252031k508426bfh25fad65e9223d87@mail.gmail.com> <147432021001260900p60ed1804t97392d2dff5cd244@mail.gmail.com> <147432021001260914x6e5e1b41n4146904ead9d9108@mail.gmail.com> <2a41acea1001260940sf89512ar5514cee9bb08fd9@mail.gmail.com> <2a41acea1001261155v20a54d39qdc5ad7b9ac88291d@mail.gmail.com> <20100126201258.GK1187@michelle.cdnetworks.com> <2a41acea1001261222v2101f3fbgd095a8f9e9b3e759@mail.gmail.com> <20100126203322.GL1187@michelle.cdnetworks.com> <2a41acea1001261236h2846787ft756433653e273ecc@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <2a41acea1001261236h2846787ft756433653e273ecc@mail.gmail.com> User-Agent: Mutt/1.4.2.3i Cc: Nick Rogers , "stable@freebsd.org" , Joshua Boyd , Pyun YongHyeon Subject: Re: em interface slow down on 8.0R X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: pyunyh@gmail.com List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jan 2010 00:46:50 -0000 On Tue, Jan 26, 2010 at 12:36:22PM -0800, Jack Vogel wrote: > Great, if you can get the changes to me quickly I'd like to incorporate > them. > Unfortunately I couldn't reproduce it on my box. I've tested both IPv4 and IPv6 at the same time with netperf and it worked as expected. Reading the code also indicates the patch wouldn't break IPv6 traffic as CSUM_OFFLOAD is not set by upper stack. Are you using any special configurations for testing? > BTW, I have merged your igb changes into my code and its very stable, should > see that checked in for 7.3 shortly. > That's great! Thank you. > Thanks for your hard work Pyun! > No problem. > Jack > > > On Tue, Jan 26, 2010 at 12:33 PM, Pyun YongHyeon wrote: > > > On Tue, Jan 26, 2010 at 12:22:01PM -0800, Jack Vogel wrote: > > > Well, what our testers do is assign BOTH an ipv4 and ipv6 address to an > > > interface, > > > then netperf runs over both, I don't know the internal details but I > > assume > > > both TCP > > > and UDP are going over ipv6. > > > > > > Prior to your change there is IPv6 handling code in the tx checksum > > > routine, so I > > > assume the hardware offload for that works. With your patch if I disable > > > TXCSUM > > > on the interface then it will work... but before your change it works > > with > > > that on. > > > > > > So, am I missing something? > > > > > > > Hmm, then I guess there is bug in the patch. Apparently upper stack > > already computed checksum for IPv6 so the patch should not try to > > offload IPv6 traffic again. I'll see the patch again. > > Thanks for valuable input. :-) > > > > > Cheers, > > > > > > Jack > > > > > > > > > On Tue, Jan 26, 2010 at 12:12 PM, Pyun YongHyeon > > wrote: > > > > > > > On Tue, Jan 26, 2010 at 11:55:00AM -0800, Jack Vogel wrote: > > > > > I've tried this patch, and it completely breaks IPv6 offloads, which > > DO > > > > work > > > > > btw, > > > > > our testers have a netperf stress test that does both ipv4 and ipv6, > > and > > > > > that test > > > > > fails 100% after this change. > > > > > > > > > > I could go hacking at it myself but as its your code Pyun would you > > like > > > > to > > > > > resolve this issue? > > > > > > > > > > > > > I wonder how you could test IPv6 checksum offloading/TSO as FreeBSD > > > > does not have that capability yet. Do we already have that > > > > capability? I vaguely remember there was an effort to bring the > > > > support in but I don't know current status. If we have the > > > > capability I would have to update all other drivers that can do > > > > IPv6 checksum offloading/TSO for IPv6. > > > > > > > > > Regards, > > > > > > > > > > Jack > > > > > > > > > > > > > > > On Tue, Jan 26, 2010 at 9:40 AM, Jack Vogel > > wrote: > > > > > > > > > > > No, it hasn't, I need time to look it over and be convinced of what > > he > > > > was > > > > > > doing. > > > > > > > > > > > > Jack > > > > > > > > > > > > > > > > > > > > > > > > On Tue, Jan 26, 2010 at 9:14 AM, Nick Rogers > > > > wrote: > > > > > > > > > > > >> looks like the patch mentioned in kern/141843 has not been applied > > to > > > > the > > > > > >> tree? > > > > > >> > > > > > >> On Tue, Jan 26, 2010 at 9:00 AM, Nick Rogers > > > > wrote: > > > > > >> > > > > > >> > Is it advisable to patch 8.0-RELEASE kernel sources with the > > latest > > > > > >> > (CURRENT) em driver (i.e., src/sys/dev/e1000)? It looks like > > there > > > > are > > > > > >> some > > > > > >> > updates to the driver since 8.0-RELEASE that may fix some > > problems? > > > > > >> > > > > > > >> > > > > > > >> _______________________________________________ > > > > > >> freebsd-stable@freebsd.org mailing list > > > > > >> http://lists.freebsd.org/mailman/listinfo/freebsd-stable > > > > > >> To unsubscribe, send any mail to " > > > > freebsd-stable-unsubscribe@freebsd.org" > > > > > >> > > > > > > > > > > > > > > > > > > From owner-freebsd-stable@FreeBSD.ORG Wed Jan 27 00:50:02 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 61CB3106566B for ; Wed, 27 Jan 2010 00:50:02 +0000 (UTC) (envelope-from dgerow@afflictions.org) Received: from out2.smtp.messagingengine.com (out2.smtp.messagingengine.com [66.111.4.26]) by mx1.freebsd.org (Postfix) with ESMTP id 313948FC17 for ; Wed, 27 Jan 2010 00:50:01 +0000 (UTC) Received: from compute1.internal (compute1.internal [10.202.2.41]) by gateway1.messagingengine.com (Postfix) with ESMTP id 9DB73CE602; Tue, 26 Jan 2010 19:50:01 -0500 (EST) Received: from heartbeat2.messagingengine.com ([10.202.2.161]) by compute1.internal (MEProxy); Tue, 26 Jan 2010 19:50:01 -0500 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=messagingengine.com; h=date:from:to:cc:subject:message-id:references:mime-version:content-type:in-reply-to; s=smtpout; bh=hicX2x0RN8eSC18HD7X88kiH79c=; b=Pgu562btMBvHSXbbnT0GuzS7xcROQgD7XGzgW2IRJTfOUAw/VzaSaGbMAjKABmyf4z0WWL7tFIHFotBDJ+g+sYx4nMt/bi9EY29M7Nea/UUVfwkAj7LpmOADRTkWIvu7F5Go4XCqHh6UeMsy6nxEvNluIAIfjNY8/1xbukY32Hg= X-Sasl-enc: Q746YXBne0movj9Hd4pZW/11AuwklRVomkyocIRKhTQ2 1264553401 Received: from plebeian.afflictions.org (CPE000db917e8b9-CM0019475d4056.cpe.net.cable.rogers.com [174.115.162.77]) by mail.messagingengine.com (Postfix) with ESMTPSA id 69FBEB9B6; Tue, 26 Jan 2010 19:50:01 -0500 (EST) Received: by plebeian.afflictions.org (Postfix, from userid 1001) id 87F68D6; Tue, 26 Jan 2010 19:49:05 -0500 (EST) Date: Tue, 26 Jan 2010 19:49:05 -0500 From: Damian Gerow To: Dan Naumov Message-ID: <20100127004905.GF9206@plebeian.afflictions.org> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) Cc: FreeBSD-STABLE Mailing List Subject: Re: immense delayed write to file system (ZFS and UFS2), performance issues X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jan 2010 00:50:02 -0000 Dan Naumov wrote: : >This drive is sitting, unused, with no filesystem, and I've performed : >approximately zero writes to the disk. : > : >Having a script kick off and write to a disk will help so long as that : >disk is writable; if it's being used as a hot spare in a raidz array, it's : >not going to help much. : : I wouldn't worry in your particular case. A value of 2710 in 508 hours : is a rate of 5,33/hour. At this rate, it's going to take you 56285 : hours or 2345 days to reach 300,000 and most disks will likely : function past 400,000 (over 600,000 all bets are off though). The : people who need(ed) to worry were people like me, who were seeing the : rate increase at a rate of 43+ per hour. Which is why I haven't spoken up on the thread -- I'm not terribly worried. Specific cases aside, writing to the FS is a workaround to a rather inconvenient issue. I, too, would like to see if the problem is fixed, not avoided, by using wdidle -- but I suspect I'll have to contact WD myself to get that confirmation. From owner-freebsd-stable@FreeBSD.ORG Wed Jan 27 02:38:09 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 63634106566B for ; Wed, 27 Jan 2010 02:38:09 +0000 (UTC) (envelope-from aw1@swelter.hanley.stade.co.uk) Received: from v-smtp-auth-relay-3.gradwell.net (v-smtp-auth-relay-3.gradwell.net [79.135.125.42]) by mx1.freebsd.org (Postfix) with ESMTP id C24C38FC15 for ; Wed, 27 Jan 2010 02:38:07 +0000 (UTC) Received: from 93-97-22-18.zone5.bethere.co.uk ([93.97.22.18] helo=swelter.hanley.stade.co.uk country=GB ident=postmaster$pop3*stade#co^uk) by v-smtp-auth-relay-3.gradwell.net with esmtpa (Gradwell gwh-smtpd 1.290) id 4b5fa70e.26ef.14 for freebsd-stable@freebsd.org; Wed, 27 Jan 2010 02:38:06 +0000 (envelope-sender ) Received: from swelter.hanley.stade.co.uk (localhost [127.0.0.1]) by swelter.hanley.stade.co.uk (8.14.3/8.14.3) with ESMTP id o0R2c5rO015018 for ; Wed, 27 Jan 2010 02:38:05 GMT (envelope-from aw1@swelter.hanley.stade.co.uk) Received: (from aw1@localhost) by swelter.hanley.stade.co.uk (8.14.3/8.14.3/Submit) id o0R2c59c015017 for freebsd-stable@freebsd.org; Wed, 27 Jan 2010 02:38:05 GMT (envelope-from aw1) Date: Wed, 27 Jan 2010 02:38:05 +0000 From: Adrian Wontroba To: FreeBSD-STABLE Mailing List Message-ID: <20100127023805.GB13665@swelter.hanley.stade.co.uk> Mail-Followup-To: Adrian Wontroba , FreeBSD-STABLE Mailing List References: <20100127004905.GF9206@plebeian.afflictions.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20100127004905.GF9206@plebeian.afflictions.org> User-Agent: Mutt/1.4.2.3i X-Operating-System: FreeBSD 8.0-STABLE Organization: Oh dear, I've joined one again. X-Virus-Scanned: clamav-milter 0.95.3 at swelter.hanley.stade.co.uk X-Virus-Status: Clean Subject: Re: immense delayed write to file system (ZFS and UFS2), performance issues X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: aw1@stade.co.uk List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jan 2010 02:38:09 -0000 On Tue, Jan 26, 2010 at 07:49:05PM -0500, Damian Gerow wrote: > Specific cases aside, writing to the FS is a workaround to a rather > inconvenient issue. I, too, would like to see if the problem is fixed, not > avoided, by using wdidle -- but I suspect I'll have to contact WD myself to > get that confirmation. A convenient workaround indeed. Much easier than running DOS (I assume) firmware twidding programs or firmware updates. As for wdidle - see the tail end of http://www.readynas.com/forum/viewtopic.php?f=24&t=32179. Sufficient customer complaints might produce a real firmware fix. One thing I'm sure of - the next time I buy a set of disks for my home fileserver, I'll spend some time on research rather than rushing to join the queue (8-( -- Adrian Wontroba I'd rather just believe that it's done by little elves running around. From owner-freebsd-stable@FreeBSD.ORG Wed Jan 27 04:13:01 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AD8581065670 for ; Wed, 27 Jan 2010 04:13:01 +0000 (UTC) (envelope-from dillon@apollo.backplane.com) Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by mx1.freebsd.org (Postfix) with ESMTP id 7F1E28FC0A for ; Wed, 27 Jan 2010 04:13:01 +0000 (UTC) Received: from apollo.backplane.com (localhost [127.0.0.1]) by apollo.backplane.com (8.14.2/8.14.1) with ESMTP id o0R4D0aq019704 for ; Tue, 26 Jan 2010 20:13:01 -0800 (PST) Received: (from dillon@localhost) by apollo.backplane.com (8.14.2/8.13.4/Submit) id o0R4D0f2019703; Tue, 26 Jan 2010 20:13:00 -0800 (PST) Date: Tue, 26 Jan 2010 20:13:00 -0800 (PST) From: Matthew Dillon Message-Id: <201001270413.o0R4D0f2019703@apollo.backplane.com> To: FreeBSD-STABLE Mailing List References: <20100127004905.GF9206@plebeian.afflictions.org> <20100127023805.GB13665@swelter.hanley.stade.co.uk> Subject: Re: immense delayed write to file system (ZFS and UFS2), performance issues X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jan 2010 04:13:01 -0000 Here's what I got from one of my 2TB WD green drives. This one is Firmware 01.00A01. Load_Cycle_Count is 26... seems under control. It gets hit with a lot of activity separated by a lot of time (several minutes to several hours), depending on what is going on. The box is used for filesystem testing. Regardless it seems to stay spun-up all the time, or nearly all the time. Neither the BIOS nor the kernel driver is messing with the SUD control on the Silicon Image board it is connected to (other then just turning it on and leaving it that way). If the drive has an intelligent parking function it doesn't seem to be using it much. I haven't specifically disabled any such function. Device Model: WDC WD20EADS-00R6B0 Serial Number: WD-WCAVY0259672 Firmware Version: 01.00A01 User Capacity: 2,000,398,934,016 bytes Device is: Not in smartctl database [for details use: -P showall] ATA Version is: 8 ATA Standard is: Exact ATA specification draft version not indicated Local Time is: Tue Jan 26 19:25:48 2010 PST SMART support is: Available - device has SMART capability. SMART support is: Enabled ... ID# ATTRIBUTE_NAME FLAG VALUE WORST THRESH TYPE UPDATED WHEN_FAILED RAW_VALUE 1 Raw_Read_Error_Rate 0x002f 200 200 051 Pre-fail Always - 0 3 Spin_Up_Time 0x0027 212 150 021 Pre-fail Always - 6375 4 Start_Stop_Count 0x0032 100 100 000 Old_age Always - 39 5 Reallocated_Sector_Ct 0x0033 200 200 140 Pre-fail Always - 0 7 Seek_Error_Rate 0x002e 200 200 000 Old_age Always - 0 9 Power_On_Hours 0x0032 095 095 000 Old_age Always - 4252 10 Spin_Retry_Count 0x0032 100 253 000 Old_age Always - 0 11 Calibration_Retry_Count 0x0032 100 253 000 Old_age Always - 0 12 Power_Cycle_Count 0x0032 100 100 000 Old_age Always - 37 192 Power-Off_Retract_Count 0x0032 200 200 000 Old_age Always - 13 193 Load_Cycle_Count 0x0032 200 200 000 Old_age Always - 26 194 Temperature_Celsius 0x0022 121 111 000 Old_age Always - 31 196 Reallocated_Event_Count 0x0032 200 200 000 Old_age Always - 0 197 Current_Pending_Sector 0x0032 200 200 000 Old_age Always - 0 198 Offline_Uncorrectable 0x0030 200 200 000 Old_age Offline - 0 199 UDMA_CRC_Error_Count 0x0032 200 200 000 Old_age Always - 0 200 Multi_Zone_Error_Rate 0x0008 200 200 000 Old_age Offline - 0 I have a few of these babies strewn around. The others show about the same stats, e.g. this one is used in a production box. Same drive type, same firmware: ID# ATTRIBUTE_NAME FLAG VALUE WORST THRESH TYPE UPDATED WHEN_FAILED RAW_VALUE 9 Power_On_Hours 0x0032 095 095 000 Old_age Always - 4164 12 Power_Cycle_Count 0x0032 100 100 000 Old_age Always - 43 193 Load_Cycle_Count 0x0032 200 200 000 Old_age Always - 26 ... So on the face of it things seem ok with these drives. Presumably WD is working adjustments into the firmware as time goes on. Hopefully they aren't just masking the count in the SMART page to appease techies :-) These particular WDs (2TB Caviar Green's) are slow drives. 5600 rpm, 100MB/sec. But they are also very quiet in operation and seem to be quite power efficient. -Matt Matthew Dillon From owner-freebsd-stable@FreeBSD.ORG Wed Jan 27 05:46:13 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 017341065670 for ; Wed, 27 Jan 2010 05:46:13 +0000 (UTC) (envelope-from gerrit@pmp.uni-hannover.de) Received: from mrelay1.uni-hannover.de (mrelay1.uni-hannover.de [130.75.2.106]) by mx1.freebsd.org (Postfix) with ESMTP id 660E08FC20 for ; Wed, 27 Jan 2010 05:46:12 +0000 (UTC) Received: from www.pmp.uni-hannover.de (www.pmp.uni-hannover.de [130.75.117.2]) by mrelay1.uni-hannover.de (8.14.2/8.14.2) with ESMTP id o0R5k6oO016777; Wed, 27 Jan 2010 06:46:08 +0100 Received: from pmp.uni-hannover.de (theq.pmp.uni-hannover.de [130.75.117.4]) by www.pmp.uni-hannover.de (Postfix) with SMTP id BE79224; Wed, 27 Jan 2010 06:46:06 +0100 (CET) Date: Wed, 27 Jan 2010 06:46:06 +0100 From: Gerrit =?ISO-8859-1?Q?K=FChn?= To: Damian Gerow Message-Id: <20100127064606.9c546283.gerrit@pmp.uni-hannover.de> In-Reply-To: <20100127001201.GE9206@plebeian.afflictions.org> References: <20100126235458.GA12634@swelter.hanley.stade.co.uk> <20100127001201.GE9206@plebeian.afflictions.org> Organization: Albert-Einstein-Institut (MPI =?ISO-8859-1?Q?f=FCr?= Gravitationsphysik & IGP =?ISO-8859-1?Q?Universit=E4t?= Hannover) X-Mailer: Sylpheed 2.4.2 (GTK+ 2.10.12; i386-portbld-freebsd6.1) Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-PMX-Version: 5.5.9.388399, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2010.1.27.53621 Cc: freebsd-stable@freebsd.org Subject: Re: immense delayed write to file system (ZFS and UFS2), performance issues X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jan 2010 05:46:13 -0000 On Tue, 26 Jan 2010 19:12:01 -0500 Damian Gerow wrote about Re: immense delayed write to file system (ZFS and UFS2), performance issues: DG> Adrian Wontroba wrote: DG> Having a script kick off and write to a disk will help so long as that DG> disk is writable; if it's being used as a hot spare in a raidz array, DG> it's not going to help much. For my RE2 and RE4 disks I wrote a script that calls smartctl -a on all disks (one after another) every 5s or so. This also prevents the counter to increase in my setup and you can do it for every disk, no matter if they are in a raid compound or not. I think writing to the disks may also fail the desired effect if you have stripes the writes are spead to (raid 50 or similar zpool setups). Just my 2=A2. cu Gerrit From owner-freebsd-stable@FreeBSD.ORG Wed Jan 27 06:36:59 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7FCB7106566B; Wed, 27 Jan 2010 06:36:59 +0000 (UTC) (envelope-from peterjeremy@acm.org) Received: from mail34.syd.optusnet.com.au (mail34.syd.optusnet.com.au [211.29.133.218]) by mx1.freebsd.org (Postfix) with ESMTP id 088EE8FC0C; Wed, 27 Jan 2010 06:36:58 +0000 (UTC) Received: from server.vk2pj.dyndns.org (c122-106-232-148.belrs3.nsw.optusnet.com.au [122.106.232.148]) by mail34.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id o0R6apxH001385 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 27 Jan 2010 17:36:52 +1100 X-Bogosity: Ham, spamicity=0.000000 Received: from server.vk2pj.dyndns.org (localhost.vk2pj.dyndns.org [127.0.0.1]) by server.vk2pj.dyndns.org (8.14.3/8.14.3) with ESMTP id o0R6anja001952; Wed, 27 Jan 2010 17:36:49 +1100 (EST) (envelope-from peter@server.vk2pj.dyndns.org) Received: (from peter@localhost) by server.vk2pj.dyndns.org (8.14.3/8.14.3/Submit) id o0R6anAX001951; Wed, 27 Jan 2010 17:36:49 +1100 (EST) (envelope-from peter) Date: Wed, 27 Jan 2010 17:36:49 +1100 From: Peter Jeremy To: John Baldwin , Marius Strobl Message-ID: <20100127063649.GA1889@server.vk2pj.dyndns.org> References: <20100126073336.GA1955@server.vk2pj.dyndns.org> <201001260946.44977.jhb@freebsd.org> <20100126183756.GA40779@alchemy.franken.de> <201001261510.59667.jhb@freebsd.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="n8g4imXOkfNTN/H1" Content-Disposition: inline In-Reply-To: <201001261510.59667.jhb@freebsd.org> X-PGP-Key: http://members.optusnet.com.au/peterjeremy/pubkey.asc User-Agent: Mutt/1.5.20 (2009-06-14) Cc: rmacklem@freebsd.org, dfr@freebsd.org, freebsd-stable@freebsd.org Subject: Re: uma_zalloc_arg complaining about non-sleepable locks X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jan 2010 06:36:59 -0000 --n8g4imXOkfNTN/H1 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 2010-Jan-26 15:10:59 -0500, John Baldwin wrote: >On Tuesday 26 January 2010 1:37:56 pm Marius Strobl wrote: >> On Tue, Jan 26, 2010 at 09:46:44AM -0500, John Baldwin wrote: >> > On Tuesday 26 January 2010 2:33:37 am Peter Jeremy wrote: >> > > I have just upgraded to 8-STABLE/amd64 from about 18 hours ago and am >> > > now getting regular (the following pair of messages about every >> > > minute) compaints as follows: >> > >=20 >> > > kernel: uma_zalloc_arg: zone "mbuf" with the following non-sleepable= locks held: >> > > kernel: exclusive sleep mutex sp_lock (sp_lock) r =3D 0 (0xffffff000= 460bb00) locked @ /usr/src/sys/rpc/svc.c:1098 =2E.. >> Could you please give the following patch a try? >> http://people.freebsd.org/~marius/fha_extract_info_realign2.diff That seems to have fixed it - I've booted the new kernel and generated some NFS activity and am not getting any messages. Also, vfs.nfs.realign_test is incrementing nicely though vfs.nfs.realign_count remains at zero. >Hmm, the old code was already using M_DONTWAIT, so now I don't see why you >were getting the witness warning. Actually, there were two nfs_realign() definitions in the kernel - one in nfsclient/nfs_krpc.c (which used M_DONTWAIT) and another in nfsserver/nfs_srvkrpc.c (which used M_WAIT). It was the server code that was being exercised here. --=20 Peter Jeremy --n8g4imXOkfNTN/H1 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.14 (FreeBSD) iEYEARECAAYFAktf3wEACgkQ/opHv/APuIdNAACeJj/mR/Jl/RH9gDcJOCDGjWKJ 5LIAnRtjov0Hx7ko+Wj3aEem0rkOe2YC =o6S9 -----END PGP SIGNATURE----- --n8g4imXOkfNTN/H1-- From owner-freebsd-stable@FreeBSD.ORG Wed Jan 27 07:09:46 2010 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2907C1065672 for ; Wed, 27 Jan 2010 07:09:46 +0000 (UTC) (envelope-from ncrogers@gmail.com) Received: from mail-pz0-f176.google.com (mail-pz0-f176.google.com [209.85.222.176]) by mx1.freebsd.org (Postfix) with ESMTP id E9F168FC0C for ; Wed, 27 Jan 2010 07:09:45 +0000 (UTC) Received: by pzk6 with SMTP id 6so260555pzk.3 for ; Tue, 26 Jan 2010 23:09:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=sfRoMkxCXp/ZEo1nM4rPH3qnGRL9uC2F7RkT5UuORaA=; b=C3HCNQZEFOoCzH1M//cPF9mMYn36F+b1MIepDWmoNNKt9bTPXbdT4cqe7/G+F6plQt Djm+OILod53w2A2qgMvYK3/UFHNYbyOJebuq9UtWXgdB3hRWxtnuryNs+orU+S3aLvno yMIACwabXx8VN40eDnZwxFagFI1V4Zbd4xGJE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=mAczXV9W2dNUEPod3Yo0iGKkHgs+RRl1msCyGbaSUgamCdpmnrZ2aGReDSKf6UZkAo 2dVEHa9mXhidi3VOfirzKDyC9aVAC6m6VStr0RYx7SgLEJxmncBlZ+hi68Pt46ajXN5v YQPhAnsiw1bSaz94j9QX6BR1xe0NlhzCNeWrE= MIME-Version: 1.0 Received: by 10.142.118.24 with SMTP id q24mr66296wfc.238.1264576185361; Tue, 26 Jan 2010 23:09:45 -0800 (PST) In-Reply-To: <33c6b0bc1001252031k508426bfh25fad65e9223d87@mail.gmail.com> References: <20091201.102925.218343479.hrs@allbsd.org> <20091203.182931.129751456.hrs@allbsd.org> <4B43F6EE.3010308@ucla.edu> <147432021001242047k659a26d0s44b35164920aeb74@mail.gmail.com> <95D3CB82-BC44-491D-86E4-5CB82F89C0FC@nokia.com> <147432021001250825p202914a7ka5a2c1d28d96bac3@mail.gmail.com> <20100125182257.GG1187@michelle.cdnetworks.com> <147432021001251038r69393ab3m1a797e58f9fa905a@mail.gmail.com> <02307620-ECDC-4E8B-A5B1-FF8491E226C4@nokia.com> <33c6b0bc1001252031k508426bfh25fad65e9223d87@mail.gmail.com> Date: Tue, 26 Jan 2010 23:09:45 -0800 Message-ID: <147432021001262309l47ac1a1bsf08c70a9335c887b@mail.gmail.com> From: Nick Rogers To: Joshua Boyd Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: "stable@freebsd.org" Subject: Re: em interface slow down on 8.0R X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 27 Jan 2010 07:09:46 -0000 Can anyone clarify if I should be looking to disable TSO or TXCSUM, or both, or does disabling either one somehow work around the problem? Thanks a lot. On Mon, Jan 25, 2010 at 8:31 PM, Joshua Boyd wrote: > I've been having a similar problem with my network dropping completely on > my > 8-STABLE gateway/firewall/fileserver. My setup is a little different, as I > have re0 and ral0 bridged for LAN, and em0 for WAN. I've just turned off TX > checksum offloading to see if that makes any difference. > > On Mon, Jan 25, 2010 at 1:49 PM, Lars Eggert > wrote: > > > Hi, > > > > On 2010-1-25, at 19:38, Nick Rogers wrote: > > >> On Mon, Jan 25, 2010 at 10:22 AM, Pyun YongHyeon > > wrote: > > >> I'm not sure you're seeing a checksum offload bug of em(4) but the > > >> bug is easily reproducible in VLAN environments. If the issue is > > >> gone when you disable TX checksum offloading, see kern/141843 for > > >> for more detailed information as well as fix. > > >> > > > Good to know, but I am having a similar problem on another em(4) > > interface that has no VLAN interfaces. > > > > FYI, I also have these issues without using VLANs, and turning off TSO > > fixed them. > > > > Lars > From owner-freebsd-stable@FreeBSD.ORG Wed Jan 27 07:16:32 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C9847106566C for ; Wed, 27 Jan 2010 07:16:32 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from qmta12.emeryville.ca.mail.comcast.net (qmta12.emeryville.ca.mail.comcast.net [76.96.27.227]) by mx1.freebsd.org (Postfix) with ESMTP id A8EAA8FC13 for ; Wed, 27 Jan 2010 07:16:32 +0000 (UTC) Received: from omta14.emeryville.ca.mail.comcast.net ([76.96.30.60]) by qmta12.emeryville.ca.mail.comcast.net with comcast id aX411d0021HpZEsACXGZwP; Wed, 27 Jan 2010 07:16:33 +0000 Received: from koitsu.dyndns.org ([98.248.46.159]) by omta14.emeryville.ca.mail.comcast.net with comcast id aXGY1d0013S48mS8aXGYRc; Wed, 27 Jan 2010 07:16:32 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id DEFB11E3033; Tue, 26 Jan 2010 23:16:30 -0800 (PST) Date: Tue, 26 Jan 2010 23:16:30 -0800 From: Jeremy Chadwick To: freebsd-stable@freebsd.org Message-ID: <20100127071630.GA69403@icarus.home.lan> References: <20091203.182931.129751456.hrs@allbsd.org> <4B43F6EE.3010308@ucla.edu> <147432021001242047k659a26d0s44b35164920aeb74@mail.gmail.com> <95D3CB82-BC44-491D-86E4-5CB82F89C0FC@nokia.com> <147432021001250825p202914a7ka5a2c1d28d96bac3@mail.gmail.com> <20100125182257.GG1187@michelle.cdnetworks.com> <147432021001251038r69393ab3m1a797e58f9fa905a@mail.gmail.com> <02307620-ECDC-4E8B-A5B1-FF8491E226C4@nokia.com> <33c6b0bc1001252031k508426bfh25fad65e9223d87@mail.gmail.com> <147432021001262309l47ac1a1bsf08c70a9335c887b@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <147432021001262309l47ac1a1bsf08c70a9335c887b@mail.gmail.com> User-Agent: Mutt/1.5.20 (2009-06-14) Subject: Re: em interface slow down on 8.0R X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 27 Jan 2010 07:16:32 -0000 On Tue, Jan 26, 2010 at 11:09:45PM -0800, Nick Rogers wrote: > Can anyone clarify if I should be looking to disable TSO or TXCSUM, or both, > or does disabling either one somehow work around the problem? Thanks a lot. > > On Mon, Jan 25, 2010 at 8:31 PM, Joshua Boyd wrote: > > > I've been having a similar problem with my network dropping completely on > > my > > 8-STABLE gateway/firewall/fileserver. My setup is a little different, as I > > have re0 and ral0 bridged for LAN, and em0 for WAN. I've just turned off TX > > checksum offloading to see if that makes any difference. > > > > On Mon, Jan 25, 2010 at 1:49 PM, Lars Eggert > > wrote: > > > > > Hi, > > > > > > On 2010-1-25, at 19:38, Nick Rogers wrote: > > > >> On Mon, Jan 25, 2010 at 10:22 AM, Pyun YongHyeon > > > wrote: > > > >> I'm not sure you're seeing a checksum offload bug of em(4) but the > > > >> bug is easily reproducible in VLAN environments. If the issue is > > > >> gone when you disable TX checksum offloading, see kern/141843 for > > > >> for more detailed information as well as fix. > > > >> > > > > Good to know, but I am having a similar problem on another em(4) > > > interface that has no VLAN interfaces. > > > > > > FYI, I also have these issues without using VLANs, and turning off TSO > > > fixed them. The recommendation is to disable TSO (TCP Segmentation Offloading) as well as TXCSUM (TCP Checksum Offloading). -- | Jeremy Chadwick jdc@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Wed Jan 27 10:46:09 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AE8FB1065776; Wed, 27 Jan 2010 10:46:09 +0000 (UTC) (envelope-from aoyama@peach.ne.jp) Received: from moon.peach.ne.jp (unknown [IPv6:2001:380:e06:127::53]) by mx1.freebsd.org (Postfix) with ESMTP id 02BE38FC13; Wed, 27 Jan 2010 10:46:08 +0000 (UTC) Received: from moon.peach.ne.jp (localhost [127.0.0.1]) by moon.peach.ne.jp (Postfix) with ESMTP id D77A178C53; Wed, 27 Jan 2010 19:46:07 +0900 (JST) Received: from artemis (unknown [192.168.2.20]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by moon.peach.ne.jp (Postfix) with ESMTP id 869B678C3B; Wed, 27 Jan 2010 19:46:07 +0900 (JST) Message-ID: From: "Daisuke Aoyama" To: References: <18D68DBE18AC435984C5F66597A869D3@artemis> Date: Wed, 27 Jan 2010 19:46:04 +0900 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="UTF-8"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5843 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 X-Virus-Scanned: ClamAV using ClamSMTP Cc: freebsd-current@freebsd.org, freebsd-stable@freebsd.org Subject: Re: [PATCH] VirtualBox headless VNC support by LibVNCServer X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 27 Jan 2010 10:46:09 -0000 Hi, all I updated for 3.1.2_1 and fixed bug of initial pixel format. Before building, install "ports/net/libvncserver". I recommend you backup virtualbox-ose directory before doing. Uncheck QT4, X11, NLS by make config before extracting. Howto apply the patch: # cd /usr/ports/emulators/virtualbox-ose # make config # make extract # patch -p < /path/to/VBox-VNC-Makefile.patch # patch -p < /path/to/VBox-VNC-20100127.patch # make Regards, Daisuke Aoyama From owner-freebsd-stable@FreeBSD.ORG Wed Jan 27 10:48:07 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id ED280106566C; Wed, 27 Jan 2010 10:48:07 +0000 (UTC) (envelope-from aoyama@peach.ne.jp) Received: from moon.peach.ne.jp (unknown [IPv6:2001:380:e06:127::53]) by mx1.freebsd.org (Postfix) with ESMTP id 87C298FC1F; Wed, 27 Jan 2010 10:48:07 +0000 (UTC) Received: from moon.peach.ne.jp (localhost [127.0.0.1]) by moon.peach.ne.jp (Postfix) with ESMTP id DFDB578C53; Wed, 27 Jan 2010 19:48:06 +0900 (JST) Received: from artemis (unknown [192.168.2.20]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by moon.peach.ne.jp (Postfix) with ESMTP id C2F4378C3B; Wed, 27 Jan 2010 19:48:06 +0900 (JST) Message-ID: From: "Daisuke Aoyama" To: Date: Wed, 27 Jan 2010 19:48:04 +0900 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0034_01CA9F89.A42D0430" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5843 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 X-Virus-Scanned: ClamAV using ClamSMTP Cc: freebsd-current@freebsd.org, freebsd-stable@freebsd.org Subject: Re: [PATCH] VirtualBox headless VNC support by LibVNCServer X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 27 Jan 2010 10:48:08 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_0034_01CA9F89.A42D0430 Content-Type: text/plain; format=flowed; charset="UTF-8"; reply-type=response Content-Transfer-Encoding: 7bit Sorry, I forgot attached files. ----- Original Message ----- From: "Daisuke Aoyama" To: Cc: ; Sent: Wednesday, January 27, 2010 7:46 PM Subject: Re: [PATCH] VirtualBox headless VNC support by LibVNCServer > Hi, all > > I updated for 3.1.2_1 and fixed bug of initial pixel format. > > Before building, install "ports/net/libvncserver". > I recommend you backup virtualbox-ose directory before doing. > Uncheck QT4, X11, NLS by make config before extracting. > > Howto apply the patch: > # cd /usr/ports/emulators/virtualbox-ose > # make config > # make extract > # patch -p < /path/to/VBox-VNC-Makefile.patch > # patch -p < /path/to/VBox-VNC-20100127.patch > # make > > Regards, > Daisuke Aoyama ------=_NextPart_000_0034_01CA9F89.A42D0430 Content-Type: application/octet-stream; name="VBox-VNC-Makefile.patch.gz" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="VBox-VNC-Makefile.patch.gz" H4sICKTlX0sCA1ZCb3gtVk5DLU1ha2VmaWxlLnBhdGNoAJ2RW2vCQBCFn82vGESwsm666y1RiMRc 1NA0kWS9vAVr1jYYTWkstIj/vTGttRTF0n3YeRi+M2fOYIzhfr7iyyjm+Dl52aaFGqEEE4prTSBy h8qduiyS4wNE2oQICKFv7ARIQFsd0ug06yJpNyS5eQJUFbDcrrYAZb8EqirARHNnQd9zHWY6ho+U iZa8aX0TDtU37Lwynm7dgS3AyLZ8FvhjDSmFGaVKsSiAyOOUC2hqsWFgW9rE0RV456kAuuv0rcHY M4OeN8iUMX54jeIQP/F5GPM0PSOnLpL1mm+2kOtuwmiZW6ZS/eCZSo1qOzddUEs7Ux+6eyjn/vPh jsn6NgMFaBm6XSjtpt6d7+n7WztZzGM92SyjR3G1Xl3Ge8Yow/9FM9Nnes83feUKjsRoCWF2sg0P b36EVhHQWeHP7h+2Ql+Bwe8B7pgFWbqVC86zVtAzDItZrnPV/fEqH8Bi7AGxAgAA ------=_NextPart_000_0034_01CA9F89.A42D0430 Content-Type: application/octet-stream; name="VBox-VNC-20100127.patch.gz" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="VBox-VNC-20100127.patch.gz" H4sICLfmX0sCA1ZCb3gtVk5DLTIwMTAwMTI3LnBhdGNoAO19e1/bSLLo3+RTdJiTYIMBS34CgR0e JvEdXmtDJrMzOb6yLWMtsuxIMuBJsp/9dvVL/ZBsE9jZ+zu/w0xsq6q6u7qrurq6+qG+NxigTWca XqCHcXi36T7GodOLtz96YTx1/KPx42Zpy9qyO5ftxnYU9rY/YtD2aTgOYjfoR+Txg+v0fTeKts+d O3fg+e7W3eiOZPf8bF5tbm6+MGcrdrG4s2nZm1YN2aVdu7ZbqW4V+R/aKO4Ui682NjZeqAa4OKu4 WbQ2bQvZxV1rZ7dcM4r7+We0WbELVbSBPy0b/fzzKyTn2LlunF+dHV43ENrdR/+V8wb44+PR5afO r83rD50Ph62TxkXz4n2+AMDzw+bF8VmzcXF9cnamQRqfGnkt75PGaRvRv31EMj09Pb9qvNfI2pc3 reNGm5MlmK3eZPJqwxv03QFKeDprHn28OH61kVHWxv5CWlEg0F4cn4bOyO1OBwM3pCVmU9+5s5Ez 2erpNLgcUfp90Ivc8N4N0Z/onxP39tUGlqM3eIX0inxsnVy9QstUI41SZkuvQf8lO58ukWeoryHc l+mEerZ/QUdMKZJ1xhKy6ruVym5xJ7UzlmvQGfEn5g06409e0POnfRe9I8W5Ybg1PDDA8PHR67tj gny18VNWp5ARrLNt/DQNTBjVyQ1RzqrWEYarIrNO5zR03aP2SacjJXgXzaLteDZxI+BJgk8DL4r7 FEhKQdvrch5ofVvG6HUgaGgAoyJSo/RwCb7XVRqqh9suGB+QVq5VoZXruJUt0sqv0PYL/82VQhQ7 sddDR5eXZ+h2cNiNxv40ds/H08h9P3WjGNu508OzdmNPJyXYC9ftRx/GUXw8DaNxKBEvbDWMufXH XcdHD65zh0IXi9INem6EcgOck3vvBjEaOgHW2zDKQyLEGDgej67iEL1rtrFGe+OgAJBfcSYtd3CA bhl0z6Q/Hge4eq5Gz6B7RBpWuQLisKpWwSoyecBf+/rkvHH94fIkdxmQxjl2Jk7X8714doyZvHXz KEcaJppOJuMwjnhLFmh7BWpD5WmuX+cIho1GWULRy9mTU2TIRmNioZR4hoBvjLwYOawwNAJWmIzi McLmEJslf4bcwOn6LoqHLhrichhdjxS3pWSJS83pdUBv3wpx5BPSr0QypQrpKCXcX6wSkcxXStK6 vgq9IB7kVm8i59bd/SNYTdKSv1X8bzMq4H+xE8b3I/yL/0TvAmxIvk2nXv8AxAxQdOvhiqGP5ygX ul+mXuj2kRPeTke4tnnIfbHQkmLvcWF4mIUi8RcaB9/GeMDT/hq02XI4U2fqx3mExdX3ItGWII82 GahJ8WYpDi3F6fdDrP2sMPaE3nkTqBtqXiEO4pmy0f/B833U9YI+FmZGCRNaAsiLZQ8/0Tv4POCU VwAKpqMuzvPpRdzRIqjjwgqhD+gd/cYF/eLOumMn7CP8CO6laLRd1J16fuwF6KadzyihTUuI3F7o 8mrQBzxGkG9cAjB9OMXsB9h4YAMyDhDFUdHP7zE/ZXhO6XoR9mk98TfTjG+9cTDwbpfVC5x5urov 98dkA7mOg7UY9YgpI1lHbozb8hZyJ76ATZ2BSpn3PlJd7Au5YYBWj1fRSeP4rPHp6rJ1jXK4O+bR dTiNYrd/7mCRAAT6EO4HuIwQra/jh3vx4Ab3k/yrheZwGkTebYB7I+SGRUfUbR9VsMPCzB9uvShm uWKCQ6bu++ji5uwsnYa2cX8uzS9UC+eRtKkaCZIf1xMlY6wZrJY031QKvZpEYHU6lbKwuaxTgRFT mlhVtMqN4GoBrUVrBWxJ3zeuL6+uO63G3zvt6xaeTKHvBTXJkmkWm0jIjFkRyGui53XTvLgu2SQv pfwfSJPYQkjlzOFaL+kHkuFUQH7/hFKeQi9sIiS6e0IhT08ljCMkaj+hqOVSPc+SEgax7mfqQpb+ LpmIRCNKJdKHajsFuyT6kPwHXsxrr59/lWpewbWAOIHjT92bAA8kW5Pozz2TthtiZ3RvSbei52CP CnO+qw1w+C8xiVKR05K9Z5LyIs2cnYycEyOj1+cJmd9nZJ4Y4WdkfpeRubDez8i7nZG3MPtL5/18 ByLRAEOTpPFCZwgUumoVQaGrtVLBqqQqNK7MFA/om5akpt9fsa+Fc3ll+s37R9JKr+kAlYeBfgU7 GJNw3Iu92Hdzqx/Pd9GbiDiQ+EefOGC72CfCvTRHupFI+zfarXbRajAOXIxnWp9nbf4duT5un6WL GAx+oIwfjxeg9HgBb6ypTyIbv3r9eIjeoYplo2/fkAI9QHaxXDfAb5CdJ0Ku04nSjl0vlHdShcxU URbwHNmukAnsAP9OemkcTmHGuUKCPRfHp0dofSKFZFRPSXHdpm2sCm7QhFzAa8OZMCXhuXMpYMxX tRvhJpUnUdDYhjGO4rA3mkj5FdAqyDgPDZaKZQ71aj5vdlq11gMHa5bWtYmykclsWsEBLhdPatNw dKpslPrVZCKZ4JLaszlphJxATEtRjrYJTHzySxq278njd5CD3IxSvSX+NN7Oxrcoh/uVFF/cpVMW PHGQ5n5bW1vAVn5PLgX+NJUJ3AeUKFROrwcRr5zkKS3XCMNxuIsl6IEoIWTh+2M8u3PRIMnwxxov lbfNA3/s9OnIkxNjUD7/RC4hExbJX8DcSgpXKkPYGoLJawaDcWKTFzby5oEXeDGxj8IMFiR/IP8s KUDenuN7f76QHIwak5gZjy/l3qYF0wrobXrETOfByJyFqnI9FrKaS4/bq+UODK3G1mfiO7PNg7Yb S/Q5YScLSj5y8u/PdSZwMhZZQF4E4pDCd5iQhwdyXad39wAxl954NHFij8Y980o8jw0SOBkLWvBB AoaknQrxO6xitVKwylJYNdOM0NCiPx5P0NDBvLnhyAtwd+0nxgQt4TCDOmeYjK/zhNVyfRe8LENc mFnMK0P3daWdpwHmmPg0+cmeQnrVpD74sqtqxrrjc1ajzEXMF1pZMzJesXZqZKGraKHizm6xiP9/ 6bU1s1CxulZBVnXXsnYrldTVtWIBP1nYRSPLDBvb61gx1rU1XvTgYc/uzOtiMI3/EiJsNVzmTsFS CbifF4dtVNyqbVmE4BhbStxXUHeGThwvmt656HA8c0YOeueQ758nrtMbbgXu1j8nB5AElmQ2tJU8 3Nvhn7ZmJlDYqcHjfBb2/dTrZ+HIMADjUCYB9P6/T92pm0WRSItQyDTeJIyBOdfRWScYN7g3kvRg cVAjTq1e1kIiwKNx786NNUTgxh7+t+0FGsIJJ842oBgz0wicJhhmo4nTc8HUEn/pJ2wAMBk6u3zf ed+6vLlKfnXe3zSNxmGrsjrYH9/qtVYsLltEnbvCypFsZwEAiQlGlMW+tBnj09Xx5Tk2thftTvP8 6qzTbN9cQWi4bXWOmznh5BVQUzXOmB7iyJ3js8N2u3lxepnQ5pOVYLEUGQ66R+Oxj/rjyUNv6Pbu chhy7HtYe2DFr+cXpFjpOvacowl+xI4MBJB9N8gnq5r3Y68P+cQhiVV3p3E8Ds6d6I4SP9KvWQFp JZhZ3HX7uYSxh4Akwf5fezYCVw5/pWbyakNUdXdX/MzharORCsoPe2z8wOPQqT9+YOPmqZZKHovC Hh55WtfHoRdjly9ugjf3dtS5mfSxiTjDOssJDyM83sfn0W0Okuyjj7j9O+2b4+NGu41nyNR5wyPe eKRl91oubtShjos63I06kRYfp9DUpU2FImMpU6ERa0IanOSqA7GEHzGM/JjhHxDq2Piutf+/0gSg trlBKbcCDM6iJZSwB5Z8eziNQTGoRRd0BXTdumlADisD/JzLgT6t5zl68wAb/bt4PLnAHWYOFXFJ joSzSAokqGPsswTTiSiPYNPFxbzqRMwn2OEB/1nXG9JuXdB0qUnIhEFeo6CTB2X1hq4jykQs1K7q +wMJbeyjarlYQEPXux2CgpTr+Kk7gVhkvYCiCcT2SgDBP8p7Um8ZOSBqu1IpoFvpd1f8lomjoTeA 3K0qpuYPOP8u/12UqPtQpw42IXw1iNSBQMU0V2pbLIT3bkwfc9DQBUQ/SQV51UilSIVIZbgyibJI Q6ANNVqF/gbhBYwl0DzaRcU8prHkxDhhjpjA/IjMe3MiS1lh1RgYCaAFEzpz61MRimQFOnqg3Jso v1ogw1Za/G1B8tW8qm+pqo55582q0kxonBO+pErwFe59Wg/MxbdvPP4ilsdX11fzQFHMQGM3Ef5j RLQtkoJ9L8KuYBP7g+EAhup9NMRjhZ9rXhyenLQ6hxe/pbTFvOTgBnSgdM5CZrtInduQKe0r67yb rMsqNHJHeL6aS82ogHBvSk+dNxs9DvFElvhnIBgYLw0aPAAqNPjZoInI94kTO1APasPioRcZhM40 Hl45UfTQV4n5iGJyCMTjsH8M/gDlkfoGfDwcdGHQ0oyvWVM6+T0dYyMSb4Wwjg02A0zKfNJbgFHi 24XEXX/qUtruQlrMQ5tZImqrluCDJ7hdIgHwwum7Mj1usdY0IPI8wxNyacDatJJBi9HS9QMWH04d HqTAmGz/qVcpmX/cmYG0QxGdGKIKOUYFZor1S1aiHJv9nskLcdEkXuSYmMwM1a2EGcl/EWqXlaEa ciJxkfW0qBPFpAaepHJTPSQTuMhfSgPPqQOPbNGtc2Ln3AF6K7ZncRYZYPMAe/zvG9fXjVaO+2P5 XOKbbTnR5TS+crDdyeVNl/N1Qpn4mncMIntWKcWRVoCyyI/FBRGypBSyR40X8f0lZxeijaRlkkEX bJgArOd7PreGslVU3Aqhe8zgD7qbB7eS5tLuBzOxIk3Ght1VmnD/TfQHLKRFIuLLJ1JiIx4rgHkU MCQSyO/FzwBc+6O4lk+6Gt/iyWxDI+iFs0l8NIvdKAe1AZN9PMSDkhvcunKxwjN2RzDeptAmbQjt J/dyXE4Y5lYddWMWiySTSQmrJeQKew+p82tyrBoHsF6a2H94Jvh8cfPuRjT0APH5C5M3eRQRSWJW nW6k4YXhycveKowweJTvz9j3n/Sb1i0SS3EpKoSbYRc97r/B3XJGPke4JfAP0ta4LWYFqYXSdCvB oreo+Fi0QJN4wd/2aSWPyHMbC8DtnLmDmD7vZediL8rl3Ov3fXdhPuVF+bTAHVqYTR2yIa26aWWT WUVBZokRkzit3YiqOSl+8+BqSoVJxlwhUdra/T8LkuhSPE0yvcKT3AJ8zshEUdIPrF+5BEs6CYkk w6z4NbAP65VkakyeKFtkIgE6lMs9ok2Sex67iFYV985tZJHtd5RoRohmlGiWTpRWyVz/EdQzrXor 31kVIqkK0BaSl5zSf38kDPNyPZgPZgdICk4wOXCI0kWjnhP0xn03qx9CFUj/w4zvv3kk3Q9gePpn wZyvwCqV1gUpBr0jKlgEAXuR40+GDsPQZckVRraP4rE/fsDOcZKjZDijBy/uDXmmYkGTbEr59Evn 0I87rV2Y/LEKIXIUKZqNbA7JMbIzIl3eGkQh2pyk+OgW56Bfs6qLQr7hutWLuCE4hCSWVww5g9iB iMOxvwyTnPQ/wyhZNNWYLD7azr+bF6W4Uu2vqjrovKW2wC9XneKurJhrxbU9dDuOxyiAOYvfkXqN ltBSE1pLJ7TVhPbSCUtqwtLSCctqwvLSCStqwsrSCatqwurSCWtqwtrSCetqwvrSCXfUhDtLJzxx ex6mUJNvZSeXjSY/UoDTsow1+gW2IzGcZHAVlO+4O0tW37e5bZ8GdwH0FULDbLuUhTS2q+kgX54I 7R+oSQtqNyOmm/PxFrp2bcDhz+q/39VBWByUap5fyZPKZLpGtqvlczdnlxfv0TqJOy2Isb93Y5JI j7C/5om13YuNTvPi4+FZ8+Sw9Z6Rr/NIMi1XipcTxJ4yKWh3Ln/ZW7o+H0jETFSIBtAW14gmM6ok ki9RJxEQNypFMU+vFcT1F614AI3MdrJK0ICYZvri0hN4uAn8JbigVOl8nLnOvftsPhIJ861OuaPf rhtwdkVfqsiSMUtoCDnJYAkpi4g2IuVnrPU8p35HXhxdueGV9+j6Qo+7MnBhTeUsjOpqWS1RZzlF mn7L+GfVHIIWOKMzL3CTmsvAxTWXqM2aq1ktU3MpRVLznGav8Lwql94aeKpVzz9L20k2NCacR7xN JhJQCdG+VjFGDa8umxc4V149iRoplwFIpXZO4b6A407r/dFz6nETuREJe35sHZ7z47nrUwWqVkXH LaqMQi+dfX7mUNJy+9MehLeS5h9qCJVvE7uIcy2FtLj5Q3xf3ruh7+Dpfk7ez8GgYDA5gcq3BF7E MCd9Lqe/ekGzj/mcYg+qWu7E4BgARGWMwxZxReh+jKWLcewNZnSAYlJ+LCD6Y8Z/PPAfkofEaO0C mtlKEOmBLlZil+yBBZg4ZigwQwnzaOOHR7SBHhhgBoAZBgyVfB/RQZbbBFk+LnKqSB72gkzsZXKZ pWYiPKaV2UJXiORiL8rGnptPSnCGihF9IgGa38jnr+TzA/7EnrkIlWKBDrlx5onlVJ9s+mCrEVYq bT20Ew66505418Iez2F0PsZwz+1Lq3N62idqaMv9Arat5Uben1xFnWRXMgVI9ryAqHt0jy1Awdy9 nfJHs5BHL56tPAo+Ja+kw/D1tYEXeNHQ1Xu4BF4Rvfv0sHmmCpiuG7UIQU4Zu5YYvArKAK8uRbEs VT9nH5VsM1Gy603WGkU6u+iB6M2QfHYnE/btk+/BKGYRQzrfAyUsaM2uNLgs1WRpV96P8yDtxhn+ J/fi0AWysd8fdAtoPXAfBl3BMI9UKu6nEq8s2buw9/pTvV4nW2BXWEX2eEX2aEVQmSwmJaxKVdhT q7Ai8b4n8b6n8m5G/Owy4eX/B1asKmGlUq2ksmJzVmyJlZItOKmWBSMlW+XDkvioLOSjTtgolexU NizOhiWxURNc1BImFB4qEgv2QhaKVEE+fRKnzaTY0H9GRN9ThyDMC+nskej89Dskn7cUxkYVagaU vWYF0kFp16Sd0jQ9pJeRrZPZ80/SA39kaxJJuGArklTtRWNfkfyvuRIygA335pB64T7I53CSLBmH y+zY+99dROYuIrJblahQMqSI0Tk5UvpEJ4XcNIbl77bpXUJYCZgnQMXEvAEmLOZcgLSodxDxVJp7 IMMXTQIEbVIJSVHJMjC2Cq/BGIK3odDzXUuKDi5f+/du/NGLvK7vttxbPI9jASoHuoUT3PpuxOvs HI+ngWiBdfp4PJ54RtWlxIsr/wRe20/k9S9i6yoc99wo+vjh18Pj8WjkBH3G2IQ9JnywXHFpF5fX cKyB5P3vPGo1fLmjScN/zzGr4V9/yGpoXmBoF+cdsarX2AkrZDQvP/c0COj1BR86QNI6PG8c3Zye NlrJ+Zs0nHzKBo8c2/ifdvYGoHRxKP2YUi/EvilWbIbt+U4USZsPdunRv/Zxq3l1fXh01iCnaXLa oRmsnpNp1/d6u9rmBbHB4J42O/qXihIHKFvXWBCdX5sXJ5e/tmkS0V861KAWED3Ams+x7vfV6IW7 u2RTM8Tl3X4zwKMDPZr+NnQHvSDW9hGYBbBTlWkl+OPgFvXIfmKllBM3qxRuOEgiGv1Qjt2SAw1I 2nIsVQSn0S964C2rSuOk2b46vD7+kCoWmoSfaBInoDgiuVFQXxrT1sb2sunZ0pO+9mSkICsgORNO F1HSMObih7H6MSeNsqCQvqIwL7UcNE+Pys9JLYev0+PXcxKrMeOMoPFCgSSR2OwI7pxMeFR0cTh1 b54qQQgzJdK5ZyqgHIvMLxOMNMpVohH5Fw4WvUyYaGGAyKiU6Vvmf9C5TGlz3XXL/5jvZjDdfmq+ acyZTlFe94pEKrIP9XlHvuQdrfNPB/DxDLb4Ldi7n3JNn7JnGn3l5l4cJeFDE8/+BXbyy1Uzt+jK Bxhy66mb/b99Q+vpu/q18VRh+optXuablaG24ujj415y+nGmVvpWS/+WZfCW5CDOTeIcZuIMpdFs iw8PZG6WVHZHyhLiUFGYtlU62R4tpyKgPXq9zST07rF92xUTfWadsDLA7k8+nU02E7Sa1+3G8TWS txGkKJV2EInqQpooNYKMExnp7SI1QGr1eVWTECqVU4HLaL6zR9wr6j9Jk9HvNBW7omI7zQV+0ckP v7H+GVMFcen9y0x2eHZ/wSRHFCVNbmx7t4T/r8+b3FR3dvjsBmsl9gtithsN7nMRW7dgnrP91Hsh jFsh0q9J6HtjE+Z73ez7FObMkLJvGci4eI5Nz35p/HZ+eHXSbKHV7WkUbsPlTv52hHuou81mP10s j3HkspaOyF2+fuRm50FTR7MIuruSbO7V5iz4wyeVJ43Tw5uz6w7NPSlNhaNVdntxZ6oWoZElF8xJ zXLdaF/r1ThtnjW0Gm1Nepu9OPS37rr9VXrjyII0/5xsWcUqo1fvtoMymYKAVgAbWMLYuRXhEjZw d/uROCMKhokKG0IniOJsCunEe3My07bIp2TGsWp2vILnh5861+dX2GyhcnGnmiA+ffrEwzk53+nC ClFROkygsag+//4Z7QsOv8JlgXC/Kv4rimtRMbQbUSDsSz1yendtcr+HRDCME4JrpyujGIKgwMkd 4PEiCw/n+0MZ2QuTfOl6Y1bSKwcOGknICOaFQIGReFwc+34Hhr+s9O1ZhEv4IqPdqEcpMLqBZTNR 8sfTb4GldwsQrMAPcAOXdzAJxn8Yj5S0gKuUKA7OChm4IsXdTAxMhWLImR4DWafIE9j1mtVOoTcO jYQWTXjl3LpaoXLaCzwSGUl3pKR6wYSgRgkaQabYj7CbH6itp4gGt24vnlOhIBPZeHR709ho+ypr 32YAC9lZiW+C/jgLh2fBmbhzN5hm4U697GY4xr3f9bOwH1w/UzBHsLaWyQ62KB22kJxBEvVCbxKn EAVSJ7qYjpIeJCh8skBCm5MsmnTO5AxCA92S0T4Yc5a/OKqipE8haGU34CSa38kpg0YlVOnFjsqD gVWr4PjU+PEjQQr7GjKTdTw/d8PsYik6M/WH2dzUFN0y7VOR9ftTS+8hRZthbAPD7NZpycCUGaZs YJjVOq0YmCrDVA0MsxunNQPDzNxp3cAwY3S6o2OsIq9p0UCJRrAyxy2jfSzePpadmchoOos3nVXK TGS0qsVb1SpnJjIa3OINblUyExmysLgsrGpmIkNMFheTVctMZEjQ4hK06pmJDOFaXLjWTmYiQ+42 l7tdzBauoRI2Vwk7UyVahkrYostkqkTLUAmbq4SdqRItQyVsrhJ2pkq0MjGndqZKtCrZiTJVolXN TpSpEq1adqJMlWjVsxNlqkQrE3NaKmYLt5idao5KWNmpsnUi24KclrKVItuEnJaytSLbhpyWstWC GRFlUwCmubg57xT56AYHHeUMAGlJSEtH2hLS1pElCVnSkWUJWdaRFQlZ0ZFVCVnVkTUJWdORdQlZ 15E7EnJHHWUBvSGhD/t9PfWmhG5PuyTWo9OsSzTnUzzJnvgznWZbojnx7r2+q1NsyRT0bKFOQmc1 nETMaiQKOiWjFOS0lFlheeqDqfTZDyfhMyBMok+CBElRkKjTEkFQEQTGlEjQ1JMqZc2MkGgYY4Ik srFENvPmSUlO+nRJZLSjZqQzJehqgi5r8pQUlsyhtFyqSRNK0x11W9xXdpXbJu2lNGoKb7dzAzek N4yPRyg7oqRFZkhQhUUfjJgGmkYdDYi0KAQie9+kyqQArELqtHwOwi7AGWoD9FoFlQpwYNoA/ayC ygU4HW2AflJBlQIchTZA/6WCqgU492yA3qigWgEOORug/1ZB9QKcaDZAb1XQTgGOLxugdQVk4SZf 2zFBORWEm3utaILyKggaetMEdVQQNPS+CdpQQeVCVhhqPq5SMKNTFCrFz7qx080rBCCLL2sG6O8q CGTxYIJ+VUEgC9cENVQQyCI0QS0FZIMsYhN0rYJAFjMT9JsKAllMTdCNCgJZeCaoqYKgH4xN0KUK qpBXFxmgKxUEDf27CfqqgqChP5ug7yqoXkgNIs5B7BSywhJzcaUiedWWATpUQRZ5+5gBaqsgEEPf BJ2oIBDDwASdqiAQw60Jeq+CQAxDE/RBBYEY/mmC/o8KqpFXdRmgX1QQdAHfBJ2pIOgCeyZoVwHB Hatrf6yZsFUVBC39f03Qv1SQnRHVmoeBdv/jjzUD9k0FQcP/aYL+oYKg4R9N0CcVBA3fM0HHKqhG 3tBmgD6qIGj4rgk6UkHQ8IEJulBAFWj3kQk6V0HQ7gUT9E4FgdJvmaADFQQNvW2C/qaCyhnRyHmY SiHb+16ErRbSYoPZcBALWlsEqmdboLm4HTPilwDluRaqFs0QoAAqM0lUtcyYoAAqMShUtc0goQAq kSdULZlRQwFU4k2oWjbDiAKoRJlQtWLGFQVQiS2hatUMNAqgElFC1ZoZeRRAJYyEqvWUUKSA2mpz U8kosffFqBoVUvqy1yKslbZkxcHa3BjVbHOhigO1qTKqlTIWmThGTJ85uKw6Z2RSZOcNkqypM6pV 0pbYOFgLH6BaNaW4ct4gMWILqFZLXZTjcC3agGr1lIKqeYMkJWKAajspq2kcqsVZUL2Yth7IwVrg BdWtzJU8jtPCMahup6+jcYQWFUJ1KmgjssARqYEJVC9rsz8TUFkIqC4E1FKWAQTUVutdT4n+C6gS lkX1nQwHMxOxUyxkrXfNxwkhGfGf+Thb1ccg6oX5eQQTg6BUSFviyoaXU41MFriSYmTSgdUsEzMH U0s1ElngenpXz4Sn9tdUqFVM7a6Z4OzuOh+X0WcpQpayE8VuXqEomYaraj2ZpDxn/KFYKYPIuXdD NX0lpQj7ySQp1r5aejJJLYWk/GSSumqLJAAHwT3leniuNw1Dl24hgrfDzo26resxt3301ozE/V78 vCdtHfKC+NXGxAkjl19h7nuBm6PborrTAd1ZK7LmL0PvDY8KCLbR43Lh6wiO664ggW0r2HZyPE3e lAqnkHERKdtVv0i7p2B/AjDriguA6Vvh+E56L5hMY3jF1MiJpdffrv5EL51DXTghjRA9qQynZkKf P21tbSXZr0ppESoWLXhvZtRDqV+Q8lJPYeMfEH+Er9dr9EK+Cf+SU9AdaezldpgBn9aPH97+Ahe4 x2FvGOYmBXqvNWuPh6Hnu7kv6ABN6AWp5DVMufXNzS/wisMV9VSn3HJJk5Ib6wWCXbkik65dru2J bYd6Phwpx5ZxJZJL/nglCKsoJ1icEAYnGxsSHxEkG0AlV9/0V6W7AOEgqqVsPBc3Fn9Xsn+dmr9g i8j+KRyBTu7T+AJu3/XcZMMizIAQOMTOcxrKIcjQjWGZhFwAANKboA1yoF+79BgaimwwlSjh4LxR GSpNoguCPX6zLX9dieiCR9B8vTdb67CFT8iqgNVoE+GmFecRoLt9kVuHdoL/sc3DbFD7h5qHqV1R u3admMtkb6V6pCMOs+0cRkrvu1FsHcXKV4Vgo/h7shf0c9pWUg7wlFuQXkA+YuyAoxV5mgW/IhR4 3YcgUHI/qGhvMlZAe48HiPwmy1NvevSqz4jdEgpJyNWmketgA9cR9RE3dGaqg2Cs+Ax2QAcmgpNk AOLFK2zB7Rnw6sKcR0rVttV6n7cYS+QO8j3kbWwkjJAbrQ16ApDe+gPv9cmg0t5qsIJVJvYC+kJr YT/xIIEtHLymICMXqK30eqCkETPqArmv6G/rlW5PVTpHsq9Z6iEpfsmrjR7Z0i9cEfaaFLkXDDz5 dR2pzo19F6kvACM7wdcHExU6pwdxFDadc7HtjN4HrlEw1l6yFUxHGkS5JZ3cKgEsDsYTN8hBPbEy hqvyDYyDCdcJKqYBU+Io7rthCK/oxkmRS99LzN4gQRoMhES6E8GljpCDWzeOzO4woK+nScqkdSPm dIW+FWDAVfCnNTjgJQBrfwQqQCgpM21CT8md/YZvScp/m3iUVCAye/AIirjCXqlMZKIStOX3btA2 1tqMFEwbBjlUduhNf4s0Hq2sapF4E64kV9esyHcYA7PkghrM3f6bCL7b4qUlRmUYk5KvBPYseZ83 Zoo4Jw6eH9JxWDkGs4K1KpEFUTHhEdEOQnsDu7qGtQzrJOs0xTqy83nFXNBEstRNVaM50tbYYu+4 XlGVLLEL6p3PnCnc2SlX8CzE9hLMsZyX5A66H7Q6FghtVFLG76T8TWhNzAQelIuft6RbsqXOm00v zKjkClDJE4ZIme15ZVpPLNOaU2ZbO2OJS4/pG7L5+6hD4eRJ2lTMsDXYwLFTTbx9TQsjvT1vSZkL oUNl8vmkpgyutAdx9nW8qL8+FRj0/HHkYiOqXR9I0hMbTC2nYm+57YMW0NMn6ihTwc1ABKoVw4Ye om3EPTTfB/bcgY6kHEx9f+LEw99h2Ls4PG908CD1WXH/IG/znYLMQ2AjD7sZTH5rIDugpZ8BW6HZ afBkaihknxllWDEjElwoK5KDPfccmeJ4aE4Pq5J0KE12dhayp7+ShrUgDGrgM2+n+ZVcCkLFE8Dq m2gbHEwaCYEb6/khNWm0lu1kulfEM0y7VX9BSl7Id6V/ZFhXo+PTTJntoO+sEiYgYxaeLd+0ORTp HfpbCJJZjfpSVY9lwvq45Ibrssx2xOXXGpjU+4r/gLUPwjS4nGAce6OJT8237tJ8XyZbVh+RtzBI RhrZ8n9Pe/VX8uJf5Ril9BahVxv96WiSZnCyjIvZ0FmKIiSv3QbLwpGksF2mI6aYwHxnC4fn9aaf vKuB+FeUXrkMlHBXSLJM/C2tFP1tS0TlRo4XED1zwtsej2Cu44f7vHYOlFm85KDpPK+evBML54gO uGfGkkPOv1uf1a7Cqwujg+HEz3uZJKGRnF2j30ISHiBO77ZW6qWMptpoCqPfOzj/PUR0xc+4N1gs Be7zN3/IL+ZYkO3az2t6hrBPMzMr1eKY54D/HTcBDJ9/nn74sjcBDP+6mwDSrjmrb9XK1Uq5mnoT gFXmFwGI5lOvN6N9r/NBP/YNEKq+FNzPdTq9iT+N4B/ux7jhXCz61eNV4tIwtaULCAv9sT1KOWds 2ptXtnQBF/3G1eNc/7janbj3Xs+NtmM3isHj2Y6jmMLa5Nh5GzsgW73JZBkpLpvXUxVx2XyxmhR3 Ni1706ohu7Rr17Cm/KhGPqFMqppWFVk7u+XKbiX9Br5S0SrsoA34sixQT8SkScad4w+N4186543z o0arc3jWfH9x3ri4zl01r9s0kAxf+KkZfimgOlaUeanabug5PkvI3wRDkzHTPC/1x/eH7evD60YB 4fouLiwhh7D3U+iBwdY/zt3ROJy1cJfnHC5ulo/n55i31Aoi436Mj83WdfNyfn5Xx03GVC+i+fw/ Nw5ljAqnAAA= ------=_NextPart_000_0034_01CA9F89.A42D0430-- From owner-freebsd-stable@FreeBSD.ORG Wed Jan 27 11:25:50 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 810B0106566B for ; Wed, 27 Jan 2010 11:25:50 +0000 (UTC) (envelope-from dimitry@andric.com) Received: from tensor.andric.com (cl-327.ede-01.nl.sixxs.net [IPv6:2001:7b8:2ff:146::2]) by mx1.freebsd.org (Postfix) with ESMTP id 46F208FC22 for ; Wed, 27 Jan 2010 11:25:50 +0000 (UTC) Received: from [IPv6:2001:7b8:3a7:0:481c:61a7:de40:51a1] (unknown [IPv6:2001:7b8:3a7:0:481c:61a7:de40:51a1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id 760FA5C43; Wed, 27 Jan 2010 12:25:49 +0100 (CET) Message-ID: <4B6022C6.1090608@andric.com> Date: Wed, 27 Jan 2010 12:25:58 +0100 From: Dimitry Andric User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.2; en-US; rv:1.9.2pre) Gecko/20100126 Lanikai/3.1b1pre MIME-Version: 1.0 To: Dan Naumov References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: FreeBSD-STABLE Mailing List Subject: Re: immense delayed write to file system (ZFS and UFS2), performance issues X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jan 2010 11:25:50 -0000 On 2010-01-27 00:15, Dan Naumov wrote: > Can anyone confirm that using the WDIDLE3 utility on the 2TB WD20EADS > discs will not cause any issues if these disks are part of a ZFS > mirror pool? I do have backups of data, but I would rather not spend > the time rebuilding the entire system and restoring enormous amounts > of data over a 100mbit network unless I absolutely have to :) Sorry to bump into this thread so late, but for some of my servers I have been using a patch for atacontrol, to turn the APM features of the disk(s) off, for a long time. This is mostly noticable with 2.5" notebook disks, which "click" like crazy all the time. :) E.g. if you run "atacontrol cap $device", and you see in the output that "advanced power management" is supported, you might be able to stop the disk from spinning down by turning the APM feature off. Patch is at . This should apply to 8-STABLE, no idea about older branches. From owner-freebsd-stable@FreeBSD.ORG Wed Jan 27 11:52:34 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5EDE2106566B; Wed, 27 Jan 2010 11:52:34 +0000 (UTC) (envelope-from marius@alchemy.franken.de) Received: from alchemy.franken.de (alchemy.franken.de [194.94.249.214]) by mx1.freebsd.org (Postfix) with ESMTP id D8F718FC1C; Wed, 27 Jan 2010 11:52:33 +0000 (UTC) Received: from alchemy.franken.de (localhost [127.0.0.1]) by alchemy.franken.de (8.14.3/8.14.3/ALCHEMY.FRANKEN.DE) with ESMTP id o0RBqUqk050762; Wed, 27 Jan 2010 12:52:30 +0100 (CET) (envelope-from marius@alchemy.franken.de) Received: (from marius@localhost) by alchemy.franken.de (8.14.3/8.14.3/Submit) id o0RBqUxJ050761; Wed, 27 Jan 2010 12:52:30 +0100 (CET) (envelope-from marius) Date: Wed, 27 Jan 2010 12:52:29 +0100 From: Marius Strobl To: Peter Jeremy Message-ID: <20100127115229.GD40779@alchemy.franken.de> References: <20100126073336.GA1955@server.vk2pj.dyndns.org> <201001260946.44977.jhb@freebsd.org> <20100126183756.GA40779@alchemy.franken.de> <201001261510.59667.jhb@freebsd.org> <20100127063649.GA1889@server.vk2pj.dyndns.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20100127063649.GA1889@server.vk2pj.dyndns.org> User-Agent: Mutt/1.4.2.3i Cc: rmacklem@freebsd.org, dfr@freebsd.org, freebsd-stable@freebsd.org, John Baldwin Subject: Re: uma_zalloc_arg complaining about non-sleepable locks X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jan 2010 11:52:34 -0000 On Wed, Jan 27, 2010 at 05:36:49PM +1100, Peter Jeremy wrote: > On 2010-Jan-26 15:10:59 -0500, John Baldwin wrote: > >On Tuesday 26 January 2010 1:37:56 pm Marius Strobl wrote: > >> On Tue, Jan 26, 2010 at 09:46:44AM -0500, John Baldwin wrote: > >> > On Tuesday 26 January 2010 2:33:37 am Peter Jeremy wrote: > >> > > I have just upgraded to 8-STABLE/amd64 from about 18 hours ago and am > >> > > now getting regular (the following pair of messages about every > >> > > minute) compaints as follows: > >> > > > >> > > kernel: uma_zalloc_arg: zone "mbuf" with the following non-sleepable locks held: > >> > > kernel: exclusive sleep mutex sp_lock (sp_lock) r = 0 (0xffffff000460bb00) locked @ /usr/src/sys/rpc/svc.c:1098 > ... > >> Could you please give the following patch a try? > >> http://people.freebsd.org/~marius/fha_extract_info_realign2.diff > > That seems to have fixed it - I've booted the new kernel and generated > some NFS activity and am not getting any messages. Also, > vfs.nfs.realign_test is incrementing nicely though > vfs.nfs.realign_count remains at zero. > Ah, I forgot that using nfsm_aligned() causes nfs_realign() to be a NOP on architectures without strict alignment requirements for performance reasons. That's generally fine but unfortunately that way you don't actually exercise the code which caused the problem before (unfortunately I still don't manage to hit the unaligned case myself). Could you please test with #ifdef __NO_STRICT_ALIGNMENT replaced with #if 0 in sys/nfs/nfs_common.h? The vfs.nfs.realign_count counter should also increase then. Marius From owner-freebsd-stable@FreeBSD.ORG Wed Jan 27 13:30:24 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 05C79106566C; Wed, 27 Jan 2010 13:30:24 +0000 (UTC) (envelope-from doconnor@gsoft.com.au) Received: from cain.gsoft.com.au (cain.gsoft.com.au [203.31.81.10]) by mx1.freebsd.org (Postfix) with ESMTP id 515098FC08; Wed, 27 Jan 2010 13:30:22 +0000 (UTC) Received: from inchoate.gsoft.com.au (ppp121-45-156-224.lns6.adl6.internode.on.net [121.45.156.224]) (authenticated bits=0) by cain.gsoft.com.au (8.13.8/8.13.8) with ESMTP id o0RDUJg5069024 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Thu, 28 Jan 2010 00:00:19 +1030 (CST) (envelope-from doconnor@gsoft.com.au) From: "Daniel O'Connor" To: freebsd-stable@freebsd.org Date: Thu, 28 Jan 2010 00:00:05 +1030 User-Agent: KMail/1.9.10 References: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1853852.VSxyxXvjT2"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <201001280000.16773.doconnor@gsoft.com.au> X-Spam-Score: -1.687 () AWL,BAYES_00,RDNS_DYNAMIC X-Scanned-By: MIMEDefang 2.63 on 203.31.81.10 Cc: Daisuke Aoyama , freebsd-current@freebsd.org, freebsd-emulation@freebsd.org Subject: Re: [PATCH] VirtualBox headless VNC support by LibVNCServer X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 27 Jan 2010 13:30:24 -0000 --nextPart1853852.VSxyxXvjT2 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Wed, 27 Jan 2010, Daisuke Aoyama wrote: > > I updated for 3.1.2_1 and fixed bug of initial pixel format. > > > > Before building, install "ports/net/libvncserver". > > I recommend you backup virtualbox-ose directory before doing. > > Uncheck QT4, X11, NLS by make config before extracting. > > > > Howto apply the patch: > > # cd /usr/ports/emulators/virtualbox-ose > > # make config > > # make extract > > # patch -p < /path/to/VBox-VNC-Makefile.patch > > # patch -p < /path/to/VBox-VNC-20100127.patch > > # make I put VBox-VNC-20100127.patch in files an modified the paths to be=20 acceptable to the ports tree and applied the Makefile patch and it=20 works well. (I say this as IMO it's easier to try if you distribute it=20 like that :) Is there any prospect of being able to build the VNC server extension in=20 parallel with X11/QT4? =2D-=20 Daniel O'Con Thanks. nor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C --nextPart1853852.VSxyxXvjT2 Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.12 (FreeBSD) iD8DBQBLYD/o5ZPcIHs/zowRAgvLAKCZG1P5JaGpwWdbuPmvWB4JNUQKaACfZXK/ qcU6PmJURadcX64NqmtC8A4= =9ZJB -----END PGP SIGNATURE----- --nextPart1853852.VSxyxXvjT2-- From owner-freebsd-stable@FreeBSD.ORG Wed Jan 27 16:45:39 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 09C1B106566B; Wed, 27 Jan 2010 16:45:39 +0000 (UTC) (envelope-from dan.naumov@gmail.com) Received: from mail-yw0-f194.google.com (mail-yw0-f194.google.com [209.85.211.194]) by mx1.freebsd.org (Postfix) with ESMTP id AE21B8FC13; Wed, 27 Jan 2010 16:45:38 +0000 (UTC) Received: by ywh32 with SMTP id 32so2399957ywh.14 for ; Wed, 27 Jan 2010 08:45:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:content-type; bh=4ylXmzQtKvCtjOic3arwQsi5yaq6oKM5lwBEaOQWa6s=; b=YKPAoEnu++QiW4fZGPlqnkKYQTB8vdKac7tA/Zqeghbp/AbzKO84+ngzbTNC8OpzLB yKZj8wX0r7z1eXnauXrRW7AG8kYa9EUCyq+f+ZaNCIwiM2El9iLQnIA8ED6Z09B9bwKs 7rNsFKXdDZEmRELerbl6sVLew2CLn/Zy3wsmQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=AMUp6aNuHz92mR4+SlHP4dNOUQM6dhb8rC8h9igCrHEKlacjwDH4SPc4eXxJniwM1f iDqzP7xH1Cae23tVMyJ4n6/YBv+x1JQoqQ+zNXrUuUKkwSGYSDW4lvI1uEnGWeSporo+ 4eo1HKwU6WxKGiIA5xNRhSuUloezgNzknhUhQ= MIME-Version: 1.0 Received: by 10.101.93.10 with SMTP id v10mr831527anl.185.1264610736650; Wed, 27 Jan 2010 08:45:36 -0800 (PST) Date: Wed, 27 Jan 2010 18:45:36 +0200 Message-ID: From: Dan Naumov To: freebsd-questions@freebsd.org, FreeBSD-STABLE Mailing List Content-Type: text/plain; charset=ISO-8859-1 Cc: Subject: booting off GPT partitions X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 27 Jan 2010 16:45:39 -0000 Hey I was under the impression that everyone and their dog is using GPT partitioning in FreeBSD these days, including for boot drives and that I was just being unlucky with my current NAS motherboard (Intel D945GCLF2) having supposedly shaky support for GPT boot. But right now I am having an email exchange with Supermicro support (whom I contacted since I am pondering their X7SPA-H board for a new system), who are telling me that booting off GPT requires UEFI BIOS, which is supposedly a very new thing and that for example NONE of their current motherboards have support for this. Am I misunderstanding something or is the Supermicro support tech misguided? - Sincerely, Dan Naumov From owner-freebsd-stable@FreeBSD.ORG Wed Jan 27 16:52:00 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8033C1065679 for ; Wed, 27 Jan 2010 16:52:00 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from qmta11.emeryville.ca.mail.comcast.net (qmta11.emeryville.ca.mail.comcast.net [76.96.27.211]) by mx1.freebsd.org (Postfix) with ESMTP id 6703D8FC08 for ; Wed, 27 Jan 2010 16:52:00 +0000 (UTC) Received: from omta22.emeryville.ca.mail.comcast.net ([76.96.30.89]) by qmta11.emeryville.ca.mail.comcast.net with comcast id agdN1d00F1vN32cABgqfzx; Wed, 27 Jan 2010 16:50:39 +0000 Received: from koitsu.dyndns.org ([98.248.46.159]) by omta22.emeryville.ca.mail.comcast.net with comcast id agt11d00S3S48mS8igt2NE; Wed, 27 Jan 2010 16:53:02 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id C9BB51E3033; Wed, 27 Jan 2010 08:51:58 -0800 (PST) Date: Wed, 27 Jan 2010 08:51:58 -0800 From: Jeremy Chadwick To: Dan Naumov Message-ID: <20100127165158.GA84643@icarus.home.lan> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) Cc: FreeBSD-STABLE Mailing List , freebsd-questions@freebsd.org Subject: Re: booting off GPT partitions X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 27 Jan 2010 16:52:00 -0000 On Wed, Jan 27, 2010 at 06:45:36PM +0200, Dan Naumov wrote: > I was under the impression that everyone and their dog is using GPT > partitioning in FreeBSD these days, including for boot drives and that > I was just being unlucky with my current NAS motherboard (Intel > D945GCLF2) having supposedly shaky support for GPT boot. But right now > I am having an email exchange with Supermicro support (whom I > contacted since I am pondering their X7SPA-H board for a new system), > who are telling me that booting off GPT requires UEFI BIOS, which is > supposedly a very new thing and that for example NONE of their current > motherboards have support for this. > > Am I misunderstanding something or is the Supermicro support tech misguided? For what it's worth, I've never encountered any production x86 system that I've worked on (Linux, FreeBSD, Solaris 10, or OpenSolaris) which has used GPT. I don't know who's giving you the impression that "everyone and their dog is using GPT". Why is this feature a deal-breaker for you? Why are you giving it so much attention? -- | Jeremy Chadwick jdc@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Wed Jan 27 16:56:45 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EA58310656AA for ; Wed, 27 Jan 2010 16:56:45 +0000 (UTC) (envelope-from roberto@keltia.net) Received: from keltia.freenix.fr (cl-180.mrs-01.fr.sixxs.net [IPv6:2a01:240:fe00:b3::2]) by mx1.freebsd.org (Postfix) with ESMTP id 958E38FC1B for ; Wed, 27 Jan 2010 16:56:45 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by keltia.freenix.fr (Postfix/TLS) with ESMTP id 8385D3919E for ; Wed, 27 Jan 2010 17:56:43 +0100 (CET) X-Virus-Scanned: amavisd-new at keltia.freenix.fr Received: from keltia.freenix.fr ([127.0.0.1]) by localhost (keltia.freenix.fr [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iRHn2yhQ5u-N for ; Wed, 27 Jan 2010 17:56:43 +0100 (CET) Received: from roberto-al.eurocontrol.fr (aran.keltia.net [88.191.250.24]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: roberto) by keltia.freenix.fr (Postfix/TLS) with ESMTPSA id 10CD93918C for ; Wed, 27 Jan 2010 17:56:43 +0100 (CET) Date: Wed, 27 Jan 2010 17:56:41 +0100 From: Ollivier Robert To: freebsd-stable@freebsd.org Message-ID: <20100127165641.GD89897@roberto-al.eurocontrol.fr> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Operating-System: MacOS X / Macbook Pro - FreeBSD 7.2 / Dell D820 SMP User-Agent: Mutt/1.5.20 (2009-06-14) Subject: Re: booting off GPT partitions X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 27 Jan 2010 16:56:46 -0000 According to Dan Naumov: > who are telling me that booting off GPT requires UEFI BIOS, which is > supposedly a very new thing and that for example NONE of their current > motherboards have support for this. The Dell T3500 I just configured was announced in March 2009 IIRC and it is booting off GPT just fine. Didn't do anything special for that. Then again, I do not see non GPT support as a deal breaker (even for ZFS). -- Ollivier ROBERT -=- FreeBSD: The Power to Serve! -=- roberto@keltia.freenix.fr In memoriam to Ondine : http://ondine.keltia.net/ From owner-freebsd-stable@FreeBSD.ORG Wed Jan 27 17:09:49 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5BCA0106568B; Wed, 27 Jan 2010 17:09:49 +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 82EB88FC24; Wed, 27 Jan 2010 17:09:48 +0000 (UTC) Received: from vhoffman.lon.namesco.net (43.78-246-213.ippool.namesco.net [213.246.78.43]) (authenticated bits=0) by unsane.co.uk (8.14.3/8.14.3) with ESMTP id o0RH9iWs052108 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 27 Jan 2010 17:09:46 GMT (envelope-from vince@unsane.co.uk) Message-ID: <4B607357.7050707@unsane.co.uk> Date: Wed, 27 Jan 2010 17:09:43 +0000 From: Vincent Hoffman User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: Dan Naumov References: In-Reply-To: X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: FreeBSD-STABLE Mailing List , freebsd-questions@freebsd.org Subject: Re: booting off GPT partitions X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 27 Jan 2010 17:09:49 -0000 GPT booting is I believe only natively supported using an EFI BIOS. However if you wish to use GPT booting with FreeBSD its not too hard, you just cant install using sysinstall. The Examples section of the gpart manpage is what i used to configure the disk for my home server, a zotac ion atom based board (dont have any production servers at work using it at the moment.) Then i just installed using the files on the usb image. >From what I understand gpart installs the pmbr file as a basic bootstrap in the protective MBR present in the GPT partition scheme, this is bootable by a standard bios and is able to understand enough GPT to look for a freebsd boot partition, load the bootcode in that, which loads the kernel etc. So no they arent completely misguided, but its certainly possible to use a GPT scheme without an EFI BIOS. What I would like is an efi bootloader for i386 so I can get my powerbook to run FreeBSD again as it has got an efi bios and bootcamp wont boot freebsd for me at the moment :( Vince Dan Naumov wrote: > Hey > > I was under the impression that everyone and their dog is using GPT > partitioning in FreeBSD these days, including for boot drives and that > I was just being unlucky with my current NAS motherboard (Intel > D945GCLF2) having supposedly shaky support for GPT boot. But right now > I am having an email exchange with Supermicro support (whom I > contacted since I am pondering their X7SPA-H board for a new system), > who are telling me that booting off GPT requires UEFI BIOS, which is > supposedly a very new thing and that for example NONE of their current > motherboards have support for this. > > Am I misunderstanding something or is the Supermicro support tech misguided? > > > - Sincerely, > Dan Naumov > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" > From owner-freebsd-stable@FreeBSD.ORG Wed Jan 27 17:11:08 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4C3231065676 for ; Wed, 27 Jan 2010 17:11:08 +0000 (UTC) (envelope-from brooks@lor.one-eyed-alien.net) Received: from lor.one-eyed-alien.net (lor.one-eyed-alien.net [69.66.77.232]) by mx1.freebsd.org (Postfix) with ESMTP id 050D98FC13 for ; Wed, 27 Jan 2010 17:11:07 +0000 (UTC) Received: from lor.one-eyed-alien.net (localhost [127.0.0.1]) by lor.one-eyed-alien.net (8.14.3/8.14.3) with ESMTP id o0RHAIYM040156; Wed, 27 Jan 2010 11:10:18 -0600 (CST) (envelope-from brooks@lor.one-eyed-alien.net) Received: (from brooks@localhost) by lor.one-eyed-alien.net (8.14.3/8.14.3/Submit) id o0RHAIk0040155; Wed, 27 Jan 2010 11:10:18 -0600 (CST) (envelope-from brooks) Date: Wed, 27 Jan 2010 11:10:18 -0600 From: Brooks Davis To: Dan Naumov Message-ID: <20100127171017.GA40068@lor.one-eyed-alien.net> References: MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="opJtzjQTFsWo+cga" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.17 (2007-11-01) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0 (lor.one-eyed-alien.net [127.0.0.1]); Wed, 27 Jan 2010 11:10:18 -0600 (CST) Cc: FreeBSD-STABLE Mailing List , freebsd-questions@freebsd.org Subject: Re: booting off GPT partitions X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 27 Jan 2010 17:11:08 -0000 --opJtzjQTFsWo+cga Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Jan 27, 2010 at 06:45:36PM +0200, Dan Naumov wrote: > Hey >=20 > I was under the impression that everyone and their dog is using GPT > partitioning in FreeBSD these days, including for boot drives and that > I was just being unlucky with my current NAS motherboard (Intel > D945GCLF2) having supposedly shaky support for GPT boot. But right now > I am having an email exchange with Supermicro support (whom I > contacted since I am pondering their X7SPA-H board for a new system), > who are telling me that booting off GPT requires UEFI BIOS, which is > supposedly a very new thing and that for example NONE of their current > motherboards have support for this. >=20 > Am I misunderstanding something or is the Supermicro support tech misguid= ed? The compatability MBR should be sufficent to let a non-GPT aware BIOS boot from GPT. Once you've loaded code from the boot partition, the BIOS doesn't need to know anything about the partitions. -- Brooks --opJtzjQTFsWo+cga Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (FreeBSD) iD8DBQFLYHN5XY6L6fI4GtQRAk6uAKCDz8HRDrS/Cjibj8Pqg7/OziXrFQCdGKAr gRQvLCMrggm9C1qKuyi727E= =ZIxv -----END PGP SIGNATURE----- --opJtzjQTFsWo+cga-- From owner-freebsd-stable@FreeBSD.ORG Wed Jan 27 17:18:07 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1132D106566C; Wed, 27 Jan 2010 17:18:07 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 212478FC17; Wed, 27 Jan 2010 17:18:05 +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 TAA01021; Wed, 27 Jan 2010 19:18:00 +0200 (EET) (envelope-from avg@icyb.net.ua) Message-ID: <4B607547.8000307@icyb.net.ua> Date: Wed, 27 Jan 2010 19:17:59 +0200 From: Andriy Gapon User-Agent: Thunderbird 2.0.0.23 (X11/20091206) MIME-Version: 1.0 To: Dan Naumov References: In-Reply-To: X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: FreeBSD-STABLE Mailing List , freebsd-questions@freebsd.org Subject: Re: booting off GPT partitions X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 27 Jan 2010 17:18:07 -0000 on 27/01/2010 18:45 Dan Naumov said the following: > Hey > > I was under the impression that everyone and their dog is using GPT > partitioning in FreeBSD these days, including for boot drives and that > I was just being unlucky with my current NAS motherboard (Intel > D945GCLF2) having supposedly shaky support for GPT boot. But right now > I am having an email exchange with Supermicro support (whom I > contacted since I am pondering their X7SPA-H board for a new system), > who are telling me that booting off GPT requires UEFI BIOS, which is > supposedly a very new thing and that for example NONE of their current > motherboards have support for this. > > Am I misunderstanding something or is the Supermicro support tech misguided? Perhaps both :-) It depends on what booting capabilities you need from your BIOS. With FreeBSD we currently typically don't use "pure" GPT and use Protective MBR and install real boot code into a special boot partition. Protective MBR looks like a "normal" MBR to BIOS, and boot code in Protective MBR is smart to find the boot partition and hand off boot process to code in it. This way you can almost have the best of both worlds, but with some limitations (like multibooting). I don't know what other OSes do or expect in this area. Obligatory wikipedia link: http://en.wikipedia.org/wiki/GUID_Partition_Table#Legacy_MBR_.28LBA_0.29 -- Andriy Gapon From owner-freebsd-stable@FreeBSD.ORG Wed Jan 27 17:26:37 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 43052106566B for ; Wed, 27 Jan 2010 17:26:37 +0000 (UTC) (envelope-from egypcio@gmail.com) Received: from gv-out-0910.google.com (gv-out-0910.google.com [216.239.58.190]) by mx1.freebsd.org (Postfix) with ESMTP id 03CCD8FC16 for ; Wed, 27 Jan 2010 17:26:35 +0000 (UTC) Received: by gv-out-0910.google.com with SMTP id n29so197913gve.39 for ; Wed, 27 Jan 2010 09:26:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:content-type; bh=yGoUL3rVbVfIfXh6uOXdUJTPiHpWWOIBcrCkpFlvHqk=; b=Tq/qQTourA9z9ptmoesETDiMMQt2+Bmo+xuKFPbHnQQ3IzTA5nsZ5UfWmuffnx2I/Z uGjjaahKff5o5XcOxARLISHwDo0A+KNWP0hL1Fu6yBl2z/DiqThpAUyYLGG5amp1SAf4 Pu12VlcTwpt4oagnSaeiy8/AVUqxLtIu6Yf8A= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=Azmjsk6oSV5/YTWzTHRQ/JZjD3/UVLTCmyCIBx5o17rgKXd3x/k8w1/0YawDcgVsDK Qu6tTFTrLz3y0m589i+YYx4aWlvDkJWmy1wtGr20APVbvotLTEugYKH+Dp3YO59q4L32 e7OrioVbqZm1NCuCUBIKnFnep0lpQyScVYOgo= MIME-Version: 1.0 Received: by 10.239.186.134 with SMTP id g6mr1071644hbh.195.1264613194337; Wed, 27 Jan 2010 09:26:34 -0800 (PST) Date: Wed, 27 Jan 2010 14:26:34 -0300 Message-ID: <8b5ad0e11001270926o19d1701fid30ba5a49cbb39b5@mail.gmail.com> From: =?ISO-8859-1?Q?Zavam=2C_Vin=EDcius?= To: freebsd-stable@freebsd.org Content-Type: multipart/mixed; boundary=001485f453423a15ad047e28b4a4 Subject: freebsd 8.0 stable amd64/x86 needs ~9min to bootup X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jan 2010 17:26:37 -0000 --001485f453423a15ad047e28b4a4 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable noon, all you guys. well, I'm having some issues during the 8.0-stable bootup process. it takes ~9min to finish the entire boot process to shows me the "login:" screen. since my first installation attempt to get freebsd up and running here with my dv3-2155mx[1] hp pavilion laptop using 8.0-RC1 amd64 iso I could not boot freebsd up smooth and nicely as it always did for me in my last laptop (dv6130us)[2], but I could install it without any problem. you may check http://www.youtube.com/watch?v=3Dgqtz7E7u4fA to see what realy happens. now I'm using a grub 0.97 from my old gentoo linux installation to bootstrap the freebsd loader. I tryed debug and verbose options using grub and freebsd loader.conf but both just result nothing special. I've been updated and downgraded my laptop bios (by Insyde Software / HP) but got no good results either. I tryed versions F1.3A, F1.2, F0.7 and the original F0.6 version that came originally from HP. to try another way to get into 8.0-stable or 9-current I used 7.2, 7.1, 6.4 and 6.2 release x86 and amd64 iso images to install freebsd and an it's older btx loader but, unfortunately, got the same. it always "freezes" ~9min. I can use freebsd after all the bootup process with no problem. It's a 8.0-stable amd64 now. but I realy wanna know how could I solve this issue. read some cases/PRs/issues with other hp laptops but nothing like this one I have. one of the problems I read was about dv6000 series - weird, it was my old laptop serie and everything was just fine installing, booting and running freebsd into. what you guys think about it? can you give me a hand or a glue to pass this through? thanks. [1] http://h10025.www1.hp.com/ewfrf/wc/document?docname=3Dc01777298&cc=3Dus= &lc=3Den&dlc=3Den [2] http://h10025.www1.hp.com/ewfrf/wc/document?docname=3Dc00782284&cc=3Dus= &lc=3Den&dlc=3Den --=20 Zavam, Vin=EDcius --001485f453423a15ad047e28b4a4 Content-Type: application/octet-stream; name="80release_dmesg.boot" Content-Disposition: attachment; filename="80release_dmesg.boot" Content-Transfer-Encoding: base64 X-Attachment-Id: f_g4ydywo80 dWhjaTA6IFJlc2VydmVkIDB4MjAgYnl0ZXMgZm9yIHJpZCAweDIwIHR5cGUgNCBhdCAweDUwYzAK aW9hcGljMDogcm91dGluZyBpbnRwaW4gMTYgKFBDSSBJUlEgMTYpIHRvIGxhcGljIDAgdmVjdG9y IDQ5CnVoY2kwOiBbTVBTQUZFXQp1aGNpMDogW0lUSFJFQURdCnVoY2kwOiBMZWdTdXAgPSAweDBm MTAKdXNidXMwOiA8SW50ZWwgODI4MDFJIChJQ0g5KSBVU0IgY29udHJvbGxlcj4gb24gdWhjaTAK dWhjaTE6IDxJbnRlbCA4MjgwMUkgKElDSDkpIFVTQiBjb250cm9sbGVyPiBwb3J0IDB4NTBhMC0w eDUwYmYgaXJxIDE3IGF0IGRldmljZSAyNi4xIG9uIHBjaTAKdWhjaTE6IFJlc2VydmVkIDB4MjAg Ynl0ZXMgZm9yIHJpZCAweDIwIHR5cGUgNCBhdCAweDUwYTAKaW9hcGljMDogcm91dGluZyBpbnRw aW4gMTcgKFBDSSBJUlEgMTcpIHRvIGxhcGljIDAgdmVjdG9yIDUwCnVoY2kxOiBbTVBTQUZFXQp1 aGNpMTogW0lUSFJFQURdCnVoY2kxOiBMZWdTdXAgPSAweDBmMDAKdXNidXMxOiA8SW50ZWwgODI4 MDFJIChJQ0g5KSBVU0IgY29udHJvbGxlcj4gb24gdWhjaTEKZWhjaTA6IDxJbnRlbCA4MjgwMUkg KElDSDkpIFVTQiAyLjAgY29udHJvbGxlcj4gbWVtIDB4ZDg1MDRjMDAtMHhkODUwNGZmZiBpcnEg MTggYXQgZGV2aWNlIDI2Ljcgb24gcGNpMAplaGNpMDogUmVzZXJ2ZWQgMHg0MDAgYnl0ZXMgZm9y IHJpZCAweDEwIHR5cGUgMyBhdCAweGQ4NTA0YzAwCmlvYXBpYzA6IHJvdXRpbmcgaW50cGluIDE4 IChQQ0kgSVJRIDE4KSB0byBsYXBpYyAwIHZlY3RvciA1MQplaGNpMDogW01QU0FGRV0KZWhjaTA6 IFtJVEhSRUFEXQp1c2J1czI6IHdhaXRpbmcgZm9yIEJJT1MgdG8gZ2l2ZSB1cCBjb250cm9sCnVz YnVzMjogRUhDSSB2ZXJzaW9uIDEuMAp1c2J1czI6IDxJbnRlbCA4MjgwMUkgKElDSDkpIFVTQiAy LjAgY29udHJvbGxlcj4gb24gZWhjaTAKcGNpMDogPG11bHRpbWVkaWEsIEhEQT4gYXQgZGV2aWNl IDI3LjAgKG5vIGRyaXZlciBhdHRhY2hlZCkKcGNpYjE6IDxBQ1BJIFBDSS1QQ0kgYnJpZGdlPiBh dCBkZXZpY2UgMjguMCBvbiBwY2kwCnBjaWIxOiAgIGRvbWFpbiAgICAgICAgICAgIDAKcGNpYjE6 ICAgc2Vjb25kYXJ5IGJ1cyAgICAgMQpwY2liMTogICBzdWJvcmRpbmF0ZSBidXMgICAxCnBjaWIx OiAgIEkvTyBkZWNvZGUgICAgICAgIDB4NDAwMC0weDRmZmYKcGNpYjE6ICAgbWVtb3J5IGRlY29k ZSAgICAgMHhkNzUwMDAwMC0weGQ4NGZmZmZmCnBjaWIxOiAgIHByZWZldGNoZWQgZGVjb2RlIDB4 ZDA0MDAwMDAtMHhkMTNmZmZmZgpwY2kxOiA8QUNQSSBQQ0kgYnVzPiBvbiBwY2liMQpwY2kxOiBk b21haW49MCwgcGh5c2ljYWwgYnVzPTEKcGNpYjI6IDxBQ1BJIFBDSS1QQ0kgYnJpZGdlPiBhdCBk ZXZpY2UgMjguMiBvbiBwY2kwCnBjaWIyOiAgIGRvbWFpbiAgICAgICAgICAgIDAKcGNpYjI6ICAg c2Vjb25kYXJ5IGJ1cyAgICAgMgpwY2liMjogICBzdWJvcmRpbmF0ZSBidXMgICAyCnBjaWIyOiAg IEkvTyBkZWNvZGUgICAgICAgIDB4MzAwMC0weDNmZmYKcGNpYjI6ICAgbWVtb3J5IGRlY29kZSAg ICAgMHhkNjUwMDAwMC0weGQ3NGZmZmZmCnBjaWIyOiAgIHByZWZldGNoZWQgZGVjb2RlIDB4ZDE0 MDAwMDAtMHhkMjNmZmZmZgpwY2kyOiA8QUNQSSBQQ0kgYnVzPiBvbiBwY2liMgpwY2kyOiBkb21h aW49MCwgcGh5c2ljYWwgYnVzPTIKZm91bmQtPgl2ZW5kb3I9MHgxNjhjLCBkZXY9MHgwMDJiLCBy ZXZpZD0weDAxCglkb21haW49MCwgYnVzPTIsIHNsb3Q9MCwgZnVuYz0wCgljbGFzcz0wMi04MC0w MCwgaGRydHlwZT0weDAwLCBtZmRldj0wCgljbWRyZWc9MHgwMDA3LCBzdGF0cmVnPTB4MDAxMCwg Y2FjaGVsbnN6PTAgKGR3b3JkcykKCWxhdHRpbWVyPTB4MDAgKDAgbnMpLCBtaW5nbnQ9MHgwMCAo MCBucyksIG1heGxhdD0weDAwICgwIG5zKQoJaW50cGluPWEsIGlycT0xMQoJcG93ZXJzcGVjIDMg IHN1cHBvcnRzIEQwIEQxIEQzICBjdXJyZW50IEQwCglNU0kgc3VwcG9ydHMgMSBtZXNzYWdlCglt YXBbMTBdOiB0eXBlIE1lbW9yeSwgcmFuZ2UgNjQsIGJhc2UgMHhkNjUwMDAwMCwgc2l6ZSAxNiwg ZW5hYmxlZApwY2liMjogcmVxdWVzdGVkIG1lbW9yeSByYW5nZSAweGQ2NTAwMDAwLTB4ZDY1MGZm ZmY6IGdvb2QKcGNpYjI6IG1hdGNoZWQgZW50cnkgZm9yIDIuMC5JTlRBCnBjaWIyOiBzbG90IDAg SU5UQSBoYXJkd2lyZWQgdG8gSVJRIDE4CnBjaTI6IDxuZXR3b3JrPiBhdCBkZXZpY2UgMC4wIChu byBkcml2ZXIgYXR0YWNoZWQpCnBjaWIzOiA8QUNQSSBQQ0ktUENJIGJyaWRnZT4gYXQgZGV2aWNl IDI4LjMgb24gcGNpMApwY2liMzogICBkb21haW4gICAgICAgICAgICAwCnBjaWIzOiAgIHNlY29u ZGFyeSBidXMgICAgIDMKcGNpYjM6ICAgc3Vib3JkaW5hdGUgYnVzICAgMwpwY2liMzogICBJL08g ZGVjb2RlICAgICAgICAweDIwMDAtMHgyZmZmCnBjaWIzOiAgIG1lbW9yeSBkZWNvZGUgICAgIDB4 ZDU1MDAwMDAtMHhkNjRmZmZmZgpwY2liMzogICBwcmVmZXRjaGVkIGRlY29kZSAweGQyNDAwMDAw LTB4ZDMzZmZmZmYKcGNpMzogPEFDUEkgUENJIGJ1cz4gb24gcGNpYjMKcGNpMzogZG9tYWluPTAs IHBoeXNpY2FsIGJ1cz0zCmZvdW5kLT4JdmVuZG9yPTB4MTBlYywgZGV2PTB4ODEzNiwgcmV2aWQ9 MHgwMgoJZG9tYWluPTAsIGJ1cz0zLCBzbG90PTAsIGZ1bmM9MAoJY2xhc3M9MDItMDAtMDAsIGhk cnR5cGU9MHgwMCwgbWZkZXY9MAoJY21kcmVnPTB4MDAwNywgc3RhdHJlZz0weDAwMTAsIGNhY2hl bG5zej0wIChkd29yZHMpCglsYXR0aW1lcj0weDAwICgwIG5zKSwgbWluZ250PTB4MDAgKDAgbnMp LCBtYXhsYXQ9MHgwMCAoMCBucykKCWludHBpbj1hLCBpcnE9MTEKCXBvd2Vyc3BlYyAzICBzdXBw b3J0cyBEMCBEMSBEMiBEMyAgY3VycmVudCBEMAoJTVNJIHN1cHBvcnRzIDEgbWVzc2FnZSwgNjQg Yml0CglNU0ktWCBzdXBwb3J0cyAyIG1lc3NhZ2VzIGluIG1hcCAweDIwCgltYXBbMTBdOiB0eXBl IEkvTyBQb3J0LCByYW5nZSAzMiwgYmFzZSAweDIwMDAsIHNpemUgIDgsIGVuYWJsZWQKcGNpYjM6 IHJlcXVlc3RlZCBJL08gcmFuZ2UgMHgyMDAwLTB4MjBmZjogaW4gcmFuZ2UKCW1hcFsxOF06IHR5 cGUgUHJlZmV0Y2hhYmxlIE1lbW9yeSwgcmFuZ2UgNjQsIGJhc2UgMHhkMjQxMDAwMCwgc2l6ZSAx MiwgZW5hYmxlZApwY2liMzogcmVxdWVzdGVkIG1lbW9yeSByYW5nZSAweGQyNDEwMDAwLTB4ZDI0 MTBmZmY6IGdvb2QKCW1hcFsyMF06IHR5cGUgUHJlZmV0Y2hhYmxlIE1lbW9yeSwgcmFuZ2UgNjQs IGJhc2UgMHhkMjQwMDAwMCwgc2l6ZSAxNiwgZW5hYmxlZApwY2liMzogcmVxdWVzdGVkIG1lbW9y eSByYW5nZSAweGQyNDAwMDAwLTB4ZDI0MGZmZmY6IGdvb2QKcGNpYjM6IG1hdGNoZWQgZW50cnkg Zm9yIDMuMC5JTlRBCnBjaWIzOiBzbG90IDAgSU5UQSBoYXJkd2lyZWQgdG8gSVJRIDE5CnJlMDog PFJlYWxUZWsgODEwMUUvODEwMkUvODEwMkVMIFBDSWUgMTAvMTAwYmFzZVRYPiBwb3J0IDB4MjAw MC0weDIwZmYgbWVtIDB4ZDI0MTAwMDAtMHhkMjQxMGZmZiwweGQyNDAwMDAwLTB4ZDI0MGZmZmYg aXJxIDE5IGF0IGRldmljZSAwLjAgb24gcGNpMwpyZTA6IFJlc2VydmVkIDB4MTAwMCBieXRlcyBm b3IgcmlkIDB4MTggdHlwZSAzIGF0IDB4ZDI0MTAwMDAKcmUwOiBNU0kgY291bnQgOiAxCnJlMDog YXR0ZW1wdGluZyB0byBhbGxvY2F0ZSAxIE1TSSB2ZWN0b3JzICgxIHN1cHBvcnRlZCkKbXNpOiBy b3V0aW5nIE1TSSBJUlEgMjU2IHRvIGxvY2FsIEFQSUMgMCB2ZWN0b3IgNTIKcmUwOiB1c2luZyBJ UlEgMjU2IGZvciBNU0kKcmUwOiBVc2luZyAxIE1TSSBtZXNzYWdlcwpyZTA6IENoaXAgcmV2LiAw eDI0ODAwMDAwCnJlMDogTUFDIHJldi4gMHgwMDQwMDAwMAptaWlidXMwOiA8TUlJIGJ1cz4gb24g cmUwCnJscGh5MDogPFJUTDgyMDFMIDEwLzEwMCBtZWRpYSBpbnRlcmZhY2U+IFBIWSAxIG9uIG1p aWJ1czAKcmxwaHkwOiAgMTBiYXNlVCwgMTBiYXNlVC1GRFgsIDEwMGJhc2VUWCwgMTAwYmFzZVRY LUZEWCwgYXV0bwpyZTA6IGJwZiBhdHRhY2hlZApyZTA6IEV0aGVybmV0IGFkZHJlc3M6IDAwOjIz OjVhOmEyOmJkOjU0CnJlMDogW01QU0FGRV0KcmUwOiBbRklMVEVSXQpwY2liNDogPEFDUEkgUENJ LVBDSSBicmlkZ2U+IGF0IGRldmljZSAyOC41IG9uIHBjaTAKcGNpYjQ6ICAgZG9tYWluICAgICAg ICAgICAgMApwY2liNDogICBzZWNvbmRhcnkgYnVzICAgICA0CnBjaWI0OiAgIHN1Ym9yZGluYXRl IGJ1cyAgIDYKcGNpYjQ6ICAgSS9PIGRlY29kZSAgICAgICAgMHgxMDAwLTB4MWZmZgpwY2liNDog ICBtZW1vcnkgZGVjb2RlICAgICAweGQ0NTAwMDAwLTB4ZDU0ZmZmZmYKcGNpYjQ6ICAgcHJlZmV0 Y2hlZCBkZWNvZGUgMHhkMzQwMDAwMC0weGQ0M2ZmZmZmCnBjaTQ6IDxBQ1BJIFBDSSBidXM+IG9u IHBjaWI0CnBjaTQ6IGRvbWFpbj0wLCBwaHlzaWNhbCBidXM9NAp1aGNpMjogPEludGVsIDgyODAx SSAoSUNIOSkgVVNCIGNvbnRyb2xsZXI+IHBvcnQgMHg1MDgwLTB4NTA5ZiBpcnEgMjAgYXQgZGV2 aWNlIDI5LjAgb24gcGNpMAp1aGNpMjogUmVzZXJ2ZWQgMHgyMCBieXRlcyBmb3IgcmlkIDB4MjAg dHlwZSA0IGF0IDB4NTA4MAppb2FwaWMwOiByb3V0aW5nIGludHBpbiAyMCAoUENJIElSUSAyMCkg dG8gbGFwaWMgMCB2ZWN0b3IgNTMKdWhjaTI6IFtNUFNBRkVdCnVoY2kyOiBbSVRIUkVBRF0KdWhj aTI6IExlZ1N1cCA9IDB4MGYwMAp1c2J1czM6IDxJbnRlbCA4MjgwMUkgKElDSDkpIFVTQiBjb250 cm9sbGVyPiBvbiB1aGNpMgp1aGNpMzogPEludGVsIDgyODAxSSAoSUNIOSkgVVNCIGNvbnRyb2xs ZXI+IHBvcnQgMHg1MDYwLTB4NTA3ZiBpcnEgMjIgYXQgZGV2aWNlIDI5LjEgb24gcGNpMAp1aGNp MzogUmVzZXJ2ZWQgMHgyMCBieXRlcyBmb3IgcmlkIDB4MjAgdHlwZSA0IGF0IDB4NTA2MAppb2Fw aWMwOiByb3V0aW5nIGludHBpbiAyMiAoUENJIElSUSAyMikgdG8gbGFwaWMgMCB2ZWN0b3IgNTQK dWhjaTM6IFtNUFNBRkVdCnVoY2kzOiBbSVRIUkVBRF0KdWhjaTM6IExlZ1N1cCA9IDB4MGYxMAp1 c2J1czQ6IDxJbnRlbCA4MjgwMUkgKElDSDkpIFVTQiBjb250cm9sbGVyPiBvbiB1aGNpMwp1aGNp NDogPEludGVsIDgyODAxSSAoSUNIOSkgVVNCIGNvbnRyb2xsZXI+IHBvcnQgMHg1MDQwLTB4NTA1 ZiBpcnEgMTggYXQgZGV2aWNlIDI5LjIgb24gcGNpMAp1aGNpNDogUmVzZXJ2ZWQgMHgyMCBieXRl cyBmb3IgcmlkIDB4MjAgdHlwZSA0IGF0IDB4NTA0MAp1aGNpNDogW01QU0FGRV0KdWhjaTQ6IFtJ VEhSRUFEXQp1aGNpNDogTGVnU3VwID0gMHgwZjAwCnVzYnVzNTogPEludGVsIDgyODAxSSAoSUNI OSkgVVNCIGNvbnRyb2xsZXI+IG9uIHVoY2k0CmVoY2kxOiA8SW50ZWwgODI4MDFJIChJQ0g5KSBV U0IgMi4wIGNvbnRyb2xsZXI+IG1lbSAweGQ4NTA0ODAwLTB4ZDg1MDRiZmYgaXJxIDIwIGF0IGRl dmljZSAyOS43IG9uIHBjaTAKZWhjaTE6IFJlc2VydmVkIDB4NDAwIGJ5dGVzIGZvciByaWQgMHgx MCB0eXBlIDMgYXQgMHhkODUwNDgwMAplaGNpMTogW01QU0FGRV0KZWhjaTE6IFtJVEhSRUFEXQp1 c2J1czY6IHdhaXRpbmcgZm9yIEJJT1MgdG8gZ2l2ZSB1cCBjb250cm9sCnVzYnVzNjogRUhDSSB2 ZXJzaW9uIDEuMAp1c2J1czY6IDxJbnRlbCA4MjgwMUkgKElDSDkpIFVTQiAyLjAgY29udHJvbGxl cj4gb24gZWhjaTEKcGNpYjU6IDxBQ1BJIFBDSS1QQ0kgYnJpZGdlPiBhdCBkZXZpY2UgMzAuMCBv biBwY2kwCnBjaWI1OiAgIGRvbWFpbiAgICAgICAgICAgIDAKcGNpYjU6ICAgc2Vjb25kYXJ5IGJ1 cyAgICAgNwpwY2liNTogICBzdWJvcmRpbmF0ZSBidXMgICA3CnBjaWI1OiAgIEkvTyBkZWNvZGUg ICAgICAgIDB4ZjAwMC0weGZmZgpwY2liNTogICBubyBwcmVmZXRjaGVkIGRlY29kZQpwY2liNTog ICBTdWJ0cmFjdGl2ZWx5IGRlY29kZWQgYnJpZGdlLgpwY2k3OiA8QUNQSSBQQ0kgYnVzPiBvbiBw Y2liNQpwY2k3OiBkb21haW49MCwgcGh5c2ljYWwgYnVzPTcKaXNhYjA6IDxQQ0ktSVNBIGJyaWRn ZT4gYXQgZGV2aWNlIDMxLjAgb24gcGNpMAppc2EwOiA8SVNBIGJ1cz4gb24gaXNhYjAKYXRhcGNp MDogPEludGVsIChJRD0yOTI5ODA4NikgQUhDSSBjb250cm9sbGVyPiBwb3J0IDB4NTBlOC0weDUw ZWYsMHg1MGZjLTB4NTBmZiwweDUwZTAtMHg1MGU3LDB4NTBmOC0weDUwZmIsMHg1MDIwLTB4NTAz ZiBtZW0gMHhkODUwNDAwMC0weGQ4NTA0N2ZmIGlycSAyMSBhdCBkZXZpY2UgMzEuMiBvbiBwY2kw CmF0YXBjaTA6IFJlc2VydmVkIDB4MjAgYnl0ZXMgZm9yIHJpZCAweDIwIHR5cGUgNCBhdCAweDUw MjAKYXRhcGNpMDogUmVzZXJ2ZWQgMHg4MDAgYnl0ZXMgZm9yIHJpZCAweDI0IHR5cGUgMyBhdCAw eGQ4NTA0MDAwCmlvYXBpYzA6IHJvdXRpbmcgaW50cGluIDIxIChQQ0kgSVJRIDIxKSB0byBsYXBp YyAwIHZlY3RvciA1NQphdGFwY2kwOiBbTVBTQUZFXQphdGFwY2kwOiBbSVRIUkVBRF0KYXRhcGNp MDogQUhDSSB2MS4yMCBjb250cm9sbGVyIHdpdGggNCAzR2JwcyBwb3J0cywgUE0gc3VwcG9ydGVk CmF0YXBjaTA6IENhcHM6IDY0Yml0IE5DUSBTTlRGIFNTIEFMUCBBTCBDTE8gM0dicHMgUE0gUE1E IFNTQyBQU0MgMzJjbWQgQ0NDIEVNIGVTQVRBIDRwb3J0cwphdGEyOiA8QVRBIGNoYW5uZWwgMD4g b24gYXRhcGNpMAphdGEyOiBBSENJIHJlc2V0Li4uCmF0YTI6IGhhcmR3YXJlIHJlc2V0IC4uLgph dGEyOiBTQVRBIGNvbm5lY3QgdGltZT0wbXMgc3RhdHVzPTAwMDAwMTIzCmF0YTI6IHJlYWR5IHdh aXQgdGltZT0zbXMKYXRhMjogc29mdHdhcmUgcmVzZXQgcG9ydCAxNS4uLgphdGEyOiByZWFkeSB3 YWl0IHRpbWU9MG1zCmF0YTI6IFNJR05BVFVSRTogMDAwMDAxMDEKYXRhMjogQUhDSSByZXNldCBk b25lOiBkZXZpY2VzPTAwMDAwMDAxCmF0YTI6IFtNUFNBRkVdCmF0YTI6IFtJVEhSRUFEXQphdGEz OiA8QVRBIGNoYW5uZWwgND4gb24gYXRhcGNpMAphdGEzOiBBSENJIHJlc2V0Li4uCmF0YTM6IGhh cmR3YXJlIHJlc2V0IC4uLgphdGEzOiBTQVRBIGNvbm5lY3QgdGltZT0xMG1zIHN0YXR1cz0wMDAw MDExMwphdGEzOiByZWFkeSB3YWl0IHRpbWU9MG1zCmF0YTM6IHNvZnR3YXJlIHJlc2V0IHBvcnQg MTUuLi4KYXRhMzogcmVhZHkgd2FpdCB0aW1lPTBtcwphdGEzOiBTSUdOQVRVUkU6IGViMTQwMTAx CmF0YTM6IEFIQ0kgcmVzZXQgZG9uZTogZGV2aWNlcz0wMDAxMDAwMAphdGEzOiBbTVBTQUZFXQph dGEzOiBbSVRIUkVBRF0KYXRhNDogPEFUQSBjaGFubmVsIDU+IG9uIGF0YXBjaTAKYXRhNDogQUhD SSByZXNldC4uLgphdGE0OiBoYXJkd2FyZSByZXNldCAuLi4KYXRhNDogU0FUQSBjb25uZWN0IHRp bWVvdXQgc3RhdHVzPTAwMDAwMDAwCmF0YTQ6IEFIQ0kgcmVzZXQgZG9uZTogcGh5IHJlc2V0IGZv dW5kIG5vIGRldmljZQphdGE0OiBbTVBTQUZFXQphdGE0OiBbSVRIUkVBRF0KcGNpMDogPHNlcmlh bCBidXMsIFNNQnVzPiBhdCBkZXZpY2UgMzEuMyAobm8gZHJpdmVyIGF0dGFjaGVkKQphY3BpX3R6 MDogPFRoZXJtYWwgWm9uZT4gb24gYWNwaTAKYXRydGMwOiA8QVQgcmVhbHRpbWUgY2xvY2s+IHBv cnQgMHg3MC0weDc3IG9uIGFjcGkwCmF0cnRjMDogV2FybmluZzogQ291bGRuJ3QgbWFwIEkvTy4K YXRydGMwOiByZWdpc3RlcmVkIGFzIGEgdGltZS1vZi1kYXkgY2xvY2sgKHJlc29sdXRpb24gMTAw MDAwMHVzKQphdGtiZGMwOiA8S2V5Ym9hcmQgY29udHJvbGxlciAoaTgwNDIpPiBwb3J0IDB4NjAs MHg2NCBpcnEgMSBvbiBhY3BpMAphdGtiZDA6IDxBVCBLZXlib2FyZD4gaXJxIDEgb24gYXRrYmRj MAphdGtiZDogdGhlIGN1cnJlbnQga2JkIGNvbnRyb2xsZXIgY29tbWFuZCBieXRlIDAwNjcKYXRr YmQ6IGtleWJvYXJkIElEIDB4NDFhYiAoMikKa2JkMCBhdCBhdGtiZDAKa2JkMDogYXRrYmQwLCBB VCAxMDEvMTAyICgyKSwgY29uZmlnOjB4MCwgZmxhZ3M6MHgzZDAwMDAKaW9hcGljMDogcm91dGlu ZyBpbnRwaW4gMSAoSVNBIElSUSAxKSB0byBsYXBpYyAwIHZlY3RvciA1NgphdGtiZDA6IFtHSUFO VC1MT0NLRURdCmF0a2JkMDogW0lUSFJFQURdCnBzbTA6IHVuYWJsZSB0byBhbGxvY2F0ZSBJUlEK cHNtY3BucDA6IDxQUy8yIG1vdXNlIHBvcnQ+IGlycSAxMiBvbiBhY3BpMApwc20wOiBjdXJyZW50 IGNvbW1hbmQgYnl0ZTowMDY3CnBzbTA6IDxQUy8yIE1vdXNlPiBpcnEgMTIgb24gYXRrYmRjMApp b2FwaWMwOiByb3V0aW5nIGludHBpbiAxMiAoSVNBIElSUSAxMikgdG8gbGFwaWMgMCB2ZWN0b3Ig NTcKcHNtMDogW0dJQU5ULUxPQ0tFRF0KcHNtMDogW0lUSFJFQURdCnBzbTA6IG1vZGVsIEdlbmVy aWMgUFMvMiBtb3VzZSwgZGV2aWNlIElEIDAtMDAsIDIgYnV0dG9ucwpwc20wOiBjb25maWc6MDAw MDAwMDAsIGZsYWdzOjAwMDAwMDA4LCBwYWNrZXQgc2l6ZTozCnBzbTA6IHN5bmNtYXNrOmMwLCBz eW5jYml0czowMApjcHUwOiA8QUNQSSBDUFU+IG9uIGFjcGkwCkFDUEk6IFNTRFQgMHhiOWU2ZWM5 OCAwMDIyMyAodjEgIFBtUmVmICBDcHUwSXN0IDAwMDAzMDAwIElOVEwgMjAwNTExMTcpCkFDUEk6 IFNTRFQgMHhiOWU2YzYxOCAwMDVCMyAodjEgIFBtUmVmICBDcHUwQ3N0IDAwMDAzMDAxIElOVEwg MjAwNTExMTcpCmVzdDA6IDxFbmhhbmNlZCBTcGVlZFN0ZXAgRnJlcXVlbmN5IENvbnRyb2w+IG9u IGNwdTAKZXN0MDogSW52YWxpZCBpZDE2IChzZXQsIGN1cikgPSAoMjA3MywgMTg5NzkpCmVzdDA6 IEludmFsaWQgZnJlcSAxNjAwLCBpZ25vcmVkLgplc3QwOiBJbnZhbGlkIGlkMTYgKHNldCwgY3Vy KSA9ICgxNTUzLCAxODk3OSkKZXN0MDogSW52YWxpZCBmcmVxIDEyMDAsIGlnbm9yZWQuCnA0dGNj MDogPENQVSBGcmVxdWVuY3kgVGhlcm1hbCBDb250cm9sPiBvbiBjcHUwCmNwdTE6IDxBQ1BJIENQ VT4gb24gYWNwaTAKQUNQSTogU1NEVCAweGI5ZTZkZTE4IDAwMUNGICh2MSAgUG1SZWYgICAgQXBJ c3QgMDAwMDMwMDAgSU5UTCAyMDA1MTExNykKQUNQSTogU1NEVCAweGI5ZTZlZjE4IDAwMDhEICh2 MSAgUG1SZWYgICAgQXBDc3QgMDAwMDMwMDAgSU5UTCAyMDA1MTExNykKZXN0MTogPEVuaGFuY2Vk IFNwZWVkU3RlcCBGcmVxdWVuY3kgQ29udHJvbD4gb24gY3B1MQplc3QxOiBJbnZhbGlkIGlkMTYg KHNldCwgY3VyKSA9ICgyMDczLCAxODk3OSkKZXN0MTogSW52YWxpZCBmcmVxIDE2MDAsIGlnbm9y ZWQuCmVzdDE6IEludmFsaWQgaWQxNiAoc2V0LCBjdXIpID0gKDE1NTMsIDE4OTc5KQplc3QxOiBJ bnZhbGlkIGZyZXEgMTIwMCwgaWdub3JlZC4KcDR0Y2MxOiA8Q1BVIEZyZXF1ZW5jeSBUaGVybWFs IENvbnRyb2w+IG9uIGNwdTEKZXhfaXNhX2lkZW50aWZ5KCkKaXNhX3Byb2JlX2NoaWxkcmVuOiBk aXNhYmxpbmcgUG5QIGRldmljZXMKYXRrYmRjOiBhdGtiZGMwIGFscmVhZHkgZXhpc3RzOyBza2lw cGluZyBpdAphdHJ0YzogYXRydGMwIGFscmVhZHkgZXhpc3RzOyBza2lwcGluZyBpdApzYzogc2Mw IGFscmVhZHkgZXhpc3RzOyBza2lwcGluZyBpdAppc2FfcHJvYmVfY2hpbGRyZW46IHByb2Jpbmcg bm9uLVBuUCBkZXZpY2VzCm9ybTA6IDxJU0EgT3B0aW9uIFJPTT4gYXQgaW9tZW0gMHhjMDAwMC0w eGNmN2ZmIG9uIGlzYTAKc2MwOiA8U3lzdGVtIGNvbnNvbGU+IGF0IGZsYWdzIDB4MTAwIG9uIGlz YTAKc2MwOiBWR0EgPDE2IHZpcnR1YWwgY29uc29sZXMsIGZsYWdzPTB4MzAwPgpzYzA6IGZiMCwg a2JkMSwgdGVybWluYWwgZW11bGF0b3I6IHNjdGVrZW4gKHRla2VuIHRlcm1pbmFsKQp2Z2EwOiA8 R2VuZXJpYyBJU0EgVkdBPiBhdCBwb3J0IDB4M2MwLTB4M2RmIGlvbWVtIDB4YTAwMDAtMHhiZmZm ZiBvbiBpc2EwCmZkYzAgZmFpbGVkIHRvIHByb2JlIGF0IHBvcnQgMHgzZjAtMHgzZjUsMHgzZjcg aXJxIDYgZHJxIDIgb24gaXNhMApwcGMwOiBjYW5ub3QgcmVzZXJ2ZSBJL08gcG9ydCByYW5nZQpw cGMwOiA8UGFyYWxsZWwgcG9ydD4gZmFpbGVkIHRvIHByb2JlIGF0IGlycSA3IG9uIGlzYTAKdWFy dDA6IDxuczgyNTA+IGZhaWxlZCB0byBwcm9iZSBhdCBwb3J0IDB4M2Y4LTB4M2ZmIGlycSA0IG9u IGlzYTAKdWFydDE6IDxuczgyNTA+IGZhaWxlZCB0byBwcm9iZSBhdCBwb3J0IDB4MmY4LTB4MmZm IGlycSAzIG9uIGlzYTAKaXNhX3Byb2JlX2NoaWxkcmVuOiBwcm9iaW5nIFBuUCBkZXZpY2VzCkRl dmljZSBjb25maWd1cmF0aW9uIGZpbmlzaGVkLgpSZWR1Y2luZyBrZXJuLm1heHZub2RlcyAyNTEz NTQgLT4gMTAwMDAwCnByb2NmcyByZWdpc3RlcmVkCmxhcGljOiBEaXZpc29yIDIsIEZyZXF1ZW5j eSA5OTk1MDIxNyBoegpUaW1lY291bnRlciAiVFNDIiBmcmVxdWVuY3kgMjA5ODk1NDUxNSBIeiBx dWFsaXR5IC0xMDAKVGltZWNvdW50ZXJzIHRpY2sgZXZlcnkgMS4wMDAgbXNlYwpsbzA6IGJwZiBh dHRhY2hlZApocHRycjogbm8gY29udHJvbGxlciBkZXRlY3RlZC4KYXRhMjogSWRlbnRpZnlpbmcg ZGV2aWNlczogMDAwMDAwMDEKYXRhMjogTmV3IGRldmljZXM6IDAwMDAwMDAxCm1kMDogUHJlbG9h ZGVkIGltYWdlIDwvYm9vdC9tZnNyb290PiA0MTk0MzA0IGJ5dGVzIGF0IDB4ZmZmZmZmZmY4MGUx N2RjMAp1c2J1czA6IDEyTWJwcyBGdWxsIFNwZWVkIFVTQiB2MS4wCnVzYnVzMTogMTJNYnBzIEZ1 bGwgU3BlZWQgVVNCIHYxLjAKdXNidXMyOiA0ODBNYnBzIEhpZ2ggU3BlZWQgVVNCIHYyLjAKdXNi dXMzOiAxMk1icHMgRnVsbCBTcGVlZCBVU0IgdjEuMAp1c2J1czQ6IDEyTWJwcyBGdWxsIFNwZWVk IFVTQiB2MS4wCnVzYnVzNTogMTJNYnBzIEZ1bGwgU3BlZWQgVVNCIHYxLjAKdXNidXM2OiA0ODBN YnBzIEhpZ2ggU3BlZWQgVVNCIHYyLjAKYmF0dGVyeTA6IGJhdHRlcnkgaW5pdGlhbGl6YXRpb24g c3RhcnQKYWNwaV9hY2FkMDogYWNsaW5lIGluaXRpYWxpemF0aW9uIHN0YXJ0CmFjcGlfdHowOiBf QUMwOiB0ZW1wZXJhdHVyZSA2My4wID49IHNldHBvaW50IDYzLjAKYXRhMi1tYXN0ZXI6IHBpbz1Q SU80IHdkbWE9V0RNQTIgdWRtYT1VRE1BMTAwIGNhYmxlPTQwIHdpcmUKYWQ0OiA0NzY5NDBNQiA8 U2VhZ2F0ZSBTVDk1MDAzMjVBUyAwMDAzSFBNMT4gYXQgYXRhMi1tYXN0ZXIgU0FUQTMwMAphZDQ6 IDk3Njc3MzE2OCBzZWN0b3JzIFs5NjkwMjFDLzE2SC82M1NdIDE2IHNlY3RvcnMvaW50ZXJydXB0 IDEgZGVwdGggcXVldWUKR0VPTTogbmV3IGRpc2sgYWQ0CmFjcGlfdHowOiBzd2l0Y2hlZCBmcm9t IE5PTkUgdG8gX0FDMDogNjMuMEMKdWdlbjAuMTogPEludGVsPiBhdCB1c2J1czAKdWh1YjA6IDxJ bnRlbCBVSENJIHJvb3QgSFVCLCBjbGFzcyA5LzAsIHJldiAxLjAwLzEuMDAsIGFkZHIgMT4gb24g dXNidXMwCnVnZW4xLjE6IDxJbnRlbD4gYXQgdXNidXMxCnVodWIxOiA8SW50ZWwgVUhDSSByb290 IEhVQiwgY2xhc3MgOS8wLCByZXYgMS4wMC8xLjAwLCBhZGRyIDE+IG9uIHVzYnVzMQp1Z2VuMi4x OiA8SW50ZWw+IGF0IHVzYnVzMgp1aHViMjogPEludGVsIEVIQ0kgcm9vdCBIVUIsIGNsYXNzIDkv MCwgcmV2IDIuMDAvMS4wMCwgYWRkciAxPiBvbiB1c2J1czIKdWdlbjMuMTogPEludGVsPiBhdCB1 c2J1czMKdWh1YjM6IDxJbnRlbCBVSENJIHJvb3QgSFVCLCBjbGFzcyA5LzAsIHJldiAxLjAwLzEu MDAsIGFkZHIgMT4gb24gdXNidXMzCnVnZW40LjE6IDxJbnRlbD4gYXQgdXNidXM0CnVodWI0OiA8 SW50ZWwgVUhDSSByb290IEhVQiwgY2xhc3MgOS8wLCByZXYgMS4wMC8xLjAwLCBhZGRyIDE+IG9u IHVzYnVzNAp1Z2VuNS4xOiA8SW50ZWw+IGF0IHVzYnVzNQp1aHViNTogPEludGVsIFVIQ0kgcm9v dCBIVUIsIGNsYXNzIDkvMCwgcmV2IDEuMDAvMS4wMCwgYWRkciAxPiBvbiB1c2J1czUKdWdlbjYu MTogPEludGVsPiBhdCB1c2J1czYKdWh1YjY6IDxJbnRlbCBFSENJIHJvb3QgSFVCLCBjbGFzcyA5 LzAsIHJldiAyLjAwLzEuMDAsIGFkZHIgMT4gb24gdXNidXM2CmFjcGlfYWNhZDA6IE9uIExpbmUK YWNwaV9hY2FkMDogYWNsaW5lIGluaXRpYWxpemF0aW9uIGRvbmUsIHRyaWVkIDEgdGltZXMKYWQ0 OiBJbnRlbCBjaGVjazEgZmFpbGVkCmFkNDogQWRhcHRlYyBjaGVjazEgZmFpbGVkCmFkNDogTFNJ ICh2MykgY2hlY2sxIGZhaWxlZAphZDQ6IExTSSAodjIpIGNoZWNrMSBmYWlsZWQKYWQ0OiBGcmVl QlNEIGNoZWNrMSBmYWlsZWQKYXRhMzogSWRlbnRpZnlpbmcgZGV2aWNlczogMDAwMTAwMDAKYXRh MzogTmV3IGRldmljZXM6IDAwMDEwMDAwCmF0YTMtbWFzdGVyOiBwaW89UElPNCB3ZG1hPVdETUEy IHVkbWE9VURNQTEwMCBjYWJsZT00MCB3aXJlCmF0YTM6IGRldmljZV9yZXNldCB0aW1lb3V0PTI1 OTB1cwphY2QwOiA8SEwtRFQtU1QgRFZEUkFNIEdUMjBML0RDMDM+IERWRFIgZHJpdmUgYXQgYXRh MyBhcyBtYXN0ZXIKYWNkMDogcmVhZCAxMDgyMEtCL3MgKDEwODIwS0Ivcykgd3JpdGUgMjcwNUtC L3MgKDI3MDVLQi9zKSwgMTAyNEtCIGJ1ZmZlciwgU0FUQTE1MAphY2QwOiBSZWFkczogQ0RSLCBD RFJXLCBDRERBIHN0cmVhbSwgRFZEUk9NLCBEVkRSLCBEVkRSQU0sIHBhY2tldAphY2QwOiBXcml0 ZXM6IENEUiwgQ0RSVywgRFZEUiwgRFZEUkFNLCB0ZXN0IHdyaXRlLCBidXJucHJvb2YKYWNkMDog QXVkaW86IHBsYXksIDI1NiB2b2x1bWUgbGV2ZWxzCmFjZDA6IE1lY2hhbmlzbTogZWplY3RhYmxl IHRyYXksIHVubG9ja2VkCmFjZDA6IE1lZGl1bTogRFZEIDEyMG1tIGRhdGEgZGlzYwphdGE0OiBJ ZGVudGlmeWluZyBkZXZpY2VzOiAwMDAwMDAwMAphdGE0OiBOZXcgZGV2aWNlczogMDAwMDAwMDAK QVRBIFBzZXVkb1JBSUQgbG9hZGVkClNNUDogQVAgQ1BVICMxIExhdW5jaGVkIQpjcHUxIEFQOgog ICAgIElEOiAweDAxMDAwMDAwICAgVkVSOiAweDAwMDUwMDE0IExEUjogMHgwMDAwMDAwMCBERlI6 IDB4ZmZmZmZmZmYKICBsaW50MDogMHgwMDAxMDcwMCBsaW50MTogMHgwMDAwMDQwMCBUUFI6IDB4 MDAwMDAwMDAgU1ZSOiAweDAwMDAwMWZmCiAgdGltZXI6IDB4MDAwMjAwZWYgdGhlcm06IDB4MDAw MTAwMDAgZXJyOiAweDAwMDEwMDAwIHBjbTogMHgwMDAxMDQwMAppb2FwaWMwOiByb3V0aW5nIGlu dHBpbiA5IChJU0EgSVJRIDkpIHRvIGxhcGljIDEgdmVjdG9yIDQ4CmlvYXBpYzA6IHJvdXRpbmcg aW50cGluIDE2IChQQ0kgSVJRIDE2KSB0byBsYXBpYyAxIHZlY3RvciA0OQppb2FwaWMwOiByb3V0 aW5nIGludHBpbiAxOCAoUENJIElSUSAxOCkgdG8gbGFwaWMgMSB2ZWN0b3IgNTAKaW9hcGljMDog cm91dGluZyBpbnRwaW4gMjEgKFBDSSBJUlEgMjEpIHRvIGxhcGljIDEgdmVjdG9yIDUxCm1zaTog QXNzaWduaW5nIE1TSSBJUlEgMjU2IHRvIGxvY2FsIEFQSUMgMSB2ZWN0b3IgNTIKdWh1YjA6IDIg cG9ydHMgd2l0aCAyIHJlbW92YWJsZSwgc2VsZiBwb3dlcmVkCnVodWIxOiAyIHBvcnRzIHdpdGgg MiByZW1vdmFibGUsIHNlbGYgcG93ZXJlZAp1aHViMzogMiBwb3J0cyB3aXRoIDIgcmVtb3ZhYmxl LCBzZWxmIHBvd2VyZWQKdWh1YjQ6IDIgcG9ydHMgd2l0aCAyIHJlbW92YWJsZSwgc2VsZiBwb3dl cmVkCnVodWI1OiAyIHBvcnRzIHdpdGggMiByZW1vdmFibGUsIHNlbGYgcG93ZXJlZApHRU9NOiBh ZDRzNDogZ2VvbWV0cnkgZG9lcyBub3QgbWF0Y2ggbGFiZWwgKDI1NWgsNjNzICE9IDE2aCw2M3Mp LgpiYXR0ZXJ5MDogYmF0dGVyeSBpbml0aWFsaXphdGlvbiBkb25lLCB0cmllZCAxIHRpbWVzCnVo dWIyOiA0IHBvcnRzIHdpdGggNCByZW1vdmFibGUsIHNlbGYgcG93ZXJlZApSb290IG1vdW50IHdh aXRpbmcgZm9yOiB1c2J1czYKdWh1YjY6IDYgcG9ydHMgd2l0aCA2IHJlbW92YWJsZSwgc2VsZiBw b3dlcmVkClJvb3QgbW91bnQgd2FpdGluZyBmb3I6IHVzYnVzNgp1Z2VuNi4yOiA8R2VuZXJpYz4g YXQgdXNidXM2CnVtYXNzMDogPEJ1bGstSW4sIEJ1bGstT3V0LCBJbnRlcmZhY2U+IG9uIHVzYnVz Ngp1bWFzczA6ICBTQ1NJIG92ZXIgQnVsay1Pbmx5OyBxdWlya3MgPSAweDAwMDAKdWdlbjQuMjog PExvZ2l0ZWNoPiBhdCB1c2J1czQKdW1zMDogPExvZ2l0ZWNoIFVTQiBSZWNlaXZlciwgY2xhc3Mg MC8wLCByZXYgMS4xMC80Ni4wMCwgYWRkciAyPiBvbiB1c2J1czQKdW1zMDogOCBidXR0b25zIGFu ZCBbWFlaXSBjb29yZGluYXRlcyBJRD0wCnVoaWQwOiA8TG9naXRlY2ggVVNCIFJlY2VpdmVyLCBj bGFzcyAwLzAsIHJldiAxLjEwLzQ2LjAwLCBhZGRyIDI+IG9uIHVzYnVzNApSb290IG1vdW50IHdh aXRpbmcgZm9yOiB1c2J1czYKdW1hc3MwOjA6MDotMTogQXR0YWNoZWQgdG8gc2NidXMwCihwcm9i ZTA6dW1hc3Mtc2ltMDowOjA6MCk6IERvd24gcmV2aW5nIFByb3RvY29sIFZlcnNpb24gZnJvbSAy IHRvIDA/ClJvb3QgbW91bnQgd2FpdGluZyBmb3I6IHVzYnVzNgoocHJvYmUwOnVtYXNzLXNpbTA6 MDowOjApOiBURVNUIFVOSVQgUkVBRFkuIENEQjogMCAwIDAgMCAwIDAgCihwcm9iZTA6dW1hc3Mt c2ltMDowOjA6MCk6IENBTSBTdGF0dXM6IFNDU0kgU3RhdHVzIEVycm9yCihwcm9iZTA6dW1hc3Mt c2ltMDowOjA6MCk6IFNDU0kgU3RhdHVzOiBDaGVjayBDb25kaXRpb24KKHByb2JlMDp1bWFzcy1z aW0wOjA6MDowKTogTk9UIFJFQURZIGFzYzozYSwwCihwcm9iZTA6dW1hc3Mtc2ltMDowOjA6MCk6 IE1lZGl1bSBub3QgcHJlc2VudAoocHJvYmUwOnVtYXNzLXNpbTA6MDowOjApOiAocHJvYmUwOnVt YXNzLXNpbTA6MDowOjApOiBURVNUIFVOSVQgUkVBRFkuIENEQjogMCAwIDAgMCAwIDAgCihwcm9i ZTA6dW1hc3Mtc2ltMDowOjA6MCk6IE5PVCBSRUFEWSBhc2M6M2EsMAoocHJvYmUwOnVtYXNzLXNp bTA6MDowOjApOiBNZWRpdW0gbm90IHByZXNlbnQKVW5yZXRyeWFibGUgZXJyb3IKKHByb2JlMDp1 bWFzcy1zaW0wOjA6MDowKTogZXJyb3IgNgoocHJvYmUwOnVtYXNzLXNpbTA6MDowOjApOiBVbnJl dHJ5YWJsZSBFcnJvcgpwYXNzMCBhdCB1bWFzcy1zaW0wIGJ1cyAwIHRhcmdldCAwIGx1biAwCnBh c3MwOiA8R2VuZXJpYy0gTXVsdGktQ2FyZCAxLjAwPiBSZW1vdmFibGUgRGlyZWN0IEFjY2VzcyBT Q1NJLTAgZGV2aWNlIApwYXNzMDogNDAuMDAwTUIvcyB0cmFuc2ZlcnMKR0VPTTogbmV3IGRpc2sg ZGEwCihkYTA6dW1hc3Mtc2ltMDowOjA6MCk6IGVycm9yIDYKKGRhMDp1bWFzcy1zaW0wOjA6MDow KTogVW5yZXRyeWFibGUgRXJyb3IKZGEwIGF0IHVtYXNzLXNpbTAgYnVzIDAgdGFyZ2V0IDAgbHVu IDAKZGEwOiA8R2VuZXJpYy0gTXVsdGktQ2FyZCAxLjAwPiBSZW1vdmFibGUgRGlyZWN0IEFjY2Vz cyBTQ1NJLTAgZGV2aWNlIApkYTA6IDQwLjAwME1CL3MgdHJhbnNmZXJzCmRhMDogQXR0ZW1wdCB0 byBxdWVyeSBkZXZpY2Ugc2l6ZSBmYWlsZWQ6IE5PVCBSRUFEWSwgTWVkaXVtIG5vdCBwcmVzZW50 CihkYTA6dW1hc3Mtc2ltMDowOjA6MCk6IGVycm9yIDYKKGRhMDp1bWFzcy1zaW0wOjA6MDowKTog VW5yZXRyeWFibGUgRXJyb3IKT3BlbmVkIGRpc2sgZGEwIC0+IDYKKGRhMDp1bWFzcy1zaW0wOjA6 MDowKTogZXJyb3IgNgooZGEwOnVtYXNzLXNpbTA6MDowOjApOiBVbnJldHJ5YWJsZSBFcnJvcgpP cGVuZWQgZGlzayBkYTAgLT4gNgp1Z2VuNi4zOiA8U3VZaW4+IGF0IHVzYnVzNgpUcnlpbmcgdG8g bW91bnQgcm9vdCBmcm9tIHVmczovZGV2L21kMApjdF90b190cyhbMjAxMC0wMS0yNCAwMjoyMTo1 OV0pID0gMTI2NDI5OTcxOS4wMDAwMDAwMDAKc3RhcnRfaW5pdDogdHJ5aW5nIC9zYmluL2luaXQK c3RhcnRfaW5pdDogdHJ5aW5nIC9zYmluL29pbml0CnN0YXJ0X2luaXQ6IHRyeWluZyAvc2Jpbi9p bml0LmJhawpzdGFydF9pbml0OiB0cnlpbmcgL3Jlc2N1ZS9pbml0CnN0YXJ0X2luaXQ6IHRyeWlu ZyAvc3RhbmQvc3lzaW5zdGFsbAphY3BpX3R6MDogc3dpdGNoZWQgZnJvbSBfQUMwIHRvIE5PTkU6 IDU5LjBDCnVnZW42LjQ6IDx2ZW5kb3IgMHgwNzgxPiBhdCB1c2J1czYKdW1hc3MxOiA8dmVuZG9y IDB4MDc4MSBwcm9kdWN0IDB4NTUzMCwgY2xhc3MgMC8wLCByZXYgMi4wMC8yLjAwLCBhZGRyIDQ+ IG9uIHVzYnVzNgp1bWFzczE6ICBTQ1NJIG92ZXIgQnVsay1Pbmx5OyBxdWlya3MgPSAweDAwMDAK dW1hc3MxOjE6MTotMTogQXR0YWNoZWQgdG8gc2NidXMxCihwcm9iZTA6dW1hc3Mtc2ltMToxOjA6 MCk6IERvd24gcmV2aW5nIFByb3RvY29sIFZlcnNpb24gZnJvbSAyIHRvIDA/Cihwcm9iZTA6dW1h c3Mtc2ltMToxOjA6MCk6IFRFU1QgVU5JVCBSRUFEWS4gQ0RCOiAwIDAgMCAwIDAgMCAKKHByb2Jl MDp1bWFzcy1zaW0xOjE6MDowKTogQ0FNIFN0YXR1czogU0NTSSBTdGF0dXMgRXJyb3IKKHByb2Jl MDp1bWFzcy1zaW0xOjE6MDowKTogU0NTSSBTdGF0dXM6IENoZWNrIENvbmRpdGlvbgoocHJvYmUw OnVtYXNzLXNpbTE6MTowOjApOiBVTklUIEFUVEVOVElPTiBhc2M6M2EsMAoocHJvYmUwOnVtYXNz LXNpbTE6MTowOjApOiBNZWRpdW0gbm90IHByZXNlbnQKKHByb2JlMDp1bWFzcy1zaW0xOjE6MDow KTogKHByb2JlMDp1bWFzcy1zaW0xOjE6MDowKTogVEVTVCBVTklUIFJFQURZLiBDREI6IDAgMCAw IDAgMCAwIAoocHJvYmUwOnVtYXNzLXNpbTE6MTowOjApOiBVTklUIEFUVEVOVElPTiBhc2M6M2Es MAoocHJvYmUwOnVtYXNzLXNpbTE6MTowOjApOiBNZWRpdW0gbm90IHByZXNlbnQKUmV0cnlpbmcg Q29tbWFuZCAocGVyIFNlbnNlIERhdGEpCihwcm9iZTA6dW1hc3Mtc2ltMToxOjA6MCk6IFJldHJ5 aW5nIENvbW1hbmQKcGFzczEgYXQgdW1hc3Mtc2ltMSBidXMgMSB0YXJnZXQgMCBsdW4gMApwYXNz MTogPFNhbkRpc2sgU2FuRGlzayBDcnV6ZXIgOC4wMj4gUmVtb3ZhYmxlIERpcmVjdCBBY2Nlc3Mg U0NTSS0wIGRldmljZSAKcGFzczE6IDQwLjAwME1CL3MgdHJhbnNmZXJzCkdFT006IG5ldyBkaXNr IGRhMQpkYTEgYXQgdW1hc3Mtc2ltMSBidXMgMSB0YXJnZXQgMCBsdW4gMApkYTE6IDxTYW5EaXNr IFNhbkRpc2sgQ3J1emVyIDguMDI+IFJlbW92YWJsZSBEaXJlY3QgQWNjZXNzIFNDU0ktMCBkZXZp Y2UgCmRhMTogNDAuMDAwTUIvcyB0cmFuc2ZlcnMKZGExOiA3NjkxTUIgKDE1NzUzMjE1IDUxMiBi eXRlIHNlY3RvcnM6IDI1NUggNjNTL1QgOTgwQykKR0VPTTogZGExOiBwYXJ0aXRpb24gMSBkb2Vz IG5vdCBzdGFydCBvbiBhIHRyYWNrIGJvdW5kYXJ5LgpHRU9NOiBkYTE6IHBhcnRpdGlvbiAxIGRv ZXMgbm90IGVuZCBvbiBhIHRyYWNrIGJvdW5kYXJ5LgpHRU9NOiBkYTE6IHBhcnRpdGlvbiAxIGRv ZXMgbm90IHN0YXJ0IG9uIGEgdHJhY2sgYm91bmRhcnkuCkdFT006IGRhMTogcGFydGl0aW9uIDEg ZG9lcyBub3QgZW5kIG9uIGEgdHJhY2sgYm91bmRhcnkuCkdFT006IGRhMTogcGFydGl0aW9uIDEg ZG9lcyBub3Qgc3RhcnQgb24gYSB0cmFjayBib3VuZGFyeS4KR0VPTTogZGExOiBwYXJ0aXRpb24g MSBkb2VzIG5vdCBlbmQgb24gYSB0cmFjayBib3VuZGFyeS4KV2FpdGluZyAobWF4IDYwIHNlY29u ZHMpIGZvciBzeXN0ZW0gcHJvY2VzcyBgdm5scnUnIHRvIHN0b3AuLi5kb25lCldhaXRpbmcgKG1h eCA2MCBzZWNvbmRzKSBmb3Igc3lzdGVtIHByb2Nlc3MgYGJ1ZmRhZW1vbicgdG8gc3RvcC4uLmRv bmUKV2FpdGluZyAobWF4IDYwIHNlY29uZHMpIGZvciBzeXN0ZW0gcHJvY2VzcyBgc3luY2VyJyB0 byBzdG9wLi4uClN5bmNpbmcgZGlza3MsIHZub2RlcyByZW1haW5pbmcuLi4xIDEgMCAwIGRvbmUK QWxsIGJ1ZmZlcnMgc3luY2VkLgpTd2FwIGRldmljZSBhZDRzNGIgcmVtb3ZlZC4KVXB0aW1lOiAy Nm00NnMKYWNwaV9idXR0b24xOiB3YWtlX3ByZXAgZGlzYWJsZWQgd2FrZSBmb3IgXFxfU0JfLlNM UEIgKFM1KQpwY2liNTogd2FrZV9wcmVwIGRpc2FibGVkIHdha2UgZm9yIFxcX1NCXy5QQ0kwLlAz Ml8gKFM1KQp1aGNpMjogd2FrZV9wcmVwIGRpc2FibGVkIHdha2UgZm9yIFxcX1NCXy5QQ0kwLlVI QzEgKFM1KQp1aGNpMzogd2FrZV9wcmVwIGRpc2FibGVkIHdha2UgZm9yIFxcX1NCXy5QQ0kwLlVI QzIgKFM1KQp1aGNpNDogd2FrZV9wcmVwIGRpc2FibGVkIHdha2UgZm9yIFxcX1NCXy5QQ0kwLlVI QzMgKFM1KQp1bmtub3duOiB3YWtlX3ByZXAgZGlzYWJsZWQgd2FrZSBmb3IgXFxfU0JfLlBDSTAu VUhDNiAoUzUpCmVoY2kxOiB3YWtlX3ByZXAgZGlzYWJsZWQgd2FrZSBmb3IgXFxfU0JfLlBDSTAu RUhDMSAoUzUpCnVoY2kwOiB3YWtlX3ByZXAgZGlzYWJsZWQgd2FrZSBmb3IgXFxfU0JfLlBDSTAu VUhDNCAoUzUpCnVoY2kxOiB3YWtlX3ByZXAgZGlzYWJsZWQgd2FrZSBmb3IgXFxfU0JfLlBDSTAu VUhDNSAoUzUpCmVoY2kwOiB3YWtlX3ByZXAgZGlzYWJsZWQgd2FrZSBmb3IgXFxfU0JfLlBDSTAu RUhDMiAoUzUpCnVua25vd246IHdha2VfcHJlcCBkaXNhYmxlZCB3YWtlIGZvciBcXF9TQl8uUENJ MC5FWFAxLlBYU1ggKFM1KQp1bmtub3duOiB3YWtlX3ByZXAgZGlzYWJsZWQgd2FrZSBmb3IgXFxf U0JfLlBDSTAuRVhQMi5QWFNYIChTNSkKdW5rbm93bjogd2FrZV9wcmVwIGRpc2FibGVkIHdha2Ug Zm9yIFxcX1NCXy5QQ0kwLkVYUDMuUFhTWCAoUzUpCnJlMDogd2FrZV9wcmVwIGRpc2FibGVkIHdh a2UgZm9yIFxcX1NCXy5QQ0kwLkVYUDQuUFhTWCAoUzUpCnVua25vd246IHdha2VfcHJlcCBkaXNh YmxlZCB3YWtlIGZvciBcXF9TQl8uUENJMC5FWFA1LlBYU1ggKFM1KQp1bmtub3duOiB3YWtlX3By ZXAgZGlzYWJsZWQgd2FrZSBmb3IgXFxfU0JfLlBDSTAuRVhQNi5QWFNYIChTNSkKUmVib290aW5n Li4uCmNwdV9yZXNldDogU3RvcHBpbmcgb3RoZXIgQ1BVcwpDb3B5cmlnaHQgKGMpIDE5OTItMjAw OSBUaGUgRnJlZUJTRCBQcm9qZWN0LgpDb3B5cmlnaHQgKGMpIDE5NzksIDE5ODAsIDE5ODMsIDE5 ODYsIDE5ODgsIDE5ODksIDE5OTEsIDE5OTIsIDE5OTMsIDE5OTQKCVRoZSBSZWdlbnRzIG9mIHRo ZSBVbml2ZXJzaXR5IG9mIENhbGlmb3JuaWEuIEFsbCByaWdodHMgcmVzZXJ2ZWQuCkZyZWVCU0Qg aXMgYSByZWdpc3RlcmVkIHRyYWRlbWFyayBvZiBUaGUgRnJlZUJTRCBGb3VuZGF0aW9uLgpGcmVl QlNEIDguMC1SRUxFQVNFICMwOiBTYXQgTm92IDIxIDE1OjAyOjA4IFVUQyAyMDA5CiAgICByb290 QG1hc29uLmNzZS5idWZmYWxvLmVkdTovdXNyL29iai91c3Ivc3JjL3N5cy9HRU5FUklDClRpbWVj b3VudGVyICJpODI1NCIgZnJlcXVlbmN5IDExOTMxODIgSHogcXVhbGl0eSAwCkNQVTogSW50ZWwo UikgQ29yZShUTSkyIER1byBDUFUgICAgIFQ2NTAwICBAIDIuMTBHSHogKDIwOTguOTUtTUh6IEs4 LWNsYXNzIENQVSkKICBPcmlnaW4gPSAiR2VudWluZUludGVsIiAgSWQgPSAweDEwNjdhICBTdGVw cGluZyA9IDEwCiAgRmVhdHVyZXM9MHhiZmViZmJmZjxGUFUsVk1FLERFLFBTRSxUU0MsTVNSLFBB RSxNQ0UsQ1g4LEFQSUMsU0VQLE1UUlIsUEdFLE1DQSxDTU9WLFBBVCxQU0UzNixDTEZMVVNILERU UyxBQ1BJLE1NWCxGWFNSLFNTRSxTU0UyLFNTLEhUVCxUTSxQQkU+CiAgRmVhdHVyZXMyPTB4NDA4 ZTM5ZDxTU0UzLERURVM2NCxNT04sRFNfQ1BMLEVTVCxUTTIsU1NTRTMsQ1gxNix4VFBSLFBEQ00s U1NFNC4xLFhTQVZFPgogIEFNRCBGZWF0dXJlcz0weDIwMTAwODAwPFNZU0NBTEwsTlgsTE0+CiAg QU1EIEZlYXR1cmVzMj0weDE8TEFIRj4KICBUU0M6IFAtc3RhdGUgaW52YXJpYW50CnJlYWwgbWVt b3J5ICA9IDQyOTQ5NjcyOTYgKDQwOTYgTUIpCmF2YWlsIG1lbW9yeSA9IDM5OTg4MTQyMDggKDM4 MTMgTUIpCkFDUEkgQVBJQyBUYWJsZTogPEhQUU9FTSBTTElDLU1QQz4KRnJlZUJTRC9TTVA6IE11 bHRpcHJvY2Vzc29yIFN5c3RlbSBEZXRlY3RlZDogMiBDUFVzCkZyZWVCU0QvU01QOiAxIHBhY2th Z2UocykgeCAyIGNvcmUocykKIGNwdTAgKEJTUCk6IEFQSUMgSUQ6ICAwCiBjcHUxIChBUCk6IEFQ SUMgSUQ6ICAxCmlvYXBpYzA6IENoYW5naW5nIEFQSUMgSUQgdG8gNAppb2FwaWMwIDxWZXJzaW9u IDIuMD4gaXJxcyAwLTIzIG9uIG1vdGhlcmJvYXJkCmtiZDEgYXQga2JkbXV4MAphY3BpMDogPEhQ UU9FTSBTTElDLU1QQz4gb24gbW90aGVyYm9hcmQKYWNwaTA6IFtJVEhSRUFEXQphY3BpMDogUG93 ZXIgQnV0dG9uIChmaXhlZCkKVGltZWNvdW50ZXIgIkFDUEktZmFzdCIgZnJlcXVlbmN5IDM1Nzk1 NDUgSHogcXVhbGl0eSAxMDAwCmFjcGlfdGltZXIwOiA8MjQtYml0IHRpbWVyIGF0IDMuNTc5NTQ1 TUh6PiBwb3J0IDB4NDA4LTB4NDBiIG9uIGFjcGkwCmFjcGlfZWMwOiA8RW1iZWRkZWQgQ29udHJv bGxlcjogR1BFIDB4MTc+IHBvcnQgMHg2MiwweDY2IG9uIGFjcGkwCmFjcGlfaHBldDA6IDxIaWdo IFByZWNpc2lvbiBFdmVudCBUaW1lcj4gaW9tZW0gMHhmZWQwMDAwMC0weGZlZDAwM2ZmIG9uIGFj cGkwClRpbWVjb3VudGVyICJIUEVUIiBmcmVxdWVuY3kgMTQzMTgxODAgSHogcXVhbGl0eSA5MDAK YWNwaV9idXR0b24wOiA8UG93ZXIgQnV0dG9uPiBvbiBhY3BpMAphY3BpX2xpZDA6IDxDb250cm9s IE1ldGhvZCBMaWQgU3dpdGNoPiBvbiBhY3BpMAphY3BpX2J1dHRvbjE6IDxTbGVlcCBCdXR0b24+ IG9uIGFjcGkwCmJhdHRlcnkwOiA8QUNQSSBDb250cm9sIE1ldGhvZCBCYXR0ZXJ5PiBvbiBhY3Bp MAphY3BpX2FjYWQwOiA8QUMgQWRhcHRlcj4gb24gYWNwaTAKcGNpYjA6IDxBQ1BJIEhvc3QtUENJ IGJyaWRnZT4gcG9ydCAweGNmOC0weGNmZiBvbiBhY3BpMApwY2kwOiA8QUNQSSBQQ0kgYnVzPiBv biBwY2liMAp2Z2FwY2kwOiA8VkdBLWNvbXBhdGlibGUgZGlzcGxheT4gcG9ydCAweDUwZjAtMHg1 MGY3IG1lbSAweGQwMDAwMDAwLTB4ZDAzZmZmZmYsMHhjMDAwMDAwMC0weGNmZmZmZmZmIGlycSAx NiBhdCBkZXZpY2UgMi4wIG9uIHBjaTAKYWdwMDogPEludGVsIEdNNDUgU1ZHQSBjb250cm9sbGVy PiBvbiB2Z2FwY2kwCmFncDA6IGRldGVjdGVkIDY1NTMyayBzdG9sZW4gbWVtb3J5CmFncDA6IGFw ZXJ0dXJlIHNpemUgaXMgMjU2TQp2Z2FwY2kxOiA8VkdBLWNvbXBhdGlibGUgZGlzcGxheT4gbWVt IDB4ZDQ0MDAwMDAtMHhkNDRmZmZmZiBhdCBkZXZpY2UgMi4xIG9uIHBjaTAKdWhjaTA6IDxJbnRl bCA4MjgwMUkgKElDSDkpIFVTQiBjb250cm9sbGVyPiBwb3J0IDB4NTBjMC0weDUwZGYgaXJxIDE2 IGF0IGRldmljZSAyNi4wIG9uIHBjaTAKdWhjaTA6IFtJVEhSRUFEXQp1aGNpMDogTGVnU3VwID0g MHgwZjEwCnVzYnVzMDogPEludGVsIDgyODAxSSAoSUNIOSkgVVNCIGNvbnRyb2xsZXI+IG9uIHVo Y2kwCnVoY2kxOiA8SW50ZWwgODI4MDFJIChJQ0g5KSBVU0IgY29udHJvbGxlcj4gcG9ydCAweDUw YTAtMHg1MGJmIGlycSAxNyBhdCBkZXZpY2UgMjYuMSBvbiBwY2kwCnVoY2kxOiBbSVRIUkVBRF0K dWhjaTE6IExlZ1N1cCA9IDB4MGYwMAp1c2J1czE6IDxJbnRlbCA4MjgwMUkgKElDSDkpIFVTQiBj b250cm9sbGVyPiBvbiB1aGNpMQplaGNpMDogPEludGVsIDgyODAxSSAoSUNIOSkgVVNCIDIuMCBj b250cm9sbGVyPiBtZW0gMHhkODUwNGMwMC0weGQ4NTA0ZmZmIGlycSAxOCBhdCBkZXZpY2UgMjYu NyBvbiBwY2kwCmVoY2kwOiBbSVRIUkVBRF0KdXNidXMyOiB3YWl0aW5nIGZvciBCSU9TIHRvIGdp dmUgdXAgY29udHJvbAp1c2J1czI6IEVIQ0kgdmVyc2lvbiAxLjAKdXNidXMyOiA8SW50ZWwgODI4 MDFJIChJQ0g5KSBVU0IgMi4wIGNvbnRyb2xsZXI+IG9uIGVoY2kwCnBjaTA6IDxtdWx0aW1lZGlh LCBIREE+IGF0IGRldmljZSAyNy4wIChubyBkcml2ZXIgYXR0YWNoZWQpCnBjaWIxOiA8QUNQSSBQ Q0ktUENJIGJyaWRnZT4gYXQgZGV2aWNlIDI4LjAgb24gcGNpMApwY2kxOiA8QUNQSSBQQ0kgYnVz PiBvbiBwY2liMQpwY2liMjogPEFDUEkgUENJLVBDSSBicmlkZ2U+IGF0IGRldmljZSAyOC4yIG9u IHBjaTAKcGNpMjogPEFDUEkgUENJIGJ1cz4gb24gcGNpYjIKcGNpMjogPG5ldHdvcms+IGF0IGRl dmljZSAwLjAgKG5vIGRyaXZlciBhdHRhY2hlZCkKcGNpYjM6IDxBQ1BJIFBDSS1QQ0kgYnJpZGdl PiBhdCBkZXZpY2UgMjguMyBvbiBwY2kwCnBjaTM6IDxBQ1BJIFBDSSBidXM+IG9uIHBjaWIzCnJl MDogPFJlYWxUZWsgODEwMUUvODEwMkUvODEwMkVMIFBDSWUgMTAvMTAwYmFzZVRYPiBwb3J0IDB4 MjAwMC0weDIwZmYgbWVtIDB4ZDI0MTAwMDAtMHhkMjQxMGZmZiwweGQyNDAwMDAwLTB4ZDI0MGZm ZmYgaXJxIDE5IGF0IGRldmljZSAwLjAgb24gcGNpMwpyZTA6IFVzaW5nIDEgTVNJIG1lc3NhZ2Vz CnJlMDogQ2hpcCByZXYuIDB4MjQ4MDAwMDAKcmUwOiBNQUMgcmV2LiAweDAwNDAwMDAwCm1paWJ1 czA6IDxNSUkgYnVzPiBvbiByZTAKcmxwaHkwOiA8UlRMODIwMUwgMTAvMTAwIG1lZGlhIGludGVy ZmFjZT4gUEhZIDEgb24gbWlpYnVzMApybHBoeTA6ICAxMGJhc2VULCAxMGJhc2VULUZEWCwgMTAw YmFzZVRYLCAxMDBiYXNlVFgtRkRYLCBhdXRvCnJlMDogRXRoZXJuZXQgYWRkcmVzczogMDA6MjM6 NWE6YTI6YmQ6NTQKcmUwOiBbRklMVEVSXQpwY2liNDogPEFDUEkgUENJLVBDSSBicmlkZ2U+IGF0 IGRldmljZSAyOC41IG9uIHBjaTAKcGNpNDogPEFDUEkgUENJIGJ1cz4gb24gcGNpYjQKdWhjaTI6 IDxJbnRlbCA4MjgwMUkgKElDSDkpIFVTQiBjb250cm9sbGVyPiBwb3J0IDB4NTA4MC0weDUwOWYg aXJxIDIwIGF0IGRldmljZSAyOS4wIG9uIHBjaTAKdWhjaTI6IFtJVEhSRUFEXQp1aGNpMjogTGVn U3VwID0gMHgwZjAwCnVzYnVzMzogPEludGVsIDgyODAxSSAoSUNIOSkgVVNCIGNvbnRyb2xsZXI+ IG9uIHVoY2kyCnVoY2kzOiA8SW50ZWwgODI4MDFJIChJQ0g5KSBVU0IgY29udHJvbGxlcj4gcG9y dCAweDUwNjAtMHg1MDdmIGlycSAyMiBhdCBkZXZpY2UgMjkuMSBvbiBwY2kwCnVoY2kzOiBbSVRI UkVBRF0KdWhjaTM6IExlZ1N1cCA9IDB4MGYxMAp1c2J1czQ6IDxJbnRlbCA4MjgwMUkgKElDSDkp IFVTQiBjb250cm9sbGVyPiBvbiB1aGNpMwp1aGNpNDogPEludGVsIDgyODAxSSAoSUNIOSkgVVNC IGNvbnRyb2xsZXI+IHBvcnQgMHg1MDQwLTB4NTA1ZiBpcnEgMTggYXQgZGV2aWNlIDI5LjIgb24g cGNpMAp1aGNpNDogW0lUSFJFQURdCnVoY2k0OiBMZWdTdXAgPSAweDBmMDAKdXNidXM1OiA8SW50 ZWwgODI4MDFJIChJQ0g5KSBVU0IgY29udHJvbGxlcj4gb24gdWhjaTQKZWhjaTE6IDxJbnRlbCA4 MjgwMUkgKElDSDkpIFVTQiAyLjAgY29udHJvbGxlcj4gbWVtIDB4ZDg1MDQ4MDAtMHhkODUwNGJm ZiBpcnEgMjAgYXQgZGV2aWNlIDI5Ljcgb24gcGNpMAplaGNpMTogW0lUSFJFQURdCnVzYnVzNjog d2FpdGluZyBmb3IgQklPUyB0byBnaXZlIHVwIGNvbnRyb2wKdXNidXM2OiBFSENJIHZlcnNpb24g MS4wCnVzYnVzNjogPEludGVsIDgyODAxSSAoSUNIOSkgVVNCIDIuMCBjb250cm9sbGVyPiBvbiBl aGNpMQpwY2liNTogPEFDUEkgUENJLVBDSSBicmlkZ2U+IGF0IGRldmljZSAzMC4wIG9uIHBjaTAK cGNpNzogPEFDUEkgUENJIGJ1cz4gb24gcGNpYjUKaXNhYjA6IDxQQ0ktSVNBIGJyaWRnZT4gYXQg ZGV2aWNlIDMxLjAgb24gcGNpMAppc2EwOiA8SVNBIGJ1cz4gb24gaXNhYjAKYXRhcGNpMDogPElu dGVsIEFIQ0kgY29udHJvbGxlcj4gcG9ydCAweDUwZTgtMHg1MGVmLDB4NTBmYy0weDUwZmYsMHg1 MGUwLTB4NTBlNywweDUwZjgtMHg1MGZiLDB4NTAyMC0weDUwM2YgbWVtIDB4ZDg1MDQwMDAtMHhk ODUwNDdmZiBpcnEgMjEgYXQgZGV2aWNlIDMxLjIgb24gcGNpMAphdGFwY2kwOiBbSVRIUkVBRF0K YXRhcGNpMDogQUhDSSB2MS4yMCBjb250cm9sbGVyIHdpdGggNCAzR2JwcyBwb3J0cywgUE0gc3Vw cG9ydGVkCmF0YTI6IDxBVEEgY2hhbm5lbCAwPiBvbiBhdGFwY2kwCmF0YTI6IFtJVEhSRUFEXQph dGEzOiA8QVRBIGNoYW5uZWwgND4gb24gYXRhcGNpMAphdGEzOiBbSVRIUkVBRF0KYXRhNDogPEFU QSBjaGFubmVsIDU+IG9uIGF0YXBjaTAKYXRhNDogW0lUSFJFQURdCnBjaTA6IDxzZXJpYWwgYnVz LCBTTUJ1cz4gYXQgZGV2aWNlIDMxLjMgKG5vIGRyaXZlciBhdHRhY2hlZCkKYWNwaV90ejA6IDxU aGVybWFsIFpvbmU+IG9uIGFjcGkwCmF0cnRjMDogPEFUIHJlYWx0aW1lIGNsb2NrPiBwb3J0IDB4 NzAtMHg3NyBvbiBhY3BpMAphdHJ0YzA6IFdhcm5pbmc6IENvdWxkbid0IG1hcCBJL08uCmF0a2Jk YzA6IDxLZXlib2FyZCBjb250cm9sbGVyIChpODA0Mik+IHBvcnQgMHg2MCwweDY0IGlycSAxIG9u IGFjcGkwCmF0a2JkMDogPEFUIEtleWJvYXJkPiBpcnEgMSBvbiBhdGtiZGMwCmtiZDAgYXQgYXRr YmQwCmF0a2JkMDogW0dJQU5ULUxPQ0tFRF0KYXRrYmQwOiBbSVRIUkVBRF0KcHNtMDogPFBTLzIg TW91c2U+IGlycSAxMiBvbiBhdGtiZGMwCnBzbTA6IFtHSUFOVC1MT0NLRURdCnBzbTA6IFtJVEhS RUFEXQpwc20wOiBtb2RlbCBHZW5lcmljIFBTLzIgbW91c2UsIGRldmljZSBJRCAwCmNwdTA6IDxB Q1BJIENQVT4gb24gYWNwaTAKZXN0MDogPEVuaGFuY2VkIFNwZWVkU3RlcCBGcmVxdWVuY3kgQ29u dHJvbD4gb24gY3B1MApwNHRjYzA6IDxDUFUgRnJlcXVlbmN5IFRoZXJtYWwgQ29udHJvbD4gb24g Y3B1MApjcHUxOiA8QUNQSSBDUFU+IG9uIGFjcGkwCmVzdDE6IDxFbmhhbmNlZCBTcGVlZFN0ZXAg RnJlcXVlbmN5IENvbnRyb2w+IG9uIGNwdTEKcDR0Y2MxOiA8Q1BVIEZyZXF1ZW5jeSBUaGVybWFs IENvbnRyb2w+IG9uIGNwdTEKb3JtMDogPElTQSBPcHRpb24gUk9NPiBhdCBpb21lbSAweGMwMDAw LTB4Y2Y3ZmYgb24gaXNhMApzYzA6IDxTeXN0ZW0gY29uc29sZT4gYXQgZmxhZ3MgMHgxMDAgb24g aXNhMApzYzA6IFZHQSA8MTYgdmlydHVhbCBjb25zb2xlcywgZmxhZ3M9MHgzMDA+CnZnYTA6IDxH ZW5lcmljIElTQSBWR0E+IGF0IHBvcnQgMHgzYzAtMHgzZGYgaW9tZW0gMHhhMDAwMC0weGJmZmZm IG9uIGlzYTAKcHBjMDogY2Fubm90IHJlc2VydmUgSS9PIHBvcnQgcmFuZ2UKVGltZWNvdW50ZXJz IHRpY2sgZXZlcnkgMS4wMDAgbXNlYwp1c2J1czA6IDEyTWJwcyBGdWxsIFNwZWVkIFVTQiB2MS4w CnVzYnVzMTogMTJNYnBzIEZ1bGwgU3BlZWQgVVNCIHYxLjAKdXNidXMyOiA0ODBNYnBzIEhpZ2gg U3BlZWQgVVNCIHYyLjAKdXNidXMzOiAxMk1icHMgRnVsbCBTcGVlZCBVU0IgdjEuMAp1c2J1czQ6 IDEyTWJwcyBGdWxsIFNwZWVkIFVTQiB2MS4wCnVzYnVzNTogMTJNYnBzIEZ1bGwgU3BlZWQgVVNC IHYxLjAKdXNidXM2OiA0ODBNYnBzIEhpZ2ggU3BlZWQgVVNCIHYyLjAKYWQ0OiA0NzY5NDBNQiA8 U2VhZ2F0ZSBTVDk1MDAzMjVBUyAwMDAzSFBNMT4gYXQgYXRhMi1tYXN0ZXIgU0FUQTMwMAp1Z2Vu MC4xOiA8SW50ZWw+IGF0IHVzYnVzMAp1aHViMDogPEludGVsIFVIQ0kgcm9vdCBIVUIsIGNsYXNz IDkvMCwgcmV2IDEuMDAvMS4wMCwgYWRkciAxPiBvbiB1c2J1czAKdWdlbjEuMTogPEludGVsPiBh dCB1c2J1czEKdWh1YjE6IDxJbnRlbCBVSENJIHJvb3QgSFVCLCBjbGFzcyA5LzAsIHJldiAxLjAw LzEuMDAsIGFkZHIgMT4gb24gdXNidXMxCnVnZW4yLjE6IDxJbnRlbD4gYXQgdXNidXMyCnVodWIy OiA8SW50ZWwgRUhDSSByb290IEhVQiwgY2xhc3MgOS8wLCByZXYgMi4wMC8xLjAwLCBhZGRyIDE+ IG9uIHVzYnVzMgp1Z2VuMy4xOiA8SW50ZWw+IGF0IHVzYnVzMwp1aHViMzogPEludGVsIFVIQ0kg cm9vdCBIVUIsIGNsYXNzIDkvMCwgcmV2IDEuMDAvMS4wMCwgYWRkciAxPiBvbiB1c2J1czMKdWdl bjQuMTogPEludGVsPiBhdCB1c2J1czQKdWh1YjQ6IDxJbnRlbCBVSENJIHJvb3QgSFVCLCBjbGFz cyA5LzAsIHJldiAxLjAwLzEuMDAsIGFkZHIgMT4gb24gdXNidXM0CnVnZW41LjE6IDxJbnRlbD4g YXQgdXNidXM1CnVodWI1OiA8SW50ZWwgVUhDSSByb290IEhVQiwgY2xhc3MgOS8wLCByZXYgMS4w MC8xLjAwLCBhZGRyIDE+IG9uIHVzYnVzNQp1Z2VuNi4xOiA8SW50ZWw+IGF0IHVzYnVzNgp1aHVi NjogPEludGVsIEVIQ0kgcm9vdCBIVUIsIGNsYXNzIDkvMCwgcmV2IDIuMDAvMS4wMCwgYWRkciAx PiBvbiB1c2J1czYKYWNkMDogRFZEUiA8SEwtRFQtU1QgRFZEUkFNIEdUMjBML0RDMDM+IGF0IGF0 YTMtbWFzdGVyIFNBVEExNTAKU01QOiBBUCBDUFUgIzEgTGF1bmNoZWQhCnVodWIwOiAyIHBvcnRz IHdpdGggMiByZW1vdmFibGUsIHNlbGYgcG93ZXJlZAp1aHViMTogMiBwb3J0cyB3aXRoIDIgcmVt b3ZhYmxlLCBzZWxmIHBvd2VyZWQKdWh1YjM6IDIgcG9ydHMgd2l0aCAyIHJlbW92YWJsZSwgc2Vs ZiBwb3dlcmVkCnVodWI0OiAyIHBvcnRzIHdpdGggMiByZW1vdmFibGUsIHNlbGYgcG93ZXJlZAp1 aHViNTogMiBwb3J0cyB3aXRoIDIgcmVtb3ZhYmxlLCBzZWxmIHBvd2VyZWQKdWh1YjI6IDQgcG9y dHMgd2l0aCA0IHJlbW92YWJsZSwgc2VsZiBwb3dlcmVkCnVodWI2OiA2IHBvcnRzIHdpdGggNiBy ZW1vdmFibGUsIHNlbGYgcG93ZXJlZAp1Z2VuNi4yOiA8dmVuZG9yIDB4MDc4MT4gYXQgdXNidXM2 CnVtYXNzMDogPHZlbmRvciAweDA3ODEgcHJvZHVjdCAweDU1MzAsIGNsYXNzIDAvMCwgcmV2IDIu MDAvMi4wMCwgYWRkciAyPiBvbiB1c2J1czYKdW1hc3MwOiAgU0NTSSBvdmVyIEJ1bGstT25seTsg cXVpcmtzID0gMHgwMDAwCnVtYXNzMDowOjA6LTE6IEF0dGFjaGVkIHRvIHNjYnVzMApkYTAgYXQg dW1hc3Mtc2ltMCBidXMgMCB0YXJnZXQgMCBsdW4gMApkYTA6IDxTYW5EaXNrIFNhbkRpc2sgQ3J1 emVyIDguMDI+IFJlbW92YWJsZSBEaXJlY3QgQWNjZXNzIFNDU0ktMCBkZXZpY2UgCmRhMDogNDAu MDAwTUIvcyB0cmFuc2ZlcnMKZGEwOiA3NjkxTUIgKDE1NzUzMjE1IDUxMiBieXRlIHNlY3RvcnM6 IDI1NUggNjNTL1QgOTgwQykKdWdlbjYuMzogPEdlbmVyaWM+IGF0IHVzYnVzNgp1bWFzczE6IDxC dWxrLUluLCBCdWxrLU91dCwgSW50ZXJmYWNlPiBvbiB1c2J1czYKdW1hc3MxOiAgU0NTSSBvdmVy IEJ1bGstT25seTsgcXVpcmtzID0gMHgwMDAwCnVnZW40LjI6IDxMb2dpdGVjaD4gYXQgdXNidXM0 CnVtczA6IDxMb2dpdGVjaCBVU0IgUmVjZWl2ZXIsIGNsYXNzIDAvMCwgcmV2IDEuMTAvNDYuMDAs IGFkZHIgMj4gb24gdXNidXM0CnVtczA6IDggYnV0dG9ucyBhbmQgW1hZWl0gY29vcmRpbmF0ZXMg SUQ9MAp1aGlkMDogPExvZ2l0ZWNoIFVTQiBSZWNlaXZlciwgY2xhc3MgMC8wLCByZXYgMS4xMC80 Ni4wMCwgYWRkciAyPiBvbiB1c2J1czQKR0VPTTogZGEwOiBwYXJ0aXRpb24gMSBkb2VzIG5vdCBz dGFydCBvbiBhIHRyYWNrIGJvdW5kYXJ5LgpHRU9NOiBkYTA6IHBhcnRpdGlvbiAxIGRvZXMgbm90 IGVuZCBvbiBhIHRyYWNrIGJvdW5kYXJ5LgpSb290IG1vdW50IHdhaXRpbmcgZm9yOiB1c2J1czYK dW1hc3MxOjE6MTotMTogQXR0YWNoZWQgdG8gc2NidXMxCihwcm9iZTA6dW1hc3Mtc2ltMToxOjA6 MCk6IFRFU1QgVU5JVCBSRUFEWS4gQ0RCOiAwIDAgMCAwIDAgMCAKKHByb2JlMDp1bWFzcy1zaW0x OjE6MDowKTogQ0FNIFN0YXR1czogU0NTSSBTdGF0dXMgRXJyb3IKKHByb2JlMDp1bWFzcy1zaW0x OjE6MDowKTogU0NTSSBTdGF0dXM6IENoZWNrIENvbmRpdGlvbgoocHJvYmUwOnVtYXNzLXNpbTE6 MTowOjApOiBOT1QgUkVBRFkgYXNjOjNhLDAKKHByb2JlMDp1bWFzcy1zaW0xOjE6MDowKTogTWVk aXVtIG5vdCBwcmVzZW50Cihwcm9iZTA6dW1hc3Mtc2ltMToxOjA6MCk6IFVucmV0cnlhYmxlIGVy cm9yCmRhMSBhdCB1bWFzcy1zaW0xIGJ1cyAxIHRhcmdldCAwIGx1biAwCmRhMTogPEdlbmVyaWMt IE11bHRpLUNhcmQgMS4wMD4gUmVtb3ZhYmxlIERpcmVjdCBBY2Nlc3MgU0NTSS0wIGRldmljZSAK ZGExOiA0MC4wMDBNQi9zIHRyYW5zZmVycwpkYTE6IEF0dGVtcHQgdG8gcXVlcnkgZGV2aWNlIHNp emUgZmFpbGVkOiBOT1QgUkVBRFksIE1lZGl1bSBub3QgcHJlc2VudApSb290IG1vdW50IHdhaXRp bmcgZm9yOiB1c2J1czYKdWdlbjYuNDogPFN1WWluPiBhdCB1c2J1czYKVHJ5aW5nIHRvIG1vdW50 IHJvb3QgZnJvbSB1ZnM6L2Rldi9hZDRzNGEKV2FpdGluZyAobWF4IDYwIHNlY29uZHMpIGZvciBz eXN0ZW0gcHJvY2VzcyBgdm5scnUnIHRvIHN0b3AuLi5kb25lCldhaXRpbmcgKG1heCA2MCBzZWNv bmRzKSBmb3Igc3lzdGVtIHByb2Nlc3MgYGJ1ZmRhZW1vbicgdG8gc3RvcC4uLmRvbmUKV2FpdGlu ZyAobWF4IDYwIHNlY29uZHMpIGZvciBzeXN0ZW0gcHJvY2VzcyBgc3luY2VyJyB0byBzdG9wLi4u ClN5bmNpbmcgZGlza3MsIHZub2RlcyByZW1haW5pbmcuLi4xIDAgMCBkb25lCkFsbCBidWZmZXJz IHN5bmNlZC4KVXB0aW1lOiAxbTIwcwpSZWJvb3RpbmcuLi4KY3B1X3Jlc2V0OiBTdG9wcGluZyBv dGhlciBDUFVzCkNvcHlyaWdodCAoYykgMTk5Mi0yMDA5IFRoZSBGcmVlQlNEIFByb2plY3QuCkNv cHlyaWdodCAoYykgMTk3OSwgMTk4MCwgMTk4MywgMTk4NiwgMTk4OCwgMTk4OSwgMTk5MSwgMTk5 MiwgMTk5MywgMTk5NAoJVGhlIFJlZ2VudHMgb2YgdGhlIFVuaXZlcnNpdHkgb2YgQ2FsaWZvcm5p YS4gQWxsIHJpZ2h0cyByZXNlcnZlZC4KRnJlZUJTRCBpcyBhIHJlZ2lzdGVyZWQgdHJhZGVtYXJr IG9mIFRoZSBGcmVlQlNEIEZvdW5kYXRpb24uCkZyZWVCU0QgOC4wLVJFTEVBU0UgIzA6IFNhdCBO b3YgMjEgMTU6MDI6MDggVVRDIDIwMDkKICAgIHJvb3RAbWFzb24uY3NlLmJ1ZmZhbG8uZWR1Oi91 c3Ivb2JqL3Vzci9zcmMvc3lzL0dFTkVSSUMKUHJlbG9hZGVkIGVsZiBrZXJuZWwgIi9ib290L2tl cm5lbC9rZXJuZWwiIGF0IDB4ZmZmZmZmZmY4MGUxOTAwMC4KVGltZWNvdW50ZXIgImk4MjU0IiBm cmVxdWVuY3kgMTE5MzE4MiBIeiBxdWFsaXR5IDAKQ2FsaWJyYXRpbmcgVFNDIGNsb2NrIC4uLiBU U0MgY2xvY2s6IDIwOTg5NTEyNjAgSHoKQ1BVOiBJbnRlbChSKSBDb3JlKFRNKTIgRHVvIENQVSAg ICAgVDY1MDAgIEAgMi4xMEdIeiAoMjA5OC45NS1NSHogSzgtY2xhc3MgQ1BVKQogIE9yaWdpbiA9 ICJHZW51aW5lSW50ZWwiICBJZCA9IDB4MTA2N2EgIFN0ZXBwaW5nID0gMTAKICBGZWF0dXJlcz0w eGJmZWJmYmZmPEZQVSxWTUUsREUsUFNFLFRTQyxNU1IsUEFFLE1DRSxDWDgsQVBJQyxTRVAsTVRS UixQR0UsTUNBLENNT1YsUEFULFBTRTM2LENMRkxVU0gsRFRTLEFDUEksTU1YLEZYU1IsU1NFLFNT RTIsU1MsSFRULFRNLFBCRT4KICBGZWF0dXJlczI9MHg0MDhlMzlkPFNTRTMsRFRFUzY0LE1PTixE U19DUEwsRVNULFRNMixTU1NFMyxDWDE2LHhUUFIsUERDTSxTU0U0LjEsWFNBVkU+CiAgQU1EIEZl YXR1cmVzPTB4MjAxMDA4MDA8U1lTQ0FMTCxOWCxMTT4KICBBTUQgRmVhdHVyZXMyPTB4MTxMQUhG PgogIFRTQzogUC1zdGF0ZSBpbnZhcmlhbnQKcmVhbCBtZW1vcnkgID0gNDI5NDk2NzI5NiAoNDA5 NiBNQikKUGh5c2ljYWwgbWVtb3J5IGNodW5rKHMpOgoweDAwMDAwMDAwMDAwMDEwMDAgLSAweDAw MDAwMDAwMDAwOTlmZmYsIDYyNjY4OCBieXRlcyAoMTUzIHBhZ2VzKQoweDAwMDAwMDAwMDBlNDgw MDAgLSAweDAwMDAwMDAwYjA3ZWFmZmYsIDI5NDYxMTc2MzIgYnl0ZXMgKDcxOTI2NyBwYWdlcykK MHgwMDAwMDAwMGI5ZWJmMDAwIC0gMHgwMDAwMDAwMGI5ZjgyZmZmLCA4MDI4MTYgYnl0ZXMgKDE5 NiBwYWdlcykKMHgwMDAwMDAwMGI5ZmJmMDAwIC0gMHgwMDAwMDAwMGI5ZmRlZmZmLCAxMzEwNzIg Ynl0ZXMgKDMyIHBhZ2VzKQoweDAwMDAwMDAwYjlmZjYwMDAgLSAweDAwMDAwMDAwYjlmZmRmZmYs IDMyNzY4IGJ5dGVzICg4IHBhZ2VzKQoweDAwMDAwMDAwYjlmZmYwMDAgLSAweDAwMDAwMDAwYjlm ZmZmZmYsIDQwOTYgYnl0ZXMgKDEgcGFnZXMpCjB4MDAwMDAwMDEwMDAwMDAwMCAtIDB4MDAwMDAw MDEzZmZlZmZmZiwgMTA3MzY3NjI4OCBieXRlcyAoMjYyMTI4IHBhZ2VzKQphdmFpbCBtZW1vcnkg PSAzOTk4ODE0MjA4ICgzODEzIE1CKQpBQ1BJIEFQSUMgVGFibGU6IDxIUFFPRU0gU0xJQy1NUEM+ CklOVFI6IEFkZGluZyBsb2NhbCBBUElDIDEgYXMgYSB0YXJnZXQKRnJlZUJTRC9TTVA6IE11bHRp cHJvY2Vzc29yIFN5c3RlbSBEZXRlY3RlZDogMiBDUFVzCkZyZWVCU0QvU01QOiAxIHBhY2thZ2Uo cykgeCAyIGNvcmUocykKIGNwdTAgKEJTUCk6IEFQSUMgSUQ6ICAwCiBjcHUxIChBUCk6IEFQSUMg SUQ6ICAxCkFQSUM6IENQVSAwIGhhcyBBQ1BJIElEIDEKQVBJQzogQ1BVIDEgaGFzIEFDUEkgSUQg MgpVTEU6IHNldHVwIGNwdSAwClVMRTogc2V0dXAgY3B1IDEKQUNQSTogUlNEUCAweGZlMDIwIDAw MDI0ICh2MiBIUCAgICApCkFDUEk6IFhTRFQgMHhiOWZmZTEyMCAwMDA3NCAodjEgSFBRT0VNIFNM SUMtTVBDIDAwMDAwMDAxICAgICAgMDEwMDAwMTMpCkFDUEk6IEZBQ1AgMHhiOWZmMzAwMCAwMDBG NCAodjQgSFAgICAgIFJIRVRUICAgIDAwMDAwMDAxIE1TRlQgMDEwMDAwMTMpCkFDUEk6IERTRFQg MHhiOWZlNDAwMCAwQTVCOCAodjEgSFAgICAgIFJIRVRUICAgIDAwMDAwMDAxIE1TRlQgMDEwMDAw MTMpCkFDUEk6IEZBQ1MgMHhiOWY4YzAwMCAwMDA0MApBQ1BJOiBETUFSIDB4YjlmZjUwMDAgMDAw QjggKHYxICAgICAgICAgICAgICAgXF5BIDAwMDAwMDAxICAgICAgMDAwMDAwMDApCkFDUEk6IFNT RFQgMHhiOWZmNDAwMCAwMDY1NSAodjEgIFBtUmVmICAgIENwdVBtIDAwMDAzMDAwIElOVEwgMjAw NTExMTcpCkFDUEk6IEhQRVQgMHhiOWZmMjAwMCAwMDAzOCAodjEgSFBRT0VNIFNMSUMtTVBDIDAw MDAwMDAxIE1TRlQgMDEwMDAwMTMpCkFDUEk6IEFQSUMgMHhiOWZmMTAwMCAwMDA2QyAodjIgSFBR T0VNIFNMSUMtTVBDIDAwMDAwMDAxIE1TRlQgMDEwMDAwMTMpCkFDUEk6IE1DRkcgMHhiOWZmMDAw MCAwMDAzQyAodjEgSFBRT0VNIFNMSUMtTVBDIDAwMDAwMDAxIE1TRlQgMDEwMDAwMTMpCkFDUEk6 IEFTRiEgMHhiOWZlZjAwMCAwMDBBNSAodjMyIEhQUU9FTSBTTElDLU1QQyAwMDAwMDAwMSBNU0ZU IDAxMDAwMDEzKQpBQ1BJOiBTTElDIDB4YjlmZTMwMDAgMDAxNzYgKHYxIEhQUU9FTSBTTElDLU1Q QyAwMDAwMDAwMSBMT0hSIDAwMEY0MjQwKQpBQ1BJOiBCT09UIDB4YjlmZTIwMDAgMDAwMjggKHYx IEhQUU9FTSBTTElDLU1QQyAwMDAwMDAwMSBNU0ZUIDAxMDAwMDEzKQpBQ1BJOiBTU0RUIDB4Yjlm ZTEwMDAgMDAyOTYgKHYxIElOVEVMICBTYXRhQWhjaSAwMDAwMTAwMCBJTlRMIDIwMDUxMTE3KQpN QURUOiBGb3VuZCBJTyBBUElDIElEIDQsIEludGVycnVwdCAwIGF0IDB4ZmVjMDAwMDAKaW9hcGlj MDogQ2hhbmdpbmcgQVBJQyBJRCB0byA0CmlvYXBpYzA6IFJvdXRpbmcgZXh0ZXJuYWwgODI1OUEn cyAtPiBpbnRwaW4gMApNQURUOiBJbnRlcnJ1cHQgb3ZlcnJpZGU6IHNvdXJjZSAwLCBpcnEgMgpp b2FwaWMwOiBSb3V0aW5nIElSUSAwIC0+IGludHBpbiAyCk1BRFQ6IEludGVycnVwdCBvdmVycmlk ZTogc291cmNlIDksIGlycSA5CmlvYXBpYzA6IGludHBpbiA5IHRyaWdnZXI6IGxldmVsCmlvYXBp YzAgPFZlcnNpb24gMi4wPiBpcnFzIDAtMjMgb24gbW90aGVyYm9hcmQKY3B1MCBCU1A6CiAgICAg SUQ6IDB4MDAwMDAwMDAgICBWRVI6IDB4MDAwNTAwMTQgTERSOiAweDAwMDAwMDAwIERGUjogMHhm ZmZmZmZmZgogIGxpbnQwOiAweDAwMDEwNzAwIGxpbnQxOiAweDAwMDAwNDAwIFRQUjogMHgwMDAw MDAwMCBTVlI6IDB4MDAwMDAxZmYKICB0aW1lcjogMHgwMDAxMDBlZiB0aGVybTogMHgwMDAxMDAw MCBlcnI6IDB4MDAwMTAwMDAgcGNtOiAweDAwMDEwNDAwCndsYW46IDw4MDIuMTEgTGluayBMYXll cj4KbnVsbDogPG51bGwgZGV2aWNlLCB6ZXJvIGRldmljZT4KcmFuZG9tOiA8ZW50cm9weSBzb3Vy Y2UsIFNvZnR3YXJlLCBZYXJyb3c+Cm5mc2xvY2s6IHBzZXVkby1kZXZpY2UKa2JkOiBuZXcgYXJy YXkgc2l6ZSA0CmtiZDEgYXQga2JkbXV4MAptZW06IDxtZW1vcnk+CmlvOiA8SS9PPgpocHRycjog Um9ja2V0UkFJRCAxN3h4LzJ4eHggU0FUQSBjb250cm9sbGVyIGRyaXZlciB2MS4yCmFjcGkwOiA8 SFBRT0VNIFNMSUMtTVBDPiBvbiBtb3RoZXJib2FyZApQQ0llOiBNZW1vcnkgTWFwcGVkIGNvbmZp Z3VyYXRpb24gYmFzZSBAIDB4ZjgwMDAwMDAKaW9hcGljMDogcm91dGluZyBpbnRwaW4gOSAoSVNB IElSUSA5KSB0byBsYXBpYyAwIHZlY3RvciA0OAphY3BpMDogW01QU0FGRV0KYWNwaTA6IFtJVEhS RUFEXQphY3BpMDogUG93ZXIgQnV0dG9uIChmaXhlZCkKYWNwaTA6IHdha2V1cCBjb2RlIHZhIDB4 ZmZmZmZmODAwMDAwZjAwMCBwYSAweDQwMDAKQWNwaU9zRGVyaXZlUGNpSWQ6IFxcX1NCXy5QQ0kw LkhCVVMgLT4gYnVzIDAgZGV2IDAgZnVuYyAwCkFjcGlPc0Rlcml2ZVBjaUlkOiBcXF9TQl8uUENJ MC5MUENfLlBSUjAgLT4gYnVzIDAgZGV2IDMxIGZ1bmMgMApBY3BpT3NEZXJpdmVQY2lJZDogXFxf U0JfLlBDSTAuTFBDXy5QUlIxIC0+IGJ1cyAwIGRldiAzMSBmdW5jIDAKQUNQSSB0aW1lcjogMS8y IDEvMSAxLzEgMS8xIDEvMSAxLzEgMS8yIDEvMSAxLzEgMS8xIC0+IDEwClRpbWVjb3VudGVyICJB Q1BJLWZhc3QiIGZyZXF1ZW5jeSAzNTc5NTQ1IEh6IHF1YWxpdHkgMTAwMAphY3BpX3RpbWVyMDog PDI0LWJpdCB0aW1lciBhdCAzLjU3OTU0NU1Iej4gcG9ydCAweDQwOC0weDQwYiBvbiBhY3BpMAph Y3BpX2VjMDogPEVtYmVkZGVkIENvbnRyb2xsZXI6IEdQRSAweDE3PiBwb3J0IDB4NjIsMHg2NiBv biBhY3BpMApwY2lfbGluazA6ICAgICAgICBJbmRleCAgSVJRICBSdGQgIFJlZiAgSVJRcwogIElu aXRpYWwgUHJvYmUgICAgICAgMCAgIDExICAgTiAgICAgMCAgMyA0IDUgNyA5IDEwIDExIDEyCiAg VmFsaWRhdGlvbiAgICAgICAgICAwICAgMTEgICBOICAgICAwICAzIDQgNSA3IDkgMTAgMTEgMTIK ICBBZnRlciBEaXNhYmxlICAgICAgIDAgIDI1NSAgIE4gICAgIDAgIDMgNCA1IDcgOSAxMCAxMSAx MgpwY2lfbGluazE6ICAgICAgICBJbmRleCAgSVJRICBSdGQgIFJlZiAgSVJRcwogIEluaXRpYWwg UHJvYmUgICAgICAgMCAgIDEwICAgTiAgICAgMCAgMyA0IDUgNyA5IDEwIDExIDEyCiAgVmFsaWRh dGlvbiAgICAgICAgICAwICAgMTAgICBOICAgICAwICAzIDQgNSA3IDkgMTAgMTEgMTIKICBBZnRl ciBEaXNhYmxlICAgICAgIDAgIDI1NSAgIE4gICAgIDAgIDMgNCA1IDcgOSAxMCAxMSAxMgpwY2lf bGluazI6ICAgICAgICBJbmRleCAgSVJRICBSdGQgIFJlZiAgSVJRcwogIEluaXRpYWwgUHJvYmUg ICAgICAgMCAgIDExICAgTiAgICAgMCAgMyA0IDUgNyA5IDEwIDExIDEyCiAgVmFsaWRhdGlvbiAg ICAgICAgICAwICAgMTEgICBOICAgICAwICAzIDQgNSA3IDkgMTAgMTEgMTIKICBBZnRlciBEaXNh YmxlICAgICAgIDAgIDI1NSAgIE4gICAgIDAgIDMgNCA1IDcgOSAxMCAxMSAxMgpwY2lfbGluazM6 ICAgICAgICBJbmRleCAgSVJRICBSdGQgIFJlZiAgSVJRcwogIEluaXRpYWwgUHJvYmUgICAgICAg MCAgIDExICAgTiAgICAgMCAgMyA0IDUgNyA5IDEwIDExIDEyCiAgVmFsaWRhdGlvbiAgICAgICAg ICAwICAgMTEgICBOICAgICAwICAzIDQgNSA3IDkgMTAgMTEgMTIKICBBZnRlciBEaXNhYmxlICAg ICAgIDAgIDI1NSAgIE4gICAgIDAgIDMgNCA1IDcgOSAxMCAxMSAxMgpwY2lfbGluazQ6ICAgICAg ICBJbmRleCAgSVJRICBSdGQgIFJlZiAgSVJRcwogIEluaXRpYWwgUHJvYmUgICAgICAgMCAgIDEx ICAgTiAgICAgMCAgMyA0IDUgNyA5IDEwIDExIDEyCiAgVmFsaWRhdGlvbiAgICAgICAgICAwICAg MTEgICBOICAgICAwICAzIDQgNSA3IDkgMTAgMTEgMTIKICBBZnRlciBEaXNhYmxlICAgICAgIDAg IDI1NSAgIE4gICAgIDAgIDMgNCA1IDcgOSAxMCAxMSAxMgpwY2lfbGluazU6ICAgICAgICBJbmRl eCAgSVJRICBSdGQgIFJlZiAgSVJRcwogIEluaXRpYWwgUHJvYmUgICAgICAgMCAgIDExICAgTiAg ICAgMCAgMyA0IDUgNyA5IDEwIDExIDEyCiAgVmFsaWRhdGlvbiAgICAgICAgICAwICAgMTEgICBO ICAgICAwICAzIDQgNSA3IDkgMTAgMTEgMTIKICBBZnRlciBEaXNhYmxlICAgICAgIDAgIDI1NSAg IE4gICAgIDAgIDMgNCA1IDcgOSAxMCAxMSAxMgpwY2lfbGluazY6ICAgICAgICBJbmRleCAgSVJR ICBSdGQgIFJlZiAgSVJRcwogIEluaXRpYWwgUHJvYmUgICAgICAgMCAgIDExICAgTiAgICAgMCAg MyA0IDUgNyA5IDEwIDExIDEyCiAgVmFsaWRhdGlvbiAgICAgICAgICAwICAgMTEgICBOICAgICAw ICAzIDQgNSA3IDkgMTAgMTEgMTIKICBBZnRlciBEaXNhYmxlICAgICAgIDAgIDI1NSAgIE4gICAg IDAgIDMgNCA1IDcgOSAxMCAxMSAxMgpwY2lfbGluazc6ICAgICAgICBJbmRleCAgSVJRICBSdGQg IFJlZiAgSVJRcwogIEluaXRpYWwgUHJvYmUgICAgICAgMCAgMjU1ICAgTiAgICAgMCAgMyA0IDUg NyA5IDEwIDExIDEyCiAgVmFsaWRhdGlvbiAgICAgICAgICAwICAyNTUgICBOICAgICAwICAzIDQg NSA3IDkgMTAgMTEgMTIKICBBZnRlciBEaXNhYmxlICAgICAgIDAgIDI1NSAgIE4gICAgIDAgIDMg NCA1IDcgOSAxMCAxMSAxMgphY3BpX2hwZXQwOiA8SGlnaCBQcmVjaXNpb24gRXZlbnQgVGltZXI+ IGlvbWVtIDB4ZmVkMDAwMDAtMHhmZWQwMDNmZiBvbiBhY3BpMAphY3BpX2hwZXQwOiB2ZW5kOiAw eDgwODYgcmV2OiAweDEgbnVtOiAzIGh6OiAxNDMxODE4MCBvcHRzOiBsZWdhY3lfcm91dGUgNjQt Yml0ClRpbWVjb3VudGVyICJIUEVUIiBmcmVxdWVuY3kgMTQzMTgxODAgSHogcXVhbGl0eSA5MDAK YWNwaV9idXR0b24wOiA8UG93ZXIgQnV0dG9uPiBvbiBhY3BpMAphY3BpX2xpZDA6IDxDb250cm9s IE1ldGhvZCBMaWQgU3dpdGNoPiBvbiBhY3BpMAphY3BpX2J1dHRvbjE6IDxTbGVlcCBCdXR0b24+ IG9uIGFjcGkwCmJhdHRlcnkwOiA8QUNQSSBDb250cm9sIE1ldGhvZCBCYXR0ZXJ5PiBvbiBhY3Bp MAphY3BpX2FjYWQwOiA8QUMgQWRhcHRlcj4gb24gYWNwaTAKcGNpYjA6IDxBQ1BJIEhvc3QtUENJ IGJyaWRnZT4gcG9ydCAweGNmOC0weGNmZiBvbiBhY3BpMApwY2kwOiA8QUNQSSBQQ0kgYnVzPiBv biBwY2liMApwY2kwOiBkb21haW49MCwgcGh5c2ljYWwgYnVzPTAKZm91bmQtPgl2ZW5kb3I9MHg4 MDg2LCBkZXY9MHgyYTQwLCByZXZpZD0weDA3Cglkb21haW49MCwgYnVzPTAsIHNsb3Q9MCwgZnVu Yz0wCgljbGFzcz0wNi0wMC0wMCwgaGRydHlwZT0weDAwLCBtZmRldj0wCgljbWRyZWc9MHgwMDA2 LCBzdGF0cmVnPTB4MjA5MCwgY2FjaGVsbnN6PTAgKGR3b3JkcykKCWxhdHRpbWVyPTB4MDAgKDAg bnMpLCBtaW5nbnQ9MHgwMCAoMCBucyksIG1heGxhdD0weDAwICgwIG5zKQpmb3VuZC0+CXZlbmRv cj0weDgwODYsIGRldj0weDJhNDIsIHJldmlkPTB4MDcKCWRvbWFpbj0wLCBidXM9MCwgc2xvdD0y LCBmdW5jPTAKCWNsYXNzPTAzLTAwLTAwLCBoZHJ0eXBlPTB4MDAsIG1mZGV2PTEKCWNtZHJlZz0w eDAwMDcsIHN0YXRyZWc9MHgwMDkwLCBjYWNoZWxuc3o9MCAoZHdvcmRzKQoJbGF0dGltZXI9MHgw MCAoMCBucyksIG1pbmdudD0weDAwICgwIG5zKSwgbWF4bGF0PTB4MDAgKDAgbnMpCglpbnRwaW49 YSwgaXJxPTExCglwb3dlcnNwZWMgMyAgc3VwcG9ydHMgRDAgRDMgIGN1cnJlbnQgRDAKCU1TSSBz dXBwb3J0cyAxIG1lc3NhZ2UKCW1hcFsxMF06IHR5cGUgTWVtb3J5LCByYW5nZSA2NCwgYmFzZSAw eGQwMDAwMDAwLCBzaXplIDIyLCBlbmFibGVkCgltYXBbMThdOiB0eXBlIFByZWZldGNoYWJsZSBN ZW1vcnksIHJhbmdlIDY0LCBiYXNlIDB4YzAwMDAwMDAsIHNpemUgMjgsIGVuYWJsZWQKCW1hcFsy MF06IHR5cGUgSS9PIFBvcnQsIHJhbmdlIDMyLCBiYXNlIDB4NTBmMCwgc2l6ZSAgMywgZW5hYmxl ZApwY2liMDogbWF0Y2hlZCBlbnRyeSBmb3IgMC4yLklOVEEKcGNpYjA6IHNsb3QgMiBJTlRBIGhh cmR3aXJlZCB0byBJUlEgMTYKZm91bmQtPgl2ZW5kb3I9MHg4MDg2LCBkZXY9MHgyYTQzLCByZXZp ZD0weDA3Cglkb21haW49MCwgYnVzPTAsIHNsb3Q9MiwgZnVuYz0xCgljbGFzcz0wMy04MC0wMCwg aGRydHlwZT0weDAwLCBtZmRldj0xCgljbWRyZWc9MHgwMDA3LCBzdGF0cmVnPTB4MDA5MCwgY2Fj aGVsbnN6PTAgKGR3b3JkcykKCWxhdHRpbWVyPTB4MDAgKDAgbnMpLCBtaW5nbnQ9MHgwMCAoMCBu cyksIG1heGxhdD0weDAwICgwIG5zKQoJcG93ZXJzcGVjIDMgIHN1cHBvcnRzIEQwIEQzICBjdXJy ZW50IEQwCgltYXBbMTBdOiB0eXBlIE1lbW9yeSwgcmFuZ2UgNjQsIGJhc2UgMHhkNDQwMDAwMCwg c2l6ZSAyMCwgZW5hYmxlZApmb3VuZC0+CXZlbmRvcj0weDgwODYsIGRldj0weDI5MzcsIHJldmlk PTB4MDMKCWRvbWFpbj0wLCBidXM9MCwgc2xvdD0yNiwgZnVuYz0wCgljbGFzcz0wYy0wMy0wMCwg aGRydHlwZT0weDAwLCBtZmRldj0xCgljbWRyZWc9MHgwMDA1LCBzdGF0cmVnPTB4MDI5MCwgY2Fj aGVsbnN6PTAgKGR3b3JkcykKCWxhdHRpbWVyPTB4MDAgKDAgbnMpLCBtaW5nbnQ9MHgwMCAoMCBu cyksIG1heGxhdD0weDAwICgwIG5zKQoJaW50cGluPWEsIGlycT0xMQoJbWFwWzIwXTogdHlwZSBJ L08gUG9ydCwgcmFuZ2UgMzIsIGJhc2UgMHg1MGMwLCBzaXplICA1LCBlbmFibGVkCnBjaWIwOiBt YXRjaGVkIGVudHJ5IGZvciAwLjI2LklOVEEKcGNpYjA6IHNsb3QgMjYgSU5UQSBoYXJkd2lyZWQg dG8gSVJRIDE2CmZvdW5kLT4JdmVuZG9yPTB4ODA4NiwgZGV2PTB4MjkzOCwgcmV2aWQ9MHgwMwoJ ZG9tYWluPTAsIGJ1cz0wLCBzbG90PTI2LCBmdW5jPTEKCWNsYXNzPTBjLTAzLTAwLCBoZHJ0eXBl PTB4MDAsIG1mZGV2PTAKCWNtZHJlZz0weDAwMDUsIHN0YXRyZWc9MHgwMjkwLCBjYWNoZWxuc3o9 MCAoZHdvcmRzKQoJbGF0dGltZXI9MHgwMCAoMCBucyksIG1pbmdudD0weDAwICgwIG5zKSwgbWF4 bGF0PTB4MDAgKDAgbnMpCglpbnRwaW49YiwgaXJxPTEwCgltYXBbMjBdOiB0eXBlIEkvTyBQb3J0 LCByYW5nZSAzMiwgYmFzZSAweDUwYTAsIHNpemUgIDUsIGVuYWJsZWQKcGNpYjA6IG1hdGNoZWQg ZW50cnkgZm9yIDAuMjYuSU5UQgpwY2liMDogc2xvdCAyNiBJTlRCIGhhcmR3aXJlZCB0byBJUlEg MTcKZm91bmQtPgl2ZW5kb3I9MHg4MDg2LCBkZXY9MHgyOTNjLCByZXZpZD0weDAzCglkb21haW49 MCwgYnVzPTAsIHNsb3Q9MjYsIGZ1bmM9NwoJY2xhc3M9MGMtMDMtMjAsIGhkcnR5cGU9MHgwMCwg bWZkZXY9MAoJY21kcmVnPTB4MDAwNiwgc3RhdHJlZz0weDAyOTAsIGNhY2hlbG5zej0wIChkd29y ZHMpCglsYXR0aW1lcj0weDAwICgwIG5zKSwgbWluZ250PTB4MDAgKDAgbnMpLCBtYXhsYXQ9MHgw MCAoMCBucykKCWludHBpbj1jLCBpcnE9MTEKCXBvd2Vyc3BlYyAyICBzdXBwb3J0cyBEMCBEMyAg Y3VycmVudCBEMAoJbWFwWzEwXTogdHlwZSBNZW1vcnksIHJhbmdlIDMyLCBiYXNlIDB4ZDg1MDRj MDAsIHNpemUgMTAsIGVuYWJsZWQKcGNpYjA6IG1hdGNoZWQgZW50cnkgZm9yIDAuMjYuSU5UQwpw Y2liMDogc2xvdCAyNiBJTlRDIGhhcmR3aXJlZCB0byBJUlEgMTgKZm91bmQtPgl2ZW5kb3I9MHg4 MDg2LCBkZXY9MHgyOTNlLCByZXZpZD0weDAzCglkb21haW49MCwgYnVzPTAsIHNsb3Q9MjcsIGZ1 bmM9MAoJY2xhc3M9MDQtMDMtMDAsIGhkcnR5cGU9MHgwMCwgbWZkZXY9MAoJY21kcmVnPTB4MDAw Niwgc3RhdHJlZz0weDAwMTAsIGNhY2hlbG5zej0xNiAoZHdvcmRzKQoJbGF0dGltZXI9MHgwMCAo MCBucyksIG1pbmdudD0weDAwICgwIG5zKSwgbWF4bGF0PTB4MDAgKDAgbnMpCglpbnRwaW49Yiwg aXJxPTExCglwb3dlcnNwZWMgMiAgc3VwcG9ydHMgRDAgRDMgIGN1cnJlbnQgRDAKCU1TSSBzdXBw b3J0cyAxIG1lc3NhZ2UsIDY0IGJpdAoJbWFwWzEwXTogdHlwZSBNZW1vcnksIHJhbmdlIDY0LCBi YXNlIDB4ZDg1MDAwMDAsIHNpemUgMTQsIGVuYWJsZWQKcGNpYjA6IG1hdGNoZWQgZW50cnkgZm9y IDAuMjcuSU5UQgpwY2liMDogc2xvdCAyNyBJTlRCIGhhcmR3aXJlZCB0byBJUlEgMjIKZm91bmQt Pgl2ZW5kb3I9MHg4MDg2LCBkZXY9MHgyOTQwLCByZXZpZD0weDAzCglkb21haW49MCwgYnVzPTAs IHNsb3Q9MjgsIGZ1bmM9MAoJY2xhc3M9MDYtMDQtMDAsIGhkcnR5cGU9MHgwMSwgbWZkZXY9MQoJ Y21kcmVnPTB4MDAwNywgc3RhdHJlZz0weDAwMTAsIGNhY2hlbG5zej0wIChkd29yZHMpCglsYXR0 aW1lcj0weDAwICgwIG5zKSwgbWluZ250PTB4MDAgKDAgbnMpLCBtYXhsYXQ9MHgwMCAoMCBucykK CWludHBpbj1hLCBpcnE9MjU1Cglwb3dlcnNwZWMgMiAgc3VwcG9ydHMgRDAgRDMgIGN1cnJlbnQg RDAKCU1TSSBzdXBwb3J0cyAxIG1lc3NhZ2UKZm91bmQtPgl2ZW5kb3I9MHg4MDg2LCBkZXY9MHgy OTQ0LCByZXZpZD0weDAzCglkb21haW49MCwgYnVzPTAsIHNsb3Q9MjgsIGZ1bmM9MgoJY2xhc3M9 MDYtMDQtMDAsIGhkcnR5cGU9MHgwMSwgbWZkZXY9MQoJY21kcmVnPTB4MDAwNywgc3RhdHJlZz0w eDAwMTAsIGNhY2hlbG5zej0wIChkd29yZHMpCglsYXR0aW1lcj0weDAwICgwIG5zKSwgbWluZ250 PTB4MDAgKDAgbnMpLCBtYXhsYXQ9MHgwMCAoMCBucykKCWludHBpbj1jLCBpcnE9MjU1Cglwb3dl cnNwZWMgMiAgc3VwcG9ydHMgRDAgRDMgIGN1cnJlbnQgRDAKCU1TSSBzdXBwb3J0cyAxIG1lc3Nh Z2UKZm91bmQtPgl2ZW5kb3I9MHg4MDg2LCBkZXY9MHgyOTQ2LCByZXZpZD0weDAzCglkb21haW49 MCwgYnVzPTAsIHNsb3Q9MjgsIGZ1bmM9MwoJY2xhc3M9MDYtMDQtMDAsIGhkcnR5cGU9MHgwMSwg bWZkZXY9MQoJY21kcmVnPTB4MDAwNywgc3RhdHJlZz0weDAwMTAsIGNhY2hlbG5zej0wIChkd29y ZHMpCglsYXR0aW1lcj0weDAwICgwIG5zKSwgbWluZ250PTB4MDAgKDAgbnMpLCBtYXhsYXQ9MHgw MCAoMCBucykKCWludHBpbj1kLCBpcnE9MjU1Cglwb3dlcnNwZWMgMiAgc3VwcG9ydHMgRDAgRDMg IGN1cnJlbnQgRDAKCU1TSSBzdXBwb3J0cyAxIG1lc3NhZ2UKZm91bmQtPgl2ZW5kb3I9MHg4MDg2 LCBkZXY9MHgyOTRhLCByZXZpZD0weDAzCglkb21haW49MCwgYnVzPTAsIHNsb3Q9MjgsIGZ1bmM9 NQoJY2xhc3M9MDYtMDQtMDAsIGhkcnR5cGU9MHgwMSwgbWZkZXY9MQoJY21kcmVnPTB4MDAwNywg c3RhdHJlZz0weDAwMTAsIGNhY2hlbG5zej0wIChkd29yZHMpCglsYXR0aW1lcj0weDAwICgwIG5z KSwgbWluZ250PTB4MDAgKDAgbnMpLCBtYXhsYXQ9MHgwMCAoMCBucykKCWludHBpbj1iLCBpcnE9 MjU1Cglwb3dlcnNwZWMgMiAgc3VwcG9ydHMgRDAgRDMgIGN1cnJlbnQgRDAKCU1TSSBzdXBwb3J0 cyAxIG1lc3NhZ2UKZm91bmQtPgl2ZW5kb3I9MHg4MDg2LCBkZXY9MHgyOTM0LCByZXZpZD0weDAz Cglkb21haW49MCwgYnVzPTAsIHNsb3Q9MjksIGZ1bmM9MAoJY2xhc3M9MGMtMDMtMDAsIGhkcnR5 cGU9MHgwMCwgbWZkZXY9MQoJY21kcmVnPTB4MDAwNSwgc3RhdHJlZz0weDAyOTAsIGNhY2hlbG5z ej0wIChkd29yZHMpCglsYXR0aW1lcj0weDAwICgwIG5zKSwgbWluZ250PTB4MDAgKDAgbnMpLCBt YXhsYXQ9MHgwMCAoMCBucykKCWludHBpbj1hLCBpcnE9MTEKCW1hcFsyMF06IHR5cGUgSS9PIFBv cnQsIHJhbmdlIDMyLCBiYXNlIDB4NTA4MCwgc2l6ZSAgNSwgZW5hYmxlZApwY2liMDogbWF0Y2hl ZCBlbnRyeSBmb3IgMC4yOS5JTlRBCnBjaWIwOiBzbG90IDI5IElOVEEgaGFyZHdpcmVkIHRvIElS USAyMApmb3VuZC0+CXZlbmRvcj0weDgwODYsIGRldj0weDI5MzUsIHJldmlkPTB4MDMKCWRvbWFp bj0wLCBidXM9MCwgc2xvdD0yOSwgZnVuYz0xCgljbGFzcz0wYy0wMy0wMCwgaGRydHlwZT0weDAw LCBtZmRldj0wCgljbWRyZWc9MHgwMDA1LCBzdGF0cmVnPTB4MDI5MCwgY2FjaGVsbnN6PTAgKGR3 b3JkcykKCWxhdHRpbWVyPTB4MDAgKDAgbnMpLCBtaW5nbnQ9MHgwMCAoMCBucyksIG1heGxhdD0w eDAwICgwIG5zKQoJaW50cGluPWIsIGlycT0xMQoJbWFwWzIwXTogdHlwZSBJL08gUG9ydCwgcmFu Z2UgMzIsIGJhc2UgMHg1MDYwLCBzaXplICA1LCBlbmFibGVkCnBjaWIwOiBtYXRjaGVkIGVudHJ5 IGZvciAwLjI5LklOVEIKcGNpYjA6IHNsb3QgMjkgSU5UQiBoYXJkd2lyZWQgdG8gSVJRIDIyCmZv dW5kLT4JdmVuZG9yPTB4ODA4NiwgZGV2PTB4MjkzNiwgcmV2aWQ9MHgwMwoJZG9tYWluPTAsIGJ1 cz0wLCBzbG90PTI5LCBmdW5jPTIKCWNsYXNzPTBjLTAzLTAwLCBoZHJ0eXBlPTB4MDAsIG1mZGV2 PTAKCWNtZHJlZz0weDAwMDUsIHN0YXRyZWc9MHgwMjkwLCBjYWNoZWxuc3o9MCAoZHdvcmRzKQoJ bGF0dGltZXI9MHgwMCAoMCBucyksIG1pbmdudD0weDAwICgwIG5zKSwgbWF4bGF0PTB4MDAgKDAg bnMpCglpbnRwaW49YywgaXJxPTExCgltYXBbMjBdOiB0eXBlIEkvTyBQb3J0LCByYW5nZSAzMiwg YmFzZSAweDUwNDAsIHNpemUgIDUsIGVuYWJsZWQKcGNpYjA6IG1hdGNoZWQgZW50cnkgZm9yIDAu MjkuSU5UQwpwY2liMDogc2xvdCAyOSBJTlRDIGhhcmR3aXJlZCB0byBJUlEgMTgKZm91bmQtPgl2 ZW5kb3I9MHg4MDg2LCBkZXY9MHgyOTNhLCByZXZpZD0weDAzCglkb21haW49MCwgYnVzPTAsIHNs b3Q9MjksIGZ1bmM9NwoJY2xhc3M9MGMtMDMtMjAsIGhkcnR5cGU9MHgwMCwgbWZkZXY9MAoJY21k cmVnPTB4MDAwNiwgc3RhdHJlZz0weDAyOTAsIGNhY2hlbG5zej0wIChkd29yZHMpCglsYXR0aW1l cj0weDAwICgwIG5zKSwgbWluZ250PTB4MDAgKDAgbnMpLCBtYXhsYXQ9MHgwMCAoMCBucykKCWlu dHBpbj1hLCBpcnE9MTEKCXBvd2Vyc3BlYyAyICBzdXBwb3J0cyBEMCBEMyAgY3VycmVudCBEMAoJ bWFwWzEwXTogdHlwZSBNZW1vcnksIHJhbmdlIDMyLCBiYXNlIDB4ZDg1MDQ4MDAsIHNpemUgMTAs IGVuYWJsZWQKcGNpYjA6IG1hdGNoZWQgZW50cnkgZm9yIDAuMjkuSU5UQQpwY2liMDogc2xvdCAy OSBJTlRBIGhhcmR3aXJlZCB0byBJUlEgMjAKZm91bmQtPgl2ZW5kb3I9MHg4MDg2LCBkZXY9MHgy NDQ4LCByZXZpZD0weDkzCglkb21haW49MCwgYnVzPTAsIHNsb3Q9MzAsIGZ1bmM9MAoJY2xhc3M9 MDYtMDQtMDEsIGhkcnR5cGU9MHgwMSwgbWZkZXY9MAoJY21kcmVnPTB4MDAwNywgc3RhdHJlZz0w eDAwMTAsIGNhY2hlbG5zej0wIChkd29yZHMpCglsYXR0aW1lcj0weDAwICgwIG5zKSwgbWluZ250 PTB4MDAgKDAgbnMpLCBtYXhsYXQ9MHgwMCAoMCBucykKZm91bmQtPgl2ZW5kb3I9MHg4MDg2LCBk ZXY9MHgyOTE5LCByZXZpZD0weDAzCglkb21haW49MCwgYnVzPTAsIHNsb3Q9MzEsIGZ1bmM9MAoJ Y2xhc3M9MDYtMDEtMDAsIGhkcnR5cGU9MHgwMCwgbWZkZXY9MQoJY21kcmVnPTB4MDAwNywgc3Rh dHJlZz0weDAyMTAsIGNhY2hlbG5zej0wIChkd29yZHMpCglsYXR0aW1lcj0weDAwICgwIG5zKSwg bWluZ250PTB4MDAgKDAgbnMpLCBtYXhsYXQ9MHgwMCAoMCBucykKZm91bmQtPgl2ZW5kb3I9MHg4 MDg2LCBkZXY9MHgyOTI5LCByZXZpZD0weDAzCglkb21haW49MCwgYnVzPTAsIHNsb3Q9MzEsIGZ1 bmM9MgoJY2xhc3M9MDEtMDYtMDEsIGhkcnR5cGU9MHgwMCwgbWZkZXY9MAoJY21kcmVnPTB4MDAw Nywgc3RhdHJlZz0weDAyYjAsIGNhY2hlbG5zej0wIChkd29yZHMpCglsYXR0aW1lcj0weDAwICgw IG5zKSwgbWluZ250PTB4MDAgKDAgbnMpLCBtYXhsYXQ9MHgwMCAoMCBucykKCWludHBpbj1iLCBp cnE9MTEKCXBvd2Vyc3BlYyAzICBzdXBwb3J0cyBEMCBEMyAgY3VycmVudCBEMAoJTVNJIHN1cHBv cnRzIDE2IG1lc3NhZ2VzCgltYXBbMTBdOiB0eXBlIEkvTyBQb3J0LCByYW5nZSAzMiwgYmFzZSAw eDUwZTgsIHNpemUgIDMsIGVuYWJsZWQKCW1hcFsxNF06IHR5cGUgSS9PIFBvcnQsIHJhbmdlIDMy LCBiYXNlIDB4NTBmYywgc2l6ZSAgMiwgZW5hYmxlZAoJbWFwWzE4XTogdHlwZSBJL08gUG9ydCwg cmFuZ2UgMzIsIGJhc2UgMHg1MGUwLCBzaXplICAzLCBlbmFibGVkCgltYXBbMWNdOiB0eXBlIEkv TyBQb3J0LCByYW5nZSAzMiwgYmFzZSAweDUwZjgsIHNpemUgIDIsIGVuYWJsZWQKCW1hcFsyMF06 IHR5cGUgSS9PIFBvcnQsIHJhbmdlIDMyLCBiYXNlIDB4NTAyMCwgc2l6ZSAgNSwgZW5hYmxlZAoJ bWFwWzI0XTogdHlwZSBNZW1vcnksIHJhbmdlIDMyLCBiYXNlIDB4ZDg1MDQwMDAsIHNpemUgMTEs IGVuYWJsZWQKcGNpYjA6IG1hdGNoZWQgZW50cnkgZm9yIDAuMzEuSU5UQgpwY2liMDogc2xvdCAz MSBJTlRCIGhhcmR3aXJlZCB0byBJUlEgMjEKZm91bmQtPgl2ZW5kb3I9MHg4MDg2LCBkZXY9MHgy OTMwLCByZXZpZD0weDAzCglkb21haW49MCwgYnVzPTAsIHNsb3Q9MzEsIGZ1bmM9MwoJY2xhc3M9 MGMtMDUtMDAsIGhkcnR5cGU9MHgwMCwgbWZkZXY9MAoJY21kcmVnPTB4MDAwMywgc3RhdHJlZz0w eDAyODAsIGNhY2hlbG5zej0wIChkd29yZHMpCglsYXR0aW1lcj0weDAwICgwIG5zKSwgbWluZ250 PTB4MDAgKDAgbnMpLCBtYXhsYXQ9MHgwMCAoMCBucykKCWludHBpbj1jLCBpcnE9MTEKCW1hcFsx MF06IHR5cGUgTWVtb3J5LCByYW5nZSA2NCwgYmFzZSAweGQ4NTA1MDAwLCBzaXplICA4LCBlbmFi bGVkCgltYXBbMjBdOiB0eXBlIEkvTyBQb3J0LCByYW5nZSAzMiwgYmFzZSAweDUwMDAsIHNpemUg IDUsIGVuYWJsZWQKcGNpYjA6IG1hdGNoZWQgZW50cnkgZm9yIDAuMzEuSU5UQwpwY2liMDogc2xv dCAzMSBJTlRDIGhhcmR3aXJlZCB0byBJUlEgMTgKdmdhcGNpMDogPFZHQS1jb21wYXRpYmxlIGRp c3BsYXk+IHBvcnQgMHg1MGYwLTB4NTBmNyBtZW0gMHhkMDAwMDAwMC0weGQwM2ZmZmZmLDB4YzAw MDAwMDAtMHhjZmZmZmZmZiBpcnEgMTYgYXQgZGV2aWNlIDIuMCBvbiBwY2kwCmFncDA6IDxJbnRl bCBHTTQ1IFNWR0EgY29udHJvbGxlcj4gb24gdmdhcGNpMAp2Z2FwY2kwOiBSZXNlcnZlZCAweDEw MDAwMDAwIGJ5dGVzIGZvciByaWQgMHgxOCB0eXBlIDMgYXQgMHhjMDAwMDAwMAp2Z2FwY2kwOiBS ZXNlcnZlZCAweDQwMDAwMCBieXRlcyBmb3IgcmlkIDB4MTAgdHlwZSAzIGF0IDB4ZDAwMDAwMDAK YWdwMDogZGV0ZWN0ZWQgNjU1MzJrIHN0b2xlbiBtZW1vcnkKYWdwMDogYXBlcnR1cmUgc2l6ZSBp cyAyNTZNCnZnYXBjaTE6IDxWR0EtY29tcGF0aWJsZSBkaXNwbGF5PiBtZW0gMHhkNDQwMDAwMC0w eGQ0NGZmZmZmIGF0IGRldmljZSAyLjEgb24gcGNpMAp1aGNpMDogPEludGVsIDgyODAxSSAoSUNI OSkgVVNCIGNvbnRyb2xsZXI+IHBvcnQgMHg1MGMwLTB4NTBkZiBpcnEgMTYgYXQgZGV2aWNlIDI2 LjAgb24gcGNpMAp1aGNpMDogUmVzZXJ2ZWQgMHgyMCBieXRlcyBmb3IgcmlkIDB4MjAgdHlwZSA0 IGF0IDB4NTBjMAppb2FwaWMwOiByb3V0aW5nIGludHBpbiAxNiAoUENJIElSUSAxNikgdG8gbGFw aWMgMCB2ZWN0b3IgNDkKdWhjaTA6IFtNUFNBRkVdCnVoY2kwOiBbSVRIUkVBRF0KdWhjaTA6IExl Z1N1cCA9IDB4MGYxMAp1c2J1czA6IDxJbnRlbCA4MjgwMUkgKElDSDkpIFVTQiBjb250cm9sbGVy PiBvbiB1aGNpMAp1aGNpMTogPEludGVsIDgyODAxSSAoSUNIOSkgVVNCIGNvbnRyb2xsZXI+IHBv cnQgMHg1MGEwLTB4NTBiZiBpcnEgMTcgYXQgZGV2aWNlIDI2LjEgb24gcGNpMAp1aGNpMTogUmVz ZXJ2ZWQgMHgyMCBieXRlcyBmb3IgcmlkIDB4MjAgdHlwZSA0IGF0IDB4NTBhMAppb2FwaWMwOiBy b3V0aW5nIGludHBpbiAxNyAoUENJIElSUSAxNykgdG8gbGFwaWMgMCB2ZWN0b3IgNTAKdWhjaTE6 IFtNUFNBRkVdCnVoY2kxOiBbSVRIUkVBRF0KdWhjaTE6IExlZ1N1cCA9IDB4MGYwMAp1c2J1czE6 IDxJbnRlbCA4MjgwMUkgKElDSDkpIFVTQiBjb250cm9sbGVyPiBvbiB1aGNpMQplaGNpMDogPElu dGVsIDgyODAxSSAoSUNIOSkgVVNCIDIuMCBjb250cm9sbGVyPiBtZW0gMHhkODUwNGMwMC0weGQ4 NTA0ZmZmIGlycSAxOCBhdCBkZXZpY2UgMjYuNyBvbiBwY2kwCmVoY2kwOiBSZXNlcnZlZCAweDQw MCBieXRlcyBmb3IgcmlkIDB4MTAgdHlwZSAzIGF0IDB4ZDg1MDRjMDAKaW9hcGljMDogcm91dGlu ZyBpbnRwaW4gMTggKFBDSSBJUlEgMTgpIHRvIGxhcGljIDAgdmVjdG9yIDUxCmVoY2kwOiBbTVBT QUZFXQplaGNpMDogW0lUSFJFQURdCnVzYnVzMjogd2FpdGluZyBmb3IgQklPUyB0byBnaXZlIHVw IGNvbnRyb2wKdXNidXMyOiBFSENJIHZlcnNpb24gMS4wCnVzYnVzMjogPEludGVsIDgyODAxSSAo SUNIOSkgVVNCIDIuMCBjb250cm9sbGVyPiBvbiBlaGNpMApwY2kwOiA8bXVsdGltZWRpYSwgSERB PiBhdCBkZXZpY2UgMjcuMCAobm8gZHJpdmVyIGF0dGFjaGVkKQpwY2liMTogPEFDUEkgUENJLVBD SSBicmlkZ2U+IGF0IGRldmljZSAyOC4wIG9uIHBjaTAKcGNpYjE6ICAgZG9tYWluICAgICAgICAg ICAgMApwY2liMTogICBzZWNvbmRhcnkgYnVzICAgICAxCnBjaWIxOiAgIHN1Ym9yZGluYXRlIGJ1 cyAgIDEKcGNpYjE6ICAgSS9PIGRlY29kZSAgICAgICAgMHg0MDAwLTB4NGZmZgpwY2liMTogICBt ZW1vcnkgZGVjb2RlICAgICAweGQ3NTAwMDAwLTB4ZDg0ZmZmZmYKcGNpYjE6ICAgcHJlZmV0Y2hl ZCBkZWNvZGUgMHhkMDQwMDAwMC0weGQxM2ZmZmZmCnBjaTE6IDxBQ1BJIFBDSSBidXM+IG9uIHBj aWIxCnBjaTE6IGRvbWFpbj0wLCBwaHlzaWNhbCBidXM9MQpwY2liMjogPEFDUEkgUENJLVBDSSBi cmlkZ2U+IGF0IGRldmljZSAyOC4yIG9uIHBjaTAKcGNpYjI6ICAgZG9tYWluICAgICAgICAgICAg MApwY2liMjogICBzZWNvbmRhcnkgYnVzICAgICAyCnBjaWIyOiAgIHN1Ym9yZGluYXRlIGJ1cyAg IDIKcGNpYjI6ICAgSS9PIGRlY29kZSAgICAgICAgMHgzMDAwLTB4M2ZmZgpwY2liMjogICBtZW1v cnkgZGVjb2RlICAgICAweGQ2NTAwMDAwLTB4ZDc0ZmZmZmYKcGNpYjI6ICAgcHJlZmV0Y2hlZCBk ZWNvZGUgMHhkMTQwMDAwMC0weGQyM2ZmZmZmCnBjaTI6IDxBQ1BJIFBDSSBidXM+IG9uIHBjaWIy CnBjaTI6IGRvbWFpbj0wLCBwaHlzaWNhbCBidXM9Mgpmb3VuZC0+CXZlbmRvcj0weDE2OGMsIGRl dj0weDAwMmIsIHJldmlkPTB4MDEKCWRvbWFpbj0wLCBidXM9Miwgc2xvdD0wLCBmdW5jPTAKCWNs YXNzPTAyLTgwLTAwLCBoZHJ0eXBlPTB4MDAsIG1mZGV2PTAKCWNtZHJlZz0weDAwMDcsIHN0YXRy ZWc9MHgwMDEwLCBjYWNoZWxuc3o9MCAoZHdvcmRzKQoJbGF0dGltZXI9MHgwMCAoMCBucyksIG1p bmdudD0weDAwICgwIG5zKSwgbWF4bGF0PTB4MDAgKDAgbnMpCglpbnRwaW49YSwgaXJxPTExCglw b3dlcnNwZWMgMyAgc3VwcG9ydHMgRDAgRDEgRDMgIGN1cnJlbnQgRDAKCU1TSSBzdXBwb3J0cyAx IG1lc3NhZ2UKCW1hcFsxMF06IHR5cGUgTWVtb3J5LCByYW5nZSA2NCwgYmFzZSAweGQ2NTAwMDAw LCBzaXplIDE2LCBlbmFibGVkCnBjaWIyOiByZXF1ZXN0ZWQgbWVtb3J5IHJhbmdlIDB4ZDY1MDAw MDAtMHhkNjUwZmZmZjogZ29vZApwY2liMjogbWF0Y2hlZCBlbnRyeSBmb3IgMi4wLklOVEEKcGNp YjI6IHNsb3QgMCBJTlRBIGhhcmR3aXJlZCB0byBJUlEgMTgKcGNpMjogPG5ldHdvcms+IGF0IGRl dmljZSAwLjAgKG5vIGRyaXZlciBhdHRhY2hlZCkKcGNpYjM6IDxBQ1BJIFBDSS1QQ0kgYnJpZGdl PiBhdCBkZXZpY2UgMjguMyBvbiBwY2kwCnBjaWIzOiAgIGRvbWFpbiAgICAgICAgICAgIDAKcGNp YjM6ICAgc2Vjb25kYXJ5IGJ1cyAgICAgMwpwY2liMzogICBzdWJvcmRpbmF0ZSBidXMgICAzCnBj aWIzOiAgIEkvTyBkZWNvZGUgICAgICAgIDB4MjAwMC0weDJmZmYKcGNpYjM6ICAgbWVtb3J5IGRl Y29kZSAgICAgMHhkNTUwMDAwMC0weGQ2NGZmZmZmCnBjaWIzOiAgIHByZWZldGNoZWQgZGVjb2Rl IDB4ZDI0MDAwMDAtMHhkMzNmZmZmZgpwY2kzOiA8QUNQSSBQQ0kgYnVzPiBvbiBwY2liMwpwY2kz OiBkb21haW49MCwgcGh5c2ljYWwgYnVzPTMKZm91bmQtPgl2ZW5kb3I9MHgxMGVjLCBkZXY9MHg4 MTM2LCByZXZpZD0weDAyCglkb21haW49MCwgYnVzPTMsIHNsb3Q9MCwgZnVuYz0wCgljbGFzcz0w Mi0wMC0wMCwgaGRydHlwZT0weDAwLCBtZmRldj0wCgljbWRyZWc9MHgwMDA3LCBzdGF0cmVnPTB4 MDAxMCwgY2FjaGVsbnN6PTAgKGR3b3JkcykKCWxhdHRpbWVyPTB4MDAgKDAgbnMpLCBtaW5nbnQ9 MHgwMCAoMCBucyksIG1heGxhdD0weDAwICgwIG5zKQoJaW50cGluPWEsIGlycT0xMQoJcG93ZXJz cGVjIDMgIHN1cHBvcnRzIEQwIEQxIEQyIEQzICBjdXJyZW50IEQwCglNU0kgc3VwcG9ydHMgMSBt ZXNzYWdlLCA2NCBiaXQKCU1TSS1YIHN1cHBvcnRzIDIgbWVzc2FnZXMgaW4gbWFwIDB4MjAKCW1h cFsxMF06IHR5cGUgSS9PIFBvcnQsIHJhbmdlIDMyLCBiYXNlIDB4MjAwMCwgc2l6ZSAgOCwgZW5h YmxlZApwY2liMzogcmVxdWVzdGVkIEkvTyByYW5nZSAweDIwMDAtMHgyMGZmOiBpbiByYW5nZQoJ bWFwWzE4XTogdHlwZSBQcmVmZXRjaGFibGUgTWVtb3J5LCByYW5nZSA2NCwgYmFzZSAweGQyNDEw MDAwLCBzaXplIDEyLCBlbmFibGVkCnBjaWIzOiByZXF1ZXN0ZWQgbWVtb3J5IHJhbmdlIDB4ZDI0 MTAwMDAtMHhkMjQxMGZmZjogZ29vZAoJbWFwWzIwXTogdHlwZSBQcmVmZXRjaGFibGUgTWVtb3J5 LCByYW5nZSA2NCwgYmFzZSAweGQyNDAwMDAwLCBzaXplIDE2LCBlbmFibGVkCnBjaWIzOiByZXF1 ZXN0ZWQgbWVtb3J5IHJhbmdlIDB4ZDI0MDAwMDAtMHhkMjQwZmZmZjogZ29vZApwY2liMzogbWF0 Y2hlZCBlbnRyeSBmb3IgMy4wLklOVEEKcGNpYjM6IHNsb3QgMCBJTlRBIGhhcmR3aXJlZCB0byBJ UlEgMTkKcmUwOiA8UmVhbFRlayA4MTAxRS84MTAyRS84MTAyRUwgUENJZSAxMC8xMDBiYXNlVFg+ IHBvcnQgMHgyMDAwLTB4MjBmZiBtZW0gMHhkMjQxMDAwMC0weGQyNDEwZmZmLDB4ZDI0MDAwMDAt MHhkMjQwZmZmZiBpcnEgMTkgYXQgZGV2aWNlIDAuMCBvbiBwY2kzCnJlMDogUmVzZXJ2ZWQgMHgx MDAwIGJ5dGVzIGZvciByaWQgMHgxOCB0eXBlIDMgYXQgMHhkMjQxMDAwMApyZTA6IE1TSSBjb3Vu dCA6IDEKcmUwOiBhdHRlbXB0aW5nIHRvIGFsbG9jYXRlIDEgTVNJIHZlY3RvcnMgKDEgc3VwcG9y dGVkKQptc2k6IHJvdXRpbmcgTVNJIElSUSAyNTYgdG8gbG9jYWwgQVBJQyAwIHZlY3RvciA1Mgpy ZTA6IHVzaW5nIElSUSAyNTYgZm9yIE1TSQpyZTA6IFVzaW5nIDEgTVNJIG1lc3NhZ2VzCnJlMDog Q2hpcCByZXYuIDB4MjQ4MDAwMDAKcmUwOiBNQUMgcmV2LiAweDAwNDAwMDAwCm1paWJ1czA6IDxN SUkgYnVzPiBvbiByZTAKcmxwaHkwOiA8UlRMODIwMUwgMTAvMTAwIG1lZGlhIGludGVyZmFjZT4g UEhZIDEgb24gbWlpYnVzMApybHBoeTA6ICAxMGJhc2VULCAxMGJhc2VULUZEWCwgMTAwYmFzZVRY LCAxMDBiYXNlVFgtRkRYLCBhdXRvCnJlMDogYnBmIGF0dGFjaGVkCnJlMDogRXRoZXJuZXQgYWRk cmVzczogMDA6MjM6NWE6YTI6YmQ6NTQKcmUwOiBbTVBTQUZFXQpyZTA6IFtGSUxURVJdCnBjaWI0 OiA8QUNQSSBQQ0ktUENJIGJyaWRnZT4gYXQgZGV2aWNlIDI4LjUgb24gcGNpMApwY2liNDogICBk b21haW4gICAgICAgICAgICAwCnBjaWI0OiAgIHNlY29uZGFyeSBidXMgICAgIDQKcGNpYjQ6ICAg c3Vib3JkaW5hdGUgYnVzICAgNgpwY2liNDogICBJL08gZGVjb2RlICAgICAgICAweDEwMDAtMHgx ZmZmCnBjaWI0OiAgIG1lbW9yeSBkZWNvZGUgICAgIDB4ZDQ1MDAwMDAtMHhkNTRmZmZmZgpwY2li NDogICBwcmVmZXRjaGVkIGRlY29kZSAweGQzNDAwMDAwLTB4ZDQzZmZmZmYKcGNpNDogPEFDUEkg UENJIGJ1cz4gb24gcGNpYjQKcGNpNDogZG9tYWluPTAsIHBoeXNpY2FsIGJ1cz00CnVoY2kyOiA8 SW50ZWwgODI4MDFJIChJQ0g5KSBVU0IgY29udHJvbGxlcj4gcG9ydCAweDUwODAtMHg1MDlmIGly cSAyMCBhdCBkZXZpY2UgMjkuMCBvbiBwY2kwCnVoY2kyOiBSZXNlcnZlZCAweDIwIGJ5dGVzIGZv ciByaWQgMHgyMCB0eXBlIDQgYXQgMHg1MDgwCmlvYXBpYzA6IHJvdXRpbmcgaW50cGluIDIwIChQ Q0kgSVJRIDIwKSB0byBsYXBpYyAwIHZlY3RvciA1Mwp1aGNpMjogW01QU0FGRV0KdWhjaTI6IFtJ VEhSRUFEXQp1aGNpMjogTGVnU3VwID0gMHgwZjAwCnVzYnVzMzogPEludGVsIDgyODAxSSAoSUNI OSkgVVNCIGNvbnRyb2xsZXI+IG9uIHVoY2kyCnVoY2kzOiA8SW50ZWwgODI4MDFJIChJQ0g5KSBV U0IgY29udHJvbGxlcj4gcG9ydCAweDUwNjAtMHg1MDdmIGlycSAyMiBhdCBkZXZpY2UgMjkuMSBv biBwY2kwCnVoY2kzOiBSZXNlcnZlZCAweDIwIGJ5dGVzIGZvciByaWQgMHgyMCB0eXBlIDQgYXQg MHg1MDYwCmlvYXBpYzA6IHJvdXRpbmcgaW50cGluIDIyIChQQ0kgSVJRIDIyKSB0byBsYXBpYyAw IHZlY3RvciA1NAp1aGNpMzogW01QU0FGRV0KdWhjaTM6IFtJVEhSRUFEXQp1aGNpMzogTGVnU3Vw ID0gMHgwZjEwCnVzYnVzNDogPEludGVsIDgyODAxSSAoSUNIOSkgVVNCIGNvbnRyb2xsZXI+IG9u IHVoY2kzCnVoY2k0OiA8SW50ZWwgODI4MDFJIChJQ0g5KSBVU0IgY29udHJvbGxlcj4gcG9ydCAw eDUwNDAtMHg1MDVmIGlycSAxOCBhdCBkZXZpY2UgMjkuMiBvbiBwY2kwCnVoY2k0OiBSZXNlcnZl ZCAweDIwIGJ5dGVzIGZvciByaWQgMHgyMCB0eXBlIDQgYXQgMHg1MDQwCnVoY2k0OiBbTVBTQUZF XQp1aGNpNDogW0lUSFJFQURdCnVoY2k0OiBMZWdTdXAgPSAweDBmMDAKdXNidXM1OiA8SW50ZWwg ODI4MDFJIChJQ0g5KSBVU0IgY29udHJvbGxlcj4gb24gdWhjaTQKZWhjaTE6IDxJbnRlbCA4Mjgw MUkgKElDSDkpIFVTQiAyLjAgY29udHJvbGxlcj4gbWVtIDB4ZDg1MDQ4MDAtMHhkODUwNGJmZiBp cnEgMjAgYXQgZGV2aWNlIDI5Ljcgb24gcGNpMAplaGNpMTogUmVzZXJ2ZWQgMHg0MDAgYnl0ZXMg Zm9yIHJpZCAweDEwIHR5cGUgMyBhdCAweGQ4NTA0ODAwCmVoY2kxOiBbTVBTQUZFXQplaGNpMTog W0lUSFJFQURdCnVzYnVzNjogd2FpdGluZyBmb3IgQklPUyB0byBnaXZlIHVwIGNvbnRyb2wKdXNi dXM2OiBFSENJIHZlcnNpb24gMS4wCnVzYnVzNjogPEludGVsIDgyODAxSSAoSUNIOSkgVVNCIDIu MCBjb250cm9sbGVyPiBvbiBlaGNpMQpwY2liNTogPEFDUEkgUENJLVBDSSBicmlkZ2U+IGF0IGRl dmljZSAzMC4wIG9uIHBjaTAKcGNpYjU6ICAgZG9tYWluICAgICAgICAgICAgMApwY2liNTogICBz ZWNvbmRhcnkgYnVzICAgICA3CnBjaWI1OiAgIHN1Ym9yZGluYXRlIGJ1cyAgIDcKcGNpYjU6ICAg SS9PIGRlY29kZSAgICAgICAgMHhmMDAwLTB4ZmZmCnBjaWI1OiAgIG5vIHByZWZldGNoZWQgZGVj b2RlCnBjaWI1OiAgIFN1YnRyYWN0aXZlbHkgZGVjb2RlZCBicmlkZ2UuCnBjaTc6IDxBQ1BJIFBD SSBidXM+IG9uIHBjaWI1CnBjaTc6IGRvbWFpbj0wLCBwaHlzaWNhbCBidXM9Nwppc2FiMDogPFBD SS1JU0EgYnJpZGdlPiBhdCBkZXZpY2UgMzEuMCBvbiBwY2kwCmlzYTA6IDxJU0EgYnVzPiBvbiBp c2FiMAphdGFwY2kwOiA8SW50ZWwgKElEPTI5Mjk4MDg2KSBBSENJIGNvbnRyb2xsZXI+IHBvcnQg MHg1MGU4LTB4NTBlZiwweDUwZmMtMHg1MGZmLDB4NTBlMC0weDUwZTcsMHg1MGY4LTB4NTBmYiww eDUwMjAtMHg1MDNmIG1lbSAweGQ4NTA0MDAwLTB4ZDg1MDQ3ZmYgaXJxIDIxIGF0IGRldmljZSAz MS4yIG9uIHBjaTAKYXRhcGNpMDogUmVzZXJ2ZWQgMHgyMCBieXRlcyBmb3IgcmlkIDB4MjAgdHlw ZSA0IGF0IDB4NTAyMAphdGFwY2kwOiBSZXNlcnZlZCAweDgwMCBieXRlcyBmb3IgcmlkIDB4MjQg dHlwZSAzIGF0IDB4ZDg1MDQwMDAKaW9hcGljMDogcm91dGluZyBpbnRwaW4gMjEgKFBDSSBJUlEg MjEpIHRvIGxhcGljIDAgdmVjdG9yIDU1CmF0YXBjaTA6IFtNUFNBRkVdCmF0YXBjaTA6IFtJVEhS RUFEXQphdGFwY2kwOiBBSENJIHYxLjIwIGNvbnRyb2xsZXIgd2l0aCA0IDNHYnBzIHBvcnRzLCBQ TSBzdXBwb3J0ZWQKYXRhcGNpMDogQ2FwczogNjRiaXQgTkNRIFNOVEYgU1MgQUxQIEFMIENMTyAz R2JwcyBQTSBQTUQgU1NDIFBTQyAzMmNtZCBDQ0MgRU0gZVNBVEEgNHBvcnRzCmF0YTI6IDxBVEEg Y2hhbm5lbCAwPiBvbiBhdGFwY2kwCmF0YTI6IEFIQ0kgcmVzZXQuLi4KYXRhMjogaGFyZHdhcmUg cmVzZXQgLi4uCmF0YTI6IFNBVEEgY29ubmVjdCB0aW1lPTBtcyBzdGF0dXM9MDAwMDAxMjMKYXRh MjogcmVhZHkgd2FpdCB0aW1lPTRtcwphdGEyOiBzb2Z0d2FyZSByZXNldCBwb3J0IDE1Li4uCmF0 YTI6IHJlYWR5IHdhaXQgdGltZT0wbXMKYXRhMjogU0lHTkFUVVJFOiAwMDAwMDEwMQphdGEyOiBB SENJIHJlc2V0IGRvbmU6IGRldmljZXM9MDAwMDAwMDEKYXRhMjogW01QU0FGRV0KYXRhMjogW0lU SFJFQURdCmF0YTM6IDxBVEEgY2hhbm5lbCA0PiBvbiBhdGFwY2kwCmF0YTM6IEFIQ0kgcmVzZXQu Li4KYXRhMzogaGFyZHdhcmUgcmVzZXQgLi4uCmF0YTM6IFNBVEEgY29ubmVjdCB0aW1lPTEwbXMg c3RhdHVzPTAwMDAwMTEzCmF0YTM6IHJlYWR5IHdhaXQgdGltZT0wbXMKYXRhMzogc29mdHdhcmUg cmVzZXQgcG9ydCAxNS4uLgphdGEzOiByZWFkeSB3YWl0IHRpbWU9MG1zCmF0YTM6IFNJR05BVFVS RTogZWIxNDAxMDEKYXRhMzogQUhDSSByZXNldCBkb25lOiBkZXZpY2VzPTAwMDEwMDAwCmF0YTM6 IFtNUFNBRkVdCmF0YTM6IFtJVEhSRUFEXQphdGE0OiA8QVRBIGNoYW5uZWwgNT4gb24gYXRhcGNp MAphdGE0OiBBSENJIHJlc2V0Li4uCmF0YTQ6IGhhcmR3YXJlIHJlc2V0IC4uLgphdGE0OiBTQVRB IGNvbm5lY3QgdGltZW91dCBzdGF0dXM9MDAwMDAwMDAKYXRhNDogQUhDSSByZXNldCBkb25lOiBw aHkgcmVzZXQgZm91bmQgbm8gZGV2aWNlCmF0YTQ6IFtNUFNBRkVdCmF0YTQ6IFtJVEhSRUFEXQpw Y2kwOiA8c2VyaWFsIGJ1cywgU01CdXM+IGF0IGRldmljZSAzMS4zIChubyBkcml2ZXIgYXR0YWNo ZWQpCmFjcGlfdHowOiA8VGhlcm1hbCBab25lPiBvbiBhY3BpMAphdHJ0YzA6IDxBVCByZWFsdGlt ZSBjbG9jaz4gcG9ydCAweDcwLTB4Nzcgb24gYWNwaTAKYXRydGMwOiBXYXJuaW5nOiBDb3VsZG4n dCBtYXAgSS9PLgphdHJ0YzA6IHJlZ2lzdGVyZWQgYXMgYSB0aW1lLW9mLWRheSBjbG9jayAocmVz b2x1dGlvbiAxMDAwMDAwdXMpCmF0a2JkYzA6IDxLZXlib2FyZCBjb250cm9sbGVyIChpODA0Mik+ IHBvcnQgMHg2MCwweDY0IGlycSAxIG9uIGFjcGkwCmF0a2JkMDogPEFUIEtleWJvYXJkPiBpcnEg MSBvbiBhdGtiZGMwCmF0a2JkOiB0aGUgY3VycmVudCBrYmQgY29udHJvbGxlciBjb21tYW5kIGJ5 dGUgMDA2NwphdGtiZDoga2V5Ym9hcmQgSUQgMHg0MWFiICgyKQprYmQwIGF0IGF0a2JkMAprYmQw OiBhdGtiZDAsIEFUIDEwMS8xMDIgKDIpLCBjb25maWc6MHgwLCBmbGFnczoweDNkMDAwMAppb2Fw aWMwOiByb3V0aW5nIGludHBpbiAxIChJU0EgSVJRIDEpIHRvIGxhcGljIDAgdmVjdG9yIDU2CmF0 a2JkMDogW0dJQU5ULUxPQ0tFRF0KYXRrYmQwOiBbSVRIUkVBRF0KcHNtMDogdW5hYmxlIHRvIGFs bG9jYXRlIElSUQpwc21jcG5wMDogPFBTLzIgbW91c2UgcG9ydD4gaXJxIDEyIG9uIGFjcGkwCnBz bTA6IGN1cnJlbnQgY29tbWFuZCBieXRlOjAwNjcKcHNtMDogPFBTLzIgTW91c2U+IGlycSAxMiBv biBhdGtiZGMwCmlvYXBpYzA6IHJvdXRpbmcgaW50cGluIDEyIChJU0EgSVJRIDEyKSB0byBsYXBp YyAwIHZlY3RvciA1Nwpwc20wOiBbR0lBTlQtTE9DS0VEXQpwc20wOiBbSVRIUkVBRF0KcHNtMDog bW9kZWwgR2VuZXJpYyBQUy8yIG1vdXNlLCBkZXZpY2UgSUQgMC0wMCwgMiBidXR0b25zCnBzbTA6 IGNvbmZpZzowMDAwMDAwMCwgZmxhZ3M6MDAwMDAwMDgsIHBhY2tldCBzaXplOjMKcHNtMDogc3lu Y21hc2s6YzAsIHN5bmNiaXRzOjAwCmNwdTA6IDxBQ1BJIENQVT4gb24gYWNwaTAKQUNQSTogU1NE VCAweGI5ZTZlYzk4IDAwMjIzICh2MSAgUG1SZWYgIENwdTBJc3QgMDAwMDMwMDAgSU5UTCAyMDA1 MTExNykKQUNQSTogU1NEVCAweGI5ZTZjNjE4IDAwNUIzICh2MSAgUG1SZWYgIENwdTBDc3QgMDAw MDMwMDEgSU5UTCAyMDA1MTExNykKZXN0MDogPEVuaGFuY2VkIFNwZWVkU3RlcCBGcmVxdWVuY3kg Q29udHJvbD4gb24gY3B1MAplc3QwOiBJbnZhbGlkIGlkMTYgKHNldCwgY3VyKSA9ICgyMDczLCAx ODk3OSkKZXN0MDogSW52YWxpZCBmcmVxIDE2MDAsIGlnbm9yZWQuCmVzdDA6IEludmFsaWQgaWQx NiAoc2V0LCBjdXIpID0gKDE1NTMsIDE4OTc5KQplc3QwOiBJbnZhbGlkIGZyZXEgMTIwMCwgaWdu b3JlZC4KcDR0Y2MwOiA8Q1BVIEZyZXF1ZW5jeSBUaGVybWFsIENvbnRyb2w+IG9uIGNwdTAKY3B1 MTogPEFDUEkgQ1BVPiBvbiBhY3BpMApBQ1BJOiBTU0RUIDB4YjllNmRlMTggMDAxQ0YgKHYxICBQ bVJlZiAgICBBcElzdCAwMDAwMzAwMCBJTlRMIDIwMDUxMTE3KQpBQ1BJOiBTU0RUIDB4YjllNmVm MTggMDAwOEQgKHYxICBQbVJlZiAgICBBcENzdCAwMDAwMzAwMCBJTlRMIDIwMDUxMTE3KQplc3Qx OiA8RW5oYW5jZWQgU3BlZWRTdGVwIEZyZXF1ZW5jeSBDb250cm9sPiBvbiBjcHUxCmVzdDE6IElu dmFsaWQgaWQxNiAoc2V0LCBjdXIpID0gKDIwNzMsIDE4OTc5KQplc3QxOiBJbnZhbGlkIGZyZXEg MTYwMCwgaWdub3JlZC4KZXN0MTogSW52YWxpZCBpZDE2IChzZXQsIGN1cikgPSAoMTU1MywgMTg5 NzkpCmVzdDE6IEludmFsaWQgZnJlcSAxMjAwLCBpZ25vcmVkLgpwNHRjYzE6IDxDUFUgRnJlcXVl bmN5IFRoZXJtYWwgQ29udHJvbD4gb24gY3B1MQpleF9pc2FfaWRlbnRpZnkoKQppc2FfcHJvYmVf Y2hpbGRyZW46IGRpc2FibGluZyBQblAgZGV2aWNlcwphdGtiZGM6IGF0a2JkYzAgYWxyZWFkeSBl eGlzdHM7IHNraXBwaW5nIGl0CmF0cnRjOiBhdHJ0YzAgYWxyZWFkeSBleGlzdHM7IHNraXBwaW5n IGl0CnNjOiBzYzAgYWxyZWFkeSBleGlzdHM7IHNraXBwaW5nIGl0CmlzYV9wcm9iZV9jaGlsZHJl bjogcHJvYmluZyBub24tUG5QIGRldmljZXMKb3JtMDogPElTQSBPcHRpb24gUk9NPiBhdCBpb21l bSAweGMwMDAwLTB4Y2Y3ZmYgb24gaXNhMApzYzA6IDxTeXN0ZW0gY29uc29sZT4gYXQgZmxhZ3Mg MHgxMDAgb24gaXNhMApzYzA6IFZHQSA8MTYgdmlydHVhbCBjb25zb2xlcywgZmxhZ3M9MHgzMDA+ CnNjMDogZmIwLCBrYmQxLCB0ZXJtaW5hbCBlbXVsYXRvcjogc2N0ZWtlbiAodGVrZW4gdGVybWlu YWwpCnZnYTA6IDxHZW5lcmljIElTQSBWR0E+IGF0IHBvcnQgMHgzYzAtMHgzZGYgaW9tZW0gMHhh MDAwMC0weGJmZmZmIG9uIGlzYTAKZmRjMCBmYWlsZWQgdG8gcHJvYmUgYXQgcG9ydCAweDNmMC0w eDNmNSwweDNmNyBpcnEgNiBkcnEgMiBvbiBpc2EwCnBwYzA6IGNhbm5vdCByZXNlcnZlIEkvTyBw b3J0IHJhbmdlCnBwYzA6IDxQYXJhbGxlbCBwb3J0PiBmYWlsZWQgdG8gcHJvYmUgYXQgaXJxIDcg b24gaXNhMAp1YXJ0MDogPG5zODI1MD4gZmFpbGVkIHRvIHByb2JlIGF0IHBvcnQgMHgzZjgtMHgz ZmYgaXJxIDQgb24gaXNhMAp1YXJ0MTogPG5zODI1MD4gZmFpbGVkIHRvIHByb2JlIGF0IHBvcnQg MHgyZjgtMHgyZmYgaXJxIDMgb24gaXNhMAppc2FfcHJvYmVfY2hpbGRyZW46IHByb2JpbmcgUG5Q IGRldmljZXMKRGV2aWNlIGNvbmZpZ3VyYXRpb24gZmluaXNoZWQuClJlZHVjaW5nIGtlcm4ubWF4 dm5vZGVzIDI1MTYxMCAtPiAxMDAwMDAKcHJvY2ZzIHJlZ2lzdGVyZWQKbGFwaWM6IERpdmlzb3Ig MiwgRnJlcXVlbmN5IDk5OTUwMDY5IGh6ClRpbWVjb3VudGVyICJUU0MiIGZyZXF1ZW5jeSAyMDk4 OTUxMjYwIEh6IHF1YWxpdHkgLTEwMApUaW1lY291bnRlcnMgdGljayBldmVyeSAxLjAwMCBtc2Vj CmxvMDogYnBmIGF0dGFjaGVkCmhwdHJyOiBubyBjb250cm9sbGVyIGRldGVjdGVkLgphdGEyOiBJ ZGVudGlmeWluZyBkZXZpY2VzOiAwMDAwMDAwMQphdGEyOiBOZXcgZGV2aWNlczogMDAwMDAwMDEK dXNidXMwOiAxMk1icHMgRnVsbCBTcGVlZCBVU0IgdjEuMAp1c2J1czE6IDEyTWJwcyBGdWxsIFNw ZWVkIFVTQiB2MS4wCnVzYnVzMjogNDgwTWJwcyBIaWdoIFNwZWVkIFVTQiB2Mi4wCnVzYnVzMzog MTJNYnBzIEZ1bGwgU3BlZWQgVVNCIHYxLjAKdXNidXM0OiAxMk1icHMgRnVsbCBTcGVlZCBVU0Ig djEuMAp1c2J1czU6IDEyTWJwcyBGdWxsIFNwZWVkIFVTQiB2MS4wCnVzYnVzNjogNDgwTWJwcyBI aWdoIFNwZWVkIFVTQiB2Mi4wCmJhdHRlcnkwOiBiYXR0ZXJ5IGluaXRpYWxpemF0aW9uIHN0YXJ0 CmFjcGlfYWNhZDA6IGFjbGluZSBpbml0aWFsaXphdGlvbiBzdGFydAphdGEyLW1hc3RlcjogcGlv PVBJTzQgd2RtYT1XRE1BMiB1ZG1hPVVETUExMDAgY2FibGU9NDAgd2lyZWFjcGlfdHowOiBfQUMw OiB0ZW1wZXJhdHVyZSA2OS4wID49IHNldHBvaW50IDY5LjAKCmFkNDogNDc2OTQwTUIgPFNlYWdh dGUgU1Q5NTAwMzI1QVMgMDAwM0hQTTE+IGF0IGF0YTItbWFzdGVyIFNBVEEzMDAKYWQ0OiA5NzY3 NzMxNjggc2VjdG9ycyBbOTY5MDIxQy8xNkgvNjNTXSAxNiBzZWN0b3JzL2ludGVycnVwdCAxIGRl cHRoIHF1ZXVlCkdFT006IG5ldyBkaXNrIGFkNAp1Z2VuMC4xOiA8SW50ZWw+IGF0IHVzYnVzMAp1 aHViMDogPEludGVsIFVIQ0kgcm9vdCBIVUIsIGNsYXNzIDkvMCwgcmV2IDEuMDAvMS4wMCwgYWRk ciAxPiBvbiB1c2J1czAKdWdlbjEuMTogPEludGVsPiBhdCB1c2J1czEKdWh1YjE6IDxJbnRlbCBV SENJIHJvb3QgSFVCLCBjbGFzcyA5LzAsIHJldiAxLjAwLzEuMDAsIGFkZHIgMT4gb24gdXNidXMx CnVnZW4yLjE6IDxJbnRlbD4gYXQgdXNidXMyCnVodWIyOiA8SW50ZWwgRUhDSSByb290IEhVQiwg Y2xhc3MgOS8wLCByZXYgMi4wMC8xLjAwLCBhZGRyIDE+IG9uIHVzYnVzMgp1Z2VuMy4xOiA8SW50 ZWw+IGF0IHVzYnVzMwp1aHViMzogPEludGVsIFVIQ0kgcm9vdCBIVUIsIGNsYXNzIDkvMCwgcmV2 IDEuMDAvMS4wMCwgYWRkciAxPiBvbiB1c2J1czMKdWdlbjQuMTogPEludGVsPiBhdCB1c2J1czQK dWh1YjQ6IDxJbnRlbCBVSENJIHJvb3QgSFVCLCBjbGFzcyA5LzAsIHJldiAxLjAwLzEuMDAsIGFk ZHIgMT4gb24gdXNidXM0CnVnZW41LjE6IDxJbnRlbD4gYXQgdXNidXM1CnVodWI1OiA8SW50ZWwg VUhDSSByb290IEhVQiwgY2xhc3MgOS8wLCByZXYgMS4wMC8xLjAwLCBhZGRyIDE+IG9uIHVzYnVz NQp1Z2VuNi4xOiA8SW50ZWw+IGF0IHVzYnVzNgp1aHViNjogPEludGVsIEVIQ0kgcm9vdCBIVUIs IGNsYXNzIDkvMCwgcmV2IDIuMDAvMS4wMCwgYWRkciAxPiBvbiB1c2J1czYKYWNwaV90ejA6IHN3 aXRjaGVkIGZyb20gTk9ORSB0byBfQUMwOiA2OS4wQwphY3BpX2FjYWQwOiBPbiBMaW5lCmFjcGlf YWNhZDA6IGFjbGluZSBpbml0aWFsaXphdGlvbiBkb25lLCB0cmllZCAxIHRpbWVzCmFkNDogSW50 ZWwgY2hlY2sxIGZhaWxlZAphZDQ6IEFkYXB0ZWMgY2hlY2sxIGZhaWxlZAphZDQ6IExTSSAodjMp IGNoZWNrMSBmYWlsZWQKYWQ0OiBMU0kgKHYyKSBjaGVjazEgZmFpbGVkCmFkNDogRnJlZUJTRCBj aGVjazEgZmFpbGVkCmF0YTM6IElkZW50aWZ5aW5nIGRldmljZXM6IDAwMDEwMDAwCmF0YTM6IE5l dyBkZXZpY2VzOiAwMDAxMDAwMAphdGEzLW1hc3RlcjogcGlvPVBJTzQgd2RtYT1XRE1BMiB1ZG1h PVVETUExMDAgY2FibGU9NDAgd2lyZQphdGEzOiBkZXZpY2VfcmVzZXQgdGltZW91dD0xMzEwdXMK YWNkMDogPEhMLURULVNUIERWRFJBTSBHVDIwTC9EQzAzPiBEVkRSIGRyaXZlIGF0IGF0YTMgYXMg bWFzdGVyCmFjZDA6IHJlYWQgMTA4MjBLQi9zICgxMDgyMEtCL3MpIHdyaXRlIDI3MDVLQi9zICgy NzA1S0IvcyksIDEwMjRLQiBidWZmZXIsIFNBVEExNTAKYWNkMDogUmVhZHM6IENEUiwgQ0RSVywg Q0REQSBzdHJlYW0sIERWRFJPTSwgRFZEUiwgRFZEUkFNLCBwYWNrZXQKYWNkMDogV3JpdGVzOiBD RFIsIENEUlcsIERWRFIsIERWRFJBTSwgdGVzdCB3cml0ZSwgYnVybnByb29mCmFjZDA6IEF1ZGlv OiBwbGF5LCAyNTYgdm9sdW1lIGxldmVscwphY2QwOiBNZWNoYW5pc206IGVqZWN0YWJsZSB0cmF5 LCB1bmxvY2tlZAphY2QwOiBNZWRpdW06IERWRCAxMjBtbSBkYXRhIGRpc2MKYXRhNDogSWRlbnRp ZnlpbmcgZGV2aWNlczogMDAwMDAwMDAKYXRhNDogTmV3IGRldmljZXM6IDAwMDAwMDAwCkFUQSBQ c2V1ZG9SQUlEIGxvYWRlZApTTVA6IEFQIENQVSAjMSBMYXVuY2hlZCEKY3B1MSBBUDoKICAgICBJ RDogMHgwMTAwMDAwMCAgIFZFUjogMHgwMDA1MDAxNCBMRFI6IDB4MDAwMDAwMDAgREZSOiAweGZm ZmZmZmZmCiAgbGludDA6IDB4MDAwMTA3MDAgbGludDE6IDB4MDAwMDA0MDAgVFBSOiAweDAwMDAw MDAwIFNWUjogMHgwMDAwMDFmZgogIHRpbWVyOiAweDAwMDIwMGVmIHRoZXJtOiAweDAwMDEwMDAw IGVycjogMHgwMDAxMDAwMCBwY206IDB4MDAwMTA0MDAKaW9hcGljMDogcm91dGluZyBpbnRwaW4g OSAoSVNBIElSUSA5KSB0byBsYXBpYyAxIHZlY3RvciA0OAppb2FwaWMwOiByb3V0aW5nIGludHBp biAxNiAoUENJIElSUSAxNikgdG8gbGFwaWMgMSB2ZWN0b3IgNDkKaW9hcGljMDogcm91dGluZyBp bnRwaW4gMTggKFBDSSBJUlEgMTgpIHRvIGxhcGljIDEgdmVjdG9yIDUwCmlvYXBpYzA6IHJvdXRp bmcgaW50cGluIDIxIChQQ0kgSVJRIDIxKSB0byBsYXBpYyAxIHZlY3RvciA1MQptc2k6IEFzc2ln bmluZyBNU0kgSVJRIDI1NiB0byBsb2NhbCBBUElDIDEgdmVjdG9yIDUyCnVodWIwOiAyIHBvcnRz IHdpdGggMiByZW1vdmFibGUsIHNlbGYgcG93ZXJlZAp1aHViMTogMiBwb3J0cyB3aXRoIDIgcmVt b3ZhYmxlLCBzZWxmIHBvd2VyZWQKdWh1YjM6IDIgcG9ydHMgd2l0aCAyIHJlbW92YWJsZSwgc2Vs ZiBwb3dlcmVkCnVodWI0OiAyIHBvcnRzIHdpdGggMiByZW1vdmFibGUsIHNlbGYgcG93ZXJlZAp1 aHViNTogMiBwb3J0cyB3aXRoIDIgcmVtb3ZhYmxlLCBzZWxmIHBvd2VyZWQKYmF0dGVyeTA6IGJh dHRlcnkgaW5pdGlhbGl6YXRpb24gZG9uZSwgdHJpZWQgMSB0aW1lcwp1aHViMjogNCBwb3J0cyB3 aXRoIDQgcmVtb3ZhYmxlLCBzZWxmIHBvd2VyZWQKdWh1YjY6IDYgcG9ydHMgd2l0aCA2IHJlbW92 YWJsZSwgc2VsZiBwb3dlcmVkCnVnZW42LjI6IDx2ZW5kb3IgMHgwNzgxPiBhdCB1c2J1czYKdW1h c3MwOiA8dmVuZG9yIDB4MDc4MSBwcm9kdWN0IDB4NTUzMCwgY2xhc3MgMC8wLCByZXYgMi4wMC8y LjAwLCBhZGRyIDI+IG9uIHVzYnVzNgp1bWFzczA6ICBTQ1NJIG92ZXIgQnVsay1Pbmx5OyBxdWly a3MgPSAweDAwMDAKdW1hc3MwOjA6MDotMTogQXR0YWNoZWQgdG8gc2NidXMwCihwcm9iZTA6dW1h c3Mtc2ltMDowOjA6MCk6IERvd24gcmV2aW5nIFByb3RvY29sIFZlcnNpb24gZnJvbSAyIHRvIDA/ CnBhc3MwIGF0IHVtYXNzLXNpbTAgYnVzIDAgdGFyZ2V0IDAgbHVuIDAKcGFzczA6IDxTYW5EaXNr IFNhbkRpc2sgQ3J1emVyIDguMDI+IFJlbW92YWJsZSBEaXJlY3QgQWNjZXNzIFNDU0ktMCBkZXZp Y2UgCnBhc3MwOiA0MC4wMDBNQi9zIHRyYW5zZmVycwpkYTAgYXQgdW1hc3Mtc2ltMCBidXMgMCB0 YXJnZXQgMCBsdW4gMApkYTA6IDxTYW5EaXNrIFNhbkRpc2sgQ3J1emVyIDguMDI+IFJlbW92YWJs ZSBEaXJlY3QgQWNjZXNzIFNDU0ktMCBkZXZpY2UgCmRhMDogNDAuMDAwTUIvcyB0cmFuc2ZlcnMK ZGEwOiA3NjkxTUIgKDE1NzUzMjE1IDUxMiBieXRlIHNlY3RvcnM6IDI1NUggNjNTL1QgOTgwQykK dWdlbjYuMzogPEdlbmVyaWM+IGF0IHVzYnVzNgp1bWFzczE6IDxCdWxrLUluLCBCdWxrLU91dCwg SW50ZXJmYWNlPiBvbiB1c2J1czYKdW1hc3MxOiAgU0NTSSBvdmVyIEJ1bGstT25seTsgcXVpcmtz ID0gMHgwMDAwCkdFT006IG5ldyBkaXNrIGRhMAp1Z2VuNC4yOiA8TG9naXRlY2g+IGF0IHVzYnVz NAp1bXMwOiA8TG9naXRlY2ggVVNCIFJlY2VpdmVyLCBjbGFzcyAwLzAsIHJldiAxLjEwLzQ2LjAw LCBhZGRyIDI+IG9uIHVzYnVzNAp1bXMwOiA4IGJ1dHRvbnMgYW5kIFtYWVpdIGNvb3JkaW5hdGVz IElEPTAKdWhpZDA6IDxMb2dpdGVjaCBVU0IgUmVjZWl2ZXIsIGNsYXNzIDAvMCwgcmV2IDEuMTAv NDYuMDAsIGFkZHIgMj4gb24gdXNidXM0CkdFT006IGRhMDogcGFydGl0aW9uIDEgZG9lcyBub3Qg c3RhcnQgb24gYSB0cmFjayBib3VuZGFyeS4KR0VPTTogZGEwOiBwYXJ0aXRpb24gMSBkb2VzIG5v dCBlbmQgb24gYSB0cmFjayBib3VuZGFyeS4KUm9vdCBtb3VudCB3YWl0aW5nIGZvcjogdXNidXM2 CnVtYXNzMToxOjE6LTE6IEF0dGFjaGVkIHRvIHNjYnVzMQoocHJvYmUwOnVtYXNzLXNpbTE6MTow OjApOiBEb3duIHJldmluZyBQcm90b2NvbCBWZXJzaW9uIGZyb20gMiB0byAwPwoocHJvYmUwOnVt YXNzLXNpbTE6MTowOjApOiBURVNUIFVOSVQgUkVBRFkuIENEQjogMCAwIDAgMCAwIDAgCihwcm9i ZTA6dW1hc3Mtc2ltMToxOjA6MCk6IENBTSBTdGF0dXM6IFNDU0kgU3RhdHVzIEVycm9yCihwcm9i ZTA6dW1hc3Mtc2ltMToxOjA6MCk6IFNDU0kgU3RhdHVzOiBDaGVjayBDb25kaXRpb24KKHByb2Jl MDp1bWFzcy1zaW0xOjE6MDowKTogTk9UIFJFQURZIGFzYzozYSwwCihwcm9iZTA6dW1hc3Mtc2lt MToxOjA6MCk6IE1lZGl1bSBub3QgcHJlc2VudAoocHJvYmUwOnVtYXNzLXNpbTE6MTowOjApOiAo cHJvYmUwOnVtYXNzLXNpbTE6MTowOjApOiBURVNUIFVOSVQgUkVBRFkuIENEQjogMCAwIDAgMCAw IDAgCihwcm9iZTA6dW1hc3Mtc2ltMToxOjA6MCk6IE5PVCBSRUFEWSBhc2M6M2EsMAoocHJvYmUw OnVtYXNzLXNpbTE6MTowOjApOiBNZWRpdW0gbm90IHByZXNlbnQKVW5yZXRyeWFibGUgZXJyb3IK KHByb2JlMDp1bWFzcy1zaW0xOjE6MDowKTogZXJyb3IgNgoocHJvYmUwOnVtYXNzLXNpbTE6MTow OjApOiBVbnJldHJ5YWJsZSBFcnJvcgpwYXNzMSBhdCB1bWFzcy1zaW0xIGJ1cyAxIHRhcmdldCAw IGx1biAwCnBhc3MxOiA8R2VuZXJpYy0gTXVsdGktQ2FyZCAxLjAwPiBSZW1vdmFibGUgRGlyZWN0 IEFjY2VzcyBTQ1NJLTAgZGV2aWNlIApwYXNzMTogNDAuMDAwTUIvcyB0cmFuc2ZlcnMKR0VPTTog bmV3IGRpc2sgZGExCihkYTE6dW1hc3Mtc2ltMToxOjA6MCk6IGVycm9yIDYKKGRhMTp1bWFzcy1z aW0xOjE6MDowKTogVW5yZXRyeWFibGUgRXJyb3IKZGExIGF0IHVtYXNzLXNpbTEgYnVzIDEgdGFy Z2V0IDAgbHVuIDAKZGExOiA8R2VuZXJpYy0gTXVsdGktQ2FyZCAxLjAwPiBSZW1vdmFibGUgRGly ZWN0IEFjY2VzcyBTQ1NJLTAgZGV2aWNlIApkYTE6IDQwLjAwME1CL3MgdHJhbnNmZXJzCmRhMTog QXR0ZW1wdCB0byBxdWVyeSBkZXZpY2Ugc2l6ZSBmYWlsZWQ6IE5PVCBSRUFEWSwgTWVkaXVtIG5v dCBwcmVzZW50CihkYTE6dW1hc3Mtc2ltMToxOjA6MCk6IGVycm9yIDYKKGRhMTp1bWFzcy1zaW0x OjE6MDowKTogVW5yZXRyeWFibGUgRXJyb3IKT3BlbmVkIGRpc2sgZGExIC0+IDYKKGRhMTp1bWFz cy1zaW0xOjE6MDowKTogZXJyb3IgNgooZGExOnVtYXNzLXNpbTE6MTowOjApOiBVbnJldHJ5YWJs ZSBFcnJvcgpPcGVuZWQgZGlzayBkYTEgLT4gNgpSb290IG1vdW50IHdhaXRpbmcgZm9yOiB1c2J1 czYKdWdlbjYuNDogPFN1WWluPiBhdCB1c2J1czYKVHJ5aW5nIHRvIG1vdW50IHJvb3QgZnJvbSB1 ZnM6L2Rldi9hZDRzNGEKY3RfdG9fdHMoWzIwMTAtMDEtMjQgMDM6MDk6MDVdKSA9IDEyNjQzMDI1 NDUuMDAwMDAwMDAwCnN0YXJ0X2luaXQ6IHRyeWluZyAvc2Jpbi9pbml0CmFjcGlfdHowOiBzd2l0 Y2hlZCBmcm9tIF9BQzAgdG8gTk9ORTogNjQuMEMKdHNfdG9fY3QoMTI2NDMwMjU4Ny4wMjg3Nzk2 NzYpID0gWzIwMTAtMDEtMjQgMDM6MDk6NDddCg== --001485f453423a15ad047e28b4a4 Content-Type: application/octet-stream; name="80stable_dmesg.boot" Content-Disposition: attachment; filename="80stable_dmesg.boot" Content-Transfer-Encoding: base64 X-Attachment-Id: f_g4ydzcpn1 Q29weXJpZ2h0IChjKSAxOTkyLTIwMTAgVGhlIEZyZWVCU0QgUHJvamVjdC4KQ29weXJpZ2h0IChj KSAxOTc5LCAxOTgwLCAxOTgzLCAxOTg2LCAxOTg4LCAxOTg5LCAxOTkxLCAxOTkyLCAxOTkzLCAx OTk0CglUaGUgUmVnZW50cyBvZiB0aGUgVW5pdmVyc2l0eSBvZiBDYWxpZm9ybmlhLiBBbGwgcmln aHRzIHJlc2VydmVkLgpGcmVlQlNEIGlzIGEgcmVnaXN0ZXJlZCB0cmFkZW1hcmsgb2YgVGhlIEZy ZWVCU0QgRm91bmRhdGlvbi4KRnJlZUJTRCA4LjAtU1RBQkxFICMwOiBTdW4gSmFuIDI0IDE0OjE5 OjQwIEJSVCAyMDEwCiAgICByb290QDovdXNyL29iai91c3Ivc3JjL3N5cy9HRU5FUklDIGFtZDY0 ClByZWxvYWRlZCBlbGYga2VybmVsICIvYm9vdC9rZXJuZWwva2VybmVsIiBhdCAweGZmZmZmZmZm ODBlMzAwMDAuClRpbWVjb3VudGVyICJpODI1NCIgZnJlcXVlbmN5IDExOTMxODIgSHogcXVhbGl0 eSAwCkNhbGlicmF0aW5nIFRTQyBjbG9jayAuLi4gVFNDIGNsb2NrOiAyMDk4OTU2MzIxIEh6CkNQ VTogSW50ZWwoUikgQ29yZShUTSkyIER1byBDUFUgICAgIFQ2NTAwICBAIDIuMTBHSHogKDIwOTgu OTYtTUh6IEs4LWNsYXNzIENQVSkKICBPcmlnaW4gPSAiR2VudWluZUludGVsIiAgSWQgPSAweDEw NjdhICBTdGVwcGluZyA9IDEwCiAgRmVhdHVyZXM9MHhiZmViZmJmZjxGUFUsVk1FLERFLFBTRSxU U0MsTVNSLFBBRSxNQ0UsQ1g4LEFQSUMsU0VQLE1UUlIsUEdFLE1DQSxDTU9WLFBBVCxQU0UzNixD TEZMVVNILERUUyxBQ1BJLE1NWCxGWFNSLFNTRSxTU0UyLFNTLEhUVCxUTSxQQkU+CiAgRmVhdHVy ZXMyPTB4NDA4ZTM5ZDxTU0UzLERURVM2NCxNT04sRFNfQ1BMLEVTVCxUTTIsU1NTRTMsQ1gxNix4 VFBSLFBEQ00sU1NFNC4xLFhTQVZFPgogIEFNRCBGZWF0dXJlcz0weDIwMTAwODAwPFNZU0NBTEws TlgsTE0+CiAgQU1EIEZlYXR1cmVzMj0weDE8TEFIRj4KICBUU0M6IFAtc3RhdGUgaW52YXJpYW50 CnJlYWwgbWVtb3J5ICA9IDQyOTQ5NjcyOTYgKDQwOTYgTUIpClBoeXNpY2FsIG1lbW9yeSBjaHVu ayhzKToKMHgwMDAwMDAwMDAwMDAxMDAwIC0gMHgwMDAwMDAwMDAwMDQ4ZmZmLCAyOTQ5MTIgYnl0 ZXMgKDcyIHBhZ2VzKQoweDAwMDAwMDAwMDAwNTkwMDAgLSAweDAwMDAwMDAwMDAwOTlmZmYsIDI2 NjI0MCBieXRlcyAoNjUgcGFnZXMpCjB4MDAwMDAwMDAwMGU1ZjAwMCAtIDB4MDAwMDAwMDBiMDdl YWZmZiwgMjk0NjAyMzQyNCBieXRlcyAoNzE5MjQ0IHBhZ2VzKQoweDAwMDAwMDAwYjllYmYwMDAg LSAweDAwMDAwMDAwYjlmODJmZmYsIDgwMjgxNiBieXRlcyAoMTk2IHBhZ2VzKQoweDAwMDAwMDAw YjlmYmYwMDAgLSAweDAwMDAwMDAwYjlmZGVmZmYsIDEzMTA3MiBieXRlcyAoMzIgcGFnZXMpCjB4 MDAwMDAwMDBiOWZmNjAwMCAtIDB4MDAwMDAwMDBiOWZmZGZmZiwgMzI3NjggYnl0ZXMgKDggcGFn ZXMpCjB4MDAwMDAwMDBiOWZmZjAwMCAtIDB4MDAwMDAwMDBiOWZmZmZmZiwgNDA5NiBieXRlcyAo MSBwYWdlcykKMHgwMDAwMDAwMTAwMDAwMDAwIC0gMHgwMDAwMDAwMTNmZmVmZmZmLCAxMDczNjc2 Mjg4IGJ5dGVzICgyNjIxMjggcGFnZXMpCmF2YWlsIG1lbW9yeSA9IDM5OTg2NTg1NjAgKDM4MTMg TUIpCkFDUEkgQVBJQyBUYWJsZTogPEhQUU9FTSBTTElDLU1QQz4KSU5UUjogQWRkaW5nIGxvY2Fs IEFQSUMgMSBhcyBhIHRhcmdldApGcmVlQlNEL1NNUDogTXVsdGlwcm9jZXNzb3IgU3lzdGVtIERl dGVjdGVkOiAyIENQVXMKRnJlZUJTRC9TTVA6IDEgcGFja2FnZShzKSB4IDIgY29yZShzKQogY3B1 MCAoQlNQKTogQVBJQyBJRDogIDAKIGNwdTEgKEFQKTogQVBJQyBJRDogIDEKQVBJQzogQ1BVIDAg aGFzIEFDUEkgSUQgMQpBUElDOiBDUFUgMSBoYXMgQUNQSSBJRCAyClVMRTogc2V0dXAgY3B1IDAK VUxFOiBzZXR1cCBjcHUgMQpBQ1BJOiBSU0RQIDB4ZmUwMjAgMDAwMjQgKHYyIEhQICAgICkKQUNQ STogWFNEVCAweGI5ZmZlMTIwIDAwMDc0ICh2MSBIUFFPRU0gU0xJQy1NUEMgMDAwMDAwMDEgICAg ICAwMTAwMDAxMykKQUNQSTogRkFDUCAweGI5ZmYzMDAwIDAwMEY0ICh2NCBIUCAgICAgUkhFVFQg ICAgMDAwMDAwMDEgTVNGVCAwMTAwMDAxMykKQUNQSTogRFNEVCAweGI5ZmU0MDAwIDBBNUI4ICh2 MSBIUCAgICAgUkhFVFQgICAgMDAwMDAwMDEgTVNGVCAwMTAwMDAxMykKQUNQSTogRkFDUyAweGI5 ZjhjMDAwIDAwMDQwCkFDUEk6IERNQVIgMHhiOWZmNTAwMCAwMDBBMCAodjEgICAgICAgICAgICAg ICBcXkEgMDAwMDAwMDEgICAgICAwMDAwMDAwMCkKQUNQSTogU1NEVCAweGI5ZmY0MDAwIDAwNjU1 ICh2MSAgUG1SZWYgICAgQ3B1UG0gMDAwMDMwMDAgSU5UTCAyMDA1MTExNykKQUNQSTogSFBFVCAw eGI5ZmYyMDAwIDAwMDM4ICh2MSBIUFFPRU0gU0xJQy1NUEMgMDAwMDAwMDEgTVNGVCAwMTAwMDAx MykKQUNQSTogQVBJQyAweGI5ZmYxMDAwIDAwMDZDICh2MiBIUFFPRU0gU0xJQy1NUEMgMDAwMDAw MDEgTVNGVCAwMTAwMDAxMykKQUNQSTogTUNGRyAweGI5ZmYwMDAwIDAwMDNDICh2MSBIUFFPRU0g U0xJQy1NUEMgMDAwMDAwMDEgTVNGVCAwMTAwMDAxMykKQUNQSTogQVNGISAweGI5ZmVmMDAwIDAw MEE1ICh2MzIgSFBRT0VNIFNMSUMtTVBDIDAwMDAwMDAxIE1TRlQgMDEwMDAwMTMpCkFDUEk6IFNM SUMgMHhiOWZlMzAwMCAwMDE3NiAodjEgSFBRT0VNIFNMSUMtTVBDIDAwMDAwMDAxIExPSFIgMDAw RjQyNDApCkFDUEk6IEJPT1QgMHhiOWZlMjAwMCAwMDAyOCAodjEgSFBRT0VNIFNMSUMtTVBDIDAw MDAwMDAxIE1TRlQgMDEwMDAwMTMpCkFDUEk6IFNTRFQgMHhiOWZlMTAwMCAwMDI5NiAodjEgSU5U RUwgIFNhdGFBaGNpIDAwMDAxMDAwIElOVEwgMjAwNTExMTcpCk1BRFQ6IEZvdW5kIElPIEFQSUMg SUQgNCwgSW50ZXJydXB0IDAgYXQgMHhmZWMwMDAwMAppb2FwaWMwOiBDaGFuZ2luZyBBUElDIElE IHRvIDQKaW9hcGljMDogUm91dGluZyBleHRlcm5hbCA4MjU5QSdzIC0+IGludHBpbiAwCk1BRFQ6 IEludGVycnVwdCBvdmVycmlkZTogc291cmNlIDAsIGlycSAyCmlvYXBpYzA6IFJvdXRpbmcgSVJR IDAgLT4gaW50cGluIDIKTUFEVDogSW50ZXJydXB0IG92ZXJyaWRlOiBzb3VyY2UgOSwgaXJxIDkK aW9hcGljMDogaW50cGluIDkgdHJpZ2dlcjogbGV2ZWwKaW9hcGljMCA8VmVyc2lvbiAyLjA+IGly cXMgMC0yMyBvbiBtb3RoZXJib2FyZApjcHUwIEJTUDoKICAgICBJRDogMHgwMDAwMDAwMCAgIFZF UjogMHgwMDA1MDAxNCBMRFI6IDB4MDAwMDAwMDAgREZSOiAweGZmZmZmZmZmCiAgbGludDA6IDB4 MDAwMTA3MDAgbGludDE6IDB4MDAwMDA0MDAgVFBSOiAweDAwMDAwMDAwIFNWUjogMHgwMDAwMDFm ZgogIHRpbWVyOiAweDAwMDEwMGVmIHRoZXJtOiAweDAwMDEwMDAwIGVycjogMHgwMDAxMDAwMCBw Y206IDB4MDAwMTA0MDAKd2xhbjogPDgwMi4xMSBMaW5rIExheWVyPgpudWxsOiA8bnVsbCBkZXZp Y2UsIHplcm8gZGV2aWNlPgpyYW5kb206IDxlbnRyb3B5IHNvdXJjZSwgU29mdHdhcmUsIFlhcnJv dz4KbmZzbG9jazogcHNldWRvLWRldmljZQprYmQ6IG5ldyBhcnJheSBzaXplIDQKa2JkMSBhdCBr YmRtdXgwCm1lbTogPG1lbW9yeT4KaW86IDxJL08+CmhwdHJyOiBSb2NrZXRSQUlEIDE3eHgvMnh4 eCBTQVRBIGNvbnRyb2xsZXIgZHJpdmVyIHYxLjIKYWNwaTA6IDxIUFFPRU0gU0xJQy1NUEM+IG9u IG1vdGhlcmJvYXJkClBDSWU6IE1lbW9yeSBNYXBwZWQgY29uZmlndXJhdGlvbiBiYXNlIEAgMHhm ODAwMDAwMAppb2FwaWMwOiByb3V0aW5nIGludHBpbiA5IChJU0EgSVJRIDkpIHRvIGxhcGljIDAg dmVjdG9yIDQ4CmFjcGkwOiBbTVBTQUZFXQphY3BpMDogW0lUSFJFQURdCmFjcGkwOiBQb3dlciBC dXR0b24gKGZpeGVkKQphY3BpMDogd2FrZXVwIGNvZGUgdmEgMHhmZmZmZmY4MDAwMDBmMDAwIHBh IDB4NDAwMApBY3BpT3NEZXJpdmVQY2lJZDogXFxfU0JfLlBDSTAuSEJVUyAtPiBidXMgMCBkZXYg MCBmdW5jIDAKQWNwaU9zRGVyaXZlUGNpSWQ6IFxcX1NCXy5QQ0kwLkxQQ18uUFJSMCAtPiBidXMg MCBkZXYgMzEgZnVuYyAwCkFjcGlPc0Rlcml2ZVBjaUlkOiBcXF9TQl8uUENJMC5MUENfLlBSUjEg LT4gYnVzIDAgZGV2IDMxIGZ1bmMgMApBQ1BJIHRpbWVyOiAxLzEgMS8yIDEvMiAxLzIgMS8yIDEv MSAxLzEgMS8xIDEvMSAxLzIgLT4gMTAKVGltZWNvdW50ZXIgIkFDUEktZmFzdCIgZnJlcXVlbmN5 IDM1Nzk1NDUgSHogcXVhbGl0eSAxMDAwCmFjcGlfdGltZXIwOiA8MjQtYml0IHRpbWVyIGF0IDMu NTc5NTQ1TUh6PiBwb3J0IDB4NDA4LTB4NDBiIG9uIGFjcGkwCmFjcGlfZWMwOiA8RW1iZWRkZWQg Q29udHJvbGxlcjogR1BFIDB4MTc+IHBvcnQgMHg2MiwweDY2IG9uIGFjcGkwCnBjaV9saW5rMDog ICAgICAgIEluZGV4ICBJUlEgIFJ0ZCAgUmVmICBJUlFzCiAgSW5pdGlhbCBQcm9iZSAgICAgICAw ICAgMTEgICBOICAgICAwICAzIDQgNSA3IDkgMTAgMTEgMTIKICBWYWxpZGF0aW9uICAgICAgICAg IDAgICAxMSAgIE4gICAgIDAgIDMgNCA1IDcgOSAxMCAxMSAxMgogIEFmdGVyIERpc2FibGUgICAg ICAgMCAgMjU1ICAgTiAgICAgMCAgMyA0IDUgNyA5IDEwIDExIDEyCnBjaV9saW5rMTogICAgICAg IEluZGV4ICBJUlEgIFJ0ZCAgUmVmICBJUlFzCiAgSW5pdGlhbCBQcm9iZSAgICAgICAwICAgMTAg ICBOICAgICAwICAzIDQgNSA3IDkgMTAgMTEgMTIKICBWYWxpZGF0aW9uICAgICAgICAgIDAgICAx MCAgIE4gICAgIDAgIDMgNCA1IDcgOSAxMCAxMSAxMgogIEFmdGVyIERpc2FibGUgICAgICAgMCAg MjU1ICAgTiAgICAgMCAgMyA0IDUgNyA5IDEwIDExIDEyCnBjaV9saW5rMjogICAgICAgIEluZGV4 ICBJUlEgIFJ0ZCAgUmVmICBJUlFzCiAgSW5pdGlhbCBQcm9iZSAgICAgICAwICAgMTEgICBOICAg ICAwICAzIDQgNSA3IDkgMTAgMTEgMTIKICBWYWxpZGF0aW9uICAgICAgICAgIDAgICAxMSAgIE4g ICAgIDAgIDMgNCA1IDcgOSAxMCAxMSAxMgogIEFmdGVyIERpc2FibGUgICAgICAgMCAgMjU1ICAg TiAgICAgMCAgMyA0IDUgNyA5IDEwIDExIDEyCnBjaV9saW5rMzogICAgICAgIEluZGV4ICBJUlEg IFJ0ZCAgUmVmICBJUlFzCiAgSW5pdGlhbCBQcm9iZSAgICAgICAwICAgMTEgICBOICAgICAwICAz IDQgNSA3IDkgMTAgMTEgMTIKICBWYWxpZGF0aW9uICAgICAgICAgIDAgICAxMSAgIE4gICAgIDAg IDMgNCA1IDcgOSAxMCAxMSAxMgogIEFmdGVyIERpc2FibGUgICAgICAgMCAgMjU1ICAgTiAgICAg MCAgMyA0IDUgNyA5IDEwIDExIDEyCnBjaV9saW5rNDogICAgICAgIEluZGV4ICBJUlEgIFJ0ZCAg UmVmICBJUlFzCiAgSW5pdGlhbCBQcm9iZSAgICAgICAwICAgMTEgICBOICAgICAwICAzIDQgNSA3 IDkgMTAgMTEgMTIKICBWYWxpZGF0aW9uICAgICAgICAgIDAgICAxMSAgIE4gICAgIDAgIDMgNCA1 IDcgOSAxMCAxMSAxMgogIEFmdGVyIERpc2FibGUgICAgICAgMCAgMjU1ICAgTiAgICAgMCAgMyA0 IDUgNyA5IDEwIDExIDEyCnBjaV9saW5rNTogICAgICAgIEluZGV4ICBJUlEgIFJ0ZCAgUmVmICBJ UlFzCiAgSW5pdGlhbCBQcm9iZSAgICAgICAwICAgMTEgICBOICAgICAwICAzIDQgNSA3IDkgMTAg MTEgMTIKICBWYWxpZGF0aW9uICAgICAgICAgIDAgICAxMSAgIE4gICAgIDAgIDMgNCA1IDcgOSAx MCAxMSAxMgogIEFmdGVyIERpc2FibGUgICAgICAgMCAgMjU1ICAgTiAgICAgMCAgMyA0IDUgNyA5 IDEwIDExIDEyCnBjaV9saW5rNjogICAgICAgIEluZGV4ICBJUlEgIFJ0ZCAgUmVmICBJUlFzCiAg SW5pdGlhbCBQcm9iZSAgICAgICAwICAgMTEgICBOICAgICAwICAzIDQgNSA3IDkgMTAgMTEgMTIK ICBWYWxpZGF0aW9uICAgICAgICAgIDAgICAxMSAgIE4gICAgIDAgIDMgNCA1IDcgOSAxMCAxMSAx MgogIEFmdGVyIERpc2FibGUgICAgICAgMCAgMjU1ICAgTiAgICAgMCAgMyA0IDUgNyA5IDEwIDEx IDEyCnBjaV9saW5rNzogICAgICAgIEluZGV4ICBJUlEgIFJ0ZCAgUmVmICBJUlFzCiAgSW5pdGlh bCBQcm9iZSAgICAgICAwICAyNTUgICBOICAgICAwICAzIDQgNSA3IDkgMTAgMTEgMTIKICBWYWxp ZGF0aW9uICAgICAgICAgIDAgIDI1NSAgIE4gICAgIDAgIDMgNCA1IDcgOSAxMCAxMSAxMgogIEFm dGVyIERpc2FibGUgICAgICAgMCAgMjU1ICAgTiAgICAgMCAgMyA0IDUgNyA5IDEwIDExIDEyCmFj cGlfaHBldDA6IDxIaWdoIFByZWNpc2lvbiBFdmVudCBUaW1lcj4gaW9tZW0gMHhmZWQwMDAwMC0w eGZlZDAwM2ZmIG9uIGFjcGkwCmFjcGlfaHBldDA6IHZlbmQ6IDB4ODA4NiByZXY6IDB4MSBudW06 IDMgaHo6IDE0MzE4MTgwIG9wdHM6IGxlZ2FjeV9yb3V0ZSA2NC1iaXQKVGltZWNvdW50ZXIgIkhQ RVQiIGZyZXF1ZW5jeSAxNDMxODE4MCBIeiBxdWFsaXR5IDkwMAphY3BpX2J1dHRvbjA6IDxQb3dl ciBCdXR0b24+IG9uIGFjcGkwCmFjcGlfbGlkMDogPENvbnRyb2wgTWV0aG9kIExpZCBTd2l0Y2g+ IG9uIGFjcGkwCmFjcGlfYnV0dG9uMTogPFNsZWVwIEJ1dHRvbj4gb24gYWNwaTAKYmF0dGVyeTA6 IDxBQ1BJIENvbnRyb2wgTWV0aG9kIEJhdHRlcnk+IG9uIGFjcGkwCmFjcGlfYWNhZDA6IDxBQyBB ZGFwdGVyPiBvbiBhY3BpMApwY2liMDogPEFDUEkgSG9zdC1QQ0kgYnJpZGdlPiBwb3J0IDB4Y2Y4 LTB4Y2ZmIG9uIGFjcGkwCnBjaTA6IDxBQ1BJIFBDSSBidXM+IG9uIHBjaWIwCnBjaTA6IGRvbWFp bj0wLCBwaHlzaWNhbCBidXM9MApmb3VuZC0+CXZlbmRvcj0weDgwODYsIGRldj0weDJhNDAsIHJl dmlkPTB4MDcKCWRvbWFpbj0wLCBidXM9MCwgc2xvdD0wLCBmdW5jPTAKCWNsYXNzPTA2LTAwLTAw LCBoZHJ0eXBlPTB4MDAsIG1mZGV2PTAKCWNtZHJlZz0weDAwMDYsIHN0YXRyZWc9MHgyMDkwLCBj YWNoZWxuc3o9MCAoZHdvcmRzKQoJbGF0dGltZXI9MHgwMCAoMCBucyksIG1pbmdudD0weDAwICgw IG5zKSwgbWF4bGF0PTB4MDAgKDAgbnMpCmZvdW5kLT4JdmVuZG9yPTB4ODA4NiwgZGV2PTB4MmE0 MiwgcmV2aWQ9MHgwNwoJZG9tYWluPTAsIGJ1cz0wLCBzbG90PTIsIGZ1bmM9MAoJY2xhc3M9MDMt MDAtMDAsIGhkcnR5cGU9MHgwMCwgbWZkZXY9MQoJY21kcmVnPTB4MDAwNywgc3RhdHJlZz0weDAw OTAsIGNhY2hlbG5zej0wIChkd29yZHMpCglsYXR0aW1lcj0weDAwICgwIG5zKSwgbWluZ250PTB4 MDAgKDAgbnMpLCBtYXhsYXQ9MHgwMCAoMCBucykKCWludHBpbj1hLCBpcnE9MTEKCXBvd2Vyc3Bl YyAzICBzdXBwb3J0cyBEMCBEMyAgY3VycmVudCBEMAoJTVNJIHN1cHBvcnRzIDEgbWVzc2FnZQoJ bWFwWzEwXTogdHlwZSBNZW1vcnksIHJhbmdlIDY0LCBiYXNlIDB4ZDAwMDAwMDAsIHNpemUgMjIs IGVuYWJsZWQKCW1hcFsxOF06IHR5cGUgUHJlZmV0Y2hhYmxlIE1lbW9yeSwgcmFuZ2UgNjQsIGJh c2UgMHhjMDAwMDAwMCwgc2l6ZSAyOCwgZW5hYmxlZAoJbWFwWzIwXTogdHlwZSBJL08gUG9ydCwg cmFuZ2UgMzIsIGJhc2UgMHg1MGYwLCBzaXplICAzLCBlbmFibGVkCnBjaWIwOiBtYXRjaGVkIGVu dHJ5IGZvciAwLjIuSU5UQQpwY2liMDogc2xvdCAyIElOVEEgaGFyZHdpcmVkIHRvIElSUSAxNgpm b3VuZC0+CXZlbmRvcj0weDgwODYsIGRldj0weDJhNDMsIHJldmlkPTB4MDcKCWRvbWFpbj0wLCBi dXM9MCwgc2xvdD0yLCBmdW5jPTEKCWNsYXNzPTAzLTgwLTAwLCBoZHJ0eXBlPTB4MDAsIG1mZGV2 PTEKCWNtZHJlZz0weDAwMDcsIHN0YXRyZWc9MHgwMDkwLCBjYWNoZWxuc3o9MCAoZHdvcmRzKQoJ bGF0dGltZXI9MHgwMCAoMCBucyksIG1pbmdudD0weDAwICgwIG5zKSwgbWF4bGF0PTB4MDAgKDAg bnMpCglwb3dlcnNwZWMgMyAgc3VwcG9ydHMgRDAgRDMgIGN1cnJlbnQgRDAKCW1hcFsxMF06IHR5 cGUgTWVtb3J5LCByYW5nZSA2NCwgYmFzZSAweGQ0NDAwMDAwLCBzaXplIDIwLCBlbmFibGVkCmZv dW5kLT4JdmVuZG9yPTB4ODA4NiwgZGV2PTB4MjkzNywgcmV2aWQ9MHgwMwoJZG9tYWluPTAsIGJ1 cz0wLCBzbG90PTI2LCBmdW5jPTAKCWNsYXNzPTBjLTAzLTAwLCBoZHJ0eXBlPTB4MDAsIG1mZGV2 PTEKCWNtZHJlZz0weDAwMDUsIHN0YXRyZWc9MHgwMjkwLCBjYWNoZWxuc3o9MCAoZHdvcmRzKQoJ bGF0dGltZXI9MHgwMCAoMCBucyksIG1pbmdudD0weDAwICgwIG5zKSwgbWF4bGF0PTB4MDAgKDAg bnMpCglpbnRwaW49YSwgaXJxPTExCgltYXBbMjBdOiB0eXBlIEkvTyBQb3J0LCByYW5nZSAzMiwg YmFzZSAweDUwYzAsIHNpemUgIDUsIGVuYWJsZWQKcGNpYjA6IG1hdGNoZWQgZW50cnkgZm9yIDAu MjYuSU5UQQpwY2liMDogc2xvdCAyNiBJTlRBIGhhcmR3aXJlZCB0byBJUlEgMTYKdW5rbm93bjog UmVzZXJ2ZWQgMHgyMCBieXRlcyBmb3IgcmlkIDB4MjAgdHlwZSA0IGF0IDB4NTBjMApmb3VuZC0+ CXZlbmRvcj0weDgwODYsIGRldj0weDI5MzgsIHJldmlkPTB4MDMKCWRvbWFpbj0wLCBidXM9MCwg c2xvdD0yNiwgZnVuYz0xCgljbGFzcz0wYy0wMy0wMCwgaGRydHlwZT0weDAwLCBtZmRldj0wCglj bWRyZWc9MHgwMDA1LCBzdGF0cmVnPTB4MDI5MCwgY2FjaGVsbnN6PTAgKGR3b3JkcykKCWxhdHRp bWVyPTB4MDAgKDAgbnMpLCBtaW5nbnQ9MHgwMCAoMCBucyksIG1heGxhdD0weDAwICgwIG5zKQoJ aW50cGluPWIsIGlycT0xMAoJbWFwWzIwXTogdHlwZSBJL08gUG9ydCwgcmFuZ2UgMzIsIGJhc2Ug MHg1MGEwLCBzaXplICA1LCBlbmFibGVkCnBjaWIwOiBtYXRjaGVkIGVudHJ5IGZvciAwLjI2LklO VEIKcGNpYjA6IHNsb3QgMjYgSU5UQiBoYXJkd2lyZWQgdG8gSVJRIDE3CnVua25vd246IFJlc2Vy dmVkIDB4MjAgYnl0ZXMgZm9yIHJpZCAweDIwIHR5cGUgNCBhdCAweDUwYTAKZm91bmQtPgl2ZW5k b3I9MHg4MDg2LCBkZXY9MHgyOTNjLCByZXZpZD0weDAzCglkb21haW49MCwgYnVzPTAsIHNsb3Q9 MjYsIGZ1bmM9NwoJY2xhc3M9MGMtMDMtMjAsIGhkcnR5cGU9MHgwMCwgbWZkZXY9MAoJY21kcmVn PTB4MDAwNiwgc3RhdHJlZz0weDAyOTAsIGNhY2hlbG5zej0wIChkd29yZHMpCglsYXR0aW1lcj0w eDAwICgwIG5zKSwgbWluZ250PTB4MDAgKDAgbnMpLCBtYXhsYXQ9MHgwMCAoMCBucykKCWludHBp bj1jLCBpcnE9MTEKCXBvd2Vyc3BlYyAyICBzdXBwb3J0cyBEMCBEMyAgY3VycmVudCBEMAoJbWFw WzEwXTogdHlwZSBNZW1vcnksIHJhbmdlIDMyLCBiYXNlIDB4ZDg1MDRjMDAsIHNpemUgMTAsIGVu YWJsZWQKcGNpYjA6IG1hdGNoZWQgZW50cnkgZm9yIDAuMjYuSU5UQwpwY2liMDogc2xvdCAyNiBJ TlRDIGhhcmR3aXJlZCB0byBJUlEgMTgKdW5rbm93bjogUmVzZXJ2ZWQgMHg0MDAgYnl0ZXMgZm9y IHJpZCAweDEwIHR5cGUgMyBhdCAweGQ4NTA0YzAwCmVoY2kgZWFybHk6IFNNTSBhY3RpdmUsIHJl cXVlc3Qgb3duZXIgY2hhbmdlCmZvdW5kLT4JdmVuZG9yPTB4ODA4NiwgZGV2PTB4MjkzZSwgcmV2 aWQ9MHgwMwoJZG9tYWluPTAsIGJ1cz0wLCBzbG90PTI3LCBmdW5jPTAKCWNsYXNzPTA0LTAzLTAw LCBoZHJ0eXBlPTB4MDAsIG1mZGV2PTAKCWNtZHJlZz0weDAwMDYsIHN0YXRyZWc9MHgwMDEwLCBj YWNoZWxuc3o9MTYgKGR3b3JkcykKCWxhdHRpbWVyPTB4MDAgKDAgbnMpLCBtaW5nbnQ9MHgwMCAo MCBucyksIG1heGxhdD0weDAwICgwIG5zKQoJaW50cGluPWIsIGlycT0xMQoJcG93ZXJzcGVjIDIg IHN1cHBvcnRzIEQwIEQzICBjdXJyZW50IEQwCglNU0kgc3VwcG9ydHMgMSBtZXNzYWdlLCA2NCBi aXQKCW1hcFsxMF06IHR5cGUgTWVtb3J5LCByYW5nZSA2NCwgYmFzZSAweGQ4NTAwMDAwLCBzaXpl IDE0LCBlbmFibGVkCnBjaWIwOiBtYXRjaGVkIGVudHJ5IGZvciAwLjI3LklOVEIKcGNpYjA6IHNs b3QgMjcgSU5UQiBoYXJkd2lyZWQgdG8gSVJRIDIyCmZvdW5kLT4JdmVuZG9yPTB4ODA4NiwgZGV2 PTB4Mjk0MCwgcmV2aWQ9MHgwMwoJZG9tYWluPTAsIGJ1cz0wLCBzbG90PTI4LCBmdW5jPTAKCWNs YXNzPTA2LTA0LTAwLCBoZHJ0eXBlPTB4MDEsIG1mZGV2PTEKCWNtZHJlZz0weDAwMDcsIHN0YXRy ZWc9MHgwMDEwLCBjYWNoZWxuc3o9MCAoZHdvcmRzKQoJbGF0dGltZXI9MHgwMCAoMCBucyksIG1p bmdudD0weDAwICgwIG5zKSwgbWF4bGF0PTB4MDAgKDAgbnMpCglpbnRwaW49YSwgaXJxPTI1NQoJ cG93ZXJzcGVjIDIgIHN1cHBvcnRzIEQwIEQzICBjdXJyZW50IEQwCglNU0kgc3VwcG9ydHMgMSBt ZXNzYWdlCmZvdW5kLT4JdmVuZG9yPTB4ODA4NiwgZGV2PTB4Mjk0NCwgcmV2aWQ9MHgwMwoJZG9t YWluPTAsIGJ1cz0wLCBzbG90PTI4LCBmdW5jPTIKCWNsYXNzPTA2LTA0LTAwLCBoZHJ0eXBlPTB4 MDEsIG1mZGV2PTEKCWNtZHJlZz0weDAwMDcsIHN0YXRyZWc9MHgwMDEwLCBjYWNoZWxuc3o9MCAo ZHdvcmRzKQoJbGF0dGltZXI9MHgwMCAoMCBucyksIG1pbmdudD0weDAwICgwIG5zKSwgbWF4bGF0 PTB4MDAgKDAgbnMpCglpbnRwaW49YywgaXJxPTI1NQoJcG93ZXJzcGVjIDIgIHN1cHBvcnRzIEQw IEQzICBjdXJyZW50IEQwCglNU0kgc3VwcG9ydHMgMSBtZXNzYWdlCmZvdW5kLT4JdmVuZG9yPTB4 ODA4NiwgZGV2PTB4Mjk0NiwgcmV2aWQ9MHgwMwoJZG9tYWluPTAsIGJ1cz0wLCBzbG90PTI4LCBm dW5jPTMKCWNsYXNzPTA2LTA0LTAwLCBoZHJ0eXBlPTB4MDEsIG1mZGV2PTEKCWNtZHJlZz0weDAw MDcsIHN0YXRyZWc9MHgwMDEwLCBjYWNoZWxuc3o9MCAoZHdvcmRzKQoJbGF0dGltZXI9MHgwMCAo MCBucyksIG1pbmdudD0weDAwICgwIG5zKSwgbWF4bGF0PTB4MDAgKDAgbnMpCglpbnRwaW49ZCwg aXJxPTI1NQoJcG93ZXJzcGVjIDIgIHN1cHBvcnRzIEQwIEQzICBjdXJyZW50IEQwCglNU0kgc3Vw cG9ydHMgMSBtZXNzYWdlCmZvdW5kLT4JdmVuZG9yPTB4ODA4NiwgZGV2PTB4Mjk0YSwgcmV2aWQ9 MHgwMwoJZG9tYWluPTAsIGJ1cz0wLCBzbG90PTI4LCBmdW5jPTUKCWNsYXNzPTA2LTA0LTAwLCBo ZHJ0eXBlPTB4MDEsIG1mZGV2PTEKCWNtZHJlZz0weDAwMDcsIHN0YXRyZWc9MHgwMDEwLCBjYWNo ZWxuc3o9MCAoZHdvcmRzKQoJbGF0dGltZXI9MHgwMCAoMCBucyksIG1pbmdudD0weDAwICgwIG5z KSwgbWF4bGF0PTB4MDAgKDAgbnMpCglpbnRwaW49YiwgaXJxPTI1NQoJcG93ZXJzcGVjIDIgIHN1 cHBvcnRzIEQwIEQzICBjdXJyZW50IEQwCglNU0kgc3VwcG9ydHMgMSBtZXNzYWdlCmZvdW5kLT4J dmVuZG9yPTB4ODA4NiwgZGV2PTB4MjkzNCwgcmV2aWQ9MHgwMwoJZG9tYWluPTAsIGJ1cz0wLCBz bG90PTI5LCBmdW5jPTAKCWNsYXNzPTBjLTAzLTAwLCBoZHJ0eXBlPTB4MDAsIG1mZGV2PTEKCWNt ZHJlZz0weDAwMDUsIHN0YXRyZWc9MHgwMjkwLCBjYWNoZWxuc3o9MCAoZHdvcmRzKQoJbGF0dGlt ZXI9MHgwMCAoMCBucyksIG1pbmdudD0weDAwICgwIG5zKSwgbWF4bGF0PTB4MDAgKDAgbnMpCglp bnRwaW49YSwgaXJxPTExCgltYXBbMjBdOiB0eXBlIEkvTyBQb3J0LCByYW5nZSAzMiwgYmFzZSAw eDUwODAsIHNpemUgIDUsIGVuYWJsZWQKcGNpYjA6IG1hdGNoZWQgZW50cnkgZm9yIDAuMjkuSU5U QQpwY2liMDogc2xvdCAyOSBJTlRBIGhhcmR3aXJlZCB0byBJUlEgMjAKdW5rbm93bjogUmVzZXJ2 ZWQgMHgyMCBieXRlcyBmb3IgcmlkIDB4MjAgdHlwZSA0IGF0IDB4NTA4MApmb3VuZC0+CXZlbmRv cj0weDgwODYsIGRldj0weDI5MzUsIHJldmlkPTB4MDMKCWRvbWFpbj0wLCBidXM9MCwgc2xvdD0y OSwgZnVuYz0xCgljbGFzcz0wYy0wMy0wMCwgaGRydHlwZT0weDAwLCBtZmRldj0wCgljbWRyZWc9 MHgwMDA1LCBzdGF0cmVnPTB4MDI5MCwgY2FjaGVsbnN6PTAgKGR3b3JkcykKCWxhdHRpbWVyPTB4 MDAgKDAgbnMpLCBtaW5nbnQ9MHgwMCAoMCBucyksIG1heGxhdD0weDAwICgwIG5zKQoJaW50cGlu PWIsIGlycT0xMQoJbWFwWzIwXTogdHlwZSBJL08gUG9ydCwgcmFuZ2UgMzIsIGJhc2UgMHg1MDYw LCBzaXplICA1LCBlbmFibGVkCnBjaWIwOiBtYXRjaGVkIGVudHJ5IGZvciAwLjI5LklOVEIKcGNp YjA6IHNsb3QgMjkgSU5UQiBoYXJkd2lyZWQgdG8gSVJRIDIyCnVua25vd246IFJlc2VydmVkIDB4 MjAgYnl0ZXMgZm9yIHJpZCAweDIwIHR5cGUgNCBhdCAweDUwNjAKZm91bmQtPgl2ZW5kb3I9MHg4 MDg2LCBkZXY9MHgyOTM2LCByZXZpZD0weDAzCglkb21haW49MCwgYnVzPTAsIHNsb3Q9MjksIGZ1 bmM9MgoJY2xhc3M9MGMtMDMtMDAsIGhkcnR5cGU9MHgwMCwgbWZkZXY9MAoJY21kcmVnPTB4MDAw NSwgc3RhdHJlZz0weDAyOTAsIGNhY2hlbG5zej0wIChkd29yZHMpCglsYXR0aW1lcj0weDAwICgw IG5zKSwgbWluZ250PTB4MDAgKDAgbnMpLCBtYXhsYXQ9MHgwMCAoMCBucykKCWludHBpbj1jLCBp cnE9MTEKCW1hcFsyMF06IHR5cGUgSS9PIFBvcnQsIHJhbmdlIDMyLCBiYXNlIDB4NTA0MCwgc2l6 ZSAgNSwgZW5hYmxlZApwY2liMDogbWF0Y2hlZCBlbnRyeSBmb3IgMC4yOS5JTlRDCnBjaWIwOiBz bG90IDI5IElOVEMgaGFyZHdpcmVkIHRvIElSUSAxOAp1bmtub3duOiBSZXNlcnZlZCAweDIwIGJ5 dGVzIGZvciByaWQgMHgyMCB0eXBlIDQgYXQgMHg1MDQwCmZvdW5kLT4JdmVuZG9yPTB4ODA4Niwg ZGV2PTB4MjkzYSwgcmV2aWQ9MHgwMwoJZG9tYWluPTAsIGJ1cz0wLCBzbG90PTI5LCBmdW5jPTcK CWNsYXNzPTBjLTAzLTIwLCBoZHJ0eXBlPTB4MDAsIG1mZGV2PTAKCWNtZHJlZz0weDAwMDYsIHN0 YXRyZWc9MHgwMjkwLCBjYWNoZWxuc3o9MCAoZHdvcmRzKQoJbGF0dGltZXI9MHgwMCAoMCBucyks IG1pbmdudD0weDAwICgwIG5zKSwgbWF4bGF0PTB4MDAgKDAgbnMpCglpbnRwaW49YSwgaXJxPTEx Cglwb3dlcnNwZWMgMiAgc3VwcG9ydHMgRDAgRDMgIGN1cnJlbnQgRDAKCW1hcFsxMF06IHR5cGUg TWVtb3J5LCByYW5nZSAzMiwgYmFzZSAweGQ4NTA0ODAwLCBzaXplIDEwLCBlbmFibGVkCnBjaWIw OiBtYXRjaGVkIGVudHJ5IGZvciAwLjI5LklOVEEKcGNpYjA6IHNsb3QgMjkgSU5UQSBoYXJkd2ly ZWQgdG8gSVJRIDIwCnVua25vd246IFJlc2VydmVkIDB4NDAwIGJ5dGVzIGZvciByaWQgMHgxMCB0 eXBlIDMgYXQgMHhkODUwNDgwMAplaGNpIGVhcmx5OiBTTU0gYWN0aXZlLCByZXF1ZXN0IG93bmVy IGNoYW5nZQpmb3VuZC0+CXZlbmRvcj0weDgwODYsIGRldj0weDI0NDgsIHJldmlkPTB4OTMKCWRv bWFpbj0wLCBidXM9MCwgc2xvdD0zMCwgZnVuYz0wCgljbGFzcz0wNi0wNC0wMSwgaGRydHlwZT0w eDAxLCBtZmRldj0wCgljbWRyZWc9MHgwMDA3LCBzdGF0cmVnPTB4MDAxMCwgY2FjaGVsbnN6PTAg KGR3b3JkcykKCWxhdHRpbWVyPTB4MDAgKDAgbnMpLCBtaW5nbnQ9MHgwMCAoMCBucyksIG1heGxh dD0weDAwICgwIG5zKQpmb3VuZC0+CXZlbmRvcj0weDgwODYsIGRldj0weDI5MTksIHJldmlkPTB4 MDMKCWRvbWFpbj0wLCBidXM9MCwgc2xvdD0zMSwgZnVuYz0wCgljbGFzcz0wNi0wMS0wMCwgaGRy dHlwZT0weDAwLCBtZmRldj0xCgljbWRyZWc9MHgwMDA3LCBzdGF0cmVnPTB4MDIxMCwgY2FjaGVs bnN6PTAgKGR3b3JkcykKCWxhdHRpbWVyPTB4MDAgKDAgbnMpLCBtaW5nbnQ9MHgwMCAoMCBucyks IG1heGxhdD0weDAwICgwIG5zKQpmb3VuZC0+CXZlbmRvcj0weDgwODYsIGRldj0weDI5MjksIHJl dmlkPTB4MDMKCWRvbWFpbj0wLCBidXM9MCwgc2xvdD0zMSwgZnVuYz0yCgljbGFzcz0wMS0wNi0w MSwgaGRydHlwZT0weDAwLCBtZmRldj0wCgljbWRyZWc9MHgwMDA3LCBzdGF0cmVnPTB4MDJiMCwg Y2FjaGVsbnN6PTAgKGR3b3JkcykKCWxhdHRpbWVyPTB4MDAgKDAgbnMpLCBtaW5nbnQ9MHgwMCAo MCBucyksIG1heGxhdD0weDAwICgwIG5zKQoJaW50cGluPWIsIGlycT0xMQoJcG93ZXJzcGVjIDMg IHN1cHBvcnRzIEQwIEQzICBjdXJyZW50IEQwCglNU0kgc3VwcG9ydHMgMTYgbWVzc2FnZXMKCW1h cFsxMF06IHR5cGUgSS9PIFBvcnQsIHJhbmdlIDMyLCBiYXNlIDB4NTBlOCwgc2l6ZSAgMywgZW5h YmxlZAoJbWFwWzE0XTogdHlwZSBJL08gUG9ydCwgcmFuZ2UgMzIsIGJhc2UgMHg1MGZjLCBzaXpl ICAyLCBlbmFibGVkCgltYXBbMThdOiB0eXBlIEkvTyBQb3J0LCByYW5nZSAzMiwgYmFzZSAweDUw ZTAsIHNpemUgIDMsIGVuYWJsZWQKCW1hcFsxY106IHR5cGUgSS9PIFBvcnQsIHJhbmdlIDMyLCBi YXNlIDB4NTBmOCwgc2l6ZSAgMiwgZW5hYmxlZAoJbWFwWzIwXTogdHlwZSBJL08gUG9ydCwgcmFu Z2UgMzIsIGJhc2UgMHg1MDIwLCBzaXplICA1LCBlbmFibGVkCgltYXBbMjRdOiB0eXBlIE1lbW9y eSwgcmFuZ2UgMzIsIGJhc2UgMHhkODUwNDAwMCwgc2l6ZSAxMSwgZW5hYmxlZApwY2liMDogbWF0 Y2hlZCBlbnRyeSBmb3IgMC4zMS5JTlRCCnBjaWIwOiBzbG90IDMxIElOVEIgaGFyZHdpcmVkIHRv IElSUSAyMQpmb3VuZC0+CXZlbmRvcj0weDgwODYsIGRldj0weDI5MzAsIHJldmlkPTB4MDMKCWRv bWFpbj0wLCBidXM9MCwgc2xvdD0zMSwgZnVuYz0zCgljbGFzcz0wYy0wNS0wMCwgaGRydHlwZT0w eDAwLCBtZmRldj0wCgljbWRyZWc9MHgwMDAzLCBzdGF0cmVnPTB4MDI4MCwgY2FjaGVsbnN6PTAg KGR3b3JkcykKCWxhdHRpbWVyPTB4MDAgKDAgbnMpLCBtaW5nbnQ9MHgwMCAoMCBucyksIG1heGxh dD0weDAwICgwIG5zKQoJaW50cGluPWMsIGlycT0xMQoJbWFwWzEwXTogdHlwZSBNZW1vcnksIHJh bmdlIDY0LCBiYXNlIDB4ZDg1MDUwMDAsIHNpemUgIDgsIGVuYWJsZWQKCW1hcFsyMF06IHR5cGUg SS9PIFBvcnQsIHJhbmdlIDMyLCBiYXNlIDB4NTAwMCwgc2l6ZSAgNSwgZW5hYmxlZApwY2liMDog bWF0Y2hlZCBlbnRyeSBmb3IgMC4zMS5JTlRDCnBjaWIwOiBzbG90IDMxIElOVEMgaGFyZHdpcmVk IHRvIElSUSAxOAp2Z2FwY2kwOiA8VkdBLWNvbXBhdGlibGUgZGlzcGxheT4gcG9ydCAweDUwZjAt MHg1MGY3IG1lbSAweGQwMDAwMDAwLTB4ZDAzZmZmZmYsMHhjMDAwMDAwMC0weGNmZmZmZmZmIGly cSAxNiBhdCBkZXZpY2UgMi4wIG9uIHBjaTAKYWdwMDogPEludGVsIEdNNDUgU1ZHQSBjb250cm9s bGVyPiBvbiB2Z2FwY2kwCnZnYXBjaTA6IFJlc2VydmVkIDB4MTAwMDAwMDAgYnl0ZXMgZm9yIHJp ZCAweDE4IHR5cGUgMyBhdCAweGMwMDAwMDAwCnZnYXBjaTA6IFJlc2VydmVkIDB4NDAwMDAwIGJ5 dGVzIGZvciByaWQgMHgxMCB0eXBlIDMgYXQgMHhkMDAwMDAwMAphZ3AwOiBkZXRlY3RlZCA2NTUz Mmsgc3RvbGVuIG1lbW9yeQphZ3AwOiBhcGVydHVyZSBzaXplIGlzIDI1Nk0KdmdhcGNpMTogPFZH QS1jb21wYXRpYmxlIGRpc3BsYXk+IG1lbSAweGQ0NDAwMDAwLTB4ZDQ0ZmZmZmYgYXQgZGV2aWNl IDIuMSBvbiBwY2kwCnVoY2kwOiA8SW50ZWwgODI4MDFJIChJQ0g5KSBVU0IgY29udHJvbGxlcj4g cG9ydCAweDUwYzAtMHg1MGRmIGlycSAxNiBhdCBkZXZpY2UgMjYuMCBvbiBwY2kwCmlvYXBpYzA6 IHJvdXRpbmcgaW50cGluIDE2IChQQ0kgSVJRIDE2KSB0byBsYXBpYyAwIHZlY3RvciA0OQp1aGNp MDogW01QU0FGRV0KdWhjaTA6IFtJVEhSRUFEXQp1aGNpMDogTGVnU3VwID0gMHgyZjAwCnVzYnVz MDogPEludGVsIDgyODAxSSAoSUNIOSkgVVNCIGNvbnRyb2xsZXI+IG9uIHVoY2kwCnVoY2kxOiA8 SW50ZWwgODI4MDFJIChJQ0g5KSBVU0IgY29udHJvbGxlcj4gcG9ydCAweDUwYTAtMHg1MGJmIGly cSAxNyBhdCBkZXZpY2UgMjYuMSBvbiBwY2kwCmlvYXBpYzA6IHJvdXRpbmcgaW50cGluIDE3IChQ Q0kgSVJRIDE3KSB0byBsYXBpYyAwIHZlY3RvciA1MAp1aGNpMTogW01QU0FGRV0KdWhjaTE6IFtJ VEhSRUFEXQp1aGNpMTogTGVnU3VwID0gMHgyZjAwCnVzYnVzMTogPEludGVsIDgyODAxSSAoSUNI OSkgVVNCIGNvbnRyb2xsZXI+IG9uIHVoY2kxCmVoY2kwOiA8SW50ZWwgODI4MDFJIChJQ0g5KSBV U0IgMi4wIGNvbnRyb2xsZXI+IG1lbSAweGQ4NTA0YzAwLTB4ZDg1MDRmZmYgaXJxIDE4IGF0IGRl dmljZSAyNi43IG9uIHBjaTAKaW9hcGljMDogcm91dGluZyBpbnRwaW4gMTggKFBDSSBJUlEgMTgp IHRvIGxhcGljIDAgdmVjdG9yIDUxCmVoY2kwOiBbTVBTQUZFXQplaGNpMDogW0lUSFJFQURdCnVz YnVzMjogRUhDSSB2ZXJzaW9uIDEuMAp1c2J1czI6IDxJbnRlbCA4MjgwMUkgKElDSDkpIFVTQiAy LjAgY29udHJvbGxlcj4gb24gZWhjaTAKcGNpMDogPG11bHRpbWVkaWEsIEhEQT4gYXQgZGV2aWNl IDI3LjAgKG5vIGRyaXZlciBhdHRhY2hlZCkKcGNpYjE6IDxBQ1BJIFBDSS1QQ0kgYnJpZGdlPiBh dCBkZXZpY2UgMjguMCBvbiBwY2kwCnBjaWIxOiAgIGRvbWFpbiAgICAgICAgICAgIDAKcGNpYjE6 ICAgc2Vjb25kYXJ5IGJ1cyAgICAgMQpwY2liMTogICBzdWJvcmRpbmF0ZSBidXMgICAxCnBjaWIx OiAgIEkvTyBkZWNvZGUgICAgICAgIDB4NDAwMC0weDRmZmYKcGNpYjE6ICAgbWVtb3J5IGRlY29k ZSAgICAgMHhkNzUwMDAwMC0weGQ4NGZmZmZmCnBjaWIxOiAgIHByZWZldGNoZWQgZGVjb2RlIDB4 ZDA0MDAwMDAtMHhkMTNmZmZmZgpwY2kxOiA8QUNQSSBQQ0kgYnVzPiBvbiBwY2liMQpwY2kxOiBk b21haW49MCwgcGh5c2ljYWwgYnVzPTEKcGNpYjI6IDxBQ1BJIFBDSS1QQ0kgYnJpZGdlPiBhdCBk ZXZpY2UgMjguMiBvbiBwY2kwCnBjaWIyOiAgIGRvbWFpbiAgICAgICAgICAgIDAKcGNpYjI6ICAg c2Vjb25kYXJ5IGJ1cyAgICAgMgpwY2liMjogICBzdWJvcmRpbmF0ZSBidXMgICAyCnBjaWIyOiAg IEkvTyBkZWNvZGUgICAgICAgIDB4MzAwMC0weDNmZmYKcGNpYjI6ICAgbWVtb3J5IGRlY29kZSAg ICAgMHhkNjUwMDAwMC0weGQ3NGZmZmZmCnBjaWIyOiAgIHByZWZldGNoZWQgZGVjb2RlIDB4ZDE0 MDAwMDAtMHhkMjNmZmZmZgpwY2kyOiA8QUNQSSBQQ0kgYnVzPiBvbiBwY2liMgpwY2kyOiBkb21h aW49MCwgcGh5c2ljYWwgYnVzPTIKZm91bmQtPgl2ZW5kb3I9MHgxNjhjLCBkZXY9MHgwMDJiLCBy ZXZpZD0weDAxCglkb21haW49MCwgYnVzPTIsIHNsb3Q9MCwgZnVuYz0wCgljbGFzcz0wMi04MC0w MCwgaGRydHlwZT0weDAwLCBtZmRldj0wCgljbWRyZWc9MHgwMDA3LCBzdGF0cmVnPTB4MDAxMCwg Y2FjaGVsbnN6PTAgKGR3b3JkcykKCWxhdHRpbWVyPTB4MDAgKDAgbnMpLCBtaW5nbnQ9MHgwMCAo MCBucyksIG1heGxhdD0weDAwICgwIG5zKQoJaW50cGluPWEsIGlycT0xMQoJcG93ZXJzcGVjIDMg IHN1cHBvcnRzIEQwIEQxIEQzICBjdXJyZW50IEQwCglNU0kgc3VwcG9ydHMgMSBtZXNzYWdlCglt YXBbMTBdOiB0eXBlIE1lbW9yeSwgcmFuZ2UgNjQsIGJhc2UgMHhkNjUwMDAwMCwgc2l6ZSAxNiwg ZW5hYmxlZApwY2liMjogcmVxdWVzdGVkIG1lbW9yeSByYW5nZSAweGQ2NTAwMDAwLTB4ZDY1MGZm ZmY6IGdvb2QKcGNpYjI6IG1hdGNoZWQgZW50cnkgZm9yIDIuMC5JTlRBCnBjaWIyOiBzbG90IDAg SU5UQSBoYXJkd2lyZWQgdG8gSVJRIDE4CnBjaTI6IDxuZXR3b3JrPiBhdCBkZXZpY2UgMC4wIChu byBkcml2ZXIgYXR0YWNoZWQpCnBjaWIzOiA8QUNQSSBQQ0ktUENJIGJyaWRnZT4gYXQgZGV2aWNl IDI4LjMgb24gcGNpMApwY2liMzogICBkb21haW4gICAgICAgICAgICAwCnBjaWIzOiAgIHNlY29u ZGFyeSBidXMgICAgIDMKcGNpYjM6ICAgc3Vib3JkaW5hdGUgYnVzICAgMwpwY2liMzogICBJL08g ZGVjb2RlICAgICAgICAweDIwMDAtMHgyZmZmCnBjaWIzOiAgIG1lbW9yeSBkZWNvZGUgICAgIDB4 ZDU1MDAwMDAtMHhkNjRmZmZmZgpwY2liMzogICBwcmVmZXRjaGVkIGRlY29kZSAweGQyNDAwMDAw LTB4ZDMzZmZmZmYKcGNpMzogPEFDUEkgUENJIGJ1cz4gb24gcGNpYjMKcGNpMzogZG9tYWluPTAs IHBoeXNpY2FsIGJ1cz0zCmZvdW5kLT4JdmVuZG9yPTB4MTBlYywgZGV2PTB4ODEzNiwgcmV2aWQ9 MHgwMgoJZG9tYWluPTAsIGJ1cz0zLCBzbG90PTAsIGZ1bmM9MAoJY2xhc3M9MDItMDAtMDAsIGhk cnR5cGU9MHgwMCwgbWZkZXY9MAoJY21kcmVnPTB4MDAwNywgc3RhdHJlZz0weDAwMTAsIGNhY2hl bG5zej0wIChkd29yZHMpCglsYXR0aW1lcj0weDAwICgwIG5zKSwgbWluZ250PTB4MDAgKDAgbnMp LCBtYXhsYXQ9MHgwMCAoMCBucykKCWludHBpbj1hLCBpcnE9MTEKCXBvd2Vyc3BlYyAzICBzdXBw b3J0cyBEMCBEMSBEMiBEMyAgY3VycmVudCBEMAoJTVNJIHN1cHBvcnRzIDEgbWVzc2FnZSwgNjQg Yml0CglNU0ktWCBzdXBwb3J0cyAyIG1lc3NhZ2VzIGluIG1hcCAweDIwCgltYXBbMTBdOiB0eXBl IEkvTyBQb3J0LCByYW5nZSAzMiwgYmFzZSAweDIwMDAsIHNpemUgIDgsIGVuYWJsZWQKcGNpYjM6 IHJlcXVlc3RlZCBJL08gcmFuZ2UgMHgyMDAwLTB4MjBmZjogaW4gcmFuZ2UKCW1hcFsxOF06IHR5 cGUgUHJlZmV0Y2hhYmxlIE1lbW9yeSwgcmFuZ2UgNjQsIGJhc2UgMHhkMjQxMDAwMCwgc2l6ZSAx MiwgZW5hYmxlZApwY2liMzogcmVxdWVzdGVkIG1lbW9yeSByYW5nZSAweGQyNDEwMDAwLTB4ZDI0 MTBmZmY6IGdvb2QKCW1hcFsyMF06IHR5cGUgUHJlZmV0Y2hhYmxlIE1lbW9yeSwgcmFuZ2UgNjQs IGJhc2UgMHhkMjQwMDAwMCwgc2l6ZSAxNiwgZW5hYmxlZApwY2liMzogcmVxdWVzdGVkIG1lbW9y eSByYW5nZSAweGQyNDAwMDAwLTB4ZDI0MGZmZmY6IGdvb2QKcGNpYjM6IG1hdGNoZWQgZW50cnkg Zm9yIDMuMC5JTlRBCnBjaWIzOiBzbG90IDAgSU5UQSBoYXJkd2lyZWQgdG8gSVJRIDE5CnJlMDog PFJlYWxUZWsgODEwMUUvODEwMkUvODEwMkVMIFBDSWUgMTAvMTAwYmFzZVRYPiBwb3J0IDB4MjAw MC0weDIwZmYgbWVtIDB4ZDI0MTAwMDAtMHhkMjQxMGZmZiwweGQyNDAwMDAwLTB4ZDI0MGZmZmYg aXJxIDE5IGF0IGRldmljZSAwLjAgb24gcGNpMwpyZTA6IFJlc2VydmVkIDB4MTAwMCBieXRlcyBm b3IgcmlkIDB4MTggdHlwZSAzIGF0IDB4ZDI0MTAwMDAKcmUwOiBNU0kgY291bnQgOiAxCnJlMDog YXR0ZW1wdGluZyB0byBhbGxvY2F0ZSAxIE1TSSB2ZWN0b3JzICgxIHN1cHBvcnRlZCkKbXNpOiBy b3V0aW5nIE1TSSBJUlEgMjU2IHRvIGxvY2FsIEFQSUMgMCB2ZWN0b3IgNTIKcmUwOiB1c2luZyBJ UlEgMjU2IGZvciBNU0kKcmUwOiBVc2luZyAxIE1TSSBtZXNzYWdlcwpyZTA6IENoaXAgcmV2LiAw eDI0ODAwMDAwCnJlMDogTUFDIHJldi4gMHgwMDQwMDAwMAptaWlidXMwOiA8TUlJIGJ1cz4gb24g cmUwCnJscGh5MDogPFJUTDgyMDFMIDEwLzEwMCBtZWRpYSBpbnRlcmZhY2U+IFBIWSAxIG9uIG1p aWJ1czAKcmxwaHkwOiAgMTBiYXNlVCwgMTBiYXNlVC1GRFgsIDEwMGJhc2VUWCwgMTAwYmFzZVRY LUZEWCwgYXV0bwpyZTA6IGJwZiBhdHRhY2hlZApyZTA6IEV0aGVybmV0IGFkZHJlc3M6IDAwOjIz OjVhOmEyOmJkOjU0CnJlMDogW01QU0FGRV0KcmUwOiBbRklMVEVSXQpwY2liNDogPEFDUEkgUENJ LVBDSSBicmlkZ2U+IGF0IGRldmljZSAyOC41IG9uIHBjaTAKcGNpYjQ6ICAgZG9tYWluICAgICAg ICAgICAgMApwY2liNDogICBzZWNvbmRhcnkgYnVzICAgICA0CnBjaWI0OiAgIHN1Ym9yZGluYXRl IGJ1cyAgIDYKcGNpYjQ6ICAgSS9PIGRlY29kZSAgICAgICAgMHgxMDAwLTB4MWZmZgpwY2liNDog ICBtZW1vcnkgZGVjb2RlICAgICAweGQ0NTAwMDAwLTB4ZDU0ZmZmZmYKcGNpYjQ6ICAgcHJlZmV0 Y2hlZCBkZWNvZGUgMHhkMzQwMDAwMC0weGQ0M2ZmZmZmCnBjaTQ6IDxBQ1BJIFBDSSBidXM+IG9u IHBjaWI0CnBjaTQ6IGRvbWFpbj0wLCBwaHlzaWNhbCBidXM9NAp1aGNpMjogPEludGVsIDgyODAx SSAoSUNIOSkgVVNCIGNvbnRyb2xsZXI+IHBvcnQgMHg1MDgwLTB4NTA5ZiBpcnEgMjAgYXQgZGV2 aWNlIDI5LjAgb24gcGNpMAppb2FwaWMwOiByb3V0aW5nIGludHBpbiAyMCAoUENJIElSUSAyMCkg dG8gbGFwaWMgMCB2ZWN0b3IgNTMKdWhjaTI6IFtNUFNBRkVdCnVoY2kyOiBbSVRIUkVBRF0KdWhj aTI6IExlZ1N1cCA9IDB4MmYwMAp1c2J1czM6IDxJbnRlbCA4MjgwMUkgKElDSDkpIFVTQiBjb250 cm9sbGVyPiBvbiB1aGNpMgp1aGNpMzogPEludGVsIDgyODAxSSAoSUNIOSkgVVNCIGNvbnRyb2xs ZXI+IHBvcnQgMHg1MDYwLTB4NTA3ZiBpcnEgMjIgYXQgZGV2aWNlIDI5LjEgb24gcGNpMAppb2Fw aWMwOiByb3V0aW5nIGludHBpbiAyMiAoUENJIElSUSAyMikgdG8gbGFwaWMgMCB2ZWN0b3IgNTQK dWhjaTM6IFtNUFNBRkVdCnVoY2kzOiBbSVRIUkVBRF0KdWhjaTM6IExlZ1N1cCA9IDB4MmYwMAp1 c2J1czQ6IDxJbnRlbCA4MjgwMUkgKElDSDkpIFVTQiBjb250cm9sbGVyPiBvbiB1aGNpMwp1aGNp NDogPEludGVsIDgyODAxSSAoSUNIOSkgVVNCIGNvbnRyb2xsZXI+IHBvcnQgMHg1MDQwLTB4NTA1 ZiBpcnEgMTggYXQgZGV2aWNlIDI5LjIgb24gcGNpMAp1aGNpNDogW01QU0FGRV0KdWhjaTQ6IFtJ VEhSRUFEXQp1aGNpNDogTGVnU3VwID0gMHgyZjAwCnVzYnVzNTogPEludGVsIDgyODAxSSAoSUNI OSkgVVNCIGNvbnRyb2xsZXI+IG9uIHVoY2k0CmVoY2kxOiA8SW50ZWwgODI4MDFJIChJQ0g5KSBV U0IgMi4wIGNvbnRyb2xsZXI+IG1lbSAweGQ4NTA0ODAwLTB4ZDg1MDRiZmYgaXJxIDIwIGF0IGRl dmljZSAyOS43IG9uIHBjaTAKZWhjaTE6IFtNUFNBRkVdCmVoY2kxOiBbSVRIUkVBRF0KdXNidXM2 OiBFSENJIHZlcnNpb24gMS4wCnVzYnVzNjogPEludGVsIDgyODAxSSAoSUNIOSkgVVNCIDIuMCBj b250cm9sbGVyPiBvbiBlaGNpMQpwY2liNTogPEFDUEkgUENJLVBDSSBicmlkZ2U+IGF0IGRldmlj ZSAzMC4wIG9uIHBjaTAKcGNpYjU6ICAgZG9tYWluICAgICAgICAgICAgMApwY2liNTogICBzZWNv bmRhcnkgYnVzICAgICA3CnBjaWI1OiAgIHN1Ym9yZGluYXRlIGJ1cyAgIDcKcGNpYjU6ICAgSS9P IGRlY29kZSAgICAgICAgMHhmMDAwLTB4ZmZmCnBjaWI1OiAgIG5vIHByZWZldGNoZWQgZGVjb2Rl CnBjaWI1OiAgIFN1YnRyYWN0aXZlbHkgZGVjb2RlZCBicmlkZ2UuCnBjaTc6IDxBQ1BJIFBDSSBi dXM+IG9uIHBjaWI1CnBjaTc6IGRvbWFpbj0wLCBwaHlzaWNhbCBidXM9Nwppc2FiMDogPFBDSS1J U0EgYnJpZGdlPiBhdCBkZXZpY2UgMzEuMCBvbiBwY2kwCmlzYTA6IDxJU0EgYnVzPiBvbiBpc2Fi MAphdGFwY2kwOiA8SW50ZWwgKElEPTI5Mjk4MDg2KSBBSENJIGNvbnRyb2xsZXI+IHBvcnQgMHg1 MGU4LTB4NTBlZiwweDUwZmMtMHg1MGZmLDB4NTBlMC0weDUwZTcsMHg1MGY4LTB4NTBmYiwweDUw MjAtMHg1MDNmIG1lbSAweGQ4NTA0MDAwLTB4ZDg1MDQ3ZmYgaXJxIDIxIGF0IGRldmljZSAzMS4y IG9uIHBjaTAKYXRhcGNpMDogUmVzZXJ2ZWQgMHgyMCBieXRlcyBmb3IgcmlkIDB4MjAgdHlwZSA0 IGF0IDB4NTAyMAphdGFwY2kwOiBSZXNlcnZlZCAweDgwMCBieXRlcyBmb3IgcmlkIDB4MjQgdHlw ZSAzIGF0IDB4ZDg1MDQwMDAKaW9hcGljMDogcm91dGluZyBpbnRwaW4gMjEgKFBDSSBJUlEgMjEp IHRvIGxhcGljIDAgdmVjdG9yIDU1CmF0YXBjaTA6IFtNUFNBRkVdCmF0YXBjaTA6IFtJVEhSRUFE XQphdGFwY2kwOiBBSENJIHYxLjIwIGNvbnRyb2xsZXIgd2l0aCA0IDNHYnBzIHBvcnRzLCBQTSBz dXBwb3J0ZWQKYXRhcGNpMDogQ2FwczogNjRiaXQgTkNRIFNOVEYgU1MgQUxQIEFMIENMTyAzR2Jw cyBQTSBQTUQgU1NDIFBTQyAzMmNtZCBDQ0MgRU0gZVNBVEEgNHBvcnRzCmF0YTI6IDxBVEEgY2hh bm5lbCAwPiBvbiBhdGFwY2kwCmF0YTI6IEFIQ0kgcmVzZXQuLi4KYXRhMjogaGFyZHdhcmUgcmVz ZXQgLi4uCmF0YTI6IFNBVEEgY29ubmVjdCB0aW1lPTBtcyBzdGF0dXM9MDAwMDAxMjMKYXRhMjog cmVhZHkgd2FpdCB0aW1lPTRtcwphdGEyOiBzb2Z0d2FyZSByZXNldCBwb3J0IDE1Li4uCmF0YTI6 IHJlYWR5IHdhaXQgdGltZT0wbXMKYXRhMjogU0lHTkFUVVJFOiAwMDAwMDEwMQphdGEyOiBBSENJ IHJlc2V0IGRvbmU6IGRldmljZXM9MDAwMDAwMDEKYXRhMjogW01QU0FGRV0KYXRhMjogW0lUSFJF QURdCmF0YTM6IDxBVEEgY2hhbm5lbCA0PiBvbiBhdGFwY2kwCmF0YTM6IEFIQ0kgcmVzZXQuLi4K YXRhMzogaGFyZHdhcmUgcmVzZXQgLi4uCmF0YTM6IFNBVEEgY29ubmVjdCB0aW1lPTEwbXMgc3Rh dHVzPTAwMDAwMTEzCmF0YTM6IHJlYWR5IHdhaXQgdGltZT0wbXMKYXRhMzogc29mdHdhcmUgcmVz ZXQgcG9ydCAxNS4uLgphdGEzOiByZWFkeSB3YWl0IHRpbWU9MG1zCmF0YTM6IFNJR05BVFVSRTog ZWIxNDAxMDEKYXRhMzogQUhDSSByZXNldCBkb25lOiBkZXZpY2VzPTAwMDEwMDAwCmF0YTM6IFtN UFNBRkVdCmF0YTM6IFtJVEhSRUFEXQphdGE0OiA8QVRBIGNoYW5uZWwgNT4gb24gYXRhcGNpMAph dGE0OiBBSENJIHJlc2V0Li4uCmF0YTQ6IGhhcmR3YXJlIHJlc2V0IC4uLgphdGE0OiBTQVRBIGNv bm5lY3QgdGltZW91dCBzdGF0dXM9MDAwMDAwMDAKYXRhNDogQUhDSSByZXNldCBkb25lOiBwaHkg cmVzZXQgZm91bmQgbm8gZGV2aWNlCmF0YTQ6IFtNUFNBRkVdCmF0YTQ6IFtJVEhSRUFEXQpwY2kw OiA8c2VyaWFsIGJ1cywgU01CdXM+IGF0IGRldmljZSAzMS4zIChubyBkcml2ZXIgYXR0YWNoZWQp CmFjcGlfdHowOiA8VGhlcm1hbCBab25lPiBvbiBhY3BpMAphdHJ0YzA6IDxBVCByZWFsdGltZSBj bG9jaz4gcG9ydCAweDcwLTB4Nzcgb24gYWNwaTAKYXRydGMwOiBXYXJuaW5nOiBDb3VsZG4ndCBt YXAgSS9PLgphdHJ0YzA6IHJlZ2lzdGVyZWQgYXMgYSB0aW1lLW9mLWRheSBjbG9jayAocmVzb2x1 dGlvbiAxMDAwMDAwdXMpCmF0a2JkYzA6IDxLZXlib2FyZCBjb250cm9sbGVyIChpODA0Mik+IHBv cnQgMHg2MCwweDY0IGlycSAxIG9uIGFjcGkwCmF0a2JkMDogPEFUIEtleWJvYXJkPiBpcnEgMSBv biBhdGtiZGMwCmF0a2JkOiB0aGUgY3VycmVudCBrYmQgY29udHJvbGxlciBjb21tYW5kIGJ5dGUg MDA2NwphdGtiZDoga2V5Ym9hcmQgSUQgMHg0MWFiICgyKQprYmQwIGF0IGF0a2JkMAprYmQwOiBh dGtiZDAsIEFUIDEwMS8xMDIgKDIpLCBjb25maWc6MHgwLCBmbGFnczoweDNkMDAwMAppb2FwaWMw OiByb3V0aW5nIGludHBpbiAxIChJU0EgSVJRIDEpIHRvIGxhcGljIDAgdmVjdG9yIDU2CmF0a2Jk MDogW0dJQU5ULUxPQ0tFRF0KYXRrYmQwOiBbSVRIUkVBRF0KcHNtMDogdW5hYmxlIHRvIGFsbG9j YXRlIElSUQpwc21jcG5wMDogPFBTLzIgbW91c2UgcG9ydD4gaXJxIDEyIG9uIGFjcGkwCnBzbTA6 IGN1cnJlbnQgY29tbWFuZCBieXRlOjAwNjcKcHNtMDogPFBTLzIgTW91c2U+IGlycSAxMiBvbiBh dGtiZGMwCmlvYXBpYzA6IHJvdXRpbmcgaW50cGluIDEyIChJU0EgSVJRIDEyKSB0byBsYXBpYyAw IHZlY3RvciA1Nwpwc20wOiBbR0lBTlQtTE9DS0VEXQpwc20wOiBbSVRIUkVBRF0KcHNtMDogbW9k ZWwgR2VuZXJpYyBQUy8yIG1vdXNlLCBkZXZpY2UgSUQgMC0wMCwgMiBidXR0b25zCnBzbTA6IGNv bmZpZzowMDAwMDAwMCwgZmxhZ3M6MDAwMDAwMDgsIHBhY2tldCBzaXplOjMKcHNtMDogc3luY21h c2s6YzAsIHN5bmNiaXRzOjAwCmNwdTA6IDxBQ1BJIENQVT4gb24gYWNwaTAKQUNQSTogU1NEVCAw eGI5ZTZlYzk4IDAwMjIzICh2MSAgUG1SZWYgIENwdTBJc3QgMDAwMDMwMDAgSU5UTCAyMDA1MTEx NykKQUNQSTogU1NEVCAweGI5ZTZjNjE4IDAwNUIzICh2MSAgUG1SZWYgIENwdTBDc3QgMDAwMDMw MDEgSU5UTCAyMDA1MTExNykKZXN0MDogPEVuaGFuY2VkIFNwZWVkU3RlcCBGcmVxdWVuY3kgQ29u dHJvbD4gb24gY3B1MAplc3QwOiBJbnZhbGlkIGlkMTYgKHNldCwgY3VyKSA9ICgyMDczLCAxODk3 OSkKZXN0MDogQ2FuJ3QgY2hlY2sgZnJlcSAxNjAwLCBpdCBtYXkgYmUgaW52YWxpZAplc3QwOiBJ bnZhbGlkIGlkMTYgKHNldCwgY3VyKSA9ICgxNTUzLCAxODk3OSkKZXN0MDogQ2FuJ3QgY2hlY2sg ZnJlcSAxMjAwLCBpdCBtYXkgYmUgaW52YWxpZApwNHRjYzA6IDxDUFUgRnJlcXVlbmN5IFRoZXJt YWwgQ29udHJvbD4gb24gY3B1MApjcHUxOiA8QUNQSSBDUFU+IG9uIGFjcGkwCkFDUEk6IFNTRFQg MHhiOWU2ZGUxOCAwMDFDRiAodjEgIFBtUmVmICAgIEFwSXN0IDAwMDAzMDAwIElOVEwgMjAwNTEx MTcpCkFDUEk6IFNTRFQgMHhiOWU2ZWYxOCAwMDA4RCAodjEgIFBtUmVmICAgIEFwQ3N0IDAwMDAz MDAwIElOVEwgMjAwNTExMTcpCmVzdDE6IDxFbmhhbmNlZCBTcGVlZFN0ZXAgRnJlcXVlbmN5IENv bnRyb2w+IG9uIGNwdTEKZXN0MTogSW52YWxpZCBpZDE2IChzZXQsIGN1cikgPSAoMjA3MywgMTg5 NzkpCmVzdDE6IENhbid0IGNoZWNrIGZyZXEgMTYwMCwgaXQgbWF5IGJlIGludmFsaWQKZXN0MTog SW52YWxpZCBpZDE2IChzZXQsIGN1cikgPSAoMTU1MywgMTg5NzkpCmVzdDE6IENhbid0IGNoZWNr IGZyZXEgMTIwMCwgaXQgbWF5IGJlIGludmFsaWQKcDR0Y2MxOiA8Q1BVIEZyZXF1ZW5jeSBUaGVy bWFsIENvbnRyb2w+IG9uIGNwdTEKZXhfaXNhX2lkZW50aWZ5KCkKaXNhX3Byb2JlX2NoaWxkcmVu OiBkaXNhYmxpbmcgUG5QIGRldmljZXMKYXRrYmRjOiBhdGtiZGMwIGFscmVhZHkgZXhpc3RzOyBz a2lwcGluZyBpdAphdHJ0YzogYXRydGMwIGFscmVhZHkgZXhpc3RzOyBza2lwcGluZyBpdApzYzog c2MwIGFscmVhZHkgZXhpc3RzOyBza2lwcGluZyBpdAppc2FfcHJvYmVfY2hpbGRyZW46IHByb2Jp bmcgbm9uLVBuUCBkZXZpY2VzCm9ybTA6IDxJU0EgT3B0aW9uIFJPTT4gYXQgaW9tZW0gMHhjMDAw MC0weGNmN2ZmIG9uIGlzYTAKc2MwOiA8U3lzdGVtIGNvbnNvbGU+IGF0IGZsYWdzIDB4MTAwIG9u IGlzYTAKc2MwOiBWR0EgPDE2IHZpcnR1YWwgY29uc29sZXMsIGZsYWdzPTB4MzAwPgpzYzA6IGZi MCwga2JkMSwgdGVybWluYWwgZW11bGF0b3I6IHNjdGVrZW4gKHRla2VuIHRlcm1pbmFsKQp2Z2Ew OiA8R2VuZXJpYyBJU0EgVkdBPiBhdCBwb3J0IDB4M2MwLTB4M2RmIGlvbWVtIDB4YTAwMDAtMHhi ZmZmZiBvbiBpc2EwCmZkYzAgZmFpbGVkIHRvIHByb2JlIGF0IHBvcnQgMHgzZjAtMHgzZjUsMHgz ZjcgaXJxIDYgZHJxIDIgb24gaXNhMApwcGMwOiBjYW5ub3QgcmVzZXJ2ZSBJL08gcG9ydCByYW5n ZQpwcGMwOiA8UGFyYWxsZWwgcG9ydD4gZmFpbGVkIHRvIHByb2JlIGF0IGlycSA3IG9uIGlzYTAK dWFydDA6IDxuczgyNTA+IGZhaWxlZCB0byBwcm9iZSBhdCBwb3J0IDB4M2Y4LTB4M2ZmIGlycSA0 IG9uIGlzYTAKdWFydDE6IDxuczgyNTA+IGZhaWxlZCB0byBwcm9iZSBhdCBwb3J0IDB4MmY4LTB4 MmZmIGlycSAzIG9uIGlzYTAKaXNhX3Byb2JlX2NoaWxkcmVuOiBwcm9iaW5nIFBuUCBkZXZpY2Vz CkRldmljZSBjb25maWd1cmF0aW9uIGZpbmlzaGVkLgpSZWR1Y2luZyBrZXJuLm1heHZub2RlcyAy NTE2MDAgLT4gMTAwMDAwCnByb2NmcyByZWdpc3RlcmVkCmxhcGljOiBEaXZpc29yIDIsIEZyZXF1 ZW5jeSA5OTk1MDMxNSBoegpUaW1lY291bnRlciAiVFNDIiBmcmVxdWVuY3kgMjA5ODk1NjMyMSBI eiBxdWFsaXR5IC0xMDAKVGltZWNvdW50ZXJzIHRpY2sgZXZlcnkgMS4wMDAgbXNlYwp2bGFuOiBp bml0aWFsaXplZCwgdXNpbmcgaGFzaCB0YWJsZXMgd2l0aCBjaGFpbmluZwpsbzA6IGJwZiBhdHRh Y2hlZApocHRycjogbm8gY29udHJvbGxlciBkZXRlY3RlZC4KYXRhMjogSWRlbnRpZnlpbmcgZGV2 aWNlczogMDAwMDAwMDEKYXRhMjogTmV3IGRldmljZXM6IDAwMDAwMDAxCnVzYnVzMDogMTJNYnBz IEZ1bGwgU3BlZWQgVVNCIHYxLjAKdXNidXMxOiAxMk1icHMgRnVsbCBTcGVlZCBVU0IgdjEuMAp1 c2J1czI6IDQ4ME1icHMgSGlnaCBTcGVlZCBVU0IgdjIuMAp1c2J1czM6IDEyTWJwcyBGdWxsIFNw ZWVkIFVTQiB2MS4wCnVzYnVzNDogMTJNYnBzIEZ1bGwgU3BlZWQgVVNCIHYxLjAKdXNidXM1OiAx Mk1icHMgRnVsbCBTcGVlZCBVU0IgdjEuMAp1c2J1czY6IDQ4ME1icHMgSGlnaCBTcGVlZCBVU0Ig djIuMAphdGEyLW1hc3RlcjogcGlvPVBJTzQgd2RtYT1XRE1BMiB1ZG1hPVVETUExMDAgY2FibGU9 NDAgd2lyZQpiYXR0ZXJ5MDogYmF0dGVyeSBpbml0aWFsaXphdGlvbiBzdGFydGFkNDogc2V0dGlu ZyBVRE1BMTAwCgphY3BpX2FjYWQwOiBhY2xpbmUgaW5pdGlhbGl6YXRpb24gc3RhcnQKYWQ0OiA0 NzY5NDBNQiA8U2VhZ2F0ZSBTVDk1MDAzMjVBUyAwMDAzSFBNMT4gYXQgYXRhMi1tYXN0ZXIgVURN QTEwMCBTQVRBIDNHYi9zCmFkNDogOTc2NzczMTY4IHNlY3RvcnMgWzk2OTAyMUMvMTZILzYzU10g MTYgc2VjdG9ycy9pbnRlcnJ1cHQgMSBkZXB0aCBxdWV1ZQpHRU9NOiBuZXcgZGlzayBhZDQKYWNw aV90ejA6IF9BQzA6IHRlbXBlcmF0dXJlIDY3LjAgPj0gc2V0cG9pbnQgNjcuMAp1Z2VuMC4xOiA8 SW50ZWw+IGF0IHVzYnVzMAp1aHViMDogPEludGVsIFVIQ0kgcm9vdCBIVUIsIGNsYXNzIDkvMCwg cmV2IDEuMDAvMS4wMCwgYWRkciAxPiBvbiB1c2J1czAKdWdlbjEuMTogPEludGVsPiBhdCB1c2J1 czEKdWh1YjE6IDxJbnRlbCBVSENJIHJvb3QgSFVCLCBjbGFzcyA5LzAsIHJldiAxLjAwLzEuMDAs IGFkZHIgMT4gb24gdXNidXMxCnVnZW4yLjE6IDxJbnRlbD4gYXQgdXNidXMyCnVodWIyOiA8SW50 ZWwgRUhDSSByb290IEhVQiwgY2xhc3MgOS8wLCByZXYgMi4wMC8xLjAwLCBhZGRyIDE+IG9uIHVz YnVzMgp1Z2VuMy4xOiA8SW50ZWw+IGF0IHVzYnVzMwp1aHViMzogPEludGVsIFVIQ0kgcm9vdCBI VUIsIGNsYXNzIDkvMCwgcmV2IDEuMDAvMS4wMCwgYWRkciAxPiBvbiB1c2J1czMKdWdlbjQuMTog PEludGVsPiBhdCB1c2J1czQKdWh1YjQ6IDxJbnRlbCBVSENJIHJvb3QgSFVCLCBjbGFzcyA5LzAs IHJldiAxLjAwLzEuMDAsIGFkZHIgMT4gb24gdXNidXM0CnVnZW41LjE6IDxJbnRlbD4gYXQgdXNi dXM1CnVodWI1OiA8SW50ZWwgVUhDSSByb290IEhVQiwgY2xhc3MgOS8wLCByZXYgMS4wMC8xLjAw LCBhZGRyIDE+IG9uIHVzYnVzNQp1Z2VuNi4xOiA8SW50ZWw+IGF0IHVzYnVzNgp1aHViNjogPElu dGVsIEVIQ0kgcm9vdCBIVUIsIGNsYXNzIDkvMCwgcmV2IDIuMDAvMS4wMCwgYWRkciAxPiBvbiB1 c2J1czYKYWNwaV90ejA6IHN3aXRjaGVkIGZyb20gTk9ORSB0byBfQUMwOiA2Ny4wQwphY3BpX2Fj YWQwOiBPbiBMaW5lCmFjcGlfYWNhZDA6IGFjbGluZSBpbml0aWFsaXphdGlvbiBkb25lLCB0cmll ZCAxIHRpbWVzCmFkNDogSW50ZWwgY2hlY2sxIGZhaWxlZAphZDQ6IEFkYXB0ZWMgY2hlY2sxIGZh aWxlZAphZDQ6IExTSSAodjMpIGNoZWNrMSBmYWlsZWQKYWQ0OiBMU0kgKHYyKSBjaGVjazEgZmFp bGVkCmFkNDogRnJlZUJTRCBjaGVjazEgZmFpbGVkCmF0YTM6IElkZW50aWZ5aW5nIGRldmljZXM6 IDAwMDEwMDAwCmF0YTM6IE5ldyBkZXZpY2VzOiAwMDAxMDAwMAphdGEzLW1hc3RlcjogcGlvPVBJ TzQgd2RtYT1XRE1BMiB1ZG1hPVVETUExMDAgY2FibGU9NDAgd2lyZQphY2QwOiBzZXR0aW5nIFVE TUExMDAKYXRhMzogZGV2aWNlX3Jlc2V0IHRpbWVvdXQ9OTcwdXMKYWNkMDogPEhMLURULVNUIERW RFJBTSBHVDIwTC9EQzAzPiBEVkRSIGRyaXZlIGF0IGF0YTMgYXMgbWFzdGVyCmFjZDA6IHJlYWQg NDEzNEtCL3MgKDQxMzRLQi9zKSB3cml0ZSA0MTM0S0IvcyAoNDEzNEtCL3MpLCAxMDI0S0IgYnVm ZmVyLCBVRE1BMTAwIFNBVEEgMS41R2IvcwphY2QwOiBSZWFkczogQ0RSLCBDRFJXLCBDRERBIHN0 cmVhbSwgRFZEUk9NLCBEVkRSLCBEVkRSQU0sIHBhY2tldAphY2QwOiBXcml0ZXM6IENEUiwgQ0RS VywgRFZEUiwgRFZEUkFNLCB0ZXN0IHdyaXRlLCBidXJucHJvb2YKYWNkMDogQXVkaW86IHBsYXks IDI1NiB2b2x1bWUgbGV2ZWxzCmFjZDA6IE1lY2hhbmlzbTogZWplY3RhYmxlIHRyYXksIHVubG9j a2VkCmFjZDA6IE1lZGl1bTogbm8vYmxhbmsgZGlzYwphdGE0OiBJZGVudGlmeWluZyBkZXZpY2Vz OiAwMDAwMDAwMAphdGE0OiBOZXcgZGV2aWNlczogMDAwMDAwMDAKQVRBIFBzZXVkb1JBSUQgbG9h ZGVkClNNUDogQVAgQ1BVICMxIExhdW5jaGVkIQpjcHUxIEFQOgogICAgIElEOiAweDAxMDAwMDAw ICAgVkVSOiAweDAwMDUwMDE0IExEUjogMHgwMDAwMDAwMCBERlI6IDB4ZmZmZmZmZmYKICBsaW50 MDogMHgwMDAxMDcwMCBsaW50MTogMHgwMDAwMDQwMCBUUFI6IDB4MDAwMDAwMDAgU1ZSOiAweDAw MDAwMWZmCiAgdGltZXI6IDB4MDAwMjAwZWYgdGhlcm06IDB4MDAwMTAwMDAgZXJyOiAweDAwMDEw MDAwIHBjbTogMHgwMDAxMDQwMAppb2FwaWMwOiByb3V0aW5nIGludHBpbiA5IChJU0EgSVJRIDkp IHRvIGxhcGljIDEgdmVjdG9yIDQ4CmlvYXBpYzA6IHJvdXRpbmcgaW50cGluIDE2IChQQ0kgSVJR IDE2KSB0byBsYXBpYyAxIHZlY3RvciA0OQppb2FwaWMwOiByb3V0aW5nIGludHBpbiAxOCAoUENJ IElSUSAxOCkgdG8gbGFwaWMgMSB2ZWN0b3IgNTAKaW9hcGljMDogcm91dGluZyBpbnRwaW4gMjEg KFBDSSBJUlEgMjEpIHRvIGxhcGljIDEgdmVjdG9yIDUxCm1zaTogQXNzaWduaW5nIE1TSSBJUlEg MjU2IHRvIGxvY2FsIEFQSUMgMSB2ZWN0b3IgNTIKdWh1YjA6IDIgcG9ydHMgd2l0aCAyIHJlbW92 YWJsZSwgc2VsZiBwb3dlcmVkCnVodWIxOiAyIHBvcnRzIHdpdGggMiByZW1vdmFibGUsIHNlbGYg cG93ZXJlZAp1aHViMzogMiBwb3J0cyB3aXRoIDIgcmVtb3ZhYmxlLCBzZWxmIHBvd2VyZWQKdWh1 YjQ6IDIgcG9ydHMgd2l0aCAyIHJlbW92YWJsZSwgc2VsZiBwb3dlcmVkCnVodWI1OiAyIHBvcnRz IHdpdGggMiByZW1vdmFibGUsIHNlbGYgcG93ZXJlZApiYXR0ZXJ5MDogYmF0dGVyeSBpbml0aWFs aXphdGlvbiBkb25lLCB0cmllZCAxIHRpbWVzClJvb3QgbW91bnQgd2FpdGluZyBmb3I6IHVzYnVz NiB1c2J1czIKUm9vdCBtb3VudCB3YWl0aW5nIGZvcjogdXNidXM2IHVzYnVzMgp1aHViMjogNCBw b3J0cyB3aXRoIDQgcmVtb3ZhYmxlLCBzZWxmIHBvd2VyZWQKdWh1YjY6IDYgcG9ydHMgd2l0aCA2 IHJlbW92YWJsZSwgc2VsZiBwb3dlcmVkClJvb3QgbW91bnQgd2FpdGluZyBmb3I6IHVzYnVzNgpS b290IG1vdW50IHdhaXRpbmcgZm9yOiB1c2J1czYKdWdlbjYuMjogPEdlbmVyaWM+IGF0IHVzYnVz Ngp1bWFzczA6IDxCdWxrLUluLCBCdWxrLU91dCwgSW50ZXJmYWNlPiBvbiB1c2J1czYKdW1hc3Mw OiAgU0NTSSBvdmVyIEJ1bGstT25seTsgcXVpcmtzID0gMHgwMDAwCnVnZW40LjI6IDxMb2dpdGVj aD4gYXQgdXNidXM0CnVtczA6IDxMb2dpdGVjaCBVU0IgUmVjZWl2ZXIsIGNsYXNzIDAvMCwgcmV2 IDEuMTAvNDYuMDAsIGFkZHIgMj4gb24gdXNidXM0CnVtczA6IDggYnV0dG9ucyBhbmQgW1hZWl0g Y29vcmRpbmF0ZXMgSUQ9MAp1aGlkMDogPExvZ2l0ZWNoIFVTQiBSZWNlaXZlciwgY2xhc3MgMC8w LCByZXYgMS4xMC80Ni4wMCwgYWRkciAyPiBvbiB1c2J1czQKUm9vdCBtb3VudCB3YWl0aW5nIGZv cjogdXNidXM2CnVtYXNzMDowOjA6LTE6IEF0dGFjaGVkIHRvIHNjYnVzMAoocHJvYmUwOnVtYXNz LXNpbTA6MDowOjApOiBEb3duIHJldmluZyBQcm90b2NvbCBWZXJzaW9uIGZyb20gMiB0byAwPwoo cHJvYmUwOnVtYXNzLXNpbTA6MDowOjApOiBURVNUIFVOSVQgUkVBRFkuIENEQjogMCAwIDAgMCAw IDAgCihwcm9iZTA6dW1hc3Mtc2ltMDowOjA6MCk6IENBTSBTdGF0dXM6IFNDU0kgU3RhdHVzIEVy cm9yCihwcm9iZTA6dW1hc3Mtc2ltMDowOjA6MCk6IFNDU0kgU3RhdHVzOiBDaGVjayBDb25kaXRp b24KKHByb2JlMDp1bWFzcy1zaW0wOjA6MDowKTogTk9UIFJFQURZIGFzYzozYSwwCihwcm9iZTA6 dW1hc3Mtc2ltMDowOjA6MCk6IE1lZGl1bSBub3QgcHJlc2VudAoocHJvYmUwOnVtYXNzLXNpbTA6 MDowOjApOiAocHJvYmUwOnVtYXNzLXNpbTA6MDowOjApOiBURVNUIFVOSVQgUkVBRFkuIENEQjog MCAwIDAgMCAwIDAgCihwcm9iZTA6dW1hc3Mtc2ltMDowOjA6MCk6IE5PVCBSRUFEWSBhc2M6M2Es MAoocHJvYmUwOnVtYXNzLXNpbTA6MDowOjApOiBNZWRpdW0gbm90IHByZXNlbnQKVW5yZXRyeWFi bGUgZXJyb3IKKHByb2JlMDp1bWFzcy1zaW0wOjA6MDowKTogZXJyb3IgNgoocHJvYmUwOnVtYXNz LXNpbTA6MDowOjApOiBVbnJldHJ5YWJsZSBFcnJvcgpwYXNzMCBhdCB1bWFzcy1zaW0wIGJ1cyAw IHNjYnVzMCB0YXJnZXQgMCBsdW4gMApwYXNzMDogPEdlbmVyaWMtIE11bHRpLUNhcmQgMS4wMD4g UmVtb3ZhYmxlIERpcmVjdCBBY2Nlc3MgU0NTSS0wIGRldmljZSAKcGFzczA6IFNlcmlhbCBOdW1i ZXIgMjAwNzExMTQxNzM0MDAwMDAKcGFzczA6IDQwLjAwME1CL3MgdHJhbnNmZXJzCkdFT006IG5l dyBkaXNrIGRhMAooZGEwOnVtYXNzLXNpbTA6MDowOjApOiBlcnJvciA2CihkYTA6dW1hc3Mtc2lt MDowOjA6MCk6IFVucmV0cnlhYmxlIEVycm9yCmRhMCBhdCB1bWFzcy1zaW0wIGJ1cyAwIHNjYnVz MCB0YXJnZXQgMCBsdW4gMApkYTA6IDxHZW5lcmljLSBNdWx0aS1DYXJkIDEuMDA+IFJlbW92YWJs ZSBEaXJlY3QgQWNjZXNzIFNDU0ktMCBkZXZpY2UgCmRhMDogU2VyaWFsIE51bWJlciAyMDA3MTEx NDE3MzQwMDAwMApkYTA6IDQwLjAwME1CL3MgdHJhbnNmZXJzCmRhMDogQXR0ZW1wdCB0byBxdWVy eSBkZXZpY2Ugc2l6ZSBmYWlsZWQ6IE5PVCBSRUFEWSwgTWVkaXVtIG5vdCBwcmVzZW50CihkYTA6 dW1hc3Mtc2ltMDowOjA6MCk6IGVycm9yIDYKKGRhMDp1bWFzcy1zaW0wOjA6MDowKTogVW5yZXRy eWFibGUgRXJyb3IKT3BlbmVkIGRpc2sgZGEwIC0+IDYKKGRhMDp1bWFzcy1zaW0wOjA6MDowKTog ZXJyb3IgNgooZGEwOnVtYXNzLXNpbTA6MDowOjApOiBVbnJldHJ5YWJsZSBFcnJvcgpPcGVuZWQg ZGlzayBkYTAgLT4gNgp1Z2VuNi4zOiA8U3VZaW4+IGF0IHVzYnVzNgpUcnlpbmcgdG8gbW91bnQg cm9vdCBmcm9tIHVmczovZGV2L2FkNHM0YQpjdF90b190cyhbMjAxMC0wMS0yNSAwOToyOTowMF0p ID0gMTI2NDQxMTc0MC4wMDAwMDAwMDAKc3RhcnRfaW5pdDogdHJ5aW5nIC9zYmluL2luaXQKYWNw aV90ejA6IHN3aXRjaGVkIGZyb20gX0FDMCB0byBOT05FOiA2Mi4wQwp0c190b19jdCgxMjY0NDEx NzY5LjM2NTg1NjY3NikgPSBbMjAxMC0wMS0yNSAwOToyOToyOV0K --001485f453423a15ad047e28b4a4 Content-Type: application/octet-stream; name="dmesg.boot" Content-Disposition: attachment; filename="dmesg.boot" Content-Transfer-Encoding: base64 X-Attachment-Id: f_g4ydzw2l2 YXRhMjogW01QU0FGRV0KYXRhMjogW0lUSFJFQURdCmF0YTM6IDxBVEEgY2hhbm5lbCA0PiBvbiBh dGFwY2kwCmF0YTM6IEFIQ0kgcmVzZXQuLi4KYXRhMzogaGFyZHdhcmUgcmVzZXQgLi4uCmF0YTM6 IFNBVEEgY29ubmVjdCB0aW1lPTEwbXMgc3RhdHVzPTAwMDAwMTEzCmF0YTM6IHJlYWR5IHdhaXQg dGltZT0wbXMKYXRhMzogc29mdHdhcmUgcmVzZXQgcG9ydCAxNS4uLgphdGEzOiByZWFkeSB3YWl0 IHRpbWU9MG1zCmF0YTM6IFNJR05BVFVSRTogZWIxNDAxMDEKYXRhMzogQUhDSSByZXNldCBkb25l OiBkZXZpY2VzPTAwMDEwMDAwCmF0YTM6IFtNUFNBRkVdCmF0YTM6IFtJVEhSRUFEXQphdGE0OiA8 QVRBIGNoYW5uZWwgNT4gb24gYXRhcGNpMAphdGE0OiBBSENJIHJlc2V0Li4uCmF0YTQ6IGhhcmR3 YXJlIHJlc2V0IC4uLgphdGE0OiBTQVRBIGNvbm5lY3QgdGltZW91dCBzdGF0dXM9MDAwMDAwMDAK YXRhNDogQUhDSSByZXNldCBkb25lOiBwaHkgcmVzZXQgZm91bmQgbm8gZGV2aWNlCmF0YTQ6IFtN UFNBRkVdCmF0YTQ6IFtJVEhSRUFEXQppY2hzbWIwOiA8SW50ZWwgODI4MDFJIChJQ0g5KSBTTUJ1 cyBjb250cm9sbGVyPiBwb3J0IDB4NTAwMC0weDUwMWYgbWVtIDB4ZDg1MDUwMDAtMHhkODUwNTBm ZiBpcnEgMTggYXQgZGV2aWNlIDMxLjMgb24gcGNpMAppY2hzbWIwOiBSZXNlcnZlZCAweDIwIGJ5 dGVzIGZvciByaWQgMHgyMCB0eXBlIDQgYXQgMHg1MDAwCmljaHNtYjA6IFtNUFNBRkVdCmljaHNt YjA6IFtJVEhSRUFEXQpzbWJ1czA6IDxTeXN0ZW0gTWFuYWdlbWVudCBCdXM+IG9uIGljaHNtYjAK YWNwaV90ejA6IDxUaGVybWFsIFpvbmU+IG9uIGFjcGkwCmF0cnRjMDogPEFUIHJlYWx0aW1lIGNs b2NrPiBwb3J0IDB4NzAtMHg3NyBvbiBhY3BpMAphdHJ0YzA6IFdhcm5pbmc6IENvdWxkbid0IG1h cCBJL08uCmF0cnRjMDogcmVnaXN0ZXJlZCBhcyBhIHRpbWUtb2YtZGF5IGNsb2NrIChyZXNvbHV0 aW9uIDEwMDAwMDB1cykKYXRrYmRjMDogPEtleWJvYXJkIGNvbnRyb2xsZXIgKGk4MDQyKT4gcG9y dCAweDYwLDB4NjQgaXJxIDEgb24gYWNwaTAKYXRrYmQwOiA8QVQgS2V5Ym9hcmQ+IGlycSAxIG9u IGF0a2JkYzAKYXRrYmQ6IHRoZSBjdXJyZW50IGtiZCBjb250cm9sbGVyIGNvbW1hbmQgYnl0ZSAw MDY3CmF0a2JkOiBrZXlib2FyZCBJRCAweDQxYWIgKDIpCmtiZDAgYXQgYXRrYmQwCmtiZDA6IGF0 a2JkMCwgQVQgMTAxLzEwMiAoMiksIGNvbmZpZzoweDAsIGZsYWdzOjB4M2QwMDAwCmlvYXBpYzA6 IHJvdXRpbmcgaW50cGluIDEgKElTQSBJUlEgMSkgdG8gbGFwaWMgMCB2ZWN0b3IgNTcKYXRrYmQw OiBbR0lBTlQtTE9DS0VEXQphdGtiZDA6IFtJVEhSRUFEXQpwc20wOiB1bmFibGUgdG8gYWxsb2Nh dGUgSVJRCnBzbWNwbnAwOiA8UFMvMiBtb3VzZSBwb3J0PiBpcnEgMTIgb24gYWNwaTAKcHNtMDog Y3VycmVudCBjb21tYW5kIGJ5dGU6MDA2Nwpwc20wOiA8UFMvMiBNb3VzZT4gaXJxIDEyIG9uIGF0 a2JkYzAKaW9hcGljMDogcm91dGluZyBpbnRwaW4gMTIgKElTQSBJUlEgMTIpIHRvIGxhcGljIDAg dmVjdG9yIDU4CnBzbTA6IFtHSUFOVC1MT0NLRURdCnBzbTA6IFtJVEhSRUFEXQpwc20wOiBtb2Rl bCBHZW5lcmljIFBTLzIgbW91c2UsIGRldmljZSBJRCAwLTAwLCAyIGJ1dHRvbnMKcHNtMDogY29u ZmlnOjAwMDAwMDAwLCBmbGFnczowMDAwMDAwOCwgcGFja2V0IHNpemU6Mwpwc20wOiBzeW5jbWFz azpjMCwgc3luY2JpdHM6MDAKY3B1MDogPEFDUEkgQ1BVPiBvbiBhY3BpMApBQ1BJOiBTU0RUIDB4 YjllNmVjOTggMDAyMjMgKHYxICBQbVJlZiAgQ3B1MElzdCAwMDAwMzAwMCBJTlRMIDIwMDUxMTE3 KQpBQ1BJOiBTU0RUIDB4YjllNmM2MTggMDA1QjMgKHYxICBQbVJlZiAgQ3B1MENzdCAwMDAwMzAw MSBJTlRMIDIwMDUxMTE3KQplc3QwOiA8RW5oYW5jZWQgU3BlZWRTdGVwIEZyZXF1ZW5jeSBDb250 cm9sPiBvbiBjcHUwCmVzdDA6IEludmFsaWQgaWQxNiAoc2V0LCBjdXIpID0gKDIwNzMsIDE4OTc5 KQplc3QwOiBDYW4ndCBjaGVjayBmcmVxIDE2MDAsIGl0IG1heSBiZSBpbnZhbGlkCmVzdDA6IElu dmFsaWQgaWQxNiAoc2V0LCBjdXIpID0gKDE1NTMsIDE4OTc5KQplc3QwOiBDYW4ndCBjaGVjayBm cmVxIDEyMDAsIGl0IG1heSBiZSBpbnZhbGlkCnA0dGNjMDogPENQVSBGcmVxdWVuY3kgVGhlcm1h bCBDb250cm9sPiBvbiBjcHUwCmNwdTE6IDxBQ1BJIENQVT4gb24gYWNwaTAKQUNQSTogU1NEVCAw eGI5ZTZkZTE4IDAwMUNGICh2MSAgUG1SZWYgICAgQXBJc3QgMDAwMDMwMDAgSU5UTCAyMDA1MTEx NykKQUNQSTogU1NEVCAweGI5ZTZlZjE4IDAwMDhEICh2MSAgUG1SZWYgICAgQXBDc3QgMDAwMDMw MDAgSU5UTCAyMDA1MTExNykKZXN0MTogPEVuaGFuY2VkIFNwZWVkU3RlcCBGcmVxdWVuY3kgQ29u dHJvbD4gb24gY3B1MQplc3QxOiBJbnZhbGlkIGlkMTYgKHNldCwgY3VyKSA9ICgyMDczLCAxODk3 OSkKZXN0MTogQ2FuJ3QgY2hlY2sgZnJlcSAxNjAwLCBpdCBtYXkgYmUgaW52YWxpZAplc3QxOiBJ bnZhbGlkIGlkMTYgKHNldCwgY3VyKSA9ICgxNTUzLCAxODk3OSkKZXN0MTogQ2FuJ3QgY2hlY2sg ZnJlcSAxMjAwLCBpdCBtYXkgYmUgaW52YWxpZApwNHRjYzE6IDxDUFUgRnJlcXVlbmN5IFRoZXJt YWwgQ29udHJvbD4gb24gY3B1MQppc2FiMDogZm91bmQgSUNIOSBvciBlcXVpdmFsZW50IGNoaXBz ZXQ6IEludGVsIElDSDlNIHdhdGNoZG9nIHRpbWVyCmlzYV9wcm9iZV9jaGlsZHJlbjogZGlzYWJs aW5nIFBuUCBkZXZpY2VzCmljaHdkMDogPEludGVsIElDSDlNIHdhdGNoZG9nIHRpbWVyPiBvbiBp c2EwCmlzYWIwOiBmb3VuZCBJQ0g5IG9yIGVxdWl2YWxlbnQgY2hpcHNldDogSW50ZWwgSUNIOU0g d2F0Y2hkb2cgdGltZXIKaWNod2QwOiBJbnRlbCBJQ0g5TSB3YXRjaGRvZyB0aW1lciAoSUNIOSBv ciBlcXVpdmFsZW50KQppY2h3ZDA6IHRpbWVyIGRpc2FibGVkCmF0a2JkYzogYXRrYmRjMCBhbHJl YWR5IGV4aXN0czsgc2tpcHBpbmcgaXQKYXRydGM6IGF0cnRjMCBhbHJlYWR5IGV4aXN0czsgc2tp cHBpbmcgaXQKc2M6IHNjMCBhbHJlYWR5IGV4aXN0czsgc2tpcHBpbmcgaXQKaXNhX3Byb2JlX2No aWxkcmVuOiBwcm9iaW5nIG5vbi1QblAgZGV2aWNlcwpvcm0wOiA8SVNBIE9wdGlvbiBST00+IGF0 IGlvbWVtIDB4YzAwMDAtMHhjZjdmZiBvbiBpc2EwCnNjMDogPFN5c3RlbSBjb25zb2xlPiBhdCBm bGFncyAweDEwMCBvbiBpc2EwCnNjMDogVkdBIDwxNiB2aXJ0dWFsIGNvbnNvbGVzLCBmbGFncz0w eDMwMD4Kc2MwOiBmYjAsIGtiZDEsIHRlcm1pbmFsIGVtdWxhdG9yOiBzY3Rla2VuICh0ZWtlbiB0 ZXJtaW5hbCkKdmdhMDogPEdlbmVyaWMgSVNBIFZHQT4gYXQgcG9ydCAweDNjMC0weDNkZiBpb21l bSAweGEwMDAwLTB4YmZmZmYgb24gaXNhMApmZGMwIGZhaWxlZCB0byBwcm9iZSBhdCBwb3J0IDB4 M2YwIGlycSA2IGRycSAyIG9uIGlzYTAKcHBjMCBmYWlsZWQgdG8gcHJvYmUgYXQgaXJxIDcgb24g aXNhMAp1YXJ0MCBmYWlsZWQgdG8gcHJvYmUgYXQgcG9ydCAweDNmOCBpcnEgNCBvbiBpc2EwCnVh cnQxIGZhaWxlZCB0byBwcm9iZSBhdCBwb3J0IDB4MmY4IGlycSAzIG9uIGlzYTAKaXNhX3Byb2Jl X2NoaWxkcmVuOiBwcm9iaW5nIFBuUCBkZXZpY2VzCkRldmljZSBjb25maWd1cmF0aW9uIGZpbmlz aGVkLgpSZWR1Y2luZyBrZXJuLm1heHZub2RlcyAyNTE5MzkgLT4gMTAwMDAwCnByb2NmcyByZWdp c3RlcmVkCmxhcGljOiBEaXZpc29yIDIsIEZyZXF1ZW5jeSA5OTc1MDkyMSBoegpUaW1lY291bnRl ciAiVFNDIiBmcmVxdWVuY3kgMjA5NDc2OTMwOSBIeiBxdWFsaXR5IC0xMDAKVGltZWNvdW50ZXJz IHRpY2sgZXZlcnkgMTAuMDAwIG1zZWMKbG8wOiBicGYgYXR0YWNoZWQKYXRhMjogSWRlbnRpZnlp bmcgZGV2aWNlczogMDAwMDAwMDEKYXRhMjogTmV3IGRldmljZXM6IDAwMDAwMDAxCnVzYnVzMDog MTJNYnBzIEZ1bGwgU3BlZWQgVVNCIHYxLjAKdXNidXMxOiAxMk1icHMgRnVsbCBTcGVlZCBVU0Ig djEuMAp1c2J1czI6IDQ4ME1icHMgSGlnaCBTcGVlZCBVU0IgdjIuMAp1c2J1czM6IDEyTWJwcyBG dWxsIFNwZWVkIFVTQiB2MS4wCnVzYnVzNDogMTJNYnBzIEZ1bGwgU3BlZWQgVVNCIHYxLjAKdXNi dXM1OiAxMk1icHMgRnVsbCBTcGVlZCBVU0IgdjEuMAp1c2J1czY6IDQ4ME1icHMgSGlnaCBTcGVl ZCBVU0IgdjIuMAphdGEyLW1hc3RlcjogcGlvPVBJTzQgd2RtYT1XRE1BMiB1ZG1hPVVETUExMDAg Y2FibGU9NDAgd2lyZQpiYXR0ZXJ5MDogYmF0dGVyeSBpbml0aWFsaXphdGlvbiBzdGFydGFkNDog c2V0dGluZyBVRE1BMTAwCgphY3BpX2FjYWQwOiBhY2xpbmUgaW5pdGlhbGl6YXRpb24gc3RhcnQK YWQ0OiA0NzY5NDBNQiA8U2VhZ2F0ZSBTVDk1MDAzMjVBUyAwMDAzSFBNMT4gYXQgYXRhMi1tYXN0 ZXIgVURNQTEwMCBTQVRBIDNHYi9zCmFkNDogOTc2NzczMTY4IHNlY3RvcnMgWzk2OTAyMUMvMTZI LzYzU10gMTYgc2VjdG9ycy9pbnRlcnJ1cHQgMSBkZXB0aCBxdWV1ZQphY3BpX3R6MDogX0FDMDog dGVtcGVyYXR1cmUgNjYuMCA+PSBzZXRwb2ludCA2Ni4wCkdFT006IG5ldyBkaXNrIGFkNAphY3Bp X3R6MDogc3dpdGNoZWQgZnJvbSBOT05FIHRvIF9BQzA6IDY2LjBDCnVnZW4wLjE6IDxJbnRlbD4g YXQgdXNidXMwCnVodWIwOiA8SW50ZWwgVUhDSSByb290IEhVQiwgY2xhc3MgOS8wLCByZXYgMS4w MC8xLjAwLCBhZGRyIDE+IG9uIHVzYnVzMAp1Z2VuMS4xOiA8SW50ZWw+IGF0IHVzYnVzMQp1aHVi MTogPEludGVsIFVIQ0kgcm9vdCBIVUIsIGNsYXNzIDkvMCwgcmV2IDEuMDAvMS4wMCwgYWRkciAx PiBvbiB1c2J1czEKdWdlbjIuMTogPEludGVsPiBhdCB1c2J1czIKdWh1YjI6IDxJbnRlbCBFSENJ IHJvb3QgSFVCLCBjbGFzcyA5LzAsIHJldiAyLjAwLzEuMDAsIGFkZHIgMT4gb24gdXNidXMyCnVn ZW4zLjE6IDxJbnRlbD4gYXQgdXNidXMzCnVodWIzOiA8SW50ZWwgVUhDSSByb290IEhVQiwgY2xh c3MgOS8wLCByZXYgMS4wMC8xLjAwLCBhZGRyIDE+IG9uIHVzYnVzMwp1Z2VuNC4xOiA8SW50ZWw+ IGF0IHVzYnVzNAp1aHViNDogPEludGVsIFVIQ0kgcm9vdCBIVUIsIGNsYXNzIDkvMCwgcmV2IDEu MDAvMS4wMCwgYWRkciAxPiBvbiB1c2J1czQKdWdlbjUuMTogPEludGVsPiBhdCB1c2J1czUKdWh1 YjU6IDxJbnRlbCBVSENJIHJvb3QgSFVCLCBjbGFzcyA5LzAsIHJldiAxLjAwLzEuMDAsIGFkZHIg MT4gb24gdXNidXM1CnVnZW42LjE6IDxJbnRlbD4gYXQgdXNidXM2CnVodWI2OiA8SW50ZWwgRUhD SSByb290IEhVQiwgY2xhc3MgOS8wLCByZXYgMi4wMC8xLjAwLCBhZGRyIDE+IG9uIHVzYnVzNgpz eXN0ZW0gcG93ZXIgcHJvZmlsZSBjaGFuZ2VkIHRvICdlY29ub215JwphY3BpX2FjYWQwOiBPZmYg TGluZQphY3BpX2FjYWQwOiBhY2xpbmUgaW5pdGlhbGl6YXRpb24gZG9uZSwgdHJpZWQgMSB0aW1l cwphZDQ6IEludGVsIGNoZWNrMSBmYWlsZWQKYWQ0OiBBZGFwdGVjIGNoZWNrMSBmYWlsZWQKYWQ0 OiBMU0kgKHYzKSBjaGVjazEgZmFpbGVkCmFkNDogTFNJICh2MikgY2hlY2sxIGZhaWxlZAphZDQ6 IEZyZWVCU0QgY2hlY2sxIGZhaWxlZAphdGEzOiBJZGVudGlmeWluZyBkZXZpY2VzOiAwMDAxMDAw MAphdGEzOiBOZXcgZGV2aWNlczogMDAwMTAwMDAKYXRhMy1tYXN0ZXI6IHBpbz1QSU80IHdkbWE9 V0RNQTIgdWRtYT1VRE1BMTAwIGNhYmxlPTQwIHdpcmUKYWNkMDogc2V0dGluZyBVRE1BMTAwCmF0 YTM6IGRldmljZV9yZXNldCB0aW1lb3V0PTk4MHVzCmFjZDA6IDxITC1EVC1TVCBEVkRSQU0gR1Qy MEwvREMwMz4gRFZEUiBkcml2ZSBhdCBhdGEzIGFzIG1hc3RlcgphY2QwOiByZWFkIDQxMzRLQi9z ICg0MTM0S0Ivcykgd3JpdGUgNDEzNEtCL3MgKDQxMzRLQi9zKSwgMTAyNEtCIGJ1ZmZlciwgVURN QTEwMCBTQVRBIDEuNUdiL3MKYWNkMDogUmVhZHM6IENEUiwgQ0RSVywgQ0REQSBzdHJlYW0sIERW RFJPTSwgRFZEUiwgRFZEUkFNLCBwYWNrZXQKYWNkMDogV3JpdGVzOiBDRFIsIENEUlcsIERWRFIs IERWRFJBTSwgdGVzdCB3cml0ZSwgYnVybnByb29mCmFjZDA6IEF1ZGlvOiBwbGF5LCAyNTYgdm9s dW1lIGxldmVscwphY2QwOiBNZWNoYW5pc206IGVqZWN0YWJsZSB0cmF5LCB1bmxvY2tlZAphY2Qw OiBNZWRpdW06IG5vL2JsYW5rIGRpc2MKYXRhNDogSWRlbnRpZnlpbmcgZGV2aWNlczogMDAwMDAw MDAKYXRhNDogTmV3IGRldmljZXM6IDAwMDAwMDAwCmJhdHRlcnkwOiBiYXR0ZXJ5IGluaXRpYWxp emF0aW9uIGRvbmUsIHRyaWVkIDEgdGltZXMKdWh1YjA6IDIgcG9ydHMgd2l0aCAyIHJlbW92YWJs ZSwgc2VsZiBwb3dlcmVkCnVodWIxOiAyIHBvcnRzIHdpdGggMiByZW1vdmFibGUsIHNlbGYgcG93 ZXJlZAp1aHViMzogMiBwb3J0cyB3aXRoIDIgcmVtb3ZhYmxlLCBzZWxmIHBvd2VyZWQKdWh1YjQ6 IDIgcG9ydHMgd2l0aCAyIHJlbW92YWJsZSwgc2VsZiBwb3dlcmVkCnVodWI1OiAyIHBvcnRzIHdp dGggMiByZW1vdmFibGUsIHNlbGYgcG93ZXJlZAp1aHViMjogNCBwb3J0cyB3aXRoIDQgcmVtb3Zh YmxlLCBzZWxmIHBvd2VyZWQKYWNkMDogRkFJTFVSRSAtIElOUVVJUlkgSUxMRUdBTCBSRVFVRVNU IGFzYz0weDI0IGFzY3E9MHgwMCBza3M9MHg0MCAweDAwIDB4MDEKKHByb2JlMDphdGExOjA6MDow KTogZXJyb3IgMjIKKHByb2JlMDphdGExOjA6MDowKTogVW5yZXRyeWFibGUgRXJyb3IKKHByb2Jl MDphdGExOjA6MDowKTogRG93biByZXZpbmcgUHJvdG9jb2wgVmVyc2lvbiBmcm9tIDIgdG8gMD8K KHByb2JlMDphdGExOjA6MDowKTogVEVTVCBVTklUIFJFQURZLiBDREI6IDAgMCAwIDAgMCAwIAoo cHJvYmUwOmF0YTE6MDowOjApOiBDQU0gU3RhdHVzOiBTQ1NJIFN0YXR1cyBFcnJvcgoocHJvYmUw OmF0YTE6MDowOjApOiBTQ1NJIFN0YXR1czogQ2hlY2sgQ29uZGl0aW9uCihwcm9iZTA6YXRhMTow OjA6MCk6IE5PVCBSRUFEWSBhc2M6M2EsMQoocHJvYmUwOmF0YTE6MDowOjApOiBNZWRpdW0gbm90 IHByZXNlbnQgLSB0cmF5IGNsb3NlZAoocHJvYmUwOmF0YTE6MDowOjApOiAocHJvYmUwOmF0YTE6 MDowOjApOiBURVNUIFVOSVQgUkVBRFkuIENEQjogMCAwIDAgMCAwIDAgCihwcm9iZTA6YXRhMTow OjA6MCk6IE5PVCBSRUFEWSBhc2M6M2EsMQoocHJvYmUwOmF0YTE6MDowOjApOiBNZWRpdW0gbm90 IHByZXNlbnQgLSB0cmF5IGNsb3NlZApVbnJldHJ5YWJsZSBlcnJvcgoocHJvYmUwOmF0YTE6MDow OjApOiBlcnJvciA2Cihwcm9iZTA6YXRhMTowOjA6MCk6IFVucmV0cnlhYmxlIEVycm9yCihwcm9i ZTA6YXRhMTowOjA6MCk6IGVycm9yIDYKKHByb2JlMDphdGExOjA6MDowKTogVW5yZXRyeWFibGUg RXJyb3IKYWNkMDogRkFJTFVSRSAtIElOUVVJUlkgSUxMRUdBTCBSRVFVRVNUIGFzYz0weDI0IGFz Y3E9MHgwMCBza3M9MHg0MCAweDAwIDB4MDEKKHByb2JlMDphdGExOjA6MDowKTogZXJyb3IgMjIK KHByb2JlMDphdGExOjA6MDowKTogVW5yZXRyeWFibGUgRXJyb3IKQVRBIFBzZXVkb1JBSUQgbG9h ZGVkClNNUDogQVAgQ1BVICMxIExhdW5jaGVkIQpjcHUxIEFQOgogICAgIElEOiAweDAxMDAwMDAw ICAgVkVSOiAweDAwMDUwMDE0IExEUjogMHgwMDAwMDAwMCBERlI6IDB4ZmZmZmZmZmYKICBsaW50 MDogMHgwMDAxMDcwMCBsaW50MTogMHgwMDAwMDQwMCBUUFI6IDB4MDAwMDAwMDAgU1ZSOiAweDAw MDAwMWZmCiAgdGltZXI6IDB4MDAwMjAwZWYgdGhlcm06IDB4MDAwMTAwMDAgZXJyOiAweDAwMDEw MDAwIHBjbTogMHgwMDAxMDQwMAppb2FwaWMwOiByb3V0aW5nIGludHBpbiA5IChJU0EgSVJRIDkp IHRvIGxhcGljIDEgdmVjdG9yIDQ4CmlvYXBpYzA6IHJvdXRpbmcgaW50cGluIDE2IChQQ0kgSVJR IDE2KSB0byBsYXBpYyAxIHZlY3RvciA0OQppb2FwaWMwOiByb3V0aW5nIGludHBpbiAxOCAoUENJ IElSUSAxOCkgdG8gbGFwaWMgMSB2ZWN0b3IgNTAKaW9hcGljMDogcm91dGluZyBpbnRwaW4gMjEg KFBDSSBJUlEgMjEpIHRvIGxhcGljIDEgdmVjdG9yIDUxCm1zaTogQXNzaWduaW5nIE1TSSBJUlEg MjU3IHRvIGxvY2FsIEFQSUMgMSB2ZWN0b3IgNTIKUm9vdCBtb3VudCB3YWl0aW5nIGZvcjogdXNi dXM2CnVodWI2OiA2IHBvcnRzIHdpdGggNiByZW1vdmFibGUsIHNlbGYgcG93ZXJlZApSb290IG1v dW50IHdhaXRpbmcgZm9yOiB1c2J1czYKdWdlbjYuMjogPFNhbkRpc2s+IGF0IHVzYnVzNgp1bWFz czA6IDxTYW5EaXNrIFNhbkRpc2sgQ3J1emVyLCBjbGFzcyAwLzAsIHJldiAyLjAwLzIuMDAsIGFk ZHIgMj4gb24gdXNidXM2CnVtYXNzMDogIFNDU0kgb3ZlciBCdWxrLU9ubHk7IHF1aXJrcyA9IDB4 MDAwMApSb290IG1vdW50IHdhaXRpbmcgZm9yOiB1c2J1czYKdW1hc3MwOjI6MDotMTogQXR0YWNo ZWQgdG8gc2NidXMyCihwcm9iZTA6dW1hc3Mtc2ltMDowOjA6MCk6IERvd24gcmV2aW5nIFByb3Rv Y29sIFZlcnNpb24gZnJvbSAyIHRvIDA/CkdFT006IG5ldyBkaXNrIGRhMApkYTAgYXQgdW1hc3Mt c2ltMCBidXMgMCBzY2J1czIgdGFyZ2V0IDAgbHVuIDAKZGEwOiA8U2FuRGlzayBTYW5EaXNrIENy dXplciA4LjAyPiBSZW1vdmFibGUgRGlyZWN0IEFjY2VzcyBTQ1NJLTAgZGV2aWNlIApkYTA6IFNl cmlhbCBOdW1iZXIgMzU1MDMzMEExNUQxRTlGNQpkYTA6IDQwLjAwME1CL3MgdHJhbnNmZXJzCmRh MDogNzY5MU1CICgxNTc1MzIxNSA1MTIgYnl0ZSBzZWN0b3JzOiAyNTVIIDYzUy9UIDk4MEMpCkdF T006IGRhMDogcGFydGl0aW9uIDEgZG9lcyBub3Qgc3RhcnQgb24gYSB0cmFjayBib3VuZGFyeS4K R0VPTTogZGEwOiBwYXJ0aXRpb24gMSBkb2VzIG5vdCBlbmQgb24gYSB0cmFjayBib3VuZGFyeS4K Um9vdCBtb3VudCB3YWl0aW5nIGZvcjogdXNidXM2CnVnZW42LjM6IDxHZW5lcmljPiBhdCB1c2J1 czYKdW1hc3MxOiA8QnVsay1JbiwgQnVsay1PdXQsIEludGVyZmFjZT4gb24gdXNidXM2CnVtYXNz MTogIFNDU0kgb3ZlciBCdWxrLU9ubHk7IHF1aXJrcyA9IDB4MDAwMApSb290IG1vdW50IHdhaXRp bmcgZm9yOiB1c2J1czYKdWdlbjQuMjogPExvZ2l0ZWNoPiBhdCB1c2J1czQKdW1zMDogPExvZ2l0 ZWNoIFVTQiBSZWNlaXZlciwgY2xhc3MgMC8wLCByZXYgMS4xMC80Ni4wMCwgYWRkciAyPiBvbiB1 c2J1czQKdW1zMDogOCBidXR0b25zIGFuZCBbWFlaXSBjb29yZGluYXRlcyBJRD0wCnVoaWQwOiA8 TG9naXRlY2ggVVNCIFJlY2VpdmVyLCBjbGFzcyAwLzAsIHJldiAxLjEwLzQ2LjAwLCBhZGRyIDI+ IG9uIHVzYnVzNAp1bWFzczE6MzoxOi0xOiBBdHRhY2hlZCB0byBzY2J1czMKKHByb2JlMDp1bWFz cy1zaW0xOjE6MDowKTogRG93biByZXZpbmcgUHJvdG9jb2wgVmVyc2lvbiBmcm9tIDIgdG8gMD8K KHByb2JlMDp1bWFzcy1zaW0xOjE6MDowKTogVEVTVCBVTklUIFJFQURZLiBDREI6IDAgMCAwIDAg MCAwIAoocHJvYmUwOnVtYXNzLXNpbTE6MTowOjApOiBDQU0gU3RhdHVzOiBTQ1NJIFN0YXR1cyBF cnJvcgoocHJvYmUwOnVtYXNzLXNpbTE6MTowOjApOiBTQ1NJIFN0YXR1czogQ2hlY2sgQ29uZGl0 aW9uCihwcm9iZTA6dW1hc3Mtc2ltMToxOjA6MCk6IE5PVCBSRUFEWSBhc2M6M2EsMAoocHJvYmUw OnVtYXNzLXNpbTE6MTowOjApOiBNZWRpdW0gbm90IHByZXNlbnQKKHByb2JlMDp1bWFzcy1zaW0x OjE6MDowKTogKHByb2JlMDp1bWFzcy1zaW0xOjE6MDowKTogVEVTVCBVTklUIFJFQURZLiBDREI6 IDAgMCAwIDAgMCAwIAoocHJvYmUwOnVtYXNzLXNpbTE6MTowOjApOiBOT1QgUkVBRFkgYXNjOjNh LDAKKHByb2JlMDp1bWFzcy1zaW0xOjE6MDowKTogTWVkaXVtIG5vdCBwcmVzZW50ClVucmV0cnlh YmxlIGVycm9yCihwcm9iZTA6dW1hc3Mtc2ltMToxOjA6MCk6IGVycm9yIDYKKHByb2JlMDp1bWFz cy1zaW0xOjE6MDowKTogVW5yZXRyeWFibGUgRXJyb3IKR0VPTTogbmV3IGRpc2sgZGExCihkYTE6 dW1hc3Mtc2ltMToxOjA6MCk6IGVycm9yIDYKKGRhMTp1bWFzcy1zaW0xOjE6MDowKTogVW5yZXRy eWFibGUgRXJyb3IKZGExIGF0IHVtYXNzLXNpbTEgYnVzIDEgc2NidXMzIHRhcmdldCAwIGx1biAw CmRhMTogPEdlbmVyaWMtIE11bHRpLUNhcmQgMS4wMD4gUmVtb3ZhYmxlIERpcmVjdCBBY2Nlc3Mg U0NTSS0wIGRldmljZSAKZGExOiBTZXJpYWwgTnVtYmVyIDIwMDcxMTE0MTczNDAwMDAwCmRhMTog NDAuMDAwTUIvcyB0cmFuc2ZlcnMKZGExOiBBdHRlbXB0IHRvIHF1ZXJ5IGRldmljZSBzaXplIGZh aWxlZDogTk9UIFJFQURZLCBNZWRpdW0gbm90IHByZXNlbnQKKGRhMTp1bWFzcy1zaW0xOjE6MDow KTogZXJyb3IgNgooZGExOnVtYXNzLXNpbTE6MTowOjApOiBVbnJldHJ5YWJsZSBFcnJvcgpPcGVu ZWQgZGlzayBkYTEgLT4gNgooZGExOnVtYXNzLXNpbTE6MTowOjApOiBlcnJvciA2CihkYTE6dW1h c3Mtc2ltMToxOjA6MCk6IFVucmV0cnlhYmxlIEVycm9yCk9wZW5lZCBkaXNrIGRhMSAtPiA2ClJv b3QgbW91bnQgd2FpdGluZyBmb3I6IHVzYnVzNgp1Z2VuNi40OiA8U3VZaW4+IGF0IHVzYnVzNgpU cnlpbmcgdG8gbW91bnQgcm9vdCBmcm9tIHVmczovZGV2L2FkNHM0YQpjdF90b190cyhbMjAxMC0w MS0yNyAxMToyNzo0N10pID0gMTI2NDU5MTY2Ny4wMDAwMDAwMDAKc3RhcnRfaW5pdDogdHJ5aW5n IC9zYmluL2luaXQKYWNwaV90ejA6IHN3aXRjaGVkIGZyb20gX0FDMCB0byBOT05FOiA2My4wQwp0 c190b19jdCgxMjY0NTkxNjk2LjA3NTY3NTY3NikgPSBbMjAxMC0wMS0yNyAxMToyODoxNl0KV2Fp dGluZyAobWF4IDYwIHNlY29uZHMpIGZvciBzeXN0ZW0gcHJvY2VzcyBgdm5scnUnIHRvIHN0b3Au Li5kb25lCldhaXRpbmcgKG1heCA2MCBzZWNvbmRzKSBmb3Igc3lzdGVtIHByb2Nlc3MgYGJ1ZmRh ZW1vbicgdG8gc3RvcC4uLmRvbmUKV2FpdGluZyAobWF4IDYwIHNlY29uZHMpIGZvciBzeXN0ZW0g cHJvY2VzcyBgc3luY2VyJyB0byBzdG9wLi4uClN5bmNpbmcgZGlza3MsIHZub2RlcyByZW1haW5p bmcuLi4xIDEgMCAwIGRvbmUKQWxsIGJ1ZmZlcnMgc3luY2VkLgpTd2FwIGRldmljZSBhZDRzNGIg cmVtb3ZlZC4KVXB0aW1lOiAxbTI4cwppc2FiMDogZm91bmQgSUNIOSBvciBlcXVpdmFsZW50IGNo aXBzZXQ6IEludGVsIElDSDlNIHdhdGNoZG9nIHRpbWVyCmFjcGlfYnV0dG9uMTogd2FrZV9wcmVw IGRpc2FibGVkIHdha2UgZm9yIFxcX1NCXy5TTFBCIChTNSkKcGNpYjU6IHdha2VfcHJlcCBkaXNh YmxlZCB3YWtlIGZvciBcXF9TQl8uUENJMC5QMzJfIChTNSkKdWhjaTI6IHdha2VfcHJlcCBkaXNh YmxlZCB3YWtlIGZvciBcXF9TQl8uUENJMC5VSEMxIChTNSkKdWhjaTM6IHdha2VfcHJlcCBkaXNh YmxlZCB3YWtlIGZvciBcXF9TQl8uUENJMC5VSEMyIChTNSkKdWhjaTQ6IHdha2VfcHJlcCBkaXNh YmxlZCB3YWtlIGZvciBcXF9TQl8uUENJMC5VSEMzIChTNSkKdW5rbm93bjogd2FrZV9wcmVwIGRp c2FibGVkIHdha2UgZm9yIFxcX1NCXy5QQ0kwLlVIQzYgKFM1KQplaGNpMTogd2FrZV9wcmVwIGRp c2FibGVkIHdha2UgZm9yIFxcX1NCXy5QQ0kwLkVIQzEgKFM1KQp1aGNpMDogd2FrZV9wcmVwIGRp c2FibGVkIHdha2UgZm9yIFxcX1NCXy5QQ0kwLlVIQzQgKFM1KQp1aGNpMTogd2FrZV9wcmVwIGRp c2FibGVkIHdha2UgZm9yIFxcX1NCXy5QQ0kwLlVIQzUgKFM1KQplaGNpMDogd2FrZV9wcmVwIGRp c2FibGVkIHdha2UgZm9yIFxcX1NCXy5QQ0kwLkVIQzIgKFM1KQp1bmtub3duOiB3YWtlX3ByZXAg ZGlzYWJsZWQgd2FrZSBmb3IgXFxfU0JfLlBDSTAuRVhQMS5QWFNYIChTNSkKdW5rbm93bjogd2Fr ZV9wcmVwIGRpc2FibGVkIHdha2UgZm9yIFxcX1NCXy5QQ0kwLkVYUDIuUFhTWCAoUzUpCnVua25v d246IHdha2VfcHJlcCBkaXNhYmxlZCB3YWtlIGZvciBcXF9TQl8uUENJMC5FWFAzLlBYU1ggKFM1 KQpyZTA6IHdha2VfcHJlcCBkaXNhYmxlZCB3YWtlIGZvciBcXF9TQl8uUENJMC5FWFA0LlBYU1gg KFM1KQp1bmtub3duOiB3YWtlX3ByZXAgZGlzYWJsZWQgd2FrZSBmb3IgXFxfU0JfLlBDSTAuRVhQ NS5QWFNYIChTNSkKdW5rbm93bjogd2FrZV9wcmVwIGRpc2FibGVkIHdha2UgZm9yIFxcX1NCXy5Q Q0kwLkVYUDYuUFhTWCAoUzUpClJlYm9vdGluZy4uLgpjcHVfcmVzZXQ6IFN0b3BwaW5nIG90aGVy IENQVXMKQ29weXJpZ2h0IChjKSAxOTkyLTIwMTAgVGhlIEZyZWVCU0QgUHJvamVjdC4KQ29weXJp Z2h0IChjKSAxOTc5LCAxOTgwLCAxOTgzLCAxOTg2LCAxOTg4LCAxOTg5LCAxOTkxLCAxOTkyLCAx OTkzLCAxOTk0CglUaGUgUmVnZW50cyBvZiB0aGUgVW5pdmVyc2l0eSBvZiBDYWxpZm9ybmlhLiBB bGwgcmlnaHRzIHJlc2VydmVkLgpGcmVlQlNEIGlzIGEgcmVnaXN0ZXJlZCB0cmFkZW1hcmsgb2Yg VGhlIEZyZWVCU0QgRm91bmRhdGlvbi4KRnJlZUJTRCA4LjAtU1RBQkxFICMwOiBXZWQgSmFuIDI3 IDA5OjI3OjM2IEJSVCAyMDEwCiAgICByb290QGR2My56YXZhbS5uZXQuYnI6L3Vzci9vYmovdXNy L3NyYy9zeXMvRFYzIGFtZDY0ClByZWxvYWRlZCBlbGYga2VybmVsICIvYm9vdC9rZXJuZWwva2Vy bmVsIiBhdCAweGZmZmZmZmZmODA4ZTQwMDAuClRpbWVjb3VudGVyICJpODI1NCIgZnJlcXVlbmN5 IDExOTMxODIgSHogcXVhbGl0eSAwCkNhbGlicmF0aW5nIFRTQyBjbG9jayAuLi4gVFNDIGNsb2Nr OiAyMDk0NzYxNjU1IEh6CkNQVTogSW50ZWwoUikgQ29yZShUTSkyIER1byBDUFUgICAgIFQ2NTAw ICBAIDIuMTBHSHogKDIwOTQuNzYtTUh6IEs4LWNsYXNzIENQVSkKICBPcmlnaW4gPSAiR2VudWlu ZUludGVsIiAgSWQgPSAweDEwNjdhICBTdGVwcGluZyA9IDEwCiAgRmVhdHVyZXM9MHhiZmViZmJm ZjxGUFUsVk1FLERFLFBTRSxUU0MsTVNSLFBBRSxNQ0UsQ1g4LEFQSUMsU0VQLE1UUlIsUEdFLE1D QSxDTU9WLFBBVCxQU0UzNixDTEZMVVNILERUUyxBQ1BJLE1NWCxGWFNSLFNTRSxTU0UyLFNTLEhU VCxUTSxQQkU+CiAgRmVhdHVyZXMyPTB4NDA4ZTM5ZDxTU0UzLERURVM2NCxNT04sRFNfQ1BMLEVT VCxUTTIsU1NTRTMsQ1gxNix4VFBSLFBEQ00sU1NFNC4xLFhTQVZFPgogIEFNRCBGZWF0dXJlcz0w eDIwMTAwODAwPFNZU0NBTEwsTlgsTE0+CiAgQU1EIEZlYXR1cmVzMj0weDE8TEFIRj4KICBUU0M6 IFAtc3RhdGUgaW52YXJpYW50CnJlYWwgbWVtb3J5ICA9IDQyOTQ5NjcyOTYgKDQwOTYgTUIpClBo eXNpY2FsIG1lbW9yeSBjaHVuayhzKToKMHgwMDAwMDAwMDAwMDAxMDAwIC0gMHgwMDAwMDAwMDAw MDQ4ZmZmLCAyOTQ5MTIgYnl0ZXMgKDcyIHBhZ2VzKQoweDAwMDAwMDAwMDAwNTkwMDAgLSAweDAw MDAwMDAwMDAwOTlmZmYsIDI2NjI0MCBieXRlcyAoNjUgcGFnZXMpCjB4MDAwMDAwMDAwMDkxMzAw MCAtIDB4MDAwMDAwMDBiMDdlYWZmZiwgMjk1MTU3NzYwMCBieXRlcyAoNzIwNjAwIHBhZ2VzKQow eDAwMDAwMDAwYjllYmYwMDAgLSAweDAwMDAwMDAwYjlmODJmZmYsIDgwMjgxNiBieXRlcyAoMTk2 IHBhZ2VzKQoweDAwMDAwMDAwYjlmYmYwMDAgLSAweDAwMDAwMDAwYjlmZGVmZmYsIDEzMTA3MiBi eXRlcyAoMzIgcGFnZXMpCjB4MDAwMDAwMDBiOWZmNjAwMCAtIDB4MDAwMDAwMDBiOWZmZGZmZiwg MzI3NjggYnl0ZXMgKDggcGFnZXMpCjB4MDAwMDAwMDBiOWZmZjAwMCAtIDB4MDAwMDAwMDBiOWZm ZmZmZiwgNDA5NiBieXRlcyAoMSBwYWdlcykKMHgwMDAwMDAwMTAwMDAwMDAwIC0gMHgwMDAwMDAw MTNmZmVmZmZmLCAxMDczNjc2Mjg4IGJ5dGVzICgyNjIxMjggcGFnZXMpCmF2YWlsIG1lbW9yeSA9 IDQwMDQzNDc5MDQgKDM4MTggTUIpCkFDUEkgQVBJQyBUYWJsZTogPEhQUU9FTSBTTElDLU1QQz4K SU5UUjogQWRkaW5nIGxvY2FsIEFQSUMgMSBhcyBhIHRhcmdldApGcmVlQlNEL1NNUDogTXVsdGlw cm9jZXNzb3IgU3lzdGVtIERldGVjdGVkOiAyIENQVXMKRnJlZUJTRC9TTVA6IDEgcGFja2FnZShz KSB4IDIgY29yZShzKQogY3B1MCAoQlNQKTogQVBJQyBJRDogIDAKIGNwdTEgKEFQKTogQVBJQyBJ RDogIDEKQVBJQzogQ1BVIDAgaGFzIEFDUEkgSUQgMQpBUElDOiBDUFUgMSBoYXMgQUNQSSBJRCAy ClVMRTogc2V0dXAgY3B1IDAKVUxFOiBzZXR1cCBjcHUgMQpBQ1BJOiBSU0RQIDB4ZmUwMjAgMDAw MjQgKHYyIEhQICAgICkKQUNQSTogWFNEVCAweGI5ZmZlMTIwIDAwMDc0ICh2MSBIUFFPRU0gU0xJ Qy1NUEMgMDAwMDAwMDEgICAgICAwMTAwMDAxMykKQUNQSTogRkFDUCAweGI5ZmYzMDAwIDAwMEY0 ICh2NCBIUCAgICAgUkhFVFQgICAgMDAwMDAwMDEgTVNGVCAwMTAwMDAxMykKQUNQSTogRFNEVCAw eGI5ZmU0MDAwIDBBNUI4ICh2MSBIUCAgICAgUkhFVFQgICAgMDAwMDAwMDEgTVNGVCAwMTAwMDAx MykKQUNQSTogRkFDUyAweGI5ZjhjMDAwIDAwMDQwCkFDUEk6IERNQVIgMHhiOWZmNTAwMCAwMDA5 OCAodjEgICAgICAgICAgICAgICBcXkEgMDAwMDAwMDEgICAgICAwMDAwMDAwMCkKQUNQSTogU1NE VCAweGI5ZmY0MDAwIDAwNjU1ICh2MSAgUG1SZWYgICAgQ3B1UG0gMDAwMDMwMDAgSU5UTCAyMDA1 MTExNykKQUNQSTogSFBFVCAweGI5ZmYyMDAwIDAwMDM4ICh2MSBIUFFPRU0gU0xJQy1NUEMgMDAw MDAwMDEgTVNGVCAwMTAwMDAxMykKQUNQSTogQVBJQyAweGI5ZmYxMDAwIDAwMDZDICh2MiBIUFFP RU0gU0xJQy1NUEMgMDAwMDAwMDEgTVNGVCAwMTAwMDAxMykKQUNQSTogTUNGRyAweGI5ZmYwMDAw IDAwMDNDICh2MSBIUFFPRU0gU0xJQy1NUEMgMDAwMDAwMDEgTVNGVCAwMTAwMDAxMykKQUNQSTog QVNGISAweGI5ZmVmMDAwIDAwMEE1ICh2MzIgSFBRT0VNIFNMSUMtTVBDIDAwMDAwMDAxIE1TRlQg MDEwMDAwMTMpCkFDUEk6IFNMSUMgMHhiOWZlMzAwMCAwMDE3NiAodjEgSFBRT0VNIFNMSUMtTVBD IDAwMDAwMDAxIExPSFIgMDAwRjQyNDApCkFDUEk6IEJPT1QgMHhiOWZlMjAwMCAwMDAyOCAodjEg SFBRT0VNIFNMSUMtTVBDIDAwMDAwMDAxIE1TRlQgMDEwMDAwMTMpCkFDUEk6IFNTRFQgMHhiOWZl MTAwMCAwMDI5NiAodjEgSU5URUwgIFNhdGFBaGNpIDAwMDAxMDAwIElOVEwgMjAwNTExMTcpCk1B RFQ6IEZvdW5kIElPIEFQSUMgSUQgNCwgSW50ZXJydXB0IDAgYXQgMHhmZWMwMDAwMAppb2FwaWMw OiBDaGFuZ2luZyBBUElDIElEIHRvIDQKaW9hcGljMDogUm91dGluZyBleHRlcm5hbCA4MjU5QSdz IC0+IGludHBpbiAwCk1BRFQ6IEludGVycnVwdCBvdmVycmlkZTogc291cmNlIDAsIGlycSAyCmlv YXBpYzA6IFJvdXRpbmcgSVJRIDAgLT4gaW50cGluIDIKTUFEVDogSW50ZXJydXB0IG92ZXJyaWRl OiBzb3VyY2UgOSwgaXJxIDkKaW9hcGljMDogaW50cGluIDkgdHJpZ2dlcjogbGV2ZWwKaW9hcGlj MCA8VmVyc2lvbiAyLjA+IGlycXMgMC0yMyBvbiBtb3RoZXJib2FyZApjcHUwIEJTUDoKICAgICBJ RDogMHgwMDAwMDAwMCAgIFZFUjogMHgwMDA1MDAxNCBMRFI6IDB4MDAwMDAwMDAgREZSOiAweGZm ZmZmZmZmCiAgbGludDA6IDB4MDAwMTA3MDAgbGludDE6IDB4MDAwMDA0MDAgVFBSOiAweDAwMDAw MDAwIFNWUjogMHgwMDAwMDFmZgogIHRpbWVyOiAweDAwMDEwMGVmIHRoZXJtOiAweDAwMDEwMDAw IGVycjogMHgwMDAxMDAwMCBwY206IDB4MDAwMTA0MDAKd2xhbjogPDgwMi4xMSBMaW5rIExheWVy PgprYmQ6IG5ldyBhcnJheSBzaXplIDQKa2JkMSBhdCBrYmRtdXgwCm1lbTogPG1lbW9yeT4KbmZz bG9jazogcHNldWRvLWRldmljZQpudWxsOiA8bnVsbCBkZXZpY2UsIHplcm8gZGV2aWNlPgpyYW5k b206IDxlbnRyb3B5IHNvdXJjZSwgU29mdHdhcmUsIFlhcnJvdz4KY3B1Y3RsOiBhY2Nlc3MgdG8g TVNSIHJlZ2lzdGVycy9jcHVpZCBpbmZvLgppY2h3ZCBtb2R1bGUgbG9hZGVkCmlvOiA8SS9PPgpz bWJpb3MwOiA8U3lzdGVtIE1hbmFnZW1lbnQgQklPUz4gYXQgaW9tZW0gMHhmZTEyMC0weGZlMTNl IG9uIG1vdGhlcmJvYXJkCnNtYmlvczA6IFZlcnNpb246IDIuNCwgQkNEIFJldmlzaW9uOiAyLjQK YWNwaTA6IDxIUFFPRU0gU0xJQy1NUEM+IG9uIG1vdGhlcmJvYXJkClBDSWU6IE1lbW9yeSBNYXBw ZWQgY29uZmlndXJhdGlvbiBiYXNlIEAgMHhmODAwMDAwMAppb2FwaWMwOiByb3V0aW5nIGludHBp biA5IChJU0EgSVJRIDkpIHRvIGxhcGljIDAgdmVjdG9yIDQ4CmFjcGkwOiBbTVBTQUZFXQphY3Bp MDogW0lUSFJFQURdCmFjcGkwOiBQb3dlciBCdXR0b24gKGZpeGVkKQphY3BpMDogd2FrZXVwIGNv ZGUgdmEgMHhmZmZmZmY4MDAwMDBmMDAwIHBhIDB4NDAwMApBY3BpT3NEZXJpdmVQY2lJZDogXFxf U0JfLlBDSTAuSEJVUyAtPiBidXMgMCBkZXYgMCBmdW5jIDAKQWNwaU9zRGVyaXZlUGNpSWQ6IFxc X1NCXy5QQ0kwLkxQQ18uUFJSMCAtPiBidXMgMCBkZXYgMzEgZnVuYyAwCkFjcGlPc0Rlcml2ZVBj aUlkOiBcXF9TQl8uUENJMC5MUENfLlBSUjEgLT4gYnVzIDAgZGV2IDMxIGZ1bmMgMApBQ1BJIHRp bWVyOiAxLzEgMS8xIDEvMSAxLzEgMS8xIDEvMSAxLzEgMS8xIDEvMSAxLzEgLT4gMTAKVGltZWNv dW50ZXIgIkFDUEktZmFzdCIgZnJlcXVlbmN5IDM1Nzk1NDUgSHogcXVhbGl0eSAxMDAwCmFjcGlf dGltZXIwOiA8MjQtYml0IHRpbWVyIGF0IDMuNTc5NTQ1TUh6PiBwb3J0IDB4NDA4LTB4NDBiIG9u IGFjcGkwCmFjcGlfZWMwOiA8RW1iZWRkZWQgQ29udHJvbGxlcjogR1BFIDB4MTc+IHBvcnQgMHg2 MiwweDY2IG9uIGFjcGkwCmFjcGlfZWMwOiBFY1JlYWQ6IGZhaWxlZCB3YWl0aW5nIHRvIGdldCBk YXRhCkFDUEkgRXhjZXB0aW9uOiBBRV9OT19IQVJEV0FSRV9SRVNQT05TRSwgUmV0dXJuZWQgYnkg SGFuZGxlciBmb3IgW0VtYmVkZGVkQ29udHJvbF0gMjAwOTA1MjEgZXZyZWdpb24tNTMxCkFDUEkg RXJyb3IgKHBzcGFyc2UtMDYzMyk6IE1ldGhvZCBwYXJzZS9leGVjdXRpb24gZmFpbGVkIFtcXF9T Ql8uUENJMC5MUENfLkVDMF8uT1NURV0gKE5vZGUgMHhmZmZmZmYwMDAxNWE1MjgwKSwgQUVfTk9f SEFSRFdBUkVfUkVTUE9OU0UKQUNQSSBFcnJvciAocHNwYXJzZS0wNjMzKTogTWV0aG9kIHBhcnNl L2V4ZWN1dGlvbiBmYWlsZWQgW1xcX1NCXy5QQ0kwLkxQQ18uRUMwXy5fUkVHXSAoTm9kZSAweGZm ZmZmZjAwMDE1YTUyYTApLCBBRV9OT19IQVJEV0FSRV9SRVNQT05TRQphY3BpX2VjMDogY2FuJ3Qg aW5zdGFsbCBhZGRyZXNzIHNwYWNlIGhhbmRsZXIgZm9yIFxcX1NCXy5QQ0kwLkxQQ18uRUMwXyAt IEFFX05PX0hBUkRXQVJFX1JFU1BPTlNFCmRldmljZV9hdHRhY2g6IGFjcGlfZWMwIGF0dGFjaCBy ZXR1cm5lZCA2CnBjaV9saW5rMDogICAgICAgIEluZGV4ICBJUlEgIFJ0ZCAgUmVmICBJUlFzCiAg SW5pdGlhbCBQcm9iZSAgICAgICAwICAgMTEgICBOICAgICAwICAzIDQgNSA3IDkgMTAgMTEgMTIK ICBWYWxpZGF0aW9uICAgICAgICAgIDAgICAxMSAgIE4gICAgIDAgIDMgNCA1IDcgOSAxMCAxMSAx MgogIEFmdGVyIERpc2FibGUgICAgICAgMCAgMjU1ICAgTiAgICAgMCAgMyA0IDUgNyA5IDEwIDEx IDEyCnBjaV9saW5rMTogICAgICAgIEluZGV4ICBJUlEgIFJ0ZCAgUmVmICBJUlFzCiAgSW5pdGlh bCBQcm9iZSAgICAgICAwICAgMTAgICBOICAgICAwICAzIDQgNSA3IDkgMTAgMTEgMTIKICBWYWxp ZGF0aW9uICAgICAgICAgIDAgICAxMCAgIE4gICAgIDAgIDMgNCA1IDcgOSAxMCAxMSAxMgogIEFm dGVyIERpc2FibGUgICAgICAgMCAgMjU1ICAgTiAgICAgMCAgMyA0IDUgNyA5IDEwIDExIDEyCnBj aV9saW5rMjogICAgICAgIEluZGV4ICBJUlEgIFJ0ZCAgUmVmICBJUlFzCiAgSW5pdGlhbCBQcm9i ZSAgICAgICAwICAgMTEgICBOICAgICAwICAzIDQgNSA3IDkgMTAgMTEgMTIKICBWYWxpZGF0aW9u ICAgICAgICAgIDAgICAxMSAgIE4gICAgIDAgIDMgNCA1IDcgOSAxMCAxMSAxMgogIEFmdGVyIERp c2FibGUgICAgICAgMCAgMjU1ICAgTiAgICAgMCAgMyA0IDUgNyA5IDEwIDExIDEyCnBjaV9saW5r MzogICAgICAgIEluZGV4ICBJUlEgIFJ0ZCAgUmVmICBJUlFzCiAgSW5pdGlhbCBQcm9iZSAgICAg ICAwICAgMTEgICBOICAgICAwICAzIDQgNSA3IDkgMTAgMTEgMTIKICBWYWxpZGF0aW9uICAgICAg ICAgIDAgICAxMSAgIE4gICAgIDAgIDMgNCA1IDcgOSAxMCAxMSAxMgogIEFmdGVyIERpc2FibGUg ICAgICAgMCAgMjU1ICAgTiAgICAgMCAgMyA0IDUgNyA5IDEwIDExIDEyCnBjaV9saW5rNDogICAg ICAgIEluZGV4ICBJUlEgIFJ0ZCAgUmVmICBJUlFzCiAgSW5pdGlhbCBQcm9iZSAgICAgICAwICAg MTEgICBOICAgICAwICAzIDQgNSA3IDkgMTAgMTEgMTIKICBWYWxpZGF0aW9uICAgICAgICAgIDAg ICAxMSAgIE4gICAgIDAgIDMgNCA1IDcgOSAxMCAxMSAxMgogIEFmdGVyIERpc2FibGUgICAgICAg MCAgMjU1ICAgTiAgICAgMCAgMyA0IDUgNyA5IDEwIDExIDEyCnBjaV9saW5rNTogICAgICAgIElu ZGV4ICBJUlEgIFJ0ZCAgUmVmICBJUlFzCiAgSW5pdGlhbCBQcm9iZSAgICAgICAwICAgMTEgICBO ICAgICAwICAzIDQgNSA3IDkgMTAgMTEgMTIKICBWYWxpZGF0aW9uICAgICAgICAgIDAgICAxMSAg IE4gICAgIDAgIDMgNCA1IDcgOSAxMCAxMSAxMgogIEFmdGVyIERpc2FibGUgICAgICAgMCAgMjU1 ICAgTiAgICAgMCAgMyA0IDUgNyA5IDEwIDExIDEyCnBjaV9saW5rNjogICAgICAgIEluZGV4ICBJ UlEgIFJ0ZCAgUmVmICBJUlFzCiAgSW5pdGlhbCBQcm9iZSAgICAgICAwICAgMTEgICBOICAgICAw ICAzIDQgNSA3IDkgMTAgMTEgMTIKICBWYWxpZGF0aW9uICAgICAgICAgIDAgICAxMSAgIE4gICAg IDAgIDMgNCA1IDcgOSAxMCAxMSAxMgogIEFmdGVyIERpc2FibGUgICAgICAgMCAgMjU1ICAgTiAg ICAgMCAgMyA0IDUgNyA5IDEwIDExIDEyCnBjaV9saW5rNzogICAgICAgIEluZGV4ICBJUlEgIFJ0 ZCAgUmVmICBJUlFzCiAgSW5pdGlhbCBQcm9iZSAgICAgICAwICAyNTUgICBOICAgICAwICAzIDQg NSA3IDkgMTAgMTEgMTIKICBWYWxpZGF0aW9uICAgICAgICAgIDAgIDI1NSAgIE4gICAgIDAgIDMg NCA1IDcgOSAxMCAxMSAxMgogIEFmdGVyIERpc2FibGUgICAgICAgMCAgMjU1ICAgTiAgICAgMCAg MyA0IDUgNyA5IDEwIDExIDEyCmFjcGlfaHBldDA6IDxIaWdoIFByZWNpc2lvbiBFdmVudCBUaW1l cj4gaW9tZW0gMHhmZWQwMDAwMC0weGZlZDAwM2ZmIG9uIGFjcGkwCmFjcGlfaHBldDA6IHZlbmQ6 IDB4ODA4NiByZXY6IDB4MSBudW06IDMgaHo6IDE0MzE4MTgwIG9wdHM6IGxlZ2FjeV9yb3V0ZSA2 NC1iaXQKVGltZWNvdW50ZXIgIkhQRVQiIGZyZXF1ZW5jeSAxNDMxODE4MCBIeiBxdWFsaXR5IDkw MAphY3BpX2J1dHRvbjA6IDxQb3dlciBCdXR0b24+IG9uIGFjcGkwCmFjcGlfbGlkMDogPENvbnRy b2wgTWV0aG9kIExpZCBTd2l0Y2g+IG9uIGFjcGkwCmFjcGlfYnV0dG9uMTogPFNsZWVwIEJ1dHRv bj4gb24gYWNwaTAKQUNQSSBFcnJvcjogTm8gaGFuZGxlciBmb3IgUmVnaW9uIFtFUkFNXSAoMHhm ZmZmZmYwMDAxNTk1OTgwKSBbRW1iZWRkZWRDb250cm9sXSAyMDA5MDUyMSBldnJlZ2lvbi00MzAK QUNQSSBFcnJvcjogUmVnaW9uIEVtYmVkZGVkQ29udHJvbCgzKSBoYXMgbm8gaGFuZGxlciAyMDA5 MDUyMSBleGZsZGlvLTM4MgpBQ1BJIEVycm9yIChwc3BhcnNlLTA2MzMpOiBNZXRob2QgcGFyc2Uv ZXhlY3V0aW9uIGZhaWxlZCBbXFxfU0JfLkJBVDAuX1NUQV0gKE5vZGUgMHhmZmZmZmYwMDAxNWEw MzIwKSwgQUVfTk9UX0VYSVNUCkFDUEkgRXJyb3IgKHV0ZXZhbC0wMzI5KTogTWV0aG9kIGV4ZWN1 dGlvbiBmYWlsZWQgW1xcX1NCXy5CQVQwLl9TVEFdIChOb2RlIDB4ZmZmZmZmMDAwMTVhMDMyMCks IEFFX05PVF9FWElTVApBQ1BJIEVycm9yOiBObyBoYW5kbGVyIGZvciBSZWdpb24gW0VSQU1dICgw eGZmZmZmZjAwMDE1OTU5ODApIFtFbWJlZGRlZENvbnRyb2xdIDIwMDkwNTIxIGV2cmVnaW9uLTQz MApBQ1BJIEVycm9yOiBSZWdpb24gRW1iZWRkZWRDb250cm9sKDMpIGhhcyBubyBoYW5kbGVyIDIw MDkwNTIxIGV4ZmxkaW8tMzgyCkFDUEkgRXJyb3IgKHBzcGFyc2UtMDYzMyk6IE1ldGhvZCBwYXJz ZS9leGVjdXRpb24gZmFpbGVkIFtcXF9TQl8uQkFUMC5fU1RBXSAoTm9kZSAweGZmZmZmZjAwMDE1 YTAzMjApLCBBRV9OT1RfRVhJU1QKQUNQSSBFcnJvciAodXRldmFsLTAzMjkpOiBNZXRob2QgZXhl Y3V0aW9uIGZhaWxlZCBbXFxfU0JfLkJBVDAuX1NUQV0gKE5vZGUgMHhmZmZmZmYwMDAxNWEwMzIw KSwgQUVfTk9UX0VYSVNUCkFDUEkgRXJyb3I6IE5vIGhhbmRsZXIgZm9yIFJlZ2lvbiBbRVJBTV0g KDB4ZmZmZmZmMDAwMTU5NTk4MCkgW0VtYmVkZGVkQ29udHJvbF0gMjAwOTA1MjEgZXZyZWdpb24t NDMwCkFDUEkgRXJyb3I6IFJlZ2lvbiBFbWJlZGRlZENvbnRyb2woMykgaGFzIG5vIGhhbmRsZXIg MjAwOTA1MjEgZXhmbGRpby0zODIKQUNQSSBFcnJvciAocHNwYXJzZS0wNjMzKTogTWV0aG9kIHBh cnNlL2V4ZWN1dGlvbiBmYWlsZWQgW1xcX1NCXy5CQVQwLl9TVEFdIChOb2RlIDB4ZmZmZmZmMDAw MTVhMDMyMCksIEFFX05PVF9FWElTVApBQ1BJIEVycm9yICh1dGV2YWwtMDMyOSk6IE1ldGhvZCBl eGVjdXRpb24gZmFpbGVkIFtcXF9TQl8uQkFUMC5fU1RBXSAoTm9kZSAweGZmZmZmZjAwMDE1YTAz MjApLCBBRV9OT1RfRVhJU1QKQUNQSSBFcnJvcjogTm8gaGFuZGxlciBmb3IgUmVnaW9uIFtFUkFN XSAoMHhmZmZmZmYwMDAxNTk1OTgwKSBbRW1iZWRkZWRDb250cm9sXSAyMDA5MDUyMSBldnJlZ2lv bi00MzAKQUNQSSBFcnJvcjogUmVnaW9uIEVtYmVkZGVkQ29udHJvbCgzKSBoYXMgbm8gaGFuZGxl ciAyMDA5MDUyMSBleGZsZGlvLTM4MgpBQ1BJIEVycm9yIChwc3BhcnNlLTA2MzMpOiBNZXRob2Qg cGFyc2UvZXhlY3V0aW9uIGZhaWxlZCBbXFxfU0JfLkJBVDAuX1NUQV0gKE5vZGUgMHhmZmZmZmYw MDAxNWEwMzIwKSwgQUVfTk9UX0VYSVNUCkFDUEkgRXJyb3IgKHV0ZXZhbC0wMzI5KTogTWV0aG9k IGV4ZWN1dGlvbiBmYWlsZWQgW1xcX1NCXy5CQVQwLl9TVEFdIChOb2RlIDB4ZmZmZmZmMDAwMTVh MDMyMCksIEFFX05PVF9FWElTVApBQ1BJIEVycm9yOiBObyBoYW5kbGVyIGZvciBSZWdpb24gW0VS QU1dICgweGZmZmZmZjAwMDE1OTU5ODApIFtFbWJlZGRlZENvbnRyb2xdIDIwMDkwNTIxIGV2cmVn aW9uLTQzMApBQ1BJIEVycm9yOiBSZWdpb24gRW1iZWRkZWRDb250cm9sKDMpIGhhcyBubyBoYW5k bGVyIDIwMDkwNTIxIGV4ZmxkaW8tMzgyCkFDUEkgRXJyb3IgKHBzcGFyc2UtMDYzMyk6IE1ldGhv ZCBwYXJzZS9leGVjdXRpb24gZmFpbGVkIFtcXF9TQl8uQkFUMC5fU1RBXSAoTm9kZSAweGZmZmZm ZjAwMDE1YTAzMjApLCBBRV9OT1RfRVhJU1QKQUNQSSBFcnJvciAodXRldmFsLTAzMjkpOiBNZXRo b2QgZXhlY3V0aW9uIGZhaWxlZCBbXFxfU0JfLkJBVDAuX1NUQV0gKE5vZGUgMHhmZmZmZmYwMDAx NWEwMzIwKSwgQUVfTk9UX0VYSVNUCkFDUEkgRXJyb3I6IE5vIGhhbmRsZXIgZm9yIFJlZ2lvbiBb RVJBTV0gKDB4ZmZmZmZmMDAwMTU5NTk4MCkgW0VtYmVkZGVkQ29udHJvbF0gMjAwOTA1MjEgZXZy ZWdpb24tNDMwCkFDUEkgRXJyb3I6IFJlZ2lvbiBFbWJlZGRlZENvbnRyb2woMykgaGFzIG5vIGhh bmRsZXIgMjAwOTA1MjEgZXhmbGRpby0zODIKQUNQSSBFcnJvciAocHNwYXJzZS0wNjMzKTogTWV0 aG9kIHBhcnNlL2V4ZWN1dGlvbiBmYWlsZWQgW1xcX1NCXy5CQVQwLl9TVEFdIChOb2RlIDB4ZmZm ZmZmMDAwMTVhMDMyMCksIEFFX05PVF9FWElTVApBQ1BJIEVycm9yICh1dGV2YWwtMDMyOSk6IE1l dGhvZCBleGVjdXRpb24gZmFpbGVkIFtcXF9TQl8uQkFUMC5fU1RBXSAoTm9kZSAweGZmZmZmZjAw MDE1YTAzMjApLCBBRV9OT1RfRVhJU1QKQUNQSSBFcnJvcjogTm8gaGFuZGxlciBmb3IgUmVnaW9u IFtFUkFNXSAoMHhmZmZmZmYwMDAxNTk1OTgwKSBbRW1iZWRkZWRDb250cm9sXSAyMDA5MDUyMSBl dnJlZ2lvbi00MzAKQUNQSSBFcnJvcjogUmVnaW9uIEVtYmVkZGVkQ29udHJvbCgzKSBoYXMgbm8g aGFuZGxlciAyMDA5MDUyMSBleGZsZGlvLTM4MgpBQ1BJIEVycm9yIChwc3BhcnNlLTA2MzMpOiBN ZXRob2QgcGFyc2UvZXhlY3V0aW9uIGZhaWxlZCBbXFxfU0JfLkJBVDAuX1NUQV0gKE5vZGUgMHhm ZmZmZmYwMDAxNWEwMzIwKSwgQUVfTk9UX0VYSVNUCkFDUEkgRXJyb3IgKHV0ZXZhbC0wMzI5KTog TWV0aG9kIGV4ZWN1dGlvbiBmYWlsZWQgW1xcX1NCXy5CQVQwLl9TVEFdIChOb2RlIDB4ZmZmZmZm MDAwMTVhMDMyMCksIEFFX05PVF9FWElTVApBQ1BJIEVycm9yOiBObyBoYW5kbGVyIGZvciBSZWdp b24gW0VSQU1dICgweGZmZmZmZjAwMDE1OTU5ODApIFtFbWJlZGRlZENvbnRyb2xdIDIwMDkwNTIx IGV2cmVnaW9uLTQzMApBQ1BJIEVycm9yOiBSZWdpb24gRW1iZWRkZWRDb250cm9sKDMpIGhhcyBu byBoYW5kbGVyIDIwMDkwNTIxIGV4ZmxkaW8tMzgyCkFDUEkgRXJyb3IgKHBzcGFyc2UtMDYzMyk6 IE1ldGhvZCBwYXJzZS9leGVjdXRpb24gZmFpbGVkIFtcXF9TQl8uQkFUMC5fU1RBXSAoTm9kZSAw eGZmZmZmZjAwMDE1YTAzMjApLCBBRV9OT1RfRVhJU1QKQUNQSSBFcnJvciAodXRldmFsLTAzMjkp OiBNZXRob2QgZXhlY3V0aW9uIGZhaWxlZCBbXFxfU0JfLkJBVDAuX1NUQV0gKE5vZGUgMHhmZmZm ZmYwMDAxNWEwMzIwKSwgQUVfTk9UX0VYSVNUCkFDUEkgRXJyb3I6IE5vIGhhbmRsZXIgZm9yIFJl Z2lvbiBbRVJBTV0gKDB4ZmZmZmZmMDAwMTU5NTk4MCkgW0VtYmVkZGVkQ29udHJvbF0gMjAwOTA1 MjEgZXZyZWdpb24tNDMwCkFDUEkgRXJyb3I6IFJlZ2lvbiBFbWJlZGRlZENvbnRyb2woMykgaGFz IG5vIGhhbmRsZXIgMjAwOTA1MjEgZXhmbGRpby0zODIKQUNQSSBFcnJvciAocHNwYXJzZS0wNjMz KTogTWV0aG9kIHBhcnNlL2V4ZWN1dGlvbiBmYWlsZWQgW1xcX1NCXy5CQVQwLl9TVEFdIChOb2Rl IDB4ZmZmZmZmMDAwMTVhMDMyMCksIEFFX05PVF9FWElTVApBQ1BJIEVycm9yICh1dGV2YWwtMDMy OSk6IE1ldGhvZCBleGVjdXRpb24gZmFpbGVkIFtcXF9TQl8uQkFUMC5fU1RBXSAoTm9kZSAweGZm ZmZmZjAwMDE1YTAzMjApLCBBRV9OT1RfRVhJU1QKQUNQSSBFcnJvcjogTm8gaGFuZGxlciBmb3Ig UmVnaW9uIFtFUkFNXSAoMHhmZmZmZmYwMDAxNTk1OTgwKSBbRW1iZWRkZWRDb250cm9sXSAyMDA5 MDUyMSBldnJlZ2lvbi00MzAKQUNQSSBFcnJvcjogUmVnaW9uIEVtYmVkZGVkQ29udHJvbCgzKSBo YXMgbm8gaGFuZGxlciAyMDA5MDUyMSBleGZsZGlvLTM4MgpBQ1BJIEVycm9yIChwc3BhcnNlLTA2 MzMpOiBNZXRob2QgcGFyc2UvZXhlY3V0aW9uIGZhaWxlZCBbXFxfU0JfLkJBVDAuX1NUQV0gKE5v ZGUgMHhmZmZmZmYwMDAxNWEwMzIwKSwgQUVfTk9UX0VYSVNUCkFDUEkgRXJyb3IgKHV0ZXZhbC0w MzI5KTogTWV0aG9kIGV4ZWN1dGlvbiBmYWlsZWQgW1xcX1NCXy5CQVQwLl9TVEFdIChOb2RlIDB4 ZmZmZmZmMDAwMTVhMDMyMCksIEFFX05PVF9FWElTVApBQ1BJIEVycm9yOiBObyBoYW5kbGVyIGZv ciBSZWdpb24gW0VSQU1dICgweGZmZmZmZjAwMDE1OTU5ODApIFtFbWJlZGRlZENvbnRyb2xdIDIw MDkwNTIxIGV2cmVnaW9uLTQzMApBQ1BJIEVycm9yOiBSZWdpb24gRW1iZWRkZWRDb250cm9sKDMp IGhhcyBubyBoYW5kbGVyIDIwMDkwNTIxIGV4ZmxkaW8tMzgyCkFDUEkgRXJyb3IgKHBzcGFyc2Ut MDYzMyk6IE1ldGhvZCBwYXJzZS9leGVjdXRpb24gZmFpbGVkIFtcXF9TQl8uQkFUMC5fU1RBXSAo Tm9kZSAweGZmZmZmZjAwMDE1YTAzMjApLCBBRV9OT1RfRVhJU1QKQUNQSSBFcnJvciAodXRldmFs LTAzMjkpOiBNZXRob2QgZXhlY3V0aW9uIGZhaWxlZCBbXFxfU0JfLkJBVDAuX1NUQV0gKE5vZGUg MHhmZmZmZmYwMDAxNWEwMzIwKSwgQUVfTk9UX0VYSVNUCkFDUEkgRXJyb3I6IE5vIGhhbmRsZXIg Zm9yIFJlZ2lvbiBbRVJBTV0gKDB4ZmZmZmZmMDAwMTU5NTk4MCkgW0VtYmVkZGVkQ29udHJvbF0g MjAwOTA1MjEgZXZyZWdpb24tNDMwCkFDUEkgRXJyb3I6IFJlZ2lvbiBFbWJlZGRlZENvbnRyb2wo MykgaGFzIG5vIGhhbmRsZXIgMjAwOTA1MjEgZXhmbGRpby0zODIKQUNQSSBFcnJvciAocHNwYXJz ZS0wNjMzKTogTWV0aG9kIHBhcnNlL2V4ZWN1dGlvbiBmYWlsZWQgW1xcX1NCXy5CQVQwLl9TVEFd IChOb2RlIDB4ZmZmZmZmMDAwMTVhMDMyMCksIEFFX05PVF9FWElTVApBQ1BJIEVycm9yICh1dGV2 YWwtMDMyOSk6IE1ldGhvZCBleGVjdXRpb24gZmFpbGVkIFtcXF9TQl8uQkFUMC5fU1RBXSAoTm9k ZSAweGZmZmZmZjAwMDE1YTAzMjApLCBBRV9OT1RfRVhJU1QKQUNQSSBFcnJvcjogTm8gaGFuZGxl ciBmb3IgUmVnaW9uIFtFUkFNXSAoMHhmZmZmZmYwMDAxNTk1OTgwKSBbRW1iZWRkZWRDb250cm9s XSAyMDA5MDUyMSBldnJlZ2lvbi00MzAKQUNQSSBFcnJvcjogUmVnaW9uIEVtYmVkZGVkQ29udHJv bCgzKSBoYXMgbm8gaGFuZGxlciAyMDA5MDUyMSBleGZsZGlvLTM4MgpBQ1BJIEVycm9yIChwc3Bh cnNlLTA2MzMpOiBNZXRob2QgcGFyc2UvZXhlY3V0aW9uIGZhaWxlZCBbXFxfU0JfLkJBVDAuX1NU QV0gKE5vZGUgMHhmZmZmZmYwMDAxNWEwMzIwKSwgQUVfTk9UX0VYSVNUCkFDUEkgRXJyb3IgKHV0 ZXZhbC0wMzI5KTogTWV0aG9kIGV4ZWN1dGlvbiBmYWlsZWQgW1xcX1NCXy5CQVQwLl9TVEFdIChO b2RlIDB4ZmZmZmZmMDAwMTVhMDMyMCksIEFFX05PVF9FWElTVApBQ1BJIEVycm9yOiBObyBoYW5k bGVyIGZvciBSZWdpb24gW0VSQU1dICgweGZmZmZmZjAwMDE1OTU5ODApIFtFbWJlZGRlZENvbnRy b2xdIDIwMDkwNTIxIGV2cmVnaW9uLTQzMApBQ1BJIEVycm9yOiBSZWdpb24gRW1iZWRkZWRDb250 cm9sKDMpIGhhcyBubyBoYW5kbGVyIDIwMDkwNTIxIGV4ZmxkaW8tMzgyCkFDUEkgRXJyb3IgKHBz cGFyc2UtMDYzMyk6IE1ldGhvZCBwYXJzZS9leGVjdXRpb24gZmFpbGVkIFtcXF9TQl8uQkFUMC5f U1RBXSAoTm9kZSAweGZmZmZmZjAwMDE1YTAzMjApLCBBRV9OT1RfRVhJU1QKQUNQSSBFcnJvciAo dXRldmFsLTAzMjkpOiBNZXRob2QgZXhlY3V0aW9uIGZhaWxlZCBbXFxfU0JfLkJBVDAuX1NUQV0g KE5vZGUgMHhmZmZmZmYwMDAxNWEwMzIwKSwgQUVfTk9UX0VYSVNUCkFDUEkgRXJyb3I6IE5vIGhh bmRsZXIgZm9yIFJlZ2lvbiBbRVJBTV0gKDB4ZmZmZmZmMDAwMTU5NTk4MCkgW0VtYmVkZGVkQ29u dHJvbF0gMjAwOTA1MjEgZXZyZWdpb24tNDMwCkFDUEkgRXJyb3I6IFJlZ2lvbiBFbWJlZGRlZENv bnRyb2woMykgaGFzIG5vIGhhbmRsZXIgMjAwOTA1MjEgZXhmbGRpby0zODIKQUNQSSBFcnJvciAo cHNwYXJzZS0wNjMzKTogTWV0aG9kIHBhcnNlL2V4ZWN1dGlvbiBmYWlsZWQgW1xcX1NCXy5CQVQw Ll9TVEFdIChOb2RlIDB4ZmZmZmZmMDAwMTVhMDMyMCksIEFFX05PVF9FWElTVApBQ1BJIEVycm9y ICh1dGV2YWwtMDMyOSk6IE1ldGhvZCBleGVjdXRpb24gZmFpbGVkIFtcXF9TQl8uQkFUMC5fU1RB XSAoTm9kZSAweGZmZmZmZjAwMDE1YTAzMjApLCBBRV9OT1RfRVhJU1QKQUNQSSBFcnJvcjogTm8g aGFuZGxlciBmb3IgUmVnaW9uIFtFUkFNXSAoMHhmZmZmZmYwMDAxNTk1OTgwKSBbRW1iZWRkZWRD b250cm9sXSAyMDA5MDUyMSBldnJlZ2lvbi00MzAKQUNQSSBFcnJvcjogUmVnaW9uIEVtYmVkZGVk Q29udHJvbCgzKSBoYXMgbm8gaGFuZGxlciAyMDA5MDUyMSBleGZsZGlvLTM4MgpBQ1BJIEVycm9y IChwc3BhcnNlLTA2MzMpOiBNZXRob2QgcGFyc2UvZXhlY3V0aW9uIGZhaWxlZCBbXFxfU0JfLkJB VDAuX1NUQV0gKE5vZGUgMHhmZmZmZmYwMDAxNWEwMzIwKSwgQUVfTk9UX0VYSVNUCkFDUEkgRXJy b3IgKHV0ZXZhbC0wMzI5KTogTWV0aG9kIGV4ZWN1dGlvbiBmYWlsZWQgW1xcX1NCXy5CQVQwLl9T VEFdIChOb2RlIDB4ZmZmZmZmMDAwMTVhMDMyMCksIEFFX05PVF9FWElTVApBQ1BJIEVycm9yOiBO byBoYW5kbGVyIGZvciBSZWdpb24gW0VSQU1dICgweGZmZmZmZjAwMDE1OTU5ODApIFtFbWJlZGRl ZENvbnRyb2xdIDIwMDkwNTIxIGV2cmVnaW9uLTQzMApBQ1BJIEVycm9yOiBSZWdpb24gRW1iZWRk ZWRDb250cm9sKDMpIGhhcyBubyBoYW5kbGVyIDIwMDkwNTIxIGV4ZmxkaW8tMzgyCkFDUEkgRXJy b3IgKHBzcGFyc2UtMDYzMyk6IE1ldGhvZCBwYXJzZS9leGVjdXRpb24gZmFpbGVkIFtcXF9TQl8u QkFUMC5fU1RBXSAoTm9kZSAweGZmZmZmZjAwMDE1YTAzMjApLCBBRV9OT1RfRVhJU1QKQUNQSSBF cnJvciAodXRldmFsLTAzMjkpOiBNZXRob2QgZXhlY3V0aW9uIGZhaWxlZCBbXFxfU0JfLkJBVDAu X1NUQV0gKE5vZGUgMHhmZmZmZmYwMDAxNWEwMzIwKSwgQUVfTk9UX0VYSVNUCkFDUEkgRXJyb3I6 IE5vIGhhbmRsZXIgZm9yIFJlZ2lvbiBbRVJBTV0gKDB4ZmZmZmZmMDAwMTU5NTk4MCkgW0VtYmVk ZGVkQ29udHJvbF0gMjAwOTA1MjEgZXZyZWdpb24tNDMwCkFDUEkgRXJyb3I6IFJlZ2lvbiBFbWJl ZGRlZENvbnRyb2woMykgaGFzIG5vIGhhbmRsZXIgMjAwOTA1MjEgZXhmbGRpby0zODIKQUNQSSBF cnJvciAocHNwYXJzZS0wNjMzKTogTWV0aG9kIHBhcnNlL2V4ZWN1dGlvbiBmYWlsZWQgW1xcX1NC Xy5CQVQwLl9TVEFdIChOb2RlIDB4ZmZmZmZmMDAwMTVhMDMyMCksIEFFX05PVF9FWElTVApBQ1BJ IEVycm9yICh1dGV2YWwtMDMyOSk6IE1ldGhvZCBleGVjdXRpb24gZmFpbGVkIFtcXF9TQl8uQkFU MC5fU1RBXSAoTm9kZSAweGZmZmZmZjAwMDE1YTAzMjApLCBBRV9OT1RfRVhJU1QKQUNQSSBFcnJv cjogTm8gaGFuZGxlciBmb3IgUmVnaW9uIFtFUkFNXSAoMHhmZmZmZmYwMDAxNTk1OTgwKSBbRW1i ZWRkZWRDb250cm9sXSAyMDA5MDUyMSBldnJlZ2lvbi00MzAKQUNQSSBFcnJvcjogUmVnaW9uIEVt YmVkZGVkQ29udHJvbCgzKSBoYXMgbm8gaGFuZGxlciAyMDA5MDUyMSBleGZsZGlvLTM4MgpBQ1BJ IEVycm9yIChwc3BhcnNlLTA2MzMpOiBNZXRob2QgcGFyc2UvZXhlY3V0aW9uIGZhaWxlZCBbXFxf U0JfLkJBVDAuX1NUQV0gKE5vZGUgMHhmZmZmZmYwMDAxNWEwMzIwKSwgQUVfTk9UX0VYSVNUCkFD UEkgRXJyb3IgKHV0ZXZhbC0wMzI5KTogTWV0aG9kIGV4ZWN1dGlvbiBmYWlsZWQgW1xcX1NCXy5C QVQwLl9TVEFdIChOb2RlIDB4ZmZmZmZmMDAwMTVhMDMyMCksIEFFX05PVF9FWElTVApBQ1BJIEVy cm9yOiBObyBoYW5kbGVyIGZvciBSZWdpb24gW0VSQU1dICgweGZmZmZmZjAwMDE1OTU5ODApIFtF bWJlZGRlZENvbnRyb2xdIDIwMDkwNTIxIGV2cmVnaW9uLTQzMApBQ1BJIEVycm9yOiBSZWdpb24g RW1iZWRkZWRDb250cm9sKDMpIGhhcyBubyBoYW5kbGVyIDIwMDkwNTIxIGV4ZmxkaW8tMzgyCkFD UEkgRXJyb3IgKHBzcGFyc2UtMDYzMyk6IE1ldGhvZCBwYXJzZS9leGVjdXRpb24gZmFpbGVkIFtc XF9TQl8uQkFUMC5fU1RBXSAoTm9kZSAweGZmZmZmZjAwMDE1YTAzMjApLCBBRV9OT1RfRVhJU1QK QUNQSSBFcnJvciAodXRldmFsLTAzMjkpOiBNZXRob2QgZXhlY3V0aW9uIGZhaWxlZCBbXFxfU0Jf LkJBVDAuX1NUQV0gKE5vZGUgMHhmZmZmZmYwMDAxNWEwMzIwKSwgQUVfTk9UX0VYSVNUCkFDUEkg RXJyb3I6IE5vIGhhbmRsZXIgZm9yIFJlZ2lvbiBbRVJBTV0gKDB4ZmZmZmZmMDAwMTU5NTk4MCkg W0VtYmVkZGVkQ29udHJvbF0gMjAwOTA1MjEgZXZyZWdpb24tNDMwCkFDUEkgRXJyb3I6IFJlZ2lv biBFbWJlZGRlZENvbnRyb2woMykgaGFzIG5vIGhhbmRsZXIgMjAwOTA1MjEgZXhmbGRpby0zODIK QUNQSSBFcnJvciAocHNwYXJzZS0wNjMzKTogTWV0aG9kIHBhcnNlL2V4ZWN1dGlvbiBmYWlsZWQg W1xcX1NCXy5CQVQwLl9TVEFdIChOb2RlIDB4ZmZmZmZmMDAwMTVhMDMyMCksIEFFX05PVF9FWElT VApBQ1BJIEVycm9yICh1dGV2YWwtMDMyOSk6IE1ldGhvZCBleGVjdXRpb24gZmFpbGVkIFtcXF9T Ql8uQkFUMC5fU1RBXSAoTm9kZSAweGZmZmZmZjAwMDE1YTAzMjApLCBBRV9OT1RfRVhJU1QKQUNQ SSBFcnJvcjogTm8gaGFuZGxlciBmb3IgUmVnaW9uIFtFUkFNXSAoMHhmZmZmZmYwMDAxNTk1OTgw KSBbRW1iZWRkZWRDb250cm9sXSAyMDA5MDUyMSBldnJlZ2lvbi00MzAKQUNQSSBFcnJvcjogUmVn aW9uIEVtYmVkZGVkQ29udHJvbCgzKSBoYXMgbm8gaGFuZGxlciAyMDA5MDUyMSBleGZsZGlvLTM4 MgpBQ1BJIEVycm9yIChwc3BhcnNlLTA2MzMpOiBNZXRob2QgcGFyc2UvZXhlY3V0aW9uIGZhaWxl ZCBbXFxfU0JfLkJBVDAuX1NUQV0gKE5vZGUgMHhmZmZmZmYwMDAxNWEwMzIwKSwgQUVfTk9UX0VY SVNUCkFDUEkgRXJyb3IgKHV0ZXZhbC0wMzI5KTogTWV0aG9kIGV4ZWN1dGlvbiBmYWlsZWQgW1xc X1NCXy5CQVQwLl9TVEFdIChOb2RlIDB4ZmZmZmZmMDAwMTVhMDMyMCksIEFFX05PVF9FWElTVApB Q1BJIEVycm9yOiBObyBoYW5kbGVyIGZvciBSZWdpb24gW0VSQU1dICgweGZmZmZmZjAwMDE1OTU5 ODApIFtFbWJlZGRlZENvbnRyb2xdIDIwMDkwNTIxIGV2cmVnaW9uLTQzMApBQ1BJIEVycm9yOiBS ZWdpb24gRW1iZWRkZWRDb250cm9sKDMpIGhhcyBubyBoYW5kbGVyIDIwMDkwNTIxIGV4ZmxkaW8t MzgyCkFDUEkgRXJyb3IgKHBzcGFyc2UtMDYzMyk6IE1ldGhvZCBwYXJzZS9leGVjdXRpb24gZmFp bGVkIFtcXF9TQl8uQkFUMC5fU1RBXSAoTm9kZSAweGZmZmZmZjAwMDE1YTAzMjApLCBBRV9OT1Rf RVhJU1QKQUNQSSBFcnJvciAodXRldmFsLTAzMjkpOiBNZXRob2QgZXhlY3V0aW9uIGZhaWxlZCBb XFxfU0JfLkJBVDAuX1NUQV0gKE5vZGUgMHhmZmZmZmYwMDAxNWEwMzIwKSwgQUVfTk9UX0VYSVNU CkFDUEkgRXJyb3I6IE5vIGhhbmRsZXIgZm9yIFJlZ2lvbiBbRVJBTV0gKDB4ZmZmZmZmMDAwMTU5 NTk4MCkgW0VtYmVkZGVkQ29udHJvbF0gMjAwOTA1MjEgZXZyZWdpb24tNDMwCkFDUEkgRXJyb3I6 IFJlZ2lvbiBFbWJlZGRlZENvbnRyb2woMykgaGFzIG5vIGhhbmRsZXIgMjAwOTA1MjEgZXhmbGRp by0zODIKQUNQSSBFcnJvciAocHNwYXJzZS0wNjMzKTogTWV0aG9kIHBhcnNlL2V4ZWN1dGlvbiBm YWlsZWQgW1xcX1NCXy5CQVQwLl9TVEFdIChOb2RlIDB4ZmZmZmZmMDAwMTVhMDMyMCksIEFFX05P VF9FWElTVApBQ1BJIEVycm9yICh1dGV2YWwtMDMyOSk6IE1ldGhvZCBleGVjdXRpb24gZmFpbGVk IFtcXF9TQl8uQkFUMC5fU1RBXSAoTm9kZSAweGZmZmZmZjAwMDE1YTAzMjApLCBBRV9OT1RfRVhJ U1QKQUNQSSBFcnJvcjogTm8gaGFuZGxlciBmb3IgUmVnaW9uIFtFUkFNXSAoMHhmZmZmZmYwMDAx NTk1OTgwKSBbRW1iZWRkZWRDb250cm9sXSAyMDA5MDUyMSBldnJlZ2lvbi00MzAKQUNQSSBFcnJv cjogUmVnaW9uIEVtYmVkZGVkQ29udHJvbCgzKSBoYXMgbm8gaGFuZGxlciAyMDA5MDUyMSBleGZs ZGlvLTM4MgpBQ1BJIEVycm9yIChwc3BhcnNlLTA2MzMpOiBNZXRob2QgcGFyc2UvZXhlY3V0aW9u IGZhaWxlZCBbXFxfU0JfLkJBVDAuX1NUQV0gKE5vZGUgMHhmZmZmZmYwMDAxNWEwMzIwKSwgQUVf Tk9UX0VYSVNUCkFDUEkgRXJyb3IgKHV0ZXZhbC0wMzI5KTogTWV0aG9kIGV4ZWN1dGlvbiBmYWls ZWQgW1xcX1NCXy5CQVQwLl9TVEFdIChOb2RlIDB4ZmZmZmZmMDAwMTVhMDMyMCksIEFFX05PVF9F WElTVApBQ1BJIEVycm9yOiBObyBoYW5kbGVyIGZvciBSZWdpb24gW0VSQU1dICgweGZmZmZmZjAw MDE1OTU5ODApIFtFbWJlZGRlZENvbnRyb2xdIDIwMDkwNTIxIGV2cmVnaW9uLTQzMApBQ1BJIEVy cm9yOiBSZWdpb24gRW1iZWRkZWRDb250cm9sKDMpIGhhcyBubyBoYW5kbGVyIDIwMDkwNTIxIGV4 ZmxkaW8tMzgyCkFDUEkgRXJyb3IgKHBzcGFyc2UtMDYzMyk6IE1ldGhvZCBwYXJzZS9leGVjdXRp b24gZmFpbGVkIFtcXF9TQl8uQkFUMC5fU1RBXSAoTm9kZSAweGZmZmZmZjAwMDE1YTAzMjApLCBB RV9OT1RfRVhJU1QKQUNQSSBFcnJvciAodXRldmFsLTAzMjkpOiBNZXRob2QgZXhlY3V0aW9uIGZh aWxlZCBbXFxfU0JfLkJBVDAuX1NUQV0gKE5vZGUgMHhmZmZmZmYwMDAxNWEwMzIwKSwgQUVfTk9U X0VYSVNUCkFDUEkgRXJyb3I6IE5vIGhhbmRsZXIgZm9yIFJlZ2lvbiBbRVJBTV0gKDB4ZmZmZmZm MDAwMTU5NTk4MCkgW0VtYmVkZGVkQ29udHJvbF0gMjAwOTA1MjEgZXZyZWdpb24tNDMwCkFDUEkg RXJyb3I6IFJlZ2lvbiBFbWJlZGRlZENvbnRyb2woMykgaGFzIG5vIGhhbmRsZXIgMjAwOTA1MjEg ZXhmbGRpby0zODIKQUNQSSBFcnJvciAocHNwYXJzZS0wNjMzKTogTWV0aG9kIHBhcnNlL2V4ZWN1 dGlvbiBmYWlsZWQgW1xcX1NCXy5CQVQwLl9TVEFdIChOb2RlIDB4ZmZmZmZmMDAwMTVhMDMyMCks IEFFX05PVF9FWElTVApBQ1BJIEVycm9yICh1dGV2YWwtMDMyOSk6IE1ldGhvZCBleGVjdXRpb24g ZmFpbGVkIFtcXF9TQl8uQkFUMC5fU1RBXSAoTm9kZSAweGZmZmZmZjAwMDE1YTAzMjApLCBBRV9O T1RfRVhJU1QKQUNQSSBFcnJvcjogTm8gaGFuZGxlciBmb3IgUmVnaW9uIFtFUkFNXSAoMHhmZmZm ZmYwMDAxNTk1OTgwKSBbRW1iZWRkZWRDb250cm9sXSAyMDA5MDUyMSBldnJlZ2lvbi00MzAKQUNQ SSBFcnJvcjogUmVnaW9uIEVtYmVkZGVkQ29udHJvbCgzKSBoYXMgbm8gaGFuZGxlciAyMDA5MDUy MSBleGZsZGlvLTM4MgpBQ1BJIEVycm9yIChwc3BhcnNlLTA2MzMpOiBNZXRob2QgcGFyc2UvZXhl Y3V0aW9uIGZhaWxlZCBbXFxfU0JfLkJBVDAuX1NUQV0gKE5vZGUgMHhmZmZmZmYwMDAxNWEwMzIw KSwgQUVfTk9UX0VYSVNUCkFDUEkgRXJyb3IgKHV0ZXZhbC0wMzI5KTogTWV0aG9kIGV4ZWN1dGlv biBmYWlsZWQgW1xcX1NCXy5CQVQwLl9TVEFdIChOb2RlIDB4ZmZmZmZmMDAwMTVhMDMyMCksIEFF X05PVF9FWElTVApBQ1BJIEVycm9yOiBObyBoYW5kbGVyIGZvciBSZWdpb24gW0VSQU1dICgweGZm ZmZmZjAwMDE1OTU5ODApIFtFbWJlZGRlZENvbnRyb2xdIDIwMDkwNTIxIGV2cmVnaW9uLTQzMApB Q1BJIEVycm9yOiBSZWdpb24gRW1iZWRkZWRDb250cm9sKDMpIGhhcyBubyBoYW5kbGVyIDIwMDkw NTIxIGV4ZmxkaW8tMzgyCkFDUEkgRXJyb3IgKHBzcGFyc2UtMDYzMyk6IE1ldGhvZCBwYXJzZS9l eGVjdXRpb24gZmFpbGVkIFtcXF9TQl8uQkFUMC5fU1RBXSAoTm9kZSAweGZmZmZmZjAwMDE1YTAz MjApLCBBRV9OT1RfRVhJU1QKQUNQSSBFcnJvciAodXRldmFsLTAzMjkpOiBNZXRob2QgZXhlY3V0 aW9uIGZhaWxlZCBbXFxfU0JfLkJBVDAuX1NUQV0gKE5vZGUgMHhmZmZmZmYwMDAxNWEwMzIwKSwg QUVfTk9UX0VYSVNUCkFDUEkgRXJyb3I6IE5vIGhhbmRsZXIgZm9yIFJlZ2lvbiBbRVJBTV0gKDB4 ZmZmZmZmMDAwMTU5NTk4MCkgW0VtYmVkZGVkQ29udHJvbF0gMjAwOTA1MjEgZXZyZWdpb24tNDMw CkFDUEkgRXJyb3I6IFJlZ2lvbiBFbWJlZGRlZENvbnRyb2woMykgaGFzIG5vIGhhbmRsZXIgMjAw OTA1MjEgZXhmbGRpby0zODIKQUNQSSBFcnJvciAocHNwYXJzZS0wNjMzKTogTWV0aG9kIHBhcnNl L2V4ZWN1dGlvbiBmYWlsZWQgW1xcX1NCXy5CQVQwLl9TVEFdIChOb2RlIDB4ZmZmZmZmMDAwMTVh MDMyMCksIEFFX05PVF9FWElTVApBQ1BJIEVycm9yICh1dGV2YWwtMDMyOSk6IE1ldGhvZCBleGVj dXRpb24gZmFpbGVkIFtcXF9TQl8uQkFUMC5fU1RBXSAoTm9kZSAweGZmZmZmZjAwMDE1YTAzMjAp LCBBRV9OT1RfRVhJU1QKYmF0dGVyeTA6IDxBQ1BJIENvbnRyb2wgTWV0aG9kIEJhdHRlcnk+IG9u IGFjcGkwCkFDUEkgRXJyb3I6IE5vIGhhbmRsZXIgZm9yIFJlZ2lvbiBbRVJBTV0gKDB4ZmZmZmZm MDAwMTU5NTk4MCkgW0VtYmVkZGVkQ29udHJvbF0gMjAwOTA1MjEgZXZyZWdpb24tNDMwCkFDUEkg RXJyb3I6IFJlZ2lvbiBFbWJlZGRlZENvbnRyb2woMykgaGFzIG5vIGhhbmRsZXIgMjAwOTA1MjEg ZXhmbGRpby0zODIKQUNQSSBFcnJvciAocHNwYXJzZS0wNjMzKTogTWV0aG9kIHBhcnNlL2V4ZWN1 dGlvbiBmYWlsZWQgW1xcX1NCXy5CQVQwLl9TVEFdIChOb2RlIDB4ZmZmZmZmMDAwMTVhMDMyMCks IEFFX05PVF9FWElTVApBQ1BJIEVycm9yICh1dGV2YWwtMDMyOSk6IE1ldGhvZCBleGVjdXRpb24g ZmFpbGVkIFtcXF9TQl8uQkFUMC5fU1RBXSAoTm9kZSAweGZmZmZmZjAwMDE1YTAzMjApLCBBRV9O T1RfRVhJU1QKQUNQSSBFcnJvcjogTm8gaGFuZGxlciBmb3IgUmVnaW9uIFtFUkFNXSAoMHhmZmZm ZmYwMDAxNTk1OTgwKSBbRW1iZWRkZWRDb250cm9sXSAyMDA5MDUyMSBldnJlZ2lvbi00MzAKQUNQ SSBFcnJvcjogUmVnaW9uIEVtYmVkZGVkQ29udHJvbCgzKSBoYXMgbm8gaGFuZGxlciAyMDA5MDUy MSBleGZsZGlvLTM4MgpBQ1BJIEVycm9yIChwc3BhcnNlLTA2MzMpOiBNZXRob2QgcGFyc2UvZXhl Y3V0aW9uIGZhaWxlZCBbXFxfU0JfLkJBVDAuX1NUQV0gKE5vZGUgMHhmZmZmZmYwMDAxNWEwMzIw KSwgQUVfTk9UX0VYSVNUCkFDUEkgRXJyb3IgKHV0ZXZhbC0wMzI5KTogTWV0aG9kIGV4ZWN1dGlv biBmYWlsZWQgW1xcX1NCXy5CQVQwLl9TVEFdIChOb2RlIDB4ZmZmZmZmMDAwMTVhMDMyMCksIEFF X05PVF9FWElTVAphY3BpX2FjYWQwOiA8QUMgQWRhcHRlcj4gb24gYWNwaTAKcGNpYjA6IDxBQ1BJ IEhvc3QtUENJIGJyaWRnZT4gcG9ydCAweGNmOC0weGNmZiBvbiBhY3BpMApwY2kwOiA8QUNQSSBQ Q0kgYnVzPiBvbiBwY2liMApwY2kwOiBkb21haW49MCwgcGh5c2ljYWwgYnVzPTAKZm91bmQtPgl2 ZW5kb3I9MHg4MDg2LCBkZXY9MHgyYTQwLCByZXZpZD0weDA3Cglkb21haW49MCwgYnVzPTAsIHNs b3Q9MCwgZnVuYz0wCgljbGFzcz0wNi0wMC0wMCwgaGRydHlwZT0weDAwLCBtZmRldj0wCgljbWRy ZWc9MHgwMDA2LCBzdGF0cmVnPTB4MjA5MCwgY2FjaGVsbnN6PTAgKGR3b3JkcykKCWxhdHRpbWVy PTB4MDAgKDAgbnMpLCBtaW5nbnQ9MHgwMCAoMCBucyksIG1heGxhdD0weDAwICgwIG5zKQpmb3Vu ZC0+CXZlbmRvcj0weDgwODYsIGRldj0weDJhNDIsIHJldmlkPTB4MDcKCWRvbWFpbj0wLCBidXM9 MCwgc2xvdD0yLCBmdW5jPTAKCWNsYXNzPTAzLTAwLTAwLCBoZHJ0eXBlPTB4MDAsIG1mZGV2PTEK CWNtZHJlZz0weDAwMDcsIHN0YXRyZWc9MHgwMDkwLCBjYWNoZWxuc3o9MCAoZHdvcmRzKQoJbGF0 dGltZXI9MHgwMCAoMCBucyksIG1pbmdudD0weDAwICgwIG5zKSwgbWF4bGF0PTB4MDAgKDAgbnMp CglpbnRwaW49YSwgaXJxPTExCglwb3dlcnNwZWMgMyAgc3VwcG9ydHMgRDAgRDMgIGN1cnJlbnQg RDAKCU1TSSBzdXBwb3J0cyAxIG1lc3NhZ2UKCW1hcFsxMF06IHR5cGUgTWVtb3J5LCByYW5nZSA2 NCwgYmFzZSAweGQwMDAwMDAwLCBzaXplIDIyLCBlbmFibGVkCgltYXBbMThdOiB0eXBlIFByZWZl dGNoYWJsZSBNZW1vcnksIHJhbmdlIDY0LCBiYXNlIDB4YzAwMDAwMDAsIHNpemUgMjgsIGVuYWJs ZWQKCW1hcFsyMF06IHR5cGUgSS9PIFBvcnQsIHJhbmdlIDMyLCBiYXNlIDB4NTBmMCwgc2l6ZSAg MywgZW5hYmxlZApwY2liMDogbWF0Y2hlZCBlbnRyeSBmb3IgMC4yLklOVEEKcGNpYjA6IHNsb3Qg MiBJTlRBIGhhcmR3aXJlZCB0byBJUlEgMTYKZm91bmQtPgl2ZW5kb3I9MHg4MDg2LCBkZXY9MHgy YTQzLCByZXZpZD0weDA3Cglkb21haW49MCwgYnVzPTAsIHNsb3Q9MiwgZnVuYz0xCgljbGFzcz0w My04MC0wMCwgaGRydHlwZT0weDAwLCBtZmRldj0xCgljbWRyZWc9MHgwMDA3LCBzdGF0cmVnPTB4 MDA5MCwgY2FjaGVsbnN6PTAgKGR3b3JkcykKCWxhdHRpbWVyPTB4MDAgKDAgbnMpLCBtaW5nbnQ9 MHgwMCAoMCBucyksIG1heGxhdD0weDAwICgwIG5zKQoJcG93ZXJzcGVjIDMgIHN1cHBvcnRzIEQw IEQzICBjdXJyZW50IEQwCgltYXBbMTBdOiB0eXBlIE1lbW9yeSwgcmFuZ2UgNjQsIGJhc2UgMHhk NDQwMDAwMCwgc2l6ZSAyMCwgZW5hYmxlZApmb3VuZC0+CXZlbmRvcj0weDgwODYsIGRldj0weDI5 MzcsIHJldmlkPTB4MDMKCWRvbWFpbj0wLCBidXM9MCwgc2xvdD0yNiwgZnVuYz0wCgljbGFzcz0w Yy0wMy0wMCwgaGRydHlwZT0weDAwLCBtZmRldj0xCgljbWRyZWc9MHgwMDA1LCBzdGF0cmVnPTB4 MDI5MCwgY2FjaGVsbnN6PTAgKGR3b3JkcykKCWxhdHRpbWVyPTB4MDAgKDAgbnMpLCBtaW5nbnQ9 MHgwMCAoMCBucyksIG1heGxhdD0weDAwICgwIG5zKQoJaW50cGluPWEsIGlycT0xMQoJbWFwWzIw XTogdHlwZSBJL08gUG9ydCwgcmFuZ2UgMzIsIGJhc2UgMHg1MGMwLCBzaXplICA1LCBlbmFibGVk CnBjaWIwOiBtYXRjaGVkIGVudHJ5IGZvciAwLjI2LklOVEEKcGNpYjA6IHNsb3QgMjYgSU5UQSBo YXJkd2lyZWQgdG8gSVJRIDE2CnVua25vd246IFJlc2VydmVkIDB4MjAgYnl0ZXMgZm9yIHJpZCAw eDIwIHR5cGUgNCBhdCAweDUwYzAKZm91bmQtPgl2ZW5kb3I9MHg4MDg2LCBkZXY9MHgyOTM4LCBy ZXZpZD0weDAzCglkb21haW49MCwgYnVzPTAsIHNsb3Q9MjYsIGZ1bmM9MQoJY2xhc3M9MGMtMDMt MDAsIGhkcnR5cGU9MHgwMCwgbWZkZXY9MAoJY21kcmVnPTB4MDAwNSwgc3RhdHJlZz0weDAyOTAs IGNhY2hlbG5zej0wIChkd29yZHMpCglsYXR0aW1lcj0weDAwICgwIG5zKSwgbWluZ250PTB4MDAg KDAgbnMpLCBtYXhsYXQ9MHgwMCAoMCBucykKCWludHBpbj1iLCBpcnE9MTAKCW1hcFsyMF06IHR5 cGUgSS9PIFBvcnQsIHJhbmdlIDMyLCBiYXNlIDB4NTBhMCwgc2l6ZSAgNSwgZW5hYmxlZApwY2li MDogbWF0Y2hlZCBlbnRyeSBmb3IgMC4yNi5JTlRCCnBjaWIwOiBzbG90IDI2IElOVEIgaGFyZHdp cmVkIHRvIElSUSAxNwp1bmtub3duOiBSZXNlcnZlZCAweDIwIGJ5dGVzIGZvciByaWQgMHgyMCB0 eXBlIDQgYXQgMHg1MGEwCmZvdW5kLT4JdmVuZG9yPTB4ODA4NiwgZGV2PTB4MjkzYywgcmV2aWQ9 MHgwMwoJZG9tYWluPTAsIGJ1cz0wLCBzbG90PTI2LCBmdW5jPTcKCWNsYXNzPTBjLTAzLTIwLCBo ZHJ0eXBlPTB4MDAsIG1mZGV2PTAKCWNtZHJlZz0weDAwMDYsIHN0YXRyZWc9MHgwMjkwLCBjYWNo ZWxuc3o9MCAoZHdvcmRzKQoJbGF0dGltZXI9MHgwMCAoMCBucyksIG1pbmdudD0weDAwICgwIG5z KSwgbWF4bGF0PTB4MDAgKDAgbnMpCglpbnRwaW49YywgaXJxPTExCglwb3dlcnNwZWMgMiAgc3Vw cG9ydHMgRDAgRDMgIGN1cnJlbnQgRDAKCW1hcFsxMF06IHR5cGUgTWVtb3J5LCByYW5nZSAzMiwg YmFzZSAweGQ4NTA0YzAwLCBzaXplIDEwLCBlbmFibGVkCnBjaWIwOiBtYXRjaGVkIGVudHJ5IGZv ciAwLjI2LklOVEMKcGNpYjA6IHNsb3QgMjYgSU5UQyBoYXJkd2lyZWQgdG8gSVJRIDE4CnVua25v d246IFJlc2VydmVkIDB4NDAwIGJ5dGVzIGZvciByaWQgMHgxMCB0eXBlIDMgYXQgMHhkODUwNGMw MAplaGNpIGVhcmx5OiBTTU0gYWN0aXZlLCByZXF1ZXN0IG93bmVyIGNoYW5nZQpmb3VuZC0+CXZl bmRvcj0weDgwODYsIGRldj0weDI5M2UsIHJldmlkPTB4MDMKCWRvbWFpbj0wLCBidXM9MCwgc2xv dD0yNywgZnVuYz0wCgljbGFzcz0wNC0wMy0wMCwgaGRydHlwZT0weDAwLCBtZmRldj0wCgljbWRy ZWc9MHgwMDA2LCBzdGF0cmVnPTB4MDAxMCwgY2FjaGVsbnN6PTE2IChkd29yZHMpCglsYXR0aW1l cj0weDAwICgwIG5zKSwgbWluZ250PTB4MDAgKDAgbnMpLCBtYXhsYXQ9MHgwMCAoMCBucykKCWlu dHBpbj1iLCBpcnE9MTEKCXBvd2Vyc3BlYyAyICBzdXBwb3J0cyBEMCBEMyAgY3VycmVudCBEMAoJ TVNJIHN1cHBvcnRzIDEgbWVzc2FnZSwgNjQgYml0CgltYXBbMTBdOiB0eXBlIE1lbW9yeSwgcmFu Z2UgNjQsIGJhc2UgMHhkODUwMDAwMCwgc2l6ZSAxNCwgZW5hYmxlZApwY2liMDogbWF0Y2hlZCBl bnRyeSBmb3IgMC4yNy5JTlRCCnBjaWIwOiBzbG90IDI3IElOVEIgaGFyZHdpcmVkIHRvIElSUSAy Mgpmb3VuZC0+CXZlbmRvcj0weDgwODYsIGRldj0weDI5NDAsIHJldmlkPTB4MDMKCWRvbWFpbj0w LCBidXM9MCwgc2xvdD0yOCwgZnVuYz0wCgljbGFzcz0wNi0wNC0wMCwgaGRydHlwZT0weDAxLCBt ZmRldj0xCgljbWRyZWc9MHgwMDA3LCBzdGF0cmVnPTB4MDAxMCwgY2FjaGVsbnN6PTAgKGR3b3Jk cykKCWxhdHRpbWVyPTB4MDAgKDAgbnMpLCBtaW5nbnQ9MHgwMCAoMCBucyksIG1heGxhdD0weDAw ICgwIG5zKQoJaW50cGluPWEsIGlycT0yNTUKCXBvd2Vyc3BlYyAyICBzdXBwb3J0cyBEMCBEMyAg Y3VycmVudCBEMAoJTVNJIHN1cHBvcnRzIDEgbWVzc2FnZQpmb3VuZC0+CXZlbmRvcj0weDgwODYs IGRldj0weDI5NDQsIHJldmlkPTB4MDMKCWRvbWFpbj0wLCBidXM9MCwgc2xvdD0yOCwgZnVuYz0y CgljbGFzcz0wNi0wNC0wMCwgaGRydHlwZT0weDAxLCBtZmRldj0xCgljbWRyZWc9MHgwMDA3LCBz dGF0cmVnPTB4MDAxMCwgY2FjaGVsbnN6PTAgKGR3b3JkcykKCWxhdHRpbWVyPTB4MDAgKDAgbnMp LCBtaW5nbnQ9MHgwMCAoMCBucyksIG1heGxhdD0weDAwICgwIG5zKQoJaW50cGluPWMsIGlycT0y NTUKCXBvd2Vyc3BlYyAyICBzdXBwb3J0cyBEMCBEMyAgY3VycmVudCBEMAoJTVNJIHN1cHBvcnRz IDEgbWVzc2FnZQpmb3VuZC0+CXZlbmRvcj0weDgwODYsIGRldj0weDI5NDYsIHJldmlkPTB4MDMK CWRvbWFpbj0wLCBidXM9MCwgc2xvdD0yOCwgZnVuYz0zCgljbGFzcz0wNi0wNC0wMCwgaGRydHlw ZT0weDAxLCBtZmRldj0xCgljbWRyZWc9MHgwMDA3LCBzdGF0cmVnPTB4MDAxMCwgY2FjaGVsbnN6 PTAgKGR3b3JkcykKCWxhdHRpbWVyPTB4MDAgKDAgbnMpLCBtaW5nbnQ9MHgwMCAoMCBucyksIG1h eGxhdD0weDAwICgwIG5zKQoJaW50cGluPWQsIGlycT0yNTUKCXBvd2Vyc3BlYyAyICBzdXBwb3J0 cyBEMCBEMyAgY3VycmVudCBEMAoJTVNJIHN1cHBvcnRzIDEgbWVzc2FnZQpmb3VuZC0+CXZlbmRv cj0weDgwODYsIGRldj0weDI5NGEsIHJldmlkPTB4MDMKCWRvbWFpbj0wLCBidXM9MCwgc2xvdD0y OCwgZnVuYz01CgljbGFzcz0wNi0wNC0wMCwgaGRydHlwZT0weDAxLCBtZmRldj0xCgljbWRyZWc9 MHgwMDA3LCBzdGF0cmVnPTB4MDAxMCwgY2FjaGVsbnN6PTAgKGR3b3JkcykKCWxhdHRpbWVyPTB4 MDAgKDAgbnMpLCBtaW5nbnQ9MHgwMCAoMCBucyksIG1heGxhdD0weDAwICgwIG5zKQoJaW50cGlu PWIsIGlycT0yNTUKCXBvd2Vyc3BlYyAyICBzdXBwb3J0cyBEMCBEMyAgY3VycmVudCBEMAoJTVNJ IHN1cHBvcnRzIDEgbWVzc2FnZQpmb3VuZC0+CXZlbmRvcj0weDgwODYsIGRldj0weDI5MzQsIHJl dmlkPTB4MDMKCWRvbWFpbj0wLCBidXM9MCwgc2xvdD0yOSwgZnVuYz0wCgljbGFzcz0wYy0wMy0w MCwgaGRydHlwZT0weDAwLCBtZmRldj0xCgljbWRyZWc9MHgwMDA1LCBzdGF0cmVnPTB4MDI5MCwg Y2FjaGVsbnN6PTAgKGR3b3JkcykKCWxhdHRpbWVyPTB4MDAgKDAgbnMpLCBtaW5nbnQ9MHgwMCAo MCBucyksIG1heGxhdD0weDAwICgwIG5zKQoJaW50cGluPWEsIGlycT0xMQoJbWFwWzIwXTogdHlw ZSBJL08gUG9ydCwgcmFuZ2UgMzIsIGJhc2UgMHg1MDgwLCBzaXplICA1LCBlbmFibGVkCnBjaWIw OiBtYXRjaGVkIGVudHJ5IGZvciAwLjI5LklOVEEKcGNpYjA6IHNsb3QgMjkgSU5UQSBoYXJkd2ly ZWQgdG8gSVJRIDIwCnVua25vd246IFJlc2VydmVkIDB4MjAgYnl0ZXMgZm9yIHJpZCAweDIwIHR5 cGUgNCBhdCAweDUwODAKZm91bmQtPgl2ZW5kb3I9MHg4MDg2LCBkZXY9MHgyOTM1LCByZXZpZD0w eDAzCglkb21haW49MCwgYnVzPTAsIHNsb3Q9MjksIGZ1bmM9MQoJY2xhc3M9MGMtMDMtMDAsIGhk cnR5cGU9MHgwMCwgbWZkZXY9MAoJY21kcmVnPTB4MDAwNSwgc3RhdHJlZz0weDAyOTAsIGNhY2hl bG5zej0wIChkd29yZHMpCglsYXR0aW1lcj0weDAwICgwIG5zKSwgbWluZ250PTB4MDAgKDAgbnMp LCBtYXhsYXQ9MHgwMCAoMCBucykKCWludHBpbj1iLCBpcnE9MTEKCW1hcFsyMF06IHR5cGUgSS9P IFBvcnQsIHJhbmdlIDMyLCBiYXNlIDB4NTA2MCwgc2l6ZSAgNSwgZW5hYmxlZApwY2liMDogbWF0 Y2hlZCBlbnRyeSBmb3IgMC4yOS5JTlRCCnBjaWIwOiBzbG90IDI5IElOVEIgaGFyZHdpcmVkIHRv IElSUSAyMgp1bmtub3duOiBSZXNlcnZlZCAweDIwIGJ5dGVzIGZvciByaWQgMHgyMCB0eXBlIDQg YXQgMHg1MDYwCmZvdW5kLT4JdmVuZG9yPTB4ODA4NiwgZGV2PTB4MjkzNiwgcmV2aWQ9MHgwMwoJ ZG9tYWluPTAsIGJ1cz0wLCBzbG90PTI5LCBmdW5jPTIKCWNsYXNzPTBjLTAzLTAwLCBoZHJ0eXBl PTB4MDAsIG1mZGV2PTAKCWNtZHJlZz0weDAwMDUsIHN0YXRyZWc9MHgwMjkwLCBjYWNoZWxuc3o9 MCAoZHdvcmRzKQoJbGF0dGltZXI9MHgwMCAoMCBucyksIG1pbmdudD0weDAwICgwIG5zKSwgbWF4 bGF0PTB4MDAgKDAgbnMpCglpbnRwaW49YywgaXJxPTExCgltYXBbMjBdOiB0eXBlIEkvTyBQb3J0 LCByYW5nZSAzMiwgYmFzZSAweDUwNDAsIHNpemUgIDUsIGVuYWJsZWQKcGNpYjA6IG1hdGNoZWQg ZW50cnkgZm9yIDAuMjkuSU5UQwpwY2liMDogc2xvdCAyOSBJTlRDIGhhcmR3aXJlZCB0byBJUlEg MTgKdW5rbm93bjogUmVzZXJ2ZWQgMHgyMCBieXRlcyBmb3IgcmlkIDB4MjAgdHlwZSA0IGF0IDB4 NTA0MApmb3VuZC0+CXZlbmRvcj0weDgwODYsIGRldj0weDI5M2EsIHJldmlkPTB4MDMKCWRvbWFp bj0wLCBidXM9MCwgc2xvdD0yOSwgZnVuYz03CgljbGFzcz0wYy0wMy0yMCwgaGRydHlwZT0weDAw LCBtZmRldj0wCgljbWRyZWc9MHgwMDA2LCBzdGF0cmVnPTB4MDI5MCwgY2FjaGVsbnN6PTAgKGR3 b3JkcykKCWxhdHRpbWVyPTB4MDAgKDAgbnMpLCBtaW5nbnQ9MHgwMCAoMCBucyksIG1heGxhdD0w eDAwICgwIG5zKQoJaW50cGluPWEsIGlycT0xMQoJcG93ZXJzcGVjIDIgIHN1cHBvcnRzIEQwIEQz ICBjdXJyZW50IEQwCgltYXBbMTBdOiB0eXBlIE1lbW9yeSwgcmFuZ2UgMzIsIGJhc2UgMHhkODUw NDgwMCwgc2l6ZSAxMCwgZW5hYmxlZApwY2liMDogbWF0Y2hlZCBlbnRyeSBmb3IgMC4yOS5JTlRB CnBjaWIwOiBzbG90IDI5IElOVEEgaGFyZHdpcmVkIHRvIElSUSAyMAp1bmtub3duOiBSZXNlcnZl ZCAweDQwMCBieXRlcyBmb3IgcmlkIDB4MTAgdHlwZSAzIGF0IDB4ZDg1MDQ4MDAKZWhjaSBlYXJs eTogU01NIGFjdGl2ZSwgcmVxdWVzdCBvd25lciBjaGFuZ2UKZm91bmQtPgl2ZW5kb3I9MHg4MDg2 LCBkZXY9MHgyNDQ4LCByZXZpZD0weDkzCglkb21haW49MCwgYnVzPTAsIHNsb3Q9MzAsIGZ1bmM9 MAoJY2xhc3M9MDYtMDQtMDEsIGhkcnR5cGU9MHgwMSwgbWZkZXY9MAoJY21kcmVnPTB4MDAwNywg c3RhdHJlZz0weDAwMTAsIGNhY2hlbG5zej0wIChkd29yZHMpCglsYXR0aW1lcj0weDAwICgwIG5z KSwgbWluZ250PTB4MDAgKDAgbnMpLCBtYXhsYXQ9MHgwMCAoMCBucykKZm91bmQtPgl2ZW5kb3I9 MHg4MDg2LCBkZXY9MHgyOTE5LCByZXZpZD0weDAzCglkb21haW49MCwgYnVzPTAsIHNsb3Q9MzEs IGZ1bmM9MAoJY2xhc3M9MDYtMDEtMDAsIGhkcnR5cGU9MHgwMCwgbWZkZXY9MQoJY21kcmVnPTB4 MDAwNywgc3RhdHJlZz0weDAyMTAsIGNhY2hlbG5zej0wIChkd29yZHMpCglsYXR0aW1lcj0weDAw ICgwIG5zKSwgbWluZ250PTB4MDAgKDAgbnMpLCBtYXhsYXQ9MHgwMCAoMCBucykKZm91bmQtPgl2 ZW5kb3I9MHg4MDg2LCBkZXY9MHgyOTI5LCByZXZpZD0weDAzCglkb21haW49MCwgYnVzPTAsIHNs b3Q9MzEsIGZ1bmM9MgoJY2xhc3M9MDEtMDYtMDEsIGhkcnR5cGU9MHgwMCwgbWZkZXY9MAoJY21k cmVnPTB4MDAwNywgc3RhdHJlZz0weDAyYjAsIGNhY2hlbG5zej0wIChkd29yZHMpCglsYXR0aW1l cj0weDAwICgwIG5zKSwgbWluZ250PTB4MDAgKDAgbnMpLCBtYXhsYXQ9MHgwMCAoMCBucykKCWlu dHBpbj1iLCBpcnE9MTEKCXBvd2Vyc3BlYyAzICBzdXBwb3J0cyBEMCBEMyAgY3VycmVudCBEMAoJ TVNJIHN1cHBvcnRzIDE2IG1lc3NhZ2VzCgltYXBbMTBdOiB0eXBlIEkvTyBQb3J0LCByYW5nZSAz MiwgYmFzZSAweDUwZTgsIHNpemUgIDMsIGVuYWJsZWQKCW1hcFsxNF06IHR5cGUgSS9PIFBvcnQs IHJhbmdlIDMyLCBiYXNlIDB4NTBmYywgc2l6ZSAgMiwgZW5hYmxlZAoJbWFwWzE4XTogdHlwZSBJ L08gUG9ydCwgcmFuZ2UgMzIsIGJhc2UgMHg1MGUwLCBzaXplICAzLCBlbmFibGVkCgltYXBbMWNd OiB0eXBlIEkvTyBQb3J0LCByYW5nZSAzMiwgYmFzZSAweDUwZjgsIHNpemUgIDIsIGVuYWJsZWQK CW1hcFsyMF06IHR5cGUgSS9PIFBvcnQsIHJhbmdlIDMyLCBiYXNlIDB4NTAyMCwgc2l6ZSAgNSwg ZW5hYmxlZAoJbWFwWzI0XTogdHlwZSBNZW1vcnksIHJhbmdlIDMyLCBiYXNlIDB4ZDg1MDQwMDAs IHNpemUgMTEsIGVuYWJsZWQKcGNpYjA6IG1hdGNoZWQgZW50cnkgZm9yIDAuMzEuSU5UQgpwY2li MDogc2xvdCAzMSBJTlRCIGhhcmR3aXJlZCB0byBJUlEgMjEKZm91bmQtPgl2ZW5kb3I9MHg4MDg2 LCBkZXY9MHgyOTMwLCByZXZpZD0weDAzCglkb21haW49MCwgYnVzPTAsIHNsb3Q9MzEsIGZ1bmM9 MwoJY2xhc3M9MGMtMDUtMDAsIGhkcnR5cGU9MHgwMCwgbWZkZXY9MAoJY21kcmVnPTB4MDAwMywg c3RhdHJlZz0weDAyODAsIGNhY2hlbG5zej0wIChkd29yZHMpCglsYXR0aW1lcj0weDAwICgwIG5z KSwgbWluZ250PTB4MDAgKDAgbnMpLCBtYXhsYXQ9MHgwMCAoMCBucykKCWludHBpbj1jLCBpcnE9 MTEKCW1hcFsxMF06IHR5cGUgTWVtb3J5LCByYW5nZSA2NCwgYmFzZSAweGQ4NTA1MDAwLCBzaXpl ICA4LCBlbmFibGVkCgltYXBbMjBdOiB0eXBlIEkvTyBQb3J0LCByYW5nZSAzMiwgYmFzZSAweDUw MDAsIHNpemUgIDUsIGVuYWJsZWQKcGNpYjA6IG1hdGNoZWQgZW50cnkgZm9yIDAuMzEuSU5UQwpw Y2liMDogc2xvdCAzMSBJTlRDIGhhcmR3aXJlZCB0byBJUlEgMTgKdmdhcGNpMDogPFZHQS1jb21w YXRpYmxlIGRpc3BsYXk+IHBvcnQgMHg1MGYwLTB4NTBmNyBtZW0gMHhkMDAwMDAwMC0weGQwM2Zm ZmZmLDB4YzAwMDAwMDAtMHhjZmZmZmZmZiBpcnEgMTYgYXQgZGV2aWNlIDIuMCBvbiBwY2kwCmFn cDA6IDxJbnRlbCBHTTQ1IFNWR0EgY29udHJvbGxlcj4gb24gdmdhcGNpMAp2Z2FwY2kwOiBSZXNl cnZlZCAweDEwMDAwMDAwIGJ5dGVzIGZvciByaWQgMHgxOCB0eXBlIDMgYXQgMHhjMDAwMDAwMAp2 Z2FwY2kwOiBSZXNlcnZlZCAweDQwMDAwMCBieXRlcyBmb3IgcmlkIDB4MTAgdHlwZSAzIGF0IDB4 ZDAwMDAwMDAKYWdwMDogZGV0ZWN0ZWQgNjU1MzJrIHN0b2xlbiBtZW1vcnkKYWdwMDogYXBlcnR1 cmUgc2l6ZSBpcyAyNTZNCmRybTA6IDxNb2JpbGUgSW50ZWxcTS1CXE0tLiBHTTQ1IEV4cHJlc3Mg Q2hpcHNldD4gb24gdmdhcGNpMAp2Z2FwY2kwOiBhdHRlbXB0aW5nIHRvIGFsbG9jYXRlIDEgTVNJ IHZlY3RvcnMgKDEgc3VwcG9ydGVkKQptc2k6IHJvdXRpbmcgTVNJIElSUSAyNTYgdG8gbG9jYWwg QVBJQyAwIHZlY3RvciA0OQp2Z2FwY2kwOiB1c2luZyBJUlEgMjU2IGZvciBNU0kKaW5mbzogW2Ry bV0gTVNJIGVuYWJsZWQgMSBtZXNzYWdlKHMpCnZnYXBjaTA6IGNoaWxkIGRybTAgcmVxdWVzdGVk IHBjaV9lbmFibGVfYnVzbWFzdGVyCmluZm86IFtkcm1dIEFHUCBhdCAweGMwMDAwMDAwIDI1Nk1C CmluZm86IFtkcm1dIEluaXRpYWxpemVkIGk5MTUgMS42LjAgMjAwODA3MzAKdmdhcGNpMTogPFZH QS1jb21wYXRpYmxlIGRpc3BsYXk+IG1lbSAweGQ0NDAwMDAwLTB4ZDQ0ZmZmZmYgYXQgZGV2aWNl IDIuMSBvbiBwY2kwCnVoY2kwOiA8SW50ZWwgODI4MDFJIChJQ0g5KSBVU0IgY29udHJvbGxlcj4g cG9ydCAweDUwYzAtMHg1MGRmIGlycSAxNiBhdCBkZXZpY2UgMjYuMCBvbiBwY2kwCmlvYXBpYzA6 IHJvdXRpbmcgaW50cGluIDE2IChQQ0kgSVJRIDE2KSB0byBsYXBpYyAwIHZlY3RvciA1MAp1aGNp MDogW01QU0FGRV0KdWhjaTA6IFtJVEhSRUFEXQp1aGNpMDogTGVnU3VwID0gMHgyZjAwCnVzYnVz MDogPEludGVsIDgyODAxSSAoSUNIOSkgVVNCIGNvbnRyb2xsZXI+IG9uIHVoY2kwCnVoY2kxOiA8 SW50ZWwgODI4MDFJIChJQ0g5KSBVU0IgY29udHJvbGxlcj4gcG9ydCAweDUwYTAtMHg1MGJmIGly cSAxNyBhdCBkZXZpY2UgMjYuMSBvbiBwY2kwCmlvYXBpYzA6IHJvdXRpbmcgaW50cGluIDE3IChQ Q0kgSVJRIDE3KSB0byBsYXBpYyAwIHZlY3RvciA1MQp1aGNpMTogW01QU0FGRV0KdWhjaTE6IFtJ VEhSRUFEXQp1aGNpMTogTGVnU3VwID0gMHgyZjAwCnVzYnVzMTogPEludGVsIDgyODAxSSAoSUNI OSkgVVNCIGNvbnRyb2xsZXI+IG9uIHVoY2kxCmVoY2kwOiA8SW50ZWwgODI4MDFJIChJQ0g5KSBV U0IgMi4wIGNvbnRyb2xsZXI+IG1lbSAweGQ4NTA0YzAwLTB4ZDg1MDRmZmYgaXJxIDE4IGF0IGRl dmljZSAyNi43IG9uIHBjaTAKaW9hcGljMDogcm91dGluZyBpbnRwaW4gMTggKFBDSSBJUlEgMTgp IHRvIGxhcGljIDAgdmVjdG9yIDUyCmVoY2kwOiBbTVBTQUZFXQplaGNpMDogW0lUSFJFQURdCnVz YnVzMjogRUhDSSB2ZXJzaW9uIDEuMAp1c2J1czI6IDxJbnRlbCA4MjgwMUkgKElDSDkpIFVTQiAy LjAgY29udHJvbGxlcj4gb24gZWhjaTAKcGNpMDogPG11bHRpbWVkaWEsIEhEQT4gYXQgZGV2aWNl IDI3LjAgKG5vIGRyaXZlciBhdHRhY2hlZCkKcGNpYjE6IDxBQ1BJIFBDSS1QQ0kgYnJpZGdlPiBh dCBkZXZpY2UgMjguMCBvbiBwY2kwCnBjaWIxOiAgIGRvbWFpbiAgICAgICAgICAgIDAKcGNpYjE6 ICAgc2Vjb25kYXJ5IGJ1cyAgICAgMQpwY2liMTogICBzdWJvcmRpbmF0ZSBidXMgICAxCnBjaWIx OiAgIEkvTyBkZWNvZGUgICAgICAgIDB4NDAwMC0weDRmZmYKcGNpYjE6ICAgbWVtb3J5IGRlY29k ZSAgICAgMHhkNzUwMDAwMC0weGQ4NGZmZmZmCnBjaWIxOiAgIHByZWZldGNoZWQgZGVjb2RlIDB4 ZDA0MDAwMDAtMHhkMTNmZmZmZgpwY2kxOiA8QUNQSSBQQ0kgYnVzPiBvbiBwY2liMQpwY2kxOiBk b21haW49MCwgcGh5c2ljYWwgYnVzPTEKcGNpYjI6IDxBQ1BJIFBDSS1QQ0kgYnJpZGdlPiBhdCBk ZXZpY2UgMjguMiBvbiBwY2kwCnBjaWIyOiAgIGRvbWFpbiAgICAgICAgICAgIDAKcGNpYjI6ICAg c2Vjb25kYXJ5IGJ1cyAgICAgMgpwY2liMjogICBzdWJvcmRpbmF0ZSBidXMgICAyCnBjaWIyOiAg IEkvTyBkZWNvZGUgICAgICAgIDB4MzAwMC0weDNmZmYKcGNpYjI6ICAgbWVtb3J5IGRlY29kZSAg ICAgMHhkNjUwMDAwMC0weGQ3NGZmZmZmCnBjaWIyOiAgIHByZWZldGNoZWQgZGVjb2RlIDB4ZDE0 MDAwMDAtMHhkMjNmZmZmZgpwY2kyOiA8QUNQSSBQQ0kgYnVzPiBvbiBwY2liMgpwY2kyOiBkb21h aW49MCwgcGh5c2ljYWwgYnVzPTIKZm91bmQtPgl2ZW5kb3I9MHgxNjhjLCBkZXY9MHgwMDJiLCBy ZXZpZD0weDAxCglkb21haW49MCwgYnVzPTIsIHNsb3Q9MCwgZnVuYz0wCgljbGFzcz0wMi04MC0w MCwgaGRydHlwZT0weDAwLCBtZmRldj0wCgljbWRyZWc9MHgwMDA3LCBzdGF0cmVnPTB4MDAxMCwg Y2FjaGVsbnN6PTAgKGR3b3JkcykKCWxhdHRpbWVyPTB4MDAgKDAgbnMpLCBtaW5nbnQ9MHgwMCAo MCBucyksIG1heGxhdD0weDAwICgwIG5zKQoJaW50cGluPWEsIGlycT0xMQoJcG93ZXJzcGVjIDMg IHN1cHBvcnRzIEQwIEQxIEQzICBjdXJyZW50IEQwCglNU0kgc3VwcG9ydHMgMSBtZXNzYWdlCglt YXBbMTBdOiB0eXBlIE1lbW9yeSwgcmFuZ2UgNjQsIGJhc2UgMHhkNjUwMDAwMCwgc2l6ZSAxNiwg ZW5hYmxlZApwY2liMjogcmVxdWVzdGVkIG1lbW9yeSByYW5nZSAweGQ2NTAwMDAwLTB4ZDY1MGZm ZmY6IGdvb2QKcGNpYjI6IG1hdGNoZWQgZW50cnkgZm9yIDIuMC5JTlRBCnBjaWIyOiBzbG90IDAg SU5UQSBoYXJkd2lyZWQgdG8gSVJRIDE4CnBjaTI6IDxuZXR3b3JrPiBhdCBkZXZpY2UgMC4wIChu byBkcml2ZXIgYXR0YWNoZWQpCnBjaWIzOiA8QUNQSSBQQ0ktUENJIGJyaWRnZT4gYXQgZGV2aWNl IDI4LjMgb24gcGNpMApwY2liMzogICBkb21haW4gICAgICAgICAgICAwCnBjaWIzOiAgIHNlY29u ZGFyeSBidXMgICAgIDMKcGNpYjM6ICAgc3Vib3JkaW5hdGUgYnVzICAgMwpwY2liMzogICBJL08g ZGVjb2RlICAgICAgICAweDIwMDAtMHgyZmZmCnBjaWIzOiAgIG1lbW9yeSBkZWNvZGUgICAgIDB4 ZDU1MDAwMDAtMHhkNjRmZmZmZgpwY2liMzogICBwcmVmZXRjaGVkIGRlY29kZSAweGQyNDAwMDAw LTB4ZDMzZmZmZmYKcGNpMzogPEFDUEkgUENJIGJ1cz4gb24gcGNpYjMKcGNpMzogZG9tYWluPTAs IHBoeXNpY2FsIGJ1cz0zCmZvdW5kLT4JdmVuZG9yPTB4MTBlYywgZGV2PTB4ODEzNiwgcmV2aWQ9 MHgwMgoJZG9tYWluPTAsIGJ1cz0zLCBzbG90PTAsIGZ1bmM9MAoJY2xhc3M9MDItMDAtMDAsIGhk cnR5cGU9MHgwMCwgbWZkZXY9MAoJY21kcmVnPTB4MDAwNywgc3RhdHJlZz0weDAwMTAsIGNhY2hl bG5zej0wIChkd29yZHMpCglsYXR0aW1lcj0weDAwICgwIG5zKSwgbWluZ250PTB4MDAgKDAgbnMp LCBtYXhsYXQ9MHgwMCAoMCBucykKCWludHBpbj1hLCBpcnE9MTEKCXBvd2Vyc3BlYyAzICBzdXBw b3J0cyBEMCBEMSBEMiBEMyAgY3VycmVudCBEMAoJTVNJIHN1cHBvcnRzIDEgbWVzc2FnZSwgNjQg Yml0CglNU0ktWCBzdXBwb3J0cyAyIG1lc3NhZ2VzIGluIG1hcCAweDIwCgltYXBbMTBdOiB0eXBl IEkvTyBQb3J0LCByYW5nZSAzMiwgYmFzZSAweDIwMDAsIHNpemUgIDgsIGVuYWJsZWQKcGNpYjM6 IHJlcXVlc3RlZCBJL08gcmFuZ2UgMHgyMDAwLTB4MjBmZjogaW4gcmFuZ2UKCW1hcFsxOF06IHR5 cGUgUHJlZmV0Y2hhYmxlIE1lbW9yeSwgcmFuZ2UgNjQsIGJhc2UgMHhkMjQxMDAwMCwgc2l6ZSAx MiwgZW5hYmxlZApwY2liMzogcmVxdWVzdGVkIG1lbW9yeSByYW5nZSAweGQyNDEwMDAwLTB4ZDI0 MTBmZmY6IGdvb2QKCW1hcFsyMF06IHR5cGUgUHJlZmV0Y2hhYmxlIE1lbW9yeSwgcmFuZ2UgNjQs IGJhc2UgMHhkMjQwMDAwMCwgc2l6ZSAxNiwgZW5hYmxlZApwY2liMzogcmVxdWVzdGVkIG1lbW9y eSByYW5nZSAweGQyNDAwMDAwLTB4ZDI0MGZmZmY6IGdvb2QKcGNpYjM6IG1hdGNoZWQgZW50cnkg Zm9yIDMuMC5JTlRBCnBjaWIzOiBzbG90IDAgSU5UQSBoYXJkd2lyZWQgdG8gSVJRIDE5CnJlMDog PFJlYWxUZWsgODEwMUUvODEwMkUvODEwMkVMIFBDSWUgMTAvMTAwYmFzZVRYPiBwb3J0IDB4MjAw MC0weDIwZmYgbWVtIDB4ZDI0MTAwMDAtMHhkMjQxMGZmZiwweGQyNDAwMDAwLTB4ZDI0MGZmZmYg aXJxIDE5IGF0IGRldmljZSAwLjAgb24gcGNpMwpyZTA6IFJlc2VydmVkIDB4MTAwMCBieXRlcyBm b3IgcmlkIDB4MTggdHlwZSAzIGF0IDB4ZDI0MTAwMDAKcmUwOiBNU0kgY291bnQgOiAxCnJlMDog YXR0ZW1wdGluZyB0byBhbGxvY2F0ZSAxIE1TSSB2ZWN0b3JzICgxIHN1cHBvcnRlZCkKbXNpOiBy b3V0aW5nIE1TSSBJUlEgMjU3IHRvIGxvY2FsIEFQSUMgMCB2ZWN0b3IgNTMKcmUwOiB1c2luZyBJ UlEgMjU3IGZvciBNU0kKcmUwOiBVc2luZyAxIE1TSSBtZXNzYWdlcwpyZTA6IENoaXAgcmV2LiAw eDI0ODAwMDAwCnJlMDogTUFDIHJldi4gMHgwMDQwMDAwMAptaWlidXMwOiA8TUlJIGJ1cz4gb24g cmUwCnJscGh5MDogPFJUTDgyMDFMIDEwLzEwMCBtZWRpYSBpbnRlcmZhY2U+IFBIWSAxIG9uIG1p aWJ1czAKcmxwaHkwOiAgMTBiYXNlVCwgMTBiYXNlVC1GRFgsIDEwMGJhc2VUWCwgMTAwYmFzZVRY LUZEWCwgYXV0bwpyZTA6IGJwZiBhdHRhY2hlZApyZTA6IEV0aGVybmV0IGFkZHJlc3M6IDAwOjIz OjVhOmEyOmJkOjU0CnJlMDogW01QU0FGRV0KcmUwOiBbRklMVEVSXQpwY2liNDogPEFDUEkgUENJ LVBDSSBicmlkZ2U+IGF0IGRldmljZSAyOC41IG9uIHBjaTAKcGNpYjQ6ICAgZG9tYWluICAgICAg ICAgICAgMApwY2liNDogICBzZWNvbmRhcnkgYnVzICAgICA0CnBjaWI0OiAgIHN1Ym9yZGluYXRl IGJ1cyAgIDYKcGNpYjQ6ICAgSS9PIGRlY29kZSAgICAgICAgMHgxMDAwLTB4MWZmZgpwY2liNDog ICBtZW1vcnkgZGVjb2RlICAgICAweGQ0NTAwMDAwLTB4ZDU0ZmZmZmYKcGNpYjQ6ICAgcHJlZmV0 Y2hlZCBkZWNvZGUgMHhkMzQwMDAwMC0weGQ0M2ZmZmZmCnBjaTQ6IDxBQ1BJIFBDSSBidXM+IG9u IHBjaWI0CnBjaTQ6IGRvbWFpbj0wLCBwaHlzaWNhbCBidXM9NAp1aGNpMjogPEludGVsIDgyODAx SSAoSUNIOSkgVVNCIGNvbnRyb2xsZXI+IHBvcnQgMHg1MDgwLTB4NTA5ZiBpcnEgMjAgYXQgZGV2 aWNlIDI5LjAgb24gcGNpMAppb2FwaWMwOiByb3V0aW5nIGludHBpbiAyMCAoUENJIElSUSAyMCkg dG8gbGFwaWMgMCB2ZWN0b3IgNTQKdWhjaTI6IFtNUFNBRkVdCnVoY2kyOiBbSVRIUkVBRF0KdWhj aTI6IExlZ1N1cCA9IDB4MmYwMAp1c2J1czM6IDxJbnRlbCA4MjgwMUkgKElDSDkpIFVTQiBjb250 cm9sbGVyPiBvbiB1aGNpMgp1aGNpMzogPEludGVsIDgyODAxSSAoSUNIOSkgVVNCIGNvbnRyb2xs ZXI+IHBvcnQgMHg1MDYwLTB4NTA3ZiBpcnEgMjIgYXQgZGV2aWNlIDI5LjEgb24gcGNpMAppb2Fw aWMwOiByb3V0aW5nIGludHBpbiAyMiAoUENJIElSUSAyMikgdG8gbGFwaWMgMCB2ZWN0b3IgNTUK dWhjaTM6IFtNUFNBRkVdCnVoY2kzOiBbSVRIUkVBRF0KdWhjaTM6IExlZ1N1cCA9IDB4MmYwMAp1 c2J1czQ6IDxJbnRlbCA4MjgwMUkgKElDSDkpIFVTQiBjb250cm9sbGVyPiBvbiB1aGNpMwp1aGNp NDogPEludGVsIDgyODAxSSAoSUNIOSkgVVNCIGNvbnRyb2xsZXI+IHBvcnQgMHg1MDQwLTB4NTA1 ZiBpcnEgMTggYXQgZGV2aWNlIDI5LjIgb24gcGNpMAp1aGNpNDogW01QU0FGRV0KdWhjaTQ6IFtJ VEhSRUFEXQp1aGNpNDogTGVnU3VwID0gMHgyZjAwCnVzYnVzNTogPEludGVsIDgyODAxSSAoSUNI OSkgVVNCIGNvbnRyb2xsZXI+IG9uIHVoY2k0CmVoY2kxOiA8SW50ZWwgODI4MDFJIChJQ0g5KSBV U0IgMi4wIGNvbnRyb2xsZXI+IG1lbSAweGQ4NTA0ODAwLTB4ZDg1MDRiZmYgaXJxIDIwIGF0IGRl dmljZSAyOS43IG9uIHBjaTAKZWhjaTE6IFtNUFNBRkVdCmVoY2kxOiBbSVRIUkVBRF0KdXNidXM2 OiBFSENJIHZlcnNpb24gMS4wCnVzYnVzNjogPEludGVsIDgyODAxSSAoSUNIOSkgVVNCIDIuMCBj b250cm9sbGVyPiBvbiBlaGNpMQpwY2liNTogPEFDUEkgUENJLVBDSSBicmlkZ2U+IGF0IGRldmlj ZSAzMC4wIG9uIHBjaTAKcGNpYjU6ICAgZG9tYWluICAgICAgICAgICAgMApwY2liNTogICBzZWNv bmRhcnkgYnVzICAgICA3CnBjaWI1OiAgIHN1Ym9yZGluYXRlIGJ1cyAgIDcKcGNpYjU6ICAgSS9P IGRlY29kZSAgICAgICAgMHhmMDAwLTB4ZmZmCnBjaWI1OiAgIG5vIHByZWZldGNoZWQgZGVjb2Rl CnBjaWI1OiAgIFN1YnRyYWN0aXZlbHkgZGVjb2RlZCBicmlkZ2UuCnBjaTc6IDxBQ1BJIFBDSSBi dXM+IG9uIHBjaWI1CnBjaTc6IGRvbWFpbj0wLCBwaHlzaWNhbCBidXM9Nwppc2FiMDogPFBDSS1J U0EgYnJpZGdlPiBhdCBkZXZpY2UgMzEuMCBvbiBwY2kwCmlzYTA6IDxJU0EgYnVzPiBvbiBpc2Fi MAphdGFwY2kwOiA8SW50ZWwgKElEPTI5Mjk4MDg2KSBBSENJIGNvbnRyb2xsZXI+IHBvcnQgMHg1 MGU4LTB4NTBlZiwweDUwZmMtMHg1MGZmLDB4NTBlMC0weDUwZTcsMHg1MGY4LTB4NTBmYiwweDUw MjAtMHg1MDNmIG1lbSAweGQ4NTA0MDAwLTB4ZDg1MDQ3ZmYgaXJxIDIxIGF0IGRldmljZSAzMS4y IG9uIHBjaTAKYXRhcGNpMDogUmVzZXJ2ZWQgMHgyMCBieXRlcyBmb3IgcmlkIDB4MjAgdHlwZSA0 IGF0IDB4NTAyMAphdGFwY2kwOiBSZXNlcnZlZCAweDgwMCBieXRlcyBmb3IgcmlkIDB4MjQgdHlw ZSAzIGF0IDB4ZDg1MDQwMDAKaW9hcGljMDogcm91dGluZyBpbnRwaW4gMjEgKFBDSSBJUlEgMjEp IHRvIGxhcGljIDAgdmVjdG9yIDU2CmF0YXBjaTA6IFtNUFNBRkVdCmF0YXBjaTA6IFtJVEhSRUFE XQphdGFwY2kwOiBBSENJIHYxLjIwIGNvbnRyb2xsZXIgd2l0aCA0IDNHYnBzIHBvcnRzLCBQTSBz dXBwb3J0ZWQKYXRhcGNpMDogQ2FwczogNjRiaXQgTkNRIFNOVEYgU1MgQUxQIEFMIENMTyAzR2Jw cyBQTSBQTUQgU1NDIFBTQyAzMmNtZCBDQ0MgRU0gZVNBVEEgNHBvcnRzCmF0YTI6IDxBVEEgY2hh bm5lbCAwPiBvbiBhdGFwY2kwCmF0YTI6IEFIQ0kgcmVzZXQuLi4KYXRhMjogaGFyZHdhcmUgcmVz ZXQgLi4uCmF0YTI6IFNBVEEgY29ubmVjdCB0aW1lPTBtcyBzdGF0dXM9MDAwMDAxMjMKYXRhMjog cmVhZHkgd2FpdCB0aW1lPTNtcwphdGEyOiBzb2Z0d2FyZSByZXNldCBwb3J0IDE1Li4uCmF0YTI6 IHJlYWR5IHdhaXQgdGltZT0wbXMKYXRhMjogU0lHTkFUVVJFOiAwMDAwMDEwMQphdGEyOiBBSENJ IHJlc2V0IGRvbmU6IGRldmljZXM9MDAwMDAwMDEKYXRhMjogW01QU0FGRV0KYXRhMjogW0lUSFJF QURdCmF0YTM6IDxBVEEgY2hhbm5lbCA0PiBvbiBhdGFwY2kwCmF0YTM6IEFIQ0kgcmVzZXQuLi4K YXRhMzogaGFyZHdhcmUgcmVzZXQgLi4uCmF0YTM6IFNBVEEgY29ubmVjdCB0aW1lPTEwbXMgc3Rh dHVzPTAwMDAwMTEzCmF0YTM6IHJlYWR5IHdhaXQgdGltZT0wbXMKYXRhMzogc29mdHdhcmUgcmVz ZXQgcG9ydCAxNS4uLgphdGEzOiByZWFkeSB3YWl0IHRpbWU9MG1zCmF0YTM6IFNJR05BVFVSRTog ZWIxNDAxMDEKYXRhMzogQUhDSSByZXNldCBkb25lOiBkZXZpY2VzPTAwMDEwMDAwCmF0YTM6IFtN UFNBRkVdCmF0YTM6IFtJVEhSRUFEXQphdGE0OiA8QVRBIGNoYW5uZWwgNT4gb24gYXRhcGNpMAph dGE0OiBBSENJIHJlc2V0Li4uCmF0YTQ6IGhhcmR3YXJlIHJlc2V0IC4uLgphdGE0OiBTQVRBIGNv bm5lY3QgdGltZW91dCBzdGF0dXM9MDAwMDAwMDAKYXRhNDogQUhDSSByZXNldCBkb25lOiBwaHkg cmVzZXQgZm91bmQgbm8gZGV2aWNlCmF0YTQ6IFtNUFNBRkVdCmF0YTQ6IFtJVEhSRUFEXQppY2hz bWIwOiA8SW50ZWwgODI4MDFJIChJQ0g5KSBTTUJ1cyBjb250cm9sbGVyPiBwb3J0IDB4NTAwMC0w eDUwMWYgbWVtIDB4ZDg1MDUwMDAtMHhkODUwNTBmZiBpcnEgMTggYXQgZGV2aWNlIDMxLjMgb24g cGNpMAppY2hzbWIwOiBSZXNlcnZlZCAweDIwIGJ5dGVzIGZvciByaWQgMHgyMCB0eXBlIDQgYXQg MHg1MDAwCmljaHNtYjA6IFtNUFNBRkVdCmljaHNtYjA6IFtJVEhSRUFEXQpzbWJ1czA6IDxTeXN0 ZW0gTWFuYWdlbWVudCBCdXM+IG9uIGljaHNtYjAKYWNwaV90ejA6IDxUaGVybWFsIFpvbmU+IG9u IGFjcGkwCkFDUEkgRXJyb3I6IE5vIGhhbmRsZXIgZm9yIFJlZ2lvbiBbRVJBTV0gKDB4ZmZmZmZm MDAwMTU5NTk4MCkgW0VtYmVkZGVkQ29udHJvbF0gMjAwOTA1MjEgZXZyZWdpb24tNDMwCkFDUEkg RXJyb3I6IFJlZ2lvbiBFbWJlZGRlZENvbnRyb2woMykgaGFzIG5vIGhhbmRsZXIgMjAwOTA1MjEg ZXhmbGRpby0zODIKQUNQSSBFcnJvciAocHNwYXJzZS0wNjMzKTogTWV0aG9kIHBhcnNlL2V4ZWN1 dGlvbiBmYWlsZWQgW1xcX1RaXy5USFJNLl9BQzBdIChOb2RlIDB4ZmZmZmZmMDAwMTU5ZTNlMCks IEFFX05PVF9FWElTVAphdHJ0YzA6IDxBVCByZWFsdGltZSBjbG9jaz4gcG9ydCAweDcwLTB4Nzcg b24gYWNwaTAKYXRydGMwOiBXYXJuaW5nOiBDb3VsZG4ndCBtYXAgSS9PLgphdHJ0YzA6IHJlZ2lz dGVyZWQgYXMgYSB0aW1lLW9mLWRheSBjbG9jayAocmVzb2x1dGlvbiAxMDAwMDAwdXMpCmF0a2Jk YzA6IDxLZXlib2FyZCBjb250cm9sbGVyIChpODA0Mik+IHBvcnQgMHg2MCwweDY0IGlycSAxIG9u IGFjcGkwCmF0a2JkMDogPEFUIEtleWJvYXJkPiBpcnEgMSBvbiBhdGtiZGMwCmF0a2JkOiB0aGUg Y3VycmVudCBrYmQgY29udHJvbGxlciBjb21tYW5kIGJ5dGUgMDA2NwphdGtiZDoga2V5Ym9hcmQg SUQgMHg0MWFiICgyKQprYmQwIGF0IGF0a2JkMAprYmQwOiBhdGtiZDAsIEFUIDEwMS8xMDIgKDIp LCBjb25maWc6MHgwLCBmbGFnczoweDNkMDAwMAppb2FwaWMwOiByb3V0aW5nIGludHBpbiAxIChJ U0EgSVJRIDEpIHRvIGxhcGljIDAgdmVjdG9yIDU3CmF0a2JkMDogW0dJQU5ULUxPQ0tFRF0KYXRr YmQwOiBbSVRIUkVBRF0KcHNtMDogdW5hYmxlIHRvIGFsbG9jYXRlIElSUQpwc21jcG5wMDogPFBT LzIgbW91c2UgcG9ydD4gaXJxIDEyIG9uIGFjcGkwCnBzbTA6IGN1cnJlbnQgY29tbWFuZCBieXRl OjAwNjcKcHNtMDogPFBTLzIgTW91c2U+IGlycSAxMiBvbiBhdGtiZGMwCmlvYXBpYzA6IHJvdXRp bmcgaW50cGluIDEyIChJU0EgSVJRIDEyKSB0byBsYXBpYyAwIHZlY3RvciA1OApwc20wOiBbR0lB TlQtTE9DS0VEXQpwc20wOiBbSVRIUkVBRF0KcHNtMDogbW9kZWwgR2VuZXJpYyBQUy8yIG1vdXNl LCBkZXZpY2UgSUQgMC0wMCwgMiBidXR0b25zCnBzbTA6IGNvbmZpZzowMDAwMDAwMCwgZmxhZ3M6 MDAwMDAwMDgsIHBhY2tldCBzaXplOjMKcHNtMDogc3luY21hc2s6YzAsIHN5bmNiaXRzOjAwCmNw dTA6IDxBQ1BJIENQVT4gb24gYWNwaTAKQUNQSTogU1NEVCAweGI5ZTZlYzk4IDAwMjIzICh2MSAg UG1SZWYgIENwdTBJc3QgMDAwMDMwMDAgSU5UTCAyMDA1MTExNykKQUNQSTogU1NEVCAweGI5ZTZj NjE4IDAwNUIzICh2MSAgUG1SZWYgIENwdTBDc3QgMDAwMDMwMDEgSU5UTCAyMDA1MTExNykKZXN0 MDogPEVuaGFuY2VkIFNwZWVkU3RlcCBGcmVxdWVuY3kgQ29udHJvbD4gb24gY3B1MAplc3QwOiBJ bnZhbGlkIGlkMTYgKHNldCwgY3VyKSA9ICgyMDczLCAxODk3OSkKZXN0MDogQ2FuJ3QgY2hlY2sg ZnJlcSAxNjAwLCBpdCBtYXkgYmUgaW52YWxpZAplc3QwOiBJbnZhbGlkIGlkMTYgKHNldCwgY3Vy KSA9ICgxNTUzLCAxODk3OSkKZXN0MDogQ2FuJ3QgY2hlY2sgZnJlcSAxMjAwLCBpdCBtYXkgYmUg aW52YWxpZApwNHRjYzA6IDxDUFUgRnJlcXVlbmN5IFRoZXJtYWwgQ29udHJvbD4gb24gY3B1MApj cHUxOiA8QUNQSSBDUFU+IG9uIGFjcGkwCkFDUEk6IFNTRFQgMHhiOWU2ZGUxOCAwMDFDRiAodjEg IFBtUmVmICAgIEFwSXN0IDAwMDAzMDAwIElOVEwgMjAwNTExMTcpCkFDUEk6IFNTRFQgMHhiOWU2 ZWYxOCAwMDA4RCAodjEgIFBtUmVmICAgIEFwQ3N0IDAwMDAzMDAwIElOVEwgMjAwNTExMTcpCmVz dDE6IDxFbmhhbmNlZCBTcGVlZFN0ZXAgRnJlcXVlbmN5IENvbnRyb2w+IG9uIGNwdTEKZXN0MTog SW52YWxpZCBpZDE2IChzZXQsIGN1cikgPSAoMjA3MywgMTg5NzkpCmVzdDE6IENhbid0IGNoZWNr IGZyZXEgMTYwMCwgaXQgbWF5IGJlIGludmFsaWQKZXN0MTogSW52YWxpZCBpZDE2IChzZXQsIGN1 cikgPSAoMTU1MywgMTg5NzkpCmVzdDE6IENhbid0IGNoZWNrIGZyZXEgMTIwMCwgaXQgbWF5IGJl IGludmFsaWQKcDR0Y2MxOiA8Q1BVIEZyZXF1ZW5jeSBUaGVybWFsIENvbnRyb2w+IG9uIGNwdTEK YWNwaV9lYzA6IDxFbWJlZGRlZCBDb250cm9sbGVyOiBHUEUgMHgxNz4gcG9ydCAweDYyLDB4NjYg b24gYWNwaTAKaXNhYjA6IGZvdW5kIElDSDkgb3IgZXF1aXZhbGVudCBjaGlwc2V0OiBJbnRlbCBJ Q0g5TSB3YXRjaGRvZyB0aW1lcgppc2FfcHJvYmVfY2hpbGRyZW46IGRpc2FibGluZyBQblAgZGV2 aWNlcwppY2h3ZDA6IDxJbnRlbCBJQ0g5TSB3YXRjaGRvZyB0aW1lcj4gb24gaXNhMAppc2FiMDog Zm91bmQgSUNIOSBvciBlcXVpdmFsZW50IGNoaXBzZXQ6IEludGVsIElDSDlNIHdhdGNoZG9nIHRp bWVyCmljaHdkMDogSW50ZWwgSUNIOU0gd2F0Y2hkb2cgdGltZXIgKElDSDkgb3IgZXF1aXZhbGVu dCkKaWNod2QwOiB0aW1lciBkaXNhYmxlZAphdGtiZGM6IGF0a2JkYzAgYWxyZWFkeSBleGlzdHM7 IHNraXBwaW5nIGl0CmF0cnRjOiBhdHJ0YzAgYWxyZWFkeSBleGlzdHM7IHNraXBwaW5nIGl0CnNj OiBzYzAgYWxyZWFkeSBleGlzdHM7IHNraXBwaW5nIGl0CmlzYV9wcm9iZV9jaGlsZHJlbjogcHJv YmluZyBub24tUG5QIGRldmljZXMKb3JtMDogPElTQSBPcHRpb24gUk9NPiBhdCBpb21lbSAweGMw MDAwLTB4Y2Y3ZmYgb24gaXNhMApzYzA6IDxTeXN0ZW0gY29uc29sZT4gYXQgZmxhZ3MgMHgxMDAg b24gaXNhMApzYzA6IFZHQSA8MTYgdmlydHVhbCBjb25zb2xlcywgZmxhZ3M9MHgzMDA+CnNjMDog ZmIwLCBrYmQxLCB0ZXJtaW5hbCBlbXVsYXRvcjogc2N0ZWtlbiAodGVrZW4gdGVybWluYWwpCnZn YTA6IDxHZW5lcmljIElTQSBWR0E+IGF0IHBvcnQgMHgzYzAtMHgzZGYgaW9tZW0gMHhhMDAwMC0w eGJmZmZmIG9uIGlzYTAKZmRjMCBmYWlsZWQgdG8gcHJvYmUgYXQgcG9ydCAweDNmMCBpcnEgNiBk cnEgMiBvbiBpc2EwCnBwYzAgZmFpbGVkIHRvIHByb2JlIGF0IGlycSA3IG9uIGlzYTAKdWFydDAg ZmFpbGVkIHRvIHByb2JlIGF0IHBvcnQgMHgzZjggaXJxIDQgb24gaXNhMAp1YXJ0MSBmYWlsZWQg dG8gcHJvYmUgYXQgcG9ydCAweDJmOCBpcnEgMyBvbiBpc2EwCmlzYV9wcm9iZV9jaGlsZHJlbjog cHJvYmluZyBQblAgZGV2aWNlcwpEZXZpY2UgY29uZmlndXJhdGlvbiBmaW5pc2hlZC4KUmVkdWNp bmcga2Vybi5tYXh2bm9kZXMgMjUxOTM5IC0+IDEwMDAwMApwcm9jZnMgcmVnaXN0ZXJlZApsYXBp YzogRGl2aXNvciAyLCBGcmVxdWVuY3kgOTk3NTA1NTcgaHoKVGltZWNvdW50ZXIgIlRTQyIgZnJl cXVlbmN5IDIwOTQ3NjE2NTUgSHogcXVhbGl0eSAtMTAwClRpbWVjb3VudGVycyB0aWNrIGV2ZXJ5 IDEwLjAwMCBtc2VjCmxvMDogYnBmIGF0dGFjaGVkCmF0YTI6IElkZW50aWZ5aW5nIGRldmljZXM6 IDAwMDAwMDAxCmF0YTI6IE5ldyBkZXZpY2VzOiAwMDAwMDAwMQp1c2J1czA6IDEyTWJwcyBGdWxs IFNwZWVkIFVTQiB2MS4wCnVzYnVzMTogMTJNYnBzIEZ1bGwgU3BlZWQgVVNCIHYxLjAKdXNidXMy OiA0ODBNYnBzIEhpZ2ggU3BlZWQgVVNCIHYyLjAKdXNidXMzOiAxMk1icHMgRnVsbCBTcGVlZCBV U0IgdjEuMAp1c2J1czQ6IDEyTWJwcyBGdWxsIFNwZWVkIFVTQiB2MS4wCnVzYnVzNTogMTJNYnBz IEZ1bGwgU3BlZWQgVVNCIHYxLjAKdXNidXM2OiA0ODBNYnBzIEhpZ2ggU3BlZWQgVVNCIHYyLjAK YXRhMi1tYXN0ZXI6IHBpbz1QSU80IHdkbWE9V0RNQTIgdWRtYT1VRE1BMTAwIGNhYmxlPTQwIHdp cmUKYmF0dGVyeTA6IGJhdHRlcnkgaW5pdGlhbGl6YXRpb24gc3RhcnRhZDQ6IHNldHRpbmcgVURN QTEwMAoKYWNwaV9hY2FkMDogYWNsaW5lIGluaXRpYWxpemF0aW9uIHN0YXJ0CmFkNDogNDc2OTQw TUIgPFNlYWdhdGUgU1Q5NTAwMzI1QVMgMDAwM0hQTTE+IGF0IGF0YTItbWFzdGVyIFVETUExMDAg U0FUQSAzR2IvcwphZDQ6IDk3Njc3MzE2OCBzZWN0b3JzIFs5NjkwMjFDLzE2SC82M1NdIDE2IHNl Y3RvcnMvaW50ZXJydXB0IDEgZGVwdGggcXVldWUKR0VPTTogbmV3IGRpc2sgYWQ0CmFjcGlfdHow OiBfQUMwOiB0ZW1wZXJhdHVyZSA2Ny4wID49IHNldHBvaW50IDY3LjAKdWdlbjAuMTogPEludGVs PiBhdCB1c2J1czAKdWh1YjA6IDxJbnRlbCBVSENJIHJvb3QgSFVCLCBjbGFzcyA5LzAsIHJldiAx LjAwLzEuMDAsIGFkZHIgMT4gb24gdXNidXMwCnVnZW4xLjE6IDxJbnRlbD4gYXQgdXNidXMxCnVo dWIxOiA8SW50ZWwgVUhDSSByb290IEhVQiwgY2xhc3MgOS8wLCByZXYgMS4wMC8xLjAwLCBhZGRy IDE+IG9uIHVzYnVzMQp1Z2VuMi4xOiA8SW50ZWw+IGF0IHVzYnVzMgp1aHViMjogPEludGVsIEVI Q0kgcm9vdCBIVUIsIGNsYXNzIDkvMCwgcmV2IDIuMDAvMS4wMCwgYWRkciAxPiBvbiB1c2J1czIK dWdlbjMuMTogPEludGVsPiBhdCB1c2J1czMKdWh1YjM6IDxJbnRlbCBVSENJIHJvb3QgSFVCLCBj bGFzcyA5LzAsIHJldiAxLjAwLzEuMDAsIGFkZHIgMT4gb24gdXNidXMzCnVnZW40LjE6IDxJbnRl bD4gYXQgdXNidXM0CnVodWI0OiA8SW50ZWwgVUhDSSByb290IEhVQiwgY2xhc3MgOS8wLCByZXYg MS4wMC8xLjAwLCBhZGRyIDE+IG9uIHVzYnVzNAp1Z2VuNS4xOiA8SW50ZWw+IGF0IHVzYnVzNQp1 aHViNTogPEludGVsIFVIQ0kgcm9vdCBIVUIsIGNsYXNzIDkvMCwgcmV2IDEuMDAvMS4wMCwgYWRk ciAxPiBvbiB1c2J1czUKdWdlbjYuMTogPEludGVsPiBhdCB1c2J1czYKdWh1YjY6IDxJbnRlbCBF SENJIHJvb3QgSFVCLCBjbGFzcyA5LzAsIHJldiAyLjAwLzEuMDAsIGFkZHIgMT4gb24gdXNidXM2 CmFjcGlfdHowOiBzd2l0Y2hlZCBmcm9tIE5PTkUgdG8gX0FDMDogNjcuMEMKc3lzdGVtIHBvd2Vy IHByb2ZpbGUgY2hhbmdlZCB0byAnZWNvbm9teScKYWNwaV9hY2FkMDogT2ZmIExpbmUKYWNwaV9h Y2FkMDogYWNsaW5lIGluaXRpYWxpemF0aW9uIGRvbmUsIHRyaWVkIDEgdGltZXMKYWQ0OiBJbnRl bCBjaGVjazEgZmFpbGVkCmFkNDogQWRhcHRlYyBjaGVjazEgZmFpbGVkCmFkNDogTFNJICh2Mykg Y2hlY2sxIGZhaWxlZAphZDQ6IExTSSAodjIpIGNoZWNrMSBmYWlsZWQKYWQ0OiBGcmVlQlNEIGNo ZWNrMSBmYWlsZWQKYXRhMzogSWRlbnRpZnlpbmcgZGV2aWNlczogMDAwMTAwMDAKYXRhMzogTmV3 IGRldmljZXM6IDAwMDEwMDAwCmF0YTMtbWFzdGVyOiBwaW89UElPNCB3ZG1hPVdETUEyIHVkbWE9 VURNQTEwMCBjYWJsZT00MCB3aXJlCmFjZDA6IHNldHRpbmcgVURNQTEwMAphdGEzOiBkZXZpY2Vf cmVzZXQgdGltZW91dD05ODB1cwphY2QwOiA8SEwtRFQtU1QgRFZEUkFNIEdUMjBML0RDMDM+IERW RFIgZHJpdmUgYXQgYXRhMyBhcyBtYXN0ZXIKYWNkMDogcmVhZCA0MTM0S0IvcyAoNDEzNEtCL3Mp IHdyaXRlIDQxMzRLQi9zICg0MTM0S0IvcyksIDEwMjRLQiBidWZmZXIsIFVETUExMDAgU0FUQSAx LjVHYi9zCmFjZDA6IFJlYWRzOiBDRFIsIENEUlcsIENEREEgc3RyZWFtLCBEVkRST00sIERWRFIs IERWRFJBTSwgcGFja2V0CmFjZDA6IFdyaXRlczogQ0RSLCBDRFJXLCBEVkRSLCBEVkRSQU0sIHRl c3Qgd3JpdGUsIGJ1cm5wcm9vZgphY2QwOiBBdWRpbzogcGxheSwgMjU2IHZvbHVtZSBsZXZlbHMK YWNkMDogTWVjaGFuaXNtOiBlamVjdGFibGUgdHJheSwgdW5sb2NrZWQKYWNkMDogTWVkaXVtOiBu by9ibGFuayBkaXNjCmF0YTQ6IElkZW50aWZ5aW5nIGRldmljZXM6IDAwMDAwMDAwCmF0YTQ6IE5l dyBkZXZpY2VzOiAwMDAwMDAwMApiYXR0ZXJ5MDogYmF0dGVyeSBpbml0aWFsaXphdGlvbiBkb25l LCB0cmllZCAxIHRpbWVzCnVodWIwOiAyIHBvcnRzIHdpdGggMiByZW1vdmFibGUsIHNlbGYgcG93 ZXJlZAp1aHViMTogMiBwb3J0cyB3aXRoIDIgcmVtb3ZhYmxlLCBzZWxmIHBvd2VyZWQKdWh1YjM6 IDIgcG9ydHMgd2l0aCAyIHJlbW92YWJsZSwgc2VsZiBwb3dlcmVkCnVodWI0OiAyIHBvcnRzIHdp dGggMiByZW1vdmFibGUsIHNlbGYgcG93ZXJlZAp1aHViNTogMiBwb3J0cyB3aXRoIDIgcmVtb3Zh YmxlLCBzZWxmIHBvd2VyZWQKdWh1YjI6IDQgcG9ydHMgd2l0aCA0IHJlbW92YWJsZSwgc2VsZiBw b3dlcmVkCmFjZDA6IEZBSUxVUkUgLSBJTlFVSVJZIElMTEVHQUwgUkVRVUVTVCBhc2M9MHgyNCBh c2NxPTB4MDAgc2tzPTB4NDAgMHgwMCAweDAxCihwcm9iZTA6YXRhMTowOjA6MCk6IGVycm9yIDIy Cihwcm9iZTA6YXRhMTowOjA6MCk6IFVucmV0cnlhYmxlIEVycm9yCihwcm9iZTA6YXRhMTowOjA6 MCk6IERvd24gcmV2aW5nIFByb3RvY29sIFZlcnNpb24gZnJvbSAyIHRvIDA/Cihwcm9iZTA6YXRh MTowOjA6MCk6IFRFU1QgVU5JVCBSRUFEWS4gQ0RCOiAwIDAgMCAwIDAgMCAKKHByb2JlMDphdGEx OjA6MDowKTogQ0FNIFN0YXR1czogU0NTSSBTdGF0dXMgRXJyb3IKKHByb2JlMDphdGExOjA6MDow KTogU0NTSSBTdGF0dXM6IENoZWNrIENvbmRpdGlvbgoocHJvYmUwOmF0YTE6MDowOjApOiBOT1Qg UkVBRFkgYXNjOjNhLDEKKHByb2JlMDphdGExOjA6MDowKTogTWVkaXVtIG5vdCBwcmVzZW50IC0g dHJheSBjbG9zZWQKKHByb2JlMDphdGExOjA6MDowKTogKHByb2JlMDphdGExOjA6MDowKTogVEVT VCBVTklUIFJFQURZLiBDREI6IDAgMCAwIDAgMCAwIAoocHJvYmUwOmF0YTE6MDowOjApOiBOT1Qg UkVBRFkgYXNjOjNhLDEKKHByb2JlMDphdGExOjA6MDowKTogTWVkaXVtIG5vdCBwcmVzZW50IC0g dHJheSBjbG9zZWQKVW5yZXRyeWFibGUgZXJyb3IKKHByb2JlMDphdGExOjA6MDowKTogZXJyb3Ig NgoocHJvYmUwOmF0YTE6MDowOjApOiBVbnJldHJ5YWJsZSBFcnJvcgoocHJvYmUwOmF0YTE6MDow OjApOiBlcnJvciA2Cihwcm9iZTA6YXRhMTowOjA6MCk6IFVucmV0cnlhYmxlIEVycm9yCmFjZDA6 IEZBSUxVUkUgLSBJTlFVSVJZIElMTEVHQUwgUkVRVUVTVCBhc2M9MHgyNCBhc2NxPTB4MDAgc2tz PTB4NDAgMHgwMCAweDAxCihwcm9iZTA6YXRhMTowOjA6MCk6IGVycm9yIDIyCihwcm9iZTA6YXRh MTowOjA6MCk6IFVucmV0cnlhYmxlIEVycm9yCkFUQSBQc2V1ZG9SQUlEIGxvYWRlZApTTVA6IEFQ IENQVSAjMSBMYXVuY2hlZCEKY3B1MSBBUDoKICAgICBJRDogMHgwMTAwMDAwMCAgIFZFUjogMHgw MDA1MDAxNCBMRFI6IDB4MDAwMDAwMDAgREZSOiAweGZmZmZmZmZmCiAgbGludDA6IDB4MDAwMTA3 MDAgbGludDE6IDB4MDAwMDA0MDAgVFBSOiAweDAwMDAwMDAwIFNWUjogMHgwMDAwMDFmZgogIHRp bWVyOiAweDAwMDIwMGVmIHRoZXJtOiAweDAwMDEwMDAwIGVycjogMHgwMDAxMDAwMCBwY206IDB4 MDAwMTA0MDAKaW9hcGljMDogcm91dGluZyBpbnRwaW4gOSAoSVNBIElSUSA5KSB0byBsYXBpYyAx IHZlY3RvciA0OAppb2FwaWMwOiByb3V0aW5nIGludHBpbiAxNiAoUENJIElSUSAxNikgdG8gbGFw aWMgMSB2ZWN0b3IgNDkKaW9hcGljMDogcm91dGluZyBpbnRwaW4gMTggKFBDSSBJUlEgMTgpIHRv IGxhcGljIDEgdmVjdG9yIDUwCmlvYXBpYzA6IHJvdXRpbmcgaW50cGluIDIxIChQQ0kgSVJRIDIx KSB0byBsYXBpYyAxIHZlY3RvciA1MQptc2k6IEFzc2lnbmluZyBNU0kgSVJRIDI1NyB0byBsb2Nh bCBBUElDIDEgdmVjdG9yIDUyClJvb3QgbW91bnQgd2FpdGluZyBmb3I6IHVzYnVzNgp1aHViNjog NiBwb3J0cyB3aXRoIDYgcmVtb3ZhYmxlLCBzZWxmIHBvd2VyZWQKUm9vdCBtb3VudCB3YWl0aW5n IGZvcjogdXNidXM2CnVnZW42LjI6IDxTYW5EaXNrPiBhdCB1c2J1czYKdW1hc3MwOiA8U2FuRGlz ayBTYW5EaXNrIENydXplciwgY2xhc3MgMC8wLCByZXYgMi4wMC8yLjAwLCBhZGRyIDI+IG9uIHVz YnVzNgp1bWFzczA6ICBTQ1NJIG92ZXIgQnVsay1Pbmx5OyBxdWlya3MgPSAweDAwMDAKUm9vdCBt b3VudCB3YWl0aW5nIGZvcjogdXNidXM2CnVtYXNzMDoyOjA6LTE6IEF0dGFjaGVkIHRvIHNjYnVz MgoocHJvYmUwOnVtYXNzLXNpbTA6MDowOjApOiBEb3duIHJldmluZyBQcm90b2NvbCBWZXJzaW9u IGZyb20gMiB0byAwPwpHRU9NOiBuZXcgZGlzayBkYTAKZGEwIGF0IHVtYXNzLXNpbTAgYnVzIDAg c2NidXMyIHRhcmdldCAwIGx1biAwCmRhMDogPFNhbkRpc2sgU2FuRGlzayBDcnV6ZXIgOC4wMj4g UmVtb3ZhYmxlIERpcmVjdCBBY2Nlc3MgU0NTSS0wIGRldmljZSAKZGEwOiBTZXJpYWwgTnVtYmVy IDM1NTAzMzBBMTVEMUU5RjUKZGEwOiA0MC4wMDBNQi9zIHRyYW5zZmVycwpkYTA6IDc2OTFNQiAo MTU3NTMyMTUgNTEyIGJ5dGUgc2VjdG9yczogMjU1SCA2M1MvVCA5ODBDKQpHRU9NOiBkYTA6IHBh cnRpdGlvbiAxIGRvZXMgbm90IHN0YXJ0IG9uIGEgdHJhY2sgYm91bmRhcnkuCkdFT006IGRhMDog cGFydGl0aW9uIDEgZG9lcyBub3QgZW5kIG9uIGEgdHJhY2sgYm91bmRhcnkuClJvb3QgbW91bnQg d2FpdGluZyBmb3I6IHVzYnVzNgp1Z2VuNi4zOiA8R2VuZXJpYz4gYXQgdXNidXM2CnVtYXNzMTog PEJ1bGstSW4sIEJ1bGstT3V0LCBJbnRlcmZhY2U+IG9uIHVzYnVzNgp1bWFzczE6ICBTQ1NJIG92 ZXIgQnVsay1Pbmx5OyBxdWlya3MgPSAweDAwMDAKUm9vdCBtb3VudCB3YWl0aW5nIGZvcjogdXNi dXM2CnVnZW40LjI6IDxMb2dpdGVjaD4gYXQgdXNidXM0CnVtczA6IDxMb2dpdGVjaCBVU0IgUmVj ZWl2ZXIsIGNsYXNzIDAvMCwgcmV2IDEuMTAvNDYuMDAsIGFkZHIgMj4gb24gdXNidXM0CnVtczA6 IDggYnV0dG9ucyBhbmQgW1hZWl0gY29vcmRpbmF0ZXMgSUQ9MAp1aGlkMDogPExvZ2l0ZWNoIFVT QiBSZWNlaXZlciwgY2xhc3MgMC8wLCByZXYgMS4xMC80Ni4wMCwgYWRkciAyPiBvbiB1c2J1czQK dW1hc3MxOjM6MTotMTogQXR0YWNoZWQgdG8gc2NidXMzCihwcm9iZTA6dW1hc3Mtc2ltMToxOjA6 MCk6IERvd24gcmV2aW5nIFByb3RvY29sIFZlcnNpb24gZnJvbSAyIHRvIDA/Cihwcm9iZTA6dW1h c3Mtc2ltMToxOjA6MCk6IFRFU1QgVU5JVCBSRUFEWS4gQ0RCOiAwIDAgMCAwIDAgMCAKKHByb2Jl MDp1bWFzcy1zaW0xOjE6MDowKTogQ0FNIFN0YXR1czogU0NTSSBTdGF0dXMgRXJyb3IKKHByb2Jl MDp1bWFzcy1zaW0xOjE6MDowKTogU0NTSSBTdGF0dXM6IENoZWNrIENvbmRpdGlvbgoocHJvYmUw OnVtYXNzLXNpbTE6MTowOjApOiBOT1QgUkVBRFkgYXNjOjNhLDAKKHByb2JlMDp1bWFzcy1zaW0x OjE6MDowKTogTWVkaXVtIG5vdCBwcmVzZW50Cihwcm9iZTA6dW1hc3Mtc2ltMToxOjA6MCk6IChw cm9iZTA6dW1hc3Mtc2ltMToxOjA6MCk6IFRFU1QgVU5JVCBSRUFEWS4gQ0RCOiAwIDAgMCAwIDAg MCAKKHByb2JlMDp1bWFzcy1zaW0xOjE6MDowKTogTk9UIFJFQURZIGFzYzozYSwwCihwcm9iZTA6 dW1hc3Mtc2ltMToxOjA6MCk6IE1lZGl1bSBub3QgcHJlc2VudApVbnJldHJ5YWJsZSBlcnJvcgoo cHJvYmUwOnVtYXNzLXNpbTE6MTowOjApOiBlcnJvciA2Cihwcm9iZTA6dW1hc3Mtc2ltMToxOjA6 MCk6IFVucmV0cnlhYmxlIEVycm9yCkdFT006IG5ldyBkaXNrIGRhMQooZGExOnVtYXNzLXNpbTE6 MTowOjApOiBlcnJvciA2CihkYTE6dW1hc3Mtc2ltMToxOjA6MCk6IFVucmV0cnlhYmxlIEVycm9y CmRhMSBhdCB1bWFzcy1zaW0xIGJ1cyAxIHNjYnVzMyB0YXJnZXQgMCBsdW4gMApkYTE6IDxHZW5l cmljLSBNdWx0aS1DYXJkIDEuMDA+IFJlbW92YWJsZSBEaXJlY3QgQWNjZXNzIFNDU0ktMCBkZXZp Y2UgCmRhMTogU2VyaWFsIE51bWJlciAyMDA3MTExNDE3MzQwMDAwMApkYTE6IDQwLjAwME1CL3Mg dHJhbnNmZXJzCmRhMTogQXR0ZW1wdCB0byBxdWVyeSBkZXZpY2Ugc2l6ZSBmYWlsZWQ6IE5PVCBS RUFEWSwgTWVkaXVtIG5vdCBwcmVzZW50CihkYTE6dW1hc3Mtc2ltMToxOjA6MCk6IGVycm9yIDYK KGRhMTp1bWFzcy1zaW0xOjE6MDowKTogVW5yZXRyeWFibGUgRXJyb3IKT3BlbmVkIGRpc2sgZGEx IC0+IDYKKGRhMTp1bWFzcy1zaW0xOjE6MDowKTogZXJyb3IgNgooZGExOnVtYXNzLXNpbTE6MTow OjApOiBVbnJldHJ5YWJsZSBFcnJvcgpPcGVuZWQgZGlzayBkYTEgLT4gNgpSb290IG1vdW50IHdh aXRpbmcgZm9yOiB1c2J1czYKdWdlbjYuNDogPFN1WWluPiBhdCB1c2J1czYKVHJ5aW5nIHRvIG1v dW50IHJvb3QgZnJvbSB1ZnM6L2Rldi9hZDRzNGEKY3RfdG9fdHMoWzIwMTAtMDEtMjcgMTE6MzY6 NTBdKSA9IDEyNjQ1OTIyMTAuMDAwMDAwMDAwCnN0YXJ0X2luaXQ6IHRyeWluZyAvc2Jpbi9pbml0 CmFjcGlfdHowOiBzd2l0Y2hlZCBmcm9tIF9BQzAgdG8gTk9ORTogNjIuMEMKdHNfdG9fY3QoMTI2 NDU5MjIzMS4zODQ5MTg2NzUpID0gWzIwMTAtMDEtMjcgMTE6Mzc6MTFdCg== --001485f453423a15ad047e28b4a4 Content-Type: application/octet-stream; name=fdisk Content-Disposition: attachment; filename=fdisk Content-Transfer-Encoding: base64 X-Attachment-Id: f_g4ye0nw33 KioqKioqKiBXb3JraW5nIG9uIGRldmljZSAvZGV2L2FkNCAqKioqKioqCnBhcmFtZXRlcnMgZXh0 cmFjdGVkIGZyb20gaW4tY29yZSBkaXNrbGFiZWwgYXJlOgpjeWxpbmRlcnM9OTY5MDIxIGhlYWRz PTE2IHNlY3RvcnMvdHJhY2s9NjMgKDEwMDggYmxrcy9jeWwpCgpGaWd1cmVzIGJlbG93IHdvbid0 IHdvcmsgd2l0aCBCSU9TIGZvciBwYXJ0aXRpb25zIG5vdCBpbiBjeWwgMQpwYXJhbWV0ZXJzIHRv IGJlIHVzZWQgZm9yIEJJT1MgY2FsY3VsYXRpb25zIGFyZToKY3lsaW5kZXJzPTk2OTAyMSBoZWFk cz0xNiBzZWN0b3JzL3RyYWNrPTYzICgxMDA4IGJsa3MvY3lsKQoKTWVkaWEgc2VjdG9yIHNpemUg aXMgNTEyCldhcm5pbmc6IEJJT1Mgc2VjdG9yIG51bWJlcmluZyBzdGFydHMgd2l0aCBzZWN0b3Ig MQpJbmZvcm1hdGlvbiBmcm9tIERPUyBib290YmxvY2sgaXM6ClRoZSBkYXRhIGZvciBwYXJ0aXRp b24gMSBpczoKc3lzaWQgMTMxICgweDgzKSwoTGludXggbmF0aXZlKQogICAgc3RhcnQgNjMsIHNp emUgMTY3NzE3OTcgKDgxODkgTWVnKSwgZmxhZyAwCgliZWc6IGN5bCAwLyBoZWFkIDEvIHNlY3Rv ciAxOwoJZW5kOiBjeWwgMTAyMy8gaGVhZCAxMS8gc2VjdG9yIDYzClRoZSBkYXRhIGZvciBwYXJ0 aXRpb24gMiBpczoKc3lzaWQgNyAoMHgwNyksKE5URlMsIE9TLzIgSFBGUywgUU5YLTIgKDE2IGJp dCkgb3IgQWR2YW5jZWQgVU5JWCkKICAgIHN0YXJ0IDE2NzcxODYwLCBzaXplIDc1NTA1NTAwICgz Njg2NyBNZWcpLCBmbGFnIDgwIChhY3RpdmUpCgliZWc6IGN5bCAxMDIzLyBoZWFkIDI1NS8gc2Vj dG9yIDYzOwoJZW5kOiBjeWwgMTAyMy8gaGVhZCAxNS8gc2VjdG9yIDYzClRoZSBkYXRhIGZvciBw YXJ0aXRpb24gMyBpczoKc3lzaWQgNSAoMHgwNSksKEV4dGVuZGVkIERPUykKICAgIHN0YXJ0IDky Mjc3MzYwLCBzaXplIDgyMjA3ODE4MCAoNDAxNDA1IE1lZyksIGZsYWcgMAoJYmVnOiBjeWwgMTAy My8gaGVhZCAyNTUvIHNlY3RvciA2MzsKCWVuZDogY3lsIDEwMjMvIGhlYWQgMTEvIHNlY3RvciA2 MwpUaGUgZGF0YSBmb3IgcGFydGl0aW9uIDQgaXM6CnN5c2lkIDE2NSAoMHhhNSksKEZyZWVCU0Qv TmV0QlNELzM4NkJTRCkKICAgIHN0YXJ0IDkxNDM1NTU0MCwgc2l6ZSA2MjQxNzYyOCAoMzA0Nzcg TWVnKSwgZmxhZyAwCgliZWc6IGN5bCAxMDIzLyBoZWFkIDI1NS8gc2VjdG9yIDYzOwoJZW5kOiBj eWwgMTAyMy8gaGVhZCAxNS8gc2VjdG9yIDYzCg== --001485f453423a15ad047e28b4a4 Content-Type: application/octet-stream; name=bsdlabel Content-Disposition: attachment; filename=bsdlabel Content-Transfer-Encoding: base64 X-Attachment-Id: f_g4ye0skw4 IyAvZGV2L2FkNHM0Ogo4IHBhcnRpdGlvbnM6CiMgICAgICAgIHNpemUgICBvZmZzZXQgICAgZnN0 eXBlICAgW2ZzaXplIGJzaXplIGJwcy9jcGddCiAgYTogIDQxOTQzMDQgICAgICAgIDAgICAgNC4y QlNEICAgICAgICAwICAgICAwICAgICAwIAogIGI6ICA5MTc1MDQwICA0MTk0MzA0ICAgICAgc3dh cCAgICAgICAgICAgICAgICAgICAgCiAgYzogNjI0MTc2MjggICAgICAgIDAgICAgdW51c2VkICAg ICAgICAwICAgICAwICAgICAgICAgIyAicmF3IiBwYXJ0LCBkb24ndCBlZGl0CiAgZDogIDQxOTQz MDQgMTMzNjkzNDQgICAgNC4yQlNEICAgICAgICAwICAgICAwICAgICAwIAogIGU6IDMxMjIxNzYw IDE3NTYzNjQ4ICAgIDQuMkJTRCAgICAgICAgMCAgICAgMCAgICAgMCAKICBmOiAxMzYzMjIyMCA0 ODc4NTQwOCAgICA0LjJCU0QgICAgICAgIDAgICAgIDAgICAgIDAgCg== --001485f453423a15ad047e28b4a4-- From owner-freebsd-stable@FreeBSD.ORG Wed Jan 27 17:41:49 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F28F9106566C; Wed, 27 Jan 2010 17:41:48 +0000 (UTC) (envelope-from jamesbrandongooch@gmail.com) Received: from mail-px0-f183.google.com (mail-px0-f183.google.com [209.85.216.183]) by mx1.freebsd.org (Postfix) with ESMTP id B44C48FC0C; Wed, 27 Jan 2010 17:41:48 +0000 (UTC) Received: by pxi13 with SMTP id 13so4163335pxi.3 for ; Wed, 27 Jan 2010 09:41:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:content-type; bh=Dm1oyqSOnUdIf8Ji/26PKBBMAhrpgQke0T2DQwLGKlQ=; b=nuPnq/9L/teyMb9cTCxrvsShJ79fvPhtmUIYdYfQkW2bu/Y2wjofCTjRyovezqzKaG ljB31WGXFSGU/6shGmge8oTtyVldqBNBALEIyrFC6CUIQ53pJ0fs+Vup2CqfVRxPPYzN JRxQ0efheh42Ec5jN/qlEi2NyZfWmiuq5G5XA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=l7MdgQnaW969vMx4QuzYE9xaKOO01B2VIQi3i6/5BxWnDtRot9sTUeyVJhuITMJz/7 s8iDrMz1UTrw3/K8CfxImFwJkFjQLVmY1UZOtnz3BXS/ibxtQ7gd7zWMHJ0/Yi8ZMvP7 2TcZP86ieq/A0eDsjEkVtA7grzv2LTvVL/C/U= MIME-Version: 1.0 Received: by 10.142.151.18 with SMTP id y18mr441211wfd.338.1264614108139; Wed, 27 Jan 2010 09:41:48 -0800 (PST) Date: Wed, 27 Jan 2010 11:41:48 -0600 Message-ID: <179b97fb1001270941m2d8e9c8au20abc798c16b9c11@mail.gmail.com> From: Brandon Gooch To: stable-list freebsd , freebsd-fs@freebsd.org, freebsd-emulation@freebsd.org Content-Type: multipart/mixed; boundary=000e0cd328beb19215047e28eab4 Cc: Subject: ZFS and sh(1) panic: spin lock [lock addr] (smp rendezvous) held by [sh(1) proc tid] too long X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 27 Jan 2010 17:41:49 -0000 --000e0cd328beb19215047e28eab4 Content-Type: text/plain; charset=ISO-8859-1 The machine, a Dell Optiplex 755, has been locking up recently. The situation usually occurs while using VirtualBox (running a 64-bit Windows 7 instance) and doing anything else in another xterm (such as rebuilding a port). I've been unable to reliably reproduce it (I'm in an X session and the machine will not panic "properly"). However, while rebuilding Xorg today at ttyv0 and runnning VBoxHeadless on ttyv1, I managed to trigger what I believe is the lockup. I've attached a textdump in hopes that someone may be able to take a look and provide clues or instruction on debugging this. Thanks! -Brandon --000e0cd328beb19215047e28eab4 Content-Type: application/octet-stream; name="textdump.tar.0" Content-Disposition: attachment; filename="textdump.tar.0" Content-Transfer-Encoding: base64 X-Attachment-Id: f_g4yelkku0 ZGRiLnR4dAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADA2MDAAAAAAMAAAAAAA AAAwAAAAAAAAADE0MDAwMAAAAAAAADExMzMwMDY1MjE1ACAgNzA2NgAgAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAB1c3RhcgAAAHJvb3QAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAd2hlZWwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABk YjowOmtkYi5lbnRlci5wYW5pYz4gIHJ1biBsb2NraW5mbwpkYjoxOmxvY2tpbmZvPiBzaG93IGxv Y2tzCk5vIHN1Y2ggY29tbWFuZApkYjoxOmxvY2tzPiAgc2hvdyBhbGxsb2NrcwpObyBzdWNoIGNv bW1hbmQKZGI6MTphbGxsb2Nrcz4gIHNob3cgbG9ja2Vkdm5vZHMKTG9ja2VkIHZub2RlcwpkYjow OmtkYi5lbnRlci5wYW5pYz4gIHNob3cgcGNwdQpjcHVpZCAgICAgICAgPSAwCmR5bmFtaWMgcGNw dSAgICA9IDB4NTMyMTgwCmN1cnRocmVhZCAgICA9IDB4ZmZmZmZmMDA4MTEyNmFlMDogcGlkIDE5 MTggImNvbnNvbGUta2l0LWRhZW1vbiIKY3VycGNiICAgICAgID0gMHhmZmZmZmY4MGU4YzkxZDQw CmZwY3VydGhyZWFkICA9IG5vbmUKaWRsZXRocmVhZCAgID0gMHhmZmZmZmYwMDAxODZkNzQwOiBw aWQgMTEgImlkbGU6IGNwdTAiCmN1cnBtYXAgICAgICAgICA9IDAKdHNzcCAgICAgICAgICAgID0g MHhmZmZmZmZmZjgwOGEwYzAwCmNvbW1vbnRzc3AgICAgICA9IDB4ZmZmZmZmZmY4MDhhMGMwMApy c3AwICAgICAgICAgICAgPSAweGZmZmZmZjgwZThjOTFkNDAKZ3MzMnAgICAgICAgICAgID0gMHhm ZmZmZmZmZjgwODlmYTM4CmxkdCAgICAgICAgICAgICA9IDB4ZmZmZmZmZmY4MDg5ZmE3OAp0c3Mg ICAgICAgICAgICAgPSAweGZmZmZmZmZmODA4OWZhNjgKZGI6MDprZGIuZW50ZXIucGFuaWM+ICBi dApUcmFjaW5nIHBpZCAxOTE4IHRpZCAxMDAyMTUgdGQgMHhmZmZmZmYwMDgxMTI2YWUwCmtkYl9l bnRlcigpIGF0IGtkYl9lbnRlcisweDNkCnBhbmljKCkgYXQgcGFuaWMrMHgxN2IKX210eF9sb2Nr X3NwaW5fZmFpbGVkKCkgYXQgX210eF9sb2NrX3NwaW5fZmFpbGVkKzB4MzkKX210eF9sb2NrX3Nw aW4oKSBhdCBfbXR4X2xvY2tfc3BpbisweGIyCnNtcF90bGJfc2hvb3Rkb3duKCkgYXQgc21wX3Rs Yl9zaG9vdGRvd24rMHhmYQpwbWFwX2ludmFsaWRhdGVfcmFuZ2UoKSBhdCBwbWFwX2ludmFsaWRh dGVfcmFuZ2UrMHhhZQp2bV90aHJlYWRfc3RhY2tfZGlzcG9zZSgpIGF0IHZtX3RocmVhZF9zdGFj a19kaXNwb3NlKzB4MmUKdGhyZWFkX2ZyZWUoKSBhdCB0aHJlYWRfZnJlZSsweDNjCnRocmVhZF9y ZWFwKCkgYXQgdGhyZWFkX3JlYXArMHhhMAp0aHJlYWRfYWxsb2MoKSBhdCB0aHJlYWRfYWxsb2Mr MHgxOApjcmVhdGVfdGhyZWFkKCkgYXQgY3JlYXRlX3RocmVhZCsweGFkCmtlcm5fdGhyX25ldygp IGF0IGtlcm5fdGhyX25ldysweDdjCnRocl9uZXcoKSBhdCB0aHJfbmV3KzB4NjgKc3lzY2FsbCgp IGF0IHN5c2NhbGwrMHgyOGYKWGZhc3Rfc3lzY2FsbCgpIGF0IFhmYXN0X3N5c2NhbGwrMHhlMQot LS0gc3lzY2FsbCAoNDU1LCBGcmVlQlNEIEVMRjY0LCB0aHJfbmV3KSwgcmlwID0gMHg4MDE4N2Q0 OGMsIHJzcCA9IDB4N2ZmZmZmZmZlN2U4LCByYnAgPSAweDgwMWMwOGVjMCAtLS0KZGI6MDprZGIu ZW50ZXIucGFuaWM+ICBwcwogIHBpZCAgcHBpZCAgcGdycCAgIHVpZCAgIHN0YXRlICAgd21lc2cg ICAgICAgICB3Y2hhbiAgICAgICAgY21kCjcwMDQzIDUxMTU5IDQzMjIwICAgICAwICBSKyAgICAg IENQVSAxICAgICAgICAgICAgICAgICAgICAgICBzaAo4ODI2NyAgICAgMSA4ODI2NiAgNzc3NyAg UiAgICAgICAodGhyZWFkZWQpICAgICAgICAgICAgICAgICAgVkJveFNWQwoxMDA0MDMgICAgICAg ICAgICAgICAgICAgUyAgICAgICB1Y29uZCAgICAweGZmZmZmZjAwODExNThjODAgVkJveFNWQwox MDA0MDIgICAgICAgICAgICAgICAgICAgUyAgICAgICB1Y29uZCAgICAweGZmZmZmZjAwMTZjODc0 MDAgVkJveFNWQwoxMDA0MDEgICAgICAgICAgICAgICAgICAgUyAgICAgICB1Y29uZCAgICAweGZm ZmZmZjAwMWY2MjA4MDAgVkJveFNWQwoxMDA0MDAgICAgICAgICAgICAgICAgICAgUnVuUSAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgVkJveFNWQwoxMDAzOTkgICAgICAgICAgICAgICAg ICAgUyAgICAgICB1Y29uZCAgICAweGZmZmZmZjAxMzBiMWJjMDAgVkJveFNWQwoxMDAzOTggICAg ICAgICAgICAgICAgICAgUyAgICAgICB1Y29uZCAgICAweGZmZmZmZjAxMzBiMWJjODAgVkJveFNW QwoxMDAzOTcgICAgICAgICAgICAgICAgICAgUyAgICAgICBzZWxlY3QgICAweGZmZmZmZjAwMjg1 ZDhiYzAgVkJveFNWQwoxMDAzMzYgICAgICAgICAgICAgICAgICAgUyAgICAgICB1Y29uZCAgICAw eGZmZmZmZjAxOWE2NzdjMDAgaW5pdGlhbCB0aHJlYWQKODgyNjQgODgyNjMgODgyNjMgIDc3Nzcg IFMrICAgICAgc2VsZWN0ICAgMHhmZmZmZmYwMTMwNDBlOGMwIGluaXRpYWwgdGhyZWFkCjg4MjYz IDcxMDQ3IDg4MjYzICA3Nzc3ICBSKyAgICAgICh0aHJlYWRlZCkgICAgICAgICAgICAgICAgICBW Qm94SGVhZGxlc3MKMTAwNDE2ICAgICAgICAgICAgICAgICAgIFMgICAgICAgdWNvbmQgICAgMHhm ZmZmZmYwMDI3OWYxNjgwIFZCb3hIZWFkbGVzcwoxMDA0MTUgICAgICAgICAgICAgICAgICAgUyAg ICAgICB1Y29uZCAgICAweGZmZmZmZjAwMWJlMmUyMDAgVkJveEhlYWRsZXNzCjEwMDQxNCAgICAg ICAgICAgICAgICAgICBTICAgICAgIHVjb25kICAgIDB4ZmZmZmZmMDAwNmI2YTEwMCBWQm94SGVh ZGxlc3MKMTAwNDEzICAgICAgICAgICAgICAgICAgIFMgICAgICAgdWNvbmQgICAgMHhmZmZmZmYw MDI4NzRlYjAwIFZCb3hIZWFkbGVzcwoxMDA0MTIgICAgICAgICAgICAgICAgICAgUyAgICAgICB1 Y29uZCAgICAweGZmZmZmZjAwODEwMzY4MDAgVkJveEhlYWRsZXNzCjEwMDQxMSAgICAgICAgICAg ICAgICAgICBSdW5RICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBWQm94SGVhZGxlc3MK MTAwNDEwICAgICAgICAgICAgICAgICAgIFMgICAgICAgdWNvbmQgICAgMHhmZmZmZmYwMTMwYjJk NjgwIFZCb3hIZWFkbGVzcwoxMDA0MDkgICAgICAgICAgICAgICAgICAgUyAgICAgICB1Y29uZCAg ICAweGZmZmZmZjAwODExNThkMDAgVkJveEhlYWRsZXNzCjEwMDQwOCAgICAgICAgICAgICAgICAg ICBTICAgICAgIHVjb25kICAgIDB4ZmZmZmZmMDA4MTc0OTY4MCBWQm94SGVhZGxlc3MKMTAwNDA3 ICAgICAgICAgICAgICAgICAgIFJ1blEgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFZC b3hIZWFkbGVzcwoxMDA0MDYgICAgICAgICAgICAgICAgICAgUnVuICAgICBDUFUgMyAgICAgICAg ICAgICAgICAgICAgICAgVkJveEhlYWRsZXNzCjEwMDQwNCAgICAgICAgICAgICAgICAgICBTICAg ICAgIHVjb25kICAgIDB4ZmZmZmZmMDAxZmEwYzg4MCBWQm94SGVhZGxlc3MKMTAwMzk2ICAgICAg ICAgICAgICAgICAgIFMgICAgICAgdWNvbmQgICAgMHhmZmZmZmYwMTlhNjc3MjgwIFZCb3hIZWFk bGVzcwoxMDAzOTUgICAgICAgICAgICAgICAgICAgUyAgICAgICBzZWxlY3QgICAweGZmZmZmZjAw Mjg3OTA2NDAgVkJveEhlYWRsZXNzCjEwMDM5NCAgICAgICAgICAgICAgICAgICBTICAgICAgIHdh aXQgICAgIDB4ZmZmZmZmMDAzMzc2MTQ2MCBWQm94SGVhZGxlc3MKMTAwMzc5ICAgICAgICAgICAg ICAgICAgIFMgICAgICAgdWNvbmQgICAgMHhmZmZmZmYwMDFmODA5MDgwIGluaXRpYWwgdGhyZWFk CjUxMTU5IDUxMTIwIDQzMjIwICAgICAwICBTKyAgICAgIHdhaXQgICAgIDB4ZmZmZmZmMDEzMDc1 ZDQ2MCBzaAo1MTEyMCA1MDc5OCA0MzIyMCAgICAgMCAgUysgICAgICB3YWl0ICAgICAweGZmZmZm ZjAwODExMWUwMDAgc2gKNTA3OTggNDMyMjAgNDMyMjAgICAgIDAgIFMrICAgICAgd2FpdCAgICAg MHhmZmZmZmYwMWE0YzczOGMwIHNoCjQ5MTc3ICAgICAxIDQ5MTc3ICAgICAwICBTcyAgICAgIGFj Y2VwdCAgIDB4ZmZmZmZmMDA4MTA1MjMwZSBuZXRzZXJ2ZXIKNzEwNDcgIDE5MDQgNzEwNDcgIDc3 NzcgIFMrICAgICAgcGF1c2UgICAgMHhmZmZmZmYwMDA2YzU5MGEwIHRjc2gKNDMyMjAgIDE5NzUg NDMyMjAgICAgIDAgIFMrICAgICAgd2FpdCAgICAgMHhmZmZmZmYwMDA2YzU4MDAwIHNoCjExOTYy ICAgICAxIDExOTYxICA3Nzc3ICBSICAgICAgICh0aHJlYWRlZCkgICAgICAgICAgICAgICAgICBW Qm94U1ZDCjEwMDMxMyAgICAgICAgICAgICAgICAgICBTICAgICAgIHVjb25kICAgIDB4ZmZmZmZm MDAxNjQzMjU4MCBWQm94U1ZDCjEwMDM0MyAgICAgICAgICAgICAgICAgICBTICAgICAgIHVjb25k ICAgIDB4ZmZmZmZmMDAwNjdlYjA4MCBWQm94U1ZDCjEwMDM0MSAgICAgICAgICAgICAgICAgICBT ICAgICAgIHVjb25kICAgIDB4ZmZmZmZmMDEzMGIxYmEwMCBWQm94U1ZDCjEwMDM0MCAgICAgICAg ICAgICAgICAgICBSdW5RICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBWQm94U1ZDCjEw MDMzOSAgICAgICAgICAgICAgICAgICBTICAgICAgIHVjb25kICAgIDB4ZmZmZmZmMDE5YTZlOGEw MCBWQm94U1ZDCjEwMDMzOCAgICAgICAgICAgICAgICAgICBTICAgICAgIHVjb25kICAgIDB4ZmZm ZmZmMDAwNjdlYjE4MCBWQm94U1ZDCjEwMDMzNyAgICAgICAgICAgICAgICAgICBTICAgICAgIHVj b25kICAgIDB4ZmZmZmZmMDAwNjdlYjIwMCBWQm94U1ZDCjEwMDMyMSAgICAgICAgICAgICAgICAg ICBTICAgICAgIHVjb25kICAgIDB4ZmZmZmZmMDE5YTRlNjc4MCBpbml0aWFsIHRocmVhZAogMTk3 NSAgMTkwMyAgMTk3NSAgNzc3NyAgUysgICAgICBwYXVzZSAgICAweGZmZmZmZjAwODExNTY1MDAg dGNzaAogMTkxOCAgICAgMSAgMTkxOCAgICAgMCAgUnMgICAgICAodGhyZWFkZWQpICAgICAgICAg ICAgICAgICAgY29uc29sZS1raXQtZGFlbW9uCjEwMDIzNSAgICAgICAgICAgICAgICAgICBTICAg ICAgIHdhaXR2dCAgIDB4ZmZmZmZmZmY4MDgyZDYyMCBjb25zb2xlLWtpdC1kYWVtb24KMTAwMjQy ICAgICAgICAgICAgICAgICAgIFMgICAgICAgd2FpdHZ0ICAgMHhmZmZmZmZmZjgwODJkNjU4IGNv bnNvbGUta2l0LWRhZW1vbgoxMDAyNDEgICAgICAgICAgICAgICAgICAgUyAgICAgICB3YWl0dnQg ICAweGZmZmZmZmZmODA4MmQ2NTAgY29uc29sZS1raXQtZGFlbW9uCjEwMDI0MCAgICAgICAgICAg ICAgICAgICBTICAgICAgIHdhaXR2dCAgIDB4ZmZmZmZmZmY4MDgyZDY0OCBjb25zb2xlLWtpdC1k YWVtb24KMTAwMjM5ICAgICAgICAgICAgICAgICAgIFMgICAgICAgd2FpdHZ0ICAgMHhmZmZmZmZm ZjgwODJkNjQwIGNvbnNvbGUta2l0LWRhZW1vbgoxMDAyMzggICAgICAgICAgICAgICAgICAgUyAg ICAgICB3YWl0dnQgICAweGZmZmZmZmZmODA4MmQ2MzggY29uc29sZS1raXQtZGFlbW9uCjEwMDIz NyAgICAgICAgICAgICAgICAgICBTICAgICAgIHdhaXR2dCAgIDB4ZmZmZmZmZmY4MDgyZDYzMCBj b25zb2xlLWtpdC1kYWVtb24KMTAwMjM2ICAgICAgICAgICAgICAgICAgIFMgICAgICAgd2FpdHZ0 ICAgMHhmZmZmZmZmZjgwODJkNjI4IGNvbnNvbGUta2l0LWRhZW1vbgoxMDAyMzQgICAgICAgICAg ICAgICAgICAgUyAgICAgICB3YWl0dnQgICAweGZmZmZmZmZmODA4MmQ2MTggY29uc29sZS1raXQt ZGFlbW9uCjEwMDIzMyAgICAgICAgICAgICAgICAgICBTICAgICAgIHdhaXR2dCAgIDB4ZmZmZmZm ZmY4MDgyZDYxMCBjb25zb2xlLWtpdC1kYWVtb24KMTAwMjMyICAgICAgICAgICAgICAgICAgIFMg ICAgICAgd2FpdHZ0ICAgMHhmZmZmZmZmZjgwODJkNjA4IGNvbnNvbGUta2l0LWRhZW1vbgoxMDAy MzEgICAgICAgICAgICAgICAgICAgUyAgICAgICB3YWl0dnQgICAweGZmZmZmZmZmODA4MmQ2MDAg Y29uc29sZS1raXQtZGFlbW9uCjEwMDIzMCAgICAgICAgICAgICAgICAgICBTICAgICAgIHdhaXR2 dCAgIDB4ZmZmZmZmZmY4MDgyZDVmOCBjb25zb2xlLWtpdC1kYWVtb24KMTAwMjI5ICAgICAgICAg ICAgICAgICAgIFMgICAgICAgd2FpdHZ0ICAgMHhmZmZmZmZmZjgwODJkNWYwIGNvbnNvbGUta2l0 LWRhZW1vbgoxMDAyMjcgICAgICAgICAgICAgICAgICAgUyAgICAgICB1Y29uZCAgICAweGZmZmZm ZjAwODEyOGZlMDAgY29uc29sZS1raXQtZGFlbW9uCjEwMDIxNSAgICAgICAgICAgICAgICAgICBS dW4gICAgIENQVSAwICAgICAgICAgICAgICAgICAgICAgICBjb25zb2xlLWtpdC1kYWVtb24KIDE5 MTAgICAgIDEgIDE5MTAgICAgIDAgIFNzKyAgICAgdHR5aW4gICAgMHhmZmZmZmYwMDA2MjlhOGE4 IGdldHR5CiAxOTA5ICAgICAxICAxOTA5ICAgICAwICBTcysgICAgIHR0eWluICAgIDB4ZmZmZmZm MDAwNjI5YWNhOCBnZXR0eQogMTkwOCAgICAgMSAgMTkwOCAgICAgMCAgU3MrICAgICB0dHlpbiAg ICAweGZmZmZmZjAwMDYyOWIwYTggZ2V0dHkKIDE5MDcgICAgIDEgIDE5MDcgICAgIDAgIFNzKyAg ICAgdHR5aW4gICAgMHhmZmZmZmYwMDA2MjliNGE4IGdldHR5CiAxOTA2ICAgICAxICAxOTA2ICAg ICAwICBTcysgICAgIHR0eWluICAgIDB4ZmZmZmZmMDAwNjI4YzBhOCBnZXR0eQogMTkwNSAgICAg MSAgMTkwNSAgICAgMCAgU3MrICAgICB0dHlpbiAgICAweGZmZmZmZjAwMDYyNTg4YTggZ2V0dHkK IDE5MDQgICAgIDEgIDE5MDQgICAgIDAgIFNzKyAgICAgd2FpdCAgICAgMHhmZmZmZmYwMDgxMzIw MDAwIGxvZ2luCiAxOTAzICAgICAxICAxOTAzICAgICAwICBTcysgICAgIHdhaXQgICAgIDB4ZmZm ZmZmMDA4MTMyMDQ2MCBsb2dpbgogMTgyOCAgICAgMSAgMTgyOCAgICAgMCAgU3MgICAgICBuYW5z bHAgICAweGZmZmZmZmZmODA4MzI5ZTggY3JvbgogMTgyMSAgICAgMSAgMTgyMSAgICAyNSAgU3Mg ICAgICBwYXVzZSAgICAweGZmZmZmZjAwODEzMjU5NjAgc2VuZG1haWwKIDE4MTcgICAgIDEgIDE4 MTcgICAgIDAgIFJzICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHNlbmRtYWlsCiAx ODA0ICAgICAxICAxODA0ICAgICAwICBTcyAgICAgIHNlbGVjdCAgIDB4ZmZmZmZmMDA4MTE1ODFj MCBzc2hkCiAxNzA1ICAgICAxICAxNzA1ICAgNTU2ICBTcyAgICAgIHNlbGVjdCAgIDB4ZmZmZmZm MDA4MTE1ODM0MCBkYnVzLWRhZW1vbgogMTY0NSAgICAgMSAgMTY0NSAgICAgMCAgU3MgICAgICBz ZWxlY3QgICAweGZmZmZmZjAwODExNTg0YzAgcG93ZXJkCiAxNTUzICAgICAxICAxNTUzICAgICAw ICBTcyAgICAgIHNlbGVjdCAgIDB4ZmZmZmZmMDA4MTE1ODA0MCBzc2hkCiAxNTE4ICAxNTE3ICAx NTE3ICAgICAwICBSICAgICAgICh0aHJlYWRlZCkgICAgICAgICAgICAgICAgICBuZnNkCjEwMDE4 NCAgICAgICAgICAgICAgICAgICBSdW5RICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBu ZnNkOiBzZXJ2aWNlCjEwMDE4MyAgICAgICAgICAgICAgICAgICBSdW5RICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICBuZnNkOiBzZXJ2aWNlCjEwMDE4MiAgICAgICAgICAgICAgICAgICBS dW5RICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBuZnNkOiBzZXJ2aWNlCjEwMDEyNiAg ICAgICAgICAgICAgICAgICBSdW5RICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBuZnNk OiBtYXN0ZXIKIDE1MTcgICAgIDEgIDE1MTcgICAgIDAgIFNzICAgICAgc2VsZWN0ICAgMHhmZmZm ZmYwMDgxMDM2OTQwIG5mc2QKIDE1MTUgICAgIDEgIDE1MTUgICAgIDAgIFNzICAgICAgc2VsZWN0 ICAgMHhmZmZmZmYwMDA2ZjA2ZDQwIG1vdW50ZAogMTQyNiAgICAgMSAgMTQyNiAgICAgMCAgU3Mg ICAgICBzZWxlY3QgICAweGZmZmZmZjAwMDZmNzkzYzAgYW1kCiAxMzk5ICAgICAxICAxMzk5ICAg ICAwICBScyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBycGNiaW5kCiAxMzc0ICAg ICAxICAxMzc0ICAgICAwICBScyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBzeXNs b2dkCiAxMTU0ICAgICAxICAxMTU0ICAgICAwICBTcyAgICAgIHNlbGVjdCAgIDB4ZmZmZmZmMDAw NmYwNjBjMCBkZXZkCiAgOTUyICAgICAxICAgOTUyICAgICAwICBTcyAgICAgIHNlbGVjdCAgIDB4 ZmZmZmZmMDAwNmVlNTU0MCBtb3VzZWQKICA3NDMgICAgIDEgICA3NDMgICAgNjUgIFNzICAgICAg c2VsZWN0ICAgMHhmZmZmZmYwMDA2ZWViNWMwIGRoY2xpZW50CiAgNzI5ICAgICAxICAgNzI5ICAg ICAwICBTcyAgICAgIHNlbGVjdCAgIDB4ZmZmZmZmMDAwNmYwNzY0MCBkaGNsaWVudAogIDU3MSAg ICAgMSAgIDU3MSAgICA2NSAgU3MgICAgICBzZWxlY3QgICAweGZmZmZmZjAwMDZmMDY1YzAgZGhj bGllbnQKICA1NTMgICAgIDEgICA1NTMgICAgIDAgIFNzICAgICAgc2VsZWN0ICAgMHhmZmZmZmYw MDA2ZGQ5OTQwIGRoY2xpZW50CiAgMTA0ICAgICAwICAgICAwICAgICAwICBTTCAgICAgICh0aHJl YWRlZCkgICAgICAgICAgICAgICAgICBuZ19xdWV1ZQoxMDAxNDggICAgICAgICAgICAgICAgICAg RCAgICAgICBzbGVlcCAgICAweGZmZmZmZmZmODBlNGNlYjAgW25nX3F1ZXVlM10KMTAwMTQ3ICAg ICAgICAgICAgICAgICAgIEQgICAgICAgc2xlZXAgICAgMHhmZmZmZmZmZjgwZTRjZWIwIFtuZ19x dWV1ZTJdCjEwMDE0NiAgICAgICAgICAgICAgICAgICBEICAgICAgIHNsZWVwICAgIDB4ZmZmZmZm ZmY4MGU0Y2ViMCBbbmdfcXVldWUxXQoxMDAxMjEgICAgICAgICAgICAgICAgICAgRCAgICAgICBz bGVlcCAgICAweGZmZmZmZmZmODBlNGNlYjAgW25nX3F1ZXVlMF0KICAgMjIgICAgIDAgICAgIDAg ICAgIDAgIFNMICAgICAgbTp3MSAgICAgMHhmZmZmZmYwMDA2NDNhYzAwIFtnX21pcnJvciBzd2Fw XQogICAyMSAgICAgMCAgICAgMCAgICAgMCAgU0wgICAgICBmbG93Y2xlYSAweGZmZmZmZmZmODA4 NTcxOTAgW2Zsb3djbGVhbmVyXQogICAyMCAgICAgMCAgICAgMCAgICAgMCAgUkwgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgW3NvZnRkZXBmbHVzaF0KICAgMTkgICAgIDAgICAgIDAg ICAgIDAgIFNMICAgICAgdmxydXd0ICAgMHhmZmZmZmYwMDA2NDM3MDAwIFt2bmxydV0KICAgMTgg ICAgIDAgICAgIDAgICAgIDAgIFJMICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFtz eW5jZXJdCiAgIDE3ICAgICAwICAgICAwICAgICAwICBSTCAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICBbYnVmZGFlbW9uXQogICAxNiAgICAgMCAgICAgMCAgICAgMCAgU0wgICAgICBw Z3plcm8gICAweGZmZmZmZmZmODA4Njg0NGMgW3BhZ2V6ZXJvXQogICAgOSAgICAgMCAgICAgMCAg ICAgMCAgU0wgICAgICBwc2xlZXAgICAweGZmZmZmZmZmODA4Njc3ZTggW3ZtZGFlbW9uXQogICAg OCAgICAgMCAgICAgMCAgICAgMCAgU0wgICAgICBwc2xlZXAgICAweGZmZmZmZmZmODA4Njc3YWMg W3BhZ2VkYWVtb25dCiAgIDE1ICAgICAwICAgICAwICAgICAwICBTTCAgICAgIElQUlQgRXZlIDB4 ZmZmZmZmMDAwNjI0MGM5MCBbVElNRVJdCiAgICA3ICAgICAwICAgICAwICAgICAwICBSTCAgICAg ICh0aHJlYWRlZCkgICAgICAgICAgICAgICAgICB6ZnNrZXJuCjEwMDExMSAgICAgICAgICAgICAg ICAgICBSdW5RICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBbdHhnX3RocmVhZF9lbnRl cl0KMTAwMTEwICAgICAgICAgICAgICAgICAgIEQgICAgICAgdHgtPnR4X3EgMHhmZmZmZmYwMDA2 NmZkMjYwIFt0eGdfdGhyZWFkX2VudGVyXQoxMDAxMDggICAgICAgICAgICAgICAgICAgRCAgICAg ICB2Z2VvbTppbyAweGZmZmZmZjAwMDY0ZjBhOTAgW3ZkZXYgZ3B0L2Rpc2sxXQoxMDAxMDcgICAg ICAgICAgICAgICAgICAgRCAgICAgICB2Z2VvbTppbyAweGZmZmZmZjAwMDY0ZjBkMTAgW3ZkZXYg Z3B0L2Rpc2swXQoxMDAwNjkgICAgICAgICAgICAgICAgICAgUnVuUSAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgW2wyYXJjX2ZlZWRfdGhyZWFkXQoxMDAwNjggICAgICAgICAgICAgICAg ICAgUnVuUSAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgW2FyY19yZWNsYWltX3RocmVh ZF0KICAgIDYgICAgIDAgICAgIDAgICAgIDAgIFJMICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgIFtmZGMwXQogICAxNCAgICAgMCAgICAgMCAgICAgMCAgUkwgICAgICAodGhyZWFkZWQp ICAgICAgICAgICAgICAgICAgdXNiCjEwMDA2MyAgICAgICAgICAgICAgICAgICBSdW5RICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICBbdXNidXM2XQoxMDAwNjIgICAgICAgICAgICAgICAg ICAgRCAgICAgICBXQ1RSTCAgICAweGZmZmZmZjAwMDYzYTAwYjAgW3VzYnVzNl0KMTAwMDYxICAg ICAgICAgICAgICAgICAgIEQgICAgICAgLSAgICAgICAgMHhmZmZmZmY4MDAwNDAwZDIwIFt1c2J1 czZdCjEwMDA2MCAgICAgICAgICAgICAgICAgICBEICAgICAgIC0gICAgICAgIDB4ZmZmZmZmODAw MDQwMGNjOCBbdXNidXM2XQoxMDAwNTkgICAgICAgICAgICAgICAgICAgRCAgICAgICAtICAgICAg ICAweGZmZmZmZjgwMDAzZjdlZjAgW3VzYnVzNV0KMTAwMDU4ICAgICAgICAgICAgICAgICAgIEQg ICAgICAgLSAgICAgICAgMHhmZmZmZmY4MDAwM2Y3ZTk4IFt1c2J1czVdCjEwMDA1NyAgICAgICAg ICAgICAgICAgICBEICAgICAgIC0gICAgICAgIDB4ZmZmZmZmODAwMDNmN2U0MCBbdXNidXM1XQox MDAwNTYgICAgICAgICAgICAgICAgICAgRCAgICAgICAtICAgICAgICAweGZmZmZmZjgwMDAzZjdk ZTggW3VzYnVzNV0KMTAwMDU1ICAgICAgICAgICAgICAgICAgIEQgICAgICAgLSAgICAgICAgMHhm ZmZmZmY4MDAwM2VlZWYwIFt1c2J1czRdCjEwMDA1NCAgICAgICAgICAgICAgICAgICBEICAgICAg IC0gICAgICAgIDB4ZmZmZmZmODAwMDNlZWU5OCBbdXNidXM0XQoxMDAwNTMgICAgICAgICAgICAg ICAgICAgRCAgICAgICAtICAgICAgICAweGZmZmZmZjgwMDAzZWVlNDAgW3VzYnVzNF0KMTAwMDUy ICAgICAgICAgICAgICAgICAgIEQgICAgICAgLSAgICAgICAgMHhmZmZmZmY4MDAwM2VlZGU4IFt1 c2J1czRdCjEwMDA1MSAgICAgICAgICAgICAgICAgICBEICAgICAgIC0gICAgICAgIDB4ZmZmZmZm ODAwMDNlNWVmMCBbdXNidXMzXQoxMDAwNTAgICAgICAgICAgICAgICAgICAgRCAgICAgICAtICAg ICAgICAweGZmZmZmZjgwMDAzZTVlOTggW3VzYnVzM10KMTAwMDQ5ICAgICAgICAgICAgICAgICAg IEQgICAgICAgLSAgICAgICAgMHhmZmZmZmY4MDAwM2U1ZTQwIFt1c2J1czNdCjEwMDA0OCAgICAg ICAgICAgICAgICAgICBEICAgICAgIC0gICAgICAgIDB4ZmZmZmZmODAwMDNlNWRlOCBbdXNidXMz XQoxMDAwNDUgICAgICAgICAgICAgICAgICAgRCAgICAgICAtICAgICAgICAweGZmZmZmZjgwMDAz ZGNkZDAgW3VzYnVzMl0KMTAwMDQ0ICAgICAgICAgICAgICAgICAgIEQgICAgICAgLSAgICAgICAg MHhmZmZmZmY4MDAwM2RjZDc4IFt1c2J1czJdCjEwMDA0MyAgICAgICAgICAgICAgICAgICBEICAg ICAgIC0gICAgICAgIDB4ZmZmZmZmODAwMDNkY2QyMCBbdXNidXMyXQoxMDAwNDIgICAgICAgICAg ICAgICAgICAgRCAgICAgICAtICAgICAgICAweGZmZmZmZjgwMDAzZGNjYzggW3VzYnVzMl0KMTAw MDQwICAgICAgICAgICAgICAgICAgIEQgICAgICAgLSAgICAgICAgMHhmZmZmZmY4MDAwM2QzZWYw IFt1c2J1czFdCjEwMDAzOSAgICAgICAgICAgICAgICAgICBMICAgICAgKnVoY2kxICAgIDB4ZmZm ZmZmMDAwMTYxZTBjMCBbdXNidXMxXQoxMDAwMzggICAgICAgICAgICAgICAgICAgRCAgICAgICAt ICAgICAgICAweGZmZmZmZjgwMDAzZDNlNDAgW3VzYnVzMV0KMTAwMDM3ICAgICAgICAgICAgICAg ICAgIEQgICAgICAgLSAgICAgICAgMHhmZmZmZmY4MDAwM2QzZGU4IFt1c2J1czFdCjEwMDAzNSAg ICAgICAgICAgICAgICAgICBEICAgICAgIC0gICAgICAgIDB4ZmZmZmZmODAwMDNjYWVmMCBbdXNi dXMwXQoxMDAwMzQgICAgICAgICAgICAgICAgICAgRCAgICAgICAtICAgICAgICAweGZmZmZmZjgw MDAzY2FlOTggW3VzYnVzMF0KMTAwMDMzICAgICAgICAgICAgICAgICAgIEQgICAgICAgLSAgICAg ICAgMHhmZmZmZmY4MDAwM2NhZTQwIFt1c2J1czBdCjEwMDAzMiAgICAgICAgICAgICAgICAgICBE ICAgICAgIC0gICAgICAgIDB4ZmZmZmZmODAwMDNjYWRlOCBbdXNidXMwXQogICAgNSAgICAgMCAg ICAgMCAgICAgMCAgU0wgICAgICBjY2Jfc2NhbiAweGZmZmZmZmZmODA4MTZjZTAgW3hwdF90aHJk XQogICAxMyAgICAgMCAgICAgMCAgICAgMCAgUkwgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgW3lhcnJvd10KICAgIDQgICAgIDAgICAgIDAgICAgIDAgIFNMICAgICAgLSAgICAgICAg MHhmZmZmZmZmZjgwODJlZTA4IFtnX2Rvd25dCiAgICAzICAgICAwICAgICAwICAgICAwICBTTCAg ICAgIC0gICAgICAgIDB4ZmZmZmZmZmY4MDgyZWUwMCBbZ191cF0KICAgIDIgICAgIDAgICAgIDAg ICAgIDAgIFJMICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFtnX2V2ZW50XQogICAx MiAgICAgMCAgICAgMCAgICAgMCAgUkwgICAgICAodGhyZWFkZWQpICAgICAgICAgICAgICAgICAg aW50cgoxMDAwNjcgICAgICAgICAgICAgICAgICAgSSAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgW2lycTE6IGF0a2JkMF0KMTAwMDY2ICAgICAgICAgICAgICAgICAgIEkgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgIFtzd2kwOiB1YXJ0XQoxMDAwNjQgICAgICAgICAg ICAgICAgICAgSSAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgW2lycTI1ODogYWhj aTBdCjEwMDA0NyAgICAgICAgICAgICAgICAgICBJICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICBbaXJxMjM6IHVoY2kyIGVoY2kxXQoxMDAwNDYgICAgICAgICAgICAgICAgICAgUnVu USAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgW2lycTI1NzogaGRhYzBdCjEwMDA0MSAg ICAgICAgICAgICAgICAgICBJICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBbaXJx MjI6IGVoY2kwXQoxMDAwMzYgICAgICAgICAgICAgICAgICAgSSAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgW2lycTE3OiB1aGNpMSB1aGNpM10KMTAwMDMxICAgICAgICAgICAgICAg ICAgIEkgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFtpcnExNjogdWhjaTArXQox MDAwMjkgICAgICAgICAgICAgICAgICAgSSAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgW2lycTE4OiBybDAgYXRhcGNpMCtdCjEwMDAyOCAgICAgICAgICAgICAgICAgICBJICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICBbaXJxOTogYWNwaTBdCjEwMDAyNyAgICAgICAg ICAgICAgICAgICBJICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBbc3dpMjogY2Ft YmlvXQoxMDAwMjUgICAgICAgICAgICAgICAgICAgSSAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgW3N3aTY6IHRhc2sgcXVldWVdCjEwMDAyNCAgICAgICAgICAgICAgICAgICBJICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBbc3dpNjogR2lhbnQgdGFza3FdCjEwMDAy MiAgICAgICAgICAgICAgICAgICBSdW4gICAgIENQVSAyICAgICAgICAgICAgICAgICAgICAgICBb c3dpNTogK10KMTAwMDEyICAgICAgICAgICAgICAgICAgIEkgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgIFtzd2k0OiBjbG9ja10KMTAwMDExICAgICAgICAgICAgICAgICAgIEkgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFtzd2k0OiBjbG9ja10KMTAwMDEwICAgICAg ICAgICAgICAgICAgIEkgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFtzd2k0OiBj bG9ja10KMTAwMDA5ICAgICAgICAgICAgICAgICAgIFJ1blEgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgIFtzd2k0OiBjbG9ja10KMTAwMDA4ICAgICAgICAgICAgICAgICAgIEkgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgIFtzd2kxOiBuZXRpc3IgMF0KMTAwMDA3ICAgICAg ICAgICAgICAgICAgIEkgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFtzd2kzOiB2 bV0KICAgMTEgICAgIDAgICAgIDAgICAgIDAgIFJMICAgICAgKHRocmVhZGVkKSAgICAgICAgICAg ICAgICAgIGlkbGUKMTAwMDA2ICAgICAgICAgICAgICAgICAgIENhblJ1biAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgIFtpZGxlOiBjcHUwXQoxMDAwMDUgICAgICAgICAgICAgICAgICAgQ2Fu UnVuICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgW2lkbGU6IGNwdTFdCjEwMDAwNCAgICAg ICAgICAgICAgICAgICBDYW5SdW4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICBbaWRsZTog Y3B1Ml0KMTAwMDAzICAgICAgICAgICAgICAgICAgIENhblJ1biAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgIFtpZGxlOiBjcHUzXQogICAgMSAgICAgMCAgICAgMSAgICAgMCAgU0xzICAgICB3 YWl0ICAgICAweGZmZmZmZjAwMDE4NWQ4YzAgW2luaXRdCiAgIDEwICAgICAwICAgICAwICAgICAw ICBTTCAgICAgIGF1ZGl0X3dvIDB4ZmZmZmZmZmY4MDg2NWQxMCBbYXVkaXRdCiAgICAwICAgICAw ICAgICAwICAgICAwICBTTHMgICAgICh0aHJlYWRlZCkgICAgICAgICAgICAgICAgICBrZXJuZWwK MTAwMTQ1ICAgICAgICAgICAgICAgICAgIEQgICAgICAgLSAgICAgICAgMHhmZmZmZmYwMDA2Yjk1 NjgwIFt6aWxfY2xlYW5dCjEwMDE0NCAgICAgICAgICAgICAgICAgICBEICAgICAgIC0gICAgICAg IDB4ZmZmZmZmMDAwNmI5NWQ4MCBbemlsX2NsZWFuXQoxMDAxNDMgICAgICAgICAgICAgICAgICAg RCAgICAgICAtICAgICAgICAweGZmZmZmZjAwMDZiOTY1ODAgW3ppbF9jbGVhbl0KMTAwMTQyICAg ICAgICAgICAgICAgICAgIEQgICAgICAgLSAgICAgICAgMHhmZmZmZmYwMDA2YjU3ZDgwIFt6aWxf Y2xlYW5dCjEwMDE0MSAgICAgICAgICAgICAgICAgICBEICAgICAgIC0gICAgICAgIDB4ZmZmZmZm MDAwNmI2NjU4MCBbemlsX2NsZWFuXQoxMDAxNDAgICAgICAgICAgICAgICAgICAgRCAgICAgICAt ICAgICAgICAweGZmZmZmZjAwMDZiNjZjMDAgW3ppbF9jbGVhbl0KMTAwMTM5ICAgICAgICAgICAg ICAgICAgIEQgICAgICAgLSAgICAgICAgMHhmZmZmZmYwMDA2YjY4MDAwIFt6aWxfY2xlYW5dCjEw MDEzOCAgICAgICAgICAgICAgICAgICBEICAgICAgIC0gICAgICAgIDB4ZmZmZmZmMDAwNmI2ODY4 MCBbemlsX2NsZWFuXQoxMDAxMzcgICAgICAgICAgICAgICAgICAgRCAgICAgICAtICAgICAgICAw eGZmZmZmZjAwMDZiNjk5ODAgW3ppbF9jbGVhbl0KMTAwMTM2ICAgICAgICAgICAgICAgICAgIEQg ICAgICAgLSAgICAgICAgMHhmZmZmZmYwMDA2YjE0YTgwIFt6aWxfY2xlYW5dCjEwMDEzNSAgICAg ICAgICAgICAgICAgICBEICAgICAgIC0gICAgICAgIDB4ZmZmZmZmMDAwNmI1NDM4MCBbemlsX2Ns ZWFuXQoxMDAxMzQgICAgICAgICAgICAgICAgICAgRCAgICAgICAtICAgICAgICAweGZmZmZmZjAw MDZiNTRiMDAgW3ppbF9jbGVhbl0KMTAwMTMzICAgICAgICAgICAgICAgICAgIEQgICAgICAgLSAg ICAgICAgMHhmZmZmZmYwMDA2YjEzMzgwIFt6aWxfY2xlYW5dCjEwMDEzMiAgICAgICAgICAgICAg ICAgICBEICAgICAgIC0gICAgICAgIDB4ZmZmZmZmMDAwNmIxMjU4MCBbemlsX2NsZWFuXQoxMDAx MzEgICAgICAgICAgICAgICAgICAgRCAgICAgICAtICAgICAgICAweGZmZmZmZjAwMDZiMTEwODAg W3ppbF9jbGVhbl0KMTAwMTMwICAgICAgICAgICAgICAgICAgIEQgICAgICAgLSAgICAgICAgMHhm ZmZmZmYwMDA2YjEwMjgwIFt6aWxfY2xlYW5dCjEwMDExMiAgICAgICAgICAgICAgICAgICBEICAg ICAgIC0gICAgICAgIDB4ZmZmZmZmMDAwNjQyODAwMCBbemlsX2NsZWFuXQoxMDAxMDkgICAgICAg ICAgICAgICAgICAgRCAgICAgICAtICAgICAgICAweGZmZmZmZjAwMDY0NDIzMDAgW3pmc192bl9y ZWxlX3Rhc2txXQoxMDAxMDYgICAgICAgICAgICAgICAgICAgRCAgICAgICAtICAgICAgICAweGZm ZmZmZjAwMDY2NWIxMDAgW3NwYV96aW9dCjEwMDEwNSAgICAgICAgICAgICAgICAgICBEICAgICAg IC0gICAgICAgIDB4ZmZmZmZmMDAwNjY1YjE4MCBbc3BhX3ppb10KMTAwMTA0ICAgICAgICAgICAg ICAgICAgIEQgICAgICAgLSAgICAgICAgMHhmZmZmZmYwMDA2NjViMjAwIFtzcGFfemlvXQoxMDAx MDMgICAgICAgICAgICAgICAgICAgRCAgICAgICAtICAgICAgICAweGZmZmZmZjAwMDY2NWIyODAg W3NwYV96aW9dCjEwMDEwMiAgICAgICAgICAgICAgICAgICBEICAgICAgIC0gICAgICAgIDB4ZmZm ZmZmMDAwNjY1YjMwMCBbc3BhX3ppb10KMTAwMTAxICAgICAgICAgICAgICAgICAgIEQgICAgICAg LSAgICAgICAgMHhmZmZmZmYwMDA2NjViMzgwIFtzcGFfemlvXQoxMDAxMDAgICAgICAgICAgICAg ICAgICAgRCAgICAgICAtICAgICAgICAweGZmZmZmZjAwMDY2NWI0MDAgW3NwYV96aW9dCjEwMDA5 OSAgICAgICAgICAgICAgICAgICBEICAgICAgIC0gICAgICAgIDB4ZmZmZmZmMDAwNjY1YjQ4MCBb c3BhX3ppb183XQoxMDAwOTggICAgICAgICAgICAgICAgICAgRCAgICAgICAtICAgICAgICAweGZm ZmZmZjAwMDY2NWI0ODAgW3NwYV96aW9fNl0KMTAwMDk3ICAgICAgICAgICAgICAgICAgIEQgICAg ICAgLSAgICAgICAgMHhmZmZmZmYwMDA2NjViNDgwIFtzcGFfemlvXzVdCjEwMDA5NiAgICAgICAg ICAgICAgICAgICBEICAgICAgIC0gICAgICAgIDB4ZmZmZmZmMDAwNjY1YjQ4MCBbc3BhX3ppb180 XQoxMDAwOTUgICAgICAgICAgICAgICAgICAgRCAgICAgICAtICAgICAgICAweGZmZmZmZjAwMDY2 NWI0ODAgW3NwYV96aW9fM10KMTAwMDk0ICAgICAgICAgICAgICAgICAgIEQgICAgICAgLSAgICAg ICAgMHhmZmZmZmYwMDA2NjViNDgwIFtzcGFfemlvXzJdCjEwMDA5MyAgICAgICAgICAgICAgICAg ICBEICAgICAgIC0gICAgICAgIDB4ZmZmZmZmMDAwNjY1YjQ4MCBbc3BhX3ppb18xXQoxMDAwOTIg ICAgICAgICAgICAgICAgICAgRCAgICAgICAtICAgICAgICAweGZmZmZmZjAwMDY2NWI0ODAgW3Nw YV96aW9fMF0KMTAwMDkxICAgICAgICAgICAgICAgICAgIEQgICAgICAgLSAgICAgICAgMHhmZmZm ZmYwMDA2NjViNTAwIFtzcGFfemlvXzddCjEwMDA5MCAgICAgICAgICAgICAgICAgICBEICAgICAg IC0gICAgICAgIDB4ZmZmZmZmMDAwNjY1YjUwMCBbc3BhX3ppb182XQoxMDAwODkgICAgICAgICAg ICAgICAgICAgRCAgICAgICAtICAgICAgICAweGZmZmZmZjAwMDY2NWI1MDAgW3NwYV96aW9fNV0K MTAwMDg4ICAgICAgICAgICAgICAgICAgIEQgICAgICAgLSAgICAgICAgMHhmZmZmZmYwMDA2NjVi NTAwIFtzcGFfemlvXzRdCjEwMDA4NyAgICAgICAgICAgICAgICAgICBEICAgICAgIC0gICAgICAg IDB4ZmZmZmZmMDAwNjY1YjUwMCBbc3BhX3ppb18zXQoxMDAwODYgICAgICAgICAgICAgICAgICAg RCAgICAgICAtICAgICAgICAweGZmZmZmZjAwMDY2NWI1MDAgW3NwYV96aW9fMl0KMTAwMDg1ICAg ICAgICAgICAgICAgICAgIEQgICAgICAgLSAgICAgICAgMHhmZmZmZmYwMDA2NjViNTAwIFtzcGFf emlvXzFdCjEwMDA4NCAgICAgICAgICAgICAgICAgICBEICAgICAgIC0gICAgICAgIDB4ZmZmZmZm MDAwNjY1YjUwMCBbc3BhX3ppb18wXQoxMDAwODMgICAgICAgICAgICAgICAgICAgRCAgICAgICAt ICAgICAgICAweGZmZmZmZjAwMDY2NWI1ODAgW3NwYV96aW9dCjEwMDA4MiAgICAgICAgICAgICAg ICAgICBEICAgICAgIC0gICAgICAgIDB4ZmZmZmZmMDAwNjY1YjYwMCBbc3BhX3ppb10KMTAwMDgx ICAgICAgICAgICAgICAgICAgIEQgICAgICAgLSAgICAgICAgMHhmZmZmZmYwMDA2NjViNjgwIFtz cGFfemlvXQoxMDAwNzEgICAgICAgICAgICAgICAgICAgRCAgICAgICAtICAgICAgICAweGZmZmZm ZjAwMDYyOTdiODAgW2R1bW15bmV0XQoxMDAwMzAgICAgICAgICAgICAgICAgICAgRCAgICAgICAt ICAgICAgICAweGZmZmZmZjAwMDE5YWMwMDAgW2VtMCB0YXNrcV0KMTAwMDIzICAgICAgICAgICAg ICAgICAgIEQgICAgICAgLSAgICAgICAgMHhmZmZmZmYwMDAxOTNkMzgwIFt0aHJlYWQgdGFza3Fd CjEwMDAyMSAgICAgICAgICAgICAgICAgICBEICAgICAgIC0gICAgICAgIDB4ZmZmZmZmMDAwMThm MmQwMCBba3F1ZXVlIHRhc2txXQoxMDAwMjAgICAgICAgICAgICAgICAgICAgRCAgICAgICAtICAg ICAgICAweGZmZmZmZjAwMDE4ZjJjMDAgW2FjcGlfdGFza18yXQoxMDAwMTkgICAgICAgICAgICAg ICAgICAgRCAgICAgICAtICAgICAgICAweGZmZmZmZjAwMDE4ZjJjMDAgW2FjcGlfdGFza18xXQox MDAwMTggICAgICAgICAgICAgICAgICAgRCAgICAgICAtICAgICAgICAweGZmZmZmZjAwMDE4ZjJj MDAgW2FjcGlfdGFza18wXQoxMDAwMTYgICAgICAgICAgICAgICAgICAgRCAgICAgICAtICAgICAg ICAweGZmZmZmZjAwMDE4NWE2ODAgW2Zpcm13YXJlIHRhc2txXQoxMDAwMDAgICAgICAgICAgICAg ICAgICAgRCAgICAgICBzY2hlZCAgICAweGZmZmZmZmZmODA4MmVmMDAgW3N3YXBwZXJdCmRiOjA6 a2RiLmVudGVyLnBhbmljPiAgYWxsdHJhY2UKClRyYWNpbmcgY29tbWFuZCBzaCBwaWQgNzAwNDMg dGlkIDEwMDMzMyB0ZCAweGZmZmZmZjAxOWE3NDFhZTAKY3B1c3RvcF9oYW5kbGVyKCkgYXQgY3B1 c3RvcF9oYW5kbGVyKzB4NDAKaXBpX25taV9oYW5kbGVyKCkgYXQgaXBpX25taV9oYW5kbGVyKzB4 MzAKdHJhcCgpIGF0IHRyYXArMHgxOTUKbm1pX2NhbGx0cmFwKCkgYXQgbm1pX2NhbGx0cmFwKzB4 OAotLS0gdHJhcCAweDEzLCByaXAgPSAweGZmZmZmZmZmODA1YTBhY2IsIHJzcCA9IDB4ZmZmZmZm ODAwMDAyM2ZlMCwgcmJwID0gMHhmZmZmZmY4MGU4ZWRmNDIwIC0tLQpzbXBfdGxiX3Nob290ZG93 bigpIGF0IHNtcF90bGJfc2hvb3Rkb3duKzB4OWIKcG1hcF9pbnZhbGlkYXRlX3BhZ2UoKSBhdCBw bWFwX2ludmFsaWRhdGVfcGFnZSsweDdiCnBtYXBfcmVtb3ZlX3B0ZSgpIGF0IHBtYXBfcmVtb3Zl X3B0ZSsweGVmCnBtYXBfcmVtb3ZlKCkgYXQgcG1hcF9yZW1vdmUrMHgyZDQKdm1fbWFwX2RlbGV0 ZSgpIGF0IHZtX21hcF9kZWxldGUrMHhmNAp2bV9tYXBfcmVtb3ZlKCkgYXQgdm1fbWFwX3JlbW92 ZSsweDUxCnVtYV9sYXJnZV9mcmVlKCkgYXQgdW1hX2xhcmdlX2ZyZWUrMHg1NQpmcmVlKCkgYXQg ZnJlZSsweDc3CmFyY19idWZfZGVzdHJveSgpIGF0IGFyY19idWZfZGVzdHJveSsweDEwMQphcmNf aGRyX2Rlc3Ryb3koKSBhdCBhcmNfaGRyX2Rlc3Ryb3krMHgyMjUKYXJjX2J1Zl9yZW1vdmVfcmVm KCkgYXQgYXJjX2J1Zl9yZW1vdmVfcmVmKzB4ZWMKZGJ1Zl9uZXdfc2l6ZSgpIGF0IGRidWZfbmV3 X3NpemUrMHhkOApkbm9kZV9zZXRfYmxrc3ooKSBhdCBkbm9kZV9zZXRfYmxrc3orMHgyYWUKZG11 X29iamVjdF9zZXRfYmxvY2tzaXplKCkgYXQgZG11X29iamVjdF9zZXRfYmxvY2tzaXplKzB4NGMK emZzX2dyb3dfYmxvY2tzaXplKCkgYXQgemZzX2dyb3dfYmxvY2tzaXplKzB4NDUKemZzX2ZyZWVi c2Rfd3JpdGUoKSBhdCB6ZnNfZnJlZWJzZF93cml0ZSsweDlkMwpWT1BfV1JJVEVfQVBWKCkgYXQg Vk9QX1dSSVRFX0FQVisweGM2CnZuX3dyaXRlKCkgYXQgdm5fd3JpdGUrMHgyZDcKZG9maWxld3Jp dGUoKSBhdCBkb2ZpbGV3cml0ZSsweDg1Cmtlcm5fd3JpdGV2KCkgYXQga2Vybl93cml0ZXYrMHg2 MAp3cml0ZSgpIGF0IHdyaXRlKzB4NTUKc3lzY2FsbCgpIGF0IHN5c2NhbGwrMHgyOGYKWGZhc3Rf c3lzY2FsbCgpIGF0IFhmYXN0X3N5c2NhbGwrMHhlMQotLS0gc3lzY2FsbCAoNCwgRnJlZUJTRCBF TEY2NCwgd3JpdGUpLCByaXAgPSAweDgwMDliY2EzYywgcnNwID0gMHg3ZmZmZmZmZmFlOTgsIHJi cCA9IDB4ODAwYzFjMDAwIC0tLQoKVHJhY2luZyBjb21tYW5kIFZCb3hTVkMgcGlkIDg4MjY3IHRp ZCAxMDA0MDMgdGQgMHhmZmZmZmYwMDgxMTU5M2EwCnNjaGVkX3N3aXRjaCgpIGF0IHNjaGVkX3N3 aXRjaCsweDEwOAptaV9zd2l0Y2goKSBhdCBtaV9zd2l0Y2grMHgxNmYKc2xlZXBxX2NhdGNoX3Np Z25hbHMoKSBhdCBzbGVlcHFfY2F0Y2hfc2lnbmFscysweDMxZgpzbGVlcHFfd2FpdF9zaWcoKSBh dCBzbGVlcHFfd2FpdF9zaWcrMHhjCl9zbGVlcCgpIGF0IF9zbGVlcCsweDI2Ygpkb19jdl93YWl0 KCkgYXQgZG9fY3Zfd2FpdCsweDg3MQpfX3VtdHhfb3BfY3Zfd2FpdCgpIGF0IF9fdW10eF9vcF9j dl93YWl0KzB4NWMKc3lzY2FsbCgpIGF0IHN5c2NhbGwrMHgyOGYKWGZhc3Rfc3lzY2FsbCgpIGF0 IFhmYXN0X3N5c2NhbGwrMHhlMQotLS0gc3lzY2FsbCAoNDU0LCBGcmVlQlNEIEVMRjY0LCBfdW10 eF9vcCksIHJpcCA9IDB4ODAxMzQ2MjljLCByc3AgPSAweDdmZmZmZjliOGRmOCwgcmJwID0gMHg4 MDI0M2MzYzAgLS0tCgpUcmFjaW5nIGNvbW1hbmQgVkJveFNWQyBwaWQgODgyNjcgdGlkIDEwMDQw MiB0ZCAweGZmZmZmZjAwOTlhNTgwMDAKc2NoZWRfc3dpdGNoKCkgYXQgc2NoZWRfc3dpdGNoKzB4 MTA4Cm1pX3N3aXRjaCgpIGF0IG1pX3N3aXRjaCsweDE2ZgpzbGVlcHFfY2F0Y2hfc2lnbmFscygp IGF0IHNsZWVwcV9jYXRjaF9zaWduYWxzKzB4MzFmCnNsZWVwcV93YWl0X3NpZygpIGF0IHNsZWVw cV93YWl0X3NpZysweGMKX3NsZWVwKCkgYXQgX3NsZWVwKzB4MjZiCmRvX2N2X3dhaXQoKSBhdCBk b19jdl93YWl0KzB4ODcxCl9fdW10eF9vcF9jdl93YWl0KCkgYXQgX191bXR4X29wX2N2X3dhaXQr MHg1YwpzeXNjYWxsKCkgYXQgc3lzY2FsbCsweDI4ZgpYZmFzdF9zeXNjYWxsKCkgYXQgWGZhc3Rf c3lzY2FsbCsweGUxCi0tLSBzeXNjYWxsICg0NTQsIEZyZWVCU0QgRUxGNjQsIF91bXR4X29wKSwg cmlwID0gMHg4MDEzNDYyOWMsIHJzcCA9IDB4N2ZmZmZmYTM5ZDc4LCByYnAgPSAweDgwMjQzYzU4 MCAtLS0KClRyYWNpbmcgY29tbWFuZCBWQm94U1ZDIHBpZCA4ODI2NyB0aWQgMTAwNDAxIHRkIDB4 ZmZmZmZmMDAyZGFjMjNhMApzY2hlZF9zd2l0Y2goKSBhdCBzY2hlZF9zd2l0Y2grMHgxMDgKbWlf c3dpdGNoKCkgYXQgbWlfc3dpdGNoKzB4MTZmCnNsZWVwcV9jYXRjaF9zaWduYWxzKCkgYXQgc2xl ZXBxX2NhdGNoX3NpZ25hbHMrMHgzMWYKc2xlZXBxX3RpbWVkd2FpdF9zaWcoKSBhdCBzbGVlcHFf dGltZWR3YWl0X3NpZysweDE5Cl9zbGVlcCgpIGF0IF9zbGVlcCsweDFhMwpkb19jdl93YWl0KCkg YXQgZG9fY3Zfd2FpdCsweDY0MApfX3VtdHhfb3BfY3Zfd2FpdCgpIGF0IF9fdW10eF9vcF9jdl93 YWl0KzB4NWMKc3lzY2FsbCgpIGF0IHN5c2NhbGwrMHgyOGYKWGZhc3Rfc3lzY2FsbCgpIGF0IFhm YXN0X3N5c2NhbGwrMHhlMQotLS0gc3lzY2FsbCAoNDU0LCBGcmVlQlNEIEVMRjY0LCBfdW10eF9v cCksIHJpcCA9IDB4ODAxMzQ2MjljLCByc3AgPSAweDdmZmZmZmFiYWNjOCwgcmJwID0gMHg4MDI0 M2M3NDAgLS0tCgpUcmFjaW5nIGNvbW1hbmQgVkJveFNWQyBwaWQgODgyNjcgdGlkIDEwMDQwMCB0 ZCAweGZmZmZmZjAxOWE3MzZhZTAKc2NoZWRfc3dpdGNoKCkgYXQgc2NoZWRfc3dpdGNoKzB4MTA4 Cm1pX3N3aXRjaCgpIGF0IG1pX3N3aXRjaCsweDE2ZgpzbGVlcHFfY2F0Y2hfc2lnbmFscygpIGF0 IHNsZWVwcV9jYXRjaF9zaWduYWxzKzB4MzFmCnNsZWVwcV90aW1lZHdhaXRfc2lnKCkgYXQgc2xl ZXBxX3RpbWVkd2FpdF9zaWcrMHgxOQpfc2xlZXAoKSBhdCBfc2xlZXArMHgxYTMKZG9fY3Zfd2Fp dCgpIGF0IGRvX2N2X3dhaXQrMHg2NDAKX191bXR4X29wX2N2X3dhaXQoKSBhdCBfX3VtdHhfb3Bf Y3Zfd2FpdCsweDVjCnN5c2NhbGwoKSBhdCBzeXNjYWxsKzB4MjhmClhmYXN0X3N5c2NhbGwoKSBh dCBYZmFzdF9zeXNjYWxsKzB4ZTEKLS0tIHN5c2NhbGwgKDQ1NCwgRnJlZUJTRCBFTEY2NCwgX3Vt dHhfb3ApLCByaXAgPSAweDgwMTM0NjI5YywgcnNwID0gMHg3ZmZmZmZiM2JlMjgsIHJicCA9IDB4 ODAyNDNjYWMwIC0tLQoKVHJhY2luZyBjb21tYW5kIFZCb3hTVkMgcGlkIDg4MjY3IHRpZCAxMDAz OTkgdGQgMHhmZmZmZmYwMTMwYjM1NzQwCnNjaGVkX3N3aXRjaCgpIGF0IHNjaGVkX3N3aXRjaCsw eDEwOAptaV9zd2l0Y2goKSBhdCBtaV9zd2l0Y2grMHgxNmYKc2xlZXBxX2NhdGNoX3NpZ25hbHMo KSBhdCBzbGVlcHFfY2F0Y2hfc2lnbmFscysweDMxZgpzbGVlcHFfd2FpdF9zaWcoKSBhdCBzbGVl cHFfd2FpdF9zaWcrMHhjCl9zbGVlcCgpIGF0IF9zbGVlcCsweDI2Ygpkb19jdl93YWl0KCkgYXQg ZG9fY3Zfd2FpdCsweDg3MQpfX3VtdHhfb3BfY3Zfd2FpdCgpIGF0IF9fdW10eF9vcF9jdl93YWl0 KzB4NWMKc3lzY2FsbCgpIGF0IHN5c2NhbGwrMHgyOGYKWGZhc3Rfc3lzY2FsbCgpIGF0IFhmYXN0 X3N5c2NhbGwrMHhlMQotLS0gc3lzY2FsbCAoNDU0LCBGcmVlQlNEIEVMRjY0LCBfdW10eF9vcCks IHJpcCA9IDB4ODAxMzQ2MjljLCByc3AgPSAweDdmZmZmZmJiY2UyOCwgcmJwID0gMHg4MDIwOTYx YzAgLS0tCgpUcmFjaW5nIGNvbW1hbmQgVkJveFNWQyBwaWQgODgyNjcgdGlkIDEwMDM5OCB0ZCAw eGZmZmZmZjAxMzBiMzUzYTAKc2NoZWRfc3dpdGNoKCkgYXQgc2NoZWRfc3dpdGNoKzB4MTA4Cm1p X3N3aXRjaCgpIGF0IG1pX3N3aXRjaCsweDE2ZgpzbGVlcHFfY2F0Y2hfc2lnbmFscygpIGF0IHNs ZWVwcV9jYXRjaF9zaWduYWxzKzB4MzFmCnNsZWVwcV93YWl0X3NpZygpIGF0IHNsZWVwcV93YWl0 X3NpZysweGMKX3NsZWVwKCkgYXQgX3NsZWVwKzB4MjZiCmRvX2N2X3dhaXQoKSBhdCBkb19jdl93 YWl0KzB4ODcxCl9fdW10eF9vcF9jdl93YWl0KCkgYXQgX191bXR4X29wX2N2X3dhaXQrMHg1Ywpz eXNjYWxsKCkgYXQgc3lzY2FsbCsweDI4ZgpYZmFzdF9zeXNjYWxsKCkgYXQgWGZhc3Rfc3lzY2Fs bCsweGUxCi0tLSBzeXNjYWxsICg0NTQsIEZyZWVCU0QgRUxGNjQsIF91bXR4X29wKSwgcmlwID0g MHg4MDEzNDYyOWMsIHJzcCA9IDB4N2ZmZmZmYmRkZGY4LCByYnAgPSAweDgwMjA5NjM4MCAtLS0K ClRyYWNpbmcgY29tbWFuZCBWQm94U1ZDIHBpZCA4ODI2NyB0aWQgMTAwMzk3IHRkIDB4ZmZmZmZm MDAwNmNiYWFlMApzY2hlZF9zd2l0Y2goKSBhdCBzY2hlZF9zd2l0Y2grMHgxMDgKbWlfc3dpdGNo KCkgYXQgbWlfc3dpdGNoKzB4MTZmCnNsZWVwcV9jYXRjaF9zaWduYWxzKCkgYXQgc2xlZXBxX2Nh dGNoX3NpZ25hbHMrMHgzMWYKc2xlZXBxX3dhaXRfc2lnKCkgYXQgc2xlZXBxX3dhaXRfc2lnKzB4 YwpfY3Zfd2FpdF9zaWcoKSBhdCBfY3Zfd2FpdF9zaWcrMHgxMjAKc2VsdGR3YWl0KCkgYXQgc2Vs dGR3YWl0KzB4ZjYKcG9sbCgpIGF0IHBvbGwrMHg0NTgKc3lzY2FsbCgpIGF0IHN5c2NhbGwrMHgy OGYKWGZhc3Rfc3lzY2FsbCgpIGF0IFhmYXN0X3N5c2NhbGwrMHhlMQotLS0gc3lzY2FsbCAoMjA5 LCBGcmVlQlNEIEVMRjY0LCBwb2xsKSwgcmlwID0gMHg4MDExOTkwMmMsIHJzcCA9IDB4N2ZmZmZm YmZlODQ4LCByYnAgPSAweDdmZmZmZmJmZTg5NCAtLS0KClRyYWNpbmcgY29tbWFuZCBWQm94U1ZD IHBpZCA4ODI2NyB0aWQgMTAwMzM2IHRkIDB4ZmZmZmZmMDE5YTc0MGFlMApzY2hlZF9zd2l0Y2go KSBhdCBzY2hlZF9zd2l0Y2grMHgxMDgKbWlfc3dpdGNoKCkgYXQgbWlfc3dpdGNoKzB4MTZmCnNs ZWVwcV9jYXRjaF9zaWduYWxzKCkgYXQgc2xlZXBxX2NhdGNoX3NpZ25hbHMrMHgzMWYKc2xlZXBx X3dhaXRfc2lnKCkgYXQgc2xlZXBxX3dhaXRfc2lnKzB4Ywpfc2xlZXAoKSBhdCBfc2xlZXArMHgy NmIKZG9fY3Zfd2FpdCgpIGF0IGRvX2N2X3dhaXQrMHg4NzEKX191bXR4X29wX2N2X3dhaXQoKSBh dCBfX3VtdHhfb3BfY3Zfd2FpdCsweDVjCnN5c2NhbGwoKSBhdCBzeXNjYWxsKzB4MjhmClhmYXN0 X3N5c2NhbGwoKSBhdCBYZmFzdF9zeXNjYWxsKzB4ZTEKLS0tIHN5c2NhbGwgKDQ1NCwgRnJlZUJT RCBFTEY2NCwgX3VtdHhfb3ApLCByaXAgPSAweDgwMTM0NjI5YywgcnNwID0gMHg3ZmZmZmZmZmU3 MjgsIHJicCA9IDB4ODAyMDA0MWMwIC0tLQoKVHJhY2luZyBjb21tYW5kIFZCb3hYUENPTUlQQ0Qg cGlkIDg4MjY0IHRpZCAxMDAzMTkgdGQgMHhmZmZmZmYwMTlhNGMxM2EwCnNjaGVkX3N3aXRjaCgp IGF0IHNjaGVkX3N3aXRjaCsweDEwOAptaV9zd2l0Y2goKSBhdCBtaV9zd2l0Y2grMHgxNmYKc2xl ZXBxX2NhdGNoX3NpZ25hbHMoKSBhdCBzbGVlcHFfY2F0Y2hfc2lnbmFscysweDMxZgpzbGVlcHFf dGltZWR3YWl0X3NpZygpIGF0IHNsZWVwcV90aW1lZHdhaXRfc2lnKzB4MTkKX2N2X3RpbWVkd2Fp dF9zaWcoKSBhdCBfY3ZfdGltZWR3YWl0X3NpZysweDEyOQpzZWx0ZHdhaXQoKSBhdCBzZWx0ZHdh aXQrMHg4ZApwb2xsKCkgYXQgcG9sbCsweDQ1OApzeXNjYWxsKCkgYXQgc3lzY2FsbCsweDI4ZgpY ZmFzdF9zeXNjYWxsKCkgYXQgWGZhc3Rfc3lzY2FsbCsweGUxCi0tLSBzeXNjYWxsICgyMDksIEZy ZWVCU0QgRUxGNjQsIHBvbGwpLCByaXAgPSAweDgwMTAwZTAyYywgcnNwID0gMHg3ZmZmZmZmZmU1 NDgsIHJicCA9IDB4NzA5YjZlZGMgLS0tCgpUcmFjaW5nIGNvbW1hbmQgVkJveEhlYWRsZXNzIHBp ZCA4ODI2MyB0aWQgMTAwNDE2IHRkIDB4ZmZmZmZmMDAzZjJkNGFlMApzY2hlZF9zd2l0Y2goKSBh dCBzY2hlZF9zd2l0Y2grMHgxMDgKbWlfc3dpdGNoKCkgYXQgbWlfc3dpdGNoKzB4MTZmCnNsZWVw cV9jYXRjaF9zaWduYWxzKCkgYXQgc2xlZXBxX2NhdGNoX3NpZ25hbHMrMHgzMWYKc2xlZXBxX3dh aXRfc2lnKCkgYXQgc2xlZXBxX3dhaXRfc2lnKzB4Ywpfc2xlZXAoKSBhdCBfc2xlZXArMHgyNmIK ZG9fY3Zfd2FpdCgpIGF0IGRvX2N2X3dhaXQrMHg4NzEKX191bXR4X29wX2N2X3dhaXQoKSBhdCBf X3VtdHhfb3BfY3Zfd2FpdCsweDVjCnN5c2NhbGwoKSBhdCBzeXNjYWxsKzB4MjhmClhmYXN0X3N5 c2NhbGwoKSBhdCBYZmFzdF9zeXNjYWxsKzB4ZTEKLS0tIHN5c2NhbGwgKDQ1NCwgRnJlZUJTRCBF TEY2NCwgX3VtdHhfb3ApLCByaXAgPSAweDgwMDY1YzI5YywgcnNwID0gMHg3ZmZmZmY1YWZkYjgs IHJicCA9IDB4ODAzMGYzMjAwIC0tLQoKVHJhY2luZyBjb21tYW5kIFZCb3hIZWFkbGVzcyBwaWQg ODgyNjMgdGlkIDEwMDQxNSB0ZCAweGZmZmZmZjAwM2YyZDUwMDAKc2NoZWRfc3dpdGNoKCkgYXQg c2NoZWRfc3dpdGNoKzB4MTA4Cm1pX3N3aXRjaCgpIGF0IG1pX3N3aXRjaCsweDE2ZgpzbGVlcHFf Y2F0Y2hfc2lnbmFscygpIGF0IHNsZWVwcV9jYXRjaF9zaWduYWxzKzB4MzFmCnNsZWVwcV93YWl0 X3NpZygpIGF0IHNsZWVwcV93YWl0X3NpZysweGMKX3NsZWVwKCkgYXQgX3NsZWVwKzB4MjZiCmRv X2N2X3dhaXQoKSBhdCBkb19jdl93YWl0KzB4ODcxCl9fdW10eF9vcF9jdl93YWl0KCkgYXQgX191 bXR4X29wX2N2X3dhaXQrMHg1YwpzeXNjYWxsKCkgYXQgc3lzY2FsbCsweDI4ZgpYZmFzdF9zeXNj YWxsKCkgYXQgWGZhc3Rfc3lzY2FsbCsweGUxCi0tLSBzeXNjYWxsICg0NTQsIEZyZWVCU0QgRUxG NjQsIF91bXR4X29wKSwgcmlwID0gMHg4MDA2NWMyOWMsIHJzcCA9IDB4N2ZmZmZmNWQwZGM4LCBy YnAgPSAweDgwMzBmMzNjMCAtLS0KClRyYWNpbmcgY29tbWFuZCBWQm94SGVhZGxlc3MgcGlkIDg4 MjYzIHRpZCAxMDA0MTQgdGQgMHhmZmZmZmYwMDNmMmQ1M2EwCnNjaGVkX3N3aXRjaCgpIGF0IHNj aGVkX3N3aXRjaCsweDEwOAptaV9zd2l0Y2goKSBhdCBtaV9zd2l0Y2grMHgxNmYKc2xlZXBxX2Nh dGNoX3NpZ25hbHMoKSBhdCBzbGVlcHFfY2F0Y2hfc2lnbmFscysweDMxZgpzbGVlcHFfd2FpdF9z aWcoKSBhdCBzbGVlcHFfd2FpdF9zaWcrMHhjCl9zbGVlcCgpIGF0IF9zbGVlcCsweDI2Ygpkb19j dl93YWl0KCkgYXQgZG9fY3Zfd2FpdCsweDg3MQpfX3VtdHhfb3BfY3Zfd2FpdCgpIGF0IF9fdW10 eF9vcF9jdl93YWl0KzB4NWMKc3lzY2FsbCgpIGF0IHN5c2NhbGwrMHgyOGYKWGZhc3Rfc3lzY2Fs bCgpIGF0IFhmYXN0X3N5c2NhbGwrMHhlMQotLS0gc3lzY2FsbCAoNDU0LCBGcmVlQlNEIEVMRjY0 LCBfdW10eF9vcCksIHJpcCA9IDB4ODAwNjVjMjljLCByc3AgPSAweDdmZmZmZjVmMWQzOCwgcmJw ID0gMHg4MDMwZjM3NDAgLS0tCgpUcmFjaW5nIGNvbW1hbmQgVkJveEhlYWRsZXNzIHBpZCA4ODI2 MyB0aWQgMTAwNDEzIHRkIDB4ZmZmZmZmMDAzZjJkNTc0MApzY2hlZF9zd2l0Y2goKSBhdCBzY2hl ZF9zd2l0Y2grMHgxMDgKbWlfc3dpdGNoKCkgYXQgbWlfc3dpdGNoKzB4MTZmCnNsZWVwcV9jYXRj aF9zaWduYWxzKCkgYXQgc2xlZXBxX2NhdGNoX3NpZ25hbHMrMHgzMWYKc2xlZXBxX3dhaXRfc2ln KCkgYXQgc2xlZXBxX3dhaXRfc2lnKzB4Ywpfc2xlZXAoKSBhdCBfc2xlZXArMHgyNmIKZG9fY3Zf d2FpdCgpIGF0IGRvX2N2X3dhaXQrMHg4NzEKX191bXR4X29wX2N2X3dhaXQoKSBhdCBfX3VtdHhf b3BfY3Zfd2FpdCsweDVjCnN5c2NhbGwoKSBhdCBzeXNjYWxsKzB4MjhmClhmYXN0X3N5c2NhbGwo KSBhdCBYZmFzdF9zeXNjYWxsKzB4ZTEKLS0tIHN5c2NhbGwgKDQ1NCwgRnJlZUJTRCBFTEY2NCwg X3VtdHhfb3ApLCByaXAgPSAweDgwMDY1YzI5YywgcnNwID0gMHg3ZmZmZmY2MTJkMzgsIHJicCA9 IDB4ODAzMGYzOTAwIC0tLQoKVHJhY2luZyBjb21tYW5kIFZCb3hIZWFkbGVzcyBwaWQgODgyNjMg dGlkIDEwMDQxMiB0ZCAweGZmZmZmZjAwOTlhNThhZTAKc2NoZWRfc3dpdGNoKCkgYXQgc2NoZWRf c3dpdGNoKzB4MTA4Cm1pX3N3aXRjaCgpIGF0IG1pX3N3aXRjaCsweDE2ZgpzbGVlcHFfY2F0Y2hf c2lnbmFscygpIGF0IHNsZWVwcV9jYXRjaF9zaWduYWxzKzB4MzFmCnNsZWVwcV93YWl0X3NpZygp IGF0IHNsZWVwcV93YWl0X3NpZysweGMKX3NsZWVwKCkgYXQgX3NsZWVwKzB4MjZiCmRvX2N2X3dh aXQoKSBhdCBkb19jdl93YWl0KzB4ODcxCl9fdW10eF9vcF9jdl93YWl0KCkgYXQgX191bXR4X29w X2N2X3dhaXQrMHg1YwpzeXNjYWxsKCkgYXQgc3lzY2FsbCsweDI4ZgpYZmFzdF9zeXNjYWxsKCkg YXQgWGZhc3Rfc3lzY2FsbCsweGUxCi0tLSBzeXNjYWxsICg0NTQsIEZyZWVCU0QgRUxGNjQsIF91 bXR4X29wKSwgcmlwID0gMHg4MDA2NWMyOWMsIHJzcCA9IDB4N2ZmZmZmNjkzZDY4LCByYnAgPSAw eDgwMmMyMDkwMCAtLS0KClRyYWNpbmcgY29tbWFuZCBWQm94SGVhZGxlc3MgcGlkIDg4MjYzIHRp ZCAxMDA0MTEgdGQgMHhmZmZmZmYwMDNmMmQ1YWUwCnNjaGVkX3N3aXRjaCgpIGF0IHNjaGVkX3N3 aXRjaCsweDEwOAptaV9zd2l0Y2goKSBhdCBtaV9zd2l0Y2grMHgxNmYKc2xlZXBxX2NhdGNoX3Np Z25hbHMoKSBhdCBzbGVlcHFfY2F0Y2hfc2lnbmFscysweDMxZgpzbGVlcHFfd2FpdF9zaWcoKSBh dCBzbGVlcHFfd2FpdF9zaWcrMHhjCl9zbGVlcCgpIGF0IF9zbGVlcCsweDI2YgprZXJuX3NpZ3Rp bWVkd2FpdCgpIGF0IGtlcm5fc2lndGltZWR3YWl0KzB4NjE1CnNpZ3dhaXRpbmZvKCkgYXQgc2ln d2FpdGluZm8rMHg2ZApzeXNjYWxsKCkgYXQgc3lzY2FsbCsweDI4ZgpYZmFzdF9zeXNjYWxsKCkg YXQgWGZhc3Rfc3lzY2FsbCsweGUxCi0tLSBzeXNjYWxsICgzNDYsIEZyZWVCU0QgRUxGNjQsIHNp Z3dhaXRpbmZvKSwgcmlwID0gMHg4MDBiZWRkZWMsIHJzcCA9IDB4N2ZmZmZmNzE0ZTc4LCByYnAg PSAweDgwMzBmM2FjMCAtLS0KClRyYWNpbmcgY29tbWFuZCBWQm94SGVhZGxlc3MgcGlkIDg4MjYz IHRpZCAxMDA0MTAgdGQgMHhmZmZmZmYwMTMwYjJlMDAwCnNjaGVkX3N3aXRjaCgpIGF0IHNjaGVk X3N3aXRjaCsweDEwOAptaV9zd2l0Y2goKSBhdCBtaV9zd2l0Y2grMHgxNmYKc2xlZXBxX2NhdGNo X3NpZ25hbHMoKSBhdCBzbGVlcHFfY2F0Y2hfc2lnbmFscysweDMxZgpzbGVlcHFfd2FpdF9zaWco KSBhdCBzbGVlcHFfd2FpdF9zaWcrMHhjCl9zbGVlcCgpIGF0IF9zbGVlcCsweDI2Ygpkb19jdl93 YWl0KCkgYXQgZG9fY3Zfd2FpdCsweDg3MQpfX3VtdHhfb3BfY3Zfd2FpdCgpIGF0IF9fdW10eF9v cF9jdl93YWl0KzB4NWMKc3lzY2FsbCgpIGF0IHN5c2NhbGwrMHgyOGYKWGZhc3Rfc3lzY2FsbCgp IGF0IFhmYXN0X3N5c2NhbGwrMHhlMQotLS0gc3lzY2FsbCAoNDU0LCBGcmVlQlNEIEVMRjY0LCBf dW10eF9vcCksIHJpcCA9IDB4ODAwNjVjMjljLCByc3AgPSAweDdmZmZmZjc5NWUwOCwgcmJwID0g MHg4MDJjM2JhYzAgLS0tCgpUcmFjaW5nIGNvbW1hbmQgVkJveEhlYWRsZXNzIHBpZCA4ODI2MyB0 aWQgMTAwNDA5IHRkIDB4ZmZmZmZmMDA4MTE1OTAwMApzY2hlZF9zd2l0Y2goKSBhdCBzY2hlZF9z d2l0Y2grMHgxMDgKbWlfc3dpdGNoKCkgYXQgbWlfc3dpdGNoKzB4MTZmCnNsZWVwcV9jYXRjaF9z aWduYWxzKCkgYXQgc2xlZXBxX2NhdGNoX3NpZ25hbHMrMHgzMWYKc2xlZXBxX3dhaXRfc2lnKCkg YXQgc2xlZXBxX3dhaXRfc2lnKzB4Ywpfc2xlZXAoKSBhdCBfc2xlZXArMHgyNmIKZG9fY3Zfd2Fp dCgpIGF0IGRvX2N2X3dhaXQrMHg4NzEKX191bXR4X29wX2N2X3dhaXQoKSBhdCBfX3VtdHhfb3Bf Y3Zfd2FpdCsweDVjCnN5c2NhbGwoKSBhdCBzeXNjYWxsKzB4MjhmClhmYXN0X3N5c2NhbGwoKSBh dCBYZmFzdF9zeXNjYWxsKzB4ZTEKLS0tIHN5c2NhbGwgKDQ1NCwgRnJlZUJTRCBFTEY2NCwgX3Vt dHhfb3ApLCByaXAgPSAweDgwMDY1YzI5YywgcnNwID0gMHg3ZmZmZmY4MTZkNjgsIHJicCA9IDB4 ODAyYzIwYWMwIC0tLQoKVHJhY2luZyBjb21tYW5kIFZCb3hIZWFkbGVzcyBwaWQgODgyNjMgdGlk IDEwMDQwOCB0ZCAweGZmZmZmZjAxMzAxODk3NDAKc2NoZWRfc3dpdGNoKCkgYXQgc2NoZWRfc3dp dGNoKzB4MTA4Cm1pX3N3aXRjaCgpIGF0IG1pX3N3aXRjaCsweDE2ZgpzbGVlcHFfY2F0Y2hfc2ln bmFscygpIGF0IHNsZWVwcV9jYXRjaF9zaWduYWxzKzB4MzFmCnNsZWVwcV93YWl0X3NpZygpIGF0 IHNsZWVwcV93YWl0X3NpZysweGMKX3NsZWVwKCkgYXQgX3NsZWVwKzB4MjZiCmRvX2N2X3dhaXQo KSBhdCBkb19jdl93YWl0KzB4ODcxCl9fdW10eF9vcF9jdl93YWl0KCkgYXQgX191bXR4X29wX2N2 X3dhaXQrMHg1YwpzeXNjYWxsKCkgYXQgc3lzY2FsbCsweDI4ZgpYZmFzdF9zeXNjYWxsKCkgYXQg WGZhc3Rfc3lzY2FsbCsweGUxCi0tLSBzeXNjYWxsICg0NTQsIEZyZWVCU0QgRUxGNjQsIF91bXR4 X29wKSwgcmlwID0gMHg4MDA2NWMyOWMsIHJzcCA9IDB4N2ZmZmZmODk3ZDY4LCByYnAgPSAweDgw MmMyMGM4MCAtLS0KClRyYWNpbmcgY29tbWFuZCBWQm94SGVhZGxlc3MgcGlkIDg4MjYzIHRpZCAx MDA0MDcgdGQgMHhmZmZmZmYwMTMwMTg5M2EwCnNjaGVkX3N3aXRjaCgpIGF0IHNjaGVkX3N3aXRj aCsweDEwOAptaV9zd2l0Y2goKSBhdCBtaV9zd2l0Y2grMHgxNmYKc2xlZXBxX2NhdGNoX3NpZ25h bHMoKSBhdCBzbGVlcHFfY2F0Y2hfc2lnbmFscysweDMxZgpzbGVlcHFfdGltZWR3YWl0X3NpZygp IGF0IHNsZWVwcV90aW1lZHdhaXRfc2lnKzB4MTkKcnRTZW1FdmVudE11bHRpV2FpdCgpIGF0IHJ0 U2VtRXZlbnRNdWx0aVdhaXQrMHgxYmEKZ19hQWRhcHRlcnMoKSBhdCBnX2FBZGFwdGVycysweDY3 MDMKZ19hQWRhcHRlcnMoKSBhdCAweGZmZmZmZmZmODBlNjI3MWEKZ19hQWRhcHRlcnMoKSBhdCAw eGZmZmZmZmZmODBlNjJhN2IKc3VwZHJ2SU9DdGwoKSBhdCBzdXBkcnZJT0N0bCsweDE3YmQKVkJv eERydkZyZWVCU0RJT0N0bCgpIGF0IFZCb3hEcnZGcmVlQlNESU9DdGwrMHgxZjYKZGV2ZnNfaW9j dGxfZigpIGF0IGRldmZzX2lvY3RsX2YrMHg3NwprZXJuX2lvY3RsKCkgYXQga2Vybl9pb2N0bCsw eGY2CmlvY3RsKCkgYXQgaW9jdGwrMHhmZApzeXNjYWxsKCkgYXQgc3lzY2FsbCsweDI4ZgpYZmFz dF9zeXNjYWxsKCkgYXQgWGZhc3Rfc3lzY2FsbCsweGUxCi0tLSBzeXNjYWxsICg1NCwgRnJlZUJT RCBFTEY2NCwgaW9jdGwpLCByaXAgPSAweDgwMGM4YzlmYywgcnNwID0gMHg3ZmZmZmY5OThkNjgs IHJicCA9IDB4N2ZmZmZmOTk4ZDcwIC0tLQoKVHJhY2luZyBjb21tYW5kIFZCb3hIZWFkbGVzcyBw aWQgODgyNjMgdGlkIDEwMDQwNiB0ZCAweGZmZmZmZjAxYTRjNjRhZTAKY3B1c3RvcF9oYW5kbGVy KCkgYXQgY3B1c3RvcF9oYW5kbGVyKzB4NDAKaXBpX25taV9oYW5kbGVyKCkgYXQgaXBpX25taV9o YW5kbGVyKzB4MzAKdHJhcCgpIGF0IHRyYXArMHgxOTUKbm1pX2NhbGx0cmFwKCkgYXQgbm1pX2Nh bGx0cmFwKzB4OAotLS0gdHJhcCAweDEzLCByaXAgPSAweGZmZmZmZmZmODAzNzdmZDYsIHJzcCA9 IDB4ZmZmZmZmODAwMDAzMWZlMCwgcmJwID0gMHhmZmZmZmY4MGU5MDAxNzQwIC0tLQpzbXBfcmVu ZGV6dm91c19hY3Rpb24oKSBhdCBzbXBfcmVuZGV6dm91c19hY3Rpb24rMHg5NgpYcmVuZGV6dm91 cygpIGF0IFhyZW5kZXp2b3VzKzB4ODkKLS0tIGludGVycnVwdCwgcmlwID0gMHhmZmZmZmZmZjgw ZTVlOTMwLCByc3AgPSAweGZmZmZmZjgwZTkwMDE4MDAsIHJicCA9IDB4ZmZmZmZmODBlOTAwMTkz MCAtLS0KZ19hQWRhcHRlcnMoKSBhdCBnX2FBZGFwdGVycysweGRmOTAKZ19hQWRhcHRlcnMoKSBh dCBnX2FBZGFwdGVycysweDc3NTIKZ19hQWRhcHRlcnMoKSBhdCAweGZmZmZmZmZmODBlOTI3MTcK Z19hQWRhcHRlcnMoKSBhdCAweGZmZmZmZmZmODBlNjJkMTUKc3VwZHJ2SU9DdGxGYXN0KCkgYXQg c3VwZHJ2SU9DdGxGYXN0KzB4NWEKVkJveERydkZyZWVCU0RJT0N0bCgpIGF0IFZCb3hEcnZGcmVl QlNESU9DdGwrMHgxMjUKZGV2ZnNfaW9jdGxfZigpIGF0IGRldmZzX2lvY3RsX2YrMHg3NwprZXJu X2lvY3RsKCkgYXQga2Vybl9pb2N0bCsweGY2CmlvY3RsKCkgYXQgaW9jdGwrMHhmZApzeXNjYWxs KCkgYXQgc3lzY2FsbCsweDI4ZgpYZmFzdF9zeXNjYWxsKCkgYXQgWGZhc3Rfc3lzY2FsbCsweGUx Ci0tLSBzeXNjYWxsICg1NCwgRnJlZUJTRCBFTEY2NCwgaW9jdGwpLCByaXAgPSAweDgwMGM4Yzlm YywgcnNwID0gMHg3ZmZmZmZhOTllMzgsIHJicCA9IDB4N2ZmZmZmYTk5ZTQwIC0tLQoKVHJhY2lu ZyBjb21tYW5kIFZCb3hIZWFkbGVzcyBwaWQgODgyNjMgdGlkIDEwMDQwNCB0ZCAweGZmZmZmZjAw MmRhYzJhZTAKc2NoZWRfc3dpdGNoKCkgYXQgc2NoZWRfc3dpdGNoKzB4MTA4Cm1pX3N3aXRjaCgp IGF0IG1pX3N3aXRjaCsweDE2ZgpzbGVlcHFfY2F0Y2hfc2lnbmFscygpIGF0IHNsZWVwcV9jYXRj aF9zaWduYWxzKzB4MzFmCnNsZWVwcV93YWl0X3NpZygpIGF0IHNsZWVwcV93YWl0X3NpZysweGMK X3NsZWVwKCkgYXQgX3NsZWVwKzB4MjZiCmRvX2N2X3dhaXQoKSBhdCBkb19jdl93YWl0KzB4ODcx Cl9fdW10eF9vcF9jdl93YWl0KCkgYXQgX191bXR4X29wX2N2X3dhaXQrMHg1YwpzeXNjYWxsKCkg YXQgc3lzY2FsbCsweDI4ZgpYZmFzdF9zeXNjYWxsKCkgYXQgWGZhc3Rfc3lzY2FsbCsweGUxCi0t LSBzeXNjYWxsICg0NTQsIEZyZWVCU0QgRUxGNjQsIF91bXR4X29wKSwgcmlwID0gMHg4MDA2NWMy OWMsIHJzcCA9IDB4N2ZmZmZmYjliZDc4LCByYnAgPSAweDgwMjI2NmM4MCAtLS0KClRyYWNpbmcg Y29tbWFuZCBWQm94SGVhZGxlc3MgcGlkIDg4MjYzIHRpZCAxMDAzOTYgdGQgMHhmZmZmZmYwMTlh NzM2NzQwCnNjaGVkX3N3aXRjaCgpIGF0IHNjaGVkX3N3aXRjaCsweDEwOAptaV9zd2l0Y2goKSBh dCBtaV9zd2l0Y2grMHgxNmYKc2xlZXBxX2NhdGNoX3NpZ25hbHMoKSBhdCBzbGVlcHFfY2F0Y2hf c2lnbmFscysweDMxZgpzbGVlcHFfd2FpdF9zaWcoKSBhdCBzbGVlcHFfd2FpdF9zaWcrMHhjCl9z bGVlcCgpIGF0IF9zbGVlcCsweDI2Ygpkb19jdl93YWl0KCkgYXQgZG9fY3Zfd2FpdCsweDg3MQpf X3VtdHhfb3BfY3Zfd2FpdCgpIGF0IF9fdW10eF9vcF9jdl93YWl0KzB4NWMKc3lzY2FsbCgpIGF0 IHN5c2NhbGwrMHgyOGYKWGZhc3Rfc3lzY2FsbCgpIGF0IFhmYXN0X3N5c2NhbGwrMHhlMQotLS0g c3lzY2FsbCAoNDU0LCBGcmVlQlNEIEVMRjY0LCBfdW10eF9vcCksIHJpcCA9IDB4ODAwNjVjMjlj LCByc3AgPSAweDdmZmZmZmJiY2RmOCwgcmJwID0gMHg4MDBlOTkxYzAgLS0tCgpUcmFjaW5nIGNv bW1hbmQgVkJveEhlYWRsZXNzIHBpZCA4ODI2MyB0aWQgMTAwMzk1IHRkIDB4ZmZmZmZmMDA5OWE3 M2FlMApzY2hlZF9zd2l0Y2goKSBhdCBzY2hlZF9zd2l0Y2grMHgxMDgKbWlfc3dpdGNoKCkgYXQg bWlfc3dpdGNoKzB4MTZmCnNsZWVwcV9jYXRjaF9zaWduYWxzKCkgYXQgc2xlZXBxX2NhdGNoX3Np Z25hbHMrMHgzMWYKc2xlZXBxX3dhaXRfc2lnKCkgYXQgc2xlZXBxX3dhaXRfc2lnKzB4YwpfY3Zf d2FpdF9zaWcoKSBhdCBfY3Zfd2FpdF9zaWcrMHgxMjAKc2VsdGR3YWl0KCkgYXQgc2VsdGR3YWl0 KzB4ZjYKcG9sbCgpIGF0IHBvbGwrMHg0NTgKc3lzY2FsbCgpIGF0IHN5c2NhbGwrMHgyOGYKWGZh c3Rfc3lzY2FsbCgpIGF0IFhmYXN0X3N5c2NhbGwrMHhlMQotLS0gc3lzY2FsbCAoMjA5LCBGcmVl QlNEIEVMRjY0LCBwb2xsKSwgcmlwID0gMHg4MDBjMzgwMmMsIHJzcCA9IDB4N2ZmZmZmYmRkODE4 LCByYnAgPSAweDdmZmZmZmJkZDg5NCAtLS0KClRyYWNpbmcgY29tbWFuZCBWQm94SGVhZGxlc3Mg cGlkIDg4MjYzIHRpZCAxMDAzOTQgdGQgMHhmZmZmZmYwMDgxMzFmNzQwCnNjaGVkX3N3aXRjaCgp IGF0IHNjaGVkX3N3aXRjaCsweDEwOAptaV9zd2l0Y2goKSBhdCBtaV9zd2l0Y2grMHgxNmYKc2xl ZXBxX2NhdGNoX3NpZ25hbHMoKSBhdCBzbGVlcHFfY2F0Y2hfc2lnbmFscysweDMxZgpzbGVlcHFf d2FpdF9zaWcoKSBhdCBzbGVlcHFfd2FpdF9zaWcrMHhjCl9zbGVlcCgpIGF0IF9zbGVlcCsweDI2 YgprZXJuX3dhaXQoKSBhdCBrZXJuX3dhaXQrMHg4MTcKd2FpdDQoKSBhdCB3YWl0NCsweDM1CnN5 c2NhbGwoKSBhdCBzeXNjYWxsKzB4MjhmClhmYXN0X3N5c2NhbGwoKSBhdCBYZmFzdF9zeXNjYWxs KzB4ZTEKLS0tIHN5c2NhbGwgKDcsIEZyZWVCU0QgRUxGNjQsIHdhaXQ0KSwgcmlwID0gMHg4MDBj MDUyM2MsIHJzcCA9IDB4N2ZmZmZmYmZlZWM4LCByYnAgPSAwIC0tLQoKVHJhY2luZyBjb21tYW5k IFZCb3hIZWFkbGVzcyBwaWQgODgyNjMgdGlkIDEwMDM3OSB0ZCAweGZmZmZmZjAwMmRhZDk3NDAK c2NoZWRfc3dpdGNoKCkgYXQgc2NoZWRfc3dpdGNoKzB4MTA4Cm1pX3N3aXRjaCgpIGF0IG1pX3N3 aXRjaCsweDE2ZgpzbGVlcHFfY2F0Y2hfc2lnbmFscygpIGF0IHNsZWVwcV9jYXRjaF9zaWduYWxz KzB4MzFmCnNsZWVwcV93YWl0X3NpZygpIGF0IHNsZWVwcV93YWl0X3NpZysweGMKX3NsZWVwKCkg YXQgX3NsZWVwKzB4MjZiCmRvX2N2X3dhaXQoKSBhdCBkb19jdl93YWl0KzB4ODcxCl9fdW10eF9v cF9jdl93YWl0KCkgYXQgX191bXR4X29wX2N2X3dhaXQrMHg1YwpzeXNjYWxsKCkgYXQgc3lzY2Fs bCsweDI4ZgpYZmFzdF9zeXNjYWxsKCkgYXQgWGZhc3Rfc3lzY2FsbCsweGUxCi0tLSBzeXNjYWxs ICg0NTQsIEZyZWVCU0QgRUxGNjQsIF91bXR4X29wKSwgcmlwID0gMHg4MDA2NWMyOWMsIHJzcCA9 IDB4N2ZmZmZmZmZjNWI4LCByYnAgPSAweDgwMGUwNDFjMCAtLS0KClRyYWNpbmcgY29tbWFuZCBz aCBwaWQgNTExNTkgdGlkIDEwMDI2OCB0ZCAweGZmZmZmZjAxMzAxM2IwMDAKc2NoZWRfc3dpdGNo KCkgYXQgc2NoZWRfc3dpdGNoKzB4MTA4Cm1pX3N3aXRjaCgpIGF0IG1pX3N3aXRjaCsweDE2Zgpz bGVlcHFfY2F0Y2hfc2lnbmFscygpIGF0IHNsZWVwcV9jYXRjaF9zaWduYWxzKzB4MzFmCnNsZWVw cV93YWl0X3NpZygpIGF0IHNsZWVwcV93YWl0X3NpZysweGMKX3NsZWVwKCkgYXQgX3NsZWVwKzB4 MjZiCmtlcm5fd2FpdCgpIGF0IGtlcm5fd2FpdCsweDgxNwp3YWl0NCgpIGF0IHdhaXQ0KzB4MzUK c3lzY2FsbCgpIGF0IHN5c2NhbGwrMHgyOGYKWGZhc3Rfc3lzY2FsbCgpIGF0IFhmYXN0X3N5c2Nh bGwrMHhlMQotLS0gc3lzY2FsbCAoNywgRnJlZUJTRCBFTEY2NCwgd2FpdDQpLCByaXAgPSAweDgw MDkzNTIzYywgcnNwID0gMHg3ZmZmZmZmZmM0NDgsIHJicCA9IDB4YThkNCAtLS0KClRyYWNpbmcg Y29tbWFuZCBzaCBwaWQgNTExMjAgdGlkIDEwMDE5MSB0ZCAweGZmZmZmZjAwMDZjMzFhZTAKc2No ZWRfc3dpdGNoKCkgYXQgc2NoZWRfc3dpdGNoKzB4MTA4Cm1pX3N3aXRjaCgpIGF0IG1pX3N3aXRj aCsweDE2ZgpzbGVlcHFfY2F0Y2hfc2lnbmFscygpIGF0IHNsZWVwcV9jYXRjaF9zaWduYWxzKzB4 MzFmCnNsZWVwcV93YWl0X3NpZygpIGF0IHNsZWVwcV93YWl0X3NpZysweGMKX3NsZWVwKCkgYXQg X3NsZWVwKzB4MjZiCmtlcm5fd2FpdCgpIGF0IGtlcm5fd2FpdCsweDgxNwp3YWl0NCgpIGF0IHdh aXQ0KzB4MzUKc3lzY2FsbCgpIGF0IHN5c2NhbGwrMHgyOGYKWGZhc3Rfc3lzY2FsbCgpIGF0IFhm YXN0X3N5c2NhbGwrMHhlMQotLS0gc3lzY2FsbCAoNywgRnJlZUJTRCBFTEY2NCwgd2FpdDQpLCBy aXAgPSAweDgwMDkzNTIzYywgcnNwID0gMHg3ZmZmZmZmZmM0NTgsIHJicCA9IDB4YThkNCAtLS0K ClRyYWNpbmcgY29tbWFuZCBzaCBwaWQgNTA3OTggdGlkIDEwMDI4NCB0ZCAweGZmZmZmZjAxMzBi MzVhZTAKc2NoZWRfc3dpdGNoKCkgYXQgc2NoZWRfc3dpdGNoKzB4MTA4Cm1pX3N3aXRjaCgpIGF0 IG1pX3N3aXRjaCsweDE2ZgpzbGVlcHFfY2F0Y2hfc2lnbmFscygpIGF0IHNsZWVwcV9jYXRjaF9z aWduYWxzKzB4MzFmCnNsZWVwcV93YWl0X3NpZygpIGF0IHNsZWVwcV93YWl0X3NpZysweGMKX3Ns ZWVwKCkgYXQgX3NsZWVwKzB4MjZiCmtlcm5fd2FpdCgpIGF0IGtlcm5fd2FpdCsweDgxNwp3YWl0 NCgpIGF0IHdhaXQ0KzB4MzUKc3lzY2FsbCgpIGF0IHN5c2NhbGwrMHgyOGYKWGZhc3Rfc3lzY2Fs bCgpIGF0IFhmYXN0X3N5c2NhbGwrMHhlMQotLS0gc3lzY2FsbCAoNywgRnJlZUJTRCBFTEY2NCwg d2FpdDQpLCByaXAgPSAweDgwMDkzNTIzYywgcnNwID0gMHg3ZmZmZmZmZmM2MjgsIHJicCA9IDB4 YThkNCAtLS0KClRyYWNpbmcgY29tbWFuZCBuZXRzZXJ2ZXIgcGlkIDQ5MTc3IHRpZCAxMDAzMjIg dGQgMHhmZmZmZmYwMTlhNGZkNzQwCnNjaGVkX3N3aXRjaCgpIGF0IHNjaGVkX3N3aXRjaCsweDEw OAptaV9zd2l0Y2goKSBhdCBtaV9zd2l0Y2grMHgxNmYKc2xlZXBxX2NhdGNoX3NpZ25hbHMoKSBh dCBzbGVlcHFfY2F0Y2hfc2lnbmFscysweDMxZgpzbGVlcHFfd2FpdF9zaWcoKSBhdCBzbGVlcHFf d2FpdF9zaWcrMHhjCl9zbGVlcCgpIGF0IF9zbGVlcCsweDI2YgprZXJuX2FjY2VwdCgpIGF0IGtl cm5fYWNjZXB0KzB4MWUyCmFjY2VwdCgpIGF0IGFjY2VwdCsweDc1CnN5c2NhbGwoKSBhdCBzeXNj YWxsKzB4MjhmClhmYXN0X3N5c2NhbGwoKSBhdCBYZmFzdF9zeXNjYWxsKzB4ZTEKLS0tIHN5c2Nh bGwgKDMwLCBGcmVlQlNEIEVMRjY0LCBhY2NlcHQpLCByaXAgPSAweDgwMDgwZGQyYywgcnNwID0g MHg3ZmZmZmZmZmRlODgsIHJicCA9IDB4NCAtLS0KClRyYWNpbmcgY29tbWFuZCB0Y3NoIHBpZCA3 MTA0NyB0aWQgMTAwMTQ5IHRkIDB4ZmZmZmZmMDAwNjUzYmFlMApzY2hlZF9zd2l0Y2goKSBhdCBz Y2hlZF9zd2l0Y2grMHgxMDgKbWlfc3dpdGNoKCkgYXQgbWlfc3dpdGNoKzB4MTZmCnNsZWVwcV9j YXRjaF9zaWduYWxzKCkgYXQgc2xlZXBxX2NhdGNoX3NpZ25hbHMrMHgzMWYKc2xlZXBxX3dhaXRf c2lnKCkgYXQgc2xlZXBxX3dhaXRfc2lnKzB4Ywpfc2xlZXAoKSBhdCBfc2xlZXArMHgyNmIKa2Vy bl9zaWdzdXNwZW5kKCkgYXQga2Vybl9zaWdzdXNwZW5kKzB4YjAKc2lnc3VzcGVuZCgpIGF0IHNp Z3N1c3BlbmQrMHgzNApzeXNjYWxsKCkgYXQgc3lzY2FsbCsweDI4ZgpYZmFzdF9zeXNjYWxsKCkg YXQgWGZhc3Rfc3lzY2FsbCsweGUxCi0tLSBzeXNjYWxsICg0LCBGcmVlQlNEIEVMRjY0LCB3cml0 ZSksIHJpcCA9IDB4ODAwOTRjZThjLCByc3AgPSAweDdmZmZmZmZmZTYwOCwgcmJwID0gMHg4MDBj NWFkMDAgLS0tCgpUcmFjaW5nIGNvbW1hbmQgc2ggcGlkIDQzMjIwIHRpZCAxMDAxNTIgdGQgMHhm ZmZmZmYwMDA2YzMxMDAwCnNjaGVkX3N3aXRjaCgpIGF0IHNjaGVkX3N3aXRjaCsweDEwOAptaV9z d2l0Y2goKSBhdCBtaV9zd2l0Y2grMHgxNmYKc2xlZXBxX2NhdGNoX3NpZ25hbHMoKSBhdCBzbGVl cHFfY2F0Y2hfc2lnbmFscysweDMxZgpzbGVlcHFfd2FpdF9zaWcoKSBhdCBzbGVlcHFfd2FpdF9z aWcrMHhjCl9zbGVlcCgpIGF0IF9zbGVlcCsweDI2YgprZXJuX3dhaXQoKSBhdCBrZXJuX3dhaXQr MHg4MTcKd2FpdDQoKSBhdCB3YWl0NCsweDM1CnN5c2NhbGwoKSBhdCBzeXNjYWxsKzB4MjhmClhm YXN0X3N5c2NhbGwoKSBhdCBYZmFzdF9zeXNjYWxsKzB4ZTEKLS0tIHN5c2NhbGwgKDcsIEZyZWVC U0QgRUxGNjQsIHdhaXQ0KSwgcmlwID0gMHg4MDA5MzUyM2MsIHJzcCA9IDB4N2ZmZmZmZmZkOWE4 LCByYnAgPSAweGE4ZDQgLS0tCgpUcmFjaW5nIGNvbW1hbmQgVkJveFNWQyBwaWQgMTE5NjIgdGlk IDEwMDMxMyB0ZCAweGZmZmZmZjAwMTYzZmIzYTAKc2NoZWRfc3dpdGNoKCkgYXQgc2NoZWRfc3dp dGNoKzB4MTA4Cm1pX3N3aXRjaCgpIGF0IG1pX3N3aXRjaCsweDE2ZgpzbGVlcHFfY2F0Y2hfc2ln bmFscygpIGF0IHNsZWVwcV9jYXRjaF9zaWduYWxzKzB4MzFmCnNsZWVwcV93YWl0X3NpZygpIGF0 IHNsZWVwcV93YWl0X3NpZysweGMKX3NsZWVwKCkgYXQgX3NsZWVwKzB4MjZiCmRvX2N2X3dhaXQo KSBhdCBkb19jdl93YWl0KzB4ODcxCl9fdW10eF9vcF9jdl93YWl0KCkgYXQgX191bXR4X29wX2N2 X3dhaXQrMHg1YwpzeXNjYWxsKCkgYXQgc3lzY2FsbCsweDI4ZgpYZmFzdF9zeXNjYWxsKCkgYXQg WGZhc3Rfc3lzY2FsbCsweGUxCi0tLSBzeXNjYWxsICg0NTQsIEZyZWVCU0QgRUxGNjQsIF91bXR4 X29wKSwgcmlwID0gMHg4MDEzNDYyOWMsIHJzcCA9IDB4N2ZmZmZmOTk3ZGY4LCByYnAgPSAweDgw MjAwYWU0MCAtLS0KClRyYWNpbmcgY29tbWFuZCBWQm94U1ZDIHBpZCAxMTk2MiB0aWQgMTAwMzQz IHRkIDB4ZmZmZmZmMDAwNmM1MTNhMApzY2hlZF9zd2l0Y2goKSBhdCBzY2hlZF9zd2l0Y2grMHgx MDgKbWlfc3dpdGNoKCkgYXQgbWlfc3dpdGNoKzB4MTZmCnNsZWVwcV9jYXRjaF9zaWduYWxzKCkg YXQgc2xlZXBxX2NhdGNoX3NpZ25hbHMrMHgzMWYKc2xlZXBxX3dhaXRfc2lnKCkgYXQgc2xlZXBx X3dhaXRfc2lnKzB4Ywpfc2xlZXAoKSBhdCBfc2xlZXArMHgyNmIKZG9fY3Zfd2FpdCgpIGF0IGRv X2N2X3dhaXQrMHg4NzEKX191bXR4X29wX2N2X3dhaXQoKSBhdCBfX3VtdHhfb3BfY3Zfd2FpdCsw eDVjCnN5c2NhbGwoKSBhdCBzeXNjYWxsKzB4MjhmClhmYXN0X3N5c2NhbGwoKSBhdCBYZmFzdF9z eXNjYWxsKzB4ZTEKLS0tIHN5c2NhbGwgKDQ1NCwgRnJlZUJTRCBFTEY2NCwgX3VtdHhfb3ApLCBy aXAgPSAweDgwMTM0NjI5YywgcnNwID0gMHg3ZmZmZmY5YjhkZjgsIHJicCA9IDB4ODAyMDk2MWMw IC0tLQoKVHJhY2luZyBjb21tYW5kIFZCb3hTVkMgcGlkIDExOTYyIHRpZCAxMDAzNDEgdGQgMHhm ZmZmZmYwMTMwYjM2NzQwCnNjaGVkX3N3aXRjaCgpIGF0IHNjaGVkX3N3aXRjaCsweDEwOAptaV9z d2l0Y2goKSBhdCBtaV9zd2l0Y2grMHgxNmYKc2xlZXBxX2NhdGNoX3NpZ25hbHMoKSBhdCBzbGVl cHFfY2F0Y2hfc2lnbmFscysweDMxZgpzbGVlcHFfd2FpdF9zaWcoKSBhdCBzbGVlcHFfd2FpdF9z aWcrMHhjCl9zbGVlcCgpIGF0IF9zbGVlcCsweDI2Ygpkb19jdl93YWl0KCkgYXQgZG9fY3Zfd2Fp dCsweDg3MQpfX3VtdHhfb3BfY3Zfd2FpdCgpIGF0IF9fdW10eF9vcF9jdl93YWl0KzB4NWMKc3lz Y2FsbCgpIGF0IHN5c2NhbGwrMHgyOGYKWGZhc3Rfc3lzY2FsbCgpIGF0IFhmYXN0X3N5c2NhbGwr MHhlMQotLS0gc3lzY2FsbCAoNDU0LCBGcmVlQlNEIEVMRjY0LCBfdW10eF9vcCksIHJpcCA9IDB4 ODAxMzQ2MjljLCByc3AgPSAweDdmZmZmZmEzOWQ3OCwgcmJwID0gMHg4MDI0M2M1ODAgLS0tCgpU cmFjaW5nIGNvbW1hbmQgVkJveFNWQyBwaWQgMTE5NjIgdGlkIDEwMDM0MCB0ZCAweGZmZmZmZjAw MDZkYmUwMDAKc2NoZWRfc3dpdGNoKCkgYXQgc2NoZWRfc3dpdGNoKzB4MTA4Cm1pX3N3aXRjaCgp IGF0IG1pX3N3aXRjaCsweDE2ZgpzbGVlcHFfY2F0Y2hfc2lnbmFscygpIGF0IHNsZWVwcV9jYXRj aF9zaWduYWxzKzB4MzFmCnNsZWVwcV90aW1lZHdhaXRfc2lnKCkgYXQgc2xlZXBxX3RpbWVkd2Fp dF9zaWcrMHgxOQpfc2xlZXAoKSBhdCBfc2xlZXArMHgxYTMKZG9fY3Zfd2FpdCgpIGF0IGRvX2N2 X3dhaXQrMHg2NDAKX191bXR4X29wX2N2X3dhaXQoKSBhdCBfX3VtdHhfb3BfY3Zfd2FpdCsweDVj CnN5c2NhbGwoKSBhdCBzeXNjYWxsKzB4MjhmClhmYXN0X3N5c2NhbGwoKSBhdCBYZmFzdF9zeXNj YWxsKzB4ZTEKLS0tIHN5c2NhbGwgKDQ1NCwgRnJlZUJTRCBFTEY2NCwgX3VtdHhfb3ApLCByaXAg PSAweDgwMTM0NjI5YywgcnNwID0gMHg3ZmZmZmZhYmFjYzgsIHJicCA9IDB4ODAyNDNjNzQwIC0t LQoKVHJhY2luZyBjb21tYW5kIFZCb3hTVkMgcGlkIDExOTYyIHRpZCAxMDAzMzkgdGQgMHhmZmZm ZmYwMTlhNzQxM2EwCnNjaGVkX3N3aXRjaCgpIGF0IHNjaGVkX3N3aXRjaCsweDEwOAptaV9zd2l0 Y2goKSBhdCBtaV9zd2l0Y2grMHgxNmYKc2xlZXBxX2NhdGNoX3NpZ25hbHMoKSBhdCBzbGVlcHFf Y2F0Y2hfc2lnbmFscysweDMxZgpzbGVlcHFfdGltZWR3YWl0X3NpZygpIGF0IHNsZWVwcV90aW1l ZHdhaXRfc2lnKzB4MTkKX3NsZWVwKCkgYXQgX3NsZWVwKzB4MWEzCmRvX2N2X3dhaXQoKSBhdCBk b19jdl93YWl0KzB4NjQwCl9fdW10eF9vcF9jdl93YWl0KCkgYXQgX191bXR4X29wX2N2X3dhaXQr MHg1YwpzeXNjYWxsKCkgYXQgc3lzY2FsbCsweDI4ZgpYZmFzdF9zeXNjYWxsKCkgYXQgWGZhc3Rf c3lzY2FsbCsweGUxCi0tLSBzeXNjYWxsICg0NTQsIEZyZWVCU0QgRUxGNjQsIF91bXR4X29wKSwg cmlwID0gMHg4MDEzNDYyOWMsIHJzcCA9IDB4N2ZmZmZmYjNiZTI4LCByYnAgPSAweDgwMjQzY2Fj MCAtLS0KClRyYWNpbmcgY29tbWFuZCBWQm94U1ZDIHBpZCAxMTk2MiB0aWQgMTAwMzM4IHRkIDB4 ZmZmZmZmMDAwNmM1MWFlMApzY2hlZF9zd2l0Y2goKSBhdCBzY2hlZF9zd2l0Y2grMHgxMDgKbWlf c3dpdGNoKCkgYXQgbWlfc3dpdGNoKzB4MTZmCnNsZWVwcV9jYXRjaF9zaWduYWxzKCkgYXQgc2xl ZXBxX2NhdGNoX3NpZ25hbHMrMHgzMWYKc2xlZXBxX3dhaXRfc2lnKCkgYXQgc2xlZXBxX3dhaXRf c2lnKzB4Ywpfc2xlZXAoKSBhdCBfc2xlZXArMHgyNmIKZG9fY3Zfd2FpdCgpIGF0IGRvX2N2X3dh aXQrMHg4NzEKX191bXR4X29wX2N2X3dhaXQoKSBhdCBfX3VtdHhfb3BfY3Zfd2FpdCsweDVjCnN5 c2NhbGwoKSBhdCBzeXNjYWxsKzB4MjhmClhmYXN0X3N5c2NhbGwoKSBhdCBYZmFzdF9zeXNjYWxs KzB4ZTEKLS0tIHN5c2NhbGwgKDQ1NCwgRnJlZUJTRCBFTEY2NCwgX3VtdHhfb3ApLCByaXAgPSAw eDgwMTM0NjI5YywgcnNwID0gMHg3ZmZmZmZiYmNlMjgsIHJicCA9IDB4ODAyMDk2MzgwIC0tLQoK VHJhY2luZyBjb21tYW5kIFZCb3hTVkMgcGlkIDExOTYyIHRpZCAxMDAzMzcgdGQgMHhmZmZmZmYw MDA2YzdhMDAwCnNjaGVkX3N3aXRjaCgpIGF0IHNjaGVkX3N3aXRjaCsweDEwOAptaV9zd2l0Y2go KSBhdCBtaV9zd2l0Y2grMHgxNmYKc2xlZXBxX2NhdGNoX3NpZ25hbHMoKSBhdCBzbGVlcHFfY2F0 Y2hfc2lnbmFscysweDMxZgpzbGVlcHFfd2FpdF9zaWcoKSBhdCBzbGVlcHFfd2FpdF9zaWcrMHhj Cl9zbGVlcCgpIGF0IF9zbGVlcCsweDI2Ygpkb19jdl93YWl0KCkgYXQgZG9fY3Zfd2FpdCsweDg3 MQpfX3VtdHhfb3BfY3Zfd2FpdCgpIGF0IF9fdW10eF9vcF9jdl93YWl0KzB4NWMKc3lzY2FsbCgp IGF0IHN5c2NhbGwrMHgyOGYKWGZhc3Rfc3lzY2FsbCgpIGF0IFhmYXN0X3N5c2NhbGwrMHhlMQot LS0gc3lzY2FsbCAoNDU0LCBGcmVlQlNEIEVMRjY0LCBfdW10eF9vcCksIHJpcCA9IDB4ODAxMzQ2 MjljLCByc3AgPSAweDdmZmZmZmJkZGRmOCwgcmJwID0gMHg4MDIwOTY1NDAgLS0tCgpUcmFjaW5n IGNvbW1hbmQgVkJveFNWQyBwaWQgMTE5NjIgdGlkIDEwMDMyMSB0ZCAweGZmZmZmZjAxOWE0ZmRh ZTAKc2NoZWRfc3dpdGNoKCkgYXQgc2NoZWRfc3dpdGNoKzB4MTA4Cm1pX3N3aXRjaCgpIGF0IG1p X3N3aXRjaCsweDE2ZgpzbGVlcHFfY2F0Y2hfc2lnbmFscygpIGF0IHNsZWVwcV9jYXRjaF9zaWdu YWxzKzB4MzFmCnNsZWVwcV93YWl0X3NpZygpIGF0IHNsZWVwcV93YWl0X3NpZysweGMKX3NsZWVw KCkgYXQgX3NsZWVwKzB4MjZiCmRvX2N2X3dhaXQoKSBhdCBkb19jdl93YWl0KzB4ODcxCl9fdW10 eF9vcF9jdl93YWl0KCkgYXQgX191bXR4X29wX2N2X3dhaXQrMHg1YwpzeXNjYWxsKCkgYXQgc3lz Y2FsbCsweDI4ZgpYZmFzdF9zeXNjYWxsKCkgYXQgWGZhc3Rfc3lzY2FsbCsweGUxCi0tLSBzeXNj YWxsICg0NTQsIEZyZWVCU0QgRUxGNjQsIF91bXR4X29wKSwgcmlwID0gMHg4MDEzNDYyOWMsIHJz cCA9IDB4N2ZmZmZmZmZlNjU4LCByYnAgPSAweDgwMjAwNDFjMCAtLS0KClRyYWNpbmcgY29tbWFu ZCB0Y3NoIHBpZCAxOTc1IHRpZCAxMDAyMDggdGQgMHhmZmZmZmYwMDgxMWY3NzQwCnNjaGVkX3N3 aXRjaCgpIGF0IHNjaGVkX3N3aXRjaCsweDEwOAptaV9zd2l0Y2goKSBhdCBtaV9zd2l0Y2grMHgx NmYKc2xlZXBxX2NhdGNoX3NpZ25hbHMoKSBhdCBzbGVlcHFfY2F0Y2hfc2lnbmFscysweDMxZgpz bGVlcHFfd2FpdF9zaWcoKSBhdCBzbGVlcHFfd2FpdF9zaWcrMHhjCl9zbGVlcCgpIGF0IF9zbGVl cCsweDI2YgprZXJuX3NpZ3N1c3BlbmQoKSBhdCBrZXJuX3NpZ3N1c3BlbmQrMHhiMApzaWdzdXNw ZW5kKCkgYXQgc2lnc3VzcGVuZCsweDM0CnN5c2NhbGwoKSBhdCBzeXNjYWxsKzB4MjhmClhmYXN0 X3N5c2NhbGwoKSBhdCBYZmFzdF9zeXNjYWxsKzB4ZTEKLS0tIHN5c2NhbGwgKDQsIEZyZWVCU0Qg RUxGNjQsIHdyaXRlKSwgcmlwID0gMHg4MDA5NGNlOGMsIHJzcCA9IDB4N2ZmZmZmZmZlNjA4LCBy YnAgPSAweDgwMGM1YWUwMCAtLS0KClRyYWNpbmcgY29tbWFuZCBjb25zb2xlLWtpdC1kYWVtb24g cGlkIDE5MTggdGlkIDEwMDIzNSB0ZCAweGZmZmZmZjAwMTYzZmIwMDAKc2NoZWRfc3dpdGNoKCkg YXQgc2NoZWRfc3dpdGNoKzB4MTA4Cm1pX3N3aXRjaCgpIGF0IG1pX3N3aXRjaCsweDE2ZgpzbGVl cHFfY2F0Y2hfc2lnbmFscygpIGF0IHNsZWVwcV9jYXRjaF9zaWduYWxzKzB4MzFmCnNsZWVwcV93 YWl0X3NpZygpIGF0IHNsZWVwcV93YWl0X3NpZysweGMKX3NsZWVwKCkgYXQgX3NsZWVwKzB4MjZi CnNjdHR5X2lvY3RsKCkgYXQgc2N0dHlfaW9jdGwrMHhhZWIKdHR5X2lvY3RsKCkgYXQgdHR5X2lv Y3RsKzB4NWQKdHR5ZGV2X2lvY3RsKCkgYXQgdHR5ZGV2X2lvY3RsKzB4MjEzCmRldmZzX2lvY3Rs X2YoKSBhdCBkZXZmc19pb2N0bF9mKzB4NzcKa2Vybl9pb2N0bCgpIGF0IGtlcm5faW9jdGwrMHhm Ngppb2N0bCgpIGF0IGlvY3RsKzB4ZmQKc3lzY2FsbCgpIGF0IHN5c2NhbGwrMHgyOGYKWGZhc3Rf c3lzY2FsbCgpIGF0IFhmYXN0X3N5c2NhbGwrMHhlMQotLS0gc3lzY2FsbCAoNTQsIEZyZWVCU0Qg RUxGNjQsIGlvY3RsKSwgcmlwID0gMHg4MDE5MWM5ZmMsIHJzcCA9IDB4N2ZmZmZmYWRkZjM4LCBy YnAgPSAweDkgLS0tCgpUcmFjaW5nIGNvbW1hbmQgY29uc29sZS1raXQtZGFlbW9uIHBpZCAxOTE4 IHRpZCAxMDAyNDIgdGQgMHhmZmZmZmYwMDgxNDVmMDAwCnNjaGVkX3N3aXRjaCgpIGF0IHNjaGVk X3N3aXRjaCsweDEwOAptaV9zd2l0Y2goKSBhdCBtaV9zd2l0Y2grMHgxNmYKc2xlZXBxX2NhdGNo X3NpZ25hbHMoKSBhdCBzbGVlcHFfY2F0Y2hfc2lnbmFscysweDMxZgpzbGVlcHFfd2FpdF9zaWco KSBhdCBzbGVlcHFfd2FpdF9zaWcrMHhjCl9zbGVlcCgpIGF0IF9zbGVlcCsweDI2YgpzY3R0eV9p b2N0bCgpIGF0IHNjdHR5X2lvY3RsKzB4YWViCnR0eV9pb2N0bCgpIGF0IHR0eV9pb2N0bCsweDVk CnR0eWRldl9pb2N0bCgpIGF0IHR0eWRldl9pb2N0bCsweDIxMwpkZXZmc19pb2N0bF9mKCkgYXQg ZGV2ZnNfaW9jdGxfZisweDc3Cmtlcm5faW9jdGwoKSBhdCBrZXJuX2lvY3RsKzB4ZjYKaW9jdGwo KSBhdCBpb2N0bCsweGZkCnN5c2NhbGwoKSBhdCBzeXNjYWxsKzB4MjhmClhmYXN0X3N5c2NhbGwo KSBhdCBYZmFzdF9zeXNjYWxsKzB4ZTEKLS0tIHN5c2NhbGwgKDU0LCBGcmVlQlNEIEVMRjY0LCBp b2N0bCksIHJpcCA9IDB4ODAxOTFjOWZjLCByc3AgPSAweDdmZmZmZmFmZmYzOCwgcmJwID0gMHgx MCAtLS0KClRyYWNpbmcgY29tbWFuZCBjb25zb2xlLWtpdC1kYWVtb24gcGlkIDE5MTggdGlkIDEw MDI0MSB0ZCAweGZmZmZmZjAwODE0NWYzYTAKc2NoZWRfc3dpdGNoKCkgYXQgc2NoZWRfc3dpdGNo KzB4MTA4Cm1pX3N3aXRjaCgpIGF0IG1pX3N3aXRjaCsweDE2ZgpzbGVlcHFfY2F0Y2hfc2lnbmFs cygpIGF0IHNsZWVwcV9jYXRjaF9zaWduYWxzKzB4MzFmCnNsZWVwcV93YWl0X3NpZygpIGF0IHNs ZWVwcV93YWl0X3NpZysweGMKX3NsZWVwKCkgYXQgX3NsZWVwKzB4MjZiCnNjdHR5X2lvY3RsKCkg YXQgc2N0dHlfaW9jdGwrMHhhZWIKdHR5X2lvY3RsKCkgYXQgdHR5X2lvY3RsKzB4NWQKdHR5ZGV2 X2lvY3RsKCkgYXQgdHR5ZGV2X2lvY3RsKzB4MjEzCmRldmZzX2lvY3RsX2YoKSBhdCBkZXZmc19p b2N0bF9mKzB4NzcKa2Vybl9pb2N0bCgpIGF0IGtlcm5faW9jdGwrMHhmNgppb2N0bCgpIGF0IGlv Y3RsKzB4ZmQKc3lzY2FsbCgpIGF0IHN5c2NhbGwrMHgyOGYKWGZhc3Rfc3lzY2FsbCgpIGF0IFhm YXN0X3N5c2NhbGwrMHhlMQotLS0gc3lzY2FsbCAoNTQsIEZyZWVCU0QgRUxGNjQsIGlvY3RsKSwg cmlwID0gMHg4MDE5MWM5ZmMsIHJzcCA9IDB4N2ZmZmZmYjEwZjM4LCByYnAgPSAweGYgLS0tCgpU cmFjaW5nIGNvbW1hbmQgY29uc29sZS1raXQtZGFlbW9uIHBpZCAxOTE4IHRpZCAxMDAyNDAgdGQg MHhmZmZmZmYwMDgxNDVmNzQwCnNjaGVkX3N3aXRjaCgpIGF0IHNjaGVkX3N3aXRjaCsweDEwOApt aV9zd2l0Y2goKSBhdCBtaV9zd2l0Y2grMHgxNmYKc2xlZXBxX2NhdGNoX3NpZ25hbHMoKSBhdCBz bGVlcHFfY2F0Y2hfc2lnbmFscysweDMxZgpzbGVlcHFfd2FpdF9zaWcoKSBhdCBzbGVlcHFfd2Fp dF9zaWcrMHhjCl9zbGVlcCgpIGF0IF9zbGVlcCsweDI2YgpzY3R0eV9pb2N0bCgpIGF0IHNjdHR5 X2lvY3RsKzB4YWViCnR0eV9pb2N0bCgpIGF0IHR0eV9pb2N0bCsweDVkCnR0eWRldl9pb2N0bCgp IGF0IHR0eWRldl9pb2N0bCsweDIxMwpkZXZmc19pb2N0bF9mKCkgYXQgZGV2ZnNfaW9jdGxfZisw eDc3Cmtlcm5faW9jdGwoKSBhdCBrZXJuX2lvY3RsKzB4ZjYKaW9jdGwoKSBhdCBpb2N0bCsweGZk CnN5c2NhbGwoKSBhdCBzeXNjYWxsKzB4MjhmClhmYXN0X3N5c2NhbGwoKSBhdCBYZmFzdF9zeXNj YWxsKzB4ZTEKLS0tIHN5c2NhbGwgKDU0LCBGcmVlQlNEIEVMRjY0LCBpb2N0bCksIHJpcCA9IDB4 ODAxOTFjOWZjLCByc3AgPSAweDdmZmZmZmIyMWYzOCwgcmJwID0gMHhlIC0tLQoKVHJhY2luZyBj b21tYW5kIGNvbnNvbGUta2l0LWRhZW1vbiBwaWQgMTkxOCB0aWQgMTAwMjM5IHRkIDB4ZmZmZmZm MDA4MTQ1ZmFlMApzY2hlZF9zd2l0Y2goKSBhdCBzY2hlZF9zd2l0Y2grMHgxMDgKbWlfc3dpdGNo KCkgYXQgbWlfc3dpdGNoKzB4MTZmCnNsZWVwcV9jYXRjaF9zaWduYWxzKCkgYXQgc2xlZXBxX2Nh dGNoX3NpZ25hbHMrMHgzMWYKc2xlZXBxX3dhaXRfc2lnKCkgYXQgc2xlZXBxX3dhaXRfc2lnKzB4 Ywpfc2xlZXAoKSBhdCBfc2xlZXArMHgyNmIKc2N0dHlfaW9jdGwoKSBhdCBzY3R0eV9pb2N0bCsw eGFlYgp0dHlfaW9jdGwoKSBhdCB0dHlfaW9jdGwrMHg1ZAp0dHlkZXZfaW9jdGwoKSBhdCB0dHlk ZXZfaW9jdGwrMHgyMTMKZGV2ZnNfaW9jdGxfZigpIGF0IGRldmZzX2lvY3RsX2YrMHg3NwprZXJu X2lvY3RsKCkgYXQga2Vybl9pb2N0bCsweGY2CmlvY3RsKCkgYXQgaW9jdGwrMHhmZApzeXNjYWxs KCkgYXQgc3lzY2FsbCsweDI4ZgpYZmFzdF9zeXNjYWxsKCkgYXQgWGZhc3Rfc3lzY2FsbCsweGUx Ci0tLSBzeXNjYWxsICg1NCwgRnJlZUJTRCBFTEY2NCwgaW9jdGwpLCByaXAgPSAweDgwMTkxYzlm YywgcnNwID0gMHg3ZmZmZmZiMzJmMzgsIHJicCA9IDB4ZCAtLS0KClRyYWNpbmcgY29tbWFuZCBj b25zb2xlLWtpdC1kYWVtb24gcGlkIDE5MTggdGlkIDEwMDIzOCB0ZCAweGZmZmZmZjAwODE0MDAw MDAKc2NoZWRfc3dpdGNoKCkgYXQgc2NoZWRfc3dpdGNoKzB4MTA4Cm1pX3N3aXRjaCgpIGF0IG1p X3N3aXRjaCsweDE2ZgpzbGVlcHFfY2F0Y2hfc2lnbmFscygpIGF0IHNsZWVwcV9jYXRjaF9zaWdu YWxzKzB4MzFmCnNsZWVwcV93YWl0X3NpZygpIGF0IHNsZWVwcV93YWl0X3NpZysweGMKX3NsZWVw KCkgYXQgX3NsZWVwKzB4MjZiCnNjdHR5X2lvY3RsKCkgYXQgc2N0dHlfaW9jdGwrMHhhZWIKdHR5 X2lvY3RsKCkgYXQgdHR5X2lvY3RsKzB4NWQKdHR5ZGV2X2lvY3RsKCkgYXQgdHR5ZGV2X2lvY3Rs KzB4MjEzCmRldmZzX2lvY3RsX2YoKSBhdCBkZXZmc19pb2N0bF9mKzB4NzcKa2Vybl9pb2N0bCgp IGF0IGtlcm5faW9jdGwrMHhmNgppb2N0bCgpIGF0IGlvY3RsKzB4ZmQKc3lzY2FsbCgpIGF0IHN5 c2NhbGwrMHgyOGYKWGZhc3Rfc3lzY2FsbCgpIGF0IFhmYXN0X3N5c2NhbGwrMHhlMQotLS0gc3lz Y2FsbCAoNTQsIEZyZWVCU0QgRUxGNjQsIGlvY3RsKSwgcmlwID0gMHg4MDE5MWM5ZmMsIHJzcCA9 IDB4N2ZmZmZmYjQzZjM4LCByYnAgPSAweGMgLS0tCgpUcmFjaW5nIGNvbW1hbmQgY29uc29sZS1r aXQtZGFlbW9uIHBpZCAxOTE4IHRpZCAxMDAyMzcgdGQgMHhmZmZmZmYwMDgxNDAwM2EwCnNjaGVk X3N3aXRjaCgpIGF0IHNjaGVkX3N3aXRjaCsweDEwOAptaV9zd2l0Y2goKSBhdCBtaV9zd2l0Y2gr MHgxNmYKc2xlZXBxX2NhdGNoX3NpZ25hbHMoKSBhdCBzbGVlcHFfY2F0Y2hfc2lnbmFscysweDMx ZgpzbGVlcHFfd2FpdF9zaWcoKSBhdCBzbGVlcHFfd2FpdF9zaWcrMHhjCl9zbGVlcCgpIGF0IF9z bGVlcCsweDI2YgpzY3R0eV9pb2N0bCgpIGF0IHNjdHR5X2lvY3RsKzB4YWViCnR0eV9pb2N0bCgp IGF0IHR0eV9pb2N0bCsweDVkCnR0eWRldl9pb2N0bCgpIGF0IHR0eWRldl9pb2N0bCsweDIxMwpk ZXZmc19pb2N0bF9mKCkgYXQgZGV2ZnNfaW9jdGxfZisweDc3Cmtlcm5faW9jdGwoKSBhdCBrZXJu X2lvY3RsKzB4ZjYKaW9jdGwoKSBhdCBpb2N0bCsweGZkCnN5c2NhbGwoKSBhdCBzeXNjYWxsKzB4 MjhmClhmYXN0X3N5c2NhbGwoKSBhdCBYZmFzdF9zeXNjYWxsKzB4ZTEKLS0tIHN5c2NhbGwgKDU0 LCBGcmVlQlNEIEVMRjY0LCBpb2N0bCksIHJpcCA9IDB4ODAxOTFjOWZjLCByc3AgPSAweDdmZmZm ZmI1NGYzOCwgcmJwID0gMHhiIC0tLQoKVHJhY2luZyBjb21tYW5kIGNvbnNvbGUta2l0LWRhZW1v biBwaWQgMTkxOCB0aWQgMTAwMjM2IHRkIDB4ZmZmZmZmMDA4MTQwMDc0MApzY2hlZF9zd2l0Y2go KSBhdCBzY2hlZF9zd2l0Y2grMHgxMDgKbWlfc3dpdGNoKCkgYXQgbWlfc3dpdGNoKzB4MTZmCnNs ZWVwcV9jYXRjaF9zaWduYWxzKCkgYXQgc2xlZXBxX2NhdGNoX3NpZ25hbHMrMHgzMWYKc2xlZXBx X3dhaXRfc2lnKCkgYXQgc2xlZXBxX3dhaXRfc2lnKzB4Ywpfc2xlZXAoKSBhdCBfc2xlZXArMHgy NmIKc2N0dHlfaW9jdGwoKSBhdCBzY3R0eV9pb2N0bCsweGFlYgp0dHlfaW9jdGwoKSBhdCB0dHlf aW9jdGwrMHg1ZAp0dHlkZXZfaW9jdGwoKSBhdCB0dHlkZXZfaW9jdGwrMHgyMTMKZGV2ZnNfaW9j dGxfZigpIGF0IGRldmZzX2lvY3RsX2YrMHg3NwprZXJuX2lvY3RsKCkgYXQga2Vybl9pb2N0bCsw eGY2CmlvY3RsKCkgYXQgaW9jdGwrMHhmZApzeXNjYWxsKCkgYXQgc3lzY2FsbCsweDI4ZgpYZmFz dF9zeXNjYWxsKCkgYXQgWGZhc3Rfc3lzY2FsbCsweGUxCi0tLSBzeXNjYWxsICg1NCwgRnJlZUJT RCBFTEY2NCwgaW9jdGwpLCByaXAgPSAweDgwMTkxYzlmYywgcnNwID0gMHg3ZmZmZmZiNjVmMzgs IHJicCA9IDB4YSAtLS0KClRyYWNpbmcgY29tbWFuZCBjb25zb2xlLWtpdC1kYWVtb24gcGlkIDE5 MTggdGlkIDEwMDIzNCB0ZCAweGZmZmZmZjAwODEzNWUwMDAKc2NoZWRfc3dpdGNoKCkgYXQgc2No ZWRfc3dpdGNoKzB4MTA4Cm1pX3N3aXRjaCgpIGF0IG1pX3N3aXRjaCsweDE2ZgpzbGVlcHFfY2F0 Y2hfc2lnbmFscygpIGF0IHNsZWVwcV9jYXRjaF9zaWduYWxzKzB4MzFmCnNsZWVwcV93YWl0X3Np ZygpIGF0IHNsZWVwcV93YWl0X3NpZysweGMKX3NsZWVwKCkgYXQgX3NsZWVwKzB4MjZiCnNjdHR5 X2lvY3RsKCkgYXQgc2N0dHlfaW9jdGwrMHhhZWIKdHR5X2lvY3RsKCkgYXQgdHR5X2lvY3RsKzB4 NWQKdHR5ZGV2X2lvY3RsKCkgYXQgdHR5ZGV2X2lvY3RsKzB4MjEzCmRldmZzX2lvY3RsX2YoKSBh dCBkZXZmc19pb2N0bF9mKzB4NzcKa2Vybl9pb2N0bCgpIGF0IGtlcm5faW9jdGwrMHhmNgppb2N0 bCgpIGF0IGlvY3RsKzB4ZmQKc3lzY2FsbCgpIGF0IHN5c2NhbGwrMHgyOGYKWGZhc3Rfc3lzY2Fs bCgpIGF0IFhmYXN0X3N5c2NhbGwrMHhlMQotLS0gc3lzY2FsbCAoNTQsIEZyZWVCU0QgRUxGNjQs IGlvY3RsKSwgcmlwID0gMHg4MDE5MWM5ZmMsIHJzcCA9IDB4N2ZmZmZmYjg3ZjM4LCByYnAgPSAw eDggLS0tCgpUcmFjaW5nIGNvbW1hbmQgY29uc29sZS1raXQtZGFlbW9uIHBpZCAxOTE4IHRpZCAx MDAyMzMgdGQgMHhmZmZmZmYwMDgxMzVlM2EwCnNjaGVkX3N3aXRjaCgpIGF0IHNjaGVkX3N3aXRj aCsweDEwOAptaV9zd2l0Y2goKSBhdCBtaV9zd2l0Y2grMHgxNmYKc2xlZXBxX2NhdGNoX3NpZ25h bHMoKSBhdCBzbGVlcHFfY2F0Y2hfc2lnbmFscysweDMxZgpzbGVlcHFfd2FpdF9zaWcoKSBhdCBz bGVlcHFfd2FpdF9zaWcrMHhjCl9zbGVlcCgpIGF0IF9zbGVlcCsweDI2YgpzY3R0eV9pb2N0bCgp IGF0IHNjdHR5X2lvY3RsKzB4YWViCnR0eV9pb2N0bCgpIGF0IHR0eV9pb2N0bCsweDVkCnR0eWRl dl9pb2N0bCgpIGF0IHR0eWRldl9pb2N0bCsweDIxMwpkZXZmc19pb2N0bF9mKCkgYXQgZGV2ZnNf aW9jdGxfZisweDc3Cmtlcm5faW9jdGwoKSBhdCBrZXJuX2lvY3RsKzB4ZjYKaW9jdGwoKSBhdCBp b2N0bCsweGZkCnN5c2NhbGwoKSBhdCBzeXNjYWxsKzB4MjhmClhmYXN0X3N5c2NhbGwoKSBhdCBY ZmFzdF9zeXNjYWxsKzB4ZTEKLS0tIHN5c2NhbGwgKDU0LCBGcmVlQlNEIEVMRjY0LCBpb2N0bCks IHJpcCA9IDB4ODAxOTFjOWZjLCByc3AgPSAweDdmZmZmZmI5OGYzOCwgcmJwID0gMHg3IC0tLQoK VHJhY2luZyBjb21tYW5kIGNvbnNvbGUta2l0LWRhZW1vbiBwaWQgMTkxOCB0aWQgMTAwMjMyIHRk IDB4ZmZmZmZmMDA4MTM1ZTc0MApzY2hlZF9zd2l0Y2goKSBhdCBzY2hlZF9zd2l0Y2grMHgxMDgK bWlfc3dpdGNoKCkgYXQgbWlfc3dpdGNoKzB4MTZmCnNsZWVwcV9jYXRjaF9zaWduYWxzKCkgYXQg c2xlZXBxX2NhdGNoX3NpZ25hbHMrMHgzMWYKc2xlZXBxX3dhaXRfc2lnKCkgYXQgc2xlZXBxX3dh aXRfc2lnKzB4Ywpfc2xlZXAoKSBhdCBfc2xlZXArMHgyNmIKc2N0dHlfaW9jdGwoKSBhdCBzY3R0 eV9pb2N0bCsweGFlYgp0dHlfaW9jdGwoKSBhdCB0dHlfaW9jdGwrMHg1ZAp0dHlkZXZfaW9jdGwo KSBhdCB0dHlkZXZfaW9jdGwrMHgyMTMKZGV2ZnNfaW9jdGxfZigpIGF0IGRldmZzX2lvY3RsX2Yr MHg3NwprZXJuX2lvY3RsKCkgYXQga2Vybl9pb2N0bCsweGY2CmlvY3RsKCkgYXQgaW9jdGwrMHhm ZApzeXNjYWxsKCkgYXQgc3lzY2FsbCsweDI4ZgpYZmFzdF9zeXNjYWxsKCkgYXQgWGZhc3Rfc3lz Y2FsbCsweGUxCi0tLSBzeXNjYWxsICg1NCwgRnJlZUJTRCBFTEY2NCwgaW9jdGwpLCByaXAgPSAw eDgwMTkxYzlmYywgcnNwID0gMHg3ZmZmZmZiYTlmMzgsIHJicCA9IDB4NiAtLS0KClRyYWNpbmcg Y29tbWFuZCBjb25zb2xlLWtpdC1kYWVtb24gcGlkIDE5MTggdGlkIDEwMDIzMSB0ZCAweGZmZmZm ZjAwODEzNWVhZTAKc2NoZWRfc3dpdGNoKCkgYXQgc2NoZWRfc3dpdGNoKzB4MTA4Cm1pX3N3aXRj aCgpIGF0IG1pX3N3aXRjaCsweDE2ZgpzbGVlcHFfY2F0Y2hfc2lnbmFscygpIGF0IHNsZWVwcV9j YXRjaF9zaWduYWxzKzB4MzFmCnNsZWVwcV93YWl0X3NpZygpIGF0IHNsZWVwcV93YWl0X3NpZysw eGMKX3NsZWVwKCkgYXQgX3NsZWVwKzB4MjZiCnNjdHR5X2lvY3RsKCkgYXQgc2N0dHlfaW9jdGwr MHhhZWIKdHR5X2lvY3RsKCkgYXQgdHR5X2lvY3RsKzB4NWQKdHR5ZGV2X2lvY3RsKCkgYXQgdHR5 ZGV2X2lvY3RsKzB4MjEzCmRldmZzX2lvY3RsX2YoKSBhdCBkZXZmc19pb2N0bF9mKzB4NzcKa2Vy bl9pb2N0bCgpIGF0IGtlcm5faW9jdGwrMHhmNgppb2N0bCgpIGF0IGlvY3RsKzB4ZmQKc3lzY2Fs bCgpIGF0IHN5c2NhbGwrMHgyOGYKWGZhc3Rfc3lzY2FsbCgpIGF0IFhmYXN0X3N5c2NhbGwrMHhl MQotLS0gc3lzY2FsbCAoNTQsIEZyZWVCU0QgRUxGNjQsIGlvY3RsKSwgcmlwID0gMHg4MDE5MWM5 ZmMsIHJzcCA9IDB4N2ZmZmZmYmJhZjM4LCByYnAgPSAweDUgLS0tCgpUcmFjaW5nIGNvbW1hbmQg Y29uc29sZS1raXQtZGFlbW9uIHBpZCAxOTE4IHRpZCAxMDAyMzAgdGQgMHhmZmZmZmYwMDgxMzFm MDAwCnNjaGVkX3N3aXRjaCgpIGF0IHNjaGVkX3N3aXRjaCsweDEwOAptaV9zd2l0Y2goKSBhdCBt aV9zd2l0Y2grMHgxNmYKc2xlZXBxX2NhdGNoX3NpZ25hbHMoKSBhdCBzbGVlcHFfY2F0Y2hfc2ln bmFscysweDMxZgpzbGVlcHFfd2FpdF9zaWcoKSBhdCBzbGVlcHFfd2FpdF9zaWcrMHhjCl9zbGVl cCgpIGF0IF9zbGVlcCsweDI2YgpzY3R0eV9pb2N0bCgpIGF0IHNjdHR5X2lvY3RsKzB4YWViCnR0 eV9pb2N0bCgpIGF0IHR0eV9pb2N0bCsweDVkCnR0eWRldl9pb2N0bCgpIGF0IHR0eWRldl9pb2N0 bCsweDIxMwpkZXZmc19pb2N0bF9mKCkgYXQgZGV2ZnNfaW9jdGxfZisweDc3Cmtlcm5faW9jdGwo KSBhdCBrZXJuX2lvY3RsKzB4ZjYKaW9jdGwoKSBhdCBpb2N0bCsweGZkCnN5c2NhbGwoKSBhdCBz eXNjYWxsKzB4MjhmClhmYXN0X3N5c2NhbGwoKSBhdCBYZmFzdF9zeXNjYWxsKzB4ZTEKLS0tIHN5 c2NhbGwgKDU0LCBGcmVlQlNEIEVMRjY0LCBpb2N0bCksIHJpcCA9IDB4ODAxOTFjOWZjLCByc3Ag PSAweDdmZmZmZmJjYmYzOCwgcmJwID0gMHg0IC0tLQoKVHJhY2luZyBjb21tYW5kIGNvbnNvbGUt a2l0LWRhZW1vbiBwaWQgMTkxOCB0aWQgMTAwMjI5IHRkIDB4ZmZmZmZmMDA4MTMxZjNhMApzY2hl ZF9zd2l0Y2goKSBhdCBzY2hlZF9zd2l0Y2grMHgxMDgKbWlfc3dpdGNoKCkgYXQgbWlfc3dpdGNo KzB4MTZmCnNsZWVwcV9jYXRjaF9zaWduYWxzKCkgYXQgc2xlZXBxX2NhdGNoX3NpZ25hbHMrMHgz MWYKc2xlZXBxX3dhaXRfc2lnKCkgYXQgc2xlZXBxX3dhaXRfc2lnKzB4Ywpfc2xlZXAoKSBhdCBf c2xlZXArMHgyNmIKc2N0dHlfaW9jdGwoKSBhdCBzY3R0eV9pb2N0bCsweGFlYgp0dHlfaW9jdGwo KSBhdCB0dHlfaW9jdGwrMHg1ZAp0dHlkZXZfaW9jdGwoKSBhdCB0dHlkZXZfaW9jdGwrMHgyMTMK ZGV2ZnNfaW9jdGxfZigpIGF0IGRldmZzX2lvY3RsX2YrMHg3NwprZXJuX2lvY3RsKCkgYXQga2Vy bl9pb2N0bCsweGY2CmlvY3RsKCkgYXQgaW9jdGwrMHhmZApzeXNjYWxsKCkgYXQgc3lzY2FsbCsw eDI4ZgpYZmFzdF9zeXNjYWxsKCkgYXQgWGZhc3Rfc3lzY2FsbCsweGUxCi0tLSBzeXNjYWxsICg1 NCwgRnJlZUJTRCBFTEY2NCwgaW9jdGwpLCByaXAgPSAweDgwMTkxYzlmYywgcnNwID0gMHg3ZmZm ZmZiZGNmMzgsIHJicCA9IDB4MyAtLS0KClRyYWNpbmcgY29tbWFuZCBjb25zb2xlLWtpdC1kYWVt b24gcGlkIDE5MTggdGlkIDEwMDIyNyB0ZCAweGZmZmZmZjAwODEzMWZhZTAKc2NoZWRfc3dpdGNo KCkgYXQgc2NoZWRfc3dpdGNtc2didWYudHh0AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAMDYwMAAAAAAwAAAAAAAAADAAAAAAAAAANDI0NzIAAAAAAAAAMTEzMzAwNjUyMTUAICA3NTU2 ACAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAHVzdGFyAAAAcm9v dAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAB3aGVlbAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAENvcHlyaWdodCAoYykgMTk5Mi0yMDEwIFRoZSBGcmVlQlNEIFByb2pl Y3QuCkNvcHlyaWdodCAoYykgMTk3OSwgMTk4MCwgMTk4MywgMTk4NiwgMTk4OCwgMTk4OSwgMTk5 MSwgMTk5MiwgMTk5MywgMTk5NAoJVGhlIFJlZ2VudHMgb2YgdGhlIFVuaXZlcnNpdHkgb2YgQ2Fs aWZvcm5pYS4gQWxsIHJpZ2h0cyByZXNlcnZlZC4KRnJlZUJTRCBpcyBhIHJlZ2lzdGVyZWQgdHJh ZGVtYXJrIG9mIFRoZSBGcmVlQlNEIEZvdW5kYXRpb24uCkZyZWVCU0QgOC4wLVNUQUJMRSAjMCBy MjAyOTY5TTogTW9uIEphbiAyNSAxMDowMTowNiBDU1QgMjAxMAogICAgcm9vdEBiZ29vY2g3NTUu c2UuZWR1Oi91c3Ivb2JqL3Vzci9zcmMvc3lzL0RFTEw3NTUgYW1kNjQKVGltZWNvdW50ZXIgImk4 MjU0IiBmcmVxdWVuY3kgMTE5MzE4MiBIeiBxdWFsaXR5IDAKQ1BVOiBJbnRlbChSKSBDb3JlKFRN KTIgUXVhZCBDUFUgICAgUTY2MDAgIEAgMi40MEdIeiAoMjM5NC4wMC1NSHogSzgtY2xhc3MgQ1BV KQogIE9yaWdpbiA9ICJHZW51aW5lSW50ZWwiICBJZCA9IDB4NmZiICBTdGVwcGluZyA9IDExCiAg RmVhdHVyZXM9MHhiZmViZmJmZjxGUFUsVk1FLERFLFBTRSxUU0MsTVNSLFBBRSxNQ0UsQ1g4LEFQ SUMsU0VQLE1UUlIsUEdFLE1DQSxDTU9WLFBBVCxQU0UzNixDTEZMVVNILERUUyxBQ1BJLE1NWCxG WFNSLFNTRSxTU0UyLFNTLEhUVCxUTSxQQkU+CiAgRmVhdHVyZXMyPTB4ZTNiZDxTU0UzLERURVM2 NCxNT04sRFNfQ1BMLFZNWCxFU1QsVE0yLFNTU0UzLENYMTYseFRQUixQRENNPgogIEFNRCBGZWF0 dXJlcz0weDIwMTAwODAwPFNZU0NBTEwsTlgsTE0+CiAgQU1EIEZlYXR1cmVzMj0weDE8TEFIRj4K ICBUU0M6IFAtc3RhdGUgaW52YXJpYW50CnJlYWwgbWVtb3J5ICA9IDg1ODk5MzQ1OTIgKDgxOTIg TUIpCmF2YWlsIG1lbW9yeSA9IDgxMTgxODE4ODggKDc3NDIgTUIpCkFDUEkgQVBJQyBUYWJsZTog PERFTEwgICBCOUsgICAgPgpGcmVlQlNEL1NNUDogTXVsdGlwcm9jZXNzb3IgU3lzdGVtIERldGVj dGVkOiA0IENQVXMKRnJlZUJTRC9TTVA6IDEgcGFja2FnZShzKSB4IDQgY29yZShzKQogY3B1MCAo QlNQKTogQVBJQyBJRDogIDAKIGNwdTEgKEFQKTogQVBJQyBJRDogIDEKIGNwdTIgKEFQKTogQVBJ QyBJRDogIDIKIGNwdTMgKEFQKTogQVBJQyBJRDogIDMKaW9hcGljMDogQ2hhbmdpbmcgQVBJQyBJ RCB0byA4CmlvYXBpYzAgPFZlcnNpb24gMi4wPiBpcnFzIDAtMjMgb24gbW90aGVyYm9hcmQKbGFw aWMwOiBGb3JjaW5nIExJTlQxIHRvIGVkZ2UgdHJpZ2dlcgprYmQxIGF0IGtiZG11eDAKYWNwaTA6 IDxERUxMIEI5SyAgICA+IG9uIG1vdGhlcmJvYXJkCmFjcGkwOiBbSVRIUkVBRF0KYWNwaTA6IFBv d2VyIEJ1dHRvbiAoZml4ZWQpClRpbWVjb3VudGVyICJBQ1BJLWZhc3QiIGZyZXF1ZW5jeSAzNTc5 NTQ1IEh6IHF1YWxpdHkgMTAwMAphY3BpX3RpbWVyMDogPDI0LWJpdCB0aW1lciBhdCAzLjU3OTU0 NU1Iej4gcG9ydCAweDgwOC0weDgwYiBvbiBhY3BpMAphY3BpX2hwZXQwOiA8SGlnaCBQcmVjaXNp b24gRXZlbnQgVGltZXI+IGlvbWVtIDB4ZmVkMDAwMDAtMHhmZWQwMDNmZiBvbiBhY3BpMApUaW1l Y291bnRlciAiSFBFVCIgZnJlcXVlbmN5IDE0MzE4MTgwIEh6IHF1YWxpdHkgOTAwCmFjcGlfYnV0 dG9uMDogPFBvd2VyIEJ1dHRvbj4gb24gYWNwaTAKcGNpYjA6IDxBQ1BJIEhvc3QtUENJIGJyaWRn ZT4gcG9ydCAweGNmOC0weGNmZiBvbiBhY3BpMApwY2kwOiA8QUNQSSBQQ0kgYnVzPiBvbiBwY2li MApwY2liMTogPEFDUEkgUENJLVBDSSBicmlkZ2U+IGlycSAxNiBhdCBkZXZpY2UgMS4wIG9uIHBj aTAKcGNpMTogPEFDUEkgUENJIGJ1cz4gb24gcGNpYjEKdmdhcGNpMDogPFZHQS1jb21wYXRpYmxl IGRpc3BsYXk+IHBvcnQgMHhkYzAwLTB4ZGNmZiBtZW0gMHhkMDAwMDAwMC0weGRmZmZmZmZmLDB4 ZmU5ZjAwMDAtMHhmZTlmZmZmZiBpcnEgMTYgYXQgZGV2aWNlIDAuMCBvbiBwY2kxCnBjaTA6IDxz aW1wbGUgY29tbXM+IGF0IGRldmljZSAzLjAgKG5vIGRyaXZlciBhdHRhY2hlZCkKYXRhcGNpMDog PEludGVsIEFUQSBjb250cm9sbGVyPiBwb3J0IDB4ZmU4MC0weGZlODcsMHhmZTkwLTB4ZmU5Myww eGZlYTAtMHhmZWE3LDB4ZmViMC0weGZlYjMsMHhmZWYwLTB4ZmVmZiBpcnEgMTggYXQgZGV2aWNl IDMuMiBvbiBwY2kwCmF0YXBjaTA6IFtJVEhSRUFEXQphdGEyOiA8QVRBIGNoYW5uZWwgMD4gb24g YXRhcGNpMAphdGEyOiBbSVRIUkVBRF0KYXRhMzogPEFUQSBjaGFubmVsIDE+IG9uIGF0YXBjaTAK YXRhMzogW0lUSFJFQURdCnBjaTA6IDxzaW1wbGUgY29tbXMsIFVBUlQ+IGF0IGRldmljZSAzLjMg KG5vIGRyaXZlciBhdHRhY2hlZCkKZW0wOiA8SW50ZWwoUikgUFJPLzEwMDAgTmV0d29yayBDb25u ZWN0aW9uIDYuOS4xND4gcG9ydCAweGVjYzAtMHhlY2RmIG1lbSAweGZlYmUwMDAwLTB4ZmViZmZm ZmYsMHhmZWJkYjAwMC0weGZlYmRiZmZmIGlycSAyMSBhdCBkZXZpY2UgMjUuMCBvbiBwY2kwCmVt MDogVXNpbmcgTVNJIGludGVycnVwdAplbTA6IFtGSUxURVJdCmVtMDogRXRoZXJuZXQgYWRkcmVz czogMDA6MWU6NGY6ZDU6ODQ6YjcKdWhjaTA6IDxJbnRlbCA4MjgwMUkgKElDSDkpIFVTQiBjb250 cm9sbGVyPiBwb3J0IDB4ZmYyMC0weGZmM2YgaXJxIDE2IGF0IGRldmljZSAyNi4wIG9uIHBjaTAK dWhjaTA6IFtJVEhSRUFEXQp1aGNpMDogTGVnU3VwID0gMHgyZjAwCnVzYnVzMDogPEludGVsIDgy ODAxSSAoSUNIOSkgVVNCIGNvbnRyb2xsZXI+IG9uIHVoY2kwCnVoY2kxOiA8SW50ZWwgODI4MDFJ IChJQ0g5KSBVU0IgY29udHJvbGxlcj4gcG9ydCAweGZmMDAtMHhmZjFmIGlycSAxNyBhdCBkZXZp Y2UgMjYuMSBvbiBwY2kwCnVoY2kxOiBbSVRIUkVBRF0KdWhjaTE6IExlZ1N1cCA9IDB4MmYwMAp1 c2J1czE6IDxJbnRlbCA4MjgwMUkgKElDSDkpIFVTQiBjb250cm9sbGVyPiBvbiB1aGNpMQplaGNp MDogPEludGVsIDgyODAxSSAoSUNIOSkgVVNCIDIuMCBjb250cm9sbGVyPiBtZW0gMHhmZWJkOWMw MC0weGZlYmQ5ZmZmIGlycSAyMiBhdCBkZXZpY2UgMjYuNyBvbiBwY2kwCmVoY2kwOiBbSVRIUkVB RF0KdXNidXMyOiBFSENJIHZlcnNpb24gMS4wCnVzYnVzMjogPEludGVsIDgyODAxSSAoSUNIOSkg VVNCIDIuMCBjb250cm9sbGVyPiBvbiBlaGNpMApoZGFjMDogPEludGVsIDgyODAxSSBIaWdoIERl ZmluaXRpb24gQXVkaW8gQ29udHJvbGxlcj4gbWVtIDB4ZmViZGMwMDAtMHhmZWJkZmZmZiBpcnEg MTYgYXQgZGV2aWNlIDI3LjAgb24gcGNpMApoZGFjMDogSERBIERyaXZlciBSZXZpc2lvbjogMjAx MDAxMTJfMDE0MApoZGFjMDogW0lUSFJFQURdCnBjaWIyOiA8QUNQSSBQQ0ktUENJIGJyaWRnZT4g aXJxIDE2IGF0IGRldmljZSAyOC4wIG9uIHBjaTAKcGNpMjogPEFDUEkgUENJIGJ1cz4gb24gcGNp YjIKdWhjaTI6IDxJbnRlbCA4MjgwMUkgKElDSDkpIFVTQiBjb250cm9sbGVyPiBwb3J0IDB4ZmY4 MC0weGZmOWYgaXJxIDIzIGF0IGRldmljZSAyOS4wIG9uIHBjaTAKdWhjaTI6IFtJVEhSRUFEXQp1 c2J1czM6IDxJbnRlbCA4MjgwMUkgKElDSDkpIFVTQiBjb250cm9sbGVyPiBvbiB1aGNpMgp1aGNp MzogPEludGVsIDgyODAxSSAoSUNIOSkgVVNCIGNvbnRyb2xsZXI+IHBvcnQgMHhmZjYwLTB4ZmY3 ZiBpcnEgMTcgYXQgZGV2aWNlIDI5LjEgb24gcGNpMAp1aGNpMzogW0lUSFJFQURdCnVzYnVzNDog PEludGVsIDgyODAxSSAoSUNIOSkgVVNCIGNvbnRyb2xsZXI+IG9uIHVoY2kzCnVoY2k0OiA8SW50 ZWwgODI4MDFJIChJQ0g5KSBVU0IgY29udHJvbGxlcj4gcG9ydCAweGZmNDAtMHhmZjVmIGlycSAx OCBhdCBkZXZpY2UgMjkuMiBvbiBwY2kwCnVoY2k0OiBbSVRIUkVBRF0KdXNidXM1OiA8SW50ZWwg ODI4MDFJIChJQ0g5KSBVU0IgY29udHJvbGxlcj4gb24gdWhjaTQKZWhjaTE6IDxJbnRlbCA4Mjgw MUkgKElDSDkpIFVTQiAyLjAgY29udHJvbGxlcj4gbWVtIDB4ZmY5ODA4MDAtMHhmZjk4MGJmZiBp cnEgMjMgYXQgZGV2aWNlIDI5Ljcgb24gcGNpMAplaGNpMTogW0lUSFJFQURdCnVzYnVzNjogRUhD SSB2ZXJzaW9uIDEuMAp1c2J1czY6IDxJbnRlbCA4MjgwMUkgKElDSDkpIFVTQiAyLjAgY29udHJv bGxlcj4gb24gZWhjaTEKcGNpYjM6IDxBQ1BJIFBDSS1QQ0kgYnJpZGdlPiBhdCBkZXZpY2UgMzAu MCBvbiBwY2kwCnBjaTM6IDxBQ1BJIFBDSSBidXM+IG9uIHBjaWIzCmF0YXBjaTE6IDxTaUkgMzEx NCBTQVRBMTUwIGNvbnRyb2xsZXI+IHBvcnQgMHhjOGUwLTB4YzhlNywweGM4ZDgtMHhjOGRiLDB4 YzhlOC0weGM4ZWYsMHhjOGRjLTB4YzhkZiwweGM4ZjAtMHhjOGZmIG1lbSAweGZlNmZmYzAwLTB4 ZmU2ZmZmZmYgaXJxIDE2IGF0IGRldmljZSAwLjAgb24gcGNpMwphdGFwY2kxOiBbSVRIUkVBRF0K YXRhNDogPEFUQSBjaGFubmVsIDA+IG9uIGF0YXBjaTEKYXRhNDogW0lUSFJFQURdCmF0YTU6IDxB VEEgY2hhbm5lbCAxPiBvbiBhdGFwY2kxCmF0YTU6IFtJVEhSRUFEXQphdGE2OiA8QVRBIGNoYW5u ZWwgMj4gb24gYXRhcGNpMQphdGE2OiBbSVRIUkVBRF0KYXRhNzogPEFUQSBjaGFubmVsIDM+IG9u IGF0YXBjaTEKYXRhNzogW0lUSFJFQURdCnJsMDogPFJlYWxUZWsgODEzOSAxMC8xMDBCYXNlVFg+ IHBvcnQgMHhjYzAwLTB4Y2NmZiBtZW0gMHhmZTZmZmIwMC0weGZlNmZmYmZmIGlycSAxOCBhdCBk ZXZpY2UgMi4wIG9uIHBjaTMKbWlpYnVzMDogPE1JSSBidXM+IG9uIHJsMApybHBoeTA6IDxSZWFs VGVrIGludGVybmFsIG1lZGlhIGludGVyZmFjZT4gUEhZIDAgb24gbWlpYnVzMApybHBoeTA6ICAx MGJhc2VULCAxMGJhc2VULUZEWCwgMTAwYmFzZVRYLCAxMDBiYXNlVFgtRkRYLCBhdXRvCnJsMDog RXRoZXJuZXQgYWRkcmVzczogMDA6YzA6YTg6ODE6NWI6YzUKcmwwOiBbSVRIUkVBRF0KaXNhYjA6 IDxQQ0ktSVNBIGJyaWRnZT4gYXQgZGV2aWNlIDMxLjAgb24gcGNpMAppc2EwOiA8SVNBIGJ1cz4g b24gaXNhYjAKYWhjaTA6IDxJbnRlbCBJQ0g5IEFIQ0kgU0FUQSBjb250cm9sbGVyPiBwb3J0IDB4 ZmUwMC0weGZlMDcsMHhmZTEwLTB4ZmUxMywweGZlMjAtMHhmZTI3LDB4ZmUzMC0weGZlMzMsMHhm ZWMwLTB4ZmVkZiBtZW0gMHhmZjk3MDAwMC0weGZmOTcwN2ZmIGlycSAxOCBhdCBkZXZpY2UgMzEu MiBvbiBwY2kwCmFoY2kwOiBbSVRIUkVBRF0KYWhjaTA6IEFIQ0kgdjEuMjAgd2l0aCA2IDNHYnBz IHBvcnRzLCBQb3J0IE11bHRpcGxpZXIgc3VwcG9ydGVkCmFoY2ljaDA6IDxBSENJIGNoYW5uZWw+ IGF0IGNoYW5uZWwgMCBvbiBhaGNpMAphaGNpY2gwOiBbSVRIUkVBRF0KYWhjaWNoMTogPEFIQ0kg Y2hhbm5lbD4gYXQgY2hhbm5lbCAxIG9uIGFoY2kwCmFoY2ljaDE6IFtJVEhSRUFEXQphaGNpY2gy OiA8QUhDSSBjaGFubmVsPiBhdCBjaGFubmVsIDIgb24gYWhjaTAKYWhjaWNoMjogW0lUSFJFQURd CmFoY2ljaDM6IDxBSENJIGNoYW5uZWw+IGF0IGNoYW5uZWwgMyBvbiBhaGNpMAphaGNpY2gzOiBb SVRIUkVBRF0KYWhjaWNoNDogPEFIQ0kgY2hhbm5lbD4gYXQgY2hhbm5lbCA1IG9uIGFoY2kwCmFo Y2ljaDQ6IFtJVEhSRUFEXQpwY2kwOiA8c2VyaWFsIGJ1cywgU01CdXM+IGF0IGRldmljZSAzMS4z IChubyBkcml2ZXIgYXR0YWNoZWQpCmF0cnRjMDogPEFUIHJlYWx0aW1lIGNsb2NrPiBwb3J0IDB4 NzAtMHg3ZiBpcnEgOCBvbiBhY3BpMApmZGMwOiA8ZmxvcHB5IGRyaXZlIGNvbnRyb2xsZXIgKEZE RSk+IHBvcnQgMHgzZjAtMHgzZjUsMHgzZjcgaXJxIDYgZHJxIDIgb24gYWNwaTAKZmRjMDogW0ZJ TFRFUl0KZmQwOiA8MTQ0MC1LQiAzLjUiIGRyaXZlPiBvbiBmZGMwIGRyaXZlIDAKdWFydDA6IDwx NjU1MCBvciBjb21wYXRpYmxlPiBwb3J0IDB4M2Y4LTB4M2ZmIGlycSA0IGZsYWdzIDB4MTAgb24g YWNwaTAKdWFydDA6IFtGSUxURVJdCmNwdTA6IDxBQ1BJIENQVT4gb24gYWNwaTAKZXN0MDogPEVu aGFuY2VkIFNwZWVkU3RlcCBGcmVxdWVuY3kgQ29udHJvbD4gb24gY3B1MApwNHRjYzA6IDxDUFUg RnJlcXVlbmN5IFRoZXJtYWwgQ29udHJvbD4gb24gY3B1MApjcHUxOiA8QUNQSSBDUFU+IG9uIGFj cGkwCmVzdDE6IDxFbmhhbmNlZCBTcGVlZFN0ZXAgRnJlcXVlbmN5IENvbnRyb2w+IG9uIGNwdTEK cDR0Y2MxOiA8Q1BVIEZyZXF1ZW5jeSBUaGVybWFsIENvbnRyb2w+IG9uIGNwdTEKY3B1MjogPEFD UEkgQ1BVPiBvbiBhY3BpMAplc3QyOiA8RW5oYW5jZWQgU3BlZWRTdGVwIEZyZXF1ZW5jeSBDb250 cm9sPiBvbiBjcHUyCnA0dGNjMjogPENQVSBGcmVxdWVuY3kgVGhlcm1hbCBDb250cm9sPiBvbiBj cHUyCmNwdTM6IDxBQ1BJIENQVT4gb24gYWNwaTAKZXN0MzogPEVuaGFuY2VkIFNwZWVkU3RlcCBG cmVxdWVuY3kgQ29udHJvbD4gb24gY3B1MwpwNHRjYzM6IDxDUFUgRnJlcXVlbmN5IFRoZXJtYWwg Q29udHJvbD4gb24gY3B1Mwpvcm0wOiA8SVNBIE9wdGlvbiBST01zPiBhdCBpb21lbSAweGMwMDAw LTB4Y2VmZmYsMHhjZjAwMC0weGQwZmZmLDB4ZDEwMDAtMHhkMzdmZiwweGQzODAwLTB4ZDNmZmYg b24gaXNhMApzYzA6IDxTeXN0ZW0gY29uc29sZT4gYXQgZmxhZ3MgMHgxMDAgb24gaXNhMApzYzA6 IFZHQSA8MTYgdmlydHVhbCBjb25zb2xlcywgZmxhZ3M9MHgzMDA+CnZnYTA6IDxHZW5lcmljIElT QSBWR0E+IGF0IHBvcnQgMHgzYzAtMHgzZGYgaW9tZW0gMHhhMDAwMC0weGJmZmZmIG9uIGlzYTAK YXRrYmRjMDogPEtleWJvYXJkIGNvbnRyb2xsZXIgKGk4MDQyKT4gYXQgcG9ydCAweDYwLDB4NjQg b24gaXNhMAphdGtiZDA6IDxBVCBLZXlib2FyZD4gaXJxIDEgb24gYXRrYmRjMAprYmQwIGF0IGF0 a2JkMAphdGtiZDA6IFtHSUFOVC1MT0NLRURdCmF0a2JkMDogW0lUSFJFQURdClpGUyBmaWxlc3lz dGVtIHZlcnNpb24gMwpaRlMgc3RvcmFnZSBwb29sIHZlcnNpb24gMTQKVGltZWNvdW50ZXJzIHRp Y2sgZXZlcnkgMS4wMDAgbXNlYwp2Ym94ZHJ2OiBmQXN5bmM9MCBvZmZNaW49MHgxNzEgb2ZmTWF4 PTB4MjM3CmlwZncyICgraXB2NikgaW5pdGlhbGl6ZWQsIGRpdmVydCBlbmFibGVkLCBuYXQgZW5h YmxlZCwgcnVsZS1iYXNlZCBmb3J3YXJkaW5nIGRpc2FibGVkLCBkZWZhdWx0IHRvIGRlbnksIGxv Z2dpbmcgZGlzYWJsZWQKV2FpdGluZyA1IHNlY29uZHMgZm9yIFNDU0kgZGV2aWNlcyB0byBzZXR0 bGUKaGRhYzA6IEhEQSBDb2RlYyAjMDogQW5hbG9nIERldmljZXMgQUQxOTg0CnBjbTA6IDxIREEg QW5hbG9nIERldmljZXMgQUQxOTg0IFBDTSAjMCBBbmFsb2c+IGF0IGNhZCAwIG5pZCAxIG9uIGhk YWMwCnBjbTE6IDxIREEgQW5hbG9nIERldmljZXMgQUQxOTg0IFBDTSAjMSBBbmFsb2c+IGF0IGNh ZCAwIG5pZCAxIG9uIGhkYWMwCnVzYnVzMDogMTJNYnBzIEZ1bGwgU3BlZWQgVVNCIHYxLjAKdXNi dXMxOiAxMk1icHMgRnVsbCBTcGVlZCBVU0IgdjEuMAp1c2J1czI6IDQ4ME1icHMgSGlnaCBTcGVl ZCBVU0IgdjIuMAp1c2J1czM6IDEyTWJwcyBGdWxsIFNwZWVkIFVTQiB2MS4wCnVzYnVzNDogMTJN YnBzIEZ1bGwgU3BlZWQgVVNCIHYxLjAKdXNidXM1OiAxMk1icHMgRnVsbCBTcGVlZCBVU0IgdjEu MAp1c2J1czY6IDQ4ME1icHMgSGlnaCBTcGVlZCBVU0IgdjIuMAp1Z2VuMC4xOiA8SW50ZWw+IGF0 IHVzYnVzMAp1aHViMDogPEludGVsIFVIQ0kgcm9vdCBIVUIsIGNsYXNzIDkvMCwgcmV2IDEuMDAv MS4wMCwgYWRkciAxPiBvbiB1c2J1czAKdWdlbjEuMTogPEludGVsPiBhdCB1c2J1czEKdWh1YjE6 IDxJbnRlbCBVSENJIHJvb3QgSFVCLCBjbGFzcyA5LzAsIHJldiAxLjAwLzEuMDAsIGFkZHIgMT4g b24gdXNidXMxCnVnZW4yLjE6IDxJbnRlbD4gYXQgdXNidXMyCnVodWIyOiA8SW50ZWwgRUhDSSBy b290IEhVQiwgY2xhc3MgOS8wLCByZXYgMi4wMC8xLjAwLCBhZGRyIDE+IG9uIHVzYnVzMgp1Z2Vu My4xOiA8SW50ZWw+IGF0IHVzYnVzMwp1aHViMzogPEludGVsIFVIQ0kgcm9vdCBIVUIsIGNsYXNz IDkvMCwgcmV2IDEuMDAvMS4wMCwgYWRkciAxPiBvbiB1c2J1czMKdWdlbjQuMTogPEludGVsPiBh dCB1c2J1czQKdWh1YjQ6IDxJbnRlbCBVSENJIHJvb3QgSFVCLCBjbGFzcyA5LzAsIHJldiAxLjAw LzEuMDAsIGFkZHIgMT4gb24gdXNidXM0CnVnZW41LjE6IDxJbnRlbD4gYXQgdXNidXM1CnVodWI1 OiA8SW50ZWwgVUhDSSByb290IEhVQiwgY2xhc3MgOS8wLCByZXYgMS4wMC8xLjAwLCBhZGRyIDE+ IG9uIHVzYnVzNQp1Z2VuNi4xOiA8SW50ZWw+IGF0IHVzYnVzNgp1aHViNjogPEludGVsIEVIQ0kg cm9vdCBIVUIsIGNsYXNzIDkvMCwgcmV2IDIuMDAvMS4wMCwgYWRkciAxPiBvbiB1c2J1czYKdWh1 YjA6IDIgcG9ydHMgd2l0aCAyIHJlbW92YWJsZSwgc2VsZiBwb3dlcmVkCnVodWIxOiAyIHBvcnRz IHdpdGggMiByZW1vdmFibGUsIHNlbGYgcG93ZXJlZAp1aHViMzogMiBwb3J0cyB3aXRoIDIgcmVt b3ZhYmxlLCBzZWxmIHBvd2VyZWQKdWh1YjQ6IDIgcG9ydHMgd2l0aCAyIHJlbW92YWJsZSwgc2Vs ZiBwb3dlcmVkCnVodWI1OiAyIHBvcnRzIHdpdGggMiByZW1vdmFibGUsIHNlbGYgcG93ZXJlZAp1 aHViMjogNiBwb3J0cyB3aXRoIDYgcmVtb3ZhYmxlLCBzZWxmIHBvd2VyZWQKdWh1YjY6IDYgcG9y dHMgd2l0aCA2IHJlbW92YWJsZSwgc2VsZiBwb3dlcmVkCnVnZW42LjI6IDx2ZW5kb3IgMHgwNWUz PiBhdCB1c2J1czYKdWh1Yjc6IDx2ZW5kb3IgMHgwNWUzIFVTQjIuMCBIdWIsIGNsYXNzIDkvMCwg cmV2IDIuMDAvOS4wMSwgYWRkciAyPiBvbiB1c2J1czYKdWh1Yjc6IDQgcG9ydHMgd2l0aCA0IHJl bW92YWJsZSwgc2VsZiBwb3dlcmVkCnVnZW42LjM6IDxHZW5lcmljPiBhdCB1c2J1czYKdW1hc3Mw OiA8R2VuZXJpYyBFeHRlcm5hbCwgY2xhc3MgMC8wLCByZXYgMi4wMC8yLjEyLCBhZGRyIDM+IG9u IHVzYnVzNgp1bWFzczA6ICBTQ1NJIG92ZXIgQnVsay1Pbmx5OyBxdWlya3MgPSAweDAwMDAKdWdl bjAuMjogPERlbGw+IGF0IHVzYnVzMAp1a2JkMDogPEVQMSBJbnRlcnJ1cHQ+IG9uIHVzYnVzMApr YmQyIGF0IHVrYmQwCmFkYTAgYXQgYWhjaWNoMCBidXMgMCBzY2J1czAgdGFyZ2V0IDAgbHVuIDAK YWRhMDogPFdEQyBXRDUwMDFBQUxTLTAwTDNCMiAwMS4wM0IwMT4gQVRBLTggU0FUQSAyLnggZGV2 aWNlCmFkYTA6IDMwMC4wMDBNQi9zIHRyYW5zZmVycyAoU0FUQSAyLngsIFVETUE2LCBQSU8gc2l6 ZSA4MTkyYnl0ZXMpCmFkYTA6IENvbW1hbmQgUXVldWVpbmcgZW5hYmxlZAphZGEwOiA0NzY5NDBN QiAoOTc2NzczMTY4IDUxMiBieXRlIHNlY3RvcnM6IDE2SCA2M1MvVCAxNjM4M0MpCmFkYTEgYXQg YWhjaWNoMSBidXMgMCBzY2J1czEgdGFyZ2V0IDAgbHVuIDAKYWRhMTogPFdEQyBXRDUwMDFBQUxT LTAwTDNCMiAwMS4wM0IwMT4gQVRBLTggU0FUQSAyLnggZGV2aWNlCmFkYTE6IDMwMC4wMDBNQi9z IHRyYW5zZmVycyAoU0FUQSAyLngsIFVETUE2LCBQSU8gc2l6ZSA4MTkyYnl0ZXMpCmFkYTE6IENv bW1hbmQgUXVldWVpbmcgZW5hYmxlZAphZGExOiA0NzY5NDBNQiAoOTc2NzczMTY4IDUxMiBieXRl IHNlY3RvcnM6IDE2SCA2M1MvVCAxNjM4M0MpCmxhcGljMTogRm9yY2luZyBMSU5UMSB0byBlZGdl IHRyaWdnZXIKY2QxIGF0IGFoY2ljaDMgYnVzIDAgc2NidXMzIHRhcmdldCAwIGx1biAwCmNkMTog PFBCRFMgRFZEKy1SVyBESC0xNlcxUyAyRDE0PiBSZW1vdmFibGUgQ0QtUk9NIFNDU0ktMCBkZXZp Y2UgCmNkMTogMTUwLjAwME1CL3MgdHJhbnNmZXJzIChTQVRBIDEueCwgVURNQTUsIFBJTyBzaXpl IDgxOTJieXRlcykKY2QxOiBBdHRlbXB0IHRvIHF1ZXJ5IGRldmljZSBzaXplIGZhaWxlZDogVU5J VCBBVFRFTlRJT04sIFBvd2VyIG9uLCByZXNldCwgb3IgYnVzIGRldmljZSByZXNldCBvY2N1cnJl ZApjZDAgYXQgYWhjaWNoMiBidXMgMCBzY2J1czIgdGFyZ2V0IDAgbHVuIDAKY2QwOiA8SEwtRFQt U1QgRFZELVJPTSBHRFJIMjBOIDBEMDQ+IFJlbW92YWJsZSBDRC1ST00gU0NTSS0wIGRldmljZSAK Y2QwOiAxNTAuMDAwTUIvcyB0cmFuc2ZlcnMgKFNBVEEgMS54LCBVRE1BNSwgUElPIHNpemUgODE5 MmJ5dGVzKQpjZDA6IEF0dGVtcHQgdG8gcXVlcnkgZGV2aWNlIHNpemUgZmFpbGVkOiBVTklUIEFU VEVOVElPTiwgUG93ZXIgb24sIHJlc2V0LCBvciBidXMgZGV2aWNlIHJlc2V0IG9jY3VycmVkClNN UDogQVAgQ1BVICMxIExhdW5jaGVkIQpsYXBpYzM6IEZvcmNpbmcgTElOVDEgdG8gZWRnZSB0cmln Z2VyClNNUDogQVAgQ1BVICMzIExhdW5jaGVkIQpsYXBpYzI6IEZvcmNpbmcgTElOVDEgdG8gZWRn ZSB0cmlnZ2VyClNNUDogQVAgQ1BVICMyIExhdW5jaGVkIQp1bWFzczA6NTowOi0xOiBBdHRhY2hl ZCB0byBzY2J1czUKZGEwIGF0IHVtYXNzLXNpbTAgYnVzIDAgc2NidXM1IHRhcmdldCAwIGx1biAw CmRhMDogPEdlbmVyaWMgRXh0ZXJuYWwgMi4xMj4gRml4ZWQgRGlyZWN0IEFjY2VzcyBTQ1NJLTQg ZGV2aWNlIApkYTA6IDQwLjAwME1CL3MgdHJhbnNmZXJzCmRhMDogNDc2OTQwTUIgKDk3Njc3MzE2 OCA1MTIgYnl0ZSBzZWN0b3JzOiAyNTVIIDYzUy9UIDYwODAxQykKdWdlbjAuMzogPHZlbmRvciAw eDA0NjE+IGF0IHVzYnVzMAp1bXMwOiA8dmVuZG9yIDB4MDQ2MSBVU0IgT3B0aWNhbCBNb3VzZSwg Y2xhc3MgMC8wLCByZXYgMi4wMC8yLjAwLCBhZGRyIDM+IG9uIHVzYnVzMAp1bXMwOiAzIGJ1dHRv bnMgYW5kIFtYWVpdIGNvb3JkaW5hdGVzIElEPTAKR0VPTV9NSVJST1I6IERldmljZSBtaXJyb3Iv c3dhcCBsYXVuY2hlZCAoMi8yKS4KVHJ5aW5nIHRvIG1vdW50IHJvb3QgZnJvbSB6ZnM6enJvb3QK PDExOD5TZXR0aW5nIGhvc3R1dWlkOiA0NDQ1NGM0Yy01MzAwLTEwNGMtODA1My1jNGMwNGYzNDRh MzEuCjwxMTg+U2V0dGluZyBob3N0aWQ6IDB4YjY3MWZjNDYuCjwxMTg+U3RhcnRpbmcgZGRiLgo8 MTE4PkVudHJvcHkgaGFydmVzdGluZzoKPDExOD4gaW50ZXJydXB0cwo8MTE4PiBldGhlcm5ldAo8 MTE4PiBwb2ludF90b19wb2ludAo8MTE4PiBraWNrc3RhcnQKPDExOD4uCjwxMTg+U3RhcnRpbmcg ZmlsZSBzeXN0ZW0gY2hlY2tzOgo8MTE4Pk1vdW50aW5nIGxvY2FsIGZpbGUgc3lzdGVtczoKPDEx OD4uCnZib3huZXQwOiBFdGhlcm5ldCBhZGRyZXNzOiAwYTowMDoyNzowMDowMDowMAo8MTE4PlNl dHRpbmcgaG9zdG5hbWU6IGJnb29jaDc1NS5zZS5lZHUKPDExOD4uCjwxMTg+dmxhbjEwOiBubyBs aW5rIC4uLgo8MTE4Pi4KPDExOD4uCjwxMTg+IGdvdCBsaW5rCjwxMTg+REhDUFJFUVVFU1Qgb24g dmxhbjEwIHRvIDI1NS4yNTUuMjU1LjI1NSBwb3J0IDY3CjwxMTg+CjwxMTg+REhDUFJFUVVFU1Qg b24gdmxhbjEwIHRvIDI1NS4yNTUuMjU1LjI1NSBwb3J0IDY3CjwxMTg+CjwxMTg+REhDUERJU0NP VkVSIG9uIHZsYW4xMCB0byAyNTUuMjU1LjI1NS4yNTUgcG9ydCA2NyBpbnRlcnZhbCA3CjwxMTg+ CjwxMTg+REhDUERJU0NPVkVSIG9uIHZsYW4xMCB0byAyNTUuMjU1LjI1NS4yNTUgcG9ydCA2NyBp bnRlcnZhbCAxMgo8MTE4Pgo8MTE4PkRIQ1BESVNDT1ZFUiBvbiB2bGFuMTAgdG8gMjU1LjI1NS4y NTUuMjU1IHBvcnQgNjcgaW50ZXJ2YWwgMTQKPDExOD4KPDExOD5ESENQT0ZGRVIgZnJvbSAxNzIu MTkuMC4xCjwxMTg+CjwxMTg+REhDUFJFUVVFU1Qgb24gdmxhbjEwIHRvIDI1NS4yNTUuMjU1LjI1 NSBwb3J0IDY3CjwxMTg+CjwxMTg+REhDUEFDSyBmcm9tIDE3Mi4xOS4wLjEKPDExOD4KPDExOD5i b3VuZCB0byAxNzIuMTkuMC4yMzEgLS0gcmVuZXdhbCBpbiAzMDAgc2Vjb25kcy4KPDExOD4KPDEx OD52bGFuMzA6IG5vIGxpbmsgLi4uCjwxMTg+Lgo8MTE4Pi4KPDExOD4gZ290IGxpbmsKPDExOD5E SENQUkVRVUVTVCBvbiB2bGFuMzAgdG8gMjU1LjI1NS4yNTUuMjU1IHBvcnQgNjcKPDExOD4KPDEx OD5ESENQUkVRVUVTVCBvbiB2bGFuMzAgdG8gMjU1LjI1NS4yNTUuMjU1IHBvcnQgNjcKPDExOD4K PDExOD5ESENQRElTQ09WRVIgb24gdmxhbjMwIHRvIDI1NS4yNTUuMjU1LjI1NSBwb3J0IDY3IGlu dGVydmFsIDgKPDExOD4KPDExOD5ESENQT0ZGRVIgZnJvbSAxNzIuMTguMC4xCjwxMTg+CjwxMTg+ REhDUFJFUVVFU1Qgb24gdmxhbjMwIHRvIDI1NS4yNTUuMjU1LjI1NSBwb3J0IDY3CjwxMTg+Cjwx MTg+REhDUEFDSyBmcm9tIDE3Mi4xOC4wLjEKPDExOD4KPDExOD5ib3VuZCB0byAxNzIuMTguMTIz Ljg2IC0tIHJlbmV3YWwgaW4gMzg4ODAwMCBzZWNvbmRzLgo8MTE4Pgo8MTE4PlN0YXJ0aW5nIE5l dHdvcms6IGxvMCBlbTAgdmxhbjEwIHZsYW4yMSB2bGFuMjUgdmxhbjMwLgo8MTE4PmxvMDogZmxh Z3M9ODA0OTxVUCxMT09QQkFDSyxSVU5OSU5HLE1VTFRJQ0FTVD4gbWV0cmljIDAgbXR1IDE2Mzg0 CjwxMTg+CW9wdGlvbnM9MzxSWENTVU0sVFhDU1VNPgo8MTE4PglpbmV0NiBmZTgwOjoxJWxvMCBw cmVmaXhsZW4gNjQgc2NvcGVpZCAweDMgCjwxMTg+CWluZXQ2IDo6MSBwcmVmaXhsZW4gMTI4IAo8 MTE4PglpbmV0IDEyNy4wLjAuMSBuZXRtYXNrIDB4ZmYwMDAwMDAgCjwxMTg+CW5kNiBvcHRpb25z PTM8UEVSRk9STU5VRCxBQ0NFUFRfUlRBRFY+CjwxMTg+ZW0wOiBmbGFncz04ODQzPFVQLEJST0FE Q0FTVCxSVU5OSU5HLFNJTVBMRVgsTVVMVElDQVNUPiBtZXRyaWMgMCBtdHUgMTUwMAo8MTE4Pglv cHRpb25zPTE5YjxSWENTVU0sVFhDU1VNLFZMQU5fTVRVLFZMQU5fSFdUQUdHSU5HLFZMQU5fSFdD U1VNLFRTTzQ+CjwxMTg+CWV0aGVyIDAwOjFlOjRmOmQ1Ojg0OmI3CjwxMTg+CWluZXQgMTAuNy4w LjcgbmV0bWFzayAweGZmMDAwMDAwIGJyb2FkY2FzdCAxMC4yNTUuMjU1LjI1NQo8MTE4PgltZWRp YTogRXRoZXJuZXQgYXV0b3NlbGVjdCAoMTAwMGJhc2VUIDxmdWxsLWR1cGxleD4pCjwxMTg+CXN0 YXR1czogYWN0aXZlCjwxMTg+dmxhbjEwOiBmbGFncz04ODQzPFVQLEJST0FEQ0FTVCxSVU5OSU5H LFNJTVBMRVgsTVVMVElDQVNUPiBtZXRyaWMgMCBtdHUgMTUwMAo8MTE4PglvcHRpb25zPTM8UlhD U1VNLFRYQ1NVTT4KPDExOD4JZXRoZXIgMDA6MWU6NGY6ZDU6ODQ6YjcKPDExOD4JaW5ldCAxNzIu MTkuMC4yMzEgbmV0bWFzayAweGZmZmZmZjAwIGJyb2FkY2FzdCAxNzIuMTkuMC4yNTUKPDExOD4J bWVkaWE6IEV0aGVybmV0IGF1dG9zZWxlY3QgKDEwMDBiYXNlVCA8ZnVsbC1kdXBsZXg+KQo8MTE4 PglzdGF0dXM6IGFjdGl2ZQo8MTE4Pgl2bGFuOiAxMCBwYXJlbnQgaW50ZXJmYWNlOiBlbTAKPDEx OD52bGFuMjE6IGZsYWdzPTg4NDM8VVAsQlJPQURDQVNULFJVTk5JTkcsU0lNUExFWCxNVUxUSUNB U1Q+IG1ldHJpYyAwIG10dSAxNTAwCjwxMTg+CW9wdGlvbnM9MzxSWENTVU0sVFhDU1VNPgo8MTE4 PglldGhlciAwMDoxZTo0ZjpkNTo4NDpiNwo8MTE4PglpbmV0IDE3Mi4xNy4xMjAuNzcgbmV0bWFz ayAweGZmZmZmZjAwIGJyb2FkY2FzdCAxNzIuMTcuMTIwLjI1NQo8MTE4PgltZWRpYTogRXRoZXJu ZXQgYXV0b3NlbGVjdCAoMTAwMGJhc2VUIDxmdWxsLWR1cGxleD4pCjwxMTg+CXN0YXR1czogYWN0 aXZlCjwxMTg+CXZsYW46IDIxIHBhcmVudCBpbnRlcmZhY2U6IGVtMAo8MTE4PnZsYW4yNTogZmxh Z3M9ODg0MzxVUCxCUk9BRENBU1QsUlVOTklORyxTSU1QTEVYLE1VTFRJQ0FTVD4gbWV0cmljIDAg bXR1IDE1MDAKPDExOD4Jb3B0aW9ucz0zPFJYQ1NVTSxUWENTVU0+CjwxMTg+CWV0aGVyIDAwOjFl OjRmOmQ1Ojg0OmI3CjwxMTg+CWluZXQgMTY0LjU4LjEyMC43NyBuZXRtYXNrIDB4ZmZmZmY4MDAg YnJvYWRjYXN0IDE2NC41OC4xMjcuMjU1CjwxMTg+CW1lZGlhOiBFdGhlcm5ldCBhdXRvc2VsZWN0 ICgxMDAwYmFzZVQgPGZ1bGwtZHVwbGV4PikKPDExOD4Jc3RhdHVzOiBhY3RpdmUKPDExOD4Jdmxh bjogMjUgcGFyZW50IGludGVyZmFjZTogZW0wCjwxMTg+dmxhbjMwOiBmbGFncz04ODQzPFVQLEJS T0FEQ0FTVCxSVU5OSU5HLFNJTVBMRVgsTVVMVElDQVNUPiBtZXRyaWMgMCBtdHUgMTUwMAo8MTE4 PglvcHRpb25zPTM8UlhDU1VNLFRYQ1NVTT4KPDExOD4JZXRoZXIgMDA6MWU6NGY6ZDU6ODQ6YjcK PDExOD4JaW5ldCAxNzIuMTguMTIzLjg2IG5ldG1hc2sgMHhmZmZmMDAwMCBicm9hZGNhc3QgMTcy LjE4LjI1NS4yNTUKPDExOD4JbWVkaWE6IEV0aGVybmV0IGF1dG9zZWxlY3QgKDEwMDBiYXNlVCA8 ZnVsbC1kdXBsZXg+KQo8MTE4PglzdGF0dXM6IGFjdGl2ZQo8MTE4Pgl2bGFuOiAzMCBwYXJlbnQg aW50ZXJmYWNlOiBlbTAKPDExOD5yb3V0ZTogCjwxMTg+d3JpdGluZyB0byByb3V0aW5nIHNvY2tl dAo8MTE4PjogCjwxMTg+RmlsZSBleGlzdHMKPDExOD5hZGQgbmV0IGRlZmF1bHQ6IGdhdGV3YXkg MTAuMC4wLjI1NDogcm91dGUgYWxyZWFkeSBpbiB0YWJsZQo8MTE4PlN0YXJ0aW5nIGRldmQuCjwx MTg+U3RhcnRpbmcgdW1zMCBtb3VzZWQKPDExOD4uCjwxMTg+CjwxMTg+MDAxMDAgYWxsb3cgaXAg ZnJvbSBhbnkgdG8gYW55CjwxMTg+RmlyZXdhbGwgcnVsZXMgbG9hZGVkLgo8MTE4PkVMRiBsZGNv bmZpZyBwYXRoOiAvbGliIC91c3IvbGliIC91c3IvbGliL2NvbXBhdCAvdXNyL2xvY2FsL2xpYiAv dXNyL2xvY2FsL2xpYi9xdDQgL3Vzci9sb2NhbC9saWIvdmlydHVhbGJveAo8MTE4PjMyLWJpdCBj b21wYXRpYmlsaXR5IGxkY29uZmlnIHBhdGg6IC91c3IvbGliMzIKPDExOD5DcmVhdGluZyBhbmQv b3IgdHJpbW1pbmcgbG9nIGZpbGVzCjwxMTg+Lgo8MTE4PlN0YXJ0aW5nIHN5c2xvZ2QuCjwxMTg+ Tm8gY29yZSBkdW1wcyBmb3VuZC4KPDExOD5BZGRpdGlvbmFsIEFCSSBzdXBwb3J0Ogo8MTE4PiBs aW51eAo8MTE4Pi4KPDExOD5TdGFydGluZyBycGNiaW5kLgo8MTE4Pk5GUyBhY2Nlc3MgY2FjaGUg dGltZT02MAo8MTE4PlN0YXJ0aW5nIGFtZC4KPDExOD5DbGVhcmluZyAvdG1wIChYIHJlbGF0ZWQp Lgo8MTE4PlN0YXJ0aW5nIG1vdW50ZC4KPDExOD5TdGFydGluZyBuZnNkLgo8MTE4PmFkZCBuZXQg ZGVmYXVsdDogZ2F0ZXdheSAxNzIuMTkuMC4xCjwxMTg+YWRkIG5ldCBkZWZhdWx0OiBnYXRld2F5 IDE3Mi4xNy4xMjAuMQo8MTE4PmFkZCBuZXQgZGVmYXVsdDogZ2F0ZXdheSAxNjQuNTguMTIwLjI1 NAo8MTE4PmFkZCBuZXQgZGVmYXVsdDogZ2F0ZXdheSAxNzIuMTguMC4xCjwxMTg+Y2hhbmdlIG5l dCBkZWZhdWx0OiBnYXRld2F5IDEwLjAuMC4yNTQKPDExOD5SZW1vdmluZyBzdGFsZSBTYW1iYSB0 ZGIgZmlsZXM6IAo8MTE4PiBkb25lCjwxMTg+VXBkYXRpbmcgbW90ZDoKPDExOD4uCjwxMTg+U3Rh cnRpbmcgcG93ZXJkLgo8MTE4PlN0YXJ0aW5nIGRidXMuCjwxMTg+U3RhcnRpbmcgaGFsZC4KPDEx OD5TdGFydGluZyBic2RzdGF0cy4KPDExOD5Qb3N0aW5nIG1vbnRobHkgT1Mgc3RhdGlzdGljcyB0 byBycHQuYnNkc3RhdHMub3JnCjwxMTg+Q29uZmlndXJpbmcgc3lzY29uczoKPDExOD4gYmxhbmt0 aW1lCjwxMTg+Lgo8MTE4PlN0YXJ0aW5nIHNzaGQuCjwxMTg+U3RhcnRpbmcgY3Jvbi4KPDExOD5T dGFydGluZyBiYWNrZ3JvdW5kIGZpbGUgc3lzdGVtIGNoZWNrcyBpbiA2MCBzZWNvbmRzLgo8MTE4 Pgo8MTE4PldlZCBKYW4gMjcgMDk6MTg6NTYgQ1NUIDIwMTAKV0FSTklORyBwaWQgMTE5NjIgKFZC b3hTVkMpOiBpb2N0bCBzaWduLWV4dGVuc2lvbiBpb2N0bCBmZmZmZmZmZmM0YTgxNTAyCldBUk5J TkcgcGlkIDExOTYyIChWQm94U1ZDKTogaW9jdGwgc2lnbi1leHRlbnNpb24gaW9jdGwgZmZmZmZm ZmZjNGE4MTUwMgpXQVJOSU5HIHBpZCAxMTk2MiAoVkJveFNWQyk6IGlvY3RsIHNpZ24tZXh0ZW5z aW9uIGlvY3RsIGZmZmZmZmZmYzRhODE1MDIKV0FSTklORyBwaWQgMTE5NjIgKFZCb3hTVkMpOiBp b2N0bCBzaWduLWV4dGVuc2lvbiBpb2N0bCBmZmZmZmZmZmM0YTgxNTAyCldBUk5JTkcgcGlkIDEx OTYyIChWQm94U1ZDKTogaW9jdGwgc2lnbi1leHRlbnNpb24gaW9jdGwgZmZmZmZmZmZjNGE4MTUw MgpXQVJOSU5HIHBpZCAxMTk2MiAoVkJveFNWQyk6IGlvY3RsIHNpZ24tZXh0ZW5zaW9uIGlvY3Rs IGZmZmZmZmZmYzRhODE1MDIKV0FSTklORyBwaWQgMTE5NjIgKFZCb3hTVkMpOiBpb2N0bCBzaWdu LWV4dGVuc2lvbiBpb2N0bCBmZmZmZmZmZmM0YTgxNTAyCldBUk5JTkcgcGlkIDExOTYyIChWQm94 U1ZDKTogaW9jdGwgc2lnbi1leHRlbnNpb24gaW9jdGwgZmZmZmZmZmZjNGE4MTUwMgpXQVJOSU5H IHBpZCAxMTk2MiAoVkJveFNWQyk6IGlvY3RsIHNpZ24tZXh0ZW5zaW9uIGlvY3RsIGZmZmZmZmZm YzRhODE1MDIKPDY+ZW0wOiBwcm9taXNjdW91cyBtb2RlIGVuYWJsZWQKPDY+ZW0wOiBwcm9taXNj dW91cyBtb2RlIGRpc2FibGVkCjw2PnBpZCA4MzQ3NyAodHJ5KSwgdWlkIDA6IGV4aXRlZCBvbiBz aWduYWwgMTAgKGNvcmUgZHVtcGVkKQpXQVJOSU5HIHBpZCA4ODI2NyAoVkJveFNWQyk6IGlvY3Rs IHNpZ24tZXh0ZW5zaW9uIGlvY3RsIGZmZmZmZmZmYzRhODE1MDIKV0FSTklORyBwaWQgODgyNjcg KFZCb3hTVkMpOiBpb2N0bCBzaWduLWV4dGVuc2lvbiBpb2N0bCBmZmZmZmZmZmM0YTgxNTAyCldB Uk5JTkcgcGlkIDg4MjY3IChWQm94U1ZDKTogaW9jdGwgc2lnbi1leHRlbnNpb24gaW9jdGwgZmZm ZmZmZmZjNGE4MTUwMgo8Nj5lbTA6IHByb21pc2N1b3VzIG1vZGUgZW5hYmxlZApzcGluIGxvY2sg MHhmZmZmZmZmZjgwODU0ODQwIChzbXAgcmVuZGV6dm91cykgaGVsZCBieSAweGZmZmZmZjAxOWE3 NDFhZTAgKHRpZCAxMDAzMzMpIHRvbyBsb25nCnBhbmljOiBzcGluIGxvY2sgaGVsZCB0b28gbG9u ZwpjcHVpZCA9IDAKS0RCOiBzdGFjayBiYWNrdHJhY2U6CmRiX3RyYWNlX3NlbGZfd3JhcHBlcigp IGF0IGRiX3RyYWNlX3NlbGZfd3JhcHBlcisweDJhCnBhbmljKCkgYXQgcGFuaWMrMHgxODIKX210 eF9sb2NrX3NwaW5fZmFpbGVkKCkgYXQgX210eF9sb2NrX3NwaW5fZmFpbGVkKzB4MzkKX210eF9s b2NrX3NwaW4oKSBhdCBfbXR4X2xvY2tfc3BpbisweGIyCnNtcF90bGJfc2hvb3Rkb3duKCkgYXQg c21wX3RsYl9zaG9vdGRvd24rMHhmYQpwbWFwX2ludmFsaWRhdGVfcmFuZ2UoKSBhdCBwbWFwX2lu dmFsaWRhdGVfcmFuZ2UrMHhhZQp2bV90aHJlYWRfc3RhY2tfZGlzcG9zZSgpIGF0IHZtX3RocmVh ZF9zdGFja19kaXNwb3NlKzB4MmUKdGhyZWFkX2ZyZWUoKSBhdCB0aHJlYWRfZnJlZSsweDNjCnRo cmVhZF9yZWFwKCkgYXQgdGhyZWFkX3JlYXArMHhhMAp0aHJlYWRfYWxsb2MoKSBhdCB0aHJlYWRf YWxsb2MrMHgxOApjcmVhdGVfdGhyZWFkKCkgYXQgY3JlYXRlX3RocmVhZCsweGFkCmtlcm5fdGhy X25ldygpIGF0IGtlcm5fdGhyX25ldysweDdjCnRocl9uZXcoKSBhdCB0aHJfbmV3KzB4NjgKc3lz Y2FsbCgpIGF0IHN5c2NhbGwrMHgyOGYKWGZhc3Rfc3lzY2FsbCgpIGF0IFhmYXN0X3N5c2NhbGwr MHhlMQotLS0gc3lzY2FsbCAoNDU1LCBGcmVlQlNEIEVMRjY0LCB0aHJfbmV3KSwgcmlwID0gMHg4 MDE4N2Q0OGMsIHJzcCA9IDB4N2ZmZmZmZmZlN2U4LCByYnAgPSAweDgwMWMwOGVjMCAtLS0KS0RC OiBlbnRlcjogcGFuaWMKCjB4ZmZmZmZmMDExMDhlNTkzODogdGFnIHpmcywgdHlwZSBWUkVHCiAg ICB1c2Vjb3VudCAxLCB3cml0ZWNvdW50IDEsIHJlZmNvdW50IDEgbW91bnRlZGhlcmUgMAogICAg ZmxhZ3MgKCkKICAgIHZfb2JqZWN0IDB4ZmZmZmZmMDAwOTM1ZWJkMCByZWYgMCBwYWdlcyAwCiAg ICBsb2NrIHR5cGUgemZzOiBFWENMIGJ5IHRocmVhZCAweGZmZmZmZjAxOWE3NDFhZTAgKHBpZCA3 MDA0MykKCjB4ZmZmZmZmMDAwNmI3ODFkODogdGFnIHN5bmNlciwgdHlwZSBWTk9OCiAgICB1c2Vj b3VudCAxLCB3cml0ZWNvdW50IDAsIHJlZmNvdW50IDIgbW91bnRlZGhlcmUgMAogICAgZmxhZ3Mg KCkKICAgIGxvY2sgdHlwZSBzeW5jZXI6IEVYQ0wgYnkgdGhyZWFkIDB4ZmZmZmZmMDAwNjJiMzNh MCAocGlkIDE4KQoAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABwYW5pYy50eHQAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAMDYwMAAAAAAwAAAAAAAAADAAAAAAAAAAMjcAAAAAAAAA AAAAMTEzMzAwNjUyMTUAICA3MTMzACAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAHVzdGFyAAAAcm9vdAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAB3aGVlbAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAHNwaW4gbG9jayBoZWxkIHRvbyBs b25nAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAdmVyc2lvbi50eHQAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAADA2MDAAAAAAMAAAAAAAAAAwAAAAAAAAADE2NAAAAAAAAAAA ADExMzMwMDY1MjE1ACAgNzYxMAAgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAB1c3RhcgAAAHJvb3QAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAd2hlZWwAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABGcmVlQlNEIDguMC1TVEFCTEUgIzAg cjIwMjk2OU06IE1vbiBKYW4gMjUgMTA6MDE6MDYgQ1NUIDIwMTAKICAgIHJvb3RAYmdvb2NoNzU1 LnNlLmVkdTovdXNyL29iai91c3Ivc3JjL3N5cy9ERUxMNzU1CgAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA== --000e0cd328beb19215047e28eab4-- From owner-freebsd-stable@FreeBSD.ORG Wed Jan 27 17:59:52 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1D2321065698 for ; Wed, 27 Jan 2010 17:59:52 +0000 (UTC) (envelope-from bsdlisten@gmail.com) Received: from mail-ew0-f218.google.com (mail-ew0-f218.google.com [209.85.219.218]) by mx1.freebsd.org (Postfix) with ESMTP id 9D2B98FC1A for ; Wed, 27 Jan 2010 17:59:51 +0000 (UTC) Received: by ewy10 with SMTP id 10so1536605ewy.3 for ; Wed, 27 Jan 2010 09:59:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:date:from:x-x-sender:to:cc :subject:in-reply-to:message-id:references:user-agent:mime-version :content-type; bh=bXVZGC8SESppR6fCC3qFLDAi9A+yrwwNH1VvFQZY/w4=; b=k6KhoejyB4YkhpLSNG1I4hOAg9QR8PWy73rufhYtngq1qie4LDHCUGDoXdtMTVHH3/ yMWaJccZ8vey24d3SzKO+UF+GKgg3Wjbgc2kARE7dgWHubn69A2jD0hK6bohp1zEl+z/ KQhFELcofRsaWNI606CxLtnYzW8ELNk+zSwB4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=date:from:x-x-sender:to:cc:subject:in-reply-to:message-id :references:user-agent:mime-version:content-type; b=mXsAsxUlG4SzpxWPrp+MycZOdG7w/rJu72XTgt/Z5GK4PycweNtCnBcefigilDCgVO MavWwdf9K5ESCPxllelAQELuDYBiwwPljjVVVM/Wm90RrKl/Oi2/D5+JZQCvubr2NXP8 bkgr9jJWGTEtpYOTP0r6J/oJJsK9zXcuGf16M= Received: by 10.213.96.195 with SMTP id i3mr1086171ebn.7.1264613742813; Wed, 27 Jan 2010 09:35:42 -0800 (PST) Received: from localhost-desk1.local ([89.47.83.116]) by mx.google.com with ESMTPS id 13sm74780ewy.9.2010.01.27.09.35.40 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 27 Jan 2010 09:35:41 -0800 (PST) Date: Wed, 27 Jan 2010 19:36:19 +0200 (EET) From: Aioanei Rares X-X-Sender: arares@localhost-desk1.localdomain To: =?ISO-8859-15?Q?Zavam=2C_Vin=EDcius?= In-Reply-To: <8b5ad0e11001270926o19d1701fid30ba5a49cbb39b5@mail.gmail.com> Message-ID: References: <8b5ad0e11001270926o19d1701fid30ba5a49cbb39b5@mail.gmail.com> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="8323329-704344098-1264613793=:5491" Cc: freebsd-stable@freebsd.org Subject: Re: freebsd 8.0 stable amd64/x86 needs ~9min to bootup X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jan 2010 17:59:52 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --8323329-704344098-1264613793=:5491 Content-Type: TEXT/PLAIN; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8BIT On Wed, 27 Jan 2010, Zavam, Vinícius wrote: > noon, all you guys. > > well, I'm having some issues during the 8.0-stable bootup process. > it takes ~9min to finish the entire boot process to shows me the > "login:" screen. > > since my first installation attempt to get freebsd up and running here > with my dv3-2155mx[1] hp pavilion laptop using 8.0-RC1 amd64 iso I > could not boot freebsd up smooth and nicely as it always did for me in > my last laptop (dv6130us)[2], but I could install it without any > problem. > you may check http://www.youtube.com/watch?v=gqtz7E7u4fA to see what > realy happens. > > now I'm using a grub 0.97 from my old gentoo linux installation to > bootstrap the freebsd loader. > I tryed debug and verbose options using grub and freebsd loader.conf > but both just result nothing special. > > I've been updated and downgraded my laptop bios (by Insyde Software / > HP) but got no good results either. I tryed versions F1.3A, F1.2, F0.7 > and the original F0.6 version that came originally from HP. > > to try another way to get into 8.0-stable or 9-current I used 7.2, > 7.1, 6.4 and 6.2 release x86 and amd64 iso images to install freebsd > and an it's older btx loader but, unfortunately, got the same. it > always "freezes" ~9min. > > I can use freebsd after all the bootup process with no problem. > It's a 8.0-stable amd64 now. but I realy wanna know how could I solve > this issue. > > read some cases/PRs/issues with other hp laptops but nothing like this > one I have. one of the problems I read was about dv6000 series - > weird, it was my old laptop serie and everything was just fine > installing, booting and running freebsd into. > > what you guys think about it? can you give me a hand or a glue to pass > this through? > > thanks. > > [1] http://h10025.www1.hp.com/ewfrf/wc/document?docname=c01777298&cc=us&lc=en&dlc=en > [2] http://h10025.www1.hp.com/ewfrf/wc/document?docname=c00782284&cc=us&lc=en&dlc=en > > > > -- > Zavam, Vinícius I suppose you tried, but I am gonna ask anyway : you did try with ACPI disabled, right?> --8323329-704344098-1264613793=:5491-- From owner-freebsd-stable@FreeBSD.ORG Wed Jan 27 18:10:00 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 96CEF1065679 for ; Wed, 27 Jan 2010 18:10:00 +0000 (UTC) (envelope-from mattjreimer@gmail.com) Received: from mail-yx0-f192.google.com (mail-yx0-f192.google.com [209.85.210.192]) by mx1.freebsd.org (Postfix) with ESMTP id 4F8018FC22 for ; Wed, 27 Jan 2010 18:10:00 +0000 (UTC) Received: by yxe30 with SMTP id 30so3623992yxe.29 for ; Wed, 27 Jan 2010 10:09:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=0o6vlxw4UEJsHt/A0WzxOo+gEaB4TjNGyKCmwleBp14=; b=Zo9NmrmP7+fjjlrL4PrPVWJHi2Q1z29iYjHiL+Psh1nCBz8bhXMHTl6BY2JMRtay+1 20+CGjwGBm4V/X0AsCyHFmJUK+GT57NaR0PNc5RTCTJaXHyEp8pZugCGVWZyXD9h2VaT w8/Hx5Ktb17a8iGMyQ6TcDRcUfNg4NeNGP/Hg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=bzPATAqvyWu33csHwga7gLA82Xobyl6n9Z6m3BJzCq5L6v5Uj83SN0rpKDFshAkv9f QwkbDSHIJ1jA95dne7ZDSJz81tVj1KhAypl5kidFhloggxJj67mCp4UDGqA0fOYP6qKY +Zl/V1nkjNz0y9+7Dg7lod5BNW+0pKE+fI7F4= MIME-Version: 1.0 Received: by 10.150.8.8 with SMTP id 8mr7337156ybh.199.1264614228205; Wed, 27 Jan 2010 09:43:48 -0800 (PST) In-Reply-To: <8b5ad0e11001270926o19d1701fid30ba5a49cbb39b5@mail.gmail.com> References: <8b5ad0e11001270926o19d1701fid30ba5a49cbb39b5@mail.gmail.com> Date: Wed, 27 Jan 2010 09:43:48 -0800 Message-ID: From: Matt Reimer To: =?ISO-8859-1?Q?Zavam=2C_Vin=EDcius?= Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-stable@freebsd.org Subject: Re: freebsd 8.0 stable amd64/x86 needs ~9min to bootup X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jan 2010 18:10:00 -0000 2010/1/27 Zavam, Vin=EDcius > noon, all you guys. > > well, I'm having some issues during the 8.0-stable bootup process. > it takes ~9min to finish the entire boot process to shows me the > "login:" screen. > Are you using zfsloader? A month or so ago the ZFS code was updated to prob= e all 128 possible GPT partitions instead of just four, resulting in a slow-down, but probably not nine minutes' worth. Matt From owner-freebsd-stable@FreeBSD.ORG Wed Jan 27 18:12:01 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 40146106568F; Wed, 27 Jan 2010 18:12:01 +0000 (UTC) (envelope-from mattjreimer@gmail.com) Received: from mail-yw0-f194.google.com (mail-yw0-f194.google.com [209.85.211.194]) by mx1.freebsd.org (Postfix) with ESMTP id DC6DD8FC2B; Wed, 27 Jan 2010 18:12:00 +0000 (UTC) Received: by ywh32 with SMTP id 32so2487309ywh.14 for ; Wed, 27 Jan 2010 10:12:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=ZMMR1+hIyePw22sBR8zsayvsssvZAPSOTwkS2BA9PjM=; b=ggY/6srxTVlo2nf244W6xQ07y0Ogtrjhtt2cQdKQ336h2SlPoPHMkBAiVaOt3sz52o tnHJ78Q/M+1u6DqCeIbWWzlludxuzvec5eTJPr389NbRcmerZWp1IT4ehsKls1EwI+RA FnY3AIM8FL5HOxvFCkSbFBz/ksAd8RUh05dSQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=jlMBd5LIFX5xxllpBLITjnc4lwU8D5XC6gL9j8o8KBBTZ++TzxzQWrEylLDQVmfYxw 1kQkMsqTC326/6yY1cBNwFUEFpmgCViOZovqL7B+XAU1v3WRnKZRQ6iU2Mxnh+MBOihH GgBY0lhxUPEPvfaDo/gWGcgy6q5+VIIdZCJ8c= MIME-Version: 1.0 Received: by 10.150.252.1 with SMTP id z1mr11279072ybh.263.1264614408855; Wed, 27 Jan 2010 09:46:48 -0800 (PST) In-Reply-To: References: Date: Wed, 27 Jan 2010 09:46:48 -0800 Message-ID: From: Matt Reimer To: Dan Naumov Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: FreeBSD-STABLE Mailing List , freebsd-questions@freebsd.org Subject: Re: booting off GPT partitions X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 27 Jan 2010 18:12:01 -0000 On Wed, Jan 27, 2010 at 8:45 AM, Dan Naumov wrote: > Hey > > I was under the impression that everyone and their dog is using GPT > partitioning in FreeBSD these days, including for boot drives and that > I was just being unlucky with my current NAS motherboard (Intel > D945GCLF2) having supposedly shaky support for GPT boot. But right now > I am having an email exchange with Supermicro support (whom I > contacted since I am pondering their X7SPA-H board for a new system), > who are telling me that booting off GPT requires UEFI BIOS, which is > supposedly a very new thing and that for example NONE of their current > motherboards have support for this. > > Am I misunderstanding something or is the Supermicro support tech > misguided? > > I'm booting servers with SuperMicro X8STi-F motherboards just fine using pmbr + GPT + ZFS. Matt From owner-freebsd-stable@FreeBSD.ORG Wed Jan 27 20:26:04 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 875DF106568D for ; Wed, 27 Jan 2010 20:26:04 +0000 (UTC) (envelope-from sty@blosphere.net) Received: from mail-px0-f183.google.com (mail-px0-f183.google.com [209.85.216.183]) by mx1.freebsd.org (Postfix) with ESMTP id 693058FC20 for ; Wed, 27 Jan 2010 20:26:03 +0000 (UTC) Received: by pxi13 with SMTP id 13so4270746pxi.3 for ; Wed, 27 Jan 2010 12:26:03 -0800 (PST) MIME-Version: 1.0 Sender: sty@blosphere.net Received: by 10.114.187.16 with SMTP id k16mr6843861waf.112.1264623962633; Wed, 27 Jan 2010 12:26:02 -0800 (PST) In-Reply-To: <4B6022C6.1090608@andric.com> References: <4B6022C6.1090608@andric.com> Date: Thu, 28 Jan 2010 05:26:00 +0900 X-Google-Sender-Auth: b7e6c77ac2640a91 Message-ID: From: =?UTF-8?B?VG9tbWkgTMOkdHRp?= To: FreeBSD-STABLE Mailing List Content-Type: text/plain; charset=UTF-8 Subject: Re: immense delayed write to file system (ZFS and UFS2), performance issues X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jan 2010 20:26:04 -0000 Seems that the performance is indeed atrocious. I recently (like 2 days ago) had to rescue my zfs pool under opensolaris to spare disks. The performance under OpenSol was what I was expecting, 70MB/s reading and writing at the same time. Now that I'm restoring the stuff back under FreeBSD 8.0-p2 it seems that first the array reads from the source disk and then stops reading and decides to empty the buffer to the destination. There's usually a 2 second pause and after that it goes back to reading. There seems to be something really wrong with this, fbsd zfs implementation seems to be unable to move data between 2 zfs pools writing and reading simultaneously... I think I'll just boot back to opensol and do the transfers there. -- br, Tommi From owner-freebsd-stable@FreeBSD.ORG Wed Jan 27 21:30:48 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 28BA91065676; Wed, 27 Jan 2010 21:30:48 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id EFCE88FC0A; Wed, 27 Jan 2010 21:30:47 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id A845946B2C; Wed, 27 Jan 2010 16:30:47 -0500 (EST) Received: from jhbbsd.localnet (smtp.hudson-trading.com [209.249.190.9]) by bigwig.baldwin.cx (Postfix) with ESMTPA id 9DB9C8A024; Wed, 27 Jan 2010 16:30:46 -0500 (EST) From: John Baldwin To: freebsd-stable@freebsd.org Date: Wed, 27 Jan 2010 16:27:37 -0500 User-Agent: KMail/1.12.1 (FreeBSD/7.2-CBSD-20100120; KDE/4.3.1; amd64; ; ) References: In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201001271627.37955.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (bigwig.baldwin.cx); Wed, 27 Jan 2010 16:30:46 -0500 (EST) X-Virus-Scanned: clamav-milter 0.95.1 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-2.5 required=4.2 tests=AWL,BAYES_00, SUBJECT_FUZZY_TION autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on bigwig.baldwin.cx Cc: Dan Naumov , freebsd-questions@freebsd.org Subject: Re: booting off GPT partitions X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 27 Jan 2010 21:30:48 -0000 On Wednesday 27 January 2010 11:45:36 am Dan Naumov wrote: > Hey > > I was under the impression that everyone and their dog is using GPT > partitioning in FreeBSD these days, including for boot drives and that > I was just being unlucky with my current NAS motherboard (Intel > D945GCLF2) having supposedly shaky support for GPT boot. But right now > I am having an email exchange with Supermicro support (whom I > contacted since I am pondering their X7SPA-H board for a new system), > who are telling me that booting off GPT requires UEFI BIOS, which is > supposedly a very new thing and that for example NONE of their current > motherboards have support for this. > > Am I misunderstanding something or is the Supermicro support tech misguided? GPT was defined along with EFI, so many folks assume that you have to use EFI to boot a GPT-labelled disk. However, FreeBSD has its own BIOS-based bootstrap that can handle GPT-labelled disks. I doubt the SuperMicro tech is familiar with that case. I thought I heard that some folks had added GPT support to grub as well. -- John Baldwin From owner-freebsd-stable@FreeBSD.ORG Wed Jan 27 21:49:12 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 426B81065693 for ; Wed, 27 Jan 2010 21:49:12 +0000 (UTC) (envelope-from cyrille.lefevre-lists@laposte.net) Received: from out1.laposte.net (out2.laposte.net [193.251.214.119]) by mx1.freebsd.org (Postfix) with ESMTP id F13068FC2A for ; Wed, 27 Jan 2010 21:49:11 +0000 (UTC) Received: from meplus.info (localhost [127.0.0.1]) by mwinf8214.laposte.net (SMTP Server) with ESMTP id EF0287000065; Wed, 27 Jan 2010 22:49:09 +0100 (CET) Received: from [192.168.1.133] (137.228.100-84.rev.gaoland.net [84.100.228.137]) by mwinf8214.laposte.net (SMTP Server) with ESMTP id 8898C7000044; Wed, 27 Jan 2010 22:49:09 +0100 (CET) X-ME-UUID: 20100127214909559.8898C7000044@mwinf8214.laposte.net Message-ID: <4B60B4D4.3020803@laposte.net> Date: Wed, 27 Jan 2010 22:49:08 +0100 From: Cyrille Lefevre Organization: ACME User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; fr; rv:1.8.1.3) Gecko/20070326 Thunderbird/2.0.0.0 Mnenhy/0.7.5.666 MIME-Version: 1.0 To: jhell References: <4B5CEC53.3090402@laposte.net> <20100125025744.GA94378@orion.hsd1.pa.comcast.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable X-me-spamlevel: not-spam X-me-spamrating: 32.799999 X-me-spamcause: OK, (-180)(0000)gggruggvucftvghtrhhoucdtuddrvdeltddruddtucetggdotefuucfrrhhofhhilhgvmecuoehnohhnvgeqnecuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenucdlqddutddtmdenfhhrvggvsghsugefgiculddqfedtmdenfhhrvggvsghsugdgucdlqddutddmneeuufffvdigucdlqddvtddmnehgvghnvghrihgtjdculdeftddmnehtohcutghhrghtucdlhedtmd Cc: freebsd-standard@freebsd.org, freebsd-stable@freebsd.org, Glen Barber Subject: Re: su password prompt ti stdout instead of /dev/tty X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 27 Jan 2010 21:49:12 -0000 jhell a =E9crit : > On Sun, 24 Jan 2010 21:57, glen.j.barber@ wrote: >> >> Cyrille Lefevre wrote: >>> >>> su password prompt is displayed to *stdout* instead of */dev/tty*. >>> >>> # su user >>> $ su root -c date > /tmp/date 2>&1 >>> (nothing displayed) >>> $ cat /tmp/date >>> Password:su: Sorry >>> $ uname -a >>> FreeBSD freebsd8.my.domain 8.0-RELEASE FreeBSD 8.0-RELEASE #0: Sat No= v >>> 21 15:48:17 UTC 2009 >>> root@almeida.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC i386 >>> >>> I suppose this is a getpass() problem ? >>> >=20 > This is intended operation as su(1) may not always be affiliated with a= =20 > TTY. This leaves it open for a script to chat with much like what samba= =20 > does with its passwd chat mechanism. just to feed the debate : aix 5.2 : prompt to tty hp-ux : prompt to stderr netbsd : prompt to tty solaris 9 : prompt to stderr solaris 10 : prompt to tty openbsd : prompt to tty ubuntu : prompt to stderr freebsd is the only one which prompt to stdout ! IMHO, it should at least prompt to stderr if not tty... and report errors to stderr as usually. CC -standard Regards, Cyrille Lefevre --=20 mailto:Cyrille.Lefevre-lists@laposte.net From owner-freebsd-stable@FreeBSD.ORG Wed Jan 27 21:55:10 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 46EBC1065670 for ; Wed, 27 Jan 2010 21:55:10 +0000 (UTC) (envelope-from paul@gromit.dlib.vt.edu) Received: from lennier.cc.vt.edu (lennier.cc.vt.edu [198.82.162.213]) by mx1.freebsd.org (Postfix) with ESMTP id F2DFE8FC13 for ; Wed, 27 Jan 2010 21:55:09 +0000 (UTC) Received: from steiner.cc.vt.edu (steiner.cc.vt.edu [198.82.163.51]) by lennier.cc.vt.edu (8.13.8/8.13.8) with ESMTP id o0RJIhsf018611 for ; Wed, 27 Jan 2010 14:18:43 -0500 Received: from auth3.smtp.vt.edu (EHLO auth3.smtp.vt.edu) ([198.82.161.152]) by steiner.cc.vt.edu (MOS 4.1.8-GA FastPath queued) with ESMTP id EXZ28766; Wed, 27 Jan 2010 14:18:43 -0500 (EST) Received: from gromit.tower.lib.vt.edu (gromit.tower.lib.vt.edu [128.173.51.22]) (authenticated bits=0) by auth3.smtp.vt.edu (8.13.8/8.13.8) with ESMTP id o0RJIhk8007486 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Wed, 27 Jan 2010 14:18:43 -0500 From: Paul Mather Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Wed, 27 Jan 2010 14:18:43 -0500 Message-Id: <432A0ECC-A743-4D24-B508-1EDC9912DD5E@gromit.dlib.vt.edu> To: freebsd-stable@freebsd.org Mime-Version: 1.0 (Apple Message framework v1077) X-Mailer: Apple Mail (2.1077) X-Mirapoint-Received-SPF: 198.82.161.152 auth3.smtp.vt.edu paul@gromit.dlib.vt.edu 5 none X-Mirapoint-IP-Reputation: reputation=neutral-1, source=Fixed, refid=n/a, actions=MAILHURDLE SPF TAG X-Junkmail-Info: (0) X-Junkmail-Status: score=10/50, host=steiner.cc.vt.edu X-Junkmail-SD-Raw: score=unknown, refid=str=0001.0A020203.4B609193.0272,ss=1,fgs=0, ip=0.0.0.0, so=2009-09-22 00:05:22, dmn=2009-09-10 00:05:08, mode=multiengine X-Junkmail-IWF: false Subject: ZFS pool upgrade to v14 broke ZFS booting X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 27 Jan 2010 21:55:10 -0000 I have a FreeBSD guest running under VirtualBox 3.1.2 on Mac OS X. It's = running a recent 8-STABLE and is a ZFS-only install booting via = gptzfsboot. I use this VirtualBox guest as a test install. A day or so ago I noticed "zpool status" report that my pool could be = upgraded from v13 to v14. I did this, via "zfs upgrade -a". Today, when attempting to fire up this FreeBSD guest in VirtualBox I get = this on the console: =3D=3D=3D=3D=3D ZFS: unsupported ZFS version 14 (should be 13) No ZFS pools located, can't boot _ =3D=3D=3D=3D=3D and the boot halts at that point. I don't see the boot menu I normally = see that lists the opportunity to boot single-user; disable ACPI; and so = on. Has anyone else experienced this? Is this a mismatch between gptzfsboot = and my current pool version? (Gptzfsboot includes the message I'm = seeing.) Am I supposed to rebuild and replace gptzfsboot every time the = pool version is updated? (There was no advisory in /usr/src/UPDATING = concerning this, nor do I remember seeing it elsewhere.) Now I have to figure out how to dig out from this. Well, I guess that's = what test installations are for... :-) Cheers, Paul.= From owner-freebsd-stable@FreeBSD.ORG Wed Jan 27 21:59:20 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 86E3510656AC for ; Wed, 27 Jan 2010 21:59:20 +0000 (UTC) (envelope-from cyrille.lefevre-lists@laposte.net) Received: from out5.laposte.net (out6.laposte.net [193.251.214.123]) by mx1.freebsd.org (Postfix) with ESMTP id 19E138FC08 for ; Wed, 27 Jan 2010 21:59:19 +0000 (UTC) Received: from meplus.info (localhost [127.0.0.1]) by mwinf8408.laposte.net (SMTP Server) with ESMTP id 99F827001275; Wed, 27 Jan 2010 22:59:18 +0100 (CET) Received: from [192.168.1.133] (137.228.100-84.rev.gaoland.net [84.100.228.137]) by mwinf8408.laposte.net (SMTP Server) with ESMTP id 345C370011A9; Wed, 27 Jan 2010 22:59:17 +0100 (CET) X-ME-UUID: 20100127215918214.345C370011A9@mwinf8408.laposte.net Message-ID: <4B60B734.7060803@laposte.net> Date: Wed, 27 Jan 2010 22:59:16 +0100 From: Cyrille Lefevre Organization: ACME User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; fr; rv:1.8.1.3) Gecko/20070326 Thunderbird/2.0.0.0 Mnenhy/0.7.5.666 MIME-Version: 1.0 To: jhell References: <4B5CEC53.3090402@laposte.net> <20100125025744.GA94378@orion.hsd1.pa.comcast.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable X-me-spamlevel: not-spam X-me-spamrating: 33.599998 X-me-spamcause: OK, (-160)(0000)gggruggvucftvghtrhhoucdtuddrvdeltddruddtucetggdotefuucfrrhhofhhilhgvmecuoehnohhnvgeqnecuuegrihhlohhuthemuceftddtnecufghrlhcuvffnffculddvtddmneesvcftvggtihhpihgvnhhtshculddquddttddmneculddquddttddmnehfrhgvvggsshgufeigucdlqdeftddmnehfrhgvvggsshgugdculddquddtmdenuefuffdvgiculddqvddtmdenghgvnhgvrhhitgdjucdlfedtmdenthhoucgthhgrthculdehtddm Cc: freebsd-stable@freebsd.org, freebsd-standards@freebsd.org, Glen Barber Subject: Re: su password prompt to stdout instead of /dev/tty X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 27 Jan 2010 21:59:20 -0000 sorry, repost to -standards w/ an s ! jhell a =E9crit : > On Sun, 24 Jan 2010 21:57, glen.j.barber@ wrote: >> >> Cyrille Lefevre wrote: >>> >>> su password prompt is displayed to *stdout* instead of */dev/tty*. >>> >>> # su user >>> $ su root -c date > /tmp/date 2>&1 >>> (nothing displayed) >>> $ cat /tmp/date >>> Password:su: Sorry >>> $ uname -a >>> FreeBSD freebsd8.my.domain 8.0-RELEASE FreeBSD 8.0-RELEASE #0: Sat No= v >>> 21 15:48:17 UTC 2009 >>> root@almeida.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC i386 >>> >>> I suppose this is a getpass() problem ? >>> >=20 > This is intended operation as su(1) may not always be affiliated with a= =20 > TTY. This leaves it open for a script to chat with much like what samba= =20 > does with its passwd chat mechanism. just to feed the debate : aix 5.2 : prompt to tty hp-ux : prompt to stderr netbsd : prompt to tty solaris 9 : prompt to stderr solaris 10 : prompt to tty openbsd : prompt to tty ubuntu : prompt to stderr freebsd is the only one which prompt to stdout ! IMHO, it should at least prompt to stderr if not tty... and report errors to stderr as usually. CC -standards Regards, Cyrille Lefevre --=20 mailto:Cyrille.Lefevre-lists@laposte.net _______________________________________________ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org"= From owner-freebsd-stable@FreeBSD.ORG Wed Jan 27 22:52:47 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 995C8106566C for ; Wed, 27 Jan 2010 22:52:47 +0000 (UTC) (envelope-from mattjreimer@gmail.com) Received: from mail-yx0-f192.google.com (mail-yx0-f192.google.com [209.85.210.192]) by mx1.freebsd.org (Postfix) with ESMTP id 541748FC1E for ; Wed, 27 Jan 2010 22:52:47 +0000 (UTC) Received: by yxe30 with SMTP id 30so61770yxe.29 for ; Wed, 27 Jan 2010 14:52:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=8nbnPR6HFhOx/7O73qYzJiecgoQDQRe3DqtON9pr0EY=; b=Z4yAy4HwB+6wyozxrLkZWodzVYx5a1mqg+ZXb/2ERsCKmzudZKMq9UiDC/ajOjccDf ZseOQB5p+pDI0t79/1EMYYqs1/CNZZvn44EOTTkBVtdyNgaJelF+VB9lkRgBm3xc39lL RrWbPQmS1MJMwIZCFVdf1AfvnP5ruvo+LKSlU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=c5kPpoDn9pq7ariNaqkgYjkP1P45u3d3BiwlJBTkxo1cZ10wmax+VBa4WvyVyigMMh CAUJ2MZm+pBnST+SHx5HfoOve4l5+O31k/femd+emJvmHpEhQWmCFPWPumkASDVVKrfF T2J1XAfPu31kANyiIfreNwdjEdYWbG9v8L8/k= MIME-Version: 1.0 Received: by 10.150.252.13 with SMTP id z13mr13629505ybh.116.1264632766586; Wed, 27 Jan 2010 14:52:46 -0800 (PST) In-Reply-To: <432A0ECC-A743-4D24-B508-1EDC9912DD5E@gromit.dlib.vt.edu> References: <432A0ECC-A743-4D24-B508-1EDC9912DD5E@gromit.dlib.vt.edu> Date: Wed, 27 Jan 2010 14:52:46 -0800 Message-ID: From: Matt Reimer To: Paul Mather Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-stable@freebsd.org Subject: Re: ZFS pool upgrade to v14 broke ZFS booting X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 27 Jan 2010 22:52:47 -0000 On Wed, Jan 27, 2010 at 11:18 AM, Paul Mather wrote: > I have a FreeBSD guest running under VirtualBox 3.1.2 on Mac OS X. It's > running a recent 8-STABLE and is a ZFS-only install booting via gptzfsboot. > I use this VirtualBox guest as a test install. > > A day or so ago I noticed "zpool status" report that my pool could be > upgraded from v13 to v14. I did this, via "zfs upgrade -a". > > Today, when attempting to fire up this FreeBSD guest in VirtualBox I get > this on the console: > > ===== > ZFS: unsupported ZFS version 14 (should be 13) > No ZFS pools located, can't boot > _ > ===== > > and the boot halts at that point. I don't see the boot menu I normally see > that lists the opportunity to boot single-user; disable ACPI; and so on. > > Has anyone else experienced this? Is this a mismatch between gptzfsboot > and my current pool version? (Gptzfsboot includes the message I'm seeing.) > Am I supposed to rebuild and replace gptzfsboot every time the pool version > is updated? (There was no advisory in /usr/src/UPDATING concerning this, > nor do I remember seeing it elsewhere.) > > Yes, you're running a version of gptzfsboot that only knows how to run version 13 and below. The commit that brought in version 14 support also bumped the version number for gptzfsboot though it doesn't look like any of the code changed; perhaps version 14 doesn't change anything that gptzfsboot cares about. Try rebuilding and reinstalling gptzfsboot and zfsloader to see if that helps: cd /sys/boot make cleandir make cleandir make obj make depend make all make install gpart bootcode -p /boot/gptzfsboot -i 1 /dev/somedisk Of course adjust the gpart command for your setup. Matt From owner-freebsd-stable@FreeBSD.ORG Wed Jan 27 23:04:05 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 57F13106566C for ; Wed, 27 Jan 2010 23:04:05 +0000 (UTC) (envelope-from delphij@delphij.net) Received: from tarsier.geekcn.org (tarsier.geekcn.org [IPv6:2001:470:a803::1]) by mx1.freebsd.org (Postfix) with ESMTP id 0132C8FC0C for ; Wed, 27 Jan 2010 23:04:05 +0000 (UTC) Received: from mail.geekcn.org (tarsier.geekcn.org [211.166.10.233]) by tarsier.geekcn.org (Postfix) with ESMTP id 15293A5BF1C; Thu, 28 Jan 2010 07:04:03 +0800 (CST) X-Virus-Scanned: amavisd-new at geekcn.org Received: from tarsier.geekcn.org ([211.166.10.233]) by mail.geekcn.org (mail.geekcn.org [211.166.10.233]) (amavisd-new, port 10024) with LMTP id yFhL-LeCN9XJ; Thu, 28 Jan 2010 07:03:55 +0800 (CST) Received: from delta.delphij.net (drawbridge.ixsystems.com [206.40.55.65]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by tarsier.geekcn.org (Postfix) with ESMTPSA id 085AFA55025; Thu, 28 Jan 2010 07:03:52 +0800 (CST) DomainKey-Signature: a=rsa-sha1; s=default; d=delphij.net; c=nofws; q=dns; h=message-id:date:from:reply-to:organization:user-agent: mime-version:to:subject:references:in-reply-to:x-enigmail-version:openpgp: content-type:content-transfer-encoding; b=hVt3w1mOCHnpco2RjJdS8Rg6+NRbhhityy1mPiJKx+V35qDtaMntiSO9o7raXt9sR EXpvzUpNXgo/8Uysb2qXQ== Message-ID: <4B60C652.8050208@delphij.net> Date: Wed, 27 Jan 2010 15:03:46 -0800 From: Xin LI Organization: The Geek China Organization User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.1.7) Gecko/20100122 Thunderbird/3.0.1 ThunderBrowse/3.2.8.1 MIME-Version: 1.0 To: freebsd-stable@freebsd.org References: <432A0ECC-A743-4D24-B508-1EDC9912DD5E@gromit.dlib.vt.edu> In-Reply-To: <432A0ECC-A743-4D24-B508-1EDC9912DD5E@gromit.dlib.vt.edu> X-Enigmail-Version: 1.0 OpenPGP: id=3FCA37C1; url=http://www.delphij.net/delphij.asc Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: ZFS pool upgrade to v14 broke ZFS booting X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: d@delphij.net List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jan 2010 23:04:05 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, On 2010/01/27 11:18, Paul Mather wrote: > I have a FreeBSD guest running under VirtualBox 3.1.2 on Mac OS X. It's running a recent 8-STABLE and is a ZFS-only install booting via gptzfsboot. I use this VirtualBox guest as a test install. > > A day or so ago I noticed "zpool status" report that my pool could be upgraded from v13 to v14. I did this, via "zfs upgrade -a". > > Today, when attempting to fire up this FreeBSD guest in VirtualBox I get this on the console: > > ===== > ZFS: unsupported ZFS version 14 (should be 13) > No ZFS pools located, can't boot > _ > ===== > > and the boot halts at that point. I don't see the boot menu I normally see that lists the opportunity to boot single-user; disable ACPI; and so on. > > Has anyone else experienced this? Is this a mismatch between gptzfsboot and my current pool version? (Gptzfsboot includes the message I'm seeing.) Am I supposed to rebuild and replace gptzfsboot every time the pool version is updated? (There was no advisory in /usr/src/UPDATING concerning this, nor do I remember seeing it elsewhere.) > > Now I have to figure out how to dig out from this. Well, I guess that's what test installations are for... :-) There is no on-disk format change that affects ZFS boot itself, but you will need to install new gptzfsboot. If you have another system and have the file, you can do it by booting from the LiveFS Disc, fetch it from network, and use gpart to install it. Cheers, - -- Xin LI http://www.delphij.net/ FreeBSD - The Power to Serve! Live free or die -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.14 (FreeBSD) iQEcBAEBAgAGBQJLYMZSAAoJEATO+BI/yjfBgNcH/jwK8bZTlX6Dr0wKYRRaaa72 wuTswokvVLCr6xZJbo18/je8F68tXkYqBdPSVm2pZsZs4kBPw8gHzQWNdQcIudVN m4qhE8QlAZVd8DIXk6hJM+7A/k6k9vo6AtHYY/nvNsKrk9Xxo1rDI5cVo9WMJeB2 6ONbPAG6aDOGEFyICRo4NoB6Qbh/Ylzx4wiLkENrI2SdDDlZQ1YmaXl8RFtCAMoK LjnNt+G/cAIm/MvYzFbEDa1Ok5YD/Osc74P+fPJvJSYNd/QmJ4PU+Lb4MPsrKBU0 FtAHl5o3f7xz1YTwmybY+9Sw67izDIDc8lalNiguTj77Uj8zLiete91t/c7BmIE= =6CG3 -----END PGP SIGNATURE----- From owner-freebsd-stable@FreeBSD.ORG Wed Jan 27 23:27:45 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A20491065676; Wed, 27 Jan 2010 23:27:45 +0000 (UTC) (envelope-from dimitry@andric.com) Received: from tensor.andric.com (cl-327.ede-01.nl.sixxs.net [IPv6:2001:7b8:2ff:146::2]) by mx1.freebsd.org (Postfix) with ESMTP id 67AEB8FC1B; Wed, 27 Jan 2010 23:27:45 +0000 (UTC) Received: from [IPv6:2001:7b8:3a7:0:481c:61a7:de40:51a1] (unknown [IPv6:2001:7b8:3a7:0:481c:61a7:de40:51a1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id 9826A5C43; Thu, 28 Jan 2010 00:27:44 +0100 (CET) Message-ID: <4B60CBFA.4050601@andric.com> Date: Thu, 28 Jan 2010 00:27:54 +0100 From: Dimitry Andric User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.2; en-US; rv:1.9.2pre) Gecko/20100126 Lanikai/3.1b1pre MIME-Version: 1.0 To: John Baldwin References: <201001271627.37955.jhb@freebsd.org> In-Reply-To: <201001271627.37955.jhb@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Dan Naumov , freebsd-stable@freebsd.org, freebsd-questions@freebsd.org Subject: Re: booting off GPT partitions X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 27 Jan 2010 23:27:45 -0000 On 2010-01-27 22:27, John Baldwin wrote: > GPT was defined along with EFI, so many folks assume that you have to use EFI > to boot a GPT-labelled disk. However, FreeBSD has its own BIOS-based > bootstrap that can handle GPT-labelled disks. I doubt the SuperMicro tech is > familiar with that case. I thought I heard that some folks had added GPT > support to grub as well. However, this won't boot disks larger than 2TiB, right? At least not without BIOS support... From owner-freebsd-stable@FreeBSD.ORG Wed Jan 27 23:55:54 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 89D2F106566C for ; Wed, 27 Jan 2010 23:55:54 +0000 (UTC) (envelope-from aw1@swelter.hanley.stade.co.uk) Received: from v-smtp-auth-relay-3.gradwell.net (v-smtp-auth-relay-3.gradwell.net [79.135.125.42]) by mx1.freebsd.org (Postfix) with ESMTP id E99528FC12 for ; Wed, 27 Jan 2010 23:55:53 +0000 (UTC) Received: from 93-97-22-18.zone5.bethere.co.uk ([93.97.22.18] helo=swelter.hanley.stade.co.uk country=GB ident=postmaster&pop3^stade^co&uk) by v-smtp-auth-relay-3.gradwell.net with esmtpa (Gradwell gwh-smtpd 1.290) id 4b60d288.5f8a.a5 for freebsd-stable@freebsd.org; Wed, 27 Jan 2010 23:55:52 +0000 (envelope-sender ) Received: from swelter.hanley.stade.co.uk (localhost [127.0.0.1]) by swelter.hanley.stade.co.uk (8.14.3/8.14.3) with ESMTP id o0RNtnT2045311 for ; Wed, 27 Jan 2010 23:55:49 GMT (envelope-from aw1@swelter.hanley.stade.co.uk) Received: (from aw1@localhost) by swelter.hanley.stade.co.uk (8.14.3/8.14.3/Submit) id o0RNtnwE045310 for freebsd-stable@freebsd.org; Wed, 27 Jan 2010 23:55:49 GMT (envelope-from aw1) Date: Wed, 27 Jan 2010 23:55:49 +0000 From: Adrian Wontroba To: FreeBSD-STABLE Mailing List Message-ID: <20100127235549.GA44968@swelter.hanley.stade.co.uk> Mail-Followup-To: Adrian Wontroba , FreeBSD-STABLE Mailing List References: <4B6022C6.1090608@andric.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4B6022C6.1090608@andric.com> User-Agent: Mutt/1.4.2.3i X-Operating-System: FreeBSD 8.0-STABLE Organization: Oh dear, I've joined one again. X-Virus-Scanned: clamav-milter 0.95.3 at swelter.hanley.stade.co.uk X-Virus-Status: Clean Subject: Re: immense delayed write to file system (ZFS and UFS2), performance issues X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: aw1@stade.co.uk List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jan 2010 23:55:54 -0000 On Wed, Jan 27, 2010 at 12:25:58PM +0100, Dimitry Andric wrote: > On 2010-01-27 00:15, Dan Naumov wrote: > Sorry to bump into this thread so late, but for some of my servers I > have been using a patch for atacontrol, to turn the APM features of the > disk(s) off, for a long time. This is mostly noticable with 2.5" > notebook disks, which "click" like crazy all the time. :) Turning off APM seems to be the LINUX world's solution to this and other similar problems. I got the impression that Windows also does this. -- Adrian Wontroba Save energy: be apathetic. From owner-freebsd-stable@FreeBSD.ORG Thu Jan 28 01:42:58 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4970B1065679 for ; Thu, 28 Jan 2010 01:42:58 +0000 (UTC) (envelope-from egypcio@gmail.com) Received: from mail-fx0-f226.google.com (mail-fx0-f226.google.com [209.85.220.226]) by mx1.freebsd.org (Postfix) with ESMTP id D25408FC19 for ; Thu, 28 Jan 2010 01:42:57 +0000 (UTC) Received: by fxm26 with SMTP id 26so193000fxm.13 for ; Wed, 27 Jan 2010 17:42:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type :content-transfer-encoding; bh=nRUaytySXGYD7r7icS2QmoBA04ulBIprFriv2EJBMpg=; b=ED5JZJI6qSEdM7Tj9VRZ22VSyttOfaHoPy/b90oCbgZC3GU/oQ1u4VIRXCFeUepJKL cLuEx0G8sdsPdaBid70qDajH70pb1W160viCmbT930jHadrKCsrDA437wV4oQMMsY5D6 oZ8anZ/uuIHpCGWr4tdZoZRajNKZmy+/1dFUc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; b=QteMzFFzrFckILbZBc+x1RzGZRee8upSYXF/A5ByQUbKlft/TZOWDFE4dZmKQwnuQH B4EFhrIpoyUAnnq+fFx80g1DHrp6mpsYBMdQkr15Hi6UG4kOjAYIpQxWVtMSF33g9+d7 Xx4HGPsGUBzhC7Yc+4xvM6aqsv2f3dqRMkkgU= MIME-Version: 1.0 Received: by 10.239.132.203 with SMTP id 11mr316402hbs.84.1264642976855; Wed, 27 Jan 2010 17:42:56 -0800 (PST) In-Reply-To: References: <8b5ad0e11001270926o19d1701fid30ba5a49cbb39b5@mail.gmail.com> Date: Wed, 27 Jan 2010 22:42:56 -0300 Message-ID: <8b5ad0e11001271742oc82a95bo7fcbf044015f1618@mail.gmail.com> From: =?ISO-8859-1?Q?Zavam=2C_Vin=EDcius?= To: freebsd-stable@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: freebsd 8.0 stable amd64/x86 needs ~9min to bootup X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jan 2010 01:42:58 -0000 2010/1/27 Aioanei Rares : > > > On Wed, 27 Jan 2010, Zavam, Vin=EDcius wrote: > >> noon, all you guys. >> >> well, I'm having some issues during the 8.0-stable bootup process. >> it takes ~9min to finish the entire boot process to shows me the >> "login:" screen. >> >> since my first installation attempt to get freebsd up and running here >> with my dv3-2155mx[1] hp pavilion laptop using 8.0-RC1 amd64 iso I >> could not boot freebsd up smooth and nicely as it always did for me in >> my last laptop (dv6130us)[2], but I could install it without any >> problem. >> you may check http://www.youtube.com/watch?v=3Dgqtz7E7u4fA to see what >> realy happens. >> >> now I'm using a grub 0.97 from my old gentoo linux installation to >> bootstrap the freebsd loader. >> I tryed debug and verbose options using grub and freebsd loader.conf >> but both just result nothing special. >> >> I've been updated and downgraded my laptop bios (by Insyde Software / >> HP) but got no good results either. I tryed versions F1.3A, F1.2, F0.7 >> and the original F0.6 version that came originally from HP. >> >> to try another way to get into 8.0-stable or 9-current I used 7.2, >> 7.1, 6.4 and 6.2 release x86 and amd64 iso images to install freebsd >> and an it's older btx loader but, unfortunately, got the same. it >> always "freezes" ~9min. >> >> I can use freebsd after all the bootup process with no problem. >> It's a 8.0-stable amd64 now. but I realy wanna know how could I solve >> this issue. >> >> read some cases/PRs/issues with other hp laptops but nothing like this >> one I have. one of the problems I read was about dv6000 series - >> weird, it was my old laptop serie and everything was just fine >> installing, booting and running freebsd into. >> >> what you guys think about it? can you give me a hand or a glue to pass >> this through? >> >> thanks. >> >> [1] >> http://h10025.www1.hp.com/ewfrf/wc/document?docname=3Dc01777298&cc=3Dus&= lc=3Den&dlc=3Den >> [2] >> http://h10025.www1.hp.com/ewfrf/wc/document?docname=3Dc00782284&cc=3Dus&= lc=3Den&dlc=3Den >> >> >> >> -- >> Zavam, Vin=EDcius > > I suppose you tried, but I am gonna ask anyway : you did try with ACPI > disabled, right? rares, the issue happens before the beastie menu shows up. --=20 Zavam, Vin=EDcius From owner-freebsd-stable@FreeBSD.ORG Thu Jan 28 01:45:23 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 00ED91065672 for ; Thu, 28 Jan 2010 01:45:23 +0000 (UTC) (envelope-from egypcio@gmail.com) Received: from mail-fx0-f226.google.com (mail-fx0-f226.google.com [209.85.220.226]) by mx1.freebsd.org (Postfix) with ESMTP id 89E338FC1E for ; Thu, 28 Jan 2010 01:45:22 +0000 (UTC) Received: by fxm26 with SMTP id 26so194357fxm.13 for ; Wed, 27 Jan 2010 17:45:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type :content-transfer-encoding; bh=ExCNfcYWr8iKvBcrKIA4T+hjUxyhkhzsagPJXUnK3U8=; b=NY7bP0wJIc0/YXjA45MBKXHNQMKz5nAK9+L42dzFZgUTGUDUjgQYaVdL5aIlNTXP/O qBY4I7n5ESE48roK6gPi23ijpUJTHcajfNL2wVSUR+AKezCbhCqofIOvhkblODU2ygE2 eAkXUTyBkHpWHqeiALaRrfqzYVU3OLrYBlCbY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; b=fDTjicoAmHJY9RxEOa71hOwqF6qkaXdii5yu1mI4oqJF8TRWmaNEU5vRysY+eZGqav uUVwZQzpYmnsvk71sob/IavrTL5rOlnBePUTbUDBIJeVhChxC9DYnhiFhNJUYWgkf1NO mY1gjOVJisFv13KgnQ3lhoX68F9IOGjqKVq9M= MIME-Version: 1.0 Received: by 10.239.136.133 with SMTP id h5mr1157084hbh.126.1264643121420; Wed, 27 Jan 2010 17:45:21 -0800 (PST) In-Reply-To: References: <8b5ad0e11001270926o19d1701fid30ba5a49cbb39b5@mail.gmail.com> Date: Wed, 27 Jan 2010 22:45:21 -0300 Message-ID: <8b5ad0e11001271745j5e681762j7dd8f79c23a94bf@mail.gmail.com> From: =?ISO-8859-1?Q?Zavam=2C_Vin=EDcius?= To: freebsd-stable@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: freebsd 8.0 stable amd64/x86 needs ~9min to bootup X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jan 2010 01:45:23 -0000 2010/1/27 Matt Reimer : > 2010/1/27 Zavam, Vin=EDcius >> >> noon, all you guys. >> >> well, I'm having some issues during the 8.0-stable bootup process. >> it takes ~9min to finish the entire boot process to shows me the >> "login:" screen. > > Are you using zfsloader? A month or so ago the ZFS code was updated to pr= obe > all 128 possible GPT partitions instead of just four, resulting in a > slow-down, but probably not nine minutes' worth. > Matt no. I'm not using zfsloader or/and ZFS. --=20 Zavam, Vin=EDcius From owner-freebsd-stable@FreeBSD.ORG Thu Jan 28 02:24:48 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 802F41065679; Thu, 28 Jan 2010 02:24:48 +0000 (UTC) (envelope-from brooks@lor.one-eyed-alien.net) Received: from lor.one-eyed-alien.net (lor.one-eyed-alien.net [69.66.77.232]) by mx1.freebsd.org (Postfix) with ESMTP id 34B518FC1B; Thu, 28 Jan 2010 02:24:47 +0000 (UTC) Received: from lor.one-eyed-alien.net (localhost [127.0.0.1]) by lor.one-eyed-alien.net (8.14.3/8.14.3) with ESMTP id o0S2Nt9X046961; Wed, 27 Jan 2010 20:23:55 -0600 (CST) (envelope-from brooks@lor.one-eyed-alien.net) Received: (from brooks@localhost) by lor.one-eyed-alien.net (8.14.3/8.14.3/Submit) id o0S2Nnsr046960; Wed, 27 Jan 2010 20:23:49 -0600 (CST) (envelope-from brooks) Date: Wed, 27 Jan 2010 20:23:49 -0600 From: Brooks Davis To: Dimitry Andric Message-ID: <20100128022349.GB46919@lor.one-eyed-alien.net> References: <201001271627.37955.jhb@freebsd.org> <4B60CBFA.4050601@andric.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="AhhlLboLdkugWU4S" Content-Disposition: inline In-Reply-To: <4B60CBFA.4050601@andric.com> User-Agent: Mutt/1.5.17 (2007-11-01) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0 (lor.one-eyed-alien.net [127.0.0.1]); Wed, 27 Jan 2010 20:23:55 -0600 (CST) Cc: freebsd-stable@freebsd.org, Dan Naumov , freebsd-questions@freebsd.org, John Baldwin Subject: Re: booting off GPT partitions X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 28 Jan 2010 02:24:48 -0000 --AhhlLboLdkugWU4S Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Jan 28, 2010 at 12:27:54AM +0100, Dimitry Andric wrote: > On 2010-01-27 22:27, John Baldwin wrote: >> GPT was defined along with EFI, so many folks assume that you have to us= e EFI >> to boot a GPT-labelled disk. However, FreeBSD has its own BIOS-based >> bootstrap that can handle GPT-labelled disks. I doubt the SuperMicro te= ch is >> familiar with that case. I thought I heard that some folks had added GPT >> support to grub as well. >=20 > However, this won't boot disks larger than 2TiB, right? At least not > without BIOS support... You won't be able to boot from a partition more than 2TiB in, but you should still be able to boot as long as you boot from the front part of the disk. -- Brook --AhhlLboLdkugWU4S Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (FreeBSD) iD8DBQFLYPU1XY6L6fI4GtQRAov9AJ0b6IZwb4rqIb/TbfssEoV/djwpwACePrWF g9Z6zw9wMhIZ3zsgm/e6oRI= =3k/J -----END PGP SIGNATURE----- --AhhlLboLdkugWU4S-- From owner-freebsd-stable@FreeBSD.ORG Thu Jan 28 03:47:08 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0FE90106566B for ; Thu, 28 Jan 2010 03:47:08 +0000 (UTC) (envelope-from zbeeble@gmail.com) Received: from mail-ew0-f218.google.com (mail-ew0-f218.google.com [209.85.219.218]) by mx1.freebsd.org (Postfix) with ESMTP id 993118FC13 for ; Thu, 28 Jan 2010 03:47:07 +0000 (UTC) Received: by ewy10 with SMTP id 10so312666ewy.3 for ; Wed, 27 Jan 2010 19:47:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=zb+DFfhUZACvtvy6PbADKkSFIpXb5gnyFgeVU0bQH/o=; b=D2eM8nzXkv8vXYryxalistUnwscw6qKNL5gDhaTWxYWXK4N7P29VUzbfexs4rqyeGl x5nd/iNjiSlMdzyztBSfpG1tLTQFhPhCDGbnkwY9yaBQK9pppov0FkhYGOBMMNXga6Ta aH64/6jITupa8u+kCGArnHdP+McSk36fsQmgo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=Bvl7xRnqF4TgfTaJnaUgjlBOPElqokjqTfzHmcQBKWfsFzBOUaqpPckOwH0P1j2HQ0 XuA5is+RFG8b8hQXG+zzQl6J6mKTpuE3tLa9z2r2KzQdMscjhTsX98ayam8yzSEPauzC F7NpIgK3DCUqZH4EKL8rlkdleAyUa5/vqmUM0= MIME-Version: 1.0 Received: by 10.216.89.18 with SMTP id b18mr647057wef.14.1264650426557; Wed, 27 Jan 2010 19:47:06 -0800 (PST) In-Reply-To: <4B60C652.8050208@delphij.net> References: <432A0ECC-A743-4D24-B508-1EDC9912DD5E@gromit.dlib.vt.edu> <4B60C652.8050208@delphij.net> Date: Wed, 27 Jan 2010 22:47:06 -0500 Message-ID: <5f67a8c41001271947o9673824g1714666b32bae714@mail.gmail.com> From: Zaphod Beeblebrox To: d@delphij.net Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-stable@freebsd.org Subject: Re: ZFS pool upgrade to v14 broke ZFS booting X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 28 Jan 2010 03:47:08 -0000 On Wed, Jan 27, 2010 at 6:03 PM, Xin LI wrote: > On 2010/01/27 11:18, Paul Mather wrote: >> I have a FreeBSD guest running under VirtualBox 3.1.2 on Mac OS X. =A0It= 's running a recent 8-STABLE and is a ZFS-only install booting via gptzfsbo= ot. =A0I use this VirtualBox guest as a test install. >> A day or so ago I noticed "zpool status" report that my pool could be up= graded from v13 to v14. =A0I did this, via "zfs upgrade -a". >> Today, when attempting to fire up this FreeBSD guest in VirtualBox I get= this on the console: >> ZFS: unsupported ZFS version 14 (should be 13) >> No ZFS pools located, can't boot > There is no on-disk format change that affects ZFS boot itself, but you > will need to install new gptzfsboot. =A0If you have another system and > have the file, you can do it by booting from the LiveFS Disc, fetch it > from network, and use gpart to install it. Since this is so fatal, you might want to give them the option to continue here. I suspect that zpool format changes that truly break the boot loader (which is read-only at any rate) are uncommon where the chances of ending up in this situation (with an unbootable machine) are much more common. From owner-freebsd-stable@FreeBSD.ORG Thu Jan 28 05:11:29 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F0385106566B for ; Thu, 28 Jan 2010 05:11:29 +0000 (UTC) (envelope-from bu7cher@yandex.ru) Received: from forward12.mail.yandex.net (forward12.mail.yandex.net [95.108.130.94]) by mx1.freebsd.org (Postfix) with ESMTP id A09FF8FC1B for ; Thu, 28 Jan 2010 05:11:29 +0000 (UTC) Received: from smtp14.mail.yandex.net (smtp14.mail.yandex.net [95.108.131.192]) by forward12.mail.yandex.net (Yandex) with ESMTP id 9276615D18B1; Thu, 28 Jan 2010 08:11:27 +0300 (MSK) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1264655487; bh=+Iv9ly8gKZe9NxIbBA7PXak5M8EPmNB1gmVTLLbKk8g=; h=Message-ID:Date:From:MIME-Version:To:CC:Subject:References: In-Reply-To:Content-Type:Content-Transfer-Encoding; b=LNWMxuR0GQvFK0JfpY+sM3GfA0qhYa7iguI+wz6W8LH48RBL4pszPa4j/ZxYFRB6M Be7p3B5B/WLDBY2ohmL+QoCsK2tcvNmuHPcWqLlLjU0NwtOkm/FiwOJ2oxZ1xR1gTo guh3wteYLQ0JJfA+DSY3nIKoZLDYzpiytM6uGWSk= Received: from [127.0.0.1] (mail.kirov.so-cdu.ru [77.72.136.145]) by smtp14.mail.yandex.net (Yandex) with ESMTPSA id 6517D68058; Thu, 28 Jan 2010 08:11:27 +0300 (MSK) Message-ID: <4B611C7E.1000708@yandex.ru> Date: Thu, 28 Jan 2010 08:11:26 +0300 From: "Andrey V. Elsukov" User-Agent: Mozilla Thunderbird 1.5 (FreeBSD/20051231) MIME-Version: 1.0 To: d@delphij.net References: <432A0ECC-A743-4D24-B508-1EDC9912DD5E@gromit.dlib.vt.edu> <4B60C652.8050208@delphij.net> In-Reply-To: <4B60C652.8050208@delphij.net> Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: 7bit X-Yandex-TimeMark: 1264655487 X-Yandex-Spam: 1 X-Yandex-Front: smtp14.mail.yandex.net Cc: freebsd-stable@freebsd.org, Xin LI Subject: Re: ZFS pool upgrade to v14 broke ZFS booting X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 28 Jan 2010 05:11:30 -0000 On 28.01.2010 2:03, Xin LI wrote: > There is no on-disk format change that affects ZFS boot itself, but you > will need to install new gptzfsboot. If you have another system and > have the file, you can do it by booting from the LiveFS Disc, fetch it > from network, and use gpart to install it. Some time ago i had the same problem. I think it is good idea to add a note about updating gptzfsboot in src/UPDATING. -- WBR, Andrey V. Elsukov From owner-freebsd-stable@FreeBSD.ORG Thu Jan 28 06:06:27 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 781F5106566C for ; Thu, 28 Jan 2010 06:06:27 +0000 (UTC) (envelope-from bms@incunabulum.net) Received: from out2.smtp.messagingengine.com (out2.smtp.messagingengine.com [66.111.4.26]) by mx1.freebsd.org (Postfix) with ESMTP id 46E178FC1B for ; Thu, 28 Jan 2010 06:06:27 +0000 (UTC) Received: from compute1.internal (compute1.internal [10.202.2.41]) by gateway1.messagingengine.com (Postfix) with ESMTP id C11FACE21D; Thu, 28 Jan 2010 01:06:26 -0500 (EST) Received: from heartbeat2.messagingengine.com ([10.202.2.161]) by compute1.internal (MEProxy); Thu, 28 Jan 2010 01:06:26 -0500 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=messagingengine.com; h=message-id:date:from:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; s=smtpout; bh=NgkTIryKD+SJIsSfjYO3lLhYl0k=; b=GcoHOJuT9F5a978f+AUAVD1tpBtxQJ6Wq+eKb0rJ8ws5+vyaWRkbnYFAftNsnjlc2H13sQs8UFed5zaWq6/h2Y+KuF8QKGDBbwJmrBZ9UC0cGA7xkSx80rxHinZputo0W7WqJRUG1jxomMBdTyJfuFjjsyJPjL12ZO71/ztpfes= X-Sasl-enc: GgQ2lc2uhrxM0F9hf1PHhtFkkNPj4JFi6+uAE3c6JGLD 1264658786 Received: from anglepoise.lon.incunabulum.net (cpc2-dals7-0-0-cust253.hari.cable.virginmedia.com [82.35.112.254]) by mail.messagingengine.com (Postfix) with ESMTPSA id 48F5F3145A; Thu, 28 Jan 2010 01:06:26 -0500 (EST) Message-ID: <4B61295F.1030802@incunabulum.net> Date: Thu, 28 Jan 2010 06:06:23 +0000 From: Bruce Simpson User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.1.7) Gecko/20100124 Thunderbird/3.0.1 MIME-Version: 1.0 To: =?ISO-8859-1?Q?=22Zavam=2C_Vin=EDcius=22?= References: <8b5ad0e11001270926o19d1701fid30ba5a49cbb39b5@mail.gmail.com> In-Reply-To: <8b5ad0e11001270926o19d1701fid30ba5a49cbb39b5@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org Subject: Re: freebsd 8.0 stable amd64/x86 needs ~9min to bootup X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jan 2010 06:06:27 -0000 Try GRUB4DOS. I use this so on boxes where I have Windows installed, I can keep GRUB in the NTFS partition. I haven't seen this issue and am tracking -STABLE on an ASUS V-series machine. From owner-freebsd-stable@FreeBSD.ORG Thu Jan 28 10:45:30 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E7598106566B for ; Thu, 28 Jan 2010 10:45:30 +0000 (UTC) (envelope-from egypcio@gmail.com) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.158]) by mx1.freebsd.org (Postfix) with ESMTP id 7C1448FC14 for ; Thu, 28 Jan 2010 10:45:30 +0000 (UTC) Received: by fg-out-1718.google.com with SMTP id 16so231498fgg.13 for ; Thu, 28 Jan 2010 02:45:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type :content-transfer-encoding; bh=b3NKl8iwjmHUQmjiPiRZ4FPzG+aLbFeCyYe6GrgR79w=; b=cGdwHJxGd9oqs5QYPcHWxt21laFUly4h/1PcxtLzZBfJ3tqR9A8w5AaeuWFdFEeYQU RKgvYJlPbms1vkY7Tue9R9s9H8QkX5rQp3AUV6x8GzsSM6/tdnpq4+3NEAKeoTCVRxdW NMv8VktPUxqIeGAv+PbDKz/x87Wlvo9GoK680= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; b=ahPydp+kvJO9ezw1xQsRENWYuvx/G5oxhC4QOoRVQ6uGHLy2U6DnKjSP1itUp1U8rQ fGy4W5luiz8LnOA0c3TYkrMdS3UH9Dsi3PKpBtrIMuu8sZzPg+MT+tiYPC2yQKbwz9kV vxngGfgzoh5QA+sr23toRiKalclsWmf7b9/BM= MIME-Version: 1.0 Received: by 10.239.132.203 with SMTP id 11mr370908hbs.84.1264675529402; Thu, 28 Jan 2010 02:45:29 -0800 (PST) In-Reply-To: <4B61295F.1030802@incunabulum.net> References: <8b5ad0e11001270926o19d1701fid30ba5a49cbb39b5@mail.gmail.com> <4B61295F.1030802@incunabulum.net> Date: Thu, 28 Jan 2010 07:45:29 -0300 Message-ID: <8b5ad0e11001280245h703990a3t2085588e141b0ab6@mail.gmail.com> From: =?ISO-8859-1?Q?Zavam=2C_Vin=EDcius?= To: freebsd-stable@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: freebsd 8.0 stable amd64/x86 needs ~9min to bootup X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jan 2010 10:45:31 -0000 2010/1/28 Bruce Simpson : > Try GRUB4DOS. I use this so on boxes where I have Windows installed, I ca= n > keep GRUB in the NTFS partition. > > I haven't seen this issue and am tracking -STABLE on an ASUS V-series > machine. > Simpson, I forgot to mention... but I tested it using boot0 (freebsd's bootmanager) with no success ;< had no shots with grub4dos, gag, lilo or grub2; I assume it may not be a bootmanager issue, but freebsd's btx bootstrap loader. my gentoo and windows o.s. can be loaded using grub or boot0. --=20 Zavam, Vin=EDcius From owner-freebsd-stable@FreeBSD.ORG Thu Jan 28 12:06:57 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AB0611065692; Thu, 28 Jan 2010 12:06:57 +0000 (UTC) (envelope-from rnoland@FreeBSD.org) Received: from gizmo.2hip.net (gizmo.2hip.net [64.74.207.195]) by mx1.freebsd.org (Postfix) with ESMTP id 6A64A8FC13; Thu, 28 Jan 2010 12:06:57 +0000 (UTC) Received: from [192.168.1.4] (adsl-149-142-141.bna.bellsouth.net [70.149.142.141]) (authenticated bits=0) by gizmo.2hip.net (8.14.3/8.14.3) with ESMTP id o0SC6p9S039711 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Thu, 28 Jan 2010 07:06:52 -0500 (EST) (envelope-from rnoland@FreeBSD.org) From: Robert Noland To: Brooks Davis In-Reply-To: <20100128022349.GB46919@lor.one-eyed-alien.net> References: <201001271627.37955.jhb@freebsd.org> <4B60CBFA.4050601@andric.com> <20100128022349.GB46919@lor.one-eyed-alien.net> Content-Type: text/plain Organization: FreeBSD Date: Thu, 28 Jan 2010 06:06:46 -0600 Message-Id: <1264680406.2869.72.camel@balrog.2hip.net> Mime-Version: 1.0 X-Mailer: Evolution 2.26.3 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=0.5 required=5.0 tests=AWL, BAYES_00, FH_DATE_PAST_20XX, RCVD_IN_PBL,RDNS_DYNAMIC,SPF_SOFTFAIL,SUBJECT_FUZZY_TION autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on gizmo.2hip.net Cc: Dan Naumov , Dimitry Andric , freebsd-stable@freebsd.org, freebsd-questions@freebsd.org, John Baldwin Subject: Re: booting off GPT partitions X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 28 Jan 2010 12:06:57 -0000 On Wed, 2010-01-27 at 20:23 -0600, Brooks Davis wrote: > On Thu, Jan 28, 2010 at 12:27:54AM +0100, Dimitry Andric wrote: > > On 2010-01-27 22:27, John Baldwin wrote: > >> GPT was defined along with EFI, so many folks assume that you have to use EFI > >> to boot a GPT-labelled disk. However, FreeBSD has its own BIOS-based > >> bootstrap that can handle GPT-labelled disks. I doubt the SuperMicro tech is > >> familiar with that case. I thought I heard that some folks had added GPT > >> support to grub as well. > > > > However, this won't boot disks larger than 2TiB, right? At least not > > without BIOS support... > > You won't be able to boot from a partition more than 2TiB in, but you > should still be able to boot as long as you boot from the front part of > the disk. John or Marcel can correct me, but I don't think that this is an issue. The bootstrap is located in the pmbr in sector 0 and the GPT headers and tables are in sectors 1 - 34. The bootstrap code knows how to read the GPT tables and can deal with > 2 tb lba's. So, as long as you can successfully load the bootstrap code from sector 0, all *should* be good. robert. > -- Brook -- Robert Noland FreeBSD From owner-freebsd-stable@FreeBSD.ORG Thu Jan 28 12:17:04 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E9F8B106566B for ; Thu, 28 Jan 2010 12:17:04 +0000 (UTC) (envelope-from marco@goofy.tols.org) Received: from goofy.tols.org (goofy.tols.org [83.163.60.200]) by mx1.freebsd.org (Postfix) with ESMTP id 6B0C58FC16 for ; Thu, 28 Jan 2010 12:17:03 +0000 (UTC) Received: from goofy.tols.org (localhost [127.0.0.1]) by goofy.tols.org (8.14.3/8.14.3) with ESMTP id o0SCH1GN011182 for ; Thu, 28 Jan 2010 12:17:01 GMT (envelope-from marco@goofy.tols.org) Received: (from marco@localhost) by goofy.tols.org (8.14.3/8.14.3/Submit) id o0SCH1NC011181 for freebsd-stable@freebsd.org; Thu, 28 Jan 2010 12:17:01 GMT (envelope-from marco) Date: Thu, 28 Jan 2010 12:17:01 +0000 From: Marco van Tol To: FreeBSD STABLE Message-ID: <20100128121701.GB9408@goofy.tols.org> Mail-Followup-To: FreeBSD STABLE References: <20091203.182931.129751456.hrs@allbsd.org> <4B43F6EE.3010308@ucla.edu> <147432021001242047k659a26d0s44b35164920aeb74@mail.gmail.com> <95D3CB82-BC44-491D-86E4-5CB82F89C0FC@nokia.com> <147432021001250825p202914a7ka5a2c1d28d96bac3@mail.gmail.com> <20100125182257.GG1187@michelle.cdnetworks.com> <147432021001251038r69393ab3m1a797e58f9fa905a@mail.gmail.com> <02307620-ECDC-4E8B-A5B1-FF8491E226C4@nokia.com> <33c6b0bc1001252031k508426bfh25fad65e9223d87@mail.gmail.com> <147432021001260900p60ed1804t97392d2dff5cd244@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <147432021001260900p60ed1804t97392d2dff5cd244@mail.gmail.com> User-Agent: Mutt/1.4.2.3i Subject: Re: em interface slow down on 8.0R X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 28 Jan 2010 12:17:05 -0000 On Tue, Jan 26, 2010 at 09:00:35AM -0800, Nick Rogers wrote: > Is it advisable to patch 8.0-RELEASE kernel sources with the latest > (CURRENT) em driver (i.e., src/sys/dev/e1000)? It looks like there are some > updates to the driver since 8.0-RELEASE that may fix some problems? While on the em subject, forgive me if I mail this to the inappropriate place, but is there any ETA on progress for bug kern/141646? I'm currently suffering from it and would be willing to provide needed assistance for fixing it. Thank you very much in advance, Marco van Tol -- Most general statements are false, including this one. - Alexander Dumas From owner-freebsd-stable@FreeBSD.ORG Thu Jan 28 12:26:15 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C275D106566B; Thu, 28 Jan 2010 12:26:15 +0000 (UTC) (envelope-from dimitry@andric.com) Received: from tensor.andric.com (cl-327.ede-01.nl.sixxs.net [IPv6:2001:7b8:2ff:146::2]) by mx1.freebsd.org (Postfix) with ESMTP id 8313C8FC13; Thu, 28 Jan 2010 12:26:15 +0000 (UTC) Received: from [IPv6:2001:7b8:3a7:0:8004:3a2d:b5f3:27ec] (unknown [IPv6:2001:7b8:3a7:0:8004:3a2d:b5f3:27ec]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id 23F395C43; Thu, 28 Jan 2010 13:26:14 +0100 (CET) Message-ID: <4B618270.3050309@andric.com> Date: Thu, 28 Jan 2010 13:26:24 +0100 From: Dimitry Andric User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.2; en-US; rv:1.9.2pre) Gecko/20100126 Lanikai/3.1b1pre MIME-Version: 1.0 To: Robert Noland References: <201001271627.37955.jhb@freebsd.org> <4B60CBFA.4050601@andric.com> <20100128022349.GB46919@lor.one-eyed-alien.net> <1264680406.2869.72.camel@balrog.2hip.net> In-Reply-To: <1264680406.2869.72.camel@balrog.2hip.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org, Brooks Davis , Dan Naumov , freebsd-questions@freebsd.org, John Baldwin Subject: Re: booting off GPT partitions X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 28 Jan 2010 12:26:15 -0000 On 2010-01-28 13:06, Robert Noland wrote: > John or Marcel can correct me, but I don't think that this is an issue. > The bootstrap is located in the pmbr in sector 0 and the GPT headers and > tables are in sectors 1 - 34. The bootstrap code knows how to read the > GPT tables and can deal with> 2 tb lba's. Ah yes, I see it now. It uses EDD packets with the BIOS int 13 interface, which apparently have a 64-bit LBA. This should support up to 8 ZiB with 512-byte sectors... OTOH, I have no idea how well most BIOSes actually implement this. Since many OSes simply don't support anything over 2^32 sectors, I would not be amazed to find much BIOSes out there that behave the same. Or am I too paranoid now? :) From owner-freebsd-stable@FreeBSD.ORG Thu Jan 28 13:42:40 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1771C106568B for ; Thu, 28 Jan 2010 13:42:40 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 5BF528FC20 for ; Thu, 28 Jan 2010 13:42:39 +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 PAA19246; Thu, 28 Jan 2010 15:42:35 +0200 (EET) (envelope-from avg@icyb.net.ua) Message-ID: <4B61944B.8090602@icyb.net.ua> Date: Thu, 28 Jan 2010 15:42:35 +0200 From: Andriy Gapon User-Agent: Thunderbird 2.0.0.23 (X11/20091206) MIME-Version: 1.0 To: =?UTF-8?B?VG9tbWkgTMOkdHRp?= References: <4B6022C6.1090608@andric.com> In-Reply-To: X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Cc: FreeBSD-STABLE Mailing List Subject: Re: immense delayed write to file system (ZFS and UFS2), performance issues X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jan 2010 13:42:40 -0000 on 27/01/2010 22:26 Tommi Lätti said the following: > Seems that the performance is indeed atrocious. I recently (like 2 > days ago) had to rescue my zfs pool under opensolaris to spare disks. > The performance under OpenSol was what I was expecting, 70MB/s reading > and writing at the same time. > > Now that I'm restoring the stuff back under FreeBSD 8.0-p2 it seems > that first the array reads from the source disk and then stops reading > and decides to empty the buffer to the destination. There's usually a > 2 second pause and after that it goes back to reading. There seems to > be something really wrong with this, fbsd zfs implementation seems to > be unable to move data between 2 zfs pools writing and reading > simultaneously... > > I think I'll just boot back to opensol and do the transfers there. I've been seeing things like this too. Also, when copying between UFS and ZFS. -- Andriy Gapon From owner-freebsd-stable@FreeBSD.ORG Thu Jan 28 15:42:45 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A6F651065670; Thu, 28 Jan 2010 15:42:45 +0000 (UTC) (envelope-from aoyama@peach.ne.jp) Received: from moon.peach.ne.jp (unknown [IPv6:2001:380:e06:127::53]) by mx1.freebsd.org (Postfix) with ESMTP id 6EAD98FC15; Thu, 28 Jan 2010 15:42:45 +0000 (UTC) Received: from moon.peach.ne.jp (localhost [127.0.0.1]) by moon.peach.ne.jp (Postfix) with ESMTP id AA00D78C4B; Fri, 29 Jan 2010 00:42:44 +0900 (JST) Received: from artemis (unknown [192.168.2.20]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by moon.peach.ne.jp (Postfix) with ESMTP id 7233F78C3B; Fri, 29 Jan 2010 00:42:44 +0900 (JST) Message-ID: From: "Daisuke Aoyama" To: "Daniel O'Connor" , References: <201001280000.16773.doconnor@gsoft.com.au> Date: Fri, 29 Jan 2010 00:42:38 +0900 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.5843 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 X-Virus-Scanned: ClamAV using ClamSMTP Cc: freebsd-emulation@freebsd.org, freebsd-current@freebsd.org Subject: Re: [PATCH] VirtualBox headless VNC support by LibVNCServer X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 28 Jan 2010 15:42:45 -0000 Thank you for your reply. >I put VBox-VNC-20100127.patch in files an modified the paths to be >acceptable to the ports tree and applied the Makefile patch and it >works well. (I say this as IMO it's easier to try if you distribute it >like that :) I think too. I have created it to use with FreeNAS. I assumed that it is used internally. The first mail of FreeBSD ML is here: http://lists.freebsd.org/pipermail/freebsd-emulation/2010-January/007336.html Next time, I will try to change you said. >Is there any prospect of being able to build the VNC server extension in >parallel with X11/QT4? There might not be problem. I'm not using X11. That is all of the reason. Daisuke Aoyama From owner-freebsd-stable@FreeBSD.ORG Thu Jan 28 16:25:57 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 10AE7106568B; Thu, 28 Jan 2010 16:25:57 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id D3EC78FC18; Thu, 28 Jan 2010 16:25:56 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id 7FEA246B0D; Thu, 28 Jan 2010 11:25:56 -0500 (EST) Received: from jhbbsd.localnet (smtp.hudson-trading.com [209.249.190.9]) by bigwig.baldwin.cx (Postfix) with ESMTPA id C896F8A01F; Thu, 28 Jan 2010 11:25:55 -0500 (EST) From: John Baldwin To: Dimitry Andric Date: Thu, 28 Jan 2010 11:23:33 -0500 User-Agent: KMail/1.12.1 (FreeBSD/7.2-CBSD-20100120; KDE/4.3.1; amd64; ; ) References: <1264680406.2869.72.camel@balrog.2hip.net> <4B618270.3050309@andric.com> In-Reply-To: <4B618270.3050309@andric.com> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201001281123.33097.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (bigwig.baldwin.cx); Thu, 28 Jan 2010 11:25:55 -0500 (EST) X-Virus-Scanned: clamav-milter 0.95.1 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-2.5 required=4.2 tests=AWL,BAYES_00, SUBJECT_FUZZY_TION autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on bigwig.baldwin.cx Cc: freebsd-stable@freebsd.org, Brooks Davis , Dan Naumov , freebsd-questions@freebsd.org, Robert Noland Subject: Re: booting off GPT partitions X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 28 Jan 2010 16:25:57 -0000 On Thursday 28 January 2010 7:26:24 am Dimitry Andric wrote: > On 2010-01-28 13:06, Robert Noland wrote: > > John or Marcel can correct me, but I don't think that this is an issue. > > The bootstrap is located in the pmbr in sector 0 and the GPT headers and > > tables are in sectors 1 - 34. The bootstrap code knows how to read the > > GPT tables and can deal with> 2 tb lba's. > > Ah yes, I see it now. It uses EDD packets with the BIOS int 13 > interface, which apparently have a 64-bit LBA. This should support up > to 8 ZiB with 512-byte sectors... > > OTOH, I have no idea how well most BIOSes actually implement this. > Since many OSes simply don't support anything over 2^32 sectors, I would > not be amazed to find much BIOSes out there that behave the same. Or am > I too paranoid now? :) It should work fine. The GPT boot code was originally written specifically to supporting booting from RAID volumes > 2TB. I've tested it on mfi(4) volumes that large (though I didn't verify the individual LBAs of all the various bits read in by the bootstrap and loader were). I know that other folks ran into bugs until the ZFS GPT boot code was all made 64-bit clean and that they have since booted > 2TB ZFS volumes ok. -- John Baldwin From owner-freebsd-stable@FreeBSD.ORG Thu Jan 28 19:16:04 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1A68E1065698 for ; Thu, 28 Jan 2010 19:16:04 +0000 (UTC) (envelope-from jfvogel@gmail.com) Received: from mail-ew0-f218.google.com (mail-ew0-f218.google.com [209.85.219.218]) by mx1.freebsd.org (Postfix) with ESMTP id 9B8458FC16 for ; Thu, 28 Jan 2010 19:16:03 +0000 (UTC) Received: by ewy10 with SMTP id 10so1129084ewy.3 for ; Thu, 28 Jan 2010 11:16:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type; bh=D2n1msgtjsWODvLkfUMuGIQW5/nxGsBCRMErjHAIEXo=; b=HL8dl7bG4qFsV4pBQJsNfMMzc7+G5B+nkdZkVkqGjcZje469Y52iUcU9i6twwoJuaS HItgN9berMLXGP1GUZcL0s5bjxC7hPPORGRrTJIeSMzphV27mElPlYkSSpBuF6CC6HQB 8R+IJ/eqgt7ndSLIlEOio73Bt335fBkw92tJw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=jTOoOIvIYssUmVYwTaKB4aVutK5jLg82eXe6k4qPKfZU+ikkbHGBTzKNjwy3Xwop2l inI4QsJ2jaSvfUSu6UZJ9QxGb4Fb0UyWItZ7Gc+aLN7bJWxyGlQyoEDskDFjA69iWUWy sVRzlVMMb0qYVUYlsQM2wXJprarJVTZs+yoIc= MIME-Version: 1.0 Received: by 10.216.86.9 with SMTP id v9mr301503wee.148.1264706162328; Thu, 28 Jan 2010 11:16:02 -0800 (PST) In-Reply-To: <20100128121701.GB9408@goofy.tols.org> References: <20091203.182931.129751456.hrs@allbsd.org> <147432021001242047k659a26d0s44b35164920aeb74@mail.gmail.com> <95D3CB82-BC44-491D-86E4-5CB82F89C0FC@nokia.com> <147432021001250825p202914a7ka5a2c1d28d96bac3@mail.gmail.com> <20100125182257.GG1187@michelle.cdnetworks.com> <147432021001251038r69393ab3m1a797e58f9fa905a@mail.gmail.com> <02307620-ECDC-4E8B-A5B1-FF8491E226C4@nokia.com> <33c6b0bc1001252031k508426bfh25fad65e9223d87@mail.gmail.com> <147432021001260900p60ed1804t97392d2dff5cd244@mail.gmail.com> <20100128121701.GB9408@goofy.tols.org> Date: Thu, 28 Jan 2010 11:16:02 -0800 Message-ID: <2a41acea1001281116k7d14cc26x120f9960ab14d19d@mail.gmail.com> From: Jack Vogel To: FreeBSD STABLE Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Re: em interface slow down on 8.0R X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 28 Jan 2010 19:16:04 -0000 I am investigating it, and have a suspicion about what's going on, you can assist in verifying my suspicion. In if_em.c search for "em_setup_vlan_hw", you will find a compile time option that uses that only if FreeBSD_version is > 700029, hack the code however you wish so that it uses the OLD way (ie that it never calls em_setup_vlan_hw_support()) and see if that makes the issue disappear. If you have any problems or questions email me directly. Jack On Thu, Jan 28, 2010 at 4:17 AM, Marco van Tol wrote: > On Tue, Jan 26, 2010 at 09:00:35AM -0800, Nick Rogers wrote: > > Is it advisable to patch 8.0-RELEASE kernel sources with the latest > > (CURRENT) em driver (i.e., src/sys/dev/e1000)? It looks like there are > some > > updates to the driver since 8.0-RELEASE that may fix some problems? > > While on the em subject, forgive me if I mail this to the inappropriate > place, but is there any ETA on progress for bug kern/141646? > > I'm currently suffering from it and would be willing to provide needed > assistance for fixing it. > > Thank you very much in advance, > > Marco van Tol > > -- > Most general statements are false, including this one. > - Alexander Dumas > _______________________________________________ > 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 Thu Jan 28 22:43:47 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 348D61065692; Thu, 28 Jan 2010 22:43:47 +0000 (UTC) (envelope-from doconnor@gsoft.com.au) Received: from cain.gsoft.com.au (cain.gsoft.com.au [203.31.81.10]) by mx1.freebsd.org (Postfix) with ESMTP id A23488FC1B; Thu, 28 Jan 2010 22:43:46 +0000 (UTC) Received: from inchoate.gsoft.com.au (ppp121-45-156-224.lns6.adl6.internode.on.net [121.45.156.224]) (authenticated bits=0) by cain.gsoft.com.au (8.13.8/8.13.8) with ESMTP id o0SMhfjE061277 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Fri, 29 Jan 2010 09:13:42 +1030 (CST) (envelope-from doconnor@gsoft.com.au) From: "Daniel O'Connor" To: "Daisuke Aoyama" Date: Fri, 29 Jan 2010 09:13:26 +1030 User-Agent: KMail/1.9.10 References: <201001280000.16773.doconnor@gsoft.com.au> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1644808.5eoKPeSfur"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <201001290913.36223.doconnor@gsoft.com.au> X-Spam-Score: -1.696 () AWL,BAYES_00,RDNS_DYNAMIC X-Scanned-By: MIMEDefang 2.63 on 203.31.81.10 Cc: freebsd-emulation@freebsd.org, freebsd-current@freebsd.org, freebsd-stable@freebsd.org Subject: Re: [PATCH] VirtualBox headless VNC support by LibVNCServer X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 28 Jan 2010 22:43:47 -0000 --nextPart1644808.5eoKPeSfur Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Fri, 29 Jan 2010, Daisuke Aoyama wrote: > I think too. I have created it to use with FreeNAS. I assumed that it > is used internally. > The first mail of FreeBSD ML is here: > http://lists.freebsd.org/pipermail/freebsd-emulation/2010-January/007 >336.html Next time, I will try to change you said. OK thanks. > >Is there any prospect of being able to build the VNC server > > extension in parallel with X11/QT4? > > There might not be problem. I'm not using X11. That is all of the > reason. Ahh.. I think that the VNC option is orthogonal to X11. IMO it should probably be installed unconditionally as it is only a very=20 minor code increase which makes the headless server much, much more=20 useful. =2D-=20 Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C --nextPart1644808.5eoKPeSfur Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.12 (FreeBSD) iD8DBQBLYhMY5ZPcIHs/zowRAuPYAJ4nngBWL8fgyWmVarHYdK8xNI2DVACgrIO6 BihY3D8fwTWGc6zmYLdm2Gw= =nQ/Y -----END PGP SIGNATURE----- --nextPart1644808.5eoKPeSfur-- From owner-freebsd-stable@FreeBSD.ORG Fri Jan 29 00:16:50 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D8378106566C; Fri, 29 Jan 2010 00:16:50 +0000 (UTC) (envelope-from cyrille.lefevre-lists@laposte.net) Received: from out3.laposte.net (out4.laposte.net [193.251.214.121]) by mx1.freebsd.org (Postfix) with ESMTP id 6D7D58FC0C; Fri, 29 Jan 2010 00:16:50 +0000 (UTC) Received: from meplus.info (localhost [127.0.0.1]) by mwinf8314.laposte.net (SMTP Server) with ESMTP id 9C07C70013A7; Fri, 29 Jan 2010 01:16:48 +0100 (CET) Received: from [192.168.1.133] (137.228.100-84.rev.gaoland.net [84.100.228.137]) by mwinf8314.laposte.net (SMTP Server) with ESMTP id 37C5970013A6; Fri, 29 Jan 2010 01:16:48 +0100 (CET) X-ME-UUID: 20100129001648228.37C5970013A6@mwinf8314.laposte.net Message-ID: <4B6228EF.5050400@laposte.net> Date: Fri, 29 Jan 2010 01:16:47 +0100 From: Cyrille Lefevre Organization: ACME User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; fr; rv:1.8.1.3) Gecko/20070326 Thunderbird/2.0.0.0 Mnenhy/0.7.5.666 MIME-Version: 1.0 To: jhell References: <4B5CEC53.3090402@laposte.net> <20100125025744.GA94378@orion.hsd1.pa.comcast.net> <4B60B734.7060803@laposte.net> In-Reply-To: <4B60B734.7060803@laposte.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable X-me-spamlevel: not-spam X-me-spamrating: 32.799999 X-me-spamcause: OK, (-180)(0000)gggruggvucftvghtrhhoucdtuddrvdeltddrudduucetggdotefuucfrrhhofhhilhgvmecuoehnohhnvgeqnecuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenucdlqddutddtmdenfhhrvggvsghsugefgiculddqfedtmdenfhhrvggvsghsugdgucdlqddutddmneeuufffvdigucdlqddvtddmnehgvghnvghrihgtjdculdeftddmnehtohcutghhrghtucdlhedtmd Cc: freebsd-standards@freebsd.org, freebsd-stable@freebsd.org, Glen Barber Subject: Re: su password prompt to stdout instead of /dev/tty X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 29 Jan 2010 00:16:50 -0000 Cyrille Lefevre a =E9crit : >=20 >=20 > sorry, repost to -standards w/ an s ! >=20 > jhell a =E9crit : >> On Sun, 24 Jan 2010 21:57, glen.j.barber@ wrote: >>> >>> Cyrille Lefevre wrote: >>>> >>>> su password prompt is displayed to *stdout* instead of */dev/tty*. >>>> >>>> # su user >>>> $ su root -c date > /tmp/date 2>&1 >>>> (nothing displayed) >>>> $ cat /tmp/date >>>> Password:su: Sorry >>>> $ uname -a >>>> FreeBSD freebsd8.my.domain 8.0-RELEASE FreeBSD 8.0-RELEASE #0: Sat N= ov >>>> 21 15:48:17 UTC 2009 >>>> root@almeida.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC i386 >>>> >>>> I suppose this is a getpass() problem ? >>>> >> >> This is intended operation as su(1) may not always be affiliated with = >> a TTY. This leaves it open for a script to chat with much like what=20 >> samba does with its passwd chat mechanism. >=20 > just to feed the debate : >=20 > aix 5.2 : prompt to tty > hp-ux : prompt to stderr > netbsd : prompt to tty > solaris 9 : prompt to stderr > solaris 10 : prompt to tty > openbsd : prompt to tty > ubuntu : prompt to stderr >=20 > freebsd is the only one which prompt to stdout ! > IMHO, it should at least prompt to stderr if not tty... > and report errors to stderr as usually. >=20 > CC -standards found it, the guilty is prompt() in=20 src/contrib/openpam/lib/openpam_ttyconv.c and not getpass() as usual... =3D> fputs(msg, stdout); which should be, IMHO, something like : FILE *ttyp; ttyp =3D fopen("/dev/tty", "w") if (!stdtty) ttyp =3D isatty(fileno(stderr)) ? stderr : stdout; fputs(msg, ttyp); or, at least : fputs(msg, stderr); Regards, Cyrille Lefevre --=20 mailto:Cyrille.Lefevre-lists@laposte.net From owner-freebsd-stable@FreeBSD.ORG Fri Jan 29 00:25:13 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 424D110656AE for ; Fri, 29 Jan 2010 00:25:13 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from mail2.fluidhosting.com (mx21.fluidhosting.com [204.14.89.4]) by mx1.freebsd.org (Postfix) with ESMTP id A3BE88FC18 for ; Fri, 29 Jan 2010 00:25:06 +0000 (UTC) Received: (qmail 18523 invoked by uid 399); 29 Jan 2010 00:25:06 -0000 Received: from localhost (HELO foreign.dougb.net) (dougb@dougbarton.us@127.0.0.1) by localhost with ESMTPAM; 29 Jan 2010 00:25:06 -0000 X-Originating-IP: 127.0.0.1 X-Sender: dougb@dougbarton.us Message-ID: <4B622AE6.2060501@FreeBSD.org> Date: Thu, 28 Jan 2010 16:25:10 -0800 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.9.1.7) Gecko/20100123 Thunderbird/3.0.1 MIME-Version: 1.0 To: Cyrille Lefevre References: <4B5CEC53.3090402@laposte.net> <20100125025744.GA94378@orion.hsd1.pa.comcast.net> <4B60B734.7060803@laposte.net> <4B6228EF.5050400@laposte.net> In-Reply-To: <4B6228EF.5050400@laposte.net> X-Enigmail-Version: 1.0 OpenPGP: id=D5B2F0FB Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: jhell , freebsd-standards@freebsd.org, freebsd-stable@freebsd.org, Glen Barber Subject: Re: su password prompt to stdout instead of /dev/tty X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 29 Jan 2010 00:25:13 -0000 Has anyone checked what POSIX has to say about this? And does this issue affect more than just su? Doug -- Improve the effectiveness of your Internet presence with a domain name makeover! http://SupersetSolutions.com/ Computers are useless. They can only give you answers. -- Pablo Picasso From owner-freebsd-stable@FreeBSD.ORG Fri Jan 29 00:43:40 2010 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5205E1065672 for ; Fri, 29 Jan 2010 00:43:40 +0000 (UTC) (envelope-from bsam@ipt.ru) Received: from services.ipt.ru (services.ipt.ru [194.62.233.110]) by mx1.freebsd.org (Postfix) with ESMTP id 0EE168FC1E for ; Fri, 29 Jan 2010 00:43:39 +0000 (UTC) Received: from [85.175.178.210] (helo=izar) by services.ipt.ru with esmtpa (Exim 4.54 (FreeBSD)) id 1NaexX-000EGd-07 for freebsd-stable@FreeBSD.org; Fri, 29 Jan 2010 03:43:39 +0300 From: Boris Samorodov To: freebsd-stable@FreeBSD.org References: Date: Fri, 29 Jan 2010 03:43:42 +0300 In-Reply-To: (Dan Naumov's message of "Tue, 26 Jan 2010 20:45:10 +0200") Message-ID: <51651473@ipt.ru> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Subject: Re: immense delayed write to file system (ZFS and UFS2), performance issues X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jan 2010 00:43:40 -0000 On Tue, 26 Jan 2010 20:45:10 +0200 Dan Naumov wrote: > This discussion made me have a look at my 2tb WD Green disks... So did I. Hm, it's a "nice" feature: ----- Model Family: Western Digital RE2-GP family Device Model: WDC WD1000FYPS-01ZKB0 Firmware Version: 02.01B01 User Capacity: 1 000 204 886 016 bytes ... 9 Power_On_Hours 0x0032 082 082 000 Old_age Always - 13206 193 Load_Cycle_Count 0x0032 001 001 000 Old_age Always - 1883216 ----- Seems I'm a winner with my nearly 2M cycles. :-( I use another script to stop that horror at five disks: ----- #!/bin/sh while true; do for i in `jot 5`; do sudo fdisk -p ada$i > /dev/null 2>&1 done sleep 5 done ----- -- WBR, Boris Samorodov (bsam) Research Engineer, http://www.ipt.ru Telephone & Internet SP FreeBSD Committer, http://www.FreeBSD.org The Power To Serve From owner-freebsd-stable@FreeBSD.ORG Fri Jan 29 01:38:50 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EE5B0106566C; Fri, 29 Jan 2010 01:38:50 +0000 (UTC) (envelope-from cyrille.lefevre-lists@laposte.net) Received: from out1.laposte.net (out2.laposte.net [193.251.214.119]) by mx1.freebsd.org (Postfix) with ESMTP id AAF7E8FC14; Fri, 29 Jan 2010 01:38:50 +0000 (UTC) Received: from meplus.info (localhost [127.0.0.1]) by mwinf8209.laposte.net (SMTP Server) with ESMTP id DEDF97000083; Fri, 29 Jan 2010 02:38:49 +0100 (CET) Received: from [192.168.1.133] (137.228.100-84.rev.gaoland.net [84.100.228.137]) by mwinf8209.laposte.net (SMTP Server) with ESMTP id 648B47000082; Fri, 29 Jan 2010 02:38:49 +0100 (CET) X-ME-UUID: 20100129013849411.648B47000082@mwinf8209.laposte.net Message-ID: <4B623C29.3090504@laposte.net> Date: Fri, 29 Jan 2010 02:38:49 +0100 From: Cyrille Lefevre Organization: ACME User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; fr; rv:1.8.1.3) Gecko/20070326 Thunderbird/2.0.0.0 Mnenhy/0.7.5.666 MIME-Version: 1.0 To: Doug Barton References: <4B5CEC53.3090402@laposte.net> <20100125025744.GA94378@orion.hsd1.pa.comcast.net> <4B60B734.7060803@laposte.net> <4B6228EF.5050400@laposte.net> <4B622AE6.2060501@FreeBSD.org> In-Reply-To: <4B622AE6.2060501@FreeBSD.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable X-me-spamlevel: not-spam X-me-spamrating: 36.000000 X-me-spamcause: OK, (-100)(0000)gggruggvucftvghtrhhoucdtuddrvdeltddrudduucetggdotefuucfrrhhofhhilhgvmecuoehnohhnvgeqnecuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmd Cc: jhell , freebsd-standards@freebsd.org, freebsd-stable@freebsd.org, Glen Barber Subject: Re: su password prompt to stdout instead of /dev/tty X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 29 Jan 2010 01:38:51 -0000 Doug Barton a =E9crit : >=20 > Has anyone checked what POSIX has to say about this? And does this issu= e=20 > affect more than just su? Hi, su isn't posix, not the susv4 way at least ! Regards, Cyrille Lefevre --=20 mailto:Cyrille.Lefevre-lists@laposte.net From owner-freebsd-stable@FreeBSD.ORG Fri Jan 29 08:02:38 2010 Return-Path: Delivered-To: freebsd-stable@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 73256106566B; Fri, 29 Jan 2010 08:02:38 +0000 (UTC) (envelope-from olli@lurza.secnetix.de) Received: from lurza.secnetix.de (lurza.secnetix.de [IPv6:2a01:170:102f::2]) by mx1.freebsd.org (Postfix) with ESMTP id ED4E98FC12; Fri, 29 Jan 2010 08:02:37 +0000 (UTC) Received: from lurza.secnetix.de (localhost [127.0.0.1]) by lurza.secnetix.de (8.14.3/8.14.3) with ESMTP id o0T82AHn050044; Fri, 29 Jan 2010 09:02:26 +0100 (CET) (envelope-from oliver.fromme@secnetix.de) Received: (from olli@localhost) by lurza.secnetix.de (8.14.3/8.14.3/Submit) id o0T829sd050043; Fri, 29 Jan 2010 09:02:09 +0100 (CET) (envelope-from olli) Date: Fri, 29 Jan 2010 09:02:09 +0100 (CET) Message-Id: <201001290802.o0T829sd050043@lurza.secnetix.de> From: Oliver Fromme To: freebsd-standards@FreeBSD.ORG, cyrille.lefevre-lists@laposte.net, jhell@DataIX.net, freebsd-stable@FreeBSD.ORG, glen.j.barber@gmail.com In-Reply-To: <4B6228EF.5050400@laposte.net> X-Newsgroups: list.freebsd-standards User-Agent: tin/1.8.3-20070201 ("Scotasay") (UNIX) (FreeBSD/6.4-PRERELEASE-20080904 (i386)) MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.1.2 (lurza.secnetix.de [127.0.0.1]); Fri, 29 Jan 2010 09:02:26 +0100 (CET) Cc: Subject: Re: su password prompt to stdout instead of /dev/tty X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 29 Jan 2010 08:02:38 -0000 Cyrille Lefevre wrote: > found it, the guilty is prompt() in > src/contrib/openpam/lib/openpam_ttyconv.c and not getpass() as usual... Are you sure this affects su(1) only? > => fputs(msg, stdout); > > which should be, IMHO, something like : > > FILE *ttyp; > ttyp = fopen("/dev/tty", "w") > if (!stdtty) > ttyp = isatty(fileno(stderr)) ? stderr : stdout; > fputs(msg, ttyp); > > or, at least : > > fputs(msg, stderr); As long as it's still possible to easily redirect the prompt on the command line, it's fine with me. Right now I can do this in a script: echo -n "$myprompt: " ; su $somerole >/dev/null ... If that doesn't work anymore, I'll complain. ;-) Best regards Oliver -- Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün- chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd "With sufficient thrust, pigs fly just fine. However, this is not necessarily a good idea. It is hard to be sure where they are going to land, and it could be dangerous sitting under them as they fly overhead." -- RFC 1925 From owner-freebsd-stable@FreeBSD.ORG Fri Jan 29 09:03:59 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A50721065670 for ; Fri, 29 Jan 2010 09:03:59 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from qmta15.emeryville.ca.mail.comcast.net (qmta15.emeryville.ca.mail.comcast.net [76.96.27.228]) by mx1.freebsd.org (Postfix) with ESMTP id 893778FC12 for ; Fri, 29 Jan 2010 09:03:59 +0000 (UTC) Received: from omta03.emeryville.ca.mail.comcast.net ([76.96.30.27]) by qmta15.emeryville.ca.mail.comcast.net with comcast id bM401d0030b6N64AFM40ic; Fri, 29 Jan 2010 09:04:00 +0000 Received: from koitsu.dyndns.org ([98.248.46.159]) by omta03.emeryville.ca.mail.comcast.net with comcast id bM3y1d0053S48mS8PM3zky; Fri, 29 Jan 2010 09:03:59 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id C81011E3033; Fri, 29 Jan 2010 01:03:57 -0800 (PST) Date: Fri, 29 Jan 2010 01:03:57 -0800 From: Jeremy Chadwick To: Oliver Fromme Message-ID: <20100129090357.GA38872@icarus.home.lan> References: <4B6228EF.5050400@laposte.net> <201001290802.o0T829sd050043@lurza.secnetix.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201001290802.o0T829sd050043@lurza.secnetix.de> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: jhell@DataIX.net, freebsd-standards@FreeBSD.ORG, freebsd-stable@FreeBSD.ORG, glen.j.barber@gmail.com Subject: Re: su password prompt to stdout instead of /dev/tty X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 29 Jan 2010 09:03:59 -0000 On Fri, Jan 29, 2010 at 09:02:09AM +0100, Oliver Fromme wrote: > Cyrille Lefevre wrote: > > found it, the guilty is prompt() in > > src/contrib/openpam/lib/openpam_ttyconv.c and not getpass() as usual... > > Are you sure this affects su(1) only? > > > => fputs(msg, stdout); > > > > which should be, IMHO, something like : > > > > FILE *ttyp; > > ttyp = fopen("/dev/tty", "w") > > if (!stdtty) > > ttyp = isatty(fileno(stderr)) ? stderr : stdout; > > fputs(msg, ttyp); > > > > or, at least : > > > > fputs(msg, stderr); > > As long as it's still possible to easily redirect the prompt > on the command line, it's fine with me. > Right now I can do this in a script: > > echo -n "$myprompt: " ; su $somerole >/dev/null ... > > If that doesn't work anymore, I'll complain. ;-) OpenPAM is des@'s responsibility. Has anyone brought this up to him? -- | Jeremy Chadwick jdc@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Fri Jan 29 10:46:35 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E665B10656A4 for ; Fri, 29 Jan 2010 10:46:35 +0000 (UTC) (envelope-from mail25@bzerk.org) Received: from ei.bzerk.org (tunnel490.ipv6.xs4all.nl [IPv6:2001:888:10:1ea::2]) by mx1.freebsd.org (Postfix) with ESMTP id 58FA98FC1E for ; Fri, 29 Jan 2010 10:46:35 +0000 (UTC) Received: from ei.bzerk.org (BOFH@localhost [127.0.0.1]) by ei.bzerk.org (8.14.3/8.14.3) with ESMTP id o0TAkQx8013535; Fri, 29 Jan 2010 11:46:26 +0100 (CET) (envelope-from mail25@bzerk.org) Received: (from bulk@localhost) by ei.bzerk.org (8.14.3/8.14.3/Submit) id o0TAkPNb013534; Fri, 29 Jan 2010 11:46:25 +0100 (CET) (envelope-from mail25@bzerk.org) Date: Fri, 29 Jan 2010 11:46:25 +0100 From: Ruben de Groot To: "Daniel O'Connor" Message-ID: <20100129104624.GA13472@ei.bzerk.org> Mail-Followup-To: Ruben de Groot , Daniel O'Connor , freebsd-stable@freebsd.org, Adrian Wontroba References: <20100122162155.GG3917@e-Gitt.NET> <20100123012328.GA3296@swelter.hanley.stade.co.uk> <20100123114209.GA21457@ei.bzerk.org> <201001232244.03752.doconnor@gsoft.com.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201001232244.03752.doconnor@gsoft.com.au> User-Agent: Mutt/1.4.2.3i X-Spam-Status: No, score=-4.3 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on ei.bzerk.org X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.0.1 (ei.bzerk.org [127.0.0.1]); Fri, 29 Jan 2010 11:46:32 +0100 (CET) Cc: Ruben de Groot , freebsd-stable@freebsd.org Subject: Re: 8.0-RELEASE -> -STABLE and size of / X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jan 2010 10:46:36 -0000 On Sat, Jan 23, 2010 at 10:43:49PM +1030, Daniel O'Connor typed: > On Sat, 23 Jan 2010, Ruben de Groot wrote: > > On Sat, Jan 23, 2010 at 01:23:28AM +0000, Adrian Wontroba typed: > > > I concur that the 235 MB size of an amd64 8.0 kernel is a bit of a > > > surprise. An i386 kernel is a mere 135 MB. IMO increasing the > > > sysinstall default root slice size for at least amd64 would be a > > > good thing. > > > > To be a little more precise: it's not the >kernel< that is so big. > > It's all the (mostly not needed) modules and symbol files that fill > > up / > > Maybe they could be put somewhere else.. > > I don't think you need them unless remote debugging and in that case you > are multiuser (I would have thought anyway). > > If they went into /usr then /boot could remain slim. But what if you have /usr on a gmirror, glabel, zfs filesystem or any other device that is not compiled in your kernel? Sure you can build a custom kernel, but I would expect a lot of questions, frustrations and footshooting from such a change. I think increasing / (again) would be the least painfull. Ruben From owner-freebsd-stable@FreeBSD.ORG Fri Jan 29 12:00:24 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9AA7110656C9 for ; Fri, 29 Jan 2010 12:00:24 +0000 (UTC) (envelope-from doconnor@gsoft.com.au) Received: from cain.gsoft.com.au (cain.gsoft.com.au [203.31.81.10]) by mx1.freebsd.org (Postfix) with ESMTP id 19B9F8FC14 for ; Fri, 29 Jan 2010 12:00:23 +0000 (UTC) Received: from inchoate.gsoft.com.au (ppp121-45-156-224.lns6.adl6.internode.on.net [121.45.156.224]) (authenticated bits=0) by cain.gsoft.com.au (8.13.8/8.13.8) with ESMTP id o0TC068C082637 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Fri, 29 Jan 2010 22:30:06 +1030 (CST) (envelope-from doconnor@gsoft.com.au) From: "Daniel O'Connor" To: Ruben de Groot Date: Fri, 29 Jan 2010 22:29:51 +1030 User-Agent: KMail/1.9.10 References: <20100122162155.GG3917@e-Gitt.NET> <201001232244.03752.doconnor@gsoft.com.au> <20100129104624.GA13472@ei.bzerk.org> In-Reply-To: <20100129104624.GA13472@ei.bzerk.org> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1942142.mvhWgjJyHj"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <201001292230.01867.doconnor@gsoft.com.au> X-Spam-Score: -1.7 () AWL,BAYES_00,RDNS_DYNAMIC X-Scanned-By: MIMEDefang 2.63 on 203.31.81.10 Cc: freebsd-stable@freebsd.org Subject: Re: 8.0-RELEASE -> -STABLE and size of / X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jan 2010 12:00:24 -0000 --nextPart1942142.mvhWgjJyHj Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Fri, 29 Jan 2010, Ruben de Groot wrote: > > I don't think you need them unless remote debugging and in that > > case you are multiuser (I would have thought anyway). > > > > If they went into /usr then /boot could remain slim. > > But what if you have /usr on a gmirror, glabel, zfs filesystem or any > other device that is not compiled in your kernel? Sure you can build > a custom kernel, but I would expect a lot of questions, frustrations > and footshooting from such a change. > > I think increasing / (again) would be the least painfull. You don't need debug symbols to boot a kernel, you only need them when=20 debugging. Since the debugging either happens after the fact (analysing a core) or=20 remotely (and the remote system would have /usr mounted) I don't see=20 that they need to go into /boot. =2D-=20 Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C --nextPart1942142.mvhWgjJyHj Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.12 (FreeBSD) iD8DBQBLYs3B5ZPcIHs/zowRAoN9AJ424SKLfAYP6oQJnanXBJdVHgE7+ACeL1kK +my/MNu/JldMoWPY2A52OFo= =7TXi -----END PGP SIGNATURE----- --nextPart1942142.mvhWgjJyHj-- From owner-freebsd-stable@FreeBSD.ORG Fri Jan 29 12:22:14 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3D9C0106566B; Fri, 29 Jan 2010 12:22:14 +0000 (UTC) (envelope-from marck@rinet.ru) Received: from woozle.rinet.ru (woozle.rinet.ru [195.54.192.68]) by mx1.freebsd.org (Postfix) with ESMTP id 5E8A28FC19; Fri, 29 Jan 2010 12:22:13 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by woozle.rinet.ru (8.14.3/8.14.3) with ESMTP id o0TCMCf2012834; Fri, 29 Jan 2010 15:22:12 +0300 (MSK) (envelope-from marck@rinet.ru) Date: Fri, 29 Jan 2010 15:22:12 +0300 (MSK) From: Dmitry Morozovsky To: freebsd-stable@freebsd.org In-Reply-To: Message-ID: References: User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) X-NCC-RegID: ru.rinet X-OpenPGP-Key-ID: 6B691B03 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.3 (woozle.rinet.ru [0.0.0.0]); Fri, 29 Jan 2010 15:22:12 +0300 (MSK) Cc: Pawel Jakub Dawidek Subject: Re: Another ZFS RELENG_7/i386 strangeness: Operation not permitted X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 29 Jan 2010 12:22:14 -0000 On Tue, 26 Jan 2010, Dmitry Morozovsky wrote: DM> DM> stable/7 as of yesterday. Operation not permitted errors during DM> DM> `rsync -avH --fileflags' to ZFS. Investigating: DM> DM> DM> DM> root@woozle:/usr/ports# la -io DM> DM> /w/backup/woozle/var/log/www/woozle/.access_log.9.gz.* DM> DM> 73613 -rw-r--r-- 1 root wheel - 1200326 Sep 25 2005 /w/backup/woozle/var/log/www/woozle/.access_log.9.gz.bg9Zcw DM> DM> 73728 -rw-r--r-- 1 root wheel - 1200326 Sep 25 2005 /w/backup/woozle/var/log/www/woozle/.access_log.9.gz.dxux3T DM> DM> 28355 -rw-r--r-- 1 root wheel - 1200326 Sep 25 2005 /w/backup/woozle/var/log/www/woozle/.access_log.9.gz.wxuWSQ DM> DM> root@woozle:/usr/ports# rm -f !$ DM> DM> rm -f /w/backup/woozle/var/log/www/woozle/.access_log.9.gz.* DM> DM> rm: /w/backup/woozle/var/log/www/woozle/.access_log.9.gz.bg9Zcw: Operation not permitted DM> DM> rm: /w/backup/woozle/var/log/www/woozle/.access_log.9.gz.dxux3T: Operation not permitted DM> DM> rm: /w/backup/woozle/var/log/www/woozle/.access_log.9.gz.wxuWSQ: Operation not permitted DM> DM> DM> DM> zfs umount/mount does not fix the problem. turning on vfs.zfs.debug does not DM> DM> reveal anything. DM> DM> found the source: it's sunlnk flag on a directory, which behaves differently on DM> UFS and ZFS: on UFS, this flag does not prevent removing files from the directory, only DM> removing and renaming directory itself. DM> DM> Should I file a PR? For the reference: http://www.freebsd.org/cgi/query-pr.cgi?pr=143343 -- Sincerely, D.Marck [DM5020, MCK-RIPE, DM3-RIPN] [ FreeBSD committer: marck@FreeBSD.org ] ------------------------------------------------------------------------ *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- marck@rinet.ru *** ------------------------------------------------------------------------ From owner-freebsd-stable@FreeBSD.ORG Fri Jan 29 13:27:32 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E6238106566C for ; Fri, 29 Jan 2010 13:27:32 +0000 (UTC) (envelope-from se@FreeBSD.org) Received: from smtp103.plus.mail.re1.yahoo.com (smtp103.plus.mail.re1.yahoo.com [69.147.102.66]) by mx1.freebsd.org (Postfix) with SMTP id 8C9508FC13 for ; Fri, 29 Jan 2010 13:27:32 +0000 (UTC) Received: (qmail 71627 invoked from network); 29 Jan 2010 13:00:51 -0000 Received: from xdsl-81-173-180-36.netcologne.de (se@81.173.180.36 with plain) by smtp103.plus.mail.re1.yahoo.com with SMTP; 29 Jan 2010 05:00:51 -0800 PST X-Yahoo-SMTP: iDf2N9.swBDAhYEh7VHfpgq0lnq. X-YMail-OSG: YQ5CEK8VM1kdeYe8KeS45zCFvga.rEQrE2QCjU8G1QvF7aDx85WmF7RNqXdERX7qFVfu2bNuoIJdKvz0POq63um1oFF0Eyclg.rAw4vk1FxKChUy5UC8l9T4RTtJyNbq_9W8q14zTv3wmUqJYjnQWVhIpFzBRo0Tl5mgZM97b4Uovka4_ocnoIsD9DWzMUBVm31Wp4pkAdhNBkOBkh.mfWCq74tpFArP._khcdUntqHX86FztqOo9TRgixa75dzRXN6NpsB1XbtfQ.tnqeMeX2A7QDze2EIQo0zXkdrCzG7iEq9YyCS1jfZ2sK9w1FkMAfBmaKp1PwXFldZv4gbxDFl5LW4370DwLvPprJXgbTQmxYH1Aqnz2SJlSQz2Wc3zVRRTUiFM58vCA329mHys1s0NzYH3EylXNL5NA6rKaN5b.Ah0PA-- X-Yahoo-Newman-Property: ymail-5 Message-ID: <4B62DC03.8000407@FreeBSD.org> Date: Fri, 29 Jan 2010 14:00:51 +0100 From: Stefan Esser User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.8.1.18) Gecko/20081105 Thunderbird/2.0.0.18 ThunderBrowse/3.2.2.1 Mnenhy/0.7.5.666 MIME-Version: 1.0 To: freebsd-stable@freebsd.org References: <4B5DE3C1.4060508@FreeBSD.org> <201001260946.01541.doconnor@gsoft.com.au> In-Reply-To: <201001260946.01541.doconnor@gsoft.com.au> X-Enigmail-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 7bit Subject: Re: 8.0-RELEASE/amd64 - full ZFS install - low read and write disk performance X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jan 2010 13:27:33 -0000 Am 26.01.2010 00:15, schrieb Daniel O'Connor: > On Tue, 26 Jan 2010, Dan Naumov wrote: >> CPU-performance-wise, I am not really worried. The current system is >> an Atom 330 and even that is a bit overkill for what I do with it and >> from what I am seeing, the new Atom D510 used on those boards is a >> tiny bit faster. What I want and care about for this system are >> reliability, stability, low power use, quietness and fast disk >> read/write speeds. I've been hearing some praise of ICH9R and 6 >> native SATA ports should be enough for my needs. AFAIK, the Intel >> 82574L network cards included on those are also very well supported? > > You might want to consider an Athlon (maybe underclock it) - the AMD IXP > 700/800 south bridge seems to work well with FreeBSD (in my > experience). > > These boards (eg Gigabyte GA-MA785GM-US2H) have 6 SATA ports (one may be > eSATA though) and PATA, they seem ideal really.. You can use PATA with > CF to boot and connect 5 disks plus a DVD drive. > > The CPU is not fanless however, but the other stuff is, on the plus side > you won't have to worry about CPU power :) > > Also, the onboard video works well with radeonhd and is quite fast. > > One other downside is the onboard network isn't great (Realtek) but I > put an em card in mine. If neither an Atom 330 nor a cheap Athlon 64 do not offer sufficient performance, the new i3-530 and H55 chip-set may be a much faster alternative (with lower power consumption than the Athlon 64). This combination is more expensive (official CPU list price $113) but a CPU plus uATX mainboard should still be under $200 (e.g. the MSI H55M-E33, or if you want an ITX form factor mainboard, the Zotac H55-ITX). Idle power of a small system (incl. 2.5" disk) has been reported as low as 20W (primary power, efficient 120W power supply), with throughput near that of low end quad CPUs. Regards, STefan From owner-freebsd-stable@FreeBSD.ORG Fri Jan 29 13:38:27 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 36BC110656AB for ; Fri, 29 Jan 2010 13:38:27 +0000 (UTC) (envelope-from marco@goofy.tols.org) Received: from goofy.tols.org (goofy.tols.org [83.163.60.200]) by mx1.freebsd.org (Postfix) with ESMTP id 9135A8FC21 for ; Fri, 29 Jan 2010 13:38:25 +0000 (UTC) Received: from goofy.tols.org (localhost [127.0.0.1]) by goofy.tols.org (8.14.3/8.14.3) with ESMTP id o0TDcOJw024454 for ; Fri, 29 Jan 2010 13:38:24 GMT (envelope-from marco@goofy.tols.org) Received: (from marco@localhost) by goofy.tols.org (8.14.3/8.14.3/Submit) id o0TDcO8A024453 for freebsd-stable@freebsd.org; Fri, 29 Jan 2010 13:38:24 GMT (envelope-from marco) Date: Fri, 29 Jan 2010 13:38:24 +0000 From: Marco van Tol To: FreeBSD STABLE Message-ID: <20100129133824.GE23403@goofy.tols.org> Mail-Followup-To: FreeBSD STABLE References: <147432021001242047k659a26d0s44b35164920aeb74@mail.gmail.com> <95D3CB82-BC44-491D-86E4-5CB82F89C0FC@nokia.com> <147432021001250825p202914a7ka5a2c1d28d96bac3@mail.gmail.com> <20100125182257.GG1187@michelle.cdnetworks.com> <147432021001251038r69393ab3m1a797e58f9fa905a@mail.gmail.com> <02307620-ECDC-4E8B-A5B1-FF8491E226C4@nokia.com> <33c6b0bc1001252031k508426bfh25fad65e9223d87@mail.gmail.com> <147432021001260900p60ed1804t97392d2dff5cd244@mail.gmail.com> <20100128121701.GB9408@goofy.tols.org> <2a41acea1001281116k7d14cc26x120f9960ab14d19d@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <2a41acea1001281116k7d14cc26x120f9960ab14d19d@mail.gmail.com> User-Agent: Mutt/1.4.2.3i Subject: Re: em interface slow down on 8.0R X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 29 Jan 2010 13:38:27 -0000 On Thu, Jan 28, 2010 at 11:16:02AM -0800, Jack Vogel wrote: > I am investigating it, and have a suspicion about what's going on, you can > assist in verifying my suspicion. In if_em.c search for "em_setup_vlan_hw", > you will find a compile time option that uses that only if FreeBSD_version > is > 700029, hack the code however you wish so that it uses the OLD way > (ie that it never calls em_setup_vlan_hw_support()) and see if that makes > the issue disappear. Oh good, I will try that and let you know about the result first chance I get. Should be days rather then hours, but I'll make it asap. > If you have any problems or questions email me directly. Will do, thanks! Marco > On Thu, Jan 28, 2010 at 4:17 AM, Marco van Tol wrote: > > > On Tue, Jan 26, 2010 at 09:00:35AM -0800, Nick Rogers wrote: > > > Is it advisable to patch 8.0-RELEASE kernel sources with the latest > > > (CURRENT) em driver (i.e., src/sys/dev/e1000)? It looks like there are > > some > > > updates to the driver since 8.0-RELEASE that may fix some problems? > > > > While on the em subject, forgive me if I mail this to the inappropriate > > place, but is there any ETA on progress for bug kern/141646? > > > > I'm currently suffering from it and would be willing to provide needed > > assistance for fixing it. > > > > Thank you very much in advance, > > > > Marco van Tol -- Better to remain silent and be thought a fool than to speak out and remove all doubt. - Abraham Lincoln From owner-freebsd-stable@FreeBSD.ORG Fri Jan 29 13:40:32 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4AF261065706 for ; Fri, 29 Jan 2010 13:40:32 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from qmta15.emeryville.ca.mail.comcast.net (qmta15.emeryville.ca.mail.comcast.net [76.96.27.228]) by mx1.freebsd.org (Postfix) with ESMTP id 31C388FC0A for ; Fri, 29 Jan 2010 13:40:31 +0000 (UTC) Received: from omta20.emeryville.ca.mail.comcast.net ([76.96.30.87]) by qmta15.emeryville.ca.mail.comcast.net with comcast id bRU21d0041smiN4AFRgYEH; Fri, 29 Jan 2010 13:40:32 +0000 Received: from koitsu.dyndns.org ([98.248.46.159]) by omta20.emeryville.ca.mail.comcast.net with comcast id bRgX1d00A3S48mS8gRgX5e; Fri, 29 Jan 2010 13:40:32 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id 7C10D1E3033; Fri, 29 Jan 2010 05:40:30 -0800 (PST) Date: Fri, 29 Jan 2010 05:40:30 -0800 From: Jeremy Chadwick To: freebsd-stable@freebsd.org Message-ID: <20100129134030.GA44869@icarus.home.lan> References: <20100122162155.GG3917@e-Gitt.NET> <201001232244.03752.doconnor@gsoft.com.au> <20100129104624.GA13472@ei.bzerk.org> <201001292230.01867.doconnor@gsoft.com.au> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201001292230.01867.doconnor@gsoft.com.au> User-Agent: Mutt/1.5.20 (2009-06-14) Subject: Re: 8.0-RELEASE -> -STABLE and size of / X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jan 2010 13:40:32 -0000 On Fri, Jan 29, 2010 at 10:29:51PM +1030, Daniel O'Connor wrote: > On Fri, 29 Jan 2010, Ruben de Groot wrote: > > > I don't think you need them unless remote debugging and in that > > > case you are multiuser (I would have thought anyway). > > > > > > If they went into /usr then /boot could remain slim. > > > > But what if you have /usr on a gmirror, glabel, zfs filesystem or any > > other device that is not compiled in your kernel? Sure you can build > > a custom kernel, but I would expect a lot of questions, frustrations > > and footshooting from such a change. > > > > I think increasing / (again) would be the least painfull. > > You don't need debug symbols to boot a kernel, you only need them when > debugging. Somewhat related: can someone explain why debugging a crash dump of a kernel which contains "makeoptions DEBUG=-g" requires and relies on stuff in /usr/obj? Meaning: if I build kernel/world, install kernel/world, and then rm -fr /usr/obj/*, I won't be able to reliably debug a crash dump after the system restarts. I believe I can get a stack trace, but there's nothing else that can be ascertained (bt full is basically worthless). I've seen kernel crash dumps from people here on the list[1] which contain way more detail than any of mine do[2]. Off-topic: I've noticed that /usr/obj is created as part of the OS installation with perms 0755. I've always thought there might be security implications by that, so usually end up setting it to 0700 or possibly 0750 (still root:wheel). [1]: http://lists.freebsd.org/pipermail/freebsd-stable/2010-January/054269.html [2]: http://lists.freebsd.org/pipermail/freebsd-stable/2009-October/052256.html -- | Jeremy Chadwick jdc@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Fri Jan 29 14:25:33 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 838801065679 for ; Fri, 29 Jan 2010 14:25:33 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id C59158FC14 for ; Fri, 29 Jan 2010 14:25:32 +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 QAA09747; Fri, 29 Jan 2010 16:25:27 +0200 (EET) (envelope-from avg@icyb.net.ua) Message-ID: <4B62EFD7.2010800@icyb.net.ua> Date: Fri, 29 Jan 2010 16:25:27 +0200 From: Andriy Gapon User-Agent: Thunderbird 2.0.0.23 (X11/20091206) MIME-Version: 1.0 To: Jeremy Chadwick References: <20100122162155.GG3917@e-Gitt.NET> <201001232244.03752.doconnor@gsoft.com.au> <20100129104624.GA13472@ei.bzerk.org> <201001292230.01867.doconnor@gsoft.com.au> <20100129134030.GA44869@icarus.home.lan> In-Reply-To: <20100129134030.GA44869@icarus.home.lan> X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org Subject: Re: 8.0-RELEASE -> -STABLE and size of / X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jan 2010 14:25:33 -0000 on 29/01/2010 15:40 Jeremy Chadwick said the following: > On Fri, Jan 29, 2010 at 10:29:51PM +1030, Daniel O'Connor wrote: >> On Fri, 29 Jan 2010, Ruben de Groot wrote: >>>> I don't think you need them unless remote debugging and in that >>>> case you are multiuser (I would have thought anyway). >>>> >>>> If they went into /usr then /boot could remain slim. >>> But what if you have /usr on a gmirror, glabel, zfs filesystem or any >>> other device that is not compiled in your kernel? Sure you can build >>> a custom kernel, but I would expect a lot of questions, frustrations >>> and footshooting from such a change. >>> >>> I think increasing / (again) would be the least painfull. >> You don't need debug symbols to boot a kernel, you only need them when >> debugging. > > Somewhat related: can someone explain why debugging a crash dump of a > kernel which contains "makeoptions DEBUG=-g" requires and relies on > stuff in /usr/obj? So do remove or not install *.symbols files? That would explain it. I keep those files and my debugging doesn't depend on /usr/obj. > Meaning: if I build kernel/world, install kernel/world, and then rm -fr > /usr/obj/*, I won't be able to reliably debug a crash dump after the > system restarts. I believe I can get a stack trace, but there's nothing > else that can be ascertained (bt full is basically worthless). > > I've seen kernel crash dumps from people here on the list[1] which > contain way more detail than any of mine do[2]. > > Off-topic: I've noticed that /usr/obj is created as part of the OS > installation with perms 0755. I've always thought there might be > security implications by that, so usually end up setting it to 0700 or > possibly 0750 (still root:wheel). > > [1]: http://lists.freebsd.org/pipermail/freebsd-stable/2010-January/054269.html > [2]: http://lists.freebsd.org/pipermail/freebsd-stable/2009-October/052256.html > -- Andriy Gapon From owner-freebsd-stable@FreeBSD.ORG Fri Jan 29 14:33:16 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 442B4106566B for ; Fri, 29 Jan 2010 14:33:16 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from qmta04.emeryville.ca.mail.comcast.net (qmta04.emeryville.ca.mail.comcast.net [76.96.30.40]) by mx1.freebsd.org (Postfix) with ESMTP id 29BDF8FC1A for ; Fri, 29 Jan 2010 14:33:15 +0000 (UTC) Received: from omta24.emeryville.ca.mail.comcast.net ([76.96.30.92]) by qmta04.emeryville.ca.mail.comcast.net with comcast id bQi11d0061zF43QA4SZGAf; Fri, 29 Jan 2010 14:33:16 +0000 Received: from koitsu.dyndns.org ([98.248.46.159]) by omta24.emeryville.ca.mail.comcast.net with comcast id bSa81d00E3S48mS8kSa8qN; Fri, 29 Jan 2010 14:34:08 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id 429F91E3033; Fri, 29 Jan 2010 06:33:14 -0800 (PST) Date: Fri, 29 Jan 2010 06:33:14 -0800 From: Jeremy Chadwick To: freebsd-stable@freebsd.org Message-ID: <20100129143314.GA46085@icarus.home.lan> References: <20100122162155.GG3917@e-Gitt.NET> <201001232244.03752.doconnor@gsoft.com.au> <20100129104624.GA13472@ei.bzerk.org> <201001292230.01867.doconnor@gsoft.com.au> <20100129134030.GA44869@icarus.home.lan> <4B62EFD7.2010800@icyb.net.ua> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4B62EFD7.2010800@icyb.net.ua> User-Agent: Mutt/1.5.20 (2009-06-14) Subject: Re: 8.0-RELEASE -> -STABLE and size of / X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jan 2010 14:33:16 -0000 On Fri, Jan 29, 2010 at 04:25:27PM +0200, Andriy Gapon wrote: > on 29/01/2010 15:40 Jeremy Chadwick said the following: > > On Fri, Jan 29, 2010 at 10:29:51PM +1030, Daniel O'Connor wrote: > >> On Fri, 29 Jan 2010, Ruben de Groot wrote: > >>>> I don't think you need them unless remote debugging and in that > >>>> case you are multiuser (I would have thought anyway). > >>>> > >>>> If they went into /usr then /boot could remain slim. > >>> But what if you have /usr on a gmirror, glabel, zfs filesystem or any > >>> other device that is not compiled in your kernel? Sure you can build > >>> a custom kernel, but I would expect a lot of questions, frustrations > >>> and footshooting from such a change. > >>> > >>> I think increasing / (again) would be the least painfull. > >> You don't need debug symbols to boot a kernel, you only need them when > >> debugging. > > > > Somewhat related: can someone explain why debugging a crash dump of a > > kernel which contains "makeoptions DEBUG=-g" requires and relies on > > stuff in /usr/obj? > > So do remove or not install *.symbols files? > That would explain it. > I keep those files and my debugging doesn't depend on /usr/obj. > > > Meaning: if I build kernel/world, install kernel/world, and then rm -fr > > /usr/obj/*, I won't be able to reliably debug a crash dump after the > > system restarts. I believe I can get a stack trace, but there's nothing > > else that can be ascertained (bt full is basically worthless). > > > > I've seen kernel crash dumps from people here on the list[1] which > > contain way more detail than any of mine do[2]. > > > > Off-topic: I've noticed that /usr/obj is created as part of the OS > > installation with perms 0755. I've always thought there might be > > security implications by that, so usually end up setting it to 0700 or > > possibly 0750 (still root:wheel). > > > > [1]: http://lists.freebsd.org/pipermail/freebsd-stable/2010-January/054269.html > > [2]: http://lists.freebsd.org/pipermail/freebsd-stable/2009-October/052256.html The *.symbols files I have for the kernel are installed in /boot/kernel. I'm referring to "stuff" in /usr/obj which appears to be required to debug a crash (vmcore). What I'm describing is even mentioned in the FreeBSD Developers Handbook: http://www.freebsd.org/doc/en/books/developers-handbook/kerneldebug-gdb.html Note the first two steps: 1:# cd /usr/obj/usr/src/sys/KERNCONF 2:# kgdb kernel.debug /var/crash/vmcore.0 -- | Jeremy Chadwick jdc@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Fri Jan 29 15:13:40 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 07AE4106568F for ; Fri, 29 Jan 2010 15:13:40 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 4C8CB8FC1C for ; Fri, 29 Jan 2010 15:13:38 +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 RAA10375; Fri, 29 Jan 2010 17:13:35 +0200 (EET) (envelope-from avg@icyb.net.ua) Message-ID: <4B62FB1F.7070005@icyb.net.ua> Date: Fri, 29 Jan 2010 17:13:35 +0200 From: Andriy Gapon User-Agent: Thunderbird 2.0.0.23 (X11/20091206) MIME-Version: 1.0 To: Jeremy Chadwick References: <20100122162155.GG3917@e-Gitt.NET> <201001232244.03752.doconnor@gsoft.com.au> <20100129104624.GA13472@ei.bzerk.org> <201001292230.01867.doconnor@gsoft.com.au> <20100129134030.GA44869@icarus.home.lan> <4B62EFD7.2010800@icyb.net.ua> <20100129143314.GA46085@icarus.home.lan> In-Reply-To: <20100129143314.GA46085@icarus.home.lan> X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org Subject: Re: 8.0-RELEASE -> -STABLE and size of / X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jan 2010 15:13:40 -0000 on 29/01/2010 16:33 Jeremy Chadwick said the following: > > The *.symbols files I have for the kernel are installed in /boot/kernel. > I'm referring to "stuff" in /usr/obj which appears to be required to > debug a crash (vmcore). What I'm describing is even mentioned in the > FreeBSD Developers Handbook: > > http://www.freebsd.org/doc/en/books/developers-handbook/kerneldebug-gdb.html > > Note the first two steps: > > 1:# cd /usr/obj/usr/src/sys/KERNCONF > 2:# kgdb kernel.debug /var/crash/vmcore.0 No, that information is outdated. The *.symbols files in /boot/kernel are required, "stuff in /usr/obj" is not. You start debugging by kgdb /boot/kernel/kernel /var/crash/vmcore.0 or whatever are the proper paths. BTW, this section is also obsolete: http://www.freebsd.org/doc/en/books/developers-handbook/kerneldebug-kld.html Modules/their symbols are loaded automatically in the recent versions of FreeBSD. -- Andriy Gapon From owner-freebsd-stable@FreeBSD.ORG Fri Jan 29 15:37:50 2010 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 143281065670 for ; Fri, 29 Jan 2010 15:37:50 +0000 (UTC) (envelope-from lists@mawer.org) Received: from mail-pw0-f44.google.com (mail-pw0-f44.google.com [209.85.160.44]) by mx1.freebsd.org (Postfix) with ESMTP id EB6BA8FC0A for ; Fri, 29 Jan 2010 15:37:49 +0000 (UTC) Received: by pwi15 with SMTP id 15so1503621pwi.3 for ; Fri, 29 Jan 2010 07:37:49 -0800 (PST) MIME-Version: 1.0 Received: by 10.140.247.16 with SMTP id u16mr754697rvh.2.1264779467422; Fri, 29 Jan 2010 07:37:47 -0800 (PST) Date: Sat, 30 Jan 2010 02:37:47 +1100 Message-ID: From: Antony Mawer To: stable@freebsd.org Content-Type: multipart/mixed; boundary=000e0cd10562dffc18047e4f6a4a Cc: Subject: [patch] New splash_txt module - support for ASCII splash(4) boot screens X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jan 2010 15:37:50 -0000 --000e0cd10562dffc18047e4f6a4a Content-Type: text/plain; charset=ISO-8859-1 Hi all, I recently dusted off an old patch I put together years ago which adds a new splash_txt decoder module for the splash(4) boot splash screen. The module allows you to use a binary-format ASCII drawing (80x25) as a boot splash screen rather than the graphical modes offered by splash_bmp and splash_pcx. We have been and still are using it, but I finally got around to adding the relevant changes to the splash(4) man page and putting together some examples for wider testing. If it seems of use to others it would be nice if someone would be interested in committing it at some stage. In case the list eats the patch, you can grab a copy of it here: http://www.mawer.org/freebsd/splash_txt.patch To give you an idea of what it looks like, here is a screenshot of a quick generic FreeBSD splash screen I put together: http://www.mawer.org/freebsd/splash_txt.png If you'd like to try it for yourself then the process to build it should be something like this: 1. Download the attached patch 2. Create the required folders before applying the patch -- cd /usr/src && mkdir sys/modules/splash/txt 3. Apply the patch -- patch < splash_txt.patch 4. Build the module -- cd sys/modules/splash/txt && make && make install Once that's completed, you can configure it by adding the following to loader.conf: splash_txt_load="YES" bitmap_load="YES" bitmap_name="/boot/freebsd.bin" I have uploaded a sample boot splash screen at http://www.mawer.org/freebsd/freebsd.bin . The files can be produced using TheDraw and saving in its Binary file format, which consists of a sequence of 2 byte pairs. The first byte in a pair is the character to draw on the screen, and the second is the colour/display attributes to draw the character with. If anyone else would like to try this out and has any feedback, or if someone thinks it may be of interest to integrate into the tree please let me know ... -- Antony --000e0cd10562dffc18047e4f6a4a Content-Type: application/octet-stream; name="splash_txt.patch" Content-Disposition: attachment; filename="splash_txt.patch" Content-Transfer-Encoding: base64 X-Attachment-Id: f_g514lfl40 LS0tIC9kZXYvbnVsbAkyMDEwLTAxLTMwIDEwOjAwOjAwLjAwMDAwMDAwMCArMTEwMAorKysgc3lz L2Rldi9mYi9zcGxhc2hfdHh0LmMJMjAxMC0wMS0zMCAwOTowNzoyOC4wMDAwMDAwMDAgKzExMDAK QEAgLTAsMCArMSwxMzkgQEAKKy8qLQorICogQ29weXJpZ2h0IChjKSAxOTk5IE1pY2hhZWwgU21p dGggPG1zbWl0aEBmcmVlYnNkLm9yZz4KKyAqIENvcHlyaWdodCAoYykgMTk5OSBLYXp1dGFrYSBZ T0tPVEEgPHlva290YUBmcmVlYnNkLm9yZz4KKyAqIENvcHlyaWdodCAoYykgMjAwNSBBbnRvbnkg TWF3ZXIgPGFudG9ueUBtYXdlci5vcmc+CisgKiBBbGwgcmlnaHRzIHJlc2VydmVkLgorICoKKyAq IFJlZGlzdHJpYnV0aW9uIGFuZCB1c2UgaW4gc291cmNlIGFuZCBiaW5hcnkgZm9ybXMsIHdpdGgg b3Igd2l0aG91dAorICogbW9kaWZpY2F0aW9uLCBhcmUgcGVybWl0dGVkIHByb3ZpZGVkIHRoYXQg dGhlIGZvbGxvd2luZyBjb25kaXRpb25zCisgKiBhcmUgbWV0OgorICogMS4gUmVkaXN0cmlidXRp b25zIG9mIHNvdXJjZSBjb2RlIG11c3QgcmV0YWluIHRoZSBhYm92ZSBjb3B5cmlnaHQKKyAqICAg IG5vdGljZSwgdGhpcyBsaXN0IG9mIGNvbmRpdGlvbnMgYW5kIHRoZSBmb2xsb3dpbmcgZGlzY2xh aW1lci4KKyAqIDIuIFJlZGlzdHJpYnV0aW9ucyBpbiBiaW5hcnkgZm9ybSBtdXN0IHJlcHJvZHVj ZSB0aGUgYWJvdmUgY29weXJpZ2h0CisgKiAgICBub3RpY2UsIHRoaXMgbGlzdCBvZiBjb25kaXRp b25zIGFuZCB0aGUgZm9sbG93aW5nIGRpc2NsYWltZXIgaW4gdGhlCisgKiAgICBkb2N1bWVudGF0 aW9uIGFuZC9vciBvdGhlciBtYXRlcmlhbHMgcHJvdmlkZWQgd2l0aCB0aGUgZGlzdHJpYnV0aW9u LgorICoKKyAqIFRISVMgU09GVFdBUkUgSVMgUFJPVklERUQgQlkgVEhFIEFVVEhPUlMgQU5EIENP TlRSSUJVVE9SUyBgYEFTIElTJycgQU5ECisgKiBBTlkgRVhQUkVTUyBPUiBJTVBMSUVEIFdBUlJB TlRJRVMsIElOQ0xVRElORywgQlVUIE5PVCBMSU1JVEVEIFRPLCBUSEUKKyAqIElNUExJRUQgV0FS UkFOVElFUyBPRiBNRVJDSEFOVEFCSUxJVFkgQU5EIEZJVE5FU1MgRk9SIEEgUEFSVElDVUxBUiBQ VVJQT1NFCisgKiBBUkUgRElTQ0xBSU1FRC4gIElOIE5PIEVWRU5UIFNIQUxMIFRIRSBBVVRIT1JT IE9SIENPTlRSSUJVVE9SUyBCRSBMSUFCTEUKKyAqIEZPUiBBTlkgRElSRUNULCBJTkRJUkVDVCwg SU5DSURFTlRBTCwgU1BFQ0lBTCwgRVhFTVBMQVJZLCBPUiBDT05TRVFVRU5USUFMCisgKiBEQU1B R0VTIChJTkNMVURJTkcsIEJVVCBOT1QgTElNSVRFRCBUTywgUFJPQ1VSRU1FTlQgT0YgU1VCU1RJ VFVURSBHT09EUworICogT1IgU0VSVklDRVM7IExPU1MgT0YgVVNFLCBEQVRBLCBPUiBQUk9GSVRT OyBPUiBCVVNJTkVTUyBJTlRFUlJVUFRJT04pCisgKiBIT1dFVkVSIENBVVNFRCBBTkQgT04gQU5Z IFRIRU9SWSBPRiBMSUFCSUxJVFksIFdIRVRIRVIgSU4gQ09OVFJBQ1QsIFNUUklDVAorICogTElB QklMSVRZLCBPUiBUT1JUIChJTkNMVURJTkcgTkVHTElHRU5DRSBPUiBPVEhFUldJU0UpIEFSSVNJ TkcgSU4gQU5ZIFdBWQorICogT1VUIE9GIFRIRSBVU0UgT0YgVEhJUyBTT0ZUV0FSRSwgRVZFTiBJ RiBBRFZJU0VEIE9GIFRIRSBQT1NTSUJJTElUWSBPRgorICogU1VDSCBEQU1BR0UuCisgKgorICog JEZyZWVCU0QkCisgKi8KKworI2luY2x1ZGUgPHN5cy9wYXJhbS5oPgorI2luY2x1ZGUgPHN5cy9z eXN0bS5oPgorI2luY2x1ZGUgPHN5cy9tb2R1bGUuaD4KKyNpbmNsdWRlIDxzeXMva2VybmVsLmg+ CisjaW5jbHVkZSA8c3lzL2NvbnNpby5oPgorI2luY2x1ZGUgPHN5cy9mYmlvLmg+CisKKyNpbmNs dWRlIDxtYWNoaW5lL3BjL2Rpc3BsYXkuaD4KKworI2luY2x1ZGUgPGRldi9mYi9mYnJlZy5oPgor I2luY2x1ZGUgPGRldi9mYi9zcGxhc2hyZWcuaD4KKyNpbmNsdWRlIDxkZXYvc3lzY29ucy9zeXNj b25zLmg+CisKK3N0YXRpYyBpbnQgIHNwbGFzaF9vbiA9IEZBTFNFOworCitzdGF0aWMgaW50IHR4 dF9pbml0KHZpZGVvX2FkYXB0ZXJfdCAqYWRwKTsKK3N0YXRpYyBpbnQgdHh0X2VuZCh2aWRlb19h ZGFwdGVyX3QgKmFkcCk7CitzdGF0aWMgaW50IHR4dF9zcGxhc2godmlkZW9fYWRhcHRlcl90ICph ZHAsIGludCBvbik7CisKKy8qIFRoZXNlIGFyZSByb3dzIGJ5IGNvbHVtbnMgb2YgdGhlIHRleHQt bW9kZSBkaXNwbGF5IGRldmljZSAqLworI2RlZmluZSBCSU5fSU1BR0VfV0lEVEgJCTgwCisjZGVm aW5lIEJJTl9JTUFHRV9IRUlHSFQJMjUKKworc3RhdGljIHNwbGFzaF9kZWNvZGVyX3QgdHh0X2Rl Y29kZXIgPSB7CisgICAgInNwbGFzaF90eHQiLCB0eHRfaW5pdCwgdHh0X2VuZCwgdHh0X3NwbGFz aCwgU1BMQVNIX0lNQUdFLAorfTsKKworU1BMQVNIX0RFQ09ERVIoc3BsYXNoX3R4dCwgdHh0X2Rl Y29kZXIpOworCisKK3N0YXRpYyB2b2lkCitkcmF3X3RleHRfc3BsYXNoKHNjX3NvZnRjX3QgKnNj KQoreworICAgIGludCB4LCB5OworICAgIHVfY2hhciBjaCwgYXR0cjsKKyAgICB1X2NoYXIgKnBk YXRhID0gKHVfY2hhciAqKXR4dF9kZWNvZGVyLmRhdGE7CisKKyAgICAvKiBJbml0IGZhaWxlZCAq LworICAgIGlmICh0eHRfZGVjb2Rlci5kYXRhID09IE5VTEwpCisJcmV0dXJuOworCisgICAgZm9y ICh5PTA7IHkgPCBCSU5fSU1BR0VfSEVJR0hUOyB5KyspIHsKKwlmb3IgKHg9MDsgeCA8IEJJTl9J TUFHRV9XSURUSDsgeCsrKSB7CisJICAgIGNoID0gcGRhdGFbMF07CisJICAgIHBkYXRhKys7CisJ ICAgIGF0dHIgPSBwZGF0YVswXTsKKwkgICAgcGRhdGErKzsKKworCSAgICBzY192dGJfcHV0Yygm c2MtPmN1cl9zY3AtPnNjciwKKwkJKHkgKiBzYy0+Y3VyX3NjcC0+eHNpemUpICsgeCwKKwkJc2Mt PnNjcl9tYXBbY2hdLAorCQkoaW50KWF0dHIgPDwgOCk7CisJfQorICAgIH0KK30KKworc3RhdGlj IGludAordHh0X2luaXQodmlkZW9fYWRhcHRlcl90ICphZHApCit7CisgICAgLy8gRW5zdXJlIHRo YXQgdGhlIGltYWdlIGRhdGEgZXhpc3RzCisgICAgaWYgKCh0eHRfZGVjb2Rlci5kYXRhID09IE5V TEwpIHx8ICh0eHRfZGVjb2Rlci5kYXRhX3NpemUgPD0gMCkpIHsKKwlwcmludGYoInNwbGFzaF90 eHQ6IE5vIEFTQ0lJIGJpdG1hcCBmaWxlIGZvdW5kXG4iKTsKKwlyZXR1cm4gRU5PREVWOworICAg IH0KKworICAgIHJldHVybiAwOworfQorCitzdGF0aWMgaW50Cit0eHRfZW5kKHZpZGVvX2FkYXB0 ZXJfdCAqYWRwKQoreworICAgIHJldHVybiAwOworfQorCitzdGF0aWMgaW50Cit0eHRfc3BsYXNo KHZpZGVvX2FkYXB0ZXJfdCAqYWRwLCBpbnQgb24pCit7CisgICAgc2Nfc29mdGNfdCAqc2M7Cisg ICAgc2NyX3N0YXQgKnNjcDsKKworICAgIHNjID0gc2NfZmluZF9zb2Z0YyhhZHAsIE5VTEwpOwor ICAgIGlmIChzYyA9PSBOVUxMKQorCXJldHVybiBFQUdBSU47CisgICAgc2NwID0gc2MtPmN1cl9z Y3A7CisKKyAgICBpZiAob24pIHsKKwlpZiAoIXNwbGFzaF9vbikgeworCSAgICBpZiAoYWRwLT52 YV9pbmZvLnZpX2ZsYWdzICYgVl9JTkZPX0dSQVBISUNTKQorCQlyZXR1cm4gRUFHQUlOOworCisJ ICAgIC8qIENsZWFyIHNjcmVlbiBhbmQgc2V0IGJvcmRlciBjb2xvdXIgKi8KKwkgICAgc2NfdnRi X2NsZWFyKCZzY3AtPnNjciwgc2MtPnNjcl9tYXBbMHgyMF0sCisJCShGR19MSUdIVEdSRVkgfCBC R19CTEFDSykgPDwgOCk7CisJICAgICgqdmlkc3dbYWRwLT52YV9pbmRleF0tPnNldF9od19jdXJz b3IpKGFkcCwgLTEsIC0xKTsKKwkgICAgc2Nfc2V0X2JvcmRlcihzY3AsIDApOworCSAgICBzcGxh c2hfb24gPSBUUlVFOworCisJICAgIC8qIERpc3BsYXkgdGhlIHNwbGFzaCBzY3JlZW4gKi8KKwkg ICAgZHJhd190ZXh0X3NwbGFzaChzYyk7CisJfQorCXJldHVybiAwOworICAgIH0gZWxzZSB7CisJ LyogdGhlIHZpZGVvIG1vZGUgd2lsbCBiZSByZXN0b3JlZCBieSB0aGUgY2FsbGVyICovCisJc3Bs YXNoX29uID0gRkFMU0U7CisJcmV0dXJuIDA7CisgICAgfQorfQorCisKZGlmZiAtTnJ1IHN5cy9t b2R1bGVzL3NwbGFzaC5vbGQvTWFrZWZpbGUgc3lzL21vZHVsZXMvc3BsYXNoL01ha2VmaWxlCi0t LSBzeXMvbW9kdWxlcy9zcGxhc2gub2xkL01ha2VmaWxlCTIwMTAtMDEtMzAgMDg6NDE6NDcuMDAw MDAwMDAwICsxMTAwCisrKyBzeXMvbW9kdWxlcy9zcGxhc2gvTWFrZWZpbGUJMjAxMC0wMS0zMCAw ODo0MzowOC4wMDAwMDAwMDAgKzExMDAKQEAgLTEsNSArMSw1IEBACiAjICRGcmVlQlNEOiBzcmMv c3lzL21vZHVsZXMvc3BsYXNoL01ha2VmaWxlLHYgMS4zLjU2LjEuMi4xIDIwMDkvMTAvMjUgMDE6 MTA6Mjkga2Vuc21pdGggRXhwICQKIAotU1VCRElSPQlibXAgcGN4CitTVUJESVI9CWJtcCBwY3gg dHh0CiAKIC5pbmNsdWRlIDxic2Quc3ViZGlyLm1rPgpkaWZmIC1OcnUgc3lzL21vZHVsZXMvc3Bs YXNoLm9sZC90eHQvTWFrZWZpbGUgc3lzL21vZHVsZXMvc3BsYXNoL3R4dC9NYWtlZmlsZQotLS0g c3lzL21vZHVsZXMvc3BsYXNoLm9sZC90eHQvTWFrZWZpbGUJMTk3MC0wMS0wMSAxMDowMDowMC4w MDAwMDAwMDAgKzEwMDAKKysrIHN5cy9tb2R1bGVzL3NwbGFzaC90eHQvTWFrZWZpbGUJMjAxMC0w MS0zMCAwODo0MzozNS4wMDAwMDAwMDAgKzExMDAKQEAgLTAsMCArMSw2IEBACisuUEFUSDoJJHsu Q1VSRElSfS8uLi8uLi8uLi9kZXYvZmIKKworS01PRD0Jc3BsYXNoX3R4dAorU1JDUz0gCXNwbGFz aF90eHQuYworCisuaW5jbHVkZSA8YnNkLmttb2QubWs+Ci0tLSBzaGFyZS9tYW4vbWFuNC9zcGxh c2guNC5vbGQJMjAxMC0wMS0zMCAwODo0NDoyMi4wMDAwMDAwMDAgKzExMDAKKysrIHNoYXJlL21h bi9tYW40L3NwbGFzaC40CTIwMTAtMDEtMzAgMDk6MTI6MjguMDAwMDAwMDAwICsxMTAwCkBAIC0y Niw3ICsyNiw3IEBACiAuXCIKIC5cIiAkRnJlZUJTRDogc3JjL3NoYXJlL21hbi9tYW40L3NwbGFz aC40LHYgMS4yOC4xMC4xLjIuMSAyMDA5LzEwLzI1IDAxOjEwOjI5IGtlbnNtaXRoIEV4cCAkCiAu XCIKLS5EZCBKYW51YXJ5IDE1LCAyMDA2CisuRGQgSmFudWFyeSAzMCwgMjAxMAogLkR0IFNQTEFT SCA0CiAuT3MKIC5TaCBOQU1FCkBAIC03NCw2ICs3NCwxMyBAQAogWlNvZnQgUENYIGRlY29kZXIu CiBUaGlzIGRlY29kZXIgY3VycmVudGx5IG9ubHkgc3VwcG9ydHMgdmVyc2lvbiA1IDgtYnBwIHNp bmdsZS1wbGFuZQogaW1hZ2VzLgorLkl0IFBhIHNwbGFzaF90eHQua28KK1RoZURyYXcgYmluYXJ5 IEFTQ0lJIGRyYXdpbmcgZmlsZSBkZWNvZGVyLgorRGlzcGxheXMgYSB0ZXh0LW1vZGUgODB4MjUg QVNDSUkgZHJhd2luZywgc3VjaCBhcyB0aGF0IHByb2R1Y2VkIGJ5Cit0aGUgQmluYXJ5IHNhdmUg Zm9ybWF0IGluIFRoZURyYXcuIFRoaXMgZm9ybWF0IGNvbnNpc3RzIG9mIGEgc2VxdWVuY2UKK29m IHR3byBieXRlIHBhaXJzIHJlcHJlc2VudGluZyB0aGUgODB4MjUgZGlzcGxheSwgd2hlcmUgdGhl IGZpcnN0IGJ5dGUKK2lzIHRoZSBBU0NJSSBjaGFyYWN0ZXIgdG8gZHJhdyBhbmQgdGhlIHNlY29u ZCBieXRlIGluZGljYXRlcyB0aGUKK2NvbG9ycy9hdHRyaWJ1dGVzIHRvIHVzZSB3aGVuIGRyYXdp bmcgdGhlIGNoYXJhY3Rlci4KIC5FbAogLlBwCiBUaGUKQEAgLTIxNCw2ICsyMjEsMTYgQEAKIG5l Y2Vzc2FyeSB0byBsb2FkIHRoZSBWRVNBIG1vZHVsZS4KIEp1c3QgbG9hZCB0aGUgYml0bWFwIGZp bGUgYW5kIHRoZSBzcGxhc2ggZGVjb2RlciBtb2R1bGUgYXMgaW4gdGhlCiBmaXJzdCBleGFtcGxl IGFib3ZlLgorLlBwCitUbyBsb2FkIGEgYmluYXJ5IEFTQ0lJIGRyYXdpbmcgYW5kIGRpc3BsYXkg dGhpcyB3aGlsZSBib290aW5nLCBpbmNsdWRlIHRoZQorZm9sbG93aW5nIGludG8geW91cgorLlBh IC9ib290L2xvYWRlci5jb25mCis6CisuQmQgLWxpdGVyYWwgLW9mZnNldCBpbmRlbnQKK3NwbGFz aF90eHRfbG9hZD0iWUVTIgorYml0bWFwX2xvYWQ9IllFUyIKK2JpdG1hcF9uYW1lPSIvYm9vdC9z cGxhc2guYmluIgorLkVkCiAuXCIuU2ggRElBR05PU1RJQ1MKIC5TaCBDQVZFQVRTCiBCb3RoIHRo ZSBzcGxhc2ggc2NyZWVuIGFuZCB0aGUgc2NyZWVuIHNhdmVyIHdvcmsgd2l0aApAQCAtMjUxLDYg KzI2OCwxNSBAQAogYmFzZWQgb24gdGhlCiAuUGEgc3BsYXNoX2JtcAogY29kZS4KK1RoZQorLlBh IHNwbGFzaF90eHQKK21vZHVsZSB3YXMgd3JpdHRlbiBieQorLkFuIEFudG9ueSBNYXdlciBBcSBh bnRvbnlAbWF3ZXIub3JnCitiYXNlZCBvbiB0aGUKKy5QYSBzcGxhc2hfYm1wCitjb2RlLCB3aXRo IHNvbWUgYWRkaXRpb25hbCBpbnNwaXJhdGlvbiBmcm9tIHRoZQorLlBhIGRhZW1vbl9zYXZlcgor Y29kZS4KIC5TaCBCVUdTCiBJZiB5b3UgbG9hZCBhIHNjcmVlbiBzYXZlciB3aGlsZSBhbm90aGVy IHNjcmVlbiBzYXZlciBoYXMgYWxyZWFkeQogYmVlbiBsb2FkZWQsIHRoZSBmaXJzdCBzY3JlZW4g c2F2ZXIgd2lsbCBub3QgYmUgYXV0b21hdGljYWxseSB1bmxvYWRlZAo= --000e0cd10562dffc18047e4f6a4a-- From owner-freebsd-stable@FreeBSD.ORG Fri Jan 29 16:31:20 2010 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AFE63106566B for ; Fri, 29 Jan 2010 16:31:20 +0000 (UTC) (envelope-from rnodal@gmail.com) Received: from mail-ew0-f211.google.com (mail-ew0-f211.google.com [209.85.219.211]) by mx1.freebsd.org (Postfix) with ESMTP id 4640C8FC08 for ; Fri, 29 Jan 2010 16:31:19 +0000 (UTC) Received: by ewy3 with SMTP id 3so1769237ewy.13 for ; Fri, 29 Jan 2010 08:31:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :from:date:message-id:subject:to:content-type; bh=zTiYDOffRVArSnQbjQbKfPCmT3Rtovrmxqd0McMGj1c=; b=DW7FcccL5ZuRspT/d5nt6RDGXBhDA4AX1Hg4Hewz4zJafMUIlSEGCrIdP73sL9nwln MBab+iTsrA2cb8tbauvsedwIA5itYIhbGzFhx9kqmvVOhNKtvZhZaD0NEsgVPOtuWjip oGIuc0DIrDI/tOYhREv51m3Hp8Pf+eBpUgVEs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type; b=r4W4A3rhVltT8o1JOhgE3+A48SyX/zH+NgIa7CXCt/o13o8yOE8OnuX941GVarciRS Qg3Pnz/QoEyQsC+vZzBlx5hCIt+E29WO6hPN5xwZEgYgmTY3ykUhhY5F1so+g0UP2xls GHqjVUbAKvEQUJn0RZ0aPOUChuHCguDHsbEgQ= MIME-Version: 1.0 Received: by 10.213.110.11 with SMTP id l11mr967685ebp.20.1264780968201; Fri, 29 Jan 2010 08:02:48 -0800 (PST) In-Reply-To: References: From: Roger Date: Fri, 29 Jan 2010 11:02:28 -0500 Message-ID: <9d972bed1001290802v3fc4a7f6r692829a75017af1a@mail.gmail.com> To: stable@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Cc: Subject: Re: [patch] New splash_txt module - support for ASCII splash(4) boot screens X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jan 2010 16:31:20 -0000 Thank you for this. This is awesome! From owner-freebsd-stable@FreeBSD.ORG Fri Jan 29 17:45:44 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1427F1065670 for ; Fri, 29 Jan 2010 17:45:44 +0000 (UTC) (envelope-from jfvogel@gmail.com) Received: from mail-ew0-f211.google.com (mail-ew0-f211.google.com [209.85.219.211]) by mx1.freebsd.org (Postfix) with ESMTP id 91B908FC13 for ; Fri, 29 Jan 2010 17:45:43 +0000 (UTC) Received: by ewy3 with SMTP id 3so1847405ewy.13 for ; Fri, 29 Jan 2010 09:45:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type; bh=IQdiaEFeo45n3q2GTJu8V2Z5K8wvjFVBvmTodofRGgI=; b=Q/zWjQdGApXIV2p1ekNaZMiEuuxbdNhx35/cE696I8+VomZpLAdh7z0T6H4NHTy/f9 8qgcF9vG0FJchVX6FxcTHkBSkCo7pKiE11brR71/U/dDzIhTdr9YcX/ha4Ur1HGgeMXs /Zc0Bmhsp6swbLytPgEK8s6zPAO+dvLHdfkGE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=oP9XZdG61Lv/abWpmpAElsvWPtnePB2wQDTl+VEi828Znx0r1QIz6Y849RnhJERA9o XqnCAbAOPGPa/nTR/mv97en0QRDhgt8o4RKVw4pA9X5GMCUm6BCy++heWnIG9poVv/xj vEcKpev9QYjDhYGNGmOriqh2E2+JDpkYbY1gI= MIME-Version: 1.0 Received: by 10.216.87.67 with SMTP id x45mr755050wee.18.1264787142287; Fri, 29 Jan 2010 09:45:42 -0800 (PST) In-Reply-To: <20100129133824.GE23403@goofy.tols.org> References: <147432021001242047k659a26d0s44b35164920aeb74@mail.gmail.com> <147432021001250825p202914a7ka5a2c1d28d96bac3@mail.gmail.com> <20100125182257.GG1187@michelle.cdnetworks.com> <147432021001251038r69393ab3m1a797e58f9fa905a@mail.gmail.com> <02307620-ECDC-4E8B-A5B1-FF8491E226C4@nokia.com> <33c6b0bc1001252031k508426bfh25fad65e9223d87@mail.gmail.com> <147432021001260900p60ed1804t97392d2dff5cd244@mail.gmail.com> <20100128121701.GB9408@goofy.tols.org> <2a41acea1001281116k7d14cc26x120f9960ab14d19d@mail.gmail.com> <20100129133824.GE23403@goofy.tols.org> Date: Fri, 29 Jan 2010 09:45:42 -0800 Message-ID: <2a41acea1001290945m77e9ae18if927716d82e50b2f@mail.gmail.com> From: Jack Vogel To: FreeBSD STABLE Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Re: em interface slow down on 8.0R X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 29 Jan 2010 17:45:44 -0000 No need, I set it up and tried it, and I was right, it does not fail if that routine is not used. The interesting thing is that the igb driver, which has the same code, works fine. In any case, I'm hot on the track of this and hope I can figure it out today. Jack On Fri, Jan 29, 2010 at 5:38 AM, Marco van Tol wrote: > On Thu, Jan 28, 2010 at 11:16:02AM -0800, Jack Vogel wrote: > > I am investigating it, and have a suspicion about what's going on, you > can > > assist in verifying my suspicion. In if_em.c search for > "em_setup_vlan_hw", > > you will find a compile time option that uses that only if > FreeBSD_version > > is > 700029, hack the code however you wish so that it uses the OLD way > > (ie that it never calls em_setup_vlan_hw_support()) and see if that makes > > the issue disappear. > > Oh good, I will try that and let you know about the result first chance I > get. Should be days rather then hours, but I'll make it asap. > > > If you have any problems or questions email me directly. > > Will do, thanks! > > Marco > > > > > > On Thu, Jan 28, 2010 at 4:17 AM, Marco van Tol wrote: > > > > > On Tue, Jan 26, 2010 at 09:00:35AM -0800, Nick Rogers wrote: > > > > Is it advisable to patch 8.0-RELEASE kernel sources with the latest > > > > (CURRENT) em driver (i.e., src/sys/dev/e1000)? It looks like there > are > > > some > > > > updates to the driver since 8.0-RELEASE that may fix some problems? > > > > > > While on the em subject, forgive me if I mail this to the inappropriate > > > place, but is there any ETA on progress for bug kern/141646? > > > > > > I'm currently suffering from it and would be willing to provide needed > > > assistance for fixing it. > > > > > > Thank you very much in advance, > > > > > > Marco van Tol > > -- > Better to remain silent and be thought a fool > than to speak out and remove all doubt. > - Abraham Lincoln > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" > From owner-freebsd-stable@FreeBSD.ORG Fri Jan 29 18:13:47 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2F6121065670 for ; Fri, 29 Jan 2010 18:13:47 +0000 (UTC) (envelope-from marco@goofy.tols.org) Received: from goofy.tols.org (goofy.tols.org [83.163.60.200]) by mx1.freebsd.org (Postfix) with ESMTP id B85518FC17 for ; Fri, 29 Jan 2010 18:13:46 +0000 (UTC) Received: from goofy.tols.org (localhost [127.0.0.1]) by goofy.tols.org (8.14.3/8.14.3) with ESMTP id o0TIDihW026908 for ; Fri, 29 Jan 2010 18:13:44 GMT (envelope-from marco@goofy.tols.org) Received: (from marco@localhost) by goofy.tols.org (8.14.3/8.14.3/Submit) id o0TIDijb026907 for freebsd-stable@freebsd.org; Fri, 29 Jan 2010 18:13:44 GMT (envelope-from marco) Date: Fri, 29 Jan 2010 18:13:44 +0000 From: Marco van Tol To: FreeBSD STABLE Message-ID: <20100129181344.GH23403@goofy.tols.org> Mail-Followup-To: FreeBSD STABLE References: <147432021001250825p202914a7ka5a2c1d28d96bac3@mail.gmail.com> <20100125182257.GG1187@michelle.cdnetworks.com> <147432021001251038r69393ab3m1a797e58f9fa905a@mail.gmail.com> <02307620-ECDC-4E8B-A5B1-FF8491E226C4@nokia.com> <33c6b0bc1001252031k508426bfh25fad65e9223d87@mail.gmail.com> <147432021001260900p60ed1804t97392d2dff5cd244@mail.gmail.com> <20100128121701.GB9408@goofy.tols.org> <2a41acea1001281116k7d14cc26x120f9960ab14d19d@mail.gmail.com> <20100129133824.GE23403@goofy.tols.org> <2a41acea1001290945m77e9ae18if927716d82e50b2f@mail.gmail.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="oyUTqETQ0mS9luUI" Content-Disposition: inline In-Reply-To: <2a41acea1001290945m77e9ae18if927716d82e50b2f@mail.gmail.com> User-Agent: Mutt/1.4.2.3i Subject: Re: em interface slow down on 8.0R X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 29 Jan 2010 18:13:47 -0000 --oyUTqETQ0mS9luUI Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Fri, Jan 29, 2010 at 09:45:42AM -0800, Jack Vogel wrote: > No need, I set it up and tried it, and I was right, it does not fail if that > routine is not used. The interesting thing is that the igb driver, which > has the same code, works fine. > > In any case, I'm hot on the track of this and hope I can figure it out > today. Ah nice, I found a hole in time to try it as well. I just rebuild a kernel and rebooted. During the reboot I found what you write above. :) Anyways, the attached patch makes it work indeed as you found yourself as well in the mean time. :-) I tried just deleting the call itself at first, but the module is compiled with warnings treated as errors and barfs about a defined but unused function. So in the patch you'll find the entire function removed. Let me know about anything else I can do. I don't have the necessary test equipment at home, so normally I'll need to find a time window to test things. But I'm more then willing to. The version I patch is the following by the way, from 8.0-RELEASE-p2: /*$FreeBSD: src/sys/dev/e1000/if_em.c,v 1.21.2.3.2.1 2009/10/25 01:10:29 kensmith Exp $*/ Thanks so far! Marco -- "Van Duitsers heb je pas gewonnen als ze met de bus de stad uit zijn." - Youp van 't Hek --oyUTqETQ0mS9luUI Content-Type: text/x-diff; charset=us-ascii Content-Disposition: attachment; filename="if_em.c.patch" --- sys/dev/e1000/if_em.c.orig 2010-01-29 18:20:46.000000000 +0100 +++ sys/dev/e1000/if_em.c 2010-01-29 18:26:59.000000000 +0100 @@ -289,7 +289,6 @@ #if __FreeBSD_version >= 700029 static void em_register_vlan(void *, struct ifnet *, u16); static void em_unregister_vlan(void *, struct ifnet *, u16); -static void em_setup_vlan_hw_support(struct adapter *); #endif static int em_xmit(struct adapter *, struct mbuf **); static void em_smartspeed(struct adapter *); @@ -1535,17 +1534,12 @@ /* Setup VLAN support, basic and offload if available */ E1000_WRITE_REG(&adapter->hw, E1000_VET, ETHERTYPE_VLAN); -#if __FreeBSD_version < 700029 if (ifp->if_capenable & IFCAP_VLAN_HWTAGGING) { u32 ctrl; ctrl = E1000_READ_REG(&adapter->hw, E1000_CTRL); ctrl |= E1000_CTRL_VME; E1000_WRITE_REG(&adapter->hw, E1000_CTRL, ctrl); } -#else - /* Use real VLAN Filter support */ - em_setup_vlan_hw_support(adapter); -#endif /* Set hardware offload abilities */ ifp->if_hwassist = 0; @@ -4762,44 +4756,6 @@ em_init(adapter); } -static void -em_setup_vlan_hw_support(struct adapter *adapter) -{ - struct e1000_hw *hw = &adapter->hw; - u32 reg; - - /* - ** We get here thru init_locked, meaning - ** a soft reset, this has already cleared - ** the VFTA and other state, so if there - ** have been no vlan's registered do nothing. - */ - if (adapter->num_vlans == 0) - return; - - /* - ** A soft reset zero's out the VFTA, so - ** we need to repopulate it now. - */ - for (int i = 0; i < EM_VFTA_SIZE; i++) - if (em_shadow_vfta[i] != 0) - E1000_WRITE_REG_ARRAY(hw, E1000_VFTA, - i, em_shadow_vfta[i]); - - reg = E1000_READ_REG(hw, E1000_CTRL); - reg |= E1000_CTRL_VME; - E1000_WRITE_REG(hw, E1000_CTRL, reg); - - /* Enable the Filter Table */ - reg = E1000_READ_REG(hw, E1000_RCTL); - reg &= ~E1000_RCTL_CFIEN; - reg |= E1000_RCTL_VFE; - E1000_WRITE_REG(hw, E1000_RCTL, reg); - - /* Update the frame size */ - E1000_WRITE_REG(&adapter->hw, E1000_RLPML, - adapter->max_frame_size + VLAN_TAG_SIZE); -} #endif static void --oyUTqETQ0mS9luUI-- From owner-freebsd-stable@FreeBSD.ORG Fri Jan 29 18:30:13 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1D05B10656B1 for ; Fri, 29 Jan 2010 18:30:13 +0000 (UTC) (envelope-from David.Boyd@insightbb.com) Received: from mxsf10.insightbb.com (mxsf10.insightbb.com [74.128.0.92]) by mx1.freebsd.org (Postfix) with ESMTP id DD4C38FC13 for ; Fri, 29 Jan 2010 18:30:12 +0000 (UTC) X-IronPort-AV: E=Sophos;i="4.49,370,1262581200"; d="scan'208";a="34745665" Received: from unknown (HELO asav03.insightbb.com) ([172.31.249.123]) by mxsf10.insightbb.com with ESMTP; 29 Jan 2010 13:30:11 -0500 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApsEALy3YktKgYh2/2dsb2JhbACJCtFWCoQ4BA X-IronPort-AV: E=Sophos;i="4.49,370,1262581200"; d="scan'208";a="122602566" Received: from 74-129-136-118.dhcp.insightbb.com (HELO sneezy) ([74.129.136.118]) by asav03.insightbb.com with SMTP; 29 Jan 2010 13:30:11 -0500 From: "David Boyd" To: Date: Fri, 29 Jan 2010 13:30:11 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 Importance: Normal Subject: make release fails if ghostscript8-8.70 is installed X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 29 Jan 2010 18:30:13 -0000 When attempting make release (7.3-PRERELEASE or 7.2-RELEASE or 8.0-RELEASE-p2) and ghostscript8-8.70 is installed on the build machine the following error occurs: ===> ghostscript8-nox11-8.70 conflicts with installed package(s): ghostscript8-8.70 They install files into the same place. Please remote them first with pkg_delete(1). *** Error code 1 Stop in /u/release/usr/ports/print/ghostscript8-nox11. *** Error code 1 Stop in /u/release/usr/ports/textproc/docproj. *** Error code 1 Stop in /var/cvsup/usr/src/release. *** Error code 1 Stop in /var/cvsup/usr/src/release. I can work around this by defining NODOC in /etc/make.conf or by deleting the ghostscipt8 package before running make release. I never had this problem in previous builds (6.4-RELEASE and 7.1-RELEASE). Is this expected/normal? Thanks. From owner-freebsd-stable@FreeBSD.ORG Fri Jan 29 19:46:48 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8C17A1065695 for ; Fri, 29 Jan 2010 19:46:48 +0000 (UTC) (envelope-from jonc@chen.org.nz) Received: from chen.org.nz (ip-58-28-152-174.static-xdsl.xnet.co.nz [58.28.152.174]) by mx1.freebsd.org (Postfix) with ESMTP id 2EE6A8FC19 for ; Fri, 29 Jan 2010 19:46:47 +0000 (UTC) Received: by chen.org.nz (Postfix, from userid 1000) id 25A71E043B; Sat, 30 Jan 2010 08:46:46 +1300 (NZDT) Date: Sat, 30 Jan 2010 08:46:46 +1300 From: Jonathan Chen To: freebsd-stable@freebsd.org Message-ID: <20100129194646.GA3178@osiris.chen.org.nz> References: <1263723781.00208012.1263711003@10.7.7.3> <4B52E634.8010609@FreeBSD.org> <20100117182008.GA3224@osiris.chen.org.nz> <20100118041148.GA3764@osiris.chen.org.nz> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20100118041148.GA3764@osiris.chen.org.nz> User-Agent: Mutt/1.4.2.3i Subject: Re: Drive light on all the time on 8-STABLE. X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jan 2010 19:46:48 -0000 On Mon, Jan 18, 2010 at 05:11:48PM +1300, Jonathan Chen wrote: [...] > I've rebooted the box a few times, and have observed that the drive > LED flickers normally up until: > > > atapci0: port 0xff00-0xff07,0xfe00-0xfe03,0xfd00-0xfd07,0xfc00-0xfc03,0xfb00-0xfb0f mem 0xfe02f000-0xfe02f3ff irq 22 at device 18.0 on pci0 > > atapci0: [ITHREAD] > > atapci0: AHCI v1.10 controller with 4 3Gbps ports, PM supported > > ata2: on atapci0 > > ata2: port is not ready (timeout 0ms) tfd = 000001d0 > > ata2: software reset clear timeout > > ata2: [ITHREAD] > > At which point after the software reset, the drive LED stays solidly > on from then onwards. Just for the archives: I've switched over to using AHCI, and this problem has now disappeared. Cheers. -- Jonathan Chen ---------------------------------------------------------------------- "Irrationality is the square root of all evil" - Douglas Hofstadter From owner-freebsd-stable@FreeBSD.ORG Fri Jan 29 20:28:28 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6764A106566B for ; Fri, 29 Jan 2010 20:28:28 +0000 (UTC) (envelope-from gperez@entel.upc.edu) Received: from dash.upc.es (dash.upc.es [147.83.2.50]) by mx1.freebsd.org (Postfix) with ESMTP id E5D6B8FC0A for ; Fri, 29 Jan 2010 20:28:27 +0000 (UTC) Received: from ackerman2.upc.es (ackerman2.upc.es [147.83.2.244]) by dash.upc.es (8.14.1/8.13.1) with ESMTP id o0TBbsn2022110 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Fri, 29 Jan 2010 12:37:55 +0100 Received: from [147.83.40.234] ([147.83.40.234]) (authenticated bits=0) by ackerman2.upc.es (8.13.8/8.13.8) with ESMTP id o0TBbscb032399 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 29 Jan 2010 12:37:54 +0100 Message-ID: <4B62C890.3020802@entel.upc.edu> Date: Fri, 29 Jan 2010 12:37:52 +0100 From: =?UTF-8?B?R3VzdGF1IFDDqXJleg==?= User-Agent: Thunderbird 2.0.0.23 (X11/20100112) MIME-Version: 1.0 To: freebsd-stable@freebsd.org X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.63 on 147.83.2.244 X-Mail-Scanned: Criba 2.0 + Clamd X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0 (dash.upc.es [147.83.2.50]); Fri, 29 Jan 2010 12:37:55 +0100 (CET) Subject: bsnmpd returns incorrect hrProcessorLoad values X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jan 2010 20:28:28 -0000 Hi, I'm using cacti to monitor some servers running FBSD. I was using 7.2 with SCHED_4BSD. With this configuration : bsnmpd+bsnmp-ucd was returning right values for the cores' load. I recently updated the servers (via csup) to RELENG_8 and bsnmpd is returning negative values for the cores' load. If I try something like in a 4-core system : snmpwalk -v 2c -c community server .1.3.6.1.2.1.25.3.3.1 what I get is : .1.3.6.1.2.1.25.3.3.1.1.6 = OID: .0.0 .1.3.6.1.2.1.25.3.3.1.1.10 = OID: .0.0 .1.3.6.1.2.1.25.3.3.1.1.14 = OID: .0.0 .1.3.6.1.2.1.25.3.3.1.1.18 = OID: .0.0 .1.3.6.1.2.1.25.3.3.1.2.6 = INTEGER: -182 .1.3.6.1.2.1.25.3.3.1.2.10 = INTEGER: -182 .1.3.6.1.2.1.25.3.3.1.2.14 = INTEGER: -182 .1.3.6.1.2.1.25.3.3.1.2.18 = INTEGER: -182 I tried and old bsnmpd-ucd (0.2.1, works fine in a 7,2 system) with a 8.0 system. Same wrong results. And it seems bsnmpd in /usr/src/contrib has not changed between 7.2 and 8.0. Any ideas ? I'm not an expert, but with tcpdump I see different results. Against an old 7.2 system, the field related to each core load gives the right value. Instead, against and 8.0 system, those field show (in hex) values like fd 4b. What I don't know is how bsdnmp-ucb retrives those values and how it construct the udp response packet. Gus -- PGP KEY : http://www-entel.upc.edu/gus/gus.asc From owner-freebsd-stable@FreeBSD.ORG Fri Jan 29 20:59:41 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2490B1065679 for ; Fri, 29 Jan 2010 20:59:41 +0000 (UTC) (envelope-from to.my.trociny@gmail.com) Received: from mail-fx0-f227.google.com (mail-fx0-f227.google.com [209.85.220.227]) by mx1.freebsd.org (Postfix) with ESMTP id A67278FC1D for ; Fri, 29 Jan 2010 20:59:40 +0000 (UTC) Received: by fxm27 with SMTP id 27so735038fxm.3 for ; Fri, 29 Jan 2010 12:59:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:to:cc:subject:references :organization:from:date:in-reply-to:message-id:user-agent :mime-version:content-type:content-transfer-encoding; bh=9wqwXrxyAzkna5dsTuTG9I6iHxmKL1UfH1swP4aAMkY=; b=Y1m8clUmkhglIUNHM3XQLa89KF22+dGHwIQLmZn/sy5HQJHouFzNXPSAZzMqjkK+/5 jZVhJFWeR+OHS/5KCHVCkTZPFeOV3ucYfulD+ergm0PA6nX6Lqru6RcQCwI7S9b9xJLU +vQ3OPpJxKm0H/YhA5LHEnoq8SeVZNolUFb/w= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=to:cc:subject:references:organization:from:date:in-reply-to :message-id:user-agent:mime-version:content-type :content-transfer-encoding; b=xAdX8D4fiFyYqiruuvPjmqh0ktObhT1edsVLBpWI8eyYEeezYYyugiPQB7fZTwwWB/ iBSsLzb3dwv/CgVs2ddDlCcaawzryNt5Yk3g2JP0WGLUxjQHztU/p5YGwsB8gkdH7RtR 3Uehg5TgeoCJFovmAuHiUncKsCNmyV0O+4DrA= Received: by 10.102.17.4 with SMTP id 4mr758323muq.4.1264798779226; Fri, 29 Jan 2010 12:59:39 -0800 (PST) Received: from localhost ([95.69.163.7]) by mx.google.com with ESMTPS id w5sm10795276mue.52.2010.01.29.12.59.37 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 29 Jan 2010 12:59:38 -0800 (PST) To: Gustau =?iso-8859-1?Q?P=E9rez?= References: <4B62C890.3020802@entel.upc.edu> Organization: TOA Ukraine From: Mikolaj Golub Date: Fri, 29 Jan 2010 22:59:36 +0200 In-Reply-To: <4B62C890.3020802@entel.upc.edu> ("Gustau =?iso-8859-1?Q?P=E9?= =?iso-8859-1?Q?rez=22's?= message of "Fri\, 29 Jan 2010 12\:37\:52 +0100") Message-ID: <86ljfg7hl3.fsf@kopusha.onet> User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.3 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-stable@freebsd.org Subject: Re: bsnmpd returns incorrect hrProcessorLoad values X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jan 2010 20:59:41 -0000 On Fri, 29 Jan 2010 12:37:52 +0100 Gustau P=E9rez wrote: > Hi, > > I'm using cacti to monitor some servers running FBSD. I was using 7.2 > with SCHED_4BSD. With this configuration : bsnmpd+bsnmp-ucd was > returning right values for the cores' load. > > I recently updated the servers (via csup) to RELENG_8 and bsnmpd is > returning negative values for the cores' load. If I try something like > in a 4-core system : > > snmpwalk -v 2c -c community server .1.3.6.1.2.1.25.3.3.1 > > what I get is : > > .1.3.6.1.2.1.25.3.3.1.1.6 =3D OID: .0.0 > .1.3.6.1.2.1.25.3.3.1.1.10 =3D OID: .0.0 > .1.3.6.1.2.1.25.3.3.1.1.14 =3D OID: .0.0 > .1.3.6.1.2.1.25.3.3.1.1.18 =3D OID: .0.0 > .1.3.6.1.2.1.25.3.3.1.2.6 =3D INTEGER: -182 > .1.3.6.1.2.1.25.3.3.1.2.10 =3D INTEGER: -182 > .1.3.6.1.2.1.25.3.3.1.2.14 =3D INTEGER: -182 > .1.3.6.1.2.1.25.3.3.1.2.18 =3D INTEGER: -182 > > I tried and old bsnmpd-ucd (0.2.1, works fine in a 7,2 system) with a > 8.0 system. Same wrong results. And it seems bsnmpd in /usr/src/contrib > has not changed between 7.2 and 8.0. > > Any ideas ? I'm not an expert, but with tcpdump I see different > results. Against an old 7.2 system, the field related to each core load > gives the right value. Instead, against and 8.0 system, those field show > (in hex) values like fd 4b. What I don't know is how bsdnmp-ucb retrives > those values and how it construct the udp response packet. bsnmpd-ucd has nothing to do with HOST-RESOURCES-MIB. These mibs are provid= ed by snmp_hostres(3) module (/usr/lib/snmp_hostres.so). So something wrong is there (I suppose it is not in sync with some recent changes in kernel or libkvm). --=20 Mikolaj Golub From owner-freebsd-stable@FreeBSD.ORG Fri Jan 29 22:30:57 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D25E2106568F for ; Fri, 29 Jan 2010 22:30:57 +0000 (UTC) (envelope-from gperez@entel.upc.edu) Received: from violet.upc.es (violet.upc.es [147.83.2.51]) by mx1.freebsd.org (Postfix) with ESMTP id 5968A8FC0C for ; Fri, 29 Jan 2010 22:30:56 +0000 (UTC) Received: from ackerman2.upc.es (ackerman2.upc.es [147.83.2.244]) by violet.upc.es (8.14.1/8.13.1) with ESMTP id o0TMUtxA030859 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 29 Jan 2010 23:30:55 +0100 Received: from [192.168.100.200] (211.Red-79-145-207.dynamicIP.rima-tde.net [79.145.207.211]) (authenticated bits=0) by ackerman2.upc.es (8.13.8/8.13.8) with ESMTP id o0TMUoaq004442 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 29 Jan 2010 23:30:54 +0100 Message-ID: <4B636196.9030101@entel.upc.edu> Date: Fri, 29 Jan 2010 23:30:46 +0100 From: =?ISO-8859-1?Q?Gustau_P=E9rez?= User-Agent: Thunderbird 2.0.0.23 (X11/20100112) MIME-Version: 1.0 To: Mikolaj Golub References: <4B62C890.3020802@entel.upc.edu> <86ljfg7hl3.fsf@kopusha.onet> In-Reply-To: <86ljfg7hl3.fsf@kopusha.onet> X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Scanned-By: MIMEDefang 2.63 on 147.83.2.244 X-Mail-Scanned: Criba 2.0 + Clamd X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0 (violet.upc.es [147.83.2.51]); Fri, 29 Jan 2010 23:30:55 +0100 (CET) Cc: freebsd-stable@freebsd.org Subject: Re: bsnmpd returns incorrect hrProcessorLoad values X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jan 2010 22:30:57 -0000 En/na Mikolaj Golub ha escrit: > On Fri, 29 Jan 2010 12:37:52 +0100 Gustau Pérez wrote: > > >> Hi, >> >> I'm using cacti to monitor some servers running FBSD. I was using 7.2 >> with SCHED_4BSD. With this configuration : bsnmpd+bsnmp-ucd was >> returning right values for the cores' load. >> >> I recently updated the servers (via csup) to RELENG_8 and bsnmpd is >> returning negative values for the cores' load. If I try something like >> in a 4-core system : >> >> snmpwalk -v 2c -c community server .1.3.6.1.2.1.25.3.3.1 >> >> what I get is : >> >> .1.3.6.1.2.1.25.3.3.1.1.6 = OID: .0.0 >> .1.3.6.1.2.1.25.3.3.1.1.10 = OID: .0.0 >> .1.3.6.1.2.1.25.3.3.1.1.14 = OID: .0.0 >> .1.3.6.1.2.1.25.3.3.1.1.18 = OID: .0.0 >> .1.3.6.1.2.1.25.3.3.1.2.6 = INTEGER: -182 >> .1.3.6.1.2.1.25.3.3.1.2.10 = INTEGER: -182 >> .1.3.6.1.2.1.25.3.3.1.2.14 = INTEGER: -182 >> .1.3.6.1.2.1.25.3.3.1.2.18 = INTEGER: -182 >> >> I tried and old bsnmpd-ucd (0.2.1, works fine in a 7,2 system) with a >> 8.0 system. Same wrong results. And it seems bsnmpd in /usr/src/contrib >> has not changed between 7.2 and 8.0. >> >> Any ideas ? I'm not an expert, but with tcpdump I see different >> results. Against an old 7.2 system, the field related to each core load >> gives the right value. Instead, against and 8.0 system, those field show >> (in hex) values like fd 4b. What I don't know is how bsdnmp-ucb retrives >> those values and how it construct the udp response packet. >> > > bsnmpd-ucd has nothing to do with HOST-RESOURCES-MIB. These mibs are provided > by snmp_hostres(3) module (/usr/lib/snmp_hostres.so). So something wrong is > there (I suppose it is not in sync with some recent changes in kernel or > libkvm). > > I thought the same with a grep -r in the bsnmpd-ucd port. But If I deinstall bsnmpd-ucb then I can't check those mibs. Anyway, changing the scheduler to SCHED_ULE gives a 100% for all processors. Maybe that can be a hint. Regards, Gus -- PGP KEY : http://www-entel.upc.edu/gus/gus.asc From owner-freebsd-stable@FreeBSD.ORG Sat Jan 30 00:42:39 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 87985106568F for ; Sat, 30 Jan 2010 00:42:39 +0000 (UTC) (envelope-from russell.yount@gmail.com) Received: from mail-vw0-f54.google.com (mail-vw0-f54.google.com [209.85.212.54]) by mx1.freebsd.org (Postfix) with ESMTP id 3CD328FC19 for ; Sat, 30 Jan 2010 00:42:38 +0000 (UTC) Received: by vws11 with SMTP id 11so219162vws.13 for ; Fri, 29 Jan 2010 16:42:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:cc:content-type; bh=QXoCmPDrcWi2jiM+aTgUKdPXS+Z4V4cKmMpWfxrk4CY=; b=IJBY00f6eTn+RsTVCuEdF7aRcbhfcXNKq8FEFioKAE3xjRFwQbmFCnhtNwQwTm62/H LubphgQcxSG9KR0BtKoAxSD5wFjqS/WM3YZhREjuCyevaId2dCQ2KkyzE34bYuqcat+U D2tawfEg3miaAVzT7H/pULsIFOVln/+YndWdA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:cc:content-type; b=iyjQWfX5mXGmIGMN2xgQSVWm9OEWI1J2J01OBrBhueSco7Jlu6mZBFsebFlyNO1i6l uV8XRAXePYst2QnHnFlRh8Jje6/ha1t6Z8TH2yVRZfx4DUUbPbW/EgkN2piJ18vGIyaP 4yPMap0zMUjRqjFrdYfsiIo5Yb3dojc3drjWQ= MIME-Version: 1.0 Received: by 10.220.127.96 with SMTP id f32mr1501987vcs.29.1264812158100; Fri, 29 Jan 2010 16:42:38 -0800 (PST) Date: Fri, 29 Jan 2010 19:42:38 -0500 Message-ID: From: Russell Yount To: freebsd-stable@freebsd.org Content-Type: multipart/mixed; boundary=0016e68ee02e64278b047e57073e X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Subject: ath(4) PATCH X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 30 Jan 2010 00:42:39 -0000 --0016e68ee02e64278b047e57073e Content-Type: text/plain; charset=ISO-8859-1 The attached patch for 8.0-STABLE enables multicast key search capability for devices which support it in the ath(4) driver. This fixes the problem of corrupted multicast traffic when more than one hostap VAP is configured on a device. You can tell if your ath(4) device supports this capability by looking at the kernel log for "kernel: ath0: using multicast key search" as the device is attached. Please test if you are using the ath(4) driver. I only have AR5212 chipsets to test with and would like to see this included in 8.0-STABLE and 9. Thanks -Russ --0016e68ee02e64278b047e57073e Content-Type: application/octet-stream; name="ath_multicast_key_search.patch" Content-Disposition: attachment; filename="ath_multicast_key_search.patch" Content-Transfer-Encoding: base64 X-Attachment-Id: f_g51ne59u0 LS0tIHNyYy9zeXMvZGV2L2F0aC9pZl9hdGh2YXIuaC5vcmlnCTIwMDktMDgtMDMgMDQ6MTM6MDYu MDAwMDAwMDAwIC0wNDAwCisrKyBzcmMvc3lzL2Rldi9hdGgvaWZfYXRodmFyLmgJMjAxMC0wMS0y NCAxNjozMTozNS4wMDAwMDAwMDAgLTA1MDAKQEAgLTU4MCwxNCArNTgwLDEyIEBACiAJYXRoX2hh bF9zZXRjYXBhYmlsaXR5KF9haCwgSEFMX0NBUF9UUEMsIDEsIF92LCBOVUxMKQogI2RlZmluZQlh dGhfaGFsX2hhc2J1cnN0aW5nKF9haCkgXAogCShhdGhfaGFsX2dldGNhcGFiaWxpdHkoX2FoLCBI QUxfQ0FQX0JVUlNULCAwLCBOVUxMKSA9PSBIQUxfT0spCi0jaWZkZWYgbm90eWV0CisjZGVmaW5l CWF0aF9oYWxfc2V0bWNhc3RrZXlzZWFyY2goX2FoLCBfdikgXAorCWF0aF9oYWxfc2V0Y2FwYWJp bGl0eShfYWgsIEhBTF9DQVBfTUNBU1RfS0VZU1JDSCwgMCwgX3YsIE5VTEwpCiAjZGVmaW5lCWF0 aF9oYWxfaGFzbWNhc3RrZXlzZWFyY2goX2FoKSBcCiAJKGF0aF9oYWxfZ2V0Y2FwYWJpbGl0eShf YWgsIEhBTF9DQVBfTUNBU1RfS0VZU1JDSCwgMCwgTlVMTCkgPT0gSEFMX09LKQogI2RlZmluZQlh dGhfaGFsX2dldG1jYXN0a2V5c2VhcmNoKF9haCkgXAogCShhdGhfaGFsX2dldGNhcGFiaWxpdHko X2FoLCBIQUxfQ0FQX01DQVNUX0tFWVNSQ0gsIDEsIE5VTEwpID09IEhBTF9PSykKLSNlbHNlCi0j ZGVmaW5lCWF0aF9oYWxfZ2V0bWNhc3RrZXlzZWFyY2goX2FoKQkwCi0jZW5kaWYKICNkZWZpbmUJ YXRoX2hhbF9oYXNmYXN0ZnJhbWVzKF9haCkgXAogCShhdGhfaGFsX2dldGNhcGFiaWxpdHkoX2Fo LCBIQUxfQ0FQX0ZBU1RGUkFNRSwgMCwgTlVMTCkgPT0gSEFMX09LKQogI2RlZmluZQlhdGhfaGFs X2hhc2Jzc2lkbWFzayhfYWgpIFwKLS0tIHNyYy9zeXMvZGV2L2F0aC9pZl9hdGguYy5vcmlnCTIw MDktMDktMDcgMTI6NDE6MTguMDAwMDAwMDAwIC0wNDAwCisrKyBzcmMvc3lzL2Rldi9hdGgvaWZf YXRoLmMJMjAxMC0wMS0yNyAyMDoyNToyOC4wMDAwMDAwMDAgLTA1MDAKQEAgLTYyMSw2ICs2MjEs MTQgQEAKIAkJCXNjLT5zY193bWV0a2lwbWljID0gMTsKIAl9CiAJc2MtPnNjX2hhc2NscmtleSA9 IGF0aF9oYWxfY2lwaGVyc3VwcG9ydGVkKGFoLCBIQUxfQ0lQSEVSX0NMUik7CisJLyoKKwkgKiBp ZiBtdWx0aWNhc3Qga2V5IHNlYXJjaCBpcyBzdXBwb3J0ZWQgYnkgZGV2aWNlIGVuYWJsZSBpdAor CSAqLworCWlmIChhdGhfaGFsX2hhc21jYXN0a2V5c2VhcmNoKHNjLT5zY19haCkpIHsKKwkJaWYg KCFhdGhfaGFsX2dldG1jYXN0a2V5c2VhcmNoKHNjLT5zY19haCkpIHsKKwkJCWF0aF9oYWxfc2V0 bWNhc3RrZXlzZWFyY2goc2MtPnNjX2FoLDEpOworCQl9CisJfQogCXNjLT5zY19tY2FzdGtleSA9 IGF0aF9oYWxfZ2V0bWNhc3RrZXlzZWFyY2goYWgpOwogCS8qCiAJICogTWFyayBrZXkgY2FjaGUg c2xvdHMgYXNzb2NpYXRlZCB3aXRoIGdsb2JhbCBrZXlzCkBAIC0yMjE5LDggKzIyMjcsMTAgQEAK IAkgKiBpdCBwZXJtaXRzIHVzIHRvIHN1cHBvcnQgbXVsdGlwbGUgdXNlcnMgZm9yIGFkaG9jIGFu ZC9vcgogCSAqIG11bHRpLXN0YXRpb24gb3BlcmF0aW9uLgogCSAqLwotCWlmIChrLT53a19rZXlp eCAhPSBJRUVFODAyMTFfS0VZSVhfTk9ORSB8fAkvKiBnbG9iYWwga2V5ICovCi0JICAgICgoay0+ d2tfZmxhZ3MgJiBJRUVFODAyMTFfS0VZX0dST1VQKSAmJiAhc2MtPnNjX21jYXN0a2V5KSkgewor CWlmIChrLT53a19rZXlpeCAhPSBJRUVFODAyMTFfS0VZSVhfTk9ORSkgeworCQkvKgorCQkgKiBv bmx5IGdsb2JhbCBrZXlzIHNob3VsZCBoYXZlIGtleSBpbmRleCBhc3NpZ25lZAorCQkgKi8KIAkJ aWYgKCEoJnZhcC0+aXZfbndfa2V5c1swXSA8PSBrICYmCiAJCSAgICAgIGsgPCAmdmFwLT5pdl9u d19rZXlzW0lFRUU4MDIxMV9XRVBfTktJRF0pKSB7CiAJCQkvKiBzaG91bGQgbm90IGhhcHBlbiAq LwpAQCAtMjIyOSwxMSArMjIzOSwyNCBAQAogCQkJcmV0dXJuIDA7CiAJCX0KIAkJLyoKLQkJICog WFhYIHdlIHByZS1hbGxvY2F0ZSB0aGUgZ2xvYmFsIGtleXMgc28KLQkJICogaGF2ZSBubyB3YXkg dG8gY2hlY2sgaWYgdGhleSd2ZSBhbHJlYWR5IGJlZW4gYWxsb2NhdGVkLgorCQkgKiBpZiBub3Qg b3BlcmF0aW5nIGluIGhvc3RhcCBtb2RlCisJCSAqIG9yIG5vdCBhIGdyb3VwIGtleQorCQkgKiBv ciBkZXZpY2UgZG9lcyBub3Qgc3VwcG9ydCBtdWl0aWNhc3Qga2V5IHNlYXJjaAorCQkgKi8KKwkJ aWYgKHZhcC0+aXZfb3Btb2RlICE9IElFRUU4MDIxMV9NX0hPU1RBUAorCQkgIHx8ICEoay0+d2tf ZmxhZ3MgJiBJRUVFODAyMTFfS0VZX0dST1VQKQorCQkgIHx8ICFzYy0+c2NfbWNhc3RrZXkpIHsK KwkJCS8qCisJCQkgKiBYWFggd2UgcHJlLWFsbG9jYXRlIHRoZSBnbG9iYWwga2V5cyBzbworCQkJ ICogaGF2ZSBubyB3YXkgdG8gY2hlY2sgaWYgdGhleSd2ZSBhbHJlYWR5IGJlZW4gYWxsb2NhdGVk LgorCQkJICovCisJCQkqa2V5aXggPSAqcnhrZXlpeCA9IGsgLSB2YXAtPml2X253X2tleXM7CisJ CQlyZXR1cm4gMTsKKwkJfQorCQkvKgorCQkgKiBncm91cCBrZXkgYW5kIGRldmljZSBzdXBwb3J0 cyBtdWx0aWNhc3Qga2V5IHNlYXJjaAogCQkgKi8KLQkJKmtleWl4ID0gKnJ4a2V5aXggPSBrIC0g dmFwLT5pdl9ud19rZXlzOwotCQlyZXR1cm4gMTsKKwkJay0+d2tfa2V5aXggPSBJRUVFODAyMTFf S0VZSVhfTk9ORTsKIAl9CiAKIAkvKgpAQCAtNjk0NSw2ICs2OTY4LDggQEAKIAkJaWZfcHJpbnRm KGlmcCwgInVzaW5nICV1IHJ4IGJ1ZmZlcnNcbiIsIGF0aF9yeGJ1Zik7CiAJaWYgKGF0aF90eGJ1 ZiAhPSBBVEhfVFhCVUYpCiAJCWlmX3ByaW50ZihpZnAsICJ1c2luZyAldSB0eCBidWZmZXJzXG4i LCBhdGhfdHhidWYpOworCWlmIChzYy0+c2NfbWNhc3RrZXkpCisJCWlmX3ByaW50ZihpZnAsICJ1 c2luZyBtdWx0aWNhc3Qga2V5IHNlYXJjaFxuIik7CiB9CiAKICNpZmRlZiBJRUVFODAyMTFfU1VQ UE9SVF9URE1BCg== --0016e68ee02e64278b047e57073e-- From owner-freebsd-stable@FreeBSD.ORG Sat Jan 30 01:43:56 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 73285106566C for ; Sat, 30 Jan 2010 01:43:56 +0000 (UTC) (envelope-from jfvogel@gmail.com) Received: from mail-ew0-f211.google.com (mail-ew0-f211.google.com [209.85.219.211]) by mx1.freebsd.org (Postfix) with ESMTP id F03168FC08 for ; Sat, 30 Jan 2010 01:43:55 +0000 (UTC) Received: by ewy3 with SMTP id 3so96884ewy.33 for ; Fri, 29 Jan 2010 17:43:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=NRaCjnrnHeKLzbxMaH6DsOFm2OqZrZrDTWQxo9m8kJQ=; b=P7q19kGOLBPUAlKJeazaUIB7pc3vb0fQAdY3IFb+r4hwx1aGnr6EdeOQotxzswqIpJ lgpinpPFoaxjhZWrD3zUL41pebWZ0bebGcEI3bG6mNuWOo73LKeP1y5AWR0PtOjbqq9v N3ZQ5ygQboffxQ8hm1Eqar8+ws3wdySlDX/Yw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=ACViTdq8kBPutBqhn5gZmkxPXUPaP3czcA31KnloPzFEliUXqROriOBTYXK84Dx5d4 9RpZvnOZkNRThqnODSUcUIkTkfNe6W5G8DQ6OYvJSXvWRrQFp0G8/tRilzASe96K0ujX wn+PxWcE1NuJtsolZ+EeXmY/LZNCkv6YHTubo= MIME-Version: 1.0 Received: by 10.216.89.205 with SMTP id c55mr175158wef.186.1264815834591; Fri, 29 Jan 2010 17:43:54 -0800 (PST) In-Reply-To: <147432021001291728w65debe89s127667ed8eca92be@mail.gmail.com> References: <147432021001242047k659a26d0s44b35164920aeb74@mail.gmail.com> <147432021001251038r69393ab3m1a797e58f9fa905a@mail.gmail.com> <02307620-ECDC-4E8B-A5B1-FF8491E226C4@nokia.com> <33c6b0bc1001252031k508426bfh25fad65e9223d87@mail.gmail.com> <147432021001260900p60ed1804t97392d2dff5cd244@mail.gmail.com> <20100128121701.GB9408@goofy.tols.org> <2a41acea1001281116k7d14cc26x120f9960ab14d19d@mail.gmail.com> <20100129133824.GE23403@goofy.tols.org> <2a41acea1001290945m77e9ae18if927716d82e50b2f@mail.gmail.com> <147432021001291728w65debe89s127667ed8eca92be@mail.gmail.com> Date: Fri, 29 Jan 2010 17:43:54 -0800 Message-ID: <2a41acea1001291743j46252b66g7fa8fccb39d0520@mail.gmail.com> From: Jack Vogel To: Nick Rogers Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: FreeBSD STABLE Subject: Re: em interface slow down on 8.0R X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 30 Jan 2010 01:43:56 -0000 You know, i know absolutely nothing about ALTQ :) This is the first I've heard about this problem, you should make sure the maintainer of the driver gets informed sooner :) Would be happy to look into it as I have time. Jack On Fri, Jan 29, 2010 at 5:28 PM, Nick Rogers wrote: > Does any of this have anything to do with the fact that ALTQ seems to be > broken for em(4) under 8.0-RELEASE? I just ran into this similar problem > today where my PF/ALTQ hfsc rules no longer seem to do anything on em > interfaces. > > http://forums.freebsd.org/showthread.php?t=6656 > > Any information regarding this would be appreciated. Thanks. > > > On Fri, Jan 29, 2010 at 9:45 AM, Jack Vogel wrote: > >> No need, I set it up and tried it, and I was right, it does not fail if >> that >> routine is not used. The interesting thing is that the igb driver, which >> has the same code, works fine. >> >> In any case, I'm hot on the track of this and hope I can figure it out >> today. >> >> Jack >> >> >> On Fri, Jan 29, 2010 at 5:38 AM, Marco van Tol wrote: >> >> > On Thu, Jan 28, 2010 at 11:16:02AM -0800, Jack Vogel wrote: >> > > I am investigating it, and have a suspicion about what's going on, you >> > can >> > > assist in verifying my suspicion. In if_em.c search for >> > "em_setup_vlan_hw", >> > > you will find a compile time option that uses that only if >> > FreeBSD_version >> > > is > 700029, hack the code however you wish so that it uses the OLD >> way >> > > (ie that it never calls em_setup_vlan_hw_support()) and see if that >> makes >> > > the issue disappear. >> > >> > Oh good, I will try that and let you know about the result first chance >> I >> > get. Should be days rather then hours, but I'll make it asap. >> > >> > > If you have any problems or questions email me directly. >> > >> > Will do, thanks! >> > >> > Marco >> > >> > >> > >> > >> > > On Thu, Jan 28, 2010 at 4:17 AM, Marco van Tol >> wrote: >> > > >> > > > On Tue, Jan 26, 2010 at 09:00:35AM -0800, Nick Rogers wrote: >> > > > > Is it advisable to patch 8.0-RELEASE kernel sources with the >> latest >> > > > > (CURRENT) em driver (i.e., src/sys/dev/e1000)? It looks like there >> > are >> > > > some >> > > > > updates to the driver since 8.0-RELEASE that may fix some >> problems? >> > > > >> > > > While on the em subject, forgive me if I mail this to the >> inappropriate >> > > > place, but is there any ETA on progress for bug kern/141646? >> > > > >> > > > I'm currently suffering from it and would be willing to provide >> needed >> > > > assistance for fixing it. >> > > > >> > > > Thank you very much in advance, >> > > > >> > > > Marco van Tol >> > >> > -- >> > Better to remain silent and be thought a fool >> > than to speak out and remove all doubt. >> > - Abraham Lincoln >> > _______________________________________________ >> > freebsd-stable@freebsd.org mailing list >> > http://lists.freebsd.org/mailman/listinfo/freebsd-stable >> > To unsubscribe, send any mail to " >> freebsd-stable-unsubscribe@freebsd.org" >> > >> _______________________________________________ >> freebsd-stable@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-stable >> To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" >> > > From owner-freebsd-stable@FreeBSD.ORG Sat Jan 30 01:52:50 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 723EA1065670 for ; Sat, 30 Jan 2010 01:52:50 +0000 (UTC) (envelope-from ncrogers@gmail.com) Received: from mail-pz0-f202.google.com (mail-pz0-f202.google.com [209.85.222.202]) by mx1.freebsd.org (Postfix) with ESMTP id 3EEE88FC08 for ; Sat, 30 Jan 2010 01:52:50 +0000 (UTC) Received: by pzk40 with SMTP id 40so1600141pzk.7 for ; Fri, 29 Jan 2010 17:52:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=IG7lfvlgjqnqOdKEE3AYEVs8aFdjeAvd7eVR+vrYImQ=; b=tW65jdAofx4B+3uZUkk1gOcCsMrZSZLtg2VHC+p5Bp4zMpPkjZtGku5DpKK/6Zl0wC IbZ6XMaTc0iR7D7ZszcBtQyueh25QY71BnwqzTC+eEKHmIqJBVy8NpgMQ6ydqzJw3DT9 Dt9DSY3UDT/o5vq+TBzOUuDz8eoJ+T3LkyfJQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=LCka1LYNGkKovw0n9ex49M+5/ZMiGx/Spc89xclpNDSBnUNAaDERx/oyQv4kGax+u5 lnN3l9z8geImMiRZjGOj+SEPrje+jm2GR8RpDWvhk4KsaZHimNSSe9VlCBnELFPDiaR8 UJ7nJXIA/AIVAV+KU2s9BWnaaX12B0Kw2NVYk= MIME-Version: 1.0 Received: by 10.142.122.6 with SMTP id u6mr1106052wfc.8.1264814929388; Fri, 29 Jan 2010 17:28:49 -0800 (PST) In-Reply-To: <2a41acea1001290945m77e9ae18if927716d82e50b2f@mail.gmail.com> References: <147432021001242047k659a26d0s44b35164920aeb74@mail.gmail.com> <20100125182257.GG1187@michelle.cdnetworks.com> <147432021001251038r69393ab3m1a797e58f9fa905a@mail.gmail.com> <02307620-ECDC-4E8B-A5B1-FF8491E226C4@nokia.com> <33c6b0bc1001252031k508426bfh25fad65e9223d87@mail.gmail.com> <147432021001260900p60ed1804t97392d2dff5cd244@mail.gmail.com> <20100128121701.GB9408@goofy.tols.org> <2a41acea1001281116k7d14cc26x120f9960ab14d19d@mail.gmail.com> <20100129133824.GE23403@goofy.tols.org> <2a41acea1001290945m77e9ae18if927716d82e50b2f@mail.gmail.com> Date: Fri, 29 Jan 2010 17:28:49 -0800 Message-ID: <147432021001291728w65debe89s127667ed8eca92be@mail.gmail.com> From: Nick Rogers To: Jack Vogel Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: FreeBSD STABLE Subject: Re: em interface slow down on 8.0R X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 30 Jan 2010 01:52:50 -0000 Does any of this have anything to do with the fact that ALTQ seems to be broken for em(4) under 8.0-RELEASE? I just ran into this similar problem today where my PF/ALTQ hfsc rules no longer seem to do anything on em interfaces. http://forums.freebsd.org/showthread.php?t=6656 Any information regarding this would be appreciated. Thanks. On Fri, Jan 29, 2010 at 9:45 AM, Jack Vogel wrote: > No need, I set it up and tried it, and I was right, it does not fail if > that > routine is not used. The interesting thing is that the igb driver, which > has the same code, works fine. > > In any case, I'm hot on the track of this and hope I can figure it out > today. > > Jack > > > On Fri, Jan 29, 2010 at 5:38 AM, Marco van Tol wrote: > > > On Thu, Jan 28, 2010 at 11:16:02AM -0800, Jack Vogel wrote: > > > I am investigating it, and have a suspicion about what's going on, you > > can > > > assist in verifying my suspicion. In if_em.c search for > > "em_setup_vlan_hw", > > > you will find a compile time option that uses that only if > > FreeBSD_version > > > is > 700029, hack the code however you wish so that it uses the OLD way > > > (ie that it never calls em_setup_vlan_hw_support()) and see if that > makes > > > the issue disappear. > > > > Oh good, I will try that and let you know about the result first chance I > > get. Should be days rather then hours, but I'll make it asap. > > > > > If you have any problems or questions email me directly. > > > > Will do, thanks! > > > > Marco > > > > > > > > > > > On Thu, Jan 28, 2010 at 4:17 AM, Marco van Tol wrote: > > > > > > > On Tue, Jan 26, 2010 at 09:00:35AM -0800, Nick Rogers wrote: > > > > > Is it advisable to patch 8.0-RELEASE kernel sources with the latest > > > > > (CURRENT) em driver (i.e., src/sys/dev/e1000)? It looks like there > > are > > > > some > > > > > updates to the driver since 8.0-RELEASE that may fix some problems? > > > > > > > > While on the em subject, forgive me if I mail this to the > inappropriate > > > > place, but is there any ETA on progress for bug kern/141646? > > > > > > > > I'm currently suffering from it and would be willing to provide > needed > > > > assistance for fixing it. > > > > > > > > Thank you very much in advance, > > > > > > > > Marco van Tol > > > > -- > > Better to remain silent and be thought a fool > > than to speak out and remove all doubt. > > - Abraham Lincoln > > _______________________________________________ > > freebsd-stable@freebsd.org mailing list > > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org > " > > > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" > From owner-freebsd-stable@FreeBSD.ORG Sat Jan 30 04:54:22 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AD0531065672 for ; Sat, 30 Jan 2010 04:54:22 +0000 (UTC) (envelope-from ncrogers@gmail.com) Received: from mail-pz0-f194.google.com (mail-pz0-f194.google.com [209.85.222.194]) by mx1.freebsd.org (Postfix) with ESMTP id 78E808FC08 for ; Sat, 30 Jan 2010 04:54:22 +0000 (UTC) Received: by pzk32 with SMTP id 32so2295384pzk.27 for ; Fri, 29 Jan 2010 20:54:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=aJTDa/FeV6NU2/kzDfDT6R2U90ZSvLeDN/xs+qCW5sM=; b=e3cXwbeYei5XyQSdja8v2POYQ5i3FUQjT6MrVBUqiMUR5TdTdtPjkpEMDIwAR6ItAb Gbz4BVNFXq44Hd01RqORscHIaCrEvtJfFN3WydZMCgtoYMb5ic81xBS/uEv02xdBfGJ9 dKIRhLhgUZXVPgTQSMfEBbVo4/rpt89zRS1Wc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=wdYNQI6TIRS2e+KTB/9uU6gyr9or7O1II1DkIQp4cfIMCq3Cu3g50XLYzmcNUuXPEb f7FXTfVBtjmJ0Xo4mdzEu7lQDckBzz3vdU2Cy/4Tpg4Tzt1dAdEtex7KF3AHbPN+NQrz z7ffZxxNuZSaduoGde5KcZyBfra3iLyBw9Iho= MIME-Version: 1.0 Received: by 10.142.8.25 with SMTP id 25mr1217031wfh.18.1264827261535; Fri, 29 Jan 2010 20:54:21 -0800 (PST) In-Reply-To: <2a41acea1001291743j46252b66g7fa8fccb39d0520@mail.gmail.com> References: <147432021001242047k659a26d0s44b35164920aeb74@mail.gmail.com> <02307620-ECDC-4E8B-A5B1-FF8491E226C4@nokia.com> <33c6b0bc1001252031k508426bfh25fad65e9223d87@mail.gmail.com> <147432021001260900p60ed1804t97392d2dff5cd244@mail.gmail.com> <20100128121701.GB9408@goofy.tols.org> <2a41acea1001281116k7d14cc26x120f9960ab14d19d@mail.gmail.com> <20100129133824.GE23403@goofy.tols.org> <2a41acea1001290945m77e9ae18if927716d82e50b2f@mail.gmail.com> <147432021001291728w65debe89s127667ed8eca92be@mail.gmail.com> <2a41acea1001291743j46252b66g7fa8fccb39d0520@mail.gmail.com> Date: Fri, 29 Jan 2010 20:54:21 -0800 Message-ID: <147432021001292054k31421fdarc349d77dc0118ed0@mail.gmail.com> From: Nick Rogers To: Jack Vogel Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: FreeBSD STABLE Subject: Re: em interface slow down on 8.0R X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 30 Jan 2010 04:54:22 -0000 I just discovered it myself today. I'll try and post more info in another thread. On Fri, Jan 29, 2010 at 5:43 PM, Jack Vogel wrote: > You know, i know absolutely nothing about ALTQ :) This is the first I've > heard > about this problem, you should make sure the maintainer of the driver gets > informed sooner :) > > Would be happy to look into it as I have time. > > Jack > > > > On Fri, Jan 29, 2010 at 5:28 PM, Nick Rogers wrote: > >> Does any of this have anything to do with the fact that ALTQ seems to be >> broken for em(4) under 8.0-RELEASE? I just ran into this similar problem >> today where my PF/ALTQ hfsc rules no longer seem to do anything on em >> interfaces. >> >> http://forums.freebsd.org/showthread.php?t=6656 >> >> Any information regarding this would be appreciated. Thanks. >> >> >> On Fri, Jan 29, 2010 at 9:45 AM, Jack Vogel wrote: >> >>> No need, I set it up and tried it, and I was right, it does not fail if >>> that >>> routine is not used. The interesting thing is that the igb driver, which >>> has the same code, works fine. >>> >>> In any case, I'm hot on the track of this and hope I can figure it out >>> today. >>> >>> Jack >>> >>> >>> On Fri, Jan 29, 2010 at 5:38 AM, Marco van Tol wrote: >>> >>> > On Thu, Jan 28, 2010 at 11:16:02AM -0800, Jack Vogel wrote: >>> > > I am investigating it, and have a suspicion about what's going on, >>> you >>> > can >>> > > assist in verifying my suspicion. In if_em.c search for >>> > "em_setup_vlan_hw", >>> > > you will find a compile time option that uses that only if >>> > FreeBSD_version >>> > > is > 700029, hack the code however you wish so that it uses the OLD >>> way >>> > > (ie that it never calls em_setup_vlan_hw_support()) and see if that >>> makes >>> > > the issue disappear. >>> > >>> > Oh good, I will try that and let you know about the result first chance >>> I >>> > get. Should be days rather then hours, but I'll make it asap. >>> > >>> > > If you have any problems or questions email me directly. >>> > >>> > Will do, thanks! >>> > >>> > Marco >>> > >>> > >>> > >>> > >>> > > On Thu, Jan 28, 2010 at 4:17 AM, Marco van Tol >>> wrote: >>> > > >>> > > > On Tue, Jan 26, 2010 at 09:00:35AM -0800, Nick Rogers wrote: >>> > > > > Is it advisable to patch 8.0-RELEASE kernel sources with the >>> latest >>> > > > > (CURRENT) em driver (i.e., src/sys/dev/e1000)? It looks like >>> there >>> > are >>> > > > some >>> > > > > updates to the driver since 8.0-RELEASE that may fix some >>> problems? >>> > > > >>> > > > While on the em subject, forgive me if I mail this to the >>> inappropriate >>> > > > place, but is there any ETA on progress for bug kern/141646? >>> > > > >>> > > > I'm currently suffering from it and would be willing to provide >>> needed >>> > > > assistance for fixing it. >>> > > > >>> > > > Thank you very much in advance, >>> > > > >>> > > > Marco van Tol >>> > >>> > -- >>> > Better to remain silent and be thought a fool >>> > than to speak out and remove all doubt. >>> > - Abraham Lincoln >>> > _______________________________________________ >>> > freebsd-stable@freebsd.org mailing list >>> > http://lists.freebsd.org/mailman/listinfo/freebsd-stable >>> > To unsubscribe, send any mail to " >>> freebsd-stable-unsubscribe@freebsd.org" >>> > >>> _______________________________________________ >>> freebsd-stable@freebsd.org mailing list >>> http://lists.freebsd.org/mailman/listinfo/freebsd-stable >>> To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org >>> " >>> >> >> > From owner-freebsd-stable@FreeBSD.ORG Sat Jan 30 05:08:33 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id ECF781065670 for ; Sat, 30 Jan 2010 05:08:33 +0000 (UTC) (envelope-from kensmith@buffalo.edu) Received: from localmailD.acsu.buffalo.edu (localmailD.acsu.buffalo.edu [128.205.5.208]) by mx1.freebsd.org (Postfix) with ESMTP id BBD348FC1C for ; Sat, 30 Jan 2010 05:08:33 +0000 (UTC) Received: from localmailD.acsu.buffalo.edu (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id D84F031951 for ; Sat, 30 Jan 2010 00:08:32 -0500 (EST) Received: from localmailD.acsu.buffalo.edu (localhost [127.0.0.1]) by localmailD.acsu.buffalo.edu (Postfix) with ESMTP id A5F2431CE4 for ; Sat, 30 Jan 2010 00:08:31 -0500 (EST) Received: from mweb1.acsu.buffalo.edu (mweb1.acsu.buffalo.edu [128.205.5.238]) by localmailD.acsu.buffalo.edu (Prefixe) with ESMTP id 9F5D3ECA8 for ; Sat, 30 Jan 2010 00:08:31 -0500 (EST) Received: from [192.168.1.101] (cpe-76-180-182-44.buffalo.res.rr.com [76.180.182.44]) by mweb1.acsu.buffalo.edu (Postfix) with ESMTP id 5DD315B0038 for ; Sat, 30 Jan 2010 00:08:31 -0500 (EST) From: Ken Smith To: freebsd-stable Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-pn2hbO0nUzVGvVJBzria" Organization: U. Buffalo Date: Sat, 30 Jan 2010 00:08:28 -0500 Message-ID: <1264828108.4948.18.camel@neo.cse.buffalo.edu> Mime-Version: 1.0 X-Mailer: Evolution 2.28.1 FreeBSD GNOME Team Port X-PM-EL-Spam-Prob: XX: 27% Subject: 7.3-BETA1 Available... X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Jan 2010 05:08:34 -0000 --=-pn2hbO0nUzVGvVJBzria Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable 7.3-BETA1, the first test build of the 7.3-RELEASE cycle, is now available for amd64, i386, pc98, and sparc64 architectures. The target schedule along with the current status of the release is available here: http://wiki.freebsd.org/Releng/7.3TODO For now we plan on BETA1 being followed by two Release Candidates, then the release itself. If you notice problems you can report them through the normal Gnats PR system or on the freebsd-stable mailing list. ISO images for the architectures listed above are available on the FTP mirror sites. For this BETA build no packages were included on any of the ISO images. An initial pass at providing packages will be done for the first Release Candidate. If you are using csup/cvsup methods to update an older system the branch tag to use is RELENG_7. The freebsd-update(8) utility supports binary upgrades of i386 and amd64 systems running earlier FreeBSD releases. Systems running 7.1-RELEASE or 7.2-RELEASE can upgrade as follows: =20 # freebsd-update upgrade -r 7.3-BETA1 During this process, FreeBSD Update may ask the user to help by merging some configuration files or by confirming that the automatically performed merging was done correctly. =20 # freebsd-update install The system must be rebooted with the newly installed kernel before continuing. # shutdown -r now =20 After rebooting, freebsd-update needs to be run again to install the new userland components, and the system needs to be rebooted again: # freebsd-update install # shutdown -r now Users of earlier FreeBSD releases (FreeBSD 6.x) can also use freebsd-update to upgrade to FreeBSD 7.3-BETA1, but will be prompted to rebuild all third-party applications (e.g., anything installed from the ports tree) after the second invocation of "freebsd-update install", in order to handle differences in the system libraries between FreeBSD 6.x and FreeBSD 7.x. Checksums: MD5 (FreeBSD-7.3-BETA1-amd64-bootonly.iso) =3D 0219e9e8ba1efecec9bba03239df= 1a36 MD5 (FreeBSD-7.3-BETA1-amd64-disc1.iso) =3D a4c49a5ad8eef58126201ba71a7b214= f MD5 (FreeBSD-7.3-BETA1-amd64-docs.iso) =3D 78fd42619550e4369d8c7e3fb85715fc MD5 (FreeBSD-7.3-BETA1-amd64-dvd1.iso) =3D ed70bfbfeb028d495ecd4e2dbcca5d07 MD5 (FreeBSD-7.3-BETA1-amd64-livefs.iso) =3D 1853ddd3a0a474bb31fc9e534b76c9= 52 MD5 (FreeBSD-7.3-BETA1-i386-bootonly.iso) =3D 9fdb08c372682ac1241f75f3c5c97= b72 MD5 (FreeBSD-7.3-BETA1-i386-disc1.iso) =3D 92b97a266771e2be4dcfa7bf241ba006 MD5 (FreeBSD-7.3-BETA1-i386-docs.iso) =3D b0e0a588873d7b5393b0fd47ff9c820b MD5 (FreeBSD-7.3-BETA1-i386-dvd1.iso) =3D 4738e6947679f72f0e3401785d83d1ec MD5 (FreeBSD-7.3-BETA1-i386-livefs.iso) =3D 618ad406e788d91d408a87472eae743= 2 MD5 (FreeBSD-7.3-BETA1-pc98-bootonly.iso) =3D 38658cbf889e2599f288ec1eca628= dd6 MD5 (FreeBSD-7.3-BETA1-pc98-disc1.iso) =3D ba5e65f1cca54c35d9933c9d27c6003c MD5 (FreeBSD-7.3-BETA1-pc98-livefs.iso) =3D 521a5add42a95b67c0470cd12b57a67= 7 MD5 (FreeBSD-7.3-BETA1-sparc64-bootonly.iso) =3D bfd1081b69f225e66b16bdb332= fbd832 MD5 (FreeBSD-7.3-BETA1-sparc64-disc1.iso) =3D 5bce58ebf4b9f10d06d522308f59a= 901 MD5 (FreeBSD-7.3-BETA1-sparc64-docs.iso) =3D 9e4d53695ad36eb5faab5e7e23a0c1= 6d SHA256 (FreeBSD-7.3-BETA1-amd64-bootonly.iso) =3D b7b2d5c72e3aff3449a0fe8ed= faace877a47b1bb6e9946f45f463a6a4bbec24c SHA256 (FreeBSD-7.3-BETA1-amd64-disc1.iso) =3D 4cc5d2a87d813f29a619225e9eda= 0ab05a5854e77ee1d3e84821b740c8c0e5ee SHA256 (FreeBSD-7.3-BETA1-amd64-docs.iso) =3D adbd636f39df3f9293cc431a1cbf9= 92e3699da219955960c14dfba8b7a55a1b5 SHA256 (FreeBSD-7.3-BETA1-amd64-dvd1.iso) =3D cbc13a91a9ed5c135153a71c8d78e= 753f8907c0dbf3391c5c480ace3d3a75b78 SHA256 (FreeBSD-7.3-BETA1-amd64-livefs.iso) =3D 0703a4af2496f5a27d23325ca44= 4d180c92e0f897c44a37a82a7ed4fa5c0cca1 SHA256 (FreeBSD-7.3-BETA1-i386-bootonly.iso) =3D 7552eb7d4d9646ee550339778f= 7041fb3170763e836dbd4e182dcc51b62662d2 SHA256 (FreeBSD-7.3-BETA1-i386-disc1.iso) =3D 69cc74ff3a37caffa055e28fb476d= b14b5cbac686a0b93a74b53c206852e663a SHA256 (FreeBSD-7.3-BETA1-i386-docs.iso) =3D 020ea6d2949f15289e9ecdb1edfff9= d7857995a67fed41df5391f8af6a6ac7ab SHA256 (FreeBSD-7.3-BETA1-i386-dvd1.iso) =3D 90364c477d0c5bec05d13d69a01838= b31575fcbc251eb9bc261557f0b3cad5ad SHA256 (FreeBSD-7.3-BETA1-i386-livefs.iso) =3D 6d17360bf9f358b5d9047de81da9= 9f497a385a70899bfcb64ba48a98f72478ca SHA256 (FreeBSD-7.3-BETA1-pc98-bootonly.iso) =3D 25faeb8c4fa656260c511585f7= 7c8ae520640b199cd6422698eabbcc0fabb524 SHA256 (FreeBSD-7.3-BETA1-pc98-disc1.iso) =3D 1799383fbd75868cebbe12204daf7= 6477adcc9c90fa7e212d77021a718109642 SHA256 (FreeBSD-7.3-BETA1-pc98-livefs.iso) =3D ede5e5d079117cb78f36171bf0a4= f0fc05828310a5f4d97a30cb399cd0a9cd63 SHA256 (FreeBSD-7.3-BETA1-sparc64-bootonly.iso) =3D 556364dc8a5c904f155ead9= f5ed857e9dc4227b5530abbdb02f3444290fe3af9 SHA256 (FreeBSD-7.3-BETA1-sparc64-disc1.iso) =3D 1779a581ca0c0024b1fb1928be= fc71c78574309e83c3c1d4cb36a4053772a93e SHA256 (FreeBSD-7.3-BETA1-sparc64-docs.iso) =3D f017ac4e343246050732b86f8d5= edeb186dd20ea6e23dd60644f244d9ad2bac6 --=20 Ken Smith - From there to here, from here to | kensmith@buffalo.edu there, funny things are everywhere. | - Theodore Geisel | --=-pn2hbO0nUzVGvVJBzria Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (FreeBSD) iEYEABECAAYFAktjvsIACgkQ/G14VSmup/ZJFwCcDbPjoJCHX/CiUo7VAomSrVu/ J28AoIKDPs9ygs3tJoHVSXkwGUIW7bz4 =BMRq -----END PGP SIGNATURE----- --=-pn2hbO0nUzVGvVJBzria-- From owner-freebsd-stable@FreeBSD.ORG Sat Jan 30 06:13:09 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 68D5B106566B for ; Sat, 30 Jan 2010 06:13:09 +0000 (UTC) (envelope-from ncrogers@gmail.com) Received: from qw-out-2122.google.com (qw-out-2122.google.com [74.125.92.25]) by mx1.freebsd.org (Postfix) with ESMTP id 1B3098FC1A for ; Sat, 30 Jan 2010 06:13:08 +0000 (UTC) Received: by qw-out-2122.google.com with SMTP id 8so536643qwh.7 for ; Fri, 29 Jan 2010 22:13:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=gb9Jv4w6scw/1qbrwAElaOma98mCN3nd8Vd1TdDL5yQ=; b=kyHa3TKK6NiXYMJNnTBqDJECtlan9sTejMAOc6biP4TaKp25DbI3NPO5q1vOyCSqay qNUzrfW9GeoRKGbNWw5VwbcrJzRvOL4Cjyh3hfP2UfQB52Bbll29cHl1IY5Z8Vli8baA 3cW88ZJ4e03CHkL3xhJDTeXuepHbqPGYTdFZ0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=DzogD28XQj5ZfxxI2llIZuvMSo2Kl6zZgQKE21i4S1VOLU8cGSL/BTZCpjvfHObkW7 H/GGRHLnqNLHIL3jlNdveMUUz0mb0at+h+av+/NzDh6ZWVN6u3nF08m2Q36kwtD/vT9D 2Jaku3oXXJtv5yTouJIk9wNsQHE5kIQ5VmS0A= MIME-Version: 1.0 Received: by 10.224.85.74 with SMTP id n10mr821322qal.126.1264831988234; Fri, 29 Jan 2010 22:13:08 -0800 (PST) In-Reply-To: <2a41acea1001291743j46252b66g7fa8fccb39d0520@mail.gmail.com> References: <147432021001242047k659a26d0s44b35164920aeb74@mail.gmail.com> <02307620-ECDC-4E8B-A5B1-FF8491E226C4@nokia.com> <33c6b0bc1001252031k508426bfh25fad65e9223d87@mail.gmail.com> <147432021001260900p60ed1804t97392d2dff5cd244@mail.gmail.com> <20100128121701.GB9408@goofy.tols.org> <2a41acea1001281116k7d14cc26x120f9960ab14d19d@mail.gmail.com> <20100129133824.GE23403@goofy.tols.org> <2a41acea1001290945m77e9ae18if927716d82e50b2f@mail.gmail.com> <147432021001291728w65debe89s127667ed8eca92be@mail.gmail.com> <2a41acea1001291743j46252b66g7fa8fccb39d0520@mail.gmail.com> Date: Fri, 29 Jan 2010 22:13:08 -0800 Message-ID: <147432021001292213w8c70b25gb63c588b9223f598@mail.gmail.com> From: Nick Rogers To: Jack Vogel Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: FreeBSD STABLE Subject: Re: em interface slow down on 8.0R X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 30 Jan 2010 06:13:09 -0000 On Fri, Jan 29, 2010 at 5:43 PM, Jack Vogel wrote: > You know, i know absolutely nothing about ALTQ :) This is the first I've > heard > about this problem, you should make sure the maintainer of the driver gets > informed sooner :) > > Look like there is an old PR for it. See kern/138392. From owner-freebsd-stable@FreeBSD.ORG Sat Jan 30 06:19:16 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1892D106568F for ; Sat, 30 Jan 2010 06:19:16 +0000 (UTC) (envelope-from smithi@nimnet.asn.au) Received: from sola.nimnet.asn.au (paqi.nimnet.asn.au [115.70.110.159]) by mx1.freebsd.org (Postfix) with ESMTP id 919FB8FC0A for ; Sat, 30 Jan 2010 06:19:15 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by sola.nimnet.asn.au (8.14.2/8.14.2) with ESMTP id o0U6Hs43070657; Sat, 30 Jan 2010 17:17:54 +1100 (EST) (envelope-from smithi@nimnet.asn.au) Date: Sat, 30 Jan 2010 17:17:54 +1100 (EST) From: Ian Smith To: Ken Smith In-Reply-To: <1264828108.4948.18.camel@neo.cse.buffalo.edu> Message-ID: <20100130164546.K46992@sola.nimnet.asn.au> References: <1264828108.4948.18.camel@neo.cse.buffalo.edu> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: freebsd-stable Subject: Re: 7.3-BETA1 Available... [memstick.img?] X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Jan 2010 06:19:16 -0000 On Sat, 30 Jan 2010, Ken Smith wrote: > 7.3-BETA1, the first test build of the 7.3-RELEASE cycle, is now > available for amd64, i386, pc98, and sparc64 architectures. The target > schedule along with the current status of the release is available here: > > http://wiki.freebsd.org/Releng/7.3TODO Hi Ken, are there any plans afoot to release memstick.img/s for 7.3-R? If so, where should I look for information on how it may be done? If not, is there something about RELENG_7 precluding that? USB stack? My search for information on the particular recipe/s used to make the 8.0-R memstick images has proven fruitless so far, despite several useful suggestions on ways to make various other sorts of bootable USB stick images. So far they seem to have been made out-of-band, somehow? My particular interest is in putting DVD release/s onto a 4GB(+) stick, hopefully on bootable slices rather than 'dangerously dedicated' form. cheers, Ian From owner-freebsd-stable@FreeBSD.ORG Sat Jan 30 09:15:29 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A5F72106568B for ; Sat, 30 Jan 2010 09:15:29 +0000 (UTC) (envelope-from doconnor@gsoft.com.au) Received: from cain.gsoft.com.au (cain.gsoft.com.au [203.31.81.10]) by mx1.freebsd.org (Postfix) with ESMTP id 2653B8FC16 for ; Sat, 30 Jan 2010 09:15:28 +0000 (UTC) Received: from inchoate.gsoft.com.au (ppp121-45-156-224.lns6.adl6.internode.on.net [121.45.156.224]) (authenticated bits=0) by cain.gsoft.com.au (8.13.8/8.13.8) with ESMTP id o0U9FLBg031685 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Sat, 30 Jan 2010 19:45:22 +1030 (CST) (envelope-from doconnor@gsoft.com.au) From: "Daniel O'Connor" To: freebsd-stable@freebsd.org Date: Sat, 30 Jan 2010 19:45:06 +1030 User-Agent: KMail/1.9.10 References: <1264828108.4948.18.camel@neo.cse.buffalo.edu> <20100130164546.K46992@sola.nimnet.asn.au> In-Reply-To: <20100130164546.K46992@sola.nimnet.asn.au> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart3125385.gH9e7dHVF0"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <201001301945.14487.doconnor@gsoft.com.au> X-Spam-Score: -1.705 () AWL,BAYES_00,RDNS_DYNAMIC X-Scanned-By: MIMEDefang 2.63 on 203.31.81.10 Cc: Ian Smith , Ken Smith Subject: Re: 7.3-BETA1 Available... [memstick.img?] X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Jan 2010 09:15:29 -0000 --nextPart3125385.gH9e7dHVF0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Sat, 30 Jan 2010, Ian Smith wrote: > My search for information on the particular recipe/s used to make the > 8.0-R memstick images has proven fruitless so far, despite several > useful suggestions on ways to make various other sorts of bootable > USB stick images. =A0So far they seem to have been made out-of-band, > somehow? > > My particular interest is in putting DVD release/s onto a 4GB(+) > stick, hopefully on bootable slices rather than 'dangerously > dedicated' form. I don't know the secret sauce used for the FreeBSD.org ones but I have=20 made my own using syslinux that boots an MFS off a FAT32 USB stick=20 (more useful to me than the UFS image one). This is the script I use.. http://www.gsoft.com.au/~doconnor/makeusb.sh Here be dragons, no warranty, etc.. =2D-=20 Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C --nextPart3125385.gH9e7dHVF0 Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.12 (FreeBSD) iD8DBQBLY/ii5ZPcIHs/zowRAk8pAJ94dBkFk6rNY0sR2FQMiGQvTZ5EzACgpCTa xonsBnmDsFyMdRF4HvQvZwU= =5r1J -----END PGP SIGNATURE----- --nextPart3125385.gH9e7dHVF0-- From owner-freebsd-stable@FreeBSD.ORG Sat Jan 30 12:08:39 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AD593106566C for ; Sat, 30 Jan 2010 12:08:39 +0000 (UTC) (envelope-from freebsd@insightbb.com) Received: from mxsf14.insightbb.com (mxsf14.insightbb.com [74.128.0.96]) by mx1.freebsd.org (Postfix) with ESMTP id 771B38FC08 for ; Sat, 30 Jan 2010 12:08:39 +0000 (UTC) X-IronPort-AV: E=Sophos;i="4.49,374,1262581200"; d="scan'208";a="28136182" Received: from unknown (HELO asav03.insightbb.com) ([172.31.249.123]) by mxsf14.insightbb.com with ESMTP; 30 Jan 2010 07:08:38 -0500 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhIGACuwY0vQLicL/2dsb2JhbACBM44rAchigkWCAAQ X-IronPort-AV: E=Sophos;i="4.49,374,1262581200"; d="scan'208";a="122680059" Received: from 208-46-39-11.dia.static.qwest.net (HELO laptop2.stevenfriedrich.org) ([208.46.39.11]) by asavout03.insightbb.com with ESMTP; 30 Jan 2010 07:08:38 -0500 To: freebsd-stable@freebsd.org From: Steven Friedrich X-Face: i~b2iK'Z*tJ)pO9@6lJG=k7>N,V~YMq":Iwdl!m|A"g,N@)'|zb[{ Subject: loading module sdhci causes panic X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Jan 2010 12:08:39 -0000 I stopped the boot before the timer expired, after it had loaded modules specified in /boot/loader.conf I loaded mmc, mmcsd, and sdhci. I continued the boot, and it panic'ed right after apic. I rebooted everal times, to load each individually, to narrow it down to sdhci. Can anyone verify that sdhci is compatible with FreeBSD 8? I updated and built today. From owner-freebsd-stable@FreeBSD.ORG Sat Jan 30 14:14:21 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 687F81065693 for ; Sat, 30 Jan 2010 14:14:21 +0000 (UTC) (envelope-from freebsd@chillt.de) Received: from dd15624.kasserver.com (dd15624.kasserver.com [85.13.136.215]) by mx1.freebsd.org (Postfix) with ESMTP id E73488FC08 for ; Sat, 30 Jan 2010 14:14:19 +0000 (UTC) Received: from takahe.local (84-203-79-36.mysmart.ie [84.203.79.36]) by dd15624.kasserver.com (Postfix) with ESMTP id 409FB2C015C56; Sat, 30 Jan 2010 14:56:05 +0100 (CET) Message-ID: <4B643A76.7040007@chillt.de> Date: Sat, 30 Jan 2010 13:56:06 +0000 From: Bartosz Fabianowski User-Agent: Thunderbird 2.0.0.23 (X11/20091215) MIME-Version: 1.0 To: Steven Friedrich References: <201001300708.37683.freebsd@insightbb.com> In-Reply-To: <201001300708.37683.freebsd@insightbb.com> X-Enigmail-Version: 0.95.6 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org Subject: Re: loading module sdhci causes panic X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Jan 2010 14:14:21 -0000 > Can anyone verify that sdhci is compatible with FreeBSD 8? I loaded mmc, mmcsd, and sdhci when I first installed FreeBSD 8.0 without any problems. Since then, I have updated to -STABLE and put these three devices in my kernel configuration file. No problems either. It must be very recent breakage or some incompatibility with your particular hardware. - Bartosz From owner-freebsd-stable@FreeBSD.ORG Sat Jan 30 14:44:37 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 317CF106566C; Sat, 30 Jan 2010 14:44:37 +0000 (UTC) (envelope-from marius@alchemy.franken.de) Received: from alchemy.franken.de (alchemy.franken.de [194.94.249.214]) by mx1.freebsd.org (Postfix) with ESMTP id 9570A8FC1A; Sat, 30 Jan 2010 14:44:36 +0000 (UTC) Received: from alchemy.franken.de (localhost [127.0.0.1]) by alchemy.franken.de (8.14.3/8.14.3/ALCHEMY.FRANKEN.DE) with ESMTP id o0UEiX40099070; Sat, 30 Jan 2010 15:44:33 +0100 (CET) (envelope-from marius@alchemy.franken.de) Received: (from marius@localhost) by alchemy.franken.de (8.14.3/8.14.3/Submit) id o0UEiXRJ099069; Sat, 30 Jan 2010 15:44:33 +0100 (CET) (envelope-from marius) Date: Sat, 30 Jan 2010 15:44:33 +0100 From: Marius Strobl To: Peter Jeremy Message-ID: <20100130144433.GA99039@alchemy.franken.de> References: <20100126073336.GA1955@server.vk2pj.dyndns.org> <201001260946.44977.jhb@freebsd.org> <20100126183756.GA40779@alchemy.franken.de> <201001261510.59667.jhb@freebsd.org> <20100127063649.GA1889@server.vk2pj.dyndns.org> <20100127115229.GD40779@alchemy.franken.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20100127115229.GD40779@alchemy.franken.de> User-Agent: Mutt/1.4.2.3i Cc: rmacklem@freebsd.org, dfr@freebsd.org, freebsd-stable@freebsd.org, John Baldwin Subject: Re: uma_zalloc_arg complaining about non-sleepable locks X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Jan 2010 14:44:37 -0000 On Wed, Jan 27, 2010 at 12:52:29PM +0100, Marius Strobl wrote: > On Wed, Jan 27, 2010 at 05:36:49PM +1100, Peter Jeremy wrote: > > On 2010-Jan-26 15:10:59 -0500, John Baldwin wrote: > > >On Tuesday 26 January 2010 1:37:56 pm Marius Strobl wrote: > > >> On Tue, Jan 26, 2010 at 09:46:44AM -0500, John Baldwin wrote: > > >> > On Tuesday 26 January 2010 2:33:37 am Peter Jeremy wrote: > > >> > > I have just upgraded to 8-STABLE/amd64 from about 18 hours ago and am > > >> > > now getting regular (the following pair of messages about every > > >> > > minute) compaints as follows: > > >> > > > > >> > > kernel: uma_zalloc_arg: zone "mbuf" with the following non-sleepable locks held: > > >> > > kernel: exclusive sleep mutex sp_lock (sp_lock) r = 0 (0xffffff000460bb00) locked @ /usr/src/sys/rpc/svc.c:1098 > > ... > > >> Could you please give the following patch a try? > > >> http://people.freebsd.org/~marius/fha_extract_info_realign2.diff > > > > That seems to have fixed it - I've booted the new kernel and generated > > some NFS activity and am not getting any messages. Also, > > vfs.nfs.realign_test is incrementing nicely though > > vfs.nfs.realign_count remains at zero. > > > > Ah, I forgot that using nfsm_aligned() causes nfs_realign() to > be a NOP on architectures without strict alignment requirements > for performance reasons. That's generally fine but unfortunately > that way you don't actually exercise the code which caused the > problem before (unfortunately I still don't manage to hit the > unaligned case myself). > Could you please test with #ifdef __NO_STRICT_ALIGNMENT replaced > with #if 0 in sys/nfs/nfs_common.h? The vfs.nfs.realign_count > counter should also increase then. > How did that work out? Marius From owner-freebsd-stable@FreeBSD.ORG Sat Jan 30 16:04:19 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B6E731065672 for ; Sat, 30 Jan 2010 16:04:19 +0000 (UTC) (envelope-from mavbsd@gmail.com) Received: from mail-fx0-f227.google.com (mail-fx0-f227.google.com [209.85.220.227]) by mx1.freebsd.org (Postfix) with ESMTP id 4599D8FC1A for ; Sat, 30 Jan 2010 16:04:19 +0000 (UTC) Received: by fxm27 with SMTP id 27so1205540fxm.3 for ; Sat, 30 Jan 2010 08:04:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=rEvUweSpzNQiWG7OMGDFS3t/rEMFRRiA5MHiEKnnTO8=; b=rNdEsXy69rxYDNJojpkeFGOWKKaoGH46cWN4xOYq8kvfjLu1Bq27mYlCWqO5aH9I52 KFyXxY7bYE8nzHjr/2NWPseyr+LYHKfuTb08gOW3Ff33K3jaKUvR7497Hn9EIe4Otnjm Ey5vC72y+HAjsxIteAyldNSumAlAtLQg0cwi4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=aD10HO1DDsgIdEHPs+ouqtRa9anhTmIRiiFdZ2cI3zZ4FAGXoPFaBadpzKMgWqyNnu uOVcozxyvoLBQSwBnO3JvlAvqu0Ucyfi2r4UU9zcRfbfnYoY4F+DnM6k1AyyPC3AS+xA MF0kWA6lB3fGhPtGPWz7Gvi+iVnZGQ4/eePnA= Received: by 10.102.107.2 with SMTP id f2mr1146166muc.49.1264867458060; Sat, 30 Jan 2010 08:04:18 -0800 (PST) Received: from mavbook.mavhome.dp.ua (pc.mavhome.dp.ua [212.86.226.226]) by mx.google.com with ESMTPS id u26sm11885057mug.45.2010.01.30.08.04.17 (version=SSLv3 cipher=RC4-MD5); Sat, 30 Jan 2010 08:04:17 -0800 (PST) Sender: Alexander Motin Message-ID: <4B64587F.7050701@FreeBSD.org> Date: Sat, 30 Jan 2010 18:04:15 +0200 From: Alexander Motin User-Agent: Thunderbird 2.0.0.23 (X11/20091212) MIME-Version: 1.0 To: Steven Friedrich References: <1264864993.00213457.1264853403@10.7.7.3> In-Reply-To: <1264864993.00213457.1264853403@10.7.7.3> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org Subject: Re: loading module sdhci causes panic X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Jan 2010 16:04:19 -0000 Steven Friedrich wrote: > I stopped the boot before the timer expired, after it had loaded modules > specified in /boot/loader.conf > > I loaded mmc, mmcsd, and sdhci. > > I continued the boot, and it panic'ed right after apic. > > I rebooted everal times, to load each individually, to narrow it down to > sdhci. > > Can anyone verify that sdhci is compatible with FreeBSD 8? > > I updated and built today. I am using it daily since written it and till present 9-CURRENT. Show your verbose boot messages and crash information. -- Alexander Motin