From owner-freebsd-stable@FreeBSD.ORG Sun Feb 8 04:05:06 2009 Return-Path: Delivered-To: FreeBSD-stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A03F01065670 for ; Sun, 8 Feb 2009 04:05:06 +0000 (UTC) (envelope-from markir@paradise.net.nz) Received: from smtp3.clear.net.nz (smtp3.clear.net.nz [203.97.33.64]) by mx1.freebsd.org (Postfix) with ESMTP id 6BDF08FC13 for ; Sun, 8 Feb 2009 04:05:06 +0000 (UTC) (envelope-from markir@paradise.net.nz) Received: from zmori.markir.net (121-73-179-120.dsl.telstraclear.net [121.73.179.120]) by smtp3.clear.net.nz (CLEAR Net Mail) with ESMTP id <0KEQ00M9ZBCGRZ30@smtp3.clear.net.nz> for FreeBSD-stable@FreeBSD.org; Sun, 08 Feb 2009 17:05:05 +1300 (NZDT) Date: Sun, 08 Feb 2009 17:05:04 +1300 From: Mark Kirkwood In-reply-to: <4976CB1C.7050409@paradise.net.nz> To: FreeBSD-stable@FreeBSD.org Message-id: <498E59F0.30700@paradise.net.nz> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7bit References: <20090109171857.GA49752@marvin.eastcentral.edu> <4975ADF4.1070103@paradise.net.nz> <4976CB1C.7050409@paradise.net.nz> User-Agent: Thunderbird 2.0.0.19 (X11/20090117) Cc: rizzo@iet.unipi.it Subject: Re: Broken loader on 7.1-STABLE? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Feb 2009 04:05:06 -0000 Mark Kirkwood wrote: > I wrote: >> >> I am getting this too - update from RELENG_7 @12 Jan src to 20 Jan >> and I have: >> >> panic: free: guard1 fail @ 0x511d >> from /usr/src/sys/boot/i386/loader/../../common/module.c:959 >> >> Can't work out which disk we are booting from. >> Guessed BIOS device 0xffffffff not found by probes, defaulting to disk0 >> >> > > Forgot to say (cc'ing Luigi as he is collecting info): > > Asus a8vx with an AMD 64x2 3800+ dual core > Also seeing this on a Supermicro P3TDER 2xPIII 1.26 GHz with RELENG_7 @08 Feb. In this case specifying /boot/loader.old got me booted ok (not sure why this *didn't* work with the Asus, maybe I need to try it again with the Feb sources). regards Mark From owner-freebsd-stable@FreeBSD.ORG Sun Feb 8 07:23:19 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AA740106564A for ; Sun, 8 Feb 2009 07:23:19 +0000 (UTC) (envelope-from todorov@paladin.bulgarpress.com) Received: from paladin.bulgarpress.com (paladin.bulgarpress.com [195.24.42.3]) by mx1.freebsd.org (Postfix) with ESMTP id 5809E8FC18 for ; Sun, 8 Feb 2009 07:23:19 +0000 (UTC) (envelope-from todorov@paladin.bulgarpress.com) Received: from localhost (localhost [127.0.0.1]) by paladin.bulgarpress.com (Postfix) with ESMTP id CC36361DB; Sun, 8 Feb 2009 09:23:17 +0200 (EET) X-Virus-Scanned: amavisd-new at paladin.bulgarpress.com Received: from paladin.bulgarpress.com ([195.24.42.3]) by localhost (paladin.bulgarpress.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Rfuhv5cknWIo; Sun, 8 Feb 2009 09:23:16 +0200 (EET) Received: from [192.168.10.12] (unknown [77.70.57.248]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by paladin.bulgarpress.com (Postfix) with ESMTPSA id 380CE61D9; Sun, 8 Feb 2009 09:23:16 +0200 (EET) Message-ID: <498E8863.7060808@paladin.bulgarpress.com> Date: Sun, 08 Feb 2009 09:23:15 +0200 From: Todorov Organization: Powerforge Net User-Agent: Thunderbird 2.0.0.19 (X11/20090203) MIME-Version: 1.0 To: Ivan Voras References: <498CCB85.2080702@paladin.bulgarpress.com> In-Reply-To: X-Enigmail-Version: 0.95.6 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: freebsd-stable@freebsd.org Subject: Re: FBSD 7.1 XEON Quad Core X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Feb 2009 07:23:19 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Ivan Voras написа: | Todorov wrote: |> Hi list, |> |> what are the good make.conf options for the Xeon Quad core. |> |> CPUTYPE=core2 ?? | | It's probably better to use | | CFLAGS+=-O2 -mtune=native | |> Also is there any benefit to use AMD64 platform for this CPU? |> (Java Diablo + PGSQL 8.1 + Apache + Apache Tomcat) | | Yes, if you have (or plan to have) more than 3 GB of memory. | Thanks! -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.10 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkmOiGMACgkQibJkIG65HMc7AACfZIDn4bv33cNyUia2mXcR3p/K ST4An18rJYrvaLJL91i0HsIhqMdqXHrO =gN9l -----END PGP SIGNATURE----- From owner-freebsd-stable@FreeBSD.ORG Sun Feb 8 08:45:15 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3E23C1065678 for ; Sun, 8 Feb 2009 08:45:15 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from kabab.cs.huji.ac.il (kabab.cs.huji.ac.il [132.65.16.84]) by mx1.freebsd.org (Postfix) with ESMTP id EB2188FC0C for ; Sun, 8 Feb 2009 08:45:14 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from pampa.cs.huji.ac.il ([132.65.80.32]) by kabab.cs.huji.ac.il with esmtp id 1LW5Ht-0000VH-D8; Sun, 08 Feb 2009 10:45:13 +0200 X-Mailer: exmh version 2.7.2 01/07/2005 with nmh-1.2 To: freebsd-stable@freebsd.org, hackers@freebsd.org In-reply-to: Your message of Fri, 06 Feb 2009 08:32:27 +0200 . Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 08 Feb 2009 10:45:13 +0200 From: Danny Braniss Message-ID: Cc: Subject: Re: impossible packet length ... X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Feb 2009 08:45:15 -0000 I'm reposting this to hackers, and there is some more info. > Hi, > on 2 different servers, running 7.1-stable + zfs, I get this > error rather frequently: > > Feb 5 17:01:03 warhol-00 kernel: impossible packet length (543383918) from > nfs server sunfire:/dist > Feb 5 17:01:03 warhol-00 kernel: impossible packet length (1936028704) from > nfs server sunfire:/dist > Feb 5 17:01:03 warhol-00 kernel: impossible packet length (1869363744) from > nfs server sunfire:/dist > Feb 5 17:01:03 warhol-00 kernel: impossible packet length (1667787057) from > nfs server sunfire:/dist > Feb 5 17:01:03 warhol-00 kernel: impossible packet length (976040755) from > nfs server sunfire:/dist > Feb 5 17:01:03 warhol-00 kernel: impossible packet length (1953459488) from > nfs server sunfire:/dist > Feb 5 17:01:03 warhol-00 kernel: impossible packet length (1348825156) from > nfs server sunfire:/dist > Feb 5 17:01:03 warhol-00 kernel: impossible packet length (0) from nfs server > sunfire:/dist > Feb 5 17:01:03 warhol-00 kernel: impossible packet length (1647208041) from > nfs server sunfire:/dist > > in this case the server is running Freebsd-7.0-stable, but I also get it when > the server is a > netapp. > > is there a connection? > > thanks, > danny going through the logs, after it happened again, I got a glimps of this: Feb 6 18:00:13 warhol-00.cs.huji.ac.il kernel: bce0: discard frame w/o leading ethernet header (len 0 pkt len 0) Feb 6 18:00:19 klee-05.cs.huji.ac.il kernel: nfs: server warhol-00 not responding, timed out ... Feb 6 19:00:00 warhol-00.cs.huji.ac.il amd[715]: More than a single value for /defaults in hesiod.local Feb 6 19:00:00 warhol-00.cs.huji.ac.il amd[715]: Unknown $ sequence in "rhost:=${RHOST};type:=nfsl;fs:=${FS};rfs:=$huldig#^ZM-^KoM- abase" Feb 6 19:00:00 warhol-00.cs.huji.ac.il kernel: impossible packet length (2068989523) from nfs server sunfire:/dist which seems to point fingers at bce... danny From owner-freebsd-stable@FreeBSD.ORG Sun Feb 8 09:31:46 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E53321065672; Sun, 8 Feb 2009 09:31:46 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from kabab.cs.huji.ac.il (kabab.cs.huji.ac.il [132.65.16.84]) by mx1.freebsd.org (Postfix) with ESMTP id 9AEE08FC18; Sun, 8 Feb 2009 09:31:46 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from pampa.cs.huji.ac.il ([132.65.80.32]) by kabab.cs.huji.ac.il with esmtp id 1LW60v-0000zC-B2; Sun, 08 Feb 2009 11:31:45 +0200 X-Mailer: exmh version 2.7.2 01/07/2005 with nmh-1.2 To: Peter Jeremy In-reply-to: <20090208091656.GA31876@test71.vk2pj.dyndns.org> References: <20090208091656.GA31876@test71.vk2pj.dyndns.org> Comments: In-reply-to Peter Jeremy message dated "Sun, 08 Feb 2009 20:16:56 +1100." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 08 Feb 2009 11:31:45 +0200 From: Danny Braniss Message-ID: Cc: hackers@freebsd.org, freebsd-stable@freebsd.org Subject: Re: impossible packet length ... X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Feb 2009 09:31:47 -0000 > > --jI8keyz6grp/JLjh > Content-Type: text/plain; charset=us-ascii > Content-Disposition: inline > Content-Transfer-Encoding: quoted-printable > > On 2009-Feb-08 10:45:13 +0200, Danny Braniss wrote: > >Feb 6 18:00:13 warhol-00.cs.huji.ac.il kernel: bce0: discard frame w/o=20 > >leading ethernet header (len 0 pkt len 0) > =2E.. > >Feb 6 19:00:00 warhol-00.cs.huji.ac.il amd[715]: Unknown $ sequence in=20 > >"rhost:=3D${RHOST};type:=3Dnfsl;fs:=3D${FS};rfs:=3D$huldig#^ZM-^KoM- a= > base" > >Feb 6 19:00:00 warhol-00.cs.huji.ac.il kernel: impossible packet length= > =20 > >(2068989523) from nfs server sunfire:/dist > > > >which seems to point fingers at bce... > > It does rather suggest that bce is not behaving. What happens if you > turn off checksum off-loading? This should make the kernel drop the > corrupt packets instead of trying to process them. If practical, you > could also try (temporarily) plugging in a different NIC. > I have, and now it's a matter of waiting... Q: with rxcsum on, and a bad checksum packet is received, is it dropped by the NIC? if not, then it somewhat explains the behaviour changing the nic is tough, but if needed will be done. danny > Peter Jeremy From owner-freebsd-stable@FreeBSD.ORG Sun Feb 8 10:43:25 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5A74D1065672 for ; Sun, 8 Feb 2009 10:43:25 +0000 (UTC) (envelope-from peter@vk2pj.dyndns.org) Received: from mail36.syd.optusnet.com.au (mail36.syd.optusnet.com.au [211.29.133.76]) by mx1.freebsd.org (Postfix) with ESMTP id E0FC68FC19 for ; Sun, 8 Feb 2009 10:43:24 +0000 (UTC) (envelope-from peter@vk2pj.dyndns.org) Received: from test71.vk2pj.dyndns.org (c122-106-216-167.belrs3.nsw.optusnet.com.au [122.106.216.167]) by mail36.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id n18AgrQ6006603 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 8 Feb 2009 21:42:54 +1100 X-Bogosity: Ham, spamicity=0.000000 Received: from test71.vk2pj.dyndns.org (localhost.vk2pj.dyndns.org [127.0.0.1]) by test71.vk2pj.dyndns.org (8.14.3/8.14.3) with ESMTP id n18AgrXi064626; Sun, 8 Feb 2009 21:42:53 +1100 (EST) (envelope-from peter@test71.vk2pj.dyndns.org) Received: (from peter@localhost) by test71.vk2pj.dyndns.org (8.14.3/8.14.3/Submit) id n18Agrrk064625; Sun, 8 Feb 2009 21:42:53 +1100 (EST) (envelope-from peter) Date: Sun, 8 Feb 2009 21:42:53 +1100 From: Peter Jeremy To: Danny Braniss Message-ID: <20090208104253.GB31876@test71.vk2pj.dyndns.org> References: <20090208091656.GA31876@test71.vk2pj.dyndns.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="ZoaI/ZTpAVc4A5k6" Content-Disposition: inline In-Reply-To: X-PGP-Key: http://members.optusnet.com.au/peterjeremy/pubkey.asc User-Agent: Mutt/1.5.18 (2008-05-17) Cc: freebsd-stable@freebsd.org Subject: Re: impossible packet length ... X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Feb 2009 10:43:25 -0000 --ZoaI/ZTpAVc4A5k6 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 2009-Feb-08 11:31:45 +0200, Danny Braniss wrote: >Q: with rxcsum on, and a bad checksum packet is received, is it > dropped by the NIC? if not, then it somewhat explains the behaviour If checksum offloading is working correctly then a bad packet should be dropped by the NIC. If checksum offloading isn't working correctly then you can wind up in the situation where both the NIC and the driver think the other party has verified the checksum. It's also possible that you may be running into corruption during DMA transfer =66rom the NIC to RAM. ISTR there have been some issues reported recently with checksum offloading on some NICs - though I don't have details to hand - you might like to search the lists. >changing the nic is tough, but if needed will be done.=20 If disabling checksum offloading fixes the problem and the additional CPU load is acceptable (at least until you find a real fix) then there's no need to change NICs. --=20 Peter Jeremy --ZoaI/ZTpAVc4A5k6 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.10 (FreeBSD) iEYEARECAAYFAkmOty0ACgkQ/opHv/APuIecbgCeKUBqmqvYE/t/UJv/Z03h7ZaM KnUAn0yYadZJgChKjSUatT1NgPAAkYJk =YD1D -----END PGP SIGNATURE----- --ZoaI/ZTpAVc4A5k6-- From owner-freebsd-stable@FreeBSD.ORG Sun Feb 8 11:23:05 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 757B8106566C; Sun, 8 Feb 2009 11:23:05 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.terabit.net.ua (mail.terabit.net.ua [195.137.202.147]) by mx1.freebsd.org (Postfix) with ESMTP id 18E3B8FC16; Sun, 8 Feb 2009 11:23:04 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from skuns.zoral.com.ua ([91.193.166.194] helo=mail.zoral.com.ua) by mail.terabit.net.ua with esmtps (TLSv1:AES256-SHA:256) (Exim 4.63 (FreeBSD)) (envelope-from ) id 1LW7kc-000Pvh-K9; Sun, 08 Feb 2009 13:23:02 +0200 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 n18BMxvG043700 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 8 Feb 2009 13:22:59 +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 n18BMx5D073851; Sun, 8 Feb 2009 13:22:59 +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 n18BMxne073850; Sun, 8 Feb 2009 13:22:59 +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: Sun, 8 Feb 2009 13:22:59 +0200 From: Kostik Belousov To: Danny Braniss Message-ID: <20090208112259.GW9427@deviant.kiev.zoral.com.ua> References: Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="+rRWuC8ZLvVekNoN" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on 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 X-Virus-Scanned: mail.terabit.net.ua 1LW7kc-000Pvh-K9 d21d0ec89b31b8a031564676a3620c67 X-Terabit: YES Cc: hackers@freebsd.org, freebsd-stable@freebsd.org Subject: Re: impossible packet length ... X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Feb 2009 11:23:05 -0000 --+rRWuC8ZLvVekNoN Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Feb 08, 2009 at 10:45:13AM +0200, Danny Braniss wrote: > I'm reposting this to hackers, and there is some more info. >=20 > > Hi, > > on 2 different servers, running 7.1-stable + zfs, I get this > > error rather frequently: > >=20 > > Feb 5 17:01:03 warhol-00 kernel: impossible packet length (543383918) = from=20 > > nfs server sunfire:/dist > > Feb 5 17:01:03 warhol-00 kernel: impossible packet length (1936028704)= from=20 > > nfs server sunfire:/dist > > Feb 5 17:01:03 warhol-00 kernel: impossible packet length (1869363744)= from=20 > > nfs server sunfire:/dist > > Feb 5 17:01:03 warhol-00 kernel: impossible packet length (1667787057)= from=20 > > nfs server sunfire:/dist > > Feb 5 17:01:03 warhol-00 kernel: impossible packet length (976040755) = from=20 > > nfs server sunfire:/dist > > Feb 5 17:01:03 warhol-00 kernel: impossible packet length (1953459488)= from=20 > > nfs server sunfire:/dist > > Feb 5 17:01:03 warhol-00 kernel: impossible packet length (1348825156)= from=20 > > nfs server sunfire:/dist > > Feb 5 17:01:03 warhol-00 kernel: impossible packet length (0) from nfs= server=20 > > sunfire:/dist > > Feb 5 17:01:03 warhol-00 kernel: impossible packet length (1647208041)= from=20 > > nfs server sunfire:/dist > >=20 > > in this case the server is running Freebsd-7.0-stable, but I also get i= t when=20 > > the server is a > > netapp. > >=20 > > is there a connection? > >=20 > > thanks, > > danny >=20 > going through the logs, after it happened again, I got a glimps of this: >=20 > Feb 6 18:00:13 warhol-00.cs.huji.ac.il kernel: bce0: discard frame w/o= =20 > leading ethernet header (len 0 pkt len 0) > Feb 6 18:00:19 klee-05.cs.huji.ac.il kernel: nfs: server warhol-00 not= =20 > responding, timed out > ... > Feb 6 19:00:00 warhol-00.cs.huji.ac.il amd[715]: More than a single valu= e for=20 > /defaults in hesiod.local > Feb 6 19:00:00 warhol-00.cs.huji.ac.il amd[715]: Unknown $ sequence in= =20 > "rhost:=3D${RHOST};type:=3Dnfsl;fs:=3D${FS};rfs:=3D$huldig#^ZM-^KoM- = abase" > Feb 6 19:00:00 warhol-00.cs.huji.ac.il kernel: impossible packet length= =20 > (2068989523) from nfs server sunfire:/dist >=20 > which seems to point fingers at bce... bce(4) is broken in stable, your best option is to revert to the driver in releng 7.1. --+rRWuC8ZLvVekNoN Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (FreeBSD) iEYEARECAAYFAkmOwJIACgkQC3+MBN1Mb4gqewCfXNYj8DTBWnqWlXiPpw4y5IFz 3EcAnjnvq1Lwt9hZia6JhvuAcT2byaVw =HaQ+ -----END PGP SIGNATURE----- --+rRWuC8ZLvVekNoN-- From owner-freebsd-stable@FreeBSD.ORG Sun Feb 8 12:11:47 2009 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 450E51065673; Sun, 8 Feb 2009 12:11:47 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.terabit.net.ua (mail.terabit.net.ua [195.137.202.147]) by mx1.freebsd.org (Postfix) with ESMTP id E010D8FC08; Sun, 8 Feb 2009 12:11:46 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from skuns.zoral.com.ua ([91.193.166.194] helo=mail.zoral.com.ua) by mail.terabit.net.ua with esmtps (TLSv1:AES256-SHA:256) (Exim 4.63 (FreeBSD)) (envelope-from ) id 1LW8Vl-0002ZX-LK; Sun, 08 Feb 2009 14:11:45 +0200 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 n18CBgmi048792 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 8 Feb 2009 14:11:43 +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 n18CBgq9076765; Sun, 8 Feb 2009 14:11:42 +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 n18CBgf0076762; Sun, 8 Feb 2009 14:11:42 +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: Sun, 8 Feb 2009 14:11:42 +0200 From: Kostik Belousov To: stable@freebsd.org, hackers@freebsd.org Message-ID: <20090208121142.GX9427@deviant.kiev.zoral.com.ua> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="Zll6mx50Q8J7qlLQ" Content-Disposition: inline User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on 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 X-Virus-Scanned: mail.terabit.net.ua 1LW8Vl-0002ZX-LK 44c56a764e0f31fb4b1e982e561e474f X-Terabit: YES Cc: Subject: Possible VFS KPI and KBI breakage on stable/7 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Feb 2009 12:11:47 -0000 --Zll6mx50Q8J7qlLQ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline There are three sets of changes that would benefit stable/7. Namely, there are 1. Improvements for the UFS unmount or rw->ro remount, that perform suspension during the operation. The changes depend on the the suspension mechanism path, that introduced the suspension owner, and added new VFS OP into the mount method table. This might also fix the hangs with gjournal or gjournal together with snapshots experienced by some users. Since the only real consumer of the suspension is UFS, I believe that MFC would have quite low impact, if any. Corresponding revision is 183073. 2. The openat(2) and similar syscalls. The new ZFS requires openat() functionality. We have to change struct nameidata to merge NDINIT_ATVP(). All modules using namei() need to be recompiled. 3. The Marcus' work on vn_fullpath() support for synthetic filesystems introduces new VOP, vop_vptocnp. This would allow procstat(1) to work on devfs and pseudofs vnodes. As I understand, this would also improve Gnome experience on FreeBSD. All fs modules need to be recompiled. There was one very magisterial voice that objected against KBI breakage on stable branch in principle. In my opinion, the benefits of the bug fixes and functionality improvements with the proposed merges are much greater then inconvenience of the need to recompile out-of-tree fs modules. Changes were discussed with re@ to some extent. In case there is vocal objection against the merge, I would abstain from doing this. --Zll6mx50Q8J7qlLQ Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (FreeBSD) iEYEARECAAYFAkmOy/0ACgkQC3+MBN1Mb4gcogCfSUjXSk3CsUNuDcr1eMvOB96O ER4AoPYtlw+M3VN8c21AxyVG6Vq0ZQck =aEg3 -----END PGP SIGNATURE----- --Zll6mx50Q8J7qlLQ-- From owner-freebsd-stable@FreeBSD.ORG Sun Feb 8 12:56:22 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1719D106564A for ; Sun, 8 Feb 2009 12:56:22 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id E58688FC16 for ; Sun, 8 Feb 2009 12:56:21 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by cyrus.watson.org (Postfix) with ESMTPS id 83A4A46B09; Sun, 8 Feb 2009 07:56:21 -0500 (EST) Date: Sun, 8 Feb 2009 12:56:21 +0000 (GMT) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Peter Jeremy In-Reply-To: <20090208104253.GB31876@test71.vk2pj.dyndns.org> Message-ID: References: <20090208091656.GA31876@test71.vk2pj.dyndns.org> <20090208104253.GB31876@test71.vk2pj.dyndns.org> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-stable@freebsd.org Subject: Re: impossible packet length ... X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Feb 2009 12:56:22 -0000 On Sun, 8 Feb 2009, Peter Jeremy wrote: > On 2009-Feb-08 11:31:45 +0200, Danny Braniss wrote: >> Q: with rxcsum on, and a bad checksum packet is received, is it >> dropped by the NIC? if not, then it somewhat explains the behaviour > > If checksum offloading is working correctly then a bad packet should be > dropped by the NIC. If checksum offloading isn't working correctly then you > can wind up in the situation where both the NIC and the driver think the > other party has verified the checksum. It's also possible that you may be > running into corruption during DMA transfer from the NIC to RAM. ISTR there > have been some issues reported recently with checksum offloading on some > NICs - though I don't have details to hand - you might like to search the > lists. > >> changing the nic is tough, but if needed will be done. > > If disabling checksum offloading fixes the problem and the additional CPU > load is acceptable (at least until you find a real fix) then there's no need > to change NICs. Actually, my understanding was that packets with bad checksums are delivered to software, and flag the descriptor ring header for each packet tells us whether the checksum was (a) checked and (b) validated by the hardware. We then propagate these to mbuf flags so that higher stack layers know whether or not to calculate the checksum themselves. Regardless of the specifics, though, packets with checked but bad checksums shouldn't make it to the socket layer where they would be visible to NFS. If the NIC is marking apparently bad packets as good, there are a number of possible sources -- be it bad checksum handling in the card, corruption between the card and higher levels of the stack (a DMA problem, as you point out, would have this symptom). Robert N M Watson Computer Laboratory University of Cambridge From owner-freebsd-stable@FreeBSD.ORG Sun Feb 8 13:12:00 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5D04E106573C; Sun, 8 Feb 2009 13:12:00 +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 225FA8FC21; Sun, 8 Feb 2009 13:12:00 +0000 (UTC) (envelope-from petefrench@ticketswitch.com) 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 1LW9Ru-0000lp-8M; Sun, 08 Feb 2009 13:11:50 +0000 Received: from petefrench by dilbert.ticketswitch.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1LW9Ru-000Bgv-6a; Sun, 08 Feb 2009 13:11:50 +0000 To: freebsd-stable@freebsd.org, rwatson@FreeBSD.org In-Reply-To: Message-Id: From: Pete French Date: Sun, 08 Feb 2009 13:11:50 +0000 Cc: Subject: Re: Big problems with 7.1 locking up :-( X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Feb 2009 13:12:01 -0000 > load. Kip Macy has corrected at least one (both?) problems in head, and > plans to MFC the fixes in the near future. We'll follow up further once > the fixes are merged, and if any further problems transpire. Hi, just wondering if we are any closer to having the MFC for this yet, or if there are any patches I could test ? cheers, -pete. From owner-freebsd-stable@FreeBSD.ORG Sun Feb 8 13:16:17 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 11828106566B; Sun, 8 Feb 2009 13:16:17 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from kabab.cs.huji.ac.il (kabab.cs.huji.ac.il [132.65.16.84]) by mx1.freebsd.org (Postfix) with ESMTP id AEEDE8FC68; Sun, 8 Feb 2009 13:16:16 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from pampa.cs.huji.ac.il ([132.65.80.32]) by kabab.cs.huji.ac.il with esmtp id 1LW9WA-0003Fu-O4; Sun, 08 Feb 2009 15:16:14 +0200 X-Mailer: exmh version 2.7.2 01/07/2005 with nmh-1.2 To: Robert Watson In-reply-to: References: <20090208091656.GA31876@test71.vk2pj.dyndns.org> <20090208104253.GB31876@test71.vk2pj.dyndns.org> Comments: In-reply-to Robert Watson message dated "Sun, 08 Feb 2009 12:56:21 +0000." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 08 Feb 2009 15:16:14 +0200 From: Danny Braniss Message-ID: Cc: Peter Jeremy , freebsd-stable@freebsd.org Subject: Re: impossible packet length ... X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Feb 2009 13:16:17 -0000 > On Sun, 8 Feb 2009, Peter Jeremy wrote: > > > On 2009-Feb-08 11:31:45 +0200, Danny Braniss wrote: > >> Q: with rxcsum on, and a bad checksum packet is received, is it > >> dropped by the NIC? if not, then it somewhat explains the behaviour > > > > If checksum offloading is working correctly then a bad packet should be > > dropped by the NIC. If checksum offloading isn't working correctly then you > > can wind up in the situation where both the NIC and the driver think the > > other party has verified the checksum. It's also possible that you may be > > running into corruption during DMA transfer from the NIC to RAM. ISTR there > > have been some issues reported recently with checksum offloading on some > > NICs - though I don't have details to hand - you might like to search the > > lists. > > > >> changing the nic is tough, but if needed will be done. > > > > If disabling checksum offloading fixes the problem and the additional CPU > > load is acceptable (at least until you find a real fix) then there's no need > > to change NICs. > > Actually, my understanding was that packets with bad checksums are delivered > to software, and flag the descriptor ring header for each packet tells us > whether the checksum was (a) checked and (b) validated by the hardware. We > then propagate these to mbuf flags so that higher stack layers know whether or > not to calculate the checksum themselves. Regardless of the specifics, > though, packets with checked but bad checksums shouldn't make it to the socket > layer where they would be visible to NFS. If the NIC is marking apparently > bad packets as good, there are a number of possible sources -- be it bad > checksum handling in the card, corruption between the card and higher levels > of the stack (a DMA problem, as you point out, would have this symptom). looking at the bce source, it's not clear (to me :-). If errors are detected in bce_rx_intr(), the packet gets dropped, which I would expect to be the treatment of an offloded chekcum error, but it seems that is not the case. danny From owner-freebsd-stable@FreeBSD.ORG Sun Feb 8 13:19:16 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2CC221065744 for ; Sun, 8 Feb 2009 13:19:16 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id D5D808FCB5 for ; Sun, 8 Feb 2009 13:18:57 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by cyrus.watson.org (Postfix) with ESMTPS id 6906F46B0D; Sun, 8 Feb 2009 08:18:57 -0500 (EST) Date: Sun, 8 Feb 2009 13:18:57 +0000 (GMT) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Danny Braniss In-Reply-To: Message-ID: References: <20090208091656.GA31876@test71.vk2pj.dyndns.org> <20090208104253.GB31876@test71.vk2pj.dyndns.org> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Peter Jeremy , freebsd-stable@freebsd.org Subject: Re: impossible packet length ... X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Feb 2009 13:19:24 -0000 On Sun, 8 Feb 2009, Danny Braniss wrote: > looking at the bce source, it's not clear (to me :-). If errors are detected > in bce_rx_intr(), the packet gets dropped, which I would expect to be the > treatment of an offloded chekcum error, but it seems that is not the case. I think we're thinking of different checksums -- devices/device drivers drop frames with bad ethernet checksums, but not IP and above layer checksums. Robert N M Watson Computer Laboratory University of Cambridge From owner-freebsd-stable@FreeBSD.ORG Sun Feb 8 13:39:24 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C7315106578B; Sun, 8 Feb 2009 13:39:24 +0000 (UTC) (envelope-from peter@vk2pj.dyndns.org) Received: from fallbackmx06.syd.optusnet.com.au (fallbackmx06.syd.optusnet.com.au [211.29.132.8]) by mx1.freebsd.org (Postfix) with ESMTP id 565958FC19; Sun, 8 Feb 2009 13:39:23 +0000 (UTC) (envelope-from peter@vk2pj.dyndns.org) Received: from mail17.syd.optusnet.com.au (mail17.syd.optusnet.com.au [211.29.132.198]) by fallbackmx06.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id n189HRv8015816; Sun, 8 Feb 2009 20:17:29 +1100 Received: from test71.vk2pj.dyndns.org (c122-106-216-167.belrs3.nsw.optusnet.com.au [122.106.216.167]) by mail17.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id n189Gv6d006676 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 8 Feb 2009 20:16:58 +1100 X-Bogosity: Ham, spamicity=0.000000 Received: from test71.vk2pj.dyndns.org (localhost.vk2pj.dyndns.org [127.0.0.1]) by test71.vk2pj.dyndns.org (8.14.3/8.14.3) with ESMTP id n189GuDa064604; Sun, 8 Feb 2009 20:16:56 +1100 (EST) (envelope-from peter@test71.vk2pj.dyndns.org) Received: (from peter@localhost) by test71.vk2pj.dyndns.org (8.14.3/8.14.3/Submit) id n189GuxW064603; Sun, 8 Feb 2009 20:16:56 +1100 (EST) (envelope-from peter) Date: Sun, 8 Feb 2009 20:16:56 +1100 From: Peter Jeremy To: Danny Braniss Message-ID: <20090208091656.GA31876@test71.vk2pj.dyndns.org> References: MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="jI8keyz6grp/JLjh" Content-Disposition: inline In-Reply-To: X-PGP-Key: http://members.optusnet.com.au/peterjeremy/pubkey.asc User-Agent: Mutt/1.5.18 (2008-05-17) Cc: hackers@freebsd.org, freebsd-stable@freebsd.org Subject: Re: impossible packet length ... X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Feb 2009 13:39:25 -0000 --jI8keyz6grp/JLjh Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 2009-Feb-08 10:45:13 +0200, Danny Braniss wrote: >Feb 6 18:00:13 warhol-00.cs.huji.ac.il kernel: bce0: discard frame w/o=20 >leading ethernet header (len 0 pkt len 0) =2E.. >Feb 6 19:00:00 warhol-00.cs.huji.ac.il amd[715]: Unknown $ sequence in=20 >"rhost:=3D${RHOST};type:=3Dnfsl;fs:=3D${FS};rfs:=3D$huldig#^ZM-^KoM- a= base" >Feb 6 19:00:00 warhol-00.cs.huji.ac.il kernel: impossible packet length= =20 >(2068989523) from nfs server sunfire:/dist > >which seems to point fingers at bce... It does rather suggest that bce is not behaving. What happens if you turn off checksum off-loading? This should make the kernel drop the corrupt packets instead of trying to process them. If practical, you could also try (temporarily) plugging in a different NIC. --=20 Peter Jeremy --jI8keyz6grp/JLjh Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.10 (FreeBSD) iEYEARECAAYFAkmOowgACgkQ/opHv/APuIezPgCZAfCn11OW1g/XoLQ7O0NXfWNe Re4AoIij1aRiYCYM+YTXlg01ZPtDrUVa =Qm+c -----END PGP SIGNATURE----- --jI8keyz6grp/JLjh-- From owner-freebsd-stable@FreeBSD.ORG Sun Feb 8 13:45:19 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2F5A9106566C; Sun, 8 Feb 2009 13:45:19 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from kabab.cs.huji.ac.il (kabab.cs.huji.ac.il [132.65.16.84]) by mx1.freebsd.org (Postfix) with ESMTP id D524E8FC1A; Sun, 8 Feb 2009 13:45:18 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from pampa.cs.huji.ac.il ([132.65.80.32]) by kabab.cs.huji.ac.il with esmtp id 1LW9yH-0003Xm-KS; Sun, 08 Feb 2009 15:45:17 +0200 X-Mailer: exmh version 2.7.2 01/07/2005 with nmh-1.2 To: Robert Watson In-reply-to: References: <20090208091656.GA31876@test71.vk2pj.dyndns.org> <20090208104253.GB31876@test71.vk2pj.dyndns.org> Comments: In-reply-to Robert Watson message dated "Sun, 08 Feb 2009 13:18:57 +0000." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 08 Feb 2009 15:45:17 +0200 From: Danny Braniss Message-ID: Cc: Peter Jeremy , freebsd-stable@freebsd.org Subject: Re: impossible packet length ... X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Feb 2009 13:45:19 -0000 > > On Sun, 8 Feb 2009, Danny Braniss wrote: > > > looking at the bce source, it's not clear (to me :-). If errors are detected > > in bce_rx_intr(), the packet gets dropped, which I would expect to be the > > treatment of an offloded chekcum error, but it seems that is not the case. > > I think we're thinking of different checksums -- devices/device drivers drop > frames with bad ethernet checksums, but not IP and above layer checksums. I know I'm stepping on thin ice hear - haven't touched Stevens for a while, (and I doubt it mentions offloading), but if the offload checksum is bad, why not just drop the packet? The way I read the driver, if the offload checksum is on, and if no errors where detected, then it's marked as ok. danny From owner-freebsd-stable@FreeBSD.ORG Sun Feb 8 14:33:33 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EEC4B106568E for ; Sun, 8 Feb 2009 14:33:33 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id AE8FD8FC22 for ; Sun, 8 Feb 2009 14:33:33 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by cyrus.watson.org (Postfix) with ESMTPS id 5CF9946B17; Sun, 8 Feb 2009 09:33:33 -0500 (EST) Date: Sun, 8 Feb 2009 14:33:33 +0000 (GMT) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Danny Braniss In-Reply-To: Message-ID: References: <20090208091656.GA31876@test71.vk2pj.dyndns.org> <20090208104253.GB31876@test71.vk2pj.dyndns.org> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Peter Jeremy , freebsd-stable@freebsd.org Subject: Re: impossible packet length ... X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Feb 2009 14:33:34 -0000 On Sun, 8 Feb 2009, Danny Braniss wrote: >> On Sun, 8 Feb 2009, Danny Braniss wrote: >> >>> looking at the bce source, it's not clear (to me :-). If errors are >>> detected in bce_rx_intr(), the packet gets dropped, which I would expect >>> to be the treatment of an offloded chekcum error, but it seems that is not >>> the case. >> >> I think we're thinking of different checksums -- devices/device drivers >> drop frames with bad ethernet checksums, but not IP and above layer >> checksums. > > I know I'm stepping on thin ice hear - haven't touched Stevens for a while, > (and I doubt it mentions offloading), but if the offload checksum is bad, > why not just drop the packet? > > The way I read the driver, if the offload checksum is on, and if no errors > where detected, then it's marked as ok. There are a few good reasons I can think of, but this is hardly a comprehensive list: (1) If there are bad higher level checksums on the wire, you want to see them in tcpdump, so allow them to get up to a higher layer if network layer checksums aren't good. (2) It's a matter of local policy as to whether UDP checksums (for example) are observed or not. (3) If you're forwarding or bridging packets, it should be up to the end nodes how they deal with bad UDP checksums on packets to them, not the routers. Looking at if_bce.c, the following seems to be reasonable logic; first, ethernet-layer checksums: 5902 /* Check the received frame for errors. */ 5903 if (status & (L2_FHDR_ERRORS_BAD_CRC | 5904 L2_FHDR_ERRORS_PHY_DECODE | L2_FHDR_ERRORS_ALIGNMENT | 5905 L2_FHDR_ERRORS_TOO_SHORT | L2_FHDR_ERRORS_GIANT_FRAME)) { 5906 5907 /* Log the error and release the mbuf. */ 5908 ifp->if_ierrors++; 5909 DBRUN(sc->l2fhdr_status_errors++); 5910 5911 m_freem(m0); 5912 m0 = NULL; 5913 goto bce_rx_int_next_rx; 5914 } I.e., if there are ethernet-level CRC failures, drop the packet. 5922 /* Validate the checksum if offload enabled. */ 5923 if (ifp->if_capenable & IFCAP_RXCSUM) { 5924 5925 /* Check for an IP datagram. */ 5926 if (!(status & L2_FHDR_STATUS_SPLIT) && 5927 (status & L2_FHDR_STATUS_IP_DATAGRAM)) { 5928 m0->m_pkthdr.csum_flags |= CSUM_IP_CHECKED; 5929 5930 /* Check if the IP checksum is valid. */ 5931 if ((l2fhdr->l2_fhdr_ip_xsum ^ 0xffff) == 0) 5932 m0->m_pkthdr.csum_flags |= CSUM_IP_VALID; 5933 } 5934 5935 /* Check for a valid TCP/UDP frame. */ 5936 if (status & (L2_FHDR_STATUS_TCP_SEGMENT | 5937 L2_FHDR_STATUS_UDP_DATAGRAM)) { 5938 5939 /* Check for a good TCP/UDP checksum. */ 5940 if ((status & (L2_FHDR_ERRORS_TCP_XSUM | 5941 L2_FHDR_ERRORS_UDP_XSUM)) == 0) { 5942 m0->m_pkthdr.csum_data = 5943 l2fhdr->l2_fhdr_tcp_udp_xsum; 5944 m0->m_pkthdr.csum_flags |= (CSUM_DATA_VALID 5945 | CSUM_PSEUDO_HDR); 5946 } 5947 } 5948 } Only look at higher level checksums if policy enables it on the interface; then, only if the hardware has a view on the IP-layer checksums, propagte that information to the mbuf flags from the descriptor ring entry flags, both whether or not the checksum was verified, and whether or not it was good. If policy disables it, or the hardware expresses no view, we don't set flags, which simply defers checksumming to a higher layer (if required -- for forwarded packets, we won't test UDP-layer checksums at all). Robert N M Watson Computer Laboratory University of Cambridge From owner-freebsd-stable@FreeBSD.ORG Sun Feb 8 15:27:22 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DBB6B106566B; Sun, 8 Feb 2009 15:27:22 +0000 (UTC) (envelope-from stefan.lambrev@moneybookers.com) Received: from blah.sun-fish.com (blah.sun-fish.com [217.18.249.150]) by mx1.freebsd.org (Postfix) with ESMTP id 194A78FC1D; Sun, 8 Feb 2009 15:27:21 +0000 (UTC) (envelope-from stefan.lambrev@moneybookers.com) Received: by blah.sun-fish.com (Postfix, from userid 1002) id E1FC71B11EE0; Sun, 8 Feb 2009 16:11:05 +0100 (CET) X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on malcho.cmotd.com X-Spam-Level: X-Spam-Status: No, score=-10.6 required=5.0 tests=ALL_TRUSTED,BAYES_00, HTML_MESSAGE autolearn=ham version=3.2.5 Received: from hater.cmotd.com (hater.cmotd.com [192.168.3.125]) by blah.sun-fish.com (Postfix) with ESMTP id B0DF51B11DD4; Sun, 8 Feb 2009 16:11:02 +0100 (CET) Message-Id: From: Stefan Lambrev To: Pete French In-Reply-To: Mime-Version: 1.0 (Apple Message framework v930.3) Date: Sun, 8 Feb 2009 17:11:02 +0200 References: X-Mailer: Apple Mail (2.930.3) X-Virus-Scanned: ClamAV version 0.94, clamav-milter version 0.94 on blah.cmotd.com X-Virus-Status: Clean Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: rwatson@FreeBSD.org, freebsd-stable@freebsd.org Subject: Re: Big problems with 7.1 locking up :-( X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Feb 2009 15:27:23 -0000 Hi all, In this thread someone mention a problem with soekris devices. I personally have one of those new soekris devices and installed 7.1R and it is very easy to freeze it. All that I have to do is to copy big file vfer WIFI (atheros) with speed higher then 1-2MB/s. It takes less then 2 minutes to freeze. I wonder if there is some improvement in 7.1-stable so I can try it or if I can help by compiling debug kernel? But I'm not sure if this is the same problem as it may be just the wireless driver in my case. On Feb 8, 2009, at 3:11 PM, Pete French wrote: >> load. Kip Macy has corrected at least one (both?) problems in >> head, and >> plans to MFC the fixes in the near future. We'll follow up further >> once >> the fixes are merged, and if any further problems transpire. > > Hi, just wondering if we are any closer to having the MFC for this > yet, or > if there are any patches I could test ? > > cheers, > > -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 > " -- Best Wishes, Stefan Lambrev ICQ# 24134177 From owner-freebsd-stable@FreeBSD.ORG Sun Feb 8 17:26:22 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1C7D31065674; Sun, 8 Feb 2009 17:26:22 +0000 (UTC) (envelope-from cpghost@cordula.ws) Received: from fw.farid-hajji.net (fw.farid-hajji.net [213.146.115.42]) by mx1.freebsd.org (Postfix) with ESMTP id 387768FC1B; Sun, 8 Feb 2009 17:26:21 +0000 (UTC) (envelope-from cpghost@cordula.ws) Received: from phenom.cordula.ws (phenom [192.168.254.60]) by fw.farid-hajji.net (Postfix) with ESMTP id 125DE31700; Sun, 8 Feb 2009 18:09:41 +0100 (CET) Date: Sun, 8 Feb 2009 18:09:41 +0100 From: cpghost To: Stefan Lambrev Message-ID: <20090208170941.GA3183@phenom.cordula.ws> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.18 (2008-05-17) Cc: freebsd-stable@freebsd.org, rwatson@FreeBSD.org, Pete French Subject: Re: Big problems with 7.1 locking up :-( X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Feb 2009 17:26:22 -0000 On Sun, Feb 08, 2009 at 05:11:02PM +0200, Stefan Lambrev wrote: > Hi all, > > In this thread someone mention a problem with soekris devices. > I personally have one of those new soekris devices and installed 7.1R > and it is very easy to freeze it. > All that I have to do is to copy big file vfer WIFI (atheros) with > speed higher then 1-2MB/s. > It takes less then 2 minutes to freeze. I wonder if there is some > improvement > in 7.1-stable so I can try it or if I can help by compiling debug > kernel? > But I'm not sure if this is the same problem as it may be just the > wireless driver in my case. One some net4801's without WIFI, I also experience frequent freezes after a couple of hours up to 2-5 days... so it's probably not only ath related. What's your kern.hz value? In my /boot/loader.conf, it is set to 100. Could you try it too, and see if you can still freeze the box (just to rule out some weird timing / interrupt issue)? > Best Wishes, > Stefan Lambrev > ICQ# 24134177 Regards, -cpghost. -- Cordula's Web. http://www.cordula.ws/ From owner-freebsd-stable@FreeBSD.ORG Sun Feb 8 20:28:50 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CF49A106566B; Sun, 8 Feb 2009 20:28:50 +0000 (UTC) (envelope-from mike@sentex.net) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.freebsd.org (Postfix) with ESMTP id 940E68FC0A; Sun, 8 Feb 2009 20:28:50 +0000 (UTC) (envelope-from mike@sentex.net) Received: from lava.sentex.ca (pyroxene.sentex.ca [199.212.134.18]) by smarthost1.sentex.ca (8.14.3/8.14.3) with ESMTP id n18KSm9E006705; Sun, 8 Feb 2009 15:28:48 -0500 (EST) (envelope-from mike@sentex.net) Received: from mdt-xp.sentex.net (simeon.sentex.ca [192.168.43.27]) by lava.sentex.ca (8.13.8/8.13.3) with ESMTP id n18KSl5S024058 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 8 Feb 2009 15:28:47 -0500 (EST) (envelope-from mike@sentex.net) Message-Id: <200902082028.n18KSl5S024058@lava.sentex.ca> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Sun, 08 Feb 2009 15:28:53 -0500 To: Stefan Lambrev From: Mike Tancsa In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Scanned-By: MIMEDefang 2.64 on 64.7.153.18 Cc: freebsd-stable@freebsd.org, rwatson@freebsd.org Subject: Re: Big problems with 7.1 locking up :-( X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Feb 2009 20:28:51 -0000 At 10:11 AM 2/8/2009, Stefan Lambrev wrote: >Hi all, > >In this thread someone mention a problem with soekris devices. >I personally have one of those new soekris devices and installed 7.1R >and it is very easy to freeze it. >All that I have to do is to copy big file vfer WIFI (atheros) with >speed higher then 1-2MB/s. Try and copy across the ethernet. I have several RELENG_7 boxes deployed on soekris and Alix boards (same chipset pretty well) and have not seen any stability issues. ---Mike From owner-freebsd-stable@FreeBSD.ORG Sun Feb 8 22:37:31 2009 Return-Path: Delivered-To: FreeBSD-stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C11CF106566C for ; Sun, 8 Feb 2009 22:37:31 +0000 (UTC) (envelope-from markir@paradise.net.nz) Received: from smtp5.clear.net.nz (smtp5.clear.net.nz [203.97.33.68]) by mx1.freebsd.org (Postfix) with ESMTP id 8C1078FC08 for ; Sun, 8 Feb 2009 22:37:31 +0000 (UTC) (envelope-from markir@paradise.net.nz) Received: from zmori.markir.net (121-73-179-120.dsl.telstraclear.net [121.73.179.120]) by smtp5.clear.net.nz (CLEAR Net Mail) with ESMTP id <0KER0001UQUHJ800@smtp5.clear.net.nz> for FreeBSD-stable@FreeBSD.org; Mon, 09 Feb 2009 11:37:30 +1300 (NZDT) Date: Mon, 09 Feb 2009 11:37:29 +1300 From: Mark Kirkwood In-reply-to: <498E59F0.30700@paradise.net.nz> To: FreeBSD-stable@FreeBSD.org Message-id: <498F5EA9.3020003@paradise.net.nz> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7bit References: <20090109171857.GA49752@marvin.eastcentral.edu> <4975ADF4.1070103@paradise.net.nz> <4976CB1C.7050409@paradise.net.nz> <498E59F0.30700@paradise.net.nz> User-Agent: Thunderbird 2.0.0.19 (X11/20090117) Cc: rizzo@iet.unipi.it Subject: Re: Broken loader on 7.1-STABLE? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Feb 2009 22:37:32 -0000 Mark Kirkwood wrote: > > ...specifying /boot/loader.old got me booted ok (not sure why this > *didn't* work with the Asus, maybe I need to try it again with the Feb > sources). > > I tried the latest RELENG_7 sources, same result - does *not* boot even specifying the old loader. I spent a bit of time narrowing down why. I'd previously noted that an empty loader.conf was sufficient to get it to boot again. After some experimentation I discovered that this line in loader.conf: sound_load="YES" made the boot with the old loader fail (loading the sound module after booting seems to work ok). The box is an Asus a8vx with amd64 x2 3800+, running i386. regards Mark From owner-freebsd-stable@FreeBSD.ORG Mon Feb 9 02:08:29 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 73910106566B for ; Mon, 9 Feb 2009 02:08:29 +0000 (UTC) (envelope-from bms@FreeBSD.org) Received: from out1.smtp.messagingengine.com (out1.smtp.messagingengine.com [66.111.4.25]) by mx1.freebsd.org (Postfix) with ESMTP id EC42C8FC0C for ; Mon, 9 Feb 2009 02:08:28 +0000 (UTC) (envelope-from bms@FreeBSD.org) Received: from compute1.internal (compute1.internal [10.202.2.41]) by out1.messagingengine.com (Postfix) with ESMTP id 5470B28FBE8; Sun, 8 Feb 2009 21:08:28 -0500 (EST) Received: from heartbeat1.messagingengine.com ([10.202.2.160]) by compute1.internal (MEProxy); Sun, 08 Feb 2009 21:08:28 -0500 X-Sasl-enc: 8Tx/Q9MSeUBSXBbCPO7+7e86+p1QxpnNJl2kG1V86rHU 1234145307 Received: from empiric.lon.incunabulum.net (82-35-112-254.cable.ubr07.dals.blueyonder.co.uk [82.35.112.254]) by mail.messagingengine.com (Postfix) with ESMTPSA id 5A249149F4; Sun, 8 Feb 2009 21:08:27 -0500 (EST) Message-ID: <498F901A.7000900@FreeBSD.org> Date: Mon, 09 Feb 2009 02:08:26 +0000 From: "Bruce M. Simpson" User-Agent: Thunderbird 2.0.0.19 (X11/20090126) MIME-Version: 1.0 To: freebsd-stable@freebsd.org References: <329181233306971@webmail57.yandex.ru> <985A59F2-20CC-4779-A000-018E52B5BFA9@jump-ing.de> <101781233319948@webmail36.yandex.ru> <4983A3AE.90804@FreeBSD.org> In-Reply-To: <4983A3AE.90804@FreeBSD.org> X-Enigmail-Version: 0.95.6 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "S.N.Grigoriev" , Markus Hitter , rnoland@FreeBSD.org Subject: Re: Unhappy Xorg upgrade X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Feb 2009 02:08:29 -0000 Bruce M. Simpson wrote: > S.N.Grigoriev wrote: >> I thank you for your response. I've applied the patch to pci.c from >> kern/130957. Unfortunately there are no positive results. USB is still >> unreachable with X. > > Just following up to confirm that you are seeing exactly the same > symptoms with USB and Xorg 7.4 as I see on my amd64 desktop running > 7-STABLE from 00:00 UTC on this Wednesday. I still see the USB symptoms with xorg-server port as of today -- forced rebuild with libpciaccess also. So amd64 is still regressed -- USB is totally unusable there after X is started. My theory was that somehow Xorg was stomping on the USB controller registers on this machine. The USB controller on this box is ALi, card=0x81561043. My i386 laptop (IBM/Lenovo T43) is not affected, and USB mice work just fine there. Obviously it's difficult to check what Xorg is actually doing to the registers on the box w/o a PCI bus analyzer, and of course due to normal decoding, those cycles probably won't be seen on the backplane itself as it sits behind a bridge; I haven't fully read what libpciaccess is doing. I skimmed patch-src-freebsd_pci.c. I wonder if this code may be stomping on the USB controller in some way (i.e. how it frobs the BARs). According to src/tools/tools/pciroms, the only PCI devices on this box with ROM BARs are mskc0 and vgapci0. (I also wonder if it's possible to guarantee that the window at 0xC0000 is always going to be available, even in the amd64 case.) cheers BMS From owner-freebsd-stable@FreeBSD.ORG Mon Feb 9 04:09:32 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D54861065674; Mon, 9 Feb 2009 04:09:32 +0000 (UTC) (envelope-from anderson@freebsd.org) Received: from ns.trinitel.com (186.161.36.72.static.reverse.ltdomains.com [72.36.161.186]) by mx1.freebsd.org (Postfix) with ESMTP id 484C98FC19; Mon, 9 Feb 2009 04:09:32 +0000 (UTC) (envelope-from anderson@freebsd.org) Received: from [10.0.7.197] (r74-193-77-79.pfvlcmta01.grtntx.tl.dh.suddenlink.net [74.193.77.79]) (authenticated bits=0) by ns.trinitel.com (8.14.1/8.14.1) with ESMTP id n193ImYQ045191; Sun, 8 Feb 2009 21:18:49 -0600 (CST) (envelope-from anderson@freebsd.org) Message-Id: <205598DD-B746-4236-9140-855811BAE21C@freebsd.org> From: Eric Anderson To: Danny Braniss In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Sun, 8 Feb 2009 21:47:01 -0600 References: <20090208091656.GA31876@test71.vk2pj.dyndns.org> X-Mailer: Apple Mail (2.930.3) X-Virus-Scanned: ClamAV 0.94.1/8966/Sun Feb 8 17:43:40 2009 on ns.trinitel.com X-Virus-Status: Clean X-Spam-Status: No, score=-0.8 required=5.0 tests=AWL,BAYES_50,RDNS_DYNAMIC autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on ns.trinitel.com Cc: Ross Dickey , Peter Jeremy , hackers@freebsd.org, freebsd-stable@freebsd.org Subject: Re: impossible packet length ... X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Feb 2009 04:09:34 -0000 On Feb 8, 2009, at 3:31 AM, Danny Braniss wrote: >> >> --jI8keyz6grp/JLjh >> Content-Type: text/plain; charset=us-ascii >> Content-Disposition: inline >> Content-Transfer-Encoding: quoted-printable >> >> On 2009-Feb-08 10:45:13 +0200, Danny Braniss >> wrote: >>> Feb 6 18:00:13 warhol-00.cs.huji.ac.il kernel: bce0: discard >>> frame w/o=20 >>> leading ethernet header (len 0 pkt len 0) >> =2E.. >>> Feb 6 19:00:00 warhol-00.cs.huji.ac.il amd[715]: Unknown $ >>> sequence in=20 >>> "rhost:=3D${RHOST};type:=3Dnfsl;fs:=3D${FS};rfs:=3D$huldig#^ZM- >>> ^KoM- a= >> base" >>> Feb 6 19:00:00 warhol-00.cs.huji.ac.il kernel: impossible packet >>> length= >> =20 >>> (2068989523) from nfs server sunfire:/dist >>> >>> which seems to point fingers at bce... >> >> It does rather suggest that bce is not behaving. What happens if you >> turn off checksum off-loading? This should make the kernel drop the >> corrupt packets instead of trying to process them. If practical, you >> could also try (temporarily) plugging in a different NIC. >> > I have, and now it's a matter of waiting... > Q: with rxcsum on, and a bad checksum packet is received, is it > dropped by the NIC? if not, then it somewhat explains the behaviour > > changing the nic is tough, but if needed will be done. > danny > >> Peter Jeremy We were hitting this quite a bit (also bce), and updated to a recent 7- branch and it seems to be behaving better for now. Running 12 days so far (which is better than what we had been seeing). Eric From owner-freebsd-stable@FreeBSD.ORG Mon Feb 9 04:31:46 2009 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 DE1F1106564A; Mon, 9 Feb 2009 04:31:46 +0000 (UTC) (envelope-from eugen@kuzbass.ru) Received: from www.svzserv.kemerovo.su (www.svzserv.kemerovo.su [213.184.65.80]) by mx1.freebsd.org (Postfix) with ESMTP id 4CACA8FC08; Mon, 9 Feb 2009 04:31:45 +0000 (UTC) (envelope-from eugen@kuzbass.ru) Received: from kuzbass.ru (kost [213.184.65.82]) by www.svzserv.kemerovo.su (8.13.8/8.13.8) with ESMTP id n1941lej098810; Mon, 9 Feb 2009 11:01:47 +0700 (KRAT) (envelope-from eugen@kuzbass.ru) Message-ID: <498FAA2A.7423AC15@kuzbass.ru> Date: Mon, 09 Feb 2009 10:59:38 +0700 From: Eugene Grosbein Organization: SVZServ X-Mailer: Mozilla 4.8 [en] (Windows NT 5.0; U) X-Accept-Language: ru,en MIME-Version: 1.0 To: stable@freebsd.org Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 7bit Cc: kib@freebsd.org Subject: sysctl lock in RELENG_6 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Feb 2009 04:31:47 -0000 Hi! I've RELENG_6 system controlling local PBX through RS-232 port, sio(4). It also runs syslogd, cron, sshd, bsnmpd and sendmail for outgoing reports. It locks very often: it answers to pings but PBX controlling software stops responding, local and remote login attempts hang due to 'login' process stuck in 'sysctl lock' state. Local consoles do switch with 'Alt-Fn' and DDB works. It shows that sendmail is in 'sysctl lock' state too. This is NanoBSD installation running from IDE flash, it's swapless but I think I could manage to obtain crashdump if there is an interest of it. I've digged commit logs a bit and found this change MFC'd to RELENG_7 but not RELENG_6: http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/kern/kern_sysctl.c#rev1.177.6.2 It seems RELENG_6 needs this too, doesn't it? I'm going to merge the change to RELENG_6 and give it a try. Eugene Grosbein From owner-freebsd-stable@FreeBSD.ORG Mon Feb 9 05:31:36 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5FD5A106566B; Mon, 9 Feb 2009 05:31:36 +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 22B278FC14; Mon, 9 Feb 2009 05:31:35 +0000 (UTC) (envelope-from rnoland@FreeBSD.org) Received: from [192.168.1.132] (adsl-1-207-86.bna.bellsouth.net [65.1.207.86]) (authenticated bits=0) by gizmo.2hip.net (8.14.3/8.14.3) with ESMTP id n195Uk5k044212 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 9 Feb 2009 00:30:50 -0500 (EST) (envelope-from rnoland@FreeBSD.org) From: Robert Noland To: "Bruce M. Simpson" In-Reply-To: <498F901A.7000900@FreeBSD.org> References: <329181233306971@webmail57.yandex.ru> <985A59F2-20CC-4779-A000-018E52B5BFA9@jump-ing.de> <101781233319948@webmail36.yandex.ru> <4983A3AE.90804@FreeBSD.org> <498F901A.7000900@FreeBSD.org> Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-+AeUqzg5hQKuhzZmvpkm" Organization: FreeBSD Date: Mon, 09 Feb 2009 00:31:20 -0500 Message-Id: <1234157480.16095.10.camel@ferret.2hip.net> Mime-Version: 1.0 X-Mailer: Evolution 2.24.3 FreeBSD GNOME Team Port X-Spam-Status: No, score=-0.8 required=5.0 tests=AWL,BAYES_00, MIME_QP_LONG_LINE, RCVD_IN_PBL, RCVD_IN_SORBS_DUL, RDNS_DYNAMIC autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on gizmo.2hip.net Cc: "S.N.Grigoriev" , Markus Hitter , freebsd-stable@freebsd.org Subject: Re: Unhappy Xorg upgrade X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Feb 2009 05:31:36 -0000 --=-+AeUqzg5hQKuhzZmvpkm Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Mon, 2009-02-09 at 02:08 +0000, Bruce M. Simpson wrote: > Bruce M. Simpson wrote: > > S.N.Grigoriev wrote: > >> I thank you for your response. I've applied the patch to pci.c from > >> kern/130957. Unfortunately there are no positive results. USB is still > >> unreachable with X. > > > > Just following up to confirm that you are seeing exactly the same=20 > > symptoms with USB and Xorg 7.4 as I see on my amd64 desktop running=20 > > 7-STABLE from 00:00 UTC on this Wednesday. >=20 > I still see the USB symptoms with xorg-server port as of today -- forced=20 > rebuild with libpciaccess also. So amd64 is still regressed -- USB is=20 > totally unusable there after X is started. My theory was that somehow=20 > Xorg was stomping on the USB controller registers on this machine. The=20 > USB controller on this box is ALi, card=3D0x81561043. >=20 > My i386 laptop (IBM/Lenovo T43) is not affected, and USB mice work just=20 > fine there. >=20 > Obviously it's difficult to check what Xorg is actually doing to the=20 > registers on the box w/o a PCI bus analyzer, and of course due to normal=20 > decoding, those cycles probably won't be seen on the backplane itself as=20 > it sits behind a bridge; I haven't fully read what libpciaccess is doing. >=20 > I skimmed patch-src-freebsd_pci.c. I wonder if this code may be stomping=20 > on the USB controller in some way (i.e. how it frobs the BARs). Until last night, it only probed pci resources for pci class DISPLAY subclass VGA. The rom reading was restricted to 0xc0000/0x10000, which it mmap and copied out to a userland buffer. As of last night, I committed the code that actually checks for a pci rom. If it finds one, it uses those values (base address, length) to mmap the bios for copy. If it doesn't find a pci rom, (most IGDs (intel, via, sis) it just uses the 0xc0000 mapping as it did before if it is i386 or amd64. Otherwise, bios reading just fails. robert. > According to src/tools/tools/pciroms, the only PCI devices on this box=20 > with ROM BARs are mskc0 and vgapci0. >=20 > (I also wonder if it's possible to guarantee that the window at 0xC0000=20 > is always going to be available, even in the amd64 case.) >=20 > cheers > BMS --=20 Robert Noland FreeBSD --=-+AeUqzg5hQKuhzZmvpkm Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.10 (FreeBSD) iEYEABECAAYFAkmPv6cACgkQM4TrQ4qfRONMTQCffZovocZrSYn6vxPOSZRKlg6G OrUAn167tkhAJzKSS84Nu04kCzrdNdGR =bxoE -----END PGP SIGNATURE----- --=-+AeUqzg5hQKuhzZmvpkm-- From owner-freebsd-stable@FreeBSD.ORG Mon Feb 9 06:00:49 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BB34C106564A; Mon, 9 Feb 2009 06:00:49 +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 7EDF68FC17; Mon, 9 Feb 2009 06:00:49 +0000 (UTC) (envelope-from rnoland@FreeBSD.org) Received: from [192.168.1.132] (adsl-1-207-86.bna.bellsouth.net [65.1.207.86]) (authenticated bits=0) by gizmo.2hip.net (8.14.3/8.14.3) with ESMTP id n19602MD044342 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 9 Feb 2009 01:00:06 -0500 (EST) (envelope-from rnoland@FreeBSD.org) From: Robert Noland To: "Bruce M. Simpson" In-Reply-To: <498F901A.7000900@FreeBSD.org> References: <329181233306971@webmail57.yandex.ru> <985A59F2-20CC-4779-A000-018E52B5BFA9@jump-ing.de> <101781233319948@webmail36.yandex.ru> <4983A3AE.90804@FreeBSD.org> <498F901A.7000900@FreeBSD.org> Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-gOszhsnuOinBWQrHk+a9" Organization: FreeBSD Date: Mon, 09 Feb 2009 01:00:36 -0500 Message-Id: <1234159237.23838.3.camel@ferret.2hip.net> Mime-Version: 1.0 X-Mailer: Evolution 2.24.3 FreeBSD GNOME Team Port X-Spam-Status: No, score=-0.8 required=5.0 tests=AWL,BAYES_00, MIME_QP_LONG_LINE, RCVD_IN_PBL, RCVD_IN_SORBS_DUL, RDNS_DYNAMIC autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on gizmo.2hip.net Cc: "S.N.Grigoriev" , Markus Hitter , freebsd-stable@freebsd.org Subject: Re: Unhappy Xorg upgrade X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Feb 2009 06:00:50 -0000 --=-gOszhsnuOinBWQrHk+a9 Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Mon, 2009-02-09 at 02:08 +0000, Bruce M. Simpson wrote: > Bruce M. Simpson wrote: > > S.N.Grigoriev wrote: > >> I thank you for your response. I've applied the patch to pci.c from > >> kern/130957. Unfortunately there are no positive results. USB is still > >> unreachable with X. > > > > Just following up to confirm that you are seeing exactly the same=20 > > symptoms with USB and Xorg 7.4 as I see on my amd64 desktop running=20 > > 7-STABLE from 00:00 UTC on this Wednesday. >=20 > I still see the USB symptoms with xorg-server port as of today -- forced=20 > rebuild with libpciaccess also. So amd64 is still regressed -- USB is=20 > totally unusable there after X is started. My theory was that somehow=20 > Xorg was stomping on the USB controller registers on this machine. The=20 > USB controller on this box is ALi, card=3D0x81561043. Is your usb sharing interrupts with the video card? Does the issue occur if you aren't using a usb mouse? robert. > My i386 laptop (IBM/Lenovo T43) is not affected, and USB mice work just=20 > fine there. >=20 > Obviously it's difficult to check what Xorg is actually doing to the=20 > registers on the box w/o a PCI bus analyzer, and of course due to normal=20 > decoding, those cycles probably won't be seen on the backplane itself as=20 > it sits behind a bridge; I haven't fully read what libpciaccess is doing. >=20 > I skimmed patch-src-freebsd_pci.c. I wonder if this code may be stomping=20 > on the USB controller in some way (i.e. how it frobs the BARs). >=20 > According to src/tools/tools/pciroms, the only PCI devices on this box=20 > with ROM BARs are mskc0 and vgapci0. >=20 > (I also wonder if it's possible to guarantee that the window at 0xC0000=20 > is always going to be available, even in the amd64 case.) >=20 > cheers > BMS --=20 Robert Noland FreeBSD --=-gOszhsnuOinBWQrHk+a9 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.10 (FreeBSD) iEYEABECAAYFAkmPxoQACgkQM4TrQ4qfROMuwgCeIaPqbNQ6akY11b6G1EeB3/Vv M4oAn0S5j8Ls7rEkEQhYCpxta/k+dJYR =Jf7L -----END PGP SIGNATURE----- --=-gOszhsnuOinBWQrHk+a9-- From owner-freebsd-stable@FreeBSD.ORG Mon Feb 9 06:13:13 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 62730106564A for ; Mon, 9 Feb 2009 06:13:13 +0000 (UTC) (envelope-from spork@bway.net) Received: from xena.bway.net (xena.bway.net [216.220.96.26]) by mx1.freebsd.org (Postfix) with ESMTP id 2B6688FC17 for ; Mon, 9 Feb 2009 06:13:12 +0000 (UTC) (envelope-from spork@bway.net) Received: (qmail 81335 invoked by uid 0); 9 Feb 2009 06:13:12 -0000 Received: from unknown (HELO toasty.nat.fasttrackmonkey.com) (spork@96.57.144.66) by smtp.bway.net with (DHE-RSA-AES256-SHA encrypted) SMTP; 9 Feb 2009 06:13:12 -0000 Date: Mon, 9 Feb 2009 01:13:08 -0500 (EST) From: Charles Sprickman X-X-Sender: spork@toasty.nat.fasttrackmonkey.com To: freebsd-stable@freebsd.org Message-ID: User-Agent: Alpine 2.00 (OSX 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII Subject: 7.1 Panic on degraded disk w/mpt X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Feb 2009 06:13:13 -0000 Howdy, I dug around and can't find a PR on this, and the only other report I saw was in this mailing list post that has no replies: http://www.nabble.com/7.1-BETA2-panic-on-mpt-degrade-td20183173.html The hardware is a Dell PowerEdge 860 with the Dell/LSI SAS5 controller: mpt0: port 0xec00-0xecff mem 0xfe9fc000-0xfe9fffff,0xfe9e0000-0xfe9effff irq 16 at device 8.0 on pci2 mpt0: MPI Version=1.5.13.0 The panic is repeatable by forcing the array into a degraded state. Here's my best shot at getting info out of kgdb: [root@uniweb /home/spork]# cd /usr/obj/usr/src/sys/BWAY7/ [root@uniweb /usr/obj/usr/src/sys/BWAY7]# kgdb kernel.debug /var/crash/vmcore.0 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 "i386-marcel-freebsd"... Unread portion of the kernel message buffer: Fatal trap 12: page fault while in kernel mode cpuid = 0; apic id = 00 fault virtual address = 0x14 fault code = supervisor read, page not present instruction pointer = 0x20:0xc044b09b stack pointer = 0x28:0xe6ee5b80 frame pointer = 0x28:0xe6ee5b9c code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 17 (swi2: cambio) trap number = 12 panic: page fault cpuid = 0 Uptime: 3m7s Physical memory: 3575 MB Dumping 94 MB: 79 63 47 31 15 Reading symbols from /boot/kernel/acpi.ko...Reading symbols from /boot/kernel/acpi.ko.symbols...done. done. Loaded symbols for /boot/kernel/acpi.ko #0 doadump () at pcpu.h:196 196 __asm __volatile("movl %%fs:0,%0" : "=r" (td)); (kgdb) list *0xc044b09b 0xc044b09b is in xpt_done (/usr/src/sys/cam/cam_xpt.c:4832). 4827 if ((done_ccb->ccb_h.func_code & XPT_FC_QUEUED) != 0) { 4828 /* 4829 * Queue up the request for handling by our SWI handler 4830 * any of the "non-immediate" type of ccbs. 4831 */ 4832 sim = done_ccb->ccb_h.path->bus->sim; 4833 switch (done_ccb->ccb_h.path->periph->type) { 4834 case CAM_PERIPH_BIO: 4835 TAILQ_INSERT_TAIL(&sim->sim_doneq, &done_ccb->ccb_h, 4836 sim_links.tqe); (kgdb) backtrace #0 doadump () at pcpu.h:196 #1 0xc061d0f7 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:418 #2 0xc061d3c9 in panic (fmt=Variable "fmt" is not available. ) at /usr/src/sys/kern/kern_shutdown.c:574 #3 0xc0865fcc in trap_fatal (frame=0xe6ee5b40, eva=20) at /usr/src/sys/i386/i386/trap.c:939 #4 0xc0866230 in trap_pfault (frame=0xe6ee5b40, usermode=0, eva=20) at /usr/src/sys/i386/i386/trap.c:852 #5 0xc0866bc2 in trap (frame=0xe6ee5b40) at /usr/src/sys/i386/i386/trap.c:530 #6 0xc084d45b in calltrap () at /usr/src/sys/i386/i386/exception.s:159 #7 0xc044b09b in xpt_done (done_ccb=0xc6bf5000) at /usr/src/sys/cam/cam_xpt.c:4832 #8 0xc044eee9 in xpt_scan_bus (periph=0xc6984b00, request_ccb=0xc6bf5000) at /usr/src/sys/cam/cam_xpt.c:5395 #9 0xc044d241 in camisr_runqueue (V_queue=Variable "V_queue" is not available. ) at /usr/src/sys/cam/cam_xpt.c:7316 #10 0xc044d39e in camisr (dummy=0x0) at /usr/src/sys/cam/cam_xpt.c:7216 #11 0xc05fb41b in ithread_loop (arg=0xc699d770) at /usr/src/sys/kern/kern_intr.c:1088 #12 0xc05f7f69 in fork_exit (callout=0xc05fb260 , arg=0xc699d770, frame=0xe6ee5d38) at /usr/src/sys/kern/kern_fork.c:810 #13 0xc084d4d0 in fork_trampoline () at /usr/src/sys/i386/i386/exception.s:264 I can supply dmesg, more info, make it crash more, etc. I suspect it will panic again when the rebuild completes, I'll capture that one as well. Please let me know how to proceed - I can open a PR if this is truly a bug, or bring it over to freebsd-scsi if more appropriate. Thanks, Charles ___ Charles Sprickman NetEng/SysAdmin Bway.net - New York's Best Internet - www.bway.net spork@bway.net - 212.655.9344 From owner-freebsd-stable@FreeBSD.ORG Mon Feb 9 06:46:14 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6B3611065672; Mon, 9 Feb 2009 06:46:14 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from kabab.cs.huji.ac.il (kabab.cs.huji.ac.il [132.65.16.84]) by mx1.freebsd.org (Postfix) with ESMTP id 1AA208FC1A; Mon, 9 Feb 2009 06:46:14 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from pampa.cs.huji.ac.il ([132.65.80.32]) by kabab.cs.huji.ac.il with esmtp id 1LWPuG-000DW9-96; Mon, 09 Feb 2009 08:46:12 +0200 X-Mailer: exmh version 2.7.2 01/07/2005 with nmh-1.2 To: Robert Watson In-reply-to: References: <20090208091656.GA31876@test71.vk2pj.dyndns.org> <20090208104253.GB31876@test71.vk2pj.dyndns.org> Comments: In-reply-to Robert Watson message dated "Sun, 08 Feb 2009 14:33:33 +0000." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 09 Feb 2009 08:46:12 +0200 From: Danny Braniss Message-ID: Cc: Peter Jeremy , freebsd-stable@freebsd.org Subject: Re: impossible packet length ... X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Feb 2009 06:46:14 -0000 > > On Sun, 8 Feb 2009, Danny Braniss wrote: > > >> On Sun, 8 Feb 2009, Danny Braniss wrote: > >> > >>> looking at the bce source, it's not clear (to me :-). If errors are > >>> detected in bce_rx_intr(), the packet gets dropped, which I would expect > >>> to be the treatment of an offloded chekcum error, but it seems that is not > >>> the case. > >> > >> I think we're thinking of different checksums -- devices/device drivers > >> drop frames with bad ethernet checksums, but not IP and above layer > >> checksums. > > > > I know I'm stepping on thin ice hear - haven't touched Stevens for a while, > > (and I doubt it mentions offloading), but if the offload checksum is bad, > > why not just drop the packet? > > > > The way I read the driver, if the offload checksum is on, and if no errors > > where detected, then it's marked as ok. > > There are a few good reasons I can think of, but this is hardly a > comprehensive list: > > (1) If there are bad higher level checksums on the wire, you want to see them > in tcpdump, so allow them to get up to a higher layer if network layer > checksums aren't good. > > (2) It's a matter of local policy as to whether UDP checksums (for example) > are observed or not. > > (3) If you're forwarding or bridging packets, it should be up to the end nodes > how they deal with bad UDP checksums on packets to them, not the routers. ok, I can understand the logic. > > Looking at if_bce.c, the following seems to be reasonable logic; first, > ethernet-layer checksums: > > 5902 /* Check the received frame for errors. */ > 5903 if (status & (L2_FHDR_ERRORS_BAD_CRC | > 5904 L2_FHDR_ERRORS_PHY_DECODE | > L2_FHDR_ERRORS_ALIGNMENT | > 5905 L2_FHDR_ERRORS_TOO_SHORT | > L2_FHDR_ERRORS_GIANT_FRAME)) { > 5906 > 5907 /* Log the error and release the mbuf. */ > 5908 ifp->if_ierrors++; > 5909 DBRUN(sc->l2fhdr_status_errors++); > 5910 > 5911 m_freem(m0); > 5912 m0 = NULL; > 5913 goto bce_rx_int_next_rx; > 5914 } > > I.e., if there are ethernet-level CRC failures, drop the packet. > > 5922 /* Validate the checksum if offload enabled. */ > 5923 if (ifp->if_capenable & IFCAP_RXCSUM) { > 5924 > 5925 /* Check for an IP datagram. */ > 5926 if (!(status & L2_FHDR_STATUS_SPLIT) && > 5927 (status & L2_FHDR_STATUS_IP_DATAGRAM)) { > 5928 m0->m_pkthdr.csum_flags |= > CSUM_IP_CHECKED; > 5929 > 5930 /* Check if the IP checksum is valid. */ > 5931 if ((l2fhdr->l2_fhdr_ip_xsum ^ 0xffff) == > 0) > 5932 m0->m_pkthdr.csum_flags |= > CSUM_IP_VALID; > 5933 } > 5934 > 5935 /* Check for a valid TCP/UDP frame. */ > 5936 if (status & (L2_FHDR_STATUS_TCP_SEGMENT | > 5937 L2_FHDR_STATUS_UDP_DATAGRAM)) { > 5938 > 5939 /* Check for a good TCP/UDP checksum. */ > 5940 if ((status & (L2_FHDR_ERRORS_TCP_XSUM | > 5941 L2_FHDR_ERRORS_UDP_XSUM)) > == 0) { > 5942 m0->m_pkthdr.csum_data = > 5943 l2fhdr->l2_fhdr_tcp_udp_xsum; > 5944 m0->m_pkthdr.csum_flags |= > (CSUM_DATA_VALID > 5945 | CSUM_PSEUDO_HDR); > 5946 } > 5947 } > 5948 } > > Only look at higher level checksums if policy enables it on the interface; > then, only if the hardware has a view on the IP-layer checksums, propagte that > information to the mbuf flags from the descriptor ring entry flags, both > whether or not the checksum was verified, and whether or not it was good. If > policy disables it, or the hardware expresses no view, we don't set flags, > which simply defers checksumming to a higher layer (if required -- for > forwarded packets, we won't test UDP-layer checksums at all). I missed line 5928, and as usual, your explanation is most educational! The comment in line 5939 is a bit missleading, the way I read the code, it does not check for good checksum. Cheers, danny From owner-freebsd-stable@FreeBSD.ORG Mon Feb 9 13:21:58 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AF9AF10656C6 for ; Mon, 9 Feb 2009 13:21:58 +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 DC0B78FC17 for ; Mon, 9 Feb 2009 13:21:56 +0000 (UTC) (envelope-from avg@icyb.net.ua) 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 PAA20655; Mon, 09 Feb 2009 15:21:54 +0200 (EET) (envelope-from avg@icyb.net.ua) Message-ID: <49902DF2.8050206@icyb.net.ua> Date: Mon, 09 Feb 2009 15:21:54 +0200 From: Andriy Gapon User-Agent: Thunderbird 2.0.0.19 (X11/20090110) MIME-Version: 1.0 To: FreeBSD Stable , freebsd-fs@freebsd.org References: <498AF8E1.7020206@icyb.net.ua> In-Reply-To: <498AF8E1.7020206@icyb.net.ua> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: Subject: Re: nfs umount soft hang X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Feb 2009 13:21:59 -0000 on 05/02/2009 16:34 Andriy Gapon said the following: > I have an NFS server and NFS client separated by a firewall. Both > servers are FreeBSD 7.1. > > Server configuration: > nfs_server_enable="YES" > nfs_server_flags="-t -n 4" > rpcbind_enable="YES" > mountd_flags="-r -p 737" > mountd_enable="YES" > > The firewall allows tcp and udp to port 111, but only tcp to ports 2049 > and 737 (configured for mountd, see above). > > On the client I use e.g. the following command for mounting: > mount -t nfs -o nfsv3,tcp,intr,rdirplus,-r=32768,-w=32768 > XXXX:/export/usr/obj /usr/obj > > Mounting and subsequent fs operations work flawlessly. > > When I unmount umount command hangs but can be interrupted with ^C. > Everything seems to be clean after that - the filesystem is unmounted, > there are no post-effects on both client and server. I think this is it: 377 /* 378 * Report to mountd-server which nfsname 379 * has been unmounted. 380 */ 381 if (ai != NULL && !(fflag & MNT_FORCE) && do_rpc) { 382 clp = clnt_create(hostp, RPCPROG_MNT, RPCMNT_VER1, "udp"); I wonder if umount could be smarter as to whether use udp or tcp here. -- Andriy Gapon From owner-freebsd-stable@FreeBSD.ORG Mon Feb 9 19:26:21 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8C0DD10656EA; Mon, 9 Feb 2009 19:26:21 +0000 (UTC) (envelope-from bms@FreeBSD.org) Received: from out1.smtp.messagingengine.com (out1.smtp.messagingengine.com [66.111.4.25]) by mx1.freebsd.org (Postfix) with ESMTP id 5A3B38FC3B; Mon, 9 Feb 2009 19:26:21 +0000 (UTC) (envelope-from bms@FreeBSD.org) Received: from compute1.internal (compute1.internal [10.202.2.41]) by out1.messagingengine.com (Postfix) with ESMTP id E00422902E6; Mon, 9 Feb 2009 14:26:20 -0500 (EST) Received: from heartbeat2.messagingengine.com ([10.202.2.161]) by compute1.internal (MEProxy); Mon, 09 Feb 2009 14:26:20 -0500 X-Sasl-enc: 4nQcRZhdtF6GW8Bciq46VJ9Xr0SjWfgVogDS3S1rYJRR 1234207580 Received: from empiric.lon.incunabulum.net (82-35-112-254.cable.ubr07.dals.blueyonder.co.uk [82.35.112.254]) by mail.messagingengine.com (Postfix) with ESMTPSA id 0EC134C575; Mon, 9 Feb 2009 14:26:19 -0500 (EST) Message-ID: <4990835A.3020303@FreeBSD.org> Date: Mon, 09 Feb 2009 19:26:18 +0000 From: "Bruce M. Simpson" User-Agent: Thunderbird 2.0.0.19 (X11/20090126) MIME-Version: 1.0 To: Robert Noland References: <329181233306971@webmail57.yandex.ru> <985A59F2-20CC-4779-A000-018E52B5BFA9@jump-ing.de> <101781233319948@webmail36.yandex.ru> <4983A3AE.90804@FreeBSD.org> <498F901A.7000900@FreeBSD.org> <1234159237.23838.3.camel@ferret.2hip.net> In-Reply-To: <1234159237.23838.3.camel@ferret.2hip.net> X-Enigmail-Version: 0.95.6 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "S.N.Grigoriev" , Markus Hitter , freebsd-stable@freebsd.org Subject: Re: Unhappy Xorg upgrade X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Feb 2009 19:26:23 -0000 Robert, First, thanks for all your dedicated work so far on the Xorg ports. I realize this upgrade has been somewhat fraught with unexpected issues. FWIW, things are not greener on the Linux side of the fence; many Ubuntu and Debian users have reported issues with the newer Xorg and in particular hald. Robert Noland wrote: > ... >> I still see the USB symptoms with xorg-server port as of today -- forced >> rebuild with libpciaccess also. So amd64 is still regressed -- USB is >> totally unusable there after X is started. My theory was that somehow >> Xorg was stomping on the USB controller registers on this machine. The >> USB controller on this box is ALi, card=0x81561043. >> > > Is your usb sharing interrupts with the video card? > Yes, it appears so. This is an ASUS Vintage AH-1, uniprocessor amd64 box w/ioapic enabled from devinfo -r (abbreviated): ohci0 17 ohci1 18 ohci2 19 ehci0 23 lspci -v jibes with devinfo -r -- the primary head got IRQ 18, the secondary IRQ 255. It appears msk0 is also sharing IRQ 18, though I haven't seen any problems with networking; mskc0, however, is then configured to use MSI (pseudo IRQ 256, 258), it is a PCI-e device. When the system starts, the drm module has not been loaded, so the Radeon (Sapphire X550) card hasn't been allocated its IRQ by FreeBSD. After X starts, glxinfo and glxgers work fine. kldstat reports drm.ko and radeon.ko got loaded by X as I would expect. I still see no IRQ allocated for the radeon, either in dmesg output or in devinfo -r, however, vmstat -i does show drm0 as sharing IRQ 18. At this point, I rebooted and tried manually resetting the BIOS ESCD table, unfortunately the BIOS on this machine won't let me tie IRQs down to particular devices. > Does the issue occur if you aren't using a usb mouse? > I see the USB problems regardless of the kind of USB devices plugged in, I continue to use a PS/2 mouse on the desktop as a workaround. I see the bump on devel/libpciaccess re typo of rombase, and forced a rebuild of xorg-server against the patched libpciaccess library (probably not needed, as the .so ABI didn't change). The USB problem is still present, unfortunately. thanks, BMS From owner-freebsd-stable@FreeBSD.ORG Mon Feb 9 19:43:14 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 963E6106566B; Mon, 9 Feb 2009 19:43:14 +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 4D7A68FC20; Mon, 9 Feb 2009 19:43:14 +0000 (UTC) (envelope-from rnoland@FreeBSD.org) Received: from [192.168.1.132] (adsl-1-207-86.bna.bellsouth.net [65.1.207.86]) (authenticated bits=0) by gizmo.2hip.net (8.14.3/8.14.3) with ESMTP id n19JgV5B049054 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 9 Feb 2009 14:42:31 -0500 (EST) (envelope-from rnoland@FreeBSD.org) From: Robert Noland To: "Bruce M. Simpson" In-Reply-To: <4990835A.3020303@FreeBSD.org> References: <329181233306971@webmail57.yandex.ru> <985A59F2-20CC-4779-A000-018E52B5BFA9@jump-ing.de> <101781233319948@webmail36.yandex.ru> <4983A3AE.90804@FreeBSD.org> <498F901A.7000900@FreeBSD.org> <1234159237.23838.3.camel@ferret.2hip.net> <4990835A.3020303@FreeBSD.org> Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-35ABTMgOdLoeR8EGQwBO" Organization: FreeBSD Date: Mon, 09 Feb 2009 14:43:06 -0500 Message-Id: <1234208586.1524.17.camel@ferret.2hip.net> Mime-Version: 1.0 X-Mailer: Evolution 2.24.3 FreeBSD GNOME Team Port X-Spam-Status: No, score=-0.8 required=5.0 tests=AWL,BAYES_00, MIME_QP_LONG_LINE, RCVD_IN_PBL, RCVD_IN_SORBS_DUL, RDNS_DYNAMIC autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on gizmo.2hip.net Cc: "S.N.Grigoriev" , Markus Hitter , freebsd-stable@freebsd.org Subject: Re: Unhappy Xorg upgrade X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Feb 2009 19:43:19 -0000 --=-35ABTMgOdLoeR8EGQwBO Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Mon, 2009-02-09 at 19:26 +0000, Bruce M. Simpson wrote: > Robert, >=20 > First, thanks for all your dedicated work so far on the Xorg ports. >=20 > I realize this upgrade has been somewhat fraught with unexpected issues. >=20 > FWIW, things are not greener on the Linux side of the fence; many Ubuntu=20 > and Debian users have reported issues with the newer Xorg and in=20 > particular hald. >=20 > Robert Noland wrote: > > ... > >> I still see the USB symptoms with xorg-server port as of today -- forc= ed=20 > >> rebuild with libpciaccess also. So amd64 is still regressed -- USB is=20 > >> totally unusable there after X is started. My theory was that somehow=20 > >> Xorg was stomping on the USB controller registers on this machine. The= =20 > >> USB controller on this box is ALi, card=3D0x81561043. > >> =20 > > > > Is your usb sharing interrupts with the video card? > > =20 >=20 > Yes, it appears so. This is an ASUS Vintage AH-1, uniprocessor amd64 box=20 > w/ioapic enabled >=20 > from devinfo -r (abbreviated): > ohci0 17 > ohci1 18 > ohci2 19 > ehci0 23 >=20 > lspci -v jibes with devinfo -r -- the primary head got IRQ 18, the=20 > secondary IRQ 255. >=20 > It appears msk0 is also sharing IRQ 18, though I haven't seen any=20 > problems with networking; mskc0, however, is then configured to use MSI=20 > (pseudo IRQ 256, 258), it is a PCI-e device. >=20 > When the system starts, the drm module has not been loaded, so the=20 > Radeon (Sapphire X550) card hasn't been allocated its IRQ by FreeBSD. >=20 > After X starts, glxinfo and glxgers work fine. kldstat reports drm.ko=20 > and radeon.ko got loaded by X as I would expect. I still see no IRQ=20 > allocated for the radeon, either in dmesg output or in devinfo -r,=20 > however, vmstat -i does show drm0 as sharing IRQ 18. Ok, that is odd... Once drm is loaded and X opens it, the ddx driver should request that the irq handler be installed. At that point, dmesg should show something resembling the following. vgapci0: child drm0 requested pci_enable_busmaster info: [drm] AGP at 0xc0000000 256MB info: [drm] Initialized i915 1.6.0 20080730 drm0: [ITHREAD] I have code to enable msi for drm, which has been at least minimally tested on intel and ati. FWIW, linux does not support msi on radeon yet, so I got the jump on them there... The outstanding issue with that code is that I still need to implement a blacklist for certain devices that report msi capability, but don't (intel 945gm, is the only known chip atm). Does the issue still occur if drm is disabled? robert. > At this point, I rebooted and tried manually resetting the BIOS ESCD=20 > table, unfortunately the BIOS on this machine won't let me tie IRQs down=20 > to particular devices. >=20 >=20 > > Does the issue occur if you aren't using a usb mouse? > > =20 >=20 > I see the USB problems regardless of the kind of USB devices plugged in,=20 > I continue to use a PS/2 mouse on the desktop as a workaround. >=20 > I see the bump on devel/libpciaccess re typo of rombase, and forced a=20 > rebuild of xorg-server against the patched libpciaccess library=20 > (probably not needed, as the .so ABI didn't change). >=20 > The USB problem is still present, unfortunately. >=20 > thanks, > BMS >=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" --=20 Robert Noland FreeBSD --=-35ABTMgOdLoeR8EGQwBO Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.10 (FreeBSD) iEYEABECAAYFAkmQh0kACgkQM4TrQ4qfROO26QCfSCPARz0lb50RJHxAYgA0rTem 3igAnA1FqQSt7CQdNZ/jrekwa94BvMY1 =9cPB -----END PGP SIGNATURE----- --=-35ABTMgOdLoeR8EGQwBO-- From owner-freebsd-stable@FreeBSD.ORG Mon Feb 9 19:53:03 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E2032106566B for ; Mon, 9 Feb 2009 19:53:03 +0000 (UTC) (envelope-from serguey-grigoriev@yandex.ru) Received: from forwards1.yandex.ru (forwards1.yandex.ru [77.88.60.125]) by mx1.freebsd.org (Postfix) with ESMTP id 883778FC0A for ; Mon, 9 Feb 2009 19:53:03 +0000 (UTC) (envelope-from serguey-grigoriev@yandex.ru) Received: from webmail60.yandex.ru (webmail60.yandex.ru [77.88.61.5]) by forwards1.yandex.ru (Yandex) with ESMTP id A61FCBA21C6; Mon, 9 Feb 2009 22:53:01 +0300 (MSK) Received: from localhost (localhost [127.0.0.1]) by webmail60.yandex.ru (Yandex) with ESMTP id 8CF532842E6; Mon, 9 Feb 2009 22:53:01 +0300 (MSK) X-Yandex-Spam: 1 X-Yandex-Front: webmail60 X-Yandex-TimeMark: 1234209181 Received: from [91.122.49.58] ([91.122.49.58]) by mail.yandex.ru with HTTP; Mon, 09 Feb 2009 22:53:00 +0300 From: "S.N.Grigoriev" To: "Robert Noland" In-Reply-To: <1234159237.23838.3.camel@ferret.2hip.net> References: <329181233306971@webmail57.yandex.ru> <985A59F2-20CC-4779-A000-018E52B5BFA9@jump-ing.de> <101781233319948@webmail36.yandex.ru> <4983A3AE.90804@FreeBSD.org> <498F901A.7000900@FreeBSD.org> <1234159237.23838.3.camel@ferret.2hip.net> MIME-Version: 1.0 Message-Id: <406921234209180@webmail60.yandex.ru> Date: Mon, 09 Feb 2009 22:53:00 +0300 X-Mailer: Yamail [ http://yandex.ru ] 5.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain Cc: freebsd-stable@freebsd.org, Markus Hitter , "Bruce M. Simpson" Subject: Re: Unhappy Xorg upgrade X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Feb 2009 19:53:04 -0000 09.02.09, 09:00, "Robert Noland" : > On Mon, 2009-02-09 at 02:08 +0000, Bruce M. Simpson wrote: > > Bruce M. Simpson wrote: > > > S.N.Grigoriev wrote: > > >> I thank you for your response. I've applied the patch to pci.c from > > >> kern/130957. Unfortunately there are no positive results. USB is still > > >> unreachable with X. > > > > > > Just following up to confirm that you are seeing exactly the same > > > symptoms with USB and Xorg 7.4 as I see on my amd64 desktop running > > > 7-STABLE from 00:00 UTC on this Wednesday. > > > > I still see the USB symptoms with xorg-server port as of today -- forced > > rebuild with libpciaccess also. So amd64 is still regressed -- USB is > > totally unusable there after X is started. My theory was that somehow > > Xorg was stomping on the USB controller registers on this machine. The > > USB controller on this box is ALi, card=0x81561043. > Is your usb sharing interrupts with the video card? Yes, it is. This is from dmesg output: ohci2: mem 0xfe02c000-0xfe02cfff irq 18 at device 19.2 on pci0 vgapci0: port 0xde00-0xdeff mem 0xd0000000-0xdfffffff, 0xfdee0000-0xfdeeffff irq 18 at device 0.0 on pci1 > Does the issue occur if you aren't using a usb mouse? I'm not using a USB mouse. My mouse is PS/2. -- Regards, S.Grigoriev. From owner-freebsd-stable@FreeBSD.ORG Mon Feb 9 21:48:29 2009 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 0BAB71065680 for ; Mon, 9 Feb 2009 21:48:29 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.terabit.net.ua (mail.terabit.net.ua [195.137.202.147]) by mx1.freebsd.org (Postfix) with ESMTP id A51038FC1C for ; Mon, 9 Feb 2009 21:48:28 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from skuns.zoral.com.ua ([91.193.166.194] helo=mail.zoral.com.ua) by mail.terabit.net.ua with esmtps (TLSv1:AES256-SHA:256) (Exim 4.63 (FreeBSD)) (envelope-from ) id 1LWdzO-000A2O-AU; Mon, 09 Feb 2009 23:48:26 +0200 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 n19LmNSB005161 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 9 Feb 2009 23:48:23 +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 n19LmNeJ089379; Mon, 9 Feb 2009 23:48:23 +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 n19LmMiV089378; Mon, 9 Feb 2009 23:48:22 +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, 9 Feb 2009 23:48:22 +0200 From: Kostik Belousov To: Eugene Grosbein Message-ID: <20090209214822.GH9427@deviant.kiev.zoral.com.ua> References: <498FAA2A.7423AC15@kuzbass.ru> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="vhOf6eAHdfH9MSjZ" Content-Disposition: inline In-Reply-To: <498FAA2A.7423AC15@kuzbass.ru> User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on 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 X-Virus-Scanned: mail.terabit.net.ua 1LWdzO-000A2O-AU 871f9b96e060e999738347688a943c59 X-Terabit: YES Cc: stable@freebsd.org Subject: Re: sysctl lock in RELENG_6 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Feb 2009 21:48:29 -0000 --vhOf6eAHdfH9MSjZ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Feb 09, 2009 at 10:59:38AM +0700, Eugene Grosbein wrote: > Hi! >=20 > I've RELENG_6 system controlling local PBX through RS-232 port, sio(4). > It also runs syslogd, cron, sshd, bsnmpd and sendmail for outgoing report= s. >=20 > It locks very often: it answers to pings but PBX controlling software sto= ps > responding, local and remote login attempts hang due to 'login' process > stuck in 'sysctl lock' state. Local consoles do switch with 'Alt-Fn' > and DDB works. It shows that sendmail is in 'sysctl lock' state too. >=20 > This is NanoBSD installation running from IDE flash, it's swapless > but I think I could manage to obtain crashdump if there is an interest of= it. >=20 > I've digged commit logs a bit and found this change MFC'd to RELENG_7 > but not RELENG_6: >=20 > http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/kern/kern_sysctl.c#rev1.177= .6.2 >=20 > It seems RELENG_6 needs this too, doesn't it? > I'm going to merge the change to RELENG_6 and give it a try. Yes, please give it a try. In fact, it was quite specific situation that I observed and produced a fix for. You need execing process that needs to grab Giant, e.g. due to image being located on !MPSAFE fs, and simultaneous sysctl issued that inspects this process. --vhOf6eAHdfH9MSjZ Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (FreeBSD) iEYEARECAAYFAkmQpKUACgkQC3+MBN1Mb4jrgACgn3DM3+XBG4zIwdcBmkev1tqA XVEAmwc917IvUzsTVMl9Kt4jypzRy+WN =EZ/K -----END PGP SIGNATURE----- --vhOf6eAHdfH9MSjZ-- From owner-freebsd-stable@FreeBSD.ORG Mon Feb 9 23:31:02 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A07A61065808; Mon, 9 Feb 2009 23:30:37 +0000 (UTC) (envelope-from bms@FreeBSD.org) Received: from out1.smtp.messagingengine.com (out1.smtp.messagingengine.com [66.111.4.25]) by mx1.freebsd.org (Postfix) with ESMTP id 3D4378FC12; Mon, 9 Feb 2009 23:30:37 +0000 (UTC) (envelope-from bms@FreeBSD.org) Received: from compute2.internal (compute2.internal [10.202.2.42]) by out1.messagingengine.com (Postfix) with ESMTP id 98438290AB9; Mon, 9 Feb 2009 18:30:36 -0500 (EST) Received: from heartbeat1.messagingengine.com ([10.202.2.160]) by compute2.internal (MEProxy); Mon, 09 Feb 2009 18:30:36 -0500 X-Sasl-enc: /AxJGmxnPX1uXueVQdXwDNuxG4Tyr77DOZK0+e88DTCR 1234222236 Received: from empiric.lon.incunabulum.net (82-35-112-254.cable.ubr07.dals.blueyonder.co.uk [82.35.112.254]) by mail.messagingengine.com (Postfix) with ESMTPSA id 8E6C62A003; Mon, 9 Feb 2009 18:30:35 -0500 (EST) Message-ID: <4990BC99.1070108@FreeBSD.org> Date: Mon, 09 Feb 2009 23:30:33 +0000 From: "Bruce M. Simpson" User-Agent: Thunderbird 2.0.0.19 (X11/20090126) MIME-Version: 1.0 To: Robert Noland References: <329181233306971@webmail57.yandex.ru> <985A59F2-20CC-4779-A000-018E52B5BFA9@jump-ing.de> <101781233319948@webmail36.yandex.ru> <4983A3AE.90804@FreeBSD.org> <498F901A.7000900@FreeBSD.org> <1234159237.23838.3.camel@ferret.2hip.net> <4990835A.3020303@FreeBSD.org> <1234208586.1524.17.camel@ferret.2hip.net> In-Reply-To: <1234208586.1524.17.camel@ferret.2hip.net> X-Enigmail-Version: 0.95.6 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "S.N.Grigoriev" , Markus Hitter , freebsd-stable@freebsd.org Subject: Re: Unhappy Xorg upgrade X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Feb 2009 23:32:15 -0000 Robert Noland wrote: > ... > Ok, that is odd... Once drm is loaded and X opens it, the ddx driver > should request that the irq handler be installed. At that point, dmesg > should show something resembling the following. > > vgapci0: child drm0 requested pci_enable_busmaster > info: [drm] AGP at 0xc0000000 256MB > info: [drm] Initialized i915 1.6.0 20080730 > drm0: [ITHREAD] > Yes, I normally see output similar to this when X is started. > ... > > Does the issue still occur if drm is disabled? > Just tried disabling DRM w/ 'Options "DRI" "off"' in Section "Device". DRM is indeed disabled -- no dmesg output and not loaded by X. However the problem is still there. BTW: This Radeon card does have MSI capabilities according to lspci, however they do not appear to be enabled either by FreeBSD or by X. I was about to point the finger at interrupt filters, however that blows that theory out of the water. FWIW the IBM T43 here has an i915GM, and USB is working just fine and dandy. The main data point which sticks out is the fact that the affected machine is amd64. Now that DRM has been disabled on my box, this would point the finger at the X userland. I don't see any obvious nasties in my Section "Device", although I do pass a BusID and BusType to prevent X from trying to use the second head with RandR (lots of pain with fubar DVI cables when I first purchased the monitor). I skimmed pci_user.c, thinking libpciaccess just thunks to it via /dev/pci, it appears there's no instrumentation there I can turn on to see what userland is actually frobbing. thanks, BMS From owner-freebsd-stable@FreeBSD.ORG Mon Feb 9 23:54:19 2009 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 721CB1065670 for ; Mon, 9 Feb 2009 23:54:19 +0000 (UTC) (envelope-from Mark_Andrews@isc.org) Received: from mx.isc.org (mx.isc.org [IPv6:2001:4f8:0:2::1c]) by mx1.freebsd.org (Postfix) with ESMTP id 55F688FC19 for ; Mon, 9 Feb 2009 23:54:19 +0000 (UTC) (envelope-from Mark_Andrews@isc.org) Received: from farside.isc.org (farside.isc.org [IPv6:2001:4f8:3:bb::5]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "farside.isc.org", Issuer "ISC CA" (verified OK)) by mx.isc.org (Postfix) with ESMTPS id 13934114049 for ; Mon, 9 Feb 2009 23:54:09 +0000 (UTC) (envelope-from Mark_Andrews@isc.org) 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 705DAE6069 for ; Mon, 9 Feb 2009 23:54:08 +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 n19Ns6xR027201 for ; Tue, 10 Feb 2009 10:54:06 +1100 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200902092354.n19Ns6xR027201@drugs.dv.isc.org> To: stable@freebsd.org From: Mark Andrews Date: Tue, 10 Feb 2009 10:54:05 +1100 Sender: Mark_Andrews@isc.org 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 mx.isc.org Cc: Subject: http://www.freebsd.org/doc/handbook/desktop-browsers.html X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Feb 2009 23:54:19 -0000 Can the instructions for adding a java pluging please be updated to something that works as what's there doesn't work for Firefox 3. javavmwrapper-2.3.2 is installed. % ls -l /usr/local/lib/browser_plugins/ total 0 lrwxr-xr-x 1 root wheel 67 Feb 8 10:38 libjavaplugin_oji.so -> /usr/local/diablo-jdk1.6.0/jre/plugin/i386/ns7/libjavaplugin_oji.so % ls -lL /usr/local/lib/browser_plugins/ total 188 -rwxr-xr-x 1 root wheel 191059 Jun 18 2008 libjavaplugin_oji.so % Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark_Andrews@isc.org From owner-freebsd-stable@FreeBSD.ORG Tue Feb 10 04:01:29 2009 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 8433E106564A for ; Tue, 10 Feb 2009 04:01:29 +0000 (UTC) (envelope-from eugen@kuzbass.ru) Received: from www.svzserv.kemerovo.su (www.svzserv.kemerovo.su [213.184.65.80]) by mx1.freebsd.org (Postfix) with ESMTP id DB4308FC0A for ; Tue, 10 Feb 2009 04:01:28 +0000 (UTC) (envelope-from eugen@kuzbass.ru) Received: from www.svzserv.kemerovo.su (eugen@localhost [127.0.0.1]) by www.svzserv.kemerovo.su (8.13.8/8.13.8) with ESMTP id n1A41Pj6080951; Tue, 10 Feb 2009 11:01:25 +0700 (KRAT) (envelope-from eugen@www.svzserv.kemerovo.su) Received: (from eugen@localhost) by www.svzserv.kemerovo.su (8.13.8/8.13.8/Submit) id n1A41PkO080950; Tue, 10 Feb 2009 11:01:25 +0700 (KRAT) (envelope-from eugen) Date: Tue, 10 Feb 2009 11:01:25 +0700 From: Eugene Grosbein To: Kostik Belousov Message-ID: <20090210040125.GA80054@svzserv.kemerovo.su> References: <498FAA2A.7423AC15@kuzbass.ru> <20090209214822.GH9427@deviant.kiev.zoral.com.ua> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20090209214822.GH9427@deviant.kiev.zoral.com.ua> User-Agent: Mutt/1.4.2.3i Cc: stable@freebsd.org Subject: Re: sysctl lock in RELENG_6 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Feb 2009 04:01:29 -0000 On Mon, Feb 09, 2009 at 11:48:22PM +0200, Kostik Belousov wrote: > > I've digged commit logs a bit and found this change MFC'd to RELENG_7 > > but not RELENG_6: > > > > http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/kern/kern_sysctl.c#rev1.177.6.2 > > > > It seems RELENG_6 needs this too, doesn't it? > > I'm going to merge the change to RELENG_6 and give it a try. > > Yes, please give it a try. In fact, it was quite specific situation > that I observed and produced a fix for. You need execing process that > needs to grab Giant, e.g. due to image being located on !MPSAFE fs, and > simultaneous sysctl issued that inspects this process. Well, my 6.3-STABLE locked very often (sometimes every hour). Yesterday I've upgraded it to 6.4-STABLE, applied 1.177.2.1 of the file to sources, rebuilt NanoBSD image and ran it. It has not locked yet. Btw, root filesystem here is UFS2 without softupdates mounted read-only but /etc and /var are md(4) (devfs is mounted too). Eugene Grosbein From owner-freebsd-stable@FreeBSD.ORG Tue Feb 10 04:12:36 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 660E7106564A for ; Tue, 10 Feb 2009 04:12:36 +0000 (UTC) (envelope-from matheusber@gmail.com) Received: from yw-out-2324.google.com (yw-out-2324.google.com [74.125.46.30]) by mx1.freebsd.org (Postfix) with ESMTP id 1758F8FC1B for ; Tue, 10 Feb 2009 04:12:35 +0000 (UTC) (envelope-from matheusber@gmail.com) Received: by yw-out-2324.google.com with SMTP id 2so701577ywt.13 for ; Mon, 09 Feb 2009 20:12:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:received:received :message-id:date:subject:from:to:user-agent:mime-version :content-type:content-transfer-encoding:x-priority:importance; bh=xqGE3HA7TGnF6RHQ6cS6BjZor2beoCnNHg0YnmR2xWo=; b=tL0NWoN3C34+4h/W9th145UHXDdaSoviaq6LXSjXsgkGKaM80guklPtaUCilKGlAdP tU79dMoHCUBRsLzBeQdlYOv83sCXQECy8ncr2N+xyW9++ohvCGIwyK7JuI8mw3SlinMT CFNsO0beI7eUDQ8h/dkin1ZHrVFPWAfkYMqsg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:subject:from:to:user-agent:mime-version :content-type:content-transfer-encoding:x-priority:importance; b=wPHR6aVkV5tP7WD5y1ni+tlIH2C+I+I110duUhZTTBdP4b2BbTQJXDzGCYJw1hkdQq zA5ly2ZrkRHEDyx/OAqJlakwJfFOXtZmjznmzJ6kaBj120tXwaypjCBECrN7xamJ3777 wjYB3rv1ZX+hQ4xE1vcklkW+KqCvyEeUyTj7o= Received: by 10.220.45.81 with SMTP id d17mr592425vcf.20.1234239155370; Mon, 09 Feb 2009 20:12:35 -0800 (PST) Received: from cygnus.homeunix.com ([189.71.57.209]) by mx.google.com with ESMTPS id 9sm4272755ywf.26.2009.02.09.20.12.34 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 09 Feb 2009 20:12:34 -0800 (PST) Sender: Nenhum_de_Nos Received: by cygnus.homeunix.com (Postfix, from userid 80) id 07515B8061; Tue, 10 Feb 2009 01:12:31 -0300 (BRT) Received: from 10.1.1.80 (SquirrelMail authenticated user matheus) by 10.1.1.10 with HTTP; Tue, 10 Feb 2009 02:12:30 -0200 (BRST) Message-ID: <92e52b8953009d1d0afd2b6e7cd09654.squirrel@10.1.1.10> Date: Tue, 10 Feb 2009 02:12:30 -0200 (BRST) From: "Nenhum_de_Nos" To: freebsd-stable@freebsd.org User-Agent: SquirrelMail/1.4.15 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Subject: ADMtek USB To LAN Converter X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Feb 2009 04:12:36 -0000 hail, I have two of these and cant make them ping. module loads ok, ifconfig sees ok, but cant send any data. tcpdump can get info though. aue0: on uhub1 miibus3: on aue0 ukphy1: PHY 1 on miibus3 ukphy1: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto aue0: Ethernet address: 00:60:6e:00:05:d2 aue0: link state changed to DOWN aue0: link state changed to UP aue0: usb error on rx: IOERROR FreeBSD xxx 7.1-PRERELEASE FreeBSD 7.1-PRERELEASE #2: Tue Dec 30 00:41:39 BRT 2008 root@xxx:/usr/obj/usr/src/sys/xxx i386 if anyone has any clues, thanks, matheus ps: sorry for posting to usb@ and stable@, but I saw no message in usb@. -- We will call you cygnus, The God of balance you shall be From owner-freebsd-stable@FreeBSD.ORG Tue Feb 10 06:07:25 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A342F106566C; Tue, 10 Feb 2009 06:07:25 +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 722828FC08; Tue, 10 Feb 2009 06:07:25 +0000 (UTC) (envelope-from rnoland@FreeBSD.org) Received: from [192.168.1.132] (adsl-1-207-86.bna.bellsouth.net [65.1.207.86]) (authenticated bits=0) by gizmo.2hip.net (8.14.3/8.14.3) with ESMTP id n1A66dJY052310 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 10 Feb 2009 01:06:41 -0500 (EST) (envelope-from rnoland@FreeBSD.org) From: Robert Noland To: "Bruce M. Simpson" In-Reply-To: <4990BC99.1070108@FreeBSD.org> References: <329181233306971@webmail57.yandex.ru> <985A59F2-20CC-4779-A000-018E52B5BFA9@jump-ing.de> <101781233319948@webmail36.yandex.ru> <4983A3AE.90804@FreeBSD.org> <498F901A.7000900@FreeBSD.org> <1234159237.23838.3.camel@ferret.2hip.net> <4990835A.3020303@FreeBSD.org> <1234208586.1524.17.camel@ferret.2hip.net> <4990BC99.1070108@FreeBSD.org> Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-pDhaORuYHyDjB+7pVlxu" Organization: FreeBSD Date: Tue, 10 Feb 2009 01:07:14 -0500 Message-Id: <1234246034.1524.27.camel@ferret.2hip.net> Mime-Version: 1.0 X-Mailer: Evolution 2.24.3 FreeBSD GNOME Team Port X-Spam-Status: No, score=-0.8 required=5.0 tests=AWL,BAYES_00, MIME_QP_LONG_LINE, RCVD_IN_PBL, RCVD_IN_SORBS_DUL, RDNS_DYNAMIC autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on gizmo.2hip.net Cc: "S.N.Grigoriev" , Markus Hitter , freebsd-stable@freebsd.org Subject: Re: Unhappy Xorg upgrade X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Feb 2009 06:07:25 -0000 --=-pDhaORuYHyDjB+7pVlxu Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Mon, 2009-02-09 at 23:30 +0000, Bruce M. Simpson wrote: > Robert Noland wrote: > > ... > > Ok, that is odd... Once drm is loaded and X opens it, the ddx driver > > should request that the irq handler be installed. At that point, dmesg > > should show something resembling the following. > > > > vgapci0: child drm0 requested pci_enable_busmaster > > info: [drm] AGP at 0xc0000000 256MB > > info: [drm] Initialized i915 1.6.0 20080730 > > drm0: [ITHREAD] > > =20 >=20 > Yes, I normally see output similar to this when X is started. >=20 > > ... > > > > Does the issue still occur if drm is disabled? > > =20 >=20 > Just tried disabling DRM w/ 'Options "DRI" "off"' in Section "Device". > DRM is indeed disabled -- no dmesg output and not loaded by X. >=20 > However the problem is still there. >=20 > BTW: This Radeon card does have MSI capabilities according to lspci,=20 > however they do not appear to be enabled either by FreeBSD or by X. I=20 > was about to point the finger at interrupt filters, however that blows=20 > that theory out of the water. >=20 > FWIW the IBM T43 here has an i915GM, and USB is working just fine and=20 > dandy. The main data point which sticks out is the fact that the=20 > affected machine is amd64. >=20 > Now that DRM has been disabled on my box, this would point the finger at=20 > the X userland. >=20 > I don't see any obvious nasties in my Section "Device", although I do=20 > pass a BusID and BusType to prevent X from trying to use the second head=20 > with RandR (lots of pain with fubar DVI cables when I first purchased=20 > the monitor). >=20 > I skimmed pci_user.c, thinking libpciaccess just thunks to it via=20 > /dev/pci, it appears there's no instrumentation there I can turn on to=20 > see what userland is actually frobbing. Ok, lets try another test... There is a scanpci util in the libpciaccess port. We don't install it, but it does get built. Build the port and run scanpci -v as root from the console. That should poke all the pci devices on the box and tell you about them. See if that is able to trigger the issue. robert. > thanks, > BMS > _______________________________________________ > 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 Robert Noland FreeBSD --=-pDhaORuYHyDjB+7pVlxu Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.10 (FreeBSD) iEYEABECAAYFAkmRGZEACgkQM4TrQ4qfRONIFwCfUt7MWo2OQIIdIjeqxwO4XIeS dIkAn2mw2zrU/0/PClUYR+u92nSoqQ75 =lgzg -----END PGP SIGNATURE----- --=-pDhaORuYHyDjB+7pVlxu-- From owner-freebsd-stable@FreeBSD.ORG Tue Feb 10 06:28:02 2009 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 1669E106566B for ; Tue, 10 Feb 2009 06:28:02 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.terabit.net.ua (mail.terabit.net.ua [195.137.202.147]) by mx1.freebsd.org (Postfix) with ESMTP id AD22A8FC0A for ; Tue, 10 Feb 2009 06:28:01 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from skuns.zoral.com.ua ([91.193.166.194] helo=mail.zoral.com.ua) by mail.terabit.net.ua with esmtps (TLSv1:AES256-SHA:256) (Exim 4.63 (FreeBSD)) (envelope-from ) id 1LWm6C-000Myq-0x; Tue, 10 Feb 2009 08:28:00 +0200 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 n1A6Rvli065788 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 10 Feb 2009 08:27:57 +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 n1A6Rv4s021187; Tue, 10 Feb 2009 08:27:57 +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 n1A6RvYr021186; Tue, 10 Feb 2009 08:27:57 +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: Tue, 10 Feb 2009 08:27:57 +0200 From: Kostik Belousov To: Eugene Grosbein Message-ID: <20090210062757.GK9427@deviant.kiev.zoral.com.ua> References: <498FAA2A.7423AC15@kuzbass.ru> <20090209214822.GH9427@deviant.kiev.zoral.com.ua> <20090210040125.GA80054@svzserv.kemerovo.su> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="J3rqiH0DIeiRD2zz" Content-Disposition: inline In-Reply-To: <20090210040125.GA80054@svzserv.kemerovo.su> User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on 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 X-Virus-Scanned: mail.terabit.net.ua 1LWm6C-000Myq-0x 13e838e2e14f003f2194599b343a470c X-Terabit: YES Cc: stable@freebsd.org Subject: Re: sysctl lock in RELENG_6 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Feb 2009 06:28:02 -0000 --J3rqiH0DIeiRD2zz Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Feb 10, 2009 at 11:01:25AM +0700, Eugene Grosbein wrote: > On Mon, Feb 09, 2009 at 11:48:22PM +0200, Kostik Belousov wrote: >=20 > > > I've digged commit logs a bit and found this change MFC'd to RELENG_7 > > > but not RELENG_6: > > >=20 > > > http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/kern/kern_sysctl.c#rev1= .177.6.2 > > >=20 > > > It seems RELENG_6 needs this too, doesn't it? > > > I'm going to merge the change to RELENG_6 and give it a try. > >=20 > > Yes, please give it a try. In fact, it was quite specific situation > > that I observed and produced a fix for. You need execing process that > > needs to grab Giant, e.g. due to image being located on !MPSAFE fs, and > > simultaneous sysctl issued that inspects this process. >=20 > Well, my 6.3-STABLE locked very often (sometimes every hour). > Yesterday I've upgraded it to 6.4-STABLE, applied 1.177.2.1 of the file > to sources, rebuilt NanoBSD image and ran it. It has not locked yet. Can you be slightly more scientific in your tests ? Try RELENG_6 without my patch to see whether it is needed at all. >=20 > Btw, root filesystem here is UFS2 without softupdates mounted read-only > but /etc and /var are md(4) (devfs is mounted too). >=20 > Eugene Grosbein --J3rqiH0DIeiRD2zz Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (FreeBSD) iEYEARECAAYFAkmRHmsACgkQC3+MBN1Mb4idjgCeM2VBjzFz3km/3vsOt4w/qGXF U/UAn30OB6pjq2UMzy4oZSfFab+Oq8Qs =ZJzE -----END PGP SIGNATURE----- --J3rqiH0DIeiRD2zz-- From owner-freebsd-stable@FreeBSD.ORG Tue Feb 10 09:51:22 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8A41D106566C for ; Tue, 10 Feb 2009 09:51:22 +0000 (UTC) (envelope-from horst@sxemacs.org) Received: from fallbackmx06.syd.optusnet.com.au (fallbackmx06.syd.optusnet.com.au [211.29.132.8]) by mx1.freebsd.org (Postfix) with ESMTP id E78138FC08 for ; Tue, 10 Feb 2009 09:51:21 +0000 (UTC) (envelope-from horst@sxemacs.org) Received: from mail10.syd.optusnet.com.au (mail10.syd.optusnet.com.au [211.29.132.191]) by fallbackmx06.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id n1A9ahgG000624 for ; Tue, 10 Feb 2009 20:36:44 +1100 Received: from [220.237.124.212] (c220-237-124-212.farfl2.nsw.optusnet.com.au [220.237.124.212]) (authenticated sender horst.burkhardt) by mail10.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id n1A9aeQ5014534; Tue, 10 Feb 2009 20:36:41 +1100 From: Horst =?ISO-8859-1?Q?G=FCnther?= Burkhardt III To: FreeBSD-STABLE Mailing List , FreeBSD PowerPC ML Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-ZP0oIEi8KxC2IEZLDczt" Date: Tue, 10 Feb 2009 20:38:00 +1100 Message-Id: <1234258680.13304.26.camel@horst-tla> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 Cc: Subject: [7-STABLE] failure during buildworld X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Feb 2009 09:51:22 -0000 --=-ZP0oIEi8KxC2IEZLDczt Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Hey everybody :)=20 I'm having a small issue compiling 7-STABLE as checked out 24 hours ago at the time of writing... during make -j4 buildworld, this error occurs:=20 =3D=3D=3D> lib/bind (install) =3D=3D=3D> lib/bind/bind (install) =3D=3D=3D> lib/bind/bind9 (install) =3D=3D=3D> lib/bind/dns (install) =3D=3D=3D> lib/bind/isc (install) =3D=3D=3D> lib/bind/isccc (install) =3D=3D=3D> lib/bind/isccfg (install) =3D=3D=3D> lib/bind/lwres (install) sh /usr/src/tools/install.sh -C -o root -g wheel -m 444 liblwres.a /usr/obj/usr/src/tmp/usr/lib sh /usr/src/tools/install.sh -C -o root -g wheel -m 444 /usr/src/lib/bind/lwres/../../../contrib/bind9/lib/lwres/include/lwres= /context.h /usr/src/lib/bind/lwres/../../../contrib/bind9/lib/lwres/include= /lwres/int.h /usr/src/lib/bind/lwres/../../../contrib/bind9/lib/lwres/inclu= de/lwres/ipv6.h /usr/src/lib/bind/lwres/../../../contrib/bind9/lib/lwres/in= clude/lwres/lang.h /usr/src/lib/bind/lwres/../../../contrib/bind9/lib/lwres= /include/lwres/list.h /usr/src/lib/bind/lwres/../../../contrib/bind9/lib/lw= res/include/lwres/lwbuffer.h /usr/src/lib/bind/lwres/../../../contrib/bind9= /lib/lwres/include/lwres/lwpacket.h /usr/src/lib/bind/lwres/../../../contri= b/bind9/lib/lwres/include/lwres/lwres.h /usr/src/lib/bind/lwres/../../../co= ntrib/bind9/lib/lwres/include/lwres/result.h /usr/src/lib/bind/lwres/../../= ../contrib/bind9/lib/lwres/include/lwres/version.h /usr/src/lib/bind/lwres/= ../../../contrib/bind9/lib/lwres/unix/include/lwres/net.h /usr/src/lib/bind= /lwres/lwres/netdb.h /usr/src/lib/bind/lwres/lwres/platform.h /usr/obj/usr/= src/tmp/usr/include/lwres sh /usr/src/tools/install.sh -s -o root -g wheel -m 444 liblwres.so.30 /usr/obj/usr/src/tmp/usr/lib ln -fs liblwres.so.30 /usr/obj/usr/src/tmp/usr/lib/liblwres.so 1 error *** Error code 2 1 error *** Error code 2 1 error *** Error code 2 1 error [ bsdbox ] [ root ] [ /usr/src ] =3D=3D>=20 lwres appears to compile cleanly. It would appear that the error is related to ln - and I don't know how to fix it.=20 (also, why doesn't make buildworld pick up from where it left off?)=20 Thanks kindly, -- Horst. --=-ZP0oIEi8KxC2IEZLDczt Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEABECAAYFAkmRSvgACgkQRtTtv0BbTe4AwQCffrjSgK+13wQPn8hJtDJDUdZC IgIAoJj1oaZM3OBwCkbMpbHg9k7CrRT1 =phQQ -----END PGP SIGNATURE----- --=-ZP0oIEi8KxC2IEZLDczt-- From owner-freebsd-stable@FreeBSD.ORG Tue Feb 10 12:44:23 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B5357106564A for ; Tue, 10 Feb 2009 12:44:23 +0000 (UTC) (envelope-from patfbsd@davenulle.org) Received: from smtp.lamaiziere.net (net.lamaiziere.net [91.121.44.19]) by mx1.freebsd.org (Postfix) with ESMTP id 6AC238FC17 for ; Tue, 10 Feb 2009 12:44:23 +0000 (UTC) (envelope-from patfbsd@davenulle.org) Received: from baby-jane.lamaiziere.net (81-65-128-47.rev.numericable.fr [81.65.128.47]) by smtp.lamaiziere.net (Postfix) with ESMTPA id 8E8B5633301; Tue, 10 Feb 2009 13:44:22 +0100 (CET) Received: from baby-jane.lamaiziere.net (localhost [127.0.0.1]) by baby-jane.lamaiziere.net (Postfix) with ESMTP id 09152C1A1; Tue, 10 Feb 2009 13:44:22 +0100 (CET) Date: Tue, 10 Feb 2009 13:44:21 +0100 From: Patrick =?ISO-8859-15?Q?Lamaizi=E8re?= To: freebsd-stable@freebsd.org Message-ID: <20090210134421.350f40b8@baby-jane.lamaiziere.net> Organization: /dave/nulle X-Mailer: Claws Mail 3.7.0 (GTK+ 2.12.11; i386-portbld-freebsd7.1) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: Lars Engels Subject: Backport of glxsb(4) to RELENG_6 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Feb 2009 12:44:24 -0000 Hi, I've backported the glxsb(4) driver to RELENG_6 (to use it on FreeNAS by instance). http://user.lamaiziere.net/patrick/glxsb-6-100209.tar.gz I am not able to test it, but I hope it will work. You can test with openssl: openssl enc -e -aes-128-cbc -in file -out file.enc -k abcdefgh -nosalt -engine cryptodev Please tell me if it works or not. Regards. From owner-freebsd-stable@FreeBSD.ORG Tue Feb 10 13:14:15 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3DC23106564A for ; Tue, 10 Feb 2009 13:14:15 +0000 (UTC) (envelope-from lme@FreeBSD.org) Received: from mail.0x20.net (mail.0x20.net [IPv6:2001:aa8:fffb::3]) by mx1.freebsd.org (Postfix) with ESMTP id C6EEE8FC19 for ; Tue, 10 Feb 2009 13:14:14 +0000 (UTC) (envelope-from lme@FreeBSD.org) Received: from mail.0x20.net (mail.0x20.net [217.69.67.217]) by mail.0x20.net (Postfix) with ESMTP id 1BDCB33C0D; Tue, 10 Feb 2009 14:14:14 +0100 (CET) Received: from i011-63.fin-nrw.de (i011-63.fin-nrw.de [193.109.238.130]) by 0x20.net (Horde MIME library) with HTTP; Tue, 10 Feb 2009 14:14:14 +0100 Message-ID: <20090210141414.2fq37wzlvggcggks@0x20.net> X-Priority: 3 (Normal) Date: Tue, 10 Feb 2009 14:14:14 +0100 From: Lars Engels To: Patrick =?iso-8859-15?b?TGFtYWl6aehyZQ==?= References: <20090210134421.350f40b8@baby-jane.lamaiziere.net> In-Reply-To: <20090210134421.350f40b8@baby-jane.lamaiziere.net> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=_euceflkm5k0"; protocol="application/pgp-signature"; micalg="pgp-sha1" Content-Transfer-Encoding: 7bit User-Agent: Internet Messaging Program (IMP) H3 (4.1.3) Cc: freebsd-stable@freebsd.org Subject: Re: Backport of glxsb(4) to RELENG_6 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Feb 2009 13:14:15 -0000 This message is in MIME format and has been PGP signed. --=_euceflkm5k0 Content-Type: text/plain; charset=ISO-8859-15; DelSp="Yes"; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Quoting Patrick Lamaizi=E8re : > Hi, > > I've backported the glxsb(4) driver to RELENG_6 (to use it on FreeNAS by > instance). > > http://user.lamaiziere.net/patrick/glxsb-6-100209.tar.gz > > I am not able to test it, but I hope it will work. > > You can test with openssl: > > openssl enc -e -aes-128-cbc -in file -out file.enc -k abcdefgh -nosalt > -engine cryptodev > Hi Patrick! Great, thanks a lot for this backport. I'll try it this evening on my =20 Alix-based FreeNAS. Lars --=_euceflkm5k0 Content-Type: application/pgp-signature Content-Description: Digitale PGP-Unterschrift Content-Disposition: inline Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (FreeBSD) iEYEABECAAYFAkmRfaUACgkQKc512sD3afjbGwCfcKmmT/3KexeVk2V5JufJMhOP Pf4An1aZMZCGlvngk5fOfiEnCXCi2/eT =ABQl -----END PGP SIGNATURE----- --=_euceflkm5k0-- From owner-freebsd-stable@FreeBSD.ORG Tue Feb 10 17:57:45 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C28EB1065670; Tue, 10 Feb 2009 17:57:45 +0000 (UTC) (envelope-from bms@FreeBSD.org) Received: from out1.smtp.messagingengine.com (out1.smtp.messagingengine.com [66.111.4.25]) by mx1.freebsd.org (Postfix) with ESMTP id 5B9488FC16; Tue, 10 Feb 2009 17:57:45 +0000 (UTC) (envelope-from bms@FreeBSD.org) Received: from compute1.internal (compute1.internal [10.202.2.41]) by out1.messagingengine.com (Postfix) with ESMTP id D4943290455; Tue, 10 Feb 2009 12:57:44 -0500 (EST) Received: from heartbeat2.messagingengine.com ([10.202.2.161]) by compute1.internal (MEProxy); Tue, 10 Feb 2009 12:57:44 -0500 X-Sasl-enc: Spa2mJYz41ZpF9XUz7yrP+DfVK4nERfrhnC7JzEUBL1j 1234288664 Received: from empiric.lon.incunabulum.net (82-35-112-254.cable.ubr07.dals.blueyonder.co.uk [82.35.112.254]) by mail.messagingengine.com (Postfix) with ESMTPSA id 1CCF9391B1; Tue, 10 Feb 2009 12:57:44 -0500 (EST) Message-ID: <4991C017.8080903@FreeBSD.org> Date: Tue, 10 Feb 2009 17:57:43 +0000 From: "Bruce M. Simpson" User-Agent: Thunderbird 2.0.0.19 (X11/20090126) MIME-Version: 1.0 To: Robert Noland References: <329181233306971@webmail57.yandex.ru> <985A59F2-20CC-4779-A000-018E52B5BFA9@jump-ing.de> <101781233319948@webmail36.yandex.ru> <4983A3AE.90804@FreeBSD.org> <498F901A.7000900@FreeBSD.org> <1234159237.23838.3.camel@ferret.2hip.net> <4990835A.3020303@FreeBSD.org> <1234208586.1524.17.camel@ferret.2hip.net> <4990BC99.1070108@FreeBSD.org> <1234246034.1524.27.camel@ferret.2hip.net> In-Reply-To: <1234246034.1524.27.camel@ferret.2hip.net> X-Enigmail-Version: 0.95.6 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "S.N.Grigoriev" , Markus Hitter , freebsd-stable@freebsd.org Subject: Re: Unhappy Xorg upgrade X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Feb 2009 17:57:46 -0000 Robert Noland wrote: > ... > Ok, lets try another test... There is a scanpci util in the > libpciaccess port. We don't install it, but it does get built. Build > the port and run scanpci -v as root from the console. That should poke > all the pci devices on the box and tell you about them. See if that is > able to trigger the issue. > Well spotted. I saw this tool in "locate" output and was going to try it the other day, although I saw it didn't get installed, so assumed it was historical. Yes, This immediately triggered the issue without even running X on a fresh boot. From owner-freebsd-stable@FreeBSD.ORG Tue Feb 10 18:08:13 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B11831065698; Tue, 10 Feb 2009 18:08:13 +0000 (UTC) (envelope-from bms@FreeBSD.org) Received: from out1.smtp.messagingengine.com (out1.smtp.messagingengine.com [66.111.4.25]) by mx1.freebsd.org (Postfix) with ESMTP id 38D818FC1F; Tue, 10 Feb 2009 18:08:13 +0000 (UTC) (envelope-from bms@FreeBSD.org) Received: from compute2.internal (compute2.internal [10.202.2.42]) by out1.messagingengine.com (Postfix) with ESMTP id CAF7628FB1C; Tue, 10 Feb 2009 13:08:12 -0500 (EST) Received: from heartbeat1.messagingengine.com ([10.202.2.160]) by compute2.internal (MEProxy); Tue, 10 Feb 2009 13:08:12 -0500 X-Sasl-enc: A8uSDWSVrqm/kcV+zUJqiBQSifaxdgXZ56w4LMImUAA4 1234289289 Received: from empiric.lon.incunabulum.net (82-35-112-254.cable.ubr07.dals.blueyonder.co.uk [82.35.112.254]) by mail.messagingengine.com (Postfix) with ESMTPSA id CBDCB31568; Tue, 10 Feb 2009 13:08:08 -0500 (EST) Message-ID: <4991C287.708@FreeBSD.org> Date: Tue, 10 Feb 2009 18:08:07 +0000 From: "Bruce M. Simpson" User-Agent: Thunderbird 2.0.0.19 (X11/20090126) MIME-Version: 1.0 To: Robert Noland References: <329181233306971@webmail57.yandex.ru> <985A59F2-20CC-4779-A000-018E52B5BFA9@jump-ing.de> <101781233319948@webmail36.yandex.ru> <4983A3AE.90804@FreeBSD.org> <498F901A.7000900@FreeBSD.org> <1234159237.23838.3.camel@ferret.2hip.net> <4990835A.3020303@FreeBSD.org> <1234208586.1524.17.camel@ferret.2hip.net> <4990BC99.1070108@FreeBSD.org> <1234246034.1524.27.camel@ferret.2hip.net> <4991C017.8080903@FreeBSD.org> In-Reply-To: <4991C017.8080903@FreeBSD.org> X-Enigmail-Version: 0.95.6 Content-Type: multipart/mixed; boundary="------------070207010404000705020605" Cc: "S.N.Grigoriev" , Markus Hitter , freebsd-stable@freebsd.org Subject: Re: Unhappy Xorg upgrade X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Feb 2009 18:08:14 -0000 This is a multi-part message in MIME format. --------------070207010404000705020605 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Robert, Bruce M. Simpson wrote: > Yes, This immediately triggered the issue without even running X on a > fresh boot. > I'm going to post the following: * output of pciconf -lv, lspci -vv before scanpci is/was run * output of scanpci -v * output of pciconf -lv, lspci -vv after scanpci is/was run ...using script(1), and also the usbdevs -v output when the issue occurs. I've ran lspci (from ports/sysutils/pciutils) before without triggering the issue, of course it doesn't use libpciaccess. The fact that scanpci triggered the issue on its own would seem to point the finger squarely at libpciaccess. Additional data point: I have 'hide inactive PCI-e p2p bridge devices' disabled in my BIOS, although none of the affected devices are behind a PCI-e bridge. There is some sort of custom bus between the ATI northbridge and ALi southbridge which ain't PCI itself. --------------070207010404000705020605 Content-Type: text/plain; name="script.log" Content-Transfer-Encoding: base64 Content-Disposition: inline; filename="script.log" U2NyaXB0IHN0YXJ0ZWQgb24gVHVlIEZlYiAxMCAxODowNToxOCAyMDA5CllvdSBoYXZlIG1h aWwuDQphbmdsZXBvaXNlIyBwY2ljb25mIC1sdg0NCmhvc3RiMEBwY2kwOjA6MDowOgljbGFz cz0weDA2MDAwMCBjYXJkPTB4ODE4NTEwNDMgY2hpcD0weDU5NTAxMDAyIHJldj0weDEwIGhk cj0weDAwDQogICAgdmVuZG9yICAgICA9ICdBVEkgVGVjaG5vbG9naWVzIEluYycNCiAgICBk ZXZpY2UgICAgID0gJ1JTNDgwIEhvc3QgQnJpZGdlJw0KICAgIGNsYXNzICAgICAgPSBicmlk Z2UNCiAgICBzdWJjbGFzcyAgID0gSE9TVC1QQ0kNCnBjaWIxQHBjaTA6MDoyOjA6CWNsYXNz PTB4MDYwNDAwIGNhcmQ9MHg1OTUwMTAwMiBjaGlwPTB4NWEzNDEwMDIgcmV2PTB4MDAgaGRy PTB4MDENCiAgICB2ZW5kb3IgICAgID0gJ0FUSSBUZWNobm9sb2dpZXMgSW5jJw0KICAgIGRl dmljZSAgICAgPSAnUlM0ODAgUENJLVggUm9vdCBQb3J0Jw0KICAgIGNsYXNzICAgICAgPSBi cmlkZ2UNCiAgICBzdWJjbGFzcyAgID0gUENJLVBDSQ0KcGNpYjJAcGNpMDowOjY6MDoJY2xh c3M9MHgwNjA0MDAgY2FyZD0weDU5NTAxMDAyIGNoaXA9MHg1YTM4MTAwMiByZXY9MHgwMCBo ZHI9MHgwMQ0KICAgIHZlbmRvciAgICAgPSAnQVRJIFRlY2hub2xvZ2llcyBJbmMnDQogICAg ZGV2aWNlICAgICA9ICdSUzQ4MCBQQ0kgQnJpZGdlJw0KICAgIGNsYXNzICAgICAgPSBicmlk Z2UNCiAgICBzdWJjbGFzcyAgID0gUENJLVBDSQ0KcGNpYjNAcGNpMDowOjc6MDoJY2xhc3M9 MHgwNjA0MDAgY2FyZD0weDU5NTAxMDAyIGNoaXA9MHg1YTM5MTAwMiByZXY9MHgwMCBoZHI9 MHgwMQ0KICAgIHZlbmRvciAgICAgPSAnQVRJIFRlY2hub2xvZ2llcyBJbmMnDQogICAgZGV2 aWNlICAgICA9ICdSUzQ4MCBQQ0kgQnJpZGdlJw0KICAgIGNsYXNzICAgICAgPSBicmlkZ2UN CiAgICBzdWJjbGFzcyAgID0gUENJLVBDSQ0KaG9zdGIxQHBjaTA6MDoyNDowOgljbGFzcz0w eDA2MDAwMCBjYXJkPTB4MDAwMDAwMDAgY2hpcD0weDExMDAxMDIyIHJldj0weDAwIGhkcj0w eDAwDQogICAgdmVuZG9yICAgICA9ICdBZHZhbmNlZCBNaWNybyBEZXZpY2VzIChBTUQpJw0K ICAgIGRldmljZSAgICAgPSAnKEs4KSBBdGhsb24gNjQvT3B0ZXJvbiBIeXBlclRyYW5zcG9y dCBUZWNobm9sb2d5IENvbmZpZ3VyYXRpb24nDQogICAgY2xhc3MgICAgICA9IGJyaWRnZQ0K ICAgIHN1YmNsYXNzICAgPSBIT1NULVBDSQ0KaG9zdGIyQHBjaTA6MDoyNDoxOgljbGFzcz0w eDA2MDAwMCBjYXJkPTB4MDAwMDAwMDAgY2hpcD0weDExMDExMDIyIHJldj0weDAwIGhkcj0w eDAwDQogICAgdmVuZG9yICAgICA9ICdBZHZhbmNlZCBNaWNybyBEZXZpY2VzIChBTUQpJw0K ICAgIGRldmljZSAgICAgPSAnKEs4KSBBdGhsb24gNjQvT3B0ZXJvbiBBZGRyZXNzIE1hcCcN CiAgICBjbGFzcyAgICAgID0gYnJpZGdlDQogICAgc3ViY2xhc3MgICA9IEhPU1QtUENJDQpo b3N0YjNAcGNpMDowOjI0OjI6CWNsYXNzPTB4MDYwMDAwIGNhcmQ9MHgwMDAwMDAwMCBjaGlw PTB4MTEwMjEwMjIgcmV2PTB4MDAgaGRyPTB4MDANCiAgICB2ZW5kb3IgICAgID0gJ0FkdmFu Y2VkIE1pY3JvIERldmljZXMgKEFNRCknDQogICAgZGV2aWNlICAgICA9ICcoSzgpIEF0aGxv biA2NC9PcHRlcm9uIERSQU0gQ29udHJvbGxlcicNCiAgICBjbGFzcyAgICAgID0gYnJpZGdl DQogICAgc3ViY2xhc3MgICA9IEhPU1QtUENJDQpob3N0YjRAcGNpMDowOjI0OjM6CWNsYXNz PTB4MDYwMDAwIGNhcmQ9MHgwMDAwMDAwMCBjaGlwPTB4MTEwMzEwMjIgcmV2PTB4MDAgaGRy PTB4MDANCiAgICB2ZW5kb3IgICAgID0gJ0FkdmFuY2VkIE1pY3JvIERldmljZXMgKEFNRCkn DQogICAgZGV2aWNlICAgICA9ICcoSzgpIEF0aGxvbiA2NC9PcHRlcm9uIE1pc2NlbGxhbmVv dXMgQ29udHJvbCcNCiAgICBjbGFzcyAgICAgID0gYnJpZGdlDQogICAgc3ViY2xhc3MgICA9 IEhPU1QtUENJDQpwY2liNEBwY2kwOjA6MjU6MDoJY2xhc3M9MHgwNjA0MDAgY2FyZD0weDAw MDAwMDAwIGNoaXA9MHg1MjQ5MTBiOSByZXY9MHgwMCBoZHI9MHgwMQ0KICAgIHZlbmRvciAg ICAgPSAnQWNlciBMYWJzIEluY29ycG9yYXRlZCAoQUxpL1VMaSknDQogICAgZGV2aWNlICAg ICA9ICdNNTI0OSBIeXBlclRyYW5zcG9ydCB0byBQQ0kgQnJpZGdlJw0KICAgIGNsYXNzICAg ICAgPSBicmlkZ2UNCiAgICBzdWJjbGFzcyAgID0gUENJLVBDSQ0Kb2hjaTBAcGNpMDowOjI4 OjA6CWNsYXNzPTB4MGMwMzEwIGNhcmQ9MHg4MTU2MTA0MyBjaGlwPTB4NTIzNzEwYjkgcmV2 PTB4MDMgaGRyPTB4MDANCiAgICB2ZW5kb3IgICAgID0gJ0FjZXIgTGFicyBJbmNvcnBvcmF0 ZWQgKEFMaS9VTGkpJw0KICAgIGRldmljZSAgICAgPSAnTTUyNzMgQTEgZm9yIHdpbmRvd3Mg d2luIDk4IE9wZW5IQ0kgMS4xIFVTQiB0byAgMi4wJw0KICAgIGNsYXNzICAgICAgPSBzZXJp YWwgYnVzDQogICAgc3ViY2xhc3MgICA9IFVTQg0Kb2hjaTFAcGNpMDowOjI4OjE6CWNsYXNz PTB4MGMwMzEwIGNhcmQ9MHg4MTU2MTA0MyBjaGlwPTB4NTIzNzEwYjkgcmV2PTB4MDMgaGRy PTB4MDANCiAgICB2ZW5kb3IgICAgID0gJ0FjZXIgTGFicyBJbmNvcnBvcmF0ZWQgKEFMaS9V TGkpJw0KICAgIGRldmljZSAgICAgPSAnTTUyNzMgQTEgZm9yIHdpbmRvd3Mgd2luIDk4IE9w ZW5IQ0kgMS4xIFVTQiB0byAgMi4wJw0KICAgIGNsYXNzICAgICAgPSBzZXJpYWwgYnVzDQog ICAgc3ViY2xhc3MgICA9IFVTQg0Kb2hjaTJAcGNpMDowOjI4OjI6CWNsYXNzPTB4MGMwMzEw IGNhcmQ9MHg4MTU2MTA0MyBjaGlwPTB4NTIzNzEwYjkgcmV2PTB4MDMgaGRyPTB4MDANCiAg ICB2ZW5kb3IgICAgID0gJ0FjZXIgTGFicyBJbmNvcnBvcmF0ZWQgKEFMaS9VTGkpJw0KICAg IGRldmljZSAgICAgPSAnTTUyNzMgQTEgZm9yIHdpbmRvd3Mgd2luIDk4IE9wZW5IQ0kgMS4x IFVTQiB0byAgMi4wJw0KICAgIGNsYXNzICAgICAgPSBzZXJpYWwgYnVzDQogICAgc3ViY2xh c3MgICA9IFVTQg0KZWhjaTBAcGNpMDowOjI4OjM6CWNsYXNzPTB4MGMwMzIwIGNhcmQ9MHg4 MTU2MTA0MyBjaGlwPTB4NTIzOTEwYjkgcmV2PTB4MDEgaGRyPTB4MDANCiAgICB2ZW5kb3Ig ICAgID0gJ0FjZXIgTGFicyBJbmNvcnBvcmF0ZWQgKEFMaS9VTGkpJw0KICAgIGRldmljZSAg ICAgPSAnVVNCIDIuMCBFbmhhbmNlZCBIb3N0IENvbnRyb2xsZXInDQogICAgY2xhc3MgICAg ICA9IHNlcmlhbCBidXMNCiAgICBzdWJjbGFzcyAgID0gVVNCDQpoZGFjMEBwY2kwOjA6Mjk6 MDoJY2xhc3M9MHgwNDAzMDAgY2FyZD0weDgxYjQxMDQzIGNoaXA9MHg1NDYxMTBiOSByZXY9 MHgwMCBoZHI9MHgwMA0KICAgIHZlbmRvciAgICAgPSAnQWNlciBMYWJzIEluY29ycG9yYXRl ZCAoQUxpL1VMaSknDQogICAgZGV2aWNlICAgICA9ICc/PyBNaWNyb3NvZnQgVUFBIEJ1cyBE cml2ZXIgZm9yIEhpZ2ggRGVmaW5pdGlvbiBBdWRpbycNCiAgICBjbGFzcyAgICAgID0gbXVs dGltZWRpYQ0KICAgIHN1YmNsYXNzICAgPSBIREENCmlzYWIwQHBjaTA6MDozMDowOgljbGFz cz0weDA2MDEwMCBjYXJkPTB4ODE1NjEwNDMgY2hpcD0weDE1NzMxMGI5IHJldj0weDMxIGhk cj0weDAwDQogICAgdmVuZG9yICAgICA9ICdBY2VyIExhYnMgSW5jb3Jwb3JhdGVkIChBTGkv VUxpKScNCiAgICBkZXZpY2UgICAgID0gJ0FMSSBNMTU3MyBTb3V0aCBCcmlkZ2Ugd2l0aCBI eXBlcnRyYW5zcG9ydCBTdXBwb3J0Jw0KICAgIGNsYXNzICAgICAgPSBicmlkZ2UNCiAgICBz dWJjbGFzcyAgID0gUENJLUlTQQ0Kbm9uZTBAcGNpMDowOjMwOjE6CWNsYXNzPTB4MDY4MDAw IGNhcmQ9MHg4MTU2MTA0MyBjaGlwPTB4NzEwMTEwYjkgcmV2PTB4MDAgaGRyPTB4MDANCiAg ICB2ZW5kb3IgICAgID0gJ0FjZXIgTGFicyBJbmNvcnBvcmF0ZWQgKEFMaS9VTGkpJw0KICAg IGRldmljZSAgICAgPSAnQUxJIE03MTAxIFBvd2VyIE1hbmFnZW1lbnQgQ29udHJvbGxlcicN CiAgICBjbGFzcyAgICAgID0gYnJpZGdlDQphdGFwY2kwQHBjaTA6MDozMTowOgljbGFzcz0w eDAxMDE4YSBjYXJkPTB4ODE1NjEwNDMgY2hpcD0weDUyMjkxMGI5IHJldj0weGM3IGhkcj0w eDAwDQogICAgdmVuZG9yICAgICA9ICdBY2VyIExhYnMgSW5jb3Jwb3JhdGVkIChBTGkvVUxp KScNCiAgICBkZXZpY2UgICAgID0gJ001MjI5IFNvdXRoYnJpZGdlIEVJREUgQ29udHJvbGxl cicNCiAgICBjbGFzcyAgICAgID0gbWFzcyBzdG9yYWdlDQogICAgc3ViY2xhc3MgICA9IEFU QQ0KYXRhcGNpMUBwY2kwOjA6MzE6MToJY2xhc3M9MHgwMTA0MDAgY2FyZD0weDgxNTYxMDQz IGNoaXA9MHg1Mjg3MTBiOSByZXY9MHgwMiBoZHI9MHgwMA0KICAgIHZlbmRvciAgICAgPSAn QWNlciBMYWJzIEluY29ycG9yYXRlZCAoQUxpL1VMaSknDQogICAgZGV2aWNlICAgICA9ICc1 Mjg3MTg0OSBBTEkgU0FUQSBjb250cm9sbGVyJw0KICAgIGNsYXNzICAgICAgPSBtYXNzIHN0 b3JhZ2UNCiAgICBzdWJjbGFzcyAgID0gUkFJRA0KdmdhcGNpMEBwY2kwOjE6MDowOgljbGFz cz0weDAzMDAwMCBjYXJkPTB4MzAwMDE3NGIgY2hpcD0weDViNjMxMDAyIHJldj0weDAwIGhk cj0weDAwDQogICAgdmVuZG9yICAgICA9ICdBVEkgVGVjaG5vbG9naWVzIEluYycNCiAgICBk ZXZpY2UgICAgID0gJ1JhZGVvbiBYNTUwIFNlcmllcycNCiAgICBjbGFzcyAgICAgID0gZGlz cGxheQ0KICAgIHN1YmNsYXNzICAgPSBWR0ENCnZnYXBjaTFAcGNpMDoxOjA6MToJY2xhc3M9 MHgwMzgwMDAgY2FyZD0weDMwMDExNzRiIGNoaXA9MHg1YjczMTAwMiByZXY9MHgwMCBoZHI9 MHgwMA0KICAgIHZlbmRvciAgICAgPSAnQVRJIFRlY2hub2xvZ2llcyBJbmMnDQogICAgZGV2 aWNlICAgICA9ICdSYWRlb24gWDU1MCBTZXJpZXMgLSBTZWNvbmRhcnknDQogICAgY2xhc3Mg ICAgICA9IGRpc3BsYXkNCm1za2MwQHBjaTA6MjowOjA6CWNsYXNzPTB4MDIwMDAwIGNhcmQ9 MHg4MTQyMTA0MyBjaGlwPTB4NDM2MjExYWIgcmV2PTB4MTkgaGRyPTB4MDANCiAgICB2ZW5k b3IgICAgID0gJ01hcnZlbGwgU2VtaWNvbmR1Y3RvciAoV2FzOiBHYWxpbGVvIFRlY2hub2xv Z3kgTHRkKScNCiAgICBkZXZpY2UgICAgID0gJzg4RTgwNTMgTWFydmVsbCBZdWtvbiA4OEU4 MDUzIFBDSS1FIEdpZ2FiaXQgRXRoZXJuZXQgQ29udHJvbGxlcicNCiAgICBjbGFzcyAgICAg ID0gbmV0d29yaw0KICAgIHN1YmNsYXNzICAgPSBldGhlcm5ldA0Kbm9uZTFAcGNpMDo0OjE4 OjA6CWNsYXNzPTB4MGMwMDEwIGNhcmQ9MHg4MDhhMTA0MyBjaGlwPTB4MzA0NDExMDYgcmV2 PTB4ODAgaGRyPTB4MDANCiAgICB2ZW5kb3IgICAgID0gJ1ZJQSBUZWNobm9sb2dpZXMgSW5j Jw0KICAgIGRldmljZSAgICAgPSAnVlQ2MzA2IFZJQSBGaXJlIElJIElFRUUtMTM5NCBPSENJ IExpbmsgTGF5ZXIgQ29udHJvbGxlcicNCiAgICBjbGFzcyAgICAgID0gc2VyaWFsIGJ1cw0K ICAgIHN1YmNsYXNzICAgPSBGaXJlV2lyZQ0KYW5nbGVwb2lzZSMgbHNwY2kgLXZ2DQ0KMDA6 MDAuMCBIb3N0IGJyaWRnZTogQVRJIFRlY2hub2xvZ2llcyBJbmMgUlM0ODAgSG9zdCBCcmlk Z2UgKHJldiAxMCkNCglTdWJzeXN0ZW06IEFTVVNUZUsgQ29tcHV0ZXIgSW5jLiBEZXZpY2Ug ODE4NQ0KCUNvbnRyb2w6IEkvTy0gTWVtKyBCdXNNYXN0ZXIrIFNwZWNDeWNsZS0gTWVtV0lO Vi0gVkdBU25vb3AtIFBhckVyci0gU3RlcHBpbmctIFNFUlItIEZhc3RCMkItIERpc0lOVHgt DQoJU3RhdHVzOiBDYXAtIDY2TUh6KyBVREYtIEZhc3RCMkItIFBhckVyci0gREVWU0VMPW1l ZGl1bSA+VEFib3J0LSA8VEFib3J0LSA8TUFib3J0KyA+U0VSUi0gPFBFUlItIElOVHgtDQoJ TGF0ZW5jeTogMA0KDQowMDowMi4wIFBDSSBicmlkZ2U6IEFUSSBUZWNobm9sb2dpZXMgSW5j IFJTNDgwIFBDSS1YIFJvb3QgUG9ydCAocHJvZy1pZiAwMCBbTm9ybWFsIGRlY29kZV0pDQoJ Q29udHJvbDogSS9PKyBNZW0rIEJ1c01hc3RlcisgU3BlY0N5Y2xlLSBNZW1XSU5WLSBWR0FT bm9vcC0gUGFyRXJyLSBTdGVwcGluZy0gU0VSUisgRmFzdEIyQi0gRGlzSU5UeC0NCglTdGF0 dXM6IENhcCsgNjZNSHotIFVERi0gRmFzdEIyQi0gUGFyRXJyLSBERVZTRUw9ZmFzdCA+VEFi b3J0LSA8VEFib3J0LSA8TUFib3J0LSA+U0VSUi0gPFBFUlItIElOVHgtDQoJTGF0ZW5jeTog MCwgQ2FjaGUgTGluZSBTaXplOiA2NCBieXRlcw0KCUJ1czogcHJpbWFyeT0wMCwgc2Vjb25k YXJ5PTAxLCBzdWJvcmRpbmF0ZT0wMSwgc2VjLWxhdGVuY3k9MA0KCUkvTyBiZWhpbmQgYnJp ZGdlOiAwMDAwYjAwMC0wMDAwYmZmZg0KCU1lbW9yeSBiZWhpbmQgYnJpZGdlOiBmZTAwMDAw MC1mZThmZmZmZg0KCVByZWZldGNoYWJsZSBtZW1vcnkgYmVoaW5kIGJyaWRnZTogMDAwMDAw MDBjZmYwMDAwMC0wMDAwMDAwMGRmZWZmZmZmDQoJU2Vjb25kYXJ5IHN0YXR1czogNjZNSHot IEZhc3RCMkItIFBhckVyci0gREVWU0VMPWZhc3QgPlRBYm9ydC0gPFRBYm9ydC0gPE1BYm9y dCsgPFNFUlItIDxQRVJSLQ0KCUJyaWRnZUN0bDogUGFyaXR5KyBTRVJSKyBOb0lTQS0gVkdB KyBNQWJvcnQtID5SZXNldC0gRmFzdEIyQi0NCgkJUHJpRGlzY1Rtci0gU2VjRGlzY1Rtci0g RGlzY1RtclN0YXQtIERpc2NUbXJTRVJSRW4tDQoJQ2FwYWJpbGl0aWVzOiBbNTBdIFBvd2Vy IE1hbmFnZW1lbnQgdmVyc2lvbiAzDQoJCUZsYWdzOiBQTUVDbGstIERTSS0gRDEtIEQyLSBB dXhDdXJyZW50PTBtQSBQTUUoRDArLEQxLSxEMi0sRDNob3QrLEQzY29sZCspDQoJCVN0YXR1 czogRDAgUE1FLUVuYWJsZS0gRFNlbD0wIERTY2FsZT0wIFBNRS0NCglDYXBhYmlsaXRpZXM6 IFs1OF0gRXhwcmVzcyAodjEpIFJvb3QgUG9ydCAoU2xvdC0pLCBNU0kgMDANCgkJRGV2Q2Fw OglNYXhQYXlsb2FkIDEyOCBieXRlcywgUGhhbnRGdW5jIDAsIExhdGVuY3kgTDBzIDw2NG5z LCBMMSA8MXVzDQoJCQlFeHRUYWcrIFJCRS0gRkxSZXNldC0NCgkJRGV2Q3RsOglSZXBvcnQg ZXJyb3JzOiBDb3JyZWN0YWJsZS0gTm9uLUZhdGFsLSBGYXRhbC0gVW5zdXBwb3J0ZWQtDQoJ CQlSbHhkT3JkKyBFeHRUYWctIFBoYW50RnVuYy0gQXV4UHdyLSBOb1Nub29wKw0KCQkJTWF4 UGF5bG9hZCAxMjggYnl0ZXMsIE1heFJlYWRSZXEgMTI4IGJ5dGVzDQoJCURldlN0YToJQ29y ckVyci0gVW5jb3JyRXJyLSBGYXRhbEVyci0gVW5zdXBwUmVxLSBBdXhQd3ItIFRyYW5zUGVu ZC0NCgkJTG5rQ2FwOglQb3J0ICMwLCBTcGVlZCAyLjVHVC9zLCBXaWR0aCB4MTYsIEFTUE0g TDBzIEwxLCBMYXRlbmN5IEwwIDw2NG5zLCBMMSA8MXVzDQoJCQlDbG9ja1BNLSBTdXByaXNl LSBMTEFjdFJlcC0gQndOb3QtDQoJCUxua0N0bDoJQVNQTSBEaXNhYmxlZDsgUkNCIDY0IGJ5 dGVzIERpc2FibGVkLSBSZXRyYWluLSBDb21tQ2xrLQ0KCQkJRXh0U3luY2gtIENsb2NrUE0t IEF1dFdpZERpcy0gQldJbnQtIEF1dEJXSW50LQ0KCQlMbmtTdGE6CVNwZWVkIDIuNUdUL3Ms IFdpZHRoIHgxNiwgVHJFcnItIFRyYWluLSBTbG90Q2xrKyBETEFjdGl2ZS0gQldNZ210LSBB QldNZ210LQ0KCQlSb290Q3RsOiBFcnJDb3JyZWN0YWJsZS0gRXJyTm9uLUZhdGFsLSBFcnJG YXRhbC0gUE1FSW50RW5hLSBDUlNWaXNpYmxlLQ0KCQlSb290Q2FwOiBDUlNWaXNpYmxlLQ0K CQlSb290U3RhOiBQTUUgUmVxSUQgMDAwMCwgUE1FU3RhdHVzLSBQTUVQZW5kaW5nLQ0KCUNh cGFiaWxpdGllczogWzgwXSBNU0k6IE1hc2stIDY0Yml0LSBDb3VudD0xLzEgRW5hYmxlLQ0K CQlBZGRyZXNzOiAwMDAwMDAwMCAgRGF0YTogMDAwMA0KCUNhcGFiaWxpdGllczogW2IwXSBT dWJzeXN0ZW06IEFUSSBUZWNobm9sb2dpZXMgSW5jIERldmljZSA1OTUwDQoJQ2FwYWJpbGl0 aWVzOiBbYjhdIEh5cGVyVHJhbnNwb3J0OiBNU0kgTWFwcGluZyBFbmFibGUrIEZpeGVkKw0K DQowMDowNi4wIFBDSSBicmlkZ2U6IEFUSSBUZWNobm9sb2dpZXMgSW5jIFJTNDgwIFBDSSBC cmlkZ2UgKHByb2ctaWYgMDAgW05vcm1hbCBkZWNvZGVdKQ0KCUNvbnRyb2w6IEkvTysgTWVt KyBCdXNNYXN0ZXIrIFNwZWNDeWNsZS0gTWVtV0lOVi0gVkdBU25vb3AtIFBhckVyci0gU3Rl cHBpbmctIFNFUlIrIEZhc3RCMkItIERpc0lOVHgtDQoJU3RhdHVzOiBDYXArIDY2TUh6LSBV REYtIEZhc3RCMkItIFBhckVyci0gREVWU0VMPWZhc3QgPlRBYm9ydC0gPFRBYm9ydC0gPE1B Ym9ydC0gPlNFUlItIDxQRVJSLSBJTlR4LQ0KCUxhdGVuY3k6IDAsIENhY2hlIExpbmUgU2l6 ZTogNjQgYnl0ZXMNCglCdXM6IHByaW1hcnk9MDAsIHNlY29uZGFyeT0wMiwgc3Vib3JkaW5h dGU9MDIsIHNlYy1sYXRlbmN5PTANCglJL08gYmVoaW5kIGJyaWRnZTogMDAwMGMwMDAtMDAw MGNmZmYNCglNZW1vcnkgYmVoaW5kIGJyaWRnZTogZmU5MDAwMDAtZmU5ZmZmZmYNCglTZWNv bmRhcnkgc3RhdHVzOiA2Nk1Iei0gRmFzdEIyQi0gUGFyRXJyLSBERVZTRUw9ZmFzdCA+VEFi b3J0LSA8VEFib3J0LSA8TUFib3J0KyA8U0VSUi0gPFBFUlItDQoJQnJpZGdlQ3RsOiBQYXJp dHkrIFNFUlIrIE5vSVNBKyBWR0EtIE1BYm9ydC0gPlJlc2V0LSBGYXN0QjJCLQ0KCQlQcmlE aXNjVG1yLSBTZWNEaXNjVG1yLSBEaXNjVG1yU3RhdC0gRGlzY1RtclNFUlJFbi0NCglDYXBh YmlsaXRpZXM6IFs1MF0gUG93ZXIgTWFuYWdlbWVudCB2ZXJzaW9uIDMNCgkJRmxhZ3M6IFBN RUNsay0gRFNJLSBEMS0gRDItIEF1eEN1cnJlbnQ9MG1BIFBNRShEMCssRDEtLEQyLSxEM2hv dCssRDNjb2xkKykNCgkJU3RhdHVzOiBEMCBQTUUtRW5hYmxlLSBEU2VsPTAgRFNjYWxlPTAg UE1FLQ0KCUNhcGFiaWxpdGllczogWzU4XSBFeHByZXNzICh2MSkgUm9vdCBQb3J0IChTbG90 LSksIE1TSSAwMA0KCQlEZXZDYXA6CU1heFBheWxvYWQgMTI4IGJ5dGVzLCBQaGFudEZ1bmMg MCwgTGF0ZW5jeSBMMHMgPDY0bnMsIEwxIDwxdXMNCgkJCUV4dFRhZysgUkJFLSBGTFJlc2V0 LQ0KCQlEZXZDdGw6CVJlcG9ydCBlcnJvcnM6IENvcnJlY3RhYmxlLSBOb24tRmF0YWwtIEZh dGFsLSBVbnN1cHBvcnRlZC0NCgkJCVJseGRPcmQrIEV4dFRhZy0gUGhhbnRGdW5jLSBBdXhQ d3ItIE5vU25vb3ArDQoJCQlNYXhQYXlsb2FkIDEyOCBieXRlcywgTWF4UmVhZFJlcSAxMjgg Ynl0ZXMNCgkJRGV2U3RhOglDb3JyRXJyLSBVbmNvcnJFcnItIEZhdGFsRXJyLSBVbnN1cHBS ZXEtIEF1eFB3ci0gVHJhbnNQZW5kLQ0KCQlMbmtDYXA6CVBvcnQgIzMsIFNwZWVkIDIuNUdU L3MsIFdpZHRoIHgxLCBBU1BNIEwwcyBMMSwgTGF0ZW5jeSBMMCA8NjRucywgTDEgPDF1cw0K CQkJQ2xvY2tQTS0gU3VwcmlzZS0gTExBY3RSZXAtIEJ3Tm90LQ0KCQlMbmtDdGw6CUFTUE0g RGlzYWJsZWQ7IFJDQiA2NCBieXRlcyBEaXNhYmxlZC0gUmV0cmFpbi0gQ29tbUNsay0NCgkJ CUV4dFN5bmNoLSBDbG9ja1BNLSBBdXRXaWREaXMtIEJXSW50LSBBdXRCV0ludC0NCgkJTG5r U3RhOglTcGVlZCAyLjVHVC9zLCBXaWR0aCB4MSwgVHJFcnItIFRyYWluLSBTbG90Q2xrKyBE TEFjdGl2ZS0gQldNZ210LSBBQldNZ210LQ0KCQlSb290Q3RsOiBFcnJDb3JyZWN0YWJsZS0g RXJyTm9uLUZhdGFsLSBFcnJGYXRhbC0gUE1FSW50RW5hLSBDUlNWaXNpYmxlLQ0KCQlSb290 Q2FwOiBDUlNWaXNpYmxlLQ0KCQlSb290U3RhOiBQTUUgUmVxSUQgMDAwMCwgUE1FU3RhdHVz LSBQTUVQZW5kaW5nLQ0KCUNhcGFiaWxpdGllczogWzgwXSBNU0k6IE1hc2stIDY0Yml0LSBD b3VudD0xLzEgRW5hYmxlLQ0KCQlBZGRyZXNzOiAwMDAwMDAwMCAgRGF0YTogMDAwMA0KCUNh cGFiaWxpdGllczogW2IwXSBTdWJzeXN0ZW06IEFUSSBUZWNobm9sb2dpZXMgSW5jIERldmlj ZSA1OTUwDQoJQ2FwYWJpbGl0aWVzOiBbYjhdIEh5cGVyVHJhbnNwb3J0OiBNU0kgTWFwcGlu ZyBFbmFibGUrIEZpeGVkKw0KDQowMDowNy4wIFBDSSBicmlkZ2U6IEFUSSBUZWNobm9sb2dp ZXMgSW5jIFJTNDgwIFBDSSBCcmlkZ2UgKHByb2ctaWYgMDAgW05vcm1hbCBkZWNvZGVdKQ0K CUNvbnRyb2w6IEkvTy0gTWVtLSBCdXNNYXN0ZXIrIFNwZWNDeWNsZS0gTWVtV0lOVi0gVkdB U25vb3AtIFBhckVyci0gU3RlcHBpbmctIFNFUlIrIEZhc3RCMkItIERpc0lOVHgtDQoJU3Rh dHVzOiBDYXArIDY2TUh6LSBVREYtIEZhc3RCMkItIFBhckVyci0gREVWU0VMPWZhc3QgPlRB Ym9ydC0gPFRBYm9ydC0gPE1BYm9ydC0gPlNFUlItIDxQRVJSLSBJTlR4LQ0KCUxhdGVuY3k6 IDAsIENhY2hlIExpbmUgU2l6ZTogNjQgYnl0ZXMNCglCdXM6IHByaW1hcnk9MDAsIHNlY29u ZGFyeT0wMywgc3Vib3JkaW5hdGU9MDMsIHNlYy1sYXRlbmN5PTANCglTZWNvbmRhcnkgc3Rh dHVzOiA2Nk1Iei0gRmFzdEIyQi0gUGFyRXJyLSBERVZTRUw9ZmFzdCA+VEFib3J0LSA8VEFi b3J0LSA8TUFib3J0LSA8U0VSUi0gPFBFUlItDQoJQnJpZGdlQ3RsOiBQYXJpdHkrIFNFUlIr IE5vSVNBKyBWR0EtIE1BYm9ydC0gPlJlc2V0LSBGYXN0QjJCLQ0KCQlQcmlEaXNjVG1yLSBT ZWNEaXNjVG1yLSBEaXNjVG1yU3RhdC0gRGlzY1RtclNFUlJFbi0NCglDYXBhYmlsaXRpZXM6 IFs1MF0gUG93ZXIgTWFuYWdlbWVudCB2ZXJzaW9uIDMNCgkJRmxhZ3M6IFBNRUNsay0gRFNJ LSBEMS0gRDItIEF1eEN1cnJlbnQ9MG1BIFBNRShEMCssRDEtLEQyLSxEM2hvdCssRDNjb2xk KykNCgkJU3RhdHVzOiBEMCBQTUUtRW5hYmxlLSBEU2VsPTAgRFNjYWxlPTAgUE1FLQ0KCUNh cGFiaWxpdGllczogWzU4XSBFeHByZXNzICh2MSkgUm9vdCBQb3J0IChTbG90LSksIE1TSSAw MA0KCQlEZXZDYXA6CU1heFBheWxvYWQgMTI4IGJ5dGVzLCBQaGFudEZ1bmMgMCwgTGF0ZW5j eSBMMHMgPDY0bnMsIEwxIDwxdXMNCgkJCUV4dFRhZysgUkJFLSBGTFJlc2V0LQ0KCQlEZXZD dGw6CVJlcG9ydCBlcnJvcnM6IENvcnJlY3RhYmxlLSBOb24tRmF0YWwtIEZhdGFsLSBVbnN1 cHBvcnRlZC0NCgkJCVJseGRPcmQrIEV4dFRhZy0gUGhhbnRGdW5jLSBBdXhQd3ItIE5vU25v b3ArDQoJCQlNYXhQYXlsb2FkIDEyOCBieXRlcywgTWF4UmVhZFJlcSAxMjggYnl0ZXMNCgkJ RGV2U3RhOglDb3JyRXJyLSBVbmNvcnJFcnItIEZhdGFsRXJyLSBVbnN1cHBSZXEtIEF1eFB3 ci0gVHJhbnNQZW5kLQ0KCQlMbmtDYXA6CVBvcnQgIzI0NywgU3BlZWQgMi41R1QvcywgV2lk dGggeDEsIEFTUE0gTDBzIEwxLCBMYXRlbmN5IEwwIDw2NG5zLCBMMSA8MXVzDQoJCQlDbG9j a1BNLSBTdXByaXNlLSBMTEFjdFJlcC0gQndOb3QtDQoJCUxua0N0bDoJQVNQTSBEaXNhYmxl ZDsgUkNCIDY0IGJ5dGVzIERpc2FibGVkLSBSZXRyYWluLSBDb21tQ2xrLQ0KCQkJRXh0U3lu Y2gtIENsb2NrUE0tIEF1dFdpZERpcy0gQldJbnQtIEF1dEJXSW50LQ0KCQlMbmtTdGE6CVNw ZWVkIDIuNUdUL3MsIFdpZHRoIHgxNiwgVHJFcnItIFRyYWluLSBTbG90Q2xrKyBETEFjdGl2 ZS0gQldNZ210LSBBQldNZ210LQ0KCQlSb290Q3RsOiBFcnJDb3JyZWN0YWJsZS0gRXJyTm9u LUZhdGFsLSBFcnJGYXRhbC0gUE1FSW50RW5hLSBDUlNWaXNpYmxlLQ0KCQlSb290Q2FwOiBD UlNWaXNpYmxlLQ0KCQlSb290U3RhOiBQTUUgUmVxSUQgMDAwMCwgUE1FU3RhdHVzLSBQTUVQ ZW5kaW5nLQ0KCUNhcGFiaWxpdGllczogWzgwXSBNU0k6IE1hc2stIDY0Yml0LSBDb3VudD0x LzEgRW5hYmxlLQ0KCQlBZGRyZXNzOiAwMDAwMDAwMCAgRGF0YTogMDAwMA0KCUNhcGFiaWxp dGllczogW2IwXSBTdWJzeXN0ZW06IEFUSSBUZWNobm9sb2dpZXMgSW5jIERldmljZSA1OTUw DQoJQ2FwYWJpbGl0aWVzOiBbYjhdIEh5cGVyVHJhbnNwb3J0OiBNU0kgTWFwcGluZyBFbmFi bGUrIEZpeGVkKw0KDQowMDoxOC4wIEhvc3QgYnJpZGdlOiBBZHZhbmNlZCBNaWNybyBEZXZp Y2VzIFtBTURdIEs4IFtBdGhsb242NC9PcHRlcm9uXSBIeXBlclRyYW5zcG9ydCBUZWNobm9s b2d5IENvbmZpZ3VyYXRpb24NCglDb250cm9sOiBJL08tIE1lbS0gQnVzTWFzdGVyLSBTcGVj Q3ljbGUtIE1lbVdJTlYtIFZHQVNub29wLSBQYXJFcnItIFN0ZXBwaW5nLSBTRVJSLSBGYXN0 QjJCLSBEaXNJTlR4LQ0KCVN0YXR1czogQ2FwKyA2Nk1Iei0gVURGLSBGYXN0QjJCLSBQYXJF cnItIERFVlNFTD1mYXN0ID5UQWJvcnQtIDxUQWJvcnQtIDxNQWJvcnQtID5TRVJSLSA8UEVS Ui0gSU5UeC0NCglDYXBhYmlsaXRpZXM6IFs4MF0gSHlwZXJUcmFuc3BvcnQ6IEhvc3Qgb3Ig U2Vjb25kYXJ5IEludGVyZmFjZQ0KCQlDb21tYW5kOiBXYXJtUnN0KyBEYmxFbmQtIERldk51 bT0wIENoYWluU2lkZS0gSG9zdEhpZGUrIFNsYXZlLSA8RU9DRXJyLSBEVUwtDQoJCUxpbmsg Q29udHJvbDogQ0ZsRS0gQ1NULSBDRkUtIDxMa0ZhaWwtIEluaXQrIEVPQy0gVFhPLSA8Q1JD RXJyPTAgSXNvY0VuLSBMU0VuLSBFeHRDVEwtIDY0Yi0NCgkJTGluayBDb25maWc6IE1MV0k9 MTZiaXQgRHdGY0luLSBNTFdPPTE2Yml0IER3RmNPdXQtIExXST0xNmJpdCBEd0ZjSW5Fbi0g TFdPPTE2Yml0IER3RmNPdXRFbi0NCgkJUmV2aXNpb24gSUQ6IDEuMDINCgkJTGluayBGcmVx dWVuY3k6IDEuMEdIeg0KCQlMaW5rIEVycm9yOiA8UHJvdC0gPE92ZmwtIDxFT0MtIENUTFRt LQ0KCQlMaW5rIEZyZXF1ZW5jeSBDYXBhYmlsaXR5OiAyMDBNSHorIDMwME1Iei0gNDAwTUh6 KyA1MDBNSHotIDYwME1IeisgODAwTUh6KyAxLjBHSHorIDEuMkdIei0gMS40R0h6LSAxLjZH SHotIFZlbmQtDQoJCUZlYXR1cmUgQ2FwYWJpbGl0eTogSXNvY0ZDLSBMRFRTVE9QKyBDUkNU TS0gRUNUTFQtIDY0YkEtIFVJRFJELSBFeHRSUy0gVUNuZkUtDQoNCjAwOjE4LjEgSG9zdCBi cmlkZ2U6IEFkdmFuY2VkIE1pY3JvIERldmljZXMgW0FNRF0gSzggW0F0aGxvbjY0L09wdGVy b25dIEFkZHJlc3MgTWFwDQoJQ29udHJvbDogSS9PLSBNZW0tIEJ1c01hc3Rlci0gU3BlY0N5 Y2xlLSBNZW1XSU5WLSBWR0FTbm9vcC0gUGFyRXJyLSBTdGVwcGluZy0gU0VSUi0gRmFzdEIy Qi0gRGlzSU5UeC0NCglTdGF0dXM6IENhcC0gNjZNSHotIFVERi0gRmFzdEIyQi0gUGFyRXJy LSBERVZTRUw9ZmFzdCA+VEFib3J0LSA8VEFib3J0LSA8TUFib3J0LSA+U0VSUi0gPFBFUlIt IElOVHgtDQoNCjAwOjE4LjIgSG9zdCBicmlkZ2U6IEFkdmFuY2VkIE1pY3JvIERldmljZXMg W0FNRF0gSzggW0F0aGxvbjY0L09wdGVyb25dIERSQU0gQ29udHJvbGxlcg0KCUNvbnRyb2w6 IEkvTy0gTWVtLSBCdXNNYXN0ZXItIFNwZWNDeWNsZS0gTWVtV0lOVi0gVkdBU25vb3AtIFBh ckVyci0gU3RlcHBpbmctIFNFUlItIEZhc3RCMkItIERpc0lOVHgtDQoJU3RhdHVzOiBDYXAt IDY2TUh6LSBVREYtIEZhc3RCMkItIFBhckVyci0gREVWU0VMPWZhc3QgPlRBYm9ydC0gPFRB Ym9ydC0gPE1BYm9ydC0gPlNFUlItIDxQRVJSLSBJTlR4LQ0KDQowMDoxOC4zIEhvc3QgYnJp ZGdlOiBBZHZhbmNlZCBNaWNybyBEZXZpY2VzIFtBTURdIEs4IFtBdGhsb242NC9PcHRlcm9u XSBNaXNjZWxsYW5lb3VzIENvbnRyb2wNCglDb250cm9sOiBJL08tIE1lbS0gQnVzTWFzdGVy LSBTcGVjQ3ljbGUtIE1lbVdJTlYtIFZHQVNub29wLSBQYXJFcnItIFN0ZXBwaW5nLSBTRVJS LSBGYXN0QjJCLSBEaXNJTlR4LQ0KCVN0YXR1czogQ2FwLSA2Nk1Iei0gVURGLSBGYXN0QjJC LSBQYXJFcnItIERFVlNFTD1mYXN0ID5UQWJvcnQtIDxUQWJvcnQtIDxNQWJvcnQtID5TRVJS LSA8UEVSUi0gSU5UeC0NCg0KMDA6MTkuMCBQQ0kgYnJpZGdlOiBBTGkgQ29ycG9yYXRpb24g TTUyNDkgSFRUIHRvIFBDSSBCcmlkZ2UgKHByb2ctaWYgMDAgW05vcm1hbCBkZWNvZGVdKQ0K CUNvbnRyb2w6IEkvTysgTWVtKyBCdXNNYXN0ZXIrIFNwZWNDeWNsZS0gTWVtV0lOVi0gVkdB U25vb3AtIFBhckVyci0gU3RlcHBpbmctIFNFUlIrIEZhc3RCMkItIERpc0lOVHgtDQoJU3Rh dHVzOiBDYXArIDY2TUh6LSBVREYtIEZhc3RCMkItIFBhckVyci0gREVWU0VMPWZhc3QgPlRB Ym9ydC0gPFRBYm9ydC0gPE1BYm9ydCsgPlNFUlIrIDxQRVJSLSBJTlR4LQ0KCUxhdGVuY3k6 IDANCglCdXM6IHByaW1hcnk9MDAsIHNlY29uZGFyeT0wNCwgc3Vib3JkaW5hdGU9MDQsIHNl Yy1sYXRlbmN5PTY0DQoJSS9PIGJlaGluZCBicmlkZ2U6IDAwMDBkMDAwLTAwMDBkZmZmDQoJ TWVtb3J5IGJlaGluZCBicmlkZ2U6IGZlYTAwMDAwLWZlYWZmZmZmDQoJU2Vjb25kYXJ5IHN0 YXR1czogNjZNSHotIEZhc3RCMkItIFBhckVyci0gREVWU0VMPW1lZGl1bSA+VEFib3J0LSA8 VEFib3J0LSA8TUFib3J0KyA8U0VSUisgPFBFUlIrDQoJQnJpZGdlQ3RsOiBQYXJpdHkrIFNF UlIrIE5vSVNBKyBWR0EtIE1BYm9ydC0gPlJlc2V0LSBGYXN0QjJCLQ0KCQlQcmlEaXNjVG1y LSBTZWNEaXNjVG1yLSBEaXNjVG1yU3RhdC0gRGlzY1RtclNFUlJFbi0NCglDYXBhYmlsaXRp ZXM6IFtjMF0gSHlwZXJUcmFuc3BvcnQ6IE1TSSBNYXBwaW5nIEVuYWJsZSsgRml4ZWQrDQoN CjAwOjFjLjAgVVNCIENvbnRyb2xsZXI6IEFMaSBDb3Jwb3JhdGlvbiBVU0IgMS4xIENvbnRy b2xsZXIgKHJldiAwMykgKHByb2ctaWYgMTAgW09IQ0ldKQ0KCVN1YnN5c3RlbTogQVNVU1Rl SyBDb21wdXRlciBJbmMuIERldmljZSA4MTU2DQoJQ29udHJvbDogSS9PKyBNZW0rIEJ1c01h c3RlcisgU3BlY0N5Y2xlLSBNZW1XSU5WKyBWR0FTbm9vcC0gUGFyRXJyLSBTdGVwcGluZy0g U0VSUisgRmFzdEIyQi0gRGlzSU5UeC0NCglTdGF0dXM6IENhcC0gNjZNSHorIFVERi0gRmFz dEIyQisgUGFyRXJyLSBERVZTRUw9bWVkaXVtID5UQWJvcnQtIDxUQWJvcnQtIDxNQWJvcnQt ID5TRVJSLSA8UEVSUisgSU5UeCsNCglMYXRlbmN5OiA2NCAoMjAwMDBucyBtYXgpLCBDYWNo ZSBMaW5lIFNpemU6IDY0IGJ5dGVzDQoJSW50ZXJydXB0OiBwaW4gQSByb3V0ZWQgdG8gSVJR IDE3DQoJUmVnaW9uIDA6IE1lbW9yeSBhdCBmZWJmYzAwMCAoMzItYml0LCBub24tcHJlZmV0 Y2hhYmxlKQ0KDQowMDoxYy4xIFVTQiBDb250cm9sbGVyOiBBTGkgQ29ycG9yYXRpb24gVVNC IDEuMSBDb250cm9sbGVyIChyZXYgMDMpIChwcm9nLWlmIDEwIFtPSENJXSkNCglTdWJzeXN0 ZW06IEFTVVNUZUsgQ29tcHV0ZXIgSW5jLiBEZXZpY2UgODE1Ng0KCUNvbnRyb2w6IEkvTysg TWVtKyBCdXNNYXN0ZXIrIFNwZWNDeWNsZS0gTWVtV0lOVisgVkdBU25vb3AtIFBhckVyci0g U3RlcHBpbmctIFNFUlIrIEZhc3RCMkItIERpc0lOVHgtDQoJU3RhdHVzOiBDYXAtIDY2TUh6 KyBVREYtIEZhc3RCMkIrIFBhckVyci0gREVWU0VMPW1lZGl1bSA+VEFib3J0LSA8VEFib3J0 LSA8TUFib3J0LSA+U0VSUi0gPFBFUlIrIElOVHgrDQoJTGF0ZW5jeTogNjQgKDIwMDAwbnMg bWF4KSwgQ2FjaGUgTGluZSBTaXplOiA2NCBieXRlcw0KCUludGVycnVwdDogcGluIEIgcm91 dGVkIHRvIElSUSAxOA0KCVJlZ2lvbiAwOiBNZW1vcnkgYXQgZmViZmQwMDAgKDMyLWJpdCwg bm9uLXByZWZldGNoYWJsZSkNCg0KMDA6MWMuMiBVU0IgQ29udHJvbGxlcjogQUxpIENvcnBv cmF0aW9uIFVTQiAxLjEgQ29udHJvbGxlciAocmV2IDAzKSAocHJvZy1pZiAxMCBbT0hDSV0p DQoJU3Vic3lzdGVtOiBBU1VTVGVLIENvbXB1dGVyIEluYy4gRGV2aWNlIDgxNTYNCglDb250 cm9sOiBJL08rIE1lbSsgQnVzTWFzdGVyKyBTcGVjQ3ljbGUtIE1lbVdJTlYrIFZHQVNub29w LSBQYXJFcnItIFN0ZXBwaW5nLSBTRVJSKyBGYXN0QjJCLSBEaXNJTlR4LQ0KCVN0YXR1czog Q2FwLSA2Nk1IeisgVURGLSBGYXN0QjJCKyBQYXJFcnItIERFVlNFTD1tZWRpdW0gPlRBYm9y dC0gPFRBYm9ydC0gPE1BYm9ydC0gPlNFUlItIDxQRVJSKyBJTlR4Kw0KCUxhdGVuY3k6IDY0 ICgyMDAwMG5zIG1heCksIENhY2hlIExpbmUgU2l6ZTogNjQgYnl0ZXMNCglJbnRlcnJ1cHQ6 IHBpbiBDIHJvdXRlZCB0byBJUlEgMTkNCglSZWdpb24gMDogTWVtb3J5IGF0IGZlYmZlMDAw ICgzMi1iaXQsIG5vbi1wcmVmZXRjaGFibGUpDQoNCjAwOjFjLjMgVVNCIENvbnRyb2xsZXI6 IEFMaSBDb3Jwb3JhdGlvbiBVU0IgMi4wIENvbnRyb2xsZXIgKHJldiAwMSkgKHByb2ctaWYg MjAgW0VIQ0ldKQ0KCVN1YnN5c3RlbTogQVNVU1RlSyBDb21wdXRlciBJbmMuIERldmljZSA4 MTU2DQoJQ29udHJvbDogSS9PLSBNZW0rIEJ1c01hc3RlcisgU3BlY0N5Y2xlLSBNZW1XSU5W KyBWR0FTbm9vcC0gUGFyRXJyLSBTdGVwcGluZy0gU0VSUisgRmFzdEIyQi0gRGlzSU5UeC0N CglTdGF0dXM6IENhcCsgNjZNSHorIFVERi0gRmFzdEIyQisgUGFyRXJyLSBERVZTRUw9bWVk aXVtID5UQWJvcnQtIDxUQWJvcnQtIDxNQWJvcnQtID5TRVJSLSA8UEVSUisgSU5UeC0NCglM YXRlbmN5OiA2NCAoNDAwMG5zIG1pbiwgODAwMG5zIG1heCksIENhY2hlIExpbmUgU2l6ZTog NjQgYnl0ZXMNCglJbnRlcnJ1cHQ6IHBpbiBEIHJvdXRlZCB0byBJUlEgMjMNCglSZWdpb24g MDogTWVtb3J5IGF0IGZlYmZmYzAwICgzMi1iaXQsIG5vbi1wcmVmZXRjaGFibGUpDQoJQ2Fw YWJpbGl0aWVzOiBbNTBdIFBvd2VyIE1hbmFnZW1lbnQgdmVyc2lvbiAyDQoJCUZsYWdzOiBQ TUVDbGstIERTSS0gRDEtIEQyLSBBdXhDdXJyZW50PTBtQSBQTUUoRDArLEQxLSxEMi0sRDNo b3QrLEQzY29sZCspDQoJCVN0YXR1czogRDAgUE1FLUVuYWJsZS0gRFNlbD0wIERTY2FsZT0w IFBNRS0NCglDYXBhYmlsaXRpZXM6IFs1OF0gRGVidWcgcG9ydDogQkFSPTEgb2Zmc2V0PTAw OTANCg0KMDA6MWQuMCBBdWRpbyBkZXZpY2U6IEFMaSBDb3Jwb3JhdGlvbiBIaWdoIERlZmlu aXRpb24gQXVkaW8vQUMnOTcgSG9zdCBDb250cm9sbGVyDQoJU3Vic3lzdGVtOiBBU1VTVGVL IENvbXB1dGVyIEluYy4gRGV2aWNlIDgxYjQNCglDb250cm9sOiBJL08tIE1lbSsgQnVzTWFz dGVyKyBTcGVjQ3ljbGUtIE1lbVdJTlYtIFZHQVNub29wLSBQYXJFcnItIFN0ZXBwaW5nLSBT RVJSKyBGYXN0QjJCLSBEaXNJTlR4LQ0KCVN0YXR1czogQ2FwKyA2Nk1Iei0gVURGLSBGYXN0 QjJCLSBQYXJFcnItIERFVlNFTD1tZWRpdW0gPlRBYm9ydC0gPFRBYm9ydC0gPE1BYm9ydC0g PlNFUlItIDxQRVJSLSBJTlR4LQ0KCUxhdGVuY3k6IDY0ICg0MDAwbnMgbWluLCAyMDAwMG5z IG1heCkNCglJbnRlcnJ1cHQ6IHBpbiBDIHJvdXRlZCB0byBJUlEgMjINCglSZWdpb24gMDog TWVtb3J5IGF0IGZlYmY4MDAwICg2NC1iaXQsIG5vbi1wcmVmZXRjaGFibGUpDQoJQ2FwYWJp bGl0aWVzOiBbNTBdIFBvd2VyIE1hbmFnZW1lbnQgdmVyc2lvbiAyDQoJCUZsYWdzOiBQTUVD bGstIERTSS0gRDEtIEQyLSBBdXhDdXJyZW50PTU1bUEgUE1FKEQwKyxEMS0sRDItLEQzaG90 KyxEM2NvbGQrKQ0KCQlTdGF0dXM6IEQwIFBNRS1FbmFibGUtIERTZWw9MCBEU2NhbGU9MCBQ TUUtDQoNCjAwOjFlLjAgSVNBIGJyaWRnZTogQUxpIENvcnBvcmF0aW9uIFBDSSB0byBMUEMg Q29udHJvbGxlciAocmV2IDMxKQ0KCVN1YnN5c3RlbTogQVNVU1RlSyBDb21wdXRlciBJbmMu IERldmljZSA4MTU2DQoJQ29udHJvbDogSS9PKyBNZW0rIEJ1c01hc3RlcisgU3BlY0N5Y2xl KyBNZW1XSU5WLSBWR0FTbm9vcC0gUGFyRXJyLSBTdGVwcGluZy0gU0VSUi0gRmFzdEIyQi0g RGlzSU5UeC0NCglTdGF0dXM6IENhcC0gNjZNSHotIFVERi0gRmFzdEIyQi0gUGFyRXJyLSBE RVZTRUw9bWVkaXVtID5UQWJvcnQtIDxUQWJvcnQtIDxNQWJvcnQtID5TRVJSLSA8UEVSUi0g SU5UeC0NCglMYXRlbmN5OiAwICgyNTBucyBtaW4sIDYwMDBucyBtYXgpDQoJSW50ZXJydXB0 OiBwaW4gPyByb3V0ZWQgdG8gSVJRIDI1NQ0KDQowMDoxZS4xIEJyaWRnZTogQUxpIENvcnBv cmF0aW9uIE03MTAxIFBvd2VyIE1hbmFnZW1lbnQgQ29udHJvbGxlciBbUE1VXQ0KCVN1YnN5 c3RlbTogQVNVU1RlSyBDb21wdXRlciBJbmMuIERldmljZSA4MTU2DQoJQ29udHJvbDogSS9P LSBNZW0tIEJ1c01hc3Rlci0gU3BlY0N5Y2xlLSBNZW1XSU5WLSBWR0FTbm9vcC0gUGFyRXJy LSBTdGVwcGluZy0gU0VSUi0gRmFzdEIyQi0gRGlzSU5UeC0NCglTdGF0dXM6IENhcC0gNjZN SHotIFVERi0gRmFzdEIyQi0gUGFyRXJyLSBERVZTRUw9bWVkaXVtID5UQWJvcnQtIDxUQWJv cnQtIDxNQWJvcnQtID5TRVJSLSA8UEVSUi0gSU5UeC0NCg0KMDA6MWYuMCBJREUgaW50ZXJm YWNlOiBBTGkgQ29ycG9yYXRpb24gTTUyMjkgSURFIChyZXYgYzcpIChwcm9nLWlmIDhhIFtN YXN0ZXIgU2VjUCBQcmlQXSkNCglTdWJzeXN0ZW06IEFTVVNUZUsgQ29tcHV0ZXIgSW5jLiBE ZXZpY2UgODE1Ng0KCUNvbnRyb2w6IEkvTysgTWVtLSBCdXNNYXN0ZXIrIFNwZWNDeWNsZS0g TWVtV0lOVi0gVkdBU25vb3AtIFBhckVyci0gU3RlcHBpbmctIFNFUlItIEZhc3RCMkItIERp c0lOVHgtDQoJU3RhdHVzOiBDYXArIDY2TUh6KyBVREYtIEZhc3RCMkIrIFBhckVyci0gREVW U0VMPW1lZGl1bSA+VEFib3J0LSA8VEFib3J0LSA8TUFib3J0LSA+U0VSUi0gPFBFUlItIElO VHgtDQoJTGF0ZW5jeTogMzINCglJbnRlcnJ1cHQ6IHBpbiBBIHJvdXRlZCB0byBJUlEgMjU1 DQoJUmVnaW9uIDQ6IEkvTyBwb3J0cyBhdCBmZjAwDQoJQ2FwYWJpbGl0aWVzOiBbNjBdIFBv d2VyIE1hbmFnZW1lbnQgdmVyc2lvbiAyDQoJCUZsYWdzOiBQTUVDbGstIERTSS0gRDEtIEQy LSBBdXhDdXJyZW50PTBtQSBQTUUoRDAtLEQxLSxEMi0sRDNob3QtLEQzY29sZC0pDQoJCVN0 YXR1czogRDAgUE1FLUVuYWJsZS0gRFNlbD0wIERTY2FsZT0wIFBNRS0NCg0KMDA6MWYuMSBS QUlEIGJ1cyBjb250cm9sbGVyOiBBTGkgQ29ycG9yYXRpb24gVUxpIDUyODcgU0FUQSAocmV2 IDAyKQ0KCVN1YnN5c3RlbTogQVNVU1RlSyBDb21wdXRlciBJbmMuIERldmljZSA4MTU2DQoJ Q29udHJvbDogSS9PKyBNZW0rIEJ1c01hc3RlcisgU3BlY0N5Y2xlLSBNZW1XSU5WLSBWR0FT bm9vcC0gUGFyRXJyLSBTdGVwcGluZy0gU0VSUisgRmFzdEIyQi0gRGlzSU5UeC0NCglTdGF0 dXM6IENhcCsgNjZNSHorIFVERi0gRmFzdEIyQisgUGFyRXJyLSBERVZTRUw9bWVkaXVtID5U QWJvcnQtIDxUQWJvcnQtIDxNQWJvcnQtID5TRVJSLSA8UEVSUi0gSU5UeC0NCglMYXRlbmN5 OiAxMjgsIENhY2hlIExpbmUgU2l6ZTogNTEyIGJ5dGVzDQoJSW50ZXJydXB0OiBwaW4gQSBy b3V0ZWQgdG8gSVJRIDIxDQoJUmVnaW9uIDA6IEkvTyBwb3J0cyBhdCBlYzAwDQoJUmVnaW9u IDE6IEkvTyBwb3J0cyBhdCBlODgwDQoJUmVnaW9uIDI6IEkvTyBwb3J0cyBhdCBlODAwDQoJ UmVnaW9uIDM6IEkvTyBwb3J0cyBhdCBlNDgwDQoJUmVnaW9uIDQ6IEkvTyBwb3J0cyBhdCBl NDAwDQoJUmVnaW9uIDU6IE1lbW9yeSBhdCBmZWJmZjgwMCAoMzItYml0LCBub24tcHJlZmV0 Y2hhYmxlKQ0KCUNhcGFiaWxpdGllczogWzYwXSBQb3dlciBNYW5hZ2VtZW50IHZlcnNpb24g Mg0KCQlGbGFnczogUE1FQ2xrLSBEU0ktIEQxLSBEMi0gQXV4Q3VycmVudD0wbUEgUE1FKEQw LSxEMS0sRDItLEQzaG90KyxEM2NvbGQtKQ0KCQlTdGF0dXM6IEQwIFBNRS1FbmFibGUtIERT ZWw9MCBEU2NhbGU9MCBQTUUrDQoNCjAxOjAwLjAgVkdBIGNvbXBhdGlibGUgY29udHJvbGxl cjogQVRJIFRlY2hub2xvZ2llcyBJbmMgUlYzNzAgW1NhcHBoaXJlIFg1NTAgU2lsZW50XSAo cHJvZy1pZiAwMCBbVkdBIGNvbnRyb2xsZXJdKQ0KCVN1YnN5c3RlbTogUEMgUGFydG5lciBM aW1pdGVkIERldmljZSAzMDAwDQoJQ29udHJvbDogSS9PKyBNZW0rIEJ1c01hc3RlcisgU3Bl Y0N5Y2xlLSBNZW1XSU5WLSBWR0FTbm9vcC0gUGFyRXJyLSBTdGVwcGluZy0gU0VSUisgRmFz dEIyQi0gRGlzSU5UeC0NCglTdGF0dXM6IENhcCsgNjZNSHotIFVERi0gRmFzdEIyQi0gUGFy RXJyLSBERVZTRUw9ZmFzdCA+VEFib3J0LSA8VEFib3J0LSA8TUFib3J0LSA+U0VSUi0gPFBF UlItIElOVHgtDQoJTGF0ZW5jeTogMCwgQ2FjaGUgTGluZSBTaXplOiA2NCBieXRlcw0KCUlu dGVycnVwdDogcGluIEEgcm91dGVkIHRvIElSUSAxOA0KCVJlZ2lvbiAwOiBNZW1vcnkgYXQg ZDAwMDAwMDAgKDMyLWJpdCwgcHJlZmV0Y2hhYmxlKQ0KCVJlZ2lvbiAxOiBJL08gcG9ydHMg YXQgYjgwMA0KCVJlZ2lvbiAyOiBNZW1vcnkgYXQgZmU0MDAwMDAgKDMyLWJpdCwgbm9uLXBy ZWZldGNoYWJsZSkNCglFeHBhbnNpb24gUk9NIGF0IGZlOGUwMDAwIFtkaXNhYmxlZF0NCglD YXBhYmlsaXRpZXM6IFs1MF0gUG93ZXIgTWFuYWdlbWVudCB2ZXJzaW9uIDINCgkJRmxhZ3M6 IFBNRUNsay0gRFNJLSBEMSsgRDIrIEF1eEN1cnJlbnQ9MG1BIFBNRShEMC0sRDEtLEQyLSxE M2hvdC0sRDNjb2xkLSkNCgkJU3RhdHVzOiBEMCBQTUUtRW5hYmxlLSBEU2VsPTAgRFNjYWxl PTAgUE1FLQ0KCUNhcGFiaWxpdGllczogWzU4XSBFeHByZXNzICh2MSkgRW5kcG9pbnQsIE1T SSAwMA0KCQlEZXZDYXA6CU1heFBheWxvYWQgMTI4IGJ5dGVzLCBQaGFudEZ1bmMgMCwgTGF0 ZW5jeSBMMHMgPDEyOG5zLCBMMSA8MnVzDQoJCQlFeHRUYWcrIEF0dG5CdG4tIEF0dG5JbmQt IFB3ckluZC0gUkJFLSBGTFJlc2V0LQ0KCQlEZXZDdGw6CVJlcG9ydCBlcnJvcnM6IENvcnJl Y3RhYmxlLSBOb24tRmF0YWwtIEZhdGFsLSBVbnN1cHBvcnRlZC0NCgkJCVJseGRPcmQrIEV4 dFRhZy0gUGhhbnRGdW5jLSBBdXhQd3ItIE5vU25vb3ArDQoJCQlNYXhQYXlsb2FkIDEyOCBi eXRlcywgTWF4UmVhZFJlcSAxMjggYnl0ZXMNCgkJRGV2U3RhOglDb3JyRXJyLSBVbmNvcnJF cnItIEZhdGFsRXJyLSBVbnN1cHBSZXEtIEF1eFB3ci0gVHJhbnNQZW5kLQ0KCQlMbmtDYXA6 CVBvcnQgIzAsIFNwZWVkIDIuNUdUL3MsIFdpZHRoIHgxNiwgQVNQTSBMMHMgTDEsIExhdGVu Y3kgTDAgPDEyOG5zLCBMMSA8MXVzDQoJCQlDbG9ja1BNLSBTdXByaXNlLSBMTEFjdFJlcC0g QndOb3QtDQoJCUxua0N0bDoJQVNQTSBEaXNhYmxlZDsgUkNCIDY0IGJ5dGVzIERpc2FibGVk LSBSZXRyYWluLSBDb21tQ2xrLQ0KCQkJRXh0U3luY2gtIENsb2NrUE0tIEF1dFdpZERpcy0g QldJbnQtIEF1dEJXSW50LQ0KCQlMbmtTdGE6CVNwZWVkIDIuNUdUL3MsIFdpZHRoIHgxNiwg VHJFcnItIFRyYWluLSBTbG90Q2xrKyBETEFjdGl2ZS0gQldNZ210LSBBQldNZ210LQ0KCUNh cGFiaWxpdGllczogWzgwXSBNU0k6IE1hc2stIDY0Yml0KyBDb3VudD0xLzEgRW5hYmxlLQ0K CQlBZGRyZXNzOiAwMDAwMDAwMDAwMDAwMDAwICBEYXRhOiAwMDAwDQoNCjAxOjAwLjEgRGlz cGxheSBjb250cm9sbGVyOiBBVEkgVGVjaG5vbG9naWVzIEluYyBSVjM3MCBzZWNvbmRhcnkg W1NhcHBoaXJlIFg1NTAgU2lsZW50XQ0KCVN1YnN5c3RlbTogUEMgUGFydG5lciBMaW1pdGVk IERldmljZSAzMDAxDQoJQ29udHJvbDogSS9PKyBNZW0rIEJ1c01hc3RlcisgU3BlY0N5Y2xl LSBNZW1XSU5WLSBWR0FTbm9vcC0gUGFyRXJyLSBTdGVwcGluZy0gU0VSUi0gRmFzdEIyQi0g RGlzSU5UeC0NCglTdGF0dXM6IENhcCsgNjZNSHotIFVERi0gRmFzdEIyQi0gUGFyRXJyLSBE RVZTRUw9ZmFzdCA+VEFib3J0LSA8VEFib3J0LSA8TUFib3J0LSA+U0VSUi0gPFBFUlItIElO VHgtDQoJTGF0ZW5jeTogMCwgQ2FjaGUgTGluZSBTaXplOiA2NCBieXRlcw0KCUludGVycnVw dDogcGluID8gcm91dGVkIHRvIElSUSAyNTUNCglSZWdpb24gMDogTWVtb3J5IGF0IGZlOGQw MDAwICgzMi1iaXQsIG5vbi1wcmVmZXRjaGFibGUpDQoJQ2FwYWJpbGl0aWVzOiBbNTBdIFBv d2VyIE1hbmFnZW1lbnQgdmVyc2lvbiAyDQoJCUZsYWdzOiBQTUVDbGstIERTSS0gRDErIEQy KyBBdXhDdXJyZW50PTBtQSBQTUUoRDAtLEQxLSxEMi0sRDNob3QtLEQzY29sZC0pDQoJCVN0 YXR1czogRDAgUE1FLUVuYWJsZS0gRFNlbD0wIERTY2FsZT0wIFBNRS0NCglDYXBhYmlsaXRp ZXM6IFs1OF0gRXhwcmVzcyAodjEpIEVuZHBvaW50LCBNU0kgMDANCgkJRGV2Q2FwOglNYXhQ YXlsb2FkIDEyOCBieXRlcywgUGhhbnRGdW5jIDAsIExhdGVuY3kgTDBzIDwxMjhucywgTDEg PDJ1cw0KCQkJRXh0VGFnLSBBdHRuQnRuLSBBdHRuSW5kLSBQd3JJbmQtIFJCRS0gRkxSZXNl dC0NCgkJRGV2Q3RsOglSZXBvcnQgZXJyb3JzOiBDb3JyZWN0YWJsZS0gTm9uLUZhdGFsLSBG YXRhbC0gVW5zdXBwb3J0ZWQtDQoJCQlSbHhkT3JkLSBFeHRUYWctIFBoYW50RnVuYy0gQXV4 UHdyLSBOb1Nub29wLQ0KCQkJTWF4UGF5bG9hZCAxMjggYnl0ZXMsIE1heFJlYWRSZXEgMTI4 IGJ5dGVzDQoJCURldlN0YToJQ29yckVyci0gVW5jb3JyRXJyLSBGYXRhbEVyci0gVW5zdXBw UmVxLSBBdXhQd3ItIFRyYW5zUGVuZC0NCgkJTG5rQ2FwOglQb3J0ICMwLCBTcGVlZCAyLjVH VC9zLCBXaWR0aCB4MTYsIEFTUE0gTDBzIEwxLCBMYXRlbmN5IEwwIDwxMjhucywgTDEgPDF1 cw0KCQkJQ2xvY2tQTS0gU3VwcmlzZS0gTExBY3RSZXAtIEJ3Tm90LQ0KCQlMbmtDdGw6CUFT UE0gRGlzYWJsZWQ7IFJDQiA2NCBieXRlcyBEaXNhYmxlZC0gUmV0cmFpbi0gQ29tbUNsay0N CgkJCUV4dFN5bmNoLSBDbG9ja1BNLSBBdXRXaWREaXMtIEJXSW50LSBBdXRCV0ludC0NCgkJ TG5rU3RhOglTcGVlZCAyLjVHVC9zLCBXaWR0aCB4MTYsIFRyRXJyLSBUcmFpbi0gU2xvdENs aysgRExBY3RpdmUtIEJXTWdtdC0gQUJXTWdtdC0NCg0KMDI6MDAuMCBFdGhlcm5ldCBjb250 cm9sbGVyOiBNYXJ2ZWxsIFRlY2hub2xvZ3kgR3JvdXAgTHRkLiA4OEU4MDUzIFBDSS1FIEdp Z2FiaXQgRXRoZXJuZXQgQ29udHJvbGxlciAocmV2IDE5KQ0KCVN1YnN5c3RlbTogQVNVU1Rl SyBDb21wdXRlciBJbmMuIE1hcnZlbGwgODhFODA1MyBHaWdhYml0IEV0aGVybmV0IGNvbnRy b2xsZXIgUENJZSAoQXN1cykNCglDb250cm9sOiBJL08rIE1lbSsgQnVzTWFzdGVyKyBTcGVj Q3ljbGUtIE1lbVdJTlYtIFZHQVNub29wLSBQYXJFcnItIFN0ZXBwaW5nLSBTRVJSKyBGYXN0 QjJCLSBEaXNJTlR4LQ0KCVN0YXR1czogQ2FwKyA2Nk1Iei0gVURGLSBGYXN0QjJCLSBQYXJF cnItIERFVlNFTD1mYXN0ID5UQWJvcnQtIDxUQWJvcnQtIDxNQWJvcnQtID5TRVJSLSA8UEVS Ui0gSU5UeC0NCglMYXRlbmN5OiAwLCBDYWNoZSBMaW5lIFNpemU6IDY0IGJ5dGVzDQoJSW50 ZXJydXB0OiBwaW4gQSByb3V0ZWQgdG8gSVJRIDE4DQoJUmVnaW9uIDA6IE1lbW9yeSBhdCBm ZTlmYzAwMCAoNjQtYml0LCBub24tcHJlZmV0Y2hhYmxlKQ0KCVJlZ2lvbiAyOiBJL08gcG9y dHMgYXQgYzgwMA0KCUV4cGFuc2lvbiBST00gYXQgZmU5YzAwMDAgW2Rpc2FibGVkXQ0KCUNh cGFiaWxpdGllczogWzQ4XSBQb3dlciBNYW5hZ2VtZW50IHZlcnNpb24gMg0KCQlGbGFnczog UE1FQ2xrLSBEU0ktIEQxKyBEMisgQXV4Q3VycmVudD0wbUEgUE1FKEQwKyxEMSssRDIrLEQz aG90KyxEM2NvbGQrKQ0KCQlTdGF0dXM6IEQwIFBNRS1FbmFibGUtIERTZWw9MCBEU2NhbGU9 MSBQTUUtDQoJQ2FwYWJpbGl0aWVzOiBbNTBdIFZpdGFsIFByb2R1Y3QgRGF0YSA8Pz4NCglD YXBhYmlsaXRpZXM6IFs1Y10gTVNJOiBNYXNrLSA2NGJpdCsgQ291bnQ9Mi8yIEVuYWJsZSsN CgkJQWRkcmVzczogMDAwMDAwMDBmZWUwMDAwMCAgRGF0YTogMDAzMg0KCUNhcGFiaWxpdGll czogW2UwXSBFeHByZXNzICh2MSkgTGVnYWN5IEVuZHBvaW50LCBNU0kgMDANCgkJRGV2Q2Fw OglNYXhQYXlsb2FkIDEyOCBieXRlcywgUGhhbnRGdW5jIDAsIExhdGVuY3kgTDBzIHVubGlt aXRlZCwgTDEgdW5saW1pdGVkDQoJCQlFeHRUYWctIEF0dG5CdG4tIEF0dG5JbmQtIFB3cklu ZC0gUkJFLSBGTFJlc2V0LQ0KCQlEZXZDdGw6CVJlcG9ydCBlcnJvcnM6IENvcnJlY3RhYmxl LSBOb24tRmF0YWwtIEZhdGFsLSBVbnN1cHBvcnRlZC0NCgkJCVJseGRPcmQtIEV4dFRhZy0g UGhhbnRGdW5jLSBBdXhQd3ItIE5vU25vb3AtDQoJCQlNYXhQYXlsb2FkIDEyOCBieXRlcywg TWF4UmVhZFJlcSA0MDk2IGJ5dGVzDQoJCURldlN0YToJQ29yckVycisgVW5jb3JyRXJyKyBG YXRhbEVyci0gVW5zdXBwUmVxKyBBdXhQd3IrIFRyYW5zUGVuZC0NCgkJTG5rQ2FwOglQb3J0 ICMzLCBTcGVlZCAyLjVHVC9zLCBXaWR0aCB4MSwgQVNQTSBMMHMsIExhdGVuY3kgTDAgPDI1 Nm5zLCBMMSB1bmxpbWl0ZWQNCgkJCUNsb2NrUE0tIFN1cHJpc2UtIExMQWN0UmVwLSBCd05v dC0NCgkJTG5rQ3RsOglBU1BNIERpc2FibGVkOyBSQ0IgMTI4IGJ5dGVzIERpc2FibGVkLSBS ZXRyYWluLSBDb21tQ2xrLQ0KCQkJRXh0U3luY2gtIENsb2NrUE0tIEF1dFdpZERpcy0gQldJ bnQtIEF1dEJXSW50LQ0KCQlMbmtTdGE6CVNwZWVkIDIuNUdUL3MsIFdpZHRoIHgxLCBUckVy ci0gVHJhaW4tIFNsb3RDbGsrIERMQWN0aXZlLSBCV01nbXQtIEFCV01nbXQtDQoNCjA0OjEy LjAgRmlyZVdpcmUgKElFRUUgMTM5NCk6IFZJQSBUZWNobm9sb2dpZXMsIEluYy4gVlQ2MzA2 IEZpcmUgSUkgSUVFRSAxMzk0IE9IQ0kgTGluayBMYXllciBDb250cm9sbGVyIChyZXYgODAp IChwcm9nLWlmIDEwIFtPSENJXSkNCglTdWJzeXN0ZW06IEFTVVNUZUsgQ29tcHV0ZXIgSW5j LiBBOFYvQThOL1A0UDgwMCBzZXJpZXMgbW90aGVyYm9hcmQNCglDb250cm9sOiBJL08rIE1l bSsgQnVzTWFzdGVyKyBTcGVjQ3ljbGUtIE1lbVdJTlYrIFZHQVNub29wLSBQYXJFcnItIFN0 ZXBwaW5nLSBTRVJSKyBGYXN0QjJCLSBEaXNJTlR4LQ0KCVN0YXR1czogQ2FwKyA2Nk1Iei0g VURGLSBGYXN0QjJCLSBQYXJFcnItIERFVlNFTD1tZWRpdW0gPlRBYm9ydC0gPFRBYm9ydC0g PE1BYm9ydC0gPlNFUlItIDxQRVJSLSBJTlR4LQ0KCUxhdGVuY3k6IDY0ICg4MDAwbnMgbWF4 KSwgQ2FjaGUgTGluZSBTaXplOiA2NCBieXRlcw0KCUludGVycnVwdDogcGluIEEgcm91dGVk IHRvIElSUSAxNg0KCVJlZ2lvbiAwOiBNZW1vcnkgYXQgZmVhZmU4MDAgKDMyLWJpdCwgbm9u LXByZWZldGNoYWJsZSkNCglSZWdpb24gMTogSS9PIHBvcnRzIGF0IGRjMDANCglDYXBhYmls aXRpZXM6IFs1MF0gUG93ZXIgTWFuYWdlbWVudCB2ZXJzaW9uIDINCgkJRmxhZ3M6IFBNRUNs ay0gRFNJLSBEMS0gRDIrIEF1eEN1cnJlbnQ9MG1BIFBNRShEMC0sRDEtLEQyKyxEM2hvdCss RDNjb2xkKykNCgkJU3RhdHVzOiBEMCBQTUUtRW5hYmxlLSBEU2VsPTAgRFNjYWxlPTAgUE1F LQ0KDQphbmdsZXBvaXNlIyBzY2FuCBtbSwgbW0sIG1tLCBtbSwcHBwcHBwd1c2JkZXZzIC12 DQ0KQ29udHJvbGxlciAvZGV2L3VzYjA6DQphZGRyIDE6IGZ1bGwgc3BlZWQsIHNlbGYgcG93 ZXJlZCwgY29uZmlnIDEsIE9IQ0kgcm9vdCBodWIoMHgwMDAwKSwgQWNlckxhYnMoMHgwMDAw KSwgcmV2IDEuMDANCiBwb3J0IDEgYWRkciAyOiBmdWxsIHNwZWVkLCBzZWxmIHBvd2VyZWQs IGNvbmZpZyAxLCBwcm9kdWN0IDB4MjA0NigweDIwNDYpLCB2ZW5kb3IgMHgwNDUxKDB4MDQ1 MSksIHJldiAxLjI1DQogIHBvcnQgMSBwb3dlcmVkDQogIHBvcnQgMiBwb3dlcmVkDQogIHBv cnQgMyBwb3dlcmVkDQogIHBvcnQgNCBwb3dlcmVkDQogcG9ydCAyIHBvd2VyZWQNCiBwb3J0 IDMgcG93ZXJlZA0KQ29udHJvbGxlciAvZGV2L3VzYjE6DQphZGRyIDE6IGZ1bGwgc3BlZWQs IHNlbGYgcG93ZXJlZCwgY29uZmlnIDEsIE9IQ0kgcm9vdCBodWIoMHgwMDAwKSwgQWNlckxh YnMoMHgwMDAwKSwgcmV2IDEuMDANCiBwb3J0IDEgcG93ZXJlZA0KIHBvcnQgMiBwb3dlcmVk DQogcG9ydCAzIHBvd2VyZWQNCkNvbnRyb2xsZXIgL2Rldi91c2IyOg0KYWRkciAxOiBmdWxs IHNwZWVkLCBzZWxmIHBvd2VyZWQsIGNvbmZpZyAxLCBPSENJIHJvb3QgaHViKDB4MDAwMCks IEFjZXJMYWJzKDB4MDAwMCksIHJldiAxLjAwDQogcG9ydCAxIHBvd2VyZWQNCiBwb3J0IDIg cG93ZXJlZA0KIHBvcnQgMyBwb3dlcmVkDQpDb250cm9sbGVyIC9kZXYvdXNiMzoNCmFkZHIg MTogaGlnaCBzcGVlZCwgc2VsZiBwb3dlcmVkLCBjb25maWcgMSwgRUhDSSByb290IGh1Yigw eDAwMDApLCBBY2VyTGFicygweDAwMDApLCByZXYgMS4wMA0KIHBvcnQgMSBwb3dlcmVkDQog cG9ydCAyIHBvd2VyZWQNCiBwb3J0IDMgcG93ZXJlZA0KIHBvcnQgNCBwb3dlcmVkDQogcG9y dCA1IHBvd2VyZWQNCiBwb3J0IDYgcG93ZXJlZA0KIHBvcnQgNyBhZGRyIDI6IGhpZ2ggc3Bl ZWQsIHNlbGYgcG93ZXJlZCwgY29uZmlnIDEsIFVTQjIuMCBIdWIoMHgwNjA2KSwgdmVuZG9y IDB4MDVlMygweDA1ZTMpLCByZXYgNy4wMg0KICBwb3J0IDEgcG93ZXJlZA0KICBwb3J0IDIg cG93ZXJlZA0KICBwb3J0IDMgcG93ZXJlZA0KICBwb3J0IDQgcG93ZXJlZA0KIHBvcnQgOCBw b3dlcmVkDQphbmdsZXBvaXNlIyBzY2FucGNpIC12DQ0Kc2NhbnBjaTogQ29tbWFuZCBub3Qg Zm91bmQuDQphbmdsZXBvaXNlIyBjZCAvdXNyL3BvcnRzL2Rpc3RmaWxlcy8IG1tLCBtbSwgb W0sIG1tLCBtbSwgbW0sIG1tLCBtbSwgbW0sIG1tLZW11bGF0b3JzLwgbW0sIG1tLCBtbSwgb W0sIG1tLCBtbSwgbW0sIG1tLCBtbSwgbW0tkZXZlbC9saWJwYwdpYWNjZXNzLw0NCmFuZ2xl cG9pc2UjIGxzDQ0KTWFrZWZpbGUJZmlsZXMJCXBrZy1wbGlzdA0KZGlzdGluZm8JcGtnLWRl c2NyCXdvcmsNCmFuZ2xlcG9pc2UjIGNkIHdvcmsvbGlicGNpYWNjZXNzLTAuMTAuNS9zcmMN DQphbmdsZXBvaXNlIyAuL3NjbggbW0thbnBjaSAtdg0NCg0KcGNpIGJ1cyAweDAwMDAgY2Fy ZG51bSAweDAwIGZ1bmN0aW9uIDB4MDA6IHZlbmRvciAweDEwMDIgZGV2aWNlIDB4NTk1MA0K IEFUSSBUZWNobm9sb2dpZXMgSW5jIFJTNDgwIEhvc3QgQnJpZGdlDQogQ2FyZFZlbmRvciAw eDEwNDMgY2FyZCAweDgxODUgKEFTVVNUZUsgQ29tcHV0ZXIgSW5jLiwgQ2FyZCB1bmtub3du KQ0KICBTVEFUVVMgICAgMHgyMjIwICBDT01NQU5EIDB4MDAwNg0KICBDTEFTUyAgICAgMHgw NiAweDAwIDB4MDAgIFJFVklTSU9OIDB4MTANCiAgQklTVCAgICAgIDB4MDAgIEhFQURFUiAw eDAwICBMQVRFTkNZIDB4MDAgIENBQ0hFIDB4MDANCnNpemUgPSAweDANCnNpemUgPSAweDAN CnNpemUgPSAweDANCnNpemUgPSAweDANCnNpemUgPSAweDANCnNpemUgPSAweDANCiAgTUFY X0xBVCAgIDB4MDAgIE1JTl9HTlQgMHgwMCAgSU5UX1BJTiAweDAwICBJTlRfTElORSAweGZm DQpzaXplID0gMHgwDQpzaXplID0gMHgwDQpzaXplID0gMHgwDQpzaXplID0gMHgwDQpzaXpl ID0gMHgwDQpzaXplID0gMHgwDQpzaXplID0gMHgwDQpzaXplID0gMHgwDQpzaXplID0gMHgw DQpzaXplID0gMHgwDQpzaXplID0gMHgwDQpzaXplID0gMHgwDQoNCnBjaSBidXMgMHgwMDAw IGNhcmRudW0gMHgwMiBmdW5jdGlvbiAweDAwOiB2ZW5kb3IgMHgxMDAyIGRldmljZSAweDVh MzQNCiBBVEkgVGVjaG5vbG9naWVzIEluYyBSUzQ4MCBQQ0ktWCBSb290IFBvcnQNCiBDYXJk VmVuZG9yIDB4MTAwMiBjYXJkIDB4NTk1MCAoQVRJIFRlY2hub2xvZ2llcyBJbmMsIENhcmQg dW5rbm93bikNCiAgU1RBVFVTICAgIDB4MDAxMCAgQ09NTUFORCAweDAxMDcNCiAgQ0xBU1Mg ICAgIDB4MDYgMHgwNCAweDAwICBSRVZJU0lPTiAweDAwDQogIEJJU1QgICAgICAweDAwICBI RUFERVIgMHgwMSAgTEFURU5DWSAweDAwICBDQUNIRSAweDEwDQpzaXplID0gMHgwDQpzaXpl ID0gMHgwDQogIE1BWF9MQVQgICAweDAwICBNSU5fR05UIDB4MGIgIElOVF9QSU4gMHgwMCAg SU5UX0xJTkUgMHhmZg0Kc2l6ZSA9IDB4MA0Kc2l6ZSA9IDB4MA0KICBCdXM6IHByaW1hcnk9 MDAsIHNlY29uZGFyeT0wMSwgc3Vib3JkaW5hdGU9MDEsIHNlYy1sYXRlbmN5PTANCiAgSS9P IGJlaGluZCBicmlkZ2U6IDAwMDBiMDAwLTAwMDBiZmZmDQogIE1lbW9yeSBiZWhpbmQgYnJp ZGdlOiBmZTAwMDAwMC1mZTgwZmZmZg0KICBQcmVmZXRjaGFibGUgbWVtb3J5IGJlaGluZCBi cmlkZ2U6IGNmZjAwMDAwLWRmZTBmZmZmDQoNCnBjaSBidXMgMHgwMDAwIGNhcmRudW0gMHgw NiBmdW5jdGlvbiAweDAwOiB2ZW5kb3IgMHgxMDAyIGRldmljZSAweDVhMzgNCiBBVEkgVGVj aG5vbG9naWVzIEluYyBSUzQ4MCBQQ0kgQnJpZGdlDQogQ2FyZFZlbmRvciAweDEwMDIgY2Fy ZCAweDU5NTAgKEFUSSBUZWNobm9sb2dpZXMgSW5jLCBDYXJkIHVua25vd24pDQogIFNUQVRV UyAgICAweDAwMTAgIENPTU1BTkQgMHgwMTA3DQogIENMQVNTICAgICAweDA2IDB4MDQgMHgw MCAgUkVWSVNJT04gMHgwMA0KICBCSVNUICAgICAgMHgwMCAgSEVBREVSIDB4MDEgIExBVEVO Q1kgMHgwMCAgQ0FDSEUgMHgxMA0Kc2l6ZSA9IDB4MA0Kc2l6ZSA9IDB4MA0KICBNQVhfTEFU ICAgMHgwMCAgTUlOX0dOVCAweDA3ICBJTlRfUElOIDB4MDAgIElOVF9MSU5FIDB4ZmYNCnNp emUgPSAweDANCnNpemUgPSAweDANCiAgQnVzOiBwcmltYXJ5PTAwLCBzZWNvbmRhcnk9MDIs IHN1Ym9yZGluYXRlPTAyLCBzZWMtbGF0ZW5jeT0wDQogIEkvTyBiZWhpbmQgYnJpZGdlOiAw MDAwYzAwMC0wMDAwY2ZmZg0KICBNZW1vcnkgYmVoaW5kIGJyaWRnZTogZmU5MDAwMDAtZmU5 MGZmZmYNCiAgUHJlZmV0Y2hhYmxlIG1lbW9yeSBiZWhpbmQgYnJpZGdlOiBmZmYwMDAwMC0w MDAwZmZmZg0KDQpwY2kgYnVzIDB4MDAwMCBjYXJkbnVtIDB4MDcgZnVuY3Rpb24gMHgwMDog dmVuZG9yIDB4MTAwMiBkZXZpY2UgMHg1YTM5DQogQVRJIFRlY2hub2xvZ2llcyBJbmMgUlM0 ODAgUENJIEJyaWRnZQ0KIENhcmRWZW5kb3IgMHgxMDAyIGNhcmQgMHg1OTUwIChBVEkgVGVj aG5vbG9naWVzIEluYywgQ2FyZCB1bmtub3duKQ0KICBTVEFUVVMgICAgMHgwMDEwICBDT01N QU5EIDB4MDEwNA0KICBDTEFTUyAgICAgMHgwNiAweDA0IDB4MDAgIFJFVklTSU9OIDB4MDAN CiAgQklTVCAgICAgIDB4MDAgIEhFQURFUiAweDAxICBMQVRFTkNZIDB4MDAgIENBQ0hFIDB4 MTANCnNpemUgPSAweDANCnNpemUgPSAweDANCiAgTUFYX0xBVCAgIDB4MDAgIE1JTl9HTlQg MHgwNyAgSU5UX1BJTiAweDAwICBJTlRfTElORSAweGZmDQpzaXplID0gMHgwDQpzaXplID0g MHgwDQogIEJ1czogcHJpbWFyeT0wMCwgc2Vjb25kYXJ5PTAzLCBzdWJvcmRpbmF0ZT0wMywg c2VjLWxhdGVuY3k9MA0KICBJL08gYmVoaW5kIGJyaWRnZTogMDAwMGYwMDAtMDAwMDBmZmYN CiAgTWVtb3J5IGJlaGluZCBicmlkZ2U6IGZmZjAwMDAwLTAwMDBmZmZmDQogIFByZWZldGNo YWJsZSBtZW1vcnkgYmVoaW5kIGJyaWRnZTogZmZmMDAwMDAtMDAwMGZmZmYNCg0KcGNpIGJ1 cyAweDAwMDAgY2FyZG51bSAweDE4IGZ1bmN0aW9uIDB4MDA6IHZlbmRvciAweDEwMjIgZGV2 aWNlIDB4MTEwMA0KIEFkdmFuY2VkIE1pY3JvIERldmljZXMgW0FNRF0gSzggW0F0aGxvbjY0 L09wdGVyb25dIEh5cGVyVHJhbnNwb3J0IFRlY2hub2xvZ3kgQ29uZmlndXJhdGlvbg0KIENh cmRWZW5kb3IgMHgwMDAwIGNhcmQgMHgwMDAwIChDYXJkIHVua25vd24pDQogIFNUQVRVUyAg ICAweDAwMTAgIENPTU1BTkQgMHgwMDAwDQogIENMQVNTICAgICAweDA2IDB4MDAgMHgwMCAg UkVWSVNJT04gMHgwMA0KICBCSVNUICAgICAgMHgwMCAgSEVBREVSIDB4ODAgIExBVEVOQ1kg MHgwMCAgQ0FDSEUgMHgwMA0Kc2l6ZSA9IDB4MA0Kc2l6ZSA9IDB4MA0Kc2l6ZSA9IDB4MA0K c2l6ZSA9IDB4MA0Kc2l6ZSA9IDB4MA0Kc2l6ZSA9IDB4MA0KICBNQVhfTEFUICAgMHgwMCAg TUlOX0dOVCAweDAwICBJTlRfUElOIDB4MDAgIElOVF9MSU5FIDB4ZmYNCnNpemUgPSAweDAN CnNpemUgPSAweDANCnNpemUgPSAweDANCnNpemUgPSAweDANCnNpemUgPSAweDANCnNpemUg PSAweDANCnNpemUgPSAweDANCnNpemUgPSAweDANCnNpemUgPSAweDANCnNpemUgPSAweDAN CnNpemUgPSAweDANCnNpemUgPSAweDANCg0KcGNpIGJ1cyAweDAwMDAgY2FyZG51bSAweDE4 IGZ1bmN0aW9uIDB4MDE6IHZlbmRvciAweDEwMjIgZGV2aWNlIDB4MTEwMQ0KIEFkdmFuY2Vk IE1pY3JvIERldmljZXMgW0FNRF0gSzggW0F0aGxvbjY0L09wdGVyb25dIEFkZHJlc3MgTWFw DQogQ2FyZFZlbmRvciAweDAwMDAgY2FyZCAweDAwMDAgKENhcmQgdW5rbm93bikNCiAgU1RB VFVTICAgIDB4MDAwMCAgQ09NTUFORCAweDAwMDANCiAgQ0xBU1MgICAgIDB4MDYgMHgwMCAw eDAwICBSRVZJU0lPTiAweDAwDQogIEJJU1QgICAgICAweDAwICBIRUFERVIgMHg4MCAgTEFU RU5DWSAweDAwICBDQUNIRSAweDAwDQpzaXplID0gMHgwDQpzaXplID0gMHgwDQpzaXplID0g MHgwDQpzaXplID0gMHgwDQpzaXplID0gMHgwDQpzaXplID0gMHgwDQogIE1BWF9MQVQgICAw eDAwICBNSU5fR05UIDB4MDAgIElOVF9QSU4gMHgwMCAgSU5UX0xJTkUgMHhmZg0Kc2l6ZSA9 IDB4MA0Kc2l6ZSA9IDB4MA0Kc2l6ZSA9IDB4MA0Kc2l6ZSA9IDB4MA0Kc2l6ZSA9IDB4MA0K c2l6ZSA9IDB4MA0Kc2l6ZSA9IDB4MA0Kc2l6ZSA9IDB4MA0Kc2l6ZSA9IDB4MA0Kc2l6ZSA9 IDB4MA0Kc2l6ZSA9IDB4MA0Kc2l6ZSA9IDB4MA0KDQpwY2kgYnVzIDB4MDAwMCBjYXJkbnVt IDB4MTggZnVuY3Rpb24gMHgwMjogdmVuZG9yIDB4MTAyMiBkZXZpY2UgMHgxMTAyDQogQWR2 YW5jZWQgTWljcm8gRGV2aWNlcyBbQU1EXSBLOCBbQXRobG9uNjQvT3B0ZXJvbl0gRFJBTSBD b250cm9sbGVyDQogQ2FyZFZlbmRvciAweDAwMDAgY2FyZCAweDAwMDAgKENhcmQgdW5rbm93 bikNCiAgU1RBVFVTICAgIDB4MDAwMCAgQ09NTUFORCAweDAwMDANCiAgQ0xBU1MgICAgIDB4 MDYgMHgwMCAweDAwICBSRVZJU0lPTiAweDAwDQogIEJJU1QgICAgICAweDAwICBIRUFERVIg MHg4MCAgTEFURU5DWSAweDAwICBDQUNIRSAweDAwDQpzaXplID0gMHgwDQpzaXplID0gMHgw DQpzaXplID0gMHgwDQpzaXplID0gMHgwDQpzaXplID0gMHgwDQpzaXplID0gMHgwDQogIE1B WF9MQVQgICAweDAwICBNSU5fR05UIDB4MDAgIElOVF9QSU4gMHgwMCAgSU5UX0xJTkUgMHhm Zg0Kc2l6ZSA9IDB4MA0Kc2l6ZSA9IDB4MA0Kc2l6ZSA9IDB4MA0Kc2l6ZSA9IDB4MA0Kc2l6 ZSA9IDB4MA0Kc2l6ZSA9IDB4MA0Kc2l6ZSA9IDB4MA0Kc2l6ZSA9IDB4MA0Kc2l6ZSA9IDB4 MA0Kc2l6ZSA9IDB4MA0Kc2l6ZSA9IDB4MA0Kc2l6ZSA9IDB4MA0KDQpwY2kgYnVzIDB4MDAw MCBjYXJkbnVtIDB4MTggZnVuY3Rpb24gMHgwMzogdmVuZG9yIDB4MTAyMiBkZXZpY2UgMHgx MTAzDQogQWR2YW5jZWQgTWljcm8gRGV2aWNlcyBbQU1EXSBLOCBbQXRobG9uNjQvT3B0ZXJv bl0gTWlzY2VsbGFuZW91cyBDb250cm9sDQogQ2FyZFZlbmRvciAweDAwMDAgY2FyZCAweDAw MDAgKENhcmQgdW5rbm93bikNCiAgU1RBVFVTICAgIDB4MDAwMCAgQ09NTUFORCAweDAwMDAN CiAgQ0xBU1MgICAgIDB4MDYgMHgwMCAweDAwICBSRVZJU0lPTiAweDAwDQogIEJJU1QgICAg ICAweDAwICBIRUFERVIgMHg4MCAgTEFURU5DWSAweDAwICBDQUNIRSAweDAwDQpzaXplID0g MHgwDQpzaXplID0gMHgwDQpzaXplID0gMHgwDQpzaXplID0gMHgwDQpzaXplID0gMHgwDQpz aXplID0gMHgwDQogIE1BWF9MQVQgICAweDAwICBNSU5fR05UIDB4MDAgIElOVF9QSU4gMHgw MCAgSU5UX0xJTkUgMHhmZg0Kc2l6ZSA9IDB4MA0Kc2l6ZSA9IDB4MA0Kc2l6ZSA9IDB4MA0K c2l6ZSA9IDB4MA0Kc2l6ZSA9IDB4MA0Kc2l6ZSA9IDB4MA0Kc2l6ZSA9IDB4MA0Kc2l6ZSA9 IDB4MA0Kc2l6ZSA9IDB4MA0Kc2l6ZSA9IDB4MA0Kc2l6ZSA9IDB4MA0Kc2l6ZSA9IDB4MA0K DQpwY2kgYnVzIDB4MDAwMCBjYXJkbnVtIDB4MTkgZnVuY3Rpb24gMHgwMDogdmVuZG9yIDB4 MTBiOSBkZXZpY2UgMHg1MjQ5DQogQUxpIENvcnBvcmF0aW9uIE01MjQ5IEhUVCB0byBQQ0kg QnJpZGdlDQogQ2FyZFZlbmRvciAweDAwMDAgY2FyZCAweDAwMDAgKENhcmQgdW5rbm93bikN CiAgU1RBVFVTICAgIDB4NjAxMCAgQ09NTUFORCAweDAxMDcNCiAgQ0xBU1MgICAgIDB4MDYg MHgwNCAweDAwICBSRVZJU0lPTiAweDAwDQogIEJJU1QgICAgICAweDAwICBIRUFERVIgMHgw MSAgTEFURU5DWSAweDAwICBDQUNIRSAweDAwDQpzaXplID0gMHgwDQpzaXplID0gMHgwDQog IE1BWF9MQVQgICAweDAwICBNSU5fR05UIDB4MDcgIElOVF9QSU4gMHgwMCAgSU5UX0xJTkUg MHhmZg0Kc2l6ZSA9IDB4MA0Kc2l6ZSA9IDB4MA0KICBCdXM6IHByaW1hcnk9MDAsIHNlY29u ZGFyeT0wNCwgc3Vib3JkaW5hdGU9MDQsIHNlYy1sYXRlbmN5PTY0DQogIEkvTyBiZWhpbmQg YnJpZGdlOiAwMDAwZDAwMC0wMDAwZGZmZg0KICBNZW1vcnkgYmVoaW5kIGJyaWRnZTogZmVh MDAwMDAtZmVhMGZmZmYNCiAgUHJlZmV0Y2hhYmxlIG1lbW9yeSBiZWhpbmQgYnJpZGdlOiBm ZmYwMDAwMC0wMDAwZmZmZg0KDQpwY2kgYnVzIDB4MDAwMCBjYXJkbnVtIDB4MWMgZnVuY3Rp b24gMHgwMDogdmVuZG9yIDB4MTBiOSBkZXZpY2UgMHg1MjM3DQogQUxpIENvcnBvcmF0aW9u IFVTQiAxLjEgQ29udHJvbGxlcg0KIENhcmRWZW5kb3IgMHgxMDQzIGNhcmQgMHg4MTU2IChB U1VTVGVLIENvbXB1dGVyIEluYy4sIENhcmQgdW5rbm93bikNCiAgU1RBVFVTICAgIDB4ODJh OCAgQ09NTUFORCAweDAxMTcNCiAgQ0xBU1MgICAgIDB4MGMgMHgwMyAweDEwICBSRVZJU0lP TiAweDAzDQogIEJJU1QgICAgICAweDAwICBIRUFERVIgMHg4MCAgTEFURU5DWSAweDQwICBD QUNIRSAweDEwDQpzaXplID0gMHgxMDAwDQpzaXplID0gMHgwDQpzaXplID0gMHgwDQpzaXpl ID0gMHgwDQpzaXplID0gMHgwDQpzaXplID0gMHgwDQogIEJBU0UwICAgICAweGZlYmZjMDAw IFNJWkUgNDA5NiAgTUVNDQogIE1BWF9MQVQgICAweDUwICBNSU5fR05UIDB4MDAgIElOVF9Q SU4gMHgwMSAgSU5UX0xJTkUgMHgxMQ0KDQpwY2kgYnVzIDB4MDAwMCBjYXJkbnVtIDB4MWMg ZnVuY3Rpb24gMHgwMTogdmVuZG9yIDB4MTBiOSBkZXZpY2UgMHg1MjM3DQogQUxpIENvcnBv cmF0aW9uIFVTQiAxLjEgQ29udHJvbGxlcg0KIENhcmRWZW5kb3IgMHgxMDQzIGNhcmQgMHg4 MTU2IChBU1VTVGVLIENvbXB1dGVyIEluYy4sIENhcmQgdW5rbm93bikNCiAgU1RBVFVTICAg IDB4ODJhOCAgQ09NTUFORCAweDAxMTcNCiAgQ0xBU1MgICAgIDB4MGMgMHgwMyAweDEwICBS RVZJU0lPTiAweDAzDQogIEJJU1QgICAgICAweDAwICBIRUFERVIgMHg4MCAgTEFURU5DWSAw eDQwICBDQUNIRSAweDEwDQpzaXplID0gMHgxMDAwDQpzaXplID0gMHgwDQpzaXplID0gMHgw DQpzaXplID0gMHgwDQpzaXplID0gMHgwDQpzaXplID0gMHgwDQogIEJBU0UwICAgICAweGZl YmZkMDAwIFNJWkUgNDA5NiAgTUVNDQogIE1BWF9MQVQgICAweDUwICBNSU5fR05UIDB4MDAg IElOVF9QSU4gMHgwMiAgSU5UX0xJTkUgMHgxMg0KDQpwY2kgYnVzIDB4MDAwMCBjYXJkbnVt IDB4MWMgZnVuY3Rpb24gMHgwMjogdmVuZG9yIDB4MTBiOSBkZXZpY2UgMHg1MjM3DQogQUxp IENvcnBvcmF0aW9uIFVTQiAxLjEgQ29udHJvbGxlcg0KIENhcmRWZW5kb3IgMHgxMDQzIGNh cmQgMHg4MTU2IChBU1VTVGVLIENvbXB1dGVyIEluYy4sIENhcmQgdW5rbm93bikNCiAgU1RB VFVTICAgIDB4ODJhOCAgQ09NTUFORCAweDAxMTcNCiAgQ0xBU1MgICAgIDB4MGMgMHgwMyAw eDEwICBSRVZJU0lPTiAweDAzDQogIEJJU1QgICAgICAweDAwICBIRUFERVIgMHg4MCAgTEFU RU5DWSAweDQwICBDQUNIRSAweDEwDQpzaXplID0gMHgxMDAwDQpzaXplID0gMHgwDQpzaXpl ID0gMHgwDQpzaXplID0gMHgwDQpzaXplID0gMHgwDQpzaXplID0gMHgwDQogIEJBU0UwICAg ICAweGZlYmZlMDAwIFNJWkUgNDA5NiAgTUVNDQogIE1BWF9MQVQgICAweDUwICBNSU5fR05U IDB4MDAgIElOVF9QSU4gMHgwMyAgSU5UX0xJTkUgMHgxMw0KDQpwY2kgYnVzIDB4MDAwMCBj YXJkbnVtIDB4MWMgZnVuY3Rpb24gMHgwMzogdmVuZG9yIDB4MTBiOSBkZXZpY2UgMHg1MjM5 DQogQUxpIENvcnBvcmF0aW9uIFVTQiAyLjAgQ29udHJvbGxlcg0KIENhcmRWZW5kb3IgMHgx MDQzIGNhcmQgMHg4MTU2IChBU1VTVGVLIENvbXB1dGVyIEluYy4sIENhcmQgdW5rbm93bikN CiAgU1RBVFVTICAgIDB4ODJiMCAgQ09NTUFORCAweDAxMTYNCiAgQ0xBU1MgICAgIDB4MGMg MHgwMyAweDIwICBSRVZJU0lPTiAweDAxDQogIEJJU1QgICAgICAweDAwICBIRUFERVIgMHg4 MCAgTEFURU5DWSAweDQwICBDQUNIRSAweDEwDQpzaXplID0gMHgxMDANCnNpemUgPSAweDAN CnNpemUgPSAweDANCnNpemUgPSAweDANCnNpemUgPSAweDANCnNpemUgPSAweDANCiAgQkFT RTAgICAgIDB4ZmViZmZjMDAgU0laRSAyNTYgIE1FTQ0KICBNQVhfTEFUICAgMHgyMCAgTUlO X0dOVCAweDEwICBJTlRfUElOIDB4MDQgIElOVF9MSU5FIDB4MTcNCg0KcGNpIGJ1cyAweDAw MDAgY2FyZG51bSAweDFkIGZ1bmN0aW9uIDB4MDA6IHZlbmRvciAweDEwYjkgZGV2aWNlIDB4 NTQ2MQ0KIEFMaSBDb3Jwb3JhdGlvbiBIaWdoIERlZmluaXRpb24gQXVkaW8vQUMnOTcgSG9z dCBDb250cm9sbGVyDQogQ2FyZFZlbmRvciAweDEwNDMgY2FyZCAweDgxYjQgKEFTVVNUZUsg Q29tcHV0ZXIgSW5jLiwgQ2FyZCB1bmtub3duKQ0KICBTVEFUVVMgICAgMHgwMjEwICBDT01N QU5EIDB4MDEwNg0KICBDTEFTUyAgICAgMHgwNCAweDAzIDB4MDAgIFJFVklTSU9OIDB4MDAN CiAgQklTVCAgICAgIDB4MDAgIEhFQURFUiAweDAwICBMQVRFTkNZIDB4NDAgIENBQ0hFIDB4 MDANCnNpemUgPSAweDQwMDANCnNpemUgPSAweDANCnNpemUgPSAweDANCnNpemUgPSAweDAN CnNpemUgPSAweDANCiAgQkFTRTAgICAgIDB4ZmViZjgwMDAgU0laRSAxNjM4NCAgTUVNDQog IE1BWF9MQVQgICAweDUwICBNSU5fR05UIDB4MTAgIElOVF9QSU4gMHgwMyAgSU5UX0xJTkUg MHgxNg0KDQpwY2kgYnVzIDB4MDAwMCBjYXJkbnVtIDB4MWUgZnVuY3Rpb24gMHgwMDogdmVu ZG9yIDB4MTBiOSBkZXZpY2UgMHgxNTczDQogQUxpIENvcnBvcmF0aW9uIFBDSSB0byBMUEMg Q29udHJvbGxlcg0KIENhcmRWZW5kb3IgMHgxMDQzIGNhcmQgMHg4MTU2IChBU1VTVGVLIENv bXB1dGVyIEluYy4sIENhcmQgdW5rbm93bikNCiAgU1RBVFVTICAgIDB4MDIwMCAgQ09NTUFO RCAweDAwMGYNCiAgQ0xBU1MgICAgIDB4MDYgMHgwMSAweDAwICBSRVZJU0lPTiAweDMxDQog IEJJU1QgICAgICAweDAwICBIRUFERVIgMHg4MCAgTEFURU5DWSAweDAwICBDQUNIRSAweDAw DQpzaXplID0gMHgwDQpzaXplID0gMHgwDQpzaXplID0gMHgwDQpzaXplID0gMHgwDQpzaXpl ID0gMHgwDQpzaXplID0gMHgwDQogIE1BWF9MQVQgICAweDE4ICBNSU5fR05UIDB4MDEgIElO VF9QSU4gMHgwMCAgSU5UX0xJTkUgMHhmZg0Kc2l6ZSA9IDB4MA0Kc2l6ZSA9IDB4MA0Kc2l6 ZSA9IDB4MA0Kc2l6ZSA9IDB4MA0Kc2l6ZSA9IDB4MA0Kc2l6ZSA9IDB4MA0Kc2l6ZSA9IDB4 MA0Kc2l6ZSA9IDB4MA0Kc2l6ZSA9IDB4MA0Kc2l6ZSA9IDB4MA0Kc2l6ZSA9IDB4MA0Kc2l6 ZSA9IDB4MA0KDQpwY2kgYnVzIDB4MDAwMCBjYXJkbnVtIDB4MWUgZnVuY3Rpb24gMHgwMTog dmVuZG9yIDB4MTBiOSBkZXZpY2UgMHg3MTAxDQogQUxpIENvcnBvcmF0aW9uIE03MTAxIFBv d2VyIE1hbmFnZW1lbnQgQ29udHJvbGxlciBbUE1VXQ0KIENhcmRWZW5kb3IgMHgxMDQzIGNh cmQgMHg4MTU2IChBU1VTVGVLIENvbXB1dGVyIEluYy4sIENhcmQgdW5rbm93bikNCiAgU1RB VFVTICAgIDB4MDIwMCAgQ09NTUFORCAweDAwMDANCiAgQ0xBU1MgICAgIDB4MDYgMHg4MCAw eDAwICBSRVZJU0lPTiAweDAwDQogIEJJU1QgICAgICAweDAwICBIRUFERVIgMHg4MCAgTEFU RU5DWSAweDAwICBDQUNIRSAweDAwDQpzaXplID0gMHgwDQpzaXplID0gMHgwDQpzaXplID0g MHgwDQpzaXplID0gMHgwDQpzaXplID0gMHgwDQpzaXplID0gMHgwDQogIE1BWF9MQVQgICAw eDAwICBNSU5fR05UIDB4MDAgIElOVF9QSU4gMHgwMCAgSU5UX0xJTkUgMHhmZg0Kc2l6ZSA9 IDB4MA0Kc2l6ZSA9IDB4MA0Kc2l6ZSA9IDB4MA0Kc2l6ZSA9IDB4MA0Kc2l6ZSA9IDB4MA0K c2l6ZSA9IDB4MA0Kc2l6ZSA9IDB4MA0Kc2l6ZSA9IDB4MA0Kc2l6ZSA9IDB4MA0Kc2l6ZSA9 IDB4MA0Kc2l6ZSA9IDB4MA0Kc2l6ZSA9IDB4MA0KDQpwY2kgYnVzIDB4MDAwMCBjYXJkbnVt IDB4MWYgZnVuY3Rpb24gMHgwMDogdmVuZG9yIDB4MTBiOSBkZXZpY2UgMHg1MjI5DQogQUxp IENvcnBvcmF0aW9uIE01MjI5IElERQ0KIENhcmRWZW5kb3IgMHgxMDQzIGNhcmQgMHg4MTU2 IChBU1VTVGVLIENvbXB1dGVyIEluYy4sIENhcmQgdW5rbm93bikNCiAgU1RBVFVTICAgIDB4 MDJiMCAgQ09NTUFORCAweDAwMDUNCiAgQ0xBU1MgICAgIDB4MDEgMHgwMSAweDhhICBSRVZJ U0lPTiAweGM3DQogIEJJU1QgICAgICAweDAwICBIRUFERVIgMHg4MCAgTEFURU5DWSAweDIw ICBDQUNIRSAweDAwDQpzaXplID0gMHgwDQpzaXplID0gMHgwDQpzaXplID0gMHgwDQpzaXpl ID0gMHgwDQpzaXplID0gMHgxMA0Kc2l6ZSA9IDB4MA0KICBCQVNFNCAgICAgMHgwMDAwZmYw MCBTSVpFIDE2ICBJL08NCiAgTUFYX0xBVCAgIDB4MDAgIE1JTl9HTlQgMHgwMCAgSU5UX1BJ TiAweDAxICBJTlRfTElORSAweGZmDQoNCnBjaSBidXMgMHgwMDAwIGNhcmRudW0gMHgxZiBm dW5jdGlvbiAweDAxOiB2ZW5kb3IgMHgxMGI5IGRldmljZSAweDUyODcNCiBBTGkgQ29ycG9y YXRpb24gVUxpIDUyODcgU0FUQQ0KIENhcmRWZW5kb3IgMHgxMDQzIGNhcmQgMHg4MTU2IChB U1VTVGVLIENvbXB1dGVyIEluYy4sIENhcmQgdW5rbm93bikNCiAgU1RBVFVTICAgIDB4MDJi MCAgQ09NTUFORCAweDAxMDcNCiAgQ0xBU1MgICAgIDB4MDEgMHgwNCAweDAwICBSRVZJU0lP TiAweDAyDQogIEJJU1QgICAgICAweDAwICBIRUFERVIgMHg4MCAgTEFURU5DWSAweDgwICBD QUNIRSAweDgwDQpzaXplID0gMHgxMA0Kc2l6ZSA9IDB4OA0Kc2l6ZSA9IDB4MTANCnNpemUg PSAweDgNCnNpemUgPSAweDIwDQpzaXplID0gMHg0MDANCiAgQkFTRTAgICAgIDB4MDAwMGVj MDAgU0laRSAxNiAgSS9PDQogIEJBU0UxICAgICAweDAwMDBlODgwIFNJWkUgOCAgSS9PDQog IEJBU0UyICAgICAweDAwMDBlODAwIFNJWkUgMTYgIEkvTw0KICBCQVNFMyAgICAgMHgwMDAw ZTQ4MCBTSVpFIDggIEkvTw0KICBCQVNFNCAgICAgMHgwMDAwZTQwMCBTSVpFIDMyICBJL08N CiAgQkFTRTUgICAgIDB4ZmViZmY4MDAgU0laRSAxMDI0ICBNRU0NCiAgTUFYX0xBVCAgIDB4 MDAgIE1JTl9HTlQgMHgwMCAgSU5UX1BJTiAweDAxICBJTlRfTElORSAweDE1DQoNCnBjaSBi dXMgMHgwMDAxIGNhcmRudW0gMHgwMCBmdW5jdGlvbiAweDAwOiB2ZW5kb3IgMHgxMDAyIGRl dmljZSAweDViNjMNCiBBVEkgVGVjaG5vbG9naWVzIEluYyBSVjM3MCBbU2FwcGhpcmUgWDU1 MCBTaWxlbnRdDQogQ2FyZFZlbmRvciAweDE3NGIgY2FyZCAweDMwMDAgKFBDIFBhcnRuZXIg TGltaXRlZCwgQ2FyZCB1bmtub3duKQ0KICBTVEFUVVMgICAgMHgwMDEwICBDT01NQU5EIDB4 MDEwNw0KICBDTEFTUyAgICAgMHgwMyAweDAwIDB4MDAgIFJFVklTSU9OIDB4MDANCiAgQklT VCAgICAgIDB4MDAgIEhFQURFUiAweDgwICBMQVRFTkNZIDB4MDAgIENBQ0hFIDB4MTANCnNp emUgPSAweDgwMDAwMDANCnNpemUgPSAweDEwMA0Kc2l6ZSA9IDB4MTAwMDANCnNpemUgPSAw eDANCnNpemUgPSAweDANCnNpemUgPSAweDANCiAgQkFTRTAgICAgIDB4ZDAwMDAwMDAgU0la RSAxMzQyMTc3MjggIE1FTSBQUkVGRVRDSEFCTEUNCiAgQkFTRTEgICAgIDB4MDAwMGI4MDAg U0laRSAyNTYgIEkvTw0KICBCQVNFMiAgICAgMHhmZTQwMDAwMCBTSVpFIDY1NTM2ICBNRU0N CiAgQkFTRVJPTSAgIDB4MDAwMDAwMDAgIGFkZHIgMHgwMDAwMDAwMA0KICBNQVhfTEFUICAg MHgwMCAgTUlOX0dOVCAweDAwICBJTlRfUElOIDB4MDEgIElOVF9MSU5FIDB4MTINCg0KcGNp IGJ1cyAweDAwMDEgY2FyZG51bSAweDAwIGZ1bmN0aW9uIDB4MDE6IHZlbmRvciAweDEwMDIg ZGV2aWNlIDB4NWI3Mw0KIEFUSSBUZWNobm9sb2dpZXMgSW5jIFJWMzcwIHNlY29uZGFyeSBb U2FwcGhpcmUgWDU1MCBTaWxlbnRdDQogQ2FyZFZlbmRvciAweDE3NGIgY2FyZCAweDMwMDEg KFBDIFBhcnRuZXIgTGltaXRlZCwgQ2FyZCB1bmtub3duKQ0KICBTVEFUVVMgICAgMHgwMDEw ICBDT01NQU5EIDB4MDAwNw0KICBDTEFTUyAgICAgMHgwMyAweDgwIDB4MDAgIFJFVklTSU9O IDB4MDANCiAgQklTVCAgICAgIDB4MDAgIEhFQURFUiAweDAwICBMQVRFTkNZIDB4MDAgIENB Q0hFIDB4MTANCnNpemUgPSAweDEwMDAwDQpzaXplID0gMHgwDQpzaXplID0gMHgwDQpzaXpl ID0gMHgwDQpzaXplID0gMHgwDQpzaXplID0gMHgwDQogIEJBU0UwICAgICAweGZlOGQwMDAw IFNJWkUgNjU1MzYgIE1FTQ0KICBNQVhfTEFUICAgMHgwMCAgTUlOX0dOVCAweDAwICBJTlRf UElOIDB4MDAgIElOVF9MSU5FIDB4ZmYNCg0KcGNpIGJ1cyAweDAwMDIgY2FyZG51bSAweDAw IGZ1bmN0aW9uIDB4MDA6IHZlbmRvciAweDExYWIgZGV2aWNlIDB4NDM2Mg0KIE1hcnZlbGwg VGVjaG5vbG9neSBHcm91cCBMdGQuIDg4RTgwNTMgUENJLUUgR2lnYWJpdCBFdGhlcm5ldCBD b250cm9sbGVyDQogQ2FyZFZlbmRvciAweDEwNDMgY2FyZCAweDgxNDIgKEFTVVNUZUsgQ29t cHV0ZXIgSW5jLiwgTWFydmVsbCA4OEU4MDUzIEdpZ2FiaXQgRXRoZXJuZXQgY29udHJvbGxl ciBQQ0llIChBc3VzKSkNCiAgU1RBVFVTICAgIDB4MDAxMCAgQ09NTUFORCAweDAxMDcNCiAg Q0xBU1MgICAgIDB4MDIgMHgwMCAweDAwICBSRVZJU0lPTiAweDE5DQogIEJJU1QgICAgICAw eDAwICBIRUFERVIgMHgwMCAgTEFURU5DWSAweDAwICBDQUNIRSAweDEwDQpzaXplID0gMHg0 MDAwDQpzaXplID0gMHgxMDANCnNpemUgPSAweDANCnNpemUgPSAweDANCnNpemUgPSAweDAN CiAgQkFTRTAgICAgIDB4ZmU5ZmMwMDAgU0laRSAxNjM4NCAgTUVNDQogIEJBU0UyICAgICAw eDAwMDBjODAwIFNJWkUgMjU2ICBJL08NCiAgTUFYX0xBVCAgIDB4MDAgIE1JTl9HTlQgMHgw MCAgSU5UX1BJTiAweDAxICBJTlRfTElORSAweDEyDQoNCnBjaSBidXMgMHgwMDA0IGNhcmRu dW0gMHgxMiBmdW5jdGlvbiAweDAwOiB2ZW5kb3IgMHgxMTA2IGRldmljZSAweDMwNDQNCiBW SUEgVGVjaG5vbG9naWVzLCBJbmMuIFZUNjMwNiBGaXJlIElJIElFRUUgMTM5NCBPSENJIExp bmsgTGF5ZXIgQ29udHJvbGxlcg0KIENhcmRWZW5kb3IgMHgxMDQzIGNhcmQgMHg4MDhhIChB U1VTVGVLIENvbXB1dGVyIEluYy4sIEE4Vi9BOE4vUDRQODAwIHNlcmllcyBtb3RoZXJib2Fy ZCkNCiAgU1RBVFVTICAgIDB4MDIxMCAgQ09NTUFORCAweDAxMTcNCiAgQ0xBU1MgICAgIDB4 MGMgMHgwMCAweDEwICBSRVZJU0lPTiAweDgwDQogIEJJU1QgICAgICAweDAwICBIRUFERVIg MHgwMCAgTEFURU5DWSAweDQwICBDQUNIRSAweDEwDQpzaXplID0gMHg4MDANCnNpemUgPSAw eDgwDQpzaXplID0gMHgwDQpzaXplID0gMHgwDQpzaXplID0gMHgwDQpzaXplID0gMHgwDQog IEJBU0UwICAgICAweGZlYWZlODAwIFNJWkUgMjA0OCAgTUVNDQogIEJBU0UxICAgICAweDAw MDBkYzAwIFNJWkUgMTI4ICBJL08NCiAgTUFYX0xBVCAgIDB4MjAgIE1JTl9HTlQgMHgwMCAg SU5UX1BJTiAweDAxICBJTlRfTElORSAweDEwDQphbmdsZXBvaXNlIyBsc2MIG1tLCBtbSwgb W0twY2ljb25mIC1sdg0NCmhvc3RiMEBwY2kwOjA6MDowOgljbGFzcz0weDA2MDAwMCBjYXJk PTB4ODE4NTEwNDMgY2hpcD0weDU5NTAxMDAyIHJldj0weDEwIGhkcj0weDAwDQogICAgdmVu ZG9yICAgICA9ICdBVEkgVGVjaG5vbG9naWVzIEluYycNCiAgICBkZXZpY2UgICAgID0gJ1JT NDgwIEhvc3QgQnJpZGdlJw0KICAgIGNsYXNzICAgICAgPSBicmlkZ2UNCiAgICBzdWJjbGFz cyAgID0gSE9TVC1QQ0kNCnBjaWIxQHBjaTA6MDoyOjA6CWNsYXNzPTB4MDYwNDAwIGNhcmQ9 MHg1OTUwMTAwMiBjaGlwPTB4NWEzNDEwMDIgcmV2PTB4MDAgaGRyPTB4MDENCiAgICB2ZW5k b3IgICAgID0gJ0FUSSBUZWNobm9sb2dpZXMgSW5jJw0KICAgIGRldmljZSAgICAgPSAnUlM0 ODAgUENJLVggUm9vdCBQb3J0Jw0KICAgIGNsYXNzICAgICAgPSBicmlkZ2UNCiAgICBzdWJj bGFzcyAgID0gUENJLVBDSQ0KcGNpYjJAcGNpMDowOjY6MDoJY2xhc3M9MHgwNjA0MDAgY2Fy ZD0weDU5NTAxMDAyIGNoaXA9MHg1YTM4MTAwMiByZXY9MHgwMCBoZHI9MHgwMQ0KICAgIHZl bmRvciAgICAgPSAnQVRJIFRlY2hub2xvZ2llcyBJbmMnDQogICAgZGV2aWNlICAgICA9ICdS UzQ4MCBQQ0kgQnJpZGdlJw0KICAgIGNsYXNzICAgICAgPSBicmlkZ2UNCiAgICBzdWJjbGFz cyAgID0gUENJLVBDSQ0KcGNpYjNAcGNpMDowOjc6MDoJY2xhc3M9MHgwNjA0MDAgY2FyZD0w eDU5NTAxMDAyIGNoaXA9MHg1YTM5MTAwMiByZXY9MHgwMCBoZHI9MHgwMQ0KICAgIHZlbmRv ciAgICAgPSAnQVRJIFRlY2hub2xvZ2llcyBJbmMnDQogICAgZGV2aWNlICAgICA9ICdSUzQ4 MCBQQ0kgQnJpZGdlJw0KICAgIGNsYXNzICAgICAgPSBicmlkZ2UNCiAgICBzdWJjbGFzcyAg ID0gUENJLVBDSQ0KaG9zdGIxQHBjaTA6MDoyNDowOgljbGFzcz0weDA2MDAwMCBjYXJkPTB4 MDAwMDAwMDAgY2hpcD0weDExMDAxMDIyIHJldj0weDAwIGhkcj0weDAwDQogICAgdmVuZG9y ICAgICA9ICdBZHZhbmNlZCBNaWNybyBEZXZpY2VzIChBTUQpJw0KICAgIGRldmljZSAgICAg PSAnKEs4KSBBdGhsb24gNjQvT3B0ZXJvbiBIeXBlclRyYW5zcG9ydCBUZWNobm9sb2d5IENv bmZpZ3VyYXRpb24nDQogICAgY2xhc3MgICAgICA9IGJyaWRnZQ0KICAgIHN1YmNsYXNzICAg PSBIT1NULVBDSQ0KaG9zdGIyQHBjaTA6MDoyNDoxOgljbGFzcz0weDA2MDAwMCBjYXJkPTB4 MDAwMDAwMDAgY2hpcD0weDExMDExMDIyIHJldj0weDAwIGhkcj0weDAwDQogICAgdmVuZG9y ICAgICA9ICdBZHZhbmNlZCBNaWNybyBEZXZpY2VzIChBTUQpJw0KICAgIGRldmljZSAgICAg PSAnKEs4KSBBdGhsb24gNjQvT3B0ZXJvbiBBZGRyZXNzIE1hcCcNCiAgICBjbGFzcyAgICAg ID0gYnJpZGdlDQogICAgc3ViY2xhc3MgICA9IEhPU1QtUENJDQpob3N0YjNAcGNpMDowOjI0 OjI6CWNsYXNzPTB4MDYwMDAwIGNhcmQ9MHgwMDAwMDAwMCBjaGlwPTB4MTEwMjEwMjIgcmV2 PTB4MDAgaGRyPTB4MDANCiAgICB2ZW5kb3IgICAgID0gJ0FkdmFuY2VkIE1pY3JvIERldmlj ZXMgKEFNRCknDQogICAgZGV2aWNlICAgICA9ICcoSzgpIEF0aGxvbiA2NC9PcHRlcm9uIERS QU0gQ29udHJvbGxlcicNCiAgICBjbGFzcyAgICAgID0gYnJpZGdlDQogICAgc3ViY2xhc3Mg ICA9IEhPU1QtUENJDQpob3N0YjRAcGNpMDowOjI0OjM6CWNsYXNzPTB4MDYwMDAwIGNhcmQ9 MHgwMDAwMDAwMCBjaGlwPTB4MTEwMzEwMjIgcmV2PTB4MDAgaGRyPTB4MDANCiAgICB2ZW5k b3IgICAgID0gJ0FkdmFuY2VkIE1pY3JvIERldmljZXMgKEFNRCknDQogICAgZGV2aWNlICAg ICA9ICcoSzgpIEF0aGxvbiA2NC9PcHRlcm9uIE1pc2NlbGxhbmVvdXMgQ29udHJvbCcNCiAg ICBjbGFzcyAgICAgID0gYnJpZGdlDQogICAgc3ViY2xhc3MgICA9IEhPU1QtUENJDQpwY2li NEBwY2kwOjA6MjU6MDoJY2xhc3M9MHgwNjA0MDAgY2FyZD0weDAwMDAwMDAwIGNoaXA9MHg1 MjQ5MTBiOSByZXY9MHgwMCBoZHI9MHgwMQ0KICAgIHZlbmRvciAgICAgPSAnQWNlciBMYWJz IEluY29ycG9yYXRlZCAoQUxpL1VMaSknDQogICAgZGV2aWNlICAgICA9ICdNNTI0OSBIeXBl clRyYW5zcG9ydCB0byBQQ0kgQnJpZGdlJw0KICAgIGNsYXNzICAgICAgPSBicmlkZ2UNCiAg ICBzdWJjbGFzcyAgID0gUENJLVBDSQ0Kb2hjaTBAcGNpMDowOjI4OjA6CWNsYXNzPTB4MGMw MzEwIGNhcmQ9MHg4MTU2MTA0MyBjaGlwPTB4NTIzNzEwYjkgcmV2PTB4MDMgaGRyPTB4MDAN CiAgICB2ZW5kb3IgICAgID0gJ0FjZXIgTGFicyBJbmNvcnBvcmF0ZWQgKEFMaS9VTGkpJw0K ICAgIGRldmljZSAgICAgPSAnTTUyNzMgQTEgZm9yIHdpbmRvd3Mgd2luIDk4IE9wZW5IQ0kg MS4xIFVTQiB0byAgMi4wJw0KICAgIGNsYXNzICAgICAgPSBzZXJpYWwgYnVzDQogICAgc3Vi Y2xhc3MgICA9IFVTQg0Kb2hjaTFAcGNpMDowOjI4OjE6CWNsYXNzPTB4MGMwMzEwIGNhcmQ9 MHg4MTU2MTA0MyBjaGlwPTB4NTIzNzEwYjkgcmV2PTB4MDMgaGRyPTB4MDANCiAgICB2ZW5k b3IgICAgID0gJ0FjZXIgTGFicyBJbmNvcnBvcmF0ZWQgKEFMaS9VTGkpJw0KICAgIGRldmlj ZSAgICAgPSAnTTUyNzMgQTEgZm9yIHdpbmRvd3Mgd2luIDk4IE9wZW5IQ0kgMS4xIFVTQiB0 byAgMi4wJw0KICAgIGNsYXNzICAgICAgPSBzZXJpYWwgYnVzDQogICAgc3ViY2xhc3MgICA9 IFVTQg0Kb2hjaTJAcGNpMDowOjI4OjI6CWNsYXNzPTB4MGMwMzEwIGNhcmQ9MHg4MTU2MTA0 MyBjaGlwPTB4NTIzNzEwYjkgcmV2PTB4MDMgaGRyPTB4MDANCiAgICB2ZW5kb3IgICAgID0g J0FjZXIgTGFicyBJbmNvcnBvcmF0ZWQgKEFMaS9VTGkpJw0KICAgIGRldmljZSAgICAgPSAn TTUyNzMgQTEgZm9yIHdpbmRvd3Mgd2luIDk4IE9wZW5IQ0kgMS4xIFVTQiB0byAgMi4wJw0K ICAgIGNsYXNzICAgICAgPSBzZXJpYWwgYnVzDQogICAgc3ViY2xhc3MgICA9IFVTQg0KZWhj aTBAcGNpMDowOjI4OjM6CWNsYXNzPTB4MGMwMzIwIGNhcmQ9MHg4MTU2MTA0MyBjaGlwPTB4 NTIzOTEwYjkgcmV2PTB4MDEgaGRyPTB4MDANCiAgICB2ZW5kb3IgICAgID0gJ0FjZXIgTGFi cyBJbmNvcnBvcmF0ZWQgKEFMaS9VTGkpJw0KICAgIGRldmljZSAgICAgPSAnVVNCIDIuMCBF bmhhbmNlZCBIb3N0IENvbnRyb2xsZXInDQogICAgY2xhc3MgICAgICA9IHNlcmlhbCBidXMN CiAgICBzdWJjbGFzcyAgID0gVVNCDQpoZGFjMEBwY2kwOjA6Mjk6MDoJY2xhc3M9MHgwNDAz MDAgY2FyZD0weDgxYjQxMDQzIGNoaXA9MHg1NDYxMTBiOSByZXY9MHgwMCBoZHI9MHgwMA0K ICAgIHZlbmRvciAgICAgPSAnQWNlciBMYWJzIEluY29ycG9yYXRlZCAoQUxpL1VMaSknDQog ICAgZGV2aWNlICAgICA9ICc/PyBNaWNyb3NvZnQgVUFBIEJ1cyBEcml2ZXIgZm9yIEhpZ2gg RGVmaW5pdGlvbiBBdWRpbycNCiAgICBjbGFzcyAgICAgID0gbXVsdGltZWRpYQ0KICAgIHN1 YmNsYXNzICAgPSBIREENCmlzYWIwQHBjaTA6MDozMDowOgljbGFzcz0weDA2MDEwMCBjYXJk PTB4ODE1NjEwNDMgY2hpcD0weDE1NzMxMGI5IHJldj0weDMxIGhkcj0weDAwDQogICAgdmVu ZG9yICAgICA9ICdBY2VyIExhYnMgSW5jb3Jwb3JhdGVkIChBTGkvVUxpKScNCiAgICBkZXZp Y2UgICAgID0gJ0FMSSBNMTU3MyBTb3V0aCBCcmlkZ2Ugd2l0aCBIeXBlcnRyYW5zcG9ydCBT dXBwb3J0Jw0KICAgIGNsYXNzICAgICAgPSBicmlkZ2UNCiAgICBzdWJjbGFzcyAgID0gUENJ LUlTQQ0Kbm9uZTBAcGNpMDowOjMwOjE6CWNsYXNzPTB4MDY4MDAwIGNhcmQ9MHg4MTU2MTA0 MyBjaGlwPTB4NzEwMTEwYjkgcmV2PTB4MDAgaGRyPTB4MDANCiAgICB2ZW5kb3IgICAgID0g J0FjZXIgTGFicyBJbmNvcnBvcmF0ZWQgKEFMaS9VTGkpJw0KICAgIGRldmljZSAgICAgPSAn QUxJIE03MTAxIFBvd2VyIE1hbmFnZW1lbnQgQ29udHJvbGxlcicNCiAgICBjbGFzcyAgICAg ID0gYnJpZGdlDQphdGFwY2kwQHBjaTA6MDozMTowOgljbGFzcz0weDAxMDE4YSBjYXJkPTB4 ODE1NjEwNDMgY2hpcD0weDUyMjkxMGI5IHJldj0weGM3IGhkcj0weDAwDQogICAgdmVuZG9y ICAgICA9ICdBY2VyIExhYnMgSW5jb3Jwb3JhdGVkIChBTGkvVUxpKScNCiAgICBkZXZpY2Ug ICAgID0gJ001MjI5IFNvdXRoYnJpZGdlIEVJREUgQ29udHJvbGxlcicNCiAgICBjbGFzcyAg ICAgID0gbWFzcyBzdG9yYWdlDQogICAgc3ViY2xhc3MgICA9IEFUQQ0KYXRhcGNpMUBwY2kw OjA6MzE6MToJY2xhc3M9MHgwMTA0MDAgY2FyZD0weDgxNTYxMDQzIGNoaXA9MHg1Mjg3MTBi OSByZXY9MHgwMiBoZHI9MHgwMA0KICAgIHZlbmRvciAgICAgPSAnQWNlciBMYWJzIEluY29y cG9yYXRlZCAoQUxpL1VMaSknDQogICAgZGV2aWNlICAgICA9ICc1Mjg3MTg0OSBBTEkgU0FU QSBjb250cm9sbGVyJw0KICAgIGNsYXNzICAgICAgPSBtYXNzIHN0b3JhZ2UNCiAgICBzdWJj bGFzcyAgID0gUkFJRA0KdmdhcGNpMEBwY2kwOjE6MDowOgljbGFzcz0weDAzMDAwMCBjYXJk PTB4MzAwMDE3NGIgY2hpcD0weDViNjMxMDAyIHJldj0weDAwIGhkcj0weDAwDQogICAgdmVu ZG9yICAgICA9ICdBVEkgVGVjaG5vbG9naWVzIEluYycNCiAgICBkZXZpY2UgICAgID0gJ1Jh ZGVvbiBYNTUwIFNlcmllcycNCiAgICBjbGFzcyAgICAgID0gZGlzcGxheQ0KICAgIHN1YmNs YXNzICAgPSBWR0ENCnZnYXBjaTFAcGNpMDoxOjA6MToJY2xhc3M9MHgwMzgwMDAgY2FyZD0w eDMwMDExNzRiIGNoaXA9MHg1YjczMTAwMiByZXY9MHgwMCBoZHI9MHgwMA0KICAgIHZlbmRv ciAgICAgPSAnQVRJIFRlY2hub2xvZ2llcyBJbmMnDQogICAgZGV2aWNlICAgICA9ICdSYWRl b24gWDU1MCBTZXJpZXMgLSBTZWNvbmRhcnknDQogICAgY2xhc3MgICAgICA9IGRpc3BsYXkN Cm1za2MwQHBjaTA6MjowOjA6CWNsYXNzPTB4MDIwMDAwIGNhcmQ9MHg4MTQyMTA0MyBjaGlw PTB4NDM2MjExYWIgcmV2PTB4MTkgaGRyPTB4MDANCiAgICB2ZW5kb3IgICAgID0gJ01hcnZl bGwgU2VtaWNvbmR1Y3RvciAoV2FzOiBHYWxpbGVvIFRlY2hub2xvZ3kgTHRkKScNCiAgICBk ZXZpY2UgICAgID0gJzg4RTgwNTMgTWFydmVsbCBZdWtvbiA4OEU4MDUzIFBDSS1FIEdpZ2Fi aXQgRXRoZXJuZXQgQ29udHJvbGxlcicNCiAgICBjbGFzcyAgICAgID0gbmV0d29yaw0KICAg IHN1YmNsYXNzICAgPSBldGhlcm5ldA0Kbm9uZTFAcGNpMDo0OjE4OjA6CWNsYXNzPTB4MGMw MDEwIGNhcmQ9MHg4MDhhMTA0MyBjaGlwPTB4MzA0NDExMDYgcmV2PTB4ODAgaGRyPTB4MDAN CiAgICB2ZW5kb3IgICAgID0gJ1ZJQSBUZWNobm9sb2dpZXMgSW5jJw0KICAgIGRldmljZSAg ICAgPSAnVlQ2MzA2IFZJQSBGaXJlIElJIElFRUUtMTM5NCBPSENJIExpbmsgTGF5ZXIgQ29u dHJvbGxlcicNCiAgICBjbGFzcyAgICAgID0gc2VyaWFsIGJ1cw0KICAgIHN1YmNsYXNzICAg PSBGaXJlV2lyZQ0KYW5nbGVwb2lzZSMgbHNwY2kgLXZ2DQ0KMDA6MDAuMCBIb3N0IGJyaWRn ZTogQVRJIFRlY2hub2xvZ2llcyBJbmMgUlM0ODAgSG9zdCBCcmlkZ2UgKHJldiAxMCkNCglT dWJzeXN0ZW06IEFTVVNUZUsgQ29tcHV0ZXIgSW5jLiBEZXZpY2UgODE4NQ0KCUNvbnRyb2w6 IEkvTy0gTWVtKyBCdXNNYXN0ZXIrIFNwZWNDeWNsZS0gTWVtV0lOVi0gVkdBU25vb3AtIFBh ckVyci0gU3RlcHBpbmctIFNFUlItIEZhc3RCMkItIERpc0lOVHgtDQoJU3RhdHVzOiBDYXAt IDY2TUh6KyBVREYtIEZhc3RCMkItIFBhckVyci0gREVWU0VMPW1lZGl1bSA+VEFib3J0LSA8 VEFib3J0LSA8TUFib3J0KyA+U0VSUi0gPFBFUlItIElOVHgtDQoJTGF0ZW5jeTogMA0KDQow MDowMi4wIFBDSSBicmlkZ2U6IEFUSSBUZWNobm9sb2dpZXMgSW5jIFJTNDgwIFBDSS1YIFJv b3QgUG9ydCAocHJvZy1pZiAwMCBbTm9ybWFsIGRlY29kZV0pDQoJQ29udHJvbDogSS9PKyBN ZW0rIEJ1c01hc3RlcisgU3BlY0N5Y2xlLSBNZW1XSU5WLSBWR0FTbm9vcC0gUGFyRXJyLSBT dGVwcGluZy0gU0VSUisgRmFzdEIyQi0gRGlzSU5UeC0NCglTdGF0dXM6IENhcCsgNjZNSHot IFVERi0gRmFzdEIyQi0gUGFyRXJyLSBERVZTRUw9ZmFzdCA+VEFib3J0LSA8VEFib3J0LSA8 TUFib3J0LSA+U0VSUi0gPFBFUlItIElOVHgtDQoJTGF0ZW5jeTogMCwgQ2FjaGUgTGluZSBT aXplOiA2NCBieXRlcw0KCUJ1czogcHJpbWFyeT0wMCwgc2Vjb25kYXJ5PTAxLCBzdWJvcmRp bmF0ZT0wMSwgc2VjLWxhdGVuY3k9MA0KCUkvTyBiZWhpbmQgYnJpZGdlOiAwMDAwYjAwMC0w MDAwYmZmZg0KCU1lbW9yeSBiZWhpbmQgYnJpZGdlOiBmZTAwMDAwMC1mZThmZmZmZg0KCVBy ZWZldGNoYWJsZSBtZW1vcnkgYmVoaW5kIGJyaWRnZTogMDAwMDAwMDBjZmYwMDAwMC0wMDAw MDAwMGRmZWZmZmZmDQoJU2Vjb25kYXJ5IHN0YXR1czogNjZNSHotIEZhc3RCMkItIFBhckVy ci0gREVWU0VMPWZhc3QgPlRBYm9ydC0gPFRBYm9ydC0gPE1BYm9ydCsgPFNFUlItIDxQRVJS LQ0KCUJyaWRnZUN0bDogUGFyaXR5KyBTRVJSKyBOb0lTQS0gVkdBKyBNQWJvcnQtID5SZXNl dC0gRmFzdEIyQi0NCgkJUHJpRGlzY1Rtci0gU2VjRGlzY1Rtci0gRGlzY1RtclN0YXQtIERp c2NUbXJTRVJSRW4tDQoJQ2FwYWJpbGl0aWVzOiBbNTBdIFBvd2VyIE1hbmFnZW1lbnQgdmVy c2lvbiAzDQoJCUZsYWdzOiBQTUVDbGstIERTSS0gRDEtIEQyLSBBdXhDdXJyZW50PTBtQSBQ TUUoRDArLEQxLSxEMi0sRDNob3QrLEQzY29sZCspDQoJCVN0YXR1czogRDAgUE1FLUVuYWJs ZS0gRFNlbD0wIERTY2FsZT0wIFBNRS0NCglDYXBhYmlsaXRpZXM6IFs1OF0gRXhwcmVzcyAo djEpIFJvb3QgUG9ydCAoU2xvdC0pLCBNU0kgMDANCgkJRGV2Q2FwOglNYXhQYXlsb2FkIDEy OCBieXRlcywgUGhhbnRGdW5jIDAsIExhdGVuY3kgTDBzIDw2NG5zLCBMMSA8MXVzDQoJCQlF eHRUYWcrIFJCRS0gRkxSZXNldC0NCgkJRGV2Q3RsOglSZXBvcnQgZXJyb3JzOiBDb3JyZWN0 YWJsZS0gTm9uLUZhdGFsLSBGYXRhbC0gVW5zdXBwb3J0ZWQtDQoJCQlSbHhkT3JkKyBFeHRU YWctIFBoYW50RnVuYy0gQXV4UHdyLSBOb1Nub29wKw0KCQkJTWF4UGF5bG9hZCAxMjggYnl0 ZXMsIE1heFJlYWRSZXEgMTI4IGJ5dGVzDQoJCURldlN0YToJQ29yckVyci0gVW5jb3JyRXJy LSBGYXRhbEVyci0gVW5zdXBwUmVxLSBBdXhQd3ItIFRyYW5zUGVuZC0NCgkJTG5rQ2FwOglQ b3J0ICMwLCBTcGVlZCAyLjVHVC9zLCBXaWR0aCB4MTYsIEFTUE0gTDBzIEwxLCBMYXRlbmN5 IEwwIDw2NG5zLCBMMSA8MXVzDQoJCQlDbG9ja1BNLSBTdXByaXNlLSBMTEFjdFJlcC0gQndO b3QtDQoJCUxua0N0bDoJQVNQTSBEaXNhYmxlZDsgUkNCIDY0IGJ5dGVzIERpc2FibGVkLSBS ZXRyYWluLSBDb21tQ2xrLQ0KCQkJRXh0U3luY2gtIENsb2NrUE0tIEF1dFdpZERpcy0gQldJ bnQtIEF1dEJXSW50LQ0KCQlMbmtTdGE6CVNwZWVkIDIuNUdUL3MsIFdpZHRoIHgxNiwgVHJF cnItIFRyYWluLSBTbG90Q2xrKyBETEFjdGl2ZS0gQldNZ210LSBBQldNZ210LQ0KCQlSb290 Q3RsOiBFcnJDb3JyZWN0YWJsZS0gRXJyTm9uLUZhdGFsLSBFcnJGYXRhbC0gUE1FSW50RW5h LSBDUlNWaXNpYmxlLQ0KCQlSb290Q2FwOiBDUlNWaXNpYmxlLQ0KCQlSb290U3RhOiBQTUUg UmVxSUQgMDAwMCwgUE1FU3RhdHVzLSBQTUVQZW5kaW5nLQ0KCUNhcGFiaWxpdGllczogWzgw XSBNU0k6IE1hc2stIDY0Yml0LSBDb3VudD0xLzEgRW5hYmxlLQ0KCQlBZGRyZXNzOiAwMDAw MDAwMCAgRGF0YTogMDAwMA0KCUNhcGFiaWxpdGllczogW2IwXSBTdWJzeXN0ZW06IEFUSSBU ZWNobm9sb2dpZXMgSW5jIERldmljZSA1OTUwDQoJQ2FwYWJpbGl0aWVzOiBbYjhdIEh5cGVy VHJhbnNwb3J0OiBNU0kgTWFwcGluZyBFbmFibGUrIEZpeGVkKw0KDQowMDowNi4wIFBDSSBi cmlkZ2U6IEFUSSBUZWNobm9sb2dpZXMgSW5jIFJTNDgwIFBDSSBCcmlkZ2UgKHByb2ctaWYg MDAgW05vcm1hbCBkZWNvZGVdKQ0KCUNvbnRyb2w6IEkvTysgTWVtKyBCdXNNYXN0ZXIrIFNw ZWNDeWNsZS0gTWVtV0lOVi0gVkdBU25vb3AtIFBhckVyci0gU3RlcHBpbmctIFNFUlIrIEZh c3RCMkItIERpc0lOVHgtDQoJU3RhdHVzOiBDYXArIDY2TUh6LSBVREYtIEZhc3RCMkItIFBh ckVyci0gREVWU0VMPWZhc3QgPlRBYm9ydC0gPFRBYm9ydC0gPE1BYm9ydC0gPlNFUlItIDxQ RVJSLSBJTlR4LQ0KCUxhdGVuY3k6IDAsIENhY2hlIExpbmUgU2l6ZTogNjQgYnl0ZXMNCglC dXM6IHByaW1hcnk9MDAsIHNlY29uZGFyeT0wMiwgc3Vib3JkaW5hdGU9MDIsIHNlYy1sYXRl bmN5PTANCglJL08gYmVoaW5kIGJyaWRnZTogMDAwMGMwMDAtMDAwMGNmZmYNCglNZW1vcnkg YmVoaW5kIGJyaWRnZTogZmU5MDAwMDAtZmU5ZmZmZmYNCglTZWNvbmRhcnkgc3RhdHVzOiA2 Nk1Iei0gRmFzdEIyQi0gUGFyRXJyLSBERVZTRUw9ZmFzdCA+VEFib3J0LSA8VEFib3J0LSA8 TUFib3J0KyA8U0VSUi0gPFBFUlItDQoJQnJpZGdlQ3RsOiBQYXJpdHkrIFNFUlIrIE5vSVNB KyBWR0EtIE1BYm9ydC0gPlJlc2V0LSBGYXN0QjJCLQ0KCQlQcmlEaXNjVG1yLSBTZWNEaXNj VG1yLSBEaXNjVG1yU3RhdC0gRGlzY1RtclNFUlJFbi0NCglDYXBhYmlsaXRpZXM6IFs1MF0g UG93ZXIgTWFuYWdlbWVudCB2ZXJzaW9uIDMNCgkJRmxhZ3M6IFBNRUNsay0gRFNJLSBEMS0g RDItIEF1eEN1cnJlbnQ9MG1BIFBNRShEMCssRDEtLEQyLSxEM2hvdCssRDNjb2xkKykNCgkJ U3RhdHVzOiBEMCBQTUUtRW5hYmxlLSBEU2VsPTAgRFNjYWxlPTAgUE1FLQ0KCUNhcGFiaWxp dGllczogWzU4XSBFeHByZXNzICh2MSkgUm9vdCBQb3J0IChTbG90LSksIE1TSSAwMA0KCQlE ZXZDYXA6CU1heFBheWxvYWQgMTI4IGJ5dGVzLCBQaGFudEZ1bmMgMCwgTGF0ZW5jeSBMMHMg PDY0bnMsIEwxIDwxdXMNCgkJCUV4dFRhZysgUkJFLSBGTFJlc2V0LQ0KCQlEZXZDdGw6CVJl cG9ydCBlcnJvcnM6IENvcnJlY3RhYmxlLSBOb24tRmF0YWwtIEZhdGFsLSBVbnN1cHBvcnRl ZC0NCgkJCVJseGRPcmQrIEV4dFRhZy0gUGhhbnRGdW5jLSBBdXhQd3ItIE5vU25vb3ArDQoJ CQlNYXhQYXlsb2FkIDEyOCBieXRlcywgTWF4UmVhZFJlcSAxMjggYnl0ZXMNCgkJRGV2U3Rh OglDb3JyRXJyLSBVbmNvcnJFcnItIEZhdGFsRXJyLSBVbnN1cHBSZXEtIEF1eFB3ci0gVHJh bnNQZW5kLQ0KCQlMbmtDYXA6CVBvcnQgIzMsIFNwZWVkIDIuNUdUL3MsIFdpZHRoIHgxLCBB U1BNIEwwcyBMMSwgTGF0ZW5jeSBMMCA8NjRucywgTDEgPDF1cw0KCQkJQ2xvY2tQTS0gU3Vw cmlzZS0gTExBY3RSZXAtIEJ3Tm90LQ0KCQlMbmtDdGw6CUFTUE0gRGlzYWJsZWQ7IFJDQiA2 NCBieXRlcyBEaXNhYmxlZC0gUmV0cmFpbi0gQ29tbUNsay0NCgkJCUV4dFN5bmNoLSBDbG9j a1BNLSBBdXRXaWREaXMtIEJXSW50LSBBdXRCV0ludC0NCgkJTG5rU3RhOglTcGVlZCAyLjVH VC9zLCBXaWR0aCB4MSwgVHJFcnItIFRyYWluLSBTbG90Q2xrKyBETEFjdGl2ZS0gQldNZ210 LSBBQldNZ210LQ0KCQlSb290Q3RsOiBFcnJDb3JyZWN0YWJsZS0gRXJyTm9uLUZhdGFsLSBF cnJGYXRhbC0gUE1FSW50RW5hLSBDUlNWaXNpYmxlLQ0KCQlSb290Q2FwOiBDUlNWaXNpYmxl LQ0KCQlSb290U3RhOiBQTUUgUmVxSUQgMDAwMCwgUE1FU3RhdHVzLSBQTUVQZW5kaW5nLQ0K CUNhcGFiaWxpdGllczogWzgwXSBNU0k6IE1hc2stIDY0Yml0LSBDb3VudD0xLzEgRW5hYmxl LQ0KCQlBZGRyZXNzOiAwMDAwMDAwMCAgRGF0YTogMDAwMA0KCUNhcGFiaWxpdGllczogW2Iw XSBTdWJzeXN0ZW06IEFUSSBUZWNobm9sb2dpZXMgSW5jIERldmljZSA1OTUwDQoJQ2FwYWJp bGl0aWVzOiBbYjhdIEh5cGVyVHJhbnNwb3J0OiBNU0kgTWFwcGluZyBFbmFibGUrIEZpeGVk Kw0KDQowMDowNy4wIFBDSSBicmlkZ2U6IEFUSSBUZWNobm9sb2dpZXMgSW5jIFJTNDgwIFBD SSBCcmlkZ2UgKHByb2ctaWYgMDAgW05vcm1hbCBkZWNvZGVdKQ0KCUNvbnRyb2w6IEkvTy0g TWVtLSBCdXNNYXN0ZXIrIFNwZWNDeWNsZS0gTWVtV0lOVi0gVkdBU25vb3AtIFBhckVyci0g U3RlcHBpbmctIFNFUlIrIEZhc3RCMkItIERpc0lOVHgtDQoJU3RhdHVzOiBDYXArIDY2TUh6 LSBVREYtIEZhc3RCMkItIFBhckVyci0gREVWU0VMPWZhc3QgPlRBYm9ydC0gPFRBYm9ydC0g PE1BYm9ydC0gPlNFUlItIDxQRVJSLSBJTlR4LQ0KCUxhdGVuY3k6IDAsIENhY2hlIExpbmUg U2l6ZTogNjQgYnl0ZXMNCglCdXM6IHByaW1hcnk9MDAsIHNlY29uZGFyeT0wMywgc3Vib3Jk aW5hdGU9MDMsIHNlYy1sYXRlbmN5PTANCglTZWNvbmRhcnkgc3RhdHVzOiA2Nk1Iei0gRmFz dEIyQi0gUGFyRXJyLSBERVZTRUw9ZmFzdCA+VEFib3J0LSA8VEFib3J0LSA8TUFib3J0LSA8 U0VSUi0gPFBFUlItDQoJQnJpZGdlQ3RsOiBQYXJpdHkrIFNFUlIrIE5vSVNBKyBWR0EtIE1B Ym9ydC0gPlJlc2V0LSBGYXN0QjJCLQ0KCQlQcmlEaXNjVG1yLSBTZWNEaXNjVG1yLSBEaXNj VG1yU3RhdC0gRGlzY1RtclNFUlJFbi0NCglDYXBhYmlsaXRpZXM6IFs1MF0gUG93ZXIgTWFu YWdlbWVudCB2ZXJzaW9uIDMNCgkJRmxhZ3M6IFBNRUNsay0gRFNJLSBEMS0gRDItIEF1eEN1 cnJlbnQ9MG1BIFBNRShEMCssRDEtLEQyLSxEM2hvdCssRDNjb2xkKykNCgkJU3RhdHVzOiBE MCBQTUUtRW5hYmxlLSBEU2VsPTAgRFNjYWxlPTAgUE1FLQ0KCUNhcGFiaWxpdGllczogWzU4 XSBFeHByZXNzICh2MSkgUm9vdCBQb3J0IChTbG90LSksIE1TSSAwMA0KCQlEZXZDYXA6CU1h eFBheWxvYWQgMTI4IGJ5dGVzLCBQaGFudEZ1bmMgMCwgTGF0ZW5jeSBMMHMgPDY0bnMsIEwx IDwxdXMNCgkJCUV4dFRhZysgUkJFLSBGTFJlc2V0LQ0KCQlEZXZDdGw6CVJlcG9ydCBlcnJv cnM6IENvcnJlY3RhYmxlLSBOb24tRmF0YWwtIEZhdGFsLSBVbnN1cHBvcnRlZC0NCgkJCVJs eGRPcmQrIEV4dFRhZy0gUGhhbnRGdW5jLSBBdXhQd3ItIE5vU25vb3ArDQoJCQlNYXhQYXls b2FkIDEyOCBieXRlcywgTWF4UmVhZFJlcSAxMjggYnl0ZXMNCgkJRGV2U3RhOglDb3JyRXJy LSBVbmNvcnJFcnItIEZhdGFsRXJyLSBVbnN1cHBSZXEtIEF1eFB3ci0gVHJhbnNQZW5kLQ0K CQlMbmtDYXA6CVBvcnQgIzI0NywgU3BlZWQgMi41R1QvcywgV2lkdGggeDEsIEFTUE0gTDBz IEwxLCBMYXRlbmN5IEwwIDw2NG5zLCBMMSA8MXVzDQoJCQlDbG9ja1BNLSBTdXByaXNlLSBM TEFjdFJlcC0gQndOb3QtDQoJCUxua0N0bDoJQVNQTSBEaXNhYmxlZDsgUkNCIDY0IGJ5dGVz IERpc2FibGVkLSBSZXRyYWluLSBDb21tQ2xrLQ0KCQkJRXh0U3luY2gtIENsb2NrUE0tIEF1 dFdpZERpcy0gQldJbnQtIEF1dEJXSW50LQ0KCQlMbmtTdGE6CVNwZWVkIDIuNUdUL3MsIFdp ZHRoIHgxNiwgVHJFcnItIFRyYWluLSBTbG90Q2xrKyBETEFjdGl2ZS0gQldNZ210LSBBQldN Z210LQ0KCQlSb290Q3RsOiBFcnJDb3JyZWN0YWJsZS0gRXJyTm9uLUZhdGFsLSBFcnJGYXRh bC0gUE1FSW50RW5hLSBDUlNWaXNpYmxlLQ0KCQlSb290Q2FwOiBDUlNWaXNpYmxlLQ0KCQlS b290U3RhOiBQTUUgUmVxSUQgMDAwMCwgUE1FU3RhdHVzLSBQTUVQZW5kaW5nLQ0KCUNhcGFi aWxpdGllczogWzgwXSBNU0k6IE1hc2stIDY0Yml0LSBDb3VudD0xLzEgRW5hYmxlLQ0KCQlB ZGRyZXNzOiAwMDAwMDAwMCAgRGF0YTogMDAwMA0KCUNhcGFiaWxpdGllczogW2IwXSBTdWJz eXN0ZW06IEFUSSBUZWNobm9sb2dpZXMgSW5jIERldmljZSA1OTUwDQoJQ2FwYWJpbGl0aWVz OiBbYjhdIEh5cGVyVHJhbnNwb3J0OiBNU0kgTWFwcGluZyBFbmFibGUrIEZpeGVkKw0KDQow MDoxOC4wIEhvc3QgYnJpZGdlOiBBZHZhbmNlZCBNaWNybyBEZXZpY2VzIFtBTURdIEs4IFtB dGhsb242NC9PcHRlcm9uXSBIeXBlclRyYW5zcG9ydCBUZWNobm9sb2d5IENvbmZpZ3VyYXRp b24NCglDb250cm9sOiBJL08tIE1lbS0gQnVzTWFzdGVyLSBTcGVjQ3ljbGUtIE1lbVdJTlYt IFZHQVNub29wLSBQYXJFcnItIFN0ZXBwaW5nLSBTRVJSLSBGYXN0QjJCLSBEaXNJTlR4LQ0K CVN0YXR1czogQ2FwKyA2Nk1Iei0gVURGLSBGYXN0QjJCLSBQYXJFcnItIERFVlNFTD1mYXN0 ID5UQWJvcnQtIDxUQWJvcnQtIDxNQWJvcnQtID5TRVJSLSA8UEVSUi0gSU5UeC0NCglDYXBh YmlsaXRpZXM6IFs4MF0gSHlwZXJUcmFuc3BvcnQ6IEhvc3Qgb3IgU2Vjb25kYXJ5IEludGVy ZmFjZQ0KCQlDb21tYW5kOiBXYXJtUnN0KyBEYmxFbmQtIERldk51bT0wIENoYWluU2lkZS0g SG9zdEhpZGUrIFNsYXZlLSA8RU9DRXJyLSBEVUwtDQoJCUxpbmsgQ29udHJvbDogQ0ZsRS0g Q1NULSBDRkUtIDxMa0ZhaWwtIEluaXQrIEVPQy0gVFhPLSA8Q1JDRXJyPTAgSXNvY0VuLSBM U0VuLSBFeHRDVEwtIDY0Yi0NCgkJTGluayBDb25maWc6IE1MV0k9MTZiaXQgRHdGY0luLSBN TFdPPTE2Yml0IER3RmNPdXQtIExXST0xNmJpdCBEd0ZjSW5Fbi0gTFdPPTE2Yml0IER3RmNP dXRFbi0NCgkJUmV2aXNpb24gSUQ6IDEuMDINCgkJTGluayBGcmVxdWVuY3k6IDEuMEdIeg0K CQlMaW5rIEVycm9yOiA8UHJvdC0gPE92ZmwtIDxFT0MtIENUTFRtLQ0KCQlMaW5rIEZyZXF1 ZW5jeSBDYXBhYmlsaXR5OiAyMDBNSHorIDMwME1Iei0gNDAwTUh6KyA1MDBNSHotIDYwME1I eisgODAwTUh6KyAxLjBHSHorIDEuMkdIei0gMS40R0h6LSAxLjZHSHotIFZlbmQtDQoJCUZl YXR1cmUgQ2FwYWJpbGl0eTogSXNvY0ZDLSBMRFRTVE9QKyBDUkNUTS0gRUNUTFQtIDY0YkEt IFVJRFJELSBFeHRSUy0gVUNuZkUtDQoNCjAwOjE4LjEgSG9zdCBicmlkZ2U6IEFkdmFuY2Vk IE1pY3JvIERldmljZXMgW0FNRF0gSzggW0F0aGxvbjY0L09wdGVyb25dIEFkZHJlc3MgTWFw DQoJQ29udHJvbDogSS9PLSBNZW0tIEJ1c01hc3Rlci0gU3BlY0N5Y2xlLSBNZW1XSU5WLSBW R0FTbm9vcC0gUGFyRXJyLSBTdGVwcGluZy0gU0VSUi0gRmFzdEIyQi0gRGlzSU5UeC0NCglT dGF0dXM6IENhcC0gNjZNSHotIFVERi0gRmFzdEIyQi0gUGFyRXJyLSBERVZTRUw9ZmFzdCA+ VEFib3J0LSA8VEFib3J0LSA8TUFib3J0LSA+U0VSUi0gPFBFUlItIElOVHgtDQoNCjAwOjE4 LjIgSG9zdCBicmlkZ2U6IEFkdmFuY2VkIE1pY3JvIERldmljZXMgW0FNRF0gSzggW0F0aGxv bjY0L09wdGVyb25dIERSQU0gQ29udHJvbGxlcg0KCUNvbnRyb2w6IEkvTy0gTWVtLSBCdXNN YXN0ZXItIFNwZWNDeWNsZS0gTWVtV0lOVi0gVkdBU25vb3AtIFBhckVyci0gU3RlcHBpbmct IFNFUlItIEZhc3RCMkItIERpc0lOVHgtDQoJU3RhdHVzOiBDYXAtIDY2TUh6LSBVREYtIEZh c3RCMkItIFBhckVyci0gREVWU0VMPWZhc3QgPlRBYm9ydC0gPFRBYm9ydC0gPE1BYm9ydC0g PlNFUlItIDxQRVJSLSBJTlR4LQ0KDQowMDoxOC4zIEhvc3QgYnJpZGdlOiBBZHZhbmNlZCBN aWNybyBEZXZpY2VzIFtBTURdIEs4IFtBdGhsb242NC9PcHRlcm9uXSBNaXNjZWxsYW5lb3Vz IENvbnRyb2wNCglDb250cm9sOiBJL08tIE1lbS0gQnVzTWFzdGVyLSBTcGVjQ3ljbGUtIE1l bVdJTlYtIFZHQVNub29wLSBQYXJFcnItIFN0ZXBwaW5nLSBTRVJSLSBGYXN0QjJCLSBEaXNJ TlR4LQ0KCVN0YXR1czogQ2FwLSA2Nk1Iei0gVURGLSBGYXN0QjJCLSBQYXJFcnItIERFVlNF TD1mYXN0ID5UQWJvcnQtIDxUQWJvcnQtIDxNQWJvcnQtID5TRVJSLSA8UEVSUi0gSU5UeC0N Cg0KMDA6MTkuMCBQQ0kgYnJpZGdlOiBBTGkgQ29ycG9yYXRpb24gTTUyNDkgSFRUIHRvIFBD SSBCcmlkZ2UgKHByb2ctaWYgMDAgW05vcm1hbCBkZWNvZGVdKQ0KCUNvbnRyb2w6IEkvTysg TWVtKyBCdXNNYXN0ZXIrIFNwZWNDeWNsZS0gTWVtV0lOVi0gVkdBU25vb3AtIFBhckVyci0g U3RlcHBpbmctIFNFUlIrIEZhc3RCMkItIERpc0lOVHgtDQoJU3RhdHVzOiBDYXArIDY2TUh6 LSBVREYtIEZhc3RCMkItIFBhckVyci0gREVWU0VMPWZhc3QgPlRBYm9ydC0gPFRBYm9ydC0g PE1BYm9ydCsgPlNFUlIrIDxQRVJSLSBJTlR4LQ0KCUxhdGVuY3k6IDANCglCdXM6IHByaW1h cnk9MDAsIHNlY29uZGFyeT0wNCwgc3Vib3JkaW5hdGU9MDQsIHNlYy1sYXRlbmN5PTY0DQoJ SS9PIGJlaGluZCBicmlkZ2U6IDAwMDBkMDAwLTAwMDBkZmZmDQoJTWVtb3J5IGJlaGluZCBi cmlkZ2U6IGZlYTAwMDAwLWZlYWZmZmZmDQoJU2Vjb25kYXJ5IHN0YXR1czogNjZNSHotIEZh c3RCMkItIFBhckVyci0gREVWU0VMPW1lZGl1bSA+VEFib3J0LSA8VEFib3J0LSA8TUFib3J0 KyA8U0VSUisgPFBFUlIrDQoJQnJpZGdlQ3RsOiBQYXJpdHkrIFNFUlIrIE5vSVNBKyBWR0Et IE1BYm9ydC0gPlJlc2V0LSBGYXN0QjJCLQ0KCQlQcmlEaXNjVG1yLSBTZWNEaXNjVG1yLSBE aXNjVG1yU3RhdC0gRGlzY1RtclNFUlJFbi0NCglDYXBhYmlsaXRpZXM6IFtjMF0gSHlwZXJU cmFuc3BvcnQ6IE1TSSBNYXBwaW5nIEVuYWJsZSsgRml4ZWQrDQoNCjAwOjFjLjAgVVNCIENv bnRyb2xsZXI6IEFMaSBDb3Jwb3JhdGlvbiBVU0IgMS4xIENvbnRyb2xsZXIgKHJldiAwMykg KHByb2ctaWYgMTAgW09IQ0ldKQ0KCVN1YnN5c3RlbTogQVNVU1RlSyBDb21wdXRlciBJbmMu IERldmljZSA4MTU2DQoJQ29udHJvbDogSS9PKyBNZW0rIEJ1c01hc3RlcisgU3BlY0N5Y2xl LSBNZW1XSU5WKyBWR0FTbm9vcC0gUGFyRXJyLSBTdGVwcGluZy0gU0VSUisgRmFzdEIyQi0g RGlzSU5UeC0NCglTdGF0dXM6IENhcC0gNjZNSHorIFVERi0gRmFzdEIyQisgUGFyRXJyLSBE RVZTRUw9bWVkaXVtID5UQWJvcnQtIDxUQWJvcnQtIDxNQWJvcnQtID5TRVJSLSA8UEVSUisg SU5UeCsNCglMYXRlbmN5OiA2NCAoMjAwMDBucyBtYXgpLCBDYWNoZSBMaW5lIFNpemU6IDY0 IGJ5dGVzDQoJSW50ZXJydXB0OiBwaW4gQSByb3V0ZWQgdG8gSVJRIDE3DQoJUmVnaW9uIDA6 IE1lbW9yeSBhdCBmZWJmYzAwMCAoMzItYml0LCBub24tcHJlZmV0Y2hhYmxlKQ0KDQowMDox Yy4xIFVTQiBDb250cm9sbGVyOiBBTGkgQ29ycG9yYXRpb24gVVNCIDEuMSBDb250cm9sbGVy IChyZXYgMDMpIChwcm9nLWlmIDEwIFtPSENJXSkNCglTdWJzeXN0ZW06IEFTVVNUZUsgQ29t cHV0ZXIgSW5jLiBEZXZpY2UgODE1Ng0KCUNvbnRyb2w6IEkvTysgTWVtKyBCdXNNYXN0ZXIr IFNwZWNDeWNsZS0gTWVtV0lOVisgVkdBU25vb3AtIFBhckVyci0gU3RlcHBpbmctIFNFUlIr IEZhc3RCMkItIERpc0lOVHgtDQoJU3RhdHVzOiBDYXAtIDY2TUh6KyBVREYtIEZhc3RCMkIr IFBhckVyci0gREVWU0VMPW1lZGl1bSA+VEFib3J0LSA8VEFib3J0LSA8TUFib3J0LSA+U0VS Ui0gPFBFUlIrIElOVHgrDQoJTGF0ZW5jeTogNjQgKDIwMDAwbnMgbWF4KSwgQ2FjaGUgTGlu ZSBTaXplOiA2NCBieXRlcw0KCUludGVycnVwdDogcGluIEIgcm91dGVkIHRvIElSUSAxOA0K CVJlZ2lvbiAwOiBNZW1vcnkgYXQgZmViZmQwMDAgKDMyLWJpdCwgbm9uLXByZWZldGNoYWJs ZSkNCg0KMDA6MWMuMiBVU0IgQ29udHJvbGxlcjogQUxpIENvcnBvcmF0aW9uIFVTQiAxLjEg Q29udHJvbGxlciAocmV2IDAzKSAocHJvZy1pZiAxMCBbT0hDSV0pDQoJU3Vic3lzdGVtOiBB U1VTVGVLIENvbXB1dGVyIEluYy4gRGV2aWNlIDgxNTYNCglDb250cm9sOiBJL08rIE1lbSsg QnVzTWFzdGVyKyBTcGVjQ3ljbGUtIE1lbVdJTlYrIFZHQVNub29wLSBQYXJFcnItIFN0ZXBw aW5nLSBTRVJSKyBGYXN0QjJCLSBEaXNJTlR4LQ0KCVN0YXR1czogQ2FwLSA2Nk1IeisgVURG LSBGYXN0QjJCKyBQYXJFcnItIERFVlNFTD1tZWRpdW0gPlRBYm9ydC0gPFRBYm9ydC0gPE1B Ym9ydC0gPlNFUlItIDxQRVJSKyBJTlR4Kw0KCUxhdGVuY3k6IDY0ICgyMDAwMG5zIG1heCks IENhY2hlIExpbmUgU2l6ZTogNjQgYnl0ZXMNCglJbnRlcnJ1cHQ6IHBpbiBDIHJvdXRlZCB0 byBJUlEgMTkNCglSZWdpb24gMDogTWVtb3J5IGF0IGZlYmZlMDAwICgzMi1iaXQsIG5vbi1w cmVmZXRjaGFibGUpDQoNCjAwOjFjLjMgVVNCIENvbnRyb2xsZXI6IEFMaSBDb3Jwb3JhdGlv biBVU0IgMi4wIENvbnRyb2xsZXIgKHJldiAwMSkgKHByb2ctaWYgMjAgW0VIQ0ldKQ0KCVN1 YnN5c3RlbTogQVNVU1RlSyBDb21wdXRlciBJbmMuIERldmljZSA4MTU2DQoJQ29udHJvbDog SS9PLSBNZW0rIEJ1c01hc3RlcisgU3BlY0N5Y2xlLSBNZW1XSU5WKyBWR0FTbm9vcC0gUGFy RXJyLSBTdGVwcGluZy0gU0VSUisgRmFzdEIyQi0gRGlzSU5UeC0NCglTdGF0dXM6IENhcCsg NjZNSHorIFVERi0gRmFzdEIyQisgUGFyRXJyLSBERVZTRUw9bWVkaXVtID5UQWJvcnQtIDxU QWJvcnQtIDxNQWJvcnQtID5TRVJSLSA8UEVSUisgSU5UeC0NCglMYXRlbmN5OiA2NCAoNDAw MG5zIG1pbiwgODAwMG5zIG1heCksIENhY2hlIExpbmUgU2l6ZTogNjQgYnl0ZXMNCglJbnRl cnJ1cHQ6IHBpbiBEIHJvdXRlZCB0byBJUlEgMjMNCglSZWdpb24gMDogTWVtb3J5IGF0IGZl YmZmYzAwICgzMi1iaXQsIG5vbi1wcmVmZXRjaGFibGUpDQoJQ2FwYWJpbGl0aWVzOiBbNTBd IFBvd2VyIE1hbmFnZW1lbnQgdmVyc2lvbiAyDQoJCUZsYWdzOiBQTUVDbGstIERTSS0gRDEt IEQyLSBBdXhDdXJyZW50PTBtQSBQTUUoRDArLEQxLSxEMi0sRDNob3QrLEQzY29sZCspDQoJ CVN0YXR1czogRDAgUE1FLUVuYWJsZS0gRFNlbD0wIERTY2FsZT0wIFBNRS0NCglDYXBhYmls aXRpZXM6IFs1OF0gRGVidWcgcG9ydDogQkFSPTEgb2Zmc2V0PTAwOTANCg0KMDA6MWQuMCBB dWRpbyBkZXZpY2U6IEFMaSBDb3Jwb3JhdGlvbiBIaWdoIERlZmluaXRpb24gQXVkaW8vQUMn OTcgSG9zdCBDb250cm9sbGVyDQoJU3Vic3lzdGVtOiBBU1VTVGVLIENvbXB1dGVyIEluYy4g RGV2aWNlIDgxYjQNCglDb250cm9sOiBJL08tIE1lbSsgQnVzTWFzdGVyKyBTcGVjQ3ljbGUt IE1lbVdJTlYtIFZHQVNub29wLSBQYXJFcnItIFN0ZXBwaW5nLSBTRVJSKyBGYXN0QjJCLSBE aXNJTlR4LQ0KCVN0YXR1czogQ2FwKyA2Nk1Iei0gVURGLSBGYXN0QjJCLSBQYXJFcnItIERF VlNFTD1tZWRpdW0gPlRBYm9ydC0gPFRBYm9ydC0gPE1BYm9ydC0gPlNFUlItIDxQRVJSLSBJ TlR4LQ0KCUxhdGVuY3k6IDY0ICg0MDAwbnMgbWluLCAyMDAwMG5zIG1heCkNCglJbnRlcnJ1 cHQ6IHBpbiBDIHJvdXRlZCB0byBJUlEgMjINCglSZWdpb24gMDogTWVtb3J5IGF0IGZlYmY4 MDAwICg2NC1iaXQsIG5vbi1wcmVmZXRjaGFibGUpDQoJQ2FwYWJpbGl0aWVzOiBbNTBdIFBv d2VyIE1hbmFnZW1lbnQgdmVyc2lvbiAyDQoJCUZsYWdzOiBQTUVDbGstIERTSS0gRDEtIEQy LSBBdXhDdXJyZW50PTU1bUEgUE1FKEQwKyxEMS0sRDItLEQzaG90KyxEM2NvbGQrKQ0KCQlT dGF0dXM6IEQwIFBNRS1FbmFibGUtIERTZWw9MCBEU2NhbGU9MCBQTUUtDQoNCjAwOjFlLjAg SVNBIGJyaWRnZTogQUxpIENvcnBvcmF0aW9uIFBDSSB0byBMUEMgQ29udHJvbGxlciAocmV2 IDMxKQ0KCVN1YnN5c3RlbTogQVNVU1RlSyBDb21wdXRlciBJbmMuIERldmljZSA4MTU2DQoJ Q29udHJvbDogSS9PKyBNZW0rIEJ1c01hc3RlcisgU3BlY0N5Y2xlKyBNZW1XSU5WLSBWR0FT bm9vcC0gUGFyRXJyLSBTdGVwcGluZy0gU0VSUi0gRmFzdEIyQi0gRGlzSU5UeC0NCglTdGF0 dXM6IENhcC0gNjZNSHotIFVERi0gRmFzdEIyQi0gUGFyRXJyLSBERVZTRUw9bWVkaXVtID5U QWJvcnQtIDxUQWJvcnQtIDxNQWJvcnQtID5TRVJSLSA8UEVSUi0gSU5UeC0NCglMYXRlbmN5 OiAwICgyNTBucyBtaW4sIDYwMDBucyBtYXgpDQoJSW50ZXJydXB0OiBwaW4gPyByb3V0ZWQg dG8gSVJRIDI1NQ0KDQowMDoxZS4xIEJyaWRnZTogQUxpIENvcnBvcmF0aW9uIE03MTAxIFBv d2VyIE1hbmFnZW1lbnQgQ29udHJvbGxlciBbUE1VXQ0KCVN1YnN5c3RlbTogQVNVU1RlSyBD b21wdXRlciBJbmMuIERldmljZSA4MTU2DQoJQ29udHJvbDogSS9PLSBNZW0tIEJ1c01hc3Rl ci0gU3BlY0N5Y2xlLSBNZW1XSU5WLSBWR0FTbm9vcC0gUGFyRXJyLSBTdGVwcGluZy0gU0VS Ui0gRmFzdEIyQi0gRGlzSU5UeC0NCglTdGF0dXM6IENhcC0gNjZNSHotIFVERi0gRmFzdEIy Qi0gUGFyRXJyLSBERVZTRUw9bWVkaXVtID5UQWJvcnQtIDxUQWJvcnQtIDxNQWJvcnQtID5T RVJSLSA8UEVSUi0gSU5UeC0NCg0KMDA6MWYuMCBJREUgaW50ZXJmYWNlOiBBTGkgQ29ycG9y YXRpb24gTTUyMjkgSURFIChyZXYgYzcpIChwcm9nLWlmIDhhIFtNYXN0ZXIgU2VjUCBQcmlQ XSkNCglTdWJzeXN0ZW06IEFTVVNUZUsgQ29tcHV0ZXIgSW5jLiBEZXZpY2UgODE1Ng0KCUNv bnRyb2w6IEkvTysgTWVtLSBCdXNNYXN0ZXIrIFNwZWNDeWNsZS0gTWVtV0lOVi0gVkdBU25v b3AtIFBhckVyci0gU3RlcHBpbmctIFNFUlItIEZhc3RCMkItIERpc0lOVHgtDQoJU3RhdHVz OiBDYXArIDY2TUh6KyBVREYtIEZhc3RCMkIrIFBhckVyci0gREVWU0VMPW1lZGl1bSA+VEFi b3J0LSA8VEFib3J0LSA8TUFib3J0LSA+U0VSUi0gPFBFUlItIElOVHgtDQoJTGF0ZW5jeTog MzINCglJbnRlcnJ1cHQ6IHBpbiBBIHJvdXRlZCB0byBJUlEgMjU1DQoJUmVnaW9uIDQ6IEkv TyBwb3J0cyBhdCBmZjAwDQoJQ2FwYWJpbGl0aWVzOiBbNjBdIFBvd2VyIE1hbmFnZW1lbnQg dmVyc2lvbiAyDQoJCUZsYWdzOiBQTUVDbGstIERTSS0gRDEtIEQyLSBBdXhDdXJyZW50PTBt QSBQTUUoRDAtLEQxLSxEMi0sRDNob3QtLEQzY29sZC0pDQoJCVN0YXR1czogRDAgUE1FLUVu YWJsZS0gRFNlbD0wIERTY2FsZT0wIFBNRS0NCg0KMDA6MWYuMSBSQUlEIGJ1cyBjb250cm9s bGVyOiBBTGkgQ29ycG9yYXRpb24gVUxpIDUyODcgU0FUQSAocmV2IDAyKQ0KCVN1YnN5c3Rl bTogQVNVU1RlSyBDb21wdXRlciBJbmMuIERldmljZSA4MTU2DQoJQ29udHJvbDogSS9PKyBN ZW0rIEJ1c01hc3RlcisgU3BlY0N5Y2xlLSBNZW1XSU5WLSBWR0FTbm9vcC0gUGFyRXJyLSBT dGVwcGluZy0gU0VSUisgRmFzdEIyQi0gRGlzSU5UeC0NCglTdGF0dXM6IENhcCsgNjZNSHor IFVERi0gRmFzdEIyQisgUGFyRXJyLSBERVZTRUw9bWVkaXVtID5UQWJvcnQtIDxUQWJvcnQt IDxNQWJvcnQtID5TRVJSLSA8UEVSUi0gSU5UeC0NCglMYXRlbmN5OiAxMjgsIENhY2hlIExp bmUgU2l6ZTogNTEyIGJ5dGVzDQoJSW50ZXJydXB0OiBwaW4gQSByb3V0ZWQgdG8gSVJRIDIx DQoJUmVnaW9uIDA6IEkvTyBwb3J0cyBhdCBlYzAwDQoJUmVnaW9uIDE6IEkvTyBwb3J0cyBh dCBlODgwDQoJUmVnaW9uIDI6IEkvTyBwb3J0cyBhdCBlODAwDQoJUmVnaW9uIDM6IEkvTyBw b3J0cyBhdCBlNDgwDQoJUmVnaW9uIDQ6IEkvTyBwb3J0cyBhdCBlNDAwDQoJUmVnaW9uIDU6 IE1lbW9yeSBhdCBmZWJmZjgwMCAoMzItYml0LCBub24tcHJlZmV0Y2hhYmxlKQ0KCUNhcGFi aWxpdGllczogWzYwXSBQb3dlciBNYW5hZ2VtZW50IHZlcnNpb24gMg0KCQlGbGFnczogUE1F Q2xrLSBEU0ktIEQxLSBEMi0gQXV4Q3VycmVudD0wbUEgUE1FKEQwLSxEMS0sRDItLEQzaG90 KyxEM2NvbGQtKQ0KCQlTdGF0dXM6IEQwIFBNRS1FbmFibGUtIERTZWw9MCBEU2NhbGU9MCBQ TUUrDQoNCjAxOjAwLjAgVkdBIGNvbXBhdGlibGUgY29udHJvbGxlcjogQVRJIFRlY2hub2xv Z2llcyBJbmMgUlYzNzAgW1NhcHBoaXJlIFg1NTAgU2lsZW50XSAocHJvZy1pZiAwMCBbVkdB IGNvbnRyb2xsZXJdKQ0KCVN1YnN5c3RlbTogUEMgUGFydG5lciBMaW1pdGVkIERldmljZSAz MDAwDQoJQ29udHJvbDogSS9PKyBNZW0rIEJ1c01hc3RlcisgU3BlY0N5Y2xlLSBNZW1XSU5W LSBWR0FTbm9vcC0gUGFyRXJyLSBTdGVwcGluZy0gU0VSUisgRmFzdEIyQi0gRGlzSU5UeC0N CglTdGF0dXM6IENhcCsgNjZNSHotIFVERi0gRmFzdEIyQi0gUGFyRXJyLSBERVZTRUw9ZmFz dCA+VEFib3J0LSA8VEFib3J0LSA8TUFib3J0LSA+U0VSUi0gPFBFUlItIElOVHgtDQoJTGF0 ZW5jeTogMCwgQ2FjaGUgTGluZSBTaXplOiA2NCBieXRlcw0KCUludGVycnVwdDogcGluIEEg cm91dGVkIHRvIElSUSAxOA0KCVJlZ2lvbiAwOiBNZW1vcnkgYXQgZDAwMDAwMDAgKDMyLWJp dCwgcHJlZmV0Y2hhYmxlKQ0KCVJlZ2lvbiAxOiBJL08gcG9ydHMgYXQgYjgwMA0KCVJlZ2lv biAyOiBNZW1vcnkgYXQgZmU0MDAwMDAgKDMyLWJpdCwgbm9uLXByZWZldGNoYWJsZSkNCglF eHBhbnNpb24gUk9NIGF0IGZlOGUwMDAwIFtkaXNhYmxlZF0NCglDYXBhYmlsaXRpZXM6IFs1 MF0gUG93ZXIgTWFuYWdlbWVudCB2ZXJzaW9uIDINCgkJRmxhZ3M6IFBNRUNsay0gRFNJLSBE MSsgRDIrIEF1eEN1cnJlbnQ9MG1BIFBNRShEMC0sRDEtLEQyLSxEM2hvdC0sRDNjb2xkLSkN CgkJU3RhdHVzOiBEMCBQTUUtRW5hYmxlLSBEU2VsPTAgRFNjYWxlPTAgUE1FLQ0KCUNhcGFi aWxpdGllczogWzU4XSBFeHByZXNzICh2MSkgRW5kcG9pbnQsIE1TSSAwMA0KCQlEZXZDYXA6 CU1heFBheWxvYWQgMTI4IGJ5dGVzLCBQaGFudEZ1bmMgMCwgTGF0ZW5jeSBMMHMgPDEyOG5z LCBMMSA8MnVzDQoJCQlFeHRUYWcrIEF0dG5CdG4tIEF0dG5JbmQtIFB3ckluZC0gUkJFLSBG TFJlc2V0LQ0KCQlEZXZDdGw6CVJlcG9ydCBlcnJvcnM6IENvcnJlY3RhYmxlLSBOb24tRmF0 YWwtIEZhdGFsLSBVbnN1cHBvcnRlZC0NCgkJCVJseGRPcmQrIEV4dFRhZy0gUGhhbnRGdW5j LSBBdXhQd3ItIE5vU25vb3ArDQoJCQlNYXhQYXlsb2FkIDEyOCBieXRlcywgTWF4UmVhZFJl cSAxMjggYnl0ZXMNCgkJRGV2U3RhOglDb3JyRXJyLSBVbmNvcnJFcnItIEZhdGFsRXJyLSBV bnN1cHBSZXEtIEF1eFB3ci0gVHJhbnNQZW5kLQ0KCQlMbmtDYXA6CVBvcnQgIzAsIFNwZWVk IDIuNUdUL3MsIFdpZHRoIHgxNiwgQVNQTSBMMHMgTDEsIExhdGVuY3kgTDAgPDEyOG5zLCBM MSA8MXVzDQoJCQlDbG9ja1BNLSBTdXByaXNlLSBMTEFjdFJlcC0gQndOb3QtDQoJCUxua0N0 bDoJQVNQTSBEaXNhYmxlZDsgUkNCIDY0IGJ5dGVzIERpc2FibGVkLSBSZXRyYWluLSBDb21t Q2xrLQ0KCQkJRXh0U3luY2gtIENsb2NrUE0tIEF1dFdpZERpcy0gQldJbnQtIEF1dEJXSW50 LQ0KCQlMbmtTdGE6CVNwZWVkIDIuNUdUL3MsIFdpZHRoIHgxNiwgVHJFcnItIFRyYWluLSBT bG90Q2xrKyBETEFjdGl2ZS0gQldNZ210LSBBQldNZ210LQ0KCUNhcGFiaWxpdGllczogWzgw XSBNU0k6IE1hc2stIDY0Yml0KyBDb3VudD0xLzEgRW5hYmxlLQ0KCQlBZGRyZXNzOiAwMDAw MDAwMDAwMDAwMDAwICBEYXRhOiAwMDAwDQoNCjAxOjAwLjEgRGlzcGxheSBjb250cm9sbGVy OiBBVEkgVGVjaG5vbG9naWVzIEluYyBSVjM3MCBzZWNvbmRhcnkgW1NhcHBoaXJlIFg1NTAg U2lsZW50XQ0KCVN1YnN5c3RlbTogUEMgUGFydG5lciBMaW1pdGVkIERldmljZSAzMDAxDQoJ Q29udHJvbDogSS9PKyBNZW0rIEJ1c01hc3RlcisgU3BlY0N5Y2xlLSBNZW1XSU5WLSBWR0FT bm9vcC0gUGFyRXJyLSBTdGVwcGluZy0gU0VSUi0gRmFzdEIyQi0gRGlzSU5UeC0NCglTdGF0 dXM6IENhcCsgNjZNSHotIFVERi0gRmFzdEIyQi0gUGFyRXJyLSBERVZTRUw9ZmFzdCA+VEFi b3J0LSA8VEFib3J0LSA8TUFib3J0LSA+U0VSUi0gPFBFUlItIElOVHgtDQoJTGF0ZW5jeTog MCwgQ2FjaGUgTGluZSBTaXplOiA2NCBieXRlcw0KCUludGVycnVwdDogcGluID8gcm91dGVk IHRvIElSUSAyNTUNCglSZWdpb24gMDogTWVtb3J5IGF0IGZlOGQwMDAwICgzMi1iaXQsIG5v bi1wcmVmZXRjaGFibGUpDQoJQ2FwYWJpbGl0aWVzOiBbNTBdIFBvd2VyIE1hbmFnZW1lbnQg dmVyc2lvbiAyDQoJCUZsYWdzOiBQTUVDbGstIERTSS0gRDErIEQyKyBBdXhDdXJyZW50PTBt QSBQTUUoRDAtLEQxLSxEMi0sRDNob3QtLEQzY29sZC0pDQoJCVN0YXR1czogRDAgUE1FLUVu YWJsZS0gRFNlbD0wIERTY2FsZT0wIFBNRS0NCglDYXBhYmlsaXRpZXM6IFs1OF0gRXhwcmVz cyAodjEpIEVuZHBvaW50LCBNU0kgMDANCgkJRGV2Q2FwOglNYXhQYXlsb2FkIDEyOCBieXRl cywgUGhhbnRGdW5jIDAsIExhdGVuY3kgTDBzIDwxMjhucywgTDEgPDJ1cw0KCQkJRXh0VGFn LSBBdHRuQnRuLSBBdHRuSW5kLSBQd3JJbmQtIFJCRS0gRkxSZXNldC0NCgkJRGV2Q3RsOglS ZXBvcnQgZXJyb3JzOiBDb3JyZWN0YWJsZS0gTm9uLUZhdGFsLSBGYXRhbC0gVW5zdXBwb3J0 ZWQtDQoJCQlSbHhkT3JkLSBFeHRUYWctIFBoYW50RnVuYy0gQXV4UHdyLSBOb1Nub29wLQ0K CQkJTWF4UGF5bG9hZCAxMjggYnl0ZXMsIE1heFJlYWRSZXEgMTI4IGJ5dGVzDQoJCURldlN0 YToJQ29yckVyci0gVW5jb3JyRXJyLSBGYXRhbEVyci0gVW5zdXBwUmVxLSBBdXhQd3ItIFRy YW5zUGVuZC0NCgkJTG5rQ2FwOglQb3J0ICMwLCBTcGVlZCAyLjVHVC9zLCBXaWR0aCB4MTYs IEFTUE0gTDBzIEwxLCBMYXRlbmN5IEwwIDwxMjhucywgTDEgPDF1cw0KCQkJQ2xvY2tQTS0g U3VwcmlzZS0gTExBY3RSZXAtIEJ3Tm90LQ0KCQlMbmtDdGw6CUFTUE0gRGlzYWJsZWQ7IFJD QiA2NCBieXRlcyBEaXNhYmxlZC0gUmV0cmFpbi0gQ29tbUNsay0NCgkJCUV4dFN5bmNoLSBD bG9ja1BNLSBBdXRXaWREaXMtIEJXSW50LSBBdXRCV0ludC0NCgkJTG5rU3RhOglTcGVlZCAy LjVHVC9zLCBXaWR0aCB4MTYsIFRyRXJyLSBUcmFpbi0gU2xvdENsaysgRExBY3RpdmUtIEJX TWdtdC0gQUJXTWdtdC0NCg0KMDI6MDAuMCBFdGhlcm5ldCBjb250cm9sbGVyOiBNYXJ2ZWxs IFRlY2hub2xvZ3kgR3JvdXAgTHRkLiA4OEU4MDUzIFBDSS1FIEdpZ2FiaXQgRXRoZXJuZXQg Q29udHJvbGxlciAocmV2IDE5KQ0KCVN1YnN5c3RlbTogQVNVU1RlSyBDb21wdXRlciBJbmMu IE1hcnZlbGwgODhFODA1MyBHaWdhYml0IEV0aGVybmV0IGNvbnRyb2xsZXIgUENJZSAoQXN1 cykNCglDb250cm9sOiBJL08rIE1lbSsgQnVzTWFzdGVyKyBTcGVjQ3ljbGUtIE1lbVdJTlYt IFZHQVNub29wLSBQYXJFcnItIFN0ZXBwaW5nLSBTRVJSKyBGYXN0QjJCLSBEaXNJTlR4LQ0K CVN0YXR1czogQ2FwKyA2Nk1Iei0gVURGLSBGYXN0QjJCLSBQYXJFcnItIERFVlNFTD1mYXN0 ID5UQWJvcnQtIDxUQWJvcnQtIDxNQWJvcnQtID5TRVJSLSA8UEVSUi0gSU5UeC0NCglMYXRl bmN5OiAwLCBDYWNoZSBMaW5lIFNpemU6IDY0IGJ5dGVzDQoJSW50ZXJydXB0OiBwaW4gQSBy b3V0ZWQgdG8gSVJRIDE4DQoJUmVnaW9uIDA6IE1lbW9yeSBhdCBmZTlmYzAwMCAoNjQtYml0 LCBub24tcHJlZmV0Y2hhYmxlKQ0KCVJlZ2lvbiAyOiBJL08gcG9ydHMgYXQgYzgwMA0KCUV4 cGFuc2lvbiBST00gYXQgZmU5YzAwMDAgW2Rpc2FibGVkXQ0KCUNhcGFiaWxpdGllczogWzQ4 XSBQb3dlciBNYW5hZ2VtZW50IHZlcnNpb24gMg0KCQlGbGFnczogUE1FQ2xrLSBEU0ktIEQx KyBEMisgQXV4Q3VycmVudD0wbUEgUE1FKEQwKyxEMSssRDIrLEQzaG90KyxEM2NvbGQrKQ0K CQlTdGF0dXM6IEQwIFBNRS1FbmFibGUtIERTZWw9MCBEU2NhbGU9MSBQTUUtDQoJQ2FwYWJp bGl0aWVzOiBbNTBdIFZpdGFsIFByb2R1Y3QgRGF0YSA8Pz4NCglDYXBhYmlsaXRpZXM6IFs1 Y10gTVNJOiBNYXNrLSA2NGJpdCsgQ291bnQ9Mi8yIEVuYWJsZSsNCgkJQWRkcmVzczogMDAw MDAwMDBmZWUwMDAwMCAgRGF0YTogMDAzMg0KCUNhcGFiaWxpdGllczogW2UwXSBFeHByZXNz ICh2MSkgTGVnYWN5IEVuZHBvaW50LCBNU0kgMDANCgkJRGV2Q2FwOglNYXhQYXlsb2FkIDEy OCBieXRlcywgUGhhbnRGdW5jIDAsIExhdGVuY3kgTDBzIHVubGltaXRlZCwgTDEgdW5saW1p dGVkDQoJCQlFeHRUYWctIEF0dG5CdG4tIEF0dG5JbmQtIFB3ckluZC0gUkJFLSBGTFJlc2V0 LQ0KCQlEZXZDdGw6CVJlcG9ydCBlcnJvcnM6IENvcnJlY3RhYmxlLSBOb24tRmF0YWwtIEZh dGFsLSBVbnN1cHBvcnRlZC0NCgkJCVJseGRPcmQtIEV4dFRhZy0gUGhhbnRGdW5jLSBBdXhQ d3ItIE5vU25vb3AtDQoJCQlNYXhQYXlsb2FkIDEyOCBieXRlcywgTWF4UmVhZFJlcSA0MDk2 IGJ5dGVzDQoJCURldlN0YToJQ29yckVycisgVW5jb3JyRXJyKyBGYXRhbEVyci0gVW5zdXBw UmVxKyBBdXhQd3IrIFRyYW5zUGVuZC0NCgkJTG5rQ2FwOglQb3J0ICMzLCBTcGVlZCAyLjVH VC9zLCBXaWR0aCB4MSwgQVNQTSBMMHMsIExhdGVuY3kgTDAgPDI1Nm5zLCBMMSB1bmxpbWl0 ZWQNCgkJCUNsb2NrUE0tIFN1cHJpc2UtIExMQWN0UmVwLSBCd05vdC0NCgkJTG5rQ3RsOglB U1BNIERpc2FibGVkOyBSQ0IgMTI4IGJ5dGVzIERpc2FibGVkLSBSZXRyYWluLSBDb21tQ2xr LQ0KCQkJRXh0U3luY2gtIENsb2NrUE0tIEF1dFdpZERpcy0gQldJbnQtIEF1dEJXSW50LQ0K CQlMbmtTdGE6CVNwZWVkIDIuNUdUL3MsIFdpZHRoIHgxLCBUckVyci0gVHJhaW4tIFNsb3RD bGsrIERMQWN0aXZlLSBCV01nbXQtIEFCV01nbXQtDQoNCjA0OjEyLjAgRmlyZVdpcmUgKElF RUUgMTM5NCk6IFZJQSBUZWNobm9sb2dpZXMsIEluYy4gVlQ2MzA2IEZpcmUgSUkgSUVFRSAx Mzk0IE9IQ0kgTGluayBMYXllciBDb250cm9sbGVyIChyZXYgODApIChwcm9nLWlmIDEwIFtP SENJXSkNCglTdWJzeXN0ZW06IEFTVVNUZUsgQ29tcHV0ZXIgSW5jLiBBOFYvQThOL1A0UDgw MCBzZXJpZXMgbW90aGVyYm9hcmQNCglDb250cm9sOiBJL08rIE1lbSsgQnVzTWFzdGVyKyBT cGVjQ3ljbGUtIE1lbVdJTlYrIFZHQVNub29wLSBQYXJFcnItIFN0ZXBwaW5nLSBTRVJSKyBG YXN0QjJCLSBEaXNJTlR4LQ0KCVN0YXR1czogQ2FwKyA2Nk1Iei0gVURGLSBGYXN0QjJCLSBQ YXJFcnItIERFVlNFTD1tZWRpdW0gPlRBYm9ydC0gPFRBYm9ydC0gPE1BYm9ydC0gPlNFUlIt IDxQRVJSLSBJTlR4LQ0KCUxhdGVuY3k6IDY0ICg4MDAwbnMgbWF4KSwgQ2FjaGUgTGluZSBT aXplOiA2NCBieXRlcw0KCUludGVycnVwdDogcGluIEEgcm91dGVkIHRvIElSUSAxNg0KCVJl Z2lvbiAwOiBNZW1vcnkgYXQgZmVhZmU4MDAgKDMyLWJpdCwgbm9uLXByZWZldGNoYWJsZSkN CglSZWdpb24gMTogSS9PIHBvcnRzIGF0IGRjMDANCglDYXBhYmlsaXRpZXM6IFs1MF0gUG93 ZXIgTWFuYWdlbWVudCB2ZXJzaW9uIDINCgkJRmxhZ3M6IFBNRUNsay0gRFNJLSBEMS0gRDIr IEF1eEN1cnJlbnQ9MG1BIFBNRShEMC0sRDEtLEQyKyxEM2hvdCssRDNjb2xkKykNCgkJU3Rh dHVzOiBEMCBQTUUtRW5hYmxlLSBEU2VsPTAgRFNjYWxlPTAgUE1FLQ0KDQphbmdsZXBvaXNl IyB1c2JkZXN2YSAICBtbSwgbW0sIG1tLdnMgLXYNDQpDb250cm9sbGVyIC9kZXYvdXNiMDoN CmFkZHIgMTogZnVsbCBzcGVlZCwgc2VsZiBwb3dlcmVkLCBjb25maWcgMSwgT0hDSSByb290 IGh1YigweDAwMDApLCBBY2VyTGFicygweDAwMDApLCByZXYgMS4wMA0KIHBvcnQgMSBhZGRy IDI6IGZ1bGwgc3BlZWQsIHNlbGYgcG93ZXJlZCwgY29uZmlnIDEsIHByb2R1Y3QgMHgyMDQ2 KDB4MjA0NiksIHZlbmRvciAweDA0NTEoMHgwNDUxKSwgcmV2IDEuMjUNCiAgcG9ydCAxIHBv d2VyZWQNCiAgcG9ydCAyIHBvd2VyZWQNCiAgcG9ydCAzIHBvd2VyZWQNCiAgcG9ydCA0IHBv d2VyZWQNCiBwb3J0IDIgcG93ZXJlZA0KIHBvcnQgMyBwb3dlcmVkDQpDb250cm9sbGVyIC9k ZXYvdXNiMToNCmFkZHIgMTogZnVsbCBzcGVlZCwgc2VsZiBwb3dlcmVkLCBjb25maWcgMSwg T0hDSSByb290IGh1YigweDAwMDApLCBBY2VyTGFicygweDAwMDApLCByZXYgMS4wMA0KIHBv cnQgMSBwb3dlcmVkDQogcG9ydCAyIHBvd2VyZWQNCiBwb3J0IDMgcG93ZXJlZA0KQ29udHJv bGxlciAvZGV2L3VzYjI6DQphZGRyIDE6IGZ1bGwgc3BlZWQsIHNlbGYgcG93ZXJlZCwgY29u ZmlnIDEsIE9IQ0kgcm9vdCBodWIoMHgwMDAwKSwgQWNlckxhYnMoMHgwMDAwKSwgcmV2IDEu MDANCiBwb3J0IDEgcG93ZXJlZA0KIHBvcnQgMiBwb3dlcmVkDQogcG9ydCAzIHBvd2VyZWQN CkNvbnRyb2xsZXIgL2Rldi91c2IzOg0KYWRkciAxOiBoaWdoIHNwZWVkLCBzZWxmIHBvd2Vy ZWQsIGNvbmZpZyAxLCBFSENJIHJvb3QgaHViKDB4MDAwMCksIEFjZXJMYWJzKDB4MDAwMCks IHJldiAxLjAwDQogcG9ydCAxIHBvd2VyZWQNCiBwb3J0IDIgcG93ZXJlZA0KIHBvcnQgMyBw b3dlcmVkDQogcG9ydCA0IHBvd2VyZWQNCiBwb3J0IDUgcG93ZXJlZA0KIHBvcnQgNiBwb3dl cmVkDQogICAgWFhYIERFTEFZVSAgcG9ydCA3IGFkZHIgMjogaGlnaCBzcGVlZCwgc2VsZiBw b3dlcmVkLCBjb25maWcgMSwgcHJvZHVjdCAweDA2MDYoMHgwNjA2KSwgdmVuZG9yIDB4MDVl MygweDA1ZTMpLCByZXYgNy4wMg0KICBwb3J0IDEgcG93ZXJlZA0KICBwb3J0IDIgcG93ZXJl ZA0KICBwb3J0IDMgcG93ZXJlZA0KICBwb3J0IDQgcG93ZXJlZA0KIHBvcnQgOCBwb3dlcmVk DQphbmdsZXBvaXNlIyAgICAgWFhYIERFTEFZVSAICBtbSyBIRVJFIA0NChtbS2FuZ2xlcG9p c2UjIGVjaG8gVGhlIGlzc3VlIGlzIG5vdyBoYXBwZW5pbmcuDQ0KVGhlIGlzc3VlIGlzIG5v dyBoYXBwZW5pbmcuDQphbmdsZXBvaXNlIyBeRAgIZXhpdA0KClNjcmlwdCBkb25lIG9uIFR1 ZSBGZWIgMTAgMTg6MDY6NDAgMjAwOQo= --------------070207010404000705020605-- From owner-freebsd-stable@FreeBSD.ORG Tue Feb 10 18:57:41 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9F145106566C; Tue, 10 Feb 2009 18:57:41 +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 3D5478FC08; Tue, 10 Feb 2009 18:57:40 +0000 (UTC) (envelope-from rnoland@FreeBSD.org) Received: from [192.168.1.132] (adsl-1-207-86.bna.bellsouth.net [65.1.207.86]) (authenticated bits=0) by gizmo.2hip.net (8.14.3/8.14.3) with ESMTP id n1AIuvWB056516 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 10 Feb 2009 13:56:58 -0500 (EST) (envelope-from rnoland@FreeBSD.org) From: Robert Noland To: "Bruce M. Simpson" In-Reply-To: <4991C017.8080903@FreeBSD.org> References: <329181233306971@webmail57.yandex.ru> <985A59F2-20CC-4779-A000-018E52B5BFA9@jump-ing.de> <101781233319948@webmail36.yandex.ru> <4983A3AE.90804@FreeBSD.org> <498F901A.7000900@FreeBSD.org> <1234159237.23838.3.camel@ferret.2hip.net> <4990835A.3020303@FreeBSD.org> <1234208586.1524.17.camel@ferret.2hip.net> <4990BC99.1070108@FreeBSD.org> <1234246034.1524.27.camel@ferret.2hip.net> <4991C017.8080903@FreeBSD.org> Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-46oDHuVXdbKn3gLAcb1k" Organization: FreeBSD Date: Tue, 10 Feb 2009 13:57:26 -0500 Message-Id: <1234292252.1524.38.camel@ferret.2hip.net> Mime-Version: 1.0 X-Mailer: Evolution 2.24.3 FreeBSD GNOME Team Port X-Spam-Status: No, score=-0.8 required=5.0 tests=AWL,BAYES_00, MIME_QP_LONG_LINE, RCVD_IN_PBL, RCVD_IN_SORBS_DUL, RDNS_DYNAMIC autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on gizmo.2hip.net Cc: "S.N.Grigoriev" , Markus Hitter , freebsd-stable@freebsd.org Subject: Re: Unhappy Xorg upgrade X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Feb 2009 18:57:41 -0000 --=-46oDHuVXdbKn3gLAcb1k Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Tue, 2009-02-10 at 17:57 +0000, Bruce M. Simpson wrote: > Robert Noland wrote: > > ... > > Ok, lets try another test... There is a scanpci util in the > > libpciaccess port. We don't install it, but it does get built. Build > > the port and run scanpci -v as root from the console. That should poke > > all the pci devices on the box and tell you about them. See if that is > > able to trigger the issue. > > =20 >=20 > Well spotted. I saw this tool in "locate" output and was going to try it=20 > the other day, although I saw it didn't get installed, so assumed it was=20 > historical. >=20 > Yes, This immediately triggered the issue without even running X on a=20 > fresh boot. Ok, At least we know where the issue lies now. I'll try and look the code over again, but I behaves almost identically to the kernel routines I think. jhb@ wrote us a new ioctl to avoid doing most of this from userland, but it will be a while before we can count on it's existence and it doesn't support bios frobbing yet. Can you verify that pciconf -lvbc does not trigger the issue? robert. --=20 Robert Noland FreeBSD --=-46oDHuVXdbKn3gLAcb1k Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.10 (FreeBSD) iEUEABECAAYFAkmRzhYACgkQM4TrQ4qfROMBagCfTdI7UPNJuz+VnP6dvyghqXjW N3EAmKzUWZ91q7dM62Qi+IVGOdW1cls= =sBUa -----END PGP SIGNATURE----- --=-46oDHuVXdbKn3gLAcb1k-- From owner-freebsd-stable@FreeBSD.ORG Tue Feb 10 18:59:08 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BB06E10656EE for ; Tue, 10 Feb 2009 18:59:08 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from mail2.fluidhosting.com (mx22.fluidhosting.com [204.14.89.5]) by mx1.freebsd.org (Postfix) with ESMTP id 513F98FC20 for ; Tue, 10 Feb 2009 18:59:08 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: (qmail 23924 invoked by uid 399); 10 Feb 2009 18:59:05 -0000 Received: from localhost (HELO ?192.168.0.19?) (dougb@dougbarton.us@127.0.0.1) by localhost with ESMTPAM; 10 Feb 2009 18:59:05 -0000 X-Originating-IP: 127.0.0.1 X-Sender: dougb@dougbarton.us Message-ID: <4991CE7A.5010300@FreeBSD.org> Date: Tue, 10 Feb 2009 10:59:06 -0800 From: Doug Barton Organization: http://www.FreeBSD.org/ User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: =?ISO-8859-1?Q?Horst_G=FCnther_Burkhardt_III?= References: <1234258680.13304.26.camel@horst-tla> In-Reply-To: <1234258680.13304.26.camel@horst-tla> X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Cc: FreeBSD-STABLE Mailing List , FreeBSD PowerPC ML Subject: Re: [7-STABLE] failure during buildworld X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Feb 2009 18:59:09 -0000 Horst Gnther Burkhardt III wrote: > Hey everybody :) > > I'm having a small issue compiling 7-STABLE as checked out 24 hours ago > at the time of writing... during make -j4 buildworld, You need to repeat the build with a clean obj directory and no -j options to find the error. Doug -- This .signature sanitized for your protection From owner-freebsd-stable@FreeBSD.ORG Tue Feb 10 19:13:29 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6E27C106564A; Tue, 10 Feb 2009 19:13:29 +0000 (UTC) (envelope-from horst@sxemacs.org) Received: from mail05.syd.optusnet.com.au (mail05.syd.optusnet.com.au [211.29.132.186]) by mx1.freebsd.org (Postfix) with ESMTP id C95FF8FC1C; Tue, 10 Feb 2009 19:13:28 +0000 (UTC) (envelope-from horst@sxemacs.org) Received: from [220.237.124.212] (c220-237-124-212.farfl2.nsw.optusnet.com.au [220.237.124.212]) (authenticated sender horst.burkhardt) by mail05.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id n1AJDP4q002161; Wed, 11 Feb 2009 06:13:26 +1100 From: Horst =?ISO-8859-1?Q?G=FCnther?= Burkhardt III To: Doug Barton In-Reply-To: <4991CE7A.5010300@FreeBSD.org> References: <1234258680.13304.26.camel@horst-tla> <4991CE7A.5010300@FreeBSD.org> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-xU6MqPdFLTju+G3hE2DY" Date: Wed, 11 Feb 2009 06:14:48 +1100 Message-Id: <1234293288.13304.27.camel@horst-tla> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 Cc: FreeBSD-STABLE Mailing List , FreeBSD PowerPC ML Subject: Re: [7-STABLE] failure during buildworld X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Feb 2009 19:13:30 -0000 --=-xU6MqPdFLTju+G3hE2DY Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Tue, 2009-02-10 at 10:59 -0800, Doug Barton wrote: > Horst G=C3=BCnther Burkhardt III wrote: > > Hey everybody :)=20 > >=20 > > I'm having a small issue compiling 7-STABLE as checked out 24 hours ago > > at the time of writing... during make -j4 buildworld,=20 >=20 > You need to repeat the build with a clean obj directory and no -j > options to find the error. >=20 > Doug New log : it looks like libstdc++ :=20 mkdep -f .depend -a /usr/src/gnu/lib/libstdc ++/../../../contrib/libstdc ++/src/bitmap_allocator.cc /usr/src/gnu/lib/libstdc ++/../../../contrib/libstdc ++/src/pool_allocator.cc /usr/src/gnu/lib/libstdc ++/../../../contrib/libstdc ++/src/mt_allocator.cc /usr/src/gnu/lib/libstdc ++/../../../contrib/libstdc++/src/codecvt.cc /usr/src/gnu/lib/libstdc ++/../../../contrib/libstdc ++/src/compatibility.cc /usr/src/gnu/lib/libstdc ++/../../../contrib/libstdc++/src/complex_io.cc /usr/src/gnu/lib/libstdc ++/../../../contrib/libstdc++/src/ctype.cc /usr/src/gnu/lib/libstdc ++/../../../contrib/libstdc++/src/debug.cc /usr/src/gnu/lib/libstdc ++/../../../contrib/libstdc++/src/debug_list.cc /usr/src/gnu/lib/libstdc ++/../../../contrib/libstdc ++/src/functexcept.cc /usr/src/gnu/lib/libstdc ++/../../../contrib/libstdc++/src/globals_io.cc /usr/src/gnu/lib/libstdc ++/../../../contrib/libstdc++/src/ios.cc /usr/src/gnu/lib/libstdc ++/../../../contrib/libstdc ++/src/ios_failure.cc /usr/src/gnu/lib/libstdc ++/../../../contrib/libstdc++/src/ios_init.cc /usr/src/gnu/lib/libstdc ++/../../../contrib/libstdc++/src/ios_locale.cc /usr/src/gnu/lib/libstdc ++/../../../contrib/libstdc++/src/limits.cc /usr/src/gnu/lib/libstdc ++/../../../contrib/libstdc++/src/list.cc /usr/src/gnu/lib/libstdc ++/../../../contrib/libstdc++/src/locale.cc /usr/src/gnu/lib/libstdc ++/../../../contrib/libstdc ++/src/locale_init.cc /usr/src/gnu/lib/libstdc ++/../../../contrib/libstdc ++/src/locale_facets.cc /usr/src/gnu/lib/libstdc ++/../../../contrib/libstdc++/src/localename.cc /usr/src/gnu/lib/libstdc ++/../../../contrib/libstdc++/src/stdexcept.cc /usr/src/gnu/lib/libstdc ++/../../../contrib/libstdc++/src/strstream.cc /usr/src/gnu/lib/libstdc ++/../../../contrib/libstdc++/src/tree.cc /usr/src/gnu/lib/libstdc ++/../../../contrib/libstdc ++/src/allocator-inst.cc /usr/src/gnu/lib/libstdc ++/../../../contrib/libstdc ++/src/concept-inst.cc /usr/src/gnu/lib/libstdc ++/../../../contrib/libstdc ++/src/fstream-inst.cc /usr/src/gnu/lib/libstdc ++/../../../contrib/libstdc++/src/ext-inst.cc /usr/src/gnu/lib/libstdc ++/../../../contrib/libstdc++/src/ios-inst.cc /usr/src/gnu/lib/libstdc ++/../../../contrib/libstdc ++/src/iostream-inst.cc /usr/src/gnu/lib/libstdc ++/../../../contrib/libstdc ++/src/istream-inst.cc /usr/src/gnu/lib/libstdc ++/../../../contrib/libstdc++/src/istream.cc /usr/src/gnu/lib/libstdc ++/../../../contrib/libstdc ++/src/locale-inst.cc /usr/src/gnu/lib/libstdc ++/../../../contrib/libstdc++/src/misc-inst.cc /usr/src/gnu/lib/libstdc ++/../../../contrib/libstdc ++/src/ostream-inst.cc /usr/src/gnu/lib/libstdc ++/../../../contrib/libstdc ++/src/sstream-inst.cc /usr/src/gnu/lib/libstdc ++/../../../contrib/libstdc ++/src/streambuf-inst.cc /usr/src/gnu/lib/libstdc ++/../../../contrib/libstdc++/src/streambuf.cc /usr/src/gnu/lib/libstdc ++/../../../contrib/libstdc ++/src/string-inst.cc /usr/src/gnu/lib/libstdc ++/../../../contrib/libstdc ++/src/valarray-inst.cc /usr/src/gnu/lib/libstdc ++/../../../contrib/libstdc ++/src/wlocale-inst.cc /usr/src/gnu/lib/libstdc ++/../../../contrib/libstdc++/src/wstring-inst.cc atomicity.cc /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc ++/config/locale/generic/codecvt_members.cc /usr/src/gnu/lib/libstdc ++/../../../contrib/libstdc ++/config/locale/generic/collate_members.cc /usr/src/gnu/lib/libstdc ++/../../../contrib/libstdc ++/config/locale/darwin/ctype_members.cc /usr/src/gnu/lib/libstdc ++/../../../contrib/libstdc ++/config/locale/generic/messages_members.cc /usr/src/gnu/lib/libstdc ++/../../../contrib/libstdc ++/config/locale/generic/monetary_members.cc /usr/src/gnu/lib/libstdc ++/../../../contrib/libstdc ++/config/locale/generic/numeric_members.cc /usr/src/gnu/lib/libstdc ++/../../../contrib/libstdc ++/config/locale/generic/time_members.cc /usr/src/gnu/lib/libstdc ++/../../../contrib/libstdc ++/config/io/basic_file_stdio.cc /usr/src/gnu/lib/libstdc ++/../../../contrib/libstdc ++/config/locale/generic/c_locale.cc /usr/src/gnu/lib/libstdc ++/../../../contrib/libstdc++/libsupc ++/del_op.cc /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc ++/libsupc++/del_opnt.cc /usr/src/gnu/lib/libstdc ++/../../../contrib/libstdc++/libsupc ++/del_opv.cc /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc ++/libsupc++/del_opvnt.cc /usr/src/gnu/lib/libstdc ++/../../../contrib/libstdc++/libsupc ++/eh_alloc.cc /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc ++/libsupc++/eh_arm.cc /usr/src/gnu/lib/libstdc ++/../../../contrib/libstdc++/libsupc ++/eh_aux_runtime.cc /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc ++/libsupc++/eh_call.cc /usr/src/gnu/lib/libstdc ++/../../../contrib/libstdc++/libsupc ++/eh_catch.cc /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc ++/libsupc++/eh_exception.cc /usr/src/gnu/lib/libstdc ++/../../../contrib/libstdc++/libsupc ++/eh_globals.cc /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc ++/libsupc++/eh_personality.cc /usr/src/gnu/lib/libstdc ++/../../../contrib/libstdc++/libsupc ++/eh_term_handler.cc /usr/src/gnu/lib/libstdc ++/../../../contrib/libstdc++/libsupc ++/eh_terminate.cc /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc ++/libsupc++/eh_throw.cc /usr/src/gnu/lib/libstdc ++/../../../contrib/libstdc++/libsupc ++/eh_type.cc /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc ++/libsupc++/eh_unex_handler.cc /usr/src/gnu/lib/libstdc ++/../../../contrib/libstdc++/libsupc ++/guard.cc /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc ++/libsupc++/new_handler.cc /usr/src/gnu/lib/libstdc ++/../../../contrib/libstdc++/libsupc ++/new_op.cc /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc ++/libsupc++/new_opnt.cc /usr/src/gnu/lib/libstdc ++/../../../contrib/libstdc++/libsupc ++/new_opv.cc /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc ++/libsupc++/new_opvnt.cc /usr/src/gnu/lib/libstdc ++/../../../contrib/libstdc++/libsupc++/pure.cc /usr/src/gnu/lib/libstdc ++/../../../contrib/libstdc++/libsupc ++/tinfo.cc /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc ++/libsupc++/tinfo2.cc /usr/src/gnu/lib/libstdc ++/../../../contrib/libstdc++/libsupc++/vec.cc /usr/src/gnu/lib/libstdc ++/../../../contrib/libstdc++/libsupc++/vterminate.cc =20 In file included from /usr/src/gnu/lib/libstdc ++/../../../contrib/libstdc++/libsupc++/eh_alloc.cc:41: /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/libsupc ++/unwind-cxx.h:41:20: error: unwind.h: No such file or directory In file included from /usr/src/gnu/lib/libstdc ++/../../../contrib/libstdc++/libsupc++/eh_arm.cc:31: /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/libsupc ++/unwind-cxx.h:41:20: error: unwind.h: No such file or directory In file included from /usr/src/gnu/lib/libstdc ++/../../../contrib/libstdc++/libsupc++/eh_aux_runtime.cc:34: /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/libsupc ++/unwind-cxx.h:41:20: error: unwind.h: No such file or directory In file included from /usr/src/gnu/lib/libstdc ++/../../../contrib/libstdc++/libsupc++/eh_call.cc:33: /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/libsupc ++/unwind-cxx.h:41:20: error: unwind.h: No such file or directory /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/libsupc ++/eh_call.cc:37:23: error: unwind-pe.h: No such file or directory In file included from /usr/src/gnu/lib/libstdc ++/../../../contrib/libstdc++/libsupc++/eh_catch.cc:31: /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/libsupc ++/unwind-cxx.h:41:20: error: unwind.h: No such file or directory In file included from /usr/src/gnu/lib/libstdc ++/../../../contrib/libstdc++/libsupc++/eh_exception.cc:34: /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/libsupc ++/unwind-cxx.h:41:20: error: unwind.h: No such file or directory In file included from /usr/src/gnu/lib/libstdc ++/../../../contrib/libstdc++/libsupc++/eh_globals.cc:35: /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/libsupc ++/unwind-cxx.h:41:20: error: unwind.h: No such file or directory In file included from /usr/src/gnu/lib/libstdc ++/../../../contrib/libstdc++/libsupc++/eh_personality.cc:33: /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/libsupc ++/unwind-cxx.h:41:20: error: unwind.h: No such file or directory /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/libsupc ++/eh_personality.cc:41:23: error: unwind-pe.h: No such file or directory In file included from /usr/src/gnu/lib/libstdc ++/../../../contrib/libstdc++/libsupc++/eh_term_handler.cc:31: /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/libsupc ++/unwind-cxx.h:41:20: error: unwind.h: No such file or directory In file included from /usr/src/gnu/lib/libstdc ++/../../../contrib/libstdc++/libsupc++/eh_terminate.cc:34: /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/libsupc ++/unwind-cxx.h:41:20: error: unwind.h: No such file or directory In file included from /usr/src/gnu/lib/libstdc ++/../../../contrib/libstdc++/libsupc++/eh_throw.cc:31: /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/libsupc ++/unwind-cxx.h:41:20: error: unwind.h: No such file or directory In file included from /usr/src/gnu/lib/libstdc ++/../../../contrib/libstdc++/libsupc++/eh_type.cc:33: /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/libsupc ++/unwind-cxx.h:41:20: error: unwind.h: No such file or directory In file included from /usr/src/gnu/lib/libstdc ++/../../../contrib/libstdc++/libsupc++/eh_unex_handler.cc:30: /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/libsupc ++/unwind-cxx.h:41:20: error: unwind.h: No such file or directory In file included from /usr/src/gnu/lib/libstdc ++/../../../contrib/libstdc++/libsupc++/pure.cc:32: /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/libsupc ++/unwind-cxx.h:41:20: error: unwind.h: No such file or directory In file included from /usr/src/gnu/lib/libstdc ++/../../../contrib/libstdc++/libsupc++/vec.cc:37: /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/libsupc ++/unwind-cxx.h:41:20: error: unwind.h: No such file or directory mkdep: compile failed *** Error code 1 Stop in /usr/src/gnu/lib/libstdc++. *** Error code 1 Stop in /usr/src/gnu/lib. *** 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. [ bsdbox ] [ root ] [ /usr/src ] =3D=3D>=20 --=-xU6MqPdFLTju+G3hE2DY Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEABECAAYFAkmR0igACgkQRtTtv0BbTe6nXgCgheY8eofifn0zg5ac7fEDDYz7 niMAn3Mnj9IFc8HZKwguIH61wqbsCXjg =xRUV -----END PGP SIGNATURE----- --=-xU6MqPdFLTju+G3hE2DY-- From owner-freebsd-stable@FreeBSD.ORG Tue Feb 10 19:16:31 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C9EDA1065672 for ; Tue, 10 Feb 2009 19:16:31 +0000 (UTC) (envelope-from danallen46@airwired.net) Received: from mail.utahbroadband.com (mail.utahbroadband.com [204.14.20.91]) by mx1.freebsd.org (Postfix) with ESMTP id 908858FC1C for ; Tue, 10 Feb 2009 19:16:31 +0000 (UTC) (envelope-from danallen46@airwired.net) Received: (qmail 20210 invoked by uid 89); 10 Feb 2009 19:01:56 -0000 Received: from unknown (HELO ?192.168.0.16?) (danallen46@airwired.net@66.29.174.6) by 0 with ESMTPA; 10 Feb 2009 19:01:56 -0000 Message-Id: From: Dan Allen To: freebsd-stable@freebsd.org Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Tue, 10 Feb 2009 12:16:28 -0700 X-Mailer: Apple Mail (2.930.3) Subject: x48 display messed up with Xorg 7.4 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Feb 2009 19:16:32 -0000 One of my favorite little apps is the HP48 calculator emulator called x48. In the recent upgrade to Xorg 7.4 the screen on the calculator is completely screwed up - nothing appears as it should. I am on a Toshiba Satellite U205 with Intel i810 graphics running 7.1- STABLE. I did manage to get Firefox working on 7.4, but this graphics issue still was there so I went back to Xorg 7.3 and everything works again. Has anyone else seen this? Dan From owner-freebsd-stable@FreeBSD.ORG Tue Feb 10 19:25:59 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B288B1065674 for ; Tue, 10 Feb 2009 19:25:59 +0000 (UTC) (envelope-from horst@sxemacs.org) Received: from mail07.syd.optusnet.com.au (mail07.syd.optusnet.com.au [211.29.132.188]) by mx1.freebsd.org (Postfix) with ESMTP id 2DBF58FC0C for ; Tue, 10 Feb 2009 19:25:58 +0000 (UTC) (envelope-from horst@sxemacs.org) Received: from [220.237.124.212] (c220-237-124-212.farfl2.nsw.optusnet.com.au [220.237.124.212]) (authenticated sender horst.burkhardt) by mail07.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id n1AJOjfW021199; Wed, 11 Feb 2009 06:24:45 +1100 From: Horst =?ISO-8859-1?Q?G=FCnther?= Burkhardt III To: Dan Allen , FreeBSD-STABLE Mailing List In-Reply-To: References: Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-hxt+31FPZ7tG3HJi+Xcp" Date: Wed, 11 Feb 2009 06:26:07 +1100 Message-Id: <1234293967.13304.30.camel@horst-tla> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 Cc: Subject: Re: x48 display messed up with Xorg 7.4 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Feb 2009 19:26:00 -0000 --=-hxt+31FPZ7tG3HJi+Xcp Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Tue, 2009-02-10 at 12:16 -0700, Dan Allen wrote: > One of my favorite little apps is the HP48 calculator emulator called =20 > x48. >=20 > In the recent upgrade to Xorg 7.4 the screen on the calculator is =20 > completely screwed up - nothing appears as it should. >=20 > I am on a Toshiba Satellite U205 with Intel i810 graphics running 7.1-=20 > STABLE. >=20 > I did manage to get Firefox working on 7.4, but this graphics issue =20 > still was there so I went back to Xorg 7.3 and everything works again. >=20 > Has anyone else seen this? >=20 > Dan Hi :) I personally suggest nonpareil, it works exceedingly well. It's unfortunate to say that I have to use it as my REAL hp calc no longer works :( :p -- Horst. --=-hxt+31FPZ7tG3HJi+Xcp Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEABECAAYFAkmR1M8ACgkQRtTtv0BbTe50+ACePiSQKjVFjiMAjxbEQ9GvnsUd 2mYAn2bZKGbRup8Jv8/q0dQj4qrvcPK0 =psHM -----END PGP SIGNATURE----- --=-hxt+31FPZ7tG3HJi+Xcp-- From owner-freebsd-stable@FreeBSD.ORG Tue Feb 10 20:16:19 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4E65B1065675; Tue, 10 Feb 2009 20:16:19 +0000 (UTC) (envelope-from andreast-list@fgznet.ch) Received: from smtp.fgznet.ch (mail.fgznet.ch [81.92.96.47]) by mx1.freebsd.org (Postfix) with ESMTP id BE7BE8FC0A; Tue, 10 Feb 2009 20:16:18 +0000 (UTC) (envelope-from andreast-list@fgznet.ch) Received: from wolfram.andreas.nets ([91.190.8.131]) by smtp.fgznet.ch (8.13.8/8.13.8/Submit_SMTPAUTH) with ESMTP id n1AK3rIN038962; Tue, 10 Feb 2009 21:03:54 +0100 (CET) (envelope-from andreast-list@fgznet.ch) Message-ID: <4991DDA9.7090008@fgznet.ch> Date: Tue, 10 Feb 2009 21:03:53 +0100 From: Andreas Tobler User-Agent: Thunderbird 2.0.0.19 (Macintosh/20081209) MIME-Version: 1.0 To: =?ISO-8859-1?Q?Horst_G=FCnther_Burkhardt_III?= References: <1234258680.13304.26.camel@horst-tla> In-Reply-To: <1234258680.13304.26.camel@horst-tla> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Scanned-By: MIMEDefang 2.64 on 81.92.96.47 Cc: FreeBSD-STABLE Mailing List , FreeBSD PowerPC ML Subject: Re: [7-STABLE] failure during buildworld X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Feb 2009 20:16:20 -0000 Horst Gnther Burkhardt III wrote: > (also, why doesn't make buildworld pick up from where it left off?) I think this intentional, but you can pass -DNO_CLEAN to your make command and buildworld should continue where it failed. make -DNO_CLEAN buildworld Andreas From owner-freebsd-stable@FreeBSD.ORG Wed Feb 11 14:55:56 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B20D81065675 for ; Wed, 11 Feb 2009 14:55:56 +0000 (UTC) (envelope-from tevans.uk@googlemail.com) Received: from mail-ew0-f21.google.com (mail-ew0-f21.google.com [209.85.219.21]) by mx1.freebsd.org (Postfix) with ESMTP id 15CF48FC08 for ; Wed, 11 Feb 2009 14:55:55 +0000 (UTC) (envelope-from tevans.uk@googlemail.com) Received: by ewy14 with SMTP id 14so211360ewy.19 for ; Wed, 11 Feb 2009 06:55:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:received:received:subject:from:to:content-type :date:message-id:mime-version:x-mailer:content-transfer-encoding; bh=hyXBjgK5BebH5xfUsIIUBjdUcpAmJAkEuGd1A7nwKfc=; b=ffgNv6tKdwsUOY48wxcfDFRbfu0t6ma/G6q5fvkvgEegLTFG67fwQtte3rTyvEgOFz 85QrBqxOzVptfuGkqznJuWH8r4QHSo/ukqydjDechd9mukkTVGtyz0yAwaWajX2PGAVz lpPPRI5z7xgo6Ia7PF8h4u+vlyxncWrJkxyqI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=subject:from:to:content-type:date:message-id:mime-version:x-mailer :content-transfer-encoding; b=jskPx6ELvgl+J9eYXl3uK/C2kwKt00H51VidWzWMAj1p3ofp0DIYnmYQ/5n8p2mW8O ObPC6SXrQj8/jKulAVngM3GAA2zxtZ0Bf6l2JzcGcwxi152y+sY1EXsw9G84PEN8V+vu e/kF1nLDzAkMExw/h4bIhTmElaMRus6cnMogQ= Received: by 10.210.29.17 with SMTP id c17mr772124ebc.187.1234362169619; Wed, 11 Feb 2009 06:22:49 -0800 (PST) Received: from ?127.0.0.1? (87-194-39-182.bethere.co.uk [87.194.39.182]) by mx.google.com with ESMTPS id u14sm7463924gvf.7.2009.02.11.06.22.48 (version=SSLv3 cipher=RC4-MD5); Wed, 11 Feb 2009 06:22:48 -0800 (PST) From: Tom Evans To: freebsd-stable@freebsd.org Content-Type: text/plain Date: Wed, 11 Feb 2009 14:24:17 +0000 Message-Id: <1234362257.2224.10.camel@strangepork.mintel.co.uk> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Subject: Page fault while in kernel mode X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Feb 2009 14:55:57 -0000 Hi all. I got this panic when our SMB server moved hostname. I still had the drives mounted, so I wondered what would happen if I ls'ed the mount point ('Doctor it hurts when I do this' 'Dont do that then..'). I'm running i386 RELENG_7 from mid October, so it is more than possible that this has already been fixed, but best to report it as well. I still have the vmcore if anyone wants more info from it. Cheers Tom FreeBSD strangepork.mintel.co.uk 7.1-PRERELEASE FreeBSD 7.1-PRERELEASE #0: Wed Oct 22 02:25:56 BST 2008 root@strangepork.mintel.co.uk:/usr/FreeBSD/RELENG_7/obj/usr/FreeBSD/RELENG_7/src/sys/STRANGEPORK i386 > # kgdb /usr/obj/usr/FreeBSD/RELENG_7/src/sys/STRANGEPORK/kernel.debug /var/crash/vmcore.1 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 "i386-marcel-freebsd"... Unread portion of the kernel message buffer: kernel trap 12 with interrupts disabled Fatal trap 12: page fault while in kernel mode cpuid = 0; apic id = 00 fault virtual address = 0x18 fault code = supervisor read, page not present instruction pointer = 0x20:0xc0817385 stack pointer = 0x28:0xe8276adc frame pointer = 0x28:0xe8276af8 code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags = resume, IOPL = 0 current process = 1032 (smbiod0) trap number = 12 panic: page fault cpuid = 0 Uptime: 20d23h21m41s Physical memory: 1992 MB Dumping 314 MB: 299 283 267 251 235 219 203 187 171 155 139 123 107 91 75 59 43 27 11 Reading symbols from /boot/kernel/snd_hda.ko...done. Loaded symbols for /boot/kernel/snd_hda.ko Reading symbols from /boot/kernel/sound.ko...Reading symbols from /boot/kernel/sound.ko.symbols...done. done. Loaded symbols for /boot/kernel/sound.ko Reading symbols from /boot/modules/nvidia.ko...done. Loaded symbols for /boot/modules/nvidia.ko Reading symbols from /boot/kernel/linux.ko...Reading symbols from /boot/kernel/linux.ko.symbols...done. done. Loaded symbols for /boot/kernel/linux.ko Reading symbols from /boot/kernel/acpi.ko...Reading symbols from /boot/kernel/acpi.ko.symbols...done. done. Loaded symbols for /boot/kernel/acpi.ko Reading symbols from /boot/kernel/linprocfs.ko...Reading symbols from /boot/kernel/linprocfs.ko.symbols...done. done. Loaded symbols for /boot/kernel/linprocfs.ko Reading symbols from /boot/kernel/smbfs.ko...Reading symbols from /boot/kernel/smbfs.ko.symbols...done. done. Loaded symbols for /boot/kernel/smbfs.ko Reading symbols from /boot/kernel/libiconv.ko...Reading symbols from /boot/kernel/libiconv.ko.symbols...done. done. Loaded symbols for /boot/kernel/libiconv.ko Reading symbols from /boot/kernel/libmchain.ko...Reading symbols from /boot/kernel/libmchain.ko.symbols...done. done. Loaded symbols for /boot/kernel/libmchain.ko Reading symbols from /boot/kernel/nullfs.ko...Reading symbols from /boot/kernel/nullfs.ko.symbols...done. done. Loaded symbols for /boot/kernel/nullfs.ko Reading symbols from /boot/kernel/fdescfs.ko...Reading symbols from /boot/kernel/fdescfs.ko.symbols...done. done. Loaded symbols for /boot/kernel/fdescfs.ko #0 doadump () at pcpu.h:196 196 pcpu.h: No such file or directory. in pcpu.h (kgdb) bt full #0 doadump () at pcpu.h:196 No locals. #1 0xc07e2047 in boot (howto=260) at /usr/FreeBSD/RELENG_7/src/sys/kern/kern_shutdown.c:418 _giantcnt = Variable "_giantcnt" is not available. (kgdb) bt #0 doadump () at pcpu.h:196 #1 0xc07e2047 in boot (howto=260) at /usr/FreeBSD/RELENG_7/src/sys/kern/kern_shutdown.c:418 #2 0xc07e2319 in panic (fmt=Variable "fmt" is not available. ) at /usr/FreeBSD/RELENG_7/src/sys/kern/kern_shutdown.c:574 #3 0xc0b1b45c in trap_fatal (frame=0xe8276a9c, eva=24) at /usr/FreeBSD/RELENG_7/src/sys/i386/i386/trap.c:939 #4 0xc0b1bdcf in trap (frame=0xe8276a9c) at /usr/FreeBSD/RELENG_7/src/sys/i386/i386/trap.c:320 #5 0xc0b028fb in calltrap () at /usr/FreeBSD/RELENG_7/src/sys/i386/i386/exception.s:159 #6 0xc0817385 in turnstile_broadcast (ts=0x0, queue=0) at /usr/FreeBSD/RELENG_7/src/sys/kern/subr_turnstile.c:836 #7 0xc07d4b12 in _mtx_unlock_sleep (m=0xc6457494, opts=0, file=0xc631c718 "/usr/FreeBSD/RELENG_7/src/sys/modules/smbfs/../../netsmb/smb_iod.c", line=97) at /usr/FreeBSD/RELENG_7/src/sys/kern/kern_mutex.c:619 #8 0xc07d4e72 in _mtx_unlock_flags (m=0xc6457494, opts=0, file=0xc631c718 "/usr/FreeBSD/RELENG_7/src/sys/modules/smbfs/../../netsmb/smb_iod.c", line=97) at /usr/FreeBSD/RELENG_7/src/sys/kern/kern_mutex.c:210 #9 0xc630fb73 in smb_iod_invrq (iod=Variable "iod" is not available. ) at /usr/FreeBSD/RELENG_7/src/sys/modules/smbfs/../../netsmb/smb_iod.c:97 #10 0xc6310d57 in smb_iod_addrq (rqp=0xc6457400) at /usr/FreeBSD/RELENG_7/src/sys/modules/smbfs/../../netsmb/smb_iod.c:424 #11 0xc630d28c in smb_rq_enqueue (rqp=0xc6457400) at /usr/FreeBSD/RELENG_7/src/sys/modules/smbfs/../../netsmb/smb_rq.c:193 #12 0xc630d6d8 in smb_rq_simple (rqp=0xc6457400) at /usr/FreeBSD/RELENG_7/src/sys/modules/smbfs/../../netsmb/smb_rq.c:174 #13 0xc630b9e4 in smb_smb_treeconnect (ssp=0xc5ee6100, scred=0xc5e9b4c4) at /usr/FreeBSD/RELENG_7/src/sys/modules/smbfs/../../netsmb/smb_smb.c:561 #14 0xc63108b8 in smb_iod_thread (arg=0xc5e9b480) at /usr/FreeBSD/RELENG_7/src/sys/modules/smbfs/../../netsmb/smb_iod.c:212 #15 0xc07be9a9 in fork_exit (callout=0xc63105c0 , arg=0xc5e9b480, frame=0xe8276d38) at /usr/FreeBSD/RELENG_7/src/sys/kern/kern_fork.c:804 #16 0xc0b02970 in fork_trampoline () at /usr/FreeBSD/RELENG_7/src/sys/i386/i386/exception.s:264 (kgdb) From owner-freebsd-stable@FreeBSD.ORG Wed Feb 11 15:18:15 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5E65F1065673 for ; Wed, 11 Feb 2009 15:18:15 +0000 (UTC) (envelope-from om-lists-bsd@omx.ch) Received: from ibox.insign.ch (ibox.insign.ch [195.134.143.207]) by mx1.freebsd.org (Postfix) with SMTP id C67A38FC12 for ; Wed, 11 Feb 2009 15:18:14 +0000 (UTC) (envelope-from om-lists-bsd@omx.ch) Received: (qmail 21421 invoked from network); 11 Feb 2009 14:51:32 -0000 Received: from [192.168.1.170] ([80.254.166.203]) by ibox.insign.ch ([195.134.143.207]) with ESMTP via TCP; 11 Feb 2009 14:51:32 -0000 From: Olivier Mueller To: freebsd-stable@freebsd.org, freebsd-hardware@freebsd.org Content-Type: text/plain Date: Wed, 11 Feb 2009 15:51:31 +0100 Message-Id: <1234363891.15909.35.camel@ompc.insign.local> Mime-Version: 1.0 X-Mailer: Evolution 2.24.1.1 Content-Transfer-Encoding: 7bit Cc: Subject: poweredge 1850 won't boot 7.1? maybe LSI-related : amr0: adapter is busy X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Feb 2009 15:18:15 -0000 Hello, This afternoon I wanted to upgrade to 7.1 two good old dell PowerEdge servers which were running FreeBSD 6.x. It went fine and quickly on the poweredge 1950, but it failed completely on the poweredge 1850. Facts: - boot cd and setup / operation of freebsd 6.x or 7.0 is fine Message log abstract: $ uname -v FreeBSD 7.0-RELEASE-p7 #0: Sun Dec 21 08:31:52 UTC 2008 root@amd64-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC $ dmesg|grep amr amr0: mem 0xd80f0000-0xd80fffff,0xdfde0000-0xdfdfffff irq 46 at device 14.0 on pci2 amr0: Using 64-bit DMA amr0: [ITHREAD] amr0: delete logical drives supported by controller amr0: Firmware 521X, BIOS H430, 256MB RAM amr0: delete logical drives supported by controller amrd0: on amr0 amrd0: 69880MB (143114240 sectors) RAID 1 (optimal) Trying to mount root from ufs:/dev/amrd0s1a - boot cd of 7.1 fails because the installed doesn't see any harddisk. Message log abstract: amr0: adapter is busy amr0: adapter is busy amr0: delete logical drives supported by controller I also tried to setup 7.0, and then upgrade to 7.1 with freebsd-update, but then it fails exactly like with the 7.1 boot CD (7.1-RELEASE-amd64-disc1.iso). Screenshot: http://omx.ch/om/stuff/pe1850bsd71error.jpg BIOS Message about the Controller on system startup: PowerEdge Expandable RAID COntroller BIOS, (c) 2006 LSI Logic Corporation I'm not sure what I can try next... I'd still like to be able to run 7.1 on this host as well as on several other old but still fine 1850. Is my system simply too old? Why is my adapter "busy" under 7.1? What would you try? I checked the relnotes as well, but saw nothing helpful about my problem there. regards & thanks in advance for any feedback, Olivier From owner-freebsd-stable@FreeBSD.ORG Wed Feb 11 15:54:08 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0ABF91065675; Wed, 11 Feb 2009 15:54:08 +0000 (UTC) (envelope-from lavalamp@spiritual-machines.org) Received: from mail.digitalfreaks.org (mail.digitalfreaks.org [216.151.95.156]) by mx1.freebsd.org (Postfix) with ESMTP id CE1078FC14; Wed, 11 Feb 2009 15:54:07 +0000 (UTC) (envelope-from lavalamp@spiritual-machines.org) Received: from localhost (localhost [127.0.0.1]) by mail.digitalfreaks.org (Postfix) with ESMTP id 53DBE797826; Wed, 11 Feb 2009 10:38:32 -0500 (EST) Received: from mail.digitalfreaks.org ([127.0.0.1]) by localhost (mail.digitalfreaks.org [127.0.0.1]) (amavisd-maia, port 10024) with ESMTP id 65381-48; Wed, 11 Feb 2009 10:38:30 -0500 (EST) Received: from [192.168.2.170] (pr40.pitbpa0.pub.collaborativefusion.com [206.210.89.202]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mail.digitalfreaks.org (Postfix) with ESMTPSA id 8DE60797829; Wed, 11 Feb 2009 10:38:30 -0500 (EST) From: "Brian A. Seklecki" To: Olivier Mueller In-Reply-To: <1234363891.15909.35.camel@ompc.insign.local> References: <1234363891.15909.35.camel@ompc.insign.local> Content-Type: text/plain Date: Wed, 11 Feb 2009 10:38:29 -0500 Message-Id: <1234366709.3500.62.camel@ingress.ws.pitbpa0.priv.collaborativefusion.com> Mime-Version: 1.0 X-Mailer: Evolution 2.24.2 (2.24.2-1.fc10) Content-Transfer-Encoding: 7bit X-Virus-Scanned: Maia Mailguard 1.0.2a mail.digitalfreaks Cc: spolyack@gmail.com, freebsd-stable@freebsd.org, freebsd-hardware@freebsd.org Subject: Re: poweredge 1850 won't boot 7.1? maybe LSI-related : amr0: adapter is busy X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Feb 2009 15:54:08 -0000 On Wed, 2009-02-11 at 15:51 +0100, Olivier Mueller wrote: > Hello, > This afternoon I wanted to upgrade to 7.1 two good old dell PowerEdge > servers which were running FreeBSD 6.x. It went fine and quickly on the There's already discussion about this in the archives. We're aware and working on it. Set: /boo/loader.conf kern.cam.scsi_delay=20000 As a work-around for now. Tracking the megarc memory corruption (and general amr(4) problems with the PERC4) at: http://www.freebsd.org/cgi/query-pr.cgi?pr=128082 ~BAS > poweredge 1950, but it failed completely on the poweredge 1850. > > Facts: > > - boot cd and setup / operation of freebsd 6.x or 7.0 is fine > Message log abstract: > $ uname -v > FreeBSD 7.0-RELEASE-p7 #0: Sun Dec 21 08:31:52 UTC 2008 root@amd64-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC > $ dmesg|grep amr > amr0: mem 0xd80f0000-0xd80fffff,0xdfde0000-0xdfdfffff irq 46 at device 14.0 on pci2 > amr0: Using 64-bit DMA > amr0: [ITHREAD] > amr0: delete logical drives supported by controller > amr0: Firmware 521X, BIOS H430, 256MB RAM > amr0: delete logical drives supported by controller > amrd0: on amr0 > amrd0: 69880MB (143114240 sectors) RAID 1 (optimal) > Trying to mount root from ufs:/dev/amrd0s1a > > - boot cd of 7.1 fails because the installed doesn't see any harddisk. > Message log abstract: > amr0: adapter is busy > amr0: adapter is busy > amr0: delete logical drives supported by controller > > > I also tried to setup 7.0, and then upgrade to 7.1 with freebsd-update, > but then it fails exactly like with the 7.1 boot CD > (7.1-RELEASE-amd64-disc1.iso). Screenshot: > http://omx.ch/om/stuff/pe1850bsd71error.jpg > > BIOS Message about the Controller on system startup: > PowerEdge Expandable RAID COntroller BIOS, (c) 2006 LSI Logic > Corporation > > I'm not sure what I can try next... I'd still like to be able to run > 7.1 on this host as well as on several other old but still fine 1850. Is > my system simply too old? Why is my adapter "busy" under 7.1? What > would you try? I checked the relnotes as well, but saw nothing helpful > about my problem there. > > regards & thanks in advance for any feedback, > Olivier > > > _______________________________________________ > freebsd-hardware@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hardware > To unsubscribe, send any mail to "freebsd-hardware-unsubscribe@freebsd.org" From owner-freebsd-stable@FreeBSD.ORG Wed Feb 11 16:39:09 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 31DE3106566B for ; Wed, 11 Feb 2009 16:39:09 +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 9A61C8FC08 for ; Wed, 11 Feb 2009 16:39:08 +0000 (UTC) (envelope-from gerrit@pmp.uni-hannover.de) 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 n1BGBBZg010686 for ; Wed, 11 Feb 2009 17:11:12 +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 EA3764F for ; Wed, 11 Feb 2009 17:11:10 +0100 (CET) Date: Wed, 11 Feb 2009 17:11:10 +0100 From: Gerrit =?ISO-8859-1?Q?K=FChn?= To: freebsd-stable@freebsd.org Message-Id: <20090211171110.a8217734.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.4.8 (GTK+ 2.12.11; i386-portbld-freebsd7.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-PMX-Version: 5.5.2.363555, Antispam-Engine: 2.6.1.350677, Antispam-Data: 2009.2.11.152513 Subject: zfs crashes with nfs and snapshots X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Feb 2009 16:39:09 -0000 Hi folks, I just saw one of my FreeBSD servers (7.0-stable of June 2008) crash while trying to access the .zfs snapshot directory via a nfs client machine. The server got a page fault caused by the nfsd process. It wasn't even able to dump the kernel image anymore. Resetting the machine it first appeared to come back fine, but shortly before the login prompt the nfsd let it crash hard again the same way as before. Then I booted single user, fscked the ufs partitions by hand and had to re-import the zpool with -f. After that I did another reboot, whereupon everything was fine again. As I need that machine I'm a bit unwilling to try accessing the snapshot directory again via nfs right now. :-) So here are some questions before I do anything else: - Did anyone else already see this behaviour? - Is there something wrong with accessing the snapshot directory via nfs? - Does zfs stability profit from an update to a recent -stable? Any answers or further thoughts/hints on this are very welcome. cu Gerrit From owner-freebsd-stable@FreeBSD.ORG Wed Feb 11 17:55:15 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 34047106566C for ; Wed, 11 Feb 2009 17:55:15 +0000 (UTC) (envelope-from jh@saunalahti.fi) Received: from gw03.mail.saunalahti.fi (gw03.mail.saunalahti.fi [195.197.172.111]) by mx1.freebsd.org (Postfix) with ESMTP id E93418FC15 for ; Wed, 11 Feb 2009 17:55:14 +0000 (UTC) (envelope-from jh@saunalahti.fi) Received: from a91-153-125-115.elisa-laajakaista.fi (a91-153-125-115.elisa-laajakaista.fi [91.153.125.115]) by gw03.mail.saunalahti.fi (Postfix) with ESMTP id C7B1121692B; Wed, 11 Feb 2009 19:55:11 +0200 (EET) Date: Wed, 11 Feb 2009 19:55:11 +0200 From: Jaakko Heinonen To: Gerrit =?utf-8?B?S8O8aG4=?= Message-ID: <20090211175511.GA38986@a91-153-125-115.elisa-laajakaista.fi> References: <20090211171110.a8217734.gerrit@pmp.uni-hannover.de> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20090211171110.a8217734.gerrit@pmp.uni-hannover.de> User-Agent: Mutt/1.5.18 (2008-05-17) Cc: freebsd-stable@freebsd.org Subject: Re: zfs crashes with nfs and snapshots X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Feb 2009 17:55:15 -0000 On 2009-02-11, Gerrit Kühn wrote: > I just saw one of my FreeBSD servers (7.0-stable of June 2008) crash while > trying to access the .zfs snapshot directory via a nfs client machine. This is likely the issue described in this message: http://lists.freebsd.org/pipermail/freebsd-fs/2008-October/005217.html The nfs fix has been committed to head and stable/7 (7.1-RELEASE has the fix). The fix prevents system from panicing but you still can't access the snapshot directory with readdirplus enabled nfs clients. As a workaround you can disable readdirplus support if your nfs client allows it. -- Jaakko From owner-freebsd-stable@FreeBSD.ORG Wed Feb 11 17:58:12 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5297A106564A for ; Wed, 11 Feb 2009 17:58:12 +0000 (UTC) (envelope-from ekarkkai@pp.htv.fi) Received: from smtp4.welho.com (smtp4.welho.com [213.243.153.38]) by mx1.freebsd.org (Postfix) with ESMTP id 0549B8FC1A for ; Wed, 11 Feb 2009 17:58:11 +0000 (UTC) (envelope-from ekarkkai@pp.htv.fi) Received: from zero.my.domain (cs181103178.pp.htv.fi [82.181.103.178]) by smtp4.welho.com (Postfix) with ESMTP id 3E8915BC039 for ; Wed, 11 Feb 2009 19:29:58 +0200 (EET) Received: from thunderbolt.my.domain (thunderbolt.my.domain [10.192.168.30]) by zero.my.domain (8.14.3/8.14.3) with ESMTP id n1BHTvPx014122 for ; Wed, 11 Feb 2009 19:29:57 +0200 (EET) (envelope-from ekarkkai@pp.htv.fi) Received: from thunderbolt.my.domain (localhost [127.0.0.1]) by thunderbolt.my.domain (8.14.3/8.14.3) with ESMTP id n1BHTvd6001787 for ; Wed, 11 Feb 2009 19:29:57 +0200 (EET) (envelope-from ejk@thunderbolt.my.domain) Received: (from ejk@localhost) by thunderbolt.my.domain (8.14.3/8.14.3/Submit) id n1BHTvKR001786 for freebsd-stable@freebsd.org; Wed, 11 Feb 2009 19:29:57 +0200 (EET) (envelope-from ejk) Date: Wed, 11 Feb 2009 19:29:57 +0200 From: Esa Karkkainen To: freebsd-stable@freebsd.org Message-ID: <20090211172957.GA1342@pp.htv.fi> Mail-Followup-To: Esa Karkkainen , 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 Subject: Re: x48 display messed up with Xorg 7.4 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Feb 2009 17:58:12 -0000 On Tue, Feb 10, 2009 at 12:16:28PM -0700, Dan Allen wrote: > In the recent upgrade to Xorg 7.4 the screen on the calculator is > completely screwed up - nothing appears as it should. I get a garbled x48 "LCD" output and calculator will not turn on. > I am on a Toshiba Satellite U205 with Intel i810 graphics running 7.1- > STABLE. I'm on Shuttle SN45G with MGA 400 display adapter, running 6.4-RELEASE-p3. > Has anyone else seen this? I've got screenshots at: http://koti.welho.com/ekarkkai/x48_snap_1.jpg http://koti.welho.com/ekarkkai/x48_snap_2.jpg I've moved the x48 window to right and screen has several lines of blinking green dots, which are *not* visible at _1.jpg and are visible at the _2.jpg. -- "In the beginning the Universe was created. This has made a lot of people very angry and been widely regarded as a bad move." -- Douglas Adams 1952 - 2001 From owner-freebsd-stable@FreeBSD.ORG Wed Feb 11 20:46:29 2009 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 D84F81065674 for ; Wed, 11 Feb 2009 20:46:29 +0000 (UTC) (envelope-from uwe@laverenz.de) Received: from mo-p00-ob.rzone.de (mo-p00-ob.rzone.de [81.169.146.161]) by mx1.freebsd.org (Postfix) with ESMTP id 2CE688FC14 for ; Wed, 11 Feb 2009 20:46:28 +0000 (UTC) (envelope-from uwe@laverenz.de) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1234385187; l=752; s=domk; d=laverenz.de; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:References: Subject:Cc:To:MIME-Version:From:Date:X-RZG-CLASS-ID:X-RZG-AUTH: DomainKey-Signature; bh=kHf72y/o2dWJyqU3ER0W+K1BUryzjuXseCz2Ct2OUa0=; b=LZ+NKfycEkzgRCbQVBKxC7mAI/SJpwzNLD8zUmXE15VnGZ5uAKfX5cx1kFnIUGI7tJh wJyBcfL/qSQzwx25wHsc1KucfYdrBA0WG0prYWrPL3CC5J+9i/yq+34R5+s0pHtSV36sV INzFIrKmjoCbTNIkjEzCoVDi0bC3BpKEVxE= DomainKey-Signature: a=rsa-sha256; s=domk; d=laverenz.de; c=nofws; q=dns; h=X-RZG-AUTH:X-RZG-CLASS-ID:Date:From:MIME-Version:To:Cc:Subject: References:In-Reply-To:Content-Type:Content-Transfer-Encoding; b=GNbfFDP95YnK+3wA/ZJfaFtW/YVXTZUKwlqoVVR303Y2Mlu+x0mpRuKSeMiTr9nqVcc SBF4GOCFZalaLt6tdbcZH6viyQMEU4sq5f+E/E55uU+CC3ZA9Es/i14HgJESctZc7Mrds 5MqZd95Hdvc15ILJPN9GYNTBR7QGsK3TIEY= X-RZG-AUTH: :LWgJfE6Id/4Sm/WkdV0gEbKL+/p/UjmosA/b4BPf1Ida/LA6f2WjvdsA X-RZG-CLASS-ID: mo00 Received: from athena.laverenz.de (77-22-194-90-dynip.superkabel.de [77.22.194.90]) by post.strato.de (mrclete mo19) (RZmta 18.18) with ESMTP id C019e9l1BJ5pIM ; Wed, 11 Feb 2009 21:35:27 +0100 (MET) Received: from localhost (localhost.localdomain [127.0.0.1]) by athena.laverenz.de (Postfix) with ESMTP id F0FBB61438; Wed, 11 Feb 2009 21:32:18 +0100 (CET) Received: from athena.laverenz.de ([127.0.0.1]) by localhost (athena [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 16535-02-4; Wed, 11 Feb 2009 21:32:18 +0100 (CET) Received: from [192.168.23.3] (unknown [192.168.23.3]) by athena.laverenz.de (Postfix) with ESMTP id AA07B127BDC; Wed, 11 Feb 2009 21:32:18 +0100 (CET) Message-ID: <4993368A.5040306@laverenz.de> Date: Wed, 11 Feb 2009 21:35:22 +0100 From: Uwe Laverenz Organization: private site User-Agent: Mozilla-Thunderbird 2.0.0.19 (X11/20090103) MIME-Version: 1.0 To: Sam Leffler References: <49665E35.1050301@errno.com> In-Reply-To: <49665E35.1050301@errno.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at laverenz.de Cc: stable@freebsd.org Subject: Re: CFT: ath hal src switchover X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Feb 2009 20:46:30 -0000 Sam Leffler schrieb: > those changes. To do this you must have an up to date RELENG_7 code > base and then apply this patch: > > http://people.freebsd.org/~sam/ath_hal-releng7.patch > > Then rebuild your kernel. There should be no changes to user apps. I tested this on a Thinkpad R51 / RELENG_7 / Atheros 5212 and I see no problems with the patch. It builds and runs fine and doesn't seem to do anything harmful. :) I have a problem with this machine though (with or without your patch): the wireless connection seems to be stalled every few minutes. If I try to send some traffic over ath0 or make wpa_cli reconnect it comes back for another few minutes. The only cure for now seems to be "ifconfig ath0 -bgscan". bye, Uwe From owner-freebsd-stable@FreeBSD.ORG Wed Feb 11 22:13:35 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9BF4F10656FD for ; Wed, 11 Feb 2009 22:13:35 +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 1909B8FC2E for ; Wed, 11 Feb 2009 22:13:35 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from server.baldwin.cx (pool-98-109-39-197.nwrknj.fios.verizon.net [98.109.39.197]) by cyrus.watson.org (Postfix) with ESMTPSA id 8F22946B0C; Wed, 11 Feb 2009 17:13:34 -0500 (EST) Received: from localhost (john@localhost [127.0.0.1]) (authenticated bits=0) by server.baldwin.cx (8.14.3/8.14.3) with ESMTP id n1BMDSMs028226; Wed, 11 Feb 2009 17:13:28 -0500 (EST) (envelope-from jhb@freebsd.org) From: John Baldwin To: freebsd-stable@freebsd.org Date: Wed, 11 Feb 2009 16:00:22 -0500 User-Agent: KMail/1.9.7 References: <47A0B642.9060000@icyb.net.ua> <200801311152.40064.jhb@freebsd.org> <47A20CCB.9020104@icyb.net.ua> In-Reply-To: <47A20CCB.9020104@icyb.net.ua> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200902111600.22611.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (server.baldwin.cx [127.0.0.1]); Wed, 11 Feb 2009 17:13:28 -0500 (EST) X-Virus-Scanned: ClamAV 0.94.2/8980/Wed Feb 11 11:40:45 2009 on server.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-4.4 required=4.2 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.1.3 X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on server.baldwin.cx Cc: Andriy Gapon Subject: Re: kld regression X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Feb 2009 22:13:36 -0000 On Thursday 31 January 2008 1:00:43 pm Andriy Gapon wrote: > on 31/01/2008 18:52 John Baldwin said the following: > > On Thursday 31 January 2008 10:05:57 am Andriy Gapon wrote: > >> on 31/01/2008 14:39 Andriy Gapon said the following: > >>> on 31/01/2008 13:07 John Baldwin said the following: > >>>> On Wednesday 30 January 2008 12:39:14 pm Andriy Gapon wrote: > >>>>> The problem is as follows: > >>>>> 1. put udf_load="YES" in loader.conf > >>>>> 2. you can mount and unmount udf filesystems > >>>>> 3. you can kldunload udf if no udf filesystems are mounted > >>>>> 4. now mount udf fs while udf.ko is unloaded > >>>>> 5. udf is auto loaded and fs is mounted > >>>>> 6. unmount fs > >>>>> 7. try to kldunload udf > >>>>> kldunload: can't unload file: Device busy > >>>>> kernel message: kldunload: attempt to unload file that was loaded by the > >>>>> kernel > >>>>> > >>>>> Yeah, it was loaded by kernel indeed, but WTF - what is the difference > >>>>> from manual/loader.conf loading and why I can not manage my modules as I > >>>>> wish? > >>>> Hmm, the relevant code (vfs_init.c) hasn't changed in 6.x since 6.0. > > There > >>>> were some changes in 7.0, but this should work in both branches. What is > > the > >>>> previous release that this worked on? > >>>> > >>> Maybe I was wrong when I called this regression, but this was very > >>> surprising behavior for me. And in 5.X I did a lot of udf > >>> debugging/experimenting and never encountered such a problem. Maybe I > >>> always did kldload before mount, I can't tell now. > >>> Anyway, this seems like an annoyance at the very least, pinning a kernel > >>> module without any important reasons. > >>> > >> Hmm, I found one difference with previous setups: in step 1 I also have > >> udf_iconv_load="YES" and udf_iconv.ko module is what seems to prevent > >> udf.ko from unloading in step 7. I can actually unload udf_iconv and > >> then I am able again to unload udf. > >> > >> Still don't understand what is a big difference here. > >> > >> And if I had UDF_ICONV built into kernel then I wouldn't have this > >> work-around. > > > > Ah, I don't think we can safely unload modules loaded from the loader IIRC. > > > > John, > > maybe there is a small misunderstanding: > 1. udf.ko and udf_iconv.ko are both loaded by loader - I *can* unload udf.ko > 2. udf_iconv.ko is loaded by loader but udf.ko is auto-loaded (by > whatever) when I do mount_udf - I can not unload udf.ko unless I unload > udf_iconv.ko. > > This is inconsistent and there is no obvious reason for things being > this way. VFS_DECLARE_ICONV() in has always made foo_iconv.ko depend on foo.ko from the beginning of its existence. Thus, udf_iconv.ko has always depended on udf.ko. I think if you had UDF_ICONV in your kernel config without UDF it would fail to link. What I do find odd is that udf_iconv.ko worked at all, perhaps the linker resolved it and linked it in when udf.ko was loaded, as prior to udf.ko being loaded it was missing a symbol in udf.ko it has a reference to. Either that or the loader was loading udf.ko as a dependency and you didn't realize it. -- John Baldwin From owner-freebsd-stable@FreeBSD.ORG Wed Feb 11 22:16:13 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2DADD106564A for ; Wed, 11 Feb 2009 22:16:13 +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 DFF828FC08 for ; Wed, 11 Feb 2009 22:16:12 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from server.baldwin.cx (pool-98-109-39-197.nwrknj.fios.verizon.net [98.109.39.197]) by cyrus.watson.org (Postfix) with ESMTPSA id 72F5846B5C; Wed, 11 Feb 2009 17:16:12 -0500 (EST) Received: from localhost (john@localhost [127.0.0.1]) (authenticated bits=0) by server.baldwin.cx (8.14.3/8.14.3) with ESMTP id n1BMFpwm028247; Wed, 11 Feb 2009 17:16:06 -0500 (EST) (envelope-from jhb@freebsd.org) From: John Baldwin To: freebsd-stable@freebsd.org Date: Wed, 11 Feb 2009 16:02:06 -0500 User-Agent: KMail/1.9.7 References: <20080917150433.GA3585@lpthe.jussieu.fr> <200809171713.39694.jhb@freebsd.org> <20080918075306.GA30709@lpthe.jussieu.fr> In-Reply-To: <20080918075306.GA30709@lpthe.jussieu.fr> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200902111602.06646.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (server.baldwin.cx [127.0.0.1]); Wed, 11 Feb 2009 17:16:06 -0500 (EST) X-Virus-Scanned: ClamAV 0.94.2/8980/Wed Feb 11 11:40:45 2009 on server.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-4.4 required=4.2 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.1.3 X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on server.baldwin.cx Cc: Michel Talon Subject: Re: floppy disk controller broken X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Feb 2009 22:16:13 -0000 On Thursday 18 September 2008 3:53:06 am Michel Talon wrote: > On Wed, Sep 17, 2008 at 05:13:39PM -0400, John Baldwin wrote: > > On Wednesday 17 September 2008 11:04:33 am Michel Talon wrote: > > > Hello, > > > > > > when testing FreeBSD-7.1-BETA i discovered that the floppy disk > > > controller doesn't work correctly. Trying to format a floppy (perhaps > > > with bad blocks) i get: > > > Processing fdformat: ioctl(FD_FORM): Device not configured > > > instead of the normal E letter. I then checked the same problem is > > > present on FreeBSD-6.3 and it has been reported by Beech Rintoul (*) in > > > 2006! Of course the floppy disk driver is particularly messy, but > > > this is not pretty. > > > > > > (*) i386/103862: Error with fdformat > > > > It looks like the ioctl to format a track used to never report failures from > > the controller. The newer driver does. What I've done with fdformat is to > > make it just ignore the errors in userland instead. Try this: > > > > Index: fdformat.c > > =================================================================== > > --- fdformat.c (revision 183112) > > +++ fdformat.c (working copy) > > @@ -75,8 +75,7 @@ > > f.fd_formb_secno(i) = il[i+1]; > > f.fd_formb_secsize(i) = secsize; > > } > > - if(ioctl(fd, FD_FORM, (caddr_t)&f) < 0) > > - err(EX_OSERR, "ioctl(FD_FORM)"); > > + (void)ioctl(fd, FD_FORM, (caddr_t)&f); > > } > > > > static int > > > > > > -- > > John Baldwin > > This doesn't work any more. This time i get > niobe# fdformat fd0 > Format 1440K floppy `/dev/fd0'? (y/n): y > Processing EEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEE done. > > where only the first E takes some time to be printed, and all subsequent > ones are printed instantaneously, that is all other formatting is not > tried. In principle the formatting process must try each of the > "sectors" in turn, and can come up with a series of V and F. > > Moreover, trying to write to the floppy: > niobe# dd if=/dev/zero of=/dev/fd0 conv=noerror > dd: /dev/fd0: Input/output error > 5+0 records in > 4+0 records out > 2048 bytes transferred in 4.054404 secs (505 bytes/sec) > > I don't expect such result. Traditionnally writing works, while reading > may fail. Here reading fails with incoherent messages: > dd: /dev/fd0: Device not configured > 3+0 records in > 3+0 records out > 1536 bytes transferred in 2.595216 secs (592 bytes/sec) > repeated a large number of times. But nothing in dmesg, contrary to the > tradition which showed the defective sectors. > > In conclusion i am under the impression that the in kernel driver is > severely botched. Of course nobody uses floppies any more, but this is > quite ugly. There are actually changes to the floppy driver in HEAD that I think address this. I don't recall if they were MFC'd to 7. -- John Baldwin From owner-freebsd-stable@FreeBSD.ORG Wed Feb 11 22:16:18 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D49F6106568B for ; Wed, 11 Feb 2009 22:16:18 +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 A49B18FC0A for ; Wed, 11 Feb 2009 22:16:18 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from server.baldwin.cx (pool-98-109-39-197.nwrknj.fios.verizon.net [98.109.39.197]) by cyrus.watson.org (Postfix) with ESMTPSA id 396B246B0C; Wed, 11 Feb 2009 17:16:18 -0500 (EST) Received: from localhost (john@localhost [127.0.0.1]) (authenticated bits=0) by server.baldwin.cx (8.14.3/8.14.3) with ESMTP id n1BMFpwn028247; Wed, 11 Feb 2009 17:16:12 -0500 (EST) (envelope-from jhb@freebsd.org) From: John Baldwin To: freebsd-stable@freebsd.org Date: Wed, 11 Feb 2009 16:37:03 -0500 User-Agent: KMail/1.9.7 References: <20090101024228.GF87057@server.vk2pj.dyndns.org> In-Reply-To: <20090101024228.GF87057@server.vk2pj.dyndns.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200902111637.04229.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (server.baldwin.cx [127.0.0.1]); Wed, 11 Feb 2009 17:16:12 -0500 (EST) X-Virus-Scanned: ClamAV 0.94.2/8980/Wed Feb 11 11:40:45 2009 on server.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-4.4 required=4.2 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.1.3 X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on server.baldwin.cx Cc: Peter Jeremy Subject: Re: Interval timers firing early X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Feb 2009 22:16:19 -0000 On Wednesday 31 December 2008 9:42:28 pm Peter Jeremy wrote: > I have some code that uses setitimer() to generate one-shot timers of > ~60s (the intent is to fire ~10msec before the minute boundary). > > On my amd64 laptop running 7.0-stable from mid-March the SIGALRM > arrives at the expected time. On a system running a recent amd64 > -current, the SIGALRM arrives about 10msec late (which I'm not too > fussed about). > > On two i386 systems running 7.1-PRE (from mid-Oct) and a fresh 7.1-RC2 > install, the SIGALRM arrives early - ~11msec for the 7.1-PRE system and > ~5msec for the 7.1-RC2 system. > > All systems are running HZ=1000. Two of the systems (the one running > 7.1-PRE and the one running -current) are running BOINC. All systems > are otherwise unloaded. I've looked at the timer code and can't > quickly see anything that would explain this. Does anyone have any > ideas? > > The relevant code looks like the following: > while (1) { > struct timeval now; > struct itimerval it; > int usecs; > > if (gettimeofday(&now, NULL) < 0) { > syslog(LOG_ERR, "gettimeofday: %m"); > exit(1); > } > /* Set timer for just before next minute */ > it.it_interval.tv_sec = 0; > it.it_interval.tv_usec = 0; > usecs = 59990000 - ((now.tv_sec % 60) * 1000000 + now.tv_usec); > if (usecs < 10000) /* allow 10msec slop */ > usecs += 60000000; > it.it_value.tv_sec = usecs / 1000000; > it.it_value.tv_usec = usecs % 1000000; > if (setitimer(ITIMER_REAL, &it, NULL) < 0) { > syslog(LOG_ERR, "setitimer: %m"); > exit(1); > } > printf("%d.%06ld %2d.%06ld %d\n", now.tv_sec, now.tv_usec, > it.it_value.tv_sec, it.it_value.tv_usec, usecs); > /* do stuff here which is interrupted by SIGALRM */ > } > > On the 7.1-PRE system, I get output like: > 1230776939.991464 59.998536 59998536 > 1230776999.978991 0.011009 11009 > 1230776999.991996 59.998004 59998004 > 1230777059.979532 0.010468 10468 > 1230777059.991538 59.998462 59998462 > 1230777119.979058 0.010942 10942 > 1230777119.991065 59.998935 59998935 > 1230777179.978597 0.011403 11403 > 1230777179.991610 59.998390 59998390 > 1230777239.979139 0.010861 10861 > 1230777239.991142 59.998858 59998858 On a whim, hack kern_tc.c to only use 2 or 3 timehands structures instead of 64. -- John Baldwin From owner-freebsd-stable@FreeBSD.ORG Wed Feb 11 22:59:18 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5C55D106566C for ; Wed, 11 Feb 2009 22:59:18 +0000 (UTC) (envelope-from gcr+freebsd-stable@tharned.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 3EF788FC15 for ; Wed, 11 Feb 2009 22:59:18 +0000 (UTC) (envelope-from gcr+freebsd-stable@tharned.org) Received: from OMTA06.emeryville.ca.mail.comcast.net ([76.96.30.51]) by QMTA08.emeryville.ca.mail.comcast.net with comcast id EgsX1b03Q16AWCUA8mjJK0; Wed, 11 Feb 2009 22:43:18 +0000 Received: from packrat.tharned.org ([75.145.12.185]) by OMTA06.emeryville.ca.mail.comcast.net with comcast id EmjF1b0013zZBGT8SmjGfB; Wed, 11 Feb 2009 22:43:18 +0000 Received: from packrat.tharned.org (11008@localhost [127.0.0.1]) by packrat.tharned.org (8.14.3/8.14.3) with ESMTP id n1BMhBxc061515 for ; Wed, 11 Feb 2009 16:43:11 -0600 (CST) (envelope-from gcr+freebsd-stable@tharned.org) Received: from localhost (gcr@localhost) by packrat.tharned.org (8.14.3/8.14.3/Submit) with ESMTP id n1BMhBhG061512 for ; Wed, 11 Feb 2009 16:43:11 -0600 (CST) (envelope-from gcr+freebsd-stable@tharned.org) Date: Wed, 11 Feb 2009 16:43:10 -0600 (CST) From: Greg Rivers To: freebsd-stable@freebsd.org Message-ID: User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII Subject: Driver for Intel 10GbE adapter X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Feb 2009 22:59:18 -0000 I'm trying to light an Intel 10GbE adapter in an HP DL380 G5 using very recent 7.1-STABLE amd64 with GENERIC kernel. I expected the ixbg(4) driver to attach, but it does not. The labels on the card show: INTEL(R) 10GbE XF SR 2 PORT SERVER ADAPTER 893135 EXPX9502FXSRGP5 001B211170BE 028AD E15728-003 A verbose boot shows the card on the PCI bus, but no driver attaches: pcib11: at device 6.0 on pci0 pcib11: domain 0 pcib11: secondary bus 23 pcib11: subordinate bus 23 pcib11: I/O decode 0x6000-0x6fff pcib11: memory decode 0xfde00000-0xfdffffff pcib11: no prefetched decode pci23: on pcib11 pci23: domain=0, physical bus=23 found-> vendor=0x8086, dev=0x10c6, revid=0x01 domain=0, bus=23, slot=0, func=0 class=02-00-00, hdrtype=0x00, mfdev=1 cmdreg=0x0047, statreg=0x0010, cachelnsz=16 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=10 powerspec 3 supports D0 D3 current D0 MSI supports 1 message, 64 bit MSI-X supports 18 messages in map 0x1c map[10]: type Memory, range 32, base 0xfdfe0000, size 17, enabled pcib11: requested memory range 0xfdfe0000-0xfdffffff: good map[14]: type Memory, range 32, base 0xfdf80000, size 18, enabled pcib11: requested memory range 0xfdf80000-0xfdfbffff: good map[18]: type I/O Port, range 32, base 0x6000, size 5, enabled pcib11: requested I/O range 0x6000-0x601f: in range map[1c]: type Memory, range 32, base 0xfdf70000, size 14, enabled pcib11: requested memory range 0xfdf70000-0xfdf73fff: good pcib11: matched entry for 23.0.INTA pcib11: slot 0 INTA hardwired to IRQ 19 found-> vendor=0x8086, dev=0x10c6, revid=0x01 domain=0, bus=23, slot=0, func=1 class=02-00-00, hdrtype=0x00, mfdev=1 cmdreg=0x0047, statreg=0x0010, cachelnsz=16 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=b, irq=5 powerspec 3 supports D0 D3 current D0 MSI supports 1 message, 64 bit MSI-X supports 18 messages in map 0x1c map[10]: type Memory, range 32, base 0xfdf40000, size 17, enabled pcib11: requested memory range 0xfdf40000-0xfdf5ffff: good map[14]: type Memory, range 32, base 0xfdf00000, size 18, enabled pcib11: requested memory range 0xfdf00000-0xfdf3ffff: good map[18]: type I/O Port, range 32, base 0x6020, size 5, enabled pcib11: requested I/O range 0x6020-0x603f: in range map[1c]: type Memory, range 32, base 0xfdef0000, size 14, enabled pcib11: requested memory range 0xfdef0000-0xfdef3fff: good pcib11: matched entry for 23.0.INTB pcib11: slot 0 INTB hardwired to IRQ 16 pci23: at device 0.0 (no driver attached) pci23: at device 0.1 (no driver attached) pciconf shows: none0@pci0:23:0:0: class=0x020000 card=0xa15f8086 chip=0x10c68086 rev=0x01 hdr=0x00 vendor = 'Intel Corporation' class = network subclass = ethernet none1@pci0:23:0:1: class=0x020000 card=0xa15f8086 chip=0x10c68086 rev=0x01 hdr=0x00 vendor = 'Intel Corporation' class = network subclass = ethernet I thought perhaps it would be a simple matter of adding/updating a card ID in the driver header file, but I see that sys/dev/ixgb/ixgb_ids.h already contains an entry for 0xA15F as listed above. Does anyone have experience with this card or know how to get it to probe and attach? Thanks! -- Greg Rivers From owner-freebsd-stable@FreeBSD.ORG Wed Feb 11 23:05:48 2009 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 10A5A106568D for ; Wed, 11 Feb 2009 23:05:48 +0000 (UTC) (envelope-from bengta@P142.sics.se) Received: from sink.sics.se (sink.sics.se [193.10.64.88]) by mx1.freebsd.org (Postfix) with ESMTP id 929F48FC1F for ; Wed, 11 Feb 2009 23:05:47 +0000 (UTC) (envelope-from bengta@P142.sics.se) Received: from P142.sics.se (h184n4-u-d1.ias.bredband.telia.com [62.20.173.184]) by sink.sics.se (8.14.3/8.14.3) with ESMTP id n1BMTuoM028561 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 11 Feb 2009 23:29:57 +0100 (CET) (envelope-from bengta@P142.sics.se) Received: from P142.sics.se (localhost [127.0.0.1]) by P142.sics.se (8.14.3/8.14.3) with ESMTP id n1BMWldb004649; Wed, 11 Feb 2009 23:32:47 +0100 (CET) (envelope-from bengta@P142.sics.se) Received: (from bengta@localhost) by P142.sics.se (8.14.3/8.14.3/Submit) id n1BMWjAg004648; Wed, 11 Feb 2009 23:32:45 +0100 (CET) (envelope-from bengta@P142.sics.se) To: Uwe Laverenz From: Bengt Ahlgren In-Reply-To: <4993368A.5040306@laverenz.de> (Uwe Laverenz's message of "Wed\, 11 Feb 2009 21\:35\:22 +0100") User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.2 (berkeley-unix) References: <49665E35.1050301@errno.com> <4993368A.5040306@laverenz.de> Date: Wed, 11 Feb 2009 23:32:45 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: stable@freebsd.org Subject: Re: CFT: ath hal src switchover X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Feb 2009 23:05:48 -0000 Uwe Laverenz writes: > Sam Leffler schrieb: > >> those changes. To do this you must have an up to date RELENG_7 code >> base and then apply this patch: >> >> http://people.freebsd.org/~sam/ath_hal-releng7.patch >> >> Then rebuild your kernel. There should be no changes to user apps. > > I tested this on a Thinkpad R51 / RELENG_7 / Atheros 5212 and I see no > problems with the patch. It builds and runs fine and doesn't seem to > do anything harmful. :) > > I have a problem with this machine though (with or without your > patch): the wireless connection seems to be stalled every few > minutes. If I try to send some traffic over ath0 or make wpa_cli > reconnect it comes back for another few minutes. > > The only cure for now seems to be "ifconfig ath0 -bgscan". That sounds like it can be the same symptoms as I described on the freebsd-mobile list earlier this week: http://lists.freebsd.org/pipermail/freebsd-mobile/2009-February/011343.html What clockrate do you run at? On my system (Thinkpad X40, Atheros 5212) the problem does not occur at kern.hz=1000, but it is present at kern.hz=100. Tomorrow evening I will investigate this further including testing if "ifconfig ath0 -bgscan" makes a difference for me. Bengt From owner-freebsd-stable@FreeBSD.ORG Wed Feb 11 23:09:26 2009 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 985681065679 for ; Wed, 11 Feb 2009 23:09:26 +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 6BF638FC08 for ; Wed, 11 Feb 2009 23:09:26 +0000 (UTC) (envelope-from sam@errno.com) Received: from trouble.errno.com (trouble.errno.com [10.0.0.248]) (authenticated bits=0) by ebb.errno.com (8.13.6/8.12.6) with ESMTP id n1BN9PqC037424 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 11 Feb 2009 15:09:25 -0800 (PST) (envelope-from sam@errno.com) Message-ID: <49935AA5.4010408@errno.com> Date: Wed, 11 Feb 2009 15:09:25 -0800 From: Sam Leffler User-Agent: Thunderbird 2.0.0.18 (X11/20081209) MIME-Version: 1.0 To: Bengt Ahlgren References: <49665E35.1050301@errno.com> <4993368A.5040306@laverenz.de> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-DCC-sonic.net-Metrics: ebb.errno.com; whitelist Cc: stable@freebsd.org, Uwe Laverenz Subject: Re: CFT: ath hal src switchover X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Feb 2009 23:09:27 -0000 Bengt Ahlgren wrote: > Uwe Laverenz writes: > > >> Sam Leffler schrieb: >> >> >>> those changes. To do this you must have an up to date RELENG_7 code >>> base and then apply this patch: >>> >>> http://people.freebsd.org/~sam/ath_hal-releng7.patch >>> >>> Then rebuild your kernel. There should be no changes to user apps. >>> >> I tested this on a Thinkpad R51 / RELENG_7 / Atheros 5212 and I see no >> problems with the patch. It builds and runs fine and doesn't seem to >> do anything harmful. :) >> >> I have a problem with this machine though (with or without your >> patch): the wireless connection seems to be stalled every few >> minutes. If I try to send some traffic over ath0 or make wpa_cli >> reconnect it comes back for another few minutes. >> >> The only cure for now seems to be "ifconfig ath0 -bgscan". >> > > That sounds like it can be the same symptoms as I described on the > freebsd-mobile list earlier this week: > > http://lists.freebsd.org/pipermail/freebsd-mobile/2009-February/011343.html > > What clockrate do you run at? On my system (Thinkpad X40, Atheros > 5212) the problem does not occur at kern.hz=1000, but it is present at > kern.hz=100. > > Tomorrow evening I will investigate this further including testing if > "ifconfig ath0 -bgscan" makes a difference for me. > There are many many changes to the ath driver in head that are not in stable. If I can get confidence in the hal backport I can try to bring back some of those. But I need to do things in the proper order; I can't backmerge a bunch of stuff, find something is broken, and then have to bisect changes. So people need to help get the hal code in place first. Sam From owner-freebsd-stable@FreeBSD.ORG Wed Feb 11 23:21:04 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B79941065670 for ; Wed, 11 Feb 2009 23:21:04 +0000 (UTC) (envelope-from pluknet@gmail.com) Received: from fk-out-0910.google.com (fk-out-0910.google.com [209.85.128.188]) by mx1.freebsd.org (Postfix) with ESMTP id 3B3208FC1D for ; Wed, 11 Feb 2009 23:21:04 +0000 (UTC) (envelope-from pluknet@gmail.com) Received: by fk-out-0910.google.com with SMTP id f40so229149fka.11 for ; Wed, 11 Feb 2009 15:21: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 :content-transfer-encoding; bh=PHOY1vknTvuW1nYHljohvjiDlCl8TDlONecJW2IlmmE=; b=uFUWqFZYjVD7vSI3OHJwwxhgFM7PEtIoBQi4r3IcvU5a8etpObFtlEcmKjPI2LvZ8b AyMkV+L43qnrEljPBCxYrgsncloKwfJt5IZjIhoO4Z4YKufbjfS+9QVBrHwPWwiEIVeo HiUhSNkP+2nvWQu8KD8Lmrr20+X/X+Q/vIzgU= 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=h86ug8mz/FPik4nYRuZpt16YQbAu+RuyWU0Wk4CUdr83s+KTryS4nWxdMbUlvxi98G AHgalkq5BgCRjPyEz/YIXhGQ+FNMr8GjjL90+vi6duTykP+MT7/ASTxhwVkVuDhpF/et ObDeybrDAbYgu16rWqnRZ/84QrKPnMAxsu0nI= MIME-Version: 1.0 Received: by 10.181.48.4 with SMTP id a4mr63614bkk.59.1234394463175; Wed, 11 Feb 2009 15:21:03 -0800 (PST) In-Reply-To: References: Date: Thu, 12 Feb 2009 02:21:03 +0300 Message-ID: From: pluknet To: Greg Rivers Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org Subject: Re: Driver for Intel 10GbE adapter X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Feb 2009 23:21:05 -0000 Hi. 2009/2/12 Greg Rivers : > I'm trying to light an Intel 10GbE adapter in an HP DL380 G5 using very > recent 7.1-STABLE amd64 with GENERIC kernel. I expected the ixbg(4) driver > to attach, but it does not. > > The labels on the card show: > INTEL(R) 10GbE XF SR 2 PORT SERVER ADAPTER > 893135 > EXPX9502FXSRGP5 > > 001B211170BE 028AD E15728-003 > > > A verbose boot shows the card on the PCI bus, but no driver attaches: > > pcib11: at device 6.0 on pci0 > pcib11: domain 0 > pcib11: secondary bus 23 > pcib11: subordinate bus 23 > pcib11: I/O decode 0x6000-0x6fff > pcib11: memory decode 0xfde00000-0xfdffffff > pcib11: no prefetched decode > pci23: on pcib11 > pci23: domain=0, physical bus=23 > found-> vendor=0x8086, dev=0x10c6, revid=0x01 > domain=0, bus=23, slot=0, func=0 > class=02-00-00, hdrtype=0x00, mfdev=1 > cmdreg=0x0047, statreg=0x0010, cachelnsz=16 (dwords) > lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) > intpin=a, irq=10 > powerspec 3 supports D0 D3 current D0 > MSI supports 1 message, 64 bit > MSI-X supports 18 messages in map 0x1c > map[10]: type Memory, range 32, base 0xfdfe0000, size 17, enabled > pcib11: requested memory range 0xfdfe0000-0xfdffffff: good > map[14]: type Memory, range 32, base 0xfdf80000, size 18, enabled > pcib11: requested memory range 0xfdf80000-0xfdfbffff: good > map[18]: type I/O Port, range 32, base 0x6000, size 5, enabled > pcib11: requested I/O range 0x6000-0x601f: in range > map[1c]: type Memory, range 32, base 0xfdf70000, size 14, enabled > pcib11: requested memory range 0xfdf70000-0xfdf73fff: good > pcib11: matched entry for 23.0.INTA > pcib11: slot 0 INTA hardwired to IRQ 19 > found-> vendor=0x8086, dev=0x10c6, revid=0x01 > domain=0, bus=23, slot=0, func=1 > class=02-00-00, hdrtype=0x00, mfdev=1 > cmdreg=0x0047, statreg=0x0010, cachelnsz=16 (dwords) > lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) > intpin=b, irq=5 > powerspec 3 supports D0 D3 current D0 > MSI supports 1 message, 64 bit > MSI-X supports 18 messages in map 0x1c > map[10]: type Memory, range 32, base 0xfdf40000, size 17, enabled > pcib11: requested memory range 0xfdf40000-0xfdf5ffff: good > map[14]: type Memory, range 32, base 0xfdf00000, size 18, enabled > pcib11: requested memory range 0xfdf00000-0xfdf3ffff: good > map[18]: type I/O Port, range 32, base 0x6020, size 5, enabled > pcib11: requested I/O range 0x6020-0x603f: in range > map[1c]: type Memory, range 32, base 0xfdef0000, size 14, enabled > pcib11: requested memory range 0xfdef0000-0xfdef3fff: good > pcib11: matched entry for 23.0.INTB > pcib11: slot 0 INTB hardwired to IRQ 16 > pci23: at device 0.0 (no driver attached) > pci23: at device 0.1 (no driver attached) > > > pciconf shows: > > none0@pci0:23:0:0: class=0x020000 card=0xa15f8086 chip=0x10c68086 > rev=0x01 hdr=0x00 > vendor = 'Intel Corporation' > class = network > subclass = ethernet > none1@pci0:23:0:1: class=0x020000 card=0xa15f8086 chip=0x10c68086 > rev=0x01 hdr=0x00 > vendor = 'Intel Corporation' > class = network > subclass = ethernet You probably want to load ixgbe(4), not ixgb(4) (latter is afaik an older PCI-X version driver). The labels on the card are close to the description of ixgbe. Note, it's not in GENERIC. -- wbr, pluknet From owner-freebsd-stable@FreeBSD.ORG Wed Feb 11 23:33:47 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 96F90106564A for ; Wed, 11 Feb 2009 23:33:47 +0000 (UTC) (envelope-from jfvogel@gmail.com) Received: from wa-out-1112.google.com (wa-out-1112.google.com [209.85.146.176]) by mx1.freebsd.org (Postfix) with ESMTP id 666E48FC17 for ; Wed, 11 Feb 2009 23:33:47 +0000 (UTC) (envelope-from jfvogel@gmail.com) Received: by wa-out-1112.google.com with SMTP id k34so208502wah.27 for ; Wed, 11 Feb 2009 15:33:47 -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=MyEica37Mh1P/IGEpb/HFM9AcE01jhF6gujB/ntD5hw=; b=KHfM3Q/tPrZhGsfIhuk34DD8uKtiyBChoGlJZkja5GXGgOaBZ5dW8tKc3RCN3XYsC+ IOER4HWIyXMh/2L3+BB3X4q9A+kmyhb0RYVNS8qaP7pMEb4/9r5/WgoV7HH9htKvNgkq YDAGJCnfCeudYS2qv00ArAtJOkpkyDyQeuW3A= 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=bzmxMFa+ZPz6cx1MGPF1qoGAa3QrDcAWefTMUkBmIMHyQGREOPIVjMpK9X+Dtib71C tXS4iCqH+L2Im0OybybYFqAqPMlVT1cCl6B0mtYixKpGASrNfWJ0hGJDp3B9vaPCjyCM 3pzxoJjX4STwqxQPRjUIO68udyKHoS8/6viPw= MIME-Version: 1.0 Received: by 10.114.36.4 with SMTP id j4mr87006waj.119.1234395226987; Wed, 11 Feb 2009 15:33:46 -0800 (PST) In-Reply-To: References: Date: Wed, 11 Feb 2009 15:33:46 -0800 Message-ID: <2a41acea0902111533u4fc7cb72h21ce0c10bb33c823@mail.gmail.com> From: Jack Vogel To: pluknet Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Greg Rivers , freebsd-stable@freebsd.org Subject: Re: Driver for Intel 10GbE adapter X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Feb 2009 23:33:48 -0000 On Wed, Feb 11, 2009 at 3:21 PM, pluknet wrote: > Hi. > > 2009/2/12 Greg Rivers > >: > > I'm trying to light an Intel 10GbE adapter in an HP DL380 G5 using very > > recent 7.1-STABLE amd64 with GENERIC kernel. I expected the ixbg(4) > driver > > to attach, but it does not. > > > > The labels on the card show: > > INTEL(R) 10GbE XF SR 2 PORT SERVER ADAPTER > > 893135 > > EXPX9502FXSRGP5 > > > > 001B211170BE 028AD E15728-003 > > > > > > A verbose boot shows the card on the PCI bus, but no driver attaches: > > > > pcib11: at device 6.0 on pci0 > > pcib11: domain 0 > > pcib11: secondary bus 23 > > pcib11: subordinate bus 23 > > pcib11: I/O decode 0x6000-0x6fff > > pcib11: memory decode 0xfde00000-0xfdffffff > > pcib11: no prefetched decode > > pci23: on pcib11 > > pci23: domain=0, physical bus=23 > > found-> vendor=0x8086, dev=0x10c6, revid=0x01 > > domain=0, bus=23, slot=0, func=0 > > class=02-00-00, hdrtype=0x00, mfdev=1 > > cmdreg=0x0047, statreg=0x0010, cachelnsz=16 (dwords) > > lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) > > intpin=a, irq=10 > > powerspec 3 supports D0 D3 current D0 > > MSI supports 1 message, 64 bit > > MSI-X supports 18 messages in map 0x1c > > map[10]: type Memory, range 32, base 0xfdfe0000, size 17, enabled > > pcib11: requested memory range 0xfdfe0000-0xfdffffff: good > > map[14]: type Memory, range 32, base 0xfdf80000, size 18, enabled > > pcib11: requested memory range 0xfdf80000-0xfdfbffff: good > > map[18]: type I/O Port, range 32, base 0x6000, size 5, enabled > > pcib11: requested I/O range 0x6000-0x601f: in range > > map[1c]: type Memory, range 32, base 0xfdf70000, size 14, enabled > > pcib11: requested memory range 0xfdf70000-0xfdf73fff: good > > pcib11: matched entry for 23.0.INTA > > pcib11: slot 0 INTA hardwired to IRQ 19 > > found-> vendor=0x8086, dev=0x10c6, revid=0x01 > > domain=0, bus=23, slot=0, func=1 > > class=02-00-00, hdrtype=0x00, mfdev=1 > > cmdreg=0x0047, statreg=0x0010, cachelnsz=16 (dwords) > > lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) > > intpin=b, irq=5 > > powerspec 3 supports D0 D3 current D0 > > MSI supports 1 message, 64 bit > > MSI-X supports 18 messages in map 0x1c > > map[10]: type Memory, range 32, base 0xfdf40000, size 17, enabled > > pcib11: requested memory range 0xfdf40000-0xfdf5ffff: good > > map[14]: type Memory, range 32, base 0xfdf00000, size 18, enabled > > pcib11: requested memory range 0xfdf00000-0xfdf3ffff: good > > map[18]: type I/O Port, range 32, base 0x6020, size 5, enabled > > pcib11: requested I/O range 0x6020-0x603f: in range > > map[1c]: type Memory, range 32, base 0xfdef0000, size 14, enabled > > pcib11: requested memory range 0xfdef0000-0xfdef3fff: good > > pcib11: matched entry for 23.0.INTB > > pcib11: slot 0 INTB hardwired to IRQ 16 > > pci23: at device 0.0 (no driver attached) > > pci23: at device 0.1 (no driver attached) > > > > > > pciconf shows: > > > > none0@pci0:23:0:0: class=0x020000 card=0xa15f8086 chip=0x10c68086 > > rev=0x01 hdr=0x00 > > vendor = 'Intel Corporation' > > class = network > > subclass = ethernet > > none1@pci0:23:0:1: class=0x020000 card=0xa15f8086 chip=0x10c68086 > > rev=0x01 hdr=0x00 > > vendor = 'Intel Corporation' > > class = network > > subclass = ethernet > > You probably want to load ixgbe(4), not ixgb(4) (latter is afaik an > older PCI-X version driver). > The labels on the card are close to the description of ixgbe. > Note, it's not in GENERIC. > Yes, its an Oplin, 82598, it uses my ixgbe driver rather than ixgb. Cheers, Jack From owner-freebsd-stable@FreeBSD.ORG Wed Feb 11 23:45:01 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 92E481065670 for ; Wed, 11 Feb 2009 23:45:01 +0000 (UTC) (envelope-from mat.macy@gmail.com) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.229]) by mx1.freebsd.org (Postfix) with ESMTP id 63B498FC1F for ; Wed, 11 Feb 2009 23:45:01 +0000 (UTC) (envelope-from mat.macy@gmail.com) Received: by rv-out-0506.google.com with SMTP id f6so117380rvb.43 for ; Wed, 11 Feb 2009 15:45:00 -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:content-transfer-encoding; bh=5lPDO3f0r7g8mgvSaZkQSzuFs9C2gorlLCIOuxZECW0=; b=wkjZm3GV0xosTPxDAlJt4ZrGiVcCll6h4pW1z8tkd94LhbNT+/yebYw+5tazVI+3zD HoR1P2Z9MxO/Rd35B39i2lR3Vgjlb1O8yiG2i2vxAnEfp9Um0r4uChEi8mEI5JGoE/1R alogElNRiql+TfHUDE39Kc/RMchqcvxZifZps= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=jqnU1Uohfch/cH/ZUOxUuhMnFvhoyN+uSGb0B5KO36tHQ8jtdCgzuxPosH8g4i9Qh0 dBXo3vz0lmdt6VXOj0VxAZlFOPUNX0/mWN423XYltnh7qba1OkXJEWI0qBiagOVwlaew XgZikStmDI+p/xxWgSNxpVTCY8IRA21mGlw4Y= MIME-Version: 1.0 Sender: mat.macy@gmail.com Received: by 10.141.198.2 with SMTP id a2mr95439rvq.297.1234394505755; Wed, 11 Feb 2009 15:21:45 -0800 (PST) In-Reply-To: References: Date: Wed, 11 Feb 2009 15:21:45 -0800 X-Google-Sender-Auth: 8bb7027b3cdbe59c Message-ID: <3c1674c90902111521n2e32c6e9h8b532df0db48475a@mail.gmail.com> From: Kip Macy To: Greg Rivers Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org Subject: Re: Driver for Intel 10GbE adapter X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Feb 2009 23:45:02 -0000 see ixgbe(4) On Wed, Feb 11, 2009 at 2:43 PM, Greg Rivers wrote: > I'm trying to light an Intel 10GbE adapter in an HP DL380 G5 using very > recent 7.1-STABLE amd64 with GENERIC kernel. I expected the ixbg(4) driver > to attach, but it does not. > > The labels on the card show: > INTEL(R) 10GbE XF SR 2 PORT SERVER ADAPTER > 893135 > EXPX9502FXSRGP5 > > 001B211170BE 028AD E15728-003 > > > A verbose boot shows the card on the PCI bus, but no driver attaches: > > pcib11: at device 6.0 on pci0 > pcib11: domain 0 > pcib11: secondary bus 23 > pcib11: subordinate bus 23 > pcib11: I/O decode 0x6000-0x6fff > pcib11: memory decode 0xfde00000-0xfdffffff > pcib11: no prefetched decode > pci23: on pcib11 > pci23: domain=0, physical bus=23 > found-> vendor=0x8086, dev=0x10c6, revid=0x01 > domain=0, bus=23, slot=0, func=0 > class=02-00-00, hdrtype=0x00, mfdev=1 > cmdreg=0x0047, statreg=0x0010, cachelnsz=16 (dwords) > lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) > intpin=a, irq=10 > powerspec 3 supports D0 D3 current D0 > MSI supports 1 message, 64 bit > MSI-X supports 18 messages in map 0x1c > map[10]: type Memory, range 32, base 0xfdfe0000, size 17, enabled > pcib11: requested memory range 0xfdfe0000-0xfdffffff: good > map[14]: type Memory, range 32, base 0xfdf80000, size 18, enabled > pcib11: requested memory range 0xfdf80000-0xfdfbffff: good > map[18]: type I/O Port, range 32, base 0x6000, size 5, enabled > pcib11: requested I/O range 0x6000-0x601f: in range > map[1c]: type Memory, range 32, base 0xfdf70000, size 14, enabled > pcib11: requested memory range 0xfdf70000-0xfdf73fff: good > pcib11: matched entry for 23.0.INTA > pcib11: slot 0 INTA hardwired to IRQ 19 > found-> vendor=0x8086, dev=0x10c6, revid=0x01 > domain=0, bus=23, slot=0, func=1 > class=02-00-00, hdrtype=0x00, mfdev=1 > cmdreg=0x0047, statreg=0x0010, cachelnsz=16 (dwords) > lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) > intpin=b, irq=5 > powerspec 3 supports D0 D3 current D0 > MSI supports 1 message, 64 bit > MSI-X supports 18 messages in map 0x1c > map[10]: type Memory, range 32, base 0xfdf40000, size 17, enabled > pcib11: requested memory range 0xfdf40000-0xfdf5ffff: good > map[14]: type Memory, range 32, base 0xfdf00000, size 18, enabled > pcib11: requested memory range 0xfdf00000-0xfdf3ffff: good > map[18]: type I/O Port, range 32, base 0x6020, size 5, enabled > pcib11: requested I/O range 0x6020-0x603f: in range > map[1c]: type Memory, range 32, base 0xfdef0000, size 14, enabled > pcib11: requested memory range 0xfdef0000-0xfdef3fff: good > pcib11: matched entry for 23.0.INTB > pcib11: slot 0 INTB hardwired to IRQ 16 > pci23: at device 0.0 (no driver attached) > pci23: at device 0.1 (no driver attached) > > > pciconf shows: > > none0@pci0:23:0:0: class=0x020000 card=0xa15f8086 chip=0x10c68086 > rev=0x01 hdr=0x00 > vendor = 'Intel Corporation' > class = network > subclass = ethernet > none1@pci0:23:0:1: class=0x020000 card=0xa15f8086 chip=0x10c68086 > rev=0x01 hdr=0x00 > vendor = 'Intel Corporation' > class = network > subclass = ethernet > > > I thought perhaps it would be a simple matter of adding/updating a card ID > in the driver header file, but I see that sys/dev/ixgb/ixgb_ids.h already > contains an entry for 0xA15F as listed above. > > Does anyone have experience with this card or know how to get it to probe > and attach? Thanks! > > -- > Greg Rivers > _______________________________________________ > 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 Feb 11 23:57:50 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4C48A106566C for ; Wed, 11 Feb 2009 23:57:50 +0000 (UTC) (envelope-from pluknet@gmail.com) Received: from mail-bw0-f170.google.com (mail-bw0-f170.google.com [209.85.218.170]) by mx1.freebsd.org (Postfix) with ESMTP id 69E798FC0C for ; Wed, 11 Feb 2009 23:57:48 +0000 (UTC) (envelope-from pluknet@gmail.com) Received: by bwz18 with SMTP id 18so854900bwz.19 for ; Wed, 11 Feb 2009 15:57:48 -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=GgiDgYm5LczlAXLpliWdMYee/plxEZCA0UsIe7KW8do=; b=xQEQ+W450WQ8Xcs/Kj0uMJkbQ5lPvQPepAuDle6slwO1gH9FKN1R8DgN8em7BVCUij 3d36BpVhNyjiU4oZyVODw89tsygFWZDiPYVbqZV6R8E7ySjeKvZvlBOpCKsLtbFx+gbY M79tUBONHWh3s54/yw7HFVc8DGFJO+iM0oJ84= 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=mob6qwAFbAojmga/pHg+q1QDC6urG/gSMNl0l1jbe0WY17sY1eIpHvTRZsKvvN9zMS UXHE8AJpRIxUt5z2EITqSYKPlXN4gBF5ChVzKxN+X+92jWNBjhoHR6VlA1jv7rucWOra WySfM8Viv4UOtNlriSfQpRbdtFF7XM/V7aRJA= MIME-Version: 1.0 Received: by 10.181.5.14 with SMTP id h14mr78283bki.22.1234396668069; Wed, 11 Feb 2009 15:57:48 -0800 (PST) In-Reply-To: <3c1674c90902111521n2e32c6e9h8b532df0db48475a@mail.gmail.com> References: <3c1674c90902111521n2e32c6e9h8b532df0db48475a@mail.gmail.com> Date: Thu, 12 Feb 2009 02:57:48 +0300 Message-ID: From: pluknet To: Kip Macy , Jack Vogel Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Greg Rivers , freebsd-stable@freebsd.org Subject: Re: Driver for Intel 10GbE adapter X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Feb 2009 23:57:51 -0000 2009/2/12 Kip Macy : > see ixgbe(4) BTW I'm afraid ixgbe manpage still to be merged to 7. > > On Wed, Feb 11, 2009 at 2:43 PM, Greg Rivers > wrote: >> I'm trying to light an Intel 10GbE adapter in an HP DL380 G5 using very >> recent 7.1-STABLE amd64 with GENERIC kernel. I expected the ixbg(4) driver >> to attach, but it does not. >> >> The labels on the card show: >> INTEL(R) 10GbE XF SR 2 PORT SERVER ADAPTER >> 893135 >> EXPX9502FXSRGP5 >> >> 001B211170BE 028AD E15728-003 >> >> >> A verbose boot shows the card on the PCI bus, but no driver attaches: >> >> pcib11: at device 6.0 on pci0 >> pcib11: domain 0 >> pcib11: secondary bus 23 >> pcib11: subordinate bus 23 >> pcib11: I/O decode 0x6000-0x6fff >> pcib11: memory decode 0xfde00000-0xfdffffff >> pcib11: no prefetched decode >> pci23: on pcib11 >> pci23: domain=0, physical bus=23 >> found-> vendor=0x8086, dev=0x10c6, revid=0x01 >> domain=0, bus=23, slot=0, func=0 >> class=02-00-00, hdrtype=0x00, mfdev=1 >> cmdreg=0x0047, statreg=0x0010, cachelnsz=16 (dwords) >> lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) >> intpin=a, irq=10 >> powerspec 3 supports D0 D3 current D0 >> MSI supports 1 message, 64 bit >> MSI-X supports 18 messages in map 0x1c >> map[10]: type Memory, range 32, base 0xfdfe0000, size 17, enabled >> pcib11: requested memory range 0xfdfe0000-0xfdffffff: good >> map[14]: type Memory, range 32, base 0xfdf80000, size 18, enabled >> pcib11: requested memory range 0xfdf80000-0xfdfbffff: good >> map[18]: type I/O Port, range 32, base 0x6000, size 5, enabled >> pcib11: requested I/O range 0x6000-0x601f: in range >> map[1c]: type Memory, range 32, base 0xfdf70000, size 14, enabled >> pcib11: requested memory range 0xfdf70000-0xfdf73fff: good >> pcib11: matched entry for 23.0.INTA >> pcib11: slot 0 INTA hardwired to IRQ 19 >> found-> vendor=0x8086, dev=0x10c6, revid=0x01 >> domain=0, bus=23, slot=0, func=1 >> class=02-00-00, hdrtype=0x00, mfdev=1 >> cmdreg=0x0047, statreg=0x0010, cachelnsz=16 (dwords) >> lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) >> intpin=b, irq=5 >> powerspec 3 supports D0 D3 current D0 >> MSI supports 1 message, 64 bit >> MSI-X supports 18 messages in map 0x1c >> map[10]: type Memory, range 32, base 0xfdf40000, size 17, enabled >> pcib11: requested memory range 0xfdf40000-0xfdf5ffff: good >> map[14]: type Memory, range 32, base 0xfdf00000, size 18, enabled >> pcib11: requested memory range 0xfdf00000-0xfdf3ffff: good >> map[18]: type I/O Port, range 32, base 0x6020, size 5, enabled >> pcib11: requested I/O range 0x6020-0x603f: in range >> map[1c]: type Memory, range 32, base 0xfdef0000, size 14, enabled >> pcib11: requested memory range 0xfdef0000-0xfdef3fff: good >> pcib11: matched entry for 23.0.INTB >> pcib11: slot 0 INTB hardwired to IRQ 16 >> pci23: at device 0.0 (no driver attached) >> pci23: at device 0.1 (no driver attached) >> >> >> pciconf shows: >> >> none0@pci0:23:0:0: class=0x020000 card=0xa15f8086 chip=0x10c68086 >> rev=0x01 hdr=0x00 >> vendor = 'Intel Corporation' >> class = network >> subclass = ethernet >> none1@pci0:23:0:1: class=0x020000 card=0xa15f8086 chip=0x10c68086 >> rev=0x01 hdr=0x00 >> vendor = 'Intel Corporation' >> class = network >> subclass = ethernet >> >> >> I thought perhaps it would be a simple matter of adding/updating a card ID >> in the driver header file, but I see that sys/dev/ixgb/ixgb_ids.h already >> contains an entry for 0xA15F as listed above. >> >> Does anyone have experience with this card or know how to get it to probe >> and attach? Thanks! >> >> -- >> Greg Rivers >> _______________________________________________ >> 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" > -- wbr, pluknet From owner-freebsd-stable@FreeBSD.ORG Thu Feb 12 01:16:56 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9EE8A106566C for ; Thu, 12 Feb 2009 01:16:56 +0000 (UTC) (envelope-from gcr+freebsd-stable@tharned.org) Received: from QMTA09.emeryville.ca.mail.comcast.net (qmta09.emeryville.ca.mail.comcast.net [76.96.30.96]) by mx1.freebsd.org (Postfix) with ESMTP id 7DD6F8FC15 for ; Thu, 12 Feb 2009 01:16:55 +0000 (UTC) (envelope-from gcr+freebsd-stable@tharned.org) Received: from OMTA11.emeryville.ca.mail.comcast.net ([76.96.30.36]) by QMTA09.emeryville.ca.mail.comcast.net with comcast id EdDX1b0030mlR8UA9pGwKT; Thu, 12 Feb 2009 01:16:56 +0000 Received: from packrat.tharned.org ([75.145.12.185]) by OMTA11.emeryville.ca.mail.comcast.net with comcast id EpGu1b0023zZBGT8XpGvKy; Thu, 12 Feb 2009 01:16:55 +0000 Received: from packrat.tharned.org (11008@localhost [127.0.0.1]) by packrat.tharned.org (8.14.3/8.14.3) with ESMTP id n1C1GqS2038305; Wed, 11 Feb 2009 19:16:52 -0600 (CST) (envelope-from gcr+freebsd-stable@tharned.org) Received: from localhost (gcr@localhost) by packrat.tharned.org (8.14.3/8.14.3/Submit) with ESMTP id n1C1Gq9c038302; Wed, 11 Feb 2009 19:16:52 -0600 (CST) (envelope-from gcr+freebsd-stable@tharned.org) Date: Wed, 11 Feb 2009 19:16:51 -0600 (CST) From: Greg Rivers To: freebsd-stable@freebsd.org In-Reply-To: Message-ID: References: <3c1674c90902111521n2e32c6e9h8b532df0db48475a@mail.gmail.com> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII Cc: pluknet , Jack Vogel , Kip Macy Subject: Re: Driver for Intel 10GbE adapter X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Feb 2009 01:16:56 -0000 On Thu, 12 Feb 2009, pluknet wrote: > You probably want to load ixgbe(4), not ixgb(4) (latter is afaik an > older PCI-X version driver). The labels on the card are close to the > description of ixgbe. Note, it's not in GENERIC. > On Wed, 11 Feb 2009, Jack Vogel wrote: > Yes, its an Oplin, 82598, it uses my ixgbe driver rather than ixgb. > On Wed, 11 Feb 2009, Kip Macy wrote: > see ixgbe(4) > I saw ixgbe in the source tree and would have tried it, but I found that no kernel module is built for ixgbe on RELENG_7. Neither is the device listed even as a comment in any stock config file. This and the lack of a manual page led me to believe it wasn't available. On Thu, 12 Feb 2009, pluknet wrote: > BTW I'm afraid ixgbe manpage still to be merged to 7. > It may be that more than just the man page remains to be merged. When I add "device ixgbe" to the GENERIC config and try to build a new kernel I get: In file included from /usr/src/sys/dev/ixgbe/ixgbe.c:39: /usr/src/sys/dev/ixgbe/ixgbe.h:87:21: error: tcp_lro.h: No such file or directory mkdep: compile failed *** Error code 1 Stop in /usr/obj/usr/src/sys/GENERIC. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. Is there any hope of seeing ixgbe fully merged into RELENG_7 soon, or is my best bet to switch to CURRENT? Thank you all for your help. -- Greg Rivers From owner-freebsd-stable@FreeBSD.ORG Thu Feb 12 01:37:48 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 667DD106566C for ; Thu, 12 Feb 2009 01:37:48 +0000 (UTC) (envelope-from jfvogel@gmail.com) Received: from wa-out-1112.google.com (wa-out-1112.google.com [209.85.146.177]) by mx1.freebsd.org (Postfix) with ESMTP id 2E1BD8FC13 for ; Thu, 12 Feb 2009 01:37:48 +0000 (UTC) (envelope-from jfvogel@gmail.com) Received: by wa-out-1112.google.com with SMTP id k34so232429wah.27 for ; Wed, 11 Feb 2009 17:37:47 -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=u8nF7oKOkKO88FUYVFcO+U9IioAhU0FQpm0nOFmO53I=; b=VGP10rzOaiIj3eLzhCXEsjQAMdlLCz2TI6yNq8j02szVOo8o73nVsEhpW87eyJNwGj EjVVsmjl08PZr0bn/2At4vI90fKLA+IOFkV6ttLlFKvOh8kQPzLzurgQpZDprskpEj2P hMYm14rksw2oCidkZAfI+xwcuJWMzak2MvlQI= 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=uLgx3QDOFpc7us2RXeYUVFbQc7AoB4IiGC50fGhQPbREAIJLi8K+ySZkrSdqRA1AOX LSrVjAmQIkCGnqD3rjF0nBXo5VMt698oArOxKy0ygFrUV9KPf0Qm5RV4RzxeDMKWjDM+ kDkshyqRilqx4i/iRIFsoVavXPhWZTsdRCitc= MIME-Version: 1.0 Received: by 10.114.176.7 with SMTP id y7mr123977wae.194.1234402667823; Wed, 11 Feb 2009 17:37:47 -0800 (PST) In-Reply-To: References: <3c1674c90902111521n2e32c6e9h8b532df0db48475a@mail.gmail.com> Date: Wed, 11 Feb 2009 17:37:47 -0800 Message-ID: <2a41acea0902111737s2d0d4176l36f14bbda82add35@mail.gmail.com> From: Jack Vogel To: Greg Rivers Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: pluknet , freebsd-stable@freebsd.org, Kip Macy Subject: Re: Driver for Intel 10GbE adapter X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Feb 2009 01:37:48 -0000 Somehow that error was corrected but just AFTER the release. Its a simple fix, look at ixgbe.h in CVS to see it, you just get rid of the "tcp_lro.h" and change it to There will be a new code drop soon also. Jack On Wed, Feb 11, 2009 at 5:16 PM, Greg Rivers > wrote: > On Thu, 12 Feb 2009, pluknet wrote: > > You probably want to load ixgbe(4), not ixgb(4) (latter is afaik an older >> PCI-X version driver). The labels on the card are close to the description >> of ixgbe. Note, it's not in GENERIC. >> >> > On Wed, 11 Feb 2009, Jack Vogel wrote: > > Yes, its an Oplin, 82598, it uses my ixgbe driver rather than ixgb. >> >> > On Wed, 11 Feb 2009, Kip Macy wrote: > > see ixgbe(4) >> >> > I saw ixgbe in the source tree and would have tried it, but I found that no > kernel module is built for ixgbe on RELENG_7. Neither is the device listed > even as a comment in any stock config file. This and the lack of a manual > page led me to believe it wasn't available. > > > On Thu, 12 Feb 2009, pluknet wrote: > > BTW I'm afraid ixgbe manpage still to be merged to 7. >> >> > It may be that more than just the man page remains to be merged. When I > add "device ixgbe" to the GENERIC config and try to build a new kernel I > get: > > In file included from /usr/src/sys/dev/ixgbe/ixgbe.c:39: > /usr/src/sys/dev/ixgbe/ixgbe.h:87:21: error: tcp_lro.h: No such file or > directory > mkdep: compile failed > *** Error code 1 > > Stop in /usr/obj/usr/src/sys/GENERIC. > *** Error code 1 > > Stop in /usr/src. > *** Error code 1 > > Stop in /usr/src. > > > Is there any hope of seeing ixgbe fully merged into RELENG_7 soon, or is my > best bet to switch to CURRENT? Thank you all for your help. > > -- > Greg Rivers > From owner-freebsd-stable@FreeBSD.ORG Thu Feb 12 02:12:42 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9EC02106566B for ; Thu, 12 Feb 2009 02:12:42 +0000 (UTC) (envelope-from admin@stardothosting.com) Received: from yx-out-2324.google.com (yx-out-2324.google.com [74.125.44.30]) by mx1.freebsd.org (Postfix) with ESMTP id 608CE8FC1A for ; Thu, 12 Feb 2009 02:12:42 +0000 (UTC) (envelope-from admin@stardothosting.com) Received: by yx-out-2324.google.com with SMTP id 31so315026yxl.13 for ; Wed, 11 Feb 2009 18:12:41 -0800 (PST) Received: by 10.65.116.10 with SMTP id t10mr135010qbm.103.1234404761438; Wed, 11 Feb 2009 18:12:41 -0800 (PST) Received: from kevin (not.enough.unixsluts.com [76.10.166.187]) by mx.google.com with ESMTPS id s35sm4336379qbs.6.2009.02.11.18.12.39 (version=SSLv3 cipher=RC4-MD5); Wed, 11 Feb 2009 18:12:40 -0800 (PST) From: "SDH Support" To: References: <498CCB85.2080702@paladin.bulgarpress.com> In-Reply-To: Date: Wed, 11 Feb 2009 21:12:30 -0500 Message-ID: <005901c98cb7$5e922670$1bb67350$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcmJRzV/Tm8Jum3BTpKKwtaykE7aQgDb+z7A Content-Language: en-us Subject: RE: FBSD 7.1 XEON Quad Core X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: admin@stardothosting.com List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Feb 2009 02:12:42 -0000 > Yes, if you have (or plan to have) more than 3 GB of memory. FYI I have had a lot of problems with FBSD7.x and HP DL-series hardware = + amd64. There is a bug IIRC in the loader. --- Kevin K. Systems Administrator www.stardothosting.com/managed-hosting=20 From owner-freebsd-stable@FreeBSD.ORG Thu Feb 12 03:10:40 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F3EBC1065677 for ; Thu, 12 Feb 2009 03:10:39 +0000 (UTC) (envelope-from gcr+freebsd-stable@tharned.org) Received: from QMTA04.westchester.pa.mail.comcast.net (qmta04.westchester.pa.mail.comcast.net [76.96.62.40]) by mx1.freebsd.org (Postfix) with ESMTP id 9689A8FC1A for ; Thu, 12 Feb 2009 03:10:39 +0000 (UTC) (envelope-from gcr+freebsd-stable@tharned.org) Received: from OMTA07.westchester.pa.mail.comcast.net ([76.96.62.59]) by QMTA04.westchester.pa.mail.comcast.net with comcast id Ep081b00E1GhbT854qxQC2; Thu, 12 Feb 2009 02:57:24 +0000 Received: from packrat.tharned.org ([75.145.12.185]) by OMTA07.westchester.pa.mail.comcast.net with comcast id EqxP1b00C3zZBGT3TqxPEU; Thu, 12 Feb 2009 02:57:24 +0000 Received: from packrat.tharned.org (11008@localhost [127.0.0.1]) by packrat.tharned.org (8.14.3/8.14.3) with ESMTP id n1C2vMiX038581; Wed, 11 Feb 2009 20:57:22 -0600 (CST) (envelope-from gcr+freebsd-stable@tharned.org) Received: from localhost (gcr@localhost) by packrat.tharned.org (8.14.3/8.14.3/Submit) with ESMTP id n1C2vLgo038578; Wed, 11 Feb 2009 20:57:21 -0600 (CST) (envelope-from gcr+freebsd-stable@tharned.org) Date: Wed, 11 Feb 2009 20:57:21 -0600 (CST) From: Greg Rivers To: Jack Vogel In-Reply-To: <2a41acea0902111737s2d0d4176l36f14bbda82add35@mail.gmail.com> Message-ID: References: <3c1674c90902111521n2e32c6e9h8b532df0db48475a@mail.gmail.com> <2a41acea0902111737s2d0d4176l36f14bbda82add35@mail.gmail.com> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: pluknet , freebsd-stable@freebsd.org, Kip Macy Subject: Re: Driver for Intel 10GbE adapter X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Feb 2009 03:10:40 -0000 On Wed, 11 Feb 2009, Jack Vogel wrote: > Somehow that error was corrected but just AFTER the release. Its a > simple fix, look at ixgbe.h in CVS to see it, you just get rid of the > "tcp_lro.h" and change it to > > There will be a new code drop soon also. > That worked perfectly. Now I see: pci23: on pcib11 ix0: port 0x6000-0x601f mem 0xfdfe0000-0xfdffffff,0xfdf80000-0xfdfbffff,0xfdf70000-0xfdf73fff irq 19 at device 0.0 on pci23 ix0: Using MSIX interrupts with 3 vectors ix0: [ITHREAD] ix0: [ITHREAD] ix0: [ITHREAD] ix0: Ethernet address: 00:1b:21:11:70:8f ix1: port 0x6020-0x603f mem 0xfdf40000-0xfdf5ffff,0xfdf00000-0xfdf3ffff,0xfdef0000-0xfdef3fff irq 16 at device 0.1 on pci23 ix1: Using MSIX interrupts with 3 vectors ix1: [ITHREAD] ix1: [ITHREAD] ix1: [ITHREAD] ix1: Ethernet address: 00:1b:21:11:70:8e and ix0@pci0:23:0:0: class=0x020000 card=0xa15f8086 chip=0x10c68086 rev=0x01 hdr=0x00 vendor = 'Intel Corporation' class = network subclass = ethernet ix1@pci0:23:0:1: class=0x020000 card=0xa15f8086 chip=0x10c68086 rev=0x01 hdr=0x00 vendor = 'Intel Corporation' class = network subclass = ethernet and ix0: flags=8802 metric 0 mtu 1500 options=13b ether 00:1b:21:11:70:8f media: Ethernet autoselect status: no carrier ix1: flags=8802 metric 0 mtu 1500 options=13b ether 00:1b:21:11:70:8e media: Ethernet autoselect status: no carrier Thanks! -- Greg Rivers From owner-freebsd-stable@FreeBSD.ORG Thu Feb 12 04:16:19 2009 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 BAA2A106566B for ; Thu, 12 Feb 2009 04:16:19 +0000 (UTC) (envelope-from gaijin.k@gmail.com) Received: from mail-qy0-f14.google.com (mail-qy0-f14.google.com [209.85.221.14]) by mx1.freebsd.org (Postfix) with ESMTP id 5AD218FC20 for ; Thu, 12 Feb 2009 04:16:19 +0000 (UTC) (envelope-from gaijin.k@gmail.com) Received: by qyk7 with SMTP id 7so957386qyk.19 for ; Wed, 11 Feb 2009 20:16:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:subject:from:to:cc :in-reply-to:references:content-type:date:message-id:mime-version :x-mailer:content-transfer-encoding; bh=Jmyl5r4mDOQgymX7mJcKWOTo8fU74mcigWPj27rjDEc=; b=J3sFHoB15/6SSoBbvzOejHTCPE9lp6LX9xnvd/bAUrzKKIFEMBK1Rk6RSehYvEjmXt BK4BVaBEEi5TlBNqQJkCZrsX+NqlnWNeiy83JthP/arF7JCUIMBOCYWLOlV6jwjHaLcf a1au/HJLYF/WgqFE50RVfA19BKI2I7eB3Drkw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=subject:from:to:cc:in-reply-to:references:content-type:date :message-id:mime-version:x-mailer:content-transfer-encoding; b=RZLAXAiiMK+HS9L1459ylLxNgoqwhxb4MWkMDlUycDKbyjM0f06W4mdrzP0HulZ7IX s4oNc/ageB98udnJe1WfdzJY919MMG8wV0l3Jk2mdD5IknIaO3ynkLCwEV3fbaqo8Q3S 4xGbOX2GOcsuC20ropVnjgOYRBOLOswRBKfKY= Received: by 10.224.46.14 with SMTP id h14mr383486qaf.182.1234410417159; Wed, 11 Feb 2009 19:46:57 -0800 (PST) Received: from ?10.0.3.231? (pool-70-111-172-146.nwrk.east.verizon.net [70.111.172.146]) by mx.google.com with ESMTPS id 30sm7141938yxk.32.2009.02.11.19.46.55 (version=SSLv3 cipher=RC4-MD5); Wed, 11 Feb 2009 19:46:56 -0800 (PST) From: "Alexandre \"Sunny\" Kovalenko" To: Sam Leffler In-Reply-To: <49935AA5.4010408@errno.com> References: <49665E35.1050301@errno.com> <4993368A.5040306@laverenz.de> <49935AA5.4010408@errno.com> Content-Type: text/plain Date: Wed, 11 Feb 2009 22:46:34 -0500 Message-Id: <1234410394.1482.16.camel@RabbitsDen> Mime-Version: 1.0 X-Mailer: Evolution 2.24.4 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: stable@freebsd.org, Uwe Laverenz Subject: Re: CFT: ath hal src switchover X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Feb 2009 04:16:20 -0000 On Wed, 2009-02-11 at 15:09 -0800, Sam Leffler wrote: > Bengt Ahlgren wrote: > > Uwe Laverenz writes: > > > > > >> Sam Leffler schrieb: > >> > >> > >>> those changes. To do this you must have an up to date RELENG_7 code > >>> base and then apply this patch: > >>> > >>> http://people.freebsd.org/~sam/ath_hal-releng7.patch > >>> > >>> Then rebuild your kernel. There should be no changes to user apps. > >>> > >> I tested this on a Thinkpad R51 / RELENG_7 / Atheros 5212 and I see no > >> problems with the patch. It builds and runs fine and doesn't seem to > >> do anything harmful. :) > >> > >> I have a problem with this machine though (with or without your > >> patch): the wireless connection seems to be stalled every few > >> minutes. If I try to send some traffic over ath0 or make wpa_cli > >> reconnect it comes back for another few minutes. > >> > >> The only cure for now seems to be "ifconfig ath0 -bgscan". > >> > > > > That sounds like it can be the same symptoms as I described on the > > freebsd-mobile list earlier this week: > > > > http://lists.freebsd.org/pipermail/freebsd-mobile/2009-February/011343.html > > > > What clockrate do you run at? On my system (Thinkpad X40, Atheros > > 5212) the problem does not occur at kern.hz=1000, but it is present at > > kern.hz=100. > > > > Tomorrow evening I will investigate this further including testing if > > "ifconfig ath0 -bgscan" makes a difference for me. > > > > There are many many changes to the ath driver in head that are not in > stable. If I can get confidence in the hal backport I can try to bring > back some of those. But I need to do things in the proper order; I > can't backmerge a bunch of stuff, find something is broken, and then > have to bisect changes. So people need to help get the hal code in > place first. Patch applied cleanly and works for ath0@pci0:3:0:0: class=0x020000 card=0x058a1014 chip=0x1014168c rev=0x01 hdr=0x00 vendor = 'Atheros Communications Inc.' device = 'AR5212 Atheros AR5212 802.11abg wireless' class = network subclass = ethernet ath0: mem 0xedf00000-0xedf0ffff irq 17 at device 0.0 on pci3 ath0: mac 10.3 phy 6.1 radio 10.2 My -STABLE is of February 5, 2009 about 7AM EST. I build wireless stuff as modules and load them manually. If it is of any value, I am using WPA-PSK. If there is any particular testing that I can perform, or any additional information that I can provide, please, let me know and I will be happy to oblige. Thank you very much for your work. -- Alexandre "Sunny" Kovalenko From owner-freebsd-stable@FreeBSD.ORG Thu Feb 12 07:25:36 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9F5C6106566C for ; Thu, 12 Feb 2009 07:25:36 +0000 (UTC) (envelope-from dean@stack.nl) Received: from mx1.stack.nl (unknown [IPv6:2001:610:150::2]) by mx1.freebsd.org (Postfix) with ESMTP id 5F36B8FC16 for ; Thu, 12 Feb 2009 07:25:36 +0000 (UTC) (envelope-from dean@stack.nl) Received: from toad.stack.nl (toad.stack.nl [IPv6:2001:610:1108:5010::135]) by mx1.stack.nl (Postfix) with ESMTP id 678573F635; Thu, 12 Feb 2009 08:25:35 +0100 (CET) Received: by toad.stack.nl (Postfix, from userid 1600) id 6138C73F57; Thu, 12 Feb 2009 08:25:35 +0100 (CET) Date: Thu, 12 Feb 2009 08:25:35 +0100 From: Dean Strik To: SDH Support Message-ID: <20090212072535.GP20905@stack.nl> References: <498CCB85.2080702@paladin.bulgarpress.com> <005901c98cb7$5e922670$1bb67350$@com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="4SRTEifjNkXp0Rce" Content-Disposition: inline In-Reply-To: <005901c98cb7$5e922670$1bb67350$@com> X-Really: Yes User-Agent: Mutt/1.5.18 (2008-05-17) Cc: freebsd-stable@freebsd.org Subject: Re: FBSD 7.1 XEON Quad Core X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Feb 2009 07:25:37 -0000 --4SRTEifjNkXp0Rce Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable SDH Support wrote: > > Yes, if you have (or plan to have) more than 3 GB of memory. >=20 > FYI I have had a lot of problems with FBSD7.x and HP DL-series hardware += amd64. There is a bug IIRC in the loader. I have 7.x/amd64 working without problems on DL360/DL380 generations 4 and 5. Can you elaborate on the problems you've had? --=20 Dean C. Strik Eindhoven University of Technology dean@stack.nl | dean@ipnet6.org | http://www.ipnet6.org/ "This isn't right. This isn't even wrong." -- Wolfgang Pauli --4SRTEifjNkXp0Rce Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (FreeBSD) iEYEARECAAYFAkmTzu8ACgkQ5Td/bYnvOANx0gCfeaQzB/jRBXRBFM0iKE9Vnfhp UU8AoNULBWr3sQkX6Y6163JO7epRuf8c =SOf0 -----END PGP SIGNATURE----- --4SRTEifjNkXp0Rce-- From owner-freebsd-stable@FreeBSD.ORG Thu Feb 12 08:24:07 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1790E106566B for ; Thu, 12 Feb 2009 08:24:07 +0000 (UTC) (envelope-from flo@kasimir.com) Received: from mail.solomo.de (mail.solomo.de [85.214.49.72]) by mx1.freebsd.org (Postfix) with ESMTP id C58F18FC1F for ; Thu, 12 Feb 2009 08:24:06 +0000 (UTC) (envelope-from flo@kasimir.com) Received: from localhost (localhost [127.0.0.1]) by mail.solomo.de (Postfix) with ESMTP id 900723F4B2; Thu, 12 Feb 2009 09:24:05 +0100 (CET) X-Virus-Scanned: amavisd-new at vistream.de Received: from mail.solomo.de ([127.0.0.1]) by localhost (mail.solomo.de [127.0.0.1]) (amavisd-new, port 10024) with LMTP id jVr9xvZftPbi; Thu, 12 Feb 2009 09:24:02 +0100 (CET) Received: from nibbler-osx.local (i53876220.versanet.de [83.135.98.32]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mail.solomo.de (Postfix) with ESMTPSA id B5FFB3F4AB; Thu, 12 Feb 2009 09:24:02 +0100 (CET) Message-ID: <4993DCA2.4000504@kasimir.com> Date: Thu, 12 Feb 2009 09:24:02 +0100 From: Florian Smeets User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1b3pre) Gecko/20090211 Shredder/3.0b2pre MIME-Version: 1.0 To: admin@stardothosting.com References: <498CCB85.2080702@paladin.bulgarpress.com> <005901c98cb7$5e922670$1bb67350$@com> In-Reply-To: <005901c98cb7$5e922670$1bb67350$@com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org Subject: Re: FBSD 7.1 XEON Quad Core X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Feb 2009 08:24:07 -0000 On 12.02.2009 3:12 Uhr, SDH Support wrote: > > >> Yes, if you have (or plan to have) more than 3 GB of memory. > > > FYI I have had a lot of problems with FBSD7.x and HP DL-series hardware + amd64. There is a bug IIRC in the loader. > > I had problems with DL3X0G5 when booting with PXE, every now an then the loader would hang when trying to load the kernel from an i386 8-CURRENT NFS server. As soon as i had installed everything and was booting from the disks the problem did not show up anymore. I also used amd64. Do you use PXE boot? Cheers, Florian From owner-freebsd-stable@FreeBSD.ORG Thu Feb 12 08:49:57 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C67EF106567A for ; Thu, 12 Feb 2009 08:49:57 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from kabab.cs.huji.ac.il (kabab.cs.huji.ac.il [132.65.16.84]) by mx1.freebsd.org (Postfix) with ESMTP id 7C05C8FC4D for ; Thu, 12 Feb 2009 08:49:57 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from pampa.cs.huji.ac.il ([132.65.80.32]) by kabab.cs.huji.ac.il with esmtp id 1LXXGP-0006Zt-LJ; Thu, 12 Feb 2009 10:49:41 +0200 X-Mailer: exmh version 2.7.2 01/07/2005 with nmh-1.2 To: Florian Smeets In-reply-to: <4993DCA2.4000504@kasimir.com> References: <498CCB85.2080702@paladin.bulgarpress.com> <005901c98cb7$5e922670$1bb67350$@com> <4993DCA2.4000504@kasimir.com> Comments: In-reply-to Florian Smeets message dated "Thu, 12 Feb 2009 09:24:02 +0100." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 12 Feb 2009 10:49:41 +0200 From: Danny Braniss Message-ID: Cc: admin@stardothosting.com, freebsd-stable@freebsd.org Subject: Re: FBSD 7.1 XEON Quad Core X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Feb 2009 08:49:58 -0000 > On 12.02.2009 3:12 Uhr, SDH Support wrote: > > > > > >> Yes, if you have (or plan to have) more than 3 GB of memory. > > > > > > FYI I have had a lot of problems with FBSD7.x and HP DL-series hardware + amd64. There is a bug IIRC in the loader. > > > > > > I had problems with DL3X0G5 when booting with PXE, every now an then the > loader would hang when trying to load the kernel from an i386 8-CURRENT > NFS server. As soon as i had installed everything and was booting from > the disks the problem did not show up anymore. I also used amd64. > > Do you use PXE boot? pxeboot is problematic on some platforms, try an older version btw, if you succeed let me know. thanks danny From owner-freebsd-stable@FreeBSD.ORG Thu Feb 12 13:56:38 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C0B5C1065677 for ; Thu, 12 Feb 2009 13:56:38 +0000 (UTC) (envelope-from uwe@laverenz.de) Received: from mo-p00-ob.rzone.de (mo-p00-ob.rzone.de [81.169.146.162]) by mx1.freebsd.org (Postfix) with ESMTP id 11F768FC0C for ; Thu, 12 Feb 2009 13:56:37 +0000 (UTC) (envelope-from uwe@laverenz.de) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1234446996; l=369; s=domk; d=laverenz.de; h=Sender:In-Reply-To:Content-Type:Mime-Version:References:Subject:To: From:Date:X-RZG-CLASS-ID:X-RZG-AUTH:DomainKey-Signature; bh=wWfdjKjpvci3UAFvYIJq3/jyKskRK6xJss5nbP5v6Ew=; b=HTCeeuA6fSGgssljTbgu1/5gci2d3O67r9lPWn8qdCOhtiT1UJsVMvRMCAtmE5pKzPd mjiUNN1EOYZMghI+X1df7PI97hlpz9PA0DkeZC4fm9AjXxcx58XESkMsRIVRhoBl+PRSv r7RMF7d7THkFSw6qX2yBObuz4gbxgUFDFrY= DomainKey-Signature: a=rsa-sha256; s=domk; d=laverenz.de; c=nofws; q=dns; h=X-RZG-AUTH:X-RZG-CLASS-ID:Date:From:To:Subject:References: Mime-Version:Content-Type:In-Reply-To:Sender; b=S3pACyHxfrhjoHmPU7QC74PnNSlrck4DSnsbFwgsGWM10J2mopJXmaMuV/NDdNG+jOk iexjzPYZzma17s62euWdWXLXmvKM5Bah0VAwNZ6xaM61wYcGp87IBYQ0tnQHISX/26Vm4 RKktIqm6qsu+ZbSZE65Y1/3nHzBnhW2lG6A= X-RZG-AUTH: :LWgJfE6Id/4Sm/WkdV0gEbKL+/p/UjmosA/b4BPf1Ida/LA6f2WjvdsA X-RZG-CLASS-ID: mo00 Received: from athena.laverenz.de (77-22-194-90-dynip.superkabel.de [77.22.194.90]) by post.strato.de (mrclete mo11) (RZmta 18.18) with ESMTP id 0014cel1CDdOjh for ; Thu, 12 Feb 2009 14:56:36 +0100 (MET) Received: from localhost (localhost.localdomain [127.0.0.1]) by athena.laverenz.de (Postfix) with ESMTP id CDF17127BF4 for ; Thu, 12 Feb 2009 14:53:20 +0100 (CET) Received: from athena.laverenz.de ([127.0.0.1]) by localhost (athena [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 07208-04 for ; Thu, 12 Feb 2009 14:53:20 +0100 (CET) Received: by athena.laverenz.de (Postfix, from userid 2000) id 84407127BF5; Thu, 12 Feb 2009 14:53:20 +0100 (CET) Date: Thu, 12 Feb 2009 14:53:20 +0100 From: Uwe Laverenz To: freebsd-stable@freebsd.org Message-ID: <20090212135320.GB3324@laverenz.de> Mail-Followup-To: freebsd-stable@freebsd.org References: <49665E35.1050301@errno.com> <4993368A.5040306@laverenz.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Organization: private site Sender: uwe@laverenz.de User-Agent: Mutt/1.5.9i X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at laverenz.de Subject: Re: CFT: ath hal src switchover X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Feb 2009 13:56:39 -0000 On Wed, Feb 11, 2009 at 11:32:45PM +0100, Bengt Ahlgren wrote: > http://lists.freebsd.org/pipermail/freebsd-mobile/2009-February/011343.html > > What clockrate do you run at? On my system (Thinkpad X40, Atheros > 5212) the problem does not occur at kern.hz=1000, but it is present at > kern.hz=100. I've tried both, 100 and 1000, same behaviour. cu, Uwe From owner-freebsd-stable@FreeBSD.ORG Thu Feb 12 14:22:06 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2D6CE106573B for ; Thu, 12 Feb 2009 14:22:06 +0000 (UTC) (envelope-from james.technew@gmail.com) Received: from wf-out-1314.google.com (wf-out-1314.google.com [209.85.200.174]) by mx1.freebsd.org (Postfix) with ESMTP id 043D78FC2A for ; Thu, 12 Feb 2009 14:22:05 +0000 (UTC) (envelope-from james.technew@gmail.com) Received: by wf-out-1314.google.com with SMTP id 27so692654wfd.7 for ; Thu, 12 Feb 2009 06:22:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:content-type:content-transfer-encoding; bh=gJOa5PS4KnYzJgSmd0NtByylAHQSnVKacj55g2x5cJ4=; b=L5zK2/UP7jOctNw3Vw87ETkheFN9q/XnGxNyq1i6ntZMnQDNdDsKyWsZQ2kzoGNEnM MtFmRxmuybZNUvGLopdy9X+jBke0Zc5XqdwnX/HXUZOy29FUvl3oRtOQFXLejvJAi5Zm oZ4cpGl1uD35LpM8z01uaT9jFnb++JgWGmxb4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type :content-transfer-encoding; b=GRWSM+FXTzuGvSt/l9enr95S6gfEm1vUV0x2ThYkjQE4JH8uUmrwMlc/tOCBYaOsYA vCr/Kks0i/1zqHIyW0XOGm0CUvHnbJ+uNZGpfYjkT0tbSqxMS4GenSwUC2jGQEh3BhOo t88Icon8v5hTQHJZ5JJYHo3aPb0uoClgJE9pI= MIME-Version: 1.0 Received: by 10.114.89.1 with SMTP id m1mr405469wab.35.1234446840700; Thu, 12 Feb 2009 05:54:00 -0800 (PST) Date: Thu, 12 Feb 2009 21:54:00 +0800 Message-ID: From: James Chang To: freebsd-stable@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: FreeBSD 7.1-Stable only support 16 CPUs !? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Feb 2009 14:22:07 -0000 Dear all, Does any ever try FreeBSD 7.1-stable on box that has more than 16 CPU? I got a HP ProLiant DL 785 G5 with 32 core (Quad-Core AMD Opteron(tm) Processor 8356 (2300.10-MHz K8-class CPU) and 256G memory. When I boot this machine, it could detect 32 core, but only 16 core could be uesd!? What should I do to get FreeBSD 7.1-stable work with 32 core? Or, FreeBSD 7.1 only support 16 Core Max ? Best Regards! James Chang From owner-freebsd-stable@FreeBSD.ORG Thu Feb 12 15:12:38 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CB927106566B for ; Thu, 12 Feb 2009 15:12:38 +0000 (UTC) (envelope-from wb@freebie.xs4all.nl) Received: from smtp-vbr10.xs4all.nl (smtp-vbr10.xs4all.nl [194.109.24.30]) by mx1.freebsd.org (Postfix) with ESMTP id 63B608FC1E for ; Thu, 12 Feb 2009 15:12:38 +0000 (UTC) (envelope-from wb@freebie.xs4all.nl) Received: from freebie.xs4all.nl (freebie.xs4all.nl [82.95.250.254]) by smtp-vbr10.xs4all.nl (8.13.8/8.13.8) with ESMTP id n1CF0FNo032040 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 12 Feb 2009 16:00:15 +0100 (CET) (envelope-from wb@freebie.xs4all.nl) Received: from freebie.xs4all.nl (localhost [127.0.0.1]) by freebie.xs4all.nl (8.14.2/8.14.2) with ESMTP id n1CExF0T037093; Thu, 12 Feb 2009 15:59:15 +0100 (CET) (envelope-from wb@freebie.xs4all.nl) Received: (from wb@localhost) by freebie.xs4all.nl (8.14.2/8.14.2/Submit) id n1CExA1D037092; Thu, 12 Feb 2009 15:59:10 +0100 (CET) (envelope-from wb) Date: Thu, 12 Feb 2009 15:59:10 +0100 From: Wilko Bulte To: James Chang Message-ID: <20090212145909.GE35858@freebie.xs4all.nl> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.18 (2008-05-17) X-Virus-Scanned: by XS4ALL Virus Scanner Cc: freebsd-stable@freebsd.org Subject: Re: FreeBSD 7.1-Stable only support 16 CPUs !? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Feb 2009 15:12:39 -0000 Quoting James Chang, who wrote on Thu, Feb 12, 2009 at 09:54:00PM +0800 .. > Dear all, > > Does any ever try FreeBSD 7.1-stable on box that has more than 16 CPU? > > I got a HP ProLiant DL 785 G5 with 32 core (Quad-Core AMD Opteron(tm) > Processor 8356 (2300.10-MHz K8-class CPU) and 256G memory. > When I boot this machine, it could detect 32 core, but only 16 core > could be uesd!? > > What should I do to get FreeBSD 7.1-stable work with 32 core? Buy the project a box like that? Or kidding aside: this is not the most common hardware, it might be that you are the first one to try ;-) Wilko > Or, FreeBSD 7.1 only support 16 Core Max ? > > > Best Regards! > > > James Chang > _______________________________________________ > 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" --- End of quoted text --- From owner-freebsd-stable@FreeBSD.ORG Thu Feb 12 15:23:15 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3856B106564A for ; Thu, 12 Feb 2009 15:23:15 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 1478F8FC14 for ; Thu, 12 Feb 2009 15:23:15 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by cyrus.watson.org (Postfix) with ESMTPS id A693E46B7F; Thu, 12 Feb 2009 10:23:14 -0500 (EST) Date: Thu, 12 Feb 2009 15:23:14 +0000 (GMT) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: James Chang In-Reply-To: Message-ID: References: User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-stable@freebsd.org Subject: Re: FreeBSD 7.1-Stable only support 16 CPUs !? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Feb 2009 15:23:15 -0000 On Thu, 12 Feb 2009, James Chang wrote: > Does any ever try FreeBSD 7.1-stable on box that has more than 16 CPU? > > I got a HP ProLiant DL 785 G5 with 32 core (Quad-Core AMD Opteron(tm) > Processor 8356 (2300.10-MHz K8-class CPU) and 256G memory. When I boot this > machine, it could detect 32 core, but only 16 core could be uesd!? > > What should I do to get FreeBSD 7.1-stable work with 32 core? Or, FreeBSD > 7.1 only support 16 Core Max ? I can't speak to the specific hardware you have, but one known limitation in several versions of FreeBSD is that the MAXCPU constant for i386 and amd64 is 16. You can redefine it in src/sys/${arch}/include/param.h and recompile your kernel to see the full 32 cores. You may need to recompile some userspace tools in order for them to properly report statistics for all CPUs, so a full rebuild of world wouldn't hurt. Robert N M Watson Computer Laboratory University of Cambridge From owner-freebsd-stable@FreeBSD.ORG Thu Feb 12 15:32:35 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5D0CC106566C for ; Thu, 12 Feb 2009 15:32:35 +0000 (UTC) (envelope-from pluknet@gmail.com) Received: from mail-fx0-f16.google.com (mail-fx0-f16.google.com [209.85.220.16]) by mx1.freebsd.org (Postfix) with ESMTP id E544D8FC08 for ; Thu, 12 Feb 2009 15:32:34 +0000 (UTC) (envelope-from pluknet@gmail.com) Received: by fxm9 with SMTP id 9so53916fxm.19 for ; Thu, 12 Feb 2009 07:32:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:content-type:content-transfer-encoding; bh=QcTM15Iw3h0vHpcojTyXY2bQwXQPT7U6AUQYpesv48g=; b=M0IMiLarpTUGIockZOA7Cj1Z/opymvR8F+/H0MYacDk4rea4tyTjx6x15uDwrhzhT8 fbjGvz645lozViBbOxWS8DllF7HKWH5r6ZsLJQv1l/R0u431oNA5MXWt6/G6UeCyhNWr M79yLru9LFnPUPLXAtdUr1AiyeKeJPqVEpUgU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type :content-transfer-encoding; b=f5+36feqkc/drpd1j2IL60MPlHybBeiLznnPidyc2p9wtz81I371+RtDPH6QgjUr5m BSQdAbEmeF6B7OQQB8mbsAQypUulFBgT3T4nnwwwYfn7MtgbcOgCyb2iNf77IXU43ahX N5+EVXI+3dedvzrIxr7KCY+BsI4jMNjDOX7tg= MIME-Version: 1.0 Received: by 10.181.159.17 with SMTP id l17mr350770bko.14.1234452601315; Thu, 12 Feb 2009 07:30:01 -0800 (PST) Date: Thu, 12 Feb 2009 18:30:01 +0300 Message-ID: From: pluknet To: FreeBSD Stable Mailing List Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: 6.2: LOR between kqueue and mount mtx X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Feb 2009 15:32:35 -0000 Hello. I'm just curious if ufs_vnops.c#rev1.290 fixes this LOR (or not): lock order reversal: 1st 0xcc9d1b00 kqueue (kqueue) @ /usr/src/sys_uvmem_uip.6.2_RELEASE/kern/kern_event.c:1547 2nd 0xc6d6b854 struct mount mtx (struct mount mtx) @ /usr/src/sys_uvmem_uip.6.2_RELEASE/ufs/ufs/ufs_vnops.c:138 KDB: stack backtrace: kdb_backtrace(0,ffffffff,c0a61df0,c0a61ee0,c09ce140,...) at kdb_backtrace+0x29 witness_checkorder(c6d6b854,9,c096683a,8a) at witness_checkorder+0x578 _mtx_lock_flags(c6d6b854,0,c096683a,8a,554,...) at _mtx_lock_flags+0x78 ufs_itimes(cbf6c000,cbf6c000,f78c0a5c,c70019d4,cd225048,...) at ufs_itimes+0x58 ufs_getattr(f78c0a5c) at ufs_getattr+0x1e VOP_GETATTR_APV(c0a09b00,f78c0a5c) at VOP_GETATTR_APV+0x7e filt_vfsread(c70019d4,6) at filt_vfsread+0x6b knote(cd225048,6,1) at knote+0x98 VOP_WRITE_APV(c0a09b00,f78c0bf4) at VOP_WRITE_APV+0x186 vn_write(c934c240,f78c0cbc,cc0b0300,0,c93ed7d0) at vn_write+0x1ea dofilewrite(c93ed7d0,3,c934c240,f78c0cbc,ffffffff,...) at dofilewrite+0x77 kern_writev(c93ed7d0,3,f78c0cbc,8054038,0,...) at kern_writev+0x3b write(c93ed7d0,f78c0d04) at write+0x45 syscall(3b,3b,3b,8054000,28296da0,...) at syscall+0x22f Xint0x80_syscall() at Xint0x80_syscall+0x1f --- syscall (4, FreeBSD ELF32, write), eip = 0x2827232f, esp = 0xbfbfd74c, ebp = 0xbfbfd768 --- P.S. I've caught this two times (almost at once) today. -- wbr, pluknet From owner-freebsd-stable@FreeBSD.ORG Thu Feb 12 15:32:45 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B4F2310656D5 for ; Thu, 12 Feb 2009 15:32:45 +0000 (UTC) (envelope-from pluknet@gmail.com) Received: from mail-bw0-f170.google.com (mail-bw0-f170.google.com [209.85.218.170]) by mx1.freebsd.org (Postfix) with ESMTP id 3DBC98FC14 for ; Thu, 12 Feb 2009 15:32:44 +0000 (UTC) (envelope-from pluknet@gmail.com) Received: by bwz18 with SMTP id 18so1365998bwz.19 for ; Thu, 12 Feb 2009 07:32:44 -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=wj5JmEfW+UljNrTmDrdnxZKPkKWKnLlko4+GoIETRUE=; b=n9foB+SZHwCNr66+AvNdUK9JIZVk3QNAXMlE65LIGA58vart5In/KO4dm8hOTsp3HI 6VBWRz/FwHZQNk45UIr/Jtox/QrmhTlyjA+DkilUH0ITHkhD/cKLXJjpu/SvIX0dag8F FwHgJ/zrO1nPYTNTuCI172ZMOBhlpljw5Ndac= 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=V35NwtRTG68qUuV66Xk3nDk2qcwnpOcZErtEQPxy2Ee2nVsa8n57lzVWlaZ3FIJ64A 5v5ue1aXkXJt2cZeuAfKUkdGTdA7y2dkCN2OnZA/6HRrFVfNxVhogWX0jwbjTLFBjqOI 1SjUhOwcrXVVeB8bPOLgoRUs04nLKQcBRG7C0= MIME-Version: 1.0 Received: by 10.181.49.3 with SMTP id b3mr350744bkk.21.1234452764234; Thu, 12 Feb 2009 07:32:44 -0800 (PST) In-Reply-To: References: Date: Thu, 12 Feb 2009 18:32:44 +0300 Message-ID: From: pluknet To: FreeBSD Stable Mailing List Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: 6.2: LOR between kqueue and mount mtx X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Feb 2009 15:32:46 -0000 2009/2/12 pluknet : > Hello. > > I'm just curious if ufs_vnops.c#rev1.290 fixes this LOR (or not): I found it was discussed already. Sorry for noise. -- wbr, pluknet From owner-freebsd-stable@FreeBSD.ORG Thu Feb 12 17:41:29 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7FE25106566B for ; Thu, 12 Feb 2009 17:41:29 +0000 (UTC) (envelope-from repcsike@gmail.com) Received: from mail-bw0-f170.google.com (mail-bw0-f170.google.com [209.85.218.170]) by mx1.freebsd.org (Postfix) with ESMTP id D641E8FC0A for ; Thu, 12 Feb 2009 17:41:28 +0000 (UTC) (envelope-from repcsike@gmail.com) Received: by bwz18 with SMTP id 18so1489085bwz.19 for ; Thu, 12 Feb 2009 09:41: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=/ewE7kZr/PmH/xkIJZwpeYXDrPJbbqNMxPpip7uuG9E=; b=KEgf6ok5MfTCFzxlTFjTUWGqv6UsMfST+A/2m67b7eNLGVk2QCD5Wi81bPAKTIdYeS bJzJQpZU5mnXfbPgEvdO9nbHWYVVZyO05rxFqT8YzXPSXISfbqOcuQ0FL7YcR7Qmi0MH bbnc8HYK55Qh2PmflxN14b1Ujk6G8lDQCRNlc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=E0Q43qD1/bNEmRb5hDHf4fmX7sIi+isKA0O5cQOvTnl6bn5uvC0sw9txj8pq1cK4Wl my4pqxNcM2HF/sDWfbmUxNLv3e+Ti9O7AX7LEo6/h4GyNkMa/2MixZYAobiG0uhejJHL 80fti+aIOWAsWwrKL+j831V4bGGdpddSQNLSw= MIME-Version: 1.0 Received: by 10.223.110.211 with SMTP id o19mr1358133fap.57.1234458586763; Thu, 12 Feb 2009 09:09:46 -0800 (PST) Date: Thu, 12 Feb 2009 18:09:46 +0100 Message-ID: From: Kevin Smith To: freebsd-stable@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Problem with SATA/SAS 5iR X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Feb 2009 17:41:30 -0000 Hi, I have a problem with a Dell Poweredge SC440 computer. It's equipped with a "Dell SATA/SAS 5iR" controller, it's from LSI actually (maybe megaraid). I'm using FreeBSD 7.1 Release I have 2x 500 GB SATA in a synchronised(status optimal) RAID-1 logical volume. The machine is brand new, first problem arised early after the installer started to install the files, the install was very slow, (I know it is because write cache is not enabled, that can be done with a management program, and I will enable it later) and sysinstall could not install the ports collection, the error it gave was "write error on transfer to cpio process, try of 1024 bytes" after OK, write error popped up. I found this error too, but I found no clue what could have happened. Installing the system without the ports collection (installed it later with cvsup)in another run gave no error at all, and in dmesg is see the logical volume: mpt0:vol0(mpt0:0:0): Settings ( Hot-Plug-Spares High-Priority-ReSync ) mpt0:vol0(mpt0:0:0): Using Spare Pool: 0 mpt0:vol0(mpt0:0:0): 2 Members: (mpt0:1:32:0): Primary Online (mpt0:1:1:0): Secondary Online mpt0:vol0(mpt0:0:0): RAID-1 - Optimal mpt0:vol0(mpt0:0:0): Status ( Enabled ) (mpt0:vol0:1): Physical (mpt0:0:1:0), Pass-thru (mpt0:1:0:0) (mpt0:vol0:1): Online (mpt0:vol0:0): Physical (mpt0:0:32:0), Pass-thru (mpt0:1:1:0) (mpt0:vol0:0): Online da0 at mpt0 bus 0 target 0 lun 0 da0: Fixed Direct Access SCSI-5 device da0: 300.000MB/s transfers da0: 476837MB (976562176 512 byte sectors: 255H 63S/T 60788C) It looks OK, but then I found this after typing "df -h", and it gives me th= e creeps: Filesystem Size Used Avail Capacity Mounted on /dev/da0s1a 496M 138M 318M 30% / devfs 1.0K 1.0K 0B 100% /dev /dev/da0s1e 3.9G 14K 3.6G 0% /tmp /dev/da0s1f 440G 537M 404G 0% /usr /dev/da0s1d 2.9G 1.3M 2.7G 0% /var I'm reading the freebsd-current list, and I found another buffer related problem there, but they say nothing about these. If you have any explanation/solution for these problems pls share them! Best Regards: Bal=E1zs M=E1t=E9ffy From owner-freebsd-stable@FreeBSD.ORG Thu Feb 12 18:03:07 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 71514106566B for ; Thu, 12 Feb 2009 18:03:07 +0000 (UTC) (envelope-from richardtector@thekeelecentre.com) Received: from mx0.thekeelecentre.com (mx0.thekeelecentre.com [IPv6:2001:470:1f09:16f:2::3]) by mx1.freebsd.org (Postfix) with ESMTP id 2A1A48FC13 for ; Thu, 12 Feb 2009 18:03:07 +0000 (UTC) (envelope-from richardtector@thekeelecentre.com) Received: from localhost (filter.mx0.thekeelecentre.com [217.206.238.165]) by mx0.thekeelecentre.com (Postfix) with ESMTP id 2E7774515D; Thu, 12 Feb 2009 18:03:06 +0000 (GMT) X-Virus-Scanned: amavisd-new at thekeelecentre.com Received: from mx0.thekeelecentre.com ([217.206.238.167]) by localhost (filter.mx0.thekeelecentre.com [217.206.238.165]) (amavisd-new, port 10024) with ESMTP id rnARkNA7fhML; Thu, 12 Feb 2009 18:03:03 +0000 (UTC) Received: from [10.0.2.50] (daffy.tector.org.uk [82.71.32.9]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx0.thekeelecentre.com (Postfix) with ESMTPSA id 7B42345151; Thu, 12 Feb 2009 18:03:02 +0000 (GMT) Message-ID: <4994644D.8070102@thekeelecentre.com> Date: Thu, 12 Feb 2009 18:02:53 +0000 From: Richard Tector User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Kevin Smith References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org Subject: Re: Problem with SATA/SAS 5iR X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Feb 2009 18:03:07 -0000 Kevin Smith wrote: > Hi, > > I have a problem with a Dell Poweredge SC440 computer. > It's equipped with a "Dell SATA/SAS 5iR" controller, it's from LSI actually > (maybe megaraid). > > I'm using FreeBSD 7.1 Release > > I have 2x 500 GB SATA in a synchronised(status optimal) RAID-1 logical > volume. > > The machine is brand new, first problem arised early after the installer > started to install the files, the install was very slow, (I know it is > because write cache is not enabled, that can be done with a management > program, and I will enable it later) and sysinstall could not install the > ports collection, the error it gave was > "write error on transfer to cpio process, try of 1024 bytes" after OK, > write error popped up. > > I found this error too, but I found no clue what could have happened. > > Installing the system without the ports collection (installed it later with > cvsup)in another run gave no error at all, and in dmesg is see the logical > volume: > > mpt0:vol0(mpt0:0:0): Settings ( Hot-Plug-Spares High-Priority-ReSync ) > mpt0:vol0(mpt0:0:0): Using Spare Pool: 0 > mpt0:vol0(mpt0:0:0): 2 Members: > (mpt0:1:32:0): Primary Online > (mpt0:1:1:0): Secondary Online > mpt0:vol0(mpt0:0:0): RAID-1 - Optimal > mpt0:vol0(mpt0:0:0): Status ( Enabled ) > (mpt0:vol0:1): Physical (mpt0:0:1:0), Pass-thru (mpt0:1:0:0) > (mpt0:vol0:1): Online > (mpt0:vol0:0): Physical (mpt0:0:32:0), Pass-thru (mpt0:1:1:0) > (mpt0:vol0:0): Online > da0 at mpt0 bus 0 target 0 lun 0 > da0: Fixed Direct Access SCSI-5 device > da0: 300.000MB/s transfers > da0: 476837MB (976562176 512 byte sectors: 255H 63S/T 60788C) > > It looks OK, but then I found this after typing "df -h", and it gives me the > creeps: > > Filesystem Size Used Avail Capacity Mounted on > /dev/da0s1a 496M 138M 318M 30% / > devfs 1.0K 1.0K 0B 100% /dev > /dev/da0s1e 3.9G 14K 3.6G 0% /tmp > /dev/da0s1f 440G 537M 404G 0% /usr > /dev/da0s1d 2.9G 1.3M 2.7G 0% /var > > I'm reading the freebsd-current list, and I found another buffer related > problem there, but they say nothing about these. > > If you have any explanation/solution for these problems pls share them! > > What's wrong with the dmesg? The used/available inconsistencies are due to space being reserved. Regarding disk performance, you need to put hw.mpt.enable_sata_wc=1 in /boot/loader.conf to reenable the write cache (it's disabled by default for consistency reasons when using SATA disks leading to poor write performance). Regards, Richard From owner-freebsd-stable@FreeBSD.ORG Thu Feb 12 18:16:16 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0B4EC1065689 for ; Thu, 12 Feb 2009 18:16:16 +0000 (UTC) (envelope-from ghelmer@palisadesys.com) Received: from cetus.palisadesys.com (cetus.palisadesys.com [205.237.115.21]) by mx1.freebsd.org (Postfix) with ESMTP id C6A4A8FC0A for ; Thu, 12 Feb 2009 18:16:15 +0000 (UTC) (envelope-from ghelmer@palisadesys.com) Received: from cancer.palisadesys.com (serverwatch [172.16.1.98]) by cetus.palisadesys.com (8.14.3/8.14.3) with ESMTP id n1CIGDsD064830; Thu, 12 Feb 2009 12:16:13 -0600 (CST) (envelope-from ghelmer@palisadesys.com) Received: from [172.16.2.242] (cetus.palisadesys.com [205.237.115.21]) (authenticated bits=0) by cancer.palisadesys.com (8.14.2/8.14.2) with ESMTP id n1CIGCcZ094982; Thu, 12 Feb 2009 12:16:13 -0600 (CST) (envelope-from ghelmer@palisadesys.com) Message-ID: <49946769.1040009@palisadesys.com> Date: Thu, 12 Feb 2009 12:16:09 -0600 From: Guy Helmer User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Pete French , freebsd-stable@freebsd.org References: <49676406.9050902@palisadesys.com> In-Reply-To: <49676406.9050902@palisadesys.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-3.0 (cancer.palisadesys.com [205.237.115.20]); Thu, 12 Feb 2009 12:16:13 -0600 (CST) X-Palisade-MailScanner-Information: Please contact the ISP for more information X-Palisade-MailScanner: Found to be clean X-Palisade-MailScanner-SpamCheck: not spam (whitelisted), SpamAssassin (not cached, score=-4.399, required 6, autolearn=not spam, ALL_TRUSTED -1.80, BAYES_00 -2.60) X-Palisade-MailScanner-From: ghelmer@palisadesys.com Cc: Subject: Re: Big problems with 7.1 locking up :-( X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Feb 2009 18:16:16 -0000 Guy Helmer wrote: > Pete French wrote: >> I have a number of HP 1U servers, all of which were running 7.0 >> perfectly happily. I have been testing 7.1 in it's various incarnations >> for the last couple of months on our test server and it has performed >> perfectly. >> >> So the last two days I have been round upgrading all our servers, >> knowing >> that I had run the system stably on identical hardware for some time. >> >> Since then I have starte seeing machines lock up. This always happens >> under >> heavy disc load. When I bring the machine back up then sometimes it >> fails >> to fsck due to a partialy truncated inode. The locksup appear to >> be disc related - on my mysql msater machine it will come back up with >> files somewhat shorted than those which ahve aready been transmitted to >> the slave (i.e. some data was in memory, and claimed to have been >> written >> to the drive, but never made it onto the disc). >> >> The only time I have seen anything useful on the screen was during >> one lockup >> where I got a message about a spin lock being held too long and some >> comment in parentheses about it being a turnstile lock. >> >> Help! :-( >> >> I am now downgrading all the machine to 7.0 as fast as I can - though >> the >> machine I am trying to compile it on has locked up once during the >> compile >> so I havent got anywhere so far. >> >> The machines are HP Proliant DL360 G5s - they have an embedded P400i >> RAID controller with a pair of mirrored drives connected. Each one has >> both ethernets connected, bundled using lagg and LACP. >> >> > I can't tell whether my situation is related, but I am seeing lockups > on SMP Supermicro servers with both older (NetBurst-ish) and current > Xeon CPUs. I have been dropping into the kernel debugger and getting > lock information and process backtraces, but so far nothing has been > conclusively identified. I think the issue I'm seeing was introduced > sometime between October 2 and November 24 in the RELENG_7 branch, and > I suppose the next step is to do a binary search for the offending > change. > > Guy > FWIW, I think I have tracked down the changes just prior to 7.1-RELEASE that is causing my Supermicro dual Xeon machines to wedge. I did the binary search between 2008-10-02 and 2008-11-24 without reproducing any lockups, and then I went on to search between 2008-11-24 and 2009-01-04. An SMP kernel build from 2008-12-22 (r186409) sources was stable for over two weeks; a kernel built from 2008-12-29 (r186590) sources wedged in under 24 hours under moderate load. It appears that the significant changes between r186409 and r186590 were r186552 (delphij - reverted ATA changes) and r186535/r186534 (delphij - reverted bce changes). My machines don't have bce interfaces, so I suspect the ATA changes. Any thoughts? Thanks, Guy -- Guy Helmer, Ph.D. Chief System Architect Palisade Systems, Inc. From owner-freebsd-stable@FreeBSD.ORG Thu Feb 12 18:33:12 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 782BA10656E0 for ; Thu, 12 Feb 2009 18:33:12 +0000 (UTC) (envelope-from repcsike@gmail.com) Received: from mail-bw0-f170.google.com (mail-bw0-f170.google.com [209.85.218.170]) by mx1.freebsd.org (Postfix) with ESMTP id BE53C8FC14 for ; Thu, 12 Feb 2009 18:33:11 +0000 (UTC) (envelope-from repcsike@gmail.com) Received: by bwz18 with SMTP id 18so1534377bwz.19 for ; Thu, 12 Feb 2009 10:33:10 -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=qaVZut6TGiVjQLaLVxWj6kURPM0Zg7hzCWNlCuZRCLI=; b=aVXZRmwfm3N0TLZzosmXyBspKA07psdFjPFWZFdNjv88Ff1cmw9CLvFGt08L0Iwcb7 kF/EJttfcVOxJrGKyhzhRpWu7sem98G5GyzNYVzvp6mlqJ6Iegvk9iVC72kWIJt8DFtn hW8Fxg8jWt7fvpLrxKpweH8+Qy1kswW0G+uGU= 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=ZAgvTbRqUrM9wGjK78JZ93f0mGZOV9t4mANj9/xvg4hPMgbeS0SwqMPd/Rd7s2U+80 Az9w7aQhGFTUckTM75RB7YDGulY+MsSSch23iWdgnaT0lECTZXIOxS9CAEfop1D4KRyv LpTyJVH7ogwxa6FcL0sf+Zk6mR76AWwBZHR4Y= MIME-Version: 1.0 Received: by 10.223.110.211 with SMTP id o19mr1497579fap.57.1234463590608; Thu, 12 Feb 2009 10:33:10 -0800 (PST) In-Reply-To: <4994644D.8070102@thekeelecentre.com> References: <4994644D.8070102@thekeelecentre.com> Date: Thu, 12 Feb 2009 19:33:10 +0100 Message-ID: From: Kevin Smith To: Richard Tector Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-stable@freebsd.org Subject: Re: Problem with SATA/SAS 5iR X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Feb 2009 18:33:13 -0000 2009/2/12 Richard Tector > Kevin Smith wrote: > >> Hi, >> >> I have a problem with a Dell Poweredge SC440 computer. >> It's equipped with a "Dell SATA/SAS 5iR" controller, it's from LSI >> actually >> (maybe megaraid). >> >> I'm using FreeBSD 7.1 Release >> >> I have 2x 500 GB SATA in a synchronised(status optimal) RAID-1 logical >> volume. >> >> The machine is brand new, first problem arised early after the installer >> started to install the files, the install was very slow, (I know it is >> because write cache is not enabled, that can be done with a management >> program, and I will enable it later) and sysinstall could not install the >> ports collection, the error it gave was >> "write error on transfer to cpio process, try of 1024 bytes" after OK, >> write error popped up. >> >> I found this error too, but I found no clue what could have happened. >> >> Installing the system without the ports collection (installed it later >> with >> cvsup)in another run gave no error at all, and in dmesg is see the logical >> volume: >> >> mpt0:vol0(mpt0:0:0): Settings ( Hot-Plug-Spares High-Priority-ReSync ) >> mpt0:vol0(mpt0:0:0): Using Spare Pool: 0 >> mpt0:vol0(mpt0:0:0): 2 Members: >> (mpt0:1:32:0): Primary Online >> (mpt0:1:1:0): Secondary Online >> mpt0:vol0(mpt0:0:0): RAID-1 - Optimal >> mpt0:vol0(mpt0:0:0): Status ( Enabled ) >> (mpt0:vol0:1): Physical (mpt0:0:1:0), Pass-thru (mpt0:1:0:0) >> (mpt0:vol0:1): Online >> (mpt0:vol0:0): Physical (mpt0:0:32:0), Pass-thru (mpt0:1:1:0) >> (mpt0:vol0:0): Online >> da0 at mpt0 bus 0 target 0 lun 0 >> da0: Fixed Direct Access SCSI-5 device >> da0: 300.000MB/s transfers >> da0: 476837MB (976562176 512 byte sectors: 255H 63S/T 60788C) >> >> It looks OK, but then I found this after typing "df -h", and it gives me >> the >> creeps: >> >> Filesystem Size Used Avail Capacity Mounted on >> /dev/da0s1a 496M 138M 318M 30% / >> devfs 1.0K 1.0K 0B 100% /dev >> /dev/da0s1e 3.9G 14K 3.6G 0% /tmp >> /dev/da0s1f 440G 537M 404G 0% /usr >> /dev/da0s1d 2.9G 1.3M 2.7G 0% /var >> >> I'm reading the freebsd-current list, and I found another buffer related >> problem there, but they say nothing about these. >> >> If you have any explanation/solution for these problems pls share them! >> >> >> > What's wrong with the dmesg? The used/available inconsistencies are due to > space being reserved. > > Regarding disk performance, you need to put hw.mpt.enable_sata_wc=1 in > /boot/loader.conf to reenable the write cache (it's disabled by default for > consistency reasons when using SATA disks leading to poor write > performance). > > Regards, > > Richard > Thanks for your advice, this was unusual for me, because even on a 4iR I couldnt see this space reservation. What about sysinstalls write error when extracting the ports collection? Regards, B. From owner-freebsd-stable@FreeBSD.ORG Thu Feb 12 18:35:41 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 680DC1065673 for ; Thu, 12 Feb 2009 18:35:41 +0000 (UTC) (envelope-from richardtector@thekeelecentre.com) Received: from mx0.thekeelecentre.com (mx0.thekeelecentre.com [IPv6:2001:470:1f09:16f:2::3]) by mx1.freebsd.org (Postfix) with ESMTP id 228FF8FC1E for ; Thu, 12 Feb 2009 18:35:41 +0000 (UTC) (envelope-from richardtector@thekeelecentre.com) Received: from localhost (filter.mx0.thekeelecentre.com [217.206.238.165]) by mx0.thekeelecentre.com (Postfix) with ESMTP id 6CD594515D; Thu, 12 Feb 2009 18:35:40 +0000 (GMT) X-Virus-Scanned: amavisd-new at thekeelecentre.com Received: from mx0.thekeelecentre.com ([217.206.238.167]) by localhost (filter.mx0.thekeelecentre.com [217.206.238.165]) (amavisd-new, port 10024) with ESMTP id Rca-QAvGze+3; Thu, 12 Feb 2009 18:35:37 +0000 (UTC) Received: from [10.0.2.50] (daffy.tector.org.uk [82.71.32.9]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx0.thekeelecentre.com (Postfix) with ESMTPSA id 7948945151; Thu, 12 Feb 2009 18:35:37 +0000 (GMT) Message-ID: <49946BF0.5010300@thekeelecentre.com> Date: Thu, 12 Feb 2009 18:35:28 +0000 From: Richard Tector User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Kevin Smith References: <4994644D.8070102@thekeelecentre.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org Subject: Re: Problem with SATA/SAS 5iR X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Feb 2009 18:35:42 -0000 Kevin Smith wrote: > Thanks for your advice, this was unusual for me, because even on a 4iR I > couldnt see this space reservation. > > What about sysinstalls write error when extracting the ports collection? Bad install media perhaps? Have you encountered any other issues? Richard From owner-freebsd-stable@FreeBSD.ORG Thu Feb 12 20:27:06 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0B04C106564A for ; Thu, 12 Feb 2009 20:27:06 +0000 (UTC) (envelope-from ross.penner@gmail.com) Received: from yw-out-2324.google.com (yw-out-2324.google.com [74.125.46.31]) by mx1.freebsd.org (Postfix) with ESMTP id B71618FC1D for ; Thu, 12 Feb 2009 20:27:05 +0000 (UTC) (envelope-from ross.penner@gmail.com) Received: by yw-out-2324.google.com with SMTP id 2so539331ywt.13 for ; Thu, 12 Feb 2009 12:27:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:content-type:content-transfer-encoding; bh=evcO/8jcz96cMEpnPLUkepRDozsVIP3QiDlq9JQZi5k=; b=OtDNwcSv8gn25n8l+nJOeRLPBUxEL6E64H8fYWldTXWOgxgkbENDJ3a+PJe2yUYHEk 6Ub9Pey1pO0EK5Ujl9USGzGfe1oQS1C5A5cWv4eBALywmMJjbtIfwlwMxdxpbtIkx/OG ossJJXcL41Z4nJeTELJXVFDuZWFuDYMMhPNWU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type :content-transfer-encoding; b=ke4NRxqh2doKK4mEzvKjZ0oQb5M0XQdrlqqwxNgil1dy+8yQK9dEQJBodoUrNDh3yr BD/+0dcWWlq8LAigzQ/AedERoKTyQYNM0hssMczl5WhniTfhic5LgB1+Vz5twxCAo2V5 WETOV29h+WayRHTak9RadVE5V1i5kTC2QESS0= MIME-Version: 1.0 Received: by 10.90.120.14 with SMTP id s14mr265045agc.20.1234469146482; Thu, 12 Feb 2009 12:05:46 -0800 (PST) Date: Thu, 12 Feb 2009 12:05:46 -0800 Message-ID: From: Ross Penner To: freebsd-stable@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: pkg_delete segfaulting after upgrading to 7.1 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Feb 2009 20:27:06 -0000 I've recently upgraded my system to 7.1Stable. While upgrading my ports, pkg_delete spontaneously ceased functioning. Some of the ports were upgraded successfully so pkg_delete must have worked at some point. I'm sort of a novice so I'm at a loss as to how to go about diagnosing and fixing this problem. here's an example below: rosbox# pkg_delete -f gpgme-1.1.5_1 pkg_delete: package 'gpgme-1.1.5_1' is required by these other packages and may not be deinstalled (but I'll delete it anyway): seahorse-2.24.1_1 Segmentation fault (core dumped) From owner-freebsd-stable@FreeBSD.ORG Thu Feb 12 21:30:01 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F12E01065725 for ; Thu, 12 Feb 2009 21:30:01 +0000 (UTC) (envelope-from danallen46@airwired.net) Received: from mail.utahbroadband.com (mail.utahbroadband.com [204.14.20.91]) by mx1.freebsd.org (Postfix) with ESMTP id B3DD08FC23 for ; Thu, 12 Feb 2009 21:30:01 +0000 (UTC) (envelope-from danallen46@airwired.net) Received: (qmail 1665 invoked by uid 89); 12 Feb 2009 21:14:53 -0000 Received: from unknown (HELO ?192.168.0.16?) (danallen46@airwired.net@66.29.174.6) by 0 with ESMTPA; 12 Feb 2009 21:14:53 -0000 Message-Id: From: Dan Allen To: FreeBSD-STABLE Mailing List In-Reply-To: <1234293967.13304.30.camel@horst-tla> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Thu, 12 Feb 2009 14:29:49 -0700 References: <1234293967.13304.30.camel@horst-tla> X-Mailer: Apple Mail (2.930.3) Subject: Re: x48 display messed up with Xorg 7.4 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Feb 2009 21:30:02 -0000 On Wed, 11 Feb 2009 19:29:57 +0200, Esa Karkkainen wrote: > I've got screenshots at: > http://koti.welho.com/ekarkkai/x48_snap_1.jpg > http://koti.welho.com/ekarkkai/x48_snap_2.jpg Those look exactly like the problem I am having. So, what piece of Xorg causes display problems? Graphics drivers, right? Dan From owner-freebsd-stable@FreeBSD.ORG Thu Feb 12 21:34:45 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3605410656F4 for ; Thu, 12 Feb 2009 21:34:45 +0000 (UTC) (envelope-from lars@e.0x20.net) Received: from mail.0x20.net (mail.0x20.net [IPv6:2001:aa8:fffb::3]) by mx1.freebsd.org (Postfix) with ESMTP id C292D8FC21 for ; Thu, 12 Feb 2009 21:34:44 +0000 (UTC) (envelope-from lars@e.0x20.net) Received: by mail.0x20.net (Postfix, from userid 1002) id 70F1133C0D; Thu, 12 Feb 2009 22:34:43 +0100 (CET) Date: Thu, 12 Feb 2009 22:34:43 +0100 From: Lars Engels To: Patrick =?iso-8859-15?Q?Lamaizi=E8re?= Message-ID: <20090212213443.GM30761@e.0x20.net> References: <20090210134421.350f40b8@baby-jane.lamaiziere.net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="j2AXaZ4YhVcLc+PQ" Content-Disposition: inline In-Reply-To: <20090210134421.350f40b8@baby-jane.lamaiziere.net> X-Editor: VIM - Vi IMproved 7.1 X-Operation-System: FreeBSD 5.5-RELEASE-p19 User-Agent: mutt-ng/devel-r804 (FreeBSD) Cc: freebsd-stable@freebsd.org Subject: Re: Backport of glxsb(4) to RELENG_6 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Lars Engels List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Feb 2009 21:34:45 -0000 --j2AXaZ4YhVcLc+PQ Content-Type: text/plain; charset=iso-8859-15 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Feb 10, 2009 at 01:44:21PM +0100, Patrick Lamaizi=E8re wrote: > Hi, >=20 > I've backported the glxsb(4) driver to RELENG_6 (to use it on FreeNAS by > instance). >=20 > http://user.lamaiziere.net/patrick/glxsb-6-100209.tar.gz >=20 > I am not able to test it, but I hope it will work. >=20 > You can test with openssl: >=20 > openssl enc -e -aes-128-cbc -in file -out file.enc -k abcdefgh -nosalt > -engine cryptodev >=20 > Please tell me if it works or not. > Regards. I just tried it, but I get this message:=20 glxsb0: mem 0xefff4000-0xe= fff7fff irq 9 at device 1.2 on pci0 glxsb0: cannot allocate DMA memory of 32768 bytes (12) device_attach: glxsb0 attach returned 6 Lars --j2AXaZ4YhVcLc+PQ Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (FreeBSD) iEYEARECAAYFAkmUlfMACgkQKc512sD3afhyrQCeKp6T6iK1v5FNViYKLB1Lygd7 YjAAn35VyUnDqjDLxszIRLm1P0hqarIr =ddDQ -----END PGP SIGNATURE----- --j2AXaZ4YhVcLc+PQ-- From owner-freebsd-stable@FreeBSD.ORG Thu Feb 12 22:22:35 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 67FEC1065672 for ; Thu, 12 Feb 2009 22:22:35 +0000 (UTC) (envelope-from repcsike@gmail.com) Received: from mail-bw0-f170.google.com (mail-bw0-f170.google.com [209.85.218.170]) by mx1.freebsd.org (Postfix) with ESMTP id B82558FC15 for ; Thu, 12 Feb 2009 22:22:34 +0000 (UTC) (envelope-from repcsike@gmail.com) Received: by bwz18 with SMTP id 18so1704032bwz.19 for ; Thu, 12 Feb 2009 14:22: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; bh=otfqlapsS6AgsYzJGRx+JiWwUUV1vA3KdOBwq0bbPpk=; b=tZeCHXKZ4I53y2ZWv3puDdc/g4SnRy151ibV++eLhXBN4ds1zsc/TA55luyZfAuPFs tPRRVqDaxJyYtNcBiVmHzCQpxKrOfF/9c0RwKidjecUjqtEGPxCNpR+0oUc93iaUFqiF mOX5hAKBTkLWgKv1luXal2nJp56+0P8muNx7Y= 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=eb3o/FoOz9g+CK0XVUJab1uff9ZixJ+o/jgqPXccwT+WGgBpDCkJMkPpFbrI23k38a DOkC/XIoPZOi+xoGWITbWtidGCiZLJjcbawB3nTBiO09Y9U/rHTSzgRTZ2avt3ajKXe3 V+39cYO2Q3WcoQUka8uwwqrqe+Z+nsWDnCfWM= MIME-Version: 1.0 Received: by 10.223.109.148 with SMTP id j20mr1801229fap.43.1234477353256; Thu, 12 Feb 2009 14:22:33 -0800 (PST) In-Reply-To: <49946BF0.5010300@thekeelecentre.com> References: <4994644D.8070102@thekeelecentre.com> <49946BF0.5010300@thekeelecentre.com> Date: Thu, 12 Feb 2009 23:22:33 +0100 Message-ID: From: Kevin Smith To: Richard Tector Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-stable@freebsd.org Subject: Re: Problem with SATA/SAS 5iR X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Feb 2009 22:22:35 -0000 2009/2/12 Richard Tector > Kevin Smith wrote: > >> Thanks for your advice, this was unusual for me, because even on a 4iR I >> couldnt see this space reservation. >> >> What about sysinstalls write error when extracting the ports collection? >> > > Bad install media perhaps? Have you encountered any other issues? > > Richard > Reinstalled the box just for kicks, and now the media was an FTP site, it looks like the culprit was the optical drive which is an Optiarc AD-5200A, using a CD and a DVD both gave me the error, now it went down alright, using the optical only for booting up. Just another thing, can you change or monitor the behaviour of this spare space reservation? Looking into man mpt gave nothing useful regarding this issue. Adding hw.mpt.enable_sata_wc to the loader conf made everything much faster, before that the computer used the disks all the time. Thank you for your help Richard, Best Regards, B. From owner-freebsd-stable@FreeBSD.ORG Fri Feb 13 00:17:07 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0D3A21065670 for ; Fri, 13 Feb 2009 00:17:07 +0000 (UTC) (envelope-from richardtector@thekeelecentre.com) Received: from mx0.thekeelecentre.com (mx0.thekeelecentre.com [IPv6:2001:470:1f09:16f:2::3]) by mx1.freebsd.org (Postfix) with ESMTP id B9B828FC18 for ; Fri, 13 Feb 2009 00:17:06 +0000 (UTC) (envelope-from richardtector@thekeelecentre.com) Received: from localhost (filter.mx0.thekeelecentre.com [217.206.238.165]) by mx0.thekeelecentre.com (Postfix) with ESMTP id 8A89445151; Fri, 13 Feb 2009 00:17:04 +0000 (GMT) X-Virus-Scanned: amavisd-new at thekeelecentre.com Received: from mx0.thekeelecentre.com ([217.206.238.167]) by localhost (filter.mx0.thekeelecentre.com [217.206.238.165]) (amavisd-new, port 10024) with ESMTP id 2EJ+shSjof8C; Fri, 13 Feb 2009 00:17:02 +0000 (UTC) Received: from [10.0.2.50] (daffy.tector.org.uk [82.71.32.9]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx0.thekeelecentre.com (Postfix) with ESMTPSA id 2DB3145020; Fri, 13 Feb 2009 00:17:01 +0000 (GMT) Message-ID: <4994BBF4.30603@thekeelecentre.com> Date: Fri, 13 Feb 2009 00:16:52 +0000 From: Richard Tector User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Kevin Smith References: <4994644D.8070102@thekeelecentre.com> <49946BF0.5010300@thekeelecentre.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org Subject: Re: Problem with SATA/SAS 5iR X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Feb 2009 00:17:07 -0000 Kevin Smith wrote: > Just another thing, can you change or monitor the behaviour of this spare > space reservation? Looking into man mpt gave nothing useful regarding this > issue. The tunefs manpage has a little about the space reservation. You can set it with -m IIRC when doing the newfs, but I believe it's generally best to leave it at the default. Note that root can still use the space, just not ordinary users (this leads to negative available space reported by df). Regards, Richard From owner-freebsd-stable@FreeBSD.ORG Fri Feb 13 01:31:42 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5C9121065670 for ; Fri, 13 Feb 2009 01:31:42 +0000 (UTC) (envelope-from karl@denninger.net) Received: from FS.denninger.net (wsip-70-169-168-7.pn.at.cox.net [70.169.168.7]) by mx1.freebsd.org (Postfix) with ESMTP id 1528E8FC0C for ; Fri, 13 Feb 2009 01:31:41 +0000 (UTC) (envelope-from karl@denninger.net) Received: from [192.168.1.40] (localhost [127.0.0.1]) by FS.denninger.net (8.14.3/8.13.1) with SMTP id n1D1VfSm028832 for ; Thu, 12 Feb 2009 19:31:42 -0600 (CST) (envelope-from karl@denninger.net) Received: from [192.168.1.40] [192.168.1.40] by Spamblock-sys (LOCAL); Thu Feb 12 19:31:42 2009 Message-ID: <4994CD7B.7040302@denninger.net> Date: Thu, 12 Feb 2009 19:31:39 -0600 From: Karl Denninger User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: freebsd-stable@freebsd.org Content-Type: multipart/mixed; boundary="------------030900040108000301090307" X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Upgrade from 32-bit to AMD-64? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Feb 2009 01:31:42 -0000 This is a multi-part message in MIME format. --------------030900040108000301090307 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit I have a machine that can run either (proved, I can boot the AMD-64 release disk) Can I SOURCE UPGRADE from one to the other? That is, is it possible to do a "make buildworld", "make buildkernel" and then "make installkernel" and wind up with AMD64 instead of the 32-bit code? Or must I reinstall? It APPEARS I can run most 32-bit code on a 64-bit system. Not all works, but most does. -- -- Karl Denninger karl@denninger.net --------------030900040108000301090307-- From owner-freebsd-stable@FreeBSD.ORG Fri Feb 13 02:08:13 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C2B29106566B for ; Fri, 13 Feb 2009 02:08:13 +0000 (UTC) (envelope-from delphij@delphij.net) Received: from tarsier.delphij.net (delphij-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:2c9::2]) by mx1.freebsd.org (Postfix) with ESMTP id 68E1D8FC18 for ; Fri, 13 Feb 2009 02:08:13 +0000 (UTC) (envelope-from delphij@delphij.net) Received: from tarsier.geekcn.org (tarsier.geekcn.org [211.166.10.233]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by tarsier.delphij.net (Postfix) with ESMTPS id 847D328448 for ; Fri, 13 Feb 2009 10:08:12 +0800 (CST) Received: from localhost (tarsier.geekcn.org [211.166.10.233]) by tarsier.geekcn.org (Postfix) with ESMTP id 27FA4EC6E2D; Fri, 13 Feb 2009 10:08:12 +0800 (CST) X-Virus-Scanned: amavisd-new at geekcn.org Received: from tarsier.geekcn.org ([211.166.10.233]) by localhost (mail.geekcn.org [211.166.10.233]) (amavisd-new, port 10024) with ESMTP id eJy0SzkuvrUZ; Fri, 13 Feb 2009 10:08:07 +0800 (CST) Received: from charlie.delphij.net (adsl-76-237-33-62.dsl.pltn13.sbcglobal.net [76.237.33.62]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by tarsier.geekcn.org (Postfix) with ESMTPSA id D8306EC6E2A; Fri, 13 Feb 2009 10:08:05 +0800 (CST) DomainKey-Signature: a=rsa-sha1; s=default; d=delphij.net; c=nofws; q=dns; h=message-id:date:from:reply-to:organization:user-agent: mime-version:to:cc:subject:references:in-reply-to: x-enigmail-version:openpgp:content-type:content-transfer-encoding; b=HihdKVK+cjnR79PJlZmThfgeo5OUogC/9aW/pa4whuHaub3cOygxwg7HflGTELWgl EtWkpbfrWTyvImRvkxxxQ== Message-ID: <4994D603.2060406@delphij.net> Date: Thu, 12 Feb 2009 18:08:03 -0800 From: Xin LI Organization: The FreeBSD Project User-Agent: Thunderbird 2.0.0.19 (X11/20090202) MIME-Version: 1.0 To: Karl Denninger References: <4994CD7B.7040302@denninger.net> In-Reply-To: <4994CD7B.7040302@denninger.net> X-Enigmail-Version: 0.95.7 OpenPGP: id=18EDEBA0; url=http://www.delphij.net/delphij.asc Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org Subject: Re: Upgrade from 32-bit to AMD-64? 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: Fri, 13 Feb 2009 02:08:14 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, Karl, Karl Denninger wrote: > I have a machine that can run either (proved, I can boot the AMD-64 > release disk) > > Can I SOURCE UPGRADE from one to the other? That is, is it possible to > do a "make buildworld", "make buildkernel" and then "make installkernel" > and wind up with AMD64 instead of the 32-bit code? > > Or must I reinstall? > > It APPEARS I can run most 32-bit code on a 64-bit system. Not all > works, but most does. This is sort of "doable" but "highly recommend you not to do that" thing. The simplest way to do 32-bit to 64-bit upgrade would be to backup your data, install from scratch, then restore data; mixing 32-bit and 64-bit stuff together, especially without 32-bit stuff moved to the right place, is among the most terrible mess you wanted to avoid. Online "upgrade" can be done if you have your 64-bit world/kernel built and installed into a separate directory (i.e. make world kernel DESTDIR=/path/to/a/temp/place), then drop into single user mode, then tar then pipe to another tar to extract the whole thing to /, but this is really a "foot, gun, shoot" thing. Cheers, - -- Xin LI http://www.delphij.net/ FreeBSD - The Power to Serve! -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.10 (FreeBSD) iEYEARECAAYFAkmU1gMACgkQi+vbBBjt66CLMQCfU77Cxz1YshGJb5C455GIGbXt vvMAn25KgUnJqEmQRbrxnxucD+CTdFyf =DiuA -----END PGP SIGNATURE----- From owner-freebsd-stable@FreeBSD.ORG Fri Feb 13 02:21:38 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A6140106566B for ; Fri, 13 Feb 2009 02:21:38 +0000 (UTC) (envelope-from karl@denninger.net) Received: from FS.denninger.net (wsip-70-169-168-7.pn.at.cox.net [70.169.168.7]) by mx1.freebsd.org (Postfix) with ESMTP id 495F48FC13 for ; Fri, 13 Feb 2009 02:21:38 +0000 (UTC) (envelope-from karl@denninger.net) Received: from [192.168.1.40] (localhost [127.0.0.1]) by FS.denninger.net (8.14.3/8.13.1) with SMTP id n1D2LcCJ055494 for ; Thu, 12 Feb 2009 20:21:38 -0600 (CST) (envelope-from karl@denninger.net) Received: from [192.168.1.40] [192.168.1.40] by Spamblock-sys (LOCAL); Thu Feb 12 20:21:38 2009 Message-ID: <4994D931.4060508@denninger.net> Date: Thu, 12 Feb 2009 20:21:37 -0600 From: Karl Denninger User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: freebsd-stable@freebsd.org References: <4994CD7B.7040302@denninger.net> <4994D603.2060406@delphij.net> In-Reply-To: <4994D603.2060406@delphij.net> Content-Type: multipart/mixed; boundary="------------060105040109000800010707" X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Re: Upgrade from 32-bit to AMD-64? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Feb 2009 02:21:38 -0000 This is a multi-part message in MIME format. --------------060105040109000800010707 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Xin LI wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Hi, Karl, > > Karl Denninger wrote: > >> I have a machine that can run either (proved, I can boot the AMD-64 >> release disk) >> >> Can I SOURCE UPGRADE from one to the other? That is, is it possible to >> do a "make buildworld", "make buildkernel" and then "make installkernel" >> and wind up with AMD64 instead of the 32-bit code? >> >> Or must I reinstall? >> >> It APPEARS I can run most 32-bit code on a 64-bit system. Not all >> works, but most does. >> > > This is sort of "doable" but "highly recommend you not to do that" > thing. The simplest way to do 32-bit to 64-bit upgrade would be to > backup your data, install from scratch, then restore data; mixing 32-bit > and 64-bit stuff together, especially without 32-bit stuff moved to the > right place, is among the most terrible mess you wanted to avoid. > > Online "upgrade" can be done if you have your 64-bit world/kernel built > and installed into a separate directory (i.e. make world kernel > DESTDIR=/path/to/a/temp/place), then drop into single user mode, then > tar then pipe to another tar to extract the whole thing to /, but this > is really a "foot, gun, shoot" thing. > > Cheers, > - -- > Xin LI http://www.delphij.net/ > > Hmmmm.... I was thinking something like this (I have the cvsup tree on the machine) 1. Compile into /usr/robj for amd64 (if I can figure out how to get make to do it - the obvious, MACHINE_ARCH=amd64, does not work - it barfs.) 2. Intentionally break the mirror (just in case) from the controller; I've now got a clean bootable drive if something goes wrong. 3. "make installkernel" (install new amd64 kernel) 4. Reboot Now, the question - will the 32-bit executables RUN under the 64-bit kernel under single-user so I can "make installworld"? Or do I get screwed instantly when I reboot? -- -- Karl Denninger karl@denninger.net --------------060105040109000800010707-- From owner-freebsd-stable@FreeBSD.ORG Fri Feb 13 02:28:39 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3499F1065672 for ; Fri, 13 Feb 2009 02:28:39 +0000 (UTC) (envelope-from delphij@delphij.net) Received: from tarsier.delphij.net (delphij-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:2c9::2]) by mx1.freebsd.org (Postfix) with ESMTP id A44798FC1D for ; Fri, 13 Feb 2009 02:28:38 +0000 (UTC) (envelope-from delphij@delphij.net) Received: from tarsier.geekcn.org (tarsier.geekcn.org [211.166.10.233]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by tarsier.delphij.net (Postfix) with ESMTPS id B700F28448 for ; Fri, 13 Feb 2009 10:28:37 +0800 (CST) Received: from localhost (tarsier.geekcn.org [211.166.10.233]) by tarsier.geekcn.org (Postfix) with ESMTP id 598F3EC6E17; Fri, 13 Feb 2009 10:28:37 +0800 (CST) X-Virus-Scanned: amavisd-new at geekcn.org Received: from tarsier.geekcn.org ([211.166.10.233]) by localhost (mail.geekcn.org [211.166.10.233]) (amavisd-new, port 10024) with ESMTP id NQ157nlQdsrV; Fri, 13 Feb 2009 10:28:32 +0800 (CST) Received: from charlie.delphij.net (adsl-76-237-33-62.dsl.pltn13.sbcglobal.net [76.237.33.62]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by tarsier.geekcn.org (Postfix) with ESMTPSA id C7D5EEC6ADF; Fri, 13 Feb 2009 10:28:30 +0800 (CST) DomainKey-Signature: a=rsa-sha1; s=default; d=delphij.net; c=nofws; q=dns; h=message-id:date:from:reply-to:organization:user-agent: mime-version:to:cc:subject:references:in-reply-to: x-enigmail-version:openpgp:content-type:content-transfer-encoding; b=UW7CCqaLoU5wqGeTPesbqu73au0K5X18bd7efqXysZA4ZCZMCnKD0lwQXPkYC6AzR LfzAaBdpaoLnjXRQ5eG5g== Message-ID: <4994DACC.1040801@delphij.net> Date: Thu, 12 Feb 2009 18:28:28 -0800 From: Xin LI Organization: The FreeBSD Project User-Agent: Thunderbird 2.0.0.19 (X11/20090202) MIME-Version: 1.0 To: Karl Denninger References: <4994CD7B.7040302@denninger.net> <4994D603.2060406@delphij.net> <4994D931.4060508@denninger.net> In-Reply-To: <4994D931.4060508@denninger.net> X-Enigmail-Version: 0.95.7 OpenPGP: id=18EDEBA0; url=http://www.delphij.net/delphij.asc Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org Subject: Re: Upgrade from 32-bit to AMD-64? 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: Fri, 13 Feb 2009 02:28:39 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Karl Denninger wrote: > > Xin LI wrote: >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> >> Hi, Karl, >> >> Karl Denninger wrote: >> >>> I have a machine that can run either (proved, I can boot the AMD-64 >>> release disk) >>> >>> Can I SOURCE UPGRADE from one to the other? That is, is it possible to >>> do a "make buildworld", "make buildkernel" and then "make installkernel" >>> and wind up with AMD64 instead of the 32-bit code? >>> >>> Or must I reinstall? >>> >>> It APPEARS I can run most 32-bit code on a 64-bit system. Not all >>> works, but most does. >>> >> >> This is sort of "doable" but "highly recommend you not to do that" >> thing. The simplest way to do 32-bit to 64-bit upgrade would be to >> backup your data, install from scratch, then restore data; mixing 32-bit >> and 64-bit stuff together, especially without 32-bit stuff moved to the >> right place, is among the most terrible mess you wanted to avoid. >> >> Online "upgrade" can be done if you have your 64-bit world/kernel built >> and installed into a separate directory (i.e. make world kernel >> DESTDIR=/path/to/a/temp/place), then drop into single user mode, then >> tar then pipe to another tar to extract the whole thing to /, but this >> is really a "foot, gun, shoot" thing. >> >> Cheers, >> - -- >> Xin LI http://www.delphij.net/ >> >> > Hmmmm.... I was thinking something like this (I have the cvsup tree on > the machine) > > 1. Compile into /usr/robj for amd64 (if I can figure out how to get make > to do it - the obvious, MACHINE_ARCH=amd64, does not work - it barfs.) > > 2. Intentionally break the mirror (just in case) from the controller; > I've now got a clean bootable drive if something goes wrong. > > 3. "make installkernel" (install new amd64 kernel) > > 4. Reboot > > Now, the question - will the 32-bit executables RUN under the 64-bit > kernel under single-user so I can "make installworld"? Yes as long as you compiled COMPAT_FREEBSD32 you can run 32-bit executables under a 64-bit kernel, but, you need to be careful since the dynamic linker would have different name. > Or do I get screwed instantly when I reboot? There is a reason we don't recommend doing that :) Cheers, - -- Xin LI http://www.delphij.net/ FreeBSD - The Power to Serve! -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.10 (FreeBSD) iEYEARECAAYFAkmU2swACgkQi+vbBBjt66CvjwCggpu439Rif7SzKnrOjpTFtCH1 CwUAnjRflrkmlrLlJvhCEJq5kUk8nPGd =rwVa -----END PGP SIGNATURE----- From owner-freebsd-stable@FreeBSD.ORG Fri Feb 13 02:32:35 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 801A7106564A for ; Fri, 13 Feb 2009 02:32:35 +0000 (UTC) (envelope-from karl@denninger.net) Received: from FS.denninger.net (wsip-70-169-168-7.pn.at.cox.net [70.169.168.7]) by mx1.freebsd.org (Postfix) with ESMTP id 253158FC15 for ; Fri, 13 Feb 2009 02:32:34 +0000 (UTC) (envelope-from karl@denninger.net) Received: from [192.168.1.40] (localhost [127.0.0.1]) by FS.denninger.net (8.14.3/8.13.1) with SMTP id n1D2WYH0061371 for ; Thu, 12 Feb 2009 20:32:35 -0600 (CST) (envelope-from karl@denninger.net) Received: from [192.168.1.40] [192.168.1.40] by Spamblock-sys (LOCAL); Thu Feb 12 20:32:35 2009 Message-ID: <4994DBC1.2000309@denninger.net> Date: Thu, 12 Feb 2009 20:32:33 -0600 From: Karl Denninger User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: freebsd-stable@freebsd.org References: <4994CD7B.7040302@denninger.net> <4994D603.2060406@delphij.net> <4994D931.4060508@denninger.net> <4994DACC.1040801@delphij.net> In-Reply-To: <4994DACC.1040801@delphij.net> Content-Type: multipart/mixed; boundary="------------020400020706080708090506" X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Re: Upgrade from 32-bit to AMD-64? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Feb 2009 02:32:35 -0000 This is a multi-part message in MIME format. --------------020400020706080708090506 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Xin LI wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Karl Denninger wrote: > >> Xin LI wrote: >> >>> -----BEGIN PGP SIGNED MESSAGE----- >>> Hash: SHA1 >>> >>> Hi, Karl, >>> >>> Karl Denninger wrote: >>> >>> >>>> I have a machine that can run either (proved, I can boot the AMD-64 >>>> release disk) >>>> >>>> Can I SOURCE UPGRADE from one to the other? That is, is it possible to >>>> do a "make buildworld", "make buildkernel" and then "make installkernel" >>>> and wind up with AMD64 instead of the 32-bit code? >>>> >>>> Or must I reinstall? >>>> >>>> It APPEARS I can run most 32-bit code on a 64-bit system. Not all >>>> works, but most does. >>>> >>>> >>> This is sort of "doable" but "highly recommend you not to do that" >>> thing. The simplest way to do 32-bit to 64-bit upgrade would be to >>> backup your data, install from scratch, then restore data; mixing 32-bit >>> and 64-bit stuff together, especially without 32-bit stuff moved to the >>> right place, is among the most terrible mess you wanted to avoid. >>> >>> Online "upgrade" can be done if you have your 64-bit world/kernel built >>> and installed into a separate directory (i.e. make world kernel >>> DESTDIR=/path/to/a/temp/place), then drop into single user mode, then >>> tar then pipe to another tar to extract the whole thing to /, but this >>> is really a "foot, gun, shoot" thing. >>> >>> Cheers, >>> - -- >>> Xin LI http://www.delphij.net/ >>> >>> >>> >> Hmmmm.... I was thinking something like this (I have the cvsup tree on >> the machine) >> >> 1. Compile into /usr/robj for amd64 (if I can figure out how to get make >> to do it - the obvious, MACHINE_ARCH=amd64, does not work - it barfs.) >> >> 2. Intentionally break the mirror (just in case) from the controller; >> I've now got a clean bootable drive if something goes wrong. >> >> 3. "make installkernel" (install new amd64 kernel) >> >> 4. Reboot >> >> Now, the question - will the 32-bit executables RUN under the 64-bit >> kernel under single-user so I can "make installworld"? >> > > Yes as long as you compiled COMPAT_FREEBSD32 you can run 32-bit > executables under a 64-bit kernel, but, you need to be careful since the > dynamic linker would have different name. > >> Or do I get screwed instantly when I reboot? >> > > There is a reason we don't recommend doing that :) > > Cheers, > - -- > Xin LI http://www.delphij.net/ > ROFL! Ok, I get it. I'm asking to get hosed as soon as I reboot..... I CAN reload the machine but it would take the machine out of service for MUCH LESS TIME if I could do it this way; a full reload is going to take a couple of hours, where I can do it that way in ~5-10 minutes of downtime. Of course if its going to blow up..... I guess I need to schedule the 2-3 hours of downtime..... the reason for this, by the way, is that I have a dbms app on there that is getting too RAM hungry for its own good (its a Quadcore CPU) and I'm up against the RAM limit for 32-bit code. The board will support more but 32-bit code won't; ergo, the only way to get beyond this is to go to 64-bit. -- -- Karl Denninger karl@denninger.net --------------020400020706080708090506-- From owner-freebsd-stable@FreeBSD.ORG Fri Feb 13 02:43:32 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E8C531065673 for ; Fri, 13 Feb 2009 02:43:32 +0000 (UTC) (envelope-from cswiger@mac.com) Received: from asmtpout019.mac.com (asmtpout019.mac.com [17.148.16.94]) by mx1.freebsd.org (Postfix) with ESMTP id D5C9F8FC16 for ; Fri, 13 Feb 2009 02:43:32 +0000 (UTC) (envelope-from cswiger@mac.com) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Received: from cswiger1.apple.com ([17.227.140.124]) by asmtp019.mac.com (Sun Java(tm) System Messaging Server 6.3-7.03 (built Aug 7 2008; 32bit)) with ESMTPSA id <0KEZ00CRJE3YE080@asmtp019.mac.com> for freebsd-stable@freebsd.org; Thu, 12 Feb 2009 17:43:11 -0800 (PST) Message-id: From: Chuck Swiger To: Karl Denninger In-reply-to: <4994CD7B.7040302@denninger.net> Date: Thu, 12 Feb 2009 17:43:10 -0800 References: <4994CD7B.7040302@denninger.net> X-Mailer: Apple Mail (2.930.3) Cc: freebsd-stable@freebsd.org Subject: Re: Upgrade from 32-bit to AMD-64? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Feb 2009 02:43:33 -0000 On Feb 12, 2009, at 5:31 PM, Karl Denninger wrote: > I have a machine that can run either (proved, I can boot the AMD-64 > release disk) > > Can I SOURCE UPGRADE from one to the other? That is, is it possible > to do a "make buildworld", "make buildkernel" and then "make > installkernel" and wind up with AMD64 instead of the 32-bit code? > > Or must I reinstall? Sure, it's possible, given sufficient toolchain knowledge, time, and skills, but it's not a sensible thing to do aside from experimentation and learning purposes. The recommended course is to determine the platform which best suits your requirements and the available hardware: ie, are you doing database stuff, SSL, or arbitrary-precision math which would really benefit from the 64-bit architecture; does the machine have more than 3 GB of RAM; does the machine have hardware (like a graphics card) which has better 32-bit drivers, etc. > It APPEARS I can run most 32-bit code on a 64-bit system. Not all > works, but most does. Right, the vast majority of 32-bit binaries should work just fine on a 64-bit platform.... Regards, -- -Chuck From owner-freebsd-stable@FreeBSD.ORG Fri Feb 13 02:49:30 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 95E621065670 for ; Fri, 13 Feb 2009 02:49:30 +0000 (UTC) (envelope-from delphij@delphij.net) Received: from tarsier.delphij.net (delphij-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:2c9::2]) by mx1.freebsd.org (Postfix) with ESMTP id 397238FC32 for ; Fri, 13 Feb 2009 02:49:30 +0000 (UTC) (envelope-from delphij@delphij.net) Received: from tarsier.geekcn.org (tarsier.geekcn.org [211.166.10.233]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by tarsier.delphij.net (Postfix) with ESMTPS id 6919228449 for ; Fri, 13 Feb 2009 10:49:29 +0800 (CST) Received: from localhost (tarsier.geekcn.org [211.166.10.233]) by tarsier.geekcn.org (Postfix) with ESMTP id 14780EC6E63; Fri, 13 Feb 2009 10:49:29 +0800 (CST) X-Virus-Scanned: amavisd-new at geekcn.org Received: from tarsier.geekcn.org ([211.166.10.233]) by localhost (mail.geekcn.org [211.166.10.233]) (amavisd-new, port 10024) with ESMTP id 83wkT3P7ClV0; Fri, 13 Feb 2009 10:49:24 +0800 (CST) Received: from charlie.delphij.net (adsl-76-237-33-62.dsl.pltn13.sbcglobal.net [76.237.33.62]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by tarsier.geekcn.org (Postfix) with ESMTPSA id D9D2DEC6945; Fri, 13 Feb 2009 10:49:22 +0800 (CST) DomainKey-Signature: a=rsa-sha1; s=default; d=delphij.net; c=nofws; q=dns; h=message-id:date:from:reply-to:organization:user-agent: mime-version:to:cc:subject:references:in-reply-to: x-enigmail-version:openpgp:content-type:content-transfer-encoding; b=IY1YSstLuAYK9Oc2mOoGUlzuvCjAe2piA1W0zsEb/bcNHFuE7CSxrLSfogwlOemdG X2n20V9XCDo7eNRiUqjEg== Message-ID: <4994DFB0.3060704@delphij.net> Date: Thu, 12 Feb 2009 18:49:20 -0800 From: Xin LI Organization: The FreeBSD Project User-Agent: Thunderbird 2.0.0.19 (X11/20090202) MIME-Version: 1.0 To: Karl Denninger References: <4994CD7B.7040302@denninger.net> <4994D603.2060406@delphij.net> <4994D931.4060508@denninger.net> <4994DACC.1040801@delphij.net> <4994DBC1.2000309@denninger.net> In-Reply-To: <4994DBC1.2000309@denninger.net> X-Enigmail-Version: 0.95.7 OpenPGP: id=18EDEBA0; url=http://www.delphij.net/delphij.asc Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org Subject: Re: Upgrade from 32-bit to AMD-64? 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: Fri, 13 Feb 2009 02:49:31 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Karl Denninger wrote: [...] > I guess I need to schedule the 2-3 hours of downtime..... the reason for > this, by the way, is that I have a dbms app on there that is getting too > RAM hungry for its own good (its a Quadcore CPU) and I'm up against the > RAM limit for 32-bit code. The board will support more but 32-bit code > won't; ergo, the only way to get beyond this is to go to 64-bit. Oh wait! One thing you wanted to know is that, some database *can* have different on-disk format for 32-bit and 64-bit binaries. Be sure to have a dump handy. Last time I hit this on a MySQL "upgrade" between two servers, and I end up using its replication functionality. The operation took longer time than I expected at the beginning. My personal suggestion is that you do an experiment on another box (64-bit capable) to make sure that the data would work, this never hurts and avoids surprises (you do want 64-bit compile of your database application since you want to take full advantage of 64-bit OS); also, just like all upgrades, full backup is advised. Cheers, - -- Xin LI http://www.delphij.net/ FreeBSD - The Power to Serve! -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.10 (FreeBSD) iEYEARECAAYFAkmU37AACgkQi+vbBBjt66BzlwCfUuQuTY8rXnhE/T1K9BNIZ7bi j9sAoJiPJApQrX5Gwd4kfFWoiGfQs44g =0oRk -----END PGP SIGNATURE----- From owner-freebsd-stable@FreeBSD.ORG Fri Feb 13 03:01:40 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9AF0B106566B for ; Fri, 13 Feb 2009 03:01:40 +0000 (UTC) (envelope-from karl@denninger.net) Received: from FS.denninger.net (wsip-70-169-168-7.pn.at.cox.net [70.169.168.7]) by mx1.freebsd.org (Postfix) with ESMTP id 5461D8FC17 for ; Fri, 13 Feb 2009 03:01:40 +0000 (UTC) (envelope-from karl@denninger.net) Received: from [192.168.1.40] (localhost [127.0.0.1]) by FS.denninger.net (8.14.3/8.13.1) with SMTP id n1D31eoq077159 for ; Thu, 12 Feb 2009 21:01:40 -0600 (CST) (envelope-from karl@denninger.net) Received: from [192.168.1.40] [192.168.1.40] by Spamblock-sys (LOCAL); Thu Feb 12 21:01:40 2009 Message-ID: <4994E292.4000802@denninger.net> Date: Thu, 12 Feb 2009 21:01:38 -0600 From: Karl Denninger User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: freebsd-stable@freebsd.org References: <4994CD7B.7040302@denninger.net> <4994D603.2060406@delphij.net> <4994D931.4060508@denninger.net> <4994DACC.1040801@delphij.net> <4994DBC1.2000309@denninger.net> <4994DFB0.3060704@delphij.net> In-Reply-To: <4994DFB0.3060704@delphij.net> Content-Type: multipart/mixed; boundary="------------030301040102000908050404" X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Re: Upgrade from 32-bit to AMD-64? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Feb 2009 03:01:40 -0000 This is a multi-part message in MIME format. --------------030301040102000908050404 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Xin LI wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Karl Denninger wrote: > [...] > >> I guess I need to schedule the 2-3 hours of downtime..... the reason for >> this, by the way, is that I have a dbms app on there that is getting too >> RAM hungry for its own good (its a Quadcore CPU) and I'm up against the >> RAM limit for 32-bit code. The board will support more but 32-bit code >> won't; ergo, the only way to get beyond this is to go to 64-bit. >> > > Oh wait! One thing you wanted to know is that, some database *can* have > different on-disk format for 32-bit and 64-bit binaries. Be sure to > have a dump handy. Last time I hit this on a MySQL "upgrade" between > two servers, and I end up using its replication functionality. The > operation took longer time than I expected at the beginning. > > My personal suggestion is that you do an experiment on another box > (64-bit capable) to make sure that the data would work, this never hurts > and avoids surprises (you do want 64-bit compile of your database > application since you want to take full advantage of 64-bit OS); also, > just like all upgrades, full backup is advised. > > Cheers, > - -- > Xin LI http://www.delphij.net I already know I have to dump the database and then reload it - I attempted to migrate the disk structure across (which would have saved even more time) and got instantaneously hosed, presumably due to internal data type length differences. This little upgrade is going to take a while; sounds like the best approach is to load a new box, shut down the dbms to connections and dump/pipe it over, then physically swap the machines. Thanks. -- -- Karl Denninger karl@denninger.net --------------030301040102000908050404-- From owner-freebsd-stable@FreeBSD.ORG Fri Feb 13 04:35:19 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7B162106568B; Fri, 13 Feb 2009 04:35:19 +0000 (UTC) (envelope-from bms@FreeBSD.org) Received: from out4.smtp.messagingengine.com (out4.smtp.messagingengine.com [66.111.4.28]) by mx1.freebsd.org (Postfix) with ESMTP id ECB218FC0C; Fri, 13 Feb 2009 04:35:18 +0000 (UTC) (envelope-from bms@FreeBSD.org) Received: from compute1.internal (compute1.internal [10.202.2.41]) by out1.messagingengine.com (Postfix) with ESMTP id EF8F2294364; Thu, 12 Feb 2009 23:35:17 -0500 (EST) Received: from heartbeat2.messagingengine.com ([10.202.2.161]) by compute1.internal (MEProxy); Thu, 12 Feb 2009 23:35:18 -0500 X-Sasl-enc: mWPyR+yBYo03dV/MwqSaoo1eYGtyuLGYHAXveHkmLmSQ 1234499715 Received: from empiric.lon.incunabulum.net (82-35-112-254.cable.ubr07.dals.blueyonder.co.uk [82.35.112.254]) by mail.messagingengine.com (Postfix) with ESMTPSA id 550C62DC61; Thu, 12 Feb 2009 23:35:15 -0500 (EST) Message-ID: <4994F882.7000903@FreeBSD.org> Date: Fri, 13 Feb 2009 04:35:14 +0000 From: "Bruce M. Simpson" User-Agent: Thunderbird 2.0.0.19 (X11/20090126) MIME-Version: 1.0 To: Robert Noland References: <329181233306971@webmail57.yandex.ru> <985A59F2-20CC-4779-A000-018E52B5BFA9@jump-ing.de> <101781233319948@webmail36.yandex.ru> <4983A3AE.90804@FreeBSD.org> <498F901A.7000900@FreeBSD.org> <1234159237.23838.3.camel@ferret.2hip.net> <4990835A.3020303@FreeBSD.org> <1234208586.1524.17.camel@ferret.2hip.net> <4990BC99.1070108@FreeBSD.org> <1234246034.1524.27.camel@ferret.2hip.net> <4991C017.8080903@FreeBSD.org> <1234292252.1524.38.camel@ferret.2hip.net> In-Reply-To: <1234292252.1524.38.camel@ferret.2hip.net> X-Enigmail-Version: 0.95.6 Content-Type: multipart/mixed; boundary="------------030503010103000806030906" Cc: "S.N.Grigoriev" , Markus Hitter , freebsd-stable@freebsd.org Subject: Re: Unhappy Xorg upgrade X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Feb 2009 04:35:20 -0000 This is a multi-part message in MIME format. --------------030503010103000806030906 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Robert Noland wrote: > Ok, At least we know where the issue lies now. I'll try and look the > code over again, but I behaves almost identically to the kernel routines > I think. jhb@ wrote us a new ioctl to avoid doing most of this from > userland, but it will be a while before we can count on it's existence > and it doesn't support bios frobbing yet. > > Can you verify that pciconf -lvbc does not trigger the issue? > Looks completely fine. I can't trigger the issue with pciconf alone. BTW: the 'b' seems to be ignored unless used as part of 'pciconf -b '. I tried using pciconf to read the first 2 bytes of config space of the controller which is normally affected, as you can see in the log, and this caused no problems. --------------030503010103000806030906 Content-Type: text/plain; name="fu" Content-Transfer-Encoding: base64 Content-Disposition: inline; filename="fu" U2NyaXB0IHN0YXJ0ZWQgb24gRnJpIEZlYiAxMyAwNDoyNzo1NSAyMDA5CllvdSBoYXZlIG1h aWwuDQphbmdsZXBvaXNlIyB1c2JkZXZzIC12DQ0KQ29udHJvbGxlciAvZGV2L3VzYjA6DQph ZGRyIDE6IGZ1bGwgc3BlZWQsIHNlbGYgcG93ZXJlZCwgY29uZmlnIDEsIE9IQ0kgcm9vdCBo dWIoMHgwMDAwKSwgQWNlckxhYnMoMHgwMDAwKSwgcmV2IDEuMDANCiBwb3J0IDEgYWRkciAy OiBmdWxsIHNwZWVkLCBzZWxmIHBvd2VyZWQsIGNvbmZpZyAxLCBwcm9kdWN0IDB4MjA0Nigw eDIwNDYpLCB2ZW5kb3IgMHgwNDUxKDB4MDQ1MSksIHJldiAxLjI1DQogIHBvcnQgMSBwb3dl cmVkDQogIHBvcnQgMiBwb3dlcmVkDQogIHBvcnQgMyBwb3dlcmVkDQogIHBvcnQgNCBwb3dl cmVkDQogcG9ydCAyIHBvd2VyZWQNCiBwb3J0IDMgcG93ZXJlZA0KQ29udHJvbGxlciAvZGV2 L3VzYjE6DQphZGRyIDE6IGZ1bGwgc3BlZWQsIHNlbGYgcG93ZXJlZCwgY29uZmlnIDEsIE9I Q0kgcm9vdCBodWIoMHgwMDAwKSwgQWNlckxhYnMoMHgwMDAwKSwgcmV2IDEuMDANCiBwb3J0 IDEgcG93ZXJlZA0KIHBvcnQgMiBwb3dlcmVkDQogcG9ydCAzIHBvd2VyZWQNCkNvbnRyb2xs ZXIgL2Rldi91c2IyOg0KYWRkciAxOiBmdWxsIHNwZWVkLCBzZWxmIHBvd2VyZWQsIGNvbmZp ZyAxLCBPSENJIHJvb3QgaHViKDB4MDAwMCksIEFjZXJMYWJzKDB4MDAwMCksIHJldiAxLjAw DQogcG9ydCAxIHBvd2VyZWQNCiBwb3J0IDIgcG93ZXJlZA0KIHBvcnQgMyBwb3dlcmVkDQpD b250cm9sbGVyIC9kZXYvdXNiMzoNCmFkZHIgMTogaGlnaCBzcGVlZCwgc2VsZiBwb3dlcmVk LCBjb25maWcgMSwgRUhDSSByb290IGh1YigweDAwMDApLCBBY2VyTGFicygweDAwMDApLCBy ZXYgMS4wMA0KIHBvcnQgMSBwb3dlcmVkDQogcG9ydCAyIHBvd2VyZWQNCiBwb3J0IDMgcG93 ZXJlZA0KIHBvcnQgNCBwb3dlcmVkDQogcG9ydCA1IHBvd2VyZWQNCiBwb3J0IDYgcG93ZXJl ZA0KIHBvcnQgNyBwb3dlcmVkDQogcG9ydCA4IHBvd2VyZWQNCmFuZ2xlcG9pc2UjIHBjaWNv bmYgLWx2Yw0NCmhvc3RiMEBwY2kwOjA6MDowOgljbGFzcz0weDA2MDAwMCBjYXJkPTB4ODE4 NTEwNDMgY2hpcD0weDU5NTAxMDAyIHJldj0weDEwIGhkcj0weDAwDQogICAgdmVuZG9yICAg ICA9ICdBVEkgVGVjaG5vbG9naWVzIEluYycNCiAgICBkZXZpY2UgICAgID0gJ1JTNDgwIEhv c3QgQnJpZGdlJw0KICAgIGNsYXNzICAgICAgPSBicmlkZ2UNCiAgICBzdWJjbGFzcyAgID0g SE9TVC1QQ0kNCnBjaWIxQHBjaTA6MDoyOjA6CWNsYXNzPTB4MDYwNDAwIGNhcmQ9MHg1OTUw MTAwMiBjaGlwPTB4NWEzNDEwMDIgcmV2PTB4MDAgaGRyPTB4MDENCiAgICB2ZW5kb3IgICAg ID0gJ0FUSSBUZWNobm9sb2dpZXMgSW5jJw0KICAgIGRldmljZSAgICAgPSAnUlM0ODAgUENJ LVggUm9vdCBQb3J0Jw0KICAgIGNsYXNzICAgICAgPSBicmlkZ2UNCiAgICBzdWJjbGFzcyAg ID0gUENJLVBDSQ0KICAgIGNhcCAwMVs1MF0gPSBwb3dlcnNwZWMgMyAgc3VwcG9ydHMgRDAg RDMgIGN1cnJlbnQgRDANCiAgICBjYXAgMTBbNThdID0gUENJLUV4cHJlc3MgMSByb290IHBv cnQNCiAgICBjYXAgMDVbODBdID0gTVNJIHN1cHBvcnRzIDEgbWVzc2FnZSANCiAgICBjYXAg MGRbYjBdID0gUENJIEJyaWRnZSBjYXJkPTB4NTk1MDEwMDINCiAgICBjYXAgMDhbYjhdID0g SFQgTVNJIGZpeGVkIGFkZHJlc3Mgd2luZG93IGVuYWJsZWQgYXQgMHhmZWUwMDAwMA0KcGNp YjJAcGNpMDowOjY6MDoJY2xhc3M9MHgwNjA0MDAgY2FyZD0weDU5NTAxMDAyIGNoaXA9MHg1 YTM4MTAwMiByZXY9MHgwMCBoZHI9MHgwMQ0KICAgIHZlbmRvciAgICAgPSAnQVRJIFRlY2hu b2xvZ2llcyBJbmMnDQogICAgZGV2aWNlICAgICA9ICdSUzQ4MCBQQ0kgQnJpZGdlJw0KICAg IGNsYXNzICAgICAgPSBicmlkZ2UNCiAgICBzdWJjbGFzcyAgID0gUENJLVBDSQ0KICAgIGNh cCAwMVs1MF0gPSBwb3dlcnNwZWMgMyAgc3VwcG9ydHMgRDAgRDMgIGN1cnJlbnQgRDANCiAg ICBjYXAgMTBbNThdID0gUENJLUV4cHJlc3MgMSByb290IHBvcnQNCiAgICBjYXAgMDVbODBd ID0gTVNJIHN1cHBvcnRzIDEgbWVzc2FnZSANCiAgICBjYXAgMGRbYjBdID0gUENJIEJyaWRn ZSBjYXJkPTB4NTk1MDEwMDINCiAgICBjYXAgMDhbYjhdID0gSFQgTVNJIGZpeGVkIGFkZHJl c3Mgd2luZG93IGVuYWJsZWQgYXQgMHhmZWUwMDAwMA0KcGNpYjNAcGNpMDowOjc6MDoJY2xh c3M9MHgwNjA0MDAgY2FyZD0weDU5NTAxMDAyIGNoaXA9MHg1YTM5MTAwMiByZXY9MHgwMCBo ZHI9MHgwMQ0KICAgIHZlbmRvciAgICAgPSAnQVRJIFRlY2hub2xvZ2llcyBJbmMnDQogICAg ZGV2aWNlICAgICA9ICdSUzQ4MCBQQ0kgQnJpZGdlJw0KICAgIGNsYXNzICAgICAgPSBicmlk Z2UNCiAgICBzdWJjbGFzcyAgID0gUENJLVBDSQ0KICAgIGNhcCAwMVs1MF0gPSBwb3dlcnNw ZWMgMyAgc3VwcG9ydHMgRDAgRDMgIGN1cnJlbnQgRDANCiAgICBjYXAgMTBbNThdID0gUENJ LUV4cHJlc3MgMSByb290IHBvcnQNCiAgICBjYXAgMDVbODBdID0gTVNJIHN1cHBvcnRzIDEg bWVzc2FnZSANCiAgICBjYXAgMGRbYjBdID0gUENJIEJyaWRnZSBjYXJkPTB4NTk1MDEwMDIN CiAgICBjYXAgMDhbYjhdID0gSFQgTVNJIGZpeGVkIGFkZHJlc3Mgd2luZG93IGVuYWJsZWQg YXQgMHhmZWUwMDAwMA0KaG9zdGIxQHBjaTA6MDoyNDowOgljbGFzcz0weDA2MDAwMCBjYXJk PTB4MDAwMDAwMDAgY2hpcD0weDExMDAxMDIyIHJldj0weDAwIGhkcj0weDAwDQogICAgdmVu ZG9yICAgICA9ICdBZHZhbmNlZCBNaWNybyBEZXZpY2VzIChBTUQpJw0KICAgIGRldmljZSAg ICAgPSAnKEs4KSBBdGhsb24gNjQvT3B0ZXJvbiBIeXBlclRyYW5zcG9ydCBUZWNobm9sb2d5 IENvbmZpZ3VyYXRpb24nDQogICAgY2xhc3MgICAgICA9IGJyaWRnZQ0KICAgIHN1YmNsYXNz ICAgPSBIT1NULVBDSQ0KICAgIGNhcCAwOFs4MF0gPSBIVCBob3N0DQpob3N0YjJAcGNpMDow OjI0OjE6CWNsYXNzPTB4MDYwMDAwIGNhcmQ9MHgwMDAwMDAwMCBjaGlwPTB4MTEwMTEwMjIg cmV2PTB4MDAgaGRyPTB4MDANCiAgICB2ZW5kb3IgICAgID0gJ0FkdmFuY2VkIE1pY3JvIERl dmljZXMgKEFNRCknDQogICAgZGV2aWNlICAgICA9ICcoSzgpIEF0aGxvbiA2NC9PcHRlcm9u IEFkZHJlc3MgTWFwJw0KICAgIGNsYXNzICAgICAgPSBicmlkZ2UNCiAgICBzdWJjbGFzcyAg ID0gSE9TVC1QQ0kNCmhvc3RiM0BwY2kwOjA6MjQ6MjoJY2xhc3M9MHgwNjAwMDAgY2FyZD0w eDAwMDAwMDAwIGNoaXA9MHgxMTAyMTAyMiByZXY9MHgwMCBoZHI9MHgwMA0KICAgIHZlbmRv ciAgICAgPSAnQWR2YW5jZWQgTWljcm8gRGV2aWNlcyAoQU1EKScNCiAgICBkZXZpY2UgICAg ID0gJyhLOCkgQXRobG9uIDY0L09wdGVyb24gRFJBTSBDb250cm9sbGVyJw0KICAgIGNsYXNz ICAgICAgPSBicmlkZ2UNCiAgICBzdWJjbGFzcyAgID0gSE9TVC1QQ0kNCmhvc3RiNEBwY2kw OjA6MjQ6MzoJY2xhc3M9MHgwNjAwMDAgY2FyZD0weDAwMDAwMDAwIGNoaXA9MHgxMTAzMTAy MiByZXY9MHgwMCBoZHI9MHgwMA0KICAgIHZlbmRvciAgICAgPSAnQWR2YW5jZWQgTWljcm8g RGV2aWNlcyAoQU1EKScNCiAgICBkZXZpY2UgICAgID0gJyhLOCkgQXRobG9uIDY0L09wdGVy b24gTWlzY2VsbGFuZW91cyBDb250cm9sJw0KICAgIGNsYXNzICAgICAgPSBicmlkZ2UNCiAg ICBzdWJjbGFzcyAgID0gSE9TVC1QQ0kNCnBjaWI0QHBjaTA6MDoyNTowOgljbGFzcz0weDA2 MDQwMCBjYXJkPTB4MDAwMDAwMDAgY2hpcD0weDUyNDkxMGI5IHJldj0weDAwIGhkcj0weDAx DQogICAgdmVuZG9yICAgICA9ICdBY2VyIExhYnMgSW5jb3Jwb3JhdGVkIChBTGkvVUxpKScN CiAgICBkZXZpY2UgICAgID0gJ001MjQ5IEh5cGVyVHJhbnNwb3J0IHRvIFBDSSBCcmlkZ2Un DQogICAgY2xhc3MgICAgICA9IGJyaWRnZQ0KICAgIHN1YmNsYXNzICAgPSBQQ0ktUENJDQog ICAgY2FwIDA4W2MwXSA9IEhUIE1TSSBmaXhlZCBhZGRyZXNzIHdpbmRvdyBlbmFibGVkIGF0 IDB4ZmVlMDAwMDANCm9oY2kwQHBjaTA6MDoyODowOgljbGFzcz0weDBjMDMxMCBjYXJkPTB4 ODE1NjEwNDMgY2hpcD0weDUyMzcxMGI5IHJldj0weDAzIGhkcj0weDAwDQogICAgdmVuZG9y ICAgICA9ICdBY2VyIExhYnMgSW5jb3Jwb3JhdGVkIChBTGkvVUxpKScNCiAgICBkZXZpY2Ug ICAgID0gJ001MjczIEExIGZvciB3aW5kb3dzIHdpbiA5OCBPcGVuSENJIDEuMSBVU0IgdG8g IDIuMCcNCiAgICBjbGFzcyAgICAgID0gc2VyaWFsIGJ1cw0KICAgIHN1YmNsYXNzICAgPSBV U0INCm9oY2kxQHBjaTA6MDoyODoxOgljbGFzcz0weDBjMDMxMCBjYXJkPTB4ODE1NjEwNDMg Y2hpcD0weDUyMzcxMGI5IHJldj0weDAzIGhkcj0weDAwDQogICAgdmVuZG9yICAgICA9ICdB Y2VyIExhYnMgSW5jb3Jwb3JhdGVkIChBTGkvVUxpKScNCiAgICBkZXZpY2UgICAgID0gJ001 MjczIEExIGZvciB3aW5kb3dzIHdpbiA5OCBPcGVuSENJIDEuMSBVU0IgdG8gIDIuMCcNCiAg ICBjbGFzcyAgICAgID0gc2VyaWFsIGJ1cw0KICAgIHN1YmNsYXNzICAgPSBVU0INCm9oY2ky QHBjaTA6MDoyODoyOgljbGFzcz0weDBjMDMxMCBjYXJkPTB4ODE1NjEwNDMgY2hpcD0weDUy MzcxMGI5IHJldj0weDAzIGhkcj0weDAwDQogICAgdmVuZG9yICAgICA9ICdBY2VyIExhYnMg SW5jb3Jwb3JhdGVkIChBTGkvVUxpKScNCiAgICBkZXZpY2UgICAgID0gJ001MjczIEExIGZv ciB3aW5kb3dzIHdpbiA5OCBPcGVuSENJIDEuMSBVU0IgdG8gIDIuMCcNCiAgICBjbGFzcyAg ICAgID0gc2VyaWFsIGJ1cw0KICAgIHN1YmNsYXNzICAgPSBVU0INCmVoY2kwQHBjaTA6MDoy ODozOgljbGFzcz0weDBjMDMyMCBjYXJkPTB4ODE1NjEwNDMgY2hpcD0weDUyMzkxMGI5IHJl dj0weDAxIGhkcj0weDAwDQogICAgdmVuZG9yICAgICA9ICdBY2VyIExhYnMgSW5jb3Jwb3Jh dGVkIChBTGkvVUxpKScNCiAgICBkZXZpY2UgICAgID0gJ1VTQiAyLjAgRW5oYW5jZWQgSG9z dCBDb250cm9sbGVyJw0KICAgIGNsYXNzICAgICAgPSBzZXJpYWwgYnVzDQogICAgc3ViY2xh c3MgICA9IFVTQg0KICAgIGNhcCAwMVs1MF0gPSBwb3dlcnNwZWMgMiAgc3VwcG9ydHMgRDAg RDMgIGN1cnJlbnQgRDANCiAgICBjYXAgMGFbNThdID0gRUhDSSBEZWJ1ZyBQb3J0IGF0IG9m ZnNldCAweDkwIGluIG1hcCAweDE0DQpoZGFjMEBwY2kwOjA6Mjk6MDoJY2xhc3M9MHgwNDAz MDAgY2FyZD0weDgxYjQxMDQzIGNoaXA9MHg1NDYxMTBiOSByZXY9MHgwMCBoZHI9MHgwMA0K ICAgIHZlbmRvciAgICAgPSAnQWNlciBMYWJzIEluY29ycG9yYXRlZCAoQUxpL1VMaSknDQog ICAgZGV2aWNlICAgICA9ICc/PyBNaWNyb3NvZnQgVUFBIEJ1cyBEcml2ZXIgZm9yIEhpZ2gg RGVmaW5pdGlvbiBBdWRpbycNCiAgICBjbGFzcyAgICAgID0gbXVsdGltZWRpYQ0KICAgIHN1 YmNsYXNzICAgPSBIREENCiAgICBjYXAgMDFbNTBdID0gcG93ZXJzcGVjIDIgIHN1cHBvcnRz IEQwIEQzICBjdXJyZW50IEQwDQppc2FiMEBwY2kwOjA6MzA6MDoJY2xhc3M9MHgwNjAxMDAg Y2FyZD0weDgxNTYxMDQzIGNoaXA9MHgxNTczMTBiOSByZXY9MHgzMSBoZHI9MHgwMA0KICAg IHZlbmRvciAgICAgPSAnQWNlciBMYWJzIEluY29ycG9yYXRlZCAoQUxpL1VMaSknDQogICAg ZGV2aWNlICAgICA9ICdBTEkgTTE1NzMgU291dGggQnJpZGdlIHdpdGggSHlwZXJ0cmFuc3Bv cnQgU3VwcG9ydCcNCiAgICBjbGFzcyAgICAgID0gYnJpZGdlDQogICAgc3ViY2xhc3MgICA9 IFBDSS1JU0ENCm5vbmUwQHBjaTA6MDozMDoxOgljbGFzcz0weDA2ODAwMCBjYXJkPTB4ODE1 NjEwNDMgY2hpcD0weDcxMDExMGI5IHJldj0weDAwIGhkcj0weDAwDQogICAgdmVuZG9yICAg ICA9ICdBY2VyIExhYnMgSW5jb3Jwb3JhdGVkIChBTGkvVUxpKScNCiAgICBkZXZpY2UgICAg ID0gJ0FMSSBNNzEwMSBQb3dlciBNYW5hZ2VtZW50IENvbnRyb2xsZXInDQogICAgY2xhc3Mg ICAgICA9IGJyaWRnZQ0KYXRhcGNpMEBwY2kwOjA6MzE6MDoJY2xhc3M9MHgwMTAxOGEgY2Fy ZD0weDgxNTYxMDQzIGNoaXA9MHg1MjI5MTBiOSByZXY9MHhjNyBoZHI9MHgwMA0KICAgIHZl bmRvciAgICAgPSAnQWNlciBMYWJzIEluY29ycG9yYXRlZCAoQUxpL1VMaSknDQogICAgZGV2 aWNlICAgICA9ICdNNTIyOSBTb3V0aGJyaWRnZSBFSURFIENvbnRyb2xsZXInDQogICAgY2xh c3MgICAgICA9IG1hc3Mgc3RvcmFnZQ0KICAgIHN1YmNsYXNzICAgPSBBVEENCiAgICBjYXAg MDFbNjBdID0gcG93ZXJzcGVjIDIgIHN1cHBvcnRzIEQwIEQzICBjdXJyZW50IEQwDQphdGFw Y2kxQHBjaTA6MDozMToxOgljbGFzcz0weDAxMDQwMCBjYXJkPTB4ODE1NjEwNDMgY2hpcD0w eDUyODcxMGI5IHJldj0weDAyIGhkcj0weDAwDQogICAgdmVuZG9yICAgICA9ICdBY2VyIExh YnMgSW5jb3Jwb3JhdGVkIChBTGkvVUxpKScNCiAgICBkZXZpY2UgICAgID0gJzUyODcxODQ5 IEFMSSBTQVRBIGNvbnRyb2xsZXInDQogICAgY2xhc3MgICAgICA9IG1hc3Mgc3RvcmFnZQ0K ICAgIHN1YmNsYXNzICAgPSBSQUlEDQogICAgY2FwIDAxWzYwXSA9IHBvd2Vyc3BlYyAyICBz dXBwb3J0cyBEMCBEMyAgY3VycmVudCBEMA0KdmdhcGNpMEBwY2kwOjE6MDowOgljbGFzcz0w eDAzMDAwMCBjYXJkPTB4MzAwMDE3NGIgY2hpcD0weDViNjMxMDAyIHJldj0weDAwIGhkcj0w eDAwDQogICAgdmVuZG9yICAgICA9ICdBVEkgVGVjaG5vbG9naWVzIEluYycNCiAgICBkZXZp Y2UgICAgID0gJ1JhZGVvbiBYNTUwIFNlcmllcycNCiAgICBjbGFzcyAgICAgID0gZGlzcGxh eQ0KICAgIHN1YmNsYXNzICAgPSBWR0ENCiAgICBjYXAgMDFbNTBdID0gcG93ZXJzcGVjIDIg IHN1cHBvcnRzIEQwIEQxIEQyIEQzICBjdXJyZW50IEQwDQogICAgY2FwIDEwWzU4XSA9IFBD SS1FeHByZXNzIDEgZW5kcG9pbnQNCiAgICBjYXAgMDVbODBdID0gTVNJIHN1cHBvcnRzIDEg bWVzc2FnZSwgNjQgYml0IA0KdmdhcGNpMUBwY2kwOjE6MDoxOgljbGFzcz0weDAzODAwMCBj YXJkPTB4MzAwMTE3NGIgY2hpcD0weDViNzMxMDAyIHJldj0weDAwIGhkcj0weDAwDQogICAg dmVuZG9yICAgICA9ICdBVEkgVGVjaG5vbG9naWVzIEluYycNCiAgICBkZXZpY2UgICAgID0g J1JhZGVvbiBYNTUwIFNlcmllcyAtIFNlY29uZGFyeScNCiAgICBjbGFzcyAgICAgID0gZGlz cGxheQ0KICAgIGNhcCAwMVs1MF0gPSBwb3dlcnNwZWMgMiAgc3VwcG9ydHMgRDAgRDEgRDIg RDMgIGN1cnJlbnQgRDANCiAgICBjYXAgMTBbNThdID0gUENJLUV4cHJlc3MgMSBlbmRwb2lu dA0KbXNrYzBAcGNpMDoyOjA6MDoJY2xhc3M9MHgwMjAwMDAgY2FyZD0weDgxNDIxMDQzIGNo aXA9MHg0MzYyMTFhYiByZXY9MHgxOSBoZHI9MHgwMA0KICAgIHZlbmRvciAgICAgPSAnTWFy dmVsbCBTZW1pY29uZHVjdG9yIChXYXM6IEdhbGlsZW8gVGVjaG5vbG9neSBMdGQpJw0KICAg IGRldmljZSAgICAgPSAnODhFODA1MyBNYXJ2ZWxsIFl1a29uIDg4RTgwNTMgUENJLUUgR2ln YWJpdCBFdGhlcm5ldCBDb250cm9sbGVyJw0KICAgIGNsYXNzICAgICAgPSBuZXR3b3JrDQog ICAgc3ViY2xhc3MgICA9IGV0aGVybmV0DQogICAgY2FwIDAxWzQ4XSA9IHBvd2Vyc3BlYyAy ICBzdXBwb3J0cyBEMCBEMSBEMiBEMyAgY3VycmVudCBEMA0KICAgIGNhcCAwM1s1MF0gPSBW UEQNCiAgICBjYXAgMDVbNWNdID0gTVNJIHN1cHBvcnRzIDIgbWVzc2FnZXMsIDY0IGJpdCBl bmFibGVkIHdpdGggMiBtZXNzYWdlcw0KICAgIGNhcCAxMFtlMF0gPSBQQ0ktRXhwcmVzcyAx IGxlZ2FjeSBlbmRwb2ludA0Kbm9uZTFAcGNpMDo0OjE4OjA6CWNsYXNzPTB4MGMwMDEwIGNh cmQ9MHg4MDhhMTA0MyBjaGlwPTB4MzA0NDExMDYgcmV2PTB4ODAgaGRyPTB4MDANCiAgICB2 ZW5kb3IgICAgID0gJ1ZJQSBUZWNobm9sb2dpZXMgSW5jJw0KICAgIGRldmljZSAgICAgPSAn VlQ2MzA2IFZJQSBGaXJlIElJIElFRUUtMTM5NCBPSENJIExpbmsgTGF5ZXIgQ29udHJvbGxl cicNCiAgICBjbGFzcyAgICAgID0gc2VyaWFsIGJ1cw0KICAgIHN1YmNsYXNzICAgPSBGaXJl V2lyZQ0KICAgIGNhcCAwMVs1MF0gPSBwb3dlcnNwZWMgMiAgc3VwcG9ydHMgRDAgRDIgRDMg IGN1cnJlbnQgRDANCmFuZ2xlcG9pc2UjIA0NCmFuZ2xlcG9pc2UjIHVzYmRldnMIG1tLCBtb SwgbW0sIG1tLCBtbSwgbW0sIG1tLBwcHB2VjaG8gJ3BsdWcgaW4gIGh1YicIG1tLIG9uIGZy b250IHBhbmVsJw0NCnBsdWcgaW4gIGh1YiBvbiBmcm9udCBwYW5lbA0KYW5nbGVwb2lzZSMg dXNiZGV2cyAtdg0NCkNvbnRyb2xsZXIgL2Rldi91c2IwOg0KYWRkciAxOiBmdWxsIHNwZWVk LCBzZWxmIHBvd2VyZWQsIGNvbmZpZyAxLCBPSENJIHJvb3QgaHViKDB4MDAwMCksIEFjZXJM YWJzKDB4MDAwMCksIHJldiAxLjAwDQogcG9ydCAxIGFkZHIgMjogZnVsbCBzcGVlZCwgc2Vs ZiBwb3dlcmVkLCBjb25maWcgMSwgcHJvZHVjdCAweDIwNDYoMHgyMDQ2KSwgdmVuZG9yIDB4 MDQ1MSgweDA0NTEpLCByZXYgMS4yNQ0KICBwb3J0IDEgcG93ZXJlZA0KICBwb3J0IDIgcG93 ZXJlZA0KICBwb3J0IDMgcG93ZXJlZA0KICBwb3J0IDQgcG93ZXJlZA0KIHBvcnQgMiBwb3dl cmVkDQogcG9ydCAzIHBvd2VyZWQNCkNvbnRyb2xsZXIgL2Rldi91c2IxOg0KYWRkciAxOiBm dWxsIHNwZWVkLCBzZWxmIHBvd2VyZWQsIGNvbmZpZyAxLCBPSENJIHJvb3QgaHViKDB4MDAw MCksIEFjZXJMYWJzKDB4MDAwMCksIHJldiAxLjAwDQogcG9ydCAxIHBvd2VyZWQNCiBwb3J0 IDIgcG93ZXJlZA0KIHBvcnQgMyBwb3dlcmVkDQpDb250cm9sbGVyIC9kZXYvdXNiMjoNCmFk ZHIgMTogZnVsbCBzcGVlZCwgc2VsZiBwb3dlcmVkLCBjb25maWcgMSwgT0hDSSByb290IGh1 YigweDAwMDApLCBBY2VyTGFicygweDAwMDApLCByZXYgMS4wMA0KIHBvcnQgMSBwb3dlcmVk DQogcG9ydCAyIHBvd2VyZWQNCiBwb3J0IDMgcG93ZXJlZA0KQ29udHJvbGxlciAvZGV2L3Vz YjM6DQphZGRyIDE6IGhpZ2ggc3BlZWQsIHNlbGYgcG93ZXJlZCwgY29uZmlnIDEsIEVIQ0kg cm9vdCBodWIoMHgwMDAwKSwgQWNlckxhYnMoMHgwMDAwKSwgcmV2IDEuMDANCiBwb3J0IDEg cG93ZXJlZA0KIHBvcnQgMiBwb3dlcmVkDQogcG9ydCAzIHBvd2VyZWQNCiBwb3J0IDQgcG93 ZXJlZA0KIHBvcnQgNSBwb3dlcmVkDQogcG9ydCA2IHBvd2VyZWQNCiBwb3J0IDcgcG93ZXJl ZA0KIHBvcnQgOCBhZGRyIDI6IGhpZ2ggc3BlZWQsIHNlbGYgcG93ZXJlZCwgY29uZmlnIDEs IFVTQjIuMCBIdWIoMHgwNjA2KSwgdmVuZG9yIDB4MDVlMygweDA1ZTMpLCByZXYgNy4wMg0K ICBwb3J0IDEgcG93ZXJlZA0KICBwb3J0IDIgcG93ZXJlZA0KICBwb3J0IDMgcG93ZXJlZA0K ICBwb3J0IDQgcG93ZXJlZA0KYW5nbGVwb2lzZSMgcGNpY29uZiAtbHZiYw0NCmhvc3RiMEBw Y2kwOjA6MDowOgljbGFzcz0weDA2MDAwMCBjYXJkPTB4ODE4NTEwNDMgY2hpcD0weDU5NTAx MDAyIHJldj0weDEwIGhkcj0weDAwDQogICAgdmVuZG9yICAgICA9ICdBVEkgVGVjaG5vbG9n aWVzIEluYycNCiAgICBkZXZpY2UgICAgID0gJ1JTNDgwIEhvc3QgQnJpZGdlJw0KICAgIGNs YXNzICAgICAgPSBicmlkZ2UNCiAgICBzdWJjbGFzcyAgID0gSE9TVC1QQ0kNCnBjaWIxQHBj aTA6MDoyOjA6CWNsYXNzPTB4MDYwNDAwIGNhcmQ9MHg1OTUwMTAwMiBjaGlwPTB4NWEzNDEw MDIgcmV2PTB4MDAgaGRyPTB4MDENCiAgICB2ZW5kb3IgICAgID0gJ0FUSSBUZWNobm9sb2dp ZXMgSW5jJw0KICAgIGRldmljZSAgICAgPSAnUlM0ODAgUENJLVggUm9vdCBQb3J0Jw0KICAg IGNsYXNzICAgICAgPSBicmlkZ2UNCiAgICBzdWJjbGFzcyAgID0gUENJLVBDSQ0KICAgIGNh cCAwMVs1MF0gPSBwb3dlcnNwZWMgMyAgc3VwcG9ydHMgRDAgRDMgIGN1cnJlbnQgRDANCiAg ICBjYXAgMTBbNThdID0gUENJLUV4cHJlc3MgMSByb290IHBvcnQNCiAgICBjYXAgMDVbODBd ID0gTVNJIHN1cHBvcnRzIDEgbWVzc2FnZSANCiAgICBjYXAgMGRbYjBdID0gUENJIEJyaWRn ZSBjYXJkPTB4NTk1MDEwMDINCiAgICBjYXAgMDhbYjhdID0gSFQgTVNJIGZpeGVkIGFkZHJl c3Mgd2luZG93IGVuYWJsZWQgYXQgMHhmZWUwMDAwMA0KcGNpYjJAcGNpMDowOjY6MDoJY2xh c3M9MHgwNjA0MDAgY2FyZD0weDU5NTAxMDAyIGNoaXA9MHg1YTM4MTAwMiByZXY9MHgwMCBo ZHI9MHgwMQ0KICAgIHZlbmRvciAgICAgPSAnQVRJIFRlY2hub2xvZ2llcyBJbmMnDQogICAg ZGV2aWNlICAgICA9ICdSUzQ4MCBQQ0kgQnJpZGdlJw0KICAgIGNsYXNzICAgICAgPSBicmlk Z2UNCiAgICBzdWJjbGFzcyAgID0gUENJLVBDSQ0KICAgIGNhcCAwMVs1MF0gPSBwb3dlcnNw ZWMgMyAgc3VwcG9ydHMgRDAgRDMgIGN1cnJlbnQgRDANCiAgICBjYXAgMTBbNThdID0gUENJ LUV4cHJlc3MgMSByb290IHBvcnQNCiAgICBjYXAgMDVbODBdID0gTVNJIHN1cHBvcnRzIDEg bWVzc2FnZSANCiAgICBjYXAgMGRbYjBdID0gUENJIEJyaWRnZSBjYXJkPTB4NTk1MDEwMDIN CiAgICBjYXAgMDhbYjhdID0gSFQgTVNJIGZpeGVkIGFkZHJlc3Mgd2luZG93IGVuYWJsZWQg YXQgMHhmZWUwMDAwMA0KcGNpYjNAcGNpMDowOjc6MDoJY2xhc3M9MHgwNjA0MDAgY2FyZD0w eDU5NTAxMDAyIGNoaXA9MHg1YTM5MTAwMiByZXY9MHgwMCBoZHI9MHgwMQ0KICAgIHZlbmRv ciAgICAgPSAnQVRJIFRlY2hub2xvZ2llcyBJbmMnDQogICAgZGV2aWNlICAgICA9ICdSUzQ4 MCBQQ0kgQnJpZGdlJw0KICAgIGNsYXNzICAgICAgPSBicmlkZ2UNCiAgICBzdWJjbGFzcyAg ID0gUENJLVBDSQ0KICAgIGNhcCAwMVs1MF0gPSBwb3dlcnNwZWMgMyAgc3VwcG9ydHMgRDAg RDMgIGN1cnJlbnQgRDANCiAgICBjYXAgMTBbNThdID0gUENJLUV4cHJlc3MgMSByb290IHBv cnQNCiAgICBjYXAgMDVbODBdID0gTVNJIHN1cHBvcnRzIDEgbWVzc2FnZSANCiAgICBjYXAg MGRbYjBdID0gUENJIEJyaWRnZSBjYXJkPTB4NTk1MDEwMDINCiAgICBjYXAgMDhbYjhdID0g SFQgTVNJIGZpeGVkIGFkZHJlc3Mgd2luZG93IGVuYWJsZWQgYXQgMHhmZWUwMDAwMA0KaG9z dGIxQHBjaTA6MDoyNDowOgljbGFzcz0weDA2MDAwMCBjYXJkPTB4MDAwMDAwMDAgY2hpcD0w eDExMDAxMDIyIHJldj0weDAwIGhkcj0weDAwDQogICAgdmVuZG9yICAgICA9ICdBZHZhbmNl ZCBNaWNybyBEZXZpY2VzIChBTUQpJw0KICAgIGRldmljZSAgICAgPSAnKEs4KSBBdGhsb24g NjQvT3B0ZXJvbiBIeXBlclRyYW5zcG9ydCBUZWNobm9sb2d5IENvbmZpZ3VyYXRpb24nDQog ICAgY2xhc3MgICAgICA9IGJyaWRnZQ0KICAgIHN1YmNsYXNzICAgPSBIT1NULVBDSQ0KICAg IGNhcCAwOFs4MF0gPSBIVCBob3N0DQpob3N0YjJAcGNpMDowOjI0OjE6CWNsYXNzPTB4MDYw MDAwIGNhcmQ9MHgwMDAwMDAwMCBjaGlwPTB4MTEwMTEwMjIgcmV2PTB4MDAgaGRyPTB4MDAN CiAgICB2ZW5kb3IgICAgID0gJ0FkdmFuY2VkIE1pY3JvIERldmljZXMgKEFNRCknDQogICAg ZGV2aWNlICAgICA9ICcoSzgpIEF0aGxvbiA2NC9PcHRlcm9uIEFkZHJlc3MgTWFwJw0KICAg IGNsYXNzICAgICAgPSBicmlkZ2UNCiAgICBzdWJjbGFzcyAgID0gSE9TVC1QQ0kNCmhvc3Ri M0BwY2kwOjA6MjQ6MjoJY2xhc3M9MHgwNjAwMDAgY2FyZD0weDAwMDAwMDAwIGNoaXA9MHgx MTAyMTAyMiByZXY9MHgwMCBoZHI9MHgwMA0KICAgIHZlbmRvciAgICAgPSAnQWR2YW5jZWQg TWljcm8gRGV2aWNlcyAoQU1EKScNCiAgICBkZXZpY2UgICAgID0gJyhLOCkgQXRobG9uIDY0 L09wdGVyb24gRFJBTSBDb250cm9sbGVyJw0KICAgIGNsYXNzICAgICAgPSBicmlkZ2UNCiAg ICBzdWJjbGFzcyAgID0gSE9TVC1QQ0kNCmhvc3RiNEBwY2kwOjA6MjQ6MzoJY2xhc3M9MHgw NjAwMDAgY2FyZD0weDAwMDAwMDAwIGNoaXA9MHgxMTAzMTAyMiByZXY9MHgwMCBoZHI9MHgw MA0KICAgIHZlbmRvciAgICAgPSAnQWR2YW5jZWQgTWljcm8gRGV2aWNlcyAoQU1EKScNCiAg ICBkZXZpY2UgICAgID0gJyhLOCkgQXRobG9uIDY0L09wdGVyb24gTWlzY2VsbGFuZW91cyBD b250cm9sJw0KICAgIGNsYXNzICAgICAgPSBicmlkZ2UNCiAgICBzdWJjbGFzcyAgID0gSE9T VC1QQ0kNCnBjaWI0QHBjaTA6MDoyNTowOgljbGFzcz0weDA2MDQwMCBjYXJkPTB4MDAwMDAw MDAgY2hpcD0weDUyNDkxMGI5IHJldj0weDAwIGhkcj0weDAxDQogICAgdmVuZG9yICAgICA9 ICdBY2VyIExhYnMgSW5jb3Jwb3JhdGVkIChBTGkvVUxpKScNCiAgICBkZXZpY2UgICAgID0g J001MjQ5IEh5cGVyVHJhbnNwb3J0IHRvIFBDSSBCcmlkZ2UnDQogICAgY2xhc3MgICAgICA9 IGJyaWRnZQ0KICAgIHN1YmNsYXNzICAgPSBQQ0ktUENJDQogICAgY2FwIDA4W2MwXSA9IEhU IE1TSSBmaXhlZCBhZGRyZXNzIHdpbmRvdyBlbmFibGVkIGF0IDB4ZmVlMDAwMDANCm9oY2kw QHBjaTA6MDoyODowOgljbGFzcz0weDBjMDMxMCBjYXJkPTB4ODE1NjEwNDMgY2hpcD0weDUy MzcxMGI5IHJldj0weDAzIGhkcj0weDAwDQogICAgdmVuZG9yICAgICA9ICdBY2VyIExhYnMg SW5jb3Jwb3JhdGVkIChBTGkvVUxpKScNCiAgICBkZXZpY2UgICAgID0gJ001MjczIEExIGZv ciB3aW5kb3dzIHdpbiA5OCBPcGVuSENJIDEuMSBVU0IgdG8gIDIuMCcNCiAgICBjbGFzcyAg ICAgID0gc2VyaWFsIGJ1cw0KICAgIHN1YmNsYXNzICAgPSBVU0INCm9oY2kxQHBjaTA6MDoy ODoxOgljbGFzcz0weDBjMDMxMCBjYXJkPTB4ODE1NjEwNDMgY2hpcD0weDUyMzcxMGI5IHJl dj0weDAzIGhkcj0weDAwDQogICAgdmVuZG9yICAgICA9ICdBY2VyIExhYnMgSW5jb3Jwb3Jh dGVkIChBTGkvVUxpKScNCiAgICBkZXZpY2UgICAgID0gJ001MjczIEExIGZvciB3aW5kb3dz IHdpbiA5OCBPcGVuSENJIDEuMSBVU0IgdG8gIDIuMCcNCiAgICBjbGFzcyAgICAgID0gc2Vy aWFsIGJ1cw0KICAgIHN1YmNsYXNzICAgPSBVU0INCm9oY2kyQHBjaTA6MDoyODoyOgljbGFz cz0weDBjMDMxMCBjYXJkPTB4ODE1NjEwNDMgY2hpcD0weDUyMzcxMGI5IHJldj0weDAzIGhk cj0weDAwDQogICAgdmVuZG9yICAgICA9ICdBY2VyIExhYnMgSW5jb3Jwb3JhdGVkIChBTGkv VUxpKScNCiAgICBkZXZpY2UgICAgID0gJ001MjczIEExIGZvciB3aW5kb3dzIHdpbiA5OCBP cGVuSENJIDEuMSBVU0IgdG8gIDIuMCcNCiAgICBjbGFzcyAgICAgID0gc2VyaWFsIGJ1cw0K ICAgIHN1YmNsYXNzICAgPSBVU0INCmVoY2kwQHBjaTA6MDoyODozOgljbGFzcz0weDBjMDMy MCBjYXJkPTB4ODE1NjEwNDMgY2hpcD0weDUyMzkxMGI5IHJldj0weDAxIGhkcj0weDAwDQog ICAgdmVuZG9yICAgICA9ICdBY2VyIExhYnMgSW5jb3Jwb3JhdGVkIChBTGkvVUxpKScNCiAg ICBkZXZpY2UgICAgID0gJ1VTQiAyLjAgRW5oYW5jZWQgSG9zdCBDb250cm9sbGVyJw0KICAg IGNsYXNzICAgICAgPSBzZXJpYWwgYnVzDQogICAgc3ViY2xhc3MgICA9IFVTQg0KICAgIGNh cCAwMVs1MF0gPSBwb3dlcnNwZWMgMiAgc3VwcG9ydHMgRDAgRDMgIGN1cnJlbnQgRDANCiAg ICBjYXAgMGFbNThdID0gRUhDSSBEZWJ1ZyBQb3J0IGF0IG9mZnNldCAweDkwIGluIG1hcCAw eDE0DQpoZGFjMEBwY2kwOjA6Mjk6MDoJY2xhc3M9MHgwNDAzMDAgY2FyZD0weDgxYjQxMDQz IGNoaXA9MHg1NDYxMTBiOSByZXY9MHgwMCBoZHI9MHgwMA0KICAgIHZlbmRvciAgICAgPSAn QWNlciBMYWJzIEluY29ycG9yYXRlZCAoQUxpL1VMaSknDQogICAgZGV2aWNlICAgICA9ICc/ PyBNaWNyb3NvZnQgVUFBIEJ1cyBEcml2ZXIgZm9yIEhpZ2ggRGVmaW5pdGlvbiBBdWRpbycN CiAgICBjbGFzcyAgICAgID0gbXVsdGltZWRpYQ0KICAgIHN1YmNsYXNzICAgPSBIREENCiAg ICBjYXAgMDFbNTBdID0gcG93ZXJzcGVjIDIgIHN1cHBvcnRzIEQwIEQzICBjdXJyZW50IEQw DQppc2FiMEBwY2kwOjA6MzA6MDoJY2xhc3M9MHgwNjAxMDAgY2FyZD0weDgxNTYxMDQzIGNo aXA9MHgxNTczMTBiOSByZXY9MHgzMSBoZHI9MHgwMA0KICAgIHZlbmRvciAgICAgPSAnQWNl ciBMYWJzIEluY29ycG9yYXRlZCAoQUxpL1VMaSknDQogICAgZGV2aWNlICAgICA9ICdBTEkg TTE1NzMgU291dGggQnJpZGdlIHdpdGggSHlwZXJ0cmFuc3BvcnQgU3VwcG9ydCcNCiAgICBj bGFzcyAgICAgID0gYnJpZGdlDQogICAgc3ViY2xhc3MgICA9IFBDSS1JU0ENCm5vbmUwQHBj aTA6MDozMDoxOgljbGFzcz0weDA2ODAwMCBjYXJkPTB4ODE1NjEwNDMgY2hpcD0weDcxMDEx MGI5IHJldj0weDAwIGhkcj0weDAwDQogICAgdmVuZG9yICAgICA9ICdBY2VyIExhYnMgSW5j b3Jwb3JhdGVkIChBTGkvVUxpKScNCiAgICBkZXZpY2UgICAgID0gJ0FMSSBNNzEwMSBQb3dl ciBNYW5hZ2VtZW50IENvbnRyb2xsZXInDQogICAgY2xhc3MgICAgICA9IGJyaWRnZQ0KYXRh cGNpMEBwY2kwOjA6MzE6MDoJY2xhc3M9MHgwMTAxOGEgY2FyZD0weDgxNTYxMDQzIGNoaXA9 MHg1MjI5MTBiOSByZXY9MHhjNyBoZHI9MHgwMA0KICAgIHZlbmRvciAgICAgPSAnQWNlciBM YWJzIEluY29ycG9yYXRlZCAoQUxpL1VMaSknDQogICAgZGV2aWNlICAgICA9ICdNNTIyOSBT b3V0aGJyaWRnZSBFSURFIENvbnRyb2xsZXInDQogICAgY2xhc3MgICAgICA9IG1hc3Mgc3Rv cmFnZQ0KICAgIHN1YmNsYXNzICAgPSBBVEENCiAgICBjYXAgMDFbNjBdID0gcG93ZXJzcGVj IDIgIHN1cHBvcnRzIEQwIEQzICBjdXJyZW50IEQwDQphdGFwY2kxQHBjaTA6MDozMToxOglj bGFzcz0weDAxMDQwMCBjYXJkPTB4ODE1NjEwNDMgY2hpcD0weDUyODcxMGI5IHJldj0weDAy IGhkcj0weDAwDQogICAgdmVuZG9yICAgICA9ICdBY2VyIExhYnMgSW5jb3Jwb3JhdGVkIChB TGkvVUxpKScNCiAgICBkZXZpY2UgICAgID0gJzUyODcxODQ5IEFMSSBTQVRBIGNvbnRyb2xs ZXInDQogICAgY2xhc3MgICAgICA9IG1hc3Mgc3RvcmFnZQ0KICAgIHN1YmNsYXNzICAgPSBS QUlEDQogICAgY2FwIDAxWzYwXSA9IHBvd2Vyc3BlYyAyICBzdXBwb3J0cyBEMCBEMyAgY3Vy cmVudCBEMA0KdmdhcGNpMEBwY2kwOjE6MDowOgljbGFzcz0weDAzMDAwMCBjYXJkPTB4MzAw MDE3NGIgY2hpcD0weDViNjMxMDAyIHJldj0weDAwIGhkcj0weDAwDQogICAgdmVuZG9yICAg ICA9ICdBVEkgVGVjaG5vbG9naWVzIEluYycNCiAgICBkZXZpY2UgICAgID0gJ1JhZGVvbiBY NTUwIFNlcmllcycNCiAgICBjbGFzcyAgICAgID0gZGlzcGxheQ0KICAgIHN1YmNsYXNzICAg PSBWR0ENCiAgICBjYXAgMDFbNTBdID0gcG93ZXJzcGVjIDIgIHN1cHBvcnRzIEQwIEQxIEQy IEQzICBjdXJyZW50IEQwDQogICAgY2FwIDEwWzU4XSA9IFBDSS1FeHByZXNzIDEgZW5kcG9p bnQNCiAgICBjYXAgMDVbODBdID0gTVNJIHN1cHBvcnRzIDEgbWVzc2FnZSwgNjQgYml0IA0K dmdhcGNpMUBwY2kwOjE6MDoxOgljbGFzcz0weDAzODAwMCBjYXJkPTB4MzAwMTE3NGIgY2hp cD0weDViNzMxMDAyIHJldj0weDAwIGhkcj0weDAwDQogICAgdmVuZG9yICAgICA9ICdBVEkg VGVjaG5vbG9naWVzIEluYycNCiAgICBkZXZpY2UgICAgID0gJ1JhZGVvbiBYNTUwIFNlcmll cyAtIFNlY29uZGFyeScNCiAgICBjbGFzcyAgICAgID0gZGlzcGxheQ0KICAgIGNhcCAwMVs1 MF0gPSBwb3dlcnNwZWMgMiAgc3VwcG9ydHMgRDAgRDEgRDIgRDMgIGN1cnJlbnQgRDANCiAg ICBjYXAgMTBbNThdID0gUENJLUV4cHJlc3MgMSBlbmRwb2ludA0KbXNrYzBAcGNpMDoyOjA6 MDoJY2xhc3M9MHgwMjAwMDAgY2FyZD0weDgxNDIxMDQzIGNoaXA9MHg0MzYyMTFhYiByZXY9 MHgxOSBoZHI9MHgwMA0KICAgIHZlbmRvciAgICAgPSAnTWFydmVsbCBTZW1pY29uZHVjdG9y IChXYXM6IEdhbGlsZW8gVGVjaG5vbG9neSBMdGQpJw0KICAgIGRldmljZSAgICAgPSAnODhF ODA1MyBNYXJ2ZWxsIFl1a29uIDg4RTgwNTMgUENJLUUgR2lnYWJpdCBFdGhlcm5ldCBDb250 cm9sbGVyJw0KICAgIGNsYXNzICAgICAgPSBuZXR3b3JrDQogICAgc3ViY2xhc3MgICA9IGV0 aGVybmV0DQogICAgY2FwIDAxWzQ4XSA9IHBvd2Vyc3BlYyAyICBzdXBwb3J0cyBEMCBEMSBE MiBEMyAgY3VycmVudCBEMA0KICAgIGNhcCAwM1s1MF0gPSBWUEQNCiAgICBjYXAgMDVbNWNd ID0gTVNJIHN1cHBvcnRzIDIgbWVzc2FnZXMsIDY0IGJpdCBlbmFibGVkIHdpdGggMiBtZXNz YWdlcw0KICAgIGNhcCAxMFtlMF0gPSBQQ0ktRXhwcmVzcyAxIGxlZ2FjeSBlbmRwb2ludA0K bm9uZTFAcGNpMDo0OjE4OjA6CWNsYXNzPTB4MGMwMDEwIGNhcmQ9MHg4MDhhMTA0MyBjaGlw PTB4MzA0NDExMDYgcmV2PTB4ODAgaGRyPTB4MDANCiAgICB2ZW5kb3IgICAgID0gJ1ZJQSBU ZWNobm9sb2dpZXMgSW5jJw0KICAgIGRldmljZSAgICAgPSAnVlQ2MzA2IFZJQSBGaXJlIElJ IElFRUUtMTM5NCBPSENJIExpbmsgTGF5ZXIgQ29udHJvbGxlcicNCiAgICBjbGFzcyAgICAg ID0gc2VyaWFsIGJ1cw0KICAgIHN1YmNsYXNzICAgPSBGaXJlV2lyZQ0KICAgIGNhcCAwMVs1 MF0gPSBwb3dlcnNwZWMgMiAgc3VwcG9ydHMgRDAgRDIgRDMgIGN1cnJlbnQgRDANCmFuZ2xl cG9pc2UjIHBjaWNvbmYgLWx2YmMbWzEzYHVzYmRldnMgLXYbW0sNDQpDb250cm9sbGVyIC9k ZXYvdXNiMDoNCmFkZHIgMTogZnVsbCBzcGVlZCwgc2VsZiBwb3dlcmVkLCBjb25maWcgMSwg T0hDSSByb290IGh1YigweDAwMDApLCBBY2VyTGFicygweDAwMDApLCByZXYgMS4wMA0KIHBv cnQgMSBhZGRyIDI6IGZ1bGwgc3BlZWQsIHNlbGYgcG93ZXJlZCwgY29uZmlnIDEsIHByb2R1 Y3QgMHgyMDQ2KDB4MjA0NiksIHZlbmRvciAweDA0NTEoMHgwNDUxKSwgcmV2IDEuMjUNCiAg cG9ydCAxIHBvd2VyZWQNCiAgcG9ydCAyIHBvd2VyZWQNCiAgcG9ydCAzIHBvd2VyZWQNCiAg cG9ydCA0IHBvd2VyZWQNCiBwb3J0IDIgcG93ZXJlZA0KIHBvcnQgMyBwb3dlcmVkDQpDb250 cm9sbGVyIC9kZXYvdXNiMToNCmFkZHIgMTogZnVsbCBzcGVlZCwgc2VsZiBwb3dlcmVkLCBj b25maWcgMSwgT0hDSSByb290IGh1YigweDAwMDApLCBBY2VyTGFicygweDAwMDApLCByZXYg MS4wMA0KIHBvcnQgMSBwb3dlcmVkDQogcG9ydCAyIHBvd2VyZWQNCiBwb3J0IDMgcG93ZXJl ZA0KQ29udHJvbGxlciAvZGV2L3VzYjI6DQphZGRyIDE6IGZ1bGwgc3BlZWQsIHNlbGYgcG93 ZXJlZCwgY29uZmlnIDEsIE9IQ0kgcm9vdCBodWIoMHgwMDAwKSwgQWNlckxhYnMoMHgwMDAw KSwgcmV2IDEuMDANCiBwb3J0IDEgcG93ZXJlZA0KIHBvcnQgMiBwb3dlcmVkDQogcG9ydCAz IHBvd2VyZWQNCkNvbnRyb2xsZXIgL2Rldi91c2IzOg0KYWRkciAxOiBoaWdoIHNwZWVkLCBz ZWxmIHBvd2VyZWQsIGNvbmZpZyAxLCBFSENJIHJvb3QgaHViKDB4MDAwMCksIEFjZXJMYWJz KDB4MDAwMCksIHJldiAxLjAwDQogcG9ydCAxIHBvd2VyZWQNCiBwb3J0IDIgcG93ZXJlZA0K IHBvcnQgMyBwb3dlcmVkDQogcG9ydCA0IHBvd2VyZWQNCiBwb3J0IDUgcG93ZXJlZA0KIHBv cnQgNiBwb3dlcmVkDQogcG9ydCA3IHBvd2VyZWQNCiBwb3J0IDggYWRkciAyOiBoaWdoIHNw ZWVkLCBzZWxmIHBvd2VyZWQsIGNvbmZpZyAxLCBVU0IyLjAgSHViKDB4MDYwNiksIHZlbmRv ciAweDA1ZTMoMHgwNWUzKSwgcmV2IDcuMDINCiAgcG9ydCAxIHBvd2VyZWQNCiAgcG9ydCAy IHBvd2VyZWQNCiAgcG9ydCAzIHBvd2VyZWQNCiAgcG9ydCA0IHBvd2VyZWQNCmFuZ2xlcG9p c2UjIGVjaCAIbyAnZGV0YWNoIGh1YicNDQpkZXRhY2ggaHViDQphbmdsZXBvaXNlIyB1c2Jk ZXZzIC12DQ0KQ29udHJvbGxlciAvZGV2L3VzYjA6DQphZGRyIDE6IGZ1bGwgc3BlZWQsIHNl bGYgcG93ZXJlZCwgY29uZmlnIDEsIE9IQ0kgcm9vdCBodWIoMHgwMDAwKSwgQWNlckxhYnMo MHgwMDAwKSwgcmV2IDEuMDANCiBwb3J0IDEgYWRkciAyOiBmdWxsIHNwZWVkLCBzZWxmIHBv d2VyZWQsIGNvbmZpZyAxLCBwcm9kdWN0IDB4MjA0NigweDIwNDYpLCB2ZW5kb3IgMHgwNDUx KDB4MDQ1MSksIHJldiAxLjI1DQogIHBvcnQgMSBwb3dlcmVkDQogIHBvcnQgMiBwb3dlcmVk DQogIHBvcnQgMyBwb3dlcmVkDQogIHBvcnQgNCBwb3dlcmVkDQogcG9ydCAyIHBvd2VyZWQN CiBwb3J0IDMgcG93ZXJlZA0KQ29udHJvbGxlciAvZGV2L3VzYjE6DQphZGRyIDE6IGZ1bGwg c3BlZWQsIHNlbGYgcG93ZXJlZCwgY29uZmlnIDEsIE9IQ0kgcm9vdCBodWIoMHgwMDAwKSwg QWNlckxhYnMoMHgwMDAwKSwgcmV2IDEuMDANCiBwb3J0IDEgcG93ZXJlZA0KIHBvcnQgMiBw b3dlcmVkDQogcG9ydCAzIHBvd2VyZWQNCkNvbnRyb2xsZXIgL2Rldi91c2IyOg0KYWRkciAx OiBmdWxsIHNwZWVkLCBzZWxmIHBvd2VyZWQsIGNvbmZpZyAxLCBPSENJIHJvb3QgaHViKDB4 MDAwMCksIEFjZXJMYWJzKDB4MDAwMCksIHJldiAxLjAwDQogcG9ydCAxIHBvd2VyZWQNCiBw b3J0IDIgcG93ZXJlZA0KIHBvcnQgMyBwb3dlcmVkDQpDb250cm9sbGVyIC9kZXYvdXNiMzoN CmFkZHIgMTogaGlnaCBzcGVlZCwgc2VsZiBwb3dlcmVkLCBjb25maWcgMSwgRUhDSSByb290 IGh1YigweDAwMDApLCBBY2VyTGFicygweDAwMDApLCByZXYgMS4wMA0KIHBvcnQgMSBwb3dl cmVkDQogcG9ydCAyIHBvd2VyZWQNCiBwb3J0IDMgcG93ZXJlZA0KIHBvcnQgNCBwb3dlcmVk DQogcG9ydCA1IHBvd2VyZWQNCiBwb3J0IDYgcG93ZXJlZA0KIHBvcnQgNyBwb3dlcmVkDQog cG9ydCA4IHBvd2VyZWQNCmFuZ2xlcG9pc2UjIHVzYmRldnMgLXYbWzEzYGVjaG8gJ2RldGFj aCBodWInG1sxM2B1c2JkZXZzIC12G1tLG1sxM2BwY2ljb25mIC1sdmJjDQ0KaG9zdGIwQHBj aTA6MDowOjA6CWNsYXNzPTB4MDYwMDAwIGNhcmQ9MHg4MTg1MTA0MyBjaGlwPTB4NTk1MDEw MDIgcmV2PTB4MTAgaGRyPTB4MDANCiAgICB2ZW5kb3IgICAgID0gJ0FUSSBUZWNobm9sb2dp ZXMgSW5jJw0KICAgIGRldmljZSAgICAgPSAnUlM0ODAgSG9zdCBCcmlkZ2UnDQogICAgY2xh c3MgICAgICA9IGJyaWRnZQ0KICAgIHN1YmNsYXNzICAgPSBIT1NULVBDSQ0KcGNpYjFAcGNp MDowOjI6MDoJY2xhc3M9MHgwNjA0MDAgY2FyZD0weDU5NTAxMDAyIGNoaXA9MHg1YTM0MTAw MiByZXY9MHgwMCBoZHI9MHgwMQ0KICAgIHZlbmRvciAgICAgPSAnQVRJIFRlY2hub2xvZ2ll cyBJbmMnDQogICAgZGV2aWNlICAgICA9ICdSUzQ4MCBQQ0ktWCBSb290IFBvcnQnDQogICAg Y2xhc3MgICAgICA9IGJyaWRnZQ0KICAgIHN1YmNsYXNzICAgPSBQQ0ktUENJDQogICAgY2Fw IDAxWzUwXSA9IHBvd2Vyc3BlYyAzICBzdXBwb3J0cyBEMCBEMyAgY3VycmVudCBEMA0KICAg IGNhcCAxMFs1OF0gPSBQQ0ktRXhwcmVzcyAxIHJvb3QgcG9ydA0KICAgIGNhcCAwNVs4MF0g PSBNU0kgc3VwcG9ydHMgMSBtZXNzYWdlIA0KICAgIGNhcCAwZFtiMF0gPSBQQ0kgQnJpZGdl IGNhcmQ9MHg1OTUwMTAwMg0KICAgIGNhcCAwOFtiOF0gPSBIVCBNU0kgZml4ZWQgYWRkcmVz cyB3aW5kb3cgZW5hYmxlZCBhdCAweGZlZTAwMDAwDQpwY2liMkBwY2kwOjA6NjowOgljbGFz cz0weDA2MDQwMCBjYXJkPTB4NTk1MDEwMDIgY2hpcD0weDVhMzgxMDAyIHJldj0weDAwIGhk cj0weDAxDQogICAgdmVuZG9yICAgICA9ICdBVEkgVGVjaG5vbG9naWVzIEluYycNCiAgICBk ZXZpY2UgICAgID0gJ1JTNDgwIFBDSSBCcmlkZ2UnDQogICAgY2xhc3MgICAgICA9IGJyaWRn ZQ0KICAgIHN1YmNsYXNzICAgPSBQQ0ktUENJDQogICAgY2FwIDAxWzUwXSA9IHBvd2Vyc3Bl YyAzICBzdXBwb3J0cyBEMCBEMyAgY3VycmVudCBEMA0KICAgIGNhcCAxMFs1OF0gPSBQQ0kt RXhwcmVzcyAxIHJvb3QgcG9ydA0KICAgIGNhcCAwNVs4MF0gPSBNU0kgc3VwcG9ydHMgMSBt ZXNzYWdlIA0KICAgIGNhcCAwZFtiMF0gPSBQQ0kgQnJpZGdlIGNhcmQ9MHg1OTUwMTAwMg0K ICAgIGNhcCAwOFtiOF0gPSBIVCBNU0kgZml4ZWQgYWRkcmVzcyB3aW5kb3cgZW5hYmxlZCBh dCAweGZlZTAwMDAwDQpwY2liM0BwY2kwOjA6NzowOgljbGFzcz0weDA2MDQwMCBjYXJkPTB4 NTk1MDEwMDIgY2hpcD0weDVhMzkxMDAyIHJldj0weDAwIGhkcj0weDAxDQogICAgdmVuZG9y ICAgICA9ICdBVEkgVGVjaG5vbG9naWVzIEluYycNCiAgICBkZXZpY2UgICAgID0gJ1JTNDgw IFBDSSBCcmlkZ2UnDQogICAgY2xhc3MgICAgICA9IGJyaWRnZQ0KICAgIHN1YmNsYXNzICAg PSBQQ0ktUENJDQogICAgY2FwIDAxWzUwXSA9IHBvd2Vyc3BlYyAzICBzdXBwb3J0cyBEMCBE MyAgY3VycmVudCBEMA0KICAgIGNhcCAxMFs1OF0gPSBQQ0ktRXhwcmVzcyAxIHJvb3QgcG9y dA0KICAgIGNhcCAwNVs4MF0gPSBNU0kgc3VwcG9ydHMgMSBtZXNzYWdlIA0KICAgIGNhcCAw ZFtiMF0gPSBQQ0kgQnJpZGdlIGNhcmQ9MHg1OTUwMTAwMg0KICAgIGNhcCAwOFtiOF0gPSBI VCBNU0kgZml4ZWQgYWRkcmVzcyB3aW5kb3cgZW5hYmxlZCBhdCAweGZlZTAwMDAwDQpob3N0 YjFAcGNpMDowOjI0OjA6CWNsYXNzPTB4MDYwMDAwIGNhcmQ9MHgwMDAwMDAwMCBjaGlwPTB4 MTEwMDEwMjIgcmV2PTB4MDAgaGRyPTB4MDANCiAgICB2ZW5kb3IgICAgID0gJ0FkdmFuY2Vk IE1pY3JvIERldmljZXMgKEFNRCknDQogICAgZGV2aWNlICAgICA9ICcoSzgpIEF0aGxvbiA2 NC9PcHRlcm9uIEh5cGVyVHJhbnNwb3J0IFRlY2hub2xvZ3kgQ29uZmlndXJhdGlvbicNCiAg ICBjbGFzcyAgICAgID0gYnJpZGdlDQogICAgc3ViY2xhc3MgICA9IEhPU1QtUENJDQogICAg Y2FwIDA4WzgwXSA9IEhUIGhvc3QNCmhvc3RiMkBwY2kwOjA6MjQ6MToJY2xhc3M9MHgwNjAw MDAgY2FyZD0weDAwMDAwMDAwIGNoaXA9MHgxMTAxMTAyMiByZXY9MHgwMCBoZHI9MHgwMA0K ICAgIHZlbmRvciAgICAgPSAnQWR2YW5jZWQgTWljcm8gRGV2aWNlcyAoQU1EKScNCiAgICBk ZXZpY2UgICAgID0gJyhLOCkgQXRobG9uIDY0L09wdGVyb24gQWRkcmVzcyBNYXAnDQogICAg Y2xhc3MgICAgICA9IGJyaWRnZQ0KICAgIHN1YmNsYXNzICAgPSBIT1NULVBDSQ0KaG9zdGIz QHBjaTA6MDoyNDoyOgljbGFzcz0weDA2MDAwMCBjYXJkPTB4MDAwMDAwMDAgY2hpcD0weDEx MDIxMDIyIHJldj0weDAwIGhkcj0weDAwDQogICAgdmVuZG9yICAgICA9ICdBZHZhbmNlZCBN aWNybyBEZXZpY2VzIChBTUQpJw0KICAgIGRldmljZSAgICAgPSAnKEs4KSBBdGhsb24gNjQv T3B0ZXJvbiBEUkFNIENvbnRyb2xsZXInDQogICAgY2xhc3MgICAgICA9IGJyaWRnZQ0KICAg IHN1YmNsYXNzICAgPSBIT1NULVBDSQ0KaG9zdGI0QHBjaTA6MDoyNDozOgljbGFzcz0weDA2 MDAwMCBjYXJkPTB4MDAwMDAwMDAgY2hpcD0weDExMDMxMDIyIHJldj0weDAwIGhkcj0weDAw DQogICAgdmVuZG9yICAgICA9ICdBZHZhbmNlZCBNaWNybyBEZXZpY2VzIChBTUQpJw0KICAg IGRldmljZSAgICAgPSAnKEs4KSBBdGhsb24gNjQvT3B0ZXJvbiBNaXNjZWxsYW5lb3VzIENv bnRyb2wnDQogICAgY2xhc3MgICAgICA9IGJyaWRnZQ0KICAgIHN1YmNsYXNzICAgPSBIT1NU LVBDSQ0KcGNpYjRAcGNpMDowOjI1OjA6CWNsYXNzPTB4MDYwNDAwIGNhcmQ9MHgwMDAwMDAw MCBjaGlwPTB4NTI0OTEwYjkgcmV2PTB4MDAgaGRyPTB4MDENCiAgICB2ZW5kb3IgICAgID0g J0FjZXIgTGFicyBJbmNvcnBvcmF0ZWQgKEFMaS9VTGkpJw0KICAgIGRldmljZSAgICAgPSAn TTUyNDkgSHlwZXJUcmFuc3BvcnQgdG8gUENJIEJyaWRnZScNCiAgICBjbGFzcyAgICAgID0g YnJpZGdlDQogICAgc3ViY2xhc3MgICA9IFBDSS1QQ0kNCiAgICBjYXAgMDhbYzBdID0gSFQg TVNJIGZpeGVkIGFkZHJlc3Mgd2luZG93IGVuYWJsZWQgYXQgMHhmZWUwMDAwMA0Kb2hjaTBA cGNpMDowOjI4OjA6CWNsYXNzPTB4MGMwMzEwIGNhcmQ9MHg4MTU2MTA0MyBjaGlwPTB4NTIz NzEwYjkgcmV2PTB4MDMgaGRyPTB4MDANCiAgICB2ZW5kb3IgICAgID0gJ0FjZXIgTGFicyBJ bmNvcnBvcmF0ZWQgKEFMaS9VTGkpJw0KICAgIGRldmljZSAgICAgPSAnTTUyNzMgQTEgZm9y IHdpbmRvd3Mgd2luIDk4IE9wZW5IQ0kgMS4xIFVTQiB0byAgMi4wJw0KICAgIGNsYXNzICAg ICAgPSBzZXJpYWwgYnVzDQogICAgc3ViY2xhc3MgICA9IFVTQg0Kb2hjaTFAcGNpMDowOjI4 OjE6CWNsYXNzPTB4MGMwMzEwIGNhcmQ9MHg4MTU2MTA0MyBjaGlwPTB4NTIzNzEwYjkgcmV2 PTB4MDMgaGRyPTB4MDANCiAgICB2ZW5kb3IgICAgID0gJ0FjZXIgTGFicyBJbmNvcnBvcmF0 ZWQgKEFMaS9VTGkpJw0KICAgIGRldmljZSAgICAgPSAnTTUyNzMgQTEgZm9yIHdpbmRvd3Mg d2luIDk4IE9wZW5IQ0kgMS4xIFVTQiB0byAgMi4wJw0KICAgIGNsYXNzICAgICAgPSBzZXJp YWwgYnVzDQogICAgc3ViY2xhc3MgICA9IFVTQg0Kb2hjaTJAcGNpMDowOjI4OjI6CWNsYXNz PTB4MGMwMzEwIGNhcmQ9MHg4MTU2MTA0MyBjaGlwPTB4NTIzNzEwYjkgcmV2PTB4MDMgaGRy PTB4MDANCiAgICB2ZW5kb3IgICAgID0gJ0FjZXIgTGFicyBJbmNvcnBvcmF0ZWQgKEFMaS9V TGkpJw0KICAgIGRldmljZSAgICAgPSAnTTUyNzMgQTEgZm9yIHdpbmRvd3Mgd2luIDk4IE9w ZW5IQ0kgMS4xIFVTQiB0byAgMi4wJw0KICAgIGNsYXNzICAgICAgPSBzZXJpYWwgYnVzDQog ICAgc3ViY2xhc3MgICA9IFVTQg0KZWhjaTBAcGNpMDowOjI4OjM6CWNsYXNzPTB4MGMwMzIw IGNhcmQ9MHg4MTU2MTA0MyBjaGlwPTB4NTIzOTEwYjkgcmV2PTB4MDEgaGRyPTB4MDANCiAg ICB2ZW5kb3IgICAgID0gJ0FjZXIgTGFicyBJbmNvcnBvcmF0ZWQgKEFMaS9VTGkpJw0KICAg IGRldmljZSAgICAgPSAnVVNCIDIuMCBFbmhhbmNlZCBIb3N0IENvbnRyb2xsZXInDQogICAg Y2xhc3MgICAgICA9IHNlcmlhbCBidXMNCiAgICBzdWJjbGFzcyAgID0gVVNCDQogICAgY2Fw IDAxWzUwXSA9IHBvd2Vyc3BlYyAyICBzdXBwb3J0cyBEMCBEMyAgY3VycmVudCBEMA0KICAg IGNhcCAwYVs1OF0gPSBFSENJIERlYnVnIFBvcnQgYXQgb2Zmc2V0IDB4OTAgaW4gbWFwIDB4 MTQNCmhkYWMwQHBjaTA6MDoyOTowOgljbGFzcz0weDA0MDMwMCBjYXJkPTB4ODFiNDEwNDMg Y2hpcD0weDU0NjExMGI5IHJldj0weDAwIGhkcj0weDAwDQogICAgdmVuZG9yICAgICA9ICdB Y2VyIExhYnMgSW5jb3Jwb3JhdGVkIChBTGkvVUxpKScNCiAgICBkZXZpY2UgICAgID0gJz8/ IE1pY3Jvc29mdCBVQUEgQnVzIERyaXZlciBmb3IgSGlnaCBEZWZpbml0aW9uIEF1ZGlvJw0K ICAgIGNsYXNzICAgICAgPSBtdWx0aW1lZGlhDQogICAgc3ViY2xhc3MgICA9IEhEQQ0KICAg IGNhcCAwMVs1MF0gPSBwb3dlcnNwZWMgMiAgc3VwcG9ydHMgRDAgRDMgIGN1cnJlbnQgRDAN CmlzYWIwQHBjaTA6MDozMDowOgljbGFzcz0weDA2MDEwMCBjYXJkPTB4ODE1NjEwNDMgY2hp cD0weDE1NzMxMGI5IHJldj0weDMxIGhkcj0weDAwDQogICAgdmVuZG9yICAgICA9ICdBY2Vy IExhYnMgSW5jb3Jwb3JhdGVkIChBTGkvVUxpKScNCiAgICBkZXZpY2UgICAgID0gJ0FMSSBN MTU3MyBTb3V0aCBCcmlkZ2Ugd2l0aCBIeXBlcnRyYW5zcG9ydCBTdXBwb3J0Jw0KICAgIGNs YXNzICAgICAgPSBicmlkZ2UNCiAgICBzdWJjbGFzcyAgID0gUENJLUlTQQ0Kbm9uZTBAcGNp MDowOjMwOjE6CWNsYXNzPTB4MDY4MDAwIGNhcmQ9MHg4MTU2MTA0MyBjaGlwPTB4NzEwMTEw YjkgcmV2PTB4MDAgaGRyPTB4MDANCiAgICB2ZW5kb3IgICAgID0gJ0FjZXIgTGFicyBJbmNv cnBvcmF0ZWQgKEFMaS9VTGkpJw0KICAgIGRldmljZSAgICAgPSAnQUxJIE03MTAxIFBvd2Vy IE1hbmFnZW1lbnQgQ29udHJvbGxlcicNCiAgICBjbGFzcyAgICAgID0gYnJpZGdlDQphdGFw Y2kwQHBjaTA6MDozMTowOgljbGFzcz0weDAxMDE4YSBjYXJkPTB4ODE1NjEwNDMgY2hpcD0w eDUyMjkxMGI5IHJldj0weGM3IGhkcj0weDAwDQogICAgdmVuZG9yICAgICA9ICdBY2VyIExh YnMgSW5jb3Jwb3JhdGVkIChBTGkvVUxpKScNCiAgICBkZXZpY2UgICAgID0gJ001MjI5IFNv dXRoYnJpZGdlIEVJREUgQ29udHJvbGxlcicNCiAgICBjbGFzcyAgICAgID0gbWFzcyBzdG9y YWdlDQogICAgc3ViY2xhc3MgICA9IEFUQQ0KICAgIGNhcCAwMVs2MF0gPSBwb3dlcnNwZWMg MiAgc3VwcG9ydHMgRDAgRDMgIGN1cnJlbnQgRDANCmF0YXBjaTFAcGNpMDowOjMxOjE6CWNs YXNzPTB4MDEwNDAwIGNhcmQ9MHg4MTU2MTA0MyBjaGlwPTB4NTI4NzEwYjkgcmV2PTB4MDIg aGRyPTB4MDANCiAgICB2ZW5kb3IgICAgID0gJ0FjZXIgTGFicyBJbmNvcnBvcmF0ZWQgKEFM aS9VTGkpJw0KICAgIGRldmljZSAgICAgPSAnNTI4NzE4NDkgQUxJIFNBVEEgY29udHJvbGxl cicNCiAgICBjbGFzcyAgICAgID0gbWFzcyBzdG9yYWdlDQogICAgc3ViY2xhc3MgICA9IFJB SUQNCiAgICBjYXAgMDFbNjBdID0gcG93ZXJzcGVjIDIgIHN1cHBvcnRzIEQwIEQzICBjdXJy ZW50IEQwDQp2Z2FwY2kwQHBjaTA6MTowOjA6CWNsYXNzPTB4MDMwMDAwIGNhcmQ9MHgzMDAw MTc0YiBjaGlwPTB4NWI2MzEwMDIgcmV2PTB4MDAgaGRyPTB4MDANCiAgICB2ZW5kb3IgICAg ID0gJ0FUSSBUZWNobm9sb2dpZXMgSW5jJw0KICAgIGRldmljZSAgICAgPSAnUmFkZW9uIFg1 NTAgU2VyaWVzJw0KICAgIGNsYXNzICAgICAgPSBkaXNwbGF5DQogICAgc3ViY2xhc3MgICA9 IFZHQQ0KICAgIGNhcCAwMVs1MF0gPSBwb3dlcnNwZWMgMiAgc3VwcG9ydHMgRDAgRDEgRDIg RDMgIGN1cnJlbnQgRDANCiAgICBjYXAgMTBbNThdID0gUENJLUV4cHJlc3MgMSBlbmRwb2lu dA0KICAgIGNhcCAwNVs4MF0gPSBNU0kgc3VwcG9ydHMgMSBtZXNzYWdlLCA2NCBiaXQgDQp2 Z2FwY2kxQHBjaTA6MTowOjE6CWNsYXNzPTB4MDM4MDAwIGNhcmQ9MHgzMDAxMTc0YiBjaGlw PTB4NWI3MzEwMDIgcmV2PTB4MDAgaGRyPTB4MDANCiAgICB2ZW5kb3IgICAgID0gJ0FUSSBU ZWNobm9sb2dpZXMgSW5jJw0KICAgIGRldmljZSAgICAgPSAnUmFkZW9uIFg1NTAgU2VyaWVz IC0gU2Vjb25kYXJ5Jw0KICAgIGNsYXNzICAgICAgPSBkaXNwbGF5DQogICAgY2FwIDAxWzUw XSA9IHBvd2Vyc3BlYyAyICBzdXBwb3J0cyBEMCBEMSBEMiBEMyAgY3VycmVudCBEMA0KICAg IGNhcCAxMFs1OF0gPSBQQ0ktRXhwcmVzcyAxIGVuZHBvaW50DQptc2tjMEBwY2kwOjI6MDow OgljbGFzcz0weDAyMDAwMCBjYXJkPTB4ODE0MjEwNDMgY2hpcD0weDQzNjIxMWFiIHJldj0w eDE5IGhkcj0weDAwDQogICAgdmVuZG9yICAgICA9ICdNYXJ2ZWxsIFNlbWljb25kdWN0b3Ig KFdhczogR2FsaWxlbyBUZWNobm9sb2d5IEx0ZCknDQogICAgZGV2aWNlICAgICA9ICc4OEU4 MDUzIE1hcnZlbGwgWXVrb24gODhFODA1MyBQQ0ktRSBHaWdhYml0IEV0aGVybmV0IENvbnRy b2xsZXInDQogICAgY2xhc3MgICAgICA9IG5ldHdvcmsNCiAgICBzdWJjbGFzcyAgID0gZXRo ZXJuZXQNCiAgICBjYXAgMDFbNDhdID0gcG93ZXJzcGVjIDIgIHN1cHBvcnRzIEQwIEQxIEQy IEQzICBjdXJyZW50IEQwDQogICAgY2FwIDAzWzUwXSA9IFZQRA0KICAgIGNhcCAwNVs1Y10g PSBNU0kgc3VwcG9ydHMgMiBtZXNzYWdlcywgNjQgYml0IGVuYWJsZWQgd2l0aCAyIG1lc3Nh Z2VzDQogICAgY2FwIDEwW2UwXSA9IFBDSS1FeHByZXNzIDEgbGVnYWN5IGVuZHBvaW50DQpu b25lMUBwY2kwOjQ6MTg6MDoJY2xhc3M9MHgwYzAwMTAgY2FyZD0weDgwOGExMDQzIGNoaXA9 MHgzMDQ0MTEwNiByZXY9MHg4MCBoZHI9MHgwMA0KICAgIHZlbmRvciAgICAgPSAnVklBIFRl Y2hub2xvZ2llcyBJbmMnDQogICAgZGV2aWNlICAgICA9ICdWVDYzMDYgVklBIEZpcmUgSUkg SUVFRS0xMzk0IE9IQ0kgTGluayBMYXllciBDb250cm9sbGVyJw0KICAgIGNsYXNzICAgICAg PSBzZXJpYWwgYnVzDQogICAgc3ViY2xhc3MgICA9IEZpcmVXaXJlDQogICAgY2FwIDAxWzUw XSA9IHBvd2Vyc3BlYyAyICBzdXBwb3J0cyBEMCBEMiBEMyAgY3VycmVudCBEMA0KYW5nbGVw b2lzZSMgcGNpY29uZiAtbHZiYxtbMTNgdXNiZGV2cyAtdhtbSxtbMTNgZWNobyAnZGV0YWNo IGh1YicbWzEzYHVzYmRldnMgLXYbW0sbWzEzYHBjaWNvbmYgLWx2YmMbWzEzYHVzYmRldnMg LXYbW0sbWzEzYGVjaG8gJ3BsdWcgaW4gIGh1YiBvbiBmcm9udCBwYW5lbCcNDQpwbHVnIGlu ICBodWIgb24gZnJvbnQgcGFuZWwNCmFuZ2xlcG9pc2UjIA0NCmFuZ2xlcG9pc2UjIGVjaG8g J3BsdWcgaW4gIGh1YiBvbiBmcm9udCBwYW5lbCcbWzEzYHBjaWNvbmYgLWx2YmMbW0sbWzEz YHVzYmRldnMgLXYbW0sbWzEzYGVjaG8gJ2RldGFjaCBodWInG1sxM2B1c2JkZXZzIC12G1tL G1sxM2BwY2ljb25mIC1sdmJjDQ0KaG9zdGIwQHBjaTA6MDowOjA6CWNsYXNzPTB4MDYwMDAw IGNhcmQ9MHg4MTg1MTA0MyBjaGlwPTB4NTk1MDEwMDIgcmV2PTB4MTAgaGRyPTB4MDANCiAg ICB2ZW5kb3IgICAgID0gJ0FUSSBUZWNobm9sb2dpZXMgSW5jJw0KICAgIGRldmljZSAgICAg PSAnUlM0ODAgSG9zdCBCcmlkZ2UnDQogICAgY2xhc3MgICAgICA9IGJyaWRnZQ0KICAgIHN1 YmNsYXNzICAgPSBIT1NULVBDSQ0KcGNpYjFAcGNpMDowOjI6MDoJY2xhc3M9MHgwNjA0MDAg Y2FyZD0weDU5NTAxMDAyIGNoaXA9MHg1YTM0MTAwMiByZXY9MHgwMCBoZHI9MHgwMQ0KICAg IHZlbmRvciAgICAgPSAnQVRJIFRlY2hub2xvZ2llcyBJbmMnDQogICAgZGV2aWNlICAgICA9 ICdSUzQ4MCBQQ0ktWCBSb290IFBvcnQnDQogICAgY2xhc3MgICAgICA9IGJyaWRnZQ0KICAg IHN1YmNsYXNzICAgPSBQQ0ktUENJDQogICAgY2FwIDAxWzUwXSA9IHBvd2Vyc3BlYyAzICBz dXBwb3J0cyBEMCBEMyAgY3VycmVudCBEMA0KICAgIGNhcCAxMFs1OF0gPSBQQ0ktRXhwcmVz cyAxIHJvb3QgcG9ydA0KICAgIGNhcCAwNVs4MF0gPSBNU0kgc3VwcG9ydHMgMSBtZXNzYWdl IA0KICAgIGNhcCAwZFtiMF0gPSBQQ0kgQnJpZGdlIGNhcmQ9MHg1OTUwMTAwMg0KICAgIGNh cCAwOFtiOF0gPSBIVCBNU0kgZml4ZWQgYWRkcmVzcyB3aW5kb3cgZW5hYmxlZCBhdCAweGZl ZTAwMDAwDQpwY2liMkBwY2kwOjA6NjowOgljbGFzcz0weDA2MDQwMCBjYXJkPTB4NTk1MDEw MDIgY2hpcD0weDVhMzgxMDAyIHJldj0weDAwIGhkcj0weDAxDQogICAgdmVuZG9yICAgICA9 ICdBVEkgVGVjaG5vbG9naWVzIEluYycNCiAgICBkZXZpY2UgICAgID0gJ1JTNDgwIFBDSSBC cmlkZ2UnDQogICAgY2xhc3MgICAgICA9IGJyaWRnZQ0KICAgIHN1YmNsYXNzICAgPSBQQ0kt UENJDQogICAgY2FwIDAxWzUwXSA9IHBvd2Vyc3BlYyAzICBzdXBwb3J0cyBEMCBEMyAgY3Vy cmVudCBEMA0KICAgIGNhcCAxMFs1OF0gPSBQQ0ktRXhwcmVzcyAxIHJvb3QgcG9ydA0KICAg IGNhcCAwNVs4MF0gPSBNU0kgc3VwcG9ydHMgMSBtZXNzYWdlIA0KICAgIGNhcCAwZFtiMF0g PSBQQ0kgQnJpZGdlIGNhcmQ9MHg1OTUwMTAwMg0KICAgIGNhcCAwOFtiOF0gPSBIVCBNU0kg Zml4ZWQgYWRkcmVzcyB3aW5kb3cgZW5hYmxlZCBhdCAweGZlZTAwMDAwDQpwY2liM0BwY2kw OjA6NzowOgljbGFzcz0weDA2MDQwMCBjYXJkPTB4NTk1MDEwMDIgY2hpcD0weDVhMzkxMDAy IHJldj0weDAwIGhkcj0weDAxDQogICAgdmVuZG9yICAgICA9ICdBVEkgVGVjaG5vbG9naWVz IEluYycNCiAgICBkZXZpY2UgICAgID0gJ1JTNDgwIFBDSSBCcmlkZ2UnDQogICAgY2xhc3Mg ICAgICA9IGJyaWRnZQ0KICAgIHN1YmNsYXNzICAgPSBQQ0ktUENJDQogICAgY2FwIDAxWzUw XSA9IHBvd2Vyc3BlYyAzICBzdXBwb3J0cyBEMCBEMyAgY3VycmVudCBEMA0KICAgIGNhcCAx MFs1OF0gPSBQQ0ktRXhwcmVzcyAxIHJvb3QgcG9ydA0KICAgIGNhcCAwNVs4MF0gPSBNU0kg c3VwcG9ydHMgMSBtZXNzYWdlIA0KICAgIGNhcCAwZFtiMF0gPSBQQ0kgQnJpZGdlIGNhcmQ9 MHg1OTUwMTAwMg0KICAgIGNhcCAwOFtiOF0gPSBIVCBNU0kgZml4ZWQgYWRkcmVzcyB3aW5k b3cgZW5hYmxlZCBhdCAweGZlZTAwMDAwDQpob3N0YjFAcGNpMDowOjI0OjA6CWNsYXNzPTB4 MDYwMDAwIGNhcmQ9MHgwMDAwMDAwMCBjaGlwPTB4MTEwMDEwMjIgcmV2PTB4MDAgaGRyPTB4 MDANCiAgICB2ZW5kb3IgICAgID0gJ0FkdmFuY2VkIE1pY3JvIERldmljZXMgKEFNRCknDQog ICAgZGV2aWNlICAgICA9ICcoSzgpIEF0aGxvbiA2NC9PcHRlcm9uIEh5cGVyVHJhbnNwb3J0 IFRlY2hub2xvZ3kgQ29uZmlndXJhdGlvbicNCiAgICBjbGFzcyAgICAgID0gYnJpZGdlDQog ICAgc3ViY2xhc3MgICA9IEhPU1QtUENJDQogICAgY2FwIDA4WzgwXSA9IEhUIGhvc3QNCmhv c3RiMkBwY2kwOjA6MjQ6MToJY2xhc3M9MHgwNjAwMDAgY2FyZD0weDAwMDAwMDAwIGNoaXA9 MHgxMTAxMTAyMiByZXY9MHgwMCBoZHI9MHgwMA0KICAgIHZlbmRvciAgICAgPSAnQWR2YW5j ZWQgTWljcm8gRGV2aWNlcyAoQU1EKScNCiAgICBkZXZpY2UgICAgID0gJyhLOCkgQXRobG9u IDY0L09wdGVyb24gQWRkcmVzcyBNYXAnDQogICAgY2xhc3MgICAgICA9IGJyaWRnZQ0KICAg IHN1YmNsYXNzICAgPSBIT1NULVBDSQ0KaG9zdGIzQHBjaTA6MDoyNDoyOgljbGFzcz0weDA2 MDAwMCBjYXJkPTB4MDAwMDAwMDAgY2hpcD0weDExMDIxMDIyIHJldj0weDAwIGhkcj0weDAw DQogICAgdmVuZG9yICAgICA9ICdBZHZhbmNlZCBNaWNybyBEZXZpY2VzIChBTUQpJw0KICAg IGRldmljZSAgICAgPSAnKEs4KSBBdGhsb24gNjQvT3B0ZXJvbiBEUkFNIENvbnRyb2xsZXIn DQogICAgY2xhc3MgICAgICA9IGJyaWRnZQ0KICAgIHN1YmNsYXNzICAgPSBIT1NULVBDSQ0K aG9zdGI0QHBjaTA6MDoyNDozOgljbGFzcz0weDA2MDAwMCBjYXJkPTB4MDAwMDAwMDAgY2hp cD0weDExMDMxMDIyIHJldj0weDAwIGhkcj0weDAwDQogICAgdmVuZG9yICAgICA9ICdBZHZh bmNlZCBNaWNybyBEZXZpY2VzIChBTUQpJw0KICAgIGRldmljZSAgICAgPSAnKEs4KSBBdGhs b24gNjQvT3B0ZXJvbiBNaXNjZWxsYW5lb3VzIENvbnRyb2wnDQogICAgY2xhc3MgICAgICA9 IGJyaWRnZQ0KICAgIHN1YmNsYXNzICAgPSBIT1NULVBDSQ0KcGNpYjRAcGNpMDowOjI1OjA6 CWNsYXNzPTB4MDYwNDAwIGNhcmQ9MHgwMDAwMDAwMCBjaGlwPTB4NTI0OTEwYjkgcmV2PTB4 MDAgaGRyPTB4MDENCiAgICB2ZW5kb3IgICAgID0gJ0FjZXIgTGFicyBJbmNvcnBvcmF0ZWQg KEFMaS9VTGkpJw0KICAgIGRldmljZSAgICAgPSAnTTUyNDkgSHlwZXJUcmFuc3BvcnQgdG8g UENJIEJyaWRnZScNCiAgICBjbGFzcyAgICAgID0gYnJpZGdlDQogICAgc3ViY2xhc3MgICA9 IFBDSS1QQ0kNCiAgICBjYXAgMDhbYzBdID0gSFQgTVNJIGZpeGVkIGFkZHJlc3Mgd2luZG93 IGVuYWJsZWQgYXQgMHhmZWUwMDAwMA0Kb2hjaTBAcGNpMDowOjI4OjA6CWNsYXNzPTB4MGMw MzEwIGNhcmQ9MHg4MTU2MTA0MyBjaGlwPTB4NTIzNzEwYjkgcmV2PTB4MDMgaGRyPTB4MDAN CiAgICB2ZW5kb3IgICAgID0gJ0FjZXIgTGFicyBJbmNvcnBvcmF0ZWQgKEFMaS9VTGkpJw0K ICAgIGRldmljZSAgICAgPSAnTTUyNzMgQTEgZm9yIHdpbmRvd3Mgd2luIDk4IE9wZW5IQ0kg MS4xIFVTQiB0byAgMi4wJw0KICAgIGNsYXNzICAgICAgPSBzZXJpYWwgYnVzDQogICAgc3Vi Y2xhc3MgICA9IFVTQg0Kb2hjaTFAcGNpMDowOjI4OjE6CWNsYXNzPTB4MGMwMzEwIGNhcmQ9 MHg4MTU2MTA0MyBjaGlwPTB4NTIzNzEwYjkgcmV2PTB4MDMgaGRyPTB4MDANCiAgICB2ZW5k b3IgICAgID0gJ0FjZXIgTGFicyBJbmNvcnBvcmF0ZWQgKEFMaS9VTGkpJw0KICAgIGRldmlj ZSAgICAgPSAnTTUyNzMgQTEgZm9yIHdpbmRvd3Mgd2luIDk4IE9wZW5IQ0kgMS4xIFVTQiB0 byAgMi4wJw0KICAgIGNsYXNzICAgICAgPSBzZXJpYWwgYnVzDQogICAgc3ViY2xhc3MgICA9 IFVTQg0Kb2hjaTJAcGNpMDowOjI4OjI6CWNsYXNzPTB4MGMwMzEwIGNhcmQ9MHg4MTU2MTA0 MyBjaGlwPTB4NTIzNzEwYjkgcmV2PTB4MDMgaGRyPTB4MDANCiAgICB2ZW5kb3IgICAgID0g J0FjZXIgTGFicyBJbmNvcnBvcmF0ZWQgKEFMaS9VTGkpJw0KICAgIGRldmljZSAgICAgPSAn TTUyNzMgQTEgZm9yIHdpbmRvd3Mgd2luIDk4IE9wZW5IQ0kgMS4xIFVTQiB0byAgMi4wJw0K ICAgIGNsYXNzICAgICAgPSBzZXJpYWwgYnVzDQogICAgc3ViY2xhc3MgICA9IFVTQg0KZWhj aTBAcGNpMDowOjI4OjM6CWNsYXNzPTB4MGMwMzIwIGNhcmQ9MHg4MTU2MTA0MyBjaGlwPTB4 NTIzOTEwYjkgcmV2PTB4MDEgaGRyPTB4MDANCiAgICB2ZW5kb3IgICAgID0gJ0FjZXIgTGFi cyBJbmNvcnBvcmF0ZWQgKEFMaS9VTGkpJw0KICAgIGRldmljZSAgICAgPSAnVVNCIDIuMCBF bmhhbmNlZCBIb3N0IENvbnRyb2xsZXInDQogICAgY2xhc3MgICAgICA9IHNlcmlhbCBidXMN CiAgICBzdWJjbGFzcyAgID0gVVNCDQogICAgY2FwIDAxWzUwXSA9IHBvd2Vyc3BlYyAyICBz dXBwb3J0cyBEMCBEMyAgY3VycmVudCBEMA0KICAgIGNhcCAwYVs1OF0gPSBFSENJIERlYnVn IFBvcnQgYXQgb2Zmc2V0IDB4OTAgaW4gbWFwIDB4MTQNCmhkYWMwQHBjaTA6MDoyOTowOglj bGFzcz0weDA0MDMwMCBjYXJkPTB4ODFiNDEwNDMgY2hpcD0weDU0NjExMGI5IHJldj0weDAw IGhkcj0weDAwDQogICAgdmVuZG9yICAgICA9ICdBY2VyIExhYnMgSW5jb3Jwb3JhdGVkIChB TGkvVUxpKScNCiAgICBkZXZpY2UgICAgID0gJz8/IE1pY3Jvc29mdCBVQUEgQnVzIERyaXZl ciBmb3IgSGlnaCBEZWZpbml0aW9uIEF1ZGlvJw0KICAgIGNsYXNzICAgICAgPSBtdWx0aW1l ZGlhDQogICAgc3ViY2xhc3MgICA9IEhEQQ0KICAgIGNhcCAwMVs1MF0gPSBwb3dlcnNwZWMg MiAgc3VwcG9ydHMgRDAgRDMgIGN1cnJlbnQgRDANCmlzYWIwQHBjaTA6MDozMDowOgljbGFz cz0weDA2MDEwMCBjYXJkPTB4ODE1NjEwNDMgY2hpcD0weDE1NzMxMGI5IHJldj0weDMxIGhk cj0weDAwDQogICAgdmVuZG9yICAgICA9ICdBY2VyIExhYnMgSW5jb3Jwb3JhdGVkIChBTGkv VUxpKScNCiAgICBkZXZpY2UgICAgID0gJ0FMSSBNMTU3MyBTb3V0aCBCcmlkZ2Ugd2l0aCBI eXBlcnRyYW5zcG9ydCBTdXBwb3J0Jw0KICAgIGNsYXNzICAgICAgPSBicmlkZ2UNCiAgICBz dWJjbGFzcyAgID0gUENJLUlTQQ0Kbm9uZTBAcGNpMDowOjMwOjE6CWNsYXNzPTB4MDY4MDAw IGNhcmQ9MHg4MTU2MTA0MyBjaGlwPTB4NzEwMTEwYjkgcmV2PTB4MDAgaGRyPTB4MDANCiAg ICB2ZW5kb3IgICAgID0gJ0FjZXIgTGFicyBJbmNvcnBvcmF0ZWQgKEFMaS9VTGkpJw0KICAg IGRldmljZSAgICAgPSAnQUxJIE03MTAxIFBvd2VyIE1hbmFnZW1lbnQgQ29udHJvbGxlcicN CiAgICBjbGFzcyAgICAgID0gYnJpZGdlDQphdGFwY2kwQHBjaTA6MDozMTowOgljbGFzcz0w eDAxMDE4YSBjYXJkPTB4ODE1NjEwNDMgY2hpcD0weDUyMjkxMGI5IHJldj0weGM3IGhkcj0w eDAwDQogICAgdmVuZG9yICAgICA9ICdBY2VyIExhYnMgSW5jb3Jwb3JhdGVkIChBTGkvVUxp KScNCiAgICBkZXZpY2UgICAgID0gJ001MjI5IFNvdXRoYnJpZGdlIEVJREUgQ29udHJvbGxl cicNCiAgICBjbGFzcyAgICAgID0gbWFzcyBzdG9yYWdlDQogICAgc3ViY2xhc3MgICA9IEFU QQ0KICAgIGNhcCAwMVs2MF0gPSBwb3dlcnNwZWMgMiAgc3VwcG9ydHMgRDAgRDMgIGN1cnJl bnQgRDANCmF0YXBjaTFAcGNpMDowOjMxOjE6CWNsYXNzPTB4MDEwNDAwIGNhcmQ9MHg4MTU2 MTA0MyBjaGlwPTB4NTI4NzEwYjkgcmV2PTB4MDIgaGRyPTB4MDANCiAgICB2ZW5kb3IgICAg ID0gJ0FjZXIgTGFicyBJbmNvcnBvcmF0ZWQgKEFMaS9VTGkpJw0KICAgIGRldmljZSAgICAg PSAnNTI4NzE4NDkgQUxJIFNBVEEgY29udHJvbGxlcicNCiAgICBjbGFzcyAgICAgID0gbWFz cyBzdG9yYWdlDQogICAgc3ViY2xhc3MgICA9IFJBSUQNCiAgICBjYXAgMDFbNjBdID0gcG93 ZXJzcGVjIDIgIHN1cHBvcnRzIEQwIEQzICBjdXJyZW50IEQwDQp2Z2FwY2kwQHBjaTA6MTow OjA6CWNsYXNzPTB4MDMwMDAwIGNhcmQ9MHgzMDAwMTc0YiBjaGlwPTB4NWI2MzEwMDIgcmV2 PTB4MDAgaGRyPTB4MDANCiAgICB2ZW5kb3IgICAgID0gJ0FUSSBUZWNobm9sb2dpZXMgSW5j Jw0KICAgIGRldmljZSAgICAgPSAnUmFkZW9uIFg1NTAgU2VyaWVzJw0KICAgIGNsYXNzICAg ICAgPSBkaXNwbGF5DQogICAgc3ViY2xhc3MgICA9IFZHQQ0KICAgIGNhcCAwMVs1MF0gPSBw b3dlcnNwZWMgMiAgc3VwcG9ydHMgRDAgRDEgRDIgRDMgIGN1cnJlbnQgRDANCiAgICBjYXAg MTBbNThdID0gUENJLUV4cHJlc3MgMSBlbmRwb2ludA0KICAgIGNhcCAwNVs4MF0gPSBNU0kg c3VwcG9ydHMgMSBtZXNzYWdlLCA2NCBiaXQgDQp2Z2FwY2kxQHBjaTA6MTowOjE6CWNsYXNz PTB4MDM4MDAwIGNhcmQ9MHgzMDAxMTc0YiBjaGlwPTB4NWI3MzEwMDIgcmV2PTB4MDAgaGRy PTB4MDANCiAgICB2ZW5kb3IgICAgID0gJ0FUSSBUZWNobm9sb2dpZXMgSW5jJw0KICAgIGRl dmljZSAgICAgPSAnUmFkZW9uIFg1NTAgU2VyaWVzIC0gU2Vjb25kYXJ5Jw0KICAgIGNsYXNz ICAgICAgPSBkaXNwbGF5DQogICAgY2FwIDAxWzUwXSA9IHBvd2Vyc3BlYyAyICBzdXBwb3J0 cyBEMCBEMSBEMiBEMyAgY3VycmVudCBEMA0KICAgIGNhcCAxMFs1OF0gPSBQQ0ktRXhwcmVz cyAxIGVuZHBvaW50DQptc2tjMEBwY2kwOjI6MDowOgljbGFzcz0weDAyMDAwMCBjYXJkPTB4 ODE0MjEwNDMgY2hpcD0weDQzNjIxMWFiIHJldj0weDE5IGhkcj0weDAwDQogICAgdmVuZG9y ICAgICA9ICdNYXJ2ZWxsIFNlbWljb25kdWN0b3IgKFdhczogR2FsaWxlbyBUZWNobm9sb2d5 IEx0ZCknDQogICAgZGV2aWNlICAgICA9ICc4OEU4MDUzIE1hcnZlbGwgWXVrb24gODhFODA1 MyBQQ0ktRSBHaWdhYml0IEV0aGVybmV0IENvbnRyb2xsZXInDQogICAgY2xhc3MgICAgICA9 IG5ldHdvcmsNCiAgICBzdWJjbGFzcyAgID0gZXRoZXJuZXQNCiAgICBjYXAgMDFbNDhdID0g cG93ZXJzcGVjIDIgIHN1cHBvcnRzIEQwIEQxIEQyIEQzICBjdXJyZW50IEQwDQogICAgY2Fw IDAzWzUwXSA9IFZQRA0KICAgIGNhcCAwNVs1Y10gPSBNU0kgc3VwcG9ydHMgMiBtZXNzYWdl cywgNjQgYml0IGVuYWJsZWQgd2l0aCAyIG1lc3NhZ2VzDQogICAgY2FwIDEwW2UwXSA9IFBD SS1FeHByZXNzIDEgbGVnYWN5IGVuZHBvaW50DQpub25lMUBwY2kwOjQ6MTg6MDoJY2xhc3M9 MHgwYzAwMTAgY2FyZD0weDgwOGExMDQzIGNoaXA9MHgzMDQ0MTEwNiByZXY9MHg4MCBoZHI9 MHgwMA0KICAgIHZlbmRvciAgICAgPSAnVklBIFRlY2hub2xvZ2llcyBJbmMnDQogICAgZGV2 aWNlICAgICA9ICdWVDYzMDYgVklBIEZpcmUgSUkgSUVFRS0xMzk0IE9IQ0kgTGluayBMYXll ciBDb250cm9sbGVyJw0KICAgIGNsYXNzICAgICAgPSBzZXJpYWwgYnVzDQogICAgc3ViY2xh c3MgICA9IEZpcmVXaXJlDQogICAgY2FwIDAxWzUwXSA9IHBvd2Vyc3BlYyAyICBzdXBwb3J0 cyBEMCBEMiBEMyAgY3VycmVudCBEMA0KYW5nbGVwb2lzZSMgcGNpY29uZiAtbHZiYxtbMTNg ZWNobyAncGx1ZyBpbiAgaHViIG9uIGZyb250IHBhbmVsJxtbMTNgcGNpY29uZiAtbHZiYxtb SxtbMTNgdXNiZGV2cyAtdhtbSw0NCkNvbnRyb2xsZXIgL2Rldi91c2IwOg0KYWRkciAxOiBm dWxsIHNwZWVkLCBzZWxmIHBvd2VyZWQsIGNvbmZpZyAxLCBPSENJIHJvb3QgaHViKDB4MDAw MCksIEFjZXJMYWJzKDB4MDAwMCksIHJldiAxLjAwDQogcG9ydCAxIGFkZHIgMjogZnVsbCBz cGVlZCwgc2VsZiBwb3dlcmVkLCBjb25maWcgMSwgcHJvZHVjdCAweDIwNDYoMHgyMDQ2KSwg dmVuZG9yIDB4MDQ1MSgweDA0NTEpLCByZXYgMS4yNQ0KICBwb3J0IDEgcG93ZXJlZA0KICBw b3J0IDIgcG93ZXJlZA0KICBwb3J0IDMgcG93ZXJlZA0KICBwb3J0IDQgcG93ZXJlZA0KIHBv cnQgMiBwb3dlcmVkDQogcG9ydCAzIHBvd2VyZWQNCkNvbnRyb2xsZXIgL2Rldi91c2IxOg0K YWRkciAxOiBmdWxsIHNwZWVkLCBzZWxmIHBvd2VyZWQsIGNvbmZpZyAxLCBPSENJIHJvb3Qg aHViKDB4MDAwMCksIEFjZXJMYWJzKDB4MDAwMCksIHJldiAxLjAwDQogcG9ydCAxIHBvd2Vy ZWQNCiBwb3J0IDIgcG93ZXJlZA0KIHBvcnQgMyBwb3dlcmVkDQpDb250cm9sbGVyIC9kZXYv dXNiMjoNCmFkZHIgMTogZnVsbCBzcGVlZCwgc2VsZiBwb3dlcmVkLCBjb25maWcgMSwgT0hD SSByb290IGh1YigweDAwMDApLCBBY2VyTGFicygweDAwMDApLCByZXYgMS4wMA0KIHBvcnQg MSBwb3dlcmVkDQogcG9ydCAyIHBvd2VyZWQNCiBwb3J0IDMgcG93ZXJlZA0KQ29udHJvbGxl ciAvZGV2L3VzYjM6DQphZGRyIDE6IGhpZ2ggc3BlZWQsIHNlbGYgcG93ZXJlZCwgY29uZmln IDEsIEVIQ0kgcm9vdCBodWIoMHgwMDAwKSwgQWNlckxhYnMoMHgwMDAwKSwgcmV2IDEuMDAN CiBwb3J0IDEgcG93ZXJlZA0KIHBvcnQgMiBwb3dlcmVkDQogcG9ydCAzIHBvd2VyZWQNCiBw b3J0IDQgcG93ZXJlZA0KIHBvcnQgNSBhZGRyIDI6IGhpZ2ggc3BlZWQsIHNlbGYgcG93ZXJl ZCwgY29uZmlnIDEsIFVTQjIuMCBIdWIoMHgwNjA2KSwgdmVuZG9yIDB4MDVlMygweDA1ZTMp LCByZXYgNy4wMg0KICBwb3J0IDEgcG93ZXJlZA0KICBwb3J0IDIgcG93ZXJlZA0KICBwb3J0 IDMgcG93ZXJlZA0KICBwb3J0IDQgcG93ZXJlZA0KIHBvcnQgNiBwb3dlcmVkDQogcG9ydCA3 IHBvd2VyZWQNCiBwb3J0IDggcG93ZXJlZA0KYW5nbGVwb2lzZSMgDQ0KYW5nbGVwb2lzZSMg dXNiZGV2cyAtdhtbMTNgcGNpY29uZiAtbHZiYw0NCmhvc3RiMEBwY2kwOjA6MDowOgljbGFz cz0weDA2MDAwMCBjYXJkPTB4ODE4NTEwNDMgY2hpcD0weDU5NTAxMDAyIHJldj0weDEwIGhk cj0weDAwDQogICAgdmVuZG9yICAgICA9ICdBVEkgVGVjaG5vbG9naWVzIEluYycNCiAgICBk ZXZpY2UgICAgID0gJ1JTNDgwIEhvc3QgQnJpZGdlJw0KICAgIGNsYXNzICAgICAgPSBicmlk Z2UNCiAgICBzdWJjbGFzcyAgID0gSE9TVC1QQ0kNCnBjaWIxQHBjaTA6MDoyOjA6CWNsYXNz PTB4MDYwNDAwIGNhcmQ9MHg1OTUwMTAwMiBjaGlwPTB4NWEzNDEwMDIgcmV2PTB4MDAgaGRy PTB4MDENCiAgICB2ZW5kb3IgICAgID0gJ0FUSSBUZWNobm9sb2dpZXMgSW5jJw0KICAgIGRl dmljZSAgICAgPSAnUlM0ODAgUENJLVggUm9vdCBQb3J0Jw0KICAgIGNsYXNzICAgICAgPSBi cmlkZ2UNCiAgICBzdWJjbGFzcyAgID0gUENJLVBDSQ0KICAgIGNhcCAwMVs1MF0gPSBwb3dl cnNwZWMgMyAgc3VwcG9ydHMgRDAgRDMgIGN1cnJlbnQgRDANCiAgICBjYXAgMTBbNThdID0g UENJLUV4cHJlc3MgMSByb290IHBvcnQNCiAgICBjYXAgMDVbODBdID0gTVNJIHN1cHBvcnRz IDEgbWVzc2FnZSANCiAgICBjYXAgMGRbYjBdID0gUENJIEJyaWRnZSBjYXJkPTB4NTk1MDEw MDINCiAgICBjYXAgMDhbYjhdID0gSFQgTVNJIGZpeGVkIGFkZHJlc3Mgd2luZG93IGVuYWJs ZWQgYXQgMHhmZWUwMDAwMA0KcGNpYjJAcGNpMDowOjY6MDoJY2xhc3M9MHgwNjA0MDAgY2Fy ZD0weDU5NTAxMDAyIGNoaXA9MHg1YTM4MTAwMiByZXY9MHgwMCBoZHI9MHgwMQ0KICAgIHZl bmRvciAgICAgPSAnQVRJIFRlY2hub2xvZ2llcyBJbmMnDQogICAgZGV2aWNlICAgICA9ICdS UzQ4MCBQQ0kgQnJpZGdlJw0KICAgIGNsYXNzICAgICAgPSBicmlkZ2UNCiAgICBzdWJjbGFz cyAgID0gUENJLVBDSQ0KICAgIGNhcCAwMVs1MF0gPSBwb3dlcnNwZWMgMyAgc3VwcG9ydHMg RDAgRDMgIGN1cnJlbnQgRDANCiAgICBjYXAgMTBbNThdID0gUENJLUV4cHJlc3MgMSByb290 IHBvcnQNCiAgICBjYXAgMDVbODBdID0gTVNJIHN1cHBvcnRzIDEgbWVzc2FnZSANCiAgICBj YXAgMGRbYjBdID0gUENJIEJyaWRnZSBjYXJkPTB4NTk1MDEwMDINCiAgICBjYXAgMDhbYjhd ID0gSFQgTVNJIGZpeGVkIGFkZHJlc3Mgd2luZG93IGVuYWJsZWQgYXQgMHhmZWUwMDAwMA0K cGNpYjNAcGNpMDowOjc6MDoJY2xhc3M9MHgwNjA0MDAgY2FyZD0weDU5NTAxMDAyIGNoaXA9 MHg1YTM5MTAwMiByZXY9MHgwMCBoZHI9MHgwMQ0KICAgIHZlbmRvciAgICAgPSAnQVRJIFRl Y2hub2xvZ2llcyBJbmMnDQogICAgZGV2aWNlICAgICA9ICdSUzQ4MCBQQ0kgQnJpZGdlJw0K ICAgIGNsYXNzICAgICAgPSBicmlkZ2UNCiAgICBzdWJjbGFzcyAgID0gUENJLVBDSQ0KICAg IGNhcCAwMVs1MF0gPSBwb3dlcnNwZWMgMyAgc3VwcG9ydHMgRDAgRDMgIGN1cnJlbnQgRDAN CiAgICBjYXAgMTBbNThdID0gUENJLUV4cHJlc3MgMSByb290IHBvcnQNCiAgICBjYXAgMDVb ODBdID0gTVNJIHN1cHBvcnRzIDEgbWVzc2FnZSANCiAgICBjYXAgMGRbYjBdID0gUENJIEJy aWRnZSBjYXJkPTB4NTk1MDEwMDINCiAgICBjYXAgMDhbYjhdID0gSFQgTVNJIGZpeGVkIGFk ZHJlc3Mgd2luZG93IGVuYWJsZWQgYXQgMHhmZWUwMDAwMA0KaG9zdGIxQHBjaTA6MDoyNDow OgljbGFzcz0weDA2MDAwMCBjYXJkPTB4MDAwMDAwMDAgY2hpcD0weDExMDAxMDIyIHJldj0w eDAwIGhkcj0weDAwDQogICAgdmVuZG9yICAgICA9ICdBZHZhbmNlZCBNaWNybyBEZXZpY2Vz IChBTUQpJw0KICAgIGRldmljZSAgICAgPSAnKEs4KSBBdGhsb24gNjQvT3B0ZXJvbiBIeXBl clRyYW5zcG9ydCBUZWNobm9sb2d5IENvbmZpZ3VyYXRpb24nDQogICAgY2xhc3MgICAgICA9 IGJyaWRnZQ0KICAgIHN1YmNsYXNzICAgPSBIT1NULVBDSQ0KICAgIGNhcCAwOFs4MF0gPSBI VCBob3N0DQpob3N0YjJAcGNpMDowOjI0OjE6CWNsYXNzPTB4MDYwMDAwIGNhcmQ9MHgwMDAw MDAwMCBjaGlwPTB4MTEwMTEwMjIgcmV2PTB4MDAgaGRyPTB4MDANCiAgICB2ZW5kb3IgICAg ID0gJ0FkdmFuY2VkIE1pY3JvIERldmljZXMgKEFNRCknDQogICAgZGV2aWNlICAgICA9ICco SzgpIEF0aGxvbiA2NC9PcHRlcm9uIEFkZHJlc3MgTWFwJw0KICAgIGNsYXNzICAgICAgPSBi cmlkZ2UNCiAgICBzdWJjbGFzcyAgID0gSE9TVC1QQ0kNCmhvc3RiM0BwY2kwOjA6MjQ6MjoJ Y2xhc3M9MHgwNjAwMDAgY2FyZD0weDAwMDAwMDAwIGNoaXA9MHgxMTAyMTAyMiByZXY9MHgw MCBoZHI9MHgwMA0KICAgIHZlbmRvciAgICAgPSAnQWR2YW5jZWQgTWljcm8gRGV2aWNlcyAo QU1EKScNCiAgICBkZXZpY2UgICAgID0gJyhLOCkgQXRobG9uIDY0L09wdGVyb24gRFJBTSBD b250cm9sbGVyJw0KICAgIGNsYXNzICAgICAgPSBicmlkZ2UNCiAgICBzdWJjbGFzcyAgID0g SE9TVC1QQ0kNCmhvc3RiNEBwY2kwOjA6MjQ6MzoJY2xhc3M9MHgwNjAwMDAgY2FyZD0weDAw MDAwMDAwIGNoaXA9MHgxMTAzMTAyMiByZXY9MHgwMCBoZHI9MHgwMA0KICAgIHZlbmRvciAg ICAgPSAnQWR2YW5jZWQgTWljcm8gRGV2aWNlcyAoQU1EKScNCiAgICBkZXZpY2UgICAgID0g JyhLOCkgQXRobG9uIDY0L09wdGVyb24gTWlzY2VsbGFuZW91cyBDb250cm9sJw0KICAgIGNs YXNzICAgICAgPSBicmlkZ2UNCiAgICBzdWJjbGFzcyAgID0gSE9TVC1QQ0kNCnBjaWI0QHBj aTA6MDoyNTowOgljbGFzcz0weDA2MDQwMCBjYXJkPTB4MDAwMDAwMDAgY2hpcD0weDUyNDkx MGI5IHJldj0weDAwIGhkcj0weDAxDQogICAgdmVuZG9yICAgICA9ICdBY2VyIExhYnMgSW5j b3Jwb3JhdGVkIChBTGkvVUxpKScNCiAgICBkZXZpY2UgICAgID0gJ001MjQ5IEh5cGVyVHJh bnNwb3J0IHRvIFBDSSBCcmlkZ2UnDQogICAgY2xhc3MgICAgICA9IGJyaWRnZQ0KICAgIHN1 YmNsYXNzICAgPSBQQ0ktUENJDQogICAgY2FwIDA4W2MwXSA9IEhUIE1TSSBmaXhlZCBhZGRy ZXNzIHdpbmRvdyBlbmFibGVkIGF0IDB4ZmVlMDAwMDANCm9oY2kwQHBjaTA6MDoyODowOglj bGFzcz0weDBjMDMxMCBjYXJkPTB4ODE1NjEwNDMgY2hpcD0weDUyMzcxMGI5IHJldj0weDAz IGhkcj0weDAwDQogICAgdmVuZG9yICAgICA9ICdBY2VyIExhYnMgSW5jb3Jwb3JhdGVkIChB TGkvVUxpKScNCiAgICBkZXZpY2UgICAgID0gJ001MjczIEExIGZvciB3aW5kb3dzIHdpbiA5 OCBPcGVuSENJIDEuMSBVU0IgdG8gIDIuMCcNCiAgICBjbGFzcyAgICAgID0gc2VyaWFsIGJ1 cw0KICAgIHN1YmNsYXNzICAgPSBVU0INCm9oY2kxQHBjaTA6MDoyODoxOgljbGFzcz0weDBj MDMxMCBjYXJkPTB4ODE1NjEwNDMgY2hpcD0weDUyMzcxMGI5IHJldj0weDAzIGhkcj0weDAw DQogICAgdmVuZG9yICAgICA9ICdBY2VyIExhYnMgSW5jb3Jwb3JhdGVkIChBTGkvVUxpKScN CiAgICBkZXZpY2UgICAgID0gJ001MjczIEExIGZvciB3aW5kb3dzIHdpbiA5OCBPcGVuSENJ IDEuMSBVU0IgdG8gIDIuMCcNCiAgICBjbGFzcyAgICAgID0gc2VyaWFsIGJ1cw0KICAgIHN1 YmNsYXNzICAgPSBVU0INCm9oY2kyQHBjaTA6MDoyODoyOgljbGFzcz0weDBjMDMxMCBjYXJk PTB4ODE1NjEwNDMgY2hpcD0weDUyMzcxMGI5IHJldj0weDAzIGhkcj0weDAwDQogICAgdmVu ZG9yICAgICA9ICdBY2VyIExhYnMgSW5jb3Jwb3JhdGVkIChBTGkvVUxpKScNCiAgICBkZXZp Y2UgICAgID0gJ001MjczIEExIGZvciB3aW5kb3dzIHdpbiA5OCBPcGVuSENJIDEuMSBVU0Ig dG8gIDIuMCcNCiAgICBjbGFzcyAgICAgID0gc2VyaWFsIGJ1cw0KICAgIHN1YmNsYXNzICAg PSBVU0INCmVoY2kwQHBjaTA6MDoyODozOgljbGFzcz0weDBjMDMyMCBjYXJkPTB4ODE1NjEw NDMgY2hpcD0weDUyMzkxMGI5IHJldj0weDAxIGhkcj0weDAwDQogICAgdmVuZG9yICAgICA9 ICdBY2VyIExhYnMgSW5jb3Jwb3JhdGVkIChBTGkvVUxpKScNCiAgICBkZXZpY2UgICAgID0g J1VTQiAyLjAgRW5oYW5jZWQgSG9zdCBDb250cm9sbGVyJw0KICAgIGNsYXNzICAgICAgPSBz ZXJpYWwgYnVzDQogICAgc3ViY2xhc3MgICA9IFVTQg0KICAgIGNhcCAwMVs1MF0gPSBwb3dl cnNwZWMgMiAgc3VwcG9ydHMgRDAgRDMgIGN1cnJlbnQgRDANCiAgICBjYXAgMGFbNThdID0g RUhDSSBEZWJ1ZyBQb3J0IGF0IG9mZnNldCAweDkwIGluIG1hcCAweDE0DQpoZGFjMEBwY2kw OjA6Mjk6MDoJY2xhc3M9MHgwNDAzMDAgY2FyZD0weDgxYjQxMDQzIGNoaXA9MHg1NDYxMTBi OSByZXY9MHgwMCBoZHI9MHgwMA0KICAgIHZlbmRvciAgICAgPSAnQWNlciBMYWJzIEluY29y cG9yYXRlZCAoQUxpL1VMaSknDQogICAgZGV2aWNlICAgICA9ICc/PyBNaWNyb3NvZnQgVUFB IEJ1cyBEcml2ZXIgZm9yIEhpZ2ggRGVmaW5pdGlvbiBBdWRpbycNCiAgICBjbGFzcyAgICAg ID0gbXVsdGltZWRpYQ0KICAgIHN1YmNsYXNzICAgPSBIREENCiAgICBjYXAgMDFbNTBdID0g cG93ZXJzcGVjIDIgIHN1cHBvcnRzIEQwIEQzICBjdXJyZW50IEQwDQppc2FiMEBwY2kwOjA6 MzA6MDoJY2xhc3M9MHgwNjAxMDAgY2FyZD0weDgxNTYxMDQzIGNoaXA9MHgxNTczMTBiOSBy ZXY9MHgzMSBoZHI9MHgwMA0KICAgIHZlbmRvciAgICAgPSAnQWNlciBMYWJzIEluY29ycG9y YXRlZCAoQUxpL1VMaSknDQogICAgZGV2aWNlICAgICA9ICdBTEkgTTE1NzMgU291dGggQnJp ZGdlIHdpdGggSHlwZXJ0cmFuc3BvcnQgU3VwcG9ydCcNCiAgICBjbGFzcyAgICAgID0gYnJp ZGdlDQogICAgc3ViY2xhc3MgICA9IFBDSS1JU0ENCm5vbmUwQHBjaTA6MDozMDoxOgljbGFz cz0weDA2ODAwMCBjYXJkPTB4ODE1NjEwNDMgY2hpcD0weDcxMDExMGI5IHJldj0weDAwIGhk cj0weDAwDQogICAgdmVuZG9yICAgICA9ICdBY2VyIExhYnMgSW5jb3Jwb3JhdGVkIChBTGkv VUxpKScNCiAgICBkZXZpY2UgICAgID0gJ0FMSSBNNzEwMSBQb3dlciBNYW5hZ2VtZW50IENv bnRyb2xsZXInDQogICAgY2xhc3MgICAgICA9IGJyaWRnZQ0KYXRhcGNpMEBwY2kwOjA6MzE6 MDoJY2xhc3M9MHgwMTAxOGEgY2FyZD0weDgxNTYxMDQzIGNoaXA9MHg1MjI5MTBiOSByZXY9 MHhjNyBoZHI9MHgwMA0KICAgIHZlbmRvciAgICAgPSAnQWNlciBMYWJzIEluY29ycG9yYXRl ZCAoQUxpL1VMaSknDQogICAgZGV2aWNlICAgICA9ICdNNTIyOSBTb3V0aGJyaWRnZSBFSURF IENvbnRyb2xsZXInDQogICAgY2xhc3MgICAgICA9IG1hc3Mgc3RvcmFnZQ0KICAgIHN1YmNs YXNzICAgPSBBVEENCiAgICBjYXAgMDFbNjBdID0gcG93ZXJzcGVjIDIgIHN1cHBvcnRzIEQw IEQzICBjdXJyZW50IEQwDQphdGFwY2kxQHBjaTA6MDozMToxOgljbGFzcz0weDAxMDQwMCBj YXJkPTB4ODE1NjEwNDMgY2hpcD0weDUyODcxMGI5IHJldj0weDAyIGhkcj0weDAwDQogICAg dmVuZG9yICAgICA9ICdBY2VyIExhYnMgSW5jb3Jwb3JhdGVkIChBTGkvVUxpKScNCiAgICBk ZXZpY2UgICAgID0gJzUyODcxODQ5IEFMSSBTQVRBIGNvbnRyb2xsZXInDQogICAgY2xhc3Mg ICAgICA9IG1hc3Mgc3RvcmFnZQ0KICAgIHN1YmNsYXNzICAgPSBSQUlEDQogICAgY2FwIDAx WzYwXSA9IHBvd2Vyc3BlYyAyICBzdXBwb3J0cyBEMCBEMyAgY3VycmVudCBEMA0KdmdhcGNp MEBwY2kwOjE6MDowOgljbGFzcz0weDAzMDAwMCBjYXJkPTB4MzAwMDE3NGIgY2hpcD0weDVi NjMxMDAyIHJldj0weDAwIGhkcj0weDAwDQogICAgdmVuZG9yICAgICA9ICdBVEkgVGVjaG5v bG9naWVzIEluYycNCiAgICBkZXZpY2UgICAgID0gJ1JhZGVvbiBYNTUwIFNlcmllcycNCiAg ICBjbGFzcyAgICAgID0gZGlzcGxheQ0KICAgIHN1YmNsYXNzICAgPSBWR0ENCiAgICBjYXAg MDFbNTBdID0gcG93ZXJzcGVjIDIgIHN1cHBvcnRzIEQwIEQxIEQyIEQzICBjdXJyZW50IEQw DQogICAgY2FwIDEwWzU4XSA9IFBDSS1FeHByZXNzIDEgZW5kcG9pbnQNCiAgICBjYXAgMDVb ODBdID0gTVNJIHN1cHBvcnRzIDEgbWVzc2FnZSwgNjQgYml0IA0KdmdhcGNpMUBwY2kwOjE6 MDoxOgljbGFzcz0weDAzODAwMCBjYXJkPTB4MzAwMTE3NGIgY2hpcD0weDViNzMxMDAyIHJl dj0weDAwIGhkcj0weDAwDQogICAgdmVuZG9yICAgICA9ICdBVEkgVGVjaG5vbG9naWVzIElu YycNCiAgICBkZXZpY2UgICAgID0gJ1JhZGVvbiBYNTUwIFNlcmllcyAtIFNlY29uZGFyeScN CiAgICBjbGFzcyAgICAgID0gZGlzcGxheQ0KICAgIGNhcCAwMVs1MF0gPSBwb3dlcnNwZWMg MiAgc3VwcG9ydHMgRDAgRDEgRDIgRDMgIGN1cnJlbnQgRDANCiAgICBjYXAgMTBbNThdID0g UENJLUV4cHJlc3MgMSBlbmRwb2ludA0KbXNrYzBAcGNpMDoyOjA6MDoJY2xhc3M9MHgwMjAw MDAgY2FyZD0weDgxNDIxMDQzIGNoaXA9MHg0MzYyMTFhYiByZXY9MHgxOSBoZHI9MHgwMA0K ICAgIHZlbmRvciAgICAgPSAnTWFydmVsbCBTZW1pY29uZHVjdG9yIChXYXM6IEdhbGlsZW8g VGVjaG5vbG9neSBMdGQpJw0KICAgIGRldmljZSAgICAgPSAnODhFODA1MyBNYXJ2ZWxsIFl1 a29uIDg4RTgwNTMgUENJLUUgR2lnYWJpdCBFdGhlcm5ldCBDb250cm9sbGVyJw0KICAgIGNs YXNzICAgICAgPSBuZXR3b3JrDQogICAgc3ViY2xhc3MgICA9IGV0aGVybmV0DQogICAgY2Fw IDAxWzQ4XSA9IHBvd2Vyc3BlYyAyICBzdXBwb3J0cyBEMCBEMSBEMiBEMyAgY3VycmVudCBE MA0KICAgIGNhcCAwM1s1MF0gPSBWUEQNCiAgICBjYXAgMDVbNWNdID0gTVNJIHN1cHBvcnRz IDIgbWVzc2FnZXMsIDY0IGJpdCBlbmFibGVkIHdpdGggMiBtZXNzYWdlcw0KICAgIGNhcCAx MFtlMF0gPSBQQ0ktRXhwcmVzcyAxIGxlZ2FjeSBlbmRwb2ludA0Kbm9uZTFAcGNpMDo0OjE4 OjA6CWNsYXNzPTB4MGMwMDEwIGNhcmQ9MHg4MDhhMTA0MyBjaGlwPTB4MzA0NDExMDYgcmV2 PTB4ODAgaGRyPTB4MDANCiAgICB2ZW5kb3IgICAgID0gJ1ZJQSBUZWNobm9sb2dpZXMgSW5j Jw0KICAgIGRldmljZSAgICAgPSAnVlQ2MzA2IFZJQSBGaXJlIElJIElFRUUtMTM5NCBPSENJ IExpbmsgTGF5ZXIgQ29udHJvbGxlcicNCiAgICBjbGFzcyAgICAgID0gc2VyaWFsIGJ1cw0K ICAgIHN1YmNsYXNzICAgPSBGaXJlV2lyZQ0KICAgIGNhcCAwMVs1MF0gPSBwb3dlcnNwZWMg MiAgc3VwcG9ydHMgRDAgRDIgRDMgIGN1cnJlbnQgRDANCmFuZ2xlcG9pc2UjIGxzcGNpIC12 dg0NCjAwOjAwLjAgSG9zdCBicmlkZ2U6IEFUSSBUZWNobm9sb2dpZXMgSW5jIFJTNDgwIEhv c3QgQnJpZGdlIChyZXYgMTApDQoJU3Vic3lzdGVtOiBBU1VTVGVLIENvbXB1dGVyIEluYy4g RGV2aWNlIDgxODUNCglDb250cm9sOiBJL08tIE1lbSsgQnVzTWFzdGVyKyBTcGVjQ3ljbGUt IE1lbVdJTlYtIFZHQVNub29wLSBQYXJFcnItIFN0ZXBwaW5nLSBTRVJSLSBGYXN0QjJCLSBE aXNJTlR4LQ0KCVN0YXR1czogQ2FwLSA2Nk1IeisgVURGLSBGYXN0QjJCLSBQYXJFcnItIERF VlNFTD1tZWRpdW0gPlRBYm9ydC0gPFRBYm9ydC0gPE1BYm9ydCsgPlNFUlItIDxQRVJSLSBJ TlR4LQ0KCUxhdGVuY3k6IDANCg0KMDA6MDIuMCBQQ0kgYnJpZGdlOiBBVEkgVGVjaG5vbG9n aWVzIEluYyBSUzQ4MCBQQ0ktWCBSb290IFBvcnQgKHByb2ctaWYgMDAgW05vcm1hbCBkZWNv ZGVdKQ0KCUNvbnRyb2w6IEkvTysgTWVtKyBCdXNNYXN0ZXIrIFNwZWNDeWNsZS0gTWVtV0lO Vi0gVkdBU25vb3AtIFBhckVyci0gU3RlcHBpbmctIFNFUlIrIEZhc3RCMkItIERpc0lOVHgt DQoJU3RhdHVzOiBDYXArIDY2TUh6LSBVREYtIEZhc3RCMkItIFBhckVyci0gREVWU0VMPWZh c3QgPlRBYm9ydC0gPFRBYm9ydC0gPE1BYm9ydC0gPlNFUlItIDxQRVJSLSBJTlR4LQ0KCUxh dGVuY3k6IDAsIENhY2hlIExpbmUgU2l6ZTogNjQgYnl0ZXMNCglCdXM6IHByaW1hcnk9MDAs IHNlY29uZGFyeT0wMSwgc3Vib3JkaW5hdGU9MDEsIHNlYy1sYXRlbmN5PTANCglJL08gYmVo aW5kIGJyaWRnZTogMDAwMGIwMDAtMDAwMGJmZmYNCglNZW1vcnkgYmVoaW5kIGJyaWRnZTog ZmUwMDAwMDAtZmU4ZmZmZmYNCglQcmVmZXRjaGFibGUgbWVtb3J5IGJlaGluZCBicmlkZ2U6 IDAwMDAwMDAwY2ZmMDAwMDAtMDAwMDAwMDBkZmVmZmZmZg0KCVNlY29uZGFyeSBzdGF0dXM6 IDY2TUh6LSBGYXN0QjJCLSBQYXJFcnItIERFVlNFTD1mYXN0ID5UQWJvcnQtIDxUQWJvcnQt IDxNQWJvcnQrIDxTRVJSLSA8UEVSUi0NCglCcmlkZ2VDdGw6IFBhcml0eSsgU0VSUisgTm9J U0EtIFZHQSsgTUFib3J0LSA+UmVzZXQtIEZhc3RCMkItDQoJCVByaURpc2NUbXItIFNlY0Rp c2NUbXItIERpc2NUbXJTdGF0LSBEaXNjVG1yU0VSUkVuLQ0KCUNhcGFiaWxpdGllczogWzUw XSBQb3dlciBNYW5hZ2VtZW50IHZlcnNpb24gMw0KCQlGbGFnczogUE1FQ2xrLSBEU0ktIEQx LSBEMi0gQXV4Q3VycmVudD0wbUEgUE1FKEQwKyxEMS0sRDItLEQzaG90KyxEM2NvbGQrKQ0K CQlTdGF0dXM6IEQwIFBNRS1FbmFibGUtIERTZWw9MCBEU2NhbGU9MCBQTUUtDQoJQ2FwYWJp bGl0aWVzOiBbNThdIEV4cHJlc3MgKHYxKSBSb290IFBvcnQgKFNsb3QtKSwgTVNJIDAwDQoJ CURldkNhcDoJTWF4UGF5bG9hZCAxMjggYnl0ZXMsIFBoYW50RnVuYyAwLCBMYXRlbmN5IEww cyA8NjRucywgTDEgPDF1cw0KCQkJRXh0VGFnKyBSQkUtIEZMUmVzZXQtDQoJCURldkN0bDoJ UmVwb3J0IGVycm9yczogQ29ycmVjdGFibGUtIE5vbi1GYXRhbC0gRmF0YWwtIFVuc3VwcG9y dGVkLQ0KCQkJUmx4ZE9yZCsgRXh0VGFnLSBQaGFudEZ1bmMtIEF1eFB3ci0gTm9Tbm9vcCsN CgkJCU1heFBheWxvYWQgMTI4IGJ5dGVzLCBNYXhSZWFkUmVxIDEyOCBieXRlcw0KCQlEZXZT dGE6CUNvcnJFcnItIFVuY29yckVyci0gRmF0YWxFcnItIFVuc3VwcFJlcS0gQXV4UHdyLSBU cmFuc1BlbmQtDQoJCUxua0NhcDoJUG9ydCAjMCwgU3BlZWQgMi41R1QvcywgV2lkdGggeDE2 LCBBU1BNIEwwcyBMMSwgTGF0ZW5jeSBMMCA8NjRucywgTDEgPDF1cw0KCQkJQ2xvY2tQTS0g U3VwcmlzZS0gTExBY3RSZXAtIEJ3Tm90LQ0KCQlMbmtDdGw6CUFTUE0gRGlzYWJsZWQ7IFJD QiA2NCBieXRlcyBEaXNhYmxlZC0gUmV0cmFpbi0gQ29tbUNsay0NCgkJCUV4dFN5bmNoLSBD bG9ja1BNLSBBdXRXaWREaXMtIEJXSW50LSBBdXRCV0ludC0NCgkJTG5rU3RhOglTcGVlZCAy LjVHVC9zLCBXaWR0aCB4MTYsIFRyRXJyLSBUcmFpbi0gU2xvdENsaysgRExBY3RpdmUtIEJX TWdtdC0gQUJXTWdtdC0NCgkJUm9vdEN0bDogRXJyQ29ycmVjdGFibGUtIEVyck5vbi1GYXRh bC0gRXJyRmF0YWwtIFBNRUludEVuYS0gQ1JTVmlzaWJsZS0NCgkJUm9vdENhcDogQ1JTVmlz aWJsZS0NCgkJUm9vdFN0YTogUE1FIFJlcUlEIDAwMDAsIFBNRVN0YXR1cy0gUE1FUGVuZGlu Zy0NCglDYXBhYmlsaXRpZXM6IFs4MF0gTVNJOiBNYXNrLSA2NGJpdC0gQ291bnQ9MS8xIEVu YWJsZS0NCgkJQWRkcmVzczogMDAwMDAwMDAgIERhdGE6IDAwMDANCglDYXBhYmlsaXRpZXM6 IFtiMF0gU3Vic3lzdGVtOiBBVEkgVGVjaG5vbG9naWVzIEluYyBEZXZpY2UgNTk1MA0KCUNh cGFiaWxpdGllczogW2I4XSBIeXBlclRyYW5zcG9ydDogTVNJIE1hcHBpbmcgRW5hYmxlKyBG aXhlZCsNCg0KMDA6MDYuMCBQQ0kgYnJpZGdlOiBBVEkgVGVjaG5vbG9naWVzIEluYyBSUzQ4 MCBQQ0kgQnJpZGdlIChwcm9nLWlmIDAwIFtOb3JtYWwgZGVjb2RlXSkNCglDb250cm9sOiBJ L08rIE1lbSsgQnVzTWFzdGVyKyBTcGVjQ3ljbGUtIE1lbVdJTlYtIFZHQVNub29wLSBQYXJF cnItIFN0ZXBwaW5nLSBTRVJSKyBGYXN0QjJCLSBEaXNJTlR4LQ0KCVN0YXR1czogQ2FwKyA2 Nk1Iei0gVURGLSBGYXN0QjJCLSBQYXJFcnItIERFVlNFTD1mYXN0ID5UQWJvcnQtIDxUQWJv cnQtIDxNQWJvcnQtID5TRVJSLSA8UEVSUi0gSU5UeC0NCglMYXRlbmN5OiAwLCBDYWNoZSBM aW5lIFNpemU6IDY0IGJ5dGVzDQoJQnVzOiBwcmltYXJ5PTAwLCBzZWNvbmRhcnk9MDIsIHN1 Ym9yZGluYXRlPTAyLCBzZWMtbGF0ZW5jeT0wDQoJSS9PIGJlaGluZCBicmlkZ2U6IDAwMDBj MDAwLTAwMDBjZmZmDQoJTWVtb3J5IGJlaGluZCBicmlkZ2U6IGZlOTAwMDAwLWZlOWZmZmZm DQoJU2Vjb25kYXJ5IHN0YXR1czogNjZNSHotIEZhc3RCMkItIFBhckVyci0gREVWU0VMPWZh c3QgPlRBYm9ydC0gPFRBYm9ydC0gPE1BYm9ydCsgPFNFUlItIDxQRVJSLQ0KCUJyaWRnZUN0 bDogUGFyaXR5KyBTRVJSKyBOb0lTQSsgVkdBLSBNQWJvcnQtID5SZXNldC0gRmFzdEIyQi0N CgkJUHJpRGlzY1Rtci0gU2VjRGlzY1Rtci0gRGlzY1RtclN0YXQtIERpc2NUbXJTRVJSRW4t DQoJQ2FwYWJpbGl0aWVzOiBbNTBdIFBvd2VyIE1hbmFnZW1lbnQgdmVyc2lvbiAzDQoJCUZs YWdzOiBQTUVDbGstIERTSS0gRDEtIEQyLSBBdXhDdXJyZW50PTBtQSBQTUUoRDArLEQxLSxE Mi0sRDNob3QrLEQzY29sZCspDQoJCVN0YXR1czogRDAgUE1FLUVuYWJsZS0gRFNlbD0wIERT Y2FsZT0wIFBNRS0NCglDYXBhYmlsaXRpZXM6IFs1OF0gRXhwcmVzcyAodjEpIFJvb3QgUG9y dCAoU2xvdC0pLCBNU0kgMDANCgkJRGV2Q2FwOglNYXhQYXlsb2FkIDEyOCBieXRlcywgUGhh bnRGdW5jIDAsIExhdGVuY3kgTDBzIDw2NG5zLCBMMSA8MXVzDQoJCQlFeHRUYWcrIFJCRS0g RkxSZXNldC0NCgkJRGV2Q3RsOglSZXBvcnQgZXJyb3JzOiBDb3JyZWN0YWJsZS0gTm9uLUZh dGFsLSBGYXRhbC0gVW5zdXBwb3J0ZWQtDQoJCQlSbHhkT3JkKyBFeHRUYWctIFBoYW50RnVu Yy0gQXV4UHdyLSBOb1Nub29wKw0KCQkJTWF4UGF5bG9hZCAxMjggYnl0ZXMsIE1heFJlYWRS ZXEgMTI4IGJ5dGVzDQoJCURldlN0YToJQ29yckVyci0gVW5jb3JyRXJyLSBGYXRhbEVyci0g VW5zdXBwUmVxLSBBdXhQd3ItIFRyYW5zUGVuZC0NCgkJTG5rQ2FwOglQb3J0ICMzLCBTcGVl ZCAyLjVHVC9zLCBXaWR0aCB4MSwgQVNQTSBMMHMgTDEsIExhdGVuY3kgTDAgPDY0bnMsIEwx IDwxdXMNCgkJCUNsb2NrUE0tIFN1cHJpc2UtIExMQWN0UmVwLSBCd05vdC0NCgkJTG5rQ3Rs OglBU1BNIERpc2FibGVkOyBSQ0IgNjQgYnl0ZXMgRGlzYWJsZWQtIFJldHJhaW4tIENvbW1D bGstDQoJCQlFeHRTeW5jaC0gQ2xvY2tQTS0gQXV0V2lkRGlzLSBCV0ludC0gQXV0QldJbnQt DQoJCUxua1N0YToJU3BlZWQgMi41R1QvcywgV2lkdGggeDEsIFRyRXJyLSBUcmFpbi0gU2xv dENsaysgRExBY3RpdmUtIEJXTWdtdC0gQUJXTWdtdC0NCgkJUm9vdEN0bDogRXJyQ29ycmVj dGFibGUtIEVyck5vbi1GYXRhbC0gRXJyRmF0YWwtIFBNRUludEVuYS0gQ1JTVmlzaWJsZS0N CgkJUm9vdENhcDogQ1JTVmlzaWJsZS0NCgkJUm9vdFN0YTogUE1FIFJlcUlEIDAwMDAsIFBN RVN0YXR1cy0gUE1FUGVuZGluZy0NCglDYXBhYmlsaXRpZXM6IFs4MF0gTVNJOiBNYXNrLSA2 NGJpdC0gQ291bnQ9MS8xIEVuYWJsZS0NCgkJQWRkcmVzczogMDAwMDAwMDAgIERhdGE6IDAw MDANCglDYXBhYmlsaXRpZXM6IFtiMF0gU3Vic3lzdGVtOiBBVEkgVGVjaG5vbG9naWVzIElu YyBEZXZpY2UgNTk1MA0KCUNhcGFiaWxpdGllczogW2I4XSBIeXBlclRyYW5zcG9ydDogTVNJ IE1hcHBpbmcgRW5hYmxlKyBGaXhlZCsNCg0KMDA6MDcuMCBQQ0kgYnJpZGdlOiBBVEkgVGVj aG5vbG9naWVzIEluYyBSUzQ4MCBQQ0kgQnJpZGdlIChwcm9nLWlmIDAwIFtOb3JtYWwgZGVj b2RlXSkNCglDb250cm9sOiBJL08tIE1lbS0gQnVzTWFzdGVyKyBTcGVjQ3ljbGUtIE1lbVdJ TlYtIFZHQVNub29wLSBQYXJFcnItIFN0ZXBwaW5nLSBTRVJSKyBGYXN0QjJCLSBEaXNJTlR4 LQ0KCVN0YXR1czogQ2FwKyA2Nk1Iei0gVURGLSBGYXN0QjJCLSBQYXJFcnItIERFVlNFTD1m YXN0ID5UQWJvcnQtIDxUQWJvcnQtIDxNQWJvcnQtID5TRVJSLSA8UEVSUi0gSU5UeC0NCglM YXRlbmN5OiAwLCBDYWNoZSBMaW5lIFNpemU6IDY0IGJ5dGVzDQoJQnVzOiBwcmltYXJ5PTAw LCBzZWNvbmRhcnk9MDMsIHN1Ym9yZGluYXRlPTAzLCBzZWMtbGF0ZW5jeT0wDQoJU2Vjb25k YXJ5IHN0YXR1czogNjZNSHotIEZhc3RCMkItIFBhckVyci0gREVWU0VMPWZhc3QgPlRBYm9y dC0gPFRBYm9ydC0gPE1BYm9ydC0gPFNFUlItIDxQRVJSLQ0KCUJyaWRnZUN0bDogUGFyaXR5 KyBTRVJSKyBOb0lTQSsgVkdBLSBNQWJvcnQtID5SZXNldC0gRmFzdEIyQi0NCgkJUHJpRGlz Y1Rtci0gU2VjRGlzY1Rtci0gRGlzY1RtclN0YXQtIERpc2NUbXJTRVJSRW4tDQoJQ2FwYWJp bGl0aWVzOiBbNTBdIFBvd2VyIE1hbmFnZW1lbnQgdmVyc2lvbiAzDQoJCUZsYWdzOiBQTUVD bGstIERTSS0gRDEtIEQyLSBBdXhDdXJyZW50PTBtQSBQTUUoRDArLEQxLSxEMi0sRDNob3Qr LEQzY29sZCspDQoJCVN0YXR1czogRDAgUE1FLUVuYWJsZS0gRFNlbD0wIERTY2FsZT0wIFBN RS0NCglDYXBhYmlsaXRpZXM6IFs1OF0gRXhwcmVzcyAodjEpIFJvb3QgUG9ydCAoU2xvdC0p LCBNU0kgMDANCgkJRGV2Q2FwOglNYXhQYXlsb2FkIDEyOCBieXRlcywgUGhhbnRGdW5jIDAs IExhdGVuY3kgTDBzIDw2NG5zLCBMMSA8MXVzDQoJCQlFeHRUYWcrIFJCRS0gRkxSZXNldC0N CgkJRGV2Q3RsOglSZXBvcnQgZXJyb3JzOiBDb3JyZWN0YWJsZS0gTm9uLUZhdGFsLSBGYXRh bC0gVW5zdXBwb3J0ZWQtDQoJCQlSbHhkT3JkKyBFeHRUYWctIFBoYW50RnVuYy0gQXV4UHdy LSBOb1Nub29wKw0KCQkJTWF4UGF5bG9hZCAxMjggYnl0ZXMsIE1heFJlYWRSZXEgMTI4IGJ5 dGVzDQoJCURldlN0YToJQ29yckVyci0gVW5jb3JyRXJyLSBGYXRhbEVyci0gVW5zdXBwUmVx LSBBdXhQd3ItIFRyYW5zUGVuZC0NCgkJTG5rQ2FwOglQb3J0ICMyNDcsIFNwZWVkIDIuNUdU L3MsIFdpZHRoIHgxLCBBU1BNIEwwcyBMMSwgTGF0ZW5jeSBMMCA8NjRucywgTDEgPDF1cw0K CQkJQ2xvY2tQTS0gU3VwcmlzZS0gTExBY3RSZXAtIEJ3Tm90LQ0KCQlMbmtDdGw6CUFTUE0g RGlzYWJsZWQ7IFJDQiA2NCBieXRlcyBEaXNhYmxlZC0gUmV0cmFpbi0gQ29tbUNsay0NCgkJ CUV4dFN5bmNoLSBDbG9ja1BNLSBBdXRXaWREaXMtIEJXSW50LSBBdXRCV0ludC0NCgkJTG5r U3RhOglTcGVlZCAyLjVHVC9zLCBXaWR0aCB4MTYsIFRyRXJyLSBUcmFpbi0gU2xvdENsaysg RExBY3RpdmUtIEJXTWdtdC0gQUJXTWdtdC0NCgkJUm9vdEN0bDogRXJyQ29ycmVjdGFibGUt IEVyck5vbi1GYXRhbC0gRXJyRmF0YWwtIFBNRUludEVuYS0gQ1JTVmlzaWJsZS0NCgkJUm9v dENhcDogQ1JTVmlzaWJsZS0NCgkJUm9vdFN0YTogUE1FIFJlcUlEIDAwMDAsIFBNRVN0YXR1 cy0gUE1FUGVuZGluZy0NCglDYXBhYmlsaXRpZXM6IFs4MF0gTVNJOiBNYXNrLSA2NGJpdC0g Q291bnQ9MS8xIEVuYWJsZS0NCgkJQWRkcmVzczogMDAwMDAwMDAgIERhdGE6IDAwMDANCglD YXBhYmlsaXRpZXM6IFtiMF0gU3Vic3lzdGVtOiBBVEkgVGVjaG5vbG9naWVzIEluYyBEZXZp Y2UgNTk1MA0KCUNhcGFiaWxpdGllczogW2I4XSBIeXBlclRyYW5zcG9ydDogTVNJIE1hcHBp bmcgRW5hYmxlKyBGaXhlZCsNCg0KMDA6MTguMCBIb3N0IGJyaWRnZTogQWR2YW5jZWQgTWlj cm8gRGV2aWNlcyBbQU1EXSBLOCBbQXRobG9uNjQvT3B0ZXJvbl0gSHlwZXJUcmFuc3BvcnQg VGVjaG5vbG9neSBDb25maWd1cmF0aW9uDQoJQ29udHJvbDogSS9PLSBNZW0tIEJ1c01hc3Rl ci0gU3BlY0N5Y2xlLSBNZW1XSU5WLSBWR0FTbm9vcC0gUGFyRXJyLSBTdGVwcGluZy0gU0VS Ui0gRmFzdEIyQi0gRGlzSU5UeC0NCglTdGF0dXM6IENhcCsgNjZNSHotIFVERi0gRmFzdEIy Qi0gUGFyRXJyLSBERVZTRUw9ZmFzdCA+VEFib3J0LSA8VEFib3J0LSA8TUFib3J0LSA+U0VS Ui0gPFBFUlItIElOVHgtDQoJQ2FwYWJpbGl0aWVzOiBbODBdIEh5cGVyVHJhbnNwb3J0OiBI b3N0IG9yIFNlY29uZGFyeSBJbnRlcmZhY2UNCgkJQ29tbWFuZDogV2FybVJzdCsgRGJsRW5k LSBEZXZOdW09MCBDaGFpblNpZGUtIEhvc3RIaWRlKyBTbGF2ZS0gPEVPQ0Vyci0gRFVMLQ0K CQlMaW5rIENvbnRyb2w6IENGbEUtIENTVC0gQ0ZFLSA8TGtGYWlsLSBJbml0KyBFT0MtIFRY Ty0gPENSQ0Vycj0wIElzb2NFbi0gTFNFbi0gRXh0Q1RMLSA2NGItDQoJCUxpbmsgQ29uZmln OiBNTFdJPTE2Yml0IER3RmNJbi0gTUxXTz0xNmJpdCBEd0ZjT3V0LSBMV0k9MTZiaXQgRHdG Y0luRW4tIExXTz0xNmJpdCBEd0ZjT3V0RW4tDQoJCVJldmlzaW9uIElEOiAxLjAyDQoJCUxp bmsgRnJlcXVlbmN5OiAxLjBHSHoNCgkJTGluayBFcnJvcjogPFByb3QtIDxPdmZsLSA8RU9D LSBDVExUbS0NCgkJTGluayBGcmVxdWVuY3kgQ2FwYWJpbGl0eTogMjAwTUh6KyAzMDBNSHot IDQwME1IeisgNTAwTUh6LSA2MDBNSHorIDgwME1IeisgMS4wR0h6KyAxLjJHSHotIDEuNEdI ei0gMS42R0h6LSBWZW5kLQ0KCQlGZWF0dXJlIENhcGFiaWxpdHk6IElzb2NGQy0gTERUU1RP UCsgQ1JDVE0tIEVDVExULSA2NGJBLSBVSURSRC0gRXh0UlMtIFVDbmZFLQ0KDQowMDoxOC4x IEhvc3QgYnJpZGdlOiBBZHZhbmNlZCBNaWNybyBEZXZpY2VzIFtBTURdIEs4IFtBdGhsb242 NC9PcHRlcm9uXSBBZGRyZXNzIE1hcA0KCUNvbnRyb2w6IEkvTy0gTWVtLSBCdXNNYXN0ZXIt IFNwZWNDeWNsZS0gTWVtV0lOVi0gVkdBU25vb3AtIFBhckVyci0gU3RlcHBpbmctIFNFUlIt IEZhc3RCMkItIERpc0lOVHgtDQoJU3RhdHVzOiBDYXAtIDY2TUh6LSBVREYtIEZhc3RCMkIt IFBhckVyci0gREVWU0VMPWZhc3QgPlRBYm9ydC0gPFRBYm9ydC0gPE1BYm9ydC0gPlNFUlIt IDxQRVJSLSBJTlR4LQ0KDQowMDoxOC4yIEhvc3QgYnJpZGdlOiBBZHZhbmNlZCBNaWNybyBE ZXZpY2VzIFtBTURdIEs4IFtBdGhsb242NC9PcHRlcm9uXSBEUkFNIENvbnRyb2xsZXINCglD b250cm9sOiBJL08tIE1lbS0gQnVzTWFzdGVyLSBTcGVjQ3ljbGUtIE1lbVdJTlYtIFZHQVNu b29wLSBQYXJFcnItIFN0ZXBwaW5nLSBTRVJSLSBGYXN0QjJCLSBEaXNJTlR4LQ0KCVN0YXR1 czogQ2FwLSA2Nk1Iei0gVURGLSBGYXN0QjJCLSBQYXJFcnItIERFVlNFTD1mYXN0ID5UQWJv cnQtIDxUQWJvcnQtIDxNQWJvcnQtID5TRVJSLSA8UEVSUi0gSU5UeC0NCg0KMDA6MTguMyBI b3N0IGJyaWRnZTogQWR2YW5jZWQgTWljcm8gRGV2aWNlcyBbQU1EXSBLOCBbQXRobG9uNjQv T3B0ZXJvbl0gTWlzY2VsbGFuZW91cyBDb250cm9sDQoJQ29udHJvbDogSS9PLSBNZW0tIEJ1 c01hc3Rlci0gU3BlY0N5Y2xlLSBNZW1XSU5WLSBWR0FTbm9vcC0gUGFyRXJyLSBTdGVwcGlu Zy0gU0VSUi0gRmFzdEIyQi0gRGlzSU5UeC0NCglTdGF0dXM6IENhcC0gNjZNSHotIFVERi0g RmFzdEIyQi0gUGFyRXJyLSBERVZTRUw9ZmFzdCA+VEFib3J0LSA8VEFib3J0LSA8TUFib3J0 LSA+U0VSUi0gPFBFUlItIElOVHgtDQoNCjAwOjE5LjAgUENJIGJyaWRnZTogQUxpIENvcnBv cmF0aW9uIE01MjQ5IEhUVCB0byBQQ0kgQnJpZGdlIChwcm9nLWlmIDAwIFtOb3JtYWwgZGVj b2RlXSkNCglDb250cm9sOiBJL08rIE1lbSsgQnVzTWFzdGVyKyBTcGVjQ3ljbGUtIE1lbVdJ TlYtIFZHQVNub29wLSBQYXJFcnItIFN0ZXBwaW5nLSBTRVJSKyBGYXN0QjJCLSBEaXNJTlR4 LQ0KCVN0YXR1czogQ2FwKyA2Nk1Iei0gVURGLSBGYXN0QjJCLSBQYXJFcnItIERFVlNFTD1m YXN0ID5UQWJvcnQtIDxUQWJvcnQtIDxNQWJvcnQrID5TRVJSKyA8UEVSUi0gSU5UeC0NCglM YXRlbmN5OiAwDQoJQnVzOiBwcmltYXJ5PTAwLCBzZWNvbmRhcnk9MDQsIHN1Ym9yZGluYXRl PTA0LCBzZWMtbGF0ZW5jeT02NA0KCUkvTyBiZWhpbmQgYnJpZGdlOiAwMDAwZDAwMC0wMDAw ZGZmZg0KCU1lbW9yeSBiZWhpbmQgYnJpZGdlOiBmZWEwMDAwMC1mZWFmZmZmZg0KCVNlY29u ZGFyeSBzdGF0dXM6IDY2TUh6LSBGYXN0QjJCLSBQYXJFcnItIERFVlNFTD1tZWRpdW0gPlRB Ym9ydC0gPFRBYm9ydC0gPE1BYm9ydCsgPFNFUlIrIDxQRVJSKw0KCUJyaWRnZUN0bDogUGFy aXR5KyBTRVJSKyBOb0lTQSsgVkdBLSBNQWJvcnQtID5SZXNldC0gRmFzdEIyQi0NCgkJUHJp RGlzY1Rtci0gU2VjRGlzY1Rtci0gRGlzY1RtclN0YXQtIERpc2NUbXJTRVJSRW4tDQoJQ2Fw YWJpbGl0aWVzOiBbYzBdIEh5cGVyVHJhbnNwb3J0OiBNU0kgTWFwcGluZyBFbmFibGUrIEZp eGVkKw0KDQowMDoxYy4wIFVTQiBDb250cm9sbGVyOiBBTGkgQ29ycG9yYXRpb24gVVNCIDEu MSBDb250cm9sbGVyIChyZXYgMDMpIChwcm9nLWlmIDEwIFtPSENJXSkNCglTdWJzeXN0ZW06 IEFTVVNUZUsgQ29tcHV0ZXIgSW5jLiBEZXZpY2UgODE1Ng0KCUNvbnRyb2w6IEkvTysgTWVt KyBCdXNNYXN0ZXIrIFNwZWNDeWNsZS0gTWVtV0lOVisgVkdBU25vb3AtIFBhckVyci0gU3Rl cHBpbmctIFNFUlIrIEZhc3RCMkItIERpc0lOVHgtDQoJU3RhdHVzOiBDYXAtIDY2TUh6KyBV REYtIEZhc3RCMkIrIFBhckVyci0gREVWU0VMPW1lZGl1bSA+VEFib3J0LSA8VEFib3J0LSA8 TUFib3J0LSA+U0VSUi0gPFBFUlIrIElOVHgrDQoJTGF0ZW5jeTogNjQgKDIwMDAwbnMgbWF4 KSwgQ2FjaGUgTGluZSBTaXplOiA2NCBieXRlcw0KCUludGVycnVwdDogcGluIEEgcm91dGVk IHRvIElSUSAxNw0KCVJlZ2lvbiAwOiBNZW1vcnkgYXQgZmViZmMwMDAgKDMyLWJpdCwgbm9u LXByZWZldGNoYWJsZSkNCg0KMDA6MWMuMSBVU0IgQ29udHJvbGxlcjogQUxpIENvcnBvcmF0 aW9uIFVTQiAxLjEgQ29udHJvbGxlciAocmV2IDAzKSAocHJvZy1pZiAxMCBbT0hDSV0pDQoJ U3Vic3lzdGVtOiBBU1VTVGVLIENvbXB1dGVyIEluYy4gRGV2aWNlIDgxNTYNCglDb250cm9s OiBJL08rIE1lbSsgQnVzTWFzdGVyKyBTcGVjQ3ljbGUtIE1lbVdJTlYrIFZHQVNub29wLSBQ YXJFcnItIFN0ZXBwaW5nLSBTRVJSKyBGYXN0QjJCLSBEaXNJTlR4LQ0KCVN0YXR1czogQ2Fw LSA2Nk1IeisgVURGLSBGYXN0QjJCKyBQYXJFcnItIERFVlNFTD1tZWRpdW0gPlRBYm9ydC0g PFRBYm9ydC0gPE1BYm9ydC0gPlNFUlItIDxQRVJSKyBJTlR4Kw0KCUxhdGVuY3k6IDY0ICgy MDAwMG5zIG1heCksIENhY2hlIExpbmUgU2l6ZTogNjQgYnl0ZXMNCglJbnRlcnJ1cHQ6IHBp biBCIHJvdXRlZCB0byBJUlEgMTgNCglSZWdpb24gMDogTWVtb3J5IGF0IGZlYmZkMDAwICgz Mi1iaXQsIG5vbi1wcmVmZXRjaGFibGUpDQoNCjAwOjFjLjIgVVNCIENvbnRyb2xsZXI6IEFM aSBDb3Jwb3JhdGlvbiBVU0IgMS4xIENvbnRyb2xsZXIgKHJldiAwMykgKHByb2ctaWYgMTAg W09IQ0ldKQ0KCVN1YnN5c3RlbTogQVNVU1RlSyBDb21wdXRlciBJbmMuIERldmljZSA4MTU2 DQoJQ29udHJvbDogSS9PKyBNZW0rIEJ1c01hc3RlcisgU3BlY0N5Y2xlLSBNZW1XSU5WKyBW R0FTbm9vcC0gUGFyRXJyLSBTdGVwcGluZy0gU0VSUisgRmFzdEIyQi0gRGlzSU5UeC0NCglT dGF0dXM6IENhcC0gNjZNSHorIFVERi0gRmFzdEIyQisgUGFyRXJyLSBERVZTRUw9bWVkaXVt ID5UQWJvcnQtIDxUQWJvcnQtIDxNQWJvcnQtID5TRVJSLSA8UEVSUisgSU5UeCsNCglMYXRl bmN5OiA2NCAoMjAwMDBucyBtYXgpLCBDYWNoZSBMaW5lIFNpemU6IDY0IGJ5dGVzDQoJSW50 ZXJydXB0OiBwaW4gQyByb3V0ZWQgdG8gSVJRIDE5DQoJUmVnaW9uIDA6IE1lbW9yeSBhdCBm ZWJmZTAwMCAoMzItYml0LCBub24tcHJlZmV0Y2hhYmxlKQ0KDQowMDoxYy4zIFVTQiBDb250 cm9sbGVyOiBBTGkgQ29ycG9yYXRpb24gVVNCIDIuMCBDb250cm9sbGVyIChyZXYgMDEpIChw cm9nLWlmIDIwIFtFSENJXSkNCglTdWJzeXN0ZW06IEFTVVNUZUsgQ29tcHV0ZXIgSW5jLiBE ZXZpY2UgODE1Ng0KCUNvbnRyb2w6IEkvTy0gTWVtKyBCdXNNYXN0ZXIrIFNwZWNDeWNsZS0g TWVtV0lOVisgVkdBU25vb3AtIFBhckVyci0gU3RlcHBpbmctIFNFUlIrIEZhc3RCMkItIERp c0lOVHgtDQoJU3RhdHVzOiBDYXArIDY2TUh6KyBVREYtIEZhc3RCMkIrIFBhckVyci0gREVW U0VMPW1lZGl1bSA+VEFib3J0LSA8VEFib3J0LSA8TUFib3J0LSA+U0VSUi0gPFBFUlIrIElO VHgtDQoJTGF0ZW5jeTogNjQgKDQwMDBucyBtaW4sIDgwMDBucyBtYXgpLCBDYWNoZSBMaW5l IFNpemU6IDY0IGJ5dGVzDQoJSW50ZXJydXB0OiBwaW4gRCByb3V0ZWQgdG8gSVJRIDIzDQoJ UmVnaW9uIDA6IE1lbW9yeSBhdCBmZWJmZmMwMCAoMzItYml0LCBub24tcHJlZmV0Y2hhYmxl KQ0KCUNhcGFiaWxpdGllczogWzUwXSBQb3dlciBNYW5hZ2VtZW50IHZlcnNpb24gMg0KCQlG bGFnczogUE1FQ2xrLSBEU0ktIEQxLSBEMi0gQXV4Q3VycmVudD0wbUEgUE1FKEQwKyxEMS0s RDItLEQzaG90KyxEM2NvbGQrKQ0KCQlTdGF0dXM6IEQwIFBNRS1FbmFibGUtIERTZWw9MCBE U2NhbGU9MCBQTUUtDQoJQ2FwYWJpbGl0aWVzOiBbNThdIERlYnVnIHBvcnQ6IEJBUj0xIG9m ZnNldD0wMDkwDQoNCjAwOjFkLjAgQXVkaW8gZGV2aWNlOiBBTGkgQ29ycG9yYXRpb24gSGln aCBEZWZpbml0aW9uIEF1ZGlvL0FDJzk3IEhvc3QgQ29udHJvbGxlcg0KCVN1YnN5c3RlbTog QVNVU1RlSyBDb21wdXRlciBJbmMuIERldmljZSA4MWI0DQoJQ29udHJvbDogSS9PLSBNZW0r IEJ1c01hc3RlcisgU3BlY0N5Y2xlLSBNZW1XSU5WLSBWR0FTbm9vcC0gUGFyRXJyLSBTdGVw cGluZy0gU0VSUisgRmFzdEIyQi0gRGlzSU5UeC0NCglTdGF0dXM6IENhcCsgNjZNSHotIFVE Ri0gRmFzdEIyQi0gUGFyRXJyLSBERVZTRUw9bWVkaXVtID5UQWJvcnQtIDxUQWJvcnQtIDxN QWJvcnQtID5TRVJSLSA8UEVSUi0gSU5UeC0NCglMYXRlbmN5OiA2NCAoNDAwMG5zIG1pbiwg MjAwMDBucyBtYXgpDQoJSW50ZXJydXB0OiBwaW4gQyByb3V0ZWQgdG8gSVJRIDIyDQoJUmVn aW9uIDA6IE1lbW9yeSBhdCBmZWJmODAwMCAoNjQtYml0LCBub24tcHJlZmV0Y2hhYmxlKQ0K CUNhcGFiaWxpdGllczogWzUwXSBQb3dlciBNYW5hZ2VtZW50IHZlcnNpb24gMg0KCQlGbGFn czogUE1FQ2xrLSBEU0ktIEQxLSBEMi0gQXV4Q3VycmVudD01NW1BIFBNRShEMCssRDEtLEQy LSxEM2hvdCssRDNjb2xkKykNCgkJU3RhdHVzOiBEMCBQTUUtRW5hYmxlLSBEU2VsPTAgRFNj YWxlPTAgUE1FLQ0KDQowMDoxZS4wIElTQSBicmlkZ2U6IEFMaSBDb3Jwb3JhdGlvbiBQQ0kg dG8gTFBDIENvbnRyb2xsZXIgKHJldiAzMSkNCglTdWJzeXN0ZW06IEFTVVNUZUsgQ29tcHV0 ZXIgSW5jLiBEZXZpY2UgODE1Ng0KCUNvbnRyb2w6IEkvTysgTWVtKyBCdXNNYXN0ZXIrIFNw ZWNDeWNsZSsgTWVtV0lOVi0gVkdBU25vb3AtIFBhckVyci0gU3RlcHBpbmctIFNFUlItIEZh c3RCMkItIERpc0lOVHgtDQoJU3RhdHVzOiBDYXAtIDY2TUh6LSBVREYtIEZhc3RCMkItIFBh ckVyci0gREVWU0VMPW1lZGl1bSA+VEFib3J0LSA8VEFib3J0LSA8TUFib3J0LSA+U0VSUi0g PFBFUlItIElOVHgtDQoJTGF0ZW5jeTogMCAoMjUwbnMgbWluLCA2MDAwbnMgbWF4KQ0KCUlu dGVycnVwdDogcGluID8gcm91dGVkIHRvIElSUSAyNTUNCg0KMDA6MWUuMSBCcmlkZ2U6IEFM aSBDb3Jwb3JhdGlvbiBNNzEwMSBQb3dlciBNYW5hZ2VtZW50IENvbnRyb2xsZXIgW1BNVV0N CglTdWJzeXN0ZW06IEFTVVNUZUsgQ29tcHV0ZXIgSW5jLiBEZXZpY2UgODE1Ng0KCUNvbnRy b2w6IEkvTy0gTWVtLSBCdXNNYXN0ZXItIFNwZWNDeWNsZS0gTWVtV0lOVi0gVkdBU25vb3At IFBhckVyci0gU3RlcHBpbmctIFNFUlItIEZhc3RCMkItIERpc0lOVHgtDQoJU3RhdHVzOiBD YXAtIDY2TUh6LSBVREYtIEZhc3RCMkItIFBhckVyci0gREVWU0VMPW1lZGl1bSA+VEFib3J0 LSA8VEFib3J0LSA8TUFib3J0LSA+U0VSUi0gPFBFUlItIElOVHgtDQoNCjAwOjFmLjAgSURF IGludGVyZmFjZTogQUxpIENvcnBvcmF0aW9uIE01MjI5IElERSAocmV2IGM3KSAocHJvZy1p ZiA4YSBbTWFzdGVyIFNlY1AgUHJpUF0pDQoJU3Vic3lzdGVtOiBBU1VTVGVLIENvbXB1dGVy IEluYy4gRGV2aWNlIDgxNTYNCglDb250cm9sOiBJL08rIE1lbS0gQnVzTWFzdGVyKyBTcGVj Q3ljbGUtIE1lbVdJTlYtIFZHQVNub29wLSBQYXJFcnItIFN0ZXBwaW5nLSBTRVJSLSBGYXN0 QjJCLSBEaXNJTlR4LQ0KCVN0YXR1czogQ2FwKyA2Nk1IeisgVURGLSBGYXN0QjJCKyBQYXJF cnItIERFVlNFTD1tZWRpdW0gPlRBYm9ydC0gPFRBYm9ydC0gPE1BYm9ydC0gPlNFUlItIDxQ RVJSLSBJTlR4LQ0KCUxhdGVuY3k6IDMyDQoJSW50ZXJydXB0OiBwaW4gQSByb3V0ZWQgdG8g SVJRIDI1NQ0KCVJlZ2lvbiA0OiBJL08gcG9ydHMgYXQgZmYwMA0KCUNhcGFiaWxpdGllczog WzYwXSBQb3dlciBNYW5hZ2VtZW50IHZlcnNpb24gMg0KCQlGbGFnczogUE1FQ2xrLSBEU0kt IEQxLSBEMi0gQXV4Q3VycmVudD0wbUEgUE1FKEQwLSxEMS0sRDItLEQzaG90LSxEM2NvbGQt KQ0KCQlTdGF0dXM6IEQwIFBNRS1FbmFibGUtIERTZWw9MCBEU2NhbGU9MCBQTUUtDQoNCjAw OjFmLjEgUkFJRCBidXMgY29udHJvbGxlcjogQUxpIENvcnBvcmF0aW9uIFVMaSA1Mjg3IFNB VEEgKHJldiAwMikNCglTdWJzeXN0ZW06IEFTVVNUZUsgQ29tcHV0ZXIgSW5jLiBEZXZpY2Ug ODE1Ng0KCUNvbnRyb2w6IEkvTysgTWVtKyBCdXNNYXN0ZXIrIFNwZWNDeWNsZS0gTWVtV0lO Vi0gVkdBU25vb3AtIFBhckVyci0gU3RlcHBpbmctIFNFUlIrIEZhc3RCMkItIERpc0lOVHgt DQoJU3RhdHVzOiBDYXArIDY2TUh6KyBVREYtIEZhc3RCMkIrIFBhckVyci0gREVWU0VMPW1l ZGl1bSA+VEFib3J0LSA8VEFib3J0LSA8TUFib3J0LSA+U0VSUi0gPFBFUlItIElOVHgtDQoJ TGF0ZW5jeTogMTI4LCBDYWNoZSBMaW5lIFNpemU6IDUxMiBieXRlcw0KCUludGVycnVwdDog cGluIEEgcm91dGVkIHRvIElSUSAyMQ0KCVJlZ2lvbiAwOiBJL08gcG9ydHMgYXQgZWMwMA0K CVJlZ2lvbiAxOiBJL08gcG9ydHMgYXQgZTg4MA0KCVJlZ2lvbiAyOiBJL08gcG9ydHMgYXQg ZTgwMA0KCVJlZ2lvbiAzOiBJL08gcG9ydHMgYXQgZTQ4MA0KCVJlZ2lvbiA0OiBJL08gcG9y dHMgYXQgZTQwMA0KCVJlZ2lvbiA1OiBNZW1vcnkgYXQgZmViZmY4MDAgKDMyLWJpdCwgbm9u LXByZWZldGNoYWJsZSkNCglDYXBhYmlsaXRpZXM6IFs2MF0gUG93ZXIgTWFuYWdlbWVudCB2 ZXJzaW9uIDINCgkJRmxhZ3M6IFBNRUNsay0gRFNJLSBEMS0gRDItIEF1eEN1cnJlbnQ9MG1B IFBNRShEMC0sRDEtLEQyLSxEM2hvdCssRDNjb2xkLSkNCgkJU3RhdHVzOiBEMCBQTUUtRW5h YmxlLSBEU2VsPTAgRFNjYWxlPTAgUE1FKw0KDQowMTowMC4wIFZHQSBjb21wYXRpYmxlIGNv bnRyb2xsZXI6IEFUSSBUZWNobm9sb2dpZXMgSW5jIFJWMzcwIFtTYXBwaGlyZSBYNTUwIFNp bGVudF0gKHByb2ctaWYgMDAgW1ZHQSBjb250cm9sbGVyXSkNCglTdWJzeXN0ZW06IFBDIFBh cnRuZXIgTGltaXRlZCBEZXZpY2UgMzAwMA0KCUNvbnRyb2w6IEkvTysgTWVtKyBCdXNNYXN0 ZXIrIFNwZWNDeWNsZS0gTWVtV0lOVi0gVkdBU25vb3AtIFBhckVyci0gU3RlcHBpbmctIFNF UlIrIEZhc3RCMkItIERpc0lOVHgtDQoJU3RhdHVzOiBDYXArIDY2TUh6LSBVREYtIEZhc3RC MkItIFBhckVyci0gREVWU0VMPWZhc3QgPlRBYm9ydC0gPFRBYm9ydC0gPE1BYm9ydC0gPlNF UlItIDxQRVJSLSBJTlR4LQ0KCUxhdGVuY3k6IDAsIENhY2hlIExpbmUgU2l6ZTogNjQgYnl0 ZXMNCglJbnRlcnJ1cHQ6IHBpbiBBIHJvdXRlZCB0byBJUlEgMTgNCglSZWdpb24gMDogTWVt b3J5IGF0IGQwMDAwMDAwICgzMi1iaXQsIHByZWZldGNoYWJsZSkNCglSZWdpb24gMTogSS9P IHBvcnRzIGF0IGI4MDANCglSZWdpb24gMjogTWVtb3J5IGF0IGZlNDAwMDAwICgzMi1iaXQs IG5vbi1wcmVmZXRjaGFibGUpDQoJRXhwYW5zaW9uIFJPTSBhdCBmZThlMDAwMCBbZGlzYWJs ZWRdDQoJQ2FwYWJpbGl0aWVzOiBbNTBdIFBvd2VyIE1hbmFnZW1lbnQgdmVyc2lvbiAyDQoJ CUZsYWdzOiBQTUVDbGstIERTSS0gRDErIEQyKyBBdXhDdXJyZW50PTBtQSBQTUUoRDAtLEQx LSxEMi0sRDNob3QtLEQzY29sZC0pDQoJCVN0YXR1czogRDAgUE1FLUVuYWJsZS0gRFNlbD0w IERTY2FsZT0wIFBNRS0NCglDYXBhYmlsaXRpZXM6IFs1OF0gRXhwcmVzcyAodjEpIEVuZHBv aW50LCBNU0kgMDANCgkJRGV2Q2FwOglNYXhQYXlsb2FkIDEyOCBieXRlcywgUGhhbnRGdW5j IDAsIExhdGVuY3kgTDBzIDwxMjhucywgTDEgPDJ1cw0KCQkJRXh0VGFnKyBBdHRuQnRuLSBB dHRuSW5kLSBQd3JJbmQtIFJCRS0gRkxSZXNldC0NCgkJRGV2Q3RsOglSZXBvcnQgZXJyb3Jz OiBDb3JyZWN0YWJsZS0gTm9uLUZhdGFsLSBGYXRhbC0gVW5zdXBwb3J0ZWQtDQoJCQlSbHhk T3JkKyBFeHRUYWctIFBoYW50RnVuYy0gQXV4UHdyLSBOb1Nub29wKw0KCQkJTWF4UGF5bG9h ZCAxMjggYnl0ZXMsIE1heFJlYWRSZXEgMTI4IGJ5dGVzDQoJCURldlN0YToJQ29yckVyci0g VW5jb3JyRXJyLSBGYXRhbEVyci0gVW5zdXBwUmVxLSBBdXhQd3ItIFRyYW5zUGVuZC0NCgkJ TG5rQ2FwOglQb3J0ICMwLCBTcGVlZCAyLjVHVC9zLCBXaWR0aCB4MTYsIEFTUE0gTDBzIEwx LCBMYXRlbmN5IEwwIDwxMjhucywgTDEgPDF1cw0KCQkJQ2xvY2tQTS0gU3VwcmlzZS0gTExB Y3RSZXAtIEJ3Tm90LQ0KCQlMbmtDdGw6CUFTUE0gRGlzYWJsZWQ7IFJDQiA2NCBieXRlcyBE aXNhYmxlZC0gUmV0cmFpbi0gQ29tbUNsay0NCgkJCUV4dFN5bmNoLSBDbG9ja1BNLSBBdXRX aWREaXMtIEJXSW50LSBBdXRCV0ludC0NCgkJTG5rU3RhOglTcGVlZCAyLjVHVC9zLCBXaWR0 aCB4MTYsIFRyRXJyLSBUcmFpbi0gU2xvdENsaysgRExBY3RpdmUtIEJXTWdtdC0gQUJXTWdt dC0NCglDYXBhYmlsaXRpZXM6IFs4MF0gTVNJOiBNYXNrLSA2NGJpdCsgQ291bnQ9MS8xIEVu YWJsZS0NCgkJQWRkcmVzczogMDAwMDAwMDAwMDAwMDAwMCAgRGF0YTogMDAwMA0KDQowMTow MC4xIERpc3BsYXkgY29udHJvbGxlcjogQVRJIFRlY2hub2xvZ2llcyBJbmMgUlYzNzAgc2Vj b25kYXJ5IFtTYXBwaGlyZSBYNTUwIFNpbGVudF0NCglTdWJzeXN0ZW06IFBDIFBhcnRuZXIg TGltaXRlZCBEZXZpY2UgMzAwMQ0KCUNvbnRyb2w6IEkvTysgTWVtKyBCdXNNYXN0ZXIrIFNw ZWNDeWNsZS0gTWVtV0lOVi0gVkdBU25vb3AtIFBhckVyci0gU3RlcHBpbmctIFNFUlItIEZh c3RCMkItIERpc0lOVHgtDQoJU3RhdHVzOiBDYXArIDY2TUh6LSBVREYtIEZhc3RCMkItIFBh ckVyci0gREVWU0VMPWZhc3QgPlRBYm9ydC0gPFRBYm9ydC0gPE1BYm9ydC0gPlNFUlItIDxQ RVJSLSBJTlR4LQ0KCUxhdGVuY3k6IDAsIENhY2hlIExpbmUgU2l6ZTogNjQgYnl0ZXMNCglJ bnRlcnJ1cHQ6IHBpbiA/IHJvdXRlZCB0byBJUlEgMjU1DQoJUmVnaW9uIDA6IE1lbW9yeSBh dCBmZThkMDAwMCAoMzItYml0LCBub24tcHJlZmV0Y2hhYmxlKQ0KCUNhcGFiaWxpdGllczog WzUwXSBQb3dlciBNYW5hZ2VtZW50IHZlcnNpb24gMg0KCQlGbGFnczogUE1FQ2xrLSBEU0kt IEQxKyBEMisgQXV4Q3VycmVudD0wbUEgUE1FKEQwLSxEMS0sRDItLEQzaG90LSxEM2NvbGQt KQ0KCQlTdGF0dXM6IEQwIFBNRS1FbmFibGUtIERTZWw9MCBEU2NhbGU9MCBQTUUtDQoJQ2Fw YWJpbGl0aWVzOiBbNThdIEV4cHJlc3MgKHYxKSBFbmRwb2ludCwgTVNJIDAwDQoJCURldkNh cDoJTWF4UGF5bG9hZCAxMjggYnl0ZXMsIFBoYW50RnVuYyAwLCBMYXRlbmN5IEwwcyA8MTI4 bnMsIEwxIDwydXMNCgkJCUV4dFRhZy0gQXR0bkJ0bi0gQXR0bkluZC0gUHdySW5kLSBSQkUt IEZMUmVzZXQtDQoJCURldkN0bDoJUmVwb3J0IGVycm9yczogQ29ycmVjdGFibGUtIE5vbi1G YXRhbC0gRmF0YWwtIFVuc3VwcG9ydGVkLQ0KCQkJUmx4ZE9yZC0gRXh0VGFnLSBQaGFudEZ1 bmMtIEF1eFB3ci0gTm9Tbm9vcC0NCgkJCU1heFBheWxvYWQgMTI4IGJ5dGVzLCBNYXhSZWFk UmVxIDEyOCBieXRlcw0KCQlEZXZTdGE6CUNvcnJFcnItIFVuY29yckVyci0gRmF0YWxFcnIt IFVuc3VwcFJlcS0gQXV4UHdyLSBUcmFuc1BlbmQtDQoJCUxua0NhcDoJUG9ydCAjMCwgU3Bl ZWQgMi41R1QvcywgV2lkdGggeDE2LCBBU1BNIEwwcyBMMSwgTGF0ZW5jeSBMMCA8MTI4bnMs IEwxIDwxdXMNCgkJCUNsb2NrUE0tIFN1cHJpc2UtIExMQWN0UmVwLSBCd05vdC0NCgkJTG5r Q3RsOglBU1BNIERpc2FibGVkOyBSQ0IgNjQgYnl0ZXMgRGlzYWJsZWQtIFJldHJhaW4tIENv bW1DbGstDQoJCQlFeHRTeW5jaC0gQ2xvY2tQTS0gQXV0V2lkRGlzLSBCV0ludC0gQXV0QldJ bnQtDQoJCUxua1N0YToJU3BlZWQgMi41R1QvcywgV2lkdGggeDE2LCBUckVyci0gVHJhaW4t IFNsb3RDbGsrIERMQWN0aXZlLSBCV01nbXQtIEFCV01nbXQtDQoNCjAyOjAwLjAgRXRoZXJu ZXQgY29udHJvbGxlcjogTWFydmVsbCBUZWNobm9sb2d5IEdyb3VwIEx0ZC4gODhFODA1MyBQ Q0ktRSBHaWdhYml0IEV0aGVybmV0IENvbnRyb2xsZXIgKHJldiAxOSkNCglTdWJzeXN0ZW06 IEFTVVNUZUsgQ29tcHV0ZXIgSW5jLiBNYXJ2ZWxsIDg4RTgwNTMgR2lnYWJpdCBFdGhlcm5l dCBjb250cm9sbGVyIFBDSWUgKEFzdXMpDQoJQ29udHJvbDogSS9PKyBNZW0rIEJ1c01hc3Rl cisgU3BlY0N5Y2xlLSBNZW1XSU5WLSBWR0FTbm9vcC0gUGFyRXJyLSBTdGVwcGluZy0gU0VS UisgRmFzdEIyQi0gRGlzSU5UeC0NCglTdGF0dXM6IENhcCsgNjZNSHotIFVERi0gRmFzdEIy Qi0gUGFyRXJyLSBERVZTRUw9ZmFzdCA+VEFib3J0LSA8VEFib3J0LSA8TUFib3J0LSA+U0VS Ui0gPFBFUlItIElOVHgtDQoJTGF0ZW5jeTogMCwgQ2FjaGUgTGluZSBTaXplOiA2NCBieXRl cw0KCUludGVycnVwdDogcGluIEEgcm91dGVkIHRvIElSUSAxOA0KCVJlZ2lvbiAwOiBNZW1v cnkgYXQgZmU5ZmMwMDAgKDY0LWJpdCwgbm9uLXByZWZldGNoYWJsZSkNCglSZWdpb24gMjog SS9PIHBvcnRzIGF0IGM4MDANCglFeHBhbnNpb24gUk9NIGF0IGZlOWMwMDAwIFtkaXNhYmxl ZF0NCglDYXBhYmlsaXRpZXM6IFs0OF0gUG93ZXIgTWFuYWdlbWVudCB2ZXJzaW9uIDINCgkJ RmxhZ3M6IFBNRUNsay0gRFNJLSBEMSsgRDIrIEF1eEN1cnJlbnQ9MG1BIFBNRShEMCssRDEr LEQyKyxEM2hvdCssRDNjb2xkKykNCgkJU3RhdHVzOiBEMCBQTUUtRW5hYmxlLSBEU2VsPTAg RFNjYWxlPTEgUE1FLQ0KCUNhcGFiaWxpdGllczogWzUwXSBWaXRhbCBQcm9kdWN0IERhdGEg PD8+DQoJQ2FwYWJpbGl0aWVzOiBbNWNdIE1TSTogTWFzay0gNjRiaXQrIENvdW50PTIvMiBF bmFibGUrDQoJCUFkZHJlc3M6IDAwMDAwMDAwZmVlMDAwMDAgIERhdGE6IDAwMzINCglDYXBh YmlsaXRpZXM6IFtlMF0gRXhwcmVzcyAodjEpIExlZ2FjeSBFbmRwb2ludCwgTVNJIDAwDQoJ CURldkNhcDoJTWF4UGF5bG9hZCAxMjggYnl0ZXMsIFBoYW50RnVuYyAwLCBMYXRlbmN5IEww cyB1bmxpbWl0ZWQsIEwxIHVubGltaXRlZA0KCQkJRXh0VGFnLSBBdHRuQnRuLSBBdHRuSW5k LSBQd3JJbmQtIFJCRS0gRkxSZXNldC0NCgkJRGV2Q3RsOglSZXBvcnQgZXJyb3JzOiBDb3Jy ZWN0YWJsZS0gTm9uLUZhdGFsLSBGYXRhbC0gVW5zdXBwb3J0ZWQtDQoJCQlSbHhkT3JkLSBF eHRUYWctIFBoYW50RnVuYy0gQXV4UHdyLSBOb1Nub29wLQ0KCQkJTWF4UGF5bG9hZCAxMjgg Ynl0ZXMsIE1heFJlYWRSZXEgNDA5NiBieXRlcw0KCQlEZXZTdGE6CUNvcnJFcnIrIFVuY29y ckVycisgRmF0YWxFcnItIFVuc3VwcFJlcSsgQXV4UHdyKyBUcmFuc1BlbmQtDQoJCUxua0Nh cDoJUG9ydCAjMywgU3BlZWQgMi41R1QvcywgV2lkdGggeDEsIEFTUE0gTDBzLCBMYXRlbmN5 IEwwIDwyNTZucywgTDEgdW5saW1pdGVkDQoJCQlDbG9ja1BNLSBTdXByaXNlLSBMTEFjdFJl cC0gQndOb3QtDQoJCUxua0N0bDoJQVNQTSBEaXNhYmxlZDsgUkNCIDEyOCBieXRlcyBEaXNh YmxlZC0gUmV0cmFpbi0gQ29tbUNsay0NCgkJCUV4dFN5bmNoLSBDbG9ja1BNLSBBdXRXaWRE aXMtIEJXSW50LSBBdXRCV0ludC0NCgkJTG5rU3RhOglTcGVlZCAyLjVHVC9zLCBXaWR0aCB4 MSwgVHJFcnItIFRyYWluLSBTbG90Q2xrKyBETEFjdGl2ZS0gQldNZ210LSBBQldNZ210LQ0K DQowNDoxMi4wIEZpcmVXaXJlIChJRUVFIDEzOTQpOiBWSUEgVGVjaG5vbG9naWVzLCBJbmMu IFZUNjMwNiBGaXJlIElJIElFRUUgMTM5NCBPSENJIExpbmsgTGF5ZXIgQ29udHJvbGxlciAo cmV2IDgwKSAocHJvZy1pZiAxMCBbT0hDSV0pDQoJU3Vic3lzdGVtOiBBU1VTVGVLIENvbXB1 dGVyIEluYy4gQThWL0E4Ti9QNFA4MDAgc2VyaWVzIG1vdGhlcmJvYXJkDQoJQ29udHJvbDog SS9PKyBNZW0rIEJ1c01hc3RlcisgU3BlY0N5Y2xlLSBNZW1XSU5WKyBWR0FTbm9vcC0gUGFy RXJyLSBTdGVwcGluZy0gU0VSUisgRmFzdEIyQi0gRGlzSU5UeC0NCglTdGF0dXM6IENhcCsg NjZNSHotIFVERi0gRmFzdEIyQi0gUGFyRXJyLSBERVZTRUw9bWVkaXVtID5UQWJvcnQtIDxU QWJvcnQtIDxNQWJvcnQtID5TRVJSLSA8UEVSUi0gSU5UeC0NCglMYXRlbmN5OiA2NCAoODAw MG5zIG1heCksIENhY2hlIExpbmUgU2l6ZTogNjQgYnl0ZXMNCglJbnRlcnJ1cHQ6IHBpbiBB IHJvdXRlZCB0byBJUlEgMTYNCglSZWdpb24gMDogTWVtb3J5IGF0IGZlYWZlODAwICgzMi1i aXQsIG5vbi1wcmVmZXRjaGFibGUpDQoJUmVnaW9uIDE6IEkvTyBwb3J0cyBhdCBkYzAwDQoJ Q2FwYWJpbGl0aWVzOiBbNTBdIFBvd2VyIE1hbmFnZW1lbnQgdmVyc2lvbiAyDQoJCUZsYWdz OiBQTUVDbGstIERTSS0gRDEtIEQyKyBBdXhDdXJyZW50PTBtQSBQTUUoRDAtLEQxLSxEMiss RDNob3QrLEQzY29sZCspDQoJCVN0YXR1czogRDAgUE1FLUVuYWJsZS0gRFNlbD0wIERTY2Fs ZT0wIFBNRS0NCg0KYW5nbGVwb2lzZSMgcGNpY29uZiAtbA0NCmhvc3RiMEBwY2kwOjA6MDow OgljbGFzcz0weDA2MDAwMCBjYXJkPTB4ODE4NTEwNDMgY2hpcD0weDU5NTAxMDAyIHJldj0w eDEwIGhkcj0weDAwDQpwY2liMUBwY2kwOjA6MjowOgljbGFzcz0weDA2MDQwMCBjYXJkPTB4 NTk1MDEwMDIgY2hpcD0weDVhMzQxMDAyIHJldj0weDAwIGhkcj0weDAxDQpwY2liMkBwY2kw OjA6NjowOgljbGFzcz0weDA2MDQwMCBjYXJkPTB4NTk1MDEwMDIgY2hpcD0weDVhMzgxMDAy IHJldj0weDAwIGhkcj0weDAxDQpwY2liM0BwY2kwOjA6NzowOgljbGFzcz0weDA2MDQwMCBj YXJkPTB4NTk1MDEwMDIgY2hpcD0weDVhMzkxMDAyIHJldj0weDAwIGhkcj0weDAxDQpob3N0 YjFAcGNpMDowOjI0OjA6CWNsYXNzPTB4MDYwMDAwIGNhcmQ9MHgwMDAwMDAwMCBjaGlwPTB4 MTEwMDEwMjIgcmV2PTB4MDAgaGRyPTB4MDANCmhvc3RiMkBwY2kwOjA6MjQ6MToJY2xhc3M9 MHgwNjAwMDAgY2FyZD0weDAwMDAwMDAwIGNoaXA9MHgxMTAxMTAyMiByZXY9MHgwMCBoZHI9 MHgwMA0KaG9zdGIzQHBjaTA6MDoyNDoyOgljbGFzcz0weDA2MDAwMCBjYXJkPTB4MDAwMDAw MDAgY2hpcD0weDExMDIxMDIyIHJldj0weDAwIGhkcj0weDAwDQpob3N0YjRAcGNpMDowOjI0 OjM6CWNsYXNzPTB4MDYwMDAwIGNhcmQ9MHgwMDAwMDAwMCBjaGlwPTB4MTEwMzEwMjIgcmV2 PTB4MDAgaGRyPTB4MDANCnBjaWI0QHBjaTA6MDoyNTowOgljbGFzcz0weDA2MDQwMCBjYXJk PTB4MDAwMDAwMDAgY2hpcD0weDUyNDkxMGI5IHJldj0weDAwIGhkcj0weDAxDQpvaGNpMEBw Y2kwOjA6Mjg6MDoJY2xhc3M9MHgwYzAzMTAgY2FyZD0weDgxNTYxMDQzIGNoaXA9MHg1MjM3 MTBiOSByZXY9MHgwMyBoZHI9MHgwMA0Kb2hjaTFAcGNpMDowOjI4OjE6CWNsYXNzPTB4MGMw MzEwIGNhcmQ9MHg4MTU2MTA0MyBjaGlwPTB4NTIzNzEwYjkgcmV2PTB4MDMgaGRyPTB4MDAN Cm9oY2kyQHBjaTA6MDoyODoyOgljbGFzcz0weDBjMDMxMCBjYXJkPTB4ODE1NjEwNDMgY2hp cD0weDUyMzcxMGI5IHJldj0weDAzIGhkcj0weDAwDQplaGNpMEBwY2kwOjA6Mjg6MzoJY2xh c3M9MHgwYzAzMjAgY2FyZD0weDgxNTYxMDQzIGNoaXA9MHg1MjM5MTBiOSByZXY9MHgwMSBo ZHI9MHgwMA0KaGRhYzBAcGNpMDowOjI5OjA6CWNsYXNzPTB4MDQwMzAwIGNhcmQ9MHg4MWI0 MTA0MyBjaGlwPTB4NTQ2MTEwYjkgcmV2PTB4MDAgaGRyPTB4MDANCmlzYWIwQHBjaTA6MDoz MDowOgljbGFzcz0weDA2MDEwMCBjYXJkPTB4ODE1NjEwNDMgY2hpcD0weDE1NzMxMGI5IHJl dj0weDMxIGhkcj0weDAwDQpub25lMEBwY2kwOjA6MzA6MToJY2xhc3M9MHgwNjgwMDAgY2Fy ZD0weDgxNTYxMDQzIGNoaXA9MHg3MTAxMTBiOSByZXY9MHgwMCBoZHI9MHgwMA0KYXRhcGNp MEBwY2kwOjA6MzE6MDoJY2xhc3M9MHgwMTAxOGEgY2FyZD0weDgxNTYxMDQzIGNoaXA9MHg1 MjI5MTBiOSByZXY9MHhjNyBoZHI9MHgwMA0KYXRhcGNpMUBwY2kwOjA6MzE6MToJY2xhc3M9 MHgwMTA0MDAgY2FyZD0weDgxNTYxMDQzIGNoaXA9MHg1Mjg3MTBiOSByZXY9MHgwMiBoZHI9 MHgwMA0KdmdhcGNpMEBwY2kwOjE6MDowOgljbGFzcz0weDAzMDAwMCBjYXJkPTB4MzAwMDE3 NGIgY2hpcD0weDViNjMxMDAyIHJldj0weDAwIGhkcj0weDAwDQp2Z2FwY2kxQHBjaTA6MTow OjE6CWNsYXNzPTB4MDM4MDAwIGNhcmQ9MHgzMDAxMTc0YiBjaGlwPTB4NWI3MzEwMDIgcmV2 PTB4MDAgaGRyPTB4MDANCm1za2MwQHBjaTA6MjowOjA6CWNsYXNzPTB4MDIwMDAwIGNhcmQ9 MHg4MTQyMTA0MyBjaGlwPTB4NDM2MjExYWIgcmV2PTB4MTkgaGRyPTB4MDANCm5vbmUxQHBj aTA6NDoxODowOgljbGFzcz0weDBjMDAxMCBjYXJkPTB4ODA4YTEwNDMgY2hpcD0weDMwNDQx MTA2IHJldj0weDgwIGhkcj0weDAwDQphbmdsZXBvaXNlIyBsc3BjaSAtaA0NCmxzcGNpOiBp bGxlZ2FsIG9wdGlvbiAtLSBoDQpVc2FnZTogbHNwY2kgWzxzd2l0Y2hlcz5dDQoNCkJhc2lj IGRpc3BsYXkgbW9kZXM6DQotbW0JCVByb2R1Y2UgbWFjaGluZS1yZWFkYWJsZSBvdXRwdXQg KHNpbmdsZSAtbSBmb3IgYW4gb2Jzb2xldGUgZm9ybWF0KQ0KLXQJCVNob3cgYnVzIHRyZWUN Cg0KRGlzcGxheSBvcHRpb25zOg0KLXYJCUJlIHZlcmJvc2UgKC12diBmb3IgdmVyeSB2ZXJi b3NlKQ0KLXgJCVNob3cgaGV4LWR1bXAgb2YgdGhlIHN0YW5kYXJkIHBhcnQgb2YgdGhlIGNv bmZpZyBzcGFjZQ0KLXh4eAkJU2hvdyBoZXgtZHVtcCBvZiB0aGUgd2hvbGUgY29uZmlnIHNw YWNlIChkYW5nZXJvdXM7IHJvb3Qgb25seSkNCi14eHh4CQlTaG93IGhleC1kdW1wIG9mIHRo ZSA0MDk2LWJ5dGUgZXh0ZW5kZWQgY29uZmlnIHNwYWNlIChyb290IG9ubHkpDQotYgkJQnVz LWNlbnRyaWMgdmlldyAoYWRkcmVzc2VzIGFuZCBJUlEncyBhcyBzZWVuIGJ5IHRoZSBidXMp DQotRAkJQWx3YXlzIHNob3cgZG9tYWluIG51bWJlcnMNCg0KUmVzb2x2aW5nIG9mIGRldmlj ZSBJRCdzIHRvIG5hbWVzOg0KLW4JCVNob3cgbnVtZXJpYyBJRCdzDQotbm4JCVNob3cgYm90 aCB0ZXh0dWFsIGFuZCBudW1lcmljIElEJ3MgKG5hbWVzICYgbnVtYmVycykNCi1xCQlRdWVy eSB0aGUgUENJIElEIGRhdGFiYXNlIGZvciB1bmtub3duIElEJ3MgdmlhIEROUw0KLXFxCQlB cyBhYm92ZSwgYnV0IHJlLXF1ZXJ5IGxvY2FsbHkgY2FjaGVkIGVudHJpZXMNCi1RCQlRdWVy eSB0aGUgUENJIElEIGRhdGFiYXNlIGZvciBhbGwgSUQncyB2aWEgRE5TDQoNClNlbGVjdGlv biBvZiBkZXZpY2VzOg0KLXMgW1tbWzxkb21haW4+XTpdPGJ1cz5dOl1bPHNsb3Q+XVsuWzxm dW5jPl1dCVNob3cgb25seSBkZXZpY2VzIGluIHNlbGVjdGVkIHNsb3RzDQotZCBbPHZlbmRv cj5dOls8ZGV2aWNlPl0JCQlTaG93IG9ubHkgZGV2aWNlcyB3aXRoIHNwZWNpZmllZCBJRCdz DQoNCk90aGVyIG9wdGlvbnM6DQotaSA8ZmlsZT4JVXNlIHNwZWNpZmllZCBJRCBkYXRhYmFz ZSBpbnN0ZWFkIG9mIC91c3IvbG9jYWwvc2hhcmUvcGNpdXRpbHMvcGNpLmlkcy5neg0KLU0J CUVuYWJsZSBgYnVzIG1hcHBpbmcnIG1vZGUgKGRhbmdlcm91czsgcm9vdCBvbmx5KQ0KDQpQ Q0kgYWNjZXNzIG9wdGlvbnM6DQotQSA8bWV0aG9kPglVc2UgdGhlIHNwZWNpZmllZCBQQ0kg YWNjZXNzIG1ldGhvZCAoc2VlIGAtQSBoZWxwJyBmb3IgYSBsaXN0KQ0KLU8gPHBhcj49PHZh bD4JU2V0IFBDSSBhY2Nlc3MgcGFyYW1ldGVyIChzZWUgYC1PIGhlbHAnIGZvciBhIGxpc3Qp DQotRwkJRW5hYmxlIFBDSSBhY2Nlc3MgZGVidWdnaW5nDQotRiA8ZmlsZT4JUmVhZCBQQ0kg Y29uZmlndXJhdGlvbiBkdW1wIGZyb20gYSBnaXZlbiBmaWxlDQphbmdsZXBvaXNlIyBsc3Bj aSAtCBtbSy1zIDA6MWMuMg0NCjAwOjFjLjIgVVNCIENvbnRyb2xsZXI6IEFMaSBDb3Jwb3Jh dGlvbiBVU0IgMS4xIENvbnRyb2xsZXIgKHJldiAwMykNCmFuZ2xlcG9pc2UjIGxzcGNpIC1z IDA6MWMuMiAtdg0NCjAwOjFjLjIgVVNCIENvbnRyb2xsZXI6IEFMaSBDb3Jwb3JhdGlvbiBV U0IgMS4xIENvbnRyb2xsZXIgKHJldiAwMykgKHByb2ctaWYgMTAgW09IQ0ldKQ0KCVN1YnN5 c3RlbTogQVNVU1RlSyBDb21wdXRlciBJbmMuIERldmljZSA4MTU2DQoJRmxhZ3M6IGJ1cyBt YXN0ZXIsIDY2TUh6LCBtZWRpdW0gZGV2c2VsLCBsYXRlbmN5IDY0LCBJUlEgMTkNCglNZW1v cnkgYXQgZmViZmUwMDAgKDMyLWJpdCwgbm9uLXByZWZldGNoYWJsZSkNCg0KYW5nbGVwb2lz ZSMgbHNwY2kgLXMgMDoxYy4yIC12CAgICCAtdhtbSwgICDEgLXYICAgNDQowMDoxYy4xIFVT QiBDb250cm9sbGVyOiBBTGkgQ29ycG9yYXRpb24gVVNCIDEuMSBDb250cm9sbGVyIChyZXYg MDMpIChwcm9nLWlmIDEwIFtPSENJXSkNCglTdWJzeXN0ZW06IEFTVVNUZUsgQ29tcHV0ZXIg SW5jLiBEZXZpY2UgODE1Ng0KCUZsYWdzOiBidXMgbWFzdGVyLCA2Nk1IeiwgbWVkaXVtIGRl dnNlbCwgbGF0ZW5jeSA2NCwgSVJRIDE4DQoJTWVtb3J5IGF0IGZlYmZkMDAwICgzMi1iaXQs IG5vbi1wcmVmZXRjaGFibGUpDQoNCmFuZ2xlcG9pc2UjIGVjaG8gJ3RoaXMgaXMgdGhlIGFm ZmVjdGVkIGNvbnRyb2xsZXInDQ0KdGhpcyBpcyB0aGUgYWZmZWN0ZWQgY29udHJvbGxlcg0K YW5nbGVwb2lzZSMgZWNobyAndGhpcyBpcyB0aGUgYWZmZWN0ZWQgY29udHJvbGxlcicbWzEz YGxzcGNpIC1zIDA6MWMuMSAtdhtbSwgICAgICAgICAgICAggLXMgMDoJYy4xIC12DQ0KG1tL YW5nbGVwb2lzZSMgcGNpY29uZiAtaA0NCnVzYWdlOiBwY2ljb25mIC1sIFstY3ZdDQogICAg ICAgcGNpY29uZiAtYSBzZWxlY3Rvcg0KICAgICAgIHBjaWNvbmYgLXIgWy1iIHwgLWhdIHNl bGVjdG9yIGFkZHJbOmFkZHIyXQ0KICAgICAgIHBjaWNvbmYgLXcgWy1iIHwgLWhdIHNlbGVj dG9yIGFkZHIgdmFsdWUNCmFuZ2xlcG9pc2UjIHBjaWNvbmYgLWgIG1tLYSAwOjEIG1tLMjg6 MQ0NCnBjaWNvbmY6IGNhbm5vdCBwYXJzZSBzZWxlY3RvciAwOjI4OjENCmFuZ2xlcG9pc2Uj IHBjaWNvbmYgLWEgMDoyODoxCBtbSwgbW0suMQ0NCnBjaWNvbmY6IGNhbm5vdCBwYXJzZSBz ZWxlY3RvciAwOjI4LjENCmFuZ2xlcG9pc2UjIHBjaWNvbmYgLWEgMDoyOC4xCBtbSwgbW0sI G1tLCBtbSwgbW0sIG1tLcGNpMDowMAgbW0s6MWM6MQ0NCnBjaWNvbmY6IGNhbm5vdCBwYXJz ZSBzZWxlY3RvciBwY2kwOjA6MWM6MQ0KYW5nbGVwb2lzZSMgcGNpY29uZiAtYSBwY2kwOjA6 MWM6MQgIMRtbSwguMQgNDQpwY2ljb25mOiBjYW5ub3QgcGFyc2Ugc2VsZWN0b3IgcGNpMDow OjFjLjENCmFuZ2xlcG9pc2UjIHBjaWNvbmYgLWwNDQpob3N0YjBAcGNpMDowOjA6MDoJY2xh c3M9MHgwNjAwMDAgY2FyZD0weDgxODUxMDQzIGNoaXA9MHg1OTUwMTAwMiByZXY9MHgxMCBo ZHI9MHgwMA0KcGNpYjFAcGNpMDowOjI6MDoJY2xhc3M9MHgwNjA0MDAgY2FyZD0weDU5NTAx MDAyIGNoaXA9MHg1YTM0MTAwMiByZXY9MHgwMCBoZHI9MHgwMQ0KcGNpYjJAcGNpMDowOjY6 MDoJY2xhc3M9MHgwNjA0MDAgY2FyZD0weDU5NTAxMDAyIGNoaXA9MHg1YTM4MTAwMiByZXY9 MHgwMCBoZHI9MHgwMQ0KcGNpYjNAcGNpMDowOjc6MDoJY2xhc3M9MHgwNjA0MDAgY2FyZD0w eDU5NTAxMDAyIGNoaXA9MHg1YTM5MTAwMiByZXY9MHgwMCBoZHI9MHgwMQ0KaG9zdGIxQHBj aTA6MDoyNDowOgljbGFzcz0weDA2MDAwMCBjYXJkPTB4MDAwMDAwMDAgY2hpcD0weDExMDAx MDIyIHJldj0weDAwIGhkcj0weDAwDQpob3N0YjJAcGNpMDowOjI0OjE6CWNsYXNzPTB4MDYw MDAwIGNhcmQ9MHgwMDAwMDAwMCBjaGlwPTB4MTEwMTEwMjIgcmV2PTB4MDAgaGRyPTB4MDAN Cmhvc3RiM0BwY2kwOjA6MjQ6MjoJY2xhc3M9MHgwNjAwMDAgY2FyZD0weDAwMDAwMDAwIGNo aXA9MHgxMTAyMTAyMiByZXY9MHgwMCBoZHI9MHgwMA0KaG9zdGI0QHBjaTA6MDoyNDozOglj bGFzcz0weDA2MDAwMCBjYXJkPTB4MDAwMDAwMDAgY2hpcD0weDExMDMxMDIyIHJldj0weDAw IGhkcj0weDAwDQpwY2liNEBwY2kwOjA6MjU6MDoJY2xhc3M9MHgwNjA0MDAgY2FyZD0weDAw MDAwMDAwIGNoaXA9MHg1MjQ5MTBiOSByZXY9MHgwMCBoZHI9MHgwMQ0Kb2hjaTBAcGNpMDow OjI4OjA6CWNsYXNzPTB4MGMwMzEwIGNhcmQ9MHg4MTU2MTA0MyBjaGlwPTB4NTIzNzEwYjkg cmV2PTB4MDMgaGRyPTB4MDANCm9oY2kxQHBjaTA6MDoyODoxOgljbGFzcz0weDBjMDMxMCBj YXJkPTB4ODE1NjEwNDMgY2hpcD0weDUyMzcxMGI5IHJldj0weDAzIGhkcj0weDAwDQpvaGNp MkBwY2kwOjA6Mjg6MjoJY2xhc3M9MHgwYzAzMTAgY2FyZD0weDgxNTYxMDQzIGNoaXA9MHg1 MjM3MTBiOSByZXY9MHgwMyBoZHI9MHgwMA0KZWhjaTBAcGNpMDowOjI4OjM6CWNsYXNzPTB4 MGMwMzIwIGNhcmQ9MHg4MTU2MTA0MyBjaGlwPTB4NTIzOTEwYjkgcmV2PTB4MDEgaGRyPTB4 MDANCmhkYWMwQHBjaTA6MDoyOTowOgljbGFzcz0weDA0MDMwMCBjYXJkPTB4ODFiNDEwNDMg Y2hpcD0weDU0NjExMGI5IHJldj0weDAwIGhkcj0weDAwDQppc2FiMEBwY2kwOjA6MzA6MDoJ Y2xhc3M9MHgwNjAxMDAgY2FyZD0weDgxNTYxMDQzIGNoaXA9MHgxNTczMTBiOSByZXY9MHgz MSBoZHI9MHgwMA0Kbm9uZTBAcGNpMDowOjMwOjE6CWNsYXNzPTB4MDY4MDAwIGNhcmQ9MHg4 MTU2MTA0MyBjaGlwPTB4NzEwMTEwYjkgcmV2PTB4MDAgaGRyPTB4MDANCmF0YXBjaTBAcGNp MDowOjMxOjA6CWNsYXNzPTB4MDEwMThhIGNhcmQ9MHg4MTU2MTA0MyBjaGlwPTB4NTIyOTEw YjkgcmV2PTB4YzcgaGRyPTB4MDANCmF0YXBjaTFAcGNpMDowOjMxOjE6CWNsYXNzPTB4MDEw NDAwIGNhcmQ9MHg4MTU2MTA0MyBjaGlwPTB4NTI4NzEwYjkgcmV2PTB4MDIgaGRyPTB4MDAN CnZnYXBjaTBAcGNpMDoxOjA6MDoJY2xhc3M9MHgwMzAwMDAgY2FyZD0weDMwMDAxNzRiIGNo aXA9MHg1YjYzMTAwMiByZXY9MHgwMCBoZHI9MHgwMA0KdmdhcGNpMUBwY2kwOjE6MDoxOglj bGFzcz0weDAzODAwMCBjYXJkPTB4MzAwMTE3NGIgY2hpcD0weDViNzMxMDAyIHJldj0weDAw IGhkcj0weDAwDQptc2tjMEBwY2kwOjI6MDowOgljbGFzcz0weDAyMDAwMCBjYXJkPTB4ODE0 MjEwNDMgY2hpcD0weDQzNjIxMWFiIHJldj0weDE5IGhkcj0weDAwDQpub25lMUBwY2kwOjQ6 MTg6MDoJY2xhc3M9MHgwYzAwMTAgY2FyZD0weDgwOGExMDQzIGNoaXA9MHgzMDQ0MTEwNiBy ZXY9MHg4MCBoZHI9MHgwMA0KYW5nbGVwb2lzZSMgcGNpY29uZiBwY2kwOjA6Mjg6MQgICAgI CAgICAgIG1tALRtbQGEbW0AgDQ0KcGNpY29uZjogaW9jdGwoUENJT0NBVFRBQ0hFRCk6IElu YXBwcm9wcmlhdGUgaW9jdGwgZm9yIGRldmljZQ0KYW5nbGVwb2lzZSMgcGNpY29uZiAtYSBw Y2kwOjA6Mjg6MQgICAgICAgICAgIG1tAbxtbQGgbW0BjG1tAaRtbQDEbW0AiCBtbUBtbQEAN DQpwY2ljb25mOiBpb2N0bChQQ0lPQ0FUVEFDSEVEKTogSW5hcHByb3ByaWF0ZSBpb2N0bCBm b3IgZGV2aWNlDQphbmdsZXBvaXNlIyBwY2ljb25mIC1hIG9oY2kxQHBjaTA6MDoyODoxCBtb SzANDQpwY2ljb25mOiBpb2N0bChQQ0lPQ0FUVEFDSEVEKTogSW5hcHByb3ByaWF0ZSBpb2N0 bCBmb3IgZGV2aWNlDQphbmdsZXBvaXNlIyBwY2ljb25mIC1hIG9oY2kxQHBjaTA6MDoyODow CBtbSzENDQpwY2ljb25mOiBpb2N0bChQQ0lPQ0FUVEFDSEVEKTogSW5hcHByb3ByaWF0ZSBp b2N0bCBmb3IgZGV2aWNlDQphbmdsZXBvaXNlIyBwY2ljb25mIC1hIG9oY2kxQHBjaTA6MDoy ODoxCAgICAgICAgICAgICAgICAgICBtbUBtbQGwNDQp1c2FnZTogcGNpY29uZiAtbCBbLWN2 XQ0KICAgICAgIHBjaWNvbmYgLWEgc2VsZWN0b3INCiAgICAgICBwY2ljb25mIC1yIFstYiB8 IC1oXSBzZWxlY3RvciBhZGRyWzphZGRyMl0NCiAgICAgICBwY2ljb25mIC13IFstYiB8IC1o XSBzZWxlY3RvciBhZGRyIHZhbHVlDQphbmdsZXBvaXNlIyBwY2ljb25mIC1sIG9oY2kxQHBj aTA6MDoyODoxCAgICAgICAgICAgICAgICAgICBtbUBtbQHIgG1tAIAgbW0AtG1tAYhtbNDRg IDA6MAgbW0sxDQ0KYjkgMTAgDQphbmdsZXBvaXNlIyB1c2JkZXZzIHYIG1tLLXYNDQpDb250 cm9sbGVyIC9kZXYvdXNiMDoNCmFkZHIgMTogZnVsbCBzcGVlZCwgc2VsZiBwb3dlcmVkLCBj b25maWcgMSwgT0hDSSByb290IGh1YigweDAwMDApLCBBY2VyTGFicygweDAwMDApLCByZXYg MS4wMA0KIHBvcnQgMSBhZGRyIDI6IGZ1bGwgc3BlZWQsIHNlbGYgcG93ZXJlZCwgY29uZmln IDEsIHByb2R1Y3QgMHgyMDQ2KDB4MjA0NiksIHZlbmRvciAweDA0NTEoMHgwNDUxKSwgcmV2 IDEuMjUNCiAgcG9ydCAxIHBvd2VyZWQNCiAgcG9ydCAyIHBvd2VyZWQNCiAgcG9ydCAzIHBv d2VyZWQNCiAgcG9ydCA0IHBvd2VyZWQNCiBwb3J0IDIgcG93ZXJlZA0KIHBvcnQgMyBwb3dl cmVkDQpDb250cm9sbGVyIC9kZXYvdXNiMToNCmFkZHIgMTogZnVsbCBzcGVlZCwgc2VsZiBw b3dlcmVkLCBjb25maWcgMSwgT0hDSSByb290IGh1YigweDAwMDApLCBBY2VyTGFicygweDAw MDApLCByZXYgMS4wMA0KIHBvcnQgMSBwb3dlcmVkDQogcG9ydCAyIHBvd2VyZWQNCiBwb3J0 IDMgcG93ZXJlZA0KQ29udHJvbGxlciAvZGV2L3VzYjI6DQphZGRyIDE6IGZ1bGwgc3BlZWQs IHNlbGYgcG93ZXJlZCwgY29uZmlnIDEsIE9IQ0kgcm9vdCBodWIoMHgwMDAwKSwgQWNlckxh YnMoMHgwMDAwKSwgcmV2IDEuMDANCiBwb3J0IDEgcG93ZXJlZA0KIHBvcnQgMiBwb3dlcmVk DQogcG9ydCAzIHBvd2VyZWQNCkNvbnRyb2xsZXIgL2Rldi91c2IzOg0KYWRkciAxOiBoaWdo IHNwZWVkLCBzZWxmIHBvd2VyZWQsIGNvbmZpZyAxLCBFSENJIHJvb3QgaHViKDB4MDAwMCks IEFjZXJMYWJzKDB4MDAwMCksIHJldiAxLjAwDQogcG9ydCAxIHBvd2VyZWQNCiBwb3J0IDIg cG93ZXJlZA0KIHBvcnQgMyBwb3dlcmVkDQogcG9ydCA0IHBvd2VyZWQNCiBwb3J0IDUgYWRk ciAyOiBoaWdoIHNwZWVkLCBzZWxmIHBvd2VyZWQsIGNvbmZpZyAxLCBVU0IyLjAgSHViKDB4 MDYwNiksIHZlbmRvciAweDA1ZTMoMHgwNWUzKSwgcmV2IDcuMDINCiAgcG9ydCAxIHBvd2Vy ZWQNCiAgcG9ydCAyIHBvd2VyZWQNCiAgcG9ydCAzIHBvd2VyZWQNCiAgcG9ydCA0IHBvd2Vy ZWQNCiBwb3J0IDYgcG93ZXJlZA0KIHBvcnQgNyBwb3dlcmVkDQogcG9ydCA4IHBvd2VyZWQN CmFuZ2xlcG9pc2UjIA0NCmFuZ2xlcG9pc2UjIGVjaG8gJ2FsbCBvaycNDQphbGwgb2sNCmFu Z2xlcG9pc2UjIF5ECAhleGl0DQoKU2NyaXB0IGRvbmUgb24gRnJpIEZlYiAxMyAwNDozMzox NSAyMDA5Cg== --------------030503010103000806030906-- From owner-freebsd-stable@FreeBSD.ORG Fri Feb 13 04:43:03 2009 Return-Path: Delivered-To: FreeBSD-stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 966C6106566C for ; Fri, 13 Feb 2009 04:43:03 +0000 (UTC) (envelope-from ota@j.email.ne.jp) Received: from mail.asahi-net.or.jp (mail1.asahi-net.or.jp [202.224.39.197]) by mx1.freebsd.org (Postfix) with ESMTP id 665288FC08 for ; Fri, 13 Feb 2009 04:43:03 +0000 (UTC) (envelope-from ota@j.email.ne.jp) Received: from localhost (pool-141-151-76-181.phlapa.east.verizon.net [141.151.76.181]) by mail.asahi-net.or.jp (Postfix) with ESMTP id D9D4161590; Fri, 13 Feb 2009 13:24:37 +0900 (JST) Date: Thu, 12 Feb 2009 23:24:32 -0500 From: Yoshihiro Ota To: Mark Kirkwood , FreeBSD-stable@FreeBSD.org Message-Id: <20090212232432.84e455f8.ota@j.email.ne.jp> In-Reply-To: <498E59F0.30700@paradise.net.nz> References: <20090109171857.GA49752@marvin.eastcentral.edu> <4975ADF4.1070103@paradise.net.nz> <4976CB1C.7050409@paradise.net.nz> <498E59F0.30700@paradise.net.nz> X-Mailer: Sylpheed 2.6.0 (GTK+ 2.12.11; i386-portbld-freebsd7.1) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: rizzo@iet.unipi.it Subject: Re: Broken loader on 7.1-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, 13 Feb 2009 04:43:03 -0000 On Sun, 08 Feb 2009 17:05:04 +1300 Mark Kirkwood wrote: > Mark Kirkwood wrote: > > I wrote: > >> > >> I am getting this too - update from RELENG_7 @12 Jan src to 20 Jan > >> and I have: > >> > >> panic: free: guard1 fail @ 0x511d > >> from /usr/src/sys/boot/i386/loader/../../common/module.c:959 > >> > >> Can't work out which disk we are booting from. > >> Guessed BIOS device 0xffffffff not found by probes, defaulting to disk0 I am experiencing same error. In my case, I cannot boot from anything other than /boot/kernel. While my /boot/kernel is bootable, I do "cp -pr /boot/kernel /boot/kernel.ok". Then, it fails like the error message above. After I do mv /boot/kernel.ok /boot/kernel, it boots fine. My environment is HP pavilion dv6425 with FreeBSD 7.1. I think I started noticing this since 7.1-RC. Regards, Hiro From owner-freebsd-stable@FreeBSD.ORG Fri Feb 13 05:58:04 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6AAE3106566C for ; Fri, 13 Feb 2009 05:58:04 +0000 (UTC) (envelope-from bakul@bitblocks.com) Received: from mail.bitblocks.com (mail.bitblocks.com [64.142.15.60]) by mx1.freebsd.org (Postfix) with ESMTP id 470C08FC17 for ; Fri, 13 Feb 2009 05:58:04 +0000 (UTC) (envelope-from bakul@bitblocks.com) Received: from bitblocks.com (localhost.bitblocks.com [127.0.0.1]) by mail.bitblocks.com (Postfix) with ESMTP id 1D4825B37; Thu, 12 Feb 2009 21:40:58 -0800 (PST) To: Karl Denninger In-reply-to: Your message of "Thu, 12 Feb 2009 21:01:38 CST." <4994E292.4000802@denninger.net> References: <4994CD7B.7040302@denninger.net> <4994D603.2060406@delphij.net> <4994D931.4060508@denninger.net> <4994DACC.1040801@delphij.net> <4994DBC1.2000309@denninger.net> <4994DFB0.3060704@delphij.net> <4994E292.4000802@denninger.net> Comments: In-reply-to Karl Denninger message dated "Thu, 12 Feb 2009 21:01:38 -0600." Date: Thu, 12 Feb 2009 21:40:58 -0800 From: Bakul Shah Message-Id: <20090213054059.1D4825B37@mail.bitblocks.com> Cc: freebsd-stable@freebsd.org Subject: Re: Upgrade from 32-bit to AMD-64? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Feb 2009 05:58:04 -0000 On Thu, 12 Feb 2009 21:01:38 CST Karl Denninger wrote: > >> I guess I need to schedule the 2-3 hours of downtime..... the reason for > >> this, by the way, is that I have a dbms app on there that is getting too > >> RAM hungry for its own good (its a Quadcore CPU) and I'm up against the > >> RAM limit for 32-bit code. The board will support more but 32-bit code > >> won't; ergo, the only way to get beyond this is to go to 64-bit. > >> > > > > Oh wait! One thing you wanted to know is that, some database *can* have > > different on-disk format for 32-bit and 64-bit binaries. Be sure to > > have a dump handy. Last time I hit this on a MySQL "upgrade" between > > two servers, and I end up using its replication functionality. The > > operation took longer time than I expected at the beginning. > > > > My personal suggestion is that you do an experiment on another box > > (64-bit capable) to make sure that the data would work, this never hurts > > and avoids surprises (you do want 64-bit compile of your database > > application since you want to take full advantage of 64-bit OS); also, > > just like all upgrades, full backup is advised. > > > > Cheers, > > - -- > > Xin LI http://www.delphij.net > I already know I have to dump the database and then reload it - I > attempted to migrate the disk structure across (which would have saved > even more time) and got instantaneously hosed, presumably due to > internal data type length differences. > > This little upgrade is going to take a while; sounds like the best > approach is to load a new box, shut down the dbms to connections and > dump/pipe it over, then physically swap the machines. May be you can install the 64 bit world from an install CD to a 2 to 4GB USB flash drive, reboot to the 64 bit kernel & set root on the flash drive, mount your original filesystems under /mnt, make and install with DESTDIR=/mnt, mergemaster -D /mnt and reboot? From owner-freebsd-stable@FreeBSD.ORG Fri Feb 13 06:51:15 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 82F1A106566B for ; Fri, 13 Feb 2009 06:51:15 +0000 (UTC) (envelope-from henry.hu.sh@gmail.com) Received: from mail-gx0-f224.google.com (mail-gx0-f224.google.com [209.85.217.224]) by mx1.freebsd.org (Postfix) with ESMTP id 3EF1A8FC0A for ; Fri, 13 Feb 2009 06:51:14 +0000 (UTC) (envelope-from henry.hu.sh@gmail.com) Received: by gxk24 with SMTP id 24so583145gxk.19 for ; Thu, 12 Feb 2009 22:51:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:reply-to:date:message-id :subject:from:to:cc:content-type:content-transfer-encoding; bh=0s/3KGPZALtbhar8nah37t5Tj1WOWgDdUF0+gV+fZFc=; b=wOzIS8z1gikam0hrdqTsXeBxDuNZ71C7yV8/ieYEk2OD92z4c7fPKPUrRGCtPM2aIS waAJOiY/Vr3NZ0ZNF57VJk0ro929uU3nJd7up5xrZ8lZjEO91fQf1w808GMBs4YsBc9c YNjWsDg3f+c3t5BlY/1O8PhfFZUJbi1qlXJOw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:reply-to:date:message-id:subject:from:to:cc :content-type:content-transfer-encoding; b=Zba1nzcRI2WOBAAnH3hmTXylpx4CbrArOvsj61nh+9c36q4MzPpIsSZd7QoWBm/1iQ 8rExotK2FaWsqx9YuqjlVBtYjc6/vPgBsKQ0uE+GjRhPjLJr0Jo+dS5CG/OAVxHjLpEG /sfXh6kZrRjaZDdhQ6INoWsta2I4mzHk7FzrM= MIME-Version: 1.0 Received: by 10.142.77.7 with SMTP id z7mr804204wfa.230.1234506586190; Thu, 12 Feb 2009 22:29:46 -0800 (PST) Date: Fri, 13 Feb 2009 14:29:46 +0800 Message-ID: <53a1e0710902122229l606bb2c9pcc71ea38fafa1193@mail.gmail.com> From: Henry Hu To: Ross Penner Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org Subject: Re: pkg_delete segfaulting after upgrading to 7.1 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: hu.henry9@gmail.com List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Feb 2009 06:51:15 -0000 > rosbox# pkg_delete -f gpgme-1.1.5_1 > pkg_delete: package 'gpgme-1.1.5_1' is required by these other packages > and may not be deinstalled (but I'll delete it anyway): > seahorse-2.24.1_1 > Segmentation fault (core dumped) I've had similar problem, and found the problem is in the +CONTENTS in the corresponding folder under /var/db/pkg/ . It's caused by an empty @pkgdep line here. I don't know what went wrong when the +CONTENTS file was created. But delete all these empty @pkgdep lines solved my problem. Cheers, Henry From owner-freebsd-stable@FreeBSD.ORG Fri Feb 13 07:53:14 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BAA0B106566B for ; Fri, 13 Feb 2009 07:53:14 +0000 (UTC) (envelope-from mandrews@bit0.com) Received: from magnum.bit0.com (magnum.bit0.com [207.246.88.226]) by mx1.freebsd.org (Postfix) with ESMTP id 8D9438FC14 for ; Fri, 13 Feb 2009 07:53:14 +0000 (UTC) (envelope-from mandrews@bit0.com) Received: from fred.int.bit0.com (nat.bit0.com [207.246.88.210]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by magnum.bit0.com (Postfix) with ESMTPSA id 5E196164DB1; Fri, 13 Feb 2009 02:53:13 -0500 (EST) Message-ID: <499526E9.3090804@bit0.com> Date: Fri, 13 Feb 2009 02:53:13 -0500 From: Mike Andrews User-Agent: Thunderbird 2.0.0.19 (Macintosh/20081209) MIME-Version: 1.0 To: d@delphij.net References: <4994CD7B.7040302@denninger.net> <4994D603.2060406@delphij.net> <4994D931.4060508@denninger.net> <4994DACC.1040801@delphij.net> <4994DBC1.2000309@denninger.net> <4994DFB0.3060704@delphij.net> In-Reply-To: <4994DFB0.3060704@delphij.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org, Karl Denninger Subject: Re: Upgrade from 32-bit to AMD-64? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Feb 2009 07:53:15 -0000 Xin LI wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Karl Denninger wrote: > [...] >> I guess I need to schedule the 2-3 hours of downtime..... the reason for >> this, by the way, is that I have a dbms app on there that is getting too >> RAM hungry for its own good (its a Quadcore CPU) and I'm up against the >> RAM limit for 32-bit code. The board will support more but 32-bit code >> won't; ergo, the only way to get beyond this is to go to 64-bit. > > Oh wait! One thing you wanted to know is that, some database *can* have > different on-disk format for 32-bit and 64-bit binaries. Be sure to > have a dump handy. Last time I hit this on a MySQL "upgrade" between > two servers, and I end up using its replication functionality. The > operation took longer time than I expected at the beginning. For what it's worth, I did an in-place source upgrade on our MySQL server (for the same lack-of-memory reason) and didn't have any on-disk format problems. In fact later on when troubleshooting data corruption problems that turned out to be bad hardware, I switched between 32-bit and 64-bit mysqld binaries without rebooting or dumping/reimporting the database. BUT... there was no replication involved. It wouldn't surprise me if the binlog or relay logs were in an architecture specific format. InnoDB and MyISAM tables don't appear to be. This was over a year ago though, so test on a scratch box first and you may save yourself a bit of downtime. The upgrade is a pain, and does have a lot of potential foot-shooting, and you have to immediately recompile ALL of your installed ports (and anything else not built from ports) to avoid mixing 32-bit and 64-bit shared libraries... and that rebuilding ports time is where most of your downtime comes from if it's a production box. If you're feeling lucky, the procedure's in the list archives somewhere and the super-short version is you turn your swap partition into a temporary amd64 root filesystem, installworld/kernel into that, boot into that, then mount and installworld/kernel on top of the old i386 root filesystem from there, then boot into it and recompile all your ports (after reclaiming your swap partition for swap). Or, the way I did it last time was to boot into a PXE diskless FreeBSD/amd64 install and use that to mount/install over the i386 stuff. Definitely practice on a scratch system first. :) -- Mike Andrews Server Monkey Fark, Inc mandrews@fark.com From owner-freebsd-stable@FreeBSD.ORG Fri Feb 13 09:05:20 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E0AF2106566C for ; Fri, 13 Feb 2009 09:05:20 +0000 (UTC) (envelope-from goran.lowkrantz@ismobile.com) Received: from mail.ismobile.com (mail.ismobile.com [62.119.44.68]) by mx1.freebsd.org (Postfix) with ESMTP id 5D4118FC1A for ; Fri, 13 Feb 2009 09:05:20 +0000 (UTC) (envelope-from goran.lowkrantz@ismobile.com) Received: from mail.ismobile.com (localhost [127.0.0.1]) by mail.ismobile.com (Postfix) with ESMTP id 4CB194B4; Fri, 13 Feb 2009 09:40:29 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=ismobile.com; h=date:from :to:cc:subject:message-id:in-reply-to:references:mime-version :content-type:content-transfer-encoding; s=selector1; bh=rpNujB6 OMD5qlBpC0dhQF64TPjk=; b=DSdC6aUffUT6tA8TNXCjaisrFLjgz+BrrezWPY8 PPuxzA3CDRB7nEjKS194C04N716v8oMOdoDKRqX2rr1/T4eIal3MpiAd9Yag7Szz XErjoznoCCJq2gQxd1GCaGb6PT12EK2FK7xe1AVHjb97GkLeXWqZSGelv9z7q2ls PKw4= Received: from [172.16.2.105] (unknown [172.16.2.105]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.ismobile.com (Postfix) with ESMTPSA id 9A5574B3; Fri, 13 Feb 2009 09:40:28 +0100 (CET) Date: Fri, 13 Feb 2009 09:40:27 +0100 From: Goran Lowkrantz To: d@delphij.net Message-ID: <2CA7DE699281AFA5DF2BD851@syn> In-Reply-To: <499526E9.3090804@bit0.com> References: <4994CD7B.7040302@denninger.net> <4994D603.2060406@delphij.net> <4994D931.4060508@denninger.net> <4994DACC.1040801@delphij.net> <4994DBC1.2000309@denninger.net> <4994DFB0.3060704@delphij.net> <499526E9.3090804@bit0.com> X-Mailer: Mulberry/4.0.8 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Cc: freebsd-stable@freebsd.org, Mike Andrews , Karl Denninger Subject: Re: Upgrade from 32-bit to AMD-64? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Feb 2009 09:05:21 -0000 Hi, When have done this, MySQL is OK but Berkley and PostgreSQL need=20 dump/restore. /glz --On February 13, 2009 2:53:13 -0500 Mike Andrews = wrote: > Xin LI wrote: >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> >> Karl Denninger wrote: >> [...] >>> I guess I need to schedule the 2-3 hours of downtime..... the reason = for >>> this, by the way, is that I have a dbms app on there that is getting = too >>> RAM hungry for its own good (its a Quadcore CPU) and I'm up against the >>> RAM limit for 32-bit code. The board will support more but 32-bit code >>> won't; ergo, the only way to get beyond this is to go to 64-bit. >> >> Oh wait! One thing you wanted to know is that, some database *can* have >> different on-disk format for 32-bit and 64-bit binaries. Be sure to >> have a dump handy. Last time I hit this on a MySQL "upgrade" between >> two servers, and I end up using its replication functionality. The >> operation took longer time than I expected at the beginning. > > For what it's worth, I did an in-place source upgrade on our MySQL server > (for the same lack-of-memory reason) and didn't have any on-disk format > problems. In fact later on when troubleshooting data corruption problems > that turned out to be bad hardware, I switched between 32-bit and 64-bit > mysqld binaries without rebooting or dumping/reimporting the database. > > BUT... there was no replication involved. It wouldn't surprise me if the > binlog or relay logs were in an architecture specific format. InnoDB and > MyISAM tables don't appear to be. This was over a year ago though, so > test on a scratch box first and you may save yourself a bit of downtime. > > The upgrade is a pain, and does have a lot of potential foot-shooting, > and you have to immediately recompile ALL of your installed ports (and > anything else not built from ports) to avoid mixing 32-bit and 64-bit > shared libraries... and that rebuilding ports time is where most of your > downtime comes from if it's a production box. > > If you're feeling lucky, the procedure's in the list archives somewhere > and the super-short version is you turn your swap partition into a > temporary amd64 root filesystem, installworld/kernel into that, boot into > that, then mount and installworld/kernel on top of the old i386 root > filesystem from there, then boot into it and recompile all your ports > (after reclaiming your swap partition for swap). Or, the way I did it > last time was to boot into a PXE diskless FreeBSD/amd64 install and use > that to mount/install over the i386 stuff. > > Definitely practice on a scratch system first. :) > > > -- > Mike Andrews > Server Monkey > Fark, Inc > mandrews@fark.com > _______________________________________________ > 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" ................................................... the future isMobile Goran Lowkrantz System Architect, isMobile AB Sandviksgatan 81, PO Box 58, S-971 03 Lule=E5, Sweden Mobile: +46(0)70-587 87 82 http://www.ismobile.com ............................................... From owner-freebsd-stable@FreeBSD.ORG Fri Feb 13 09:19:14 2009 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 18F8E106566B for ; Fri, 13 Feb 2009 09:19:14 +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 5AA848FC12 for ; Fri, 13 Feb 2009 09:19:12 +0000 (UTC) (envelope-from gerrit@pmp.uni-hannover.de) 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 n1D9JAle011183; Fri, 13 Feb 2009 10:19:11 +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 2E4424F; Fri, 13 Feb 2009 10:19:10 +0100 (CET) Date: Fri, 13 Feb 2009 10:19:10 +0100 From: Gerrit =?ISO-8859-1?Q?K=FChn?= To: pyunyh@gmail.com Message-Id: <20090213101910.a126c14d.gerrit@pmp.uni-hannover.de> In-Reply-To: <20090205082804.GD77461@michelle.cdnetworks.co.kr> References: <20090204100507.5f223d9e.gerrit@pmp.uni-hannover.de> <20090204104655.GA73543@michelle.cdnetworks.co.kr> <20090205085812.b2deb1f7.gerrit@pmp.uni-hannover.de> <20090205082804.GD77461@michelle.cdnetworks.co.kr> 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.8 (GTK+ 2.12.11; i386-portbld-freebsd7.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-PMX-Version: 5.5.2.363555, Antispam-Engine: 2.6.1.350677, Antispam-Data: 2009.2.13.90715 Cc: stable@freebsd.org Subject: Re: fun with if_re X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Feb 2009 09:19:14 -0000 On Thu, 5 Feb 2009 17:28:04 +0900 Pyun YongHyeon wrote about Re: fun with if_re: PY> > I did build new nanobsd images with these patches meanwhile and will PY> > start using them today. However, as it has worked without problems PY> > for weeks with the buggy version before, I will not be able to say PY> > if it is really working until next month or so. Or do you know any PY> > method to reliably PY> PY> That's fine. I had to reboot some of the machines meanwhile and could do some further testing. One strange thing I noticed is that the re-interfaces often do not come up in a working state after rebooting. Strangely, I see network traffic floating around via tcpdump, but not even ping works. This state often goes away when playing around with the interface (sometimes ifconfig down/up helps, sometimes disabling some of the additional features like txc/rxc), but I cannot make out a reproducible behaviour so far. When the interface leaves this strange state it seems to work fine afterwards. Any clues? cu Gerrit From owner-freebsd-stable@FreeBSD.ORG Fri Feb 13 09:28:59 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1A8B110656C9 for ; Fri, 13 Feb 2009 09:28:59 +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 7E0F98FC12 for ; Fri, 13 Feb 2009 09:28:58 +0000 (UTC) (envelope-from gerrit@pmp.uni-hannover.de) 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 n1D9Stgs011668; Fri, 13 Feb 2009 10:28:57 +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 E7FCE4F; Fri, 13 Feb 2009 10:28:55 +0100 (CET) Date: Fri, 13 Feb 2009 10:28:55 +0100 From: Gerrit =?ISO-8859-1?Q?K=FChn?= To: Jaakko Heinonen Message-Id: <20090213102855.51976ec4.gerrit@pmp.uni-hannover.de> In-Reply-To: <20090211175511.GA38986@a91-153-125-115.elisa-laajakaista.fi> References: <20090211171110.a8217734.gerrit@pmp.uni-hannover.de> <20090211175511.GA38986@a91-153-125-115.elisa-laajakaista.fi> 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.8 (GTK+ 2.12.11; i386-portbld-freebsd7.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-PMX-Version: 5.5.2.363555, Antispam-Engine: 2.6.1.350677, Antispam-Data: 2009.2.13.91638 Cc: freebsd-stable@freebsd.org Subject: Re: zfs crashes with nfs and snapshots X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Feb 2009 09:29:00 -0000 On Wed, 11 Feb 2009 19:55:11 +0200 Jaakko Heinonen wrote about Re: zfs crashes with nfs and snapshots: JH> This is likely the issue described in this message: JH> http://lists.freebsd.org/pipermail/freebsd-fs/2008-October/005217.html Yes, this looks very much like it. JH> The nfs fix has been committed to head and stable/7 (7.1-RELEASE has JH> the fix). The fix prevents system from panicing but you still can't JH> access the snapshot directory with readdirplus enabled nfs clients. As JH> a workaround you can disable readdirplus support if your nfs client JH> allows it. Ok, I will upgrade to 7.1-stable asap. The client was Linux 2.6.25, I cannot say if it uses readdirplus and if I could disable that (the manpage says nothing about it at all, but I will look into that further). Thanks for the hint. cu Gerrit From owner-freebsd-stable@FreeBSD.ORG Fri Feb 13 09:45:07 2009 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 396AC1065679; Fri, 13 Feb 2009 09:45:07 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from mail.cksoft.de (mail.cksoft.de [62.111.66.27]) by mx1.freebsd.org (Postfix) with ESMTP id E14B78FC0C; Fri, 13 Feb 2009 09:45:06 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from localhost (amavis.str.cksoft.de [192.168.74.71]) by mail.cksoft.de (Postfix) with ESMTP id DC4E941C65E; Fri, 13 Feb 2009 10:45:05 +0100 (CET) X-Virus-Scanned: amavisd-new at cksoft.de Received: from mail.cksoft.de ([62.111.66.27]) by localhost (amavis.str.cksoft.de [192.168.74.71]) (amavisd-new, port 10024) with ESMTP id 6q0eVXvAuzLR; Fri, 13 Feb 2009 10:45:05 +0100 (CET) Received: by mail.cksoft.de (Postfix, from userid 66) id 8365641C63C; Fri, 13 Feb 2009 10: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 33A9B4448EC; Fri, 13 Feb 2009 09:44:14 +0000 (UTC) Date: Fri, 13 Feb 2009 09:44:14 +0000 (UTC) From: "Bjoern A. Zeeb" X-X-Sender: bz@maildrop.int.zabbadoz.net To: FreeBSD current mailing list Message-ID: <20090213092746.R53478@maildrop.int.zabbadoz.net> X-OpenPGP-Key: 0x14003F198FEFA3E77207EE8D2B58B8F83CCF1842 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: FreeBSD stable mailing list , FreeBSD questions mailing list , FreeBSD net mailing list Subject: "The LOR page" is back X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Feb 2009 09:45:07 -0000 Hi, in case you find a LOR, want to report it or want to see if it's known or find out more about it... you can go and check "The LOR page" again. It's up on a temporary setup (so in case it's not avail come back a bit later) until I can finally move the web elsewhere. The URL has stayed the same: http://sources.zabbadoz.net/freebsd/lor.html The page has a few instructions and links to further information. You may want to read them before doing anything else to help everybody. Thanks! /bz -- Bjoern A. Zeeb The greatest risk is not taking one. From owner-freebsd-stable@FreeBSD.ORG Fri Feb 13 10:20:17 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DF6381065672 for ; Fri, 13 Feb 2009 10:20:17 +0000 (UTC) (envelope-from richardtoohey@paradise.net.nz) Received: from smtp3.clear.net.nz (smtp3.clear.net.nz [203.97.33.64]) by mx1.freebsd.org (Postfix) with ESMTP id AC5E18FC18 for ; Fri, 13 Feb 2009 10:20:17 +0000 (UTC) (envelope-from richardtoohey@paradise.net.nz) Received: from [192.168.1.2] (121-72-11-54.dsl.telstraclear.net [121.72.11.54]) by smtp3.clear.net.nz (CLEAR Net Mail) with ESMTP id <0KF000D9N1CIFV20@smtp3.clear.net.nz> for freebsd-stable@freebsd.org; Fri, 13 Feb 2009 23:05:07 +1300 (NZDT) Date: Fri, 13 Feb 2009 23:05:05 +1300 From: Richard Toohey To: freebsd-stable@freebsd.org Message-id: MIME-version: 1.0 (Apple Message framework v753.1) X-Mailer: Apple Mail (2.753.1) Content-type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Content-transfer-encoding: 7bit Cc: spork@bway.net Subject: Re: 7.1 Panic on degraded disk w/mpt X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Feb 2009 10:20:18 -0000 Charles Sprickman said: >Howdy, > >I dug around and can't find a PR on this, and the only other report I saw >was in this mailing list post that has no replies: > >http://www.nabble.com/7.1-BETA2-panic-on-mpt-degrade-td20183173.html > >The hardware is a Dell PowerEdge 860 with the Dell/LSI SAS5 controller: >mpt0: port 0xec00-0xecff mem >0xfe9fc000-0xfe9fffff,0xfe9e0000-0xfe9effff irq 16 at device 8.0 on pci2 >mpt0: MPI Version=1.5.13.0 > >The panic is repeatable by forcing the array into a degraded state. I think this is PR 130330. http://www.freebsd.org/cgi/query-pr.cgi?pr=130330&cat= I am trying to get another test machine available - the machines I had have gone into production with 7.0 installed. (Apologies if this email doesn't appear correctly, done what I can!) From owner-freebsd-stable@FreeBSD.ORG Fri Feb 13 10:21:09 2009 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 E18D71065688 for ; Fri, 13 Feb 2009 10:21:09 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.236]) by mx1.freebsd.org (Postfix) with ESMTP id AC3D58FC29 for ; Fri, 13 Feb 2009 10:21:08 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: by rv-out-0506.google.com with SMTP id f6so687213rvb.43 for ; Fri, 13 Feb 2009 02:21:08 -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=VjA9r3z41zCDXv01leTcYLl8MbZCZZx7ita43JTZflY=; b=QHi7QUVBmT+z9im9oN9T9R1+1D0E0T84twZbftpqReIV5WPkfNEPyvLstV7yO83eMb ii2I6S1lK37oSr/XpI80E3XbIbuTRMbk5S7uP36t/vKXYArsjQxvds9raqcEgXciBIJ0 xXlohawu/MVoxQqWsxdKsjojs1Ad5si/HPVhA= 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=eyMhysNeQD/xxHdsCZFZyyvHXTL8ygISr1RNp+YijYf22fbosTN0hL6mIaj6urPXif 5lNDkEcqAbkdoAyP/KYYR3fr02ZWuUrfBwOQRUH8X8Ahx8RL47D4QvTX/yA+ebEzuD/H JiWg4XYwWILmL4PV9HlIXTuXaT9A4/avMQS8A= Received: by 10.141.128.19 with SMTP id f19mr1066818rvn.276.1234520468549; Fri, 13 Feb 2009 02:21:08 -0800 (PST) Received: from michelle.cdnetworks.co.kr ([114.111.62.249]) by mx.google.com with ESMTPS id k2sm2436897rvb.4.2009.02.13.02.21.06 (version=SSLv3 cipher=RC4-MD5); Fri, 13 Feb 2009 02:21:07 -0800 (PST) Received: by michelle.cdnetworks.co.kr (sSMTP sendmail emulation); Fri, 13 Feb 2009 19:24:00 +0900 From: Pyun YongHyeon Date: Fri, 13 Feb 2009 19:24:00 +0900 To: Gerrit K?hn Message-ID: <20090213102400.GD12653@michelle.cdnetworks.co.kr> References: <20090204100507.5f223d9e.gerrit@pmp.uni-hannover.de> <20090204104655.GA73543@michelle.cdnetworks.co.kr> <20090205085812.b2deb1f7.gerrit@pmp.uni-hannover.de> <20090205082804.GD77461@michelle.cdnetworks.co.kr> <20090213101910.a126c14d.gerrit@pmp.uni-hannover.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20090213101910.a126c14d.gerrit@pmp.uni-hannover.de> User-Agent: Mutt/1.4.2.3i Cc: stable@freebsd.org Subject: Re: fun with if_re 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: Fri, 13 Feb 2009 10:21:10 -0000 On Fri, Feb 13, 2009 at 10:19:10AM +0100, Gerrit K?hn wrote: > On Thu, 5 Feb 2009 17:28:04 +0900 Pyun YongHyeon wrote > about Re: fun with if_re: > > PY> > I did build new nanobsd images with these patches meanwhile and will > PY> > start using them today. However, as it has worked without problems > PY> > for weeks with the buggy version before, I will not be able to say > PY> > if it is really working until next month or so. Or do you know any > PY> > method to reliably > PY> > PY> That's fine. > > > I had to reboot some of the machines meanwhile and could do some further > testing. One strange thing I noticed is that the re-interfaces often do > not come up in a working state after rebooting. Strangely, I see > network traffic floating around via tcpdump, but not even ping works. > This state often goes away when playing around with the interface > (sometimes ifconfig down/up helps, sometimes disabling some of the > additional features like txc/rxc), but I cannot make out a reproducible > behaviour so far. When the interface leaves this strange state it seems to > work fine afterwards. Any clues? > Does this happen on latest if_re.c/if_rlreg.h? I guess jkim fixed this type of problem in r187483. If that have no effect please let me know. From owner-freebsd-stable@FreeBSD.ORG Fri Feb 13 10:41:46 2009 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 E0596106564A for ; Fri, 13 Feb 2009 10:41:46 +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 6A1FE8FC1F for ; Fri, 13 Feb 2009 10:41:46 +0000 (UTC) (envelope-from gerrit@pmp.uni-hannover.de) 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 n1DAfh7B015146; Fri, 13 Feb 2009 11:41:45 +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 EEA9972; Fri, 13 Feb 2009 11:41:43 +0100 (CET) Date: Fri, 13 Feb 2009 11:41:43 +0100 From: Gerrit =?ISO-8859-1?Q?K=FChn?= To: pyunyh@gmail.com Message-Id: <20090213114143.a77f1acb.gerrit@pmp.uni-hannover.de> In-Reply-To: <20090213102400.GD12653@michelle.cdnetworks.co.kr> References: <20090204100507.5f223d9e.gerrit@pmp.uni-hannover.de> <20090204104655.GA73543@michelle.cdnetworks.co.kr> <20090205085812.b2deb1f7.gerrit@pmp.uni-hannover.de> <20090205082804.GD77461@michelle.cdnetworks.co.kr> <20090213101910.a126c14d.gerrit@pmp.uni-hannover.de> <20090213102400.GD12653@michelle.cdnetworks.co.kr> 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.8 (GTK+ 2.12.11; i386-portbld-freebsd7.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-PMX-Version: 5.5.2.363555, Antispam-Engine: 2.6.1.350677, Antispam-Data: 2009.2.13.102516 Cc: stable@freebsd.org Subject: Re: fun with if_re X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Feb 2009 10:41:47 -0000 On Fri, 13 Feb 2009 19:24:00 +0900 Pyun YongHyeon wrote about Re: fun with if_re: PY> > I had to reboot some of the machines meanwhile and could do some PY> > further testing. One strange thing I noticed is that the PY> > re-interfaces often do not come up in a working state after PY> > rebooting. Strangely, I see network traffic floating around via PY> > tcpdump, but not even ping works. This state often goes away when PY> > playing around with the interface (sometimes ifconfig down/up helps, PY> > sometimes disabling some of the additional features like txc/rxc), PY> > but I cannot make out a reproducible behaviour so far. When the PY> > interface leaves this strange state it seems to work fine PY> > afterwards. Any clues? PY> Does this happen on latest if_re.c/if_rlreg.h? I guess jkim fixed PY> this type of problem in r187483. If that have no effect please let PY> me know. It happens on both versions: the old one from 11th Dec 08 I still had, and the new one I built with the patches you recommended about a week ago. if_re is 1.151 2009/01/20 20:22:28 jkim, if_rlreg is 1.94 2009/01/20 20:22:28 jkim for the latter. cu Gerrit From owner-freebsd-stable@FreeBSD.ORG Fri Feb 13 10:48:18 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EAA231065677; Fri, 13 Feb 2009 10:48:18 +0000 (UTC) (envelope-from horst@sxemacs.org) Received: from mail11.syd.optusnet.com.au (mail11.syd.optusnet.com.au [211.29.132.192]) by mx1.freebsd.org (Postfix) with ESMTP id 4CB7A8FC16; Fri, 13 Feb 2009 10:48:17 +0000 (UTC) (envelope-from horst@sxemacs.org) Received: from [220.237.124.212] (c220-237-124-212.farfl2.nsw.optusnet.com.au [220.237.124.212]) (authenticated sender horst.burkhardt) by mail11.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id n1DAmENG018638; Fri, 13 Feb 2009 21:48:15 +1100 From: Horst =?ISO-8859-1?Q?G=FCnther?= Burkhardt III To: FreeBSD-STABLE Mailing List , FreeBSD PowerPC ML Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-1Dcse+3ym96ibWoWRMyE" Date: Fri, 13 Feb 2009 21:49:54 +1100 Message-Id: <1234522194.13304.34.camel@horst-tla> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 Cc: Subject: [7-STABLE] failure during buildworld X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Feb 2009 10:48:19 -0000 --=-1Dcse+3ym96ibWoWRMyE Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Hey everybody :)=20 I'm having a small issue compiling 7-STABLE... during make buildworld, this= error occurs:=20 =3D=3D=3D> gnu/lib/libstdc++ (depend) ln -sf /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/config/cpu/gen= eric/atomicity_mutex/atomicity.h atomicity.cc ln -sf /usr/src/gnu/lib/libstdc++/../../../contrib/gcc/unwind-generic.h unw= ind.h rm -f .depend mkdep -f .depend -a -DIN_GLIBCPP_V3 -DHAVE_CONFIG_H -I/usr/src/gnu/lib/l= ibstdc++ -I/usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/libsupc++ = -I/usr/src/gnu/lib/libstdc++/../../../contrib/gcc -I/usr/src/gnu/lib/libstd= c++/../../../contrib/libstdc++/include -I/usr/src/gnu/lib/libstdc++/../../.= ./contrib/gcclibs/include -I/usr/src/gnu/lib/libstdc++/../../../contrib/lib= stdc++/include -I. /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/li= bmath/stubs.c /usr/src/gnu/lib/libstdc++/../../../contrib/gcclibs/libiberty= /cp-demangle.c mkdep -f .depend -a /usr/src/gnu/lib/libstdc++/../../../contrib/libstd= c++/src/bitmap_allocator.cc /usr/src/gnu/lib/libstdc++/../../../contrib/lib= stdc++/src/pool_allocator.cc /usr/src/gnu/lib/libstdc++/../../../contrib/li= bstdc++/src/mt_allocator.cc /usr/src/gnu/lib/libstdc++/../../../contrib/lib= stdc++/src/codecvt.cc /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++= /src/compatibility.cc /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++= /src/complex_io.cc /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/sr= c/ctype.cc /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/src/debug.= cc /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/src/debug_list.cc = /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/src/functexcept.cc /u= sr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/src/globals_io.cc /usr/= src/gnu/lib/libstdc++/../../../contrib/libstdc++/src/ios.cc /usr/src/gnu/li= b/libstdc++/../../../contrib/libstdc++/src/ios_failure.cc /usr/src/gnu/lib/= libstdc++/../../../contrib/libstdc++/src/ios_init.cc /usr/src/gnu/lib/libst= dc++/../../../contrib/libstdc++/src/ios_locale.cc /usr/src/gnu/lib/libstdc+= +/../../../contrib/libstdc++/src/limits.cc /usr/src/gnu/lib/libstdc++/../..= /../contrib/libstdc++/src/list.cc /usr/src/gnu/lib/libstdc++/../../../contr= ib/libstdc++/src/locale.cc /usr/src/gnu/lib/libstdc++/../../../contrib/libs= tdc++/src/locale_init.cc /usr/src/gnu/lib/libstdc++/../../../contrib/libstd= c++/src/locale_facets.cc /usr/src/gnu/lib/libstdc++/../../../contrib/libstd= c++/src/localename.cc /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++= /src/stdexcept.cc /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/src= /strstream.cc /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/src/tre= e.cc /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/src/allocator-in= st.cc /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/src/concept-ins= t.cc /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/src/fstream-inst= .cc /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/src/ext-inst.cc /= usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/src/ios-inst.cc /usr/s= rc/gnu/lib/libstdc++/../../../contrib/libstdc++/src/iostream-inst.cc /usr/s= rc/gnu/lib/libstdc++/../../../contrib/libstdc++/src/istream-inst.cc /usr/sr= c/gnu/lib/libstdc++/../../../contrib/libstdc++/src/istream.cc /usr/src/gnu/= lib/libstdc++/../../../contrib/libstdc++/src/locale-inst.cc /usr/src/gnu/li= b/libstdc++/../../../contrib/libstdc++/src/misc-inst.cc /usr/src/gnu/lib/li= bstdc++/../../../contrib/libstdc++/src/ostream-inst.cc /usr/src/gnu/lib/lib= stdc++/../../../contrib/libstdc++/src/sstream-inst.cc /usr/src/gnu/lib/libs= tdc++/../../../contrib/libstdc++/src/streambuf-inst.cc /usr/src/gnu/lib/lib= stdc++/../../../contrib/libstdc++/src/streambuf.cc /usr/src/gnu/lib/libstdc= ++/../../../contrib/libstdc++/src/string-inst.cc /usr/src/gnu/lib/libstdc++= /../../../contrib/libstdc++/src/valarray-inst.cc /usr/src/gnu/lib/libstdc++= /../../../contrib/libstdc++/src/wlocale-inst.cc /usr/src/gnu/lib/libstdc++/= ../../../contrib/libstdc++/src/wstring-inst.cc atomicity.cc /usr/src/gnu/li= b/libstdc++/../../../contrib/libstdc++/config/locale/generic/codecvt_member= s.cc /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/config/locale/ge= neric/collate_members.cc /usr/src/gnu/lib/libstdc++/../../../contrib/libstd= c++/config/locale/darwin/ctype_members.cc /usr/src/gnu/lib/libstdc++/../../= ../contrib/libstdc++/config/locale/generic/messages_members.cc /usr/src/gnu= /lib/libstdc++/../../../contrib/libstdc++/config/locale/generic/monetary_me= mbers.cc /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/config/local= e/generic/numeric_members.cc /usr/src/gnu/lib/libstdc++/../../../contrib/li= bstdc++/config/locale/generic/time_members.cc /usr/src/gnu/lib/libstdc++/..= /../../contrib/libstdc++/config/io/basic_file_stdio.cc /usr/src/gnu/lib/lib= stdc++/../../../contrib/libstdc++/config/locale/generic/c_locale.cc /usr/sr= c/gnu/lib/libstdc++/../../../contrib/libstdc++/libsupc++/del_op.cc /usr/src= /gnu/lib/libstdc++/../../../contrib/libstdc++/libsupc++/del_opnt.cc /usr/sr= c/gnu/lib/libstdc++/../../../contrib/libstdc++/libsupc++/del_opv.cc /usr/sr= c/gnu/lib/libstdc++/../../../contrib/libstdc++/libsupc++/del_opvnt.cc /usr/= src/gnu/lib/libstdc++/../../../contrib/libstdc++/libsupc++/eh_alloc.cc /usr= /src/gnu/lib/libstdc++/../../../contrib/libstdc++/libsupc++/eh_arm.cc /usr/= src/gnu/lib/libstdc++/../../../contrib/libstdc++/libsupc++/eh_aux_runtime.c= c /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/libsupc++/eh_call.c= c /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/libsupc++/eh_catch.= cc /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/libsupc++/eh_excep= tion.cc /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/libsupc++/eh_= globals.cc /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/libsupc++/= eh_personality.cc /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/lib= supc++/eh_term_handler.cc /usr/src/gnu/lib/libstdc++/../../../contrib/libst= dc++/libsupc++/eh_terminate.cc /usr/src/gnu/lib/libstdc++/../../../contrib/= libstdc++/libsupc++/eh_throw.cc /usr/src/gnu/lib/libstdc++/../../../contrib= /libstdc++/libsupc++/eh_type.cc /usr/src/gnu/lib/libstdc++/../../../contrib= /libstdc++/libsupc++/eh_unex_handler.cc /usr/src/gnu/lib/libstdc++/../../..= /contrib/libstdc++/libsupc++/guard.cc /usr/src/gnu/lib/libstdc++/../../../c= ontrib/libstdc++/libsupc++/new_handler.cc /usr/src/gnu/lib/libstdc++/../../= ../contrib/libstdc++/libsupc++/new_op.cc /usr/src/gnu/lib/libstdc++/../../.= ./contrib/libstdc++/libsupc++/new_opnt.cc /usr/src/gnu/lib/libstdc++/../../= ../contrib/libstdc++/libsupc++/new_opv.cc /usr/src/gnu/lib/libstdc++/../../= ../contrib/libstdc++/libsupc++/new_opvnt.cc /usr/src/gnu/lib/libstdc++/../.= ./../contrib/libstdc++/libsupc++/pure.cc /usr/src/gnu/lib/libstdc++/../../.= ./contrib/libstdc++/libsupc++/tinfo.cc /usr/src/gnu/lib/libstdc++/../../../= contrib/libstdc++/libsupc++/tinfo2.cc /usr/src/gnu/lib/libstdc++/../../../c= ontrib/libstdc++/libsupc++/vec.cc /usr/src/gnu/lib/libstdc++/../../../contr= ib/libstdc++/libsupc++/vterminate.cc =20 In file included from /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++= /libsupc++/eh_alloc.cc:41: /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/libsupc++/unwind-cxx.= h:41:20: error: unwind.h: No such file or directory In file included from /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++= /libsupc++/eh_arm.cc:31: /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/libsupc++/unwind-cxx.= h:41:20: error: unwind.h: No such file or directory In file included from /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++= /libsupc++/eh_aux_runtime.cc:34: /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/libsupc++/unwind-cxx.= h:41:20: error: unwind.h: No such file or directory In file included from /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++= /libsupc++/eh_call.cc:33: /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/libsupc++/unwind-cxx.= h:41:20: error: unwind.h: No such file or directory /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/libsupc++/eh_call.cc:= 37:23: error: unwind-pe.h: No such file or directory In file included from /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++= /libsupc++/eh_catch.cc:31: /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/libsupc++/unwind-cxx.= h:41:20: error: unwind.h: No such file or directory In file included from /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++= /libsupc++/eh_exception.cc:34: /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/libsupc++/unwind-cxx.= h:41:20: error: unwind.h: No such file or directory In file included from /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++= /libsupc++/eh_globals.cc:35: /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/libsupc++/unwind-cxx.= h:41:20: error: unwind.h: No such file or directory In file included from /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++= /libsupc++/eh_personality.cc:33: /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/libsupc++/unwind-cxx.= h:41:20: error: unwind.h: No such file or directory /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/libsupc++/eh_personal= ity.cc:41:23: error: unwind-pe.h: No such file or directory In file included from /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++= /libsupc++/eh_term_handler.cc:31: /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/libsupc++/unwind-cxx.= h:41:20: error: unwind.h: No such file or directory In file included from /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++= /libsupc++/eh_terminate.cc:34: /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/libsupc++/unwind-cxx.= h:41:20: error: unwind.h: No such file or directory In file included from /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++= /libsupc++/eh_throw.cc:31: /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/libsupc++/unwind-cxx.= h:41:20: error: unwind.h: No such file or directory In file included from /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++= /libsupc++/eh_type.cc:33: /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/libsupc++/unwind-cxx.= h:41:20: error: unwind.h: No such file or directory In file included from /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++= /libsupc++/eh_unex_handler.cc:30: /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/libsupc++/unwind-cxx.= h:41:20: error: unwind.h: No such file or directory In file included from /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++= /libsupc++/pure.cc:32: /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/libsupc++/unwind-cxx.= h:41:20: error: unwind.h: No such file or directory In file included from /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++= /libsupc++/vec.cc:37: /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/libsupc++/unwind-cxx.= h:41:20: error: unwind.h: No such file or directory mkdep: compile failed *** Error code 1 Stop in /usr/src/gnu/lib/libstdc++. *** Error code 1 Stop in /usr/src/gnu/lib. *** 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. You have new mail in /var/mail/root [ bsdbox ] [ root ] [ /usr/src ] =3D=3D>=20 Is anyone else experiencing this issue? If not, what's going on? This puzzl= es me. Any help would be much appreciated. Thanks kindly, -- Horst. --=-1Dcse+3ym96ibWoWRMyE Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEABECAAYFAkmVUFIACgkQRtTtv0BbTe6aqwCeIrtH+i+EiBfHjRxJYd/Mgjex S7UAoKVzIH03mKzHErC8hQiIGMXp0QW9 =nHRo -----END PGP SIGNATURE----- --=-1Dcse+3ym96ibWoWRMyE-- From owner-freebsd-stable@FreeBSD.ORG Fri Feb 13 10:55:59 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C61DA106564A; Fri, 13 Feb 2009 10:55:59 +0000 (UTC) (envelope-from scottl@samsco.org) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.freebsd.org (Postfix) with ESMTP id 70A7C8FC0A; Fri, 13 Feb 2009 10:55:59 +0000 (UTC) (envelope-from scottl@samsco.org) Received: from phobos.local ([192.168.254.200]) (authenticated bits=0) by pooker.samsco.org (8.14.2/8.14.2) with ESMTP id n1DAtrsA072344; Fri, 13 Feb 2009 03:55:54 -0700 (MST) (envelope-from scottl@samsco.org) Message-ID: <499551B9.7050805@samsco.org> Date: Fri, 13 Feb 2009 03:55:53 -0700 From: Scott Long User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:1.8.1.13) Gecko/20080313 SeaMonkey/1.1.9 MIME-Version: 1.0 To: FreeBSD Current , FreeBSD Stable X-Enigmail-Version: 0.95.6 Content-Type: multipart/mixed; boundary="------------090508060706040908050304" X-Spam-Status: No, score=-4.4 required=3.8 tests=ALL_TRUSTED,BAYES_00 autolearn=ham version=3.1.8 X-Spam-Checker-Version: SpamAssassin 3.1.8 (2007-02-13) on pooker.samsco.org Cc: Subject: HEADS UP: Major CAM performance regression X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Feb 2009 10:56:00 -0000 This is a multi-part message in MIME format. --------------090508060706040908050304 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit All, A major performance regression was introduced to the CAM subsystem in FreeBSD 7.1. The following configurations are known to be affected: VMWare ESX VMWare Fusion (using bt or lsilogic controller options) HP CISS RAID Some MPT-SAS combinations with SATA drives attached (Includes Dell SAS5/ir, but not PERC5/PERC6). Pure SCSI and SAS subsystems likely are NOT affected. Any hardware that uses the 'ata' driver is also definitely NOT affected. To determine if your installation is affected, run the following command as root: camcontrol tags da0 Substitute 'da0' with another appropriate drive device number, if needed. Note that this ONLY AFFECTS 'da' DEVICES. If your disks are 'ad' devices, they are NOT affected. The result from running this command should be an output similar to the following: (pass0:mpt0:0:8:0): device openings: 255 If, instead, it reports a value of '1', you are likely affected. Note that it may be normal for USB memory devices to report a low number. Also, many legacy SCSI disks, and devices that are not disks, may also be expected to report a low number. The effect of this problem is that only one I/O command will be issued to the controller and disk at a time, instead of overlapping multiple commands in parallel. This causes significantly higher latency in servicing moderate and heavy I/O workloads, leading to very poor performance. Performance can be easily compared by downgrading to FreeBSD 7.0. I have committed a fix for this problem for FreeBSD 8-CURRENT as of SVN revision 188570. FreeBSD 7-STABLE will be updated with the fix in a few days once I've gotten confirmation that the fix works and doesn't cause any adverse side-effects. Anyone wanting to help in this validation effort should apply the attached patch to their kernel source tree and recompile. Please contact me directly by email to report if the problem is fixed for you. If the validation process goes smoothly, I will work with the release engineering team to turn this fix into an official errata update for FreeBSD 7.1. Thanks in advance for your help. Scott --------------090508060706040908050304 Content-Type: text/x-diff; name="cam_tags.diff" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="cam_tags.diff" Index: cam_xpt.c =================================================================== --- cam_xpt.c (revision 188569) +++ cam_xpt.c (revision 188570) @@ -6143,10 +6143,9 @@ xpt_schedule(periph, priority); return; } - xpt_release_ccb(done_ccb); - softc->action = PROBE_TUR_FOR_NEGOTIATION; - xpt_schedule(periph, priority); - return; + + csio->data_ptr = NULL; + /* FALLTHROUGH */ } case PROBE_SERIAL_NUM_1: --------------090508060706040908050304-- From owner-freebsd-stable@FreeBSD.ORG Fri Feb 13 11:37:03 2009 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 6D592106564A for ; Fri, 13 Feb 2009 11:37:03 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.225]) by mx1.freebsd.org (Postfix) with ESMTP id 33CFA8FC19 for ; Fri, 13 Feb 2009 11:37:02 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: by rv-out-0506.google.com with SMTP id f6so706904rvb.43 for ; Fri, 13 Feb 2009 03:37:02 -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=VyPQhsyH/SYXXGztx1e/ILpnCWPwgt/kfxB13KVPtzw=; b=qWbwGlVMVwNnojT5d0vGHZTBLY1FTyU4aU396KOm2lESEdvdX2/0QrXcKZR1dLUcIK bhjXRQSu1GUqkyJBHkakYa/dvYJ4YaPNqBm6VYE4I5aRIwvQaRJ5OIxBSnvWvxPCJ4Jz QD6lBlzM13EN+1KTPJ6QzD2MEfQboaHMUQxDg= 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=THqNl1fDVrxIO9oZrZgMPRor5q7nYbdJSMNVLvA8ExoQfE1HVdx8ZriUo+ko8tF0bM Hwx+okTZjB8SKKnTL+xKaSasYOpEkY+R37ZEKf+OR0/HerSV4ctu08K912GFyDrTBzcN G9vw+xWbp/wRHMl/ULRPRitb1JAglR0FLmtlg= Received: by 10.141.153.16 with SMTP id f16mr1097877rvo.272.1234525022742; Fri, 13 Feb 2009 03:37:02 -0800 (PST) Received: from michelle.cdnetworks.co.kr ([114.111.62.249]) by mx.google.com with ESMTPS id k37sm1254428rvb.1.2009.02.13.03.37.00 (version=SSLv3 cipher=RC4-MD5); Fri, 13 Feb 2009 03:37:01 -0800 (PST) Received: by michelle.cdnetworks.co.kr (sSMTP sendmail emulation); Fri, 13 Feb 2009 20:39:55 +0900 From: Pyun YongHyeon Date: Fri, 13 Feb 2009 20:39:55 +0900 To: Gerrit K?hn Message-ID: <20090213113955.GE12653@michelle.cdnetworks.co.kr> References: <20090204100507.5f223d9e.gerrit@pmp.uni-hannover.de> <20090204104655.GA73543@michelle.cdnetworks.co.kr> <20090205085812.b2deb1f7.gerrit@pmp.uni-hannover.de> <20090205082804.GD77461@michelle.cdnetworks.co.kr> <20090213101910.a126c14d.gerrit@pmp.uni-hannover.de> <20090213102400.GD12653@michelle.cdnetworks.co.kr> <20090213114143.a77f1acb.gerrit@pmp.uni-hannover.de> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="fUYQa+Pmc3FrFX/N" Content-Disposition: inline In-Reply-To: <20090213114143.a77f1acb.gerrit@pmp.uni-hannover.de> User-Agent: Mutt/1.4.2.3i Cc: stable@freebsd.org Subject: Re: fun with if_re 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: Fri, 13 Feb 2009 11:37:03 -0000 --fUYQa+Pmc3FrFX/N Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Fri, Feb 13, 2009 at 11:41:43AM +0100, Gerrit K?hn wrote: > On Fri, 13 Feb 2009 19:24:00 +0900 Pyun YongHyeon wrote > about Re: fun with if_re: > > PY> > I had to reboot some of the machines meanwhile and could do some > PY> > further testing. One strange thing I noticed is that the > PY> > re-interfaces often do not come up in a working state after > PY> > rebooting. Strangely, I see network traffic floating around via > PY> > tcpdump, but not even ping works. This state often goes away when > PY> > playing around with the interface (sometimes ifconfig down/up helps, > PY> > sometimes disabling some of the additional features like txc/rxc), > PY> > but I cannot make out a reproducible behaviour so far. When the > PY> > interface leaves this strange state it seems to work fine > PY> > afterwards. Any clues? > > PY> Does this happen on latest if_re.c/if_rlreg.h? I guess jkim fixed > PY> this type of problem in r187483. If that have no effect please let > PY> me know. > > It happens on both versions: the old one from 11th Dec 08 I still had, and > the new one I built with the patches you recommended about a week ago. > if_re is 1.151 2009/01/20 20:22:28 jkim, if_rlreg is 1.94 2009/01/20 > 20:22:28 jkim for the latter. > Ok, try attached patch. --fUYQa+Pmc3FrFX/N Content-Type: text/x-diff; charset=us-ascii Content-Disposition: attachment; filename="re.8169sc.diff" Index: sys/dev/re/if_re.c =================================================================== --- sys/dev/re/if_re.c (revision 187352) +++ sys/dev/re/if_re.c (working copy) @@ -158,6 +158,8 @@ /* Tunables. */ static int msi_disable = 1; TUNABLE_INT("hw.re.msi_disable", &msi_disable); +static int prefer_iomap = 0; +TUNABLE_INT("hw.re.prefer_iomap", &prefer_iomap); #define RE_CSUM_FEATURES (CSUM_IP | CSUM_TCP | CSUM_UDP) @@ -1131,26 +1133,36 @@ pci_enable_busmaster(dev); devid = pci_get_device(dev); - /* Prefer memory space register mapping over IO space. */ - sc->rl_res_id = PCIR_BAR(1); - sc->rl_res_type = SYS_RES_MEMORY; - /* RTL8168/8101E seems to use different BARs. */ - if (devid == RT_DEVICEID_8168 || devid == RT_DEVICEID_8101E) - sc->rl_res_id = PCIR_BAR(2); + /* + * Prefer memory space register mapping over IO space. + * Because RTL8169SC does not seem to work when memory mapping + * is used always activate io mapping. + */ + if (devid == RT_DEVICEID_8169SC) + prefer_iomap = 1; + if (prefer_iomap == 0) { + sc->rl_res_id = PCIR_BAR(1); + sc->rl_res_type = SYS_RES_MEMORY; + /* RTL8168/8101E seems to use different BARs. */ + if (devid == RT_DEVICEID_8168 || devid == RT_DEVICEID_8101E) + sc->rl_res_id = PCIR_BAR(2); + } else { + sc->rl_res_id = PCIR_BAR(0); + sc->rl_res_type = SYS_RES_IOPORT; + } sc->rl_res = bus_alloc_resource_any(dev, sc->rl_res_type, &sc->rl_res_id, RF_ACTIVE); - - if (sc->rl_res == NULL) { + if (sc->rl_res == NULL && prefer_iomap == 0) { sc->rl_res_id = PCIR_BAR(0); sc->rl_res_type = SYS_RES_IOPORT; sc->rl_res = bus_alloc_resource_any(dev, sc->rl_res_type, &sc->rl_res_id, RF_ACTIVE); - if (sc->rl_res == NULL) { - device_printf(dev, "couldn't map ports/memory\n"); - error = ENXIO; - goto fail; - } } + if (sc->rl_res == NULL) { + device_printf(dev, "couldn't map ports/memory\n"); + error = ENXIO; + goto fail; + } sc->rl_btag = rman_get_bustag(sc->rl_res); sc->rl_bhandle = rman_get_bushandle(sc->rl_res); --fUYQa+Pmc3FrFX/N-- From owner-freebsd-stable@FreeBSD.ORG Fri Feb 13 11:42:27 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5529B1065677 for ; Fri, 13 Feb 2009 11:42:27 +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 1A7B78FC1C for ; Fri, 13 Feb 2009 11:42:27 +0000 (UTC) (envelope-from petefrench@ticketswitch.com) 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 1LXwR4-000PxG-7Z; Fri, 13 Feb 2009 11:42:22 +0000 Received: from petefrench by dilbert.ticketswitch.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1LXwR4-000Fn6-5I; Fri, 13 Feb 2009 11:42:22 +0000 To: cswiger@mac.com, karl@denninger.net In-Reply-To: Message-Id: From: Pete French Date: Fri, 13 Feb 2009 11:42:22 +0000 Cc: freebsd-stable@freebsd.org Subject: Re: Upgrade from 32-bit to AMD-64? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Feb 2009 11:42:27 -0000 > Sure, it's possible, given sufficient toolchain knowledge, time, and > skills, but it's not a sensible thing to do aside from experimentation > and learning purposes. Theres an intermediate method between upgrading in place and doing a full re-install which si what I used when I did this. 1) Install amd64 onto a completely separate bootable drive (USB will do). On that one do a 'make buildworld', 'make buildkernel'. 2) Take down the machine you mant to upgrade - boot it off the USB drive. When booted off the USb drive mount the orignal '/' somewhere. 3) Do a 'make installkernel' and 'make installworld' with DESTDIR=/oldslah to install the 64 bit OS onto the old drive. I also rewrote the boot sectors on the old slash drive too. 4) Reboot - it should come up amd64 with the old config fine. I have done this a couple of time to convert from 32 to 64 bit installs. The beauty is that it preserves the config. I would note, however, that in my case I did de-install all the packages and re-installed them afterwards, so I was then running full 64 bit. but it works, and the machine is only down for a few minutes. -pete. From owner-freebsd-stable@FreeBSD.ORG Fri Feb 13 13:13:00 2009 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 8D5841065678 for ; Fri, 13 Feb 2009 13:13:00 +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 EFA578FC19 for ; Fri, 13 Feb 2009 13:12:59 +0000 (UTC) (envelope-from gerrit@pmp.uni-hannover.de) 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 n1DDCvk2023274; Fri, 13 Feb 2009 14:12:58 +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 E65E34F; Fri, 13 Feb 2009 14:12:56 +0100 (CET) Date: Fri, 13 Feb 2009 14:12:56 +0100 From: Gerrit =?ISO-8859-1?Q?K=FChn?= To: pyunyh@gmail.com Message-Id: <20090213141256.b06aa86b.gerrit@pmp.uni-hannover.de> In-Reply-To: <20090213113955.GE12653@michelle.cdnetworks.co.kr> References: <20090204100507.5f223d9e.gerrit@pmp.uni-hannover.de> <20090204104655.GA73543@michelle.cdnetworks.co.kr> <20090205085812.b2deb1f7.gerrit@pmp.uni-hannover.de> <20090205082804.GD77461@michelle.cdnetworks.co.kr> <20090213101910.a126c14d.gerrit@pmp.uni-hannover.de> <20090213102400.GD12653@michelle.cdnetworks.co.kr> <20090213114143.a77f1acb.gerrit@pmp.uni-hannover.de> <20090213113955.GE12653@michelle.cdnetworks.co.kr> 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.8 (GTK+ 2.12.11; i386-portbld-freebsd7.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-PMX-Version: 5.5.2.363555, Antispam-Engine: 2.6.1.350677, Antispam-Data: 2009.2.13.125824 Cc: stable@freebsd.org Subject: Re: fun with if_re X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Feb 2009 13:13:00 -0000 On Fri, 13 Feb 2009 20:39:55 +0900 Pyun YongHyeon wrote about Re: fun with if_re: PY> Ok, try attached patch. Thanks, building new images right now. I'll be back later (next week). cu Gerrit From owner-freebsd-stable@FreeBSD.ORG Fri Feb 13 13:21:21 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 50B541065731 for ; Fri, 13 Feb 2009 13:21:21 +0000 (UTC) (envelope-from tevans.uk@googlemail.com) Received: from mail-fx0-f16.google.com (mail-fx0-f16.google.com [209.85.220.16]) by mx1.freebsd.org (Postfix) with ESMTP id A886F8FC18 for ; Fri, 13 Feb 2009 13:21:20 +0000 (UTC) (envelope-from tevans.uk@googlemail.com) Received: by fxm9 with SMTP id 9so1003825fxm.19 for ; Fri, 13 Feb 2009 05:21:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:received:received:subject:from:to:cc :in-reply-to:references:content-type:date:message-id:mime-version :x-mailer:content-transfer-encoding; bh=gVaSfB84FUsNfl0aFkNuJrck+Ed8UgXzWeuvtEjQDfI=; b=TwRHRUpSAgKey8Cs7HN6K3089pb7+qwjaPvMuLAKZZt6ACWp4g/dHkZRZ8npYsMkJc lviN7MOWrtrM8e57QIqimpWTDJ4PLMiH/qBvfkxConMsA2OOYRfl/M8VEmPZePr59xn3 +qY2z0xM+NTI1iGvxaE7sse6kCpU2SC4mGzfE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=subject:from:to:cc:in-reply-to:references:content-type:date :message-id:mime-version:x-mailer:content-transfer-encoding; b=CtctptUxML6jXO1MV/Vgwh7z2Hx2bSMH0tjjiCLxCjhll+8iTuyd31Xd/+ijGC9+Rl o8LEgQ8wbQJLhxa0KbrGwmfS1KpXoydRMD2+Vf8X14CXCCMFXwgPZcL1wIWrGG5IXX7F 1q3ZE2oaseofoJjRh5qtQ96ItPG20z7omUc2w= Received: by 10.223.110.3 with SMTP id l3mr989313fap.49.1234531094250; Fri, 13 Feb 2009 05:18:14 -0800 (PST) Received: from ?192.168.1.66? (87-194-39-182.bethere.co.uk [87.194.39.182]) by mx.google.com with ESMTPS id i39sm23550195ugd.32.2009.02.13.05.18.13 (version=SSLv3 cipher=RC4-MD5); Fri, 13 Feb 2009 05:18:13 -0800 (PST) From: Tom Evans To: Scott Long In-Reply-To: <499551B9.7050805@samsco.org> References: <499551B9.7050805@samsco.org> Content-Type: text/plain Date: Fri, 13 Feb 2009 13:18:05 +0000 Message-Id: <1234531085.2998.42.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.24.3 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: FreeBSD Stable Subject: Re: HEADS UP: Major CAM performance regression X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Feb 2009 13:21:21 -0000 On Fri, 2009-02-13 at 03:55 -0700, Scott Long wrote: > All, > > A major performance regression was introduced to the CAM subsystem in > FreeBSD 7.1. The following configurations are known to be affected: > > VMWare ESX > VMWare Fusion > (using bt or lsilogic controller options) > HP CISS RAID > Some MPT-SAS combinations with SATA drives attached > (Includes Dell SAS5/ir, but not PERC5/PERC6). > > Pure SCSI and SAS subsystems likely are NOT affected. Any hardware > that uses the 'ata' driver is also definitely NOT affected. To > determine if your installation is affected, run the following command as > root: > > camcontrol tags da0 > > Substitute 'da0' with another appropriate drive device number, if > needed. Note that this ONLY AFFECTS 'da' DEVICES. If your disks are > 'ad' devices, they are NOT affected. > > The result from running this command should be an output similar to the > following: > > (pass0:mpt0:0:8:0): device openings: 255 > > If, instead, it reports a value of '1', you are likely affected. Note > that it may be normal for USB memory devices to report a low number. > Also, many legacy SCSI disks, and devices that are not disks, may also > be expected to report a low number. > > The effect of this problem is that only one I/O command will be issued > to the controller and disk at a time, instead of overlapping multiple > commands in parallel. This causes significantly higher latency in > servicing moderate and heavy I/O workloads, leading to very poor > performance. Performance can be easily compared by downgrading to > FreeBSD 7.0. > > I have committed a fix for this problem for FreeBSD 8-CURRENT as of SVN > revision 188570. FreeBSD 7-STABLE will be updated with the fix in a few > days once I've gotten confirmation that the fix works and doesn't cause > any adverse side-effects. Anyone wanting to help in this validation > effort should apply the attached patch to their kernel source tree and > recompile. Please contact me directly by email to report if the problem > is fixed for you. > > If the validation process goes smoothly, I will work with the release > engineering team to turn this fix into an official errata update for > FreeBSD 7.1. > > Thanks in advance for your help. > > Scott > Hi Scott I have one da0 device, a USB attached hard disk: umass0: on uhub6 da0 at umass-sim0 bus 0 target 0 lun 0 da0: Fixed Direct Access SCSI-2 device da0: 40.000MB/s transfers da0: 238475MB (488397168 512 byte sectors: 255H 63S/T 30401C) camcontrol shows: > $ sudo camcontrol tags da0 (pass0:umass-sim0:0:0:0): device openings: 1 Is that to be expected? This is RELENG_7 from October '08: FreeBSD strangepork.mintel.co.uk 7.1-PRERELEASE FreeBSD 7.1-PRERELEASE #0: Wed Oct 22 02:25:56 BST 2008 root@sweetpork.pc.mintel.co.uk:/usr/FreeBSD/RELENG_7/obj/usr/FreeBSD/RELENG_7/src/sys/STRANGEPORK i386 Thanks Tom From owner-freebsd-stable@FreeBSD.ORG Fri Feb 13 13:26:32 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BAAD810656BD for ; Fri, 13 Feb 2009 13:26:32 +0000 (UTC) (envelope-from ghelmer@palisadesys.com) Received: from cetus.palisadesys.com (cetus.palisadesys.com [205.237.115.21]) by mx1.freebsd.org (Postfix) with ESMTP id 7C5888FC22 for ; Fri, 13 Feb 2009 13:26:32 +0000 (UTC) (envelope-from ghelmer@palisadesys.com) Received: from cancer.palisadesys.com (serverwatch [172.16.1.98]) by cetus.palisadesys.com (8.14.3/8.14.3) with ESMTP id n1DDQVMT070925 for ; Fri, 13 Feb 2009 07:26:31 -0600 (CST) (envelope-from ghelmer@palisadesys.com) Received: from [172.16.2.242] (cetus.palisadesys.com [205.237.115.21]) (authenticated bits=0) by cancer.palisadesys.com (8.14.2/8.14.2) with ESMTP id n1DDQVcd026584 for ; Fri, 13 Feb 2009 07:26:32 -0600 (CST) (envelope-from ghelmer@palisadesys.com) Message-ID: <49957505.7090405@palisadesys.com> Date: Fri, 13 Feb 2009 07:26:29 -0600 From: Guy Helmer User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: freebsd-stable@freebsd.org References: <49676406.9050902@palisadesys.com> <49946769.1040009@palisadesys.com> In-Reply-To: <49946769.1040009@palisadesys.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-3.0 (cancer.palisadesys.com [205.237.115.20]); Fri, 13 Feb 2009 07:26:32 -0600 (CST) X-Palisade-MailScanner-Information: Please contact the ISP for more information X-Palisade-MailScanner: Found to be clean X-Palisade-MailScanner-SpamCheck: not spam (whitelisted), SpamAssassin (not cached, score=-4.399, required 6, autolearn=not spam, ALL_TRUSTED -1.80, BAYES_00 -2.60) X-Palisade-MailScanner-From: ghelmer@palisadesys.com Subject: Re: Big problems with 7.1 locking up :-( X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Feb 2009 13:26:33 -0000 Guy Helmer wrote: > FWIW, I think I have tracked down the changes just prior to > 7.1-RELEASE that is causing my Supermicro dual Xeon machines to > wedge. I did the binary search between 2008-10-02 and 2008-11-24 > without reproducing any lockups, and then I went on to search between > 2008-11-24 and 2009-01-04. An SMP kernel build from 2008-12-22 > (r186409) sources was stable for over two weeks; a kernel built from > 2008-12-29 (r186590) sources wedged in under 24 hours under moderate > load. > > It appears that the significant changes between r186409 and r186590 > were r186552 (delphij - reverted ATA changes) and r186535/r186534 > (delphij - reverted bce changes). My machines don't have bce > interfaces, so I suspect the ATA changes. > Never mind. I'm stepping back through older kernels and finding that the hangs are now occurring in kernels that had seemed to be stable... Guy From owner-freebsd-stable@FreeBSD.ORG Fri Feb 13 14:43:36 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1E3701065672; Fri, 13 Feb 2009 14:43:36 +0000 (UTC) (envelope-from patfbsd@davenulle.org) Received: from smtp.lamaiziere.net (net.lamaiziere.net [91.121.44.19]) by mx1.freebsd.org (Postfix) with ESMTP id D53088FC17; Fri, 13 Feb 2009 14:43:35 +0000 (UTC) (envelope-from patfbsd@davenulle.org) Received: from baby-jane.lamaiziere.net (81-65-128-47.rev.numericable.fr [81.65.128.47]) by smtp.lamaiziere.net (Postfix) with ESMTPA id 02654633301; Fri, 13 Feb 2009 15:43:34 +0100 (CET) Received: from baby-jane.lamaiziere.net (localhost [127.0.0.1]) by baby-jane.lamaiziere.net (Postfix) with ESMTP id 282B8C3A6; Fri, 13 Feb 2009 15:43:34 +0100 (CET) Date: Fri, 13 Feb 2009 15:43:33 +0100 From: Patrick =?ISO-8859-15?Q?Lamaizi=E8re?= To: Lars Engels Message-ID: <20090213154333.18f0bf13@baby-jane.lamaiziere.net> In-Reply-To: <20090212213443.GM30761@e.0x20.net> References: <20090210134421.350f40b8@baby-jane.lamaiziere.net> <20090212213443.GM30761@e.0x20.net> Organization: /dave/nulle X-Mailer: Claws Mail 3.7.0 (GTK+ 2.14.7; i386-portbld-freebsd7.1) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org Subject: Re: Backport of glxsb(4) to RELENG_6 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Feb 2009 14:43:36 -0000 Le Thu, 12 Feb 2009 22:34:43 +0100, Lars Engels : Hi, > I just tried it, but I get this message: > glxsb0: mem > 0xefff4000-0xefff7fff irq 9 at device 1.2 on pci0 > glxsb0: cannot allocate DMA memory of 32768 bytes (12) I think you are very low on memory and the driver cannot allocate his DMA-able buffer (error 12=ENOMEM) This is not really a bug. But i've found another problem related to the taskqueue. I'm doing a fake driver to be able to test on a vmware machine. From owner-freebsd-stable@FreeBSD.ORG Fri Feb 13 15:40:10 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D779010656CE for ; Fri, 13 Feb 2009 15:40:10 +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 959628FC21 for ; Fri, 13 Feb 2009 15:40:10 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from server.baldwin.cx (pool-98-109-39-197.nwrknj.fios.verizon.net [98.109.39.197]) by cyrus.watson.org (Postfix) with ESMTPSA id 3DAEF46B5C; Fri, 13 Feb 2009 10:40:10 -0500 (EST) Received: from localhost (john@localhost [127.0.0.1]) (authenticated bits=0) by server.baldwin.cx (8.14.3/8.14.3) with ESMTP id n1DFd49P044500; Fri, 13 Feb 2009 10:40:04 -0500 (EST) (envelope-from jhb@freebsd.org) From: John Baldwin To: freebsd-stable@freebsd.org Date: Fri, 13 Feb 2009 10:18:37 -0500 User-Agent: KMail/1.9.7 References: In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200902131018.37940.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (server.baldwin.cx [127.0.0.1]); Fri, 13 Feb 2009 10:40:04 -0500 (EST) X-Virus-Scanned: ClamAV 0.94.2/8987/Fri Feb 13 05:32:33 2009 on server.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-4.4 required=4.2 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.1.3 X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on server.baldwin.cx Cc: Charles Sprickman Subject: Re: 7.1 Panic on degraded disk w/mpt X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Feb 2009 15:40:11 -0000 On Monday 09 February 2009 1:13:08 am Charles Sprickman wrote: > Howdy, > > I dug around and can't find a PR on this, and the only other report I saw > was in this mailing list post that has no replies: > > http://www.nabble.com/7.1-BETA2-panic-on-mpt-degrade-td20183173.html > > The hardware is a Dell PowerEdge 860 with the Dell/LSI SAS5 controller: > mpt0: port 0xec00-0xecff mem > 0xfe9fc000-0xfe9fffff,0xfe9e0000-0xfe9effff irq 16 at device 8.0 on pci2 > mpt0: MPI Version=1.5.13.0 > > The panic is repeatable by forcing the array into a degraded state. > > Here's my best shot at getting info out of kgdb: > > [root@uniweb /home/spork]# cd /usr/obj/usr/src/sys/BWAY7/ > [root@uniweb /usr/obj/usr/src/sys/BWAY7]# kgdb kernel.debug > /var/crash/vmcore.0 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 "i386-marcel-freebsd"... > > Unread portion of the kernel message buffer: > > > Fatal trap 12: page fault while in kernel mode > cpuid = 0; apic id = 00 > fault virtual address = 0x14 > fault code = supervisor read, page not present > instruction pointer = 0x20:0xc044b09b > stack pointer = 0x28:0xe6ee5b80 > frame pointer = 0x28:0xe6ee5b9c > code segment = base 0x0, limit 0xfffff, type 0x1b > = DPL 0, pres 1, def32 1, gran 1 > processor eflags = interrupt enabled, resume, IOPL = 0 > current process = 17 (swi2: cambio) > trap number = 12 > panic: page fault > cpuid = 0 > Uptime: 3m7s > Physical memory: 3575 MB > Dumping 94 MB: 79 63 47 31 15 > > Reading symbols from /boot/kernel/acpi.ko...Reading symbols from > /boot/kernel/acpi.ko.symbols...done. > done. > Loaded symbols for /boot/kernel/acpi.ko > #0 doadump () at pcpu.h:196 > 196 __asm __volatile("movl %%fs:0,%0" : "=r" (td)); > (kgdb) list *0xc044b09b > 0xc044b09b is in xpt_done (/usr/src/sys/cam/cam_xpt.c:4832). > 4827 if ((done_ccb->ccb_h.func_code & XPT_FC_QUEUED) != 0) { > 4828 /* > 4829 * Queue up the request for handling by our SWI handler > 4830 * any of the "non-immediate" type of ccbs. > 4831 */ > 4832 sim = done_ccb->ccb_h.path->bus->sim; > 4833 switch (done_ccb->ccb_h.path->periph->type) { > 4834 case CAM_PERIPH_BIO: > 4835 TAILQ_INSERT_TAIL(&sim->sim_doneq, &done_ccb->ccb_h, > 4836 sim_links.tqe); Can you 'p done_ccb->ccb_h.path' and if that is not 0, 'p done_ccb->ccb_h.path.bus'? -- John Baldwin From owner-freebsd-stable@FreeBSD.ORG Fri Feb 13 17:48:56 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 70DF1106564A for ; Fri, 13 Feb 2009 17:48:56 +0000 (UTC) (envelope-from ross.penner@gmail.com) Received: from mail-gx0-f224.google.com (mail-gx0-f224.google.com [209.85.217.224]) by mx1.freebsd.org (Postfix) with ESMTP id 2E2498FC1C for ; Fri, 13 Feb 2009 17:48:55 +0000 (UTC) (envelope-from ross.penner@gmail.com) Received: by gxk24 with SMTP id 24so1085501gxk.19 for ; Fri, 13 Feb 2009 09:48:55 -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=HHogHMrLJqXa6XW8LTTBvQ67hPfk5f6qIkH0Lh1R5A0=; b=J70uXklYXb8sVSP400jxW8asWnGaIRvtOy2YkyATj0ZzK4sHCYLcFkls16ExmRX64w ZtunDsFVXOeinDLSLLDlx7N9hz7v0UvNBntCg8aVNUIKrmmrmQxeT53JpG4JEmQOxScL 12O/V6/nu2hASwYNfrauHLq0QF/AcK+vLIQjk= 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=qix+XeQisZZmO9QwyprMoCTBDVReVNEFo7RuKx0fBW1zSoIWl3roJYukCBpck54MST DIplgKqWsYmck7jCeQfMVeSxREZirfVHh6wKpvuFVhTAlss72YoCpgxSHAGbAvIc6EmZ u0jcKvrvhKaarO1cWsxlCLFxeJZRQoJEAJ4S4= MIME-Version: 1.0 Received: by 10.90.53.5 with SMTP id b5mr1022676aga.91.1234547335537; Fri, 13 Feb 2009 09:48:55 -0800 (PST) In-Reply-To: <53a1e0710902122229l606bb2c9pcc71ea38fafa1193@mail.gmail.com> References: <53a1e0710902122229l606bb2c9pcc71ea38fafa1193@mail.gmail.com> Date: Fri, 13 Feb 2009 09:48:55 -0800 Message-ID: From: Ross Penner To: hu.henry9@gmail.com Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org Subject: Re: pkg_delete segfaulting after upgrading to 7.1 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Feb 2009 17:48:56 -0000 On Thu, Feb 12, 2009 at 10:29 PM, Henry Hu wrote: >> rosbox# pkg_delete -f gpgme-1.1.5_1 >> pkg_delete: package 'gpgme-1.1.5_1' is required by these other packages >> and may not be deinstalled (but I'll delete it anyway): >> seahorse-2.24.1_1 >> Segmentation fault (core dumped) > > I've had similar problem, and found the problem is in the +CONTENTS in > the corresponding folder under /var/db/pkg/ . > It's caused by an empty @pkgdep line here. > I don't know what went wrong when the +CONTENTS file was created. But > delete all these empty @pkgdep lines solved my problem. > > Cheers, > Henry Worked for me too! Thanks a lot, I never would have thought to have tried that. From owner-freebsd-stable@FreeBSD.ORG Fri Feb 13 20:05:24 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 58314106566B; Fri, 13 Feb 2009 20:05:24 +0000 (UTC) (envelope-from patfbsd@davenulle.org) Received: from smtp.lamaiziere.net (net.lamaiziere.net [91.121.44.19]) by mx1.freebsd.org (Postfix) with ESMTP id 18E148FC0C; Fri, 13 Feb 2009 20:05:23 +0000 (UTC) (envelope-from patfbsd@davenulle.org) Received: from baby-jane.lamaiziere.net (81-65-128-47.rev.numericable.fr [81.65.128.47]) by smtp.lamaiziere.net (Postfix) with ESMTPA id 09EC5633301; Fri, 13 Feb 2009 21:05:23 +0100 (CET) Received: from baby-jane.lamaiziere.net (localhost [127.0.0.1]) by baby-jane.lamaiziere.net (Postfix) with ESMTP id 056D6C3C0; Fri, 13 Feb 2009 21:05:21 +0100 (CET) Date: Fri, 13 Feb 2009 21:05:16 +0100 From: Patrick =?ISO-8859-15?Q?Lamaizi=E8re?= To: freebsd-stable@freebsd.org Message-ID: <20090213210516.3667403a@baby-jane.lamaiziere.net> In-Reply-To: <20090213154333.18f0bf13@baby-jane.lamaiziere.net> References: <20090210134421.350f40b8@baby-jane.lamaiziere.net> <20090212213443.GM30761@e.0x20.net> <20090213154333.18f0bf13@baby-jane.lamaiziere.net> Organization: /dave/nulle X-Mailer: Claws Mail 3.7.0 (GTK+ 2.14.7; i386-portbld-freebsd7.1) Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 8bit Cc: Lars Engels Subject: Re: Backport of glxsb(4) to RELENG_6 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Feb 2009 20:05:24 -0000 Le Fri, 13 Feb 2009 15:43:33 +0100, Patrick Lamaizire : > Le Thu, 12 Feb 2009 22:34:43 +0100, > Lars Engels : > > Hi, > > > I just tried it, but I get this message: > > glxsb0: mem > > 0xefff4000-0xefff7fff irq 9 at device 1.2 on pci0 > > > glxsb0: cannot allocate DMA memory of 32768 bytes (12) > > I think you are very low on memory and the driver cannot allocate his > DMA-able buffer (error 12=ENOMEM) > > This is not really a bug. To Lars: Yes it should work at bootime. You must also load the module cryptodev.ko to use it with openssl. > But i've found another problem related to > the taskqueue. > > I'm doing a fake driver to be able to test on a vmware machine. I've tested most of the driver and I think (hope) this is ok. http://user.lamaiziere.net/patrick/glxsb-6-130209.tar.gz Let me know how it works. Regards. From owner-freebsd-stable@FreeBSD.ORG Fri Feb 13 20:32:59 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E1AE1106564A for ; Fri, 13 Feb 2009 20:32:59 +0000 (UTC) (envelope-from patfbsd@davenulle.org) Received: from smtp.lamaiziere.net (net.lamaiziere.net [91.121.44.19]) by mx1.freebsd.org (Postfix) with ESMTP id A5B868FC12 for ; Fri, 13 Feb 2009 20:32:59 +0000 (UTC) (envelope-from patfbsd@davenulle.org) Received: from baby-jane.lamaiziere.net (81-65-128-47.rev.numericable.fr [81.65.128.47]) by smtp.lamaiziere.net (Postfix) with ESMTPA id CE55E633301 for ; Fri, 13 Feb 2009 21:32:58 +0100 (CET) Received: from baby-jane.lamaiziere.net (localhost [127.0.0.1]) by baby-jane.lamaiziere.net (Postfix) with ESMTP id DA547BCD1 for ; Fri, 13 Feb 2009 21:32:57 +0100 (CET) Date: Fri, 13 Feb 2009 21:32:57 +0100 From: Patrick =?ISO-8859-15?Q?Lamaizi=E8re?= To: freebsd-stable@freebsd.org Message-ID: <20090213213257.52a11130@baby-jane.lamaiziere.net> Organization: /dave/nulle X-Mailer: Claws Mail 3.7.0 (GTK+ 2.14.7; i386-portbld-freebsd7.1) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: FreeBSD CVS problem ? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Feb 2009 20:33:00 -0000 Hi, I've just found that the files for glxsb(4) in RELENG_7 are older than in RELENG_7_1. I don't think this is normal? http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/dev/glxsb/glxsb.c?only_with_tag=RELENG_7 http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/dev/glxsb/glxsb.c?only_with_tag=RELENG_7_1 RELENG_7_1 contains changes made by philip@ in SVN rev 185021 RELENG_7 contains an older version SVN rev 181919 on 2008-08-20 11:33:13Z by philip If you know how solve this, thanks. Regards. From owner-freebsd-stable@FreeBSD.ORG Fri Feb 13 20:43:28 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CE250106564A for ; Fri, 13 Feb 2009 20:43:28 +0000 (UTC) (envelope-from scottl@samsco.org) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.freebsd.org (Postfix) with ESMTP id 7BB258FC0C for ; Fri, 13 Feb 2009 20:43:28 +0000 (UTC) (envelope-from scottl@samsco.org) Received: from phobos.local (71-218-27-233.hlrn.qwest.net [71.218.27.233]) (authenticated bits=0) by pooker.samsco.org (8.14.2/8.14.2) with ESMTP id n1DKhIAW074493; Fri, 13 Feb 2009 13:43:23 -0700 (MST) (envelope-from scottl@samsco.org) Message-ID: <4995DB65.5020200@samsco.org> Date: Fri, 13 Feb 2009 13:43:17 -0700 From: Scott Long User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:1.8.1.13) Gecko/20080313 SeaMonkey/1.1.9 MIME-Version: 1.0 To: Tom Evans References: <499551B9.7050805@samsco.org> <1234531085.2998.42.camel@localhost> In-Reply-To: <1234531085.2998.42.camel@localhost> X-Enigmail-Version: 0.95.6 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-2.6 required=3.8 tests=BAYES_00,RCVD_IN_PBL autolearn=ham version=3.1.8 X-Spam-Checker-Version: SpamAssassin 3.1.8 (2007-02-13) on pooker.samsco.org Cc: FreeBSD Stable Subject: Re: HEADS UP: Major CAM performance regression X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Feb 2009 20:43:29 -0000 Tom Evans wrote: > On Fri, 2009-02-13 at 03:55 -0700, Scott Long wrote: >> All, >> >> A major performance regression was introduced to the CAM subsystem in >> FreeBSD 7.1. The following configurations are known to be affected: >> >> VMWare ESX >> VMWare Fusion >> (using bt or lsilogic controller options) >> HP CISS RAID >> Some MPT-SAS combinations with SATA drives attached >> (Includes Dell SAS5/ir, but not PERC5/PERC6). >> >> Pure SCSI and SAS subsystems likely are NOT affected. Any hardware >> that uses the 'ata' driver is also definitely NOT affected. To >> determine if your installation is affected, run the following command as >> root: >> >> camcontrol tags da0 >> >> Substitute 'da0' with another appropriate drive device number, if >> needed. Note that this ONLY AFFECTS 'da' DEVICES. If your disks are >> 'ad' devices, they are NOT affected. >> >> The result from running this command should be an output similar to the >> following: >> >> (pass0:mpt0:0:8:0): device openings: 255 >> >> If, instead, it reports a value of '1', you are likely affected. Note >> that it may be normal for USB memory devices to report a low number. >> Also, many legacy SCSI disks, and devices that are not disks, may also >> be expected to report a low number. >> >> The effect of this problem is that only one I/O command will be issued >> to the controller and disk at a time, instead of overlapping multiple >> commands in parallel. This causes significantly higher latency in >> servicing moderate and heavy I/O workloads, leading to very poor >> performance. Performance can be easily compared by downgrading to >> FreeBSD 7.0. >> >> I have committed a fix for this problem for FreeBSD 8-CURRENT as of SVN >> revision 188570. FreeBSD 7-STABLE will be updated with the fix in a few >> days once I've gotten confirmation that the fix works and doesn't cause >> any adverse side-effects. Anyone wanting to help in this validation >> effort should apply the attached patch to their kernel source tree and >> recompile. Please contact me directly by email to report if the problem >> is fixed for you. >> >> If the validation process goes smoothly, I will work with the release >> engineering team to turn this fix into an official errata update for >> FreeBSD 7.1. >> >> Thanks in advance for your help. >> >> Scott >> > > Hi Scott > > I have one da0 device, a USB attached hard disk: > > umass0: > on uhub6 > da0 at umass-sim0 bus 0 target 0 lun 0 > da0: Fixed Direct Access SCSI-2 device > da0: 40.000MB/s transfers > da0: 238475MB (488397168 512 byte sectors: 255H 63S/T 30401C) > > > camcontrol shows: > >> $ sudo camcontrol tags da0 > (pass0:umass-sim0:0:0:0): device openings: 1 > > Is that to be expected? This is RELENG_7 from October '08: > The date falls within the range. Have you tried the patch to see if it changes anything? Scott From owner-freebsd-stable@FreeBSD.ORG Fri Feb 13 21:02:50 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1DB00106564A; Fri, 13 Feb 2009 21:02:50 +0000 (UTC) (envelope-from scottl@samsco.org) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.freebsd.org (Postfix) with ESMTP id 271A98FC08; Fri, 13 Feb 2009 21:02:48 +0000 (UTC) (envelope-from scottl@samsco.org) Received: from phobos.local (71-218-27-233.hlrn.qwest.net [71.218.27.233]) (authenticated bits=0) by pooker.samsco.org (8.14.2/8.14.2) with ESMTP id n1DL2Urw074614; Fri, 13 Feb 2009 14:02:37 -0700 (MST) (envelope-from scottl@samsco.org) Message-ID: <4995DFE5.1020205@samsco.org> Date: Fri, 13 Feb 2009 14:02:29 -0700 From: Scott Long User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:1.8.1.13) Gecko/20080313 SeaMonkey/1.1.9 MIME-Version: 1.0 To: Ivan Voras References: <499551B9.7050805@samsco.org> In-Reply-To: X-Enigmail-Version: 0.95.6 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-2.9 required=3.8 tests=AWL,BAYES_00,RCVD_IN_PBL autolearn=ham version=3.1.8 X-Spam-Checker-Version: SpamAssassin 3.1.8 (2007-02-13) on pooker.samsco.org Cc: freebsd-current@freebsd.org, freebsd-stable@freebsd.org Subject: Re: HEADS UP: Major CAM performance regression X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Feb 2009 21:02:50 -0000 Ivan Voras wrote: > Scott Long wrote: > >> I have committed a fix for this problem for FreeBSD 8-CURRENT as of SVN >> revision 188570. FreeBSD 7-STABLE will be updated with the fix in a few >> days once I've gotten confirmation that the fix works and doesn't cause >> any adverse side-effects. Anyone wanting to help in this validation >> effort should apply the attached patch to their kernel source tree and >> recompile. Please contact me directly by email to report if the problem >> is fixed for you. > > I notice that write performance on an ESXi 3.5 hosted system is doubled, > but read performance remains the same (in bonnie++). > On a CISS system there is no significant change. > bonnie is an unreliable tool for measuring performance. Scott From owner-freebsd-stable@FreeBSD.ORG Fri Feb 13 22:20:29 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2DE8310656F9 for ; Fri, 13 Feb 2009 22:20:29 +0000 (UTC) (envelope-from delphij@delphij.net) Received: from tarsier.delphij.net (delphij-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:2c9::2]) by mx1.freebsd.org (Postfix) with ESMTP id C6EAA8FC15 for ; Fri, 13 Feb 2009 22:20:28 +0000 (UTC) (envelope-from delphij@delphij.net) Received: from tarsier.geekcn.org (tarsier.geekcn.org [211.166.10.233]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by tarsier.delphij.net (Postfix) with ESMTPS id AD60C28449 for ; Sat, 14 Feb 2009 06:20:27 +0800 (CST) Received: from localhost (tarsier.geekcn.org [211.166.10.233]) by tarsier.geekcn.org (Postfix) with ESMTP id 501E3EC73AD; Sat, 14 Feb 2009 06:20:27 +0800 (CST) X-Virus-Scanned: amavisd-new at geekcn.org Received: from tarsier.geekcn.org ([211.166.10.233]) by localhost (mail.geekcn.org [211.166.10.233]) (amavisd-new, port 10024) with ESMTP id eYBIVBxHlKNb; Sat, 14 Feb 2009 06:20:21 +0800 (CST) Received: from charlie.delphij.net (adsl-76-237-33-62.dsl.pltn13.sbcglobal.net [76.237.33.62]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by tarsier.geekcn.org (Postfix) with ESMTPSA id 0C1A3EC73C6; Sat, 14 Feb 2009 06:20:19 +0800 (CST) DomainKey-Signature: a=rsa-sha1; s=default; d=delphij.net; c=nofws; q=dns; h=message-id:date:from:reply-to:organization:user-agent: mime-version:to:cc:subject:references:in-reply-to: x-enigmail-version:openpgp:content-type:content-transfer-encoding; b=kWfon/JgL+ZlHDlI2ot5nRnJgo63+h1fCBkPEus4/2PFb3Im+fpt/wUgsjP3ejVif d/bdx5oeZmjFsFS+sK4xQ== Message-ID: <4995F221.7040801@delphij.net> Date: Fri, 13 Feb 2009 14:20:17 -0800 From: Xin LI Organization: The FreeBSD Project User-Agent: Thunderbird 2.0.0.19 (X11/20090202) MIME-Version: 1.0 To: =?ISO-8859-1?Q?Patrick_Lamaizi=E8re?= References: <20090213213257.52a11130@baby-jane.lamaiziere.net> In-Reply-To: <20090213213257.52a11130@baby-jane.lamaiziere.net> X-Enigmail-Version: 0.95.7 OpenPGP: id=18EDEBA0; url=http://www.delphij.net/delphij.asc Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Cc: freebsd-stable@freebsd.org Subject: Re: FreeBSD CVS problem ? 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: Fri, 13 Feb 2009 22:20:29 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Patrick Lamaizire wrote: > Hi, > > I've just found that the files for glxsb(4) in RELENG_7 are older than > in RELENG_7_1. I don't think this is normal? > > http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/dev/glxsb/glxsb.c?only_with_tag=RELENG_7 > > http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/dev/glxsb/glxsb.c?only_with_tag=RELENG_7_1 > > RELENG_7_1 contains changes made by philip@ in SVN rev 185021 > > RELENG_7 contains an older version SVN rev 181919 on 2008-08-20 > 11:33:13Z by philip > > If you know how solve this, thanks. > Regards. "older" is just meaningful on the same branch... This is normal. Cheers, - -- Xin LI http://www.delphij.net/ FreeBSD - The Power to Serve! -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.10 (FreeBSD) iEYEARECAAYFAkmV8iAACgkQi+vbBBjt66CDeACgrUSl37l5lBLqbJUFXvCD08nl aNkAoKcuzVLNcZWxwfVXuAjktN2gIee/ =wCfl -----END PGP SIGNATURE----- From owner-freebsd-stable@FreeBSD.ORG Fri Feb 13 22:48:01 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CDA3C106566B for ; Fri, 13 Feb 2009 22:48:01 +0000 (UTC) (envelope-from ivoras@gmail.com) Received: from mail-bw0-f170.google.com (mail-bw0-f170.google.com [209.85.218.170]) by mx1.freebsd.org (Postfix) with ESMTP id 2B6F08FC0C for ; Fri, 13 Feb 2009 22:48:00 +0000 (UTC) (envelope-from ivoras@gmail.com) Received: by bwz18 with SMTP id 18so2566275bwz.19 for ; Fri, 13 Feb 2009 14:48:00 -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:content-transfer-encoding; bh=YqNoW4LdO5HLSDAy73Qb78MGganIW2/OC0tjEdEL7/s=; b=tEsa9k5B6YQ9jQvty4r+xAsuwEhyX++JoubYfSAYBbf0Gc3K6GkBEDftd/sz/qvTVZ FTxZ80hQvKLP80tOe9UThc4ASFNvO/880jdSV2xuQ+OVEa/ebhAJ+ggXNEdi0eZtQhGc L1q2sgpTdbLe87ANR/jvPNUaHUf7uJqKh04j0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=J3xAp1fsDCY9GYkQWIZxLDBTBLe1spPlaNieg3sPJP9wz3FRhhv0D7Rzcj5F1mzhQZ PmrRdSLaUPjLMUagg8ICXIhHAkajil9LGdLKOST88NysujEqn1FfB96jjfjr8Mo+tj5S WUYE2Fvq2OD9MoJ4hJaCoXRc5VQSsn+2QuGqU= MIME-Version: 1.0 Sender: ivoras@gmail.com Received: by 10.181.206.7 with SMTP id i7mr878436bkq.57.1234563668962; Fri, 13 Feb 2009 14:21:08 -0800 (PST) In-Reply-To: <4995DFE5.1020205@samsco.org> References: <499551B9.7050805@samsco.org> <4995DFE5.1020205@samsco.org> Date: Fri, 13 Feb 2009 23:21:08 +0100 X-Google-Sender-Auth: 1492621c167cccb0 Message-ID: <9bbcef730902131421r53efa13dq371658888747f387@mail.gmail.com> From: Ivan Voras To: Scott Long Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org, freebsd-stable@freebsd.org Subject: Re: HEADS UP: Major CAM performance regression X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Feb 2009 22:48:02 -0000 2009/2/13 Scott Long : > Ivan Voras wrote: >> >> Scott Long wrote: >> >>> I have committed a fix for this problem for FreeBSD 8-CURRENT as of SVN >>> revision 188570. FreeBSD 7-STABLE will be updated with the fix in a few >>> days once I've gotten confirmation that the fix works and doesn't cause >>> any adverse side-effects. Anyone wanting to help in this validation >>> effort should apply the attached patch to their kernel source tree and >>> recompile. Please contact me directly by email to report if the problem >>> is fixed for you. >> >> I notice that write performance on an ESXi 3.5 hosted system is doubled, >> but read performance remains the same (in bonnie++). >> On a CISS system there is no significant change. > > bonnie is an unreliable tool for measuring performance. I'll try your suggestion if you have one. (except if it's about bonnie++ primarily measuring sequential read/write - if a system can't do sequential IO well, it probably won't do random IO well) From owner-freebsd-stable@FreeBSD.ORG Sat Feb 14 13:33:27 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AAE2D106564A; Sat, 14 Feb 2009 13:33:27 +0000 (UTC) (envelope-from rehsack@web.de) Received: from fmmailgate02.web.de (fmmailgate02.web.de [217.72.192.227]) by mx1.freebsd.org (Postfix) with ESMTP id 37E558FC1F; Sat, 14 Feb 2009 13:33:27 +0000 (UTC) (envelope-from rehsack@web.de) Received: from smtp05.web.de (fmsmtp05.dlan.cinetic.de [172.20.4.166]) by fmmailgate02.web.de (Postfix) with ESMTP id CA64FFA68D86; Sat, 14 Feb 2009 14:10:05 +0100 (CET) Received: from [87.149.224.150] (helo=waldorf.muppets.liwing.de) by smtp05.web.de with esmtp (TLSv1:AES256-SHA:256) (WEB.DE 4.110 #277) id 1LYKHV-0002tc-00; Sat, 14 Feb 2009 14:10:05 +0100 Message-ID: <4996C16D.8050909@web.de> Date: Sat, 14 Feb 2009 13:04:45 +0000 From: Jens Rehsack User-Agent: Thunderbird 2.0.0.19 (X11/20090114) MIME-Version: 1.0 To: John Baldwin X-Enigmail-Version: 0.95.7 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigA5DEDAE572FAE7669411584A" Sender: rehsack@web.de X-Sender: rehsack@web.de X-Provags-ID: V01U2FsdGVkX1/+cNVuH/HDdVn8CXIGmWGJ3ZJXPfQTg2fFhrWo Vh0PGcB+62yNm0nAq0xte7qofeljL0WrhCdaSk3i6hqsC9HN+r XUA21D2EA= Cc: freebsd-stable@freebsd.org Subject: Error compiling FreeBSD-Stable with MFC'ed iconv locking X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Feb 2009 13:33:28 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigA5DEDAE572FAE7669411584A Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi John, after I updated my system (-STABLE) I received following compilation erro= r while building the kernel (having ICONV built in): cc -c -O2 -frename-registers -pipe -fno-strict-aliasing -march=3Dnocona -std=3Dc99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototype= s -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/usr/src/sys -I/usr/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -inclu= de opt_global.h -fno-common -finline-limit=3D8000 --param inline-unit-growth= =3D100 --param large-function-growth=3D1000 -fno-omit-frame-pointer -mcmodel=3D= kernel -mno-red-zone -mfpmath=3D387 -mno-sse -mno-sse2 -mno-mmx -mno-3dnow -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -Werror /usr/src/sys/libkern/iconv.c /usr/src/sys/libkern/iconv.c: In function 'iconv_mod_unload': /usr/src/sys/libkern/iconv.c:92: error: 'curthread' undeclared (first use= in this function) /usr/src/sys/libkern/iconv.c:92: error: (Each undeclared identifier is reported only once /usr/src/sys/libkern/iconv.c:92: error: for each function it appears in.)= /usr/src/sys/libkern/iconv.c: In function 'iconv_sysctl_add': /usr/src/sys/libkern/iconv.c:401: error: 'curthread' undeclared (first us= e in this function) /usr/src/sys/libkern/iconv.c: In function 'iconv_converter_handler': /usr/src/sys/libkern/iconv.c:452: error: 'curthread' undeclared (first us= e in this function) I applied following patch - and it works: --- sys/sys/sx.h.orig 2009-02-14 12:56:11.000000000 +0000 +++ sys/sys/sx.h 2009-02-14 12:57:33.000000000 +0000 @@ -35,6 +35,7 @@ #include #include #include +#include #ifdef _KERNEL #include Google didn't find anything so I thought I mail this quickly. Best regards, Jens --------------enigA5DEDAE572FAE7669411584A 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.10 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iQIcBAEBAgAGBQJJlsF0AAoJEIc3wDcpRJzFBkwP/0h3ifjg5FUatHlyiWM/ZqQs xkHSDkq3zn2NacHyGFwqF+Bd9bV+yLKlQvCQAm7bKByhHZMyqB3PV7kKpMEFjZ9n 5tuVKbG6ikctP8eLdnfbckZFm+bbgWJQ2IUkcG/q8/WKC6pCODvjipYoWdpKx0iT PYUUNxeu8mIDZ4U6WkOjXbxRvJG/yrPAmqal9XfhydrDyhqLQ2BzaaFLVzEzbqmn jZdinwmiSssoARw2+h4Krz3YoR5TCJ1k27C8PNPE7w4uSoYXIL8RQE3Ou+6P2TRR ejpm38QK+QeePjBv+TAUIaCho+KG5FW1pgNwut54OdQ/wXUXiKRtyVacd6e8XkeM HY/yQVMwX3VakCwMreNRtGw0r3sgASF5lvloMSsaPPmta8YCvk4YogFGz8kzkg5q aWjMf2Id/tl1A38FR98NqEcmW5JsHXipvyES+gM+OOdA2bOVjI9ac1fBUvn0YaMO GHHtIY5L2LTZNCkWG+to5newy8TUy6gHv/w/mS1PiYtR9Yi29z0UXHn02xPi/3lK lKx3/L2yE4S4puGBp/QA4borqaQaZqJijEdM72BbKK0sIxC1XCqvcX5/8hAmA13x PBHTn//npWwgZ4kAmAa6BJQ80p/oClMO1MLICOiOhFOcm2GdwKNDfN6mTKQlyssx 37HKmanth4bBgOj0nfJF =e2/z -----END PGP SIGNATURE----- --------------enigA5DEDAE572FAE7669411584A-- From owner-freebsd-stable@FreeBSD.ORG Sat Feb 14 14:33:29 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9A8561065672; Sat, 14 Feb 2009 14:33:29 +0000 (UTC) (envelope-from scottl@samsco.org) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.freebsd.org (Postfix) with ESMTP id 4B09C8FC14; Sat, 14 Feb 2009 14:33:29 +0000 (UTC) (envelope-from scottl@samsco.org) Received: from phobos.local ([192.168.254.200]) (authenticated bits=0) by pooker.samsco.org (8.14.2/8.14.2) with ESMTP id n1EEXPnJ078537; Sat, 14 Feb 2009 07:33:25 -0700 (MST) (envelope-from scottl@samsco.org) Message-ID: <4996D635.3000802@samsco.org> Date: Sat, 14 Feb 2009 07:33:25 -0700 From: Scott Long User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:1.8.1.13) Gecko/20080313 SeaMonkey/1.1.9 MIME-Version: 1.0 To: Ivan Voras References: <499551B9.7050805@samsco.org> <4995DFE5.1020205@samsco.org> <9bbcef730902131421r53efa13dq371658888747f387@mail.gmail.com> In-Reply-To: <9bbcef730902131421r53efa13dq371658888747f387@mail.gmail.com> X-Enigmail-Version: 0.95.6 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-4.4 required=3.8 tests=ALL_TRUSTED,BAYES_00 autolearn=ham version=3.1.8 X-Spam-Checker-Version: SpamAssassin 3.1.8 (2007-02-13) on pooker.samsco.org Cc: freebsd-current@freebsd.org, freebsd-stable@freebsd.org Subject: Re: HEADS UP: Major CAM performance regression X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Feb 2009 14:33:30 -0000 Ivan Voras wrote: > 2009/2/13 Scott Long : >> Ivan Voras wrote: >>> Scott Long wrote: >>> >>>> I have committed a fix for this problem for FreeBSD 8-CURRENT as of SVN >>>> revision 188570. FreeBSD 7-STABLE will be updated with the fix in a few >>>> days once I've gotten confirmation that the fix works and doesn't cause >>>> any adverse side-effects. Anyone wanting to help in this validation >>>> effort should apply the attached patch to their kernel source tree and >>>> recompile. Please contact me directly by email to report if the problem >>>> is fixed for you. >>> I notice that write performance on an ESXi 3.5 hosted system is doubled, >>> but read performance remains the same (in bonnie++). >>> On a CISS system there is no significant change. >> bonnie is an unreliable tool for measuring performance. > > I'll try your suggestion if you have one. I don't have a magic universal testing suite in my back pocket, sorry. You need to look at your expected workload and develop tests to simulate it. When I do testing during driver development, I try a lot of different parallel, sequential, large i/o, and small i/o combinations. > > (except if it's about bonnie++ primarily measuring sequential > read/write - if a system can't do sequential IO well, it probably > won't do random IO well) This is completely false. Disks can't do sequential i/o very well due to the physical limits of long seek times, but those seek times can be greatly amortized, even in a random workload, with tagged queueing and parallel dispatch from the OS. Bonnie simply cannot exercise this very well. Bonnie tests system latency for discrete I/O's. That is all it tests. Scott From owner-freebsd-stable@FreeBSD.ORG Sat Feb 14 15:44:50 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C8599106564A; Sat, 14 Feb 2009 15:44:50 +0000 (UTC) (envelope-from ivoras@gmail.com) Received: from mail-fx0-f11.google.com (mail-fx0-f11.google.com [209.85.220.11]) by mx1.freebsd.org (Postfix) with ESMTP id F21C78FC0A; Sat, 14 Feb 2009 15:44:49 +0000 (UTC) (envelope-from ivoras@gmail.com) Received: by fxm4 with SMTP id 4so483678fxm.19 for ; Sat, 14 Feb 2009 07:44:48 -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:content-transfer-encoding; bh=MzNZtZqvxnFQ+iZMGbu2ODQMVZdEF0YjKl/UunRAN0w=; b=fH9Z/JwW2FMYlJsEjWvAU9ya5ZqehmJD36g2t14AIMYsqzPjxXBJP++xImZmqQbW/9 yvCqsMlToQ98L8DT2V6HJR2W1wP+9D79mhXFdhTtc29SFbvu56WPST9z2AwnzVd4VjJP 2yFkjos2TP2LFBQyMAAfXnAYvMI7CTl4LJaP8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=L9KN4Xufif41LhK/h9yQxNq0pGBp45SZ3d5c15O8SnLC12sbh0DPayVMbWob5CmcHN gufAGccetvIjsCG+dHkYrt0tpfEsOYogLCPK3b6EfrEuynPnnINhPQhq6vE1oDw6eYze Ic470e8cs9XN/z3LRyZ0YTFSEi2u5bM7As5KE= MIME-Version: 1.0 Sender: ivoras@gmail.com Received: by 10.181.205.3 with SMTP id h3mr1172052bkq.91.1234626287238; Sat, 14 Feb 2009 07:44:47 -0800 (PST) In-Reply-To: <4996D635.3000802@samsco.org> References: <499551B9.7050805@samsco.org> <4995DFE5.1020205@samsco.org> <9bbcef730902131421r53efa13dq371658888747f387@mail.gmail.com> <4996D635.3000802@samsco.org> Date: Sat, 14 Feb 2009 16:44:47 +0100 X-Google-Sender-Auth: 11fbe127f30ffea4 Message-ID: <9bbcef730902140744i14c2a9e6i211a549eada7b057@mail.gmail.com> From: Ivan Voras To: Scott Long Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org, freebsd-stable@freebsd.org Subject: Re: HEADS UP: Major CAM performance regression X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Feb 2009 15:44:51 -0000 2009/2/14 Scott Long : >> I'll try your suggestion if you have one. > > I don't have a magic universal testing suite in my back pocket, sorry. > You need to look at your expected workload and develop tests to simulate > it. When I do testing during driver development, I try a lot of > different parallel, sequential, large i/o, and small i/o combinations. Of course you're right about testing for specific workloads - I just thought you needed data points "from the field" if the patch is helping or not. >> (except if it's about bonnie++ primarily measuring sequential >> read/write - if a system can't do sequential IO well, it probably >> won't do random IO well) > > This is completely false. Disks can't do sequential i/o very well due > to the physical limits of long seek times, but those seek times can be I don't follow this - where are the long seek times in sequential IO? > greatly amortized, even in a random workload, with tagged queueing and > parallel dispatch from the OS. Bonnie simply cannot exercise this very > well. > > Bonnie tests system latency for discrete I/O's. That is all it tests. Doesn't tagged queuing serve, among other things, to decrease overall latency for IOs? Since AFAIK UFS queues multiple IO requests in both directions (read-ahead and write-behind), shouldn't the benefits of the patch - liberating the tags - be visible even with sequential IO? I have the systems on which I tested for a few more days, if you need the data I can run some other tests (randomio?). From owner-freebsd-stable@FreeBSD.ORG Sat Feb 14 17:31:38 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A8F2C106566C for ; Sat, 14 Feb 2009 17:31:38 +0000 (UTC) (envelope-from svein-listmail@stillbilde.net) Received: from mail.stillbilde.net (d80.iso100.no [81.175.61.195]) by mx1.freebsd.org (Postfix) with ESMTP id 628A88FC25 for ; Sat, 14 Feb 2009 17:31:38 +0000 (UTC) (envelope-from svein-listmail@stillbilde.net) Received: from [192.168.4.9] (unknown [192.168.4.9]) (Authenticated sender: svein) by mail.stillbilde.net (Familien Skogens mail) with ESMTPSA id 5A1EC39; Sat, 14 Feb 2009 17:11:11 +0000 (UTC) Message-ID: <4996FBF3.3040801@stillbilde.net> Date: Sat, 14 Feb 2009 18:14:27 +0100 From: "Svein Skogen (listmail account)" User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Scott Long References: <499551B9.7050805@samsco.org> In-Reply-To: <499551B9.7050805@samsco.org> X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Cc: FreeBSD Current , FreeBSD Stable Subject: Re: HEADS UP: Major CAM performance regression X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Feb 2009 17:31:38 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Scott Long wrote: > All, > > A major performance regression was introduced to the CAM subsystem in > FreeBSD 7.1. The following configurations are known to be affected: > > VMWare ESX > VMWare Fusion > (using bt or lsilogic controller options) > HP CISS RAID > Some MPT-SAS combinations with SATA drives attached > (Includes Dell SAS5/ir, but not PERC5/PERC6). > > Pure SCSI and SAS subsystems likely are NOT affected. Any hardware > that uses the 'ata' driver is also definitely NOT affected. To > determine if your installation is affected, run the following command as > root: > > camcontrol tags da0 > > Substitute 'da0' with another appropriate drive device number, if > needed. Note that this ONLY AFFECTS 'da' DEVICES. If your disks are > 'ad' devices, they are NOT affected. > > The result from running this command should be an output similar to the > following: > > (pass0:mpt0:0:8:0): device openings: 255 > > If, instead, it reports a value of '1', you are likely affected. Note > that it may be normal for USB memory devices to report a low number. > Also, many legacy SCSI disks, and devices that are not disks, may also > be expected to report a low number. > > The effect of this problem is that only one I/O command will be issued > to the controller and disk at a time, instead of overlapping multiple > commands in parallel. This causes significantly higher latency in > servicing moderate and heavy I/O workloads, leading to very poor > performance. Performance can be easily compared by downgrading to > FreeBSD 7.0. Any estimate on when this will be MFC'ed down to RELENG_7 yet? //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 - --------+-------------------+------------------------------- Picture Gallery: https://gallery.stillbilde.net/v/svein/ - ------------------------------------------------------------ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkmW+/IACgkQODUnwSLUlKTVuACgpk70v7d6hyBmvIdaFhLsDA01 nqIAoJkljSXU+TRb7tl9xM8EEerFeMGz =0mNQ -----END PGP SIGNATURE----- From owner-freebsd-stable@FreeBSD.ORG Sat Feb 14 21:54:09 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 31B11106566B for ; Sat, 14 Feb 2009 21:54:09 +0000 (UTC) (envelope-from goran.lowkrantz@ismobile.com) Received: from mail.ismobile.com (mail.ismobile.com [62.119.44.68]) by mx1.freebsd.org (Postfix) with ESMTP id 6D3328FC1E for ; Sat, 14 Feb 2009 21:54:08 +0000 (UTC) (envelope-from goran.lowkrantz@ismobile.com) Received: from mail.ismobile.com (localhost [127.0.0.1]) by mail.ismobile.com (Postfix) with ESMTP id 7D716C2A for ; Sat, 14 Feb 2009 22:54:06 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=ismobile.com; h=date:from :to:subject:message-id:mime-version:content-type: content-transfer-encoding; s=selector1; bh=5mGn/+qyutg8Q7wudmMk9 dgfCkY=; b=bDRe8pVAYVD7Sq30z8yCokKWZQBq4m2Kc27sV0lfbmXECFXSJtC9L rYCLncmuQ4S73KkejMdO1i2jmUtJM3dfuEDWXHpaevb+Xln/kawY+Jb5rZ9y9Xl+ ALuPjI588P2VQmv2tjDKVdLGcX+uovcZ1TV+E6VFNOupbrHB+Js3Uo= Received: from [10.255.253.2] (modgunn.iii-norr.com [213.242.135.174]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.ismobile.com (Postfix) with ESMTPSA id 3A8B6C29 for ; Sat, 14 Feb 2009 22:54:06 +0100 (CET) Date: Sat, 14 Feb 2009 22:54:05 +0100 From: Goran Lowkrantz To: freebsd-stable@freebsd.org Message-ID: <6142197C185AA728E9D4345C@[10.255.253.2]> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Subject: Problems with samba and vista on 7.1-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: Sat, 14 Feb 2009 21:54:09 -0000 I have few Samba servers running FreeBSD 7.1 were we have a problem with=20 connection blocking from a few Vista systems that run programs that watch=20 directories and files on the samba shares. On my test setup I have managed to get a hang in about 30 min. Samba is built with minimum functions and full debug. Options don't seems=20 to have any impact on the problem. The PC uses Vista Business SP1 and all patches, I run a DAM program called=20 IMatch that watches for changes in the photo database. The FreeBSD server is an up-to-date quad AMD server with 8GB running=20 7.1-STABLE. In normal operation, I see the following: # sockstat | grep 445 glz smbd 7828 23 tcp4 10.255.253.1:445 = 10.255.253.2:57355 root smbd 76917 19 tcp4 127.0.0.1:445 *:* root smbd 76917 20 tcp4 10.255.253.1:445 *:* When I get the hang, it looks like this: # sockstat | grep 445 root smbd 7828 23 tcp4 10.255.253.1:445 = 10.255.253.2:57355 root smbd 76917 19 tcp4 127.0.0.1:445 *:* root smbd 76917 20 tcp4 10.255.253.1:445 *:* and the GDB session: # gdb /usr/local/sbin/smbd 7828 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=20 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"... Attaching to program: /usr/local/sbin/smbd, process 7828 Reading symbols from /usr/local/lib/libldap-2.3.so.2...done. Loaded symbols for /usr/local/lib/libldap-2.3.so.2 Reading symbols from /usr/local/lib/liblber-2.3.so.2...done. Loaded symbols for /usr/local/lib/liblber-2.3.so.2 Reading symbols from /usr/local/lib/libcups.so.2...done. Loaded symbols for /usr/local/lib/libcups.so.2 Reading symbols from /usr/lib/libssl.so.5...done. Loaded symbols for /usr/lib/libssl.so.5 Reading symbols from /lib/libcrypto.so.5...done. Loaded symbols for /lib/libcrypto.so.5 Reading symbols from /lib/libz.so.4...done. Loaded symbols for /lib/libz.so.4 Reading symbols from /lib/libm.so.5...done. Loaded symbols for /lib/libm.so.5 Reading symbols from /lib/libcrypt.so.4...done. Loaded symbols for /lib/libcrypt.so.4 Reading symbols from /usr/lib/libpam.so.4...done. Loaded symbols for /usr/lib/libpam.so.4 Reading symbols from /usr/local/lib/libexecinfo.so.1...done. Loaded symbols for /usr/local/lib/libexecinfo.so.1 Reading symbols from /usr/local/lib/libiconv.so.3...done. Loaded symbols for /usr/local/lib/libiconv.so.3 Reading symbols from /usr/local/lib/libdmalloc.so.1...done. Loaded symbols for /usr/local/lib/libdmalloc.so.1 Reading symbols from /usr/local/lib/libpopt.so.0...done. Loaded symbols for /usr/local/lib/libpopt.so.0 Reading symbols from /lib/libthr.so.3...done. [New Thread 0x800a62e00 (LWP 100076)] Loaded symbols for /lib/libthr.so.3 Reading symbols from /lib/libc.so.7...done. Loaded symbols for /lib/libc.so.7 Reading symbols from /usr/local/lib/libsasl2.so.2...done. Loaded symbols for /usr/local/lib/libsasl2.so.2 Reading symbols from /usr/local/lib/libintl.so.8...done. Loaded symbols for /usr/local/lib/libintl.so.8 Reading symbols from /usr/local/lib/nss_ldap.so.1...done. Loaded symbols for /usr/local/lib/nss_ldap.so.1 Reading symbols from /usr/lib/libcom_err.so.4...done. Loaded symbols for /usr/lib/libcom_err.so.4 Reading symbols from /libexec/ld-elf.so.1...done. Loaded symbols for /libexec/ld-elf.so.1 [Switching to Thread 0x800a62e00 (LWP 100076)] 0x0000000801f01d6c in select () from /lib/libc.so.7 (gdb) directory /usr/ports/net/samba32-devel/work/samba-3.2.7/source/ Source directories searched:=20 /usr/ports/net/samba32-devel/work/samba-3.2.7/source:$cdir:$cwd (gdb) bt #0 0x0000000801f01d6c in select () from /lib/libc.so.7 #1 0x0000000801d0f4d4 in select () from /lib/libthr.so.3 #2 0x00000000006749fe in sys_select (maxfd=3D24, readfds=3D0x7fffffffd420, = writefds=3D0x7fffffffd3a0, errorfds=3D0x0, tval=3D0x7fffffffd500) at lib/select.c:93 #3 0x00000000004df64c in smbd_process () at smbd/process.c:839 #4 0x0000000000854074 in main (argc=3D2, argv=3D0x7fffffffd638) at=20 smbd/server.c:1450 (gdb) frame 2 #2 0x00000000006749fe in sys_select (maxfd=3D24, readfds=3D0x7fffffffd420, = writefds=3D0x7fffffffd3a0, errorfds=3D0x0, tval=3D0x7fffffffd500) at lib/select.c:93 93 ret =3D select(maxfd,readfds2,writefds,errorfds,tval); (gdb) print tval $1 =3D (struct timeval *) 0x7fffffffd500 (gdb) print *tval $2 =3D {tv_sec =3D 59, tv_usec =3D 999977} (gdb) The program is running. Quit anyway (and detach it)? (y or n) y Detaching from program: /usr/local/sbin/smbd, process 7828 The following is a truss of the process until I have seen the switch to=20 root as owner: # time truss -p 8307 gettimeofday({1234648077.989004 },0x0) =3D 0 (0x0) gettimeofday({1234648077.989081 },0x0) =3D 0 (0x0) select(24,{6 23},{},0x0,{21.288167 }) =3D 0 (0x0) gettimeofday({1234648099.279293 },0x0) =3D 0 (0x0) gettimeofday({1234648099.279370 },0x0) =3D 0 (0x0) gettimeofday({1234648099.279417 },0x0) =3D 0 (0x0) select(24,{6 23},{},0x0,{59.989982 }) =3D 1 (0x1) gettimeofday({1234648102.286493 },0x0) =3D 0 (0x0) read(23,"\0\0\0r",4) =3D 4 (0x4) read(23,"\M^?SMB2\0\0\0\0\^X\a\M-H\0\0\0"...,114) =3D 114 (0x72) geteuid(0x3e8,0x3e8,0x2,0x800adf750,0x2,0x800adf750) =3D 0 (0x0) getegid(0x3e8,0x3e8,0x2,0x801eadb8c,0xffffff006cf16a50,0x7fffffffd138) =3D = 0=20 (0x0) __sysctl(0x7fffffffd0a0,0x2,0x7fffffffd0bc,0x7fffffffd0b0,0x0,0x0) =3D 0 = (0x0) 0.000u 0.001s 2:36.56 0.0% 0+0k 0+0io 0pf+0w # sockstat | grep 445 glz smbd 8307 23 tcp4 10.255.253.1:445 = 10.255.253.2:57438 root smbd 76917 19 tcp4 127.0.0.1:445 *:* root smbd 76917 20 tcp4 10.255.253.1:445 *:* # ps -awxl | grep 8307 1000 8307 8556 0 44 0 34672 7984 select IX ?? 0:04.57=20 /usr/local/sbin/smbd -D -s /usr/local/etc/smb.conf 0 8556 3273 0 8 0 4600 1204 wait I+ p0 0:00.00 truss=20 -p 8307 # sockstat | grep 445 root smbd 8307 23 tcp4 10.255.253.1:445 = 10.255.253.2:57438 root smbd 76917 19 tcp4 127.0.0.1:445 *:* root smbd 76917 20 tcp4 10.255.253.1:445 *:* # ps -awxl | grep 8307 0 8307 8556 0 44 0 34672 7984 select SX ?? 0:04.57=20 /usr/local/sbin/smbd -D -s /usr/local/etc/smb.conf 0 8556 3273 0 8 0 4600 1204 wait I+ p0 0:00.00 truss=20 -p 8307 I can recreate this at any time and the condition can be cleared in two=20 ways: - killing the offending smbd process and the PC reconnects just fine - attach and detach truss, as can bee seen in the logs below taken after=20 the truss session above: # sockstat | grep 445 glz smbd 8307 23 tcp4 10.255.253.1:445 = 10.255.253.2:57438 root smbd 76917 19 tcp4 127.0.0.1:445 *:* root smbd 76917 20 tcp4 10.255.253.1:445 *:* # ps -awxl | grep 8307 1000 8307 76917 0 44 0 34672 7984 select S ?? 0:04.58=20 /usr/local/sbin/smbd -D -s /usr/local/etc/smb.conf /glz ................................................... the future isMobile Goran Lowkrantz System Architect, isMobile, Aurorum 2, S-977 75 Lule=C3=A5, Sweden Phone: +46(0)920-75559 Mobile: +46(0)70-587 87 82 Fax: +46(0)70-615 87 82 http://www.ismobile.com ............................................... From owner-freebsd-stable@FreeBSD.ORG Sat Feb 14 23:04:50 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 854651065672 for ; Sat, 14 Feb 2009 23:04:50 +0000 (UTC) (envelope-from swsirlin@earthlink.net) Received: from elasmtp-kukur.atl.sa.earthlink.net (elasmtp-kukur.atl.sa.earthlink.net [209.86.89.65]) by mx1.freebsd.org (Postfix) with ESMTP id 575B08FC0A for ; Sat, 14 Feb 2009 23:04:50 +0000 (UTC) (envelope-from swsirlin@earthlink.net) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=TvCx8tgamLl+zAXUi+Kmw8sZWo80F60anTvnmEXewwBOGh0x8hIeUu8Ep1PMp7SZ; h=Received:Message-ID:Date:From:User-Agent:MIME-Version:To:Subject:Content-Type:Content-Transfer-Encoding:X-ELNK-Trace:X-Originating-IP; Received: from [24.205.80.117] (helo=celeborn.my.domain) by elasmtp-kukur.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1LYTIO-0002U0-SW for freebsd-stable@freebsd.org; Sat, 14 Feb 2009 17:47:36 -0500 Message-ID: <499749E3.7000507@earthlink.net> Date: Sat, 14 Feb 2009 14:46:59 -0800 From: sam sirlin User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.8.1.19) Gecko/20090110 SeaMonkey/1.1.14 MIME-Version: 1.0 To: freebsd-stable@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ELNK-Trace: 52e4e1bd8cc945501aa676d7e74259b7b3291a7d08dfec79c82b1fbb9212b2cc6ab05ee28736d7fb350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 24.205.80.117 Subject: Re: Unhappy Xorg upgrade X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Feb 2009 23:04:50 -0000 I've just upgraded to the latest xorg on my amd64 box 7.1-STABLE FreeBSD 7.1-STABLE #0: Fri Jan 16 07:33:20 PST 2009 I have a radeon graphics card, drm0: on vgapci0 - had to add the option mentioned in UPDATING Section "ServerLayout" Option "AllowEmptyInput" "off" ... Things seem mostly running on my box, though there are many of these emacs Xlib: extension "Generic Event Extension" missing on display ":0.0". ... I now see that ssh into a remote host (solaris 10 sparc), running emacs there pops up a window, but then typing anything into the window kills it, with X protocol error: BadAlloc (insufficient resources for operation) on protocol request 149 (on the remote machine). xv works ok. This doesn't happen if the remote host is linux rh4... This didn't happen before the xorg upgrade. Seems to be some sort of incompatibility in X11. Any ideas? Sam Sirlin