From owner-freebsd-stable@FreeBSD.ORG Sun May 12 02:27:33 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 4E878157 for ; Sun, 12 May 2013 02:27:33 +0000 (UTC) (envelope-from illoai@gmail.com) Received: from mail-pb0-x234.google.com (mail-pb0-x234.google.com [IPv6:2607:f8b0:400e:c01::234]) by mx1.freebsd.org (Postfix) with ESMTP id 2EF96630 for ; Sun, 12 May 2013 02:27:33 +0000 (UTC) Received: by mail-pb0-f52.google.com with SMTP id xa7so3625983pbc.11 for ; Sat, 11 May 2013 19:27:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=/CqDj7LUN3S+kk9QPx8/g+FH7b3i14IytFnnrtkL03E=; b=P4nfACMDcBl8JnB/iwhVUmqWqf7sEAqpJFjXGBiRNF7Oaln98NdkxzYbELLMLD65Cu MfW3en5XJiATDXV1kfXK4uz5nyMNkAUw/PD224t2il494XLVHelTM/ZxAnzL7RKlcuC/ kM/LtULFtGs6Vx+pwLSYS+fFmCSvgtiiwlMV04jlbPn05cBdv377yO1ASG3rPQbX5126 R6fZ1Z1N0ozKJPHpQ+0VDTL51Ee/rZTki+ZIa0LV8xLhC5KXvZpp+nt8k2JCXb5DZOgN cqNhe7iEF/DSYxcKb4L1i9tmk/ZJb7vYmvm+nUbPANQVZ7W04Y4nzfVm4VswSH/WsREL w3DA== MIME-Version: 1.0 X-Received: by 10.68.223.10 with SMTP id qq10mr23551051pbc.57.1368325652216; Sat, 11 May 2013 19:27:32 -0700 (PDT) Received: by 10.68.149.3 with HTTP; Sat, 11 May 2013 19:27:32 -0700 (PDT) In-Reply-To: <518ED0CA.4030007@wp.pl> References: <518ED0CA.4030007@wp.pl> Date: Sat, 11 May 2013 22:27:32 -0400 Message-ID: Subject: Re: Build GENERIC with IPX support From: "illoai@gmail.com" To: Marek Salwerowicz Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: "freebsd-stable@freebsd.org" X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 12 May 2013 02:27:33 -0000 On 11 May 2013 19:14, Marek Salwerowicz wrote: > Hi list, > > I am using 9.1-RELEASE amd64 FreeBSD > I order to connect my FreeBSD box to NetWare servers, I am trying to > recompile the kernel. > > To GENERIC config I've added following options: > > options IPX > options NCP > options NWFS > > > unfortunately, during buildkernel process I got an error: > > nwfs_subr.o: In function `ncp_lookup_volume': > /usr/src/sys/fs/nwfs/nwfs_**subr.c:499: undefined reference to > `mb_put_uint8' > ... > /usr/src/sys/netncp/ncp_rq.c:**189: undefined reference to `mb_put_mem' > *** [kernel.debug] Error code 1 > > Stop in /tmp/obj/usr/src/sys/**GENERICIPX. > *** [buildkernel] Error code 1 > > Stop in /usr/src. > *** [buildkernel] Error code 1 > > Stop in /usr/src. > 641.92s user 284.90s system 102% cpu 15:03.37s total > marek@bsd-gen:/usr/src% > > > Does anyone still uses IPX and could help me compiling the kernel ? > > I think you also have to have options LIBMCHAIN HTH -- -- From owner-freebsd-stable@FreeBSD.ORG Sun May 12 03:18:58 2013 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 7B1CE94A; Sun, 12 May 2013 03:18:58 +0000 (UTC) (envelope-from mikes@siralan.org) Received: from mail.suso.org (mail.suso.org [66.244.94.5]) by mx1.freebsd.org (Postfix) with ESMTP id EB1788B3; Sun, 12 May 2013 03:18:57 +0000 (UTC) Received: from c-98-223-197-163.hsd1.in.comcast.net (c-98-223-197-163.hsd1.in.comcast.net [98.223.197.163]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.suso.org (Postfix) with ESMTP id CDACA1381FB; Sun, 12 May 2013 02:57:54 +0000 (GMT) Date: Sat, 11 May 2013 22:57:44 -0400 (EDT) From: "Michael L. Squires" X-X-Sender: mikes@familysquires.net To: Glen Barber Subject: Apparent fxp regression in FreeBSD 8.4-RC3 In-Reply-To: <20130508174721.GD1651@glenbarber.us> Message-ID: References: <20130508174721.GD1651@glenbarber.us> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="-1160921188-1351541650-1368327465=:1240" Cc: FreeBSD Release Engineering Team , freebsd-stable@FreeBSD.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 12 May 2013 03:18:58 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. ---1160921188-1351541650-1368327465=:1240 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII I upgraded to FreeBSD 8.4-RC3 and noticed a problem with the fxp driver on an older Supermicro single CPU single core Xeon motherboard. I know that 8.3-Release does not have this issue, but don't know when in the updates to that release the regression was introduced. I use the fxp driver to connect to a Motorola Surfboard cable modem, and immediately saw the following occur many times: May 10 23:00:04 familysquires kernel: fxp0: link state changed to DOWN May 10 23:00:04 familysquires dhclient: New Subnet Mask (fxp0): 255.255.240.0 May 10 23:00:04 familysquires dhclient: New Broadcast Address (fxp0): 255.255.25 5.255 May 10 23:00:04 familysquires dhclient: New Routers (fxp0): xx.xxx.xxx.1 May 10 23:00:06 familysquires kernel: fxp0: link state changed to UP May 10 23:00:22 familysquires dhclient: New IP Address (fxp0): xx.xxx.xxx.163 May 10 23:00:22 familysquires kernel: fxp0: link state changed to DOWN May 10 23:00:22 familysquires dhclient: New Subnet Mask (fxp0): 255.255.240.0 May 10 23:00:22 familysquires dhclient: New Broadcast Address (fxp0): 255.255.255.255 May 10 23:00:22 familysquires dhclient: New Routers (fxp0): xx.xxx.xxx.1 May 10 23:00:24 familysquires kernel: fxp0: link state changed to UP repeated without end. I reinsalled 8.3-Release p8 FreeBSD familysquires.net 8.3-RELEASE-p8 FreeBSD 8.3-RELEASE-p8 #46: Sat May 11 00:05:26 EDT 2013 which ended the string up fxp up/down messages. This kernel has now operated for 24 hours without generating this error. I've attached a verbose dmesg from 8.4-RC3 and a standard dmesg from 8.3-Release p8, and can provide whatever else you need. This is not a critical issue for me. The system has an unused bge interface (replaced by an Intel em0 interface during a previous bout of a problem with the bge driver). Mike Squires mikes@siralan.org ---1160921188-1351541650-1368327465=:1240 Content-Type: TEXT/PLAIN; charset=US-ASCII; name=dmesg_84RC3.txt Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: dmesg verbose RC3 Content-Disposition: attachment; filename=dmesg_84RC3.txt Q29weXJpZ2h0IChjKSAxOTkyLTIwMTMgVGhlIEZyZWVCU0QgUHJvamVjdC4N CkNvcHlyaWdodCAoYykgMTk3OSwgMTk4MCwgMTk4MywgMTk4NiwgMTk4OCwg MTk4OSwgMTk5MSwgMTk5MiwgMTk5MywgMTk5NA0KCVRoZSBSZWdlbnRzIG9m IHRoZSBVbml2ZXJzaXR5IG9mIENhbGlmb3JuaWEuIEFsbCByaWdodHMgcmVz ZXJ2ZWQuDQpGcmVlQlNEIGlzIGEgcmVnaXN0ZXJlZCB0cmFkZW1hcmsgb2Yg VGhlIEZyZWVCU0QgRm91bmRhdGlvbi4NCkZyZWVCU0QgOC40LVBSRVJFTEVB U0UgIzQ1OiBGcmkgTWF5IDEwIDA5OjQzOjQwIEVEVCAyMDEzDQogICAgcm9v dEBmYW1pbHlzcXVpcmVzLm5ldDovdXNyL29iai91c3Ivc3JjL3N5cy9ORVdH QVRFIGkzODYNCmdjYyB2ZXJzaW9uIDQuMi4xIDIwMDcwODMxIHBhdGNoZWQg W0ZyZWVCU0RdDQpQcmVsb2FkZWQgZWxmIGtlcm5lbCAiL2Jvb3Qva2VybmVs L2tlcm5lbCIgYXQgMHhjMTA2MDAwMC4NClRpbWVjb3VudGVyICJpODI1NCIg ZnJlcXVlbmN5IDExOTMxODIgSHogcXVhbGl0eSAwDQpDYWxpYnJhdGluZyBU U0MgY2xvY2sgLi4uIFRTQyBjbG9jazogMjY2Njc4Njk4OCBIeg0KQ1BVOiBJ bnRlbChSKSBYZW9uKFRNKSBDUFUgMi42NkdIeiAoMjY2Ni43OS1NSHogNjg2 LWNsYXNzIENQVSkNCiAgT3JpZ2luID0gIkdlbnVpbmVJbnRlbCIgIElkID0g MHhmMjUgIEZhbWlseSA9IGYgIE1vZGVsID0gMiAgU3RlcHBpbmcgPSA1DQog IEZlYXR1cmVzPTB4YmZlYmZiZmY8RlBVLFZNRSxERSxQU0UsVFNDLE1TUixQ QUUsTUNFLENYOCxBUElDLFNFUCxNVFJSLFBHRSxNQ0EsQ01PVixQQVQsUFNF MzYsQ0xGTFVTSCxEVFMsQUNQSSxNTVgsRlhTUixTU0UsU1NFMixTUyxIVFQs VE0sUEJFPg0KICBGZWF0dXJlczI9MHg0NDAwPENOWFQtSUQseFRQUj4NCg0K SW5zdHJ1Y3Rpb24gVExCOiA0IEtCLCAyIE1CIG9yIDQgTUIgcGFnZXMsIGZ1 bGx5IGFzc29jaWF0aXZlLCAxMjggZW50cmllcw0KRGF0YSBUTEI6IDQgS0Ig b3IgNCBNQiBwYWdlcywgZnVsbHkgYXNzb2NpYXRpdmUsIDY0IGVudHJpZXMN CjFzdC1sZXZlbCBkYXRhIGNhY2hlOiA4IEtCLCA0LXdheSBzZXQgYXNzb2Np YXRpdmUsIHNlY3RvcmVkIGNhY2hlLCA2NCBieXRlIGxpbmUgc2l6ZQ0KVHJh Y2UgY2FjaGU6IDEySy11b3BzLCA4LXdheSBzZXQgYXNzb2NpYXRpdmUNCjJu ZC1sZXZlbCBjYWNoZTogNTEyIEtCLCA4LXdheSBzZXQgYXNzb2NpYXRpdmUs IHNlY3RvcmVkIGNhY2hlLCA2NCBieXRlIGxpbmUgc2l6ZQ0KcmVhbCBtZW1v cnkgID0gMTA3Mzc0MTgyNCAoMTAyNCBNQikNClBoeXNpY2FsIG1lbW9yeSBj aHVuayhzKToNCjB4MDAwMDAwMDAwMDAwMTAwMCAtIDB4MDAwMDAwMDAwMDA5 ZWZmZiwgNjQ3MTY4IGJ5dGVzICgxNTggcGFnZXMpDQoweDAwMDAwMDAwMDAx MDAwMDAgLSAweDAwMDAwMDAwMDAzZmZmZmYsIDMxNDU3MjggYnl0ZXMgKDc2 OCBwYWdlcykNCjB4MDAwMDAwMDAwMTQyNjAwMCAtIDB4MDAwMDAwMDAzZWRh NGZmZiwgMTAzMzM2NzU1MiBieXRlcyAoMjUyMjg3IHBhZ2VzKQ0KYXZhaWwg bWVtb3J5ID0gMTAzMjA2OTEyMCAoOTg0IE1CKQ0KVGFibGUgJ0ZBQ1AnIGF0 IDB4M2ZmZjAwMzANClRhYmxlICdBUElDJyBhdCAweDNmZmYwMGIwDQpBUElD OiBGb3VuZCB0YWJsZSBhdCAweDNmZmYwMGIwDQpNUCBDb25maWd1cmF0aW9u IFRhYmxlIHZlcnNpb24gMS40IGZvdW5kIGF0IDB4YzAwZjBjYjANCkFQSUM6 IFVzaW5nIHRoZSBNQURUIGVudW1lcmF0b3IuDQpNQURUOiBGb3VuZCBDUFUg QVBJQyBJRCAwIEFDUEkgSUQgMDogZW5hYmxlZA0KU01QOiBBZGRlZCBDUFUg MCAoQVApDQpNQURUOiBGb3VuZCBDUFUgQVBJQyBJRCAwIEFDUEkgSUQgMTog ZGlzYWJsZWQNCk1BRFQ6IEZvdW5kIENQVSBBUElDIElEIDAgQUNQSSBJRCAy OiBkaXNhYmxlZA0KTUFEVDogRm91bmQgQ1BVIEFQSUMgSUQgMCBBQ1BJIElE IDM6IGRpc2FibGVkDQpNQURUOiBGb3VuZCBDUFUgQVBJQyBJRCAwIEFDUEkg SUQgNDogZGlzYWJsZWQNCk1BRFQ6IEZvdW5kIENQVSBBUElDIElEIDAgQUNQ SSBJRCA1OiBkaXNhYmxlZA0KTUFEVDogRm91bmQgQ1BVIEFQSUMgSUQgMCBB Q1BJIElEIDY6IGRpc2FibGVkDQpNQURUOiBGb3VuZCBDUFUgQVBJQyBJRCAw IEFDUEkgSUQgNzogZGlzYWJsZWQNCkFDUEkgQVBJQyBUYWJsZTogPFJDQyAg ICBHQ0hFICAgID4NCkFQSUM6IENQVSAwIGhhcyBBQ1BJIElEIDANCmJpb3Mz MjogRm91bmQgQklPUzMyIFNlcnZpY2UgRGlyZWN0b3J5IGhlYWRlciBhdCAw eGMwMGZkYjcwDQpiaW9zMzI6IEVudHJ5ID0gMHhmZGI4MCAoYzAwZmRiODAp ICBSZXYgPSAwICBMZW4gPSAxDQpwY2liaW9zOiBQQ0kgQklPUyBlbnRyeSBh dCAweGYwMDAwKzB4ZGJhMQ0KcG5wYmlvczogRm91bmQgUG5QIEJJT1MgZGF0 YSBhdCAweGMwMGY0NTAwDQpwbnBiaW9zOiBFbnRyeSA9IGYwMDAwOjMzYTQg IFJldiA9IDEuMA0KT3RoZXIgQklPUyBzaWduYXR1cmVzIGZvdW5kOg0KeDg2 YmlvczogICBJVlQgMHgwMDAwMDAtMHgwMDA0ZmYgYXQgMHhjMDAwMDAwMA0K eDg2YmlvczogIFNTRUcgMHgwOWUwMDAtMHgwOWVmZmYgYXQgMHhjNGRjMDAw MA0KeDg2YmlvczogIEVCREEgMHgwOWYwMDAtMHgwOWZmZmYgYXQgMHhjMDA5 ZjAwMA0KeDg2YmlvczogICBST00gMHgwYTAwMDAtMHgwZmVmZmYgYXQgMHhj MDBhMDAwMA0KVUxFOiBzZXR1cCBjcHUgMA0KQUNQSTogUlNEUCAweGZmOTAw IDAwMDE0ICh2MDAgQU1JICAgKQ0KQUNQSTogUlNEVCAweDNmZmYwMDAwIDAw MDJDICh2MDEgUkNDICAgIEdDSEUgICAgIDAwMDAwMDAxIE1TRlQgMDEwMDAw MDApDQpBQ1BJOiBGQUNQIDB4M2ZmZjAwMzAgMDAwNzQgKHYwMSBSQ0MgICAg R0NIRSAgICAgMDAwMDAwMDEgTVNGVCAwMTAwMDAwMCkNCkFDUEk6IERTRFQg MHgzZmZmMDE1MCAwNDlGMSAodjAxICAgIFJDQyAgICAgR0NTTCAwMDAwMDEw MCBNU0ZUIDAxMDAwMDBEKQ0KQUNQSTogRkFDUyAweDNmZmZmMDAwIDAwMDQw DQpBQ1BJOiBBUElDIDB4M2ZmZjAwYjAgMDAwOUEgKHYwMSBSQ0MgICAgR0NI RSAgICAgMDAwMDAwMDEgTVNGVCAwMTAwMDAwMCkNCk1BRFQ6IEZvdW5kIElP IEFQSUMgSUQgOCwgSW50ZXJydXB0IDAgYXQgMHhmZWMwMDAwMA0KaW9hcGlj MDogUm91dGluZyBleHRlcm5hbCA4MjU5QSdzIC0+IGludHBpbiAwDQpNQURU OiBGb3VuZCBJTyBBUElDIElEIDksIEludGVycnVwdCAxNiBhdCAweGZlYzAx MDAwDQpNQURUOiBGb3VuZCBJTyBBUElDIElEIDEwLCBJbnRlcnJ1cHQgMzIg YXQgMHhmZWMwMjAwMA0KTUFEVDogSW50ZXJydXB0IG92ZXJyaWRlOiBzb3Vy Y2UgMCwgaXJxIDINCmlvYXBpYzA6IFJvdXRpbmcgSVJRIDAgLT4gaW50cGlu IDINCk1BRFQ6IEZvcmNpbmcgYWN0aXZlLWxvdyBwb2xhcml0eSBhbmQgbGV2 ZWwgdHJpZ2dlciBmb3IgU0NJDQppb2FwaWMwOiBpbnRwaW4gOSBwb2xhcml0 eTogbG93DQppb2FwaWMwOiBpbnRwaW4gOSB0cmlnZ2VyOiBsZXZlbA0KaW9h cGljMCA8VmVyc2lvbiAxLjE+IGlycXMgMC0xNSBvbiBtb3RoZXJib2FyZA0K aW9hcGljMSA8VmVyc2lvbiAxLjE+IGlycXMgMTYtMzEgb24gbW90aGVyYm9h cmQNCmlvYXBpYzIgPFZlcnNpb24gMS4xPiBpcnFzIDMyLTQ3IG9uIG1vdGhl cmJvYXJkDQpjcHUwIEJTUDoNCiAgICAgSUQ6IDB4MDAwMDAwMDAgICBWRVI6 IDB4MDAwNTAwMTQgTERSOiAweDAwMDAwMDAwIERGUjogMHhmZmZmZmZmZg0K ICBsaW50MDogMHgwMDAxMDcwMCBsaW50MTogMHgwMDAwMDQwMCBUUFI6IDB4 MDAwMDAwMDAgU1ZSOiAweDAwMDAwMWZmDQogIHRpbWVyOiAweDAwMDEwMGVm IHRoZXJtOiAweDAwMDEwMDAwIGVycjogMHgwMDAwMDBmMCBwbWM6IDB4MDAw MTA0MDANCndsYW46IDw4MDIuMTEgTGluayBMYXllcj4NCnJhbmRvbTogPGVu dHJvcHkgc291cmNlLCBTb2Z0d2FyZSwgWWFycm93Pg0KbmZzbG9jazogcHNl dWRvLWRldmljZQ0Ka2JkOiBuZXcgYXJyYXkgc2l6ZSA0DQprYmQxIGF0IGti ZG11eDANCm1lbTogPG1lbW9yeT4NClBlbnRpdW0gUHJvIE1UUlIgc3VwcG9y dCBlbmFibGVkDQppbzogPEkvTz4NCm51bGw6IDxudWxsIGRldmljZSwgemVy byBkZXZpY2U+DQpocHRycjogUm9ja2V0UkFJRCAxN3h4LzJ4eHggU0FUQSBj b250cm9sbGVyIGRyaXZlciB2MS4yDQphY3BpMDogPFJDQyBHQ0hFPiBvbiBt b3RoZXJib2FyZA0KQUNQSSBXYXJuaW5nOiBUeXBlIG92ZXJyaWRlIC0gW0RF Ql9dIGhhZCBpbnZhbGlkIHR5cGUgKEludGVnZXIpIGZvciBTY29wZSBvcGVy YXRvciwgY2hhbmdlZCB0byB0eXBlIEFOWQ0KICgyMDEwMTAxMy9kc3dsb2Fk LTgwOCkNCkFDUEkgV2FybmluZzogVHlwZSBvdmVycmlkZSAtIFtNTElCXSBo YWQgaW52YWxpZCB0eXBlIChJbnRlZ2VyKSBmb3IgU2NvcGUgb3BlcmF0b3Is IGNoYW5nZWQgdG8gdHlwZSBBTlkNCiAoMjAxMDEwMTMvZHN3bG9hZC04MDgp DQpBQ1BJIFdhcm5pbmc6IFR5cGUgb3ZlcnJpZGUgLSBbSU9fX10gaGFkIGlu dmFsaWQgdHlwZSAoSW50ZWdlcikgZm9yIFNjb3BlIG9wZXJhdG9yLCBjaGFu Z2VkIHRvIHR5cGUgQU5ZDQogKDIwMTAxMDEzL2Rzd2xvYWQtODA4KQ0KQUNQ SSBXYXJuaW5nOiBUeXBlIG92ZXJyaWRlIC0gW0RBVEFdIGhhZCBpbnZhbGlk IHR5cGUgKFN0cmluZykgZm9yIFNjb3BlIG9wZXJhdG9yLCBjaGFuZ2VkIHRv IHR5cGUgQU5ZDQogKDIwMTAxMDEzL2Rzd2xvYWQtODA4KQ0KQUNQSSBXYXJu aW5nOiBUeXBlIG92ZXJyaWRlIC0gW1NJT19dIGhhZCBpbnZhbGlkIHR5cGUg KFN0cmluZykgZm9yIFNjb3BlIG9wZXJhdG9yLCBjaGFuZ2VkIHRvIHR5cGUg QU5ZDQogKDIwMTAxMDEzL2Rzd2xvYWQtODA4KQ0KQUNQSSBXYXJuaW5nOiBU eXBlIG92ZXJyaWRlIC0gW1NCX19dIGhhZCBpbnZhbGlkIHR5cGUgKFN0cmlu ZykgZm9yIFNjb3BlIG9wZXJhdG9yLCBjaGFuZ2VkIHRvIHR5cGUgQU5ZDQog KDIwMTAxMDEzL2Rzd2xvYWQtODA4KQ0KQUNQSSBXYXJuaW5nOiBUeXBlIG92 ZXJyaWRlIC0gW1BNX19dIGhhZCBpbnZhbGlkIHR5cGUgKFN0cmluZykgZm9y IFNjb3BlIG9wZXJhdG9yLCBjaGFuZ2VkIHRvIHR5cGUgQU5ZDQogKDIwMTAx MDEzL2Rzd2xvYWQtODA4KQ0KQUNQSSBXYXJuaW5nOiBUeXBlIG92ZXJyaWRl IC0gW0lDTlRdIGhhZCBpbnZhbGlkIHR5cGUgKFN0cmluZykgZm9yIFNjb3Bl IG9wZXJhdG9yLCBjaGFuZ2VkIHRvIHR5cGUgQU5ZDQogKDIwMTAxMDEzL2Rz d2xvYWQtODA4KQ0KQUNQSSBXYXJuaW5nOiBUeXBlIG92ZXJyaWRlIC0gW0FD UEldIGhhZCBpbnZhbGlkIHR5cGUgKFN0cmluZykgZm9yIFNjb3BlIG9wZXJh dG9yLCBjaGFuZ2VkIHRvIHR5cGUgQU5ZDQogKDIwMTAxMDEzL2Rzd2xvYWQt ODA4KQ0KQUNQSSBXYXJuaW5nOiBUeXBlIG92ZXJyaWRlIC0gW0lPUkddIGhh ZCBpbnZhbGlkIHR5cGUgKFN0cmluZykgZm9yIFNjb3BlIG9wZXJhdG9yLCBj aGFuZ2VkIHRvIHR5cGUgQU5ZDQogKDIwMTAxMDEzL2Rzd2xvYWQtODA4KQ0K QUNQSSBXYXJuaW5nOiBUeXBlIG92ZXJyaWRlIC0gW1NCX19dIGhhZCBpbnZh bGlkIHR5cGUgKFN0cmluZykgZm9yIFNjb3BlIG9wZXJhdG9yLCBjaGFuZ2Vk IHRvIHR5cGUgQU5ZDQogKDIwMTAxMDEzL2Rzd2xvYWQtODA4KQ0KQUNQSSBX YXJuaW5nOiBUeXBlIG92ZXJyaWRlIC0gW1BNX19dIGhhZCBpbnZhbGlkIHR5 cGUgKFN0cmluZykgZm9yIFNjb3BlIG9wZXJhdG9yLCBjaGFuZ2VkIHRvIHR5 cGUgQU5ZDQogKDIwMTAxMDEzL2Rzd2xvYWQtODA4KQ0KQUNQSSBXYXJuaW5n OiBUeXBlIG92ZXJyaWRlIC0gW1NJT19dIGhhZCBpbnZhbGlkIHR5cGUgKFN0 cmluZykgZm9yIFNjb3BlIG9wZXJhdG9yLCBjaGFuZ2VkIHRvIHR5cGUgQU5Z DQogKDIwMTAxMDEzL2Rzd2xvYWQtODA4KQ0KQUNQSSBXYXJuaW5nOiBUeXBl IG92ZXJyaWRlIC0gW1BNX19dIGhhZCBpbnZhbGlkIHR5cGUgKFN0cmluZykg Zm9yIFNjb3BlIG9wZXJhdG9yLCBjaGFuZ2VkIHRvIHR5cGUgQU5ZDQogKDIw MTAxMDEzL2Rzd2xvYWQtODA4KQ0KQUNQSSBXYXJuaW5nOiBUeXBlIG92ZXJy aWRlIC0gW0JJT1NdIGhhZCBpbnZhbGlkIHR5cGUgKEludGVnZXIpIGZvciBT Y29wZSBvcGVyYXRvciwgY2hhbmdlZCB0byB0eXBlIEFOWQ0KICgyMDEwMTAx My9kc3dsb2FkLTgwOCkNCkFDUEkgV2FybmluZzogVHlwZSBvdmVycmlkZSAt IFtDTU9TXSBoYWQgaW52YWxpZCB0eXBlIChJbnRlZ2VyKSBmb3IgU2NvcGUg b3BlcmF0b3IsIGNoYW5nZWQgdG8gdHlwZSBBTlkNCiAoMjAxMDEwMTMvZHN3 bG9hZC04MDgpDQpBQ1BJIFdhcm5pbmc6IFR5cGUgb3ZlcnJpZGUgLSBbS0JD X10gaGFkIGludmFsaWQgdHlwZSAoSW50ZWdlcikgZm9yIFNjb3BlIG9wZXJh dG9yLCBjaGFuZ2VkIHRvIHR5cGUgQU5ZDQogKDIwMTAxMDEzL2Rzd2xvYWQt ODA4KQ0KQUNQSSBXYXJuaW5nOiBUeXBlIG92ZXJyaWRlIC0gW09FTV9dIGhh ZCBpbnZhbGlkIHR5cGUgKEludGVnZXIpIGZvciBTY29wZSBvcGVyYXRvciwg Y2hhbmdlZCB0byB0eXBlIEFOWQ0KICgyMDEwMTAxMy9kc3dsb2FkLTgwOCkN CmlvYXBpYzA6IHJvdXRpbmcgaW50cGluIDkgKElTQSBJUlEgOSkgdG8gbGFw aWMgMCB2ZWN0b3IgNDgNCmFjcGkwOiBbTVBTQUZFXQ0KYWNwaTA6IFtJVEhS RUFEXQ0KYWNwaTA6IFBvd2VyIEJ1dHRvbiAoZml4ZWQpDQphY3BpMDogd2Fr ZXVwIGNvZGUgdmEgMHhjNGRiZDAwMCBwYSAweDEwMDANCnBjaV9vcGVuKDEp Ogltb2RlIDEgYWRkciBwb3J0ICgweDBjZjgpIGlzIDB4ODAwMDc4YWMNCnBj aV9vcGVuKDFhKToJbW9kZTFyZXM9MHg4MDAwMDAwMCAoMHg4MDAwMDAwMCkN CnBjaV9jZmdjaGVjazoJZGV2aWNlIDAgW2NsYXNzPTA2MDAwMF0gW2hkcj04 MF0gaXMgdGhlcmUgKGlkPTAwMTcxMTY2KQ0KcGNpYmlvczogQklPUyB2ZXJz aW9uIDIuMTANCnVua25vd246IEkvTyByYW5nZSBub3Qgc3VwcG9ydGVkDQph Y3BpMDogcmVzZXJ2YXRpb24gb2YgMCwgYTAwMDAgKDMpIGZhaWxlZA0KYWNw aTA6IHJlc2VydmF0aW9uIG9mIDEwMDAwMCwgM2ZmMDAwMDAgKDMpIGZhaWxl ZA0KQUNQSSB0aW1lcjogMS8yIDAvMyAxLzIgMS8yIDAvMyAxLzIgMC8zIDEv MiAwLzMgMC80IC0+IDUNClRpbWVjb3VudGVyICJBQ1BJLXNhZmUiIGZyZXF1 ZW5jeSAzNTc5NTQ1IEh6IHF1YWxpdHkgODUwDQphY3BpX3RpbWVyMDogPDMy LWJpdCB0aW1lciBhdCAzLjU3OTU0NU1Iej4gcG9ydCAweDUwOC0weDUwYiBv biBhY3BpMA0KY3B1MDogPEFDUEkgQ1BVPiBvbiBhY3BpMA0KY3B1MDogc3dp dGNoaW5nIHRvIGdlbmVyaWMgQ3ggbW9kZQ0KQUNQSTogUHJvY2Vzc29yIFxc X1BSXy5DUFUxIChBQ1BJIElEIDEpIGlnbm9yZWQNCkFDUEk6IFByb2Nlc3Nv ciBcXF9QUl8uQ1BVMiAoQUNQSSBJRCAyKSBpZ25vcmVkDQpBQ1BJOiBQcm9j ZXNzb3IgXFxfUFJfLkNQVTMgKEFDUEkgSUQgMykgaWdub3JlZA0KQUNQSTog UHJvY2Vzc29yIFxcX1BSXy5DUFU0IChBQ1BJIElEIDQpIGlnbm9yZWQNCkFD UEk6IFByb2Nlc3NvciBcXF9QUl8uQ1BVNSAoQUNQSSBJRCA1KSBpZ25vcmVk DQpBQ1BJOiBQcm9jZXNzb3IgXFxfUFJfLkNQVTYgKEFDUEkgSUQgNikgaWdu b3JlZA0KQUNQSTogUHJvY2Vzc29yIFxcX1BSXy5DUFU3IChBQ1BJIElEIDcp IGlnbm9yZWQNCnBjaV9saW5rMDogICAgICAgIEluZGV4ICBJUlEgIFJ0ZCAg UmVmICBJUlFzDQogIEluaXRpYWwgUHJvYmUgICAgICAgMCAgMjU1ICAgTiAg ICAgMCAgMyA0IDUgNyA5IDExIDEyIDE0IDE1DQogIFZhbGlkYXRpb24gICAg ICAgICAgMCAgMjU1ICAgTiAgICAgMCAgMyA0IDUgNyA5IDExIDEyIDE0IDE1 DQogIEFmdGVyIERpc2FibGUgICAgICAgMCAgMjU1ICAgTiAgICAgMCAgMyA0 IDUgNyA5IDExIDEyIDE0IDE1DQpwY2lfbGluazE6ICAgICAgICBJbmRleCAg SVJRICBSdGQgIFJlZiAgSVJRcw0KICBJbml0aWFsIFByb2JlICAgICAgIDAg IDI1NSAgIE4gICAgIDAgIDMgNCA1IDcgOSAxMSAxMiAxNCAxNQ0KICBWYWxp ZGF0aW9uICAgICAgICAgIDAgIDI1NSAgIE4gICAgIDAgIDMgNCA1IDcgOSAx MSAxMiAxNCAxNQ0KICBBZnRlciBEaXNhYmxlICAgICAgIDAgIDI1NSAgIE4g ICAgIDAgIDMgNCA1IDcgOSAxMSAxMiAxNCAxNQ0KcGNpX2xpbmsyOiAgICAg ICAgSW5kZXggIElSUSAgUnRkICBSZWYgIElSUXMNCiAgSW5pdGlhbCBQcm9i ZSAgICAgICAwICAyNTUgICBOICAgICAwICAzIDQgNSA3IDkgMTEgMTIgMTQg MTUNCiAgVmFsaWRhdGlvbiAgICAgICAgICAwICAyNTUgICBOICAgICAwICAz IDQgNSA3IDkgMTEgMTIgMTQgMTUNCiAgQWZ0ZXIgRGlzYWJsZSAgICAgICAw ICAyNTUgICBOICAgICAwICAzIDQgNSA3IDkgMTEgMTIgMTQgMTUNCnBjaV9s aW5rMzogICAgICAgIEluZGV4ICBJUlEgIFJ0ZCAgUmVmICBJUlFzDQogIElu aXRpYWwgUHJvYmUgICAgICAgMCAgMjU1ICAgTiAgICAgMCAgMyA0IDUgNyA5 IDExIDEyIDE0IDE1DQogIFZhbGlkYXRpb24gICAgICAgICAgMCAgMjU1ICAg TiAgICAgMCAgMyA0IDUgNyA5IDExIDEyIDE0IDE1DQogIEFmdGVyIERpc2Fi bGUgICAgICAgMCAgMjU1ICAgTiAgICAgMCAgMyA0IDUgNyA5IDExIDEyIDE0 IDE1DQpwY2lfbGluazQ6ICAgICAgICBJbmRleCAgSVJRICBSdGQgIFJlZiAg SVJRcw0KICBJbml0aWFsIFByb2JlICAgICAgIDAgIDI1NSAgIE4gICAgIDAg IDMgNCA1IDcgOSAxMSAxMiAxNCAxNQ0KICBWYWxpZGF0aW9uICAgICAgICAg IDAgIDI1NSAgIE4gICAgIDAgIDMgNCA1IDcgOSAxMSAxMiAxNCAxNQ0KICBB ZnRlciBEaXNhYmxlICAgICAgIDAgIDI1NSAgIE4gICAgIDAgIDMgNCA1IDcg OSAxMSAxMiAxNCAxNQ0KcGNpX2xpbms1OiAgICAgICAgSW5kZXggIElSUSAg UnRkICBSZWYgIElSUXMNCiAgSW5pdGlhbCBQcm9iZSAgICAgICAwICAyNTUg ICBOICAgICAwICAzIDQgNSA3IDkgMTEgMTIgMTQgMTUNCiAgVmFsaWRhdGlv biAgICAgICAgICAwICAyNTUgICBOICAgICAwICAzIDQgNSA3IDkgMTEgMTIg MTQgMTUNCiAgQWZ0ZXIgRGlzYWJsZSAgICAgICAwICAyNTUgICBOICAgICAw ICAzIDQgNSA3IDkgMTEgMTIgMTQgMTUNCnBjaV9saW5rNjogICAgICAgIElu ZGV4ICBJUlEgIFJ0ZCAgUmVmICBJUlFzDQogIEluaXRpYWwgUHJvYmUgICAg ICAgMCAgMjU1ICAgTiAgICAgMCAgMyA0IDUgNyA5IDExIDEyIDE0IDE1DQog IFZhbGlkYXRpb24gICAgICAgICAgMCAgMjU1ICAgTiAgICAgMCAgMyA0IDUg NyA5IDExIDEyIDE0IDE1DQogIEFmdGVyIERpc2FibGUgICAgICAgMCAgMjU1 ICAgTiAgICAgMCAgMyA0IDUgNyA5IDExIDEyIDE0IDE1DQpwY2lfbGluazc6 ICAgICAgICBJbmRleCAgSVJRICBSdGQgIFJlZiAgSVJRcw0KICBJbml0aWFs IFByb2JlICAgICAgIDAgIDI1NSAgIE4gICAgIDAgIDMgNCA1IDcgOSAxMSAx MiAxNCAxNQ0KICBWYWxpZGF0aW9uICAgICAgICAgIDAgIDI1NSAgIE4gICAg IDAgIDMgNCA1IDcgOSAxMSAxMiAxNCAxNQ0KICBBZnRlciBEaXNhYmxlICAg ICAgIDAgIDI1NSAgIE4gICAgIDAgIDMgNCA1IDcgOSAxMSAxMiAxNCAxNQ0K cGNpX2xpbms4OiAgICAgICAgSW5kZXggIElSUSAgUnRkICBSZWYgIElSUXMN CiAgSW5pdGlhbCBQcm9iZSAgICAgICAwICAyNTUgICBOICAgICAwICAzIDQg NSA3IDkgMTEgMTIgMTQgMTUNCiAgVmFsaWRhdGlvbiAgICAgICAgICAwICAy NTUgICBOICAgICAwICAzIDQgNSA3IDkgMTEgMTIgMTQgMTUNCiAgQWZ0ZXIg RGlzYWJsZSAgICAgICAwICAyNTUgICBOICAgICAwICAzIDQgNSA3IDkgMTEg MTIgMTQgMTUNCnBjaV9saW5rOTogICAgICAgIEluZGV4ICBJUlEgIFJ0ZCAg UmVmICBJUlFzDQogIEluaXRpYWwgUHJvYmUgICAgICAgMCAgMjU1ICAgTiAg ICAgMCAgMyA0IDUgNyA5IDExIDEyIDE0IDE1DQogIFZhbGlkYXRpb24gICAg ICAgICAgMCAgMjU1ICAgTiAgICAgMCAgMyA0IDUgNyA5IDExIDEyIDE0IDE1 DQogIEFmdGVyIERpc2FibGUgICAgICAgMCAgMjU1ICAgTiAgICAgMCAgMyA0 IDUgNyA5IDExIDEyIDE0IDE1DQpwY2lfbGluazEwOiAgICAgICBJbmRleCAg SVJRICBSdGQgIFJlZiAgSVJRcw0KICBJbml0aWFsIFByb2JlICAgICAgIDAg IDI1NSAgIE4gICAgIDAgIDMgNCA1IDcgOSAxMSAxMiAxNCAxNQ0KICBWYWxp ZGF0aW9uICAgICAgICAgIDAgIDI1NSAgIE4gICAgIDAgIDMgNCA1IDcgOSAx MSAxMiAxNCAxNQ0KICBBZnRlciBEaXNhYmxlICAgICAgIDAgIDI1NSAgIE4g ICAgIDAgIDMgNCA1IDcgOSAxMSAxMiAxNCAxNQ0KcGNpX2xpbmsxMTogICAg ICAgSW5kZXggIElSUSAgUnRkICBSZWYgIElSUXMNCiAgSW5pdGlhbCBQcm9i ZSAgICAgICAwICAyNTUgICBOICAgICAwICAzIDQgNSA3IDkgMTEgMTIgMTQg MTUNCiAgVmFsaWRhdGlvbiAgICAgICAgICAwICAyNTUgICBOICAgICAwICAz IDQgNSA3IDkgMTEgMTIgMTQgMTUNCiAgQWZ0ZXIgRGlzYWJsZSAgICAgICAw ICAyNTUgICBOICAgICAwICAzIDQgNSA3IDkgMTEgMTIgMTQgMTUNCnBjaV9s aW5rMTI6ICAgICAgIEluZGV4ICBJUlEgIFJ0ZCAgUmVmICBJUlFzDQogIElu aXRpYWwgUHJvYmUgICAgICAgMCAgMjU1ICAgTiAgICAgMCAgMyA0IDUgNyA5 IDExIDEyIDE0IDE1DQogIFZhbGlkYXRpb24gICAgICAgICAgMCAgMjU1ICAg TiAgICAgMCAgMyA0IDUgNyA5IDExIDEyIDE0IDE1DQogIEFmdGVyIERpc2Fi bGUgICAgICAgMCAgMjU1ICAgTiAgICAgMCAgMyA0IDUgNyA5IDExIDEyIDE0 IDE1DQpwY2lfbGluazEzOiAgICAgICBJbmRleCAgSVJRICBSdGQgIFJlZiAg SVJRcw0KICBJbml0aWFsIFByb2JlICAgICAgIDAgIDI1NSAgIE4gICAgIDAg IDMgNCA1IDcgOSAxMSAxMiAxNCAxNQ0KICBWYWxpZGF0aW9uICAgICAgICAg IDAgIDI1NSAgIE4gICAgIDAgIDMgNCA1IDcgOSAxMSAxMiAxNCAxNQ0KICBB ZnRlciBEaXNhYmxlICAgICAgIDAgIDI1NSAgIE4gICAgIDAgIDMgNCA1IDcg OSAxMSAxMiAxNCAxNQ0KcGNpX2xpbmsxNDogICAgICAgSW5kZXggIElSUSAg UnRkICBSZWYgIElSUXMNCiAgSW5pdGlhbCBQcm9iZSAgICAgICAwICAyNTUg ICBOICAgICAwICAzIDQgNSA3IDkgMTEgMTIgMTQgMTUNCiAgVmFsaWRhdGlv biAgICAgICAgICAwICAyNTUgICBOICAgICAwICAzIDQgNSA3IDkgMTEgMTIg MTQgMTUNCiAgQWZ0ZXIgRGlzYWJsZSAgICAgICAwICAyNTUgICBOICAgICAw ICAzIDQgNSA3IDkgMTEgMTIgMTQgMTUNCnBjaV9saW5rMTU6ICAgICAgIElu ZGV4ICBJUlEgIFJ0ZCAgUmVmICBJUlFzDQogIEluaXRpYWwgUHJvYmUgICAg ICAgMCAgMjU1ICAgTiAgICAgMCAgMyA0IDUgNyA5IDExIDEyIDE0IDE1DQog IFZhbGlkYXRpb24gICAgICAgICAgMCAgMjU1ICAgTiAgICAgMCAgMyA0IDUg NyA5IDExIDEyIDE0IDE1DQogIEFmdGVyIERpc2FibGUgICAgICAgMCAgMjU1 ICAgTiAgICAgMCAgMyA0IDUgNyA5IDExIDEyIDE0IDE1DQpwY2lfbGluazE2 OiAgICAgICBJbmRleCAgSVJRICBSdGQgIFJlZiAgSVJRcw0KICBJbml0aWFs IFByb2JlICAgICAgIDAgIDI1NSAgIE4gICAgIDAgIDMgNCA1IDcgOSAxMSAx MiAxNCAxNQ0KICBWYWxpZGF0aW9uICAgICAgICAgIDAgIDI1NSAgIE4gICAg IDAgIDMgNCA1IDcgOSAxMSAxMiAxNCAxNQ0KICBBZnRlciBEaXNhYmxlICAg ICAgIDAgIDI1NSAgIE4gICAgIDAgIDMgNCA1IDcgOSAxMSAxMiAxNCAxNQ0K cGNpX2xpbmsxNzogICAgICAgSW5kZXggIElSUSAgUnRkICBSZWYgIElSUXMN CiAgSW5pdGlhbCBQcm9iZSAgICAgICAwICAyNTUgICBOICAgICAwICAzIDQg NSA3IDkgMTEgMTIgMTQgMTUNCiAgVmFsaWRhdGlvbiAgICAgICAgICAwICAy NTUgICBOICAgICAwICAzIDQgNSA3IDkgMTEgMTIgMTQgMTUNCiAgQWZ0ZXIg RGlzYWJsZSAgICAgICAwICAyNTUgICBOICAgICAwICAzIDQgNSA3IDkgMTEg MTIgMTQgMTUNCnBjaV9saW5rMTg6ICAgICAgIEluZGV4ICBJUlEgIFJ0ZCAg UmVmICBJUlFzDQogIEluaXRpYWwgUHJvYmUgICAgICAgMCAgMjU1ICAgTiAg ICAgMCAgMyA0IDUgNyA5IDExIDEyIDE0IDE1DQogIFZhbGlkYXRpb24gICAg ICAgICAgMCAgMjU1ICAgTiAgICAgMCAgMyA0IDUgNyA5IDExIDEyIDE0IDE1 DQogIEFmdGVyIERpc2FibGUgICAgICAgMCAgMjU1ICAgTiAgICAgMCAgMyA0 IDUgNyA5IDExIDEyIDE0IDE1DQpwY2lfbGluazE5OiAgICAgICBJbmRleCAg SVJRICBSdGQgIFJlZiAgSVJRcw0KICBJbml0aWFsIFByb2JlICAgICAgIDAg IDI1NSAgIE4gICAgIDAgIDMgNCA1IDcgOSAxMSAxMiAxNCAxNQ0KICBWYWxp ZGF0aW9uICAgICAgICAgIDAgIDI1NSAgIE4gICAgIDAgIDMgNCA1IDcgOSAx MSAxMiAxNCAxNQ0KICBBZnRlciBEaXNhYmxlICAgICAgIDAgIDI1NSAgIE4g ICAgIDAgIDMgNCA1IDcgOSAxMSAxMiAxNCAxNQ0KcGNpX2xpbmsyMDogICAg ICAgSW5kZXggIElSUSAgUnRkICBSZWYgIElSUXMNCiAgSW5pdGlhbCBQcm9i ZSAgICAgICAwICAyNTUgICBOICAgICAwICAzIDQgNSA3IDkgMTEgMTIgMTQg MTUNCiAgVmFsaWRhdGlvbiAgICAgICAgICAwICAyNTUgICBOICAgICAwICAz IDQgNSA3IDkgMTEgMTIgMTQgMTUNCiAgQWZ0ZXIgRGlzYWJsZSAgICAgICAw ICAyNTUgICBOICAgICAwICAzIDQgNSA3IDkgMTEgMTIgMTQgMTUNCnBjaV9s aW5rMjE6ICAgICAgIEluZGV4ICBJUlEgIFJ0ZCAgUmVmICBJUlFzDQogIElu aXRpYWwgUHJvYmUgICAgICAgMCAgMjU1ICAgTiAgICAgMCAgMyA0IDUgNyA5 IDExIDEyIDE0IDE1DQogIFZhbGlkYXRpb24gICAgICAgICAgMCAgMjU1ICAg TiAgICAgMCAgMyA0IDUgNyA5IDExIDEyIDE0IDE1DQogIEFmdGVyIERpc2Fi bGUgICAgICAgMCAgMjU1ICAgTiAgICAgMCAgMyA0IDUgNyA5IDExIDEyIDE0 IDE1DQpwY2lfbGluazIyOiAgICAgICBJbmRleCAgSVJRICBSdGQgIFJlZiAg SVJRcw0KICBJbml0aWFsIFByb2JlICAgICAgIDAgIDI1NSAgIE4gICAgIDAg IDMgNCA1IDcgOSAxMSAxMiAxNCAxNQ0KICBWYWxpZGF0aW9uICAgICAgICAg IDAgIDI1NSAgIE4gICAgIDAgIDMgNCA1IDcgOSAxMSAxMiAxNCAxNQ0KICBB ZnRlciBEaXNhYmxlICAgICAgIDAgIDI1NSAgIE4gICAgIDAgIDMgNCA1IDcg OSAxMSAxMiAxNCAxNQ0KcGNpX2xpbmsyMzogICAgICAgSW5kZXggIElSUSAg UnRkICBSZWYgIElSUXMNCiAgSW5pdGlhbCBQcm9iZSAgICAgICAwICAyNTUg ICBOICAgICAwICAzIDQgNSA3IDkgMTEgMTIgMTQgMTUNCiAgVmFsaWRhdGlv biAgICAgICAgICAwICAyNTUgICBOICAgICAwICAzIDQgNSA3IDkgMTEgMTIg MTQgMTUNCiAgQWZ0ZXIgRGlzYWJsZSAgICAgICAwICAyNTUgICBOICAgICAw ICAzIDQgNSA3IDkgMTEgMTIgMTQgMTUNCnBjaV9saW5rMjQ6ICAgICAgIElu ZGV4ICBJUlEgIFJ0ZCAgUmVmICBJUlFzDQogIEluaXRpYWwgUHJvYmUgICAg ICAgMCAgMjU1ICAgTiAgICAgMCAgMyA0IDUgNyA5IDExIDEyIDE0IDE1DQog IFZhbGlkYXRpb24gICAgICAgICAgMCAgMjU1ICAgTiAgICAgMCAgMyA0IDUg NyA5IDExIDEyIDE0IDE1DQogIEFmdGVyIERpc2FibGUgICAgICAgMCAgMjU1 ICAgTiAgICAgMCAgMyA0IDUgNyA5IDExIDEyIDE0IDE1DQpwY2lfbGluazI1 OiAgICAgICBJbmRleCAgSVJRICBSdGQgIFJlZiAgSVJRcw0KICBJbml0aWFs IFByb2JlICAgICAgIDAgIDI1NSAgIE4gICAgIDAgIDMgNCA1IDcgOSAxMSAx MiAxNCAxNQ0KICBWYWxpZGF0aW9uICAgICAgICAgIDAgIDI1NSAgIE4gICAg IDAgIDMgNCA1IDcgOSAxMSAxMiAxNCAxNQ0KICBBZnRlciBEaXNhYmxlICAg ICAgIDAgIDI1NSAgIE4gICAgIDAgIDMgNCA1IDcgOSAxMSAxMiAxNCAxNQ0K cGNpX2xpbmsyNjogICAgICAgSW5kZXggIElSUSAgUnRkICBSZWYgIElSUXMN CiAgSW5pdGlhbCBQcm9iZSAgICAgICAwICAyNTUgICBOICAgICAwICAzIDQg NSA3IDkgMTEgMTIgMTQgMTUNCiAgVmFsaWRhdGlvbiAgICAgICAgICAwICAy NTUgICBOICAgICAwICAzIDQgNSA3IDkgMTEgMTIgMTQgMTUNCiAgQWZ0ZXIg RGlzYWJsZSAgICAgICAwICAyNTUgICBOICAgICAwICAzIDQgNSA3IDkgMTEg MTIgMTQgMTUNCnBjaV9saW5rMjc6ICAgICAgIEluZGV4ICBJUlEgIFJ0ZCAg UmVmICBJUlFzDQogIEluaXRpYWwgUHJvYmUgICAgICAgMCAgMjU1ICAgTiAg ICAgMCAgMyA0IDUgNyA5IDExIDEyIDE0IDE1DQogIFZhbGlkYXRpb24gICAg ICAgICAgMCAgMjU1ICAgTiAgICAgMCAgMyA0IDUgNyA5IDExIDEyIDE0IDE1 DQogIEFmdGVyIERpc2FibGUgICAgICAgMCAgMjU1ICAgTiAgICAgMCAgMyA0 IDUgNyA5IDExIDEyIDE0IDE1DQpwY2lfbGluazI4OiAgICAgICBJbmRleCAg SVJRICBSdGQgIFJlZiAgSVJRcw0KICBJbml0aWFsIFByb2JlICAgICAgIDAg IDI1NSAgIE4gICAgIDAgIDMgNCA1IDcgOSAxMSAxMiAxNCAxNQ0KICBWYWxp ZGF0aW9uICAgICAgICAgIDAgIDI1NSAgIE4gICAgIDAgIDMgNCA1IDcgOSAx MSAxMiAxNCAxNQ0KICBBZnRlciBEaXNhYmxlICAgICAgIDAgIDI1NSAgIE4g ICAgIDAgIDMgNCA1IDcgOSAxMSAxMiAxNCAxNQ0KcGNpX2xpbmsyOTogICAg ICAgSW5kZXggIElSUSAgUnRkICBSZWYgIElSUXMNCiAgSW5pdGlhbCBQcm9i ZSAgICAgICAwICAyNTUgICBOICAgICAwICAzIDQgNSA3IDkgMTEgMTIgMTQg MTUNCiAgVmFsaWRhdGlvbiAgICAgICAgICAwICAyNTUgICBOICAgICAwICAz IDQgNSA3IDkgMTEgMTIgMTQgMTUNCiAgQWZ0ZXIgRGlzYWJsZSAgICAgICAw ICAyNTUgICBOICAgICAwICAzIDQgNSA3IDkgMTEgMTIgMTQgMTUNCnBjaV9s aW5rMzA6ICAgICAgIEluZGV4ICBJUlEgIFJ0ZCAgUmVmICBJUlFzDQogIElu aXRpYWwgUHJvYmUgICAgICAgMCAgMjU1ICAgTiAgICAgMCAgMyA0IDUgNyA5 IDExIDEyIDE0IDE1DQogIFZhbGlkYXRpb24gICAgICAgICAgMCAgMjU1ICAg TiAgICAgMCAgMyA0IDUgNyA5IDExIDEyIDE0IDE1DQogIEFmdGVyIERpc2Fi bGUgICAgICAgMCAgMjU1ICAgTiAgICAgMCAgMyA0IDUgNyA5IDExIDEyIDE0 IDE1DQpwY2lfbGluazMxOiAgICAgICBJbmRleCAgSVJRICBSdGQgIFJlZiAg SVJRcw0KICBJbml0aWFsIFByb2JlICAgICAgIDAgIDI1NSAgIE4gICAgIDAg IDMgNCA1IDcgOSAxMSAxMiAxNCAxNQ0KICBWYWxpZGF0aW9uICAgICAgICAg IDAgIDI1NSAgIE4gICAgIDAgIDMgNCA1IDcgOSAxMSAxMiAxNCAxNQ0KICBB ZnRlciBEaXNhYmxlICAgICAgIDAgIDI1NSAgIE4gICAgIDAgIDMgNCA1IDcg OSAxMSAxMiAxNCAxNQ0KcGNpX2xpbmszMjogICAgICAgSW5kZXggIElSUSAg UnRkICBSZWYgIElSUXMNCiAgSW5pdGlhbCBQcm9iZSAgICAgICAwICAgMTAg ICBOICAgICAwICAxMA0KICBWYWxpZGF0aW9uICAgICAgICAgIDAgICAxMCAg IE4gICAgIDAgIDEwDQogIEFmdGVyIERpc2FibGUgICAgICAgMCAgMjU1ICAg TiAgICAgMCAgMTANCnBjaV9saW5rMzM6ICAgICAgIEluZGV4ICBJUlEgIFJ0 ZCAgUmVmICBJUlFzDQogIEluaXRpYWwgUHJvYmUgICAgICAgMCAgMjU1ICAg TiAgICAgMCAgMTENCiAgVmFsaWRhdGlvbiAgICAgICAgICAwICAyNTUgICBO ICAgICAwICAxMQ0KICBBZnRlciBEaXNhYmxlICAgICAgIDAgIDI1NSAgIE4g ICAgIDAgIDExDQphY3BpX2J1dHRvbjA6IDxTbGVlcCBCdXR0b24+IG9uIGFj cGkwDQpwY2liMDogPEFDUEkgSG9zdC1QQ0kgYnJpZGdlPiBwb3J0IDB4Y2Y4 LTB4Y2ZmIG9uIGFjcGkwDQpBQ1BJOiBGb3VuZCBtYXRjaGluZyBwaW4gZm9y IDAuMTUuSU5UQSBhdCBmdW5jIDI6IDEwDQpwY2kwOiA8QUNQSSBQQ0kgYnVz PiBvbiBwY2liMA0KcGNpMDogZG9tYWluPTAsIHBoeXNpY2FsIGJ1cz0wDQpm b3VuZC0+CXZlbmRvcj0weDExNjYsIGRldj0weDAwMTcsIHJldmlkPTB4MzIN Cglkb21haW49MCwgYnVzPTAsIHNsb3Q9MCwgZnVuYz0wDQoJY2xhc3M9MDYt MDAtMDAsIGhkcnR5cGU9MHgwMCwgbWZkZXY9MQ0KCWNtZHJlZz0weDAwMDAs IHN0YXRyZWc9MHgwMDAwLCBjYWNoZWxuc3o9MTYgKGR3b3JkcykNCglsYXR0 aW1lcj0weDAwICgwIG5zKSwgbWluZ250PTB4MDAgKDAgbnMpLCBtYXhsYXQ9 MHgwMCAoMCBucykNCmZvdW5kLT4JdmVuZG9yPTB4MTE2NiwgZGV2PTB4MDAx NywgcmV2aWQ9MHgwMA0KCWRvbWFpbj0wLCBidXM9MCwgc2xvdD0wLCBmdW5j PTENCgljbGFzcz0wNi0wMC0wMCwgaGRydHlwZT0weDAwLCBtZmRldj0xDQoJ Y21kcmVnPTB4MDAwMCwgc3RhdHJlZz0weDAwMDAsIGNhY2hlbG5zej0xNiAo ZHdvcmRzKQ0KCWxhdHRpbWVyPTB4MDAgKDAgbnMpLCBtaW5nbnQ9MHgwMCAo MCBucyksIG1heGxhdD0weDAwICgwIG5zKQ0KZm91bmQtPgl2ZW5kb3I9MHg4 MDg2LCBkZXY9MHgxMDI2LCByZXZpZD0weDA0DQoJZG9tYWluPTAsIGJ1cz0w LCBzbG90PTEsIGZ1bmM9MA0KCWNsYXNzPTAyLTAwLTAwLCBoZHJ0eXBlPTB4 MDAsIG1mZGV2PTANCgljbWRyZWc9MHgwMTE3LCBzdGF0cmVnPTB4MDIzMCwg Y2FjaGVsbnN6PTE2IChkd29yZHMpDQoJbGF0dGltZXI9MHg0MCAoMTkyMCBu cyksIG1pbmdudD0weGZmICg2Mzc1MCBucyksIG1heGxhdD0weDAwICgwIG5z KQ0KCWludHBpbj1hLCBpcnE9NQ0KCXBvd2Vyc3BlYyAyICBzdXBwb3J0cyBE MCBEMyAgY3VycmVudCBEMA0KCW1hcFsxMF06IHR5cGUgTWVtb3J5LCByYW5n ZSA2NCwgYmFzZSAweGZlYjYwMDAwLCBzaXplIDE3LCBlbmFibGVkDQoJbWFw WzE4XTogdHlwZSBNZW1vcnksIHJhbmdlIDY0LCBiYXNlIDB4ZmViMDAwMDAs IHNpemUgMTgsIGVuYWJsZWQNCgltYXBbMjBdOiB0eXBlIEkvTyBQb3J0LCBy YW5nZSAzMiwgYmFzZSAweGUwMDAsIHNpemUgIDYsIGVuYWJsZWQNCnBjaWIw OiBtYXRjaGVkIGVudHJ5IGZvciAwLjEuSU5UQQ0KcGNpYjA6IHNsb3QgMSBJ TlRBIGhhcmR3aXJlZCB0byBJUlEgMTYNCmZvdW5kLT4JdmVuZG9yPTB4MTAw MiwgZGV2PTB4NDc1MiwgcmV2aWQ9MHgyNw0KCWRvbWFpbj0wLCBidXM9MCwg c2xvdD02LCBmdW5jPTANCgljbGFzcz0wMy0wMC0wMCwgaGRydHlwZT0weDAw LCBtZmRldj0wDQoJY21kcmVnPTB4MDA4Nywgc3RhdHJlZz0weDAyOTAsIGNh Y2hlbG5zej0xNiAoZHdvcmRzKQ0KCWxhdHRpbWVyPTB4NDAgKDE5MjAgbnMp LCBtaW5nbnQ9MHgwOCAoMjAwMCBucyksIG1heGxhdD0weDAwICgwIG5zKQ0K CWludHBpbj1hLCBpcnE9MTANCglwb3dlcnNwZWMgMiAgc3VwcG9ydHMgRDAg RDEgRDIgRDMgIGN1cnJlbnQgRDANCgltYXBbMTBdOiB0eXBlIE1lbW9yeSwg cmFuZ2UgMzIsIGJhc2UgMHhmZDAwMDAwMCwgc2l6ZSAyNCwgZW5hYmxlZA0K CW1hcFsxNF06IHR5cGUgSS9PIFBvcnQsIHJhbmdlIDMyLCBiYXNlIDB4ZTgw MCwgc2l6ZSAgOCwgZW5hYmxlZA0KCW1hcFsxOF06IHR5cGUgTWVtb3J5LCBy YW5nZSAzMiwgYmFzZSAweGZlYmZmMDAwLCBzaXplIDEyLCBlbmFibGVkDQpw Y2liMDogbWF0Y2hlZCBlbnRyeSBmb3IgMC42LklOVEENCnBjaWIwOiBzbG90 IDYgSU5UQSBoYXJkd2lyZWQgdG8gSVJRIDI2DQpmb3VuZC0+CXZlbmRvcj0w eDgwODYsIGRldj0weDEyMjksIHJldmlkPTB4MTANCglkb21haW49MCwgYnVz PTAsIHNsb3Q9NywgZnVuYz0wDQoJY2xhc3M9MDItMDAtMDAsIGhkcnR5cGU9 MHgwMCwgbWZkZXY9MA0KCWNtZHJlZz0weDAxMTcsIHN0YXRyZWc9MHgwMjkw LCBjYWNoZWxuc3o9MTYgKGR3b3JkcykNCglsYXR0aW1lcj0weDQwICgxOTIw IG5zKSwgbWluZ250PTB4MDggKDIwMDAgbnMpLCBtYXhsYXQ9MHgzOCAoMTQw MDAgbnMpDQoJaW50cGluPWEsIGlycT05DQoJcG93ZXJzcGVjIDIgIHN1cHBv cnRzIEQwIEQxIEQyIEQzICBjdXJyZW50IEQwDQoJbWFwWzEwXTogdHlwZSBN ZW1vcnksIHJhbmdlIDMyLCBiYXNlIDB4ZmViZmQwMDAsIHNpemUgMTIsIGVu YWJsZWQNCgltYXBbMTRdOiB0eXBlIEkvTyBQb3J0LCByYW5nZSAzMiwgYmFz ZSAweGU0MDAsIHNpemUgIDYsIGVuYWJsZWQNCgltYXBbMThdOiB0eXBlIE1l bW9yeSwgcmFuZ2UgMzIsIGJhc2UgMHhmZWI4MDAwMCwgc2l6ZSAxNywgZW5h YmxlZA0KcGNpYjA6IG1hdGNoZWQgZW50cnkgZm9yIDAuNy5JTlRBDQpwY2li MDogc2xvdCA3IElOVEEgaGFyZHdpcmVkIHRvIElSUSAyNw0KZm91bmQtPgl2 ZW5kb3I9MHgxNGU0LCBkZXY9MHgxNmE2LCByZXZpZD0weDAyDQoJZG9tYWlu PTAsIGJ1cz0wLCBzbG90PTgsIGZ1bmM9MA0KCWNsYXNzPTAyLTAwLTAwLCBo ZHJ0eXBlPTB4MDAsIG1mZGV2PTANCgljbWRyZWc9MHgwMTE2LCBzdGF0cmVn PTB4MDJiMCwgY2FjaGVsbnN6PTE2IChkd29yZHMpDQoJbGF0dGltZXI9MHg0 MCAoMTkyMCBucyksIG1pbmdudD0weDQwICgxNjAwMCBucyksIG1heGxhdD0w eDAwICgwIG5zKQ0KCWludHBpbj1hLCBpcnE9MTENCglwb3dlcnNwZWMgMiAg c3VwcG9ydHMgRDAgRDMgIGN1cnJlbnQgRDANCglNU0kgc3VwcG9ydHMgOCBt ZXNzYWdlcywgNjQgYml0DQoJbWFwWzEwXTogdHlwZSBNZW1vcnksIHJhbmdl IDY0LCBiYXNlIDB4ZmViZTAwMDAsIHNpemUgMTYsIGVuYWJsZWQNCnBjaWIw OiBtYXRjaGVkIGVudHJ5IGZvciAwLjguSU5UQQ0KcGNpYjA6IHNsb3QgOCBJ TlRBIGhhcmR3aXJlZCB0byBJUlEgMjgNCmZvdW5kLT4JdmVuZG9yPTB4MTE2 NiwgZGV2PTB4MDIwMywgcmV2aWQ9MHhhMA0KCWRvbWFpbj0wLCBidXM9MCwg c2xvdD0xNSwgZnVuYz0wDQoJY2xhc3M9MDYtMDAtMDAsIGhkcnR5cGU9MHgw MCwgbWZkZXY9MQ0KCWNtZHJlZz0weDAxMDcsIHN0YXRyZWc9MHgyMjAwLCBj YWNoZWxuc3o9MCAoZHdvcmRzKQ0KCWxhdHRpbWVyPTB4NDAgKDE5MjAgbnMp LCBtaW5nbnQ9MHgwMCAoMCBucyksIG1heGxhdD0weDAwICgwIG5zKQ0KZm91 bmQtPgl2ZW5kb3I9MHgxMTY2LCBkZXY9MHgwMjEzLCByZXZpZD0weGEwDQoJ ZG9tYWluPTAsIGJ1cz0wLCBzbG90PTE1LCBmdW5jPTENCgljbGFzcz0wMS0w MS04YSwgaGRydHlwZT0weDAwLCBtZmRldj0xDQoJY21kcmVnPTB4MDAxNSwg c3RhdHJlZz0weDAyMDAsIGNhY2hlbG5zej04IChkd29yZHMpDQoJbGF0dGlt ZXI9MHg0MCAoMTkyMCBucyksIG1pbmdudD0weDAwICgwIG5zKSwgbWF4bGF0 PTB4MDAgKDAgbnMpDQoJbWFwWzIwXTogdHlwZSBJL08gUG9ydCwgcmFuZ2Ug MzIsIGJhc2UgMHhmZmEwLCBzaXplICA0LCBlbmFibGVkDQpmb3VuZC0+CXZl bmRvcj0weDExNjYsIGRldj0weDAyMjEsIHJldmlkPTB4MDUNCglkb21haW49 MCwgYnVzPTAsIHNsb3Q9MTUsIGZ1bmM9Mg0KCWNsYXNzPTBjLTAzLTEwLCBo ZHJ0eXBlPTB4MDAsIG1mZGV2PTENCgljbWRyZWc9MHgwMTE3LCBzdGF0cmVn PTB4MDI4MCwgY2FjaGVsbnN6PTAgKGR3b3JkcykNCglsYXR0aW1lcj0weDQw ICgxOTIwIG5zKSwgbWluZ250PTB4MDAgKDAgbnMpLCBtYXhsYXQ9MHg1MCAo MjAwMDAgbnMpDQoJaW50cGluPWEsIGlycT0xMA0KCW1hcFsxMF06IHR5cGUg TWVtb3J5LCByYW5nZSAzMiwgYmFzZSAweGZlYmZlMDAwLCBzaXplIDEyLCBl bmFibGVkDQpwY2liMDogbWF0Y2hlZCBlbnRyeSBmb3IgMC4xNS5JTlRBIChz cmMgXFxfU0JfLkxOVVM6MCkNCmlvYXBpYzA6IENoYW5naW5nIHRyaWdnZXIg Zm9yIHBpbiAxMCB0byBsZXZlbA0KaW9hcGljMDogQ2hhbmdpbmcgcG9sYXJp dHkgZm9yIHBpbiAxMCB0byBsb3cNCnBjaWIwOiBzbG90IDE1IElOVEEgcm91 dGVkIHRvIGlycSAxMCB2aWEgXFxfU0JfLkxOVVMNCnVua25vd246IFJlc2Vy dmVkIDB4MTAwMCBieXRlcyBmb3IgcmlkIDB4MTAgdHlwZSAzIGF0IDB4ZmVi ZmUwMDANCm9oY2kgZWFybHk6IFNNTSBhY3RpdmUsIHJlcXVlc3Qgb3duZXIg Y2hhbmdlDQpmb3VuZC0+CXZlbmRvcj0weDExNjYsIGRldj0weDAyMjcsIHJl dmlkPTB4MDANCglkb21haW49MCwgYnVzPTAsIHNsb3Q9MTUsIGZ1bmM9Mw0K CWNsYXNzPTA2LTAxLTAwLCBoZHJ0eXBlPTB4MDAsIG1mZGV2PTENCgljbWRy ZWc9MHgwMTA3LCBzdGF0cmVnPTB4MDIwMCwgY2FjaGVsbnN6PTAgKGR3b3Jk cykNCglsYXR0aW1lcj0weDAwICgwIG5zKSwgbWluZ250PTB4MDAgKDAgbnMp LCBtYXhsYXQ9MHgwMCAoMCBucykNCmVtMDogPEludGVsKFIpIFBSTy8xMDAw IExlZ2FjeSBOZXR3b3JrIENvbm5lY3Rpb24gMS4wLjU+IHBvcnQgMHhlMDAw LTB4ZTAzZiBtZW0gMHhmZWI2MDAwMC0weGZlYjdmZmZmLDB4ZmViMDAwMDAt MHhmZWIzZmZmZiBpcnEgMTYgYXQgZGV2aWNlIDEuMCBvbiBwY2kwDQplbTA6 IFJlc2VydmVkIDB4MjAwMDAgYnl0ZXMgZm9yIHJpZCAweDEwIHR5cGUgMyBh dCAweGZlYjYwMDAwDQplbTA6IFJlc2VydmVkIDB4NDAgYnl0ZXMgZm9yIHJp ZCAweDIwIHR5cGUgNCBhdCAweGUwMDANCmlvYXBpYzE6IHJvdXRpbmcgaW50 cGluIDAgKFBDSSBJUlEgMTYpIHRvIGxhcGljIDAgdmVjdG9yIDQ5DQplbTA6 IFtGSUxURVJdDQplbTA6IGJwZiBhdHRhY2hlZA0KZW0wOiBFdGhlcm5ldCBh ZGRyZXNzOiAwMDowNDoyMzpkZjpmYTo0Ng0KdmdhcGNpMDogPFZHQS1jb21w YXRpYmxlIGRpc3BsYXk+IHBvcnQgMHhlODAwLTB4ZThmZiBtZW0gMHhmZDAw MDAwMC0weGZkZmZmZmZmLDB4ZmViZmYwMDAtMHhmZWJmZmZmZiBpcnEgMjYg YXQgZGV2aWNlIDYuMCBvbiBwY2kwDQpmeHAwOiA8SW50ZWwgODI1NTEgUHJv LzEwMCBFdGhlcm5ldD4gcG9ydCAweGU0MDAtMHhlNDNmIG1lbSAweGZlYmZk MDAwLTB4ZmViZmRmZmYsMHhmZWI4MDAwMC0weGZlYjlmZmZmIGlycSAyNyBh dCBkZXZpY2UgNy4wIG9uIHBjaTANCmZ4cDA6IFJlc2VydmVkIDB4MTAwMCBi eXRlcyBmb3IgcmlkIDB4MTAgdHlwZSAzIGF0IDB4ZmViZmQwMDANCmZ4cDA6 IHVzaW5nIG1lbW9yeSBzcGFjZSByZWdpc3RlciBtYXBwaW5nDQpmeHAwOiBQ Q0kgSURzOiA4MDg2IDEyMjkgODA4NiAxMDUwIDAwMTANCmZ4cDA6IER5bmFt aWMgU3RhbmRieSBtb2RlIGlzIGRpc2FibGVkDQptaWlidXMwOiA8TUlJIGJ1 cz4gb24gZnhwMA0KaW5waHkwOiA8aTgyNTU1IDEwLzEwMCBtZWRpYSBpbnRl cmZhY2U+IFBIWSAxIG9uIG1paWJ1czANCmlucGh5MDogIDEwYmFzZVQsIDEw YmFzZVQtRkRYLCAxMDBiYXNlVFgsIDEwMGJhc2VUWC1GRFgsIGF1dG8sIGF1 dG8tZmxvdw0KZnhwMDogYnBmIGF0dGFjaGVkDQpmeHAwOiBFdGhlcm5ldCBh ZGRyZXNzOiAwMDozMDo0ODo1Mjo1MTphZQ0KaW9hcGljMTogcm91dGluZyBp bnRwaW4gMTEgKFBDSSBJUlEgMjcpIHRvIGxhcGljIDAgdmVjdG9yIDUwDQpm eHAwOiBbTVBTQUZFXQ0KZnhwMDogW0lUSFJFQURdDQpwY2kwOjA6ODowOiBi YWQgVlBEIGNrc3VtLCByZW1haW4gMTQNCmJnZTA6IDxCcm9hZGNvbSBOZXRY dHJlbWUgR2lnYWJpdCBFdGhlcm5ldCBDb250cm9sbGVyLCBBU0lDIHJldi4g MHgwMDEwMDI+IG1lbSAweGZlYmUwMDAwLTB4ZmViZWZmZmYgaXJxIDI4IGF0 IGRldmljZSA4LjAgb24gcGNpMA0KYmdlMDogUmVzZXJ2ZWQgMHgxMDAwMCBi eXRlcyBmb3IgcmlkIDB4MTAgdHlwZSAzIGF0IDB4ZmViZTAwMDANCmJnZTA6 IENISVAgSUQgMHgwMDAwMTAwMjsgQVNJQyBSRVYgMHgwMTsgQ0hJUCBSRVYg MHgxMDsgUENJIG9uIFBDSS1YIDMzIE1IejsgMzJiaXQNCm1paWJ1czE6IDxN SUkgYnVzPiBvbiBiZ2UwDQpicmdwaHkwOiA8QkNNNTcwMyAxMC8xMDAvMTAw MGJhc2VUWCBQSFk+IFBIWSAxIG9uIG1paWJ1czENCmJyZ3BoeTA6IE9VSSAw eDAwMDgxOCwgbW9kZWwgMHgwMDE2LCByZXYuIDINCmJyZ3BoeTA6ICAxMGJh c2VULCAxMGJhc2VULUZEWCwgMTAwYmFzZVRYLCAxMDBiYXNlVFgtRkRYLCAx MDAwYmFzZVQsIDEwMDBiYXNlVC1tYXN0ZXIsIDEwMDBiYXNlVC1GRFgsIDEw MDBiYXNlVC1GRFgtbWFzdGVyLCBhdXRvLCBhdXRvLWZsb3cNCmJnZTA6IGJw ZiBhdHRhY2hlZA0KYmdlMDogRXRoZXJuZXQgYWRkcmVzczogMDA6MzA6NDg6 NTI6NTE6YWYNCmlvYXBpYzE6IHJvdXRpbmcgaW50cGluIDEyIChQQ0kgSVJR IDI4KSB0byBsYXBpYyAwIHZlY3RvciA1MQ0KYmdlMDogW01QU0FGRV0NCmJn ZTA6IFtJVEhSRUFEXQ0KYXRhcGNpMDogPFNlcnZlcldvcmtzIENTQjYgVURN QTEwMCBjb250cm9sbGVyPiBwb3J0IDB4MWYwLTB4MWY3LDB4M2Y2LDB4MTcw LTB4MTc3LDB4Mzc2LDB4ZmZhMC0weGZmYWYgYXQgZGV2aWNlIDE1LjEgb24g cGNpMA0KYXRhcGNpMDogUmVzZXJ2ZWQgMHgxMCBieXRlcyBmb3IgcmlkIDB4 MjAgdHlwZSA0IGF0IDB4ZmZhMA0KYXRhMDogPEFUQSBjaGFubmVsPiBhdCBj aGFubmVsIDAgb24gYXRhcGNpMA0KYXRhcGNpMDogUmVzZXJ2ZWQgMHg4IGJ5 dGVzIGZvciByaWQgMHgxMCB0eXBlIDQgYXQgMHgxZjANCmF0YXBjaTA6IFJl c2VydmVkIDB4MSBieXRlcyBmb3IgcmlkIDB4MTQgdHlwZSA0IGF0IDB4M2Y2 DQphdGEwOiByZXNldCB0cDEgbWFzaz0wMyBvc3RhdDA9NTAgb3N0YXQxPTAw DQphdGEwOiBzdGF0MD0weDUwIGVycj0weDAxIGxzYj0weDAwIG1zYj0weDAw DQphdGEwOiBzdGF0MT0weDAwIGVycj0weDAxIGxzYj0weDAwIG1zYj0weDAw DQphdGEwOiByZXNldCB0cDIgc3RhdDA9NTAgc3RhdDE9MDAgZGV2aWNlcz0w eDENCmlvYXBpYzA6IHJvdXRpbmcgaW50cGluIDE0IChJU0EgSVJRIDE0KSB0 byBsYXBpYyAwIHZlY3RvciA1Mg0KYXRhMDogW01QU0FGRV0NCmF0YTA6IFtJ VEhSRUFEXQ0KYXRhMTogPEFUQSBjaGFubmVsPiBhdCBjaGFubmVsIDEgb24g YXRhcGNpMA0KYXRhcGNpMDogUmVzZXJ2ZWQgMHg4IGJ5dGVzIGZvciByaWQg MHgxOCB0eXBlIDQgYXQgMHgxNzANCmF0YXBjaTA6IFJlc2VydmVkIDB4MSBi eXRlcyBmb3IgcmlkIDB4MWMgdHlwZSA0IGF0IDB4Mzc2DQphdGExOiByZXNl dCB0cDEgbWFzaz0wMSBvc3RhdDA9NTAgb3N0YXQxPWZmDQphdGExOiBzdGF0 MD0weDAwIGVycj0weDAxIGxzYj0weDE0IG1zYj0weGViDQphdGExOiByZXNl dCB0cDIgc3RhdDA9MDAgc3RhdDE9MDAgZGV2aWNlcz0weDEwMDAwDQppb2Fw aWMwOiByb3V0aW5nIGludHBpbiAxNSAoSVNBIElSUSAxNSkgdG8gbGFwaWMg MCB2ZWN0b3IgNTMNCmF0YTE6IFtNUFNBRkVdDQphdGExOiBbSVRIUkVBRF0N Cm9oY2kwOiA8T0hDSSAoZ2VuZXJpYykgVVNCIGNvbnRyb2xsZXI+IG1lbSAw eGZlYmZlMDAwLTB4ZmViZmVmZmYgaXJxIDEwIGF0IGRldmljZSAxNS4yIG9u IHBjaTANCm9oY2kwOiAoTmV3IE9IQ0kgRGV2aWNlSWQ9MHgwMjIxMTE2NikN CmlvYXBpYzA6IHJvdXRpbmcgaW50cGluIDEwIChJU0EgSVJRIDEwKSB0byBs YXBpYyAwIHZlY3RvciA1NA0Kb2hjaTA6IFtNUFNBRkVdDQpvaGNpMDogW0lU SFJFQURdDQp1c2J1czAgb24gb2hjaTANCnVzYnVzMDogYnBmIGF0dGFjaGVk DQpvaGNpMDogdXNicGY6IEF0dGFjaGVkDQppc2FiMDogPFBDSS1JU0EgYnJp ZGdlPiBhdCBkZXZpY2UgMTUuMyBvbiBwY2kwDQppc2EwOiA8SVNBIGJ1cz4g b24gaXNhYjANCmF0cnRjMDogPEFUIHJlYWx0aW1lIGNsb2NrPiBwb3J0IDB4 NzAtMHg3MSBpcnEgOCBvbiBhY3BpMA0KYXRydGMwOiByZWdpc3RlcmVkIGFz IGEgdGltZS1vZi1kYXkgY2xvY2sgKHJlc29sdXRpb24gMTAwMDAwMHVzKQ0K cHNtY3BucDA6IDxQUy8yIG1vdXNlIHBvcnQ+IGlycSAxMiBvbiBhY3BpMA0K YXRrYmRjMDogPEtleWJvYXJkIGNvbnRyb2xsZXIgKGk4MDQyKT4gcG9ydCAw eDYwLDB4NjQgaXJxIDEgb24gYWNwaTANCmF0a2JkMDogPEFUIEtleWJvYXJk PiBpcnEgMSBvbiBhdGtiZGMwDQphdGtiZDogdGhlIGN1cnJlbnQga2JkIGNv bnRyb2xsZXIgY29tbWFuZCBieXRlIDAwNjUNCmF0a2JkOiBrZXlib2FyZCBJ RCAweDQxYWIgKDIpDQprYmQwIGF0IGF0a2JkMA0Ka2JkMDogYXRrYmQwLCBB VCAxMDEvMTAyICgyKSwgY29uZmlnOjB4MCwgZmxhZ3M6MHgzZDAwMDANCmlv YXBpYzA6IHJvdXRpbmcgaW50cGluIDEgKElTQSBJUlEgMSkgdG8gbGFwaWMg MCB2ZWN0b3IgNTUNCmF0a2JkMDogW0dJQU5ULUxPQ0tFRF0NCmF0a2JkMDog W0lUSFJFQURdDQpwc20wOiBjdXJyZW50IGNvbW1hbmQgYnl0ZTowMDY1DQpw c20wOiA8UFMvMiBNb3VzZT4gaXJxIDEyIG9uIGF0a2JkYzANCmlvYXBpYzA6 IHJvdXRpbmcgaW50cGluIDEyIChJU0EgSVJRIDEyKSB0byBsYXBpYyAwIHZl Y3RvciA1Ng0KcHNtMDogW0dJQU5ULUxPQ0tFRF0NCnBzbTA6IFtJVEhSRUFE XQ0KcHNtMDogbW9kZWwgSW50ZWxsaU1vdXNlLCBkZXZpY2UgSUQgMy0wMCwg MyBidXR0b25zDQpwc20wOiBjb25maWc6MDAwMDAwMDAsIGZsYWdzOjAwMDAw MDA4LCBwYWNrZXQgc2l6ZTo0DQpwc20wOiBzeW5jbWFzazowOCwgc3luY2Jp dHM6MDANCmZkYzA6IDxmbG9wcHkgZHJpdmUgY29udHJvbGxlciAoRkRFKT4g cG9ydCAweDNmMi0weDNmMywweDNmNC0weDNmNSwweDNmNyBpcnEgNiBkcnEg MiBvbiBhY3BpMA0KZmRjMDogaWNfdHlwZSA5MCBwYXJ0X2lkIDczDQppb2Fw aWMwOiByb3V0aW5nIGludHBpbiA2IChJU0EgSVJRIDYpIHRvIGxhcGljIDAg dmVjdG9yIDU3DQpmZGMwOiBbRklMVEVSXQ0KZmQwOiA8MTQ0MC1LQiAzLjUi IGRyaXZlPiBvbiBmZGMwIGRyaXZlIDANCnVhcnQwOiA8MTY1NTAgb3IgY29t cGF0aWJsZT4gcG9ydCAweDNmOC0weDNmZiBpcnEgNCBmbGFncyAweDEwIG9u IGFjcGkwDQppb2FwaWMwOiByb3V0aW5nIGludHBpbiA0IChJU0EgSVJRIDQp IHRvIGxhcGljIDAgdmVjdG9yIDU4DQp1YXJ0MDogW0ZJTFRFUl0NCnVhcnQw OiBmYXN0IGludGVycnVwdA0KdWFydDE6IDwxNjU1MCBvciBjb21wYXRpYmxl PiBwb3J0IDB4MmY4LTB4MmZmIGlycSAzIG9uIGFjcGkwDQppb2FwaWMwOiBy b3V0aW5nIGludHBpbiAzIChJU0EgSVJRIDMpIHRvIGxhcGljIDAgdmVjdG9y IDU5DQp1YXJ0MTogW0ZJTFRFUl0NCnVhcnQxOiBmYXN0IGludGVycnVwdA0K cHBjMDogdXNpbmcgZXh0ZW5kZWQgSS9PIHBvcnQgcmFuZ2UNCnBwYzA6IFNQ UCBFQ1AgDQpwcGMwOiA8UGFyYWxsZWwgcG9ydD4gcG9ydCAweDM3OC0weDM3 ZiwweDc3OC0weDc3ZiBpcnEgNyBkcnEgMyBvbiBhY3BpMA0KcHBjMDogR2Vu ZXJpYyBjaGlwc2V0IChFQ1AvUFMyL05JQkJMRSkgaW4gQ09NUEFUSUJMRSBt b2RlDQpwcGMwOiBGSUZPIHdpdGggMTYvMTYvOCBieXRlcyB0aHJlc2hvbGQN CmlvYXBpYzA6IHJvdXRpbmcgaW50cGluIDcgKElTQSBJUlEgNykgdG8gbGFw aWMgMCB2ZWN0b3IgNjANCnBwYzA6IFtNUFNBRkVdDQpwcGMwOiBbSVRIUkVB RF0NCnBwYnVzMDogPFBhcmFsbGVsIHBvcnQgYnVzPiBvbiBwcGMwDQpwbGlw MDogPFBMSVAgbmV0d29yayBpbnRlcmZhY2U+IG9uIHBwYnVzMA0KcGxpcDA6 IGJwZiBhdHRhY2hlZA0KcGxpcDA6IFtNUFNBRkVdDQpwbGlwMDogW0lUSFJF QURdDQpscHQwOiA8UHJpbnRlcj4gb24gcHBidXMwDQpscHQwOiBbTVBTQUZF XQ0KbHB0MDogW0lUSFJFQURdDQpscHQwOiBJbnRlcnJ1cHQtZHJpdmVuIHBv cnQNCnBwaTA6IDxQYXJhbGxlbCBJL08+IG9uIHBwYnVzMA0KZXhfaXNhX2lk ZW50aWZ5KCkNCnBucF9pZGVudGlmeTogVHJ5aW5nIFJlYWRfUG9ydCBhdCAy MDMNCnBucF9pZGVudGlmeTogVHJ5aW5nIFJlYWRfUG9ydCBhdCAyNDMNCnBu cF9pZGVudGlmeTogVHJ5aW5nIFJlYWRfUG9ydCBhdCAyODMNCnBucF9pZGVu dGlmeTogVHJ5aW5nIFJlYWRfUG9ydCBhdCAyYzMNCnBucF9pZGVudGlmeTog VHJ5aW5nIFJlYWRfUG9ydCBhdCAzMDMNCnBucF9pZGVudGlmeTogVHJ5aW5n IFJlYWRfUG9ydCBhdCAzNDMNCnBucF9pZGVudGlmeTogVHJ5aW5nIFJlYWRf UG9ydCBhdCAzODMNCnBucF9pZGVudGlmeTogVHJ5aW5nIFJlYWRfUG9ydCBh dCAzYzMNClBOUCBJZGVudGlmeSBjb21wbGV0ZQ0KYWhjX2lzYV9wcm9iZSAw OiBpb3BvcnQgMHhjMDAgYWxsb2MgZmFpbGVkDQphaGNfaXNhX3Byb2JlIDE6 IGlvcG9ydCAweDFjMDAgYWxsb2MgZmFpbGVkDQphaGNfaXNhX3Byb2JlIDI6 IGlvcG9ydCAweDJjMDAgYWxsb2MgZmFpbGVkDQphaGNfaXNhX3Byb2JlIDM6 IGlvcG9ydCAweDNjMDAgYWxsb2MgZmFpbGVkDQphaGNfaXNhX3Byb2JlIDQ6 IGlvcG9ydCAweDRjMDAgYWxsb2MgZmFpbGVkDQphaGNfaXNhX3Byb2JlIDU6 IGlvcG9ydCAweDVjMDAgYWxsb2MgZmFpbGVkDQphaGNfaXNhX3Byb2JlIDY6 IGlvcG9ydCAweDZjMDAgYWxsb2MgZmFpbGVkDQphaGNfaXNhX3Byb2JlIDc6 IGlvcG9ydCAweDdjMDAgYWxsb2MgZmFpbGVkDQphaGNfaXNhX3Byb2JlIDg6 IGlvcG9ydCAweDhjMDAgYWxsb2MgZmFpbGVkDQphaGNfaXNhX3Byb2JlIDk6 IGlvcG9ydCAweDljMDAgYWxsb2MgZmFpbGVkDQphaGNfaXNhX3Byb2JlIDEw OiBpb3BvcnQgMHhhYzAwIGFsbG9jIGZhaWxlZA0KYWhjX2lzYV9wcm9iZSAx MTogaW9wb3J0IDB4YmMwMCBhbGxvYyBmYWlsZWQNCmFoY19pc2FfcHJvYmUg MTI6IGlvcG9ydCAweGNjMDAgYWxsb2MgZmFpbGVkDQphaGNfaXNhX3Byb2Jl IDEzOiBpb3BvcnQgMHhkYzAwIGFsbG9jIGZhaWxlZA0KYWhjX2lzYV9wcm9i ZSAxNDogaW9wb3J0IDB4ZWMwMCBhbGxvYyBmYWlsZWQNCmlzYV9wcm9iZV9j aGlsZHJlbjogZGlzYWJsaW5nIFBuUCBkZXZpY2VzDQpwbXRpbWVyMCBvbiBp c2EwDQphdGE6IGF0YTAgYWxyZWFkeSBleGlzdHM7IHNraXBwaW5nIGl0DQph dGE6IGF0YTEgYWxyZWFkeSBleGlzdHM7IHNraXBwaW5nIGl0DQphdGtiZGM6 IGF0a2JkYzAgYWxyZWFkeSBleGlzdHM7IHNraXBwaW5nIGl0DQphdHJ0Yzog YXRydGMwIGFscmVhZHkgZXhpc3RzOyBza2lwcGluZyBpdA0KZmRjOiBmZGMw IGFscmVhZHkgZXhpc3RzOyBza2lwcGluZyBpdA0KcHBjOiBwcGMwIGFscmVh ZHkgZXhpc3RzOyBza2lwcGluZyBpdA0Kc2M6IHNjMCBhbHJlYWR5IGV4aXN0 czsgc2tpcHBpbmcgaXQNCnVhcnQ6IHVhcnQwIGFscmVhZHkgZXhpc3RzOyBz a2lwcGluZyBpdA0KdWFydDogdWFydDEgYWxyZWFkeSBleGlzdHM7IHNraXBw aW5nIGl0DQppc2FfcHJvYmVfY2hpbGRyZW46IHByb2Jpbmcgbm9uLVBuUCBk ZXZpY2VzDQpvcm0wOiA8SVNBIE9wdGlvbiBST01zPiBhdCBpb21lbSAweGMw MDAwLTB4YzdmZmYsMHhjODAwMC0weGM5N2ZmLDB4Yzk4MDAtMHhjYWZmZiBw bnBpZCBPUk0wMDAwIG9uIGlzYTANCnNjMDogPFN5c3RlbSBjb25zb2xlPiBh dCBmbGFncyAweDEwMCBvbiBpc2EwDQpzYzA6IFZHQSA8MTYgdmlydHVhbCBj b25zb2xlcywgZmxhZ3M9MHgzMDA+DQpzYzA6IGZiMCwga2JkMSwgdGVybWlu YWwgZW11bGF0b3I6IHNjdGVrZW4gKHRla2VuIHRlcm1pbmFsKQ0KdmdhMDog PEdlbmVyaWMgSVNBIFZHQT4gYXQgcG9ydCAweDNjMC0weDNkZiBpb21lbSAw eGEwMDAwLTB4YmZmZmYgb24gaXNhMA0Kd2J3ZDAgZmFpbGVkIHRvIHByb2Jl IG9uIGlzYTANCmlzYV9wcm9iZV9jaGlsZHJlbjogcHJvYmluZyBQblAgZGV2 aWNlcw0KcDR0Y2MwOiA8Q1BVIEZyZXF1ZW5jeSBUaGVybWFsIENvbnRyb2w+ IG9uIGNwdTANCkRldmljZSBjb25maWd1cmF0aW9uIGZpbmlzaGVkLg0KcHJv Y2ZzIHJlZ2lzdGVyZWQNCmxhcGljOiBEaXZpc29yIDIsIEZyZXF1ZW5jeSA2 NjY2OTY3OSBIeg0KVGltZWNvdW50ZXIgIlRTQyIgZnJlcXVlbmN5IDI2NjY3 ODY5ODggSHogcXVhbGl0eSA4MDANClRpbWVjb3VudGVycyB0aWNrIGV2ZXJ5 IDEuMDAwIG1zZWMNCnZsYW46IGluaXRpYWxpemVkLCB1c2luZyBoYXNoIHRh YmxlcyB3aXRoIGNoYWluaW5nDQppcGZ3MiAoK2lwdjYpIGluaXRpYWxpemVk LCBkaXZlcnQgZW5hYmxlZCwgbmF0IGxvYWRhYmxlLCBydWxlLWJhc2VkIGZv cndhcmRpbmcgZGlzYWJsZWQsIGRlZmF1bHQgdG8gYWNjZXB0LCBsb2dnaW5n IGRpc2FibGVkDQppcGZ3MDogYnBmIGF0dGFjaGVkDQpsbzA6IGJwZiBhdHRh Y2hlZA0KaHB0cnI6IG5vIGNvbnRyb2xsZXIgZGV0ZWN0ZWQuDQphdGEwOiBJ ZGVudGlmeWluZyBkZXZpY2VzOiAwMDAwMDAwMQ0KYXRhMDogTmV3IGRldmlj ZXM6IDAwMDAwMDAxDQp1c2J1czA6IDEyTWJwcyBGdWxsIFNwZWVkIFVTQiB2 MS4wDQphdGEwLW1hc3RlcjogcGlvPVBJTzQgd2RtYT1XRE1BMiB1ZG1hPVVE TUExMDAgY2FibGU9ODAgd2lyZQ0KYWQwOiBzZXR0aW5nIFVETUExMDANCmFk MDogMTUyNjI3TUIgPFdEQyBXRDE2MDBMQi01NUVEQTAgMTUuMDVSMTU+IGF0 IGF0YTAtbWFzdGVyIFVETUExMDAgDQphZDA6IDMxMjU4MTgwOCBzZWN0b3Jz IFszMTAxMDFDLzE2SC82M1NdIDE2IHNlY3RvcnMvaW50ZXJydXB0IDEgZGVw dGggcXVldWUNCnVnZW4wLjE6IDwweDExNjY+IGF0IHVzYnVzMA0KdWh1YjA6 IDwweDExNjYgT0hDSSByb290IEhVQiwgY2xhc3MgOS8wLCByZXYgMS4wMC8x LjAwLCBhZGRyIDE+IG9uIHVzYnVzMA0KYWQwOiBBZGFwdGVjIGNoZWNrMSBm YWlsZWQNCmFkMDogTFNJICh2MykgY2hlY2sxIGZhaWxlZA0KYWQwOiBMU0kg KHYyKSBjaGVjazEgZmFpbGVkDQphZDA6IEZyZWVCU0QgY2hlY2sxIGZhaWxl ZA0KYXRhMTogSWRlbnRpZnlpbmcgZGV2aWNlczogMDAwMTAwMDANCmF0YTE6 IE5ldyBkZXZpY2VzOiAwMDAxMDAwMA0KYXRhMS1tYXN0ZXI6IHBpbz1QSU80 IHdkbWE9V0RNQTIgdWRtYT1VRE1BMzMgY2FibGU9NDAgd2lyZQ0KYWNkMDog c2V0dGluZyBVRE1BMzMNCmFjZDA6IDxNQVRTSElUQSBDUi0xNzcvN1QwRD4g Q0RST00gZHJpdmUgYXQgYXRhMSBhcyBtYXN0ZXINCmFjZDA6IHJlYWQgNDEy NUtCL3MgKDQxMjVLQi9zKSwgMTI4S0IgYnVmZmVyLCBVRE1BMzMgDQphY2Qw OiBSZWFkczogQ0RSLCBDRFJXLCBDRERBIHN0cmVhbSwgcGFja2V0DQphY2Qw OiBXcml0ZXM6DQphY2QwOiBBdWRpbzogcGxheSwgMjU2IHZvbHVtZSBsZXZl bHMNCmFjZDA6IE1lY2hhbmlzbTogZWplY3RhYmxlIHRyYXksIHVubG9ja2Vk DQphY2QwOiBNZWRpdW06IG5vL2JsYW5rIGRpc2MNCkFUQSBQc2V1ZG9SQUlE IGxvYWRlZA0KdWh1YjA6IDQgcG9ydHMgd2l0aCA0IHJlbW92YWJsZSwgc2Vs ZiBwb3dlcmVkDQpHRU9NOiBuZXcgZGlzayBhZDANCkdFT006IGFkMHMyOiBn ZW9tZXRyeSBkb2VzIG5vdCBtYXRjaCBsYWJlbCAoMjU1aCw2M3MgIT0gMTZo LDYzcykuDQpUcnlpbmcgdG8gbW91bnQgcm9vdCBmcm9tIHVmczovZGV2L2Fk MHMyYQ0Kc3RhcnRfaW5pdDogdHJ5aW5nIC9zYmluL2luaXQNCmVtMDogTGlu ayBpcyB1cCAxMDAwIE1icHMgRnVsbCBEdXBsZXgNCmVtMDogTGluayBpcyBE b3duDQplbTA6IExpbmsgaXMgdXAgMTAwMCBNYnBzIEZ1bGwgRHVwbGV4DQpm eHAwOiBsaW5rIHN0YXRlIGNoYW5nZWQgdG8gVVANCmZ4cDA6IGxpbmsgc3Rh dGUgY2hhbmdlZCB0byBET1dODQpmeHAwOiBsaW5rIHN0YXRlIGNoYW5nZWQg dG8gVVANCmZ4cDA6IGxpbmsgc3RhdGUgY2hhbmdlZCB0byBET1dODQpmeHAw OiBsaW5rIHN0YXRlIGNoYW5nZWQgdG8gVVANCmZ4cDA6IGxpbmsgc3RhdGUg Y2hhbmdlZCB0byBET1dODQpmeHAwOiBsaW5rIHN0YXRlIGNoYW5nZWQgdG8g VVANCmZ4cDA6IGxpbmsgc3RhdGUgY2hhbmdlZCB0byBET1dODQpmeHAwOiBs aW5rIHN0YXRlIGNoYW5nZWQgdG8gVVANCmZ4cDA6IGxpbmsgc3RhdGUgY2hh bmdlZCB0byBET1dODQpmeHAwOiBsaW5rIHN0YXRlIGNoYW5nZWQgdG8gVVAN CmZ4cDA6IGxpbmsgc3RhdGUgY2hhbmdlZCB0byBET1dODQpmeHAwOiBsaW5r IHN0YXRlIGNoYW5nZWQgdG8gVVANCmZ4cDA6IGxpbmsgc3RhdGUgY2hhbmdl ZCB0byBET1dODQpmeHAwOiBsaW5rIHN0YXRlIGNoYW5nZWQgdG8gVVANCmZ4 cDA6IGxpbmsgc3RhdGUgY2hhbmdlZCB0byBET1dODQpmeHAwOiBsaW5rIHN0 YXRlIGNoYW5nZWQgdG8gVVANCmZ4cDA6IGxpbmsgc3RhdGUgY2hhbmdlZCB0 byBET1dODQpmeHAwOiBsaW5rIHN0YXRlIGNoYW5nZWQgdG8gVVANCmZ4cDA6 IGxpbmsgc3RhdGUgY2hhbmdlZCB0byBET1dODQpmeHAwOiBsaW5rIHN0YXRl IGNoYW5nZWQgdG8gVVANCmZ4cDA6IGxpbmsgc3RhdGUgY2hhbmdlZCB0byBE T1dODQpmeHAwOiBsaW5rIHN0YXRlIGNoYW5nZWQgdG8gVVANCmZ4cDA6IGxp bmsgc3RhdGUgY2hhbmdlZCB0byBET1dODQpmeHAwOiBsaW5rIHN0YXRlIGNo YW5nZWQgdG8gVVANCmZ4cDA6IGxpbmsgc3RhdGUgY2hhbmdlZCB0byBET1dO DQpmeHAwOiBsaW5rIHN0YXRlIGNoYW5nZWQgdG8gVVANCmZ4cDA6IGxpbmsg c3RhdGUgY2hhbmdlZCB0byBET1dODQpmeHAwOiBsaW5rIHN0YXRlIGNoYW5n ZWQgdG8gVVANCmZ4cDA6IGxpbmsgc3RhdGUgY2hhbmdlZCB0byBET1dODQpm eHAwOiBsaW5rIHN0YXRlIGNoYW5nZWQgdG8gVVANCnNwbGFzaDogaW1hZ2Ug ZGVjb2RlciBmb3VuZDogZGFlbW9uX3NhdmVyDQpmeHAwOiBsaW5rIHN0YXRl IGNoYW5nZWQgdG8gRE9XTg0KZnhwMDogbGluayBzdGF0ZSBjaGFuZ2VkIHRv IFVQDQpmeHAwOiBsaW5rIHN0YXRlIGNoYW5nZWQgdG8gRE9XTg0KZnhwMDog bGluayBzdGF0ZSBjaGFuZ2VkIHRvIFVQDQpmeHAwOiBsaW5rIHN0YXRlIGNo YW5nZWQgdG8gRE9XTg0KZnhwMDogbGluayBzdGF0ZSBjaGFuZ2VkIHRvIFVQ DQo= ---1160921188-1351541650-1368327465=:1240 Content-Type: TEXT/PLAIN; charset=US-ASCII; name=dmesg_83Releasep8.txt Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: dmesg 8.3R p8 Content-Disposition: attachment; filename=dmesg_83Releasep8.txt Q29weXJpZ2h0IChjKSAxOTkyLTIwMTIgVGhlIEZyZWVCU0QgUHJvamVjdC4N CkNvcHlyaWdodCAoYykgMTk3OSwgMTk4MCwgMTk4MywgMTk4NiwgMTk4OCwg MTk4OSwgMTk5MSwgMTk5MiwgMTk5MywgMTk5NA0KCVRoZSBSZWdlbnRzIG9m IHRoZSBVbml2ZXJzaXR5IG9mIENhbGlmb3JuaWEuIEFsbCByaWdodHMgcmVz ZXJ2ZWQuDQpGcmVlQlNEIGlzIGEgcmVnaXN0ZXJlZCB0cmFkZW1hcmsgb2Yg VGhlIEZyZWVCU0QgRm91bmRhdGlvbi4NCkZyZWVCU0QgOC4zLVJFTEVBU0Ut cDggIzQ2OiBTYXQgTWF5IDExIDAwOjA1OjI2IEVEVCAyMDEzDQogICAgcm9v dEBmYW1pbHlzcXVpcmVzLm5ldDovdXNyL29iai91c3Ivc3JjL3N5cy9ORVdH QVRFIGkzODYNClByZWxvYWRlZCBlbGYga2VybmVsICIvYm9vdC9rZXJuZWwv a2VybmVsIiBhdCAweGMxMDJkMDAwLg0KVGltZWNvdW50ZXIgImk4MjU0IiBm cmVxdWVuY3kgMTE5MzE4MiBIeiBxdWFsaXR5IDANCkNhbGlicmF0aW5nIFRT QyBjbG9jayAuLi4gVFNDIGNsb2NrOiAyNjY2NzgyNTkyIEh6DQpDUFU6IElu dGVsKFIpIFhlb24oVE0pIENQVSAyLjY2R0h6ICgyNjY2Ljc4LU1IeiA2ODYt Y2xhc3MgQ1BVKQ0KICBPcmlnaW4gPSAiR2VudWluZUludGVsIiAgSWQgPSAw eGYyNSAgRmFtaWx5ID0gZiAgTW9kZWwgPSAyICBTdGVwcGluZyA9IDUNCiAg RmVhdHVyZXM9MHhiZmViZmJmZjxGUFUsVk1FLERFLFBTRSxUU0MsTVNSLFBB RSxNQ0UsQ1g4LEFQSUMsU0VQLE1UUlIsUEdFLE1DQSxDTU9WLFBBVCxQU0Uz NixDTEZMVVNILERUUyxBQ1BJLE1NWCxGWFNSLFNTRSxTU0UyLFNTLEhUVCxU TSxQQkU+DQogIEZlYXR1cmVzMj0weDQ0MDA8Q05YVC1JRCx4VFBSPg0KDQpJ bnN0cnVjdGlvbiBUTEI6IDQgS0IsIDIgTUIgb3IgNCBNQiBwYWdlcywgZnVs bHkgYXNzb2NpYXRpdmUsIDEyOCBlbnRyaWVzDQpEYXRhIFRMQjogNCBLQiBv ciA0IE1CIHBhZ2VzLCBmdWxseSBhc3NvY2lhdGl2ZSwgNjQgZW50cmllcw0K MXN0LWxldmVsIGRhdGEgY2FjaGU6IDggS0IsIDQtd2F5IHNldCBhc3NvY2lh dGl2ZSwgc2VjdG9yZWQgY2FjaGUsIDY0IGJ5dGUgbGluZSBzaXplDQpUcmFj ZSBjYWNoZTogMTJLLXVvcHMsIDgtd2F5IHNldCBhc3NvY2lhdGl2ZQ0KMm5k LWxldmVsIGNhY2hlOiA1MTIgS0IsIDgtd2F5IHNldCBhc3NvY2lhdGl2ZSwg c2VjdG9yZWQgY2FjaGUsIDY0IGJ5dGUgbGluZSBzaXplDQpyZWFsIG1lbW9y eSAgPSAxMDczNzQxODI0ICgxMDI0IE1CKQ0KUGh5c2ljYWwgbWVtb3J5IGNo dW5rKHMpOg0KMHgwMDAwMDAwMDAwMDAxMDAwIC0gMHgwMDAwMDAwMDAwMDll ZmZmLCA2NDcxNjggYnl0ZXMgKDE1OCBwYWdlcykNCjB4MDAwMDAwMDAwMDEw MDAwMCAtIDB4MDAwMDAwMDAwMDNmZmZmZiwgMzE0NTcyOCBieXRlcyAoNzY4 IHBhZ2VzKQ0KMHgwMDAwMDAwMDAxNDI2MDAwIC0gMHgwMDAwMDAwMDNlZGE0 ZmZmLCAxMDMzMzY3NTUyIGJ5dGVzICgyNTIyODcgcGFnZXMpDQphdmFpbCBt ZW1vcnkgPSAxMDMyMDg1NTA0ICg5ODQgTUIpDQpUYWJsZSAnRkFDUCcgYXQg MHgzZmZmMDAzMA0KVGFibGUgJ0FQSUMnIGF0IDB4M2ZmZjAwYjANCkFQSUM6 IEZvdW5kIHRhYmxlIGF0IDB4M2ZmZjAwYjANCk1QIENvbmZpZ3VyYXRpb24g VGFibGUgdmVyc2lvbiAxLjQgZm91bmQgYXQgMHhjMDBmMGNiMA0KQVBJQzog VXNpbmcgdGhlIE1BRFQgZW51bWVyYXRvci4NCk1BRFQ6IEZvdW5kIENQVSBB UElDIElEIDAgQUNQSSBJRCAwOiBlbmFibGVkDQpTTVA6IEFkZGVkIENQVSAw IChBUCkNCk1BRFQ6IEZvdW5kIENQVSBBUElDIElEIDAgQUNQSSBJRCAxOiBk aXNhYmxlZA0KTUFEVDogRm91bmQgQ1BVIEFQSUMgSUQgMCBBQ1BJIElEIDI6 IGRpc2FibGVkDQpNQURUOiBGb3VuZCBDUFUgQVBJQyBJRCAwIEFDUEkgSUQg MzogZGlzYWJsZWQNCk1BRFQ6IEZvdW5kIENQVSBBUElDIElEIDAgQUNQSSBJ RCA0OiBkaXNhYmxlZA0KTUFEVDogRm91bmQgQ1BVIEFQSUMgSUQgMCBBQ1BJ IElEIDU6IGRpc2FibGVkDQpNQURUOiBGb3VuZCBDUFUgQVBJQyBJRCAwIEFD UEkgSUQgNjogZGlzYWJsZWQNCk1BRFQ6IEZvdW5kIENQVSBBUElDIElEIDAg QUNQSSBJRCA3OiBkaXNhYmxlZA0KQUNQSSBBUElDIFRhYmxlOiA8UkNDICAg IEdDSEUgICAgPg0KQVBJQzogQ1BVIDAgaGFzIEFDUEkgSUQgMA0KYmlvczMy OiBGb3VuZCBCSU9TMzIgU2VydmljZSBEaXJlY3RvcnkgaGVhZGVyIGF0IDB4 YzAwZmRiNzANCmJpb3MzMjogRW50cnkgPSAweGZkYjgwIChjMDBmZGI4MCkg IFJldiA9IDAgIExlbiA9IDENCnBjaWJpb3M6IFBDSSBCSU9TIGVudHJ5IGF0 IDB4ZjAwMDArMHhkYmExDQpwbnBiaW9zOiBGb3VuZCBQblAgQklPUyBkYXRh IGF0IDB4YzAwZjQ1MDANCnBucGJpb3M6IEVudHJ5ID0gZjAwMDA6MzNhNCAg UmV2ID0gMS4wDQpPdGhlciBCSU9TIHNpZ25hdHVyZXMgZm91bmQ6DQp4ODZi aW9zOiAgIElWVCAweDAwMDAwMC0weDAwMDRmZiBhdCAweGMwMDAwMDAwDQp4 ODZiaW9zOiAgU1NFRyAweDAxMDAwMC0weDAxZmZmZiBhdCAweGM0M2I5MDAw DQp4ODZiaW9zOiAgRUJEQSAweDA5ZjAwMC0weDA5ZmZmZiBhdCAweGMwMDlm MDAwDQp4ODZiaW9zOiAgIFJPTSAweDBhMDAwMC0weDBlZmZmZiBhdCAweGMw MGEwMDAwDQpVTEU6IHNldHVwIGNwdSAwDQpBQ1BJOiBSU0RQIDB4ZmY5MDAg MDAwMTQgKHYwMCBBTUkgICApDQpBQ1BJOiBSU0RUIDB4M2ZmZjAwMDAgMDAw MkMgKHYwMSBSQ0MgICAgR0NIRSAgICAgMDAwMDAwMDEgTVNGVCAwMTAwMDAw MCkNCkFDUEk6IEZBQ1AgMHgzZmZmMDAzMCAwMDA3NCAodjAxIFJDQyAgICBH Q0hFICAgICAwMDAwMDAwMSBNU0ZUIDAxMDAwMDAwKQ0KQUNQSTogRFNEVCAw eDNmZmYwMTUwIDA0OUYxICh2MDEgICAgUkNDICAgICBHQ1NMIDAwMDAwMTAw IE1TRlQgMDEwMDAwMEQpDQpBQ1BJOiBGQUNTIDB4M2ZmZmYwMDAgMDAwNDAN CkFDUEk6IEFQSUMgMHgzZmZmMDBiMCAwMDA5QSAodjAxIFJDQyAgICBHQ0hF ICAgICAwMDAwMDAwMSBNU0ZUIDAxMDAwMDAwKQ0KTUFEVDogRm91bmQgSU8g QVBJQyBJRCA4LCBJbnRlcnJ1cHQgMCBhdCAweGZlYzAwMDAwDQppb2FwaWMw OiBSb3V0aW5nIGV4dGVybmFsIDgyNTlBJ3MgLT4gaW50cGluIDANCk1BRFQ6 IEZvdW5kIElPIEFQSUMgSUQgOSwgSW50ZXJydXB0IDE2IGF0IDB4ZmVjMDEw MDANCk1BRFQ6IEZvdW5kIElPIEFQSUMgSUQgMTAsIEludGVycnVwdCAzMiBh dCAweGZlYzAyMDAwDQpNQURUOiBJbnRlcnJ1cHQgb3ZlcnJpZGU6IHNvdXJj ZSAwLCBpcnEgMg0KaW9hcGljMDogUm91dGluZyBJUlEgMCAtPiBpbnRwaW4g Mg0KTUFEVDogRm9yY2luZyBhY3RpdmUtbG93IHBvbGFyaXR5IGFuZCBsZXZl bCB0cmlnZ2VyIGZvciBTQ0kNCmlvYXBpYzA6IGludHBpbiA5IHBvbGFyaXR5 OiBsb3cNCmlvYXBpYzA6IGludHBpbiA5IHRyaWdnZXI6IGxldmVsDQppb2Fw aWMwIDxWZXJzaW9uIDEuMT4gaXJxcyAwLTE1IG9uIG1vdGhlcmJvYXJkDQpp b2FwaWMxIDxWZXJzaW9uIDEuMT4gaXJxcyAxNi0zMSBvbiBtb3RoZXJib2Fy ZA0KaW9hcGljMiA8VmVyc2lvbiAxLjE+IGlycXMgMzItNDcgb24gbW90aGVy Ym9hcmQNCmNwdTAgQlNQOg0KICAgICBJRDogMHgwMDAwMDAwMCAgIFZFUjog MHgwMDA1MDAxNCBMRFI6IDB4MDAwMDAwMDAgREZSOiAweGZmZmZmZmZmDQog IGxpbnQwOiAweDAwMDEwNzAwIGxpbnQxOiAweDAwMDAwNDAwIFRQUjogMHgw MDAwMDAwMCBTVlI6IDB4MDAwMDAxZmYNCiAgdGltZXI6IDB4MDAwMTAwZWYg dGhlcm06IDB4MDAwMTAwMDAgZXJyOiAweDAwMDAwMGYwIHBtYzogMHgwMDAx MDQwMA0Kd2xhbjogPDgwMi4xMSBMaW5rIExheWVyPg0KbnVsbDogPG51bGwg ZGV2aWNlLCB6ZXJvIGRldmljZT4NCnJhbmRvbTogPGVudHJvcHkgc291cmNl LCBTb2Z0d2FyZSwgWWFycm93Pg0KbmZzbG9jazogcHNldWRvLWRldmljZQ0K aW86IDxJL08+DQprYmQ6IG5ldyBhcnJheSBzaXplIDQNCmtiZDEgYXQga2Jk bXV4MA0KbWVtOiA8bWVtb3J5Pg0KUGVudGl1bSBQcm8gTVRSUiBzdXBwb3J0 IGVuYWJsZWQNCmhwdHJyOiBSb2NrZXRSQUlEIDE3eHgvMnh4eCBTQVRBIGNv bnRyb2xsZXIgZHJpdmVyIHYxLjINCmFjcGkwOiA8UkNDIEdDSEU+IG9uIG1v dGhlcmJvYXJkDQpBQ1BJIFdhcm5pbmc6IFR5cGUgb3ZlcnJpZGUgLSBbREVC X10gaGFkIGludmFsaWQgdHlwZSAoSW50ZWdlcikgZm9yIFNjb3BlIG9wZXJh dG9yLCBjaGFuZ2VkIHRvIHR5cGUgQU5ZDQogKDIwMTAxMDEzL2Rzd2xvYWQt ODA4KQ0KQUNQSSBXYXJuaW5nOiBUeXBlIG92ZXJyaWRlIC0gW01MSUJdIGhh ZCBpbnZhbGlkIHR5cGUgKEludGVnZXIpIGZvciBTY29wZSBvcGVyYXRvciwg Y2hhbmdlZCB0byB0eXBlIEFOWQ0KICgyMDEwMTAxMy9kc3dsb2FkLTgwOCkN CkFDUEkgV2FybmluZzogVHlwZSBvdmVycmlkZSAtIFtJT19fXSBoYWQgaW52 YWxpZCB0eXBlIChJbnRlZ2VyKSBmb3IgU2NvcGUgb3BlcmF0b3IsIGNoYW5n ZWQgdG8gdHlwZSBBTlkNCiAoMjAxMDEwMTMvZHN3bG9hZC04MDgpDQpBQ1BJ IFdhcm5pbmc6IFR5cGUgb3ZlcnJpZGUgLSBbREFUQV0gaGFkIGludmFsaWQg dHlwZSAoU3RyaW5nKSBmb3IgU2NvcGUgb3BlcmF0b3IsIGNoYW5nZWQgdG8g dHlwZSBBTlkNCiAoMjAxMDEwMTMvZHN3bG9hZC04MDgpDQpBQ1BJIFdhcm5p bmc6IFR5cGUgb3ZlcnJpZGUgLSBbU0lPX10gaGFkIGludmFsaWQgdHlwZSAo U3RyaW5nKSBmb3IgU2NvcGUgb3BlcmF0b3IsIGNoYW5nZWQgdG8gdHlwZSBB TlkNCiAoMjAxMDEwMTMvZHN3bG9hZC04MDgpDQpBQ1BJIFdhcm5pbmc6IFR5 cGUgb3ZlcnJpZGUgLSBbU0JfX10gaGFkIGludmFsaWQgdHlwZSAoU3RyaW5n KSBmb3IgU2NvcGUgb3BlcmF0b3IsIGNoYW5nZWQgdG8gdHlwZSBBTlkNCiAo MjAxMDEwMTMvZHN3bG9hZC04MDgpDQpBQ1BJIFdhcm5pbmc6IFR5cGUgb3Zl cnJpZGUgLSBbUE1fX10gaGFkIGludmFsaWQgdHlwZSAoU3RyaW5nKSBmb3Ig U2NvcGUgb3BlcmF0b3IsIGNoYW5nZWQgdG8gdHlwZSBBTlkNCiAoMjAxMDEw MTMvZHN3bG9hZC04MDgpDQpBQ1BJIFdhcm5pbmc6IFR5cGUgb3ZlcnJpZGUg LSBbSUNOVF0gaGFkIGludmFsaWQgdHlwZSAoU3RyaW5nKSBmb3IgU2NvcGUg b3BlcmF0b3IsIGNoYW5nZWQgdG8gdHlwZSBBTlkNCiAoMjAxMDEwMTMvZHN3 bG9hZC04MDgpDQpBQ1BJIFdhcm5pbmc6IFR5cGUgb3ZlcnJpZGUgLSBbQUNQ SV0gaGFkIGludmFsaWQgdHlwZSAoU3RyaW5nKSBmb3IgU2NvcGUgb3BlcmF0 b3IsIGNoYW5nZWQgdG8gdHlwZSBBTlkNCiAoMjAxMDEwMTMvZHN3bG9hZC04 MDgpDQpBQ1BJIFdhcm5pbmc6IFR5cGUgb3ZlcnJpZGUgLSBbSU9SR10gaGFk IGludmFsaWQgdHlwZSAoU3RyaW5nKSBmb3IgU2NvcGUgb3BlcmF0b3IsIGNo YW5nZWQgdG8gdHlwZSBBTlkNCiAoMjAxMDEwMTMvZHN3bG9hZC04MDgpDQpB Q1BJIFdhcm5pbmc6IFR5cGUgb3ZlcnJpZGUgLSBbU0JfX10gaGFkIGludmFs aWQgdHlwZSAoU3RyaW5nKSBmb3IgU2NvcGUgb3BlcmF0b3IsIGNoYW5nZWQg dG8gdHlwZSBBTlkNCiAoMjAxMDEwMTMvZHN3bG9hZC04MDgpDQpBQ1BJIFdh cm5pbmc6IFR5cGUgb3ZlcnJpZGUgLSBbUE1fX10gaGFkIGludmFsaWQgdHlw ZSAoU3RyaW5nKSBmb3IgU2NvcGUgb3BlcmF0b3IsIGNoYW5nZWQgdG8gdHlw ZSBBTlkNCiAoMjAxMDEwMTMvZHN3bG9hZC04MDgpDQpBQ1BJIFdhcm5pbmc6 IFR5cGUgb3ZlcnJpZGUgLSBbU0lPX10gaGFkIGludmFsaWQgdHlwZSAoU3Ry aW5nKSBmb3IgU2NvcGUgb3BlcmF0b3IsIGNoYW5nZWQgdG8gdHlwZSBBTlkN CiAoMjAxMDEwMTMvZHN3bG9hZC04MDgpDQpBQ1BJIFdhcm5pbmc6IFR5cGUg b3ZlcnJpZGUgLSBbUE1fX10gaGFkIGludmFsaWQgdHlwZSAoU3RyaW5nKSBm b3IgU2NvcGUgb3BlcmF0b3IsIGNoYW5nZWQgdG8gdHlwZSBBTlkNCiAoMjAx MDEwMTMvZHN3bG9hZC04MDgpDQpBQ1BJIFdhcm5pbmc6IFR5cGUgb3ZlcnJp ZGUgLSBbQklPU10gaGFkIGludmFsaWQgdHlwZSAoSW50ZWdlcikgZm9yIFNj b3BlIG9wZXJhdG9yLCBjaGFuZ2VkIHRvIHR5cGUgQU5ZDQogKDIwMTAxMDEz L2Rzd2xvYWQtODA4KQ0KQUNQSSBXYXJuaW5nOiBUeXBlIG92ZXJyaWRlIC0g W0NNT1NdIGhhZCBpbnZhbGlkIHR5cGUgKEludGVnZXIpIGZvciBTY29wZSBv cGVyYXRvciwgY2hhbmdlZCB0byB0eXBlIEFOWQ0KICgyMDEwMTAxMy9kc3ds b2FkLTgwOCkNCkFDUEkgV2FybmluZzogVHlwZSBvdmVycmlkZSAtIFtLQkNf XSBoYWQgaW52YWxpZCB0eXBlIChJbnRlZ2VyKSBmb3IgU2NvcGUgb3BlcmF0 b3IsIGNoYW5nZWQgdG8gdHlwZSBBTlkNCiAoMjAxMDEwMTMvZHN3bG9hZC04 MDgpDQpBQ1BJIFdhcm5pbmc6IFR5cGUgb3ZlcnJpZGUgLSBbT0VNX10gaGFk IGludmFsaWQgdHlwZSAoSW50ZWdlcikgZm9yIFNjb3BlIG9wZXJhdG9yLCBj aGFuZ2VkIHRvIHR5cGUgQU5ZDQogKDIwMTAxMDEzL2Rzd2xvYWQtODA4KQ0K aW9hcGljMDogcm91dGluZyBpbnRwaW4gOSAoSVNBIElSUSA5KSB0byBsYXBp YyAwIHZlY3RvciA0OA0KYWNwaTA6IFtNUFNBRkVdDQphY3BpMDogW0lUSFJF QURdDQphY3BpMDogUG93ZXIgQnV0dG9uIChmaXhlZCkNCmFjcGkwOiB3YWtl dXAgY29kZSB2YSAweGM0M2I2MDAwIHBhIDB4MTAwMA0KcGNpX29wZW4oMSk6 CW1vZGUgMSBhZGRyIHBvcnQgKDB4MGNmOCkgaXMgMHg4MDAwNzhhYw0KcGNp X29wZW4oMWEpOgltb2RlMXJlcz0weDgwMDAwMDAwICgweDgwMDAwMDAwKQ0K cGNpX2NmZ2NoZWNrOglkZXZpY2UgMCBbY2xhc3M9MDYwMDAwXSBbaGRyPTgw XSBpcyB0aGVyZSAoaWQ9MDAxNzExNjYpDQpwY2liaW9zOiBCSU9TIHZlcnNp b24gMi4xMA0KdW5rbm93bjogSS9PIHJhbmdlIG5vdCBzdXBwb3J0ZWQNCmFj cGkwOiByZXNlcnZhdGlvbiBvZiAwLCBhMDAwMCAoMykgZmFpbGVkDQphY3Bp MDogcmVzZXJ2YXRpb24gb2YgMTAwMDAwLCAzZmYwMDAwMCAoMykgZmFpbGVk DQpBQ1BJIHRpbWVyOiAwLzMgMS8yIDEvMiAwLzMgMC8zIDAvMyAxLzIgMC8z IDAvMyAwLzMgLT4gMw0KVGltZWNvdW50ZXIgIkFDUEktc2FmZSIgZnJlcXVl bmN5IDM1Nzk1NDUgSHogcXVhbGl0eSA4NTANCmFjcGlfdGltZXIwOiA8MzIt Yml0IHRpbWVyIGF0IDMuNTc5NTQ1TUh6PiBwb3J0IDB4NTA4LTB4NTBiIG9u IGFjcGkwDQpjcHUwOiA8QUNQSSBDUFU+IG9uIGFjcGkwDQpjcHUwOiBzd2l0 Y2hpbmcgdG8gZ2VuZXJpYyBDeCBtb2RlDQpwY2lfbGluazA6ICAgICAgICBJ bmRleCAgSVJRICBSdGQgIFJlZiAgSVJRcw0KICBJbml0aWFsIFByb2JlICAg ICAgIDAgIDI1NSAgIE4gICAgIDAgIDMgNCA1IDcgOSAxMSAxMiAxNCAxNQ0K ICBWYWxpZGF0aW9uICAgICAgICAgIDAgIDI1NSAgIE4gICAgIDAgIDMgNCA1 IDcgOSAxMSAxMiAxNCAxNQ0KICBBZnRlciBEaXNhYmxlICAgICAgIDAgIDI1 NSAgIE4gICAgIDAgIDMgNCA1IDcgOSAxMSAxMiAxNCAxNQ0KcGNpX2xpbmsx OiAgICAgICAgSW5kZXggIElSUSAgUnRkICBSZWYgIElSUXMNCiAgSW5pdGlh bCBQcm9iZSAgICAgICAwICAyNTUgICBOICAgICAwICAzIDQgNSA3IDkgMTEg MTIgMTQgMTUNCiAgVmFsaWRhdGlvbiAgICAgICAgICAwICAyNTUgICBOICAg ICAwICAzIDQgNSA3IDkgMTEgMTIgMTQgMTUNCiAgQWZ0ZXIgRGlzYWJsZSAg ICAgICAwICAyNTUgICBOICAgICAwICAzIDQgNSA3IDkgMTEgMTIgMTQgMTUN CnBjaV9saW5rMjogICAgICAgIEluZGV4ICBJUlEgIFJ0ZCAgUmVmICBJUlFz DQogIEluaXRpYWwgUHJvYmUgICAgICAgMCAgMjU1ICAgTiAgICAgMCAgMyA0 IDUgNyA5IDExIDEyIDE0IDE1DQogIFZhbGlkYXRpb24gICAgICAgICAgMCAg MjU1ICAgTiAgICAgMCAgMyA0IDUgNyA5IDExIDEyIDE0IDE1DQogIEFmdGVy IERpc2FibGUgICAgICAgMCAgMjU1ICAgTiAgICAgMCAgMyA0IDUgNyA5IDEx IDEyIDE0IDE1DQpwY2lfbGluazM6ICAgICAgICBJbmRleCAgSVJRICBSdGQg IFJlZiAgSVJRcw0KICBJbml0aWFsIFByb2JlICAgICAgIDAgIDI1NSAgIE4g ICAgIDAgIDMgNCA1IDcgOSAxMSAxMiAxNCAxNQ0KICBWYWxpZGF0aW9uICAg ICAgICAgIDAgIDI1NSAgIE4gICAgIDAgIDMgNCA1IDcgOSAxMSAxMiAxNCAx NQ0KICBBZnRlciBEaXNhYmxlICAgICAgIDAgIDI1NSAgIE4gICAgIDAgIDMg NCA1IDcgOSAxMSAxMiAxNCAxNQ0KcGNpX2xpbms0OiAgICAgICAgSW5kZXgg IElSUSAgUnRkICBSZWYgIElSUXMNCiAgSW5pdGlhbCBQcm9iZSAgICAgICAw ICAyNTUgICBOICAgICAwICAzIDQgNSA3IDkgMTEgMTIgMTQgMTUNCiAgVmFs aWRhdGlvbiAgICAgICAgICAwICAyNTUgICBOICAgICAwICAzIDQgNSA3IDkg MTEgMTIgMTQgMTUNCiAgQWZ0ZXIgRGlzYWJsZSAgICAgICAwICAyNTUgICBO ICAgICAwICAzIDQgNSA3IDkgMTEgMTIgMTQgMTUNCnBjaV9saW5rNTogICAg ICAgIEluZGV4ICBJUlEgIFJ0ZCAgUmVmICBJUlFzDQogIEluaXRpYWwgUHJv YmUgICAgICAgMCAgMjU1ICAgTiAgICAgMCAgMyA0IDUgNyA5IDExIDEyIDE0 IDE1DQogIFZhbGlkYXRpb24gICAgICAgICAgMCAgMjU1ICAgTiAgICAgMCAg MyA0IDUgNyA5IDExIDEyIDE0IDE1DQogIEFmdGVyIERpc2FibGUgICAgICAg MCAgMjU1ICAgTiAgICAgMCAgMyA0IDUgNyA5IDExIDEyIDE0IDE1DQpwY2lf bGluazY6ICAgICAgICBJbmRleCAgSVJRICBSdGQgIFJlZiAgSVJRcw0KICBJ bml0aWFsIFByb2JlICAgICAgIDAgIDI1NSAgIE4gICAgIDAgIDMgNCA1IDcg OSAxMSAxMiAxNCAxNQ0KICBWYWxpZGF0aW9uICAgICAgICAgIDAgIDI1NSAg IE4gICAgIDAgIDMgNCA1IDcgOSAxMSAxMiAxNCAxNQ0KICBBZnRlciBEaXNh YmxlICAgICAgIDAgIDI1NSAgIE4gICAgIDAgIDMgNCA1IDcgOSAxMSAxMiAx NCAxNQ0KcGNpX2xpbms3OiAgICAgICAgSW5kZXggIElSUSAgUnRkICBSZWYg IElSUXMNCiAgSW5pdGlhbCBQcm9iZSAgICAgICAwICAyNTUgICBOICAgICAw ICAzIDQgNSA3IDkgMTEgMTIgMTQgMTUNCiAgVmFsaWRhdGlvbiAgICAgICAg ICAwICAyNTUgICBOICAgICAwICAzIDQgNSA3IDkgMTEgMTIgMTQgMTUNCiAg QWZ0ZXIgRGlzYWJsZSAgICAgICAwICAyNTUgICBOICAgICAwICAzIDQgNSA3 IDkgMTEgMTIgMTQgMTUNCnBjaV9saW5rODogICAgICAgIEluZGV4ICBJUlEg IFJ0ZCAgUmVmICBJUlFzDQogIEluaXRpYWwgUHJvYmUgICAgICAgMCAgMjU1 ICAgTiAgICAgMCAgMyA0IDUgNyA5IDExIDEyIDE0IDE1DQogIFZhbGlkYXRp b24gICAgICAgICAgMCAgMjU1ICAgTiAgICAgMCAgMyA0IDUgNyA5IDExIDEy IDE0IDE1DQogIEFmdGVyIERpc2FibGUgICAgICAgMCAgMjU1ICAgTiAgICAg MCAgMyA0IDUgNyA5IDExIDEyIDE0IDE1DQpwY2lfbGluazk6ICAgICAgICBJ bmRleCAgSVJRICBSdGQgIFJlZiAgSVJRcw0KICBJbml0aWFsIFByb2JlICAg ICAgIDAgIDI1NSAgIE4gICAgIDAgIDMgNCA1IDcgOSAxMSAxMiAxNCAxNQ0K ICBWYWxpZGF0aW9uICAgICAgICAgIDAgIDI1NSAgIE4gICAgIDAgIDMgNCA1 IDcgOSAxMSAxMiAxNCAxNQ0KICBBZnRlciBEaXNhYmxlICAgICAgIDAgIDI1 NSAgIE4gICAgIDAgIDMgNCA1IDcgOSAxMSAxMiAxNCAxNQ0KcGNpX2xpbmsx MDogICAgICAgSW5kZXggIElSUSAgUnRkICBSZWYgIElSUXMNCiAgSW5pdGlh bCBQcm9iZSAgICAgICAwICAyNTUgICBOICAgICAwICAzIDQgNSA3IDkgMTEg MTIgMTQgMTUNCiAgVmFsaWRhdGlvbiAgICAgICAgICAwICAyNTUgICBOICAg ICAwICAzIDQgNSA3IDkgMTEgMTIgMTQgMTUNCiAgQWZ0ZXIgRGlzYWJsZSAg ICAgICAwICAyNTUgICBOICAgICAwICAzIDQgNSA3IDkgMTEgMTIgMTQgMTUN CnBjaV9saW5rMTE6ICAgICAgIEluZGV4ICBJUlEgIFJ0ZCAgUmVmICBJUlFz DQogIEluaXRpYWwgUHJvYmUgICAgICAgMCAgMjU1ICAgTiAgICAgMCAgMyA0 IDUgNyA5IDExIDEyIDE0IDE1DQogIFZhbGlkYXRpb24gICAgICAgICAgMCAg MjU1ICAgTiAgICAgMCAgMyA0IDUgNyA5IDExIDEyIDE0IDE1DQogIEFmdGVy IERpc2FibGUgICAgICAgMCAgMjU1ICAgTiAgICAgMCAgMyA0IDUgNyA5IDEx IDEyIDE0IDE1DQpwY2lfbGluazEyOiAgICAgICBJbmRleCAgSVJRICBSdGQg IFJlZiAgSVJRcw0KICBJbml0aWFsIFByb2JlICAgICAgIDAgIDI1NSAgIE4g ICAgIDAgIDMgNCA1IDcgOSAxMSAxMiAxNCAxNQ0KICBWYWxpZGF0aW9uICAg ICAgICAgIDAgIDI1NSAgIE4gICAgIDAgIDMgNCA1IDcgOSAxMSAxMiAxNCAx NQ0KICBBZnRlciBEaXNhYmxlICAgICAgIDAgIDI1NSAgIE4gICAgIDAgIDMg NCA1IDcgOSAxMSAxMiAxNCAxNQ0KcGNpX2xpbmsxMzogICAgICAgSW5kZXgg IElSUSAgUnRkICBSZWYgIElSUXMNCiAgSW5pdGlhbCBQcm9iZSAgICAgICAw ICAyNTUgICBOICAgICAwICAzIDQgNSA3IDkgMTEgMTIgMTQgMTUNCiAgVmFs aWRhdGlvbiAgICAgICAgICAwICAyNTUgICBOICAgICAwICAzIDQgNSA3IDkg MTEgMTIgMTQgMTUNCiAgQWZ0ZXIgRGlzYWJsZSAgICAgICAwICAyNTUgICBO ICAgICAwICAzIDQgNSA3IDkgMTEgMTIgMTQgMTUNCnBjaV9saW5rMTQ6ICAg ICAgIEluZGV4ICBJUlEgIFJ0ZCAgUmVmICBJUlFzDQogIEluaXRpYWwgUHJv YmUgICAgICAgMCAgMjU1ICAgTiAgICAgMCAgMyA0IDUgNyA5IDExIDEyIDE0 IDE1DQogIFZhbGlkYXRpb24gICAgICAgICAgMCAgMjU1ICAgTiAgICAgMCAg MyA0IDUgNyA5IDExIDEyIDE0IDE1DQogIEFmdGVyIERpc2FibGUgICAgICAg MCAgMjU1ICAgTiAgICAgMCAgMyA0IDUgNyA5IDExIDEyIDE0IDE1DQpwY2lf bGluazE1OiAgICAgICBJbmRleCAgSVJRICBSdGQgIFJlZiAgSVJRcw0KICBJ bml0aWFsIFByb2JlICAgICAgIDAgIDI1NSAgIE4gICAgIDAgIDMgNCA1IDcg OSAxMSAxMiAxNCAxNQ0KICBWYWxpZGF0aW9uICAgICAgICAgIDAgIDI1NSAg IE4gICAgIDAgIDMgNCA1IDcgOSAxMSAxMiAxNCAxNQ0KICBBZnRlciBEaXNh YmxlICAgICAgIDAgIDI1NSAgIE4gICAgIDAgIDMgNCA1IDcgOSAxMSAxMiAx NCAxNQ0KcGNpX2xpbmsxNjogICAgICAgSW5kZXggIElSUSAgUnRkICBSZWYg IElSUXMNCiAgSW5pdGlhbCBQcm9iZSAgICAgICAwICAyNTUgICBOICAgICAw ICAzIDQgNSA3IDkgMTEgMTIgMTQgMTUNCiAgVmFsaWRhdGlvbiAgICAgICAg ICAwICAyNTUgICBOICAgICAwICAzIDQgNSA3IDkgMTEgMTIgMTQgMTUNCiAg QWZ0ZXIgRGlzYWJsZSAgICAgICAwICAyNTUgICBOICAgICAwICAzIDQgNSA3 IDkgMTEgMTIgMTQgMTUNCnBjaV9saW5rMTc6ICAgICAgIEluZGV4ICBJUlEg IFJ0ZCAgUmVmICBJUlFzDQogIEluaXRpYWwgUHJvYmUgICAgICAgMCAgMjU1 ICAgTiAgICAgMCAgMyA0IDUgNyA5IDExIDEyIDE0IDE1DQogIFZhbGlkYXRp b24gICAgICAgICAgMCAgMjU1ICAgTiAgICAgMCAgMyA0IDUgNyA5IDExIDEy IDE0IDE1DQogIEFmdGVyIERpc2FibGUgICAgICAgMCAgMjU1ICAgTiAgICAg MCAgMyA0IDUgNyA5IDExIDEyIDE0IDE1DQpwY2lfbGluazE4OiAgICAgICBJ bmRleCAgSVJRICBSdGQgIFJlZiAgSVJRcw0KICBJbml0aWFsIFByb2JlICAg ICAgIDAgIDI1NSAgIE4gICAgIDAgIDMgNCA1IDcgOSAxMSAxMiAxNCAxNQ0K ICBWYWxpZGF0aW9uICAgICAgICAgIDAgIDI1NSAgIE4gICAgIDAgIDMgNCA1 IDcgOSAxMSAxMiAxNCAxNQ0KICBBZnRlciBEaXNhYmxlICAgICAgIDAgIDI1 NSAgIE4gICAgIDAgIDMgNCA1IDcgOSAxMSAxMiAxNCAxNQ0KcGNpX2xpbmsx OTogICAgICAgSW5kZXggIElSUSAgUnRkICBSZWYgIElSUXMNCiAgSW5pdGlh bCBQcm9iZSAgICAgICAwICAyNTUgICBOICAgICAwICAzIDQgNSA3IDkgMTEg MTIgMTQgMTUNCiAgVmFsaWRhdGlvbiAgICAgICAgICAwICAyNTUgICBOICAg ICAwICAzIDQgNSA3IDkgMTEgMTIgMTQgMTUNCiAgQWZ0ZXIgRGlzYWJsZSAg ICAgICAwICAyNTUgICBOICAgICAwICAzIDQgNSA3IDkgMTEgMTIgMTQgMTUN CnBjaV9saW5rMjA6ICAgICAgIEluZGV4ICBJUlEgIFJ0ZCAgUmVmICBJUlFz DQogIEluaXRpYWwgUHJvYmUgICAgICAgMCAgMjU1ICAgTiAgICAgMCAgMyA0 IDUgNyA5IDExIDEyIDE0IDE1DQogIFZhbGlkYXRpb24gICAgICAgICAgMCAg MjU1ICAgTiAgICAgMCAgMyA0IDUgNyA5IDExIDEyIDE0IDE1DQogIEFmdGVy IERpc2FibGUgICAgICAgMCAgMjU1ICAgTiAgICAgMCAgMyA0IDUgNyA5IDEx IDEyIDE0IDE1DQpwY2lfbGluazIxOiAgICAgICBJbmRleCAgSVJRICBSdGQg IFJlZiAgSVJRcw0KICBJbml0aWFsIFByb2JlICAgICAgIDAgIDI1NSAgIE4g ICAgIDAgIDMgNCA1IDcgOSAxMSAxMiAxNCAxNQ0KICBWYWxpZGF0aW9uICAg ICAgICAgIDAgIDI1NSAgIE4gICAgIDAgIDMgNCA1IDcgOSAxMSAxMiAxNCAx NQ0KICBBZnRlciBEaXNhYmxlICAgICAgIDAgIDI1NSAgIE4gICAgIDAgIDMg NCA1IDcgOSAxMSAxMiAxNCAxNQ0KcGNpX2xpbmsyMjogICAgICAgSW5kZXgg IElSUSAgUnRkICBSZWYgIElSUXMNCiAgSW5pdGlhbCBQcm9iZSAgICAgICAw ICAyNTUgICBOICAgICAwICAzIDQgNSA3IDkgMTEgMTIgMTQgMTUNCiAgVmFs aWRhdGlvbiAgICAgICAgICAwICAyNTUgICBOICAgICAwICAzIDQgNSA3IDkg MTEgMTIgMTQgMTUNCiAgQWZ0ZXIgRGlzYWJsZSAgICAgICAwICAyNTUgICBO ICAgICAwICAzIDQgNSA3IDkgMTEgMTIgMTQgMTUNCnBjaV9saW5rMjM6ICAg ICAgIEluZGV4ICBJUlEgIFJ0ZCAgUmVmICBJUlFzDQogIEluaXRpYWwgUHJv YmUgICAgICAgMCAgMjU1ICAgTiAgICAgMCAgMyA0IDUgNyA5IDExIDEyIDE0 IDE1DQogIFZhbGlkYXRpb24gICAgICAgICAgMCAgMjU1ICAgTiAgICAgMCAg MyA0IDUgNyA5IDExIDEyIDE0IDE1DQogIEFmdGVyIERpc2FibGUgICAgICAg MCAgMjU1ICAgTiAgICAgMCAgMyA0IDUgNyA5IDExIDEyIDE0IDE1DQpwY2lf bGluazI0OiAgICAgICBJbmRleCAgSVJRICBSdGQgIFJlZiAgSVJRcw0KICBJ bml0aWFsIFByb2JlICAgICAgIDAgIDI1NSAgIE4gICAgIDAgIDMgNCA1IDcg OSAxMSAxMiAxNCAxNQ0KICBWYWxpZGF0aW9uICAgICAgICAgIDAgIDI1NSAg IE4gICAgIDAgIDMgNCA1IDcgOSAxMSAxMiAxNCAxNQ0KICBBZnRlciBEaXNh YmxlICAgICAgIDAgIDI1NSAgIE4gICAgIDAgIDMgNCA1IDcgOSAxMSAxMiAx NCAxNQ0KcGNpX2xpbmsyNTogICAgICAgSW5kZXggIElSUSAgUnRkICBSZWYg IElSUXMNCiAgSW5pdGlhbCBQcm9iZSAgICAgICAwICAyNTUgICBOICAgICAw ICAzIDQgNSA3IDkgMTEgMTIgMTQgMTUNCiAgVmFsaWRhdGlvbiAgICAgICAg ICAwICAyNTUgICBOICAgICAwICAzIDQgNSA3IDkgMTEgMTIgMTQgMTUNCiAg QWZ0ZXIgRGlzYWJsZSAgICAgICAwICAyNTUgICBOICAgICAwICAzIDQgNSA3 IDkgMTEgMTIgMTQgMTUNCnBjaV9saW5rMjY6ICAgICAgIEluZGV4ICBJUlEg IFJ0ZCAgUmVmICBJUlFzDQogIEluaXRpYWwgUHJvYmUgICAgICAgMCAgMjU1 ICAgTiAgICAgMCAgMyA0IDUgNyA5IDExIDEyIDE0IDE1DQogIFZhbGlkYXRp b24gICAgICAgICAgMCAgMjU1ICAgTiAgICAgMCAgMyA0IDUgNyA5IDExIDEy IDE0IDE1DQogIEFmdGVyIERpc2FibGUgICAgICAgMCAgMjU1ICAgTiAgICAg MCAgMyA0IDUgNyA5IDExIDEyIDE0IDE1DQpwY2lfbGluazI3OiAgICAgICBJ bmRleCAgSVJRICBSdGQgIFJlZiAgSVJRcw0KICBJbml0aWFsIFByb2JlICAg ICAgIDAgIDI1NSAgIE4gICAgIDAgIDMgNCA1IDcgOSAxMSAxMiAxNCAxNQ0K ICBWYWxpZGF0aW9uICAgICAgICAgIDAgIDI1NSAgIE4gICAgIDAgIDMgNCA1 IDcgOSAxMSAxMiAxNCAxNQ0KICBBZnRlciBEaXNhYmxlICAgICAgIDAgIDI1 NSAgIE4gICAgIDAgIDMgNCA1IDcgOSAxMSAxMiAxNCAxNQ0KcGNpX2xpbmsy ODogICAgICAgSW5kZXggIElSUSAgUnRkICBSZWYgIElSUXMNCiAgSW5pdGlh bCBQcm9iZSAgICAgICAwICAyNTUgICBOICAgICAwICAzIDQgNSA3IDkgMTEg MTIgMTQgMTUNCiAgVmFsaWRhdGlvbiAgICAgICAgICAwICAyNTUgICBOICAg ICAwICAzIDQgNSA3IDkgMTEgMTIgMTQgMTUNCiAgQWZ0ZXIgRGlzYWJsZSAg ICAgICAwICAyNTUgICBOICAgICAwICAzIDQgNSA3IDkgMTEgMTIgMTQgMTUN CnBjaV9saW5rMjk6ICAgICAgIEluZGV4ICBJUlEgIFJ0ZCAgUmVmICBJUlFz DQogIEluaXRpYWwgUHJvYmUgICAgICAgMCAgMjU1ICAgTiAgICAgMCAgMyA0 IDUgNyA5IDExIDEyIDE0IDE1DQogIFZhbGlkYXRpb24gICAgICAgICAgMCAg MjU1ICAgTiAgICAgMCAgMyA0IDUgNyA5IDExIDEyIDE0IDE1DQogIEFmdGVy IERpc2FibGUgICAgICAgMCAgMjU1ICAgTiAgICAgMCAgMyA0IDUgNyA5IDEx IDEyIDE0IDE1DQpwY2lfbGluazMwOiAgICAgICBJbmRleCAgSVJRICBSdGQg IFJlZiAgSVJRcw0KICBJbml0aWFsIFByb2JlICAgICAgIDAgIDI1NSAgIE4g ICAgIDAgIDMgNCA1IDcgOSAxMSAxMiAxNCAxNQ0KICBWYWxpZGF0aW9uICAg ICAgICAgIDAgIDI1NSAgIE4gICAgIDAgIDMgNCA1IDcgOSAxMSAxMiAxNCAx NQ0KICBBZnRlciBEaXNhYmxlICAgICAgIDAgIDI1NSAgIE4gICAgIDAgIDMg NCA1IDcgOSAxMSAxMiAxNCAxNQ0KcGNpX2xpbmszMTogICAgICAgSW5kZXgg IElSUSAgUnRkICBSZWYgIElSUXMNCiAgSW5pdGlhbCBQcm9iZSAgICAgICAw ICAyNTUgICBOICAgICAwICAzIDQgNSA3IDkgMTEgMTIgMTQgMTUNCiAgVmFs aWRhdGlvbiAgICAgICAgICAwICAyNTUgICBOICAgICAwICAzIDQgNSA3IDkg MTEgMTIgMTQgMTUNCiAgQWZ0ZXIgRGlzYWJsZSAgICAgICAwICAyNTUgICBO ICAgICAwICAzIDQgNSA3IDkgMTEgMTIgMTQgMTUNCnBjaV9saW5rMzI6ICAg ICAgIEluZGV4ICBJUlEgIFJ0ZCAgUmVmICBJUlFzDQogIEluaXRpYWwgUHJv YmUgICAgICAgMCAgIDEwICAgTiAgICAgMCAgMTANCiAgVmFsaWRhdGlvbiAg ICAgICAgICAwICAgMTAgICBOICAgICAwICAxMA0KICBBZnRlciBEaXNhYmxl ICAgICAgIDAgIDI1NSAgIE4gICAgIDAgIDEwDQpwY2lfbGluazMzOiAgICAg ICBJbmRleCAgSVJRICBSdGQgIFJlZiAgSVJRcw0KICBJbml0aWFsIFByb2Jl ICAgICAgIDAgIDI1NSAgIE4gICAgIDAgIDExDQogIFZhbGlkYXRpb24gICAg ICAgICAgMCAgMjU1ICAgTiAgICAgMCAgMTENCiAgQWZ0ZXIgRGlzYWJsZSAg ICAgICAwICAyNTUgICBOICAgICAwICAxMQ0KYWNwaV9idXR0b24wOiA8U2xl ZXAgQnV0dG9uPiBvbiBhY3BpMA0KcGNpYjA6IDxBQ1BJIEhvc3QtUENJIGJy aWRnZT4gcG9ydCAweGNmOC0weGNmZiBvbiBhY3BpMA0KQUNQSTogRm91bmQg bWF0Y2hpbmcgcGluIGZvciAwLjE1LklOVEEgYXQgZnVuYyAyOiAxMA0KcGNp MDogPEFDUEkgUENJIGJ1cz4gb24gcGNpYjANCnBjaTA6IGRvbWFpbj0wLCBw aHlzaWNhbCBidXM9MA0KZm91bmQtPgl2ZW5kb3I9MHgxMTY2LCBkZXY9MHgw MDE3LCByZXZpZD0weDMyDQoJZG9tYWluPTAsIGJ1cz0wLCBzbG90PTAsIGZ1 bmM9MA0KCWNsYXNzPTA2LTAwLTAwLCBoZHJ0eXBlPTB4MDAsIG1mZGV2PTEN CgljbWRyZWc9MHgwMDAwLCBzdGF0cmVnPTB4MDAwMCwgY2FjaGVsbnN6PTE2 IChkd29yZHMpDQoJbGF0dGltZXI9MHgwMCAoMCBucyksIG1pbmdudD0weDAw ICgwIG5zKSwgbWF4bGF0PTB4MDAgKDAgbnMpDQpmb3VuZC0+CXZlbmRvcj0w eDExNjYsIGRldj0weDAwMTcsIHJldmlkPTB4MDANCglkb21haW49MCwgYnVz PTAsIHNsb3Q9MCwgZnVuYz0xDQoJY2xhc3M9MDYtMDAtMDAsIGhkcnR5cGU9 MHgwMCwgbWZkZXY9MQ0KCWNtZHJlZz0weDAwMDAsIHN0YXRyZWc9MHgwMDAw LCBjYWNoZWxuc3o9MTYgKGR3b3JkcykNCglsYXR0aW1lcj0weDAwICgwIG5z KSwgbWluZ250PTB4MDAgKDAgbnMpLCBtYXhsYXQ9MHgwMCAoMCBucykNCmZv dW5kLT4JdmVuZG9yPTB4ODA4NiwgZGV2PTB4MTAyNiwgcmV2aWQ9MHgwNA0K CWRvbWFpbj0wLCBidXM9MCwgc2xvdD0xLCBmdW5jPTANCgljbGFzcz0wMi0w MC0wMCwgaGRydHlwZT0weDAwLCBtZmRldj0wDQoJY21kcmVnPTB4MDExNywg c3RhdHJlZz0weDAyMzAsIGNhY2hlbG5zej0xNiAoZHdvcmRzKQ0KCWxhdHRp bWVyPTB4NDAgKDE5MjAgbnMpLCBtaW5nbnQ9MHhmZiAoNjM3NTAgbnMpLCBt YXhsYXQ9MHgwMCAoMCBucykNCglpbnRwaW49YSwgaXJxPTUNCglwb3dlcnNw ZWMgMiAgc3VwcG9ydHMgRDAgRDMgIGN1cnJlbnQgRDANCgltYXBbMTBdOiB0 eXBlIE1lbW9yeSwgcmFuZ2UgNjQsIGJhc2UgMHhmZWI2MDAwMCwgc2l6ZSAx NywgZW5hYmxlZA0KCW1hcFsxOF06IHR5cGUgTWVtb3J5LCByYW5nZSA2NCwg YmFzZSAweGZlYjAwMDAwLCBzaXplIDE4LCBlbmFibGVkDQoJbWFwWzIwXTog dHlwZSBJL08gUG9ydCwgcmFuZ2UgMzIsIGJhc2UgMHhlMDAwLCBzaXplICA2 LCBlbmFibGVkDQpwY2liMDogbWF0Y2hlZCBlbnRyeSBmb3IgMC4xLklOVEEN CnBjaWIwOiBzbG90IDEgSU5UQSBoYXJkd2lyZWQgdG8gSVJRIDE2DQpmb3Vu ZC0+CXZlbmRvcj0weDEwMDIsIGRldj0weDQ3NTIsIHJldmlkPTB4MjcNCglk b21haW49MCwgYnVzPTAsIHNsb3Q9NiwgZnVuYz0wDQoJY2xhc3M9MDMtMDAt MDAsIGhkcnR5cGU9MHgwMCwgbWZkZXY9MA0KCWNtZHJlZz0weDAwODcsIHN0 YXRyZWc9MHgwMjkwLCBjYWNoZWxuc3o9MTYgKGR3b3JkcykNCglsYXR0aW1l cj0weDQwICgxOTIwIG5zKSwgbWluZ250PTB4MDggKDIwMDAgbnMpLCBtYXhs YXQ9MHgwMCAoMCBucykNCglpbnRwaW49YSwgaXJxPTEwDQoJcG93ZXJzcGVj IDIgIHN1cHBvcnRzIEQwIEQxIEQyIEQzICBjdXJyZW50IEQwDQoJbWFwWzEw XTogdHlwZSBNZW1vcnksIHJhbmdlIDMyLCBiYXNlIDB4ZmQwMDAwMDAsIHNp emUgMjQsIGVuYWJsZWQNCgltYXBbMTRdOiB0eXBlIEkvTyBQb3J0LCByYW5n ZSAzMiwgYmFzZSAweGU4MDAsIHNpemUgIDgsIGVuYWJsZWQNCgltYXBbMThd OiB0eXBlIE1lbW9yeSwgcmFuZ2UgMzIsIGJhc2UgMHhmZWJmZjAwMCwgc2l6 ZSAxMiwgZW5hYmxlZA0KcGNpYjA6IG1hdGNoZWQgZW50cnkgZm9yIDAuNi5J TlRBDQpwY2liMDogc2xvdCA2IElOVEEgaGFyZHdpcmVkIHRvIElSUSAyNg0K Zm91bmQtPgl2ZW5kb3I9MHg4MDg2LCBkZXY9MHgxMjI5LCByZXZpZD0weDEw DQoJZG9tYWluPTAsIGJ1cz0wLCBzbG90PTcsIGZ1bmM9MA0KCWNsYXNzPTAy LTAwLTAwLCBoZHJ0eXBlPTB4MDAsIG1mZGV2PTANCgljbWRyZWc9MHgwMTE3 LCBzdGF0cmVnPTB4MDI5MCwgY2FjaGVsbnN6PTE2IChkd29yZHMpDQoJbGF0 dGltZXI9MHg0MCAoMTkyMCBucyksIG1pbmdudD0weDA4ICgyMDAwIG5zKSwg bWF4bGF0PTB4MzggKDE0MDAwIG5zKQ0KCWludHBpbj1hLCBpcnE9OQ0KCXBv d2Vyc3BlYyAyICBzdXBwb3J0cyBEMCBEMSBEMiBEMyAgY3VycmVudCBEMA0K CW1hcFsxMF06IHR5cGUgTWVtb3J5LCByYW5nZSAzMiwgYmFzZSAweGZlYmZk MDAwLCBzaXplIDEyLCBlbmFibGVkDQoJbWFwWzE0XTogdHlwZSBJL08gUG9y dCwgcmFuZ2UgMzIsIGJhc2UgMHhlNDAwLCBzaXplICA2LCBlbmFibGVkDQoJ bWFwWzE4XTogdHlwZSBNZW1vcnksIHJhbmdlIDMyLCBiYXNlIDB4ZmViODAw MDAsIHNpemUgMTcsIGVuYWJsZWQNCnBjaWIwOiBtYXRjaGVkIGVudHJ5IGZv ciAwLjcuSU5UQQ0KcGNpYjA6IHNsb3QgNyBJTlRBIGhhcmR3aXJlZCB0byBJ UlEgMjcNCmZvdW5kLT4JdmVuZG9yPTB4MTRlNCwgZGV2PTB4MTZhNiwgcmV2 aWQ9MHgwMg0KCWRvbWFpbj0wLCBidXM9MCwgc2xvdD04LCBmdW5jPTANCglj bGFzcz0wMi0wMC0wMCwgaGRydHlwZT0weDAwLCBtZmRldj0wDQoJY21kcmVn PTB4MDExNiwgc3RhdHJlZz0weDAyYjAsIGNhY2hlbG5zej0xNiAoZHdvcmRz KQ0KCWxhdHRpbWVyPTB4NDAgKDE5MjAgbnMpLCBtaW5nbnQ9MHg0MCAoMTYw MDAgbnMpLCBtYXhsYXQ9MHgwMCAoMCBucykNCglpbnRwaW49YSwgaXJxPTEx DQoJcG93ZXJzcGVjIDIgIHN1cHBvcnRzIEQwIEQzICBjdXJyZW50IEQwDQoJ TVNJIHN1cHBvcnRzIDggbWVzc2FnZXMsIDY0IGJpdA0KCW1hcFsxMF06IHR5 cGUgTWVtb3J5LCByYW5nZSA2NCwgYmFzZSAweGZlYmUwMDAwLCBzaXplIDE2 LCBlbmFibGVkDQpwY2liMDogbWF0Y2hlZCBlbnRyeSBmb3IgMC44LklOVEEN CnBjaWIwOiBzbG90IDggSU5UQSBoYXJkd2lyZWQgdG8gSVJRIDI4DQpmb3Vu ZC0+CXZlbmRvcj0weDExNjYsIGRldj0weDAyMDMsIHJldmlkPTB4YTANCglk b21haW49MCwgYnVzPTAsIHNsb3Q9MTUsIGZ1bmM9MA0KCWNsYXNzPTA2LTAw LTAwLCBoZHJ0eXBlPTB4MDAsIG1mZGV2PTENCgljbWRyZWc9MHgwMTA3LCBz dGF0cmVnPTB4MjIwMCwgY2FjaGVsbnN6PTAgKGR3b3JkcykNCglsYXR0aW1l cj0weDQwICgxOTIwIG5zKSwgbWluZ250PTB4MDAgKDAgbnMpLCBtYXhsYXQ9 MHgwMCAoMCBucykNCmZvdW5kLT4JdmVuZG9yPTB4MTE2NiwgZGV2PTB4MDIx MywgcmV2aWQ9MHhhMA0KCWRvbWFpbj0wLCBidXM9MCwgc2xvdD0xNSwgZnVu Yz0xDQoJY2xhc3M9MDEtMDEtOGEsIGhkcnR5cGU9MHgwMCwgbWZkZXY9MQ0K CWNtZHJlZz0weDAwMTUsIHN0YXRyZWc9MHgwMjAwLCBjYWNoZWxuc3o9OCAo ZHdvcmRzKQ0KCWxhdHRpbWVyPTB4NDAgKDE5MjAgbnMpLCBtaW5nbnQ9MHgw MCAoMCBucyksIG1heGxhdD0weDAwICgwIG5zKQ0KCW1hcFsyMF06IHR5cGUg SS9PIFBvcnQsIHJhbmdlIDMyLCBiYXNlIDB4ZmZhMCwgc2l6ZSAgNCwgZW5h YmxlZA0KZm91bmQtPgl2ZW5kb3I9MHgxMTY2LCBkZXY9MHgwMjIxLCByZXZp ZD0weDA1DQoJZG9tYWluPTAsIGJ1cz0wLCBzbG90PTE1LCBmdW5jPTINCglj bGFzcz0wYy0wMy0xMCwgaGRydHlwZT0weDAwLCBtZmRldj0xDQoJY21kcmVn PTB4MDExNywgc3RhdHJlZz0weDAyODAsIGNhY2hlbG5zej0wIChkd29yZHMp DQoJbGF0dGltZXI9MHg0MCAoMTkyMCBucyksIG1pbmdudD0weDAwICgwIG5z KSwgbWF4bGF0PTB4NTAgKDIwMDAwIG5zKQ0KCWludHBpbj1hLCBpcnE9MTAN CgltYXBbMTBdOiB0eXBlIE1lbW9yeSwgcmFuZ2UgMzIsIGJhc2UgMHhmZWJm ZTAwMCwgc2l6ZSAxMiwgZW5hYmxlZA0KcGNpYjA6IG1hdGNoZWQgZW50cnkg Zm9yIDAuMTUuSU5UQSAoc3JjIFxcX1NCXy5MTlVTOjApDQppb2FwaWMwOiBD aGFuZ2luZyB0cmlnZ2VyIGZvciBwaW4gMTAgdG8gbGV2ZWwNCmlvYXBpYzA6 IENoYW5naW5nIHBvbGFyaXR5IGZvciBwaW4gMTAgdG8gbG93DQpwY2liMDog c2xvdCAxNSBJTlRBIHJvdXRlZCB0byBpcnEgMTAgdmlhIFxcX1NCXy5MTlVT DQp1bmtub3duOiBSZXNlcnZlZCAweDEwMDAgYnl0ZXMgZm9yIHJpZCAweDEw IHR5cGUgMyBhdCAweGZlYmZlMDAwDQpvaGNpIGVhcmx5OiBTTU0gYWN0aXZl LCByZXF1ZXN0IG93bmVyIGNoYW5nZQ0KZm91bmQtPgl2ZW5kb3I9MHgxMTY2 LCBkZXY9MHgwMjI3LCByZXZpZD0weDAwDQoJZG9tYWluPTAsIGJ1cz0wLCBz bG90PTE1LCBmdW5jPTMNCgljbGFzcz0wNi0wMS0wMCwgaGRydHlwZT0weDAw LCBtZmRldj0xDQoJY21kcmVnPTB4MDEwNywgc3RhdHJlZz0weDAyMDAsIGNh Y2hlbG5zej0wIChkd29yZHMpDQoJbGF0dGltZXI9MHgwMCAoMCBucyksIG1p bmdudD0weDAwICgwIG5zKSwgbWF4bGF0PTB4MDAgKDAgbnMpDQplbTA6IDxJ bnRlbChSKSBQUk8vMTAwMCBMZWdhY3kgTmV0d29yayBDb25uZWN0aW9uIDEu MC40PiBwb3J0IDB4ZTAwMC0weGUwM2YgbWVtIDB4ZmViNjAwMDAtMHhmZWI3 ZmZmZiwweGZlYjAwMDAwLTB4ZmViM2ZmZmYgaXJxIDE2IGF0IGRldmljZSAx LjAgb24gcGNpMA0KZW0wOiBSZXNlcnZlZCAweDIwMDAwIGJ5dGVzIGZvciBy aWQgMHgxMCB0eXBlIDMgYXQgMHhmZWI2MDAwMA0KZW0wOiBSZXNlcnZlZCAw eDQwIGJ5dGVzIGZvciByaWQgMHgyMCB0eXBlIDQgYXQgMHhlMDAwDQppb2Fw aWMxOiByb3V0aW5nIGludHBpbiAwIChQQ0kgSVJRIDE2KSB0byBsYXBpYyAw IHZlY3RvciA0OQ0KZW0wOiBbRklMVEVSXQ0KZW0wOiBicGYgYXR0YWNoZWQN CmVtMDogRXRoZXJuZXQgYWRkcmVzczogMDA6MDQ6MjM6ZGY6ZmE6NDYNCnZn YXBjaTA6IDxWR0EtY29tcGF0aWJsZSBkaXNwbGF5PiBwb3J0IDB4ZTgwMC0w eGU4ZmYgbWVtIDB4ZmQwMDAwMDAtMHhmZGZmZmZmZiwweGZlYmZmMDAwLTB4 ZmViZmZmZmYgaXJxIDI2IGF0IGRldmljZSA2LjAgb24gcGNpMA0KZnhwMDog PEludGVsIDgyNTUxIFByby8xMDAgRXRoZXJuZXQ+IHBvcnQgMHhlNDAwLTB4 ZTQzZiBtZW0gMHhmZWJmZDAwMC0weGZlYmZkZmZmLDB4ZmViODAwMDAtMHhm ZWI5ZmZmZiBpcnEgMjcgYXQgZGV2aWNlIDcuMCBvbiBwY2kwDQpmeHAwOiBS ZXNlcnZlZCAweDEwMDAgYnl0ZXMgZm9yIHJpZCAweDEwIHR5cGUgMyBhdCAw eGZlYmZkMDAwDQpmeHAwOiB1c2luZyBtZW1vcnkgc3BhY2UgcmVnaXN0ZXIg bWFwcGluZw0KZnhwMDogUENJIElEczogODA4NiAxMjI5IDgwODYgMTA1MCAw MDEwDQpmeHAwOiBEeW5hbWljIFN0YW5kYnkgbW9kZSBpcyBkaXNhYmxlZA0K bWlpYnVzMDogPE1JSSBidXM+IG9uIGZ4cDANCmlucGh5MDogPGk4MjU1NSAx MC8xMDAgbWVkaWEgaW50ZXJmYWNlPiBQSFkgMSBvbiBtaWlidXMwDQppbnBo eTA6ICAxMGJhc2VULCAxMGJhc2VULUZEWCwgMTAwYmFzZVRYLCAxMDBiYXNl VFgtRkRYLCBhdXRvLCBhdXRvLWZsb3cNCmZ4cDA6IGJwZiBhdHRhY2hlZA0K ZnhwMDogRXRoZXJuZXQgYWRkcmVzczogMDA6MzA6NDg6NTI6NTE6YWUNCmlv YXBpYzE6IHJvdXRpbmcgaW50cGluIDExIChQQ0kgSVJRIDI3KSB0byBsYXBp YyAwIHZlY3RvciA1MA0KZnhwMDogW01QU0FGRV0NCmZ4cDA6IFtJVEhSRUFE XQ0KcGNpMDowOjg6MDogYmFkIFZQRCBja3N1bSwgcmVtYWluIDE0DQpiZ2Uw OiA8QnJvYWRjb20gTmV0WHRyZW1lIEdpZ2FiaXQgRXRoZXJuZXQgQ29udHJv bGxlciwgQVNJQyByZXYuIDB4MDAxMDAyPiBtZW0gMHhmZWJlMDAwMC0weGZl YmVmZmZmIGlycSAyOCBhdCBkZXZpY2UgOC4wIG9uIHBjaTANCmJnZTA6IFJl c2VydmVkIDB4MTAwMDAgYnl0ZXMgZm9yIHJpZCAweDEwIHR5cGUgMyBhdCAw eGZlYmUwMDAwDQpiZ2UwOiBDSElQIElEIDB4MDAwMDEwMDI7IEFTSUMgUkVW IDB4MDE7IENISVAgUkVWIDB4MTA7IFBDSQ0KbWlpYnVzMTogPE1JSSBidXM+ IG9uIGJnZTANCmJyZ3BoeTA6IDxCQ001NzAzIDEwLzEwMC8xMDAwYmFzZVRY IFBIWT4gUEhZIDEgb24gbWlpYnVzMQ0KYnJncGh5MDogT1VJIDB4MDAwODE4 LCBtb2RlbCAweDAwMTYsIHJldi4gMg0KYnJncGh5MDogIDEwYmFzZVQsIDEw YmFzZVQtRkRYLCAxMDBiYXNlVFgsIDEwMGJhc2VUWC1GRFgsIDEwMDBiYXNl VCwgMTAwMGJhc2VULW1hc3RlciwgMTAwMGJhc2VULUZEWCwgMTAwMGJhc2VU LUZEWC1tYXN0ZXIsIGF1dG8sIGF1dG8tZmxvdw0KYmdlMDogYnBmIGF0dGFj aGVkDQpiZ2UwOiBFdGhlcm5ldCBhZGRyZXNzOiAwMDozMDo0ODo1Mjo1MTph Zg0KaW9hcGljMTogcm91dGluZyBpbnRwaW4gMTIgKFBDSSBJUlEgMjgpIHRv IGxhcGljIDAgdmVjdG9yIDUxDQpiZ2UwOiBbTVBTQUZFXQ0KYmdlMDogW0lU SFJFQURdDQphdGFwY2kwOiA8U2VydmVyV29ya3MgQ1NCNiBVRE1BMTAwIGNv bnRyb2xsZXI+IHBvcnQgMHgxZjAtMHgxZjcsMHgzZjYsMHgxNzAtMHgxNzcs MHgzNzYsMHhmZmEwLTB4ZmZhZiBhdCBkZXZpY2UgMTUuMSBvbiBwY2kwDQph dGFwY2kwOiBSZXNlcnZlZCAweDEwIGJ5dGVzIGZvciByaWQgMHgyMCB0eXBl IDQgYXQgMHhmZmEwDQphdGEwOiA8QVRBIGNoYW5uZWw+IGF0IGNoYW5uZWwg MCBvbiBhdGFwY2kwDQphdGFwY2kwOiBSZXNlcnZlZCAweDggYnl0ZXMgZm9y IHJpZCAweDEwIHR5cGUgNCBhdCAweDFmMA0KYXRhcGNpMDogUmVzZXJ2ZWQg MHgxIGJ5dGVzIGZvciByaWQgMHgxNCB0eXBlIDQgYXQgMHgzZjYNCmF0YTA6 IHJlc2V0IHRwMSBtYXNrPTAzIG9zdGF0MD01MCBvc3RhdDE9MDANCmF0YTA6 IHN0YXQwPTB4NTAgZXJyPTB4MDEgbHNiPTB4MDAgbXNiPTB4MDANCmF0YTA6 IHN0YXQxPTB4MDAgZXJyPTB4MDEgbHNiPTB4MDAgbXNiPTB4MDANCmF0YTA6 IHJlc2V0IHRwMiBzdGF0MD01MCBzdGF0MT0wMCBkZXZpY2VzPTB4MQ0KaW9h cGljMDogcm91dGluZyBpbnRwaW4gMTQgKElTQSBJUlEgMTQpIHRvIGxhcGlj IDAgdmVjdG9yIDUyDQphdGEwOiBbTVBTQUZFXQ0KYXRhMDogW0lUSFJFQURd DQphdGExOiA8QVRBIGNoYW5uZWw+IGF0IGNoYW5uZWwgMSBvbiBhdGFwY2kw DQphdGFwY2kwOiBSZXNlcnZlZCAweDggYnl0ZXMgZm9yIHJpZCAweDE4IHR5 cGUgNCBhdCAweDE3MA0KYXRhcGNpMDogUmVzZXJ2ZWQgMHgxIGJ5dGVzIGZv ciByaWQgMHgxYyB0eXBlIDQgYXQgMHgzNzYNCmF0YTE6IHJlc2V0IHRwMSBt YXNrPTAxIG9zdGF0MD01MCBvc3RhdDE9ZmYNCmF0YTE6IHN0YXQwPTB4MDAg ZXJyPTB4MDEgbHNiPTB4MTQgbXNiPTB4ZWINCmF0YTE6IHJlc2V0IHRwMiBz dGF0MD0wMCBzdGF0MT0wMCBkZXZpY2VzPTB4MTAwMDANCmlvYXBpYzA6IHJv dXRpbmcgaW50cGluIDE1IChJU0EgSVJRIDE1KSB0byBsYXBpYyAwIHZlY3Rv ciA1Mw0KYXRhMTogW01QU0FGRV0NCmF0YTE6IFtJVEhSRUFEXQ0Kb2hjaTA6 IDxPSENJIChnZW5lcmljKSBVU0IgY29udHJvbGxlcj4gbWVtIDB4ZmViZmUw MDAtMHhmZWJmZWZmZiBpcnEgMTAgYXQgZGV2aWNlIDE1LjIgb24gcGNpMA0K b2hjaTA6IChOZXcgT0hDSSBEZXZpY2VJZD0weDAyMjExMTY2KQ0KaW9hcGlj MDogcm91dGluZyBpbnRwaW4gMTAgKElTQSBJUlEgMTApIHRvIGxhcGljIDAg dmVjdG9yIDU0DQpvaGNpMDogW01QU0FGRV0NCm9oY2kwOiBbSVRIUkVBRF0N CnVzYnVzMDogPE9IQ0kgKGdlbmVyaWMpIFVTQiBjb250cm9sbGVyPiBvbiBv aGNpMA0KdXNidXMwOiBicGYgYXR0YWNoZWQNCm9oY2kwOiB1c2JwZjogQXR0 YWNoZWQNCmlzYWIwOiA8UENJLUlTQSBicmlkZ2U+IGF0IGRldmljZSAxNS4z IG9uIHBjaTANCmlzYTA6IDxJU0EgYnVzPiBvbiBpc2FiMA0KYXRydGMwOiA8 QVQgcmVhbHRpbWUgY2xvY2s+IHBvcnQgMHg3MC0weDcxIGlycSA4IG9uIGFj cGkwDQphdHJ0YzA6IHJlZ2lzdGVyZWQgYXMgYSB0aW1lLW9mLWRheSBjbG9j ayAocmVzb2x1dGlvbiAxMDAwMDAwdXMpDQpwc21jcG5wMDogPFBTLzIgbW91 c2UgcG9ydD4gaXJxIDEyIG9uIGFjcGkwDQphdGtiZGMwOiA8S2V5Ym9hcmQg Y29udHJvbGxlciAoaTgwNDIpPiBwb3J0IDB4NjAsMHg2NCBpcnEgMSBvbiBh Y3BpMA0KYXRrYmQwOiA8QVQgS2V5Ym9hcmQ+IGlycSAxIG9uIGF0a2JkYzAN CmF0a2JkOiB0aGUgY3VycmVudCBrYmQgY29udHJvbGxlciBjb21tYW5kIGJ5 dGUgMDA2NQ0KYXRrYmQ6IGtleWJvYXJkIElEIDB4NDFhYiAoMikNCmtiZDAg YXQgYXRrYmQwDQprYmQwOiBhdGtiZDAsIEFUIDEwMS8xMDIgKDIpLCBjb25m aWc6MHgwLCBmbGFnczoweDNkMDAwMA0KaW9hcGljMDogcm91dGluZyBpbnRw aW4gMSAoSVNBIElSUSAxKSB0byBsYXBpYyAwIHZlY3RvciA1NQ0KYXRrYmQw OiBbR0lBTlQtTE9DS0VEXQ0KYXRrYmQwOiBbSVRIUkVBRF0NCnBzbTA6IGN1 cnJlbnQgY29tbWFuZCBieXRlOjAwNjUNCnBzbTA6IDxQUy8yIE1vdXNlPiBp cnEgMTIgb24gYXRrYmRjMA0KaW9hcGljMDogcm91dGluZyBpbnRwaW4gMTIg KElTQSBJUlEgMTIpIHRvIGxhcGljIDAgdmVjdG9yIDU2DQpwc20wOiBbR0lB TlQtTE9DS0VEXQ0KcHNtMDogW0lUSFJFQURdDQpwc20wOiBtb2RlbCBJbnRl bGxpTW91c2UsIGRldmljZSBJRCAzLTAwLCAzIGJ1dHRvbnMNCnBzbTA6IGNv bmZpZzowMDAwMDAwMCwgZmxhZ3M6MDAwMDAwMDgsIHBhY2tldCBzaXplOjQN CnBzbTA6IHN5bmNtYXNrOjA4LCBzeW5jYml0czowMA0KZmRjMDogPGZsb3Bw eSBkcml2ZSBjb250cm9sbGVyIChGREUpPiBwb3J0IDB4M2YyLTB4M2YzLDB4 M2Y0LTB4M2Y1LDB4M2Y3IGlycSA2IGRycSAyIG9uIGFjcGkwDQpmZGMwOiBp Y190eXBlIDkwIHBhcnRfaWQgNzMNCmlvYXBpYzA6IHJvdXRpbmcgaW50cGlu IDYgKElTQSBJUlEgNikgdG8gbGFwaWMgMCB2ZWN0b3IgNTcNCmZkYzA6IFtG SUxURVJdDQpmZDA6IDwxNDQwLUtCIDMuNSIgZHJpdmU+IG9uIGZkYzAgZHJp dmUgMA0KdWFydDA6IDwxNjU1MCBvciBjb21wYXRpYmxlPiBwb3J0IDB4M2Y4 LTB4M2ZmIGlycSA0IGZsYWdzIDB4MTAgb24gYWNwaTANCmlvYXBpYzA6IHJv dXRpbmcgaW50cGluIDQgKElTQSBJUlEgNCkgdG8gbGFwaWMgMCB2ZWN0b3Ig NTgNCnVhcnQwOiBbRklMVEVSXQ0KdWFydDA6IGZhc3QgaW50ZXJydXB0DQp1 YXJ0MTogPDE2NTUwIG9yIGNvbXBhdGlibGU+IHBvcnQgMHgyZjgtMHgyZmYg aXJxIDMgb24gYWNwaTANCmlvYXBpYzA6IHJvdXRpbmcgaW50cGluIDMgKElT QSBJUlEgMykgdG8gbGFwaWMgMCB2ZWN0b3IgNTkNCnVhcnQxOiBbRklMVEVS XQ0KdWFydDE6IGZhc3QgaW50ZXJydXB0DQpwcGMwOiB1c2luZyBleHRlbmRl ZCBJL08gcG9ydCByYW5nZQ0KcHBjMDogU1BQIEVDUCANCnBwYzA6IDxQYXJh bGxlbCBwb3J0PiBwb3J0IDB4Mzc4LTB4MzdmLDB4Nzc4LTB4NzdmIGlycSA3 IGRycSAzIG9uIGFjcGkwDQpwcGMwOiBHZW5lcmljIGNoaXBzZXQgKEVDUC9Q UzIvTklCQkxFKSBpbiBDT01QQVRJQkxFIG1vZGUNCnBwYzA6IEZJRk8gd2l0 aCAxNi8xNi84IGJ5dGVzIHRocmVzaG9sZA0KaW9hcGljMDogcm91dGluZyBp bnRwaW4gNyAoSVNBIElSUSA3KSB0byBsYXBpYyAwIHZlY3RvciA2MA0KcHBj MDogW01QU0FGRV0NCnBwYzA6IFtJVEhSRUFEXQ0KcHBidXMwOiA8UGFyYWxs ZWwgcG9ydCBidXM+IG9uIHBwYzANCnBsaXAwOiA8UExJUCBuZXR3b3JrIGlu dGVyZmFjZT4gb24gcHBidXMwDQpwbGlwMDogYnBmIGF0dGFjaGVkDQpwbGlw MDogW01QU0FGRV0NCnBsaXAwOiBbSVRIUkVBRF0NCmxwdDA6IDxQcmludGVy PiBvbiBwcGJ1czANCmxwdDA6IFtNUFNBRkVdDQpscHQwOiBbSVRIUkVBRF0N CmxwdDA6IEludGVycnVwdC1kcml2ZW4gcG9ydA0KcHBpMDogPFBhcmFsbGVs IEkvTz4gb24gcHBidXMwDQp1bmtub3duOiBzdGF0dXMgcmVnIHRlc3QgZmFp bGVkIGZmDQp1bmtub3duOiBzdGF0dXMgcmVnIHRlc3QgZmFpbGVkIGZmDQp1 bmtub3duOiBzdGF0dXMgcmVnIHRlc3QgZmFpbGVkIGZmDQp1bmtub3duOiBz dGF0dXMgcmVnIHRlc3QgZmFpbGVkIGZmDQp1bmtub3duOiBzdGF0dXMgcmVn IHRlc3QgZmFpbGVkIGZmDQp1bmtub3duOiBzdGF0dXMgcmVnIHRlc3QgZmFp bGVkIGZmDQphaGNfaXNhX3Byb2JlIDA6IGlvcG9ydCAweGMwMCBhbGxvYyBm YWlsZWQNCmV4X2lzYV9pZGVudGlmeSgpDQpwbnBfaWRlbnRpZnk6IFRyeWlu ZyBSZWFkX1BvcnQgYXQgMjAzDQpwbnBfaWRlbnRpZnk6IFRyeWluZyBSZWFk X1BvcnQgYXQgMjQzDQpwbnBfaWRlbnRpZnk6IFRyeWluZyBSZWFkX1BvcnQg YXQgMjgzDQpwbnBfaWRlbnRpZnk6IFRyeWluZyBSZWFkX1BvcnQgYXQgMmMz DQpwbnBfaWRlbnRpZnk6IFRyeWluZyBSZWFkX1BvcnQgYXQgMzAzDQpwbnBf aWRlbnRpZnk6IFRyeWluZyBSZWFkX1BvcnQgYXQgMzQzDQpwbnBfaWRlbnRp Znk6IFRyeWluZyBSZWFkX1BvcnQgYXQgMzgzDQpwbnBfaWRlbnRpZnk6IFRy eWluZyBSZWFkX1BvcnQgYXQgM2MzDQpQTlAgSWRlbnRpZnkgY29tcGxldGUN CmlzYV9wcm9iZV9jaGlsZHJlbjogZGlzYWJsaW5nIFBuUCBkZXZpY2VzDQpw bXRpbWVyMCBvbiBpc2EwDQphdGE6IGF0YTAgYWxyZWFkeSBleGlzdHM7IHNr aXBwaW5nIGl0DQphdGE6IGF0YTEgYWxyZWFkeSBleGlzdHM7IHNraXBwaW5n IGl0DQphdGtiZGM6IGF0a2JkYzAgYWxyZWFkeSBleGlzdHM7IHNraXBwaW5n IGl0DQphdHJ0YzogYXRydGMwIGFscmVhZHkgZXhpc3RzOyBza2lwcGluZyBp dA0KZmRjOiBmZGMwIGFscmVhZHkgZXhpc3RzOyBza2lwcGluZyBpdA0KcHBj OiBwcGMwIGFscmVhZHkgZXhpc3RzOyBza2lwcGluZyBpdA0Kc2M6IHNjMCBh bHJlYWR5IGV4aXN0czsgc2tpcHBpbmcgaXQNCnVhcnQ6IHVhcnQwIGFscmVh ZHkgZXhpc3RzOyBza2lwcGluZyBpdA0KdWFydDogdWFydDEgYWxyZWFkeSBl eGlzdHM7IHNraXBwaW5nIGl0DQppc2FfcHJvYmVfY2hpbGRyZW46IHByb2Jp bmcgbm9uLVBuUCBkZXZpY2VzDQpvcm0wOiA8SVNBIE9wdGlvbiBST01zPiBh dCBpb21lbSAweGMwMDAwLTB4YzdmZmYsMHhjODAwMC0weGM5N2ZmLDB4Yzk4 MDAtMHhjYWZmZiBwbnBpZCBPUk0wMDAwIG9uIGlzYTANCnNjMDogPFN5c3Rl bSBjb25zb2xlPiBhdCBmbGFncyAweDEwMCBvbiBpc2EwDQpzYzA6IFZHQSA8 MTYgdmlydHVhbCBjb25zb2xlcywgZmxhZ3M9MHgzMDA+DQpzYzA6IGZiMCwg a2JkMSwgdGVybWluYWwgZW11bGF0b3I6IHNjdGVrZW4gKHRla2VuIHRlcm1p bmFsKQ0KdmdhMDogPEdlbmVyaWMgSVNBIFZHQT4gYXQgcG9ydCAweDNjMC0w eDNkZiBpb21lbSAweGEwMDAwLTB4YmZmZmYgb24gaXNhMA0KaXNhX3Byb2Jl X2NoaWxkcmVuOiBwcm9iaW5nIFBuUCBkZXZpY2VzDQpwNHRjYzA6IDxDUFUg RnJlcXVlbmN5IFRoZXJtYWwgQ29udHJvbD4gb24gY3B1MA0KRGV2aWNlIGNv bmZpZ3VyYXRpb24gZmluaXNoZWQuDQpwcm9jZnMgcmVnaXN0ZXJlZA0KbGFw aWM6IERpdmlzb3IgMiwgRnJlcXVlbmN5IDY2NjY5NTg5IEh6DQpUaW1lY291 bnRlciAiVFNDIiBmcmVxdWVuY3kgMjY2Njc4MjU5MiBIeiBxdWFsaXR5IDgw MA0KVGltZWNvdW50ZXJzIHRpY2sgZXZlcnkgMS4wMDAgbXNlYw0Kdmxhbjog aW5pdGlhbGl6ZWQsIHVzaW5nIGhhc2ggdGFibGVzIHdpdGggY2hhaW5pbmcN CmlwZncyICgraXB2NikgaW5pdGlhbGl6ZWQsIGRpdmVydCBlbmFibGVkLCBu YXQgbG9hZGFibGUsIHJ1bGUtYmFzZWQgZm9yd2FyZGluZyBkaXNhYmxlZCwg ZGVmYXVsdCB0byBhY2NlcHQsIGxvZ2dpbmcgZGlzYWJsZWQNCmlwZncwOiBi cGYgYXR0YWNoZWQNCmxvMDogYnBmIGF0dGFjaGVkDQpocHRycjogbm8gY29u dHJvbGxlciBkZXRlY3RlZC4NCmF0YTA6IElkZW50aWZ5aW5nIGRldmljZXM6 IDAwMDAwMDAxDQphdGEwOiBOZXcgZGV2aWNlczogMDAwMDAwMDENCnVzYnVz MDogMTJNYnBzIEZ1bGwgU3BlZWQgVVNCIHYxLjANCmF0YTAtbWFzdGVyOiBw aW89UElPNCB3ZG1hPVdETUEyIHVkbWE9VURNQTEwMCBjYWJsZT04MCB3aXJl DQphZDA6IHNldHRpbmcgVURNQTEwMA0KYWQwOiAxNTI2MjdNQiA8V0RDIFdE MTYwMExCLTU1RURBMCAxNS4wNVIxNT4gYXQgYXRhMC1tYXN0ZXIgVURNQTEw MCANCmFkMDogMzEyNTgxODA4IHNlY3RvcnMgWzMxMDEwMUMvMTZILzYzU10g MTYgc2VjdG9ycy9pbnRlcnJ1cHQgMSBkZXB0aCBxdWV1ZQ0KdWdlbjAuMTog PDB4MTE2Nj4gYXQgdXNidXMwDQp1aHViMDogPDB4MTE2NiBPSENJIHJvb3Qg SFVCLCBjbGFzcyA5LzAsIHJldiAxLjAwLzEuMDAsIGFkZHIgMT4gb24gdXNi dXMwDQphZDA6IEFkYXB0ZWMgY2hlY2sxIGZhaWxlZA0KYWQwOiBMU0kgKHYz KSBjaGVjazEgZmFpbGVkDQphZDA6IExTSSAodjIpIGNoZWNrMSBmYWlsZWQN CmFkMDogRnJlZUJTRCBjaGVjazEgZmFpbGVkDQphdGExOiBJZGVudGlmeWlu ZyBkZXZpY2VzOiAwMDAxMDAwMA0KYXRhMTogTmV3IGRldmljZXM6IDAwMDEw MDAwDQphdGExLW1hc3RlcjogcGlvPVBJTzQgd2RtYT1XRE1BMiB1ZG1hPVVE TUEzMyBjYWJsZT00MCB3aXJlDQphY2QwOiBzZXR0aW5nIFVETUEzMw0KYWNk MDogPE1BVFNISVRBIENSLTE3Ny83VDBEPiBDRFJPTSBkcml2ZSBhdCBhdGEx IGFzIG1hc3Rlcg0KYWNkMDogcmVhZCA0MTI1S0IvcyAoNDEyNUtCL3MpLCAx MjhLQiBidWZmZXIsIFVETUEzMyANCmFjZDA6IFJlYWRzOiBDRFIsIENEUlcs IENEREEgc3RyZWFtLCBwYWNrZXQNCmFjZDA6IFdyaXRlczoNCmFjZDA6IEF1 ZGlvOiBwbGF5LCAyNTYgdm9sdW1lIGxldmVscw0KYWNkMDogTWVjaGFuaXNt OiBlamVjdGFibGUgdHJheSwgdW5sb2NrZWQNCmFjZDA6IE1lZGl1bTogbm8v YmxhbmsgZGlzYw0KQVRBIFBzZXVkb1JBSUQgbG9hZGVkDQp1aHViMDogNCBw b3J0cyB3aXRoIDQgcmVtb3ZhYmxlLCBzZWxmIHBvd2VyZWQNCkdFT006IG5l dyBkaXNrIGFkMA0KR0VPTTogYWQwczI6IGdlb21ldHJ5IGRvZXMgbm90IG1h dGNoIGxhYmVsICgyNTVoLDYzcyAhPSAxNmgsNjNzKS4NClRyeWluZyB0byBt b3VudCByb290IGZyb20gdWZzOi9kZXYvYWQwczJhDQpzdGFydF9pbml0OiB0 cnlpbmcgL3NiaW4vaW5pdA0KZW0wOiBMaW5rIGlzIHVwIDEwMDAgTWJwcyBG dWxsIER1cGxleA0KZW0wOiBMaW5rIGlzIERvd24NCmVtMDogTGluayBpcyB1 cCAxMDAwIE1icHMgRnVsbCBEdXBsZXgNCnNwbGFzaDogaW1hZ2UgZGVjb2Rl ciBmb3VuZDogZGFlbW9uX3NhdmVyDQo= ---1160921188-1351541650-1368327465=:1240-- From owner-freebsd-stable@FreeBSD.ORG Sun May 12 03:23:04 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id F1AF1A5D for ; Sun, 12 May 2013 03:23:04 +0000 (UTC) (envelope-from jdc@koitsu.org) Received: from qmta14.emeryville.ca.mail.comcast.net (qmta14.emeryville.ca.mail.comcast.net [IPv6:2001:558:fe2d:44:76:96:27:212]) by mx1.freebsd.org (Postfix) with ESMTP id B5AAE8CE for ; Sun, 12 May 2013 03:23:04 +0000 (UTC) Received: from omta06.emeryville.ca.mail.comcast.net ([76.96.30.51]) by qmta14.emeryville.ca.mail.comcast.net with comcast id arLC1l00116AWCUAErP3Yu; Sun, 12 May 2013 03:23:03 +0000 Received: from koitsu.strangled.net ([67.180.84.87]) by omta06.emeryville.ca.mail.comcast.net with comcast id arP21l00z1t3BNj8SrP3HW; Sun, 12 May 2013 03:23:03 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id B72C673A33; Sat, 11 May 2013 20:23:02 -0700 (PDT) Date: Sat, 11 May 2013 20:23:02 -0700 From: Jeremy Chadwick To: "Michael L. Squires" Subject: Re: Apparent fxp regression in FreeBSD 8.4-RC3 Message-ID: <20130512032302.GA51272@icarus.home.lan> References: <20130508174721.GD1651@glenbarber.us> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1368328983; bh=Dhe6B1oRIh6ER/B4YYYrDeViNzPvhw8lYdkWa2lH/zw=; h=Received:Received:Received:Date:From:To:Subject:Message-ID: MIME-Version:Content-Type; b=ZTvnZqFcckJ1b/uByZKPrh4/kavLTZmKQZFOVwHBLSiZnaG7++ydjPUeC1s7wip/J YJWyijWzjY6c7hOc4LrvFJuNmL98C3hySjFn95ypVvO0TSm6Dqo4L2lsVeLDMy/bx6 p0+gRC3mKPbWBaiYdxZM3tqQ24ZnhADLlmaNp24XYffMPwLnNAnz6fsI4m5xG913nP T7JLfH3H5U3jR74ZviQfqBvsv1SV/rIWLAYFeG4GdkJ+6RvW/fXJbWoWgJ2hJUKpsF rbMSlzIecjnv3DPUphSJ745sGzo3RBHQMCBh60+jHYmtZ8M/WZ9AXU+fUiYcHFcVV+ dKO28zJPIGlog== Cc: Yong-Hyeon PYUN , Glen Barber , FreeBSD Release Engineering Team , freebsd-stable@FreeBSD.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 12 May 2013 03:23:05 -0000 On Sat, May 11, 2013 at 10:57:44PM -0400, Michael L. Squires wrote: > I upgraded to FreeBSD 8.4-RC3 and noticed a problem with the fxp > driver on an older Supermicro single CPU single core Xeon > motherboard. > > I know that 8.3-Release does not have this issue, but don't know when in > the updates to that release the regression was introduced. > > I use the fxp driver to connect to a Motorola Surfboard cable modem, > and immediately saw the following occur many times: > > May 10 23:00:04 familysquires kernel: fxp0: link state changed to DOWN > May 10 23:00:04 familysquires dhclient: New Subnet Mask (fxp0): > 255.255.240.0 > May 10 23:00:04 familysquires dhclient: New Broadcast Address > (fxp0): 255.255.25 > 5.255 > May 10 23:00:04 familysquires dhclient: New Routers (fxp0): xx.xxx.xxx.1 > May 10 23:00:06 familysquires kernel: fxp0: link state changed to UP > May 10 23:00:22 familysquires dhclient: New IP Address (fxp0): > xx.xxx.xxx.163 > May 10 23:00:22 familysquires kernel: fxp0: link state changed to DOWN > May 10 23:00:22 familysquires dhclient: New Subnet Mask (fxp0): > 255.255.240.0 > May 10 23:00:22 familysquires dhclient: New Broadcast Address > (fxp0): 255.255.255.255 > May 10 23:00:22 familysquires dhclient: New Routers (fxp0): xx.xxx.xxx.1 > May 10 23:00:24 familysquires kernel: fxp0: link state changed to UP > > repeated without end. > > I reinsalled 8.3-Release p8 > > FreeBSD familysquires.net 8.3-RELEASE-p8 FreeBSD 8.3-RELEASE-p8 #46: > Sat May 11 00:05:26 EDT 2013 > > which ended the string up fxp up/down messages. This kernel has now > operated for 24 hours without generating this error. > > I've attached a verbose dmesg from 8.4-RC3 and a standard dmesg from > 8.3-Release p8, and can provide whatever else you need. > > This is not a critical issue for me. The system has an unused bge interface > (replaced by an Intel em0 interface during a previous bout of a problem with > the bge driver). > > Mike Squires > mikes@siralan.org > Copyright (c) 1992-2013 The FreeBSD Project. > Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 > The Regents of the University of California. All rights reserved. > FreeBSD is a registered trademark of The FreeBSD Foundation. > FreeBSD 8.4-PRERELEASE #45: Fri May 10 09:43:40 EDT 2013 > root@familysquires.net:/usr/obj/usr/src/sys/NEWGATE i386 > gcc version 4.2.1 20070831 patched [FreeBSD] > Preloaded elf kernel "/boot/kernel/kernel" at 0xc1060000. > Timecounter "i8254" frequency 1193182 Hz quality 0 > Calibrating TSC clock ... TSC clock: 2666786988 Hz > CPU: Intel(R) Xeon(TM) CPU 2.66GHz (2666.79-MHz 686-class CPU) > Origin = "GenuineIntel" Id = 0xf25 Family = f Model = 2 Stepping = 5 > Features=0xbfebfbff > Features2=0x4400 > > Instruction TLB: 4 KB, 2 MB or 4 MB pages, fully associative, 128 entries > Data TLB: 4 KB or 4 MB pages, fully associative, 64 entries > 1st-level data cache: 8 KB, 4-way set associative, sectored cache, 64 byte line size > Trace cache: 12K-uops, 8-way set associative > 2nd-level cache: 512 KB, 8-way set associative, sectored cache, 64 byte line size > real memory = 1073741824 (1024 MB) > Physical memory chunk(s): > 0x0000000000001000 - 0x000000000009efff, 647168 bytes (158 pages) > 0x0000000000100000 - 0x00000000003fffff, 3145728 bytes (768 pages) > 0x0000000001426000 - 0x000000003eda4fff, 1033367552 bytes (252287 pages) > avail memory = 1032069120 (984 MB) > Table 'FACP' at 0x3fff0030 > Table 'APIC' at 0x3fff00b0 > APIC: Found table at 0x3fff00b0 > MP Configuration Table version 1.4 found at 0xc00f0cb0 > APIC: Using the MADT enumerator. > MADT: Found CPU APIC ID 0 ACPI ID 0: enabled > SMP: Added CPU 0 (AP) > MADT: Found CPU APIC ID 0 ACPI ID 1: disabled > MADT: Found CPU APIC ID 0 ACPI ID 2: disabled > MADT: Found CPU APIC ID 0 ACPI ID 3: disabled > MADT: Found CPU APIC ID 0 ACPI ID 4: disabled > MADT: Found CPU APIC ID 0 ACPI ID 5: disabled > MADT: Found CPU APIC ID 0 ACPI ID 6: disabled > MADT: Found CPU APIC ID 0 ACPI ID 7: disabled > ACPI APIC Table: > APIC: CPU 0 has ACPI ID 0 > bios32: Found BIOS32 Service Directory header at 0xc00fdb70 > bios32: Entry = 0xfdb80 (c00fdb80) Rev = 0 Len = 1 > pcibios: PCI BIOS entry at 0xf0000+0xdba1 > pnpbios: Found PnP BIOS data at 0xc00f4500 > pnpbios: Entry = f0000:33a4 Rev = 1.0 > Other BIOS signatures found: > x86bios: IVT 0x000000-0x0004ff at 0xc0000000 > x86bios: SSEG 0x09e000-0x09efff at 0xc4dc0000 > x86bios: EBDA 0x09f000-0x09ffff at 0xc009f000 > x86bios: ROM 0x0a0000-0x0fefff at 0xc00a0000 > ULE: setup cpu 0 > ACPI: RSDP 0xff900 00014 (v00 AMI ) > ACPI: RSDT 0x3fff0000 0002C (v01 RCC GCHE 00000001 MSFT 01000000) > ACPI: FACP 0x3fff0030 00074 (v01 RCC GCHE 00000001 MSFT 01000000) > ACPI: DSDT 0x3fff0150 049F1 (v01 RCC GCSL 00000100 MSFT 0100000D) > ACPI: FACS 0x3ffff000 00040 > ACPI: APIC 0x3fff00b0 0009A (v01 RCC GCHE 00000001 MSFT 01000000) > MADT: Found IO APIC ID 8, Interrupt 0 at 0xfec00000 > ioapic0: Routing external 8259A's -> intpin 0 > MADT: Found IO APIC ID 9, Interrupt 16 at 0xfec01000 > MADT: Found IO APIC ID 10, Interrupt 32 at 0xfec02000 > MADT: Interrupt override: source 0, irq 2 > ioapic0: Routing IRQ 0 -> intpin 2 > MADT: Forcing active-low polarity and level trigger for SCI > ioapic0: intpin 9 polarity: low > ioapic0: intpin 9 trigger: level > ioapic0 irqs 0-15 on motherboard > ioapic1 irqs 16-31 on motherboard > ioapic2 irqs 32-47 on motherboard > cpu0 BSP: > ID: 0x00000000 VER: 0x00050014 LDR: 0x00000000 DFR: 0xffffffff > lint0: 0x00010700 lint1: 0x00000400 TPR: 0x00000000 SVR: 0x000001ff > timer: 0x000100ef therm: 0x00010000 err: 0x000000f0 pmc: 0x00010400 > wlan: <802.11 Link Layer> > random: > nfslock: pseudo-device > kbd: new array size 4 > kbd1 at kbdmux0 > mem: > Pentium Pro MTRR support enabled > io: > null: > hptrr: RocketRAID 17xx/2xxx SATA controller driver v1.2 > acpi0: on motherboard > ACPI Warning: Type override - [DEB_] had invalid type (Integer) for Scope operator, changed to type ANY > (20101013/dswload-808) > ACPI Warning: Type override - [MLIB] had invalid type (Integer) for Scope operator, changed to type ANY > (20101013/dswload-808) > ACPI Warning: Type override - [IO__] had invalid type (Integer) for Scope operator, changed to type ANY > (20101013/dswload-808) > ACPI Warning: Type override - [DATA] had invalid type (String) for Scope operator, changed to type ANY > (20101013/dswload-808) > ACPI Warning: Type override - [SIO_] had invalid type (String) for Scope operator, changed to type ANY > (20101013/dswload-808) > ACPI Warning: Type override - [SB__] had invalid type (String) for Scope operator, changed to type ANY > (20101013/dswload-808) > ACPI Warning: Type override - [PM__] had invalid type (String) for Scope operator, changed to type ANY > (20101013/dswload-808) > ACPI Warning: Type override - [ICNT] had invalid type (String) for Scope operator, changed to type ANY > (20101013/dswload-808) > ACPI Warning: Type override - [ACPI] had invalid type (String) for Scope operator, changed to type ANY > (20101013/dswload-808) > ACPI Warning: Type override - [IORG] had invalid type (String) for Scope operator, changed to type ANY > (20101013/dswload-808) > ACPI Warning: Type override - [SB__] had invalid type (String) for Scope operator, changed to type ANY > (20101013/dswload-808) > ACPI Warning: Type override - [PM__] had invalid type (String) for Scope operator, changed to type ANY > (20101013/dswload-808) > ACPI Warning: Type override - [SIO_] had invalid type (String) for Scope operator, changed to type ANY > (20101013/dswload-808) > ACPI Warning: Type override - [PM__] had invalid type (String) for Scope operator, changed to type ANY > (20101013/dswload-808) > ACPI Warning: Type override - [BIOS] had invalid type (Integer) for Scope operator, changed to type ANY > (20101013/dswload-808) > ACPI Warning: Type override - [CMOS] had invalid type (Integer) for Scope operator, changed to type ANY > (20101013/dswload-808) > ACPI Warning: Type override - [KBC_] had invalid type (Integer) for Scope operator, changed to type ANY > (20101013/dswload-808) > ACPI Warning: Type override - [OEM_] had invalid type (Integer) for Scope operator, changed to type ANY > (20101013/dswload-808) > ioapic0: routing intpin 9 (ISA IRQ 9) to lapic 0 vector 48 > acpi0: [MPSAFE] > acpi0: [ITHREAD] > acpi0: Power Button (fixed) > acpi0: wakeup code va 0xc4dbd000 pa 0x1000 > pci_open(1): mode 1 addr port (0x0cf8) is 0x800078ac > pci_open(1a): mode1res=0x80000000 (0x80000000) > pci_cfgcheck: device 0 [class=060000] [hdr=80] is there (id=00171166) > pcibios: BIOS version 2.10 > unknown: I/O range not supported > acpi0: reservation of 0, a0000 (3) failed > acpi0: reservation of 100000, 3ff00000 (3) failed > ACPI timer: 1/2 0/3 1/2 1/2 0/3 1/2 0/3 1/2 0/3 0/4 -> 5 > Timecounter "ACPI-safe" frequency 3579545 Hz quality 850 > acpi_timer0: <32-bit timer at 3.579545MHz> port 0x508-0x50b on acpi0 > cpu0: on acpi0 > cpu0: switching to generic Cx mode > ACPI: Processor \\_PR_.CPU1 (ACPI ID 1) ignored > ACPI: Processor \\_PR_.CPU2 (ACPI ID 2) ignored > ACPI: Processor \\_PR_.CPU3 (ACPI ID 3) ignored > ACPI: Processor \\_PR_.CPU4 (ACPI ID 4) ignored > ACPI: Processor \\_PR_.CPU5 (ACPI ID 5) ignored > ACPI: Processor \\_PR_.CPU6 (ACPI ID 6) ignored > ACPI: Processor \\_PR_.CPU7 (ACPI ID 7) ignored > pci_link0: Index IRQ Rtd Ref IRQs > Initial Probe 0 255 N 0 3 4 5 7 9 11 12 14 15 > Validation 0 255 N 0 3 4 5 7 9 11 12 14 15 > After Disable 0 255 N 0 3 4 5 7 9 11 12 14 15 > pci_link1: Index IRQ Rtd Ref IRQs > Initial Probe 0 255 N 0 3 4 5 7 9 11 12 14 15 > Validation 0 255 N 0 3 4 5 7 9 11 12 14 15 > After Disable 0 255 N 0 3 4 5 7 9 11 12 14 15 > pci_link2: Index IRQ Rtd Ref IRQs > Initial Probe 0 255 N 0 3 4 5 7 9 11 12 14 15 > Validation 0 255 N 0 3 4 5 7 9 11 12 14 15 > After Disable 0 255 N 0 3 4 5 7 9 11 12 14 15 > pci_link3: Index IRQ Rtd Ref IRQs > Initial Probe 0 255 N 0 3 4 5 7 9 11 12 14 15 > Validation 0 255 N 0 3 4 5 7 9 11 12 14 15 > After Disable 0 255 N 0 3 4 5 7 9 11 12 14 15 > pci_link4: Index IRQ Rtd Ref IRQs > Initial Probe 0 255 N 0 3 4 5 7 9 11 12 14 15 > Validation 0 255 N 0 3 4 5 7 9 11 12 14 15 > After Disable 0 255 N 0 3 4 5 7 9 11 12 14 15 > pci_link5: Index IRQ Rtd Ref IRQs > Initial Probe 0 255 N 0 3 4 5 7 9 11 12 14 15 > Validation 0 255 N 0 3 4 5 7 9 11 12 14 15 > After Disable 0 255 N 0 3 4 5 7 9 11 12 14 15 > pci_link6: Index IRQ Rtd Ref IRQs > Initial Probe 0 255 N 0 3 4 5 7 9 11 12 14 15 > Validation 0 255 N 0 3 4 5 7 9 11 12 14 15 > After Disable 0 255 N 0 3 4 5 7 9 11 12 14 15 > pci_link7: Index IRQ Rtd Ref IRQs > Initial Probe 0 255 N 0 3 4 5 7 9 11 12 14 15 > Validation 0 255 N 0 3 4 5 7 9 11 12 14 15 > After Disable 0 255 N 0 3 4 5 7 9 11 12 14 15 > pci_link8: Index IRQ Rtd Ref IRQs > Initial Probe 0 255 N 0 3 4 5 7 9 11 12 14 15 > Validation 0 255 N 0 3 4 5 7 9 11 12 14 15 > After Disable 0 255 N 0 3 4 5 7 9 11 12 14 15 > pci_link9: Index IRQ Rtd Ref IRQs > Initial Probe 0 255 N 0 3 4 5 7 9 11 12 14 15 > Validation 0 255 N 0 3 4 5 7 9 11 12 14 15 > After Disable 0 255 N 0 3 4 5 7 9 11 12 14 15 > pci_link10: Index IRQ Rtd Ref IRQs > Initial Probe 0 255 N 0 3 4 5 7 9 11 12 14 15 > Validation 0 255 N 0 3 4 5 7 9 11 12 14 15 > After Disable 0 255 N 0 3 4 5 7 9 11 12 14 15 > pci_link11: Index IRQ Rtd Ref IRQs > Initial Probe 0 255 N 0 3 4 5 7 9 11 12 14 15 > Validation 0 255 N 0 3 4 5 7 9 11 12 14 15 > After Disable 0 255 N 0 3 4 5 7 9 11 12 14 15 > pci_link12: Index IRQ Rtd Ref IRQs > Initial Probe 0 255 N 0 3 4 5 7 9 11 12 14 15 > Validation 0 255 N 0 3 4 5 7 9 11 12 14 15 > After Disable 0 255 N 0 3 4 5 7 9 11 12 14 15 > pci_link13: Index IRQ Rtd Ref IRQs > Initial Probe 0 255 N 0 3 4 5 7 9 11 12 14 15 > Validation 0 255 N 0 3 4 5 7 9 11 12 14 15 > After Disable 0 255 N 0 3 4 5 7 9 11 12 14 15 > pci_link14: Index IRQ Rtd Ref IRQs > Initial Probe 0 255 N 0 3 4 5 7 9 11 12 14 15 > Validation 0 255 N 0 3 4 5 7 9 11 12 14 15 > After Disable 0 255 N 0 3 4 5 7 9 11 12 14 15 > pci_link15: Index IRQ Rtd Ref IRQs > Initial Probe 0 255 N 0 3 4 5 7 9 11 12 14 15 > Validation 0 255 N 0 3 4 5 7 9 11 12 14 15 > After Disable 0 255 N 0 3 4 5 7 9 11 12 14 15 > pci_link16: Index IRQ Rtd Ref IRQs > Initial Probe 0 255 N 0 3 4 5 7 9 11 12 14 15 > Validation 0 255 N 0 3 4 5 7 9 11 12 14 15 > After Disable 0 255 N 0 3 4 5 7 9 11 12 14 15 > pci_link17: Index IRQ Rtd Ref IRQs > Initial Probe 0 255 N 0 3 4 5 7 9 11 12 14 15 > Validation 0 255 N 0 3 4 5 7 9 11 12 14 15 > After Disable 0 255 N 0 3 4 5 7 9 11 12 14 15 > pci_link18: Index IRQ Rtd Ref IRQs > Initial Probe 0 255 N 0 3 4 5 7 9 11 12 14 15 > Validation 0 255 N 0 3 4 5 7 9 11 12 14 15 > After Disable 0 255 N 0 3 4 5 7 9 11 12 14 15 > pci_link19: Index IRQ Rtd Ref IRQs > Initial Probe 0 255 N 0 3 4 5 7 9 11 12 14 15 > Validation 0 255 N 0 3 4 5 7 9 11 12 14 15 > After Disable 0 255 N 0 3 4 5 7 9 11 12 14 15 > pci_link20: Index IRQ Rtd Ref IRQs > Initial Probe 0 255 N 0 3 4 5 7 9 11 12 14 15 > Validation 0 255 N 0 3 4 5 7 9 11 12 14 15 > After Disable 0 255 N 0 3 4 5 7 9 11 12 14 15 > pci_link21: Index IRQ Rtd Ref IRQs > Initial Probe 0 255 N 0 3 4 5 7 9 11 12 14 15 > Validation 0 255 N 0 3 4 5 7 9 11 12 14 15 > After Disable 0 255 N 0 3 4 5 7 9 11 12 14 15 > pci_link22: Index IRQ Rtd Ref IRQs > Initial Probe 0 255 N 0 3 4 5 7 9 11 12 14 15 > Validation 0 255 N 0 3 4 5 7 9 11 12 14 15 > After Disable 0 255 N 0 3 4 5 7 9 11 12 14 15 > pci_link23: Index IRQ Rtd Ref IRQs > Initial Probe 0 255 N 0 3 4 5 7 9 11 12 14 15 > Validation 0 255 N 0 3 4 5 7 9 11 12 14 15 > After Disable 0 255 N 0 3 4 5 7 9 11 12 14 15 > pci_link24: Index IRQ Rtd Ref IRQs > Initial Probe 0 255 N 0 3 4 5 7 9 11 12 14 15 > Validation 0 255 N 0 3 4 5 7 9 11 12 14 15 > After Disable 0 255 N 0 3 4 5 7 9 11 12 14 15 > pci_link25: Index IRQ Rtd Ref IRQs > Initial Probe 0 255 N 0 3 4 5 7 9 11 12 14 15 > Validation 0 255 N 0 3 4 5 7 9 11 12 14 15 > After Disable 0 255 N 0 3 4 5 7 9 11 12 14 15 > pci_link26: Index IRQ Rtd Ref IRQs > Initial Probe 0 255 N 0 3 4 5 7 9 11 12 14 15 > Validation 0 255 N 0 3 4 5 7 9 11 12 14 15 > After Disable 0 255 N 0 3 4 5 7 9 11 12 14 15 > pci_link27: Index IRQ Rtd Ref IRQs > Initial Probe 0 255 N 0 3 4 5 7 9 11 12 14 15 > Validation 0 255 N 0 3 4 5 7 9 11 12 14 15 > After Disable 0 255 N 0 3 4 5 7 9 11 12 14 15 > pci_link28: Index IRQ Rtd Ref IRQs > Initial Probe 0 255 N 0 3 4 5 7 9 11 12 14 15 > Validation 0 255 N 0 3 4 5 7 9 11 12 14 15 > After Disable 0 255 N 0 3 4 5 7 9 11 12 14 15 > pci_link29: Index IRQ Rtd Ref IRQs > Initial Probe 0 255 N 0 3 4 5 7 9 11 12 14 15 > Validation 0 255 N 0 3 4 5 7 9 11 12 14 15 > After Disable 0 255 N 0 3 4 5 7 9 11 12 14 15 > pci_link30: Index IRQ Rtd Ref IRQs > Initial Probe 0 255 N 0 3 4 5 7 9 11 12 14 15 > Validation 0 255 N 0 3 4 5 7 9 11 12 14 15 > After Disable 0 255 N 0 3 4 5 7 9 11 12 14 15 > pci_link31: Index IRQ Rtd Ref IRQs > Initial Probe 0 255 N 0 3 4 5 7 9 11 12 14 15 > Validation 0 255 N 0 3 4 5 7 9 11 12 14 15 > After Disable 0 255 N 0 3 4 5 7 9 11 12 14 15 > pci_link32: Index IRQ Rtd Ref IRQs > Initial Probe 0 10 N 0 10 > Validation 0 10 N 0 10 > After Disable 0 255 N 0 10 > pci_link33: Index IRQ Rtd Ref IRQs > Initial Probe 0 255 N 0 11 > Validation 0 255 N 0 11 > After Disable 0 255 N 0 11 > acpi_button0: on acpi0 > pcib0: port 0xcf8-0xcff on acpi0 > ACPI: Found matching pin for 0.15.INTA at func 2: 10 > pci0: on pcib0 > pci0: domain=0, physical bus=0 > found-> vendor=0x1166, dev=0x0017, revid=0x32 > domain=0, bus=0, slot=0, func=0 > class=06-00-00, hdrtype=0x00, mfdev=1 > cmdreg=0x0000, statreg=0x0000, cachelnsz=16 (dwords) > lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) > found-> vendor=0x1166, dev=0x0017, revid=0x00 > domain=0, bus=0, slot=0, func=1 > class=06-00-00, hdrtype=0x00, mfdev=1 > cmdreg=0x0000, statreg=0x0000, cachelnsz=16 (dwords) > lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) > found-> vendor=0x8086, dev=0x1026, revid=0x04 > domain=0, bus=0, slot=1, func=0 > class=02-00-00, hdrtype=0x00, mfdev=0 > cmdreg=0x0117, statreg=0x0230, cachelnsz=16 (dwords) > lattimer=0x40 (1920 ns), mingnt=0xff (63750 ns), maxlat=0x00 (0 ns) > intpin=a, irq=5 > powerspec 2 supports D0 D3 current D0 > map[10]: type Memory, range 64, base 0xfeb60000, size 17, enabled > map[18]: type Memory, range 64, base 0xfeb00000, size 18, enabled > map[20]: type I/O Port, range 32, base 0xe000, size 6, enabled > pcib0: matched entry for 0.1.INTA > pcib0: slot 1 INTA hardwired to IRQ 16 > found-> vendor=0x1002, dev=0x4752, revid=0x27 > domain=0, bus=0, slot=6, func=0 > class=03-00-00, hdrtype=0x00, mfdev=0 > cmdreg=0x0087, statreg=0x0290, cachelnsz=16 (dwords) > lattimer=0x40 (1920 ns), mingnt=0x08 (2000 ns), maxlat=0x00 (0 ns) > intpin=a, irq=10 > powerspec 2 supports D0 D1 D2 D3 current D0 > map[10]: type Memory, range 32, base 0xfd000000, size 24, enabled > map[14]: type I/O Port, range 32, base 0xe800, size 8, enabled > map[18]: type Memory, range 32, base 0xfebff000, size 12, enabled > pcib0: matched entry for 0.6.INTA > pcib0: slot 6 INTA hardwired to IRQ 26 > found-> vendor=0x8086, dev=0x1229, revid=0x10 > domain=0, bus=0, slot=7, func=0 > class=02-00-00, hdrtype=0x00, mfdev=0 > cmdreg=0x0117, statreg=0x0290, cachelnsz=16 (dwords) > lattimer=0x40 (1920 ns), mingnt=0x08 (2000 ns), maxlat=0x38 (14000 ns) > intpin=a, irq=9 > powerspec 2 supports D0 D1 D2 D3 current D0 > map[10]: type Memory, range 32, base 0xfebfd000, size 12, enabled > map[14]: type I/O Port, range 32, base 0xe400, size 6, enabled > map[18]: type Memory, range 32, base 0xfeb80000, size 17, enabled > pcib0: matched entry for 0.7.INTA > pcib0: slot 7 INTA hardwired to IRQ 27 > found-> vendor=0x14e4, dev=0x16a6, revid=0x02 > domain=0, bus=0, slot=8, func=0 > class=02-00-00, hdrtype=0x00, mfdev=0 > cmdreg=0x0116, statreg=0x02b0, cachelnsz=16 (dwords) > lattimer=0x40 (1920 ns), mingnt=0x40 (16000 ns), maxlat=0x00 (0 ns) > intpin=a, irq=11 > powerspec 2 supports D0 D3 current D0 > MSI supports 8 messages, 64 bit > map[10]: type Memory, range 64, base 0xfebe0000, size 16, enabled > pcib0: matched entry for 0.8.INTA > pcib0: slot 8 INTA hardwired to IRQ 28 > found-> vendor=0x1166, dev=0x0203, revid=0xa0 > domain=0, bus=0, slot=15, func=0 > class=06-00-00, hdrtype=0x00, mfdev=1 > cmdreg=0x0107, statreg=0x2200, cachelnsz=0 (dwords) > lattimer=0x40 (1920 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) > found-> vendor=0x1166, dev=0x0213, revid=0xa0 > domain=0, bus=0, slot=15, func=1 > class=01-01-8a, hdrtype=0x00, mfdev=1 > cmdreg=0x0015, statreg=0x0200, cachelnsz=8 (dwords) > lattimer=0x40 (1920 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) > map[20]: type I/O Port, range 32, base 0xffa0, size 4, enabled > found-> vendor=0x1166, dev=0x0221, revid=0x05 > domain=0, bus=0, slot=15, func=2 > class=0c-03-10, hdrtype=0x00, mfdev=1 > cmdreg=0x0117, statreg=0x0280, cachelnsz=0 (dwords) > lattimer=0x40 (1920 ns), mingnt=0x00 (0 ns), maxlat=0x50 (20000 ns) > intpin=a, irq=10 > map[10]: type Memory, range 32, base 0xfebfe000, size 12, enabled > pcib0: matched entry for 0.15.INTA (src \\_SB_.LNUS:0) > ioapic0: Changing trigger for pin 10 to level > ioapic0: Changing polarity for pin 10 to low > pcib0: slot 15 INTA routed to irq 10 via \\_SB_.LNUS > unknown: Reserved 0x1000 bytes for rid 0x10 type 3 at 0xfebfe000 > ohci early: SMM active, request owner change > found-> vendor=0x1166, dev=0x0227, revid=0x00 > domain=0, bus=0, slot=15, func=3 > class=06-01-00, hdrtype=0x00, mfdev=1 > cmdreg=0x0107, statreg=0x0200, cachelnsz=0 (dwords) > lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) > em0: port 0xe000-0xe03f mem 0xfeb60000-0xfeb7ffff,0xfeb00000-0xfeb3ffff irq 16 at device 1.0 on pci0 > em0: Reserved 0x20000 bytes for rid 0x10 type 3 at 0xfeb60000 > em0: Reserved 0x40 bytes for rid 0x20 type 4 at 0xe000 > ioapic1: routing intpin 0 (PCI IRQ 16) to lapic 0 vector 49 > em0: [FILTER] > em0: bpf attached > em0: Ethernet address: 00:04:23:df:fa:46 > vgapci0: port 0xe800-0xe8ff mem 0xfd000000-0xfdffffff,0xfebff000-0xfebfffff irq 26 at device 6.0 on pci0 > fxp0: port 0xe400-0xe43f mem 0xfebfd000-0xfebfdfff,0xfeb80000-0xfeb9ffff irq 27 at device 7.0 on pci0 > fxp0: Reserved 0x1000 bytes for rid 0x10 type 3 at 0xfebfd000 > fxp0: using memory space register mapping > fxp0: PCI IDs: 8086 1229 8086 1050 0010 > fxp0: Dynamic Standby mode is disabled > miibus0: on fxp0 > inphy0: PHY 1 on miibus0 > inphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto, auto-flow > fxp0: bpf attached > fxp0: Ethernet address: 00:30:48:52:51:ae > ioapic1: routing intpin 11 (PCI IRQ 27) to lapic 0 vector 50 > fxp0: [MPSAFE] > fxp0: [ITHREAD] > pci0:0:8:0: bad VPD cksum, remain 14 > bge0: mem 0xfebe0000-0xfebeffff irq 28 at device 8.0 on pci0 > bge0: Reserved 0x10000 bytes for rid 0x10 type 3 at 0xfebe0000 > bge0: CHIP ID 0x00001002; ASIC REV 0x01; CHIP REV 0x10; PCI on PCI-X 33 MHz; 32bit > miibus1: on bge0 > brgphy0: PHY 1 on miibus1 > brgphy0: OUI 0x000818, model 0x0016, rev. 2 > brgphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-master, 1000baseT-FDX, 1000baseT-FDX-master, auto, auto-flow > bge0: bpf attached > bge0: Ethernet address: 00:30:48:52:51:af > ioapic1: routing intpin 12 (PCI IRQ 28) to lapic 0 vector 51 > bge0: [MPSAFE] > bge0: [ITHREAD] > atapci0: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xffa0-0xffaf at device 15.1 on pci0 > atapci0: Reserved 0x10 bytes for rid 0x20 type 4 at 0xffa0 > ata0: at channel 0 on atapci0 > atapci0: Reserved 0x8 bytes for rid 0x10 type 4 at 0x1f0 > atapci0: Reserved 0x1 bytes for rid 0x14 type 4 at 0x3f6 > ata0: reset tp1 mask=03 ostat0=50 ostat1=00 > ata0: stat0=0x50 err=0x01 lsb=0x00 msb=0x00 > ata0: stat1=0x00 err=0x01 lsb=0x00 msb=0x00 > ata0: reset tp2 stat0=50 stat1=00 devices=0x1 > ioapic0: routing intpin 14 (ISA IRQ 14) to lapic 0 vector 52 > ata0: [MPSAFE] > ata0: [ITHREAD] > ata1: at channel 1 on atapci0 > atapci0: Reserved 0x8 bytes for rid 0x18 type 4 at 0x170 > atapci0: Reserved 0x1 bytes for rid 0x1c type 4 at 0x376 > ata1: reset tp1 mask=01 ostat0=50 ostat1=ff > ata1: stat0=0x00 err=0x01 lsb=0x14 msb=0xeb > ata1: reset tp2 stat0=00 stat1=00 devices=0x10000 > ioapic0: routing intpin 15 (ISA IRQ 15) to lapic 0 vector 53 > ata1: [MPSAFE] > ata1: [ITHREAD] > ohci0: mem 0xfebfe000-0xfebfefff irq 10 at device 15.2 on pci0 > ohci0: (New OHCI DeviceId=0x02211166) > ioapic0: routing intpin 10 (ISA IRQ 10) to lapic 0 vector 54 > ohci0: [MPSAFE] > ohci0: [ITHREAD] > usbus0 on ohci0 > usbus0: bpf attached > ohci0: usbpf: Attached > isab0: at device 15.3 on pci0 > isa0: on isab0 > atrtc0: port 0x70-0x71 irq 8 on acpi0 > atrtc0: registered as a time-of-day clock (resolution 1000000us) > psmcpnp0: irq 12 on acpi0 > atkbdc0: port 0x60,0x64 irq 1 on acpi0 > atkbd0: irq 1 on atkbdc0 > atkbd: the current kbd controller command byte 0065 > atkbd: keyboard ID 0x41ab (2) > kbd0 at atkbd0 > kbd0: atkbd0, AT 101/102 (2), config:0x0, flags:0x3d0000 > ioapic0: routing intpin 1 (ISA IRQ 1) to lapic 0 vector 55 > atkbd0: [GIANT-LOCKED] > atkbd0: [ITHREAD] > psm0: current command byte:0065 > psm0: irq 12 on atkbdc0 > ioapic0: routing intpin 12 (ISA IRQ 12) to lapic 0 vector 56 > psm0: [GIANT-LOCKED] > psm0: [ITHREAD] > psm0: model IntelliMouse, device ID 3-00, 3 buttons > psm0: config:00000000, flags:00000008, packet size:4 > psm0: syncmask:08, syncbits:00 > fdc0: port 0x3f2-0x3f3,0x3f4-0x3f5,0x3f7 irq 6 drq 2 on acpi0 > fdc0: ic_type 90 part_id 73 > ioapic0: routing intpin 6 (ISA IRQ 6) to lapic 0 vector 57 > fdc0: [FILTER] > fd0: <1440-KB 3.5" drive> on fdc0 drive 0 > uart0: <16550 or compatible> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 > ioapic0: routing intpin 4 (ISA IRQ 4) to lapic 0 vector 58 > uart0: [FILTER] > uart0: fast interrupt > uart1: <16550 or compatible> port 0x2f8-0x2ff irq 3 on acpi0 > ioapic0: routing intpin 3 (ISA IRQ 3) to lapic 0 vector 59 > uart1: [FILTER] > uart1: fast interrupt > ppc0: using extended I/O port range > ppc0: SPP ECP > ppc0: port 0x378-0x37f,0x778-0x77f irq 7 drq 3 on acpi0 > ppc0: Generic chipset (ECP/PS2/NIBBLE) in COMPATIBLE mode > ppc0: FIFO with 16/16/8 bytes threshold > ioapic0: routing intpin 7 (ISA IRQ 7) to lapic 0 vector 60 > ppc0: [MPSAFE] > ppc0: [ITHREAD] > ppbus0: on ppc0 > plip0: on ppbus0 > plip0: bpf attached > plip0: [MPSAFE] > plip0: [ITHREAD] > lpt0: on ppbus0 > lpt0: [MPSAFE] > lpt0: [ITHREAD] > lpt0: Interrupt-driven port > ppi0: on ppbus0 > ex_isa_identify() > pnp_identify: Trying Read_Port at 203 > pnp_identify: Trying Read_Port at 243 > pnp_identify: Trying Read_Port at 283 > pnp_identify: Trying Read_Port at 2c3 > pnp_identify: Trying Read_Port at 303 > pnp_identify: Trying Read_Port at 343 > pnp_identify: Trying Read_Port at 383 > pnp_identify: Trying Read_Port at 3c3 > PNP Identify complete > ahc_isa_probe 0: ioport 0xc00 alloc failed > ahc_isa_probe 1: ioport 0x1c00 alloc failed > ahc_isa_probe 2: ioport 0x2c00 alloc failed > ahc_isa_probe 3: ioport 0x3c00 alloc failed > ahc_isa_probe 4: ioport 0x4c00 alloc failed > ahc_isa_probe 5: ioport 0x5c00 alloc failed > ahc_isa_probe 6: ioport 0x6c00 alloc failed > ahc_isa_probe 7: ioport 0x7c00 alloc failed > ahc_isa_probe 8: ioport 0x8c00 alloc failed > ahc_isa_probe 9: ioport 0x9c00 alloc failed > ahc_isa_probe 10: ioport 0xac00 alloc failed > ahc_isa_probe 11: ioport 0xbc00 alloc failed > ahc_isa_probe 12: ioport 0xcc00 alloc failed > ahc_isa_probe 13: ioport 0xdc00 alloc failed > ahc_isa_probe 14: ioport 0xec00 alloc failed > isa_probe_children: disabling PnP devices > pmtimer0 on isa0 > ata: ata0 already exists; skipping it > ata: ata1 already exists; skipping it > atkbdc: atkbdc0 already exists; skipping it > atrtc: atrtc0 already exists; skipping it > fdc: fdc0 already exists; skipping it > ppc: ppc0 already exists; skipping it > sc: sc0 already exists; skipping it > uart: uart0 already exists; skipping it > uart: uart1 already exists; skipping it > isa_probe_children: probing non-PnP devices > orm0: at iomem 0xc0000-0xc7fff,0xc8000-0xc97ff,0xc9800-0xcafff pnpid ORM0000 on isa0 > sc0: at flags 0x100 on isa0 > sc0: VGA <16 virtual consoles, flags=0x300> > sc0: fb0, kbd1, terminal emulator: scteken (teken terminal) > vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 > wbwd0 failed to probe on isa0 > isa_probe_children: probing PnP devices > p4tcc0: on cpu0 > Device configuration finished. > procfs registered > lapic: Divisor 2, Frequency 66669679 Hz > Timecounter "TSC" frequency 2666786988 Hz quality 800 > Timecounters tick every 1.000 msec > vlan: initialized, using hash tables with chaining > ipfw2 (+ipv6) initialized, divert enabled, nat loadable, rule-based forwarding disabled, default to accept, logging disabled > ipfw0: bpf attached > lo0: bpf attached > hptrr: no controller detected. > ata0: Identifying devices: 00000001 > ata0: New devices: 00000001 > usbus0: 12Mbps Full Speed USB v1.0 > ata0-master: pio=PIO4 wdma=WDMA2 udma=UDMA100 cable=80 wire > ad0: setting UDMA100 > ad0: 152627MB at ata0-master UDMA100 > ad0: 312581808 sectors [310101C/16H/63S] 16 sectors/interrupt 1 depth queue > ugen0.1: <0x1166> at usbus0 > uhub0: <0x1166 OHCI root HUB, class 9/0, rev 1.00/1.00, addr 1> on usbus0 > ad0: Adaptec check1 failed > ad0: LSI (v3) check1 failed > ad0: LSI (v2) check1 failed > ad0: FreeBSD check1 failed > ata1: Identifying devices: 00010000 > ata1: New devices: 00010000 > ata1-master: pio=PIO4 wdma=WDMA2 udma=UDMA33 cable=40 wire > acd0: setting UDMA33 > acd0: CDROM drive at ata1 as master > acd0: read 4125KB/s (4125KB/s), 128KB buffer, UDMA33 > acd0: Reads: CDR, CDRW, CDDA stream, packet > acd0: Writes: > acd0: Audio: play, 256 volume levels > acd0: Mechanism: ejectable tray, unlocked > acd0: Medium: no/blank disc > ATA PseudoRAID loaded > uhub0: 4 ports with 4 removable, self powered > GEOM: new disk ad0 > GEOM: ad0s2: geometry does not match label (255h,63s != 16h,63s). > Trying to mount root from ufs:/dev/ad0s2a > start_init: trying /sbin/init > em0: Link is up 1000 Mbps Full Duplex > em0: Link is Down > em0: Link is up 1000 Mbps Full Duplex > fxp0: link state changed to UP > fxp0: link state changed to DOWN > fxp0: link state changed to UP > fxp0: link state changed to DOWN > fxp0: link state changed to UP > fxp0: link state changed to DOWN > fxp0: link state changed to UP > fxp0: link state changed to DOWN > fxp0: link state changed to UP > fxp0: link state changed to DOWN > fxp0: link state changed to UP > fxp0: link state changed to DOWN > fxp0: link state changed to UP > fxp0: link state changed to DOWN > fxp0: link state changed to UP > fxp0: link state changed to DOWN > fxp0: link state changed to UP > fxp0: link state changed to DOWN > fxp0: link state changed to UP > fxp0: link state changed to DOWN > fxp0: link state changed to UP > fxp0: link state changed to DOWN > fxp0: link state changed to UP > fxp0: link state changed to DOWN > fxp0: link state changed to UP > fxp0: link state changed to DOWN > fxp0: link state changed to UP > fxp0: link state changed to DOWN > fxp0: link state changed to UP > fxp0: link state changed to DOWN > fxp0: link state changed to UP > splash: image decoder found: daemon_saver > fxp0: link state changed to DOWN > fxp0: link state changed to UP > fxp0: link state changed to DOWN > fxp0: link state changed to UP > fxp0: link state changed to DOWN > fxp0: link state changed to UP > Copyright (c) 1992-2012 The FreeBSD Project. > Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 > The Regents of the University of California. All rights reserved. > FreeBSD is a registered trademark of The FreeBSD Foundation. > FreeBSD 8.3-RELEASE-p8 #46: Sat May 11 00:05:26 EDT 2013 > root@familysquires.net:/usr/obj/usr/src/sys/NEWGATE i386 > Preloaded elf kernel "/boot/kernel/kernel" at 0xc102d000. > Timecounter "i8254" frequency 1193182 Hz quality 0 > Calibrating TSC clock ... TSC clock: 2666782592 Hz > CPU: Intel(R) Xeon(TM) CPU 2.66GHz (2666.78-MHz 686-class CPU) > Origin = "GenuineIntel" Id = 0xf25 Family = f Model = 2 Stepping = 5 > Features=0xbfebfbff > Features2=0x4400 > > Instruction TLB: 4 KB, 2 MB or 4 MB pages, fully associative, 128 entries > Data TLB: 4 KB or 4 MB pages, fully associative, 64 entries > 1st-level data cache: 8 KB, 4-way set associative, sectored cache, 64 byte line size > Trace cache: 12K-uops, 8-way set associative > 2nd-level cache: 512 KB, 8-way set associative, sectored cache, 64 byte line size > real memory = 1073741824 (1024 MB) > Physical memory chunk(s): > 0x0000000000001000 - 0x000000000009efff, 647168 bytes (158 pages) > 0x0000000000100000 - 0x00000000003fffff, 3145728 bytes (768 pages) > 0x0000000001426000 - 0x000000003eda4fff, 1033367552 bytes (252287 pages) > avail memory = 1032085504 (984 MB) > Table 'FACP' at 0x3fff0030 > Table 'APIC' at 0x3fff00b0 > APIC: Found table at 0x3fff00b0 > MP Configuration Table version 1.4 found at 0xc00f0cb0 > APIC: Using the MADT enumerator. > MADT: Found CPU APIC ID 0 ACPI ID 0: enabled > SMP: Added CPU 0 (AP) > MADT: Found CPU APIC ID 0 ACPI ID 1: disabled > MADT: Found CPU APIC ID 0 ACPI ID 2: disabled > MADT: Found CPU APIC ID 0 ACPI ID 3: disabled > MADT: Found CPU APIC ID 0 ACPI ID 4: disabled > MADT: Found CPU APIC ID 0 ACPI ID 5: disabled > MADT: Found CPU APIC ID 0 ACPI ID 6: disabled > MADT: Found CPU APIC ID 0 ACPI ID 7: disabled > ACPI APIC Table: > APIC: CPU 0 has ACPI ID 0 > bios32: Found BIOS32 Service Directory header at 0xc00fdb70 > bios32: Entry = 0xfdb80 (c00fdb80) Rev = 0 Len = 1 > pcibios: PCI BIOS entry at 0xf0000+0xdba1 > pnpbios: Found PnP BIOS data at 0xc00f4500 > pnpbios: Entry = f0000:33a4 Rev = 1.0 > Other BIOS signatures found: > x86bios: IVT 0x000000-0x0004ff at 0xc0000000 > x86bios: SSEG 0x010000-0x01ffff at 0xc43b9000 > x86bios: EBDA 0x09f000-0x09ffff at 0xc009f000 > x86bios: ROM 0x0a0000-0x0effff at 0xc00a0000 > ULE: setup cpu 0 > ACPI: RSDP 0xff900 00014 (v00 AMI ) > ACPI: RSDT 0x3fff0000 0002C (v01 RCC GCHE 00000001 MSFT 01000000) > ACPI: FACP 0x3fff0030 00074 (v01 RCC GCHE 00000001 MSFT 01000000) > ACPI: DSDT 0x3fff0150 049F1 (v01 RCC GCSL 00000100 MSFT 0100000D) > ACPI: FACS 0x3ffff000 00040 > ACPI: APIC 0x3fff00b0 0009A (v01 RCC GCHE 00000001 MSFT 01000000) > MADT: Found IO APIC ID 8, Interrupt 0 at 0xfec00000 > ioapic0: Routing external 8259A's -> intpin 0 > MADT: Found IO APIC ID 9, Interrupt 16 at 0xfec01000 > MADT: Found IO APIC ID 10, Interrupt 32 at 0xfec02000 > MADT: Interrupt override: source 0, irq 2 > ioapic0: Routing IRQ 0 -> intpin 2 > MADT: Forcing active-low polarity and level trigger for SCI > ioapic0: intpin 9 polarity: low > ioapic0: intpin 9 trigger: level > ioapic0 irqs 0-15 on motherboard > ioapic1 irqs 16-31 on motherboard > ioapic2 irqs 32-47 on motherboard > cpu0 BSP: > ID: 0x00000000 VER: 0x00050014 LDR: 0x00000000 DFR: 0xffffffff > lint0: 0x00010700 lint1: 0x00000400 TPR: 0x00000000 SVR: 0x000001ff > timer: 0x000100ef therm: 0x00010000 err: 0x000000f0 pmc: 0x00010400 > wlan: <802.11 Link Layer> > null: > random: > nfslock: pseudo-device > io: > kbd: new array size 4 > kbd1 at kbdmux0 > mem: > Pentium Pro MTRR support enabled > hptrr: RocketRAID 17xx/2xxx SATA controller driver v1.2 > acpi0: on motherboard > ACPI Warning: Type override - [DEB_] had invalid type (Integer) for Scope operator, changed to type ANY > (20101013/dswload-808) > ACPI Warning: Type override - [MLIB] had invalid type (Integer) for Scope operator, changed to type ANY > (20101013/dswload-808) > ACPI Warning: Type override - [IO__] had invalid type (Integer) for Scope operator, changed to type ANY > (20101013/dswload-808) > ACPI Warning: Type override - [DATA] had invalid type (String) for Scope operator, changed to type ANY > (20101013/dswload-808) > ACPI Warning: Type override - [SIO_] had invalid type (String) for Scope operator, changed to type ANY > (20101013/dswload-808) > ACPI Warning: Type override - [SB__] had invalid type (String) for Scope operator, changed to type ANY > (20101013/dswload-808) > ACPI Warning: Type override - [PM__] had invalid type (String) for Scope operator, changed to type ANY > (20101013/dswload-808) > ACPI Warning: Type override - [ICNT] had invalid type (String) for Scope operator, changed to type ANY > (20101013/dswload-808) > ACPI Warning: Type override - [ACPI] had invalid type (String) for Scope operator, changed to type ANY > (20101013/dswload-808) > ACPI Warning: Type override - [IORG] had invalid type (String) for Scope operator, changed to type ANY > (20101013/dswload-808) > ACPI Warning: Type override - [SB__] had invalid type (String) for Scope operator, changed to type ANY > (20101013/dswload-808) > ACPI Warning: Type override - [PM__] had invalid type (String) for Scope operator, changed to type ANY > (20101013/dswload-808) > ACPI Warning: Type override - [SIO_] had invalid type (String) for Scope operator, changed to type ANY > (20101013/dswload-808) > ACPI Warning: Type override - [PM__] had invalid type (String) for Scope operator, changed to type ANY > (20101013/dswload-808) > ACPI Warning: Type override - [BIOS] had invalid type (Integer) for Scope operator, changed to type ANY > (20101013/dswload-808) > ACPI Warning: Type override - [CMOS] had invalid type (Integer) for Scope operator, changed to type ANY > (20101013/dswload-808) > ACPI Warning: Type override - [KBC_] had invalid type (Integer) for Scope operator, changed to type ANY > (20101013/dswload-808) > ACPI Warning: Type override - [OEM_] had invalid type (Integer) for Scope operator, changed to type ANY > (20101013/dswload-808) > ioapic0: routing intpin 9 (ISA IRQ 9) to lapic 0 vector 48 > acpi0: [MPSAFE] > acpi0: [ITHREAD] > acpi0: Power Button (fixed) > acpi0: wakeup code va 0xc43b6000 pa 0x1000 > pci_open(1): mode 1 addr port (0x0cf8) is 0x800078ac > pci_open(1a): mode1res=0x80000000 (0x80000000) > pci_cfgcheck: device 0 [class=060000] [hdr=80] is there (id=00171166) > pcibios: BIOS version 2.10 > unknown: I/O range not supported > acpi0: reservation of 0, a0000 (3) failed > acpi0: reservation of 100000, 3ff00000 (3) failed > ACPI timer: 0/3 1/2 1/2 0/3 0/3 0/3 1/2 0/3 0/3 0/3 -> 3 > Timecounter "ACPI-safe" frequency 3579545 Hz quality 850 > acpi_timer0: <32-bit timer at 3.579545MHz> port 0x508-0x50b on acpi0 > cpu0: on acpi0 > cpu0: switching to generic Cx mode > pci_link0: Index IRQ Rtd Ref IRQs > Initial Probe 0 255 N 0 3 4 5 7 9 11 12 14 15 > Validation 0 255 N 0 3 4 5 7 9 11 12 14 15 > After Disable 0 255 N 0 3 4 5 7 9 11 12 14 15 > pci_link1: Index IRQ Rtd Ref IRQs > Initial Probe 0 255 N 0 3 4 5 7 9 11 12 14 15 > Validation 0 255 N 0 3 4 5 7 9 11 12 14 15 > After Disable 0 255 N 0 3 4 5 7 9 11 12 14 15 > pci_link2: Index IRQ Rtd Ref IRQs > Initial Probe 0 255 N 0 3 4 5 7 9 11 12 14 15 > Validation 0 255 N 0 3 4 5 7 9 11 12 14 15 > After Disable 0 255 N 0 3 4 5 7 9 11 12 14 15 > pci_link3: Index IRQ Rtd Ref IRQs > Initial Probe 0 255 N 0 3 4 5 7 9 11 12 14 15 > Validation 0 255 N 0 3 4 5 7 9 11 12 14 15 > After Disable 0 255 N 0 3 4 5 7 9 11 12 14 15 > pci_link4: Index IRQ Rtd Ref IRQs > Initial Probe 0 255 N 0 3 4 5 7 9 11 12 14 15 > Validation 0 255 N 0 3 4 5 7 9 11 12 14 15 > After Disable 0 255 N 0 3 4 5 7 9 11 12 14 15 > pci_link5: Index IRQ Rtd Ref IRQs > Initial Probe 0 255 N 0 3 4 5 7 9 11 12 14 15 > Validation 0 255 N 0 3 4 5 7 9 11 12 14 15 > After Disable 0 255 N 0 3 4 5 7 9 11 12 14 15 > pci_link6: Index IRQ Rtd Ref IRQs > Initial Probe 0 255 N 0 3 4 5 7 9 11 12 14 15 > Validation 0 255 N 0 3 4 5 7 9 11 12 14 15 > After Disable 0 255 N 0 3 4 5 7 9 11 12 14 15 > pci_link7: Index IRQ Rtd Ref IRQs > Initial Probe 0 255 N 0 3 4 5 7 9 11 12 14 15 > Validation 0 255 N 0 3 4 5 7 9 11 12 14 15 > After Disable 0 255 N 0 3 4 5 7 9 11 12 14 15 > pci_link8: Index IRQ Rtd Ref IRQs > Initial Probe 0 255 N 0 3 4 5 7 9 11 12 14 15 > Validation 0 255 N 0 3 4 5 7 9 11 12 14 15 > After Disable 0 255 N 0 3 4 5 7 9 11 12 14 15 > pci_link9: Index IRQ Rtd Ref IRQs > Initial Probe 0 255 N 0 3 4 5 7 9 11 12 14 15 > Validation 0 255 N 0 3 4 5 7 9 11 12 14 15 > After Disable 0 255 N 0 3 4 5 7 9 11 12 14 15 > pci_link10: Index IRQ Rtd Ref IRQs > Initial Probe 0 255 N 0 3 4 5 7 9 11 12 14 15 > Validation 0 255 N 0 3 4 5 7 9 11 12 14 15 > After Disable 0 255 N 0 3 4 5 7 9 11 12 14 15 > pci_link11: Index IRQ Rtd Ref IRQs > Initial Probe 0 255 N 0 3 4 5 7 9 11 12 14 15 > Validation 0 255 N 0 3 4 5 7 9 11 12 14 15 > After Disable 0 255 N 0 3 4 5 7 9 11 12 14 15 > pci_link12: Index IRQ Rtd Ref IRQs > Initial Probe 0 255 N 0 3 4 5 7 9 11 12 14 15 > Validation 0 255 N 0 3 4 5 7 9 11 12 14 15 > After Disable 0 255 N 0 3 4 5 7 9 11 12 14 15 > pci_link13: Index IRQ Rtd Ref IRQs > Initial Probe 0 255 N 0 3 4 5 7 9 11 12 14 15 > Validation 0 255 N 0 3 4 5 7 9 11 12 14 15 > After Disable 0 255 N 0 3 4 5 7 9 11 12 14 15 > pci_link14: Index IRQ Rtd Ref IRQs > Initial Probe 0 255 N 0 3 4 5 7 9 11 12 14 15 > Validation 0 255 N 0 3 4 5 7 9 11 12 14 15 > After Disable 0 255 N 0 3 4 5 7 9 11 12 14 15 > pci_link15: Index IRQ Rtd Ref IRQs > Initial Probe 0 255 N 0 3 4 5 7 9 11 12 14 15 > Validation 0 255 N 0 3 4 5 7 9 11 12 14 15 > After Disable 0 255 N 0 3 4 5 7 9 11 12 14 15 > pci_link16: Index IRQ Rtd Ref IRQs > Initial Probe 0 255 N 0 3 4 5 7 9 11 12 14 15 > Validation 0 255 N 0 3 4 5 7 9 11 12 14 15 > After Disable 0 255 N 0 3 4 5 7 9 11 12 14 15 > pci_link17: Index IRQ Rtd Ref IRQs > Initial Probe 0 255 N 0 3 4 5 7 9 11 12 14 15 > Validation 0 255 N 0 3 4 5 7 9 11 12 14 15 > After Disable 0 255 N 0 3 4 5 7 9 11 12 14 15 > pci_link18: Index IRQ Rtd Ref IRQs > Initial Probe 0 255 N 0 3 4 5 7 9 11 12 14 15 > Validation 0 255 N 0 3 4 5 7 9 11 12 14 15 > After Disable 0 255 N 0 3 4 5 7 9 11 12 14 15 > pci_link19: Index IRQ Rtd Ref IRQs > Initial Probe 0 255 N 0 3 4 5 7 9 11 12 14 15 > Validation 0 255 N 0 3 4 5 7 9 11 12 14 15 > After Disable 0 255 N 0 3 4 5 7 9 11 12 14 15 > pci_link20: Index IRQ Rtd Ref IRQs > Initial Probe 0 255 N 0 3 4 5 7 9 11 12 14 15 > Validation 0 255 N 0 3 4 5 7 9 11 12 14 15 > After Disable 0 255 N 0 3 4 5 7 9 11 12 14 15 > pci_link21: Index IRQ Rtd Ref IRQs > Initial Probe 0 255 N 0 3 4 5 7 9 11 12 14 15 > Validation 0 255 N 0 3 4 5 7 9 11 12 14 15 > After Disable 0 255 N 0 3 4 5 7 9 11 12 14 15 > pci_link22: Index IRQ Rtd Ref IRQs > Initial Probe 0 255 N 0 3 4 5 7 9 11 12 14 15 > Validation 0 255 N 0 3 4 5 7 9 11 12 14 15 > After Disable 0 255 N 0 3 4 5 7 9 11 12 14 15 > pci_link23: Index IRQ Rtd Ref IRQs > Initial Probe 0 255 N 0 3 4 5 7 9 11 12 14 15 > Validation 0 255 N 0 3 4 5 7 9 11 12 14 15 > After Disable 0 255 N 0 3 4 5 7 9 11 12 14 15 > pci_link24: Index IRQ Rtd Ref IRQs > Initial Probe 0 255 N 0 3 4 5 7 9 11 12 14 15 > Validation 0 255 N 0 3 4 5 7 9 11 12 14 15 > After Disable 0 255 N 0 3 4 5 7 9 11 12 14 15 > pci_link25: Index IRQ Rtd Ref IRQs > Initial Probe 0 255 N 0 3 4 5 7 9 11 12 14 15 > Validation 0 255 N 0 3 4 5 7 9 11 12 14 15 > After Disable 0 255 N 0 3 4 5 7 9 11 12 14 15 > pci_link26: Index IRQ Rtd Ref IRQs > Initial Probe 0 255 N 0 3 4 5 7 9 11 12 14 15 > Validation 0 255 N 0 3 4 5 7 9 11 12 14 15 > After Disable 0 255 N 0 3 4 5 7 9 11 12 14 15 > pci_link27: Index IRQ Rtd Ref IRQs > Initial Probe 0 255 N 0 3 4 5 7 9 11 12 14 15 > Validation 0 255 N 0 3 4 5 7 9 11 12 14 15 > After Disable 0 255 N 0 3 4 5 7 9 11 12 14 15 > pci_link28: Index IRQ Rtd Ref IRQs > Initial Probe 0 255 N 0 3 4 5 7 9 11 12 14 15 > Validation 0 255 N 0 3 4 5 7 9 11 12 14 15 > After Disable 0 255 N 0 3 4 5 7 9 11 12 14 15 > pci_link29: Index IRQ Rtd Ref IRQs > Initial Probe 0 255 N 0 3 4 5 7 9 11 12 14 15 > Validation 0 255 N 0 3 4 5 7 9 11 12 14 15 > After Disable 0 255 N 0 3 4 5 7 9 11 12 14 15 > pci_link30: Index IRQ Rtd Ref IRQs > Initial Probe 0 255 N 0 3 4 5 7 9 11 12 14 15 > Validation 0 255 N 0 3 4 5 7 9 11 12 14 15 > After Disable 0 255 N 0 3 4 5 7 9 11 12 14 15 > pci_link31: Index IRQ Rtd Ref IRQs > Initial Probe 0 255 N 0 3 4 5 7 9 11 12 14 15 > Validation 0 255 N 0 3 4 5 7 9 11 12 14 15 > After Disable 0 255 N 0 3 4 5 7 9 11 12 14 15 > pci_link32: Index IRQ Rtd Ref IRQs > Initial Probe 0 10 N 0 10 > Validation 0 10 N 0 10 > After Disable 0 255 N 0 10 > pci_link33: Index IRQ Rtd Ref IRQs > Initial Probe 0 255 N 0 11 > Validation 0 255 N 0 11 > After Disable 0 255 N 0 11 > acpi_button0: on acpi0 > pcib0: port 0xcf8-0xcff on acpi0 > ACPI: Found matching pin for 0.15.INTA at func 2: 10 > pci0: on pcib0 > pci0: domain=0, physical bus=0 > found-> vendor=0x1166, dev=0x0017, revid=0x32 > domain=0, bus=0, slot=0, func=0 > class=06-00-00, hdrtype=0x00, mfdev=1 > cmdreg=0x0000, statreg=0x0000, cachelnsz=16 (dwords) > lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) > found-> vendor=0x1166, dev=0x0017, revid=0x00 > domain=0, bus=0, slot=0, func=1 > class=06-00-00, hdrtype=0x00, mfdev=1 > cmdreg=0x0000, statreg=0x0000, cachelnsz=16 (dwords) > lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) > found-> vendor=0x8086, dev=0x1026, revid=0x04 > domain=0, bus=0, slot=1, func=0 > class=02-00-00, hdrtype=0x00, mfdev=0 > cmdreg=0x0117, statreg=0x0230, cachelnsz=16 (dwords) > lattimer=0x40 (1920 ns), mingnt=0xff (63750 ns), maxlat=0x00 (0 ns) > intpin=a, irq=5 > powerspec 2 supports D0 D3 current D0 > map[10]: type Memory, range 64, base 0xfeb60000, size 17, enabled > map[18]: type Memory, range 64, base 0xfeb00000, size 18, enabled > map[20]: type I/O Port, range 32, base 0xe000, size 6, enabled > pcib0: matched entry for 0.1.INTA > pcib0: slot 1 INTA hardwired to IRQ 16 > found-> vendor=0x1002, dev=0x4752, revid=0x27 > domain=0, bus=0, slot=6, func=0 > class=03-00-00, hdrtype=0x00, mfdev=0 > cmdreg=0x0087, statreg=0x0290, cachelnsz=16 (dwords) > lattimer=0x40 (1920 ns), mingnt=0x08 (2000 ns), maxlat=0x00 (0 ns) > intpin=a, irq=10 > powerspec 2 supports D0 D1 D2 D3 current D0 > map[10]: type Memory, range 32, base 0xfd000000, size 24, enabled > map[14]: type I/O Port, range 32, base 0xe800, size 8, enabled > map[18]: type Memory, range 32, base 0xfebff000, size 12, enabled > pcib0: matched entry for 0.6.INTA > pcib0: slot 6 INTA hardwired to IRQ 26 > found-> vendor=0x8086, dev=0x1229, revid=0x10 > domain=0, bus=0, slot=7, func=0 > class=02-00-00, hdrtype=0x00, mfdev=0 > cmdreg=0x0117, statreg=0x0290, cachelnsz=16 (dwords) > lattimer=0x40 (1920 ns), mingnt=0x08 (2000 ns), maxlat=0x38 (14000 ns) > intpin=a, irq=9 > powerspec 2 supports D0 D1 D2 D3 current D0 > map[10]: type Memory, range 32, base 0xfebfd000, size 12, enabled > map[14]: type I/O Port, range 32, base 0xe400, size 6, enabled > map[18]: type Memory, range 32, base 0xfeb80000, size 17, enabled > pcib0: matched entry for 0.7.INTA > pcib0: slot 7 INTA hardwired to IRQ 27 > found-> vendor=0x14e4, dev=0x16a6, revid=0x02 > domain=0, bus=0, slot=8, func=0 > class=02-00-00, hdrtype=0x00, mfdev=0 > cmdreg=0x0116, statreg=0x02b0, cachelnsz=16 (dwords) > lattimer=0x40 (1920 ns), mingnt=0x40 (16000 ns), maxlat=0x00 (0 ns) > intpin=a, irq=11 > powerspec 2 supports D0 D3 current D0 > MSI supports 8 messages, 64 bit > map[10]: type Memory, range 64, base 0xfebe0000, size 16, enabled > pcib0: matched entry for 0.8.INTA > pcib0: slot 8 INTA hardwired to IRQ 28 > found-> vendor=0x1166, dev=0x0203, revid=0xa0 > domain=0, bus=0, slot=15, func=0 > class=06-00-00, hdrtype=0x00, mfdev=1 > cmdreg=0x0107, statreg=0x2200, cachelnsz=0 (dwords) > lattimer=0x40 (1920 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) > found-> vendor=0x1166, dev=0x0213, revid=0xa0 > domain=0, bus=0, slot=15, func=1 > class=01-01-8a, hdrtype=0x00, mfdev=1 > cmdreg=0x0015, statreg=0x0200, cachelnsz=8 (dwords) > lattimer=0x40 (1920 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) > map[20]: type I/O Port, range 32, base 0xffa0, size 4, enabled > found-> vendor=0x1166, dev=0x0221, revid=0x05 > domain=0, bus=0, slot=15, func=2 > class=0c-03-10, hdrtype=0x00, mfdev=1 > cmdreg=0x0117, statreg=0x0280, cachelnsz=0 (dwords) > lattimer=0x40 (1920 ns), mingnt=0x00 (0 ns), maxlat=0x50 (20000 ns) > intpin=a, irq=10 > map[10]: type Memory, range 32, base 0xfebfe000, size 12, enabled > pcib0: matched entry for 0.15.INTA (src \\_SB_.LNUS:0) > ioapic0: Changing trigger for pin 10 to level > ioapic0: Changing polarity for pin 10 to low > pcib0: slot 15 INTA routed to irq 10 via \\_SB_.LNUS > unknown: Reserved 0x1000 bytes for rid 0x10 type 3 at 0xfebfe000 > ohci early: SMM active, request owner change > found-> vendor=0x1166, dev=0x0227, revid=0x00 > domain=0, bus=0, slot=15, func=3 > class=06-01-00, hdrtype=0x00, mfdev=1 > cmdreg=0x0107, statreg=0x0200, cachelnsz=0 (dwords) > lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) > em0: port 0xe000-0xe03f mem 0xfeb60000-0xfeb7ffff,0xfeb00000-0xfeb3ffff irq 16 at device 1.0 on pci0 > em0: Reserved 0x20000 bytes for rid 0x10 type 3 at 0xfeb60000 > em0: Reserved 0x40 bytes for rid 0x20 type 4 at 0xe000 > ioapic1: routing intpin 0 (PCI IRQ 16) to lapic 0 vector 49 > em0: [FILTER] > em0: bpf attached > em0: Ethernet address: 00:04:23:df:fa:46 > vgapci0: port 0xe800-0xe8ff mem 0xfd000000-0xfdffffff,0xfebff000-0xfebfffff irq 26 at device 6.0 on pci0 > fxp0: port 0xe400-0xe43f mem 0xfebfd000-0xfebfdfff,0xfeb80000-0xfeb9ffff irq 27 at device 7.0 on pci0 > fxp0: Reserved 0x1000 bytes for rid 0x10 type 3 at 0xfebfd000 > fxp0: using memory space register mapping > fxp0: PCI IDs: 8086 1229 8086 1050 0010 > fxp0: Dynamic Standby mode is disabled > miibus0: on fxp0 > inphy0: PHY 1 on miibus0 > inphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto, auto-flow > fxp0: bpf attached > fxp0: Ethernet address: 00:30:48:52:51:ae > ioapic1: routing intpin 11 (PCI IRQ 27) to lapic 0 vector 50 > fxp0: [MPSAFE] > fxp0: [ITHREAD] > pci0:0:8:0: bad VPD cksum, remain 14 > bge0: mem 0xfebe0000-0xfebeffff irq 28 at device 8.0 on pci0 > bge0: Reserved 0x10000 bytes for rid 0x10 type 3 at 0xfebe0000 > bge0: CHIP ID 0x00001002; ASIC REV 0x01; CHIP REV 0x10; PCI > miibus1: on bge0 > brgphy0: PHY 1 on miibus1 > brgphy0: OUI 0x000818, model 0x0016, rev. 2 > brgphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-master, 1000baseT-FDX, 1000baseT-FDX-master, auto, auto-flow > bge0: bpf attached > bge0: Ethernet address: 00:30:48:52:51:af > ioapic1: routing intpin 12 (PCI IRQ 28) to lapic 0 vector 51 > bge0: [MPSAFE] > bge0: [ITHREAD] > atapci0: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xffa0-0xffaf at device 15.1 on pci0 > atapci0: Reserved 0x10 bytes for rid 0x20 type 4 at 0xffa0 > ata0: at channel 0 on atapci0 > atapci0: Reserved 0x8 bytes for rid 0x10 type 4 at 0x1f0 > atapci0: Reserved 0x1 bytes for rid 0x14 type 4 at 0x3f6 > ata0: reset tp1 mask=03 ostat0=50 ostat1=00 > ata0: stat0=0x50 err=0x01 lsb=0x00 msb=0x00 > ata0: stat1=0x00 err=0x01 lsb=0x00 msb=0x00 > ata0: reset tp2 stat0=50 stat1=00 devices=0x1 > ioapic0: routing intpin 14 (ISA IRQ 14) to lapic 0 vector 52 > ata0: [MPSAFE] > ata0: [ITHREAD] > ata1: at channel 1 on atapci0 > atapci0: Reserved 0x8 bytes for rid 0x18 type 4 at 0x170 > atapci0: Reserved 0x1 bytes for rid 0x1c type 4 at 0x376 > ata1: reset tp1 mask=01 ostat0=50 ostat1=ff > ata1: stat0=0x00 err=0x01 lsb=0x14 msb=0xeb > ata1: reset tp2 stat0=00 stat1=00 devices=0x10000 > ioapic0: routing intpin 15 (ISA IRQ 15) to lapic 0 vector 53 > ata1: [MPSAFE] > ata1: [ITHREAD] > ohci0: mem 0xfebfe000-0xfebfefff irq 10 at device 15.2 on pci0 > ohci0: (New OHCI DeviceId=0x02211166) > ioapic0: routing intpin 10 (ISA IRQ 10) to lapic 0 vector 54 > ohci0: [MPSAFE] > ohci0: [ITHREAD] > usbus0: on ohci0 > usbus0: bpf attached > ohci0: usbpf: Attached > isab0: at device 15.3 on pci0 > isa0: on isab0 > atrtc0: port 0x70-0x71 irq 8 on acpi0 > atrtc0: registered as a time-of-day clock (resolution 1000000us) > psmcpnp0: irq 12 on acpi0 > atkbdc0: port 0x60,0x64 irq 1 on acpi0 > atkbd0: irq 1 on atkbdc0 > atkbd: the current kbd controller command byte 0065 > atkbd: keyboard ID 0x41ab (2) > kbd0 at atkbd0 > kbd0: atkbd0, AT 101/102 (2), config:0x0, flags:0x3d0000 > ioapic0: routing intpin 1 (ISA IRQ 1) to lapic 0 vector 55 > atkbd0: [GIANT-LOCKED] > atkbd0: [ITHREAD] > psm0: current command byte:0065 > psm0: irq 12 on atkbdc0 > ioapic0: routing intpin 12 (ISA IRQ 12) to lapic 0 vector 56 > psm0: [GIANT-LOCKED] > psm0: [ITHREAD] > psm0: model IntelliMouse, device ID 3-00, 3 buttons > psm0: config:00000000, flags:00000008, packet size:4 > psm0: syncmask:08, syncbits:00 > fdc0: port 0x3f2-0x3f3,0x3f4-0x3f5,0x3f7 irq 6 drq 2 on acpi0 > fdc0: ic_type 90 part_id 73 > ioapic0: routing intpin 6 (ISA IRQ 6) to lapic 0 vector 57 > fdc0: [FILTER] > fd0: <1440-KB 3.5" drive> on fdc0 drive 0 > uart0: <16550 or compatible> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 > ioapic0: routing intpin 4 (ISA IRQ 4) to lapic 0 vector 58 > uart0: [FILTER] > uart0: fast interrupt > uart1: <16550 or compatible> port 0x2f8-0x2ff irq 3 on acpi0 > ioapic0: routing intpin 3 (ISA IRQ 3) to lapic 0 vector 59 > uart1: [FILTER] > uart1: fast interrupt > ppc0: using extended I/O port range > ppc0: SPP ECP > ppc0: port 0x378-0x37f,0x778-0x77f irq 7 drq 3 on acpi0 > ppc0: Generic chipset (ECP/PS2/NIBBLE) in COMPATIBLE mode > ppc0: FIFO with 16/16/8 bytes threshold > ioapic0: routing intpin 7 (ISA IRQ 7) to lapic 0 vector 60 > ppc0: [MPSAFE] > ppc0: [ITHREAD] > ppbus0: on ppc0 > plip0: on ppbus0 > plip0: bpf attached > plip0: [MPSAFE] > plip0: [ITHREAD] > lpt0: on ppbus0 > lpt0: [MPSAFE] > lpt0: [ITHREAD] > lpt0: Interrupt-driven port > ppi0: on ppbus0 > unknown: status reg test failed ff > unknown: status reg test failed ff > unknown: status reg test failed ff > unknown: status reg test failed ff > unknown: status reg test failed ff > unknown: status reg test failed ff > ahc_isa_probe 0: ioport 0xc00 alloc failed > ex_isa_identify() > pnp_identify: Trying Read_Port at 203 > pnp_identify: Trying Read_Port at 243 > pnp_identify: Trying Read_Port at 283 > pnp_identify: Trying Read_Port at 2c3 > pnp_identify: Trying Read_Port at 303 > pnp_identify: Trying Read_Port at 343 > pnp_identify: Trying Read_Port at 383 > pnp_identify: Trying Read_Port at 3c3 > PNP Identify complete > isa_probe_children: disabling PnP devices > pmtimer0 on isa0 > ata: ata0 already exists; skipping it > ata: ata1 already exists; skipping it > atkbdc: atkbdc0 already exists; skipping it > atrtc: atrtc0 already exists; skipping it > fdc: fdc0 already exists; skipping it > ppc: ppc0 already exists; skipping it > sc: sc0 already exists; skipping it > uart: uart0 already exists; skipping it > uart: uart1 already exists; skipping it > isa_probe_children: probing non-PnP devices > orm0: at iomem 0xc0000-0xc7fff,0xc8000-0xc97ff,0xc9800-0xcafff pnpid ORM0000 on isa0 > sc0: at flags 0x100 on isa0 > sc0: VGA <16 virtual consoles, flags=0x300> > sc0: fb0, kbd1, terminal emulator: scteken (teken terminal) > vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 > isa_probe_children: probing PnP devices > p4tcc0: on cpu0 > Device configuration finished. > procfs registered > lapic: Divisor 2, Frequency 66669589 Hz > Timecounter "TSC" frequency 2666782592 Hz quality 800 > Timecounters tick every 1.000 msec > vlan: initialized, using hash tables with chaining > ipfw2 (+ipv6) initialized, divert enabled, nat loadable, rule-based forwarding disabled, default to accept, logging disabled > ipfw0: bpf attached > lo0: bpf attached > hptrr: no controller detected. > ata0: Identifying devices: 00000001 > ata0: New devices: 00000001 > usbus0: 12Mbps Full Speed USB v1.0 > ata0-master: pio=PIO4 wdma=WDMA2 udma=UDMA100 cable=80 wire > ad0: setting UDMA100 > ad0: 152627MB at ata0-master UDMA100 > ad0: 312581808 sectors [310101C/16H/63S] 16 sectors/interrupt 1 depth queue > ugen0.1: <0x1166> at usbus0 > uhub0: <0x1166 OHCI root HUB, class 9/0, rev 1.00/1.00, addr 1> on usbus0 > ad0: Adaptec check1 failed > ad0: LSI (v3) check1 failed > ad0: LSI (v2) check1 failed > ad0: FreeBSD check1 failed > ata1: Identifying devices: 00010000 > ata1: New devices: 00010000 > ata1-master: pio=PIO4 wdma=WDMA2 udma=UDMA33 cable=40 wire > acd0: setting UDMA33 > acd0: CDROM drive at ata1 as master > acd0: read 4125KB/s (4125KB/s), 128KB buffer, UDMA33 > acd0: Reads: CDR, CDRW, CDDA stream, packet > acd0: Writes: > acd0: Audio: play, 256 volume levels > acd0: Mechanism: ejectable tray, unlocked > acd0: Medium: no/blank disc > ATA PseudoRAID loaded > uhub0: 4 ports with 4 removable, self powered > GEOM: new disk ad0 > GEOM: ad0s2: geometry does not match label (255h,63s != 16h,63s). > Trying to mount root from ufs:/dev/ad0s2a > start_init: trying /sbin/init > em0: Link is up 1000 Mbps Full Duplex > em0: Link is Down > em0: Link is up 1000 Mbps Full Duplex > splash: image decoder found: daemon_saver CC'ing Yong-Hyeon PYUN who may be able to help with this. If you could also provide "pciconf -lvbc" output that would be useful. -- | Jeremy Chadwick jdc@koitsu.org | | UNIX Systems Administrator http://jdc.koitsu.org/ | | Mountain View, CA, US | | Making life hard for others since 1977. PGP 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Sun May 12 06:45:07 2013 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id AB0939DA; Sun, 12 May 2013 06:45:07 +0000 (UTC) (envelope-from gjb@FreeBSD.org) Received: from onyx.glenbarber.us (onyx.glenbarber.us [199.48.134.227]) by mx1.freebsd.org (Postfix) with ESMTP id 89F69DBD; Sun, 12 May 2013 06:45:07 +0000 (UTC) Received: from glenbarber.us (70.15.88.86.res-cmts.sewb.ptd.net [70.15.88.86]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) (Authenticated sender: gjb) by onyx.glenbarber.us (Postfix) with ESMTPSA id D151723F804; Sun, 12 May 2013 02:45:05 -0400 (EDT) DKIM-Filter: OpenDKIM Filter v2.8.3 onyx.glenbarber.us D151723F804 Authentication-Results: onyx.glenbarber.us; dkim=none reason="no signature"; dkim-adsp=none Date: Sun, 12 May 2013 02:45:03 -0400 From: Glen Barber To: "Michael L. Squires" Subject: Re: Apparent fxp regression in FreeBSD 8.4-RC3 Message-ID: <20130512064503.GA1632@glenbarber.us> References: <20130508174721.GD1651@glenbarber.us> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="liOOAslEiF7prFVr" Content-Disposition: inline In-Reply-To: X-Operating-System: FreeBSD 10.0-CURRENT amd64 User-Agent: Mutt/1.5.21 (2010-09-15) Cc: FreeBSD Release Engineering Team , freebsd-stable@FreeBSD.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 12 May 2013 06:45:07 -0000 --liOOAslEiF7prFVr Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, May 11, 2013 at 10:57:44PM -0400, Michael L. Squires wrote: > I upgraded to FreeBSD 8.4-RC3 and noticed a problem with the fxp > driver on an older Supermicro single CPU single core Xeon > motherboard. >=20 > [...] > Copyright (c) 1992-2013 The FreeBSD Project. > Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 > The Regents of the University of California. All rights reserved. > FreeBSD is a registered trademark of The FreeBSD Foundation. > FreeBSD 8.4-PRERELEASE #45: Fri May 10 09:43:40 EDT 2013 > root@familysquires.net:/usr/obj/usr/src/sys/NEWGATE i386 Your attached dmesg of -RC3 is not -RC3, it is 8-STABLE. At this point, there have been changes between the stable/8 and releng/8.4 branches enough say that the two have diverged, and the stable/8 code is _not_ what will be the 8.4-RELEASE. While your issue does concern me, it is still unclear that this is a problem with the upcoming 8.4-RELEASE. Can you please try upgrading to the releng/8.4 branch to see if this issue persists? Glen --liOOAslEiF7prFVr Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iQEcBAEBCAAGBQJRjzpvAAoJEFJPDDeguUaj3uQH/RtVyl4/sSoYMYtgf8WQLsUI TqYE093S1FYYFqWvvI43e7V+aaE6cga7sqpKbWfk0V0sutQUm88D3T1Nrn2oyXGn Jwo3akdgicHDAJzNkKE1qBtWxfQecQ60q9a08vJksjjS/20lPOzXcLIVfTIXnGi0 PrXFBiLOPJP42D7SI6tXlSK5l0bck/dqvzH1zO2bXGTm+03EuD2fcT1ESKxAU9cz b+jboswapnMk7lKg6Kn2IBshlVjDB8dRjjc1DbRWBV/bkyXxgFAw0mSoVo0zfoZo GPYIz9kVhceKOMzZ4VeI3YxA9FS3HsIJ5z9iZLhumsMsCDfOpbl/DQjsvAQj49Q= =rszd -----END PGP SIGNATURE----- --liOOAslEiF7prFVr-- From owner-freebsd-stable@FreeBSD.ORG Sun May 12 13:14:02 2013 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 5A0239E8; Sun, 12 May 2013 13:14:02 +0000 (UTC) (envelope-from mikes@siralan.org) Received: from mail.suso.org (mail.suso.org [66.244.94.5]) by mx1.freebsd.org (Postfix) with ESMTP id 296EFAE7; Sun, 12 May 2013 13:14:01 +0000 (UTC) Received: from c-98-223-197-163.hsd1.in.comcast.net (c-98-223-197-163.hsd1.in.comcast.net [98.223.197.163]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.suso.org (Postfix) with ESMTP id 8A8DA138257; Sun, 12 May 2013 13:13:58 +0000 (GMT) Date: Sun, 12 May 2013 09:13:44 -0400 (EDT) From: "Michael L. Squires" X-X-Sender: mikes@familysquires.net To: Jeremy Chadwick Subject: Re: Apparent fxp regression in FreeBSD 8.4-RC3 In-Reply-To: <20130512032302.GA51272@icarus.home.lan> Message-ID: References: <20130508174721.GD1651@glenbarber.us> <20130512032302.GA51272@icarus.home.lan> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII Cc: Yong-Hyeon PYUN , Glen Barber , FreeBSD Release Engineering Team , freebsd-stable@FreeBSD.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 12 May 2013 13:14:02 -0000 Here is pciconf -lvbc under 8.3-RELEASE p8: hostb0@pci0:0:0:0: class=0x060000 card=0x00000000 chip=0x00171166 rev=0x32 hdr=0x00 vendor = 'ServerWorks (Was: Reliance Computer Corp)' device = 'CMIC-SL' class = bridge subclass = HOST-PCI hostb1@pci0:0:0:1: class=0x060000 card=0x00000000 chip=0x00171166 rev=0x00 hdr=0x00 vendor = 'ServerWorks (Was: Reliance Computer Corp)' device = 'CMIC-SL' class = bridge subclass = HOST-PCI em0@pci0:0:1:0: class=0x020000 card=0x10018086 chip=0x10268086 rev=0x04 hdr=0x00 vendor = 'Intel Corporation' device = 'Gigabit Ethernet Controller (82545ep)' class = network subclass = ethernet bar [10] = type Memory, range 64, base 0xfeb60000, size 131072, enabled bar [18] = type Memory, range 64, base 0xfeb00000, size 262144, enabled bar [20] = type I/O Port, range 32, base 0xe000, size 64, enabled cap 01[dc] = powerspec 2 supports D0 D3 current D0 cap 07[e4] = PCI-X 64-bit supports 133MHz, 2048 burst read, 1 split transaction vgapci0@pci0:0:6:0: class=0x030000 card=0x00081002 chip=0x47521002 rev=0x27 hdr=0x00 vendor = 'ATI Technologies Inc. / Advanced Micro Devices, Inc.' device = 'ATI On-Board VGA for HP Proliant 350 G3 (Rage XL PCI)' class = display subclass = VGA bar [10] = type Memory, range 32, base 0xfd000000, size 16777216, enabled bar [14] = type I/O Port, range 32, base 0xe800, size 256, enabled bar [18] = type Memory, range 32, base 0xfebff000, size 4096, enabled cap 01[5c] = powerspec 2 supports D0 D1 D2 D3 current D0 fxp0@pci0:0:7:0: class=0x020000 card=0x10508086 chip=0x12298086 rev=0x10 hdr=0x00 vendor = 'Intel Corporation' device = '82550/1/7/8/9 EtherExpress PRO/100(B) Ethernet Adapter' class = network subclass = ethernet bar [10] = type Memory, range 32, base 0xfebfd000, size 4096, enabled bar [14] = type I/O Port, range 32, base 0xe400, size 64, enabled bar [18] = type Memory, range 32, base 0xfeb80000, size 131072, enabled cap 01[dc] = powerspec 2 supports D0 D1 D2 D3 current D0 bge0@pci0:0:8:0: class=0x020000 card=0x800914e4 chip=0x16a614e4 rev=0x02 hdr=0x00 vendor = 'Broadcom Corporation' device = 'BCM5702X NetXtreme Gigabit Ethernet' class = network subclass = ethernet bar [10] = type Memory, range 64, base 0xfebe0000, size 65536, enabled cap 07[40] = PCI-X 64-bit supports 133MHz, 2048 burst read, 1 split transaction cap 01[48] = powerspec 2 supports D0 D3 current D0 cap 03[50] = VPD cap 05[58] = MSI supports 8 messages, 64 bit hostb2@pci0:0:15:0: class=0x060000 card=0x425515d9 chip=0x02031166 rev=0xa0 hdr=0x00 vendor = 'ServerWorks (Was: Reliance Computer Corp)' device = 'PCI to ISA Bridge (CSB6)' class = bridge subclass = HOST-PCI atapci0@pci0:0:15:1: class=0x01018a card=0x021211d9 chip=0x02131166 rev=0xa0 hdr=0x00 vendor = 'ServerWorks (Was: Reliance Computer Corp)' device = 'OSB6/CSB6 PCI EIDE Controller' class = mass storage subclass = ATA bar [10] = type I/O Port, range 32, base 0x1f0, size 8, enabled bar [14] = type I/O Port, range 32, base 0x3f4, size 1, enabled bar [18] = type I/O Port, range 32, base 0x170, size 8, enabled bar [1c] = type I/O Port, range 32, base 0x374, size 1, enabled bar [20] = type I/O Port, range 32, base 0xffa0, size 16, enabled ohci0@pci0:0:15:2: class=0x0c0310 card=0x425515d9 chip=0x02211166 rev=0x05 hdr=0x00 vendor = 'ServerWorks (Was: Reliance Computer Corp)' device = 'OHCI Compliant USB Controller (OSB6)' class = serial bus subclass = USB bar [10] = type Memory, range 32, base 0xfebfe000, size 4096, enabled isab0@pci0:0:15:3: class=0x060100 card=0x425515d9 chip=0x02271166 rev=0x00 hdr=0x00 vendor = 'ServerWorks (Was: Reliance Computer Corp)' device = 'PCI Bridge (CSB6)' class = bridge subclass = PCI-ISA From owner-freebsd-stable@FreeBSD.ORG Sun May 12 17:54:58 2013 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 63234802; Sun, 12 May 2013 17:54:58 +0000 (UTC) (envelope-from pali.gabor@gmail.com) Received: from mail-ee0-f46.google.com (mail-ee0-f46.google.com [74.125.83.46]) by mx1.freebsd.org (Postfix) with ESMTP id 6558067D; Sun, 12 May 2013 17:54:56 +0000 (UTC) Received: by mail-ee0-f46.google.com with SMTP id e49so1173774eek.5 for ; Sun, 12 May 2013 10:54:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:sender:date:from:to:cc:subject:message-id:organization :x-mailer:mime-version:content-type:content-transfer-encoding; bh=eULesjOb39sJd/mJ0denfWWGMB8KfGMdpy/4x27l1Ew=; b=z6zg4xAouE04VXCoJM1e8hqP/Wnww+f6xosQwKSvxQeUV5plNkqe69mIGH5uhu6BnJ jcKF0I8sza6uBAs2S4DfxwQXtP5jjmyyFfYJdtT8EAH3kWGUiPZD2IahDhANtZkFB/T0 1YyQ1nPeQO/lxvRz+OEBFeqC3nKzzqnDri63tx95T5P5UeybTa48SikVwcXiY/dT/oTa uLzepYjMeCWEOtZqHIKJcMGV0fsGqzSJQ2NxoQ1s/GMaNVzACAKSzbKRmvsJHL30GDwa Z2v6TIq4ILM1VrRCbdKAyfE7LcyDreMLJ2RN1a5F82k9FdymxYvW8+49VPg9h8KkjuMC vLNQ== X-Received: by 10.14.0.129 with SMTP id 1mr68418742eeb.43.1368381289883; Sun, 12 May 2013 10:54:49 -0700 (PDT) Received: from funktor (catv-80-98-246-83.catv.broadband.hu. [80.98.246.83]) by mx.google.com with ESMTPSA id i2sm6674817eeg.2.2013.05.12.10.54.48 for (version=SSLv3 cipher=RC4-SHA bits=128/128); Sun, 12 May 2013 10:54:49 -0700 (PDT) Sender: =?UTF-8?B?UMOhbGkgR8OhYm9yIErDoW5vcw==?= Date: Sun, 12 May 2013 19:54:05 +0200 From: Gabor Pali To: hackers@freebsd.org Subject: FreeBSD Quarterly Status Report, January-March 2013 Message-ID: <20130512195405.04653b64@funktor> Organization: The FreeBSD Project X-Mailer: Claws Mail 3.9.0 (GTK+ 2.24.17; i386-portbld-freebsd9.1) Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: stable@freebsd.org, current@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 12 May 2013 17:54:58 -0000 FreeBSD Quarterly Status Report, January-March 2013 Introduction This report covers FreeBSD-related projects between January and March 2013. This is the first of four reports planned for 2013. Highlights from this status report include the busy preparations of 8.4-RELEASE, restoration of binary package building, steady progress of several porting efforts, like work on the FreeBSD ports of xorg, GNOME, KDE, and Xfce, bringing FreeBSD to Cubieboard and Hackberry boards, development of ARM and AMD GPU support, improving performance of UFS/FFS and callouts, and introducing a multipath TCP implementation for the network stack. Thanks to all the reporters for the excellent work! This report contains 31 entries and we hope you enjoy reading it. The deadline for submissions covering the period between April and June 2013 is July 7th, 2013. __________________________________________________________________ Projects * FreeNAS * Kernel Information in Process Core Dumps * Native iSCSI Stack FreeBSD Team Reports * FreeBSD Bugmeister Team * FreeBSD Core Team * FreeBSD Port Managers * FreeBSD Postmaster Team * FreeBSD Release Engineering Team Kernel * AMD GPU Kernel Mode-Setting (KMS) Support * Atomic "close-on-exec" * callout(9) Improvements * Multipath TCP (MPTCP) for FreeBSD * racct: Block IO Accounting * Read-only Port of NetBSD's UDF File System * TCP-AO Authentication Option * UFS/FFS Performance Work Documentation * Improving the Documentation Project Infrastructre * The entities Documentation Branch * The FreeBSD Japanese Documentation Project Architectures * FreeBSD on Cubieboard * FreeBSD/arm Superpages for ARMv7 * FreeBSD/ARM Toolchain Improvements Ports * FreeBSD Haskell Ports * GNOME/FreeBSD * KDE/FreeBSD * PyPy * Wine32 on FreeBSD/amd64 * Xfce/FreeBSD * xorg on FreeBSD Miscellaneous * BXR.SU -- Super User's BSD Cross Reference * mdoc.su -- Short Manual Page URLs __________________________________________________________________ AMD GPU Kernel Mode-Setting (KMS) Support URL: https://wiki.freebsd.org/AMD_GPU Contact: Jean-S=C3=A9bastien P=C3=A9dron Contact: J.R. Oldroyd Contact: Konstantin Belousov The project progressed well since February: * Konstantin committed is TTM port to 10-CURRENT. * With the help of John Baldwin (jhb) and Andriy Gapon (avg), the Video BIOS situation greatly improved: the radeonkms driver reads the BIOS shadow copy if the video card is the primary one, or query the PCI expansion ROM otherwise. In the end, this code will be probably committed to the PCI driver so that other video drivers benefit from it. * Andriy also reported several problems with the I2C code. Now that they are fixed, the monitors plugged into DVI and HDMI connectors are detected and their EDID is read correctly. VGA connector is not tested so far. * There is a locking problem in either TTM or the Radeon driver which prevents OpenGL from working properly. Jean-S=C3=A9bastien is curren= tly tracking this down. * J.R. Oldroyd started to work on a 9-STABLE backport of the driver which is now working quite well. He had to backport some features from the VM which may need further refinement by the VM folks. Yakaz lended Jean-S=C3=A9bastien a computer which allows him to test a RV630-based discrete card and, in the future, other PCIe cards. Several users already kindly tested the driver. Big thanks to all those contributors! In its current state, the driver allows to have a simple X session (no OpenGL), run common applications, watch movies, change the resolution and enable additional monitors with xrandr(1). The most blocking issue now is the OpenGL deadlock which prevents to run modern compositors/desktop environment, games and WebGL demos. We are not ready for a "Call For Testers" yet. Open tasks: 1. Test multiple cards configurations for Video BIOS issues, especially Intel integrated card + Radeon discrete card, and AMD integrated card (IGP) + Radeon discrete card. No need to check configurations with one shared connector though, it is not supported right now. __________________________________________________________________ Atomic "close-on-exec" URL: https://wiki.freebsd.org/AtomicCloseOnExec Contact: Jilles Tjoelker If threads or signal handlers call fork() and exec(), file descriptors may be passed undesirably to child processes, which may lead to hangs (if a pipe is not closed), exceeding the file descriptor limit and security problems (if the child process has lower privilege). One solution is various new APIs that set the "close-on-exec" flag atomically with allocating a file descriptor. Some existing software will use the new features if present or will even refuse to compile without them. Various parts have been present for some time. In first quarter of 2013, extensions to recvmsg(), socket(), socketpair() and posix_openpt() have been added. __________________________________________________________________ BXR.SU -- Super User's BSD Cross Reference URL: http://bxr.su/ URL: http://lists.freebsd.org/pipermail/freebsd-hackers/2013-April/04233= 4.html Contact: Constantine A. Murenin Super User's BSD Cross Reference (BXR.SU) is a new source-code search engine that covers the complete kernel and non-GNU userland source trees of FreeBSD, NetBSD, OpenBSD, and DragonFly BSD. BXR.SU is optimised to be very fast, has daily updates of all the trees, and also acts as a deterministic URL shortener. BXR.SU is based on an OpenGrok fork, but it is more than just OpenGrok. We have fixed a number of annoyances, eliminated features that just never worked right from the outright, and provided integration with tools like CVSweb (including great mirrors like allbsd.org), FreeBSD's ViewVC (SVN), as well as GitHub and Gitweb from git.freebsd.your.org, plus a tad of other improvements, including a complete rewrite of an mdoc parser. Last, but definitely not least, is an extensive set of nginx rewrite rules that makes it a breeze to use BXR.SU as a deterministic URL compactor for referencing BSD source code. For example, the http://bxr.su/f/kern/sched_ule.c URL will automatically redirect to http://bxr.su/FreeBSD/sys/kern/sched_ule.c through nginx. Note that according to the release schedule of BXR.SU, there is no IPv4 glue until 2013-04-24; otherwise, the service is available via both IPv4 and IPv6. See the 2013-04-01 announcement on the freebsd-hackers mailing list for more details. Open tasks: 1. Find up-to-date git repositories (served with Gitweb) of NetBSD and OpenBSD. 2. Find a Gitweb mirror of FreeBSD that is faster than GitHub and Gitorious. __________________________________________________________________ callout(9) Improvements URL: http://people.freebsd.org/~davide/asia/callout_paper.pdf URL: http://people.freebsd.org/~davide/asia/calloutng.pdf URL: http://svnweb.freebsd.org/base?view=3Drevision&revision=3D247777 Contact: Davide Italiano Contact: Alexander Motin In FreeBSD, timers are provided by the callout facility, which allows to register a function with an argument to be called at specified future time. The subsystem suffered of some problems, such as the impossibility of handling high-resolution events or its inherent periodic structure, which may lead to spurious wakeups and higher power consumption. Some consumers, such as high-speed networking, VoIP and other real-time applications need a better precision than the one currently allowed. Also, especially with the ubiquity of laptops in the last years, the energy wasted by interrupts waking CPUs from sleep may be a sensitive factor. Recent changes in the subsystem addressed those long-standing issues as well as introduced a new programming interface to take advantage of the new features. Open tasks: 1. Evaluating if it is worth to migrate any of the other callout(9) consumers to the new interface. 2. Move callout consumers still using the legacy timeout()/untimeout() interface to callout_*() in order to get rid of redundant code and clean up KPI. __________________________________________________________________ FreeBSD Bugmeister Team Contact: Eitan Adler Contact: Gavin Atkinson Contact: Oleksandr Tymoshenko The FreeBSD Bugmeister Team are continuing to evaluate options for alternate bug trackers and have narrowed their choices to two possibilities: Bugzilla and roundup. The number of non-ports PRs have remained relatively static over the last three months, with as many coming in as being closed. The number of ports PRs have increased recently, largely due to the ports freeze for the upcoming 8.4-RELEASE. The Bugmeister team continue work on trying to make the contents of the GNATS PR database cleaner, more accessible and easier for committers to find and resolve PRs, by tagging PRs to indicate the areas involved, and by ensuring that there is sufficient info within each PR to resolve each issue. As always, anybody interested in helping out with the PR queue is welcome to join us in #freebsd-bugbusters on EFnet. We are always looking for additional help, whether your interests lie in triaging incoming PRs, generating patches to resolve existing problems, or simply helping with the database housekeeping (identifying duplicate PRs, ones that have already been resolved, etc). This is a great way of getting more involved with FreeBSD! Open tasks: 1. Finalize the decision of which new bug tracker to use. 2. Get more users involved with triaging PRs as they come in. 3. Assist committers with closing PRs. __________________________________________________________________ FreeBSD Core Team Contact: Core Team At the end of 2012, the Core Team approved using Google Analytics on the Project web site to enable the Documentation Engineering Team to collect statistics on its usage for better profiling. In the first quarter of 2013, the Core Team worked with the Documentation Engineering Team to finalize the associated policies. Due to some debates around the political correctness of quotes added for the fortune(6) utility, the corresponding data file has been removed from the base system in -CURRENT. In light of the security incident, the liaison role between the Core Team and the Security Team has been restored, with Gavin Atkinson assuming this role. The Core Team work hard on resolving the current situation of the binary package building cluster and the associated security problems in tight cooperation with the Ports Management Team, Cluster Administators, and the FreeBSD Foundation Board. The compromise page is kept updated on the results. The FreeBSD Project submitted an application for Google Summer of Code this year again. There was access granted for 2 new committers and 1 commit bit was taken for safekeeping in this quarter. __________________________________________________________________ FreeBSD Haskell Ports URL: http://wiki.freebsd.org/Haskell URL: https://github.com/freebsd-haskell/freebsd-haskell/ Contact: G=C3=A1bor P=C3=A1li Contact: Ashish Shukla We are proud to announce FreeBSD Haskell Team has updated existing ports to their latest stable versions. We also added number of new ports, which brings the count of Haskell ports in FreeBSD ports tree to more than 400, featuring many popular software, e.g. xmonad, git-annex, pandoc or various web framework implementations. All of these updates will be available as part of the upcoming 8.4-RELEASE. We also came to know that Haskell ports are also being used successfully on DragonFlyBSD's dports tree. In our development repository, there was some optional support added for LLVM-based code generation using the GHC LLVM backend. This works mostly on FreeBSD too, though some of the ports would need fixing so it is still considered experimental. Open tasks: 1. Try to build GHC with clang (as system compiler). 2. Commit pending Haskell ports to the FreeBSD ports tree. 3. Add more ports to the Ports Collection. __________________________________________________________________ FreeBSD on Cubieboard Contact: Ganbold Tsagaankhuu Contact: Oleksandr Tymoshenko Initial support of Allwinner A10 SoC is committed to -CURRENT. FreeBSD is now running on boards such as Cubieboard, Hackberry and it supports following peripherals: * USB EHCI * GPIO Open tasks: 1. Get EMAC Ethernet driver working. Need more help from network driver experts. 2. Implement more drivers. __________________________________________________________________ FreeBSD Port Managers URL: http://www.FreeBSD.org/ports/ URL: http://www.freebsd.org/doc/en/articles/contributing-ports/ URL: http://portsmon.freebsd.org/ URL: http://www.freebsd.org/portmgr/ URL: http://blogs.freebsdish.org/portmgr/ URL: http://www.twitter.com/freebsd_portmgr/ URL: http://www.facebook.com/portmgr Contact: Thomas Abthorpe Contact: Port Management Team The ports tree contains approximately 24,300 ports, while the PR count still is close to 1600. In the first quarter we added 4 new committers, took in 1 commit bit for safe keeping, and re-instated 1 commit bit. In February, Mark Linimon (linimon) stepped down from his duties in the team. Mark had been the longest serving member of the team. Mark had spent many long hours refactoring and documenting the portbuild software to ensure that pointyhat services could be restored. After a security review, redports.org was turned back on, restoring Tinderbox services to contributors, along with post commit QATs. In addition, pointyhat infrastructure had also undergone a review and work begain on restoring the package build system. Erwin Lansing (erwin) and Martin Wilke (miwi) took on the principle roles of getting the portbuild software installed and running on pointyhat. As a result of all their hard work, portmgr@ was finally able to resume doing -exp runs, preparing packages for the upcoming 8.4 release, as well as getting a set of 9.1 packages retroactively prepared. After many long years of being the defacto standard for the Project, CVS support for the ports tree officially ended on February 28. The ports tree was tagged with RELEASE_7_EOL, to coincide with the end of life for FreeBSD 7.X. Beat Gaetzi (beat) stepped down from his duties on portmgr@ in March. Among his notable contributions, was the task of migrating the Ports Tree from the old CVS repo to Subversion. Bryan Drewery (bdrewery) joined the Ports Management team in March, bringing with him his wealth of knowledge and skill from maintaining portupgrade, portmaster, assisting with pkgng, as well as co-developing poudriere. Open tasks: 1. Most ports PRs are assigned, we now need to focus on testing, committing and closing. __________________________________________________________________ FreeBSD Postmaster Team Contact: David Wolfskill In the first quarter of 2013, the FreeBSD Postmaster Team has implemented the following items that may be interest of the general public: * Changes in configuration of Mailman-managed lists: allow to accept the application/pkcs7-signature MIME type (in addition to the application/x-pkcs7-signature MIME type), thus permitting S/MIME signatures on list mail. * New lists: freebsd-ops-announce -- announcements of infrastructure issues, and freebsd-pkg -- discussion of binary package management and package tools. __________________________________________________________________ FreeBSD Release Engineering Team URL: http://www.freebsd.org/releases/8.4R/schedule.html Contact: FreeBSD Release Engineering Team FreeBSD 8.4-RC1 just got out the door and we are planning RC2. A couple of critical fixes have come in that will be included in RC2. The schedule has slipped about 10 days so far. We are expecting the final release by the end of April. Packages for 8.4 have been provided by a fully operational package building cluster. __________________________________________________________________ FreeBSD/arm Superpages for ARMv7 URL: http://static.usenix.org/events/osdi02/tech/full_papers/navarro/nav= arro.pdf URL: https://wiki.freebsd.org/ARMSuperpages URL: https://github.com/semihalf-bodek-zbigniew/freebsd-arm-superpages.g= it Contact: Zbigniew Bodek Contact: Grzegorz Bernacki Contact: Rafa=C5=82 Jaworowski ARM architecture is more and more prevailing, not only in the mobile and embedded space. Among the more interesting industry trends emerging in the recent months has been the "ARM server" concept. Some top-tier companies started developing systems like this already (Dell, HP). Key to FreeBSD success in these new areas are sophisticated features, among them are superpages. The objective of this project is to provide FreeBSD/arm with the superpages support, which will allow for efficient use of TLB translations (enlarge TLB coverage), leading to improved performance in many applications and scalability. Indicated functionality is intended to work on ARMv7-based processors, however compatibility with ARMv6 will be preserved. Current support status: * Port of the pv_entry allocator. * Switch to "AP[2:1]" access permissions model. * PTE-based, page-referenced/modified emulation. * Fixes regarding page replacement strategy. * Code optimizations and bug fixes. Next steps: * Dirty pages management. * Gradual integration to FreeBSD -CURRENT. * Further pmap optimizations. * Fragmentation control management. * Testing and benchmarking. Open tasks: 1. Support for multiple page sizes. 2. Implementation of page promotion, demotion and eviction mechanisms. __________________________________________________________________ FreeBSD/ARM Toolchain Improvements Contact: Andrew Turner Clang has been made the default compiler on ARM. A number of issues with LLVM and clang have been found, reported, and fixed upstream. An issue where some ARM EABI applications compiled with clang crash has been reported upstream with a patch and will be brought into the FreeBSD tree when it is accepted. The only other issue blocking moving to the ARM EABI is C++ exceptions fail to work correctly with shared objects. This will need us to either import libunwind or implement the functions libgcc_s requires to find the correct unwind table. Open tasks: 1. Fix exception handling for EABI. __________________________________________________________________ FreeNAS URL: http://www.FreeNAS.org/ Contact: Alfred Perlstein Contact: Josh Paetzel FreeNAS 8.3.1-RELEASE-p2 will hit Sourceforge the second week of April, and should end up as the last FreeNAS release based on FreeBSD 8.X It's currently the only Free Open Source NAS product available with any form of ZFS encryption (provided by GELI). Open tasks: 1. The team is hard at work on getting a FreeBSD 9.X-based release of FreeNAS ready. Currently there are several nightly snapshots available. 2. Add HAST to the webinterface. 3. Migrate to NFSv4. 4. Integrate foundation sponsored kernel iSCSI target. __________________________________________________________________ GNOME/FreeBSD URL: http://www.freebsd.org/gnome URL: http://www.freebsd.org/gnome/docs/develfaq.html URL: http://www.marcuscom.com:8080/viewvc/viewvc.cgi/marcuscom URL: https://github.com/jlmess77/mate-ports Contact: FreeBSD GNOME team The GNOME/FreeBSD Team has recently merged Glib 2.34, Gtk+ 2.24.17 and Gtk+ 3.6.4 into ports, the C++ bindings also have got updates. In additional "low-level" GNOME ports received updates, like libsoup, gobject-introspection, atk and vala for example. The telepathy stack and empathy where also updated. The USE_GNOME macro has received support for :run and :build targets thanks to Jeremy Messenger (mezz). Currently only libxml2 and libxslt support these targets. USE_GNOME=3Dpkgconfig is being deprecated in favor of USE_PKGCONFIG=3Dbuild. The former also adds a run dependency on pkg-config, which is not required. A first pass was done to get rid of this in the Glib update to 2.34. In cooperation with the X11 Team, the usage of USE_GNOME=3Dpkgconfig in X components will be removed. After the fallout from this is handled and stranglers are converted, the USE_GNOME option will be removed. In addition USE_GNOME=3Dgnomehack is deprecated and should not be used. Please replace it with USES=3Dpathfix. The GNOME development repository has switched from CVS to SVN. CVS will not get any more updates. Uses can get a new version of the marcusmerge script that supports SVN from its home page, and should remove the old CVS checkout "ports" dir. * SVN anonymous root: svn://creme-brulee.marcuscom.com/ or svn://sushi.marcuscom.com/ (IPv6) * ViewVC: http://www.marcuscom.com:8080/viewvc/viewvc.cgi/marcuscom On-going efforts: * glib 2.36, pango 1.34.0, gtk 3.8.0 and gobject-introspection 1.36.0 where updated in the GNOME development repository. * Gustau Perez i Querol stepped up and started work on updating the old GNOME 3.4 ports to 3.6. At the moment of writing these are not available in the GNOME development repository just yet. For his efforts, he was awarded a FreeBSD GNOME team membership. * Jeremy Messenger (mezz) has completed Mate 1.6 which will be arriving in ports near you when deemed stable enough. If you want to help with keeping the documentation updated or helping out in other ways, even if it only parts for the Glib/Gtk/GNOME stack you are interested in, please contact us! Open tasks: 1. Update the FreeBSD.org/gnome website, in particular the developer information about USE_GNOME, maybe put that section in the Porter's Handbook instead. 2. Merge more updated ports from MC to ports. 3. Testing latest Glib/Gtk releases with existing ports, and import it into ports when it is ready. 4. After porting GNOME 3.6 run tests and fix bugs. __________________________________________________________________ Improving the Documentation Project Infrastructre URL: http://svnweb.freebsd.org/doc/projects/xml-tools/ Contact: G=C3=A1bor K=C3=B6vesd=C3=A1n There is an on-going work to improve the documentation infrastructure and modernize our documentation toolchain. The work can be found in the xml-tools branch and is very near to completion. The improvements include the following: * Upgrade to DocBook 4.5. * Use XSLT instead of DSSSL to render XHTML-based output. * Generate PDF from PS and simplify image processing. * Fix make lint and validate the whole documentation set. * Fix rendering of TOC elements. * Fix misused link elements that resulted in a corrupt rendering. * Use more human-friendly publication data and release info rendering. * Add support for XInclude in DocBook documents. * Add support for profiling with attributes. * Add support for Schematron constraints. * Add experimental epub support. * Add experimental support for XSL-FO-based printed output. * Clean up obsolete SGML constructs. * Clean up catalogs. * Drop HTML Tidy since it is not needed any more. The changes eliminate some dependencies and switch the doc repository to a real XML toolchain with proper validation and more advanced rendering tools. The only exceptions are Jade and the DSSSL stylesheets, which are still needed for printed output. Open tasks: 1. Fix rendering problems with images in printed formats. 2. Update the Documentation Primer to reflect changes. __________________________________________________________________ KDE/FreeBSD URL: http://FreeBSD.kde.org URL: http://FreeBSD.kde.org/area51.php Contact: KDE FreeBSD The KDE/FreeBSD Team is very proud to have Schaich Alonso (aschai) joining the team. Welcome! The KDE/FreeBSD Team have continued to improve the experience of KDE software and Qt under FreeBSD. The latest round of improvements include: * Fix problems establishing UDP connections. The Team have also made many releases and upstreamed many fixes and patches. The latest round of releases include: * KDE SC: 4.9.5, 4.10.1 (ports) * Qt: 5.0.0 (area51) and 4.8.4 (ports) * PyQt: 4.9.6 (ports); QScintilla 2.7 (ports); SIP: 4.14.2 (area51) and 4.14.3 (ports) * KDevelop: 4.4.1 (ports); KDevPlatform: 1.4.1 (ports) * Calligra: 2.5.5, 2.6.2 (ports) * Amarok: 2.7.0 * CMake: 2.8.10.2 * Digikam (and KIPI-plugins): 3.1.0 (area51) * QtCreator: 4.6.1 (ports) * KDE Telepathy 0.6.0 (area51) * many smaller ports As a result -- according to PortScout -- we have 431 ports, of which 93.5% (from 91%) are up-to-date. The Team are always looking for more testers and porters so please contact us and visit our home page. Open tasks: 1. Updating out-of-date ports, see PortScout for a list. __________________________________________________________________ Kernel Information in Process Core Dumps Contact: Mikolaj Golub When doing postmortem analysis of a crashed process it is sometimes very useful to have kernel information about the process at the moment of the crash, like open file descriptors or resource limits. For a live process this information can be obtained via sysctl(3) interface e.g. using procstat(1). The aim of the project is to add additional notes to a process core dump, which include process information from the kernel at the moment of the process crash, teach libprocstat(3) to extract this information and make procstat(1) use this functionality. At the moment all necessary code changes are committed to HEAD and are going to be merge to stable/9 in 1 month. __________________________________________________________________ mdoc.su -- Short Manual Page URLs URL: http://mdoc.su/ URL: http://nginx.conf.mdoc.su/mdoc.su.nginx.conf URL: https://github.com/cnst/mdoc.su URL: http://lists.freebsd.org/pipermail/freebsd-doc/2013-February/021465= .html Contact: Constantine A. Murenin mdoc.su is a deterministic URL shortener for BSD manual pages, written entirely in nginx.conf. Since the original announcement, OS version support has been added (e.g. /f91/ and /FreeBSD-9.1/ etc.), as well as dynamic multi-flavour web-pages with multiple links (e.g. http://mdoc.su/f,d/ifnet.9 and http://mdoc.su/-/mdoc), which even let you specify the versions too (e.g. http://mdoc.su/f91,n60,o52,d/mdoc). The source code for the whole site is available under a BSD licence. Open tasks: 1. Fork it on GitHub (see links)! __________________________________________________________________ Multipath TCP (MPTCP) for FreeBSD URL: http://caia.swin.edu.au/urp/newtcp/mptcp/tools.html URL: http://caia.swin.edu.au/newtcp/mptcp/ URL: http://caia.swin.edu.au/reports/130424A/CAIA-TR-130424A.pdf URL: https://pub.allbsd.org/FreeBSD-snapshots/ Contact: Nigel Williams Contact: Lawrence Stewart Contact: Grenville Armitage We have been working to create a BSD-licensed implementation of Multipath TCP -- a set of TCP extensions that allow for transparent multipath operation with multiple IP addresses as specified in experimental RFC6824. We made our first v0.1 public release on 2013-03-11 and recently released v0.3 on 2013-04-16. The code is currently considered to be of alpha quality. We are working towards pushing the code into a FreeBSD Subversion repository project branch to continue the on-going development effort in a more publicly accessible location. As part of this move, we hope to begin releasing regular snapshot installer ISOs of the MPTCP project branch courtesy of Hiroki Sato and the allbsd.org daily snapshot infrastructure. We are about to release a CAIA technical report 130424A entitled "Design Overview of Multipath TCP version 0.3 for FreeBSD 10" on 2013-04-24 which provides a high-level design and architecture overview of the v0.3 code release. Going forward, we expect to continue development and release additional technical reports and academic papers covering topics such as performance analysis and multipath congestion control/scheduling. Open tasks: 1. The code is currently of alpha quality so we welcome all testing feedback, but please familiarize yourself with the README file and "Known Limitations" section in particular before jumping in. __________________________________________________________________ Native iSCSI Stack URL: https://wiki.freebsd.org/Native%20iSCSI%20target Contact: Edward Tomasz Napieral/a Focus of the project was extended to also include a new iSCSI initiator. Compared to the old one, it is more reliable, much more user-friendly, and somewhat faster. It uses exactly the same configuration file format as the old one to make migration easier. As for the target side, it was verified to work properly against major initiators (FreeBSD, Linux, Solaris, Windows and VMWare ESX). This project is being sponsored by FreeBSD Foundation. Open tasks: 1. RDMA support, for both the target and the initiator. 2. Performance optimization. __________________________________________________________________ PyPy URL: http://wiki.FreeBSD.org/PyPy Contact: David Naylor PyPy has been successfully updated to 2.0-beta1 with 2.0-beta2 finishing translating and other tests. Many major changes were made to the PyPy port fr the 2.0-beta1 release, these include: * Reworking the build script. * Optionally use pypy (when available) for self-translating. * Refine memory checks. * Fix the test target. Although the port is in a healthy state; PyPy on FreeBSD has some rough edges (see make test for examples of roughness). Open tasks: 1. Fix failed unit tests. 2. Integrate PyPy into bsd.python.mk. 3. See the project page for more items. __________________________________________________________________ racct: Block IO Accounting URL: https://wiki.freebsd.org/RudolfTomori/IOLimits Contact: Rudolf Tomori This project adds the block IO access accounting to the racct/rctl resource limiting framework, a working prototype implementation is available. __________________________________________________________________ Read-only Port of NetBSD's UDF File System URL: https://github.com/williamdevries/UDF Contact: Will DeVries An initial read-only port of NetBSD's UDF file system has been largely completed. (The UDF file system is often used on CD, DVD and Blu-Ray discs.) This port provides a number of advantages over FreeBSD's current UDF implementation, which include: * Support for version 2.60 of the UDF file system specification. FreeBSD's current implementation only partially supports version 1.5 of the standard, which was released in 1997. Since Windows and other systems support newer version of this file system, our users are left without the ability to read some media written by these systems. In addition, Blu-Ray discs are commonly written using version 2.50 or 2.60. * The ability to override the owner and group for all the files and directories on a UDF volume using mount options. * The ability to set the owner and group for files and directories that lack defined owner or group information using mount options. (The UDF specification allows for files and directories without owners or groups.) * The ability to override the mode for all directories and files on a volume using mount options. * Support for mounting previous versions of incrementally recorded media, like CD-Rs. __________________________________________________________________ TCP-AO Authentication Option URL: http://svnweb.freebsd.org/base/user/andre/tcp-ao/ Contact: Andr=C3=A9 Oppermann Work is under way to implement TCP-AO (TCP Authentication Option) according to RFC5925 and RFC5926. TCP-AO is an extension to TCP-MD5 signatures commonly used in routers to secure BGP routing protocol sessions against spoofing attacks. The work is under contract and sponsored by Juniper Networks. __________________________________________________________________ The entities Documentation Branch URL: http://svnweb.freebsd.org/doc/projects/entities/ Contact: Ren=C3=A9 Ladan The entities branch was created to reduce duplication of committer entities. Currently there is one in authors.ent (with email addresses) and another one in developers.ent (without email addresses). This seems to be a leftover from the doc/www split in earlier times. To remedy this, developers.ent is merged into authors.ent and entities with email addresses are postfixed as such. Apart from the instructions for the initial commit, there should be little user-visible changes. Some related cleanups, like cleaning up team definitions, replacing literal names by entities from authors.ent, and adding missing names to authors.ent are also made. Open tasks: 1. Finish processing of the tag. 2. Send out a CFT. 3. Merge back into head branch. __________________________________________________________________ The FreeBSD Japanese Documentation Project URL: http://www.FreeBSD.org/ja/ URL: http://www.jp.FreeBSD.org/doc-jp/ Contact: Hiroki Sato Contact: Ryusuke Suzuki Web page (htdocs): Newsflash and some other updates in the English version have been translated to keep them up-to-date. Specifically, the release related contents were updated in this period. Books: FreeBSD Handbook has constantly been updated since the last report; particularly, "ports", "desktop" section were largely updated. Some progress has been made in the "advanced-networking" section, contributed by a new translator. "Writing FreeBSD Problem Reports" article is now in sync with the English version. Open tasks: 1. Further translation work of outdated documents in ja_JP.eucJP subtree. __________________________________________________________________ UFS/FFS Performance Work URL: http://www.mckusick.com/publications/faster_fsck.pdf Contact: Kirk McKusick Some work on the performance of UFS/FFS has been recently committed to HEAD. The purpose of the corresponding change to the FFS layout policy is to reduce the running time for a full file system check. It also reduces the random access time for large files and speeds up the traversal time for directory tree walks. The key idea is to reserve a small area in each cylinder group immediately following the inode blocks for the use of metadata, specifically indirect blocks and directory contents. The new policy is to preferentially place metadata in the metadata area and everything else in the blocks that follow the metadata area. The size of this area can be set when creating a filesystem using newfs(8) or changed in an existing filesystem using tunefs(8). Both utilities use the -k held-for-metadata-blocks option to specify the amount of space to be held for metadata blocks in each cylinder group. By default, newfs(8) sets this area to half of minfree (typically 4% of the data area). As with all layout policies, it only affect layouts of things allocated after it is put in place. So these changes will primarily be noticable on newly created file systems. File system checks have been sped up by caching the cylinder group maps in pass1 so that they do not need to be read again in pass5. As this nearly doubles the memory requirement for fsck(8), the cache is thrown away if other memory needs in fsck(8) would otherwise fail. Thus, the memory footprint of fsck(8) remains unchanged in memory constrained environments. This optimization will be evident on all UFS/FFS filesystems. This work was inspired by a paper presented at Usenix's FAST '13. Open tasks: 1. MFC to 9-STABLE and possibly 8-STABLE should happen by May unless problems arise with these changes in HEAD. __________________________________________________________________ Wine32 on FreeBSD/amd64 URL: http://wiki.freebsd.org/i386-Wine Contact: David Naylor The i386-wine port (formally wine-fbsd64) has been added to the ports collection (as emulators/i386-wine-devel). Although the port can only be compiled under a x86 32-bit system the resulting package can be installed on a x86 64-bit system and enable running of 32-bit Microsoft Windows programs. Packages for the port are in development and should be announced shortly on the freebsd-questions and freebsd-emulation mailing lists. There are some issues with Wine32 on FreeBSD/amd64 -- possibly related to FreeBSD32_COMPACT, or other general 32/64-bit issues -- that could do with some focus. Open tasks: 1. Port wine64 to FreeBSD. 2. Port WoW64 (wine32 and wine64 together) to FreeBSD. 3. Fix 32- and 64-bit issues (such as Intel graphics not accelerating). __________________________________________________________________ Xfce/FreeBSD URL: https://wiki.FreeBSD.org/Xfce URL: http://people.freebsd.org/~olivierd/patches/midori-0.4.9_0.5.0.diff Contact: FreeBSD Xfce Team The Xfce FreeBSD Team has updated many ports, especially: * tumbler: 0.1.27 (add new option, COVER) * Parole: 0.5.0 * xfdesktop: 4.10.2 * Midori: 0.4.9 (full compatible with Vala 0.18), 0.5.0 is available (see links) * Orage: 4.8.4 * xfce4-terminal: 0.6.1 (renamed by upstream, previous name was Terminal) This last application contains drop-down functionality, new window slides down from the top of the screen when key (we can define keyboard shortcut) is pressed. Open tasks: 1. Replace libxfce4gui (deprecated and not maintained by upstream) by libxfce4ui in order to enhance support panel plugins for Xfce >=3D 4.10. 2. Work on Midori Gtk3 port. 3. Fix gtk-xfce-engine with Gtk+ >=3D3.6. __________________________________________________________________ xorg on FreeBSD URL: http://wiki.freebsd.org/Xorg URL: http://people.freebsd.org/~zeising/xorg-7.7.diff URL: http://trillian.chruetertee.ch/ports/browser/trunk URL: http://trillian.chruetertee.ch/ports/browser/branches/xorg-7.7 Contact: FreeBSD X11 Team Contact: Niclas Zeising Contact: Koop Mast Most of the work during this period has been in updating, testing and stabilizing the development repository. A number of xorg applications and various other leaf ports has been committed as part of this effort. After this a CFT was sent out asking for help in testing the remaining bits in development, including updates to all major libraries and xorg-server. Currently, the CFT patch has been submitted for an exp-run to iron out any final bugs. The plan is to merge it sometime after FreeBSD 8.4 is released and the ports tree is reopened for commits. Work is also on-going to port new versions of MESA and OpenGL, as well as a new version of xorg-server, and perhaps in the future, Wayland. These are considered more long-term goals and are not targeted for the current update. Open tasks: 1. Decide how to handle the new and old xorg distributions. In recent xorg, a lot of legacy driver support has been dropped, therefore we need to maintain two xorg distributions to not lose a lot of hardware drivers. Currently, this is done by setting the flag WITH_NEW_XORG in /etc/make.conf, but a more practical solution is needed. This is especially important since the flag is not very user-friendly, and since there currently will be no official packages for the new distribution. 2. Continue to test and update xorg related ports. There are new versions of xserver, as well as MESA and related OpenGL libraries which needs to be ported and eventually integrated into the ports tree. 3. Port Wayland. The future of graphical environments in open source operating systems seems to be Wayland. This needs to be ported to FreeBSD so that a wider audience can test it, and so that it eventually can be integrated into the ports tree, perhaps as a replacement for the current xorg. 4. Look into replacements for HAL. HAL is used for hot-plugging of devices, but it has been long abandoned by Linux. A replacement, perhaps build on top of devd would be nice to have. This work should be coordinated with the FreeBSD GNOME and KDE teams. __________________________________________________________________ From owner-freebsd-stable@FreeBSD.ORG Sun May 12 18:56:54 2013 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id DF566554; Sun, 12 May 2013 18:56:54 +0000 (UTC) (envelope-from outbackdingo@gmail.com) Received: from mail-ob0-x22e.google.com (mail-ob0-x22e.google.com [IPv6:2607:f8b0:4003:c01::22e]) by mx1.freebsd.org (Postfix) with ESMTP id 89F9C98F; Sun, 12 May 2013 18:56:54 +0000 (UTC) Received: by mail-ob0-f174.google.com with SMTP id un3so794108obb.5 for ; Sun, 12 May 2013 11:56:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=AlYy3tO43JYaan/9H2V4y2UM9PgQQ+RI/HNMFRv1Go0=; b=WP2COk1Zx6lNZYtI2e939viqdSZtgbJGDEKEAUjq9gQUBQ49d+I0U2fjmu56Z3D9sJ Tm61zTOPhZWvP0C1SPLfme42w/HKcYOumdGOcjK2hqyT22/pxH1++O55pKRaE+kCPwiU 8m28TmVJn7+gMTmGlCWu2rqidquFSPpCdTX7XhCzwJvelAywZjw7BHTjoUMqypgfd91p 3cVz0nZTjheVPz6DxzDmm6aqAGHEiAoJpgNkIfz6PJXoz8hG/xATvL1RgAzSFCrnGD79 Wgv8KBe1OD4KRZWrg5vz+G1Fmls2ivlPdfaKRncj9I5BsF3FIJEJOevetyZdwtDLtkDc /Owg== MIME-Version: 1.0 X-Received: by 10.60.56.132 with SMTP id a4mr2534426oeq.113.1368385013793; Sun, 12 May 2013 11:56:53 -0700 (PDT) Received: by 10.76.96.49 with HTTP; Sun, 12 May 2013 11:56:53 -0700 (PDT) In-Reply-To: <20130512195405.04653b64@funktor> References: <20130512195405.04653b64@funktor> Date: Sun, 12 May 2013 14:56:53 -0400 Message-ID: Subject: Re: FreeBSD Quarterly Status Report, January-March 2013 From: Outback Dingo To: Gabor Pali Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: stable@freebsd.org, hackers@freebsd.org, current@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 12 May 2013 18:56:55 -0000 __________________________________________________________________ > > FreeNAS > > URL: http://www.FreeNAS.org/ > > Contact: Alfred Perlstein > Contact: Josh Paetzel > > FreeNAS 8.3.1-RELEASE-p2 will hit Sourceforge the second week of April, > and should end up as the last FreeNAS release based on FreeBSD 8.X It's > currently the only Free Open Source NAS product available with any form > of ZFS encryption (provided by GELI). > > Open tasks: > > 1. The team is hard at work on getting a FreeBSD 9.X-based release of > FreeNAS ready. Currently there are several nightly snapshots > available. > 2. Add HAST to the webinterface. > 3. Migrate to NFSv4. > 4. Integrate foundation sponsored kernel iSCSI target. > Uhmmmmmm WHAT??? FreeNAS is not the only Free Open Source NAS product available with any form of ZFS encryption (provided by GELI). NAS4Free has been doing it. From owner-freebsd-stable@FreeBSD.ORG Sun May 12 20:50:48 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id A53A6CD for ; Sun, 12 May 2013 20:50:48 +0000 (UTC) (envelope-from cross+freebsd@distal.com) Received: from mail.distal.com (mail.distal.com [IPv6:2001:470:e24c:200::ae25]) by mx1.freebsd.org (Postfix) with ESMTP id 7C8C4E27 for ; Sun, 12 May 2013 20:50:48 +0000 (UTC) Received: from magrathea.distal.com (magrathea.distal.com [IPv6:2001:470:e24c:200:ea06:88ff:feca:960e]) (authenticated bits=0) by mail.distal.com (8.14.3/8.14.3) with ESMTP id r4CKokqJ010390 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Sun, 12 May 2013 16:50:47 -0400 (EDT) From: Chris Ross Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Subject: Reinstalling boot blocks on a ZFS-only system Message-Id: Date: Sun, 12 May 2013 16:50:46 -0400 To: "freebsd-stable@freebsd.org" Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) X-Mailer: Apple Mail (2.1503) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.2 (mail.distal.com [IPv6:2001:470:e24c:200::ae25]); Sun, 12 May 2013 16:50:47 -0400 (EDT) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 12 May 2013 20:50:48 -0000 So, I've long known and it makes sense that when you're booted from a = ZFS volume, you can't mess with the boot-loader. And, I know a few = months ago I had a set of commands I would use when booted from a CD = that would initialize the network and copy the "release/boot" from = somewhere else so that I could install bootblocks and boot-loaders from = more recent code. Sadly, I didn't _record_ those commands I was using. What do "people in the know" do when they want to update the = bootblocks of a ZFS-boot system? Or, have too few people followed this = path so far that they can boot UFS and do it with less difficulty? Thanks. Happy for any information. - Chris From owner-freebsd-stable@FreeBSD.ORG Sun May 12 20:58:39 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 463363C5 for ; Sun, 12 May 2013 20:58:39 +0000 (UTC) (envelope-from jdc@koitsu.org) Received: from qmta03.emeryville.ca.mail.comcast.net (qmta03.emeryville.ca.mail.comcast.net [IPv6:2001:558:fe2d:43:76:96:30:32]) by mx1.freebsd.org (Postfix) with ESMTP id 182A1E91 for ; Sun, 12 May 2013 20:58:39 +0000 (UTC) Received: from omta07.emeryville.ca.mail.comcast.net ([76.96.30.59]) by qmta03.emeryville.ca.mail.comcast.net with comcast id b8q51l0031GXsucA38yeAL; Sun, 12 May 2013 20:58:38 +0000 Received: from koitsu.strangled.net ([67.180.84.87]) by omta07.emeryville.ca.mail.comcast.net with comcast id b8yd1l00Z1t3BNj8U8yesx; Sun, 12 May 2013 20:58:38 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id A73EB73A33; Sun, 12 May 2013 13:58:37 -0700 (PDT) Date: Sun, 12 May 2013 13:58:37 -0700 From: Jeremy Chadwick To: Chris Ross Subject: Re: Reinstalling boot blocks on a ZFS-only system Message-ID: <20130512205837.GA69605@icarus.home.lan> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1368392318; bh=MJiOrHDkYDNOtV65PuBN66ThEC1AcewHvriyC/m6z6Y=; h=Received:Received:Received:Date:From:To:Subject:Message-ID: MIME-Version:Content-Type; b=FBXmEZW6d9sSwsYv1qQcVeDcvYBVdMltXa26PXaYOCajUbLqFQd/sSL9v6mqfWIFq 1118uX9G2D33Zq9hVlpMLSVlSE23TRoWruI5ScFIXiEQxsg2qF99gRbEp4Hfm4MgY+ LN/uGJI06adQYM1P+wYX7exWj+hR9/1IrJ2WlCBRgpRIvFQWClGE1UNWBNnLaQgJ49 nx00FNLAc4802w16wO2BmNNdeWBWcJuXMRQbEwS1DvtzWbky/mtnpOLmYsvFQrNdLq +AAMjZ1tljQvnCpBY+4aigOsz7Qw2UHeFDewWrKFaNmudvs77KOuB1rVQ0+Bny9o4L 7OtbbJuGx1UzQ== Cc: "freebsd-stable@freebsd.org" X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 12 May 2013 20:58:39 -0000 On Sun, May 12, 2013 at 04:50:46PM -0400, Chris Ross wrote: > > So, I've long known and it makes sense that when you're booted from a ZFS volume, you can't mess with the boot-loader. And, I know a few months ago I had a set of commands I would use when booted from a CD that would initialize the network and copy the "release/boot" from somewhere else so that I could install bootblocks and boot-loaders from more recent code. Sadly, I didn't _record_ those commands I was using. > > What do "people in the know" do when they want to update the bootblocks of a ZFS-boot system? Or, have too few people followed this path so far that they can boot UFS and do it with less difficulty? The command is "gpart bootcode", however I cannot be bothered to remember the syntax; I imagine it greatly depends on if you're using GPT vs. MBR, in addition to what your partition layout look like. Meaning: there is no "universal standard", it depends entirely on how you set your stuff up. But the command is definitely "gpart bootcode". Next, AFAIK there is no need to boot alternate media (CD etc.) to accomplish this. You may also need to set kern.geom.debugflags=0x10 to inhibit GEOM's "safety measure" / to permit writing to LBA 0; see GEOM(4) and search for the word "foot". -- | Jeremy Chadwick jdc@koitsu.org | | UNIX Systems Administrator http://jdc.koitsu.org/ | | Mountain View, CA, US | | Making life hard for others since 1977. PGP 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Sun May 12 21:54:50 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id AF203F4 for ; Sun, 12 May 2013 21:54:50 +0000 (UTC) (envelope-from marek_sal@wp.pl) Received: from mx3.wp.pl (mx3.wp.pl [212.77.101.7]) by mx1.freebsd.org (Postfix) with ESMTP id 3803E18A for ; Sun, 12 May 2013 21:54:49 +0000 (UTC) Received: (wp-smtpd smtp.wp.pl 19323 invoked from network); 12 May 2013 23:54:47 +0200 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=wp.pl; s=1024a; t=1368395687; bh=zgEzDvIwQ0JYE9OfBEgtz9TnuUN9fwjcPFjBs0ooreA=; h=From:To:CC:Subject; b=jB/BUhombh4pX8hrwJpZ5PmdS27h53A3aLInhWLRmdBH5WrYJ3JG5jwbTY/KPbn85 vFVHKYPc/O4J+5RqhBgrwoKOMKH1ajgC9mraKuBLxL6xStddVXjExFU4TDMnV7EjTu OaQ/bgrf8kBcAn1hsx2acti/Y+YnyQ+6IqUAXbSQ= Received: from nat.misal.pl (HELO [127.0.0.1]) (marek_sal@[83.19.131.171]) (envelope-sender ) by smtp.wp.pl (WP-SMTPD) with AES256-SHA encrypted SMTP for ; 12 May 2013 23:54:47 +0200 Message-ID: <51900FA5.20204@wp.pl> Date: Sun, 12 May 2013 23:54:45 +0200 From: Marek Salwerowicz User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: "illoai@gmail.com" Subject: Re: Build GENERIC with IPX support References: <518ED0CA.4030007@wp.pl> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 130512-0, 2013-05-12), Outbound message X-Antivirus-Status: Clean X-WP-AV: skaner antywirusowy poczty Wirtualnej Polski S. A. X-WP-SPAM: NO 0000000 [UcNk] Cc: "freebsd-stable@freebsd.org" X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 12 May 2013 21:54:50 -0000 W dniu 2013-05-12 04:27, illoai@gmail.com pisze: > I think you also have to have > options LIBMCHAIN That helped, thanks! anyway, despite using ef(4) module, configuring IPX net number, I am unable to list my NetWare servers: # ncplogin Segmentation fault (core dumped) # I'm not sure whether IPX is still supported in FreeBSD? -- Marek Salwerowicz From owner-freebsd-stable@FreeBSD.ORG Sun May 12 22:45:14 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 19208CCB for ; Sun, 12 May 2013 22:45:14 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-wg0-x22f.google.com (mail-wg0-x22f.google.com [IPv6:2a00:1450:400c:c00::22f]) by mx1.freebsd.org (Postfix) with ESMTP id A8E14336 for ; Sun, 12 May 2013 22:45:13 +0000 (UTC) Received: by mail-wg0-f47.google.com with SMTP id e11so5840320wgh.14 for ; Sun, 12 May 2013 15:45:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=ZR8UBd63kJHwvWrHGsHk3eKR+qdWzIaux7sJZY8uexE=; b=q67gIHJYRwxLscBitbdM0DbUygmV68HwInOFecGzhHvCV+zzldHPNKv+JSkPIE8nEK cAFRrOIy6qTzxNut28pQyX9VBWLli4ZxDpk29CY2PvH6LJGYzxNMtjKastEpZnlEgqP3 WvIKLYRZ0UBhzrCuTXcg+4k/0XSE+4UPVUwYQEJl+vYe9YboudEEMEfNs2R0Rm5Ws+Ev bzTw/GsZ48UQqdnUUNJmdkMAHwH7z9sY2ksOhH0a13BcxqRQSy56lUR101aLS1Fw/rxF 43crq2Jbvq9lz796gsBIwJAOZUFVcqCf7VaF93M7b2BsuXt3USK4efIwtcYi9aQ00s+v trOA== MIME-Version: 1.0 X-Received: by 10.194.93.133 with SMTP id cu5mr36178021wjb.56.1368398712898; Sun, 12 May 2013 15:45:12 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.217.58.138 with HTTP; Sun, 12 May 2013 15:45:12 -0700 (PDT) In-Reply-To: <51900FA5.20204@wp.pl> References: <518ED0CA.4030007@wp.pl> <51900FA5.20204@wp.pl> Date: Sun, 12 May 2013 15:45:12 -0700 X-Google-Sender-Auth: XdLhQwfaRAv4JPT1TWhgsWdNtz0 Message-ID: Subject: Re: Build GENERIC with IPX support From: Adrian Chadd To: Marek Salwerowicz Content-Type: text/plain; charset=ISO-8859-1 Cc: "freebsd-stable@freebsd.org" , "illoai@gmail.com" X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 12 May 2013 22:45:14 -0000 It's supported as long as someone wants to use it and can help in at least diagnosing issues. So, if you have a segfault, run it inside gdb and report where its dying. Chances are things have just bitrotted a bit but not so much that it's worth killing. adrian On 12 May 2013 14:54, Marek Salwerowicz wrote: > W dniu 2013-05-12 04:27, illoai@gmail.com pisze: > >> I think you also have to have >> options LIBMCHAIN > > That helped, thanks! > > anyway, despite using ef(4) module, configuring IPX net number, I am unable > to list my NetWare servers: > > # ncplogin > Segmentation fault (core dumped) > # > > I'm not sure whether IPX is still supported in FreeBSD? > > -- > Marek Salwerowicz > > > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" From owner-freebsd-stable@FreeBSD.ORG Mon May 13 00:09:16 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id C48F0726 for ; Mon, 13 May 2013 00:09:16 +0000 (UTC) (envelope-from ler@lerctr.org) Received: from thebighonker.lerctr.org (lrosenman-1-pt.tunnel.tserv8.dal1.ipv6.he.net [IPv6:2001:470:1f0e:3ad::2]) by mx1.freebsd.org (Postfix) with ESMTP id 96FC580C for ; Mon, 13 May 2013 00:09:16 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lerctr.org; s=lerami; h=Message-ID:References:In-Reply-To:Subject:To:From:Date:Content-Transfer-Encoding:Content-Type:MIME-Version; bh=2xuOo/gQAjp1FTPK/z9oGozEwPw1juY72aEm9O2a36A=; b=ZLhpEIX6RuBdW9DoRuL1F4Ok51dnSiHnIPZnl5OIMTmntNbZlJMEqhrSDlrUJzyXuzcp8I2+9f0yEbF7DufNeYTblfuFiN2Vr0l3THFoeeLchPlzFMIFeLEjZ2xmpnuvfoIAexOJgiZ5c9ADltl/z1y3KULZlzz7VJr3LiZ7M0c=; Received: from localhost.lerctr.org ([127.0.0.1]:47542 helo=webmail.lerctr.org) by thebighonker.lerctr.org with esmtpa (Exim 4.80.1 (FreeBSD)) (envelope-from ) id 1UbgKJ-000K93-Ex for freebsd-stable@freebsd.org; Sun, 12 May 2013 19:09:16 -0500 Received: from cpe-72-182-19-162.austin.res.rr.com ([72.182.19.162]) by webmail.lerctr.org with HTTP (HTTP/1.1 POST); Sun, 12 May 2013 19:09:15 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Date: Sun, 12 May 2013 19:09:15 -0500 From: Larry Rosenman To: freebsd-stable@freebsd.org Subject: Re: Reinstalling boot blocks on a ZFS-only system In-Reply-To: <20130512205837.GA69605@icarus.home.lan> References: <20130512205837.GA69605@icarus.home.lan> Message-ID: X-Sender: ler@lerctr.org User-Agent: Roundcube Webmail/0.9.0 X-Spam-Score: -3.5 (---) X-LERCTR-Spam-Score: -3.5 (---) X-Spam-Report: SpamScore (-3.5/5.0) ALL_TRUSTED=-1, BAYES_00=-1.9, RP_MATCHES_RCVD=-0.628 X-LERCTR-Spam-Report: SpamScore (-3.5/5.0) ALL_TRUSTED=-1, BAYES_00=-1.9, RP_MATCHES_RCVD=-0.628 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 13 May 2013 00:09:16 -0000 On 2013-05-12 15:58, Jeremy Chadwick wrote: > On Sun, May 12, 2013 at 04:50:46PM -0400, Chris Ross wrote: > > So, I've long known and it makes sense that when you're booted from a > ZFS volume, you can't mess with the boot-loader. And, I know a few > months ago I had a set of commands I would use when booted from a CD > that would initialize the network and copy the "release/boot" from > somewhere else so that I could install bootblocks and boot-loaders from > more recent code. Sadly, I didn't _record_ those commands I was using. > > What do "people in the know" do when they want to update the bootblocks > of a ZFS-boot system? Or, have too few people followed this path so > far that they can boot UFS and do it with less difficulty? > > The command is "gpart bootcode", however I cannot be bothered to > remember the syntax; I imagine it greatly depends on if you're using > GPT > vs. MBR, in addition to what your partition layout look like. Meaning: > there is no "universal standard", it depends entirely on how you set > your stuff up. But the command is definitely "gpart bootcode". > > Next, AFAIK there is no need to boot alternate media (CD etc.) to > accomplish this. > > You may also need to set kern.geom.debugflags=0x10 to inhibit GEOM's > "safety measure" / to permit writing to LBA 0; see GEOM(4) and search > for the word "foot". Assuming a freebsd-boot type partition, and GPT type partition scheme, this is what I use on my ZFS boot system: $ cat bin/update_boot.sh #!/bin/sh for i in `seq 0 5` do echo Disk ${i} gpart bootcode -b /boot/pmbr -p /boot/gptzfsboot -i 1 ada${i} done $ -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 214-642-9640 (c) E-Mail: ler@lerctr.org US Mail: 430 Valona Loop, Round Rock, TX 78681-3893 From owner-freebsd-stable@FreeBSD.ORG Mon May 13 01:50:26 2013 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 06D811F9; Mon, 13 May 2013 01:50:26 +0000 (UTC) (envelope-from mikes@siralan.org) Received: from mail.suso.org (mail.suso.org [66.244.94.5]) by mx1.freebsd.org (Postfix) with ESMTP id CA7D9B17; Mon, 13 May 2013 01:50:25 +0000 (UTC) Received: from c-98-223-197-163.hsd1.in.comcast.net (c-98-223-197-163.hsd1.in.comcast.net [98.223.197.163]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.suso.org (Postfix) with ESMTP id 5D3F51381A9; Mon, 13 May 2013 01:50:22 +0000 (GMT) Date: Sun, 12 May 2013 21:50:18 -0400 (EDT) From: "Michael L. Squires" X-X-Sender: mikes@familysquires.net To: Glen Barber Subject: Re: Apparent fxp regression in FreeBSD 8.4-RC3 In-Reply-To: <20130512064503.GA1632@glenbarber.us> Message-ID: References: <20130508174721.GD1651@glenbarber.us> <20130512064503.GA1632@glenbarber.us> 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 Release Engineering Team , freebsd-stable@FreeBSD.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 13 May 2013 01:50:26 -0000 On Sun, 12 May 2013, Glen Barber wrote: > On Sat, May 11, 2013 at 10:57:44PM -0400, Michael L. Squires wrote: >> I upgraded to FreeBSD 8.4-RC3 and noticed a problem with the fxp >> driver on an older Supermicro single CPU single core Xeon >> motherboard. >> >> [...] > >> Copyright (c) 1992-2013 The FreeBSD Project. >> Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 >> The Regents of the University of California. All rights reserved. >> FreeBSD is a registered trademark of The FreeBSD Foundation. >> FreeBSD 8.4-PRERELEASE #45: Fri May 10 09:43:40 EDT 2013 >> root@familysquires.net:/usr/obj/usr/src/sys/NEWGATE i386 > > Your attached dmesg of -RC3 is not -RC3, it is 8-STABLE. At this point, > there have been changes between the stable/8 and releng/8.4 branches > enough say that the two have diverged, and the stable/8 code is _not_ > what will be the 8.4-RELEASE. > > While your issue does concern me, it is still unclear that this is > a problem with the upcoming 8.4-RELEASE. Can you please try upgrading > to the releng/8.4 branch to see if this issue persists? > > Glen > > I installed RELENG_8_4 using cvsup (yes, I'm planning on updating) and got 8.4-BETA; this had the same behavior as 8-STABLE. I tried booting the 8.3-RELEASE p8 kernel and got the same behavior, which makes me wonder if I had made some earlier mistake. I reinstalled 8.3-RELEASE p8 (world and kernel) from source and the system is now operating normally. The differences between the kernel file I'm using and GENERIC are that I have options for "ipfirewall" and the "amd" driver for the AMD 53C974 and do not have devices "esp" nor "isci" (revised amd and iscsi). I'm going to revise my kernel file to be more up-to-date and will test that. I'm not having problems with two other systems, one a Tyan S4882 with 4 single-core Opterons and a Tyan S2882 with two dual-core Opterons. Neither one uses the "fxp" driver; both are operating in x64 mode. Mike Squires mikes@siralan.org UN*X at home since 1986 From owner-freebsd-stable@FreeBSD.ORG Mon May 13 02:12:01 2013 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id E78EE954; Mon, 13 May 2013 02:12:01 +0000 (UTC) (envelope-from gjb@FreeBSD.org) Received: from onyx.glenbarber.us (onyx.glenbarber.us [199.48.134.227]) by mx1.freebsd.org (Postfix) with ESMTP id C64E6D97; Mon, 13 May 2013 02:12:01 +0000 (UTC) Received: from glenbarber.us (70.15.88.86.res-cmts.sewb.ptd.net [70.15.88.86]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) (Authenticated sender: gjb) by onyx.glenbarber.us (Postfix) with ESMTPSA id DF38A23F804; Sun, 12 May 2013 22:11:59 -0400 (EDT) DKIM-Filter: OpenDKIM Filter v2.8.3 onyx.glenbarber.us DF38A23F804 Authentication-Results: onyx.glenbarber.us; dkim=none reason="no signature"; dkim-adsp=none Date: Sun, 12 May 2013 22:11:57 -0400 From: Glen Barber To: "Michael L. Squires" Subject: Re: Apparent fxp regression in FreeBSD 8.4-RC3 Message-ID: <20130513021157.GA1657@glenbarber.us> References: <20130508174721.GD1651@glenbarber.us> <20130512064503.GA1632@glenbarber.us> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="nFreZHaLTZJo0R7j" Content-Disposition: inline In-Reply-To: X-Operating-System: FreeBSD 10.0-CURRENT amd64 User-Agent: Mutt/1.5.21 (2010-09-15) Cc: FreeBSD Release Engineering Team , freebsd-stable@FreeBSD.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 13 May 2013 02:12:02 -0000 --nFreZHaLTZJo0R7j Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, May 12, 2013 at 09:50:18PM -0400, Michael L. Squires wrote: > I installed RELENG_8_4 using cvsup (yes, I'm planning on updating) > and got 8.4-BETA; this had the same behavior as 8-STABLE. >=20 Right. releng/8.4 is not exported to cvsup. Please update your tree with svn or svnup (net/svnup in ports). If 'uname -a' shows -BETA*, that is older than -PRERELEASE. Glen --nFreZHaLTZJo0R7j Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iQEcBAEBCAAGBQJRkEvtAAoJEFJPDDeguUajC70IAICy4cBII6vlOFS068U31ytS BLMG7CuSqynoPWiFMxA9faoRBaBQUD8sc4jd+IW1l1FvS2NTCOoVnguaB+uEDC57 +o/NH0PwGP7/KYTld9h9PkDbi/04UvJ1OFi/2yRwcSgrhQBoQdT3xMW3QFwh9pxM PGguvFIsEPl1UvnHGLt3RhbKqVLl+UJR8CoulsZSQAN5dt5uVjTwh++HbOUKsLoB bRWl5oeVHXybU22XFxATP26Y7F6GQE3nymkL7J/LJ75jNt++xYut1H8ZG/oL0OIS LNsCiKWMRWWvpQJ+HRNUybL9/eKHwNZ+1yZ6ClWI3onHRSBy2KHWBcL9ohJtIgw= =O8rc -----END PGP SIGNATURE----- --nFreZHaLTZJo0R7j-- From owner-freebsd-stable@FreeBSD.ORG Mon May 13 02:20:29 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 04025C4B for ; Mon, 13 May 2013 02:20:29 +0000 (UTC) (envelope-from cross+freebsd@distal.com) Received: from mail.distal.com (mail.distal.com [IPv6:2001:470:e24c:200::ae25]) by mx1.freebsd.org (Postfix) with ESMTP id BBEA6DEA for ; Mon, 13 May 2013 02:20:28 +0000 (UTC) Received: from magrathea.distal.com (magrathea.distal.com [IPv6:2001:470:e24c:200:ea06:88ff:feca:960e]) (authenticated bits=0) by mail.distal.com (8.14.3/8.14.3) with ESMTP id r4D2KQoI010397 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sun, 12 May 2013 22:20:27 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) Subject: Re: Reinstalling boot blocks on a ZFS-only system From: Chris Ross In-Reply-To: <20130512205837.GA69605@icarus.home.lan> Date: Sun, 12 May 2013 22:20:26 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <28B5181C-E185-40E5-90EC-9600297BE590@distal.com> References: <20130512205837.GA69605@icarus.home.lan> To: Jeremy Chadwick X-Mailer: Apple Mail (2.1503) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.2 (mail.distal.com [IPv6:2001:470:e24c:200::ae25]); Sun, 12 May 2013 22:20:27 -0400 (EDT) Cc: "freebsd-stable@freebsd.org" X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 13 May 2013 02:20:29 -0000 On May 12, 2013, at 16:58 , Jeremy Chadwick wrote: > The command is "gpart bootcode", however I cannot be bothered to > remember the syntax; I imagine it greatly depends on if you're using = GPT > vs. MBR, in addition to what your partition layout look like. = Meaning: > there is no "universal standard", it depends entirely on how you set > your stuff up. But the command is definitely "gpart bootcode". >=20 > Next, AFAIK there is no need to boot alternate media (CD etc.) to > accomplish this. >=20 > You may also need to set kern.geom.debugflags=3D0x10 to inhibit GEOM's > "safety measure" / to permit writing to LBA 0; see GEOM(4) and search > for the word "foot". In the past, I've found I've been unable to install all of the = bootblocks if I boot from the ZFS root. When booting from a cd, the basic: gpart bootcode -p ${bootdir}/zfsboot ${disk} dd if=3D${bootdir}zfsloader of=3D/dev/${disk}a bs=3D512 = oseek=3D1024 conv=3Dnotrunc,sync works. But, if I boot from ZFS, then I can't dd anything into the front = of the=20 drives. Right now, the problem after booting from the CD, is trying to = mount a read/write filesystem (mfs, or the like) so that I can scp the = bootblocks onto the system and install them. BUt, I eventually found the command I'd lost. = so I=20 think I'm alright. Thanks... - Chris From owner-freebsd-stable@FreeBSD.ORG Mon May 13 03:14:24 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 4CAFD92F for ; Mon, 13 May 2013 03:14:24 +0000 (UTC) (envelope-from wollman@hergotha.csail.mit.edu) Received: from hergotha.csail.mit.edu (wollman-1-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:ccb::2]) by mx1.freebsd.org (Postfix) with ESMTP id 0867F10B for ; Mon, 13 May 2013 03:14:23 +0000 (UTC) Received: from hergotha.csail.mit.edu (localhost [127.0.0.1]) by hergotha.csail.mit.edu (8.14.5/8.14.5) with ESMTP id r4D3EKQ9016782; Sun, 12 May 2013 23:14:20 -0400 (EDT) (envelope-from wollman@hergotha.csail.mit.edu) Received: (from wollman@localhost) by hergotha.csail.mit.edu (8.14.5/8.14.4/Submit) id r4D3EKaJ016781; Sun, 12 May 2013 23:14:20 -0400 (EDT) (envelope-from wollman) Date: Sun, 12 May 2013 23:14:20 -0400 (EDT) From: Garrett Wollman Message-Id: <201305130314.r4D3EKaJ016781@hergotha.csail.mit.edu> To: jdc@koitsu.org Subject: Re: Reinstalling boot blocks on a ZFS-only system X-Newsgroups: mit.lcs.mail.freebsd-stable In-Reply-To: <20130512205837.GA69605@icarus.home.lan> References: Organization: none X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (hergotha.csail.mit.edu [127.0.0.1]); Sun, 12 May 2013 23:14:20 -0400 (EDT) X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED autolearn=disabled version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on hergotha.csail.mit.edu Cc: freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 13 May 2013 03:14:24 -0000 In article <20130512205837.GA69605@icarus.home.lan>, jdc@koitsu.org writes: >You may also need to set kern.geom.debugflags=0x10 to inhibit GEOM's >"safety measure" / to permit writing to LBA 0; see GEOM(4) and search >for the word "foot". If you have set up your partitioning properly (read: following the clearly recommended best practice on the wiki), there should never, ever be any reason to do this. (That is why it's called a DEBUG flag.) The necessary and sufficient invocation is: # gpart bootcode -b /boot/pmbr -p /boot/gptzfsloader -i 1 [a]daX I have no idea how this works with MBR partitioning, but I would make one suggestion in that regard: DON'T. Whatever makes you think you want to do that, think harder and find another way. -GAWollman From owner-freebsd-stable@FreeBSD.ORG Mon May 13 03:17:44 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id B8DC6A43 for ; Mon, 13 May 2013 03:17:44 +0000 (UTC) (envelope-from jdc@koitsu.org) Received: from qmta05.emeryville.ca.mail.comcast.net (qmta05.emeryville.ca.mail.comcast.net [IPv6:2001:558:fe2d:43:76:96:30:48]) by mx1.freebsd.org (Postfix) with ESMTP id 86AD8123 for ; Mon, 13 May 2013 03:17:44 +0000 (UTC) Received: from omta21.emeryville.ca.mail.comcast.net ([76.96.30.88]) by qmta05.emeryville.ca.mail.comcast.net with comcast id bERW1l0011u4NiLA5FHjaA; Mon, 13 May 2013 03:17:43 +0000 Received: from koitsu.strangled.net ([67.180.84.87]) by omta21.emeryville.ca.mail.comcast.net with comcast id bFHi1l00X1t3BNj8hFHiMF; Mon, 13 May 2013 03:17:43 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id 83C5473A33; Sun, 12 May 2013 20:17:42 -0700 (PDT) Date: Sun, 12 May 2013 20:17:42 -0700 From: Jeremy Chadwick To: Chris Ross Subject: Re: Reinstalling boot blocks on a ZFS-only system Message-ID: <20130513031742.GA75801@icarus.home.lan> References: <20130512205837.GA69605@icarus.home.lan> <28B5181C-E185-40E5-90EC-9600297BE590@distal.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <28B5181C-E185-40E5-90EC-9600297BE590@distal.com> User-Agent: Mutt/1.5.21 (2010-09-15) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1368415063; bh=X2UlqapqFdUYjqprqRv9C9dNtg/T15TG1x9oqpKsuCU=; h=Received:Received:Received:Date:From:To:Subject:Message-ID: MIME-Version:Content-Type; b=BBkZXbdGF3HwLGrGsXzP8Uy0M6/0rdFs9fYoK9meq3M+fL47xTVfEBhaiMwLkwVZ3 li1MQKqkq/Vnw/xA/yZkA/E+SzoPZNJSUwfQQhyjvX9JNAxACtDsCn8I5mZCzgOMIS NJ7NbHBm2PSvPUZEJF+n6SA9V+PJ4Vro+xiKh61qwzT0Ai+PIdUtu9KYTjZOpfJ4aX xHf/rAaYs4U/kqNeb3vroJOmqyH+/pLlqlKdRiODu03FzSveKlaEO4/1t9KWa3W0HG +EjNpaZ0Uxqu7S4AA72eNVjNeSWNmncPfXsTBli9GJwh5iC8PB2luTRolz6HpYjCkM YvMUT/kX1EHRg== Cc: "freebsd-stable@freebsd.org" X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 13 May 2013 03:17:44 -0000 On Sun, May 12, 2013 at 10:20:26PM -0400, Chris Ross wrote: > > On May 12, 2013, at 16:58 , Jeremy Chadwick wrote: > > The command is "gpart bootcode", however I cannot be bothered to > > remember the syntax; I imagine it greatly depends on if you're using GPT > > vs. MBR, in addition to what your partition layout look like. Meaning: > > there is no "universal standard", it depends entirely on how you set > > your stuff up. But the command is definitely "gpart bootcode". > > > > Next, AFAIK there is no need to boot alternate media (CD etc.) to > > accomplish this. > > > > You may also need to set kern.geom.debugflags=0x10 to inhibit GEOM's > > "safety measure" / to permit writing to LBA 0; see GEOM(4) and search > > for the word "foot". > > In the past, I've found I've been unable to install all of the bootblocks if I > boot from the ZFS root. When booting from a cd, the basic: > > gpart bootcode -p ${bootdir}/zfsboot ${disk} > dd if=${bootdir}zfsloader of=/dev/${disk}a bs=512 oseek=1024 conv=notrunc,sync > > works. But, if I boot from ZFS, then I can't dd anything into the front of the > drives. Right now, the problem after booting from the CD, is trying to mount > a read/write filesystem (mfs, or the like) so that I can scp the bootblocks onto the > system and install them. BUt, I eventually found the command I'd lost. so I > think I'm alright. Thanks... What does "unable to install" mean? What output/error do you get? I am going to assume you get EPERM (Operation not permitted), which would be caused by GEOM's "preventive foot-shooting" (keep reading). Is there some reason you're sticking with the MBR scheme instead of GPT? Taken from GEOM(4): Both types of bootstrap code are used to boot from the GUID Partition Ta- ble. First, a protective MBR is embedded into the first disk sector from the /boot/pmbr image. It searches the GPT freebsd-boot partition (see the PARTITION TYPES section) in the GPT and runs the next bootstrap stage from it. The freebsd-boot partition should be smaller than 545 KB. There are two variants of bootstrap code to write to this partition: /boot/gptboot and /boot/gptzfsboot. /boot/gptboot is used to boot from UFS. It searches freebsd-ufs GPT partitions and starts /boot/loader (the third bootstrap stage) if found. The /boot/gptzfsboot is used to boot from ZFS. It searches freebsd-zfs GPT partitions and starts /boot/zfsloader if found. So by moving to GPT you would relieve yourself of a lot of pain, particularly that dd nonsense (which looks like it could seriously hurt you, especially if you're doing it by hand by booting some CD). An added bonus to using the GPT scheme is that you can align your partitions easier for 4096-byte sector drives. With GPT, I believe you'd use this, and only this: sysctl kern.geom.debugflags=16 gpart bootcode -b /boot/pmbr -p /boot/gptzfsboot -i 1 ${disk} sysctl kern.geom.debugflags=0 (That also assumes the GPT freebsd-boot partition is what's comes first on $disk (i.e. index 1), as it should be) If you're using mirrors, you would need to do the gpart command for each disk that is part of your mirror vdev; i.e. if ada0 and ada1 are a mirror, issue the gpart command against ada0 and ada1, otherwise you may find that if one of your disks dies you might not be able to boot from the system. All this comes from: https://wiki.freebsd.org/RootOnZFS/GPTZFSBoot/Mirror (You'll find the EPERM situation mentioned there too) I should also note that if you do go with GPT, please use a larger freebsd-boot partition size (512KBytes is ideal, not 64KBytes), because the bootstraps are often >64KBytes these days. http://www.wonkity.com/~wblock/docs/html/ssd.html Good luck. -- | Jeremy Chadwick jdc@koitsu.org | | UNIX Systems Administrator http://jdc.koitsu.org/ | | Mountain View, CA, US | | Making life hard for others since 1977. PGP 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Mon May 13 03:28:40 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 59566CC8 for ; Mon, 13 May 2013 03:28:40 +0000 (UTC) (envelope-from jdc@koitsu.org) Received: from qmta11.emeryville.ca.mail.comcast.net (qmta11.emeryville.ca.mail.comcast.net [IPv6:2001:558:fe2d:44:76:96:27:211]) by mx1.freebsd.org (Postfix) with ESMTP id 2800B188 for ; Mon, 13 May 2013 03:28:40 +0000 (UTC) Received: from omta07.emeryville.ca.mail.comcast.net ([76.96.30.59]) by qmta11.emeryville.ca.mail.comcast.net with comcast id bFA41l0031GXsucABFUfRN; Mon, 13 May 2013 03:28:39 +0000 Received: from koitsu.strangled.net ([67.180.84.87]) by omta07.emeryville.ca.mail.comcast.net with comcast id bFUe1l00f1t3BNj8UFUfY9; Mon, 13 May 2013 03:28:39 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id BB4F673A33; Sun, 12 May 2013 20:28:38 -0700 (PDT) Date: Sun, 12 May 2013 20:28:38 -0700 From: Jeremy Chadwick To: Garrett Wollman Subject: Re: Reinstalling boot blocks on a ZFS-only system Message-ID: <20130513032838.GA76253@icarus.home.lan> References: <201305130314.r4D3EKaJ016781@hergotha.csail.mit.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201305130314.r4D3EKaJ016781@hergotha.csail.mit.edu> User-Agent: Mutt/1.5.21 (2010-09-15) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1368415719; bh=F3hSkwZPuWWDDPj2kKwHlrqbVe68GHnlKoEiyC/JeCY=; h=Received:Received:Received:Date:From:To:Subject:Message-ID: MIME-Version:Content-Type; b=mVOHvkhNsVmsNYZfQ8z1AIun6xgvxYHTfT86CT/gzu8UrSNllCnOtkmCnpL67Vg7G grpibWqFpB8bMoCbX23ExzHA1JQDj9T8RcxQJozI5sTBSji1Z4D/sRy9kIAYB4w/1U /8TVsS6ByMOPqsxDaQTSqx2P/iHV0+meqGLhUuGedLriFu1xCQ8oN3oe5Zw9B9AD6g NPOSEWn2P4lQVTxSSCH8dxbtzBhx/130RGQmUkNT3hzsjaldnjP/+oiEDpYHDbdIcM yG5GawQayyHeA+a/gVehdGEa1Bj2sMKwUuH49ePOHJUrZ/Ve441nhWRTFqNmMB0xt2 1bYp8cPL1s4xw== Cc: freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 13 May 2013 03:28:40 -0000 On Sun, May 12, 2013 at 11:14:20PM -0400, Garrett Wollman wrote: > In article <20130512205837.GA69605@icarus.home.lan>, jdc@koitsu.org writes: > > >You may also need to set kern.geom.debugflags=0x10 to inhibit GEOM's > >"safety measure" / to permit writing to LBA 0; see GEOM(4) and search > >for the word "foot". > > If you have set up your partitioning properly (read: following the > clearly recommended best practice on the wiki), there should never, > ever be any reason to do this. (That is why it's called a DEBUG > flag.) ... I'm in full agreement with you, but the irony is that you refer to "the wiki", which I have intentionally ignored for years now because it's always wrong/always out of date/under scrutiny/do-not-care-to-debate. Case in point: https://wiki.freebsd.org/RootOnZFS/GPTZFSBoot 5. Install the Protected MBR (pmbr) and gptzfsboot loader Fixit# gpart bootcode -b /mnt2/boot/pmbr -p /mnt2/boot/gptzfsboot -i 1 ad0 This may fail with an "operation not permitted" error message, since the kernel likes to protect critical parts of the disk. If this happens for you, run: Fixit# sysctl kern.geom.debugflags=0x10 https://wiki.freebsd.org/RootOnZFS/GPTZFSBoot/Mirror 5. Install the Protected MBR (pmbr) and gptzfsboot loader to both drives Fixit# gpart bootcode -b /mnt2/boot/pmbr -p /mnt2/boot/gptzfsboot -i 1 ad0 Fixit# gpart bootcode -b /mnt2/boot/pmbr -p /mnt2/boot/gptzfsboot -i 1 ad1 This may fail with an "operation not permitted" error message, since the kernel likes to protect critical parts of the disk. If this happens for you, run: Fixit# sysctl kern.geom.debugflags=0x10 https://wiki.freebsd.org/RootOnZFS/ZFSBootPartition 10. Install ZFS boot ... Install the boot1 stage: Fixit# dd if=/mnt2/boot/zfsboot of=/dev/ad0s3 count=1 This may fail with an "operation not permitted" error message, since the kernel likes to protect critical parts of the disk. If this happens for you, run: Fixit# sysctl kern.geom.debugflags=0x10 > The necessary and sufficient invocation is: > > # gpart bootcode -b /boot/pmbr -p /boot/gptzfsloader -i 1 [a]daX > > I have no idea how this works with MBR partitioning, but I would make > one suggestion in that regard: DON'T. Whatever makes you think you > want to do that, think harder and find another way. I believe for MBR you'd need to refer to the slice, not the disk, i.e. ada0s1 (NOT THE PARTITION ada0s1a). I found this out long ago when doing the classic "bsdlabel -B ada0" method of updating boot blocks only to find it bitch/complain and insist I use the slice. I haven't dared touch gpart for bootblock updates on any FreeBSD system I have access to, simply because the gpart syntax is long and could really screw you over if you make a typo. Plus, remembering which files to refer to in /boot is always spotty. "Uh, do I use -b here or -p... Uh, do I use /boot/mbr or /boot/pmbr... err...". /boot is such a mess these days. -- | Jeremy Chadwick jdc@koitsu.org | | UNIX Systems Administrator http://jdc.koitsu.org/ | | Mountain View, CA, US | | Making life hard for others since 1977. PGP 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Mon May 13 03:54:47 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id A57D9ECC for ; Mon, 13 May 2013 03:54:47 +0000 (UTC) (envelope-from wollman@hergotha.csail.mit.edu) Received: from hergotha.csail.mit.edu (wollman-1-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:ccb::2]) by mx1.freebsd.org (Postfix) with ESMTP id 4764022C for ; Mon, 13 May 2013 03:54:46 +0000 (UTC) Received: from hergotha.csail.mit.edu (localhost [127.0.0.1]) by hergotha.csail.mit.edu (8.14.5/8.14.5) with ESMTP id r4D3sjTA017173; Sun, 12 May 2013 23:54:45 -0400 (EDT) (envelope-from wollman@hergotha.csail.mit.edu) Received: (from wollman@localhost) by hergotha.csail.mit.edu (8.14.5/8.14.4/Submit) id r4D3sjUu017172; Sun, 12 May 2013 23:54:45 -0400 (EDT) (envelope-from wollman) Date: Sun, 12 May 2013 23:54:45 -0400 (EDT) From: Garrett Wollman Message-Id: <201305130354.r4D3sjUu017172@hergotha.csail.mit.edu> To: jdc@koitsu.org Subject: Re: Reinstalling boot blocks on a ZFS-only system X-Newsgroups: mit.lcs.mail.freebsd-stable In-Reply-To: <20130513032838.GA76253@icarus.home.lan> References: <201305130314.r4D3EKaJ016781@hergotha.csail.mit.edu> Organization: none X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (hergotha.csail.mit.edu [127.0.0.1]); Sun, 12 May 2013 23:54:46 -0400 (EDT) X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED autolearn=disabled version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on hergotha.csail.mit.edu Cc: freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 13 May 2013 03:54:47 -0000 In article <20130513032838.GA76253@icarus.home.lan>, jdc@koitsu.org write: >https://wiki.freebsd.org/RootOnZFS/GPTZFSBoot > >5. Install the Protected MBR (pmbr) and gptzfsboot loader Bug #1: "Protective", not "Protected". > Fixit# gpart bootcode -b /mnt2/boot/pmbr -p /mnt2/boot/gptzfsboot -i 1 ad0 > > This may fail with an "operation not permitted" error message, since the > kernel likes to protect critical parts of the disk. If this happens for > you, run: > > Fixit# sysctl kern.geom.debugflags=0x10 I suppose the bit that's missing here is: ...and then file a bug report, with severity "serious" and priority "high", because this indicates that something is seriously broken in the kernel's implementation of GPT partitioning. The only way this step can fail (absent bugs) is if something (other than gpart) has either the whole-disk device or the partition 1 device open in exclusive mode, which is a "can't happen" condition at this stage in an installation. (Well, it can happen if the disk you are in the process of destroying has a still-mounted filesystem on it, which is what the code is supposed to prevent!) This little bit of cargo-culting used to be necessary for *MBR* and *bsdlabel* partitioning, before the days of "gpart bootcode", to update the boot0 and embedded partition-boot (boot1) blocks while the filesystem was mounted, because the bsdlabel boot blocks are stored in the first 64k of the root filesystem. When using GPT, the boot blocks are stored in the boot partition, which doesn't have a mountable filesystem on it, so should never be open for write except when gpart bootcode is doing the deed. -GAWollman From owner-freebsd-stable@FreeBSD.ORG Mon May 13 04:56:38 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 6F55AA04; Mon, 13 May 2013 04:56:38 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from mail-pb0-x22b.google.com (mail-pb0-x22b.google.com [IPv6:2607:f8b0:400e:c01::22b]) by mx1.freebsd.org (Postfix) with ESMTP id 3FBB75E8; Mon, 13 May 2013 04:56:38 +0000 (UTC) Received: by mail-pb0-f43.google.com with SMTP id md12so4151222pbc.30 for ; Sun, 12 May 2013 21:56:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:from:date:to:cc:subject:message-id:reply-to:references :mime-version:content-type:content-disposition:in-reply-to :user-agent; bh=n9Flj/6tr4v6wg0czVQSDFWPJXXHL5GpgIjomNYmNkg=; b=z8GtboaiDu2FFO0R4+1ktRcn3t9fAsWX2zX1EL8Jz9lZzp7nHgBb0f8YyqPPuweAyE Jr6ERPM9PZcq/HXHdPujNJ72LXtGN2tthMacOLjNgajS7nxtlSebfMLgB04QIMAmDama OS8xiM7XvShIlnFjCy2cSU0X5YuTnI5JHuc16Xr8C828b9Fn4eGRjCr/TUntiNTsj2s6 sUE66KR5J0g2jrL4zG88QJM9ZiU80dY6Hyd8PTNFfMKCk2FBwaQKbQyi1T19zLiF/SAE YtP79zByu5TP3J0w+mBRLggDxaIfeXT1dIqDwqx0vEtPHn8NKjOCUAasYoM/xgwzpqQN T6Sg== X-Received: by 10.68.211.73 with SMTP id na9mr27837362pbc.90.1368420998027; Sun, 12 May 2013 21:56:38 -0700 (PDT) Received: from pyunyh@gmail.com (lpe4.p59-icn.cdngp.net. [114.111.62.249]) by mx.google.com with ESMTPSA id wi6sm12451797pbc.22.2013.05.12.21.56.34 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Sun, 12 May 2013 21:56:36 -0700 (PDT) Received: by pyunyh@gmail.com (sSMTP sendmail emulation); Mon, 13 May 2013 13:56:30 +0900 From: YongHyeon PYUN Date: Mon, 13 May 2013 13:56:30 +0900 To: "Michael L. Squires" Subject: Re: Apparent fxp regression in FreeBSD 8.4-RC3 Message-ID: <20130513045630.GB1480@michelle.cdnetworks.com> References: <20130508174721.GD1651@glenbarber.us> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Cc: Glen Barber , FreeBSD Release Engineering Team , freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: pyunyh@gmail.com List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 May 2013 04:56:38 -0000 On Sat, May 11, 2013 at 10:57:44PM -0400, Michael L. Squires wrote: > I upgraded to FreeBSD 8.4-RC3 and noticed a problem with the fxp driver on > an older Supermicro single CPU single core Xeon motherboard. > > I know that 8.3-Release does not have this issue, but don't know when in > the updates to that release the regression was introduced. > > I use the fxp driver to connect to a Motorola Surfboard cable modem, and > immediately saw the following occur many times: > > May 10 23:00:04 familysquires kernel: fxp0: link state changed to DOWN > May 10 23:00:04 familysquires dhclient: New Subnet Mask (fxp0): > 255.255.240.0 > May 10 23:00:04 familysquires dhclient: New Broadcast Address (fxp0): > 255.255.25 > 5.255 > May 10 23:00:04 familysquires dhclient: New Routers (fxp0): xx.xxx.xxx.1 > May 10 23:00:06 familysquires kernel: fxp0: link state changed to UP > May 10 23:00:22 familysquires dhclient: New IP Address (fxp0): > xx.xxx.xxx.163 > May 10 23:00:22 familysquires kernel: fxp0: link state changed to DOWN > May 10 23:00:22 familysquires dhclient: New Subnet Mask (fxp0): > 255.255.240.0 > May 10 23:00:22 familysquires dhclient: New Broadcast Address (fxp0): > 255.255.255.255 > May 10 23:00:22 familysquires dhclient: New Routers (fxp0): xx.xxx.xxx.1 > May 10 23:00:24 familysquires kernel: fxp0: link state changed to UP > > repeated without end. If you assign static IP address, fxp(4) works? > > I reinsalled 8.3-Release p8 > > FreeBSD familysquires.net 8.3-RELEASE-p8 FreeBSD 8.3-RELEASE-p8 #46: Sat > May 11 00:05:26 EDT 2013 > > which ended the string up fxp up/down messages. This kernel has now > operated for 24 hours without generating this error. There were several fxp(4)changes made since FreeBSD 8.3-RELEASE but I don't see any fxp(4) commits that may result in DHCP issue above. I recall there was a dhclient(8) change that makes dhclient track link state. Could you rebuild dhclient(8) and try again without that change(i.e. locally back out r247336)? > > I've attached a verbose dmesg from 8.4-RC3 and a standard dmesg from > 8.3-Release p8, and can provide whatever else you need. > > This is not a critical issue for me. The system has an unused bge interface > (replaced by an Intel em0 interface during a previous bout of a problem with > the bge driver). > > Mike Squires > mikes@siralan.org From owner-freebsd-stable@FreeBSD.ORG Mon May 13 06:07:47 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id AF1B0AD5 for ; Mon, 13 May 2013 06:07:47 +0000 (UTC) (envelope-from marek_sal@wp.pl) Received: from mx4.wp.pl (mx4.wp.pl [212.77.101.8]) by mx1.freebsd.org (Postfix) with ESMTP id 39FF785A for ; Mon, 13 May 2013 06:07:46 +0000 (UTC) Received: (wp-smtpd smtp.wp.pl 13017 invoked from network); 13 May 2013 08:07:45 +0200 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=wp.pl; s=1024a; t=1368425265; bh=mnNxNjEj4WgvNdc8bFT/ak/BFgLZl30p8zQet06+tOI=; h=From:To:CC:Subject; b=Hx+6tH3moVNJl64jQa3G56VMQLJ6HDB0k2/KNbscn44x9VtSc8frJyFxiLFbpMaJB XR3ustVZbrsPU/1JRqoShYoPH+QzZUNXUta7dUZMuebXeLDWqYM6cR0gn8IDeNhwFA CQrp6cXEghAhoPJGmDzy5mdxrdpOx/vaEiZtVNXQ= Received: from nat.misal.pl (HELO [127.0.0.1]) (marek_sal@[83.19.131.171]) (envelope-sender ) by smtp.wp.pl (WP-SMTPD) with AES256-SHA encrypted SMTP for ; 13 May 2013 08:07:45 +0200 Message-ID: <5190832E.5040102@wp.pl> Date: Mon, 13 May 2013 08:07:42 +0200 From: Marek Salwerowicz User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: Adrian Chadd Subject: Re: Build GENERIC with IPX support References: <518ED0CA.4030007@wp.pl> <51900FA5.20204@wp.pl> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 130512-1, 2013-05-12), Outbound message X-Antivirus-Status: Clean X-WP-DKIM-Status: good (id: wp.pl) X-WP-AV: skaner antywirusowy poczty Wirtualnej Polski S. A. X-WP-SPAM: NO 0000000 [EZOk] Cc: Marek Salwerowicz , "freebsd-stable@freebsd.org" , "illoai@gmail.com" X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 13 May 2013 06:07:47 -0000 W dniu 2013-05-13 00:45, Adrian Chadd pisze: > It's supported as long as someone wants to use it and can help in at > least diagnosing issues. > > So, if you have a segfault, run it inside gdb and report where its dying. > > Chances are things have just bitrotted a bit but not so much that it's > worth killing. # gdb ncplogin GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "amd64-marcel-freebsd"...(no debugging symbols found)... (gdb) run Starting program: /usr/bin/ncplogin (no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)... Program received signal SIGSEGV, Segmentation fault. 0x0000000800d285f7 in strlen () from /lib/libc.so.7 (gdb) bt #0 0x0000000800d285f7 in strlen () from /lib/libc.so.7 #1 0x0000000800d205b0 in gettimeofday () from /lib/libc.so.7 #2 0x0000000800d2163e in gettimeofday () from /lib/libc.so.7 #3 0x0000000800d21798 in vfprintf_l () from /lib/libc.so.7 #4 0x0000000800d0e701 in fprintf () from /lib/libc.so.7 #5 0x0000000800822a85 in ncp_error () from /usr/lib/libncp.so.4 #6 0x000000080081fa7c in ncp_li_readrc () from /usr/lib/libncp.so.4 #7 0x0000000000400ea7 in ?? () #8 0x0000000000400d2e in ?? () #9 0x000000080061c000 in ?? () #10 0x0000000000000000 in ?? () #11 0x0000000000000001 in ?? () #12 0x00007fffffffddf8 in ?? () #13 0x0000000000000000 in ?? () #14 0x00007fffffffde0a in ?? () #15 0x00007fffffffde1e in ?? () #16 0x00007fffffffde35 in ?? () #17 0x00007fffffffde3d in ?? () #18 0x00007fffffffde49 in ?? () #19 0x00007fffffffde52 in ?? () #20 0x00007fffffffde67 in ?? () #21 0x00007fffffffde74 in ?? () #22 0x00007fffffffde88 in ?? () #23 0x00007fffffffdee5 in ?? () #24 0x00007fffffffdef3 in ?? () #25 0x00007fffffffdf07 in ?? () #26 0x00007fffffffdf12 in ?? () #27 0x00007fffffffdf1d in ?? () #28 0x00007fffffffdf27 in ?? () #29 0x00007fffffffdf40 in ?? () #30 0x00007fffffffdf50 in ?? () #31 0x00007fffffffdf5e in ?? () #32 0x0000000000000000 in ?? () #33 0x0000000000000003 in ?? () #34 0x0000000000400040 in ?? () #35 0x0000000000000004 in ?? () #36 0x0000000000000038 in ?? () #37 0x0000000000000005 in ?? () #38 0x0000000000000008 in ?? () #39 0x0000000000000006 in ?? () #40 0x0000000000001000 in ?? () #41 0x0000000000000008 in ?? () #42 0x0000000000000000 in ?? () #43 0x0000000000000009 in ?? () #44 0x0000000000400ca0 in ?? () #45 0x0000000000000007 in ?? () #46 0x0000000800601000 in ?? () #47 0x000000000000000f in ?? () #48 #49 0x0000000000000000 in ?? () Previous frame inner to this frame (corrupt stack?) (gdb) # my /etc/rc.conf file contains these lines: ifconfig_em0f1_ipx="ipx 0x01230000.1" ipxrouted_enable="YES" and in /boot/loader.conf: if_ef_load="YES" What's more, the 'ncplist s' command is unable to find any NetWare servers: # ncplist s Can't find any file server # But Frame type (802.3) and network number (0x0123) are correct. From owner-freebsd-stable@FreeBSD.ORG Mon May 13 06:52:08 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 285D6E1E for ; Mon, 13 May 2013 06:52:08 +0000 (UTC) (envelope-from jdc@koitsu.org) Received: from qmta15.emeryville.ca.mail.comcast.net (qmta15.emeryville.ca.mail.comcast.net [IPv6:2001:558:fe2d:44:76:96:27:228]) by mx1.freebsd.org (Postfix) with ESMTP id F2ABF97C for ; Mon, 13 May 2013 06:52:07 +0000 (UTC) Received: from omta18.emeryville.ca.mail.comcast.net ([76.96.30.74]) by qmta15.emeryville.ca.mail.comcast.net with comcast id bJs71l0011bwxycAFJs7MG; Mon, 13 May 2013 06:52:07 +0000 Received: from koitsu.strangled.net ([67.180.84.87]) by omta18.emeryville.ca.mail.comcast.net with comcast id bJs61l00B1t3BNj8eJs6gs; Mon, 13 May 2013 06:52:06 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id 1AAAD73A33; Sun, 12 May 2013 23:52:06 -0700 (PDT) Date: Sun, 12 May 2013 23:52:06 -0700 From: Jeremy Chadwick To: Marek Salwerowicz Subject: Re: Build GENERIC with IPX support Message-ID: <20130513065206.GA78810@icarus.home.lan> References: <518ED0CA.4030007@wp.pl> <51900FA5.20204@wp.pl> <5190832E.5040102@wp.pl> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5190832E.5040102@wp.pl> User-Agent: Mutt/1.5.21 (2010-09-15) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1368427927; bh=oAxlYyYaGRhowu9Nv4iZBRwaeOQ5RHbjoD2y8t9P710=; h=Received:Received:Received:Date:From:To:Subject:Message-ID: MIME-Version:Content-Type; b=OiuHnzUW/DnhGECc1ddHXUg3I+0wfskJfTzEwHP/tCsVq95YieNDJQX/gg91tJX1T oghsYBfmsmvQ/ay9sl97fROU0HZtCaO5ytlQ+0fZyTmHdGdX/fWZWPCJkJqiWVLdMj TrilhPCuqxIbAWf4ItCHmDvdjPQI5u7ad3S+082IxZCnsilopsW3Bl9bGzx4erv9UY YRI9+LZZrNdby5In0VzO3AViROj3uM2vXo8TIci7OauGxIFomaWRUZM9ba8FiU6LZo RRh562bLQcrCn21rj7S/UZCKK9i5zcMPCrT4Kv4FRGtn0Z9cJzVaVgNZ7Iho5cwZ8E oW1cdBf3bL3lQ== Cc: Adrian Chadd , "freebsd-stable@freebsd.org" , "illoai@gmail.com" X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 13 May 2013 06:52:08 -0000 On Mon, May 13, 2013 at 08:07:42AM +0200, Marek Salwerowicz wrote: > W dniu 2013-05-13 00:45, Adrian Chadd pisze: > >It's supported as long as someone wants to use it and can help in at > >least diagnosing issues. > > > >So, if you have a segfault, run it inside gdb and report where its dying. > > > >Chances are things have just bitrotted a bit but not so much that it's > >worth killing. > > # gdb ncplogin > GNU gdb 6.1.1 [FreeBSD] > Copyright 2004 Free Software Foundation, Inc. > GDB is free software, covered by the GNU General Public License, and you are > welcome to change it and/or distribute copies of it under certain > conditions. > Type "show copying" to see the conditions. > There is absolutely no warranty for GDB. Type "show warranty" for details. > This GDB was configured as "amd64-marcel-freebsd"...(no debugging > symbols found)... > (gdb) run > Starting program: /usr/bin/ncplogin > (no debugging symbols found)...(no debugging symbols found)...(no > debugging symbols found)...(no debugging symbols found)... > Program received signal SIGSEGV, Segmentation fault. > 0x0000000800d285f7 in strlen () from /lib/libc.so.7 > (gdb) bt > #0 0x0000000800d285f7 in strlen () from /lib/libc.so.7 > #1 0x0000000800d205b0 in gettimeofday () from /lib/libc.so.7 > #2 0x0000000800d2163e in gettimeofday () from /lib/libc.so.7 > #3 0x0000000800d21798 in vfprintf_l () from /lib/libc.so.7 > #4 0x0000000800d0e701 in fprintf () from /lib/libc.so.7 > #5 0x0000000800822a85 in ncp_error () from /usr/lib/libncp.so.4 > #6 0x000000080081fa7c in ncp_li_readrc () from /usr/lib/libncp.so.4 > #7 0x0000000000400ea7 in ?? () > #8 0x0000000000400d2e in ?? () > #9 0x000000080061c000 in ?? () > #10 0x0000000000000000 in ?? () > #11 0x0000000000000001 in ?? () > #12 0x00007fffffffddf8 in ?? () > #13 0x0000000000000000 in ?? () > #14 0x00007fffffffde0a in ?? () > #15 0x00007fffffffde1e in ?? () > #16 0x00007fffffffde35 in ?? () > #17 0x00007fffffffde3d in ?? () > #18 0x00007fffffffde49 in ?? () > #19 0x00007fffffffde52 in ?? () > #20 0x00007fffffffde67 in ?? () > #21 0x00007fffffffde74 in ?? () > #22 0x00007fffffffde88 in ?? () > #23 0x00007fffffffdee5 in ?? () > #24 0x00007fffffffdef3 in ?? () > #25 0x00007fffffffdf07 in ?? () > #26 0x00007fffffffdf12 in ?? () > #27 0x00007fffffffdf1d in ?? () > #28 0x00007fffffffdf27 in ?? () > #29 0x00007fffffffdf40 in ?? () > #30 0x00007fffffffdf50 in ?? () > #31 0x00007fffffffdf5e in ?? () > #32 0x0000000000000000 in ?? () > #33 0x0000000000000003 in ?? () > #34 0x0000000000400040 in ?? () > #35 0x0000000000000004 in ?? () > #36 0x0000000000000038 in ?? () > #37 0x0000000000000005 in ?? () > #38 0x0000000000000008 in ?? () > #39 0x0000000000000006 in ?? () > #40 0x0000000000001000 in ?? () > #41 0x0000000000000008 in ?? () > #42 0x0000000000000000 in ?? () > #43 0x0000000000000009 in ?? () > #44 0x0000000000400ca0 in ?? () > #45 0x0000000000000007 in ?? () > #46 0x0000000800601000 in ?? () > #47 0x000000000000000f in ?? () > #48 > #49 0x0000000000000000 in ?? () > Previous frame inner to this frame (corrupt stack?) > (gdb) > > # > > my /etc/rc.conf file contains these lines: > > ifconfig_em0f1_ipx="ipx 0x01230000.1" > ipxrouted_enable="YES" > > and in /boot/loader.conf: > if_ef_load="YES" > > What's more, the 'ncplist s' command is unable to find any NetWare servers: > # ncplist s > Can't find any file server > # > > But Frame type (802.3) and network number (0x0123) are correct. Without debugging symbols this will be annoying to debug. From a brief skim of the code, it looks like the author has very horrible error checking and makes a lot of assumptions about the user's environment (dot files, etc.). IPX has been neglected for what should be obvious reasons. As someone who got his CNE back in 1994 (circa Netware 3.11), you're the first person I have encountered since roughly 1997 who is actively using IPX. Netware does support TCP/IP, you know... Anyway, in your case, you're in luck: > #0 0x0000000800d285f7 in strlen () from /lib/libc.so.7 > #1 0x0000000800d205b0 in gettimeofday () from /lib/libc.so.7 > #2 0x0000000800d2163e in gettimeofday () from /lib/libc.so.7 > #3 0x0000000800d21798 in vfprintf_l () from /lib/libc.so.7 > #4 0x0000000800d0e701 in fprintf () from /lib/libc.so.7 > #5 0x0000000800822a85 in ncp_error () from /usr/lib/libncp.so.4 > #6 0x000000080081fa7c in ncp_li_readrc () from /usr/lib/libncp.so.4 ncp_li_readrc(), which is part of libncp, only has one call to ncp_error() in it: src/lib/libncp/ncpl_conn.c -- 180 /* 181 * read rc file as follows: 182 * 1. read [server] section 183 * 2. override with [server:user] section 184 * Since abcence of rcfile is not a bug, silently ignore that fact. 185 * rcfile never closed to reduce number of open/close operations. 186 */ 187 int 188 ncp_li_readrc(struct ncp_conn_loginfo *li) { 189 int i, val, error; 190 char uname[NCP_BINDERY_NAME_LEN*2+1]; 191 char *sect = NULL, *p; 192 193 /* 194 * if info from cmd line incomplete, try to find existing 195 * connection and fill server/user from it. 196 */ 197 if (li->server[0] == 0 || li->user == NULL) { 198 int connHandle; 199 struct ncp_conn_stat cs; 200 201 if ((error = ncp_conn_scan(li, &connHandle)) != 0) { 202 ncp_error("no default connection found", errno); 203 return error; 204 } To me, this may indicate you have some kind of "ncp rc file" (I believe this is ~/.nwfsrc according to the ncplist(1) man page) that may contain something invalid, or maybe you lack such a file altogether (creating one might work around the problem). Back to the actual segfault itself: ncp_error() is pretty simple: src/lib/libncp/ncpl_subr.c -- 447 /* 448 * Print a (descriptive) error message 449 * error values: 450 * 0 - no specific error code available; 451 * -999..-1 - NDS error 452 * 1..32767 - system error 453 * the rest - requester error; 454 */ 455 void 456 ncp_error(const char *fmt, int error, ...) { 457 va_list ap; 458 459 fprintf(stderr, "%s: ", _getprogname()); 460 va_start(ap, error); 461 vfprintf(stderr, fmt, ap); 462 va_end(ap); 463 if (error == -1) 464 error = errno; 465 if (error > -1000 && error < 0) { 466 fprintf(stderr, ": dserr = %d\n", error); 467 } else if (error & 0x8000) { 468 fprintf(stderr, ": nwerr = %04x\n", error); 469 } else if (error) { 470 fprintf(stderr, ": syserr = %s\n", strerror(error)); 471 } else 472 fprintf(stderr, "\n"); 473 } What I don't understand from the calling stack is how gettimeofday() is involved. I have looked at the libc code, looked at the underlying calling functions and so on (from fprintf() to vfprintf_l() and deeper), and I don't see how or where gettimeofday() would be called. The only place I can think of might be the related locale stuff, but I'm doubting that given what I've looked at but could still be wrong. Have world/kernel on this system ever been rebuilt? If they have, were both kernel and world rebuilt together from the same source code and not at different times? If you're setting LANG, LC_CTYPE, LC_COLLATE, or other locale-oriented settings in your environment (and my gut feeling is that you are), you could try removing them and see if you get an actual useful error message on stderr, but I'm not holding my breath. I cannot help you with the remaining IPX-specific "stuff"; it's fairly obvious though, as I said, that this code has been neglected. -- | Jeremy Chadwick jdc@koitsu.org | | UNIX Systems Administrator http://jdc.koitsu.org/ | | Mountain View, CA, US | | Making life hard for others since 1977. PGP 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Mon May 13 09:15:52 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id EEF03327 for ; Mon, 13 May 2013 09:15:52 +0000 (UTC) (envelope-from andriy.kornatskyy@live.com) Received: from dub0-omc2-s8.dub0.hotmail.com (dub0-omc2-s8.dub0.hotmail.com [157.55.1.147]) by mx1.freebsd.org (Postfix) with ESMTP id 0FCE3CF for ; Mon, 13 May 2013 09:15:51 +0000 (UTC) Received: from DUB118-W9 ([157.55.1.137]) by dub0-omc2-s8.dub0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 13 May 2013 02:14:44 -0700 X-EIP: [WXJ7XNyE+bApzhZNvNJbdLtUVcz3Zq6N] X-Originating-Email: [andriy.kornatskyy@live.com] Message-ID: Content-Type: multipart/mixed; boundary="_8186b539-d85c-4bd1-9e9b-c960c7981732_" From: Andriy Kornatskyy To: "freebsd-stable@freebsd.org" Subject: kernel panic: ffs_valloc: dup alloc Date: Mon, 13 May 2013 12:14:44 +0300 Importance: Normal MIME-Version: 1.0 X-OriginalArrivalTime: 13 May 2013 09:14:44.0723 (UTC) FILETIME=[4EF0AC30:01CE4FBA] X-Content-Filtered-By: Mailman/MimeDel 2.1.14 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 13 May 2013 09:15:53 -0000 --_8186b539-d85c-4bd1-9e9b-c960c7981732_ Content-Type: text/plain; charset="windows-1251" Content-Transfer-Encoding: quoted-printable The core.txt and info files can be found in attached archive. If you need v= mcore=2C just let me know where I can upload it.=0A= =0A= ASUS K73E=0A= Architecture: i386=0A= OS: FreeBSD 9.1-RELEASE-p3=0A= =0A= Please let me know should you need some other information.=0A= =0A= Thanks.=0A= =0A= Andriy = --_8186b539-d85c-4bd1-9e9b-c960c7981732_-- From owner-freebsd-stable@FreeBSD.ORG Mon May 13 09:22:50 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 30AC2932 for ; Mon, 13 May 2013 09:22:50 +0000 (UTC) (envelope-from wolfgang@riegler.homeip.net) Received: from slave4.cbt-l.de (ip-125-173-205-91.static.contabo.net [91.205.173.125]) by mx1.freebsd.org (Postfix) with ESMTP id E583413A for ; Mon, 13 May 2013 09:22:49 +0000 (UTC) Received: from localhost (slave4.cbt-l.de [127.0.0.1]) by slave4.cbt-l.de (Postfix) with ESMTP id C15DD1DC130C for ; Mon, 13 May 2013 11:22:42 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at slave4.cbt-l.de Received: from slave4.cbt-l.de ([127.0.0.1]) by localhost (slave4.cbt-l.de [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KzLzVqS+aVLg for ; Mon, 13 May 2013 11:22:42 +0200 (CEST) Received: from mail.cbt-l.de (mail.cbt-l.de [212.185.49.146]) by slave4.cbt-l.de (Postfix) with ESMTP id 8358A1DC1137 for ; Mon, 13 May 2013 11:22:42 +0200 (CEST) Received: (qmail 80518 invoked by uid 1009); 13 May 2013 09:22:42 -0000 Received: from 192.168.40.46 by mail.cbt-l.de (envelope-from , uid 1008) with qmail-scanner-1.25-st-qms (clamdscan: ClamAV 0.97.8/17095. spamassassin: 3.3.0. perlscan: 1.25-st-qms. Clear:RC:1(192.168.40.46):. Processed in 0.058164 secs); 13 May 2013 09:22:42 -0000 X-Antivirus-CBTL-Mail-From: wolfgang@riegler.homeip.net via mail.cbt-l.de X-Antivirus-CBTL: 1.25-st-qms (Clear:RC:1(192.168.40.46):. Processed in 0.058164 secs Process 80408) Received: from wolfgang.cbt-l.de (HELO wolfgang.localnet) (w.riegler@cbt-l.de@192.168.40.46) by mail.cbt-l.de with SMTP; 13 May 2013 09:22:42 -0000 From: Wolfgang Riegler To: freebsd-questions@freebsd.org, freebsd-stable@freebsd.org Subject: freebsd-update and /boot/kernel/linker.hints Date: Mon, 13 May 2013 11:22:41 +0200 Message-ID: <1636055.7lG3Jua4h4@wolfgang> User-Agent: KMail/4.10.2 (Linux/3.8.2-pf-sepp1; KDE/4.10.2; x86_64; ; ) MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="utf-8" X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 13 May 2013 09:22:50 -0000 Hi, since last freebsd-update fetch install I always get this message after freebsd-update fetch: The following files will be updated as part of updating to 9.1-RELEASE-p3: /boot/kernel/linker.hints but freebsd-update install doesn't install anything. Is there something wrong with my system or is this a bug in freebsd-update? kind regards Wolfgang From owner-freebsd-stable@FreeBSD.ORG Mon May 13 09:11:12 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 9F37CFC7 for ; Mon, 13 May 2013 09:11:12 +0000 (UTC) (envelope-from andriy.kornatskyy@live.com) Received: from dub0-omc2-s20.dub0.hotmail.com (dub0-omc2-s20.dub0.hotmail.com [157.55.1.159]) by mx1.freebsd.org (Postfix) with ESMTP id 66AF2A8 for ; Mon, 13 May 2013 09:11:10 +0000 (UTC) Received: from DUB118-W4 ([157.55.1.136]) by dub0-omc2-s20.dub0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 13 May 2013 02:10:04 -0700 X-EIP: [ug1A6xmN8xendynMJ0q8GDpOpHDarxu7] X-Originating-Email: [andriy.kornatskyy@live.com] Message-ID: Content-Type: multipart/mixed; boundary="_f75f8498-aec0-4b12-8d35-d09e3387bf89_" From: Andriy Kornatskyy To: "freebsd-stable@freebsd.org" Subject: kernel panic: ffs_valloc: dup alloc Date: Mon, 13 May 2013 12:10:04 +0300 Importance: Normal MIME-Version: 1.0 X-OriginalArrivalTime: 13 May 2013 09:10:04.0354 (UTC) FILETIME=[A7D3C220:01CE4FB9] X-Mailman-Approved-At: Mon, 13 May 2013 11:38:59 +0000 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 13 May 2013 09:11:12 -0000 --_f75f8498-aec0-4b12-8d35-d09e3387bf89_ Content-Type: text/plain; charset="windows-1251" Content-Transfer-Encoding: quoted-printable The core.txt and info files can be found in attached archive (there are 2 c= rash reports there). If you need vmcores=2C just let me know where I can up= load them.=0A= =0A= ASUS K73E=0A= Architecture: i386=0A= OS:=A0FreeBSD 9.1-RELEASE-p3=0A= =0A= Please let me know should you need some other information.=0A= =0A= Thanks.=0A= =0A= Andriy = --_f75f8498-aec0-4b12-8d35-d09e3387bf89_-- From owner-freebsd-stable@FreeBSD.ORG Mon May 13 12:14:20 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 1A13A92F for ; Mon, 13 May 2013 12:14:20 +0000 (UTC) (envelope-from ronald-freebsd8@klop.yi.org) Received: from smarthost1.greenhost.nl (smarthost1.greenhost.nl [195.190.28.78]) by mx1.freebsd.org (Postfix) with ESMTP id D30A1E3C for ; Mon, 13 May 2013 12:14:19 +0000 (UTC) Received: from smtp.greenhost.nl ([213.108.104.138]) by smarthost1.greenhost.nl with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from ) id 1Ubrdq-0002N1-7E; Mon, 13 May 2013 14:14:11 +0200 Received: from [81.21.138.17] (helo=ronaldradial.versatec.local) by smtp.greenhost.nl with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1Ubrdo-00066z-S0; Mon, 13 May 2013 14:14:08 +0200 Content-Type: text/plain; charset=utf-8; format=flowed; delsp=yes To: "freebsd-stable@freebsd.org" , "Andriy Kornatskyy" Subject: Re: kernel panic: ffs_valloc: dup alloc References: Date: Mon, 13 May 2013 14:14:09 +0200 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit From: "Ronald Klop" Message-ID: In-Reply-To: User-Agent: Opera Mail/12.15 (Win32) X-Virus-Scanned: by clamav at smarthost1.samage.net X-Spam-Level: / X-Spam-Score: -0.0 X-Spam-Status: No, score=-0.0 required=5.0 tests=BAYES_40 autolearn=disabled version=3.3.1 X-Scan-Signature: 739ba1b2be5fabc1cc6069058737919f X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 13 May 2013 12:14:20 -0000 On Mon, 13 May 2013 11:10:04 +0200, Andriy Kornatskyy wrote: > The core.txt and info files can be found in attached archive (there are > 2 crash reports there). If you need vmcores, just let me know where I > can upload them. > > ASUS K73E > Architecture: i386 > OS: FreeBSD 9.1-RELEASE-p3 > > Please let me know should you need some other information. > > Thanks. > > Andriy Attachments are stripped by the mailinglist. Put them inline or on something like http://pastebin.com/. Ronald. From owner-freebsd-stable@FreeBSD.ORG Mon May 13 13:51:25 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id D366E4D6 for ; Mon, 13 May 2013 13:51:25 +0000 (UTC) (envelope-from vanhu@zeninc.net) Received: from smtp.zeninc.net (smtp.zeninc.net [80.67.176.25]) by mx1.freebsd.org (Postfix) with ESMTP id 69982630 for ; Mon, 13 May 2013 13:51:25 +0000 (UTC) Received: from nono (nono.zen.inc [192.168.1.95]) by smtp.zeninc.net (smtpd) with ESMTP id CA2732798D0 for ; Mon, 13 May 2013 15:42:30 +0200 (CEST) Received: by nono (Postfix, from userid 1000) id BC0C720BC6; Mon, 13 May 2013 15:44:15 +0200 (CEST) Date: Mon, 13 May 2013 15:44:15 +0200 From: VANHULLEBUS Yvan To: freebsd-stable@freebsd.org Subject: Re: IKEv2/IPSEC "Road Warrior" VPN Tunneling? Message-ID: <20130513134415.GA20624@zeninc.net> References: <516739C9.4080902@denninger.net> <20130417095719.GH3480@vpn.offrom.nl> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20130417095719.GH3480@vpn.offrom.nl> User-Agent: All mail clients suck. This one just sucks less. X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 13 May 2013 13:51:25 -0000 On Wed, Apr 17, 2013 at 11:57:19AM +0200, Willy Offermans wrote: > Hello Karl and FreeBSD friends, Hi all. > I recall having read about racoon and roadwarrior. Have a look to > /usr/local/share/examples/ipsec-tools/, if you have installed it. I'm also > planning to install this on my server. However I have only little time at > the moment. I'm also looking for examples of configuration files to work > with. First, ipsec-tools is for IKEv1 only, as the subject of the original mail talks about IKEv2. For IKEv1 (with ipsec-tools), the simplest way to do this would be to create a remote "anonymous" and a sainfo "anonymous" section, with "generate_policy" set to on: racoon will negociate phase 1 / phase 2, then will generate SPD entries from peer's proposal. Of course, this means that you'll have to trust what your peers will negociate as traffic endpoints ! If you have some more time to spend on configuration (recommanded !), you can specify traffic endpoints for the sainfo section: valid endpoints (which match the sainfo) negociated by peer will work as described upper, and other traffic endpoints will not negociate, as racoon won't find any related sainfo. Yvan. From owner-freebsd-stable@FreeBSD.ORG Mon May 13 14:25:39 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 8378A63E for ; Mon, 13 May 2013 14:25:39 +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 3781991B for ; Mon, 13 May 2013 14:25:39 +0000 (UTC) Received: from [192.168.1.40] (localhost [127.0.0.1]) by fs.denninger.net (8.14.6/8.13.1) with ESMTP id r4DDuECN066054 for ; Mon, 13 May 2013 08:56:14 -0500 (CDT) (envelope-from karl@denninger.net) Received: from [192.168.1.40] (TLS/SSL) [192.168.1.40] by Spamblock-sys (LOCAL/AUTH); Mon May 13 08:56:14 2013 Message-ID: <5190F0F9.3040908@denninger.net> Date: Mon, 13 May 2013 08:56:09 -0500 From: Karl Denninger User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130215 Thunderbird/17.0.3 MIME-Version: 1.0 To: VANHULLEBUS Yvan Subject: Re: IKEv2/IPSEC "Road Warrior" VPN Tunneling? References: <516739C9.4080902@denninger.net> <20130417095719.GH3480@vpn.offrom.nl> <20130513134415.GA20624@zeninc.net> In-Reply-To: <20130513134415.GA20624@zeninc.net> X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 13 May 2013 14:25:39 -0000 On 5/13/2013 8:44 AM, VANHULLEBUS Yvan wrote: > On Wed, Apr 17, 2013 at 11:57:19AM +0200, Willy Offermans wrote: >> Hello Karl and FreeBSD friends, > Hi all. > >> I recall having read about racoon and roadwarrior. Have a look to >> /usr/local/share/examples/ipsec-tools/, if you have installed it. I'm also >> planning to install this on my server. However I have only little time at >> the moment. I'm also looking for examples of configuration files to work >> with. > First, ipsec-tools is for IKEv1 only, as the subject of the original > mail talks about IKEv2. > > For IKEv1 (with ipsec-tools), the simplest way to do this would be to > create a remote "anonymous" and a sainfo "anonymous" section, with > "generate_policy" set to on: racoon will negociate phase 1 / phase 2, > then will generate SPD entries from peer's proposal. > > Of course, this means that you'll have to trust what your peers will > negociate as traffic endpoints ! > > If you have some more time to spend on configuration (recommanded !), > you can specify traffic endpoints for the sainfo section: valid > endpoints (which match the sainfo) negociated by peer will work as > described upper, and other traffic endpoints will not negociate, as > racoon won't find any related sainfo. > > > Yvan. > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" > > I have successfully configured StrongSwan for IPSEC/IKEv2 and have it operating both with Windows clients and also with the BlackBerry Z-10. It is fast and works very well; I went for the current source directly rather than the port as I wanted to enable a number of options. If readers believe there's value in posting the "recipe" I used here let me know. -- Karl Denninger karl@denninger.net /Cuda Systems LLC/ From owner-freebsd-stable@FreeBSD.ORG Mon May 13 14:36:38 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id C9FC2207; Mon, 13 May 2013 14:36:38 +0000 (UTC) (envelope-from sodynet1@gmail.com) Received: from mail-pb0-x229.google.com (mail-pb0-x229.google.com [IPv6:2607:f8b0:400e:c01::229]) by mx1.freebsd.org (Postfix) with ESMTP id A215DA21; Mon, 13 May 2013 14:36:38 +0000 (UTC) Received: by mail-pb0-f41.google.com with SMTP id xb12so526407pbc.28 for ; Mon, 13 May 2013 07:36:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=FNR8iYEVtl5NXDQ4xG9ZxfMRcVat3MLGgzgRC2cptTQ=; b=yXR0UABBVSqCXj1uAhsVv7pLKHXxlmwS2g+4nfKNJTKvmbhspqvQYASkXE0IoD2NrJ GbSGo4k/QIqhYcMbWLafrxiywOlXGhXijxoGP1t2I2uCFrE3jXYPJRFOP6FOnuNDAUzf A1CPwIC62JpQJCPFMIH8qqPHs8jXAf6NsJWZWxhG0Wn3kf6+IL15O95Ar3Kh/y6+evnF Y5yBZ33+SuHc6OvoK9t2e/+DHLLG6IlrrS9hJPSl3vQXwBLFWCO7ieQvBWKS4AijhNI2 BVq0I4MmL2Hc2zMcIqmLh1pODKrym+k1DshaHR0Jw56wa0bcqBZqc3k3KYbdPV+KnRl6 w+CA== MIME-Version: 1.0 X-Received: by 10.68.49.130 with SMTP id u2mr29409328pbn.124.1368455798494; Mon, 13 May 2013 07:36:38 -0700 (PDT) Received: by 10.70.67.195 with HTTP; Mon, 13 May 2013 07:36:38 -0700 (PDT) Received: by 10.70.67.195 with HTTP; Mon, 13 May 2013 07:36:38 -0700 (PDT) In-Reply-To: <5190F0F9.3040908@denninger.net> References: <516739C9.4080902@denninger.net> <20130417095719.GH3480@vpn.offrom.nl> <20130513134415.GA20624@zeninc.net> <5190F0F9.3040908@denninger.net> Date: Mon, 13 May 2013 17:36:38 +0300 Message-ID: Subject: Re: IKEv2/IPSEC "Road Warrior" VPN Tunneling? From: Sami Halabi To: Karl Denninger Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: VANHULLEBUS Yvan , freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 13 May 2013 14:36:38 -0000 Please share the confs. Sami On May 13, 2013 5:25 PM, "Karl Denninger" wrote: > On 5/13/2013 8:44 AM, VANHULLEBUS Yvan wrote: > > On Wed, Apr 17, 2013 at 11:57:19AM +0200, Willy Offermans wrote: > >> Hello Karl and FreeBSD friends, > > Hi all. > > > >> I recall having read about racoon and roadwarrior. Have a look to > >> /usr/local/share/examples/ipsec-tools/, if you have installed it. I'm > also > >> planning to install this on my server. However I have only little time > at > >> the moment. I'm also looking for examples of configuration files to work > >> with. > > First, ipsec-tools is for IKEv1 only, as the subject of the original > > mail talks about IKEv2. > > > > For IKEv1 (with ipsec-tools), the simplest way to do this would be to > > create a remote "anonymous" and a sainfo "anonymous" section, with > > "generate_policy" set to on: racoon will negociate phase 1 / phase 2, > > then will generate SPD entries from peer's proposal. > > > > Of course, this means that you'll have to trust what your peers will > > negociate as traffic endpoints ! > > > > If you have some more time to spend on configuration (recommanded !), > > you can specify traffic endpoints for the sainfo section: valid > > endpoints (which match the sainfo) negociated by peer will work as > > described upper, and other traffic endpoints will not negociate, as > > racoon won't find any related sainfo. > > > > > > Yvan. > > _______________________________________________ > > freebsd-stable@freebsd.org mailing list > > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org > " > > > > > I have successfully configured StrongSwan for IPSEC/IKEv2 and have it > operating both with Windows clients and also with the BlackBerry Z-10. > It is fast and works very well; I went for the current source directly > rather than the port as I wanted to enable a number of options. > > If readers believe there's value in posting the "recipe" I used here let > me know. > > -- > Karl Denninger > karl@denninger.net > /Cuda Systems LLC/ > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" > From owner-freebsd-stable@FreeBSD.ORG Mon May 13 16:46:56 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 6A567FBD; Mon, 13 May 2013 16:46:56 +0000 (UTC) (envelope-from mikes@siralan.org) Received: from mail.suso.org (mail.suso.org [66.244.94.5]) by mx1.freebsd.org (Postfix) with ESMTP id 46F21820; Mon, 13 May 2013 16:46:56 +0000 (UTC) Received: from c-98-223-197-163.hsd1.in.comcast.net (c-98-223-197-163.hsd1.in.comcast.net [98.223.197.163]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.suso.org (Postfix) with ESMTP id EBA0B138236; Mon, 13 May 2013 16:46:47 +0000 (GMT) Date: Mon, 13 May 2013 12:46:43 -0400 (EDT) From: "Michael L. Squires" X-X-Sender: mikes@familysquires.net To: YongHyeon PYUN Subject: Re: Apparent fxp regression in FreeBSD 8.4-RC3 In-Reply-To: <20130513045630.GB1480@michelle.cdnetworks.com> Message-ID: References: <20130508174721.GD1651@glenbarber.us> <20130513045630.GB1480@michelle.cdnetworks.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: Glen Barber , FreeBSD Release Engineering Team , freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 13 May 2013 16:46:56 -0000 I'm not sure this is a kernel issue. I re-installed 8.3Release p8 (have to get work done!) and then installed a 8.4 Prerelease kernel (I'm still running cvsup, going to svn is a number of crisis problems down from the list of things to fix today). Booted with the 8.4 Prerelease kernel but using the 8.3R p8 world - no problems with fxp0. I've tried that twice, same results. This suggests to me that the problem may not be in 8.4 at all, but in some weirdness of my setup. The motherboard is old; it's one of the Supermicro Xeon boards using the Serverworks chipset which they had to produce when the Intel support chipset turned out to be buggy, which is a number of years ago. I have another box at work which I will set up as my NAT box (the system in question is my NAT box) from scratch with 8.4 and then take the current box off-line, and then reinstall 8.4 from scratch on that system. When that is done I'll report. This probably won't happen until later this week, Friday. No issues with 8.4 with the other two systems at home, one a Tyan S4882 and the other a Tyan S2882. Mike Squires From owner-freebsd-stable@FreeBSD.ORG Mon May 13 16:50:20 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 9C3A231F for ; Mon, 13 May 2013 16:50:20 +0000 (UTC) (envelope-from cross+freebsd@distal.com) Received: from mail1.markmonitor.com (mail1.markmonitor.com [209.66.70.11]) by mx1.freebsd.org (Postfix) with ESMTP id 63E6387A for ; Mon, 13 May 2013 16:50:20 +0000 (UTC) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail1.markmonitor.com (Postfix) with ESMTP id 0CEDE17A48; Mon, 13 May 2013 11:47:42 -0400 (EDT) X-Virus-Scanned: amavisd-new at markmonitor.com Received: from mail1.markmonitor.com ([127.0.0.1]) by localhost (mail1.mm-corp.net [127.0.0.1]) (amavisd-new, port 10024) with LMTP id a5vBYhuOpw0s; Mon, 13 May 2013 11:47:27 -0400 (EDT) Received: from dc-exch4.mm-ads.com (dc-exch4.mm-corp.net [10.112.0.225]) by mail1.markmonitor.com (Postfix) with ESMTP id 4DA2417A28; Mon, 13 May 2013 11:47:27 -0400 (EDT) Received: from zalamar.mm-corp.net ([10.112.52.72]) by dc-exch4.mm-ads.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 13 May 2013 11:47:27 -0400 Subject: Re: Reinstalling boot blocks on a ZFS-only system Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii From: Chris Ross In-Reply-To: <20130513031742.GA75801@icarus.home.lan> Date: Mon, 13 May 2013 11:47:24 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20130512205837.GA69605@icarus.home.lan> <28B5181C-E185-40E5-90EC-9600297BE590@distal.com> <20130513031742.GA75801@icarus.home.lan> To: Jeremy Chadwick X-Mailer: Apple Mail (2.1283) X-OriginalArrivalTime: 13 May 2013 15:47:27.0051 (UTC) FILETIME=[2B2E99B0:01CE4FF1] Cc: "freebsd-stable@freebsd.org" X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 13 May 2013 16:50:20 -0000 On May 12, 2013, at 23:17 , Jeremy Chadwick wrote: > On Sun, May 12, 2013 at 10:20:26PM -0400, Chris Ross wrote: >> In the past, I've found I've been unable to install all of the = bootblocks if I >> boot from the ZFS root. When booting from a cd, the basic: >>=20 >> gpart bootcode -p ${bootdir}/zfsboot ${disk} >> dd if=3D${bootdir}zfsloader of=3D/dev/${disk}a bs=3D512 = oseek=3D1024 conv=3Dnotrunc,sync >>=20 >> works. But, if I boot from ZFS, then I can't dd anything into the = front of the=20 >> drives. Right now, the problem after booting from the CD, is trying = to mount >> a read/write filesystem (mfs, or the like) so that I can scp the = bootblocks onto the >> system and install them. But, I eventually found the command I'd = lost. so I=20 >> think I'm alright. Thanks... >=20 > What does "unable to install" mean? What output/error do you get? I = am > going to assume you get EPERM (Operation not permitted), which would = be > caused by GEOM's "preventive foot-shooting" (keep reading). >=20 > Is there some reason you're sticking with the MBR scheme instead of = GPT? I apologize for all of the noise on the list. I failed to mention the = important detail, which is that I'm working on a sparc64 system, so it's all VTOC8, not = MBR nor GPT. But as noted, I was able to mount an MBR an accomplish what I'd intended when booting from a CD-R. Thanks. - Chris From owner-freebsd-stable@FreeBSD.ORG Mon May 13 21:11:02 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 95DF390F for ; Mon, 13 May 2013 21:11:02 +0000 (UTC) (envelope-from marek_sal@wp.pl) Received: from mx4.wp.pl (mx4.wp.pl [212.77.101.8]) by mx1.freebsd.org (Postfix) with ESMTP id 1B716A89 for ; Mon, 13 May 2013 21:11:01 +0000 (UTC) Received: (wp-smtpd smtp.wp.pl 5052 invoked from network); 13 May 2013 23:10:59 +0200 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=wp.pl; s=1024a; t=1368479459; bh=y9n8+kv6Z4+B8gohNMkf4wMi5dv9Ae/nS7VwsTGHsMo=; h=From:To:CC:Subject; b=Ne2y7oElCZ8tGZrput/IKr9yTvF6UymMw0tyaG21Sym/xej46GbvTo4xMCwt5ttgG CYxr2yvE4zor3tn63MIEPiWjh4r7Zm7Ynu7k3BObLM5NWcs49ZjkMikAXcd4KG/zE8 rg6JMO5jbiKvPUP85lOxkR2v98e/pytUzZCLpwak= Received: from nat.misal.pl (HELO [127.0.0.1]) (marek_sal@[83.19.131.171]) (envelope-sender ) by smtp.wp.pl (WP-SMTPD) with AES256-SHA encrypted SMTP for ; 13 May 2013 23:10:59 +0200 Message-ID: <519156DF.6090307@wp.pl> Date: Mon, 13 May 2013 23:10:55 +0200 From: Marek Salwerowicz User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: Jeremy Chadwick Subject: Re: Build GENERIC with IPX support References: <518ED0CA.4030007@wp.pl> <51900FA5.20204@wp.pl> <5190832E.5040102@wp.pl> <20130513065206.GA78810@icarus.home.lan> In-Reply-To: <20130513065206.GA78810@icarus.home.lan> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 130513-0, 2013-05-13), Outbound message X-Antivirus-Status: Clean X-WP-DKIM-Status: good (id: wp.pl) X-WP-AV: skaner antywirusowy poczty Wirtualnej Polski S. A. X-WP-SPAM: NO 0000000 [sZNk] Cc: bp@butya.kz, Adrian Chadd , "freebsd-stable@freebsd.org" , Marek Salwerowicz , rbp@chat.ru, "illoai@gmail.com" X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 13 May 2013 21:11:02 -0000 W dniu 2013-05-13 08:52, Jeremy Chadwick pisze: > IPX has been neglected for what should be obvious reasons. As someone > who got his CNE back in 1994 (circa Netware 3.11), you're the first > person I have encountered since roughly 1997 who is actively using IPX. > Netware does support TCP/IP, you know... Yes, I am aware of it but in that case I would like to connect to Netware 3.12, which is configured in IPX-only environment. As you see some people still use it, it still works (and works good) and is a perfect back-end for applications and environments working on it. > > Anyway, in your case, you're in luck: > >> #0 0x0000000800d285f7 in strlen () from /lib/libc.so.7 >> #1 0x0000000800d205b0 in gettimeofday () from /lib/libc.so.7 >> #2 0x0000000800d2163e in gettimeofday () from /lib/libc.so.7 >> #3 0x0000000800d21798 in vfprintf_l () from /lib/libc.so.7 >> #4 0x0000000800d0e701 in fprintf () from /lib/libc.so.7 >> #5 0x0000000800822a85 in ncp_error () from /usr/lib/libncp.so.4 >> #6 0x000000080081fa7c in ncp_li_readrc () from /usr/lib/libncp.so.4 > ncp_li_readrc(), which is part of libncp, only has one call to > ncp_error() in it: > > src/lib/libncp/ncpl_conn.c -- > > 180 /* > 181 * read rc file as follows: > 182 * 1. read [server] section > 183 * 2. override with [server:user] section > 184 * Since abcence of rcfile is not a bug, silently ignore that fact. > 185 * rcfile never closed to reduce number of open/close operations. > 186 */ > 187 int > 188 ncp_li_readrc(struct ncp_conn_loginfo *li) { > 189 int i, val, error; > 190 char uname[NCP_BINDERY_NAME_LEN*2+1]; > 191 char *sect = NULL, *p; > 192 > 193 /* > 194 * if info from cmd line incomplete, try to find existing > 195 * connection and fill server/user from it. > 196 */ > 197 if (li->server[0] == 0 || li->user == NULL) { > 198 int connHandle; > 199 struct ncp_conn_stat cs; > 200 > 201 if ((error = ncp_conn_scan(li, &connHandle)) != 0) { > 202 ncp_error("no default connection found", errno); > 203 return error; > 204 } > > To me, this may indicate you have some kind of "ncp rc file" (I believe > this is ~/.nwfsrc according to the ncplist(1) man page) that may contain > something invalid, or maybe you lack such a file altogether (creating one > might work around the problem). Seems you're right. What's more surprising, using % sudo ncplogin Results in no seg fault errors. It creates a file in home directory: arch-gate% sudo file ncplogin.core ncplogin.core: ELF 64-bit LSB core file x86-64, version 1 (FreeBSD), FreeBSD-style, from 'n' arch-gate% But, from shell account it results in segfault. > > Back to the actual segfault itself: ncp_error() is pretty simple: > > src/lib/libncp/ncpl_subr.c -- > > 447 /* > 448 * Print a (descriptive) error message > 449 * error values: > 450 * 0 - no specific error code available; > 451 * -999..-1 - NDS error > 452 * 1..32767 - system error > 453 * the rest - requester error; > 454 */ > 455 void > 456 ncp_error(const char *fmt, int error, ...) { > 457 va_list ap; > 458 > 459 fprintf(stderr, "%s: ", _getprogname()); > 460 va_start(ap, error); > 461 vfprintf(stderr, fmt, ap); > 462 va_end(ap); > 463 if (error == -1) > 464 error = errno; > 465 if (error > -1000 && error < 0) { > 466 fprintf(stderr, ": dserr = %d\n", error); > 467 } else if (error & 0x8000) { > 468 fprintf(stderr, ": nwerr = %04x\n", error); > 469 } else if (error) { > 470 fprintf(stderr, ": syserr = %s\n", strerror(error)); > 471 } else > 472 fprintf(stderr, "\n"); > 473 } > > What I don't understand from the calling stack is how gettimeofday() is > involved. I have looked at the libc code, looked at the underlying > calling functions and so on (from fprintf() to vfprintf_l() and deeper), > and I don't see how or where gettimeofday() would be called. The only > place I can think of might be the related locale stuff, but I'm doubting > that given what I've looked at but could still be wrong. > > Have world/kernel on this system ever been rebuilt? If they have, > were both kernel and world rebuilt together from the same source code > and not at different times? I've installled the 9.1-RELEASE from ISO, then updated using: # freebsd-update fetch install And then recompiled the kernel from sources. I haven't rebuilt the world. > > If you're setting LANG, LC_CTYPE, LC_COLLATE, or other locale-oriented > settings in your environment (and my gut feeling is that you are), you > could try removing them and see if you get an actual useful error > message on stderr, but I'm not holding my breath. No, I don't change any environment variables: arch-gate% sudo env PATH=/sbin:/bin:/usr/sbin:/usr/bin:/usr/games:/usr/local/sbin:/usr/local/bin:/home/marek/bin TERM=xterm SHELL=/usr/local/bin/zsh MAIL=/var/mail/root LOGNAME=root USER=root USERNAME=root HOME=/root SUDO_COMMAND=/usr/bin/env SUDO_USER=marek SUDO_UID=1001 SUDO_GID=1001 arch-gate% root@arch-gate:/home/marek # env _=/usr/bin/su OLDPWD=/home/marek PWD=/home/marek SHLVL=2 USER=root LOGNAME=root HOME=/root MAIL=/var/mail/marek PATH=/sbin:/bin:/usr/sbin:/usr/bin:/usr/games:/usr/local/sbin:/usr/local/bin:/root/bin TERM=xterm BLOCKSIZE=K SHELL=/bin/csh SSH_CLIENT=127.0.0.1 60737 22 SSH_CONNECTION=127.0.0.1 60737 127.0.0.1 22 SSH_TTY=/dev/pts/0 HOSTTYPE=FreeBSD VENDOR=amd OSTYPE=FreeBSD MACHTYPE=x86_64 GROUP=wheel HOST=arch-gate REMOTEHOST=localhost EDITOR=vi PAGER=more root@arch-gate:/home/marek # > > I cannot help you with the remaining IPX-specific "stuff"; it's fairly > obvious though, as I said, that this code has been neglected. Anyway, thanks for help. 3 years ago I've successfully integrated Linux Debian (kernel 2.6.20 as far as I remember) with Netware 3.12. Most likely I'd try to use it also that time instead of FreeBSD if it's not working. -- Marek Salwerowicz From owner-freebsd-stable@FreeBSD.ORG Mon May 13 21:31:13 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 635B21F0 for ; Mon, 13 May 2013 21:31:13 +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 221F9B53 for ; Mon, 13 May 2013 21:31:12 +0000 (UTC) Received: from [192.168.1.40] (localhost [127.0.0.1]) by fs.denninger.net (8.14.6/8.13.1) with ESMTP id r4DLV8Af078132 for ; Mon, 13 May 2013 16:31:08 -0500 (CDT) (envelope-from karl@denninger.net) Received: from [192.168.1.40] (TLS/SSL) [192.168.1.40] by Spamblock-sys (LOCAL/AUTH); Mon May 13 16:31:08 2013 Message-ID: <51915B97.8020009@denninger.net> Date: Mon, 13 May 2013 16:31:03 -0500 From: Karl Denninger User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130215 Thunderbird/17.0.3 MIME-Version: 1.0 To: Sami Halabi Subject: Re: IKEv2/IPSEC "Road Warrior" VPN Tunneling? References: <516739C9.4080902@denninger.net> <20130417095719.GH3480@vpn.offrom.nl> <20130513134415.GA20624@zeninc.net> <5190F0F9.3040908@denninger.net> In-Reply-To: X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: VANHULLEBUS Yvan , freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 13 May 2013 21:31:13 -0000 On 5/13/2013 9:36 AM, Sami Halabi wrote: > Please share the confs. > > Sami > On May 13, 2013 5:25 PM, "Karl Denninger" wrote: > >> On 5/13/2013 8:44 AM, VANHULLEBUS Yvan wrote: >>> On Wed, Apr 17, 2013 at 11:57:19AM +0200, Willy Offermans wrote: >>>> Hello Karl and FreeBSD friends, >>> Hi all. >>> >>>> I recall having read about racoon and roadwarrior. Have a look to >>>> /usr/local/share/examples/ipsec-tools/, if you have installed it. I'm >> also >>>> planning to install this on my server. However I have only little time >> at >>>> the moment. I'm also looking for examples of configuration files to work >>>> with. >>> First, ipsec-tools is for IKEv1 only, as the subject of the original >>> mail talks about IKEv2. >>> >>> For IKEv1 (with ipsec-tools), the simplest way to do this would be to >>> create a remote "anonymous" and a sainfo "anonymous" section, with >>> "generate_policy" set to on: racoon will negociate phase 1 / phase 2, >>> then will generate SPD entries from peer's proposal. >>> >>> Of course, this means that you'll have to trust what your peers will >>> negociate as traffic endpoints ! >>> >>> If you have some more time to spend on configuration (recommanded !), >>> you can specify traffic endpoints for the sainfo section: valid >>> endpoints (which match the sainfo) negociated by peer will work as >>> described upper, and other traffic endpoints will not negociate, as >>> racoon won't find any related sainfo. >>> >>> >>> Yvan. >>> _______________________________________________ >>> freebsd-stable@freebsd.org mailing list >>> http://lists.freebsd.org/mailman/listinfo/freebsd-stable >>> To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org >> " >>> >> I have successfully configured StrongSwan for IPSEC/IKEv2 and have it >> operating both with Windows clients and also with the BlackBerry Z-10. >> It is fast and works very well; I went for the current source directly >> rather than the port as I wanted to enable a number of options. >> >> If readers believe there's value in posting the "recipe" I used here let >> me know. >> >> -- >> Karl Denninger >> karl@denninger.net >> /Cuda Systems LLC/ >> _______________________________________________ >> 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" > > > %SPAMBLOCK-SYS: Matched [@freebsd.org+], message ok Here's a link to a rather long post on setting it up that I put up on my blog that pretty much walks through the details. http://market-ticker.org/akcs-www?post=220395 The configuration for StrongSwan looks like this: # ipsec.conf - strongSwan IPsec configuration file # basic configuration config setup # strictcrlpolicy=yes # uniqueids = no # Add connections here. # Sample VPN connections conn %default keyingtries=1 keyexchange=ikev2 conn BB10 left=%any leftsubnet=0.0.0.0/0 right=%any rightsourceip=192.168.2.0/24 rightid=my@email.address rightauth=psk leftauth=pubkey leftcert=my-host-certificate.pem auto=add conn Win7 left=%any leftsubnet=0.0.0.0/0 leftauth=pubkey leftcert=my-host-certificate.pem leftid=@my-host-name right=%any rightsourceip=192.168.2.0/24 rightauth=eap-mschapv2 rightsendcert=never eap_identity=%any rekey=no dpdaction=clear dpddelay=300s auto=add You must have built StrongSwan with: $ ./configure --enable-kernel-pfkey --enable-kernel-pfroute --disable-kernel-netlink --disable-tools --disable-scripts --with-group=wheel --enable-eap-gtc --enable-xauth-pam --enable-eap-mschapv2 --enable-md4 --enable-eap-identity I have both Windows 7 and BlackBerry 10 clients working against this without problems. -- Karl Denninger karl@denninger.net /Cuda Systems LLC/ From owner-freebsd-stable@FreeBSD.ORG Mon May 13 22:07:00 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 61456240; Mon, 13 May 2013 22:07:00 +0000 (UTC) (envelope-from crodr001@gmail.com) Received: from mail-la0-x22a.google.com (mail-la0-x22a.google.com [IPv6:2a00:1450:4010:c03::22a]) by mx1.freebsd.org (Postfix) with ESMTP id 7DC6ADA5; Mon, 13 May 2013 22:06:59 +0000 (UTC) Received: by mail-la0-f42.google.com with SMTP id er20so3859321lab.29 for ; Mon, 13 May 2013 15:06:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=zhIJzZtEO6qeFrSEddRt1nIzfFgBKM1/mkcX8tc61xg=; b=AXeoZ832Ex/U9JgI+4Yhe5d7JUTvEIgcvNl8o1vOVXIUWCqtyRNdkudVheBF7g++QF 9kz2gXOZm6nOhYTth9sFLoTxbzrTK+jt28Mgxs7fp8lLgfwwN0XDhmuHUr5EPDMozZsc nUTJBDSKdRQO3y99nW3RpGE0hwP3q8HIsHlkrmXbdasKw+mpifppVI6ot3QT3uGifezu BIUZqxjr0vgBfYxdzAix1ZN0YyLw0738NEZEr/wsIA4SwSNl3A1wNOAwse/zHRgyWXK2 RuCDRtgvADu61BAsnxGRTI0cJtpAy8JFatJjcdmeEuYDU4rPYZmixeSe8p8Mrr0/b1Rk POEg== MIME-Version: 1.0 X-Received: by 10.112.138.100 with SMTP id qp4mr14153885lbb.84.1368482818353; Mon, 13 May 2013 15:06:58 -0700 (PDT) Sender: crodr001@gmail.com Received: by 10.112.2.73 with HTTP; Mon, 13 May 2013 15:06:58 -0700 (PDT) In-Reply-To: References: <20130508174721.GD1651@glenbarber.us> Date: Mon, 13 May 2013 15:06:58 -0700 X-Google-Sender-Auth: hqW2FUMKQUu4KZM9xs12RjleUms Message-ID: Subject: Re: Apparent fxp regression in FreeBSD 8.4-RC3 From: Craig Rodrigues To: "Michael L. Squires" Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: Glen Barber , freebsd-stable@freebsd.org, FreeBSD Release Engineering Team X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 13 May 2013 22:07:00 -0000 On Sat, May 11, 2013 at 7:57 PM, Michael L. Squires wrote: > I upgraded to FreeBSD 8.4-RC3 and noticed a problem with the fxp driver on > an older Supermicro single CPU single core Xeon motherboard. > > I know that 8.3-Release does not have this issue, but don't know when in > the updates to that release the regression was introduced. > > I use the fxp driver to connect to a Motorola Surfboard cable modem, and > immediately saw the following occur many times: > > May 10 23:00:04 familysquires kernel: fxp0: link state changed to DOWN > May 10 23:00:04 familysquires dhclient: New Subnet Mask (fxp0): > 255.255.240.0 > May 10 23:00:04 familysquires dhclient: New Broadcast Address (fxp0): > 255.255.25 > 5.255 > May 10 23:00:04 familysquires dhclient: New Routers (fxp0): xx.xxx.xxx.1 > May 10 23:00:06 familysquires kernel: fxp0: link state changed to UP > May 10 23:00:22 familysquires dhclient: New IP Address (fxp0): > xx.xxx.xxx.163 > May 10 23:00:22 familysquires kernel: fxp0: link state changed to DOWN > May 10 23:00:22 familysquires dhclient: New Subnet Mask (fxp0): > 255.255.240.0 > May 10 23:00:22 familysquires dhclient: New Broadcast Address (fxp0): > 255.255.255.255 > May 10 23:00:22 familysquires dhclient: New Routers (fxp0): xx.xxx.xxx.1 > May 10 23:00:24 familysquires kernel: fxp0: link state changed to UP > > repeated without end. > I recently upgraded one of my systems from FreeBSD 7.4 to FreeBSD releng/8, and had DHCP problems. My system though is running a bge NIC, not fxp. I don't know if this solution can help your case, but I found that this helped me. I added the following line to my /etc/rc.conf: synchronous_dhclient="YES" Without that line, my system would not boot up properly with networking working. -- Craig From owner-freebsd-stable@FreeBSD.ORG Tue May 14 02:10:21 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id CDF68D78 for ; Tue, 14 May 2013 02:10:21 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-we0-x22d.google.com (mail-we0-x22d.google.com [IPv6:2a00:1450:400c:c03::22d]) by mx1.freebsd.org (Postfix) with ESMTP id 64C3A8A5 for ; Tue, 14 May 2013 02:10:21 +0000 (UTC) Received: by mail-we0-f173.google.com with SMTP id q54so6767990wes.18 for ; Mon, 13 May 2013 19:10:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=Xat0kmcWZNjaLqUpetdWtXr4gJAB5gBSy0HToj6XGSs=; b=kB+hQyPR5xUfTcF9elbP4YN77ahZr4uiaoXtq87n5MebthFJCWAMRdqEntDWm23SFZ pwfFskGF8UmqClyl58EXq1+hLZdZ6Z9q9+E1qgRo8bgzyQaoQ6vedkMyzEJsPNSPgleu Ij+JB/zMcn+e9S72FMCx7eUxGsWoqB4upS4GIBqQn4r8LMkfxUmGGDPjh5G8k9xsM3ql uq9U9nkAekJgcG6qPu7Lq0Lwup3RJwN4jyVnRSeJltlMYju/qRx9JD8ITkpzKJR6Aj/1 onRRSZ8JmjHXjMQSk6FWytwKXMIKAOLmObgt6LHN/Djp+emo03MpriusacBDJkXARuL0 ja1w== MIME-Version: 1.0 X-Received: by 10.180.89.140 with SMTP id bo12mr1570113wib.22.1368497420580; Mon, 13 May 2013 19:10:20 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.217.58.138 with HTTP; Mon, 13 May 2013 19:10:20 -0700 (PDT) In-Reply-To: <519156DF.6090307@wp.pl> References: <518ED0CA.4030007@wp.pl> <51900FA5.20204@wp.pl> <5190832E.5040102@wp.pl> <20130513065206.GA78810@icarus.home.lan> <519156DF.6090307@wp.pl> Date: Mon, 13 May 2013 19:10:20 -0700 X-Google-Sender-Auth: gjVEMXXyjuLWYIVNHhjMyeYVU0c Message-ID: Subject: Re: Build GENERIC with IPX support From: Adrian Chadd To: Marek Salwerowicz Content-Type: text/plain; charset=ISO-8859-1 Cc: Jeremy Chadwick , bp@butya.kz, "freebsd-stable@freebsd.org" , "illoai@gmail.com" , rbp@chat.ru X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 14 May 2013 02:10:21 -0000 Hi, Are you able to help someone figure out what's going on? The main problem with IPX / netware testing is that we just don't have netware servers lying around. :) Adrian On 13 May 2013 14:10, Marek Salwerowicz wrote: > W dniu 2013-05-13 08:52, Jeremy Chadwick pisze: > >> IPX has been neglected for what should be obvious reasons. As someone >> who got his CNE back in 1994 (circa Netware 3.11), you're the first >> person I have encountered since roughly 1997 who is actively using IPX. >> Netware does support TCP/IP, you know... > > > Yes, I am aware of it but in that case I would like to connect to Netware > 3.12, which is configured in IPX-only environment. > As you see some people still use it, it still works (and works good) and is > a perfect back-end for applications and environments working on it. > > > >> >> Anyway, in your case, you're in luck: >> >>> #0 0x0000000800d285f7 in strlen () from /lib/libc.so.7 >>> #1 0x0000000800d205b0 in gettimeofday () from /lib/libc.so.7 >>> #2 0x0000000800d2163e in gettimeofday () from /lib/libc.so.7 >>> #3 0x0000000800d21798 in vfprintf_l () from /lib/libc.so.7 >>> #4 0x0000000800d0e701 in fprintf () from /lib/libc.so.7 >>> #5 0x0000000800822a85 in ncp_error () from /usr/lib/libncp.so.4 >>> #6 0x000000080081fa7c in ncp_li_readrc () from /usr/lib/libncp.so.4 >> >> ncp_li_readrc(), which is part of libncp, only has one call to >> ncp_error() in it: >> >> src/lib/libncp/ncpl_conn.c -- >> >> 180 /* >> 181 * read rc file as follows: >> 182 * 1. read [server] section >> 183 * 2. override with [server:user] section >> 184 * Since abcence of rcfile is not a bug, silently ignore that fact. >> 185 * rcfile never closed to reduce number of open/close operations. >> 186 */ >> 187 int >> 188 ncp_li_readrc(struct ncp_conn_loginfo *li) { >> 189 int i, val, error; >> 190 char uname[NCP_BINDERY_NAME_LEN*2+1]; >> 191 char *sect = NULL, *p; >> 192 >> 193 /* >> 194 * if info from cmd line incomplete, try to find existing >> 195 * connection and fill server/user from it. >> 196 */ >> 197 if (li->server[0] == 0 || li->user == NULL) { >> 198 int connHandle; >> 199 struct ncp_conn_stat cs; >> 200 >> 201 if ((error = ncp_conn_scan(li, &connHandle)) != 0) { >> 202 ncp_error("no default connection found", >> errno); >> 203 return error; >> 204 } >> >> To me, this may indicate you have some kind of "ncp rc file" (I believe >> this is ~/.nwfsrc according to the ncplist(1) man page) that may contain >> something invalid, or maybe you lack such a file altogether (creating one >> might work around the problem). > > > Seems you're right. What's more surprising, using > > % sudo ncplogin > > Results in no seg fault errors. > > It creates a file in home directory: > arch-gate% sudo file ncplogin.core > ncplogin.core: ELF 64-bit LSB core file x86-64, version 1 (FreeBSD), > FreeBSD-style, from 'n' > arch-gate% > > But, from shell account it results in segfault. > > > >> >> Back to the actual segfault itself: ncp_error() is pretty simple: >> >> src/lib/libncp/ncpl_subr.c -- >> >> 447 /* >> 448 * Print a (descriptive) error message >> 449 * error values: >> 450 * 0 - no specific error code available; >> 451 * -999..-1 - NDS error >> 452 * 1..32767 - system error >> 453 * the rest - requester error; >> 454 */ >> 455 void >> 456 ncp_error(const char *fmt, int error, ...) { >> 457 va_list ap; >> 458 >> 459 fprintf(stderr, "%s: ", _getprogname()); >> 460 va_start(ap, error); >> 461 vfprintf(stderr, fmt, ap); >> 462 va_end(ap); >> 463 if (error == -1) >> 464 error = errno; >> 465 if (error > -1000 && error < 0) { >> 466 fprintf(stderr, ": dserr = %d\n", error); >> 467 } else if (error & 0x8000) { >> 468 fprintf(stderr, ": nwerr = %04x\n", error); >> 469 } else if (error) { >> 470 fprintf(stderr, ": syserr = %s\n", strerror(error)); >> 471 } else >> 472 fprintf(stderr, "\n"); >> 473 } >> >> What I don't understand from the calling stack is how gettimeofday() is >> involved. I have looked at the libc code, looked at the underlying >> calling functions and so on (from fprintf() to vfprintf_l() and deeper), >> and I don't see how or where gettimeofday() would be called. The only >> place I can think of might be the related locale stuff, but I'm doubting >> that given what I've looked at but could still be wrong. >> >> Have world/kernel on this system ever been rebuilt? If they have, >> were both kernel and world rebuilt together from the same source code >> and not at different times? > > I've installled the 9.1-RELEASE from ISO, then updated using: > # freebsd-update fetch install > > And then recompiled the kernel from sources. > I haven't rebuilt the world. > > >> >> If you're setting LANG, LC_CTYPE, LC_COLLATE, or other locale-oriented >> settings in your environment (and my gut feeling is that you are), you >> could try removing them and see if you get an actual useful error >> message on stderr, but I'm not holding my breath. > > No, I don't change any environment variables: > arch-gate% sudo env > PATH=/sbin:/bin:/usr/sbin:/usr/bin:/usr/games:/usr/local/sbin:/usr/local/bin:/home/marek/bin > TERM=xterm > SHELL=/usr/local/bin/zsh > MAIL=/var/mail/root > LOGNAME=root > USER=root > USERNAME=root > HOME=/root > SUDO_COMMAND=/usr/bin/env > SUDO_USER=marek > SUDO_UID=1001 > SUDO_GID=1001 > arch-gate% > > root@arch-gate:/home/marek # env > _=/usr/bin/su > OLDPWD=/home/marek > PWD=/home/marek > SHLVL=2 > USER=root > LOGNAME=root > HOME=/root > MAIL=/var/mail/marek > PATH=/sbin:/bin:/usr/sbin:/usr/bin:/usr/games:/usr/local/sbin:/usr/local/bin:/root/bin > TERM=xterm > BLOCKSIZE=K > SHELL=/bin/csh > SSH_CLIENT=127.0.0.1 60737 22 > SSH_CONNECTION=127.0.0.1 60737 127.0.0.1 22 > SSH_TTY=/dev/pts/0 > HOSTTYPE=FreeBSD > VENDOR=amd > OSTYPE=FreeBSD > MACHTYPE=x86_64 > GROUP=wheel > HOST=arch-gate > REMOTEHOST=localhost > EDITOR=vi > PAGER=more > root@arch-gate:/home/marek # > > > > >> >> I cannot help you with the remaining IPX-specific "stuff"; it's fairly >> obvious though, as I said, that this code has been neglected. > > Anyway, thanks for help. > > 3 years ago I've successfully integrated Linux Debian (kernel 2.6.20 as far > as I remember) with Netware 3.12. > Most likely I'd try to use it also that time instead of FreeBSD if it's not > working. > > -- > Marek Salwerowicz > From owner-freebsd-stable@FreeBSD.ORG Tue May 14 07:06:11 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id AA366EC9 for ; Tue, 14 May 2013 07:06:11 +0000 (UTC) (envelope-from andriy.kornatskyy@live.com) Received: from dub0-omc2-s12.dub0.hotmail.com (dub0-omc2-s12.dub0.hotmail.com [157.55.1.151]) by mx1.freebsd.org (Postfix) with ESMTP id 52B1E68F for ; Tue, 14 May 2013 07:06:10 +0000 (UTC) Received: from DUB118-W48 ([157.55.1.137]) by dub0-omc2-s12.dub0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 14 May 2013 00:04:57 -0700 X-EIP: [KBrPUV7Vpg75K7QNUMYIo+/pGDcUG5FX] X-Originating-Email: [andriy.kornatskyy@live.com] Message-ID: From: Andriy Kornatskyy To: "freebsd-stable@freebsd.org" Subject: RE: kernel panic: ffs_valloc: dup alloc Date: Tue, 14 May 2013 10:04:57 +0300 Importance: Normal In-Reply-To: References: , Content-Type: text/plain; charset="windows-1251" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 14 May 2013 07:04:57.0513 (UTC) FILETIME=[57D07990:01CE5071] X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 14 May 2013 07:06:11 -0000 A part of core.txt file is here:=0A= http://pastebin.com/gygnMh6G=0A= =0A= Andriy=0A= =0A= --------------------- info ------------------=0A= =0A= Dump header from device /dev/ada0s1b=0A= =A0 Architecture: i386=0A= =A0 Architecture Version: 2=0A= =A0 Dump Length: 232882176B (222 MB)=0A= =A0 Blocksize: 512=0A= =A0 Dumptime: Fri May 10 15:39:57 2013=0A= =A0 Hostname: freex=0A= =A0 Magic: FreeBSD Kernel Dump=0A= =A0 Version String: FreeBSD 9.1-RELEASE-p3 #0: Mon Apr 29 18:11:52 UTC 2013= =0A= =A0 =A0 root@amd64-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC=0A= =A0 Panic String: ffs_valloc: dup alloc=0A= =A0 Dump Parity: 4278856205=0A= =A0 Bounds: 0=0A= =A0 Dump Status: good=0A= =0A= =0A= ----------------------------------------=0A= > To: freebsd-stable@freebsd.org=3B andriy.kornatskyy@live.com=0A= > Subject: Re: kernel panic: ffs_valloc: dup alloc=0A= > Date: Mon=2C 13 May 2013 14:14:09 +0200=0A= > From: ronald-freebsd8@klop.yi.org=0A= >=0A= > On Mon=2C 13 May 2013 11:10:04 +0200=2C Andriy Kornatskyy=0A= > wrote:=0A= >=0A= > > The core.txt and info files can be found in attached archive (there are= =0A= > > 2 crash reports there). If you need vmcores=2C just let me know where I= =0A= > > can upload them.=0A= > >=0A= > > ASUS K73E=0A= > > Architecture: i386=0A= > > OS: FreeBSD 9.1-RELEASE-p3=0A= > >=0A= > > Please let me know should you need some other information.=0A= > >=0A= > > Thanks.=0A= > >=0A= > > Andriy=0A= >=0A= > Attachments are stripped by the mailinglist. Put them inline or on=0A= > something like http://pastebin.com/.=0A= >=0A= > Ronald.=0A= > _______________________________________________=0A= > freebsd-stable@freebsd.org mailing list=0A= > http://lists.freebsd.org/mailman/listinfo/freebsd-stable=0A= > To unsubscribe=2C send any mail to "freebsd-stable-unsubscribe@freebsd.or= g" = From owner-freebsd-stable@FreeBSD.ORG Tue May 14 10:40:03 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id CAF3D5C0 for ; Tue, 14 May 2013 10:40:03 +0000 (UTC) (envelope-from rainer@ultra-secure.de) Received: from mail.ultra-secure.de (mail.ultra-secure.de [78.47.114.122]) by mx1.freebsd.org (Postfix) with ESMTP id 14EC8F1 for ; Tue, 14 May 2013 10:40:02 +0000 (UTC) Received: (qmail 33933 invoked by uid 89); 14 May 2013 10:36:45 -0000 Received: by simscan 1.4.0 ppid: 33928, pid: 33930, t: 0.1288s scanners: attach: 1.4.0 clamav: 0.97.3/m:54/d:17205 Received: from unknown (HELO suse3) (rainer@ultra-secure.de@212.71.117.1) by mail.ultra-secure.de with ESMTPA; 14 May 2013 10:36:44 -0000 Date: Tue, 14 May 2013 12:36:44 +0200 From: Rainer Duffner To: freebsd-stable@freebsd.org Subject: How to get pkgng work through a proxy? Message-ID: <20130514123644.4b5a53af@suse3> X-Mailer: Claws Mail 3.8.1 (GTK+ 2.24.10; x86_64-suse-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 14 May 2013 10:40:03 -0000 Hi, I have this host (a cloned VM, FreeBSD 9.1 AMD64) behind an Astaro Web-Proxy: (blahost ) 70 # pkg update [12:00] Updating repository catalogue repo.txz 3% 10KB 0.5KB/s 0.0KB/s - stalled -pkg: http://pkgng.our.repo/91amd64-91patch/repo.txz: Operation timed out It's a proxy with authentication. I'm not sure if it's a fetch(3) problem in general. Because a single fetch from the same server of a small and large file does work, though a bit slow. pkg is 1.0.2 From owner-freebsd-stable@FreeBSD.ORG Tue May 14 14:58:02 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id B2EDF995 for ; Tue, 14 May 2013 14:58:02 +0000 (UTC) (envelope-from lars@e-new.0x20.net) Received: from mail.0x20.net (mail.0x20.net [217.69.76.211]) by mx1.freebsd.org (Postfix) with ESMTP id 7838BFE9 for ; Tue, 14 May 2013 14:58:02 +0000 (UTC) Received: from e-new.0x20.net (mail.0x20.net [IPv6:2001:aa8:fffb:1::3]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.0x20.net (Postfix) with ESMTPS id 7F03C6A6002; Tue, 14 May 2013 16:58:01 +0200 (CEST) Received: from e-new.0x20.net (localhost [127.0.0.1]) by e-new.0x20.net (8.14.5/8.14.5) with ESMTP id r4EEw15O012111; Tue, 14 May 2013 16:58:01 +0200 (CEST) (envelope-from lars@e-new.0x20.net) Received: (from lars@localhost) by e-new.0x20.net (8.14.5/8.14.5/Submit) id r4EEw1wf009249; Tue, 14 May 2013 16:58:01 +0200 (CEST) (envelope-from lars) Date: Tue, 14 May 2013 16:58:01 +0200 From: Lars Engels To: Rainer Duffner Subject: Re: How to get pkgng work through a proxy? Message-ID: <20130514145801.GE32935@e-new.0x20.net> References: <20130514123644.4b5a53af@suse3> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="2IUIi54rL+LZyXu+" Content-Disposition: inline In-Reply-To: <20130514123644.4b5a53af@suse3> X-Editor: VIM - Vi IMproved 7.3 X-Operation-System: FreeBSD 8.3-RELEASE-p5 User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 14 May 2013 14:58:02 -0000 --2IUIi54rL+LZyXu+ Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, May 14, 2013 at 12:36:44PM +0200, Rainer Duffner wrote: > Hi, >=20 > I have this host (a cloned VM, FreeBSD 9.1 AMD64) behind an Astaro > Web-Proxy: >=20 >=20 > (blahost ) 70 # pkg > update > [12:00] Updating repository catalogue > repo.txz 3% > 10KB 0.5KB/s 0.0KB/s - stalled -pkg: > http://pkgng.our.repo/91amd64-91patch/repo.txz: Operation timed out >=20 >=20 > It's a proxy with authentication. >=20 > I'm not sure if it's a fetch(3) problem in general. > Because a single fetch from the same server of a small and large file > does work, though a bit slow. >=20 > pkg is 1.0.2 It's working here with these env vars set: http_proxy=3Dhttp://:@:8080 ftp_proxy=3Dhttp://:@:8080 HTTP_PROXY=3Dhttp://:@:8080 FTP_PROXY=3Dhttp://:@:8080 HTTP_PROXY_AUTH=3Dbasic:*:: But I can't tell which one get's pulled in. --2IUIi54rL+LZyXu+ Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iEYEARECAAYFAlGSUPkACgkQKc512sD3afgILwCfaG1Qg/oPd4NaAhMJY/C6F+7D DboAniwk37s2OCOTLe+w4MknH+98BqQ6 =czHm -----END PGP SIGNATURE----- --2IUIi54rL+LZyXu+-- From owner-freebsd-stable@FreeBSD.ORG Tue May 14 16:03:13 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id C42779F4 for ; Tue, 14 May 2013 16:03:13 +0000 (UTC) (envelope-from tevans.uk@googlemail.com) Received: from mail-la0-x229.google.com (mail-la0-x229.google.com [IPv6:2a00:1450:4010:c03::229]) by mx1.freebsd.org (Postfix) with ESMTP id 505DA63D for ; Tue, 14 May 2013 16:03:13 +0000 (UTC) Received: by mail-la0-f41.google.com with SMTP id lx15so730062lab.28 for ; Tue, 14 May 2013 09:03:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=esKm3qCOJFZhNsUIc0XAvatYQ5ngxNC/BFiii563t8A=; b=mWRvv81pe9dsvDhqqWkrzKkrYMSpNjkRNiCz+2k2MeoT5Lton0UBTMaVM9JkaXsodU 4d3XzmSZ1T2ya9DVKGxMIYctXR48MKrYDHpkE7PN04tQ3/LScmy9reHwV/WUPOSNpz7G kC7+eLPT8ZnmO1cR6w+fB+U3gKMmLy07nOMJ59iJJ/zHGnZV2W9OceJC8UuQ4B/jMXe1 FozlZLQtEUZ+UnoR7UrrDrtZdPDb1+m6hEBn+ovSACwFXlT4ybYC5piltd00DpBSx9/g Grym0AFP5EHqiO2+Z8jSc5FpPthyhisdHidJnW4DzG61yZEbr/9zHYqoDZKG6KtKh3+F P2vQ== MIME-Version: 1.0 X-Received: by 10.112.35.69 with SMTP id f5mr15294954lbj.105.1368547392122; Tue, 14 May 2013 09:03:12 -0700 (PDT) Received: by 10.112.202.137 with HTTP; Tue, 14 May 2013 09:03:12 -0700 (PDT) In-Reply-To: <20130514145801.GE32935@e-new.0x20.net> References: <20130514123644.4b5a53af@suse3> <20130514145801.GE32935@e-new.0x20.net> Date: Tue, 14 May 2013 17:03:12 +0100 Message-ID: Subject: Re: How to get pkgng work through a proxy? From: Tom Evans To: Lars Engels Content-Type: text/plain; charset=UTF-8 Cc: freebsd-stable@freebsd.org, Rainer Duffner X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 14 May 2013 16:03:13 -0000 On Tue, May 14, 2013 at 3:58 PM, Lars Engels wrote: > On Tue, May 14, 2013 at 12:36:44PM +0200, Rainer Duffner wrote: >> Hi, >> >> I have this host (a cloned VM, FreeBSD 9.1 AMD64) behind an Astaro >> Web-Proxy: >> >> >> (blahost ) 70 # pkg >> update >> [12:00] Updating repository catalogue >> repo.txz 3% >> 10KB 0.5KB/s 0.0KB/s - stalled -pkg: >> http://pkgng.our.repo/91amd64-91patch/repo.txz: Operation timed out >> >> >> It's a proxy with authentication. >> >> I'm not sure if it's a fetch(3) problem in general. >> Because a single fetch from the same server of a small and large file >> does work, though a bit slow. >> >> pkg is 1.0.2 > > It's working here with these env vars set: > > http_proxy=http://:@:8080 > ftp_proxy=http://:@:8080 > HTTP_PROXY=http://:@:8080 > FTP_PROXY=http://:@:8080 > HTTP_PROXY_AUTH=basic:*:: > > > But I can't tell which one get's pulled in. My work require proxy authentication also, with the annoying requirement that the username is my email address, which ultimately means that I cannot insert username/pass into http_proxy or variants. libfetch is smart enough to pull these out of HTTP_PROXY_AUTH, but very few other applications are. Eventually, I gave up trying to convince all these disparate applications to discover my proxy auth, and instead I set up a local copy of squid on my laptop, which I point at my upstream proxy and provide with authentication details. I can then use this unauthenticated proxy on localhost to access my corporate proxy fully authenticated. It's a bit of hassle in the short term, but all proxy setup becomes much simpler with it in place. IIRC, the only lines I added to squid.conf's defaults were these: http_port 127.0.0.1:3128 cache_peer parent 3128 0 proxy-only default login=: Cheers Tom From owner-freebsd-stable@FreeBSD.ORG Tue May 14 19:16:49 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id E7FE7853 for ; Tue, 14 May 2013 19:16:49 +0000 (UTC) (envelope-from jean-sebastien.pedron@dumbbell.fr) Received: from mail.made4.biz (ns25270.ovh.net [91.121.29.24]) by mx1.freebsd.org (Postfix) with ESMTP id B1F80383 for ; Tue, 14 May 2013 19:16:49 +0000 (UTC) Received: from 141.7.19.93.rev.sfr.net ([93.19.7.141] helo=magellan.dumbbell.fr) by mail.made4.biz with esmtpsa (TLSv1:DHE-RSA-CAMELLIA256-SHA:256) (Exim 4.80.1 (FreeBSD)) (envelope-from ) id 1UcKh5-0005Qu-JY for freebsd-stable@freebsd.org; Tue, 14 May 2013 21:15:30 +0200 Message-ID: <51928D4F.2040704@dumbbell.fr> Date: Tue, 14 May 2013 21:15:27 +0200 From: =?ISO-8859-1?Q?Jean-S=E9bastien_P=E9dron?= User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130404 Thunderbird/17.0.5 MIME-Version: 1.0 To: freebsd-stable@freebsd.org Subject: Re: freebsd-update and /boot/kernel/linker.hints References: <1636055.7lG3Jua4h4@wolfgang> In-Reply-To: <1636055.7lG3Jua4h4@wolfgang> X-Enigmail-Version: 1.5.1 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="----enig2TSKVDLXGCGEJPULTVLEB" X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 14 May 2013 19:16:50 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) ------enig2TSKVDLXGCGEJPULTVLEB Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 13.05.2013 11:22, Wolfgang Riegler wrote: > since last freebsd-update fetch install I always get this message after= freebsd-update fetch: >=20 > The following files will be updated as part of updating to 9.1-RELEASE-= p3: > /boot/kernel/linker.hints >=20 > but freebsd-update install doesn't install anything. I have exactly the same problem but didn't have the time to investigate deeper... --=20 Jean-S=E9bastien P=E9dron ------enig2TSKVDLXGCGEJPULTVLEB 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.20 (FreeBSD) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlGSjU8ACgkQa+xGJsFYOlMqxQCeJmVEu5ukFd0Jf/BGjd2lYAYY +UoAnjo/koS4tn5aF3Q8HWUgzUet0cT3 =uSOV -----END PGP SIGNATURE----- ------enig2TSKVDLXGCGEJPULTVLEB-- From owner-freebsd-stable@FreeBSD.ORG Wed May 15 05:00:41 2013 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id CD8B877A; Wed, 15 May 2013 05:00:41 +0000 (UTC) (envelope-from outbackdingo@gmail.com) Received: from mail1.ozon.ru (mx4.ozon.ru [194.186.179.140]) by mx1.freebsd.org (Postfix) with ESMTP id 5F33294B; Wed, 15 May 2013 05:00:41 +0000 (UTC) Received: from intmail03msk.ozon (intmail03msk.ozon [10.18.18.171]) by mail1.ozon.ru (Postfix) with ESMTP id A17E9719E76; Wed, 15 May 2013 09:00:40 +0400 (MSK) Received: from mail pickup service by intmail03msk.ozon with Microsoft SMTPSVC; Wed, 15 May 2013 08:56:06 +0400 Received: from intmail03msk.ozon ([10.18.18.171]) by intmail02msk.ozon with Microsoft SMTPSVC(6.0.3790.4675); Sun, 12 May 2013 22:57:11 +0400 Received: from mail1.ozon.ru ([194.186.179.140]) by intmail03msk.ozon with Microsoft SMTPSVC(6.0.3790.4675); Sun, 12 May 2013 22:57:11 +0400 Received: from localhost (localhost [127.0.0.1]) by mail1.ozon.ru (Postfix) with ESMTP id 85BE97195DF for ; Sun, 12 May 2013 22:57:11 +0400 (MSK) X-Virus-Scanned: amavisd-new at ozon.ru Received: from mail1.ozon.ru ([127.0.0.1]) by localhost (mx4.ozon.ru [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tAtM0g6zg-Ca for ; Sun, 12 May 2013 22:57:04 +0400 (MSK) X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6 Received-SPF: pass (freebsd.org: 8.8.178.116 is authorized to use 'owner-freebsd-current@freebsd.org' in 'mfrom' identity (mechanism 'ip4:8.8.178.116' matched)) receiver=mx4.ozon.ru; identity=mfrom; envelope-from="owner-freebsd-current@freebsd.org"; helo=mx2.freebsd.org; client-ip=8.8.178.116 Received: from mx2.freebsd.org (mx2.FreeBSD.org [8.8.178.116]) by mail1.ozon.ru (Postfix) with ESMTP id 7B57871965E for ; Sun, 12 May 2013 22:57:03 +0400 (MSK) Received: from hub.freebsd.org (hub.freebsd.org [IPv6:2001:1900:2254:206c::16:88]) by mx2.freebsd.org (Postfix) with ESMTP id 53E5823DA; Sun, 12 May 2013 18:56:58 +0000 (UTC) Received: from hub.freebsd.org (hub.freebsd.org [IPv6:2001:1900:2254:206c::16:88]) by hub.freebsd.org (Postfix) with ESMTP id 29FB2641; Sun, 12 May 2013 18:56:58 +0000 (UTC) (envelope-from owner-freebsd-current@freebsd.org) Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id DF566554; Sun, 12 May 2013 18:56:54 +0000 (UTC) (envelope-from outbackdingo@gmail.com) Received: from mail-ob0-x22e.google.com (mail-ob0-x22e.google.com [IPv6:2607:f8b0:4003:c01::22e]) by mx1.freebsd.org (Postfix) with ESMTP id 89F9C98F; Sun, 12 May 2013 18:56:54 +0000 (UTC) Received: by mail-ob0-f174.google.com with SMTP id un3so794108obb.5 for ; Sun, 12 May 2013 11:56:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=AlYy3tO43JYaan/9H2V4y2UM9PgQQ+RI/HNMFRv1Go0=; b=WP2COk1Zx6lNZYtI2e939viqdSZtgbJGDEKEAUjq9gQUBQ49d+I0U2fjmu56Z3D9sJ Tm61zTOPhZWvP0C1SPLfme42w/HKcYOumdGOcjK2hqyT22/pxH1++O55pKRaE+kCPwiU 8m28TmVJn7+gMTmGlCWu2rqidquFSPpCdTX7XhCzwJvelAywZjw7BHTjoUMqypgfd91p 3cVz0nZTjheVPz6DxzDmm6aqAGHEiAoJpgNkIfz6PJXoz8hG/xATvL1RgAzSFCrnGD79 Wgv8KBe1OD4KRZWrg5vz+G1Fmls2ivlPdfaKRncj9I5BsF3FIJEJOevetyZdwtDLtkDc /Owg== MIME-Version: 1.0 X-Received: by 10.60.56.132 with SMTP id a4mr2534426oeq.113.1368385013793; Sun, 12 May 2013 11:56:53 -0700 (PDT) Received: by 10.76.96.49 with HTTP; Sun, 12 May 2013 11:56:53 -0700 (PDT) In-Reply-To: <20130512195405.04653b64@funktor> References: <20130512195405.04653b64@funktor> Date: Sun, 12 May 2013 14:56:53 -0400 Message-ID: Subject: Re: FreeBSD Quarterly Status Report, January-March 2013 From: Outback Dingo To: Gabor Pali X-Content-Filtered-By: Mailman/MimeDel 2.1.14 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: owner-freebsd-current@freebsd.org Sender: owner-freebsd-current@freebsd.org X-OriginalArrivalTime: 12 May 2013 18:57:11.0416 (UTC) FILETIME=[82611780:01CE4F42] Cc: stable@freebsd.org, hackers@freebsd.org, current@freebsd.org X-BeenThere: freebsd-stable@freebsd.org List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 May 2013 05:00:41 -0000 __________________________________________________________________ > > FreeNAS > > URL: http://www.FreeNAS.org/ > > Contact: Alfred Perlstein > Contact: Josh Paetzel > > FreeNAS 8.3.1-RELEASE-p2 will hit Sourceforge the second week of April, > and should end up as the last FreeNAS release based on FreeBSD 8.X It's > currently the only Free Open Source NAS product available with any form > of ZFS encryption (provided by GELI). > > Open tasks: > > 1. The team is hard at work on getting a FreeBSD 9.X-based release of > FreeNAS ready. Currently there are several nightly snapshots > available. > 2. Add HAST to the webinterface. > 3. Migrate to NFSv4. > 4. Integrate foundation sponsored kernel iSCSI target. > Uhmmmmmm WHAT??? FreeNAS is not the only Free Open Source NAS product available with any form of ZFS encryption (provided by GELI). NAS4Free has been doing it. _______________________________________________ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" From owner-freebsd-stable@FreeBSD.ORG Wed May 15 05:02:10 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 5A0FBC03; Wed, 15 May 2013 05:02:10 +0000 (UTC) (envelope-from wolfgang@riegler.homeip.net) Received: from mail1.ozon.ru (mx4.ozon.ru [194.186.179.140]) by mx1.freebsd.org (Postfix) with ESMTP id E06819C1; Wed, 15 May 2013 05:02:09 +0000 (UTC) Received: from intmail03msk.ozon (intmail03msk.ozon [10.18.18.171]) by mail1.ozon.ru (Postfix) with ESMTP id EE36671A51F; Wed, 15 May 2013 09:02:08 +0400 (MSK) Received: from mail pickup service by intmail03msk.ozon with Microsoft SMTPSVC; Wed, 15 May 2013 08:58:04 +0400 Received: from intmail03msk.ozon ([10.18.18.171]) by intmail02msk.ozon with Microsoft SMTPSVC(6.0.3790.4675); Mon, 13 May 2013 13:30:35 +0400 Received: from mail1.ozon.ru ([194.186.179.140]) by intmail03msk.ozon with Microsoft SMTPSVC(6.0.3790.4675); Mon, 13 May 2013 13:30:33 +0400 Received: from localhost (localhost [127.0.0.1]) by mail1.ozon.ru (Postfix) with ESMTP id B939B719330 for ; Mon, 13 May 2013 13:30:33 +0400 (MSK) X-Virus-Scanned: amavisd-new at ozon.ru Received: from mail1.ozon.ru ([127.0.0.1]) by localhost (mx4.ozon.ru [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b4PcDZyxSlLr for ; Mon, 13 May 2013 13:30:25 +0400 (MSK) X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6 Received-SPF: pass (freebsd.org: 8.8.178.116 is authorized to use 'owner-freebsd-questions@freebsd.org' in 'mfrom' identity (mechanism 'ip4:8.8.178.116' matched)) receiver=mx4.ozon.ru; identity=mfrom; envelope-from="owner-freebsd-questions@freebsd.org"; helo=mx2.freebsd.org; client-ip=8.8.178.116 Received: from mx2.freebsd.org (mx2.FreeBSD.org [8.8.178.116]) by mail1.ozon.ru (Postfix) with ESMTP id E41A571953C for ; Mon, 13 May 2013 13:30:24 +0400 (MSK) Received: from hub.freebsd.org (hub.freebsd.org [IPv6:2001:1900:2254:206c::16:88]) by mx2.freebsd.org (Postfix) with ESMTP id AE1A756E0; Mon, 13 May 2013 09:30:23 +0000 (UTC) Received: from hub.freebsd.org (hub.freebsd.org [IPv6:2001:1900:2254:206c::16:88]) by hub.freebsd.org (Postfix) with ESMTP id AB9E6E94; Mon, 13 May 2013 09:30:23 +0000 (UTC) (envelope-from owner-freebsd-questions@freebsd.org) Delivered-To: freebsd-questions@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id C7137E17 for ; Mon, 13 May 2013 09:30:15 +0000 (UTC) (envelope-from wolfgang@riegler.homeip.net) Received: from slave1.cbt-l.de (slave1.cbt-l.de [178.77.79.191]) by mx1.freebsd.org (Postfix) with ESMTP id 81BC7183 for ; Mon, 13 May 2013 09:30:15 +0000 (UTC) Received: from localhost (slave1.cbt-l.de [127.0.0.1]) by slave1.cbt-l.de (Postfix) with ESMTP id A594215F00F9 for ; Mon, 13 May 2013 11:22:42 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at slave1.cbt-l.de Received: from slave1.cbt-l.de ([127.0.0.1]) by localhost (slave1.cbt-l.de [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id siNLYJCAo-aC for ; Mon, 13 May 2013 11:22:42 +0200 (CEST) Received: from mail.cbt-l.de (mail.cbt-l.de [212.185.49.146]) by slave1.cbt-l.de (Postfix) with ESMTP id 742CB15F00F8 for ; Mon, 13 May 2013 11:22:42 +0200 (CEST) Received: (qmail 80518 invoked by uid 1009); 13 May 2013 09:22:42 -0000 Received: from 192.168.40.46 by mail.cbt-l.de (envelope-from , uid 1008) with qmail-scanner-1.25-st-qms (clamdscan: ClamAV 0.97.8/17095. spamassassin: 3.3.0. perlscan: 1.25-st-qms. Clear:RC:1(192.168.40.46):. Processed in 0.058164 secs); 13 May 2013 09:22:42 -0000 X-Antivirus-CBTL-Mail-From: wolfgang@riegler.homeip.net via mail.cbt-l.de X-Antivirus-CBTL: 1.25-st-qms (Clear:RC:1(192.168.40.46):. Processed in 0.058164 secs Process 80408) Received: from wolfgang.cbt-l.de (HELO wolfgang.localnet) (w.riegler@cbt-l.de@192.168.40.46) by mail.cbt-l.de with SMTP; 13 May 2013 09:22:42 -0000 From: Wolfgang Riegler To: freebsd-questions@freebsd.org, freebsd-stable@freebsd.org Subject: freebsd-update and /boot/kernel/linker.hints Date: Mon, 13 May 2013 11:22:41 +0200 Message-ID: <1636055.7lG3Jua4h4@wolfgang> User-Agent: KMail/4.10.2 (Linux/3.8.2-pf-sepp1; KDE/4.10.2; x86_64; ; ) MIME-Version: 1.0 X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: owner-freebsd-questions@freebsd.org Sender: owner-freebsd-questions@freebsd.org X-OriginalArrivalTime: 13 May 2013 09:30:33.0784 (UTC) FILETIME=[849FE380:01CE4FBC] X-BeenThere: freebsd-stable@freebsd.org List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 May 2013 05:02:10 -0000 Hi, since last freebsd-update fetch install I always get this message after freebsd-update fetch: The following files will be updated as part of updating to 9.1-RELEASE-p3: /boot/kernel/linker.hints but freebsd-update install doesn't install anything. Is there something wrong with my system or is this a bug in freebsd-update? kind regards Wolfgang _______________________________________________ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "freebsd-questions-unsubscribe@freebsd.org" From owner-freebsd-stable@FreeBSD.ORG Wed May 15 05:25:44 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 54D074B2; Wed, 15 May 2013 05:25:44 +0000 (UTC) (envelope-from lists@eitanadler.com) Received: from mail1.ozon.ru (mx4.ozon.ru [194.186.179.140]) by mx1.freebsd.org (Postfix) with ESMTP id 5FACACC2; Wed, 15 May 2013 05:25:43 +0000 (UTC) Received: from intmail03msk.ozon (intmail03msk.ozon [10.18.18.171]) by mail1.ozon.ru (Postfix) with ESMTP id CCD9271AB92; Wed, 15 May 2013 09:25:09 +0400 (MSK) Received: from mail pickup service by intmail03msk.ozon with Microsoft SMTPSVC; Wed, 15 May 2013 09:08:59 +0400 Received: from intmail03msk.ozon ([10.18.18.171]) by intmail02msk.ozon with Microsoft SMTPSVC(6.0.3790.4675); Sun, 12 May 2013 12:56:41 +0400 Received: from mail1.ozon.ru ([194.186.179.140]) by intmail03msk.ozon with Microsoft SMTPSVC(6.0.3790.4675); Sun, 12 May 2013 12:03:13 +0400 Received: from localhost (localhost [127.0.0.1]) by mail1.ozon.ru (Postfix) with ESMTP id 5388F71B4D0 for ; Sun, 12 May 2013 02:55:15 +0400 (MSK) X-Virus-Scanned: amavisd-new at ozon.ru Received: from mail1.ozon.ru ([127.0.0.1]) by localhost (mx4.ozon.ru [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3bbsQerjU+HW for ; Sun, 12 May 2013 02:55:07 +0400 (MSK) X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6 Received-SPF: pass (freebsd.org: 8.8.178.116 is authorized to use 'owner-freebsd-current@freebsd.org' in 'mfrom' identity (mechanism 'ip4:8.8.178.116' matched)) receiver=mx4.ozon.ru; identity=mfrom; envelope-from="owner-freebsd-current@freebsd.org"; helo=mx2.freebsd.org; client-ip=8.8.178.116 Received: from mx2.freebsd.org (mx2.FreeBSD.org [8.8.178.116]) by mail1.ozon.ru (Postfix) with ESMTP id 37A9071A711 for ; Sun, 12 May 2013 02:55:07 +0400 (MSK) Received: from hub.freebsd.org (hub.freebsd.org [IPv6:2001:1900:2254:206c::16:88]) by mx2.freebsd.org (Postfix) with ESMTP id 640888AD; Sat, 11 May 2013 22:55:00 +0000 (UTC) Received: from hub.freebsd.org (hub.freebsd.org [IPv6:2001:1900:2254:206c::16:88]) by hub.freebsd.org (Postfix) with ESMTP id 48603C60; Sat, 11 May 2013 22:55:00 +0000 (UTC) (envelope-from owner-freebsd-current@freebsd.org) Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 0326CB74 for ; Sat, 11 May 2013 22:54:58 +0000 (UTC) (envelope-from lists@eitanadler.com) Received: from mail-pb0-x231.google.com (mail-pb0-x231.google.com [IPv6:2607:f8b0:400e:c01::231]) by mx1.freebsd.org (Postfix) with ESMTP id D1677DB0 for ; Sat, 11 May 2013 22:54:57 +0000 (UTC) Received: by mail-pb0-f49.google.com with SMTP id rp2so858500pbb.22 for ; Sat, 11 May 2013 15:54:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=eitanadler.com; s=0xdeadbeef; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=F7PQ69qokh6aELKFL7xOZwsyX+emmAS2ubA1OOcYoaw=; b=XqkKP/TEqlOmSNxHRe+DquBLdou+kC2fuguw9mwJqtMyN979xxpX7PAn1skZyWLk7p yt9xS+t9rs2sxQtG1wcjraBlOCXYna8//diK/BGgcbDHdxbGSnAEf7F5igQSRK0J5fKL 1jnJ4mp/GhvJ966070GWAd0wpib8y5tZn/afQ= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type:x-gm-message-state; bh=F7PQ69qokh6aELKFL7xOZwsyX+emmAS2ubA1OOcYoaw=; b=lAB+94aXj20M+Y7O5s3z6KvLRtBvnNI1TVIpcEI/M9qXHpBBrGHCUhbktN8rI79d0c A7OsM4q0DFTfhwTkOK/BBYU0PSB/Rca0rmY06u9UO6sVTldGwwOlf8twRas7NYaHQF7S 2QFcuUU29wNqvp9tWl4comnaU1WT7QLoQ/1tFUzlq9oR4naZwuo29t3JavVKtzBRBGW5 tiONGRkCapSkoku9xkV82RL9TThf0JAZ/IlXLvcPyIMJNgqudcnJzpeNqqn5pdRRWAIV WdGJn6iFgffOraBDkAjKtdkiMVj+CtIu0BTFXguYCofTpPD0vno4eKpFfrHm+YJ1zpo/ 0NQg== X-Received: by 10.69.0.226 with SMTP id bb2mr23156593pbd.34.1368312896847; Sat, 11 May 2013 15:54:56 -0700 (PDT) MIME-Version: 1.0 Received: by 10.66.192.42 with HTTP; Sat, 11 May 2013 15:54:26 -0700 (PDT) In-Reply-To: <87178.1368219589@server1.tristatelogic.com> References: <87178.1368219589@server1.tristatelogic.com> From: Eitan Adler Date: Sat, 11 May 2013 18:54:26 -0400 Message-ID: Subject: Re: bin/152154: script(1) -k malfunctions with certain shells (e.g. tcsh, bash, zsh) To: "Ronald F. Guilmette" X-Gm-Message-State: ALoCoQnqsKrkgUyr2bZiFD8Ddh6X4+NL/6EfejgKAtRs2ECrzzFG0XvQ9tUQCHcqWk8cy8JMH0Fz X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: owner-freebsd-current@freebsd.org Sender: owner-freebsd-current@freebsd.org X-OriginalArrivalTime: 12 May 2013 08:03:13.0826 (UTC) FILETIME=[26F40020:01CE4EE7] Cc: freebsd-current@freebsd.org, freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 May 2013 05:25:44 -0000 On 10 May 2013 16:59, Ronald F. Guilmette wrote: > > http://www.freebsd.org/cgi/query-pr.cgi?pr=bin/152154 > > It has been suggested to me (by a committer) that I should raise the > issue of this PR here on these lists, because the problem described > within the PR remains a real problem, and despite my having proposed > something that seems to be a perfectly workable fix, no action has > been taken on this PR for some years now. By the way, it will go a long way to helping get some site on these PRs, if you provide diffs in 'unified diff' form (diff -u) instead of context diff form. I have been recently looking for old PRs with patches attached. :) -- Eitan Adler _______________________________________________ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" From owner-freebsd-stable@FreeBSD.ORG Wed May 15 05:32:14 2013 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 8F47EA8B; Wed, 15 May 2013 05:32:14 +0000 (UTC) (envelope-from pgj@freebsd.org) Received: from mail1.ozon.ru (mx4.ozon.ru [194.186.179.140]) by mx1.freebsd.org (Postfix) with ESMTP id 53D1BE10; Wed, 15 May 2013 05:32:12 +0000 (UTC) Received: from intmail03msk.ozon (intmail03msk.ozon [10.18.18.171]) by mail1.ozon.ru (Postfix) with ESMTP id 7BBD271A1E1; Wed, 15 May 2013 09:32:10 +0400 (MSK) Received: from mail pickup service by intmail03msk.ozon with Microsoft SMTPSVC; Wed, 15 May 2013 09:32:05 +0400 Received: from intmail03msk.ozon ([10.18.18.171]) by intmail02msk.ozon with Microsoft SMTPSVC(6.0.3790.4675); Sun, 12 May 2013 21:55:21 +0400 Received: from mail1.ozon.ru ([194.186.179.140]) by intmail03msk.ozon with Microsoft SMTPSVC(6.0.3790.4675); Sun, 12 May 2013 21:55:21 +0400 Received: from localhost (localhost [127.0.0.1]) by mail1.ozon.ru (Postfix) with ESMTP id 4007F7196E1 for ; Sun, 12 May 2013 21:55:21 +0400 (MSK) X-Virus-Scanned: amavisd-new at ozon.ru Received: from mail1.ozon.ru ([127.0.0.1]) by localhost (mx4.ozon.ru [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JyQbjE0mM7xC for ; Sun, 12 May 2013 21:55:13 +0400 (MSK) X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6 Received-SPF: pass (freebsd.org: 8.8.178.116 is authorized to use 'owner-freebsd-hackers@freebsd.org' in 'mfrom' identity (mechanism 'ip4:8.8.178.116' matched)) receiver=mx4.ozon.ru; identity=mfrom; envelope-from="owner-freebsd-hackers@freebsd.org"; helo=mx2.freebsd.org; client-ip=8.8.178.116 Received: from mx2.freebsd.org (mx2.FreeBSD.org [8.8.178.116]) by mail1.ozon.ru (Postfix) with ESMTP id BEE6F7196C3 for ; Sun, 12 May 2013 21:55:12 +0400 (MSK) Received: from hub.freebsd.org (hub.freebsd.org [IPv6:2001:1900:2254:206c::16:88]) by mx2.freebsd.org (Postfix) with ESMTP id 56A378D1; Sun, 12 May 2013 17:55:09 +0000 (UTC) Received: from hub.freebsd.org (hub.freebsd.org [IPv6:2001:1900:2254:206c::16:88]) by hub.freebsd.org (Postfix) with ESMTP id 53B968CC; Sun, 12 May 2013 17:55:09 +0000 (UTC) (envelope-from owner-freebsd-hackers@freebsd.org) Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 63234802; Sun, 12 May 2013 17:54:58 +0000 (UTC) (envelope-from pali.gabor@gmail.com) Received: from mail-ee0-f46.google.com (mail-ee0-f46.google.com [74.125.83.46]) by mx1.freebsd.org (Postfix) with ESMTP id 6558067D; Sun, 12 May 2013 17:54:56 +0000 (UTC) Received: by mail-ee0-f46.google.com with SMTP id e49so1173774eek.5 for ; Sun, 12 May 2013 10:54:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:sender:date:from:to:cc:subject:message-id:organization :x-mailer:mime-version:content-type:content-transfer-encoding; bh=eULesjOb39sJd/mJ0denfWWGMB8KfGMdpy/4x27l1Ew=; b=z6zg4xAouE04VXCoJM1e8hqP/Wnww+f6xosQwKSvxQeUV5plNkqe69mIGH5uhu6BnJ jcKF0I8sza6uBAs2S4DfxwQXtP5jjmyyFfYJdtT8EAH3kWGUiPZD2IahDhANtZkFB/T0 1YyQ1nPeQO/lxvRz+OEBFeqC3nKzzqnDri63tx95T5P5UeybTa48SikVwcXiY/dT/oTa uLzepYjMeCWEOtZqHIKJcMGV0fsGqzSJQ2NxoQ1s/GMaNVzACAKSzbKRmvsJHL30GDwa Z2v6TIq4ILM1VrRCbdKAyfE7LcyDreMLJ2RN1a5F82k9FdymxYvW8+49VPg9h8KkjuMC vLNQ== X-Received: by 10.14.0.129 with SMTP id 1mr68418742eeb.43.1368381289883; Sun, 12 May 2013 10:54:49 -0700 (PDT) Received: from funktor (catv-80-98-246-83.catv.broadband.hu. [80.98.246.83]) by mx.google.com with ESMTPSA id i2sm6674817eeg.2.2013.05.12.10.54.48 for (version=SSLv3 cipher=RC4-SHA bits=128/128); Sun, 12 May 2013 10:54:49 -0700 (PDT) Date: Sun, 12 May 2013 19:54:05 +0200 From: Gabor Pali To: hackers@freebsd.org Subject: FreeBSD Quarterly Status Report, January-March 2013 Message-ID: <20130512195405.04653b64@funktor> Organization: The FreeBSD Project X-Mailer: Claws Mail 3.9.0 (GTK+ 2.24.17; i386-portbld-freebsd9.1) Mime-Version: 1.0 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Errors-To: owner-freebsd-hackers@freebsd.org Sender: owner-freebsd-hackers@freebsd.org X-OriginalArrivalTime: 12 May 2013 17:55:21.0174 (UTC) FILETIME=[DEE71760:01CE4F39] Cc: stable@freebsd.org, current@freebsd.org X-BeenThere: freebsd-stable@freebsd.org List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 May 2013 05:32:14 -0000 RnJlZUJTRCBRdWFydGVybHkgU3RhdHVzIFJlcG9ydCwgSmFudWFyeS1NYXJjaCAyMDEzCgpJbnRy b2R1Y3Rpb24KCiAgIFRoaXMgcmVwb3J0IGNvdmVycyBGcmVlQlNELXJlbGF0ZWQgcHJvamVjdHMg YmV0d2VlbiBKYW51YXJ5IGFuZCBNYXJjaAogICAyMDEzLiBUaGlzIGlzIHRoZSBmaXJzdCBvZiBm b3VyIHJlcG9ydHMgcGxhbm5lZCBmb3IgMjAxMy4KCiAgIEhpZ2hsaWdodHMgZnJvbSB0aGlzIHN0 YXR1cyByZXBvcnQgaW5jbHVkZSB0aGUgYnVzeSBwcmVwYXJhdGlvbnMgb2YKICAgOC40LVJFTEVB U0UsIHJlc3RvcmF0aW9uIG9mIGJpbmFyeSBwYWNrYWdlIGJ1aWxkaW5nLCBzdGVhZHkgcHJvZ3Jl c3Mgb2YKICAgc2V2ZXJhbCBwb3J0aW5nIGVmZm9ydHMsIGxpa2Ugd29yayBvbiB0aGUgRnJlZUJT RCBwb3J0cyBvZiB4b3JnLCBHTk9NRSwKICAgS0RFLCBhbmQgWGZjZSwgYnJpbmdpbmcgRnJlZUJT RCB0byBDdWJpZWJvYXJkIGFuZCBIYWNrYmVycnkgYm9hcmRzLAogICBkZXZlbG9wbWVudCBvZiBB Uk0gYW5kIEFNRCBHUFUgc3VwcG9ydCwgaW1wcm92aW5nIHBlcmZvcm1hbmNlIG9mCiAgIFVGUy9G RlMgYW5kIGNhbGxvdXRzLCBhbmQgaW50cm9kdWNpbmcgYSBtdWx0aXBhdGggVENQIGltcGxlbWVu dGF0aW9uCiAgIGZvciB0aGUgbmV0d29yayBzdGFjay4KCiAgIFRoYW5rcyB0byBhbGwgdGhlIHJl cG9ydGVycyBmb3IgdGhlIGV4Y2VsbGVudCB3b3JrISBUaGlzIHJlcG9ydAogICBjb250YWlucyAz MSBlbnRyaWVzIGFuZCB3ZSBob3BlIHlvdSBlbmpveSByZWFkaW5nIGl0LgoKICAgVGhlIGRlYWRs aW5lIGZvciBzdWJtaXNzaW9ucyBjb3ZlcmluZyB0aGUgcGVyaW9kIGJldHdlZW4gQXByaWwgYW5k IEp1bmUKICAgMjAxMyBpcyBKdWx5IDd0aCwgMjAxMy4KICAgICBfX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KClByb2plY3Rz CgogICAgICogRnJlZU5BUwogICAgICogS2VybmVsIEluZm9ybWF0aW9uIGluIFByb2Nlc3MgQ29y ZSBEdW1wcwogICAgICogTmF0aXZlIGlTQ1NJIFN0YWNrCgpGcmVlQlNEIFRlYW0gUmVwb3J0cwoK ICAgICAqIEZyZWVCU0QgQnVnbWVpc3RlciBUZWFtCiAgICAgKiBGcmVlQlNEIENvcmUgVGVhbQog ICAgICogRnJlZUJTRCBQb3J0IE1hbmFnZXJzCiAgICAgKiBGcmVlQlNEIFBvc3RtYXN0ZXIgVGVh bQogICAgICogRnJlZUJTRCBSZWxlYXNlIEVuZ2luZWVyaW5nIFRlYW0KCktlcm5lbAoKICAgICAq IEFNRCBHUFUgS2VybmVsIE1vZGUtU2V0dGluZyAoS01TKSBTdXBwb3J0CiAgICAgKiBBdG9taWMg ImNsb3NlLW9uLWV4ZWMiCiAgICAgKiBjYWxsb3V0KDkpIEltcHJvdmVtZW50cwogICAgICogTXVs dGlwYXRoIFRDUCAoTVBUQ1ApIGZvciBGcmVlQlNECiAgICAgKiByYWNjdDogQmxvY2sgSU8gQWNj b3VudGluZwogICAgICogUmVhZC1vbmx5IFBvcnQgb2YgTmV0QlNEJ3MgVURGIEZpbGUgU3lzdGVt CiAgICAgKiBUQ1AtQU8gQXV0aGVudGljYXRpb24gT3B0aW9uCiAgICAgKiBVRlMvRkZTIFBlcmZv cm1hbmNlIFdvcmsKCkRvY3VtZW50YXRpb24KCiAgICAgKiBJbXByb3ZpbmcgdGhlIERvY3VtZW50 YXRpb24gUHJvamVjdCBJbmZyYXN0cnVjdHJlCiAgICAgKiBUaGUgZW50aXRpZXMgRG9jdW1lbnRh dGlvbiBCcmFuY2gKICAgICAqIFRoZSBGcmVlQlNEIEphcGFuZXNlIERvY3VtZW50YXRpb24gUHJv amVjdAoKQXJjaGl0ZWN0dXJlcwoKICAgICAqIEZyZWVCU0Qgb24gQ3ViaWVib2FyZAogICAgICog RnJlZUJTRC9hcm0gU3VwZXJwYWdlcyBmb3IgQVJNdjcKICAgICAqIEZyZWVCU0QvQVJNIFRvb2xj aGFpbiBJbXByb3ZlbWVudHMKClBvcnRzCgogICAgICogRnJlZUJTRCBIYXNrZWxsIFBvcnRzCiAg ICAgKiBHTk9NRS9GcmVlQlNECiAgICAgKiBLREUvRnJlZUJTRAogICAgICogUHlQeQogICAgICog V2luZTMyIG9uIEZyZWVCU0QvYW1kNjQKICAgICAqIFhmY2UvRnJlZUJTRAogICAgICogeG9yZyBv biBGcmVlQlNECgpNaXNjZWxsYW5lb3VzCgogICAgICogQlhSLlNVIC0tIFN1cGVyIFVzZXIncyBC U0QgQ3Jvc3MgUmVmZXJlbmNlCiAgICAgKiBtZG9jLnN1IC0tIFNob3J0IE1hbnVhbCBQYWdlIFVS THMKICAgICBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX18KCkFNRCBHUFUgS2VybmVsIE1vZGUtU2V0dGluZyAoS01TKSBTdXBw b3J0CgogICBVUkw6IGh0dHBzOi8vd2lraS5mcmVlYnNkLm9yZy9BTURfR1BVCgogICBDb250YWN0 OiBKZWFuLVPDqWJhc3RpZW4gUMOpZHJvbiA8ZHVtYmJlbGxARnJlZUJTRC5vcmc+CiAgIENvbnRh Y3Q6IEouUi4gT2xkcm95ZCA8anJAb3BhbC5jb20+CiAgIENvbnRhY3Q6IEtvbnN0YW50aW4gQmVs b3Vzb3YgPGtpYkBGcmVlQlNELm9yZz4KCiAgIFRoZSBwcm9qZWN0IHByb2dyZXNzZWQgd2VsbCBz aW5jZSBGZWJydWFyeToKCiAgICAgKiBLb25zdGFudGluIGNvbW1pdHRlZCBpcyBUVE0gcG9ydCB0 byAxMC1DVVJSRU5ULgogICAgICogV2l0aCB0aGUgaGVscCBvZiBKb2huIEJhbGR3aW4gKGpoYikg YW5kIEFuZHJpeSBHYXBvbiAoYXZnKSwgdGhlCiAgICAgICBWaWRlbyBCSU9TIHNpdHVhdGlvbiBn cmVhdGx5IGltcHJvdmVkOiB0aGUgcmFkZW9ua21zIGRyaXZlciByZWFkcwogICAgICAgdGhlIEJJ T1Mgc2hhZG93IGNvcHkgaWYgdGhlIHZpZGVvIGNhcmQgaXMgdGhlIHByaW1hcnkgb25lLCBvciBx dWVyeQogICAgICAgdGhlIFBDSSBleHBhbnNpb24gUk9NIG90aGVyd2lzZS4gSW4gdGhlIGVuZCwg dGhpcyBjb2RlIHdpbGwgYmUKICAgICAgIHByb2JhYmx5IGNvbW1pdHRlZCB0byB0aGUgUENJIGRy aXZlciBzbyB0aGF0IG90aGVyIHZpZGVvIGRyaXZlcnMKICAgICAgIGJlbmVmaXQgZnJvbSBpdC4K ICAgICAqIEFuZHJpeSBhbHNvIHJlcG9ydGVkIHNldmVyYWwgcHJvYmxlbXMgd2l0aCB0aGUgSTJD IGNvZGUuIE5vdyB0aGF0CiAgICAgICB0aGV5IGFyZSBmaXhlZCwgdGhlIG1vbml0b3JzIHBsdWdn ZWQgaW50byBEVkkgYW5kIEhETUkgY29ubmVjdG9ycwogICAgICAgYXJlIGRldGVjdGVkIGFuZCB0 aGVpciBFRElEIGlzIHJlYWQgY29ycmVjdGx5LiBWR0EgY29ubmVjdG9yIGlzIG5vdAogICAgICAg dGVzdGVkIHNvIGZhci4KICAgICAqIFRoZXJlIGlzIGEgbG9ja2luZyBwcm9ibGVtIGluIGVpdGhl ciBUVE0gb3IgdGhlIFJhZGVvbiBkcml2ZXIgd2hpY2gKICAgICAgIHByZXZlbnRzIE9wZW5HTCBm cm9tIHdvcmtpbmcgcHJvcGVybHkuIEplYW4tU8OpYmFzdGllbiBpcyBjdXJyZW50bHkKICAgICAg IHRyYWNraW5nIHRoaXMgZG93bi4KICAgICAqIEouUi4gT2xkcm95ZCBzdGFydGVkIHRvIHdvcmsg b24gYSA5LVNUQUJMRSBiYWNrcG9ydCBvZiB0aGUgZHJpdmVyCiAgICAgICB3aGljaCBpcyBub3cg d29ya2luZyBxdWl0ZSB3ZWxsLiBIZSBoYWQgdG8gYmFja3BvcnQgc29tZSBmZWF0dXJlcwogICAg ICAgZnJvbSB0aGUgVk0gd2hpY2ggbWF5IG5lZWQgZnVydGhlciByZWZpbmVtZW50IGJ5IHRoZSBW TSBmb2xrcy4KCiAgIFlha2F6IGxlbmRlZCBKZWFuLVPDqWJhc3RpZW4gYSBjb21wdXRlciB3aGlj aCBhbGxvd3MgaGltIHRvIHRlc3QgYQogICBSVjYzMC1iYXNlZCBkaXNjcmV0ZSBjYXJkIGFuZCwg aW4gdGhlIGZ1dHVyZSwgb3RoZXIgUENJZSBjYXJkcy4gU2V2ZXJhbAogICB1c2VycyBhbHJlYWR5 IGtpbmRseSB0ZXN0ZWQgdGhlIGRyaXZlci4gQmlnIHRoYW5rcyB0byBhbGwgdGhvc2UKICAgY29u dHJpYnV0b3JzIQoKICAgSW4gaXRzIGN1cnJlbnQgc3RhdGUsIHRoZSBkcml2ZXIgYWxsb3dzIHRv IGhhdmUgYSBzaW1wbGUgWCBzZXNzaW9uIChubwogICBPcGVuR0wpLCBydW4gY29tbW9uIGFwcGxp Y2F0aW9ucywgd2F0Y2ggbW92aWVzLCBjaGFuZ2UgdGhlIHJlc29sdXRpb24KICAgYW5kIGVuYWJs ZSBhZGRpdGlvbmFsIG1vbml0b3JzIHdpdGggeHJhbmRyKDEpLiBUaGUgbW9zdCBibG9ja2luZyBp c3N1ZQogICBub3cgaXMgdGhlIE9wZW5HTCBkZWFkbG9jayB3aGljaCBwcmV2ZW50cyB0byBydW4g bW9kZXJuCiAgIGNvbXBvc2l0b3JzL2Rlc2t0b3AgZW52aXJvbm1lbnQsIGdhbWVzIGFuZCBXZWJH TCBkZW1vcy4gV2UgYXJlIG5vdAogICByZWFkeSBmb3IgYSAiQ2FsbCBGb3IgVGVzdGVycyIgeWV0 LgoKT3BlbiB0YXNrczoKCiAgICAxLiBUZXN0IG11bHRpcGxlIGNhcmRzIGNvbmZpZ3VyYXRpb25z IGZvciBWaWRlbyBCSU9TIGlzc3VlcywKICAgICAgIGVzcGVjaWFsbHkgSW50ZWwgaW50ZWdyYXRl ZCBjYXJkICsgUmFkZW9uIGRpc2NyZXRlIGNhcmQsIGFuZCBBTUQKICAgICAgIGludGVncmF0ZWQg Y2FyZCAoSUdQKSArIFJhZGVvbiBkaXNjcmV0ZSBjYXJkLiBObyBuZWVkIHRvIGNoZWNrCiAgICAg ICBjb25maWd1cmF0aW9ucyB3aXRoIG9uZSBzaGFyZWQgY29ubmVjdG9yIHRob3VnaCwgaXQgaXMg bm90CiAgICAgICBzdXBwb3J0ZWQgcmlnaHQgbm93LgogICAgIF9fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwoKQXRvbWljICJj bG9zZS1vbi1leGVjIgoKICAgVVJMOiBodHRwczovL3dpa2kuZnJlZWJzZC5vcmcvQXRvbWljQ2xv c2VPbkV4ZWMKCiAgIENvbnRhY3Q6IEppbGxlcyBUam9lbGtlciA8amlsbGVzQEZyZWVCU0Qub3Jn PgoKICAgSWYgdGhyZWFkcyBvciBzaWduYWwgaGFuZGxlcnMgY2FsbCBmb3JrKCkgYW5kIGV4ZWMo KSwgZmlsZSBkZXNjcmlwdG9ycwogICBtYXkgYmUgcGFzc2VkIHVuZGVzaXJhYmx5IHRvIGNoaWxk IHByb2Nlc3Nlcywgd2hpY2ggbWF5IGxlYWQgdG8gaGFuZ3MKICAgKGlmIGEgcGlwZSBpcyBub3Qg Y2xvc2VkKSwgZXhjZWVkaW5nIHRoZSBmaWxlIGRlc2NyaXB0b3IgbGltaXQgYW5kCiAgIHNlY3Vy aXR5IHByb2JsZW1zIChpZiB0aGUgY2hpbGQgcHJvY2VzcyBoYXMgbG93ZXIgcHJpdmlsZWdlKS4g T25lCiAgIHNvbHV0aW9uIGlzIHZhcmlvdXMgbmV3IEFQSXMgdGhhdCBzZXQgdGhlICJjbG9zZS1v bi1leGVjIiBmbGFnCiAgIGF0b21pY2FsbHkgd2l0aCBhbGxvY2F0aW5nIGEgZmlsZSBkZXNjcmlw dG9yLiBTb21lIGV4aXN0aW5nIHNvZnR3YXJlCiAgIHdpbGwgdXNlIHRoZSBuZXcgZmVhdHVyZXMg aWYgcHJlc2VudCBvciB3aWxsIGV2ZW4gcmVmdXNlIHRvIGNvbXBpbGUKICAgd2l0aG91dCB0aGVt LgoKICAgVmFyaW91cyBwYXJ0cyBoYXZlIGJlZW4gcHJlc2VudCBmb3Igc29tZSB0aW1lLgoKICAg SW4gZmlyc3QgcXVhcnRlciBvZiAyMDEzLCBleHRlbnNpb25zIHRvIHJlY3Ztc2coKSwgc29ja2V0 KCksCiAgIHNvY2tldHBhaXIoKSBhbmQgcG9zaXhfb3BlbnB0KCkgaGF2ZSBiZWVuIGFkZGVkLgog ICAgIF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fXwoKQlhSLlNVIC0tIFN1cGVyIFVzZXIncyBCU0QgQ3Jvc3MgUmVmZXJlbmNl CgogICBVUkw6IGh0dHA6Ly9ieHIuc3UvCiAgIFVSTDogaHR0cDovL2xpc3RzLmZyZWVic2Qub3Jn L3BpcGVybWFpbC9mcmVlYnNkLWhhY2tlcnMvMjAxMy1BcHJpbC8wNDIzMzQuaHRtbAoKICAgQ29u dGFjdDogQ29uc3RhbnRpbmUgQS4gTXVyZW5pbiA8Y25zdCsrQEZyZWVCU0Qub3JnPgoKICAgU3Vw ZXIgVXNlcidzIEJTRCBDcm9zcyBSZWZlcmVuY2UgKEJYUi5TVSkgaXMgYSBuZXcgc291cmNlLWNv ZGUgc2VhcmNoCiAgIGVuZ2luZSB0aGF0IGNvdmVycyB0aGUgY29tcGxldGUga2VybmVsIGFuZCBu b24tR05VIHVzZXJsYW5kIHNvdXJjZQogICB0cmVlcyBvZiBGcmVlQlNELCBOZXRCU0QsIE9wZW5C U0QsIGFuZCBEcmFnb25GbHkgQlNELgoKICAgQlhSLlNVIGlzIG9wdGltaXNlZCB0byBiZSB2ZXJ5 IGZhc3QsIGhhcyBkYWlseSB1cGRhdGVzIG9mIGFsbCB0aGUKICAgdHJlZXMsIGFuZCBhbHNvIGFj dHMgYXMgYSBkZXRlcm1pbmlzdGljIFVSTCBzaG9ydGVuZXIuCgogICBCWFIuU1UgaXMgYmFzZWQg b24gYW4gT3Blbkdyb2sgZm9yaywgYnV0IGl0IGlzIG1vcmUgdGhhbiBqdXN0IE9wZW5Hcm9rLgog ICBXZSBoYXZlIGZpeGVkIGEgbnVtYmVyIG9mIGFubm95YW5jZXMsIGVsaW1pbmF0ZWQgZmVhdHVy ZXMgdGhhdCBqdXN0CiAgIG5ldmVyIHdvcmtlZCByaWdodCBmcm9tIHRoZSBvdXRyaWdodCwgYW5k IHByb3ZpZGVkIGludGVncmF0aW9uIHdpdGgKICAgdG9vbHMgbGlrZSBDVlN3ZWIgKGluY2x1ZGlu ZyBncmVhdCBtaXJyb3JzIGxpa2UgYWxsYnNkLm9yZyksIEZyZWVCU0QncwogICBWaWV3VkMgKFNW TiksIGFzIHdlbGwgYXMgR2l0SHViIGFuZCBHaXR3ZWIgZnJvbSBnaXQuZnJlZWJzZC55b3VyLm9y ZywKICAgcGx1cyBhIHRhZCBvZiBvdGhlciBpbXByb3ZlbWVudHMsIGluY2x1ZGluZyBhIGNvbXBs ZXRlIHJld3JpdGUgb2YgYW4KICAgbWRvYyBwYXJzZXIuIExhc3QsIGJ1dCBkZWZpbml0ZWx5IG5v dCBsZWFzdCwgaXMgYW4gZXh0ZW5zaXZlIHNldCBvZgogICBuZ2lueCByZXdyaXRlIHJ1bGVzIHRo YXQgbWFrZXMgaXQgYSBicmVlemUgdG8gdXNlIEJYUi5TVSBhcyBhCiAgIGRldGVybWluaXN0aWMg VVJMIGNvbXBhY3RvciBmb3IgcmVmZXJlbmNpbmcgQlNEIHNvdXJjZSBjb2RlLiBGb3IKICAgZXhh bXBsZSwgdGhlIGh0dHA6Ly9ieHIuc3UvZi9rZXJuL3NjaGVkX3VsZS5jIFVSTCB3aWxsIGF1dG9t YXRpY2FsbHkKICAgcmVkaXJlY3QgdG8gaHR0cDovL2J4ci5zdS9GcmVlQlNEL3N5cy9rZXJuL3Nj aGVkX3VsZS5jIHRocm91Z2ggbmdpbnguCgogICBOb3RlIHRoYXQgYWNjb3JkaW5nIHRvIHRoZSBy ZWxlYXNlIHNjaGVkdWxlIG9mIEJYUi5TVSwgdGhlcmUgaXMgbm8gSVB2NAogICBnbHVlIHVudGls IDIwMTMtMDQtMjQ7IG90aGVyd2lzZSwgdGhlIHNlcnZpY2UgaXMgYXZhaWxhYmxlIHZpYSBib3Ro CiAgIElQdjQgYW5kIElQdjYuIFNlZSB0aGUgMjAxMy0wNC0wMSBhbm5vdW5jZW1lbnQgb24gdGhl IGZyZWVic2QtaGFja2VycwogICBtYWlsaW5nIGxpc3QgZm9yIG1vcmUgZGV0YWlscy4KCk9wZW4g dGFza3M6CgogICAgMS4gRmluZCB1cC10by1kYXRlIGdpdCByZXBvc2l0b3JpZXMgKHNlcnZlZCB3 aXRoIEdpdHdlYikgb2YgTmV0QlNEIGFuZAogICAgICAgT3BlbkJTRC4KICAgIDIuIEZpbmQgYSBH aXR3ZWIgbWlycm9yIG9mIEZyZWVCU0QgdGhhdCBpcyBmYXN0ZXIgdGhhbiBHaXRIdWIgYW5kCiAg ICAgICBHaXRvcmlvdXMuCiAgICAgX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCgpjYWxsb3V0KDkpIEltcHJvdmVtZW50cwoK ICAgVVJMOiBodHRwOi8vcGVvcGxlLmZyZWVic2Qub3JnL35kYXZpZGUvYXNpYS9jYWxsb3V0X3Bh cGVyLnBkZgogICBVUkw6IGh0dHA6Ly9wZW9wbGUuZnJlZWJzZC5vcmcvfmRhdmlkZS9hc2lhL2Nh bGxvdXRuZy5wZGYKICAgVVJMOiBodHRwOi8vc3Zud2ViLmZyZWVic2Qub3JnL2Jhc2U/dmlldz1y ZXZpc2lvbiZyZXZpc2lvbj0yNDc3NzcKCiAgIENvbnRhY3Q6IERhdmlkZSBJdGFsaWFubyA8ZGF2 aWRlQEZyZWVCU0Qub3JnPgogICBDb250YWN0OiBBbGV4YW5kZXIgTW90aW4gPG1hdkBGcmVlQlNE Lm9yZz4KCiAgIEluIEZyZWVCU0QsIHRpbWVycyBhcmUgcHJvdmlkZWQgYnkgdGhlIGNhbGxvdXQg ZmFjaWxpdHksIHdoaWNoIGFsbG93cwogICB0byByZWdpc3RlciBhIGZ1bmN0aW9uIHdpdGggYW4g YXJndW1lbnQgdG8gYmUgY2FsbGVkIGF0IHNwZWNpZmllZAogICBmdXR1cmUgdGltZS4gVGhlIHN1 YnN5c3RlbSBzdWZmZXJlZCBvZiBzb21lIHByb2JsZW1zLCBzdWNoIGFzIHRoZQogICBpbXBvc3Np YmlsaXR5IG9mIGhhbmRsaW5nIGhpZ2gtcmVzb2x1dGlvbiBldmVudHMgb3IgaXRzIGluaGVyZW50 CiAgIHBlcmlvZGljIHN0cnVjdHVyZSwgd2hpY2ggbWF5IGxlYWQgdG8gc3B1cmlvdXMgd2FrZXVw cyBhbmQgaGlnaGVyIHBvd2VyCiAgIGNvbnN1bXB0aW9uLiBTb21lIGNvbnN1bWVycywgc3VjaCBh cyBoaWdoLXNwZWVkIG5ldHdvcmtpbmcsIFZvSVAgYW5kCiAgIG90aGVyIHJlYWwtdGltZSBhcHBs aWNhdGlvbnMgbmVlZCBhIGJldHRlciBwcmVjaXNpb24gdGhhbiB0aGUgb25lCiAgIGN1cnJlbnRs eSBhbGxvd2VkLiBBbHNvLCBlc3BlY2lhbGx5IHdpdGggdGhlIHViaXF1aXR5IG9mIGxhcHRvcHMg aW4gdGhlCiAgIGxhc3QgeWVhcnMsIHRoZSBlbmVyZ3kgd2FzdGVkIGJ5IGludGVycnVwdHMgd2Fr aW5nIENQVXMgZnJvbSBzbGVlcCBtYXkKICAgYmUgYSBzZW5zaXRpdmUgZmFjdG9yLiBSZWNlbnQg Y2hhbmdlcyBpbiB0aGUgc3Vic3lzdGVtIGFkZHJlc3NlZCB0aG9zZQogICBsb25nLXN0YW5kaW5n IGlzc3VlcyBhcyB3ZWxsIGFzIGludHJvZHVjZWQgYSBuZXcgcHJvZ3JhbW1pbmcgaW50ZXJmYWNl CiAgIHRvIHRha2UgYWR2YW50YWdlIG9mIHRoZSBuZXcgZmVhdHVyZXMuCgpPcGVuIHRhc2tzOgoK ICAgIDEuIEV2YWx1YXRpbmcgaWYgaXQgaXMgd29ydGggdG8gbWlncmF0ZSBhbnkgb2YgdGhlIG90 aGVyIGNhbGxvdXQoOSkKICAgICAgIGNvbnN1bWVycyB0byB0aGUgbmV3IGludGVyZmFjZS4KICAg IDIuIE1vdmUgY2FsbG91dCBjb25zdW1lcnMgc3RpbGwgdXNpbmcgdGhlIGxlZ2FjeSB0aW1lb3V0 KCkvdW50aW1lb3V0KCkKICAgICAgIGludGVyZmFjZSB0byBjYWxsb3V0XyooKSBpbiBvcmRlciB0 byBnZXQgcmlkIG9mIHJlZHVuZGFudCBjb2RlIGFuZAogICAgICAgY2xlYW4gdXAgS1BJLgogICAg IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fXwoKRnJlZUJTRCBCdWdtZWlzdGVyIFRlYW0KCiAgIENvbnRhY3Q6IEVpdGFuIEFk bGVyIDxlYWRsZXJARnJlZUJTRC5vcmc+CiAgIENvbnRhY3Q6IEdhdmluIEF0a2luc29uIDxnYXZp bkBGcmVlQlNELm9yZz4KICAgQ29udGFjdDogT2xla3NhbmRyIFR5bW9zaGVua28gPGdvbnpvQEZy ZWVCU0Qub3JnPgoKICAgVGhlIEZyZWVCU0QgQnVnbWVpc3RlciBUZWFtIGFyZSBjb250aW51aW5n IHRvIGV2YWx1YXRlIG9wdGlvbnMgZm9yCiAgIGFsdGVybmF0ZSBidWcgdHJhY2tlcnMgYW5kIGhh dmUgbmFycm93ZWQgdGhlaXIgY2hvaWNlcyB0byB0d28KICAgcG9zc2liaWxpdGllczogQnVnemls bGEgYW5kIHJvdW5kdXAuCgogICBUaGUgbnVtYmVyIG9mIG5vbi1wb3J0cyBQUnMgaGF2ZSByZW1h aW5lZCByZWxhdGl2ZWx5IHN0YXRpYyBvdmVyIHRoZQogICBsYXN0IHRocmVlIG1vbnRocywgd2l0 aCBhcyBtYW55IGNvbWluZyBpbiBhcyBiZWluZyBjbG9zZWQuIFRoZSBudW1iZXIKICAgb2YgcG9y dHMgUFJzIGhhdmUgaW5jcmVhc2VkIHJlY2VudGx5LCBsYXJnZWx5IGR1ZSB0byB0aGUgcG9ydHMg ZnJlZXplCiAgIGZvciB0aGUgdXBjb21pbmcgOC40LVJFTEVBU0UuCgogICBUaGUgQnVnbWVpc3Rl ciB0ZWFtIGNvbnRpbnVlIHdvcmsgb24gdHJ5aW5nIHRvIG1ha2UgdGhlIGNvbnRlbnRzIG9mIHRo ZQogICBHTkFUUyBQUiBkYXRhYmFzZSBjbGVhbmVyLCBtb3JlIGFjY2Vzc2libGUgYW5kIGVhc2ll ciBmb3IgY29tbWl0dGVycyB0bwogICBmaW5kIGFuZCByZXNvbHZlIFBScywgYnkgdGFnZ2luZyBQ UnMgdG8gaW5kaWNhdGUgdGhlIGFyZWFzIGludm9sdmVkLAogICBhbmQgYnkgZW5zdXJpbmcgdGhh dCB0aGVyZSBpcyBzdWZmaWNpZW50IGluZm8gd2l0aGluIGVhY2ggUFIgdG8gcmVzb2x2ZQogICBl YWNoIGlzc3VlLgoKICAgQXMgYWx3YXlzLCBhbnlib2R5IGludGVyZXN0ZWQgaW4gaGVscGluZyBv dXQgd2l0aCB0aGUgUFIgcXVldWUgaXMKICAgd2VsY29tZSB0byBqb2luIHVzIGluICNmcmVlYnNk LWJ1Z2J1c3RlcnMgb24gRUZuZXQuIFdlIGFyZSBhbHdheXMKICAgbG9va2luZyBmb3IgYWRkaXRp b25hbCBoZWxwLCB3aGV0aGVyIHlvdXIgaW50ZXJlc3RzIGxpZSBpbiB0cmlhZ2luZwogICBpbmNv bWluZyBQUnMsIGdlbmVyYXRpbmcgcGF0Y2hlcyB0byByZXNvbHZlIGV4aXN0aW5nIHByb2JsZW1z LCBvcgogICBzaW1wbHkgaGVscGluZyB3aXRoIHRoZSBkYXRhYmFzZSBob3VzZWtlZXBpbmcgKGlk ZW50aWZ5aW5nIGR1cGxpY2F0ZQogICBQUnMsIG9uZXMgdGhhdCBoYXZlIGFscmVhZHkgYmVlbiBy ZXNvbHZlZCwgZXRjKS4gVGhpcyBpcyBhIGdyZWF0IHdheSBvZgogICBnZXR0aW5nIG1vcmUgaW52 b2x2ZWQgd2l0aCBGcmVlQlNEIQoKT3BlbiB0YXNrczoKCiAgICAxLiBGaW5hbGl6ZSB0aGUgZGVj aXNpb24gb2Ygd2hpY2ggbmV3IGJ1ZyB0cmFja2VyIHRvIHVzZS4KICAgIDIuIEdldCBtb3JlIHVz ZXJzIGludm9sdmVkIHdpdGggdHJpYWdpbmcgUFJzIGFzIHRoZXkgY29tZSBpbi4KICAgIDMuIEFz c2lzdCBjb21taXR0ZXJzIHdpdGggY2xvc2luZyBQUnMuCiAgICAgX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCgpGcmVlQlNE IENvcmUgVGVhbQoKICAgQ29udGFjdDogQ29yZSBUZWFtIDxjb3JlQEZyZWVCU0Qub3JnPgoKICAg QXQgdGhlIGVuZCBvZiAyMDEyLCB0aGUgQ29yZSBUZWFtIGFwcHJvdmVkIHVzaW5nIEdvb2dsZSBB bmFseXRpY3Mgb24KICAgdGhlIFByb2plY3Qgd2ViIHNpdGUgdG8gZW5hYmxlIHRoZSBEb2N1bWVu dGF0aW9uIEVuZ2luZWVyaW5nIFRlYW0gdG8KICAgY29sbGVjdCBzdGF0aXN0aWNzIG9uIGl0cyB1 c2FnZSBmb3IgYmV0dGVyIHByb2ZpbGluZy4gSW4gdGhlIGZpcnN0CiAgIHF1YXJ0ZXIgb2YgMjAx MywgdGhlIENvcmUgVGVhbSB3b3JrZWQgd2l0aCB0aGUgRG9jdW1lbnRhdGlvbgogICBFbmdpbmVl cmluZyBUZWFtIHRvIGZpbmFsaXplIHRoZSBhc3NvY2lhdGVkIHBvbGljaWVzLgoKICAgRHVlIHRv IHNvbWUgZGViYXRlcyBhcm91bmQgdGhlIHBvbGl0aWNhbCBjb3JyZWN0bmVzcyBvZiBxdW90ZXMg YWRkZWQKICAgZm9yIHRoZSBmb3J0dW5lKDYpIHV0aWxpdHksIHRoZSBjb3JyZXNwb25kaW5nIGRh dGEgZmlsZSBoYXMgYmVlbgogICByZW1vdmVkIGZyb20gdGhlIGJhc2Ugc3lzdGVtIGluIC1DVVJS RU5ULgoKICAgSW4gbGlnaHQgb2YgdGhlIHNlY3VyaXR5IGluY2lkZW50LCB0aGUgbGlhaXNvbiBy b2xlIGJldHdlZW4gdGhlIENvcmUKICAgVGVhbSBhbmQgdGhlIFNlY3VyaXR5IFRlYW0gaGFzIGJl ZW4gcmVzdG9yZWQsIHdpdGggR2F2aW4gQXRraW5zb24KICAgYXNzdW1pbmcgdGhpcyByb2xlLiBU aGUgQ29yZSBUZWFtIHdvcmsgaGFyZCBvbiByZXNvbHZpbmcgdGhlIGN1cnJlbnQKICAgc2l0dWF0 aW9uIG9mIHRoZSBiaW5hcnkgcGFja2FnZSBidWlsZGluZyBjbHVzdGVyIGFuZCB0aGUgYXNzb2Np YXRlZAogICBzZWN1cml0eSBwcm9ibGVtcyBpbiB0aWdodCBjb29wZXJhdGlvbiB3aXRoIHRoZSBQ b3J0cyBNYW5hZ2VtZW50IFRlYW0sCiAgIENsdXN0ZXIgQWRtaW5pc3RhdG9ycywgYW5kIHRoZSBG cmVlQlNEIEZvdW5kYXRpb24gQm9hcmQuIFRoZSBjb21wcm9taXNlCiAgIHBhZ2UgaXMga2VwdCB1 cGRhdGVkIG9uIHRoZSByZXN1bHRzLgoKICAgVGhlIEZyZWVCU0QgUHJvamVjdCBzdWJtaXR0ZWQg YW4gYXBwbGljYXRpb24gZm9yIEdvb2dsZSBTdW1tZXIgb2YgQ29kZQogICB0aGlzIHllYXIgYWdh aW4uCgogICBUaGVyZSB3YXMgYWNjZXNzIGdyYW50ZWQgZm9yIDIgbmV3IGNvbW1pdHRlcnMgYW5k IDEgY29tbWl0IGJpdCB3YXMKICAgdGFrZW4gZm9yIHNhZmVrZWVwaW5nIGluIHRoaXMgcXVhcnRl ci4KICAgICBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX18KCkZyZWVCU0QgSGFza2VsbCBQb3J0cwoKICAgVVJMOiBodHRwOi8v d2lraS5mcmVlYnNkLm9yZy9IYXNrZWxsCiAgIFVSTDogaHR0cHM6Ly9naXRodWIuY29tL2ZyZWVi c2QtaGFza2VsbC9mcmVlYnNkLWhhc2tlbGwvCgogICBDb250YWN0OiBHw6Fib3IgUMOhbGkgPHBn akBGcmVlQlNELm9yZz4KICAgQ29udGFjdDogQXNoaXNoIFNodWtsYSA8YXNoaXNoQEZyZWVCU0Qu b3JnPgoKICAgV2UgYXJlIHByb3VkIHRvIGFubm91bmNlIEZyZWVCU0QgSGFza2VsbCBUZWFtIGhh cyB1cGRhdGVkIGV4aXN0aW5nCiAgIHBvcnRzIHRvIHRoZWlyIGxhdGVzdCBzdGFibGUgdmVyc2lv bnMuIFdlIGFsc28gYWRkZWQgbnVtYmVyIG9mIG5ldwogICBwb3J0cywgd2hpY2ggYnJpbmdzIHRo ZSBjb3VudCBvZiBIYXNrZWxsIHBvcnRzIGluIEZyZWVCU0QgcG9ydHMgdHJlZSB0bwogICBtb3Jl IHRoYW4gNDAwLCBmZWF0dXJpbmcgbWFueSBwb3B1bGFyIHNvZnR3YXJlLCBlLmcuIHhtb25hZCwg Z2l0LWFubmV4LAogICBwYW5kb2Mgb3IgdmFyaW91cyB3ZWIgZnJhbWV3b3JrIGltcGxlbWVudGF0 aW9ucy4gQWxsIG9mIHRoZXNlIHVwZGF0ZXMKICAgd2lsbCBiZSBhdmFpbGFibGUgYXMgcGFydCBv ZiB0aGUgdXBjb21pbmcgOC40LVJFTEVBU0UuIFdlIGFsc28gY2FtZSB0bwogICBrbm93IHRoYXQg SGFza2VsbCBwb3J0cyBhcmUgYWxzbyBiZWluZyB1c2VkIHN1Y2Nlc3NmdWxseSBvbgogICBEcmFn b25GbHlCU0QncyBkcG9ydHMgdHJlZS4KCiAgIEluIG91ciBkZXZlbG9wbWVudCByZXBvc2l0b3J5 LCB0aGVyZSB3YXMgc29tZSBvcHRpb25hbCBzdXBwb3J0IGFkZGVkCiAgIGZvciBMTFZNLWJhc2Vk IGNvZGUgZ2VuZXJhdGlvbiB1c2luZyB0aGUgR0hDIExMVk0gYmFja2VuZC4gVGhpcyB3b3Jrcwog ICBtb3N0bHkgb24gRnJlZUJTRCB0b28sIHRob3VnaCBzb21lIG9mIHRoZSBwb3J0cyB3b3VsZCBu ZWVkIGZpeGluZyBzbyBpdAogICBpcyBzdGlsbCBjb25zaWRlcmVkIGV4cGVyaW1lbnRhbC4KCk9w ZW4gdGFza3M6CgogICAgMS4gVHJ5IHRvIGJ1aWxkIEdIQyB3aXRoIGNsYW5nIChhcyBzeXN0ZW0g Y29tcGlsZXIpLgogICAgMi4gQ29tbWl0IHBlbmRpbmcgSGFza2VsbCBwb3J0cyB0byB0aGUgRnJl ZUJTRCBwb3J0cyB0cmVlLgogICAgMy4gQWRkIG1vcmUgcG9ydHMgdG8gdGhlIFBvcnRzIENvbGxl Y3Rpb24uCiAgICAgX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fCgpGcmVlQlNEIG9uIEN1YmllYm9hcmQKCiAgIENvbnRhY3Q6 IEdhbmJvbGQgVHNhZ2FhbmtodXUgPGdhbmJvbGRARnJlZUJTRC5vcmc+CiAgIENvbnRhY3Q6IE9s ZWtzYW5kciBUeW1vc2hlbmtvIDxnb256b0BGcmVlQlNELm9yZz4KCiAgIEluaXRpYWwgc3VwcG9y dCBvZiBBbGx3aW5uZXIgQTEwIFNvQyBpcyBjb21taXR0ZWQgdG8gLUNVUlJFTlQuIEZyZWVCU0QK ICAgaXMgbm93IHJ1bm5pbmcgb24gYm9hcmRzIHN1Y2ggYXMgQ3ViaWVib2FyZCwgSGFja2JlcnJ5 IGFuZCBpdCBzdXBwb3J0cwogICBmb2xsb3dpbmcgcGVyaXBoZXJhbHM6CiAgICAgKiBVU0IgRUhD SQogICAgICogR1BJTwoKT3BlbiB0YXNrczoKCiAgICAxLiBHZXQgRU1BQyBFdGhlcm5ldCBkcml2 ZXIgd29ya2luZy4gTmVlZCBtb3JlIGhlbHAgZnJvbSBuZXR3b3JrCiAgICAgICBkcml2ZXIgZXhw ZXJ0cy4KICAgIDIuIEltcGxlbWVudCBtb3JlIGRyaXZlcnMuCiAgICAgX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCgpGcmVl QlNEIFBvcnQgTWFuYWdlcnMKCiAgIFVSTDogaHR0cDovL3d3dy5GcmVlQlNELm9yZy9wb3J0cy8K ICAgVVJMOiBodHRwOi8vd3d3LmZyZWVic2Qub3JnL2RvYy9lbi9hcnRpY2xlcy9jb250cmlidXRp bmctcG9ydHMvCiAgIFVSTDogaHR0cDovL3BvcnRzbW9uLmZyZWVic2Qub3JnLwogICBVUkw6IGh0 dHA6Ly93d3cuZnJlZWJzZC5vcmcvcG9ydG1nci8KICAgVVJMOiBodHRwOi8vYmxvZ3MuZnJlZWJz ZGlzaC5vcmcvcG9ydG1nci8KICAgVVJMOiBodHRwOi8vd3d3LnR3aXR0ZXIuY29tL2ZyZWVic2Rf cG9ydG1nci8KICAgVVJMOiBodHRwOi8vd3d3LmZhY2Vib29rLmNvbS9wb3J0bWdyCgogICBDb250 YWN0OiBUaG9tYXMgQWJ0aG9ycGUgPHBvcnRtZ3Itc2VjcmV0YXJ5QEZyZWVCU0Qub3JnPgogICBD b250YWN0OiBQb3J0IE1hbmFnZW1lbnQgVGVhbSA8cG9ydG1nckBGcmVlQlNELm9yZz4KCiAgIFRo ZSBwb3J0cyB0cmVlIGNvbnRhaW5zIGFwcHJveGltYXRlbHkgMjQsMzAwIHBvcnRzLCB3aGlsZSB0 aGUgUFIgY291bnQKICAgc3RpbGwgaXMgY2xvc2UgdG8gMTYwMC4KCiAgIEluIHRoZSBmaXJzdCBx dWFydGVyIHdlIGFkZGVkIDQgbmV3IGNvbW1pdHRlcnMsIHRvb2sgaW4gMSBjb21taXQgYml0CiAg IGZvciBzYWZlIGtlZXBpbmcsIGFuZCByZS1pbnN0YXRlZCAxIGNvbW1pdCBiaXQuCgogICBJbiBG ZWJydWFyeSwgTWFyayBMaW5pbW9uIChsaW5pbW9uKSBzdGVwcGVkIGRvd24gZnJvbSBoaXMgZHV0 aWVzIGluIHRoZQogICB0ZWFtLiBNYXJrIGhhZCBiZWVuIHRoZSBsb25nZXN0IHNlcnZpbmcgbWVt YmVyIG9mIHRoZSB0ZWFtLiBNYXJrIGhhZAogICBzcGVudCBtYW55IGxvbmcgaG91cnMgcmVmYWN0 b3JpbmcgYW5kIGRvY3VtZW50aW5nIHRoZSBwb3J0YnVpbGQKICAgc29mdHdhcmUgdG8gZW5zdXJl IHRoYXQgcG9pbnR5aGF0IHNlcnZpY2VzIGNvdWxkIGJlIHJlc3RvcmVkLgoKICAgQWZ0ZXIgYSBz ZWN1cml0eSByZXZpZXcsIHJlZHBvcnRzLm9yZyB3YXMgdHVybmVkIGJhY2sgb24sIHJlc3Rvcmlu ZwogICBUaW5kZXJib3ggc2VydmljZXMgdG8gY29udHJpYnV0b3JzLCBhbG9uZyB3aXRoIHBvc3Qg Y29tbWl0IFFBVHMuIEluCiAgIGFkZGl0aW9uLCBwb2ludHloYXQgaW5mcmFzdHJ1Y3R1cmUgaGFk IGFsc28gdW5kZXJnb25lIGEgcmV2aWV3IGFuZCB3b3JrCiAgIGJlZ2FpbiBvbiByZXN0b3Jpbmcg dGhlIHBhY2thZ2UgYnVpbGQgc3lzdGVtLgoKICAgRXJ3aW4gTGFuc2luZyAoZXJ3aW4pIGFuZCBN YXJ0aW4gV2lsa2UgKG1pd2kpIHRvb2sgb24gdGhlIHByaW5jaXBsZQogICByb2xlcyBvZiBnZXR0 aW5nIHRoZSBwb3J0YnVpbGQgc29mdHdhcmUgaW5zdGFsbGVkIGFuZCBydW5uaW5nIG9uCiAgIHBv aW50eWhhdC4gQXMgYSByZXN1bHQgb2YgYWxsIHRoZWlyIGhhcmQgd29yaywgcG9ydG1nckAgd2Fz IGZpbmFsbHkKICAgYWJsZSB0byByZXN1bWUgZG9pbmcgLWV4cCBydW5zLCBwcmVwYXJpbmcgcGFj a2FnZXMgZm9yIHRoZSB1cGNvbWluZyA4LjQKICAgcmVsZWFzZSwgYXMgd2VsbCBhcyBnZXR0aW5n IGEgc2V0IG9mIDkuMSBwYWNrYWdlcyByZXRyb2FjdGl2ZWx5CiAgIHByZXBhcmVkLgoKICAgQWZ0 ZXIgbWFueSBsb25nIHllYXJzIG9mIGJlaW5nIHRoZSBkZWZhY3RvIHN0YW5kYXJkIGZvciB0aGUg UHJvamVjdCwKICAgQ1ZTIHN1cHBvcnQgZm9yIHRoZSBwb3J0cyB0cmVlIG9mZmljaWFsbHkgZW5k ZWQgb24gRmVicnVhcnkgMjguCgogICBUaGUgcG9ydHMgdHJlZSB3YXMgdGFnZ2VkIHdpdGggUkVM RUFTRV83X0VPTCwgdG8gY29pbmNpZGUgd2l0aCB0aGUgZW5kCiAgIG9mIGxpZmUgZm9yIEZyZWVC U0QgNy5YLgoKICAgQmVhdCBHYWV0emkgKGJlYXQpIHN0ZXBwZWQgZG93biBmcm9tIGhpcyBkdXRp ZXMgb24gcG9ydG1nckAgaW4gTWFyY2guCiAgIEFtb25nIGhpcyBub3RhYmxlIGNvbnRyaWJ1dGlv bnMsIHdhcyB0aGUgdGFzayBvZiBtaWdyYXRpbmcgdGhlIFBvcnRzCiAgIFRyZWUgZnJvbSB0aGUg b2xkIENWUyByZXBvIHRvIFN1YnZlcnNpb24uCgogICBCcnlhbiBEcmV3ZXJ5IChiZHJld2VyeSkg am9pbmVkIHRoZSBQb3J0cyBNYW5hZ2VtZW50IHRlYW0gaW4gTWFyY2gsCiAgIGJyaW5naW5nIHdp dGggaGltIGhpcyB3ZWFsdGggb2Yga25vd2xlZGdlIGFuZCBza2lsbCBmcm9tIG1haW50YWluaW5n CiAgIHBvcnR1cGdyYWRlLCBwb3J0bWFzdGVyLCBhc3Npc3Rpbmcgd2l0aCBwa2duZywgYXMgd2Vs bCBhcyBjby1kZXZlbG9waW5nCiAgIHBvdWRyaWVyZS4KCk9wZW4gdGFza3M6CgogICAgMS4gTW9z dCBwb3J0cyBQUnMgYXJlIGFzc2lnbmVkLCB3ZSBub3cgbmVlZCB0byBmb2N1cyBvbiB0ZXN0aW5n LAogICAgICAgY29tbWl0dGluZyBhbmQgY2xvc2luZy4KICAgICBfX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KCkZyZWVCU0Qg UG9zdG1hc3RlciBUZWFtCgogICBDb250YWN0OiBEYXZpZCBXb2xmc2tpbGwgPHBvc3RtYXN0ZXJA RnJlZUJTRC5vcmc+CgogICBJbiB0aGUgZmlyc3QgcXVhcnRlciBvZiAyMDEzLCB0aGUgRnJlZUJT RCBQb3N0bWFzdGVyIFRlYW0gaGFzCiAgIGltcGxlbWVudGVkIHRoZSBmb2xsb3dpbmcgaXRlbXMg dGhhdCBtYXkgYmUgaW50ZXJlc3Qgb2YgdGhlIGdlbmVyYWwKICAgcHVibGljOgoKICAgICAqIENo YW5nZXMgaW4gY29uZmlndXJhdGlvbiBvZiBNYWlsbWFuLW1hbmFnZWQgbGlzdHM6IGFsbG93IHRv IGFjY2VwdAogICAgICAgdGhlIGFwcGxpY2F0aW9uL3BrY3M3LXNpZ25hdHVyZSBNSU1FIHR5cGUg KGluIGFkZGl0aW9uIHRvIHRoZQogICAgICAgYXBwbGljYXRpb24veC1wa2NzNy1zaWduYXR1cmUg TUlNRSB0eXBlKSwgdGh1cyBwZXJtaXR0aW5nIFMvTUlNRQogICAgICAgc2lnbmF0dXJlcyBvbiBs aXN0IG1haWwuCiAgICAgKiBOZXcgbGlzdHM6IGZyZWVic2Qtb3BzLWFubm91bmNlIC0tIGFubm91 bmNlbWVudHMgb2YgaW5mcmFzdHJ1Y3R1cmUKICAgICAgIGlzc3VlcywgYW5kIGZyZWVic2QtcGtn IC0tIGRpc2N1c3Npb24gb2YgYmluYXJ5IHBhY2thZ2UgbWFuYWdlbWVudAogICAgICAgYW5kIHBh Y2thZ2UgdG9vbHMuCiAgICAgX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fCgpGcmVlQlNEIFJlbGVhc2UgRW5naW5lZXJpbmcg VGVhbQoKICAgVVJMOiBodHRwOi8vd3d3LmZyZWVic2Qub3JnL3JlbGVhc2VzLzguNFIvc2NoZWR1 bGUuaHRtbAoKICAgQ29udGFjdDogRnJlZUJTRCBSZWxlYXNlIEVuZ2luZWVyaW5nIFRlYW0gPHJl QEZyZWVCU0Qub3JnPgoKICAgRnJlZUJTRCA4LjQtUkMxIGp1c3QgZ290IG91dCB0aGUgZG9vciBh bmQgd2UgYXJlIHBsYW5uaW5nIFJDMi4gQSBjb3VwbGUKICAgb2YgY3JpdGljYWwgZml4ZXMgaGF2 ZSBjb21lIGluIHRoYXQgd2lsbCBiZSBpbmNsdWRlZCBpbiBSQzIuIFRoZQogICBzY2hlZHVsZSBo YXMgc2xpcHBlZCBhYm91dCAxMCBkYXlzIHNvIGZhci4gV2UgYXJlIGV4cGVjdGluZyB0aGUgZmlu YWwKICAgcmVsZWFzZSBieSB0aGUgZW5kIG9mIEFwcmlsLiBQYWNrYWdlcyBmb3IgOC40IGhhdmUg YmVlbiBwcm92aWRlZCBieSBhCiAgIGZ1bGx5IG9wZXJhdGlvbmFsIHBhY2thZ2UgYnVpbGRpbmcg Y2x1c3Rlci4KICAgICBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX18KCkZyZWVCU0QvYXJtIFN1cGVycGFnZXMgZm9yIEFSTXY3 CgogICBVUkw6IGh0dHA6Ly9zdGF0aWMudXNlbml4Lm9yZy9ldmVudHMvb3NkaTAyL3RlY2gvZnVs bF9wYXBlcnMvbmF2YXJyby9uYXZhcnJvLnBkZgogICBVUkw6IGh0dHBzOi8vd2lraS5mcmVlYnNk Lm9yZy9BUk1TdXBlcnBhZ2VzCiAgIFVSTDogaHR0cHM6Ly9naXRodWIuY29tL3NlbWloYWxmLWJv ZGVrLXpiaWduaWV3L2ZyZWVic2QtYXJtLXN1cGVycGFnZXMuZ2l0CgogICBDb250YWN0OiBaYmln bmlldyBCb2RlayA8emJiQHNlbWloYWxmLmNvbT4KICAgQ29udGFjdDogR3J6ZWdvcnogQmVybmFj a2kgPGdqYkBzZW1paGFsZi5jb20+CiAgIENvbnRhY3Q6IFJhZmHFgiBKYXdvcm93c2tpIDxyYWpA c2VtaWhhbGYuY29tPgoKICAgQVJNIGFyY2hpdGVjdHVyZSBpcyBtb3JlIGFuZCBtb3JlIHByZXZh aWxpbmcsIG5vdCBvbmx5IGluIHRoZSBtb2JpbGUKICAgYW5kIGVtYmVkZGVkIHNwYWNlLiBBbW9u ZyB0aGUgbW9yZSBpbnRlcmVzdGluZyBpbmR1c3RyeSB0cmVuZHMgZW1lcmdpbmcKICAgaW4gdGhl IHJlY2VudCBtb250aHMgaGFzIGJlZW4gdGhlICJBUk0gc2VydmVyIiBjb25jZXB0LiBTb21lIHRv cC10aWVyCiAgIGNvbXBhbmllcyBzdGFydGVkIGRldmVsb3Bpbmcgc3lzdGVtcyBsaWtlIHRoaXMg YWxyZWFkeSAoRGVsbCwgSFApLgoKICAgS2V5IHRvIEZyZWVCU0Qgc3VjY2VzcyBpbiB0aGVzZSBu ZXcgYXJlYXMgYXJlIHNvcGhpc3RpY2F0ZWQgZmVhdHVyZXMsCiAgIGFtb25nIHRoZW0gYXJlIHN1 cGVycGFnZXMuCgogICBUaGUgb2JqZWN0aXZlIG9mIHRoaXMgcHJvamVjdCBpcyB0byBwcm92aWRl IEZyZWVCU0QvYXJtIHdpdGggdGhlCiAgIHN1cGVycGFnZXMgc3VwcG9ydCwgd2hpY2ggd2lsbCBh bGxvdyBmb3IgZWZmaWNpZW50IHVzZSBvZiBUTEIKICAgdHJhbnNsYXRpb25zIChlbmxhcmdlIFRM QiBjb3ZlcmFnZSksIGxlYWRpbmcgdG8gaW1wcm92ZWQgcGVyZm9ybWFuY2UgaW4KICAgbWFueSBh cHBsaWNhdGlvbnMgYW5kIHNjYWxhYmlsaXR5LiBJbmRpY2F0ZWQgZnVuY3Rpb25hbGl0eSBpcyBp bnRlbmRlZAogICB0byB3b3JrIG9uIEFSTXY3LWJhc2VkIHByb2Nlc3NvcnMsIGhvd2V2ZXIgY29t cGF0aWJpbGl0eSB3aXRoIEFSTXY2CiAgIHdpbGwgYmUgcHJlc2VydmVkLgoKICAgQ3VycmVudCBz dXBwb3J0IHN0YXR1czoKICAgICAqIFBvcnQgb2YgdGhlIHB2X2VudHJ5IGFsbG9jYXRvci4KICAg ICAqIFN3aXRjaCB0byAiQVBbMjoxXSIgYWNjZXNzIHBlcm1pc3Npb25zIG1vZGVsLgogICAgICog UFRFLWJhc2VkLCBwYWdlLXJlZmVyZW5jZWQvbW9kaWZpZWQgZW11bGF0aW9uLgogICAgICogRml4 ZXMgcmVnYXJkaW5nIHBhZ2UgcmVwbGFjZW1lbnQgc3RyYXRlZ3kuCiAgICAgKiBDb2RlIG9wdGlt aXphdGlvbnMgYW5kIGJ1ZyBmaXhlcy4KCiAgIE5leHQgc3RlcHM6CiAgICAgKiBEaXJ0eSBwYWdl cyBtYW5hZ2VtZW50LgogICAgICogR3JhZHVhbCBpbnRlZ3JhdGlvbiB0byBGcmVlQlNEIC1DVVJS RU5ULgogICAgICogRnVydGhlciBwbWFwIG9wdGltaXphdGlvbnMuCiAgICAgKiBGcmFnbWVudGF0 aW9uIGNvbnRyb2wgbWFuYWdlbWVudC4KICAgICAqIFRlc3RpbmcgYW5kIGJlbmNobWFya2luZy4K Ck9wZW4gdGFza3M6CgogICAgMS4gU3VwcG9ydCBmb3IgbXVsdGlwbGUgcGFnZSBzaXplcy4KICAg IDIuIEltcGxlbWVudGF0aW9uIG9mIHBhZ2UgcHJvbW90aW9uLCBkZW1vdGlvbiBhbmQgZXZpY3Rp b24gbWVjaGFuaXNtcy4KICAgICBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX18KCkZyZWVCU0QvQVJNIFRvb2xjaGFpbiBJbXBy b3ZlbWVudHMKCiAgIENvbnRhY3Q6IEFuZHJldyBUdXJuZXIgPGFuZHJld0BGcmVlQlNELm9yZz4K CiAgIENsYW5nIGhhcyBiZWVuIG1hZGUgdGhlIGRlZmF1bHQgY29tcGlsZXIgb24gQVJNLiBBIG51 bWJlciBvZiBpc3N1ZXMKICAgd2l0aCBMTFZNIGFuZCBjbGFuZyBoYXZlIGJlZW4gZm91bmQsIHJl cG9ydGVkLCBhbmQgZml4ZWQgdXBzdHJlYW0uCgogICBBbiBpc3N1ZSB3aGVyZSBzb21lIEFSTSBF QUJJIGFwcGxpY2F0aW9ucyBjb21waWxlZCB3aXRoIGNsYW5nIGNyYXNoIGhhcwogICBiZWVuIHJl cG9ydGVkIHVwc3RyZWFtIHdpdGggYSBwYXRjaCBhbmQgd2lsbCBiZSBicm91Z2h0IGludG8gdGhl CiAgIEZyZWVCU0QgdHJlZSB3aGVuIGl0IGlzIGFjY2VwdGVkLiBUaGUgb25seSBvdGhlciBpc3N1 ZSBibG9ja2luZyBtb3ZpbmcKICAgdG8gdGhlIEFSTSBFQUJJIGlzIEMrKyBleGNlcHRpb25zIGZh aWwgdG8gd29yayBjb3JyZWN0bHkgd2l0aCBzaGFyZWQKICAgb2JqZWN0cy4gVGhpcyB3aWxsIG5l ZWQgdXMgdG8gZWl0aGVyIGltcG9ydCBsaWJ1bndpbmQgb3IgaW1wbGVtZW50IHRoZQogICBmdW5j dGlvbnMgbGliZ2NjX3MgcmVxdWlyZXMgdG8gZmluZCB0aGUgY29ycmVjdCB1bndpbmQgdGFibGUu CgpPcGVuIHRhc2tzOgoKICAgIDEuIEZpeCBleGNlcHRpb24gaGFuZGxpbmcgZm9yIEVBQkkuCiAg ICAgX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fCgpGcmVlTkFTCgogICBVUkw6IGh0dHA6Ly93d3cuRnJlZU5BUy5vcmcvCgog ICBDb250YWN0OiBBbGZyZWQgUGVybHN0ZWluIDxhbGZyZWRARnJlZUJTRC5vcmc+CiAgIENvbnRh Y3Q6IEpvc2ggUGFldHplbCA8anBhZXR6ZWxARnJlZUJTRC5vcmc+CgogICBGcmVlTkFTIDguMy4x LVJFTEVBU0UtcDIgd2lsbCBoaXQgU291cmNlZm9yZ2UgdGhlIHNlY29uZCB3ZWVrIG9mIEFwcmls LAogICBhbmQgc2hvdWxkIGVuZCB1cCBhcyB0aGUgbGFzdCBGcmVlTkFTIHJlbGVhc2UgYmFzZWQg b24gRnJlZUJTRCA4LlggSXQncwogICBjdXJyZW50bHkgdGhlIG9ubHkgRnJlZSBPcGVuIFNvdXJj ZSBOQVMgcHJvZHVjdCBhdmFpbGFibGUgd2l0aCBhbnkgZm9ybQogICBvZiBaRlMgZW5jcnlwdGlv biAocHJvdmlkZWQgYnkgR0VMSSkuCgpPcGVuIHRhc2tzOgoKICAgIDEuIFRoZSB0ZWFtIGlzIGhh cmQgYXQgd29yayBvbiBnZXR0aW5nIGEgRnJlZUJTRCA5LlgtYmFzZWQgcmVsZWFzZSBvZgogICAg ICAgRnJlZU5BUyByZWFkeS4gQ3VycmVudGx5IHRoZXJlIGFyZSBzZXZlcmFsIG5pZ2h0bHkgc25h cHNob3RzCiAgICAgICBhdmFpbGFibGUuCiAgICAyLiBBZGQgSEFTVCB0byB0aGUgd2ViaW50ZXJm YWNlLgogICAgMy4gTWlncmF0ZSB0byBORlN2NC4KICAgIDQuIEludGVncmF0ZSBmb3VuZGF0aW9u IHNwb25zb3JlZCBrZXJuZWwgaVNDU0kgdGFyZ2V0LgogICAgIF9fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwoKR05PTUUvRnJl ZUJTRAoKICAgVVJMOiBodHRwOi8vd3d3LmZyZWVic2Qub3JnL2dub21lCiAgIFVSTDogaHR0cDov L3d3dy5mcmVlYnNkLm9yZy9nbm9tZS9kb2NzL2RldmVsZmFxLmh0bWwKICAgVVJMOiBodHRwOi8v d3d3Lm1hcmN1c2NvbS5jb206ODA4MC92aWV3dmMvdmlld3ZjLmNnaS9tYXJjdXNjb20KICAgVVJM OiBodHRwczovL2dpdGh1Yi5jb20vamxtZXNzNzcvbWF0ZS1wb3J0cwoKICAgQ29udGFjdDogRnJl ZUJTRCBHTk9NRSB0ZWFtIDxnbm9tZUBGcmVlQlNELm9yZz4KCiAgIFRoZSBHTk9NRS9GcmVlQlNE IFRlYW0gaGFzIHJlY2VudGx5IG1lcmdlZCBHbGliIDIuMzQsIEd0aysgMi4yNC4xNyBhbmQKICAg R3RrKyAzLjYuNCBpbnRvIHBvcnRzLCB0aGUgQysrIGJpbmRpbmdzIGFsc28gaGF2ZSBnb3QgdXBk YXRlcy4gSW4KICAgYWRkaXRpb25hbCAibG93LWxldmVsIiBHTk9NRSBwb3J0cyByZWNlaXZlZCB1 cGRhdGVzLCBsaWtlIGxpYnNvdXAsCiAgIGdvYmplY3QtaW50cm9zcGVjdGlvbiwgYXRrIGFuZCB2 YWxhIGZvciBleGFtcGxlLiBUaGUgdGVsZXBhdGh5IHN0YWNrCiAgIGFuZCBlbXBhdGh5IHdoZXJl IGFsc28gdXBkYXRlZC4KCiAgIFRoZSBVU0VfR05PTUUgbWFjcm8gaGFzIHJlY2VpdmVkIHN1cHBv cnQgZm9yIDpydW4gYW5kIDpidWlsZCB0YXJnZXRzCiAgIHRoYW5rcyB0byBKZXJlbXkgTWVzc2Vu Z2VyIChtZXp6KS4gQ3VycmVudGx5IG9ubHkgbGlieG1sMiBhbmQgbGlieHNsdAogICBzdXBwb3J0 IHRoZXNlIHRhcmdldHMuCgogICBVU0VfR05PTUU9cGtnY29uZmlnIGlzIGJlaW5nIGRlcHJlY2F0 ZWQgaW4gZmF2b3Igb2YKICAgVVNFX1BLR0NPTkZJRz1idWlsZC4gVGhlIGZvcm1lciBhbHNvIGFk ZHMgYSBydW4gZGVwZW5kZW5jeSBvbgogICBwa2ctY29uZmlnLCB3aGljaCBpcyBub3QgcmVxdWly ZWQuIEEgZmlyc3QgcGFzcyB3YXMgZG9uZSB0byBnZXQgcmlkIG9mCiAgIHRoaXMgaW4gdGhlIEds aWIgdXBkYXRlIHRvIDIuMzQuIEluIGNvb3BlcmF0aW9uIHdpdGggdGhlIFgxMSBUZWFtLCB0aGUK ICAgdXNhZ2Ugb2YgVVNFX0dOT01FPXBrZ2NvbmZpZyBpbiBYIGNvbXBvbmVudHMgd2lsbCBiZSBy ZW1vdmVkLiBBZnRlciB0aGUKICAgZmFsbG91dCBmcm9tIHRoaXMgaXMgaGFuZGxlZCBhbmQgc3Ry YW5nbGVycyBhcmUgY29udmVydGVkLCB0aGUKICAgVVNFX0dOT01FIG9wdGlvbiB3aWxsIGJlIHJl bW92ZWQuCgogICBJbiBhZGRpdGlvbiBVU0VfR05PTUU9Z25vbWVoYWNrIGlzIGRlcHJlY2F0ZWQg YW5kIHNob3VsZCBub3QgYmUgdXNlZC4KICAgUGxlYXNlIHJlcGxhY2UgaXQgd2l0aCBVU0VTPXBh dGhmaXguCgogICBUaGUgR05PTUUgZGV2ZWxvcG1lbnQgcmVwb3NpdG9yeSBoYXMgc3dpdGNoZWQg ZnJvbSBDVlMgdG8gU1ZOLiBDVlMgd2lsbAogICBub3QgZ2V0IGFueSBtb3JlIHVwZGF0ZXMuIFVz ZXMgY2FuIGdldCBhIG5ldyB2ZXJzaW9uIG9mIHRoZSBtYXJjdXNtZXJnZQogICBzY3JpcHQgdGhh dCBzdXBwb3J0cyBTVk4gZnJvbSBpdHMgaG9tZSBwYWdlLCBhbmQgc2hvdWxkIHJlbW92ZSB0aGUg b2xkCiAgIENWUyBjaGVja291dCAicG9ydHMiIGRpci4KCiAgICAgKiBTVk4gYW5vbnltb3VzIHJv b3Q6IHN2bjovL2NyZW1lLWJydWxlZS5tYXJjdXNjb20uY29tLyBvcgogICAgICAgc3ZuOi8vc3Vz aGkubWFyY3VzY29tLmNvbS8gKElQdjYpCiAgICAgKiBWaWV3VkM6IGh0dHA6Ly93d3cubWFyY3Vz Y29tLmNvbTo4MDgwL3ZpZXd2Yy92aWV3dmMuY2dpL21hcmN1c2NvbQoKICAgT24tZ29pbmcgZWZm b3J0czoKCiAgICAgKiBnbGliIDIuMzYsIHBhbmdvIDEuMzQuMCwgZ3RrIDMuOC4wIGFuZCBnb2Jq ZWN0LWludHJvc3BlY3Rpb24gMS4zNi4wCiAgICAgICB3aGVyZSB1cGRhdGVkIGluIHRoZSBHTk9N RSBkZXZlbG9wbWVudCByZXBvc2l0b3J5LgogICAgICogR3VzdGF1IFBlcmV6IGkgUXVlcm9sIHN0 ZXBwZWQgdXAgYW5kIHN0YXJ0ZWQgd29yayBvbiB1cGRhdGluZyB0aGUKICAgICAgIG9sZCBHTk9N RSAzLjQgcG9ydHMgdG8gMy42LiBBdCB0aGUgbW9tZW50IG9mIHdyaXRpbmcgdGhlc2UgYXJlIG5v dAogICAgICAgYXZhaWxhYmxlIGluIHRoZSBHTk9NRSBkZXZlbG9wbWVudCByZXBvc2l0b3J5IGp1 c3QgeWV0LiBGb3IgaGlzCiAgICAgICBlZmZvcnRzLCBoZSB3YXMgYXdhcmRlZCBhIEZyZWVCU0Qg R05PTUUgdGVhbSBtZW1iZXJzaGlwLgogICAgICogSmVyZW15IE1lc3NlbmdlciAobWV6eikgaGFz IGNvbXBsZXRlZCBNYXRlIDEuNiB3aGljaCB3aWxsIGJlCiAgICAgICBhcnJpdmluZyBpbiBwb3J0 cyBuZWFyIHlvdSB3aGVuIGRlZW1lZCBzdGFibGUgZW5vdWdoLgoKICAgSWYgeW91IHdhbnQgdG8g aGVscCB3aXRoIGtlZXBpbmcgdGhlIGRvY3VtZW50YXRpb24gdXBkYXRlZCBvciBoZWxwaW5nCiAg IG91dCBpbiBvdGhlciB3YXlzLCBldmVuIGlmIGl0IG9ubHkgcGFydHMgZm9yIHRoZSBHbGliL0d0 ay9HTk9NRSBzdGFjawogICB5b3UgYXJlIGludGVyZXN0ZWQgaW4sIHBsZWFzZSBjb250YWN0IHVz IQoKT3BlbiB0YXNrczoKCiAgICAxLiBVcGRhdGUgdGhlIEZyZWVCU0Qub3JnL2dub21lIHdlYnNp dGUsIGluIHBhcnRpY3VsYXIgdGhlIGRldmVsb3BlcgogICAgICAgaW5mb3JtYXRpb24gYWJvdXQg VVNFX0dOT01FLCBtYXliZSBwdXQgdGhhdCBzZWN0aW9uIGluIHRoZSBQb3J0ZXIncwogICAgICAg SGFuZGJvb2sgaW5zdGVhZC4KICAgIDIuIE1lcmdlIG1vcmUgdXBkYXRlZCBwb3J0cyBmcm9tIE1D IHRvIHBvcnRzLgogICAgMy4gVGVzdGluZyBsYXRlc3QgR2xpYi9HdGsgcmVsZWFzZXMgd2l0aCBl eGlzdGluZyBwb3J0cywgYW5kIGltcG9ydCBpdAogICAgICAgaW50byBwb3J0cyB3aGVuIGl0IGlz IHJlYWR5LgogICAgNC4gQWZ0ZXIgcG9ydGluZyBHTk9NRSAzLjYgcnVuIHRlc3RzIGFuZCBmaXgg YnVncy4KICAgICBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX18KCkltcHJvdmluZyB0aGUgRG9jdW1lbnRhdGlvbiBQcm9qZWN0 IEluZnJhc3RydWN0cmUKCiAgIFVSTDogaHR0cDovL3N2bndlYi5mcmVlYnNkLm9yZy9kb2MvcHJv amVjdHMveG1sLXRvb2xzLwoKICAgQ29udGFjdDogR8OhYm9yIEvDtnZlc2TDoW4gPGdhYm9yQEZy ZWVCU0Qub3JnPgoKICAgVGhlcmUgaXMgYW4gb24tZ29pbmcgd29yayB0byBpbXByb3ZlIHRoZSBk b2N1bWVudGF0aW9uIGluZnJhc3RydWN0dXJlCiAgIGFuZCBtb2Rlcm5pemUgb3VyIGRvY3VtZW50 YXRpb24gdG9vbGNoYWluLiBUaGUgd29yayBjYW4gYmUgZm91bmQgaW4gdGhlCiAgIHhtbC10b29s cyBicmFuY2ggYW5kIGlzIHZlcnkgbmVhciB0byBjb21wbGV0aW9uLiBUaGUgaW1wcm92ZW1lbnRz CiAgIGluY2x1ZGUgdGhlIGZvbGxvd2luZzoKCiAgICAgKiBVcGdyYWRlIHRvIERvY0Jvb2sgNC41 LgogICAgICogVXNlIFhTTFQgaW5zdGVhZCBvZiBEU1NTTCB0byByZW5kZXIgWEhUTUwtYmFzZWQg b3V0cHV0LgogICAgICogR2VuZXJhdGUgUERGIGZyb20gUFMgYW5kIHNpbXBsaWZ5IGltYWdlIHBy b2Nlc3NpbmcuCiAgICAgKiBGaXggbWFrZSBsaW50IGFuZCB2YWxpZGF0ZSB0aGUgd2hvbGUgZG9j dW1lbnRhdGlvbiBzZXQuCiAgICAgKiBGaXggcmVuZGVyaW5nIG9mIFRPQyBlbGVtZW50cy4KICAg ICAqIEZpeCBtaXN1c2VkIGxpbmsgZWxlbWVudHMgdGhhdCByZXN1bHRlZCBpbiBhIGNvcnJ1cHQg cmVuZGVyaW5nLgogICAgICogVXNlIG1vcmUgaHVtYW4tZnJpZW5kbHkgcHVibGljYXRpb24gZGF0 YSBhbmQgcmVsZWFzZSBpbmZvCiAgICAgICByZW5kZXJpbmcuCiAgICAgKiBBZGQgc3VwcG9ydCBm b3IgWEluY2x1ZGUgaW4gRG9jQm9vayBkb2N1bWVudHMuCiAgICAgKiBBZGQgc3VwcG9ydCBmb3Ig cHJvZmlsaW5nIHdpdGggYXR0cmlidXRlcy4KICAgICAqIEFkZCBzdXBwb3J0IGZvciBTY2hlbWF0 cm9uIGNvbnN0cmFpbnRzLgogICAgICogQWRkIGV4cGVyaW1lbnRhbCBlcHViIHN1cHBvcnQuCiAg ICAgKiBBZGQgZXhwZXJpbWVudGFsIHN1cHBvcnQgZm9yIFhTTC1GTy1iYXNlZCBwcmludGVkIG91 dHB1dC4KICAgICAqIENsZWFuIHVwIG9ic29sZXRlIFNHTUwgY29uc3RydWN0cy4KICAgICAqIENs ZWFuIHVwIGNhdGFsb2dzLgogICAgICogRHJvcCBIVE1MIFRpZHkgc2luY2UgaXQgaXMgbm90IG5l ZWRlZCBhbnkgbW9yZS4KCiAgIFRoZSBjaGFuZ2VzIGVsaW1pbmF0ZSBzb21lIGRlcGVuZGVuY2ll cyBhbmQgc3dpdGNoIHRoZSBkb2MgcmVwb3NpdG9yeQogICB0byBhIHJlYWwgWE1MIHRvb2xjaGFp biB3aXRoIHByb3BlciB2YWxpZGF0aW9uIGFuZCBtb3JlIGFkdmFuY2VkCiAgIHJlbmRlcmluZyB0 b29scy4gVGhlIG9ubHkgZXhjZXB0aW9ucyBhcmUgSmFkZSBhbmQgdGhlIERTU1NMCiAgIHN0eWxl c2hlZXRzLCB3aGljaCBhcmUgc3RpbGwgbmVlZGVkIGZvciBwcmludGVkIG91dHB1dC4KCk9wZW4g dGFza3M6CgogICAgMS4gRml4IHJlbmRlcmluZyBwcm9ibGVtcyB3aXRoIGltYWdlcyBpbiBwcmlu dGVkIGZvcm1hdHMuCiAgICAyLiBVcGRhdGUgdGhlIERvY3VtZW50YXRpb24gUHJpbWVyIHRvIHJl ZmxlY3QgY2hhbmdlcy4KICAgICBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX18KCktERS9GcmVlQlNECgogICBVUkw6IGh0dHA6 Ly9GcmVlQlNELmtkZS5vcmcKICAgVVJMOiBodHRwOi8vRnJlZUJTRC5rZGUub3JnL2FyZWE1MS5w aHAKCiAgIENvbnRhY3Q6IEtERSBGcmVlQlNEIDxrZGVARnJlZUJTRC5vcmc+CgogICBUaGUgS0RF L0ZyZWVCU0QgVGVhbSBpcyB2ZXJ5IHByb3VkIHRvIGhhdmUgU2NoYWljaCBBbG9uc28gKGFzY2hh aSkKICAgam9pbmluZyB0aGUgdGVhbS4gV2VsY29tZSEKCiAgIFRoZSBLREUvRnJlZUJTRCBUZWFt IGhhdmUgY29udGludWVkIHRvIGltcHJvdmUgdGhlIGV4cGVyaWVuY2Ugb2YgS0RFCiAgIHNvZnR3 YXJlIGFuZCBRdCB1bmRlciBGcmVlQlNELiBUaGUgbGF0ZXN0IHJvdW5kIG9mIGltcHJvdmVtZW50 cwogICBpbmNsdWRlOgoKICAgICAqIEZpeCBwcm9ibGVtcyBlc3RhYmxpc2hpbmcgVURQIGNvbm5l Y3Rpb25zLgoKICAgVGhlIFRlYW0gaGF2ZSBhbHNvIG1hZGUgbWFueSByZWxlYXNlcyBhbmQgdXBz dHJlYW1lZCBtYW55IGZpeGVzIGFuZAogICBwYXRjaGVzLiBUaGUgbGF0ZXN0IHJvdW5kIG9mIHJl bGVhc2VzIGluY2x1ZGU6CgogICAgICogS0RFIFNDOiA0LjkuNSwgNC4xMC4xIChwb3J0cykKICAg ICAqIFF0OiA1LjAuMCAoYXJlYTUxKSBhbmQgNC44LjQgKHBvcnRzKQogICAgICogUHlRdDogNC45 LjYgKHBvcnRzKTsgUVNjaW50aWxsYSAyLjcgKHBvcnRzKTsgU0lQOiA0LjE0LjIgKGFyZWE1MSkK ICAgICAgIGFuZCA0LjE0LjMgKHBvcnRzKQogICAgICogS0RldmVsb3A6IDQuNC4xIChwb3J0cyk7 IEtEZXZQbGF0Zm9ybTogMS40LjEgKHBvcnRzKQogICAgICogQ2FsbGlncmE6IDIuNS41LCAyLjYu MiAocG9ydHMpCiAgICAgKiBBbWFyb2s6IDIuNy4wCiAgICAgKiBDTWFrZTogMi44LjEwLjIKICAg ICAqIERpZ2lrYW0gKGFuZCBLSVBJLXBsdWdpbnMpOiAzLjEuMCAoYXJlYTUxKQogICAgICogUXRD cmVhdG9yOiA0LjYuMSAocG9ydHMpCiAgICAgKiBLREUgVGVsZXBhdGh5IDAuNi4wIChhcmVhNTEp CiAgICAgKiBtYW55IHNtYWxsZXIgcG9ydHMKCiAgIEFzIGEgcmVzdWx0IC0tIGFjY29yZGluZyB0 byBQb3J0U2NvdXQgLS0gd2UgaGF2ZSA0MzEgcG9ydHMsIG9mIHdoaWNoCiAgIDkzLjUlIChmcm9t IDkxJSkgYXJlIHVwLXRvLWRhdGUuCgogICBUaGUgVGVhbSBhcmUgYWx3YXlzIGxvb2tpbmcgZm9y IG1vcmUgdGVzdGVycyBhbmQgcG9ydGVycyBzbyBwbGVhc2UKICAgY29udGFjdCB1cyBhbmQgdmlz aXQgb3VyIGhvbWUgcGFnZS4KCk9wZW4gdGFza3M6CgogICAgMS4gVXBkYXRpbmcgb3V0LW9mLWRh dGUgcG9ydHMsIHNlZSBQb3J0U2NvdXQgZm9yIGEgbGlzdC4KICAgICBfX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KCktlcm5l bCBJbmZvcm1hdGlvbiBpbiBQcm9jZXNzIENvcmUgRHVtcHMKCiAgIENvbnRhY3Q6IE1pa29sYWog R29sdWIgPHRyb2NpbnlAZnJlZWJzZC5vcmc+CgogICBXaGVuIGRvaW5nIHBvc3Rtb3J0ZW0gYW5h bHlzaXMgb2YgYSBjcmFzaGVkIHByb2Nlc3MgaXQgaXMgc29tZXRpbWVzCiAgIHZlcnkgdXNlZnVs IHRvIGhhdmUga2VybmVsIGluZm9ybWF0aW9uIGFib3V0IHRoZSBwcm9jZXNzIGF0IHRoZSBtb21l bnQKICAgb2YgdGhlIGNyYXNoLCBsaWtlIG9wZW4gZmlsZSBkZXNjcmlwdG9ycyBvciByZXNvdXJj ZSBsaW1pdHMuIEZvciBhIGxpdmUKICAgcHJvY2VzcyB0aGlzIGluZm9ybWF0aW9uIGNhbiBiZSBv YnRhaW5lZCB2aWEgc3lzY3RsKDMpIGludGVyZmFjZSBlLmcuCiAgIHVzaW5nIHByb2NzdGF0KDEp LgoKICAgVGhlIGFpbSBvZiB0aGUgcHJvamVjdCBpcyB0byBhZGQgYWRkaXRpb25hbCBub3RlcyB0 byBhIHByb2Nlc3MgY29yZQogICBkdW1wLCB3aGljaCBpbmNsdWRlIHByb2Nlc3MgaW5mb3JtYXRp b24gZnJvbSB0aGUga2VybmVsIGF0IHRoZSBtb21lbnQKICAgb2YgdGhlIHByb2Nlc3MgY3Jhc2gs IHRlYWNoIGxpYnByb2NzdGF0KDMpIHRvIGV4dHJhY3QgdGhpcyBpbmZvcm1hdGlvbgogICBhbmQg bWFrZSBwcm9jc3RhdCgxKSB1c2UgdGhpcyBmdW5jdGlvbmFsaXR5LgoKICAgQXQgdGhlIG1vbWVu dCBhbGwgbmVjZXNzYXJ5IGNvZGUgY2hhbmdlcyBhcmUgY29tbWl0dGVkIHRvIEhFQUQgYW5kIGFy ZQogICBnb2luZyB0byBiZSBtZXJnZSB0byBzdGFibGUvOSBpbiAxIG1vbnRoLgogICAgIF9fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fXwoKbWRvYy5zdSAtLSBTaG9ydCBNYW51YWwgUGFnZSBVUkxzCgogICBVUkw6IGh0dHA6Ly9t ZG9jLnN1LwogICBVUkw6IGh0dHA6Ly9uZ2lueC5jb25mLm1kb2Muc3UvbWRvYy5zdS5uZ2lueC5j b25mCiAgIFVSTDogaHR0cHM6Ly9naXRodWIuY29tL2Nuc3QvbWRvYy5zdQogICBVUkw6IGh0dHA6 Ly9saXN0cy5mcmVlYnNkLm9yZy9waXBlcm1haWwvZnJlZWJzZC1kb2MvMjAxMy1GZWJydWFyeS8w MjE0NjUuaHRtbAoKICAgQ29udGFjdDogQ29uc3RhbnRpbmUgQS4gTXVyZW5pbiA8Y25zdCsrQEZy ZWVCU0Qub3JnPgoKICAgbWRvYy5zdSBpcyBhIGRldGVybWluaXN0aWMgVVJMIHNob3J0ZW5lciBm b3IgQlNEIG1hbnVhbCBwYWdlcywgd3JpdHRlbgogICBlbnRpcmVseSBpbiBuZ2lueC5jb25mLgoK ICAgU2luY2UgdGhlIG9yaWdpbmFsIGFubm91bmNlbWVudCwgT1MgdmVyc2lvbiBzdXBwb3J0IGhh cyBiZWVuIGFkZGVkCiAgIChlLmcuIC9mOTEvIGFuZCAvRnJlZUJTRC05LjEvIGV0Yy4pLCBhcyB3 ZWxsIGFzIGR5bmFtaWMgbXVsdGktZmxhdm91cgogICB3ZWItcGFnZXMgd2l0aCBtdWx0aXBsZSBs aW5rcyAoZS5nLiBodHRwOi8vbWRvYy5zdS9mLGQvaWZuZXQuOSBhbmQKICAgaHR0cDovL21kb2Mu c3UvLS9tZG9jKSwgd2hpY2ggZXZlbiBsZXQgeW91IHNwZWNpZnkgdGhlIHZlcnNpb25zIHRvbwog ICAoZS5nLiBodHRwOi8vbWRvYy5zdS9mOTEsbjYwLG81MixkL21kb2MpLgoKICAgVGhlIHNvdXJj ZSBjb2RlIGZvciB0aGUgd2hvbGUgc2l0ZSBpcyBhdmFpbGFibGUgdW5kZXIgYSBCU0QgbGljZW5j ZS4KCk9wZW4gdGFza3M6CgogICAgMS4gRm9yayBpdCBvbiBHaXRIdWIgKHNlZSBsaW5rcykhCiAg ICAgX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fCgpNdWx0aXBhdGggVENQIChNUFRDUCkgZm9yIEZyZWVCU0QKCiAgIFVSTDog aHR0cDovL2NhaWEuc3dpbi5lZHUuYXUvdXJwL25ld3RjcC9tcHRjcC90b29scy5odG1sCiAgIFVS TDogaHR0cDovL2NhaWEuc3dpbi5lZHUuYXUvbmV3dGNwL21wdGNwLwogICBVUkw6IGh0dHA6Ly9j YWlhLnN3aW4uZWR1LmF1L3JlcG9ydHMvMTMwNDI0QS9DQUlBLVRSLTEzMDQyNEEucGRmCiAgIFVS TDogaHR0cHM6Ly9wdWIuYWxsYnNkLm9yZy9GcmVlQlNELXNuYXBzaG90cy8KCiAgIENvbnRhY3Q6 IE5pZ2VsIFdpbGxpYW1zIDxuandpbGxpYW1zQHN3aW4uZWR1LmF1PgogICBDb250YWN0OiBMYXdy ZW5jZSBTdGV3YXJ0IDxsYXN0ZXdhcnRAc3dpbi5lZHUuYXU+CiAgIENvbnRhY3Q6IEdyZW52aWxs ZSBBcm1pdGFnZSA8Z2FybWl0YWdlQHN3aW4uZWR1LmF1PgoKICAgV2UgaGF2ZSBiZWVuIHdvcmtp bmcgdG8gY3JlYXRlIGEgQlNELWxpY2Vuc2VkIGltcGxlbWVudGF0aW9uIG9mCiAgIE11bHRpcGF0 aCBUQ1AgLS0gYSBzZXQgb2YgVENQIGV4dGVuc2lvbnMgdGhhdCBhbGxvdyBmb3IgdHJhbnNwYXJl bnQKICAgbXVsdGlwYXRoIG9wZXJhdGlvbiB3aXRoIG11bHRpcGxlIElQIGFkZHJlc3NlcyBhcyBz cGVjaWZpZWQgaW4KICAgZXhwZXJpbWVudGFsIFJGQzY4MjQuCgogICBXZSBtYWRlIG91ciBmaXJz dCB2MC4xIHB1YmxpYyByZWxlYXNlIG9uIDIwMTMtMDMtMTEgYW5kIHJlY2VudGx5CiAgIHJlbGVh c2VkIHYwLjMgb24gMjAxMy0wNC0xNi4gVGhlIGNvZGUgaXMgY3VycmVudGx5IGNvbnNpZGVyZWQg dG8gYmUgb2YKICAgYWxwaGEgcXVhbGl0eS4gV2UgYXJlIHdvcmtpbmcgdG93YXJkcyBwdXNoaW5n IHRoZSBjb2RlIGludG8gYSBGcmVlQlNECiAgIFN1YnZlcnNpb24gcmVwb3NpdG9yeSBwcm9qZWN0 IGJyYW5jaCB0byBjb250aW51ZSB0aGUgb24tZ29pbmcKICAgZGV2ZWxvcG1lbnQgZWZmb3J0IGlu IGEgbW9yZSBwdWJsaWNseSBhY2Nlc3NpYmxlIGxvY2F0aW9uLiBBcyBwYXJ0IG9mCiAgIHRoaXMg bW92ZSwgd2UgaG9wZSB0byBiZWdpbiByZWxlYXNpbmcgcmVndWxhciBzbmFwc2hvdCBpbnN0YWxs ZXIgSVNPcwogICBvZiB0aGUgTVBUQ1AgcHJvamVjdCBicmFuY2ggY291cnRlc3kgb2YgSGlyb2tp IFNhdG8gYW5kIHRoZSBhbGxic2Qub3JnCiAgIGRhaWx5IHNuYXBzaG90IGluZnJhc3RydWN0dXJl LgoKICAgV2UgYXJlIGFib3V0IHRvIHJlbGVhc2UgYSBDQUlBIHRlY2huaWNhbCByZXBvcnQgMTMw NDI0QSBlbnRpdGxlZAogICAiRGVzaWduIE92ZXJ2aWV3IG9mIE11bHRpcGF0aCBUQ1AgdmVyc2lv biAwLjMgZm9yIEZyZWVCU0QgMTAiIG9uCiAgIDIwMTMtMDQtMjQgd2hpY2ggcHJvdmlkZXMgYSBo aWdoLWxldmVsIGRlc2lnbiBhbmQgYXJjaGl0ZWN0dXJlIG92ZXJ2aWV3CiAgIG9mIHRoZSB2MC4z IGNvZGUgcmVsZWFzZS4KCiAgIEdvaW5nIGZvcndhcmQsIHdlIGV4cGVjdCB0byBjb250aW51ZSBk ZXZlbG9wbWVudCBhbmQgcmVsZWFzZSBhZGRpdGlvbmFsCiAgIHRlY2huaWNhbCByZXBvcnRzIGFu ZCBhY2FkZW1pYyBwYXBlcnMgY292ZXJpbmcgdG9waWNzIHN1Y2ggYXMKICAgcGVyZm9ybWFuY2Ug YW5hbHlzaXMgYW5kIG11bHRpcGF0aCBjb25nZXN0aW9uIGNvbnRyb2wvc2NoZWR1bGluZy4KCk9w ZW4gdGFza3M6CgogICAgMS4gVGhlIGNvZGUgaXMgY3VycmVudGx5IG9mIGFscGhhIHF1YWxpdHkg c28gd2Ugd2VsY29tZSBhbGwgdGVzdGluZwogICAgICAgZmVlZGJhY2ssIGJ1dCBwbGVhc2UgZmFt aWxpYXJpemUgeW91cnNlbGYgd2l0aCB0aGUgUkVBRE1FIGZpbGUgYW5kCiAgICAgICAiS25vd24g TGltaXRhdGlvbnMiIHNlY3Rpb24gaW4gcGFydGljdWxhciBiZWZvcmUganVtcGluZyBpbi4KICAg ICBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX18KCk5hdGl2ZSBpU0NTSSBTdGFjawoKICAgVVJMOiBodHRwczovL3dpa2kuZnJl ZWJzZC5vcmcvTmF0aXZlJTIwaVNDU0klMjB0YXJnZXQKCiAgIENvbnRhY3Q6IEVkd2FyZCBUb21h c3ogTmFwaWVyYWwvYSA8dHJhc3pARnJlZUJTRC5vcmc+CgogICBGb2N1cyBvZiB0aGUgcHJvamVj dCB3YXMgZXh0ZW5kZWQgdG8gYWxzbyBpbmNsdWRlIGEgbmV3IGlTQ1NJCiAgIGluaXRpYXRvci4g Q29tcGFyZWQgdG8gdGhlIG9sZCBvbmUsIGl0IGlzIG1vcmUgcmVsaWFibGUsIG11Y2ggbW9yZQog ICB1c2VyLWZyaWVuZGx5LCBhbmQgc29tZXdoYXQgZmFzdGVyLiBJdCB1c2VzIGV4YWN0bHkgdGhl IHNhbWUKICAgY29uZmlndXJhdGlvbiBmaWxlIGZvcm1hdCBhcyB0aGUgb2xkIG9uZSB0byBtYWtl IG1pZ3JhdGlvbiBlYXNpZXIuCgogICBBcyBmb3IgdGhlIHRhcmdldCBzaWRlLCBpdCB3YXMgdmVy aWZpZWQgdG8gd29yayBwcm9wZXJseSBhZ2FpbnN0IG1ham9yCiAgIGluaXRpYXRvcnMgKEZyZWVC U0QsIExpbnV4LCBTb2xhcmlzLCBXaW5kb3dzIGFuZCBWTVdhcmUgRVNYKS4KCiAgIFRoaXMgcHJv amVjdCBpcyBiZWluZyBzcG9uc29yZWQgYnkgRnJlZUJTRCBGb3VuZGF0aW9uLgoKT3BlbiB0YXNr czoKCiAgICAxLiBSRE1BIHN1cHBvcnQsIGZvciBib3RoIHRoZSB0YXJnZXQgYW5kIHRoZSBpbml0 aWF0b3IuCiAgICAyLiBQZXJmb3JtYW5jZSBvcHRpbWl6YXRpb24uCiAgICAgX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCgpQ eVB5CgogICBVUkw6IGh0dHA6Ly93aWtpLkZyZWVCU0Qub3JnL1B5UHkKCiAgIENvbnRhY3Q6IERh dmlkIE5heWxvciA8ZGJuQEZyZWVCU0Qub3JnPgoKICAgUHlQeSBoYXMgYmVlbiBzdWNjZXNzZnVs bHkgdXBkYXRlZCB0byAyLjAtYmV0YTEgd2l0aCAyLjAtYmV0YTIKICAgZmluaXNoaW5nIHRyYW5z bGF0aW5nIGFuZCBvdGhlciB0ZXN0cy4gTWFueSBtYWpvciBjaGFuZ2VzIHdlcmUgbWFkZSB0bwog ICB0aGUgUHlQeSBwb3J0IGZyIHRoZSAyLjAtYmV0YTEgcmVsZWFzZSwgdGhlc2UgaW5jbHVkZToK CiAgICAgKiBSZXdvcmtpbmcgdGhlIGJ1aWxkIHNjcmlwdC4KICAgICAqIE9wdGlvbmFsbHkgdXNl IHB5cHkgKHdoZW4gYXZhaWxhYmxlKSBmb3Igc2VsZi10cmFuc2xhdGluZy4KICAgICAqIFJlZmlu ZSBtZW1vcnkgY2hlY2tzLgogICAgICogRml4IHRoZSB0ZXN0IHRhcmdldC4KCiAgIEFsdGhvdWdo IHRoZSBwb3J0IGlzIGluIGEgaGVhbHRoeSBzdGF0ZTsgUHlQeSBvbiBGcmVlQlNEIGhhcyBzb21l IHJvdWdoCiAgIGVkZ2VzIChzZWUgbWFrZSB0ZXN0IGZvciBleGFtcGxlcyBvZiByb3VnaG5lc3Mp LgoKT3BlbiB0YXNrczoKCiAgICAxLiBGaXggZmFpbGVkIHVuaXQgdGVzdHMuCiAgICAyLiBJbnRl Z3JhdGUgUHlQeSBpbnRvIGJzZC5weXRob24ubWsuCiAgICAzLiBTZWUgdGhlIHByb2plY3QgcGFn ZSBmb3IgbW9yZSBpdGVtcy4KICAgICBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KCnJhY2N0OiBCbG9jayBJTyBBY2NvdW50 aW5nCgogICBVUkw6IGh0dHBzOi8vd2lraS5mcmVlYnNkLm9yZy9SdWRvbGZUb21vcmkvSU9MaW1p dHMKCiAgIENvbnRhY3Q6IFJ1ZG9sZiBUb21vcmkgPHJ1ZG90QEZyZWVCU0Qub3JnPgoKICAgVGhp cyBwcm9qZWN0IGFkZHMgdGhlIGJsb2NrIElPIGFjY2VzcyBhY2NvdW50aW5nIHRvIHRoZSByYWNj dC9yY3RsCiAgIHJlc291cmNlIGxpbWl0aW5nIGZyYW1ld29yaywgYSB3b3JraW5nIHByb3RvdHlw ZSBpbXBsZW1lbnRhdGlvbiBpcwogICBhdmFpbGFibGUuCiAgICAgX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCgpSZWFkLW9u bHkgUG9ydCBvZiBOZXRCU0QncyBVREYgRmlsZSBTeXN0ZW0KCiAgIFVSTDogaHR0cHM6Ly9naXRo dWIuY29tL3dpbGxpYW1kZXZyaWVzL1VERgoKICAgQ29udGFjdDogV2lsbCBEZVZyaWVzIDx3aWxs aWFtLmRldnJpZXNAZ21haWwuY29tPgoKICAgQW4gaW5pdGlhbCByZWFkLW9ubHkgcG9ydCBvZiBO ZXRCU0QncyBVREYgZmlsZSBzeXN0ZW0gaGFzIGJlZW4gbGFyZ2VseQogICBjb21wbGV0ZWQuIChU aGUgVURGIGZpbGUgc3lzdGVtIGlzIG9mdGVuIHVzZWQgb24gQ0QsIERWRCBhbmQgQmx1LVJheQog ICBkaXNjcy4pIFRoaXMgcG9ydCBwcm92aWRlcyBhIG51bWJlciBvZiBhZHZhbnRhZ2VzIG92ZXIg RnJlZUJTRCdzCiAgIGN1cnJlbnQgVURGIGltcGxlbWVudGF0aW9uLCB3aGljaCBpbmNsdWRlOgoK ICAgICAqIFN1cHBvcnQgZm9yIHZlcnNpb24gMi42MCBvZiB0aGUgVURGIGZpbGUgc3lzdGVtIHNw ZWNpZmljYXRpb24uCiAgICAgICBGcmVlQlNEJ3MgY3VycmVudCBpbXBsZW1lbnRhdGlvbiBvbmx5 IHBhcnRpYWxseSBzdXBwb3J0cyB2ZXJzaW9uCiAgICAgICAxLjUgb2YgdGhlIHN0YW5kYXJkLCB3 aGljaCB3YXMgcmVsZWFzZWQgaW4gMTk5Ny4gU2luY2UgV2luZG93cyBhbmQKICAgICAgIG90aGVy IHN5c3RlbXMgc3VwcG9ydCBuZXdlciB2ZXJzaW9uIG9mIHRoaXMgZmlsZSBzeXN0ZW0sIG91ciB1 c2VycwogICAgICAgYXJlIGxlZnQgd2l0aG91dCB0aGUgYWJpbGl0eSB0byByZWFkIHNvbWUgbWVk aWEgd3JpdHRlbiBieSB0aGVzZQogICAgICAgc3lzdGVtcy4gSW4gYWRkaXRpb24sIEJsdS1SYXkg ZGlzY3MgYXJlIGNvbW1vbmx5IHdyaXR0ZW4gdXNpbmcKICAgICAgIHZlcnNpb24gMi41MCBvciAy LjYwLgogICAgICogVGhlIGFiaWxpdHkgdG8gb3ZlcnJpZGUgdGhlIG93bmVyIGFuZCBncm91cCBm b3IgYWxsIHRoZSBmaWxlcyBhbmQKICAgICAgIGRpcmVjdG9yaWVzIG9uIGEgVURGIHZvbHVtZSB1 c2luZyBtb3VudCBvcHRpb25zLgogICAgICogVGhlIGFiaWxpdHkgdG8gc2V0IHRoZSBvd25lciBh bmQgZ3JvdXAgZm9yIGZpbGVzIGFuZCBkaXJlY3RvcmllcwogICAgICAgdGhhdCBsYWNrIGRlZmlu ZWQgb3duZXIgb3IgZ3JvdXAgaW5mb3JtYXRpb24gdXNpbmcgbW91bnQgb3B0aW9ucy4KICAgICAg IChUaGUgVURGIHNwZWNpZmljYXRpb24gYWxsb3dzIGZvciBmaWxlcyBhbmQgZGlyZWN0b3JpZXMg d2l0aG91dAogICAgICAgb3duZXJzIG9yIGdyb3Vwcy4pCiAgICAgKiBUaGUgYWJpbGl0eSB0byBv dmVycmlkZSB0aGUgbW9kZSBmb3IgYWxsIGRpcmVjdG9yaWVzIGFuZCBmaWxlcyBvbiBhCiAgICAg ICB2b2x1bWUgdXNpbmcgbW91bnQgb3B0aW9ucy4KICAgICAqIFN1cHBvcnQgZm9yIG1vdW50aW5n IHByZXZpb3VzIHZlcnNpb25zIG9mIGluY3JlbWVudGFsbHkgcmVjb3JkZWQKICAgICAgIG1lZGlh LCBsaWtlIENELVJzLgogICAgIF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fXwoKVENQLUFPIEF1dGhlbnRpY2F0aW9uIE9wdGlv bgoKICAgVVJMOiBodHRwOi8vc3Zud2ViLmZyZWVic2Qub3JnL2Jhc2UvdXNlci9hbmRyZS90Y3At YW8vCgogICBDb250YWN0OiBBbmRyw6kgT3BwZXJtYW5uIDxhbmRyZUBGcmVlQlNELm9yZz4KCiAg IFdvcmsgaXMgdW5kZXIgd2F5IHRvIGltcGxlbWVudCBUQ1AtQU8gKFRDUCBBdXRoZW50aWNhdGlv biBPcHRpb24pCiAgIGFjY29yZGluZyB0byBSRkM1OTI1IGFuZCBSRkM1OTI2LiBUQ1AtQU8gaXMg YW4gZXh0ZW5zaW9uIHRvIFRDUC1NRDUKICAgc2lnbmF0dXJlcyBjb21tb25seSB1c2VkIGluIHJv dXRlcnMgdG8gc2VjdXJlIEJHUCByb3V0aW5nIHByb3RvY29sCiAgIHNlc3Npb25zIGFnYWluc3Qg c3Bvb2ZpbmcgYXR0YWNrcy4gVGhlIHdvcmsgaXMgdW5kZXIgY29udHJhY3QgYW5kCiAgIHNwb25z b3JlZCBieSBKdW5pcGVyIE5ldHdvcmtzLgogICAgIF9fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwoKVGhlIGVudGl0aWVzIERv Y3VtZW50YXRpb24gQnJhbmNoCgogICBVUkw6IGh0dHA6Ly9zdm53ZWIuZnJlZWJzZC5vcmcvZG9j L3Byb2plY3RzL2VudGl0aWVzLwoKICAgQ29udGFjdDogUmVuw6kgTGFkYW4gPHJlbmVARnJlZUJT RC5vcmc+CgogICBUaGUgZW50aXRpZXMgYnJhbmNoIHdhcyBjcmVhdGVkIHRvIHJlZHVjZSBkdXBs aWNhdGlvbiBvZiBjb21taXR0ZXIKICAgZW50aXRpZXMuIEN1cnJlbnRseSB0aGVyZSBpcyBvbmUg aW4gYXV0aG9ycy5lbnQgKHdpdGggZW1haWwgYWRkcmVzc2VzKQogICBhbmQgYW5vdGhlciBvbmUg aW4gZGV2ZWxvcGVycy5lbnQgKHdpdGhvdXQgZW1haWwgYWRkcmVzc2VzKS4gVGhpcyBzZWVtcwog ICB0byBiZSBhIGxlZnRvdmVyIGZyb20gdGhlIGRvYy93d3cgc3BsaXQgaW4gZWFybGllciB0aW1l cy4gVG8gcmVtZWR5CiAgIHRoaXMsIGRldmVsb3BlcnMuZW50IGlzIG1lcmdlZCBpbnRvIGF1dGhv cnMuZW50IGFuZCBlbnRpdGllcyB3aXRoIGVtYWlsCiAgIGFkZHJlc3NlcyBhcmUgcG9zdGZpeGVk IGFzIHN1Y2guIEFwYXJ0IGZyb20gdGhlIGluc3RydWN0aW9ucyBmb3IgdGhlCiAgIGluaXRpYWwg Y29tbWl0LCB0aGVyZSBzaG91bGQgYmUgbGl0dGxlIHVzZXItdmlzaWJsZSBjaGFuZ2VzLiBTb21l CiAgIHJlbGF0ZWQgY2xlYW51cHMsIGxpa2UgY2xlYW5pbmcgdXAgdGVhbSBkZWZpbml0aW9ucywg cmVwbGFjaW5nIGxpdGVyYWwKICAgbmFtZXMgYnkgZW50aXRpZXMgZnJvbSBhdXRob3JzLmVudCwg YW5kIGFkZGluZyBtaXNzaW5nIG5hbWVzIHRvCiAgIGF1dGhvcnMuZW50IGFyZSBhbHNvIG1hZGUu CgpPcGVuIHRhc2tzOgoKICAgIDEuIEZpbmlzaCBwcm9jZXNzaW5nIG9mIHRoZSA8ZW1haWw+IHRh Zy4KICAgIDIuIFNlbmQgb3V0IGEgQ0ZULgogICAgMy4gTWVyZ2UgYmFjayBpbnRvIGhlYWQgYnJh bmNoLgogICAgIF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fXwoKVGhlIEZyZWVCU0QgSmFwYW5lc2UgRG9jdW1lbnRhdGlvbiBQ cm9qZWN0CgogICBVUkw6IGh0dHA6Ly93d3cuRnJlZUJTRC5vcmcvamEvCiAgIFVSTDogaHR0cDov L3d3dy5qcC5GcmVlQlNELm9yZy9kb2MtanAvCgogICBDb250YWN0OiBIaXJva2kgU2F0byA8aHJz QEZyZWVCU0Qub3JnPgogICBDb250YWN0OiBSeXVzdWtlIFN1enVraSA8cnl1c3VrZUBGcmVlQlNE Lm9yZz4KCiAgIFdlYiBwYWdlIChodGRvY3MpOiBOZXdzZmxhc2ggYW5kIHNvbWUgb3RoZXIgdXBk YXRlcyBpbiB0aGUgRW5nbGlzaAogICB2ZXJzaW9uIGhhdmUgYmVlbiB0cmFuc2xhdGVkIHRvIGtl ZXAgdGhlbSB1cC10by1kYXRlLiBTcGVjaWZpY2FsbHksIHRoZQogICByZWxlYXNlIHJlbGF0ZWQg Y29udGVudHMgd2VyZSB1cGRhdGVkIGluIHRoaXMgcGVyaW9kLgoKICAgQm9va3M6IEZyZWVCU0Qg SGFuZGJvb2sgaGFzIGNvbnN0YW50bHkgYmVlbiB1cGRhdGVkIHNpbmNlIHRoZSBsYXN0CiAgIHJl cG9ydDsgcGFydGljdWxhcmx5LCAicG9ydHMiLCAiZGVza3RvcCIgc2VjdGlvbiB3ZXJlIGxhcmdl bHkgdXBkYXRlZC4KICAgU29tZSBwcm9ncmVzcyBoYXMgYmVlbiBtYWRlIGluIHRoZSAiYWR2YW5j ZWQtbmV0d29ya2luZyIgc2VjdGlvbiwKICAgY29udHJpYnV0ZWQgYnkgYSBuZXcgdHJhbnNsYXRv ci4KCiAgICJXcml0aW5nIEZyZWVCU0QgUHJvYmxlbSBSZXBvcnRzIiBhcnRpY2xlIGlzIG5vdyBp biBzeW5jIHdpdGggdGhlCiAgIEVuZ2xpc2ggdmVyc2lvbi4KCk9wZW4gdGFza3M6CgogICAgMS4g RnVydGhlciB0cmFuc2xhdGlvbiB3b3JrIG9mIG91dGRhdGVkIGRvY3VtZW50cyBpbiBqYV9KUC5l dWNKUAogICAgICAgc3VidHJlZS4KICAgICBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KClVGUy9GRlMgUGVyZm9ybWFuY2Ug V29yawoKICAgVVJMOiBodHRwOi8vd3d3Lm1ja3VzaWNrLmNvbS9wdWJsaWNhdGlvbnMvZmFzdGVy X2ZzY2sucGRmCgogICBDb250YWN0OiBLaXJrIE1jS3VzaWNrIDxtY2t1c2lja0BtY2t1c2ljay5j b20+CgogICBTb21lIHdvcmsgb24gdGhlIHBlcmZvcm1hbmNlIG9mIFVGUy9GRlMgaGFzIGJlZW4g cmVjZW50bHkgY29tbWl0dGVkIHRvCiAgIEhFQUQuIFRoZSBwdXJwb3NlIG9mIHRoZSBjb3JyZXNw b25kaW5nIGNoYW5nZSB0byB0aGUgRkZTIGxheW91dCBwb2xpY3kKICAgaXMgdG8gcmVkdWNlIHRo ZSBydW5uaW5nIHRpbWUgZm9yIGEgZnVsbCBmaWxlIHN5c3RlbSBjaGVjay4gSXQgYWxzbwogICBy ZWR1Y2VzIHRoZSByYW5kb20gYWNjZXNzIHRpbWUgZm9yIGxhcmdlIGZpbGVzIGFuZCBzcGVlZHMg dXAgdGhlCiAgIHRyYXZlcnNhbCB0aW1lIGZvciBkaXJlY3RvcnkgdHJlZSB3YWxrcy4KCiAgIFRo ZSBrZXkgaWRlYSBpcyB0byByZXNlcnZlIGEgc21hbGwgYXJlYSBpbiBlYWNoIGN5bGluZGVyIGdy b3VwCiAgIGltbWVkaWF0ZWx5IGZvbGxvd2luZyB0aGUgaW5vZGUgYmxvY2tzIGZvciB0aGUgdXNl IG9mIG1ldGFkYXRhLAogICBzcGVjaWZpY2FsbHkgaW5kaXJlY3QgYmxvY2tzIGFuZCBkaXJlY3Rv cnkgY29udGVudHMuIFRoZSBuZXcgcG9saWN5IGlzCiAgIHRvIHByZWZlcmVudGlhbGx5IHBsYWNl IG1ldGFkYXRhIGluIHRoZSBtZXRhZGF0YSBhcmVhIGFuZCBldmVyeXRoaW5nCiAgIGVsc2UgaW4g dGhlIGJsb2NrcyB0aGF0IGZvbGxvdyB0aGUgbWV0YWRhdGEgYXJlYS4KCiAgIFRoZSBzaXplIG9m IHRoaXMgYXJlYSBjYW4gYmUgc2V0IHdoZW4gY3JlYXRpbmcgYSBmaWxlc3lzdGVtIHVzaW5nCiAg IG5ld2ZzKDgpIG9yIGNoYW5nZWQgaW4gYW4gZXhpc3RpbmcgZmlsZXN5c3RlbSB1c2luZyB0dW5l ZnMoOCkuIEJvdGgKICAgdXRpbGl0aWVzIHVzZSB0aGUgLWsgaGVsZC1mb3ItbWV0YWRhdGEtYmxv Y2tzIG9wdGlvbiB0byBzcGVjaWZ5IHRoZQogICBhbW91bnQgb2Ygc3BhY2UgdG8gYmUgaGVsZCBm b3IgbWV0YWRhdGEgYmxvY2tzIGluIGVhY2ggY3lsaW5kZXIgZ3JvdXAuCiAgIEJ5IGRlZmF1bHQs IG5ld2ZzKDgpIHNldHMgdGhpcyBhcmVhIHRvIGhhbGYgb2YgbWluZnJlZSAodHlwaWNhbGx5IDQl IG9mCiAgIHRoZSBkYXRhIGFyZWEpLgoKICAgQXMgd2l0aCBhbGwgbGF5b3V0IHBvbGljaWVzLCBp dCBvbmx5IGFmZmVjdCBsYXlvdXRzIG9mIHRoaW5ncyBhbGxvY2F0ZWQKICAgYWZ0ZXIgaXQgaXMg cHV0IGluIHBsYWNlLiBTbyB0aGVzZSBjaGFuZ2VzIHdpbGwgcHJpbWFyaWx5IGJlIG5vdGljYWJs ZQogICBvbiBuZXdseSBjcmVhdGVkIGZpbGUgc3lzdGVtcy4KCiAgIEZpbGUgc3lzdGVtIGNoZWNr cyBoYXZlIGJlZW4gc3BlZCB1cCBieSBjYWNoaW5nIHRoZSBjeWxpbmRlciBncm91cCBtYXBzCiAg IGluIHBhc3MxIHNvIHRoYXQgdGhleSBkbyBub3QgbmVlZCB0byBiZSByZWFkIGFnYWluIGluIHBh c3M1LiBBcyB0aGlzCiAgIG5lYXJseSBkb3VibGVzIHRoZSBtZW1vcnkgcmVxdWlyZW1lbnQgZm9y IGZzY2soOCksIHRoZSBjYWNoZSBpcyB0aHJvd24KICAgYXdheSBpZiBvdGhlciBtZW1vcnkgbmVl ZHMgaW4gZnNjayg4KSB3b3VsZCBvdGhlcndpc2UgZmFpbC4gVGh1cywgdGhlCiAgIG1lbW9yeSBm b290cHJpbnQgb2YgZnNjayg4KSByZW1haW5zIHVuY2hhbmdlZCBpbiBtZW1vcnkgY29uc3RyYWlu ZWQKICAgZW52aXJvbm1lbnRzLiBUaGlzIG9wdGltaXphdGlvbiB3aWxsIGJlIGV2aWRlbnQgb24g YWxsIFVGUy9GRlMKICAgZmlsZXN5c3RlbXMuCgogICBUaGlzIHdvcmsgd2FzIGluc3BpcmVkIGJ5 IGEgcGFwZXIgcHJlc2VudGVkIGF0IFVzZW5peCdzIEZBU1QgJzEzLgoKT3BlbiB0YXNrczoKCiAg ICAxLiBNRkMgdG8gOS1TVEFCTEUgYW5kIHBvc3NpYmx5IDgtU1RBQkxFIHNob3VsZCBoYXBwZW4g YnkgTWF5IHVubGVzcwogICAgICAgcHJvYmxlbXMgYXJpc2Ugd2l0aCB0aGVzZSBjaGFuZ2VzIGlu IEhFQUQuCiAgICAgX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fCgpXaW5lMzIgb24gRnJlZUJTRC9hbWQ2NAoKICAgVVJMOiBo dHRwOi8vd2lraS5mcmVlYnNkLm9yZy9pMzg2LVdpbmUKCiAgIENvbnRhY3Q6IERhdmlkIE5heWxv ciA8ZGJuQEZyZWVCU0Qub3JnPgoKICAgVGhlIGkzODYtd2luZSBwb3J0IChmb3JtYWxseSB3aW5l LWZic2Q2NCkgaGFzIGJlZW4gYWRkZWQgdG8gdGhlIHBvcnRzCiAgIGNvbGxlY3Rpb24gKGFzIGVt dWxhdG9ycy9pMzg2LXdpbmUtZGV2ZWwpLiBBbHRob3VnaCB0aGUgcG9ydCBjYW4gb25seQogICBi ZSBjb21waWxlZCB1bmRlciBhIHg4NiAzMi1iaXQgc3lzdGVtIHRoZSByZXN1bHRpbmcgcGFja2Fn ZSBjYW4gYmUKICAgaW5zdGFsbGVkIG9uIGEgeDg2IDY0LWJpdCBzeXN0ZW0gYW5kIGVuYWJsZSBy dW5uaW5nIG9mIDMyLWJpdCBNaWNyb3NvZnQKICAgV2luZG93cyBwcm9ncmFtcy4KCiAgIFBhY2th Z2VzIGZvciB0aGUgcG9ydCBhcmUgaW4gZGV2ZWxvcG1lbnQgYW5kIHNob3VsZCBiZSBhbm5vdW5j ZWQKICAgc2hvcnRseSBvbiB0aGUgZnJlZWJzZC1xdWVzdGlvbnMgYW5kIGZyZWVic2QtZW11bGF0 aW9uIG1haWxpbmcgbGlzdHMuCgogICBUaGVyZSBhcmUgc29tZSBpc3N1ZXMgd2l0aCBXaW5lMzIg b24gRnJlZUJTRC9hbWQ2NCAtLSBwb3NzaWJseSByZWxhdGVkCiAgIHRvIEZyZWVCU0QzMl9DT01Q QUNULCBvciBvdGhlciBnZW5lcmFsIDMyLzY0LWJpdCBpc3N1ZXMgLS0gdGhhdCBjb3VsZAogICBk byB3aXRoIHNvbWUgZm9jdXMuCgpPcGVuIHRhc2tzOgoKICAgIDEuIFBvcnQgd2luZTY0IHRvIEZy ZWVCU0QuCiAgICAyLiBQb3J0IFdvVzY0ICh3aW5lMzIgYW5kIHdpbmU2NCB0b2dldGhlcikgdG8g RnJlZUJTRC4KICAgIDMuIEZpeCAzMi0gYW5kIDY0LWJpdCBpc3N1ZXMgKHN1Y2ggYXMgSW50ZWwg Z3JhcGhpY3Mgbm90CiAgICAgICBhY2NlbGVyYXRpbmcpLgogICAgIF9fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwoKWGZjZS9G cmVlQlNECgogICBVUkw6IGh0dHBzOi8vd2lraS5GcmVlQlNELm9yZy9YZmNlCiAgIFVSTDogaHR0 cDovL3Blb3BsZS5mcmVlYnNkLm9yZy9+b2xpdmllcmQvcGF0Y2hlcy9taWRvcmktMC40LjlfMC41 LjAuZGlmZgoKICAgQ29udGFjdDogRnJlZUJTRCBYZmNlIFRlYW0gPHhmY2VARnJlZUJTRC5vcmc+ CgogICBUaGUgWGZjZSBGcmVlQlNEIFRlYW0gaGFzIHVwZGF0ZWQgbWFueSBwb3J0cywgZXNwZWNp YWxseToKCiAgICAgKiB0dW1ibGVyOiAwLjEuMjcgKGFkZCBuZXcgb3B0aW9uLCBDT1ZFUikKICAg ICAqIFBhcm9sZTogMC41LjAKICAgICAqIHhmZGVza3RvcDogNC4xMC4yCiAgICAgKiBNaWRvcmk6 IDAuNC45IChmdWxsIGNvbXBhdGlibGUgd2l0aCBWYWxhIDAuMTgpLCAwLjUuMCBpcyBhdmFpbGFi bGUKICAgICAgIChzZWUgbGlua3MpCiAgICAgKiBPcmFnZTogNC44LjQKICAgICAqIHhmY2U0LXRl cm1pbmFsOiAwLjYuMSAocmVuYW1lZCBieSB1cHN0cmVhbSwgcHJldmlvdXMgbmFtZSB3YXMKICAg ICAgIFRlcm1pbmFsKQoKICAgVGhpcyBsYXN0IGFwcGxpY2F0aW9uIGNvbnRhaW5zIGRyb3AtZG93 biBmdW5jdGlvbmFsaXR5LCBuZXcgd2luZG93CiAgIHNsaWRlcyBkb3duIGZyb20gdGhlIHRvcCBv ZiB0aGUgc2NyZWVuIHdoZW4ga2V5ICh3ZSBjYW4gZGVmaW5lIGtleWJvYXJkCiAgIHNob3J0Y3V0 KSBpcyBwcmVzc2VkLgoKT3BlbiB0YXNrczoKCiAgICAxLiBSZXBsYWNlIGxpYnhmY2U0Z3VpIChk ZXByZWNhdGVkIGFuZCBub3QgbWFpbnRhaW5lZCBieSB1cHN0cmVhbSkgYnkKICAgICAgIGxpYnhm Y2U0dWkgaW4gb3JkZXIgdG8gZW5oYW5jZSBzdXBwb3J0IHBhbmVsIHBsdWdpbnMgZm9yIFhmY2Ug Pj0KICAgICAgIDQuMTAuCiAgICAyLiBXb3JrIG9uIE1pZG9yaSBHdGszIHBvcnQuCiAgICAzLiBG aXggZ3RrLXhmY2UtZW5naW5lIHdpdGggR3RrKyA+PTMuNi4KICAgICBfX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KCnhvcmcg b24gRnJlZUJTRAoKICAgVVJMOiBodHRwOi8vd2lraS5mcmVlYnNkLm9yZy9Yb3JnCiAgIFVSTDog aHR0cDovL3Blb3BsZS5mcmVlYnNkLm9yZy9+emVpc2luZy94b3JnLTcuNy5kaWZmCiAgIFVSTDog aHR0cDovL3RyaWxsaWFuLmNocnVldGVydGVlLmNoL3BvcnRzL2Jyb3dzZXIvdHJ1bmsKICAgVVJM OiBodHRwOi8vdHJpbGxpYW4uY2hydWV0ZXJ0ZWUuY2gvcG9ydHMvYnJvd3Nlci9icmFuY2hlcy94 b3JnLTcuNwoKICAgQ29udGFjdDogRnJlZUJTRCBYMTEgVGVhbSA8eDExQEZyZWVCU0Qub3JnPgog ICBDb250YWN0OiBOaWNsYXMgWmVpc2luZyA8emVpc2luZ0BGcmVlQlNELm9yZz4KICAgQ29udGFj dDogS29vcCBNYXN0IDxrd21ARnJlZUJTRC5vcmc+CgogICBNb3N0IG9mIHRoZSB3b3JrIGR1cmlu ZyB0aGlzIHBlcmlvZCBoYXMgYmVlbiBpbiB1cGRhdGluZywgdGVzdGluZyBhbmQKICAgc3RhYmls aXppbmcgdGhlIGRldmVsb3BtZW50IHJlcG9zaXRvcnkuIEEgbnVtYmVyIG9mIHhvcmcgYXBwbGlj YXRpb25zCiAgIGFuZCB2YXJpb3VzIG90aGVyIGxlYWYgcG9ydHMgaGFzIGJlZW4gY29tbWl0dGVk IGFzIHBhcnQgb2YgdGhpcyBlZmZvcnQuCiAgIEFmdGVyIHRoaXMgYSBDRlQgd2FzIHNlbnQgb3V0 IGFza2luZyBmb3IgaGVscCBpbiB0ZXN0aW5nIHRoZSByZW1haW5pbmcKICAgYml0cyBpbiBkZXZl bG9wbWVudCwgaW5jbHVkaW5nIHVwZGF0ZXMgdG8gYWxsIG1ham9yIGxpYnJhcmllcyBhbmQKICAg eG9yZy1zZXJ2ZXIuCgogICBDdXJyZW50bHksIHRoZSBDRlQgcGF0Y2ggaGFzIGJlZW4gc3VibWl0 dGVkIGZvciBhbiBleHAtcnVuIHRvIGlyb24gb3V0CiAgIGFueSBmaW5hbCBidWdzLiBUaGUgcGxh biBpcyB0byBtZXJnZSBpdCBzb21ldGltZSBhZnRlciBGcmVlQlNEIDguNCBpcwogICByZWxlYXNl ZCBhbmQgdGhlIHBvcnRzIHRyZWUgaXMgcmVvcGVuZWQgZm9yIGNvbW1pdHMuCgogICBXb3JrIGlz IGFsc28gb24tZ29pbmcgdG8gcG9ydCBuZXcgdmVyc2lvbnMgb2YgTUVTQSBhbmQgT3BlbkdMLCBh cyB3ZWxsCiAgIGFzIGEgbmV3IHZlcnNpb24gb2YgeG9yZy1zZXJ2ZXIsIGFuZCBwZXJoYXBzIGlu IHRoZSBmdXR1cmUsIFdheWxhbmQuCiAgIFRoZXNlIGFyZSBjb25zaWRlcmVkIG1vcmUgbG9uZy10 ZXJtIGdvYWxzIGFuZCBhcmUgbm90IHRhcmdldGVkIGZvciB0aGUKICAgY3VycmVudCB1cGRhdGUu CgpPcGVuIHRhc2tzOgoKICAgIDEuIERlY2lkZSBob3cgdG8gaGFuZGxlIHRoZSBuZXcgYW5kIG9s ZCB4b3JnIGRpc3RyaWJ1dGlvbnMuIEluIHJlY2VudAogICAgICAgeG9yZywgYSBsb3Qgb2YgbGVn YWN5IGRyaXZlciBzdXBwb3J0IGhhcyBiZWVuIGRyb3BwZWQsIHRoZXJlZm9yZSB3ZQogICAgICAg bmVlZCB0byBtYWludGFpbiB0d28geG9yZyBkaXN0cmlidXRpb25zIHRvIG5vdCBsb3NlIGEgbG90 IG9mCiAgICAgICBoYXJkd2FyZSBkcml2ZXJzLiBDdXJyZW50bHksIHRoaXMgaXMgZG9uZSBieSBz ZXR0aW5nIHRoZSBmbGFnCiAgICAgICBXSVRIX05FV19YT1JHIGluIC9ldGMvbWFrZS5jb25mLCBi dXQgYSBtb3JlIHByYWN0aWNhbCBzb2x1dGlvbiBpcwogICAgICAgbmVlZGVkLiBUaGlzIGlzIGVz cGVjaWFsbHkgaW1wb3J0YW50IHNpbmNlIHRoZSBmbGFnIGlzIG5vdCB2ZXJ5CiAgICAgICB1c2Vy LWZyaWVuZGx5LCBhbmQgc2luY2UgdGhlcmUgY3VycmVudGx5IHdpbGwgYmUgbm8gb2ZmaWNpYWwK ICAgICAgIHBhY2thZ2VzIGZvciB0aGUgbmV3IGRpc3RyaWJ1dGlvbi4KICAgIDIuIENvbnRpbnVl IHRvIHRlc3QgYW5kIHVwZGF0ZSB4b3JnIHJlbGF0ZWQgcG9ydHMuIFRoZXJlIGFyZSBuZXcKICAg ICAgIHZlcnNpb25zIG9mIHhzZXJ2ZXIsIGFzIHdlbGwgYXMgTUVTQSBhbmQgcmVsYXRlZCBPcGVu R0wgbGlicmFyaWVzCiAgICAgICB3aGljaCBuZWVkcyB0byBiZSBwb3J0ZWQgYW5kIGV2ZW50dWFs bHkgaW50ZWdyYXRlZCBpbnRvIHRoZSBwb3J0cwogICAgICAgdHJlZS4KICAgIDMuIFBvcnQgV2F5 bGFuZC4gVGhlIGZ1dHVyZSBvZiBncmFwaGljYWwgZW52aXJvbm1lbnRzIGluIG9wZW4gc291cmNl CiAgICAgICBvcGVyYXRpbmcgc3lzdGVtcyBzZWVtcyB0byBiZSBXYXlsYW5kLiBUaGlzIG5lZWRz IHRvIGJlIHBvcnRlZCB0bwogICAgICAgRnJlZUJTRCBzbyB0aGF0IGEgd2lkZXIgYXVkaWVuY2Ug Y2FuIHRlc3QgaXQsIGFuZCBzbyB0aGF0IGl0CiAgICAgICBldmVudHVhbGx5IGNhbiBiZSBpbnRl Z3JhdGVkIGludG8gdGhlIHBvcnRzIHRyZWUsIHBlcmhhcHMgYXMgYQogICAgICAgcmVwbGFjZW1l bnQgZm9yIHRoZSBjdXJyZW50IHhvcmcuCiAgICA0LiBMb29rIGludG8gcmVwbGFjZW1lbnRzIGZv ciBIQUwuIEhBTCBpcyB1c2VkIGZvciBob3QtcGx1Z2dpbmcgb2YKICAgICAgIGRldmljZXMsIGJ1 dCBpdCBoYXMgYmVlbiBsb25nIGFiYW5kb25lZCBieSBMaW51eC4gQSByZXBsYWNlbWVudCwKICAg ICAgIHBlcmhhcHMgYnVpbGQgb24gdG9wIG9mIGRldmQgd291bGQgYmUgbmljZSB0byBoYXZlLiBU aGlzIHdvcmsKICAgICAgIHNob3VsZCBiZSBjb29yZGluYXRlZCB3aXRoIHRoZSBGcmVlQlNEIEdO T01FIGFuZCBLREUgdGVhbXMuCiAgICAgX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCl9fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fCmZyZWVic2QtaGFja2Vyc0BmcmVlYnNkLm9yZyBtYWls aW5nIGxpc3QKaHR0cDovL2xpc3RzLmZyZWVic2Qub3JnL21haWxtYW4vbGlzdGluZm8vZnJlZWJz ZC1oYWNrZXJzClRvIHVuc3Vic2NyaWJlLCBzZW5kIGFueSBtYWlsIHRvICJmcmVlYnNkLWhhY2tl cnMtdW5zdWJzY3JpYmVAZnJlZWJzZC5vcmci From owner-freebsd-stable@FreeBSD.ORG Wed May 15 12:40:20 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id D0CB0299 for ; Wed, 15 May 2013 12:40:20 +0000 (UTC) (envelope-from db@nipsi.de) Received: from fop.bsdsystems.de (mx.bsdsystems.de [88.198.57.43]) by mx1.freebsd.org (Postfix) with ESMTP id A21D09BB for ; Wed, 15 May 2013 12:40:19 +0000 (UTC) Received: from [172.16.6.25] (p579A60A2.dip0.t-ipconnect.de [87.154.96.162]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by fop.bsdsystems.de (Postfix) with ESMTP id 2F3BC54BF7 for ; Wed, 15 May 2013 14:40:18 +0200 (CEST) Subject: still mbuf leak in 9.0 / 9.1? Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: multipart/mixed; boundary=Apple-Mail-36--527606426 From: dennis berger Resent-From: dennis berger Date: Wed, 15 May 2013 11:00:23 +0200 Resent-Date: Wed, 15 May 2013 14:40:17 +0200 Resent-To: freebsd-stable@freebsd.org Message-Id: To: freebsd-stable@freebsd.org X-Mailer: Apple Mail (2.1085) Resent-Message-Id: <20130515124018.2F3BC54BF7@fop.bsdsystems.de> X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 15 May 2013 12:40:20 -0000 --Apple-Mail-36--527606426 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Hi list, since we activated 10gbe on ixgbe cards + jumbo frames(9k) on 9.0 and = now on 9.1 we recognize that after a random period of time, sometimes a = week, sometimes only a day, the system doesn't send any packets out. The phenomenon is that you can't = login via ssh, nfs and istgt is not operative. Yet you can login on the = console and execute commands. A clean shutdown isn't possible though. It hangs after vnode cleaning, = normally you would see detaching of usb devices here, or other devices = maybe?=20 I've read the other post on this ML about mbuf leak in the arp handling = code in if_ether.c line 558. We don't see any of those notices in dmesg = so I don't think that glebius fix would apply for us. I'm collecting system and memory information every hour.=20 Script looks like this. less /etc/periodic/hourly/100.report-memory.sh=20 #!/bin/sh reporttimestamp=3D`date +%d-%m-%Y-%H-%M` reportname=3D${reporttimestamp}.txt cd /root/memory-mon top -b > $reportname echo "" >> $reportname vmstat -m >> $reportname echo "" >> $reportname vmstat -z >> $reportname echo "" >> $reportname netstat -Q >> $reportname echo "" >> $reportname netstat -n -x >> $reportname echo "" >> $reportname netstat -m >> $reportname /usr/bin/perl /usr/local/bin/zfs-stats -a >> $reportname When you grep for mbuf or mbuf usage you will see this for example: root@freenas:/root/memory-mon # grep mbuf_packet: * 14-05-2013-14-09.txt:mbuf_packet: 256, 0, 9246, = 2786,201700429, 0, 0 14-05-2013-15-09.txt:mbuf_packet: 256, 0, 9256, = 2776,201773122, 0, 0 14-05-2013-16-09.txt:mbuf_packet: 256, 0, 9266, = 2766,201871553, 0, 0 14-05-2013-17-09.txt:mbuf_packet: 256, 0, 9276, = 2756,201915405, 0, 0 14-05-2013-18-09.txt:mbuf_packet: 256, 0, 9286, = 2746,201927956, 0, 0 14-05-2013-19-09.txt:mbuf_packet: 256, 0, 9296, = 2352,201935681, 0, 0 14-05-2013-20-09.txt:mbuf_packet: 256, 0, 9306, = 2342,201943754, 0, 0 14-05-2013-21-09.txt:mbuf_packet: 256, 0, 9316, = 2332,201950961, 0, 0 14-05-2013-22-09.txt:mbuf_packet: 256, 0, 9326, = 2450,201958150, 0, 0 14-05-2013-23-09.txt:mbuf_packet: 256, 0, 9336, = 2440,201967178, 0, 0 15-05-2013-00-09.txt:mbuf_packet: 256, 0, 9346, = 2430,201974561, 0, 0 15-05-2013-01-09.txt:mbuf_packet: 256, 0, 9356, = 2420,201982105, 0, 0 15-05-2013-02-09.txt:mbuf_packet: 256, 0, 9366, = 2410,201989463, 0, 0 15-05-2013-03-09.txt:mbuf_packet: 256, 0, 9378, = 1502,203019168, 0, 0 15-05-2013-04-09.txt:mbuf_packet: 256, 0, 9384, = 1624,205953601, 0, 0 15-05-2013-05-09.txt:mbuf_packet: 256, 0, 9394, = 1870,205959258, 0, 0 15-05-2013-06-09.txt:mbuf_packet: 256, 0, 9404, = 2500,205969396, 0, 0 15-05-2013-07-09.txt:mbuf_packet: 256, 0, 9414, = 3386,207945161, 0, 0 15-05-2013-08-09.txt:mbuf_packet: 256, 0, 9424, = 3376,208094689, 0, 0 15-05-2013-09-09.txt:mbuf_packet: 256, 0, 9434, = 2982,208172465, 0, 0 15-05-2013-10-09.txt:mbuf_packet: 256, 0, 9444, = 3100,208270369, 0, 0 and root@freenas:/root/memory-mon # grep "mbufs in use" * 14-05-2013-14-09.txt:58444/5816/64260 mbufs in use (current/cache/total) 14-05-2013-15-09.txt:58455/5805/64260 mbufs in use (current/cache/total) 14-05-2013-16-09.txt:58464/5796/64260 mbufs in use (current/cache/total) 14-05-2013-17-09.txt:58475/5785/64260 mbufs in use (current/cache/total) 14-05-2013-18-09.txt:58484/5776/64260 mbufs in use (current/cache/total) 14-05-2013-19-09.txt:58493/5767/64260 mbufs in use (current/cache/total) 14-05-2013-20-09.txt:58503/5757/64260 mbufs in use (current/cache/total) 14-05-2013-21-09.txt:58513/5747/64260 mbufs in use (current/cache/total) 14-05-2013-22-09.txt:58523/5737/64260 mbufs in use (current/cache/total) 14-05-2013-23-09.txt:58533/5727/64260 mbufs in use (current/cache/total) 15-05-2013-00-09.txt:58543/5717/64260 mbufs in use (current/cache/total) 15-05-2013-01-09.txt:58554/5706/64260 mbufs in use (current/cache/total) 15-05-2013-02-09.txt:58563/5697/64260 mbufs in use (current/cache/total) 15-05-2013-03-09.txt:58639/5621/64260 mbufs in use (current/cache/total) 15-05-2013-04-09.txt:58581/5679/64260 mbufs in use (current/cache/total) 15-05-2013-05-09.txt:58591/5669/64260 mbufs in use (current/cache/total) 15-05-2013-06-09.txt:58602/5658/64260 mbufs in use (current/cache/total) 15-05-2013-07-09.txt:58613/5647/64260 mbufs in use (current/cache/total) 15-05-2013-08-09.txt:58623/6027/64650 mbufs in use (current/cache/total) 15-05-2013-09-09.txt:58634/6016/64650 mbufs in use (current/cache/total) 15-05-2013-10-09.txt:58645/6005/64650 mbufs in use (current/cache/total) This increasing number of used mbuf_packets and mbufs in use makes me = nervous. See the complete reports http://knownhosts.org:/reports-14-15.tgz=20 Thanks for help, -dennis --------------BEGIN System information--------------- It's a stock FreeBSD 9.1, yet the hostname is called freenas. Don't be = confused. igb0: flags=3D8c02 metric 0 mtu = 1500 = options=3D401bb ether 00:25:90:34:c1:12 nd6 options=3D21 media: Ethernet autoselect (1000baseT ) status: active igb1: flags=3D8843 metric 0 mtu = 1500 = options=3D401bb ether 00:25:90:34:c1:13 inet 172.16.1.6 netmask 0xfffff000 broadcast 172.16.15.255 inet6 fe80::225:90ff:fe34:c113%igb1 prefixlen 64 scopeid 0x2=20 nd6 options=3D21 media: Ethernet autoselect (1000baseT ) status: active ix0: flags=3D8843 metric 0 mtu = 9000 = options=3D401bb ether 00:1b:21:cc:12:8b inet 10.254.254.242 netmask 0xfffffffc broadcast 10.254.254.243 inet6 fe80::21b:21ff:fecc:128b%ix0 prefixlen 64 scopeid 0xb=20 nd6 options=3D21 media: Ethernet autoselect (10Gbase-Twinax ) status: active ix1: flags=3D8843 metric 0 mtu = 9000 = options=3D401bb ether 00:1b:21:cc:12:8a inet 10.254.254.254 netmask 0xfffffffc broadcast 10.254.254.255 inet6 fe80::21b:21ff:fecc:128a%ix1 prefixlen 64 scopeid 0xc=20 nd6 options=3D21 media: Ethernet autoselect (10Gbase-Twinax ) status: active ix2: flags=3D8843 metric 0 mtu = 9000 = options=3D401bb ether 00:1b:21:cc:12:b3 inet 10.254.254.246 netmask 0xfffffffc broadcast 10.254.254.247 inet6 fe80::21b:21ff:fecc:12b3%ix2 prefixlen 64 scopeid 0xd=20 nd6 options=3D21 media: Ethernet autoselect status: no carrier ix3: flags=3D8802 metric 0 mtu 1500 = options=3D401bb ether 00:1b:21:cc:12:b2 nd6 options=3D21 media: Ethernet autoselect status: no carrier lo0: flags=3D8049 metric 0 mtu 16384 options=3D600003 inet6 ::1 prefixlen 128=20 inet6 fe80::1%lo0 prefixlen 64 scopeid 0xf=20 inet 127.0.0.1 netmask 0xff000000=20 nd6 options=3D21 #dmesg =85.. mfi0: 21294 (421879975s/0x0008/info) - Battery started charging ix1: link state changed to DOWN ix1: link state changed to UP ix1: link state changed to DOWN ix1: link state changed to UP ix1: link state changed to DOWN ix1: link state changed to UP ix1: link state changed to DOWN ix1: link state changed to UP ix1: link state changed to DOWN ix1: link state changed to UP ix1: link state changed to DOWN ix1: link state changed to UP ix1: link state changed to DOWN ix1: link state changed to UP ix1: link state changed to DOWN ix1: link state changed to UP ix1: link state changed to DOWN ix1: link state changed to UP ix1: link state changed to DOWN ix1: link state changed to UP ix1: link state changed to DOWN ix1: link state changed to UP ix1: link state changed to DOWN ix1: link state changed to UP ix1: link state changed to DOWN ix1: link state changed to UP ix1: link state changed to DOWN ix1: link state changed to UP ix1: link state changed to DOWN ix1: link state changed to UP ix1: link state changed to DOWN ix1: link state changed to UP ix1: link state changed to DOWN ix1: link state changed to UP ix1: link state changed to DOWN ix1: link state changed to UP ix1: link state changed to DOWN ix1: link state changed to UP ix1: link state changed to DOWN ix1: link state changed to UP ix1: link state changed to DOWN ix1: link state changed to UP I should add that the servers that are directly connected to this = freebsd server reboot every night. This is why you see ix0 UP/DOWN messages in dmesg. --Apple-Mail-36--527606426 Content-Disposition: attachment; filename=dmesg.boot Content-Type: application/octet-stream; name="dmesg.boot" Content-Transfer-Encoding: 7bit Copyright (c) 1992-2012 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 9.1-RELEASE #0 r243825: Tue Dec 4 09:23:10 UTC 2012 root@farrell.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC amd64 can't re-use a leaf (geom_label)! module_register: module g_label already exists! Module g_label failed to register: 17 CPU: Intel(R) Xeon(R) CPU E5620 @ 2.40GHz (2400.14-MHz K8-class CPU) Origin = "GenuineIntel" Id = 0x206c2 Family = 6 Model = 2c Stepping = 2 Features=0xbfebfbff Features2=0x29ee3ff AMD Features=0x2c100800 AMD Features2=0x1 TSC: P-state invariant, performance statistics real memory = 51543801856 (49156 MB) avail memory = 49657782272 (47357 MB) Event timer "LAPIC" quality 600 ACPI APIC Table: FreeBSD/SMP: Multiprocessor System Detected: 16 CPUs FreeBSD/SMP: 2 package(s) x 4 core(s) x 2 SMT threads cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 cpu2 (AP): APIC ID: 2 cpu3 (AP): APIC ID: 3 cpu4 (AP): APIC ID: 18 cpu5 (AP): APIC ID: 19 cpu6 (AP): APIC ID: 20 cpu7 (AP): APIC ID: 21 cpu8 (AP): APIC ID: 32 cpu9 (AP): APIC ID: 33 cpu10 (AP): APIC ID: 34 cpu11 (AP): APIC ID: 35 cpu12 (AP): APIC ID: 50 cpu13 (AP): APIC ID: 51 cpu14 (AP): APIC ID: 52 cpu15 (AP): APIC ID: 53 ioapic0: Changing APIC ID to 6 ioapic1: Changing APIC ID to 7 ioapic0 irqs 0-23 on motherboard ioapic1 irqs 24-47 on motherboard ioapic2 irqs 48-71 on motherboard kbd1 at kbdmux0 ctl: CAM Target Layer loaded acpi0: on motherboard acpi0: Power Button (fixed) acpi0: reservation of 400, 100 (3) failed cpu0: on acpi0 ACPI Warning: Incorrect checksum in table [OEMB] - 0x98, should be 0x95 (20110527/tbutils-282) cpu1: on acpi0 cpu2: on acpi0 cpu3: on acpi0 cpu4: on acpi0 cpu5: on acpi0 cpu6: on acpi0 cpu7: on acpi0 cpu8: on acpi0 cpu9: on acpi0 cpu10: on acpi0 cpu11: on acpi0 cpu12: on acpi0 cpu13: on acpi0 cpu14: on acpi0 cpu15: on acpi0 attimer0: port 0x40-0x43 irq 0 on acpi0 Timecounter "i8254" frequency 1193182 Hz quality 0 Event timer "i8254" frequency 1193182 Hz quality 100 atrtc0: port 0x70-0x71 irq 8 on acpi0 Event timer "RTC" frequency 32768 Hz quality 0 hpet0: iomem 0xfed00000-0xfed003ff on acpi0 Timecounter "HPET" frequency 14318180 Hz quality 950 Event timer "HPET" frequency 14318180 Hz quality 450 Event timer "HPET1" frequency 14318180 Hz quality 440 Event timer "HPET2" frequency 14318180 Hz quality 440 Event timer "HPET3" frequency 14318180 Hz quality 440 Timecounter "ACPI-fast" frequency 3579545 Hz quality 900 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x808-0x80b on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 pcib1: at device 1.0 on pci0 pci1: on pcib1 igb0: port 0xcc00-0xcc1f mem 0xfafe0000-0xfaffffff,0xfafc0000-0xfafdffff,0xfaf9c000-0xfaf9ffff irq 28 at device 0.0 on pci1 igb0: Using MSIX interrupts with 9 vectors igb0: Ethernet address: 00:25:90:34:c1:12 igb0: Bound queue 0 to cpu 0 igb0: Bound queue 1 to cpu 1 igb0: Bound queue 2 to cpu 2 igb0: Bound queue 3 to cpu 3 igb0: Bound queue 4 to cpu 4 igb0: Bound queue 5 to cpu 5 igb0: Bound queue 6 to cpu 6 igb0: Bound queue 7 to cpu 7 igb1: port 0xc800-0xc81f mem 0xfaf60000-0xfaf7ffff,0xfaf40000-0xfaf5ffff,0xfaf98000-0xfaf9bfff irq 40 at device 0.1 on pci1 igb1: Using MSIX interrupts with 9 vectors igb1: Ethernet address: 00:25:90:34:c1:13 igb1: Bound queue 0 to cpu 8 igb1: Bound queue 1 to cpu 9 igb1: Bound queue 2 to cpu 10 igb1: Bound queue 3 to cpu 11 igb1: Bound queue 4 to cpu 12 igb1: Bound queue 5 to cpu 13 igb1: Bound queue 6 to cpu 14 igb1: Bound queue 7 to cpu 15 pcib2: at device 3.0 on pci0 pci2: on pcib2 pcib3: at device 5.0 on pci0 pci3: on pcib3 pcib4: at device 7.0 on pci0 pci4: on pcib4 pcib5: at device 9.0 on pci0 pci5: on pcib5 pci0: at device 20.0 (no driver attached) pci0: at device 20.1 (no driver attached) pci0: at device 20.2 (no driver attached) pci0: at device 20.3 (no driver attached) pci0: at device 22.0 (no driver attached) pci0: at device 22.1 (no driver attached) pci0: at device 22.2 (no driver attached) pci0: at device 22.3 (no driver attached) pci0: at device 22.4 (no driver attached) pci0: at device 22.5 (no driver attached) pci0: at device 22.6 (no driver attached) pci0: at device 22.7 (no driver attached) uhci0: port 0xaf80-0xaf9f irq 16 at device 26.0 on pci0 uhci0: LegSup = 0x2f00 usbus0 on uhci0 uhci1: port 0xaf40-0xaf5f irq 21 at device 26.1 on pci0 uhci1: LegSup = 0x2f00 usbus1 on uhci1 uhci2: port 0xaf20-0xaf3f irq 19 at device 26.2 on pci0 uhci2: LegSup = 0x2f00 usbus2 on uhci2 ehci0: mem 0xfaefc000-0xfaefc3ff irq 18 at device 26.7 on pci0 usbus3: EHCI version 1.0 usbus3 on ehci0 uhci3: port 0xaf00-0xaf1f irq 23 at device 29.0 on pci0 uhci3: LegSup = 0x2f00 usbus4 on uhci3 uhci4: port 0xaec0-0xaedf irq 19 at device 29.1 on pci0 uhci4: LegSup = 0x2f00 usbus5 on uhci4 uhci5: port 0xaea0-0xaebf irq 18 at device 29.2 on pci0 uhci5: LegSup = 0x2f00 usbus6 on uhci5 ehci1: mem 0xfaeda000-0xfaeda3ff irq 23 at device 29.7 on pci0 usbus7: EHCI version 1.0 usbus7 on ehci1 pcib6: at device 30.0 on pci0 pci6: on pcib6 vgapci0: mem 0xf9000000-0xf9ffffff,0xfbefc000-0xfbefffff,0xfb000000-0xfb7fffff irq 16 at device 4.0 on pci6 isab0: at device 31.0 on pci0 isa0: on isab0 ahci0: port 0xaff0-0xaff7,0xafac-0xafaf,0xafe0-0xafe7,0xafa8-0xafab,0xae80-0xae9f mem 0xfaed8000-0xfaed87ff irq 19 at device 31.2 on pci0 ahci0: AHCI v1.20 with 6 3Gbps ports, Port Multiplier not supported ahcich0: at channel 0 on ahci0 ahcich1: at channel 1 on ahci0 ahcich2: at channel 2 on ahci0 ahcich3: at channel 3 on ahci0 ahcich4: at channel 4 on ahci0 ahcich5: at channel 5 on ahci0 pci0: at device 31.3 (no driver attached) pcib7: on acpi0 pci128: on pcib7 pcib8: at device 0.0 on pci128 pci129: on pcib8 pcib9: at device 1.0 on pci128 pci130: on pcib9 pcib10: at device 3.0 on pci128 pci131: on pcib10 ix0: port 0xdc00-0xdc1f mem 0xf8da0000-0xf8dbffff,0xf8dc0000-0xf8dfffff,0xf8d9c000-0xf8d9ffff irq 48 at device 0.0 on pci131 ix0: Using MSIX interrupts with 9 vectors ix0: Ethernet address: 00:1b:21:cc:12:8b ix0: PCI Express Bus: Speed 2.5Gb/s Width x8 ix1: port 0xd800-0xd81f mem 0xf8d20000-0xf8d3ffff,0xf8d40000-0xf8d7ffff,0xf8d98000-0xf8d9bfff irq 58 at device 0.1 on pci131 ix1: Using MSIX interrupts with 9 vectors ix1: Ethernet address: 00:1b:21:cc:12:8a ix1: PCI Express Bus: Speed 2.5Gb/s Width x8 pcib11: at device 5.0 on pci128 pci132: on pcib11 ix2: port 0xec00-0xec1f mem 0xf8ea0000-0xf8ebffff,0xf8ec0000-0xf8efffff,0xf8e9c000-0xf8e9ffff irq 50 at device 0.0 on pci132 ix2: Using MSIX interrupts with 9 vectors ix2: Ethernet address: 00:1b:21:cc:12:b3 ix2: PCI Express Bus: Speed 2.5Gb/s Width x8 ix3: port 0xe800-0xe81f mem 0xf8e20000-0xf8e3ffff,0xf8e40000-0xf8e7ffff,0xf8e98000-0xf8e9bfff irq 49 at device 0.1 on pci132 ix3: Using MSIX interrupts with 9 vectors ix3: No SFP+ Module found ix3: Ethernet address: 00:1b:21:cc:12:b2 ix3: PCI Express Bus: Speed 2.5Gb/s Width x8 pcib12: at device 7.0 on pci128 pci133: on pcib12 mfi0: port 0xf800-0xf8ff mem 0xf8f9c000-0xf8f9ffff,0xf8fc0000-0xf8ffffff irq 54 at device 0.0 on pci133 mfi0: Using MSI mfi0: Megaraid SAS driver Ver 4.23 mfip0: on mfi0 pcib13: at device 9.0 on pci128 pci134: on pcib13 pci128: at device 20.0 (no driver attached) pci128: at device 20.1 (no driver attached) pci128: at device 20.2 (no driver attached) pci128: at device 20.3 (no driver attached) pci128: at device 22.0 (no driver attached) pci128: at device 22.1 (no driver attached) pci128: at device 22.2 (no driver attached) pci128: at device 22.3 (no driver attached) pci128: at device 22.4 (no driver attached) pci128: at device 22.5 (no driver attached) pci128: at device 22.6 (no driver attached) pci128: at device 22.7 (no driver attached) acpi_button0: on acpi0 ipmi0: port 0xca2-0xca3 on acpi0 ipmi0: KCS mode found at io 0xca2 on acpi atkbdc0: port 0x60,0x64 irq 1 on acpi0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] psm0: irq 12 on atkbdc0 psm0: [GIANT-LOCKED] psm0: model IntelliMouse Explorer, device ID 4 uart0: <16550 or compatible> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 uart1: <16550 or compatible> port 0x2f8-0x2ff irq 3 on acpi0 qpi0: on motherboard pcib14: pcibus 255 on qpi0 pci255: on pcib14 pcib15: pcibus 254 on qpi0 pci254: on pcib15 ipmi1: on isa0 device_attach: ipmi1 attach returned 16 ipmi1: on isa0 device_attach: ipmi1 attach returned 16 orm0: at iomem 0xc0000-0xc7fff,0xc8000-0xc8fff on isa0 sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 ppc0: cannot reserve I/O port range est0: on cpu0 p4tcc0: on cpu0 est1: on cpu1 p4tcc1: on cpu1 est2: on cpu2 p4tcc2: on cpu2 est3: on cpu3 p4tcc3: on cpu3 est4: on cpu4 p4tcc4: on cpu4 est5: on cpu5 p4tcc5: on cpu5 est6: on cpu6 p4tcc6: on cpu6 est7: on cpu7 p4tcc7: on cpu7 est8: on cpu8 p4tcc8: on cpu8 est9: on cpu9 p4tcc9: on cpu9 est10: on cpu10 p4tcc10: on cpu10 est11: on cpu11 p4tcc11: on cpu11 est12: on cpu12 p4tcc12: on cpu12 est13: on cpu13 p4tcc13: on cpu13 est14: on cpu14 p4tcc14: on cpu14 est15: on cpu15 p4tcc15: on cpu15 Timecounters tick every 1.000 msec mfi0: 19571 (417203816s/0x0020/info) - Shutdown command received from host mfi0: 19572 (boot + 3s/0x0020/info) - Firmware initialization started (PCI ID 0079/1000/9260/1000) mfi0: 19573 (boot + 3s/0x0020/info) - Firmware version 2.130.363-1846 mfi0: 19574 (boot + 9s/0x0008/info) - Battery Present mfi0: 19575 (boot + 9s/0x0020/info) - Package version 12.12.0-0124 mfi0: 19576 (boot + 9s/0x0020/info) - Board Revision 61A mfi0: 19577 (boot + 27s/0x0004/info) - Enclosure (SES) discovered on PD 16(c Port 0 - 3/p1) mfi0: 19578 (boot + 27s/0x0004/info) - Enclosure PD 16(c Port 0 - 3/p1) communication restored mfi0: 19579 (boot + 27s/0x0002/info) - Inserted: Encl PD 16 mfi0: 19580 (boot + 27s/0x0002/info) - Inserted: PD 16(c Port 0 - 3/p1) Info: enclPd=16, scsiType=d, portMap=00, sasAddr=500304800000007d,0000000000000000 mfi0: 19581 (boot + 27s/0x0002/info) - Inserted: PD 04(e0x16/s0) mfi0: 19582 (boot + 27s/0x0002/info) - Inserted: PD 04(e0x16/s0) Info: enclPd=16, scsiType=0, portMap=00, sasAddr=500304800000004c,0000000000000000 mfi0: 19583 (boot + 27s/0x0002/info) - Inserted: PD 05(e0x16/s1) mfi0: 19584 (boot + 27s/0x0002/info) - Inserted: PD 05(e0x16/s1) Info: enclPd=16, scsiType=0, portMap=00, sasAddr=500304800000004d,0000000000000000 mfi0: 19585 (boot + 27s/0x0002/info) - Inserted: PD 06(e0x16/s2) mfi0: 19586 (boot + 27s/0x0002/info) - Inserted: PD 06(e0x16/s2) Info: enclPd=16, scsiType=0, portMap=00, sasAddr=5000c5003a5439ed,0000000000000000 mfi0: 19587 (boot + 27s/0x0002/info) - Inserted: PD 07(e0x16/s3) mfi0: 19588 (boot + 27s/0x0002/info) - Inserted: PD 07(e0x16/s3) Info: enclPd=16, scsiType=0, portMap=00, sasAddr=5000c5003a4dcafd,0000000000000000 mfi0: 19589 (boot + 27s/0x0002/info) - Inserted: PD 08(e0x16/s4) mfi0: 19590 (boot + 27s/0x0002/info) - Inserted: PD 08(e0x16/s4) Info: enclPd=16, scsiType=0, portMap=00, sasAddr=5000c50039d51041,0000000000000000 mfi0: 19591 (boot + 27s/0x0002/info) - Inserted: PD 09(e0x16/s5) mfi0: 19592 (boot + 27s/0x0002/info) - Inserted: PD 09(e0x16/s5) Info: enclPd=16, scsiType=0, portMap=00, sasAddr=500003937813d41a,0000000000000000 mfi0: 19593 (boot + 27s/0x0002/info) - Inserted: PD 0a(e0x16/s6) mfi0: 19594 (boot + 27s/0x0002/info) - Inserted: PD 0a(e0x16/s6) Info: enclPd=16, scsiType=0, portMap=00, sasAddr=500003937813d3be,0000000000000000 mfi0: 19595 (boot + 27s/0x0002/info) - Inserted: PD 0b(e0x16/s7) mfi0: 19596 (boot + 27s/0x0002/info) - Inserted: PD 0b(e0x16/s7) Info: enclPd=16, scsiType=0, portMap=00, sasAddr=500003937813d372,0000000000000000 mfi0: 19597 (boot + 27s/0x0002/info) - Inserted: PD 0c(e0x16/s8) mfi0: 19598 (boot + 27s/0x0002/info) - Inserted: PD 0c(e0x16/s8) Info: enclPd=16, scsiType=0, portMap=00, sasAddr=500003937813d3ea,0000000000000000 mfi0: 19599 (boot + 27s/0x0002/info) - Inserted: PD 0d(e0x16/s9) mfi0: 19600 (boot + 27s/0x0002/info) - Inserted: PD 0d(e0x16/s9) Info: enclPd=16, scsiType=0, portMap=00, sasAddr=500003937813d37a,0000000000000000 mfi0: 19601 (boot + 27s/0x0002/info) - Inserted: PD 0e(e0x16/s10) mfi0: 19602 (boot + 27s/0x0002/info) - Inserted: PD 0e(e0x16/s10) Info: enclPd=16, scsiType=0, portMap=00, sasAddr=500003937813d352,0000000000000000 mfi0: 19603 (boot + 27s/0x0002/info) - Inserted: PD 0f(e0x16/s11) mfi0: 19604 (boot + 27s/0x0002/info) - Inserted: PD 0f(e0x16/s11) Info: enclPd=16, scsiType=0, portMap=00, sasAddr=500003937813d406,0000000000000000 mfi0: 19605 (boot + 27s/0x0002/info) - Inserted: PD 10(e0x16/s12) mfi0: 19606 (boot + 27s/0x0002/info) - Inserted: PD 10(e0x16/s12) Info: enclPd=16, scsiType=0, portMap=00, sasAddr=500003937813d33e,0000000000000000 mfi0: 19607 (boot + 27s/0x0002/info) - Inserted: PD 11(e0x16/s13) mfi0: 19608 (boot + 27s/0x0002/info) - Inserted: PD 11(e0x16/s13) Info: enclPd=16, scsiType=0, portMap=00, sasAddr=500003937813d3de,0000000000000000 mfi0: 19609 (boot + 27s/0x0002/info) - Inserted: PD 12(e0x16/s14) mfi0: 19610 (boot + 27s/0x0002/info) - Inserted: PD 12(e0x16/s14) Info: enclPd=16, scsiType=0, portMap=00, sasAddr=500003937813d3da,0000000000000000 mfi0: 19611 (boot + 27s/0x0002/info) - Inserted: PD 13(e0x16/s15) mfi0: 19612 (boot + 27s/0x0002/info) - Inserted: PD 13(e0x16/s15) Info: enclPd=16, scsiType=0, portMap=00, sasAddr=500003937813d37e,0000000000000000 mfi0: 19613 (boot + 27s/0x0002/info) - Inserted: PD 14(e0x16/s16) mfi0: 19614 (boot + 27s/0x0002/info) - Inserted: PD 14(e0x16/s16) Info: enclPd=16, scsiType=0, portMap=00, sasAddr=500003937813d3e6,0000000000000000 mfi0: 19615 (boot + 27s/0x0002/info) - Inserted: PD 15(e0x16/s17) mfi0: 19616 (boot + 27s/0x0002/info) - Inserted: PD 15(e0x16/s17) Info: enclPd=16, scsiType=0, portMap=00, sasAddr=500003937813d33a,0000000000000000 mfi0: 19617 (boot + 27s/0x0002/info) - Inserted: PD 17(e0x16/s18) mfi0: 19618 (boot + 27s/0x0002/info) - Inserted: PD 17(e0x16/s18) Info: enclPd=16, scsiType=0, portMap=00, sasAddr=500304800000005e,0000000000000000 mfi0: 19619 (boot + 27s/0x0002/info) - Inserted: PD 18(e0x16/s19) mfi0: 19620 (boot + 27s/0x0002/info) - Inserted: PD 18(e0x16/s19) Info: enclPd=16, scsiType=0, portMap=00, sasAddr=500304800000005f,0000000000000000 mfi0: 19621 (417203877s/0x0020/info) - Time established as 03/21/13 17:57:57; (46 seconds since power on) mfi0: 19622 (417203895s/0x0008/info) - Battery started charging mfi0: 19623 (417203895s/0x0008/info) - Battery temperature is normal mfi0: 19624 (417203926s/0x0020/info) - Host driver is loaded and operational mfi0: 19625 (417203936s/0x0002/info) - Unexpected sense: Encl PD 16 Path 500304800000007d, CDB: 1a 00 0a 00 14 00, Sense: 5/24/00 mfi0: 19626 (417259210s/0x0008/info) - Battery relearn will start in 2 day mfi0: 19627 (417322797s/0x0020/info) - Patrol Read started mfi0: 19808 (417344758s/0x0020/info) - Patrol Read complete mfi0: 19809 (417345595s/0x0008/info) - Battery relearn will start in 1 day mfi0: 19810 (417413975s/0x0008/info) - Battery relearn will start in 5 hours mfi0: 19811 (417427560s/0x0008/info) - Battery charge complete mfi0: 19812 (417927597s/0x0020/info) - Patrol Read started mfi0: 20011 (417951400s/0x0020/info) - Patrol Read complete mfi0: 20012 (418050975s/0x0008/info) - Battery started charging mfi0: 20013 (418164335s/0x0008/info) - Battery charge complete mfi0: 20014 (418282570s/0x0008/info) - Battery started charging mfi0: 20015 (418324234s/0x0002/WARN) - Removed: PD 17(e0x16/s18) mfi0: 20016 (418324234s/0x0002/info) - Removed: PD 17(e0x16/s18) Info: enclPd=16, scsiType=0, portMap=00, sasAddr=500304800000005e,0000000000000000 mfi0: 20017 (418324234s/0x0002/info) - State change on PD 17(e0x16/s18) from ONLINE(18) to FAILED(11) mfi0: 20018 (418324234s/0x0001/info) - State change on VD 00/10 from OPTIMAL(3) to OFFLINE(0) mfi0: 20019 (418324234s/0x0001/FATAL) - VD 00/10 is now OFFLINE mfi0: 20020 (418324235s/0x0002/info) - State change on PD 17(e0x16/s18) from FAILED(11) to UNCONFIGURED_BAD(1) mfi0: 20021 (418324235s/0x0041/info) - Deleted VD 00/10 mfi0: 20022 (418324244s/0x0002/info) - Inserted: PD 17(e0x16/s18) mfi0: 20023 (418324244s/0x0002/info) - Inserted: PD 17(e0x16/s18) Info: enclPd=16, scsiType=0, portMap=00, sasAddr=500304800000005e,0000000000000000 mfi0: 20024 (418532397s/0x0020/info) - Patrol Read started mfi0: 20212 (418553611s/0x0020/info) - Patrol Read complete mfi0: 20213 (418901370s/0x0008/info) - Battery charge complete mfi0: 20214 (419019670s/0x0008/info) - Battery started charging mfi0: 20215 (419137197s/0x0020/info) - Patrol Read started mfi0: 20403 (419159066s/0x0020/info) - Patrol Read complete mfi0: 20404 (419638470s/0x0008/info) - Battery charge complete mfi0: 20405 (boot + 3s/0x0020/info) - Firmware initialization started (PCI ID 0079/1000/9260/1000) mfi0: 20406 (boot + 3s/0x0020/info) - Firmware version 2.130.363-1846 mfi0: 20407 (boot + 9s/0x0008/info) - Battery Present mfi0: 20408 (boot + 9s/0x0020/info) - Package version 12.12.0-0124 mfi0: 20409 (boot + 9s/0x0020/info) - Board Revision 61A mfi0: 20410 (boot + 28s/0x0004/info) - Enclosure (SES) discovered on PD 16(c Port 0 - 3/p1) mfi0: 20411 (boot + 28s/0x0004/info) - Enclosure PD 16(c Port 0 - 3/p1) communication restored mfi0: 20412 (boot + 28s/0x0002/info) - Inserted: Encl PD 16 mfi0: 20413 (boot + 28s/0x0002/info) - Inserted: PD 16(c Port 0 - 3/p1) Info: enclPd=16, scsiType=d, portMap=00, sasAddr=500304800000007d,0000000000000000 mfi0: 20414 (boot + 28s/0x0002/info) - Inserted: PD 04(e0x16/s0) mfi0: 20415 (boot + 28s/0x0002/info) - Inserted: PD 04(e0x16/s0) Info: enclPd=16, scsiType=0, portMap=00, sasAddr=500304800000004c,0000000000000000 mfi0: 20416 (boot + 28s/0x0002/info) - Inserted: PD 05(e0x16/s1) mfi0: 20417 (boot + 28s/0x0002/info) - Inserted: PD 05(e0x16/s1) Info: enclPd=16, scsiType=0, portMap=00, sasAddr=500304800000004d,0000000000000000 mfi0: 20418 (boot + 28s/0x0002/info) - Inserted: PD 06(e0x16/s2) mfi0: 20419 (boot + 28s/0x0002/info) - Inserted: PD 06(e0x16/s2) Info: enclPd=16, scsiType=0, portMap=00, sasAddr=5000c5003a5439ed,0000000000000000 mfi0: 20420 (boot + 28s/0x0002/info) - Inserted: PD 07(e0x16/s3) mfi0: 20421 (boot + 28s/0x0002/info) - Inserted: PD 07(e0x16/s3) Info: enclPd=16, scsiType=0, portMap=00, sasAddr=5000c5003a4dcafd,0000000000000000 mfi0: 20422 (boot + 28s/0x0002/info) - Inserted: PD 08(e0x16/s4) mfi0: 20423 (boot + 28s/0x0002/info) - Inserted: PD 08(e0x16/s4) Info: enclPd=16, scsiType=0, portMap=00, sasAddr=5000c50039d51041,0000000000000000 mfi0: 20424 (boot + 28s/0x0002/info) - Inserted: PD 09(e0x16/s5) mfi0: 20425 (boot + 28s/0x0002/info) - Inserted: PD 09(e0x16/s5) Info: enclPd=16, scsiType=0, portMap=00, sasAddr=500003937813d41a,0000000000000000 mfi0: 20426 (boot + 28s/0x0002/info) - Inserted: PD 0a(e0x16/s6) mfi0: 20427 (boot + 28s/0x0002/info) - Inserted: PD 0a(e0x16/s6) Info: enclPd=16, scsiType=0, portMap=00, sasAddr=500003937813d3be,0000000000000000 mfi0: 20428 (boot + 28s/0x0002/info) - Inserted: PD 0b(e0x16/s7) mfi0: 20429 (boot + 28s/0x0002/info) - Inserted: PD 0b(e0x16/s7) Info: enclPd=16, scsiType=0, portMap=00, sasAddr=500003937813d372,0000000000000000 mfi0: 20430 (boot + 28s/0x0002/info) - Inserted: PD 0c(e0x16/s8) mfi0: 20431 (boot + 28s/0x0002/info) - Inserted: PD 0c(e0x16/s8) Info: enclPd=16, scsiType=0, portMap=00, sasAddr=500003937813d3ea,0000000000000000 mfi0: 20432 (boot + 28s/0x0002/info) - Inserted: PD 0d(e0x16/s9) mfi0: 20433 (boot + 28s/0x0002/info) - Inserted: PD 0d(e0x16/s9) Info: enclPd=16, scsiType=0, portMap=00, sasAddr=500003937813d37a,0000000000000000 mfi0: 20434 (boot + 28s/0x0002/info) - Inserted: PD 0e(e0x16/s10) mfi0: 20435 (boot + 28s/0x0002/info) - Inserted: PD 0e(e0x16/s10) Info: enclPd=16, scsiType=0, portMap=00, sasAddr=500003937813d352,0000000000000000 mfi0: 20436 (boot + 28s/0x0002/info) - Inserted: PD 0f(e0x16/s11) mfi0: 20437 (boot + 28s/0x0002/info) - Inserted: PD 0f(e0x16/s11) Info: enclPd=16, scsiType=0, portMap=00, sasAddr=500003937813d406,0000000000000000 mfi0: 20438 (boot + 28s/0x0002/info) - Inserted: PD 10(e0x16/s12) mfi0: 20439 (boot + 28s/0x0002/info) - Inserted: PD 10(e0x16/s12) Info: enclPd=16, scsiType=0, portMap=00, sasAddr=500003937813d33e,0000000000000000 mfi0: 20440 (boot + 28s/0x0002/info) - Inserted: PD 11(e0x16/s13) mfi0: 20441 (boot + 28s/0x0002/info) - Inserted: PD 11(e0x16/s13) Info: enclPd=16, scsiType=0, portMap=00, sasAddr=500003937813d3de,0000000000000000 mfi0: 20442 (boot + 28s/0x0002/info) - Inserted: PD 12(e0x16/s14) mfi0: 20443 (boot + 28s/0x0002/info) - Inserted: PD 12(e0x16/s14) Info: enclPd=16, scsiType=0, portMap=00, sasAddr=500003937813d3da,0000000000000000 mfi0: 20444 (boot + 28s/0x0002/info) - Inserted: PD 13(e0x16/s15) mfi0: 20445 (boot + 28s/0x0002/info) - Inserted: PD 13(e0x16/s15) Info: enclPd=16, scsiType=0, portMap=00, sasAddr=500003937813d37e,0000000000000000 mfi0: 20446 (boot + 28s/0x0002/info) - Inserted: PD 14(e0x16/s16) mfi0: 20447 (boot + 28s/0x0002/info) - Inserted: PD 14(e0x16/s16) Info: enclPd=16, scsiType=0, portMap=00, sasAddr=500003937813d3e6,0000000000000000 mfi0: 20448 (boot + 28s/0x0002/info) - Inserted: PD 15(e0x16/s17) mfi0: 20449 (boot + 28s/0x0002/info) - Inserted: PD 15(e0x16/s17) Info: enclPd=16, scsiType=0, portMap=00, sasAddr=500003937813d33a,0000000000000000 mfi0: 20450 (boot + 28s/0x0002/info) - Inserted: PD 17(e0x16/s18) mfi0: 20451 (boot + 28s/0x0002/info) - Inserted: PD 17(e0x16/s18) Info: enclPd=16, scsiType=0, portMap=00, sasAddr=500304800000005e,0000000000000000 mfi0: 20452 (boot + 28s/0x0002/info) - Inserted: PD 18(e0x16/s19) mfi0: 20453 (boot + 28s/0x0002/info) - Inserted: PD 18(e0x16/s19) Info: enclPd=16, scsiType=0, portMap=00, sasAddr=500304800000005f,0000000000000000 mfi0: 20454 (boot + 64s/0x0008/info) - Battery temperature is normal mfi0: 20455 (419670570s/0x0020/info) - Time established as 04/19/13 7:09:30; (74 seconds since power on) mfi0: 20456 (419670625s/0x0008/info) - Periodic Battery Relearn was missed, and rescheduled to 04/21/13 9:19:30. mfi0: 20457 (419670627s/0x0020/info) - Host driver is loaded and operational mfi0: 20458 (419670637s/0x0002/info) - Unexpected sense: Encl PD 16 Path 500304800000007d, CDB: 1a 00 0a 00 14 00, Sense: 5/24/00 mfi0: 20459 (419678425s/0x0008/info) - Battery relearn will start in 2 day mfi0: 20460 (419741997s/0x0020/info) - Patrol Read started mfi0: 20569 (419760845s/0x0008/info) - Battery started charging mfi0: 20632 (419764409s/0x0020/info) - Patrol Read complete mfi0: 20633 (419764810s/0x0008/info) - Battery relearn will start in 1 day mfi0: 20634 (419833190s/0x0008/info) - Battery relearn will start in 5 hours mfi0: 20635 (420346797s/0x0020/info) - Patrol Read started mfi0: 20823 (420372124s/0x0020/info) - Patrol Read complete mfi0: 20824 (420379775s/0x0008/info) - Battery charge complete mfi0: 20825 (boot + 3s/0x0020/info) - Firmware initialization started (PCI ID 0079/1000/9260/1000) mfi0: 20826 (boot + 3s/0x0020/info) - Firmware version 2.130.363-1846 mfi0: 20827 (boot + 9s/0x0008/info) - Battery Present mfi0: 20828 (boot + 9s/0x0020/info) - Package version 12.12.0-0124 mfi0: 20829 (boot + 9s/0x0020/info) - Board Revision 61A mfi0: 20830 (boot + 28s/0x0004/info) - Enclosure (SES) discovered on PD 16(c Port 0 - 3/p1) mfi0: 20831 (boot + 28s/0x0004/info) - Enclosure PD 16(c Port 0 - 3/p1) communication restored mfi0: 20832 (boot + 28s/0x0002/info) - Inserted: Encl PD 16 mfi0: 20833 (boot + 28s/0x0002/info) - Inserted: PD 16(c Port 0 - 3/p1) Info: enclPd=16, scsiType=d, portMap=00, sasAddr=500304800000007d,0000000000000000 mfi0: 20834 (boot + 28s/0x0002/info) - Inserted: PD 04(e0x16/s0) mfi0: 20835 (boot + 28s/0x0002/info) - Inserted: PD 04(e0x16/s0) Info: enclPd=16, scsiType=0, portMap=00, sasAddr=500304800000004c,0000000000000000 mfi0: 20836 (boot + 28s/0x0002/info) - Inserted: PD 05(e0x16/s1) mfi0: 20837 (boot + 28s/0x0002/info) - Inserted: PD 05(e0x16/s1) Info: enclPd=16, scsiType=0, portMap=00, sasAddr=500304800000004d,0000000000000000 mfi0: 20838 (boot + 28s/0x0002/info) - Inserted: PD 06(e0x16/s2) mfi0: 20839 (boot + 28s/0x0002/info) - Inserted: PD 06(e0x16/s2) Info: enclPd=16, scsiType=0, portMap=00, sasAddr=5000c5003a5439ed,0000000000000000 mfi0: 20840 (boot + 28s/0x0002/info) - Inserted: PD 07(e0x16/s3) mfi0: 20841 (boot + 28s/0x0002/info) - Inserted: PD 07(e0x16/s3) Info: enclPd=16, scsiType=0, portMap=00, sasAddr=5000c5003a4dcafd,0000000000000000 mfi0: 20842 (boot + 28s/0x0002/info) - Inserted: PD 08(e0x16/s4) mfi0: 20843 (boot + 28s/0x0002/info) - Inserted: PD 08(e0x16/s4) Info: enclPd=16, scsiType=0, portMap=00, sasAddr=5000c50039d51041,0000000000000000 mfi0: 20844 (boot + 28s/0x0002/info) - Inserted: PD 09(e0x16/s5) mfi0: 20845 (boot + 28s/0x0002/info) - Inserted: PD 09(e0x16/s5) Info: enclPd=16, scsiType=0, portMap=00, sasAddr=500003937813d41a,0000000000000000 mfi0: 20846 (boot + 28s/0x0002/info) - Inserted: PD 0a(e0x16/s6) mfi0: 20847 (boot + 28s/0x0002/info) - Inserted: PD 0a(e0x16/s6) Info: enclPd=16, scsiType=0, portMap=00, sasAddr=500003937813d3be,0000000000000000 mfi0: 20848 (boot + 28s/0x0002/info) - Inserted: PD 0b(e0x16/s7) mfi0: 20849 (boot + 28s/0x0002/info) - Inserted: PD 0b(e0x16/s7) Info: enclPd=16, scsiType=0, portMap=00, sasAddr=500003937813d372,0000000000000000 mfi0: 20850 (boot + 28s/0x0002/info) - Inserted: PD 0c(e0x16/s8) mfi0: 20851 (boot + 28s/0x0002/info) - Inserted: PD 0c(e0x16/s8) Info: enclPd=16, scsiType=0, portMap=00, sasAddr=500003937813d3ea,0000000000000000 mfi0: 20852 (boot + 28s/0x0002/info) - Inserted: PD 0d(e0x16/s9) mfi0: 20853 (boot + 28s/0x0002/info) - Inserted: PD 0d(e0x16/s9) Info: enclPd=16, scsiType=0, portMap=00, sasAddr=500003937813d37a,0000000000000000 mfi0: 20854 (boot + 28s/0x0002/info) - Inserted: PD 0e(e0x16/s10) mfi0: 20855 (boot + 28s/0x0002/info) - Inserted: PD 0e(e0x16/s10) Info: enclPd=16, scsiType=0, portMap=00, sasAddr=500003937813d352,0000000000000000 mfi0: 20856 (boot + 28s/0x0002/info) - Inserted: PD 0f(e0x16/s11) mfi0: 20857 (boot + 28s/0x0002/info) - Inserted: PD 0f(e0x16/s11) Info: enclPd=16, scsiType=0, portMap=00, sasAddr=500003937813d406,0000000000000000 mfi0: 20858 (boot + 28s/0x0002/info) - Inserted: PD 10(e0x16/s12) mfi0: 20859 (boot + 28s/0x0002/info) - Inserted: PD 10(e0x16/s12) Info: enclPd=16, scsiType=0, portMap=00, sasAddr=500003937813d33e,0000000000000000 mfi0: 20860 (boot + 28s/0x0002/info) - Inserted: PD 11(e0x16/s13) mfi0: 20861 (boot + 28s/0x0002/info) - Inserted: PD 11(e0x16/s13) Info: enclPd=16, scsiType=0, portMap=00, sasAddr=500003937813d3de,0000000000000000 mfi0: 20862 (boot + 28s/0x0002/info) - Inserted: PD 12(e0x16/s14) mfi0: 20863 (boot + 28s/0x0002/info) - Inserted: PD 12(e0x16/s14) Info: enclPd=16, scsiType=0, portMap=00, sasAddr=500003937813d3da,0000000000000000 mfi0: 20864 (boot + 28s/0x0002/info) - Inserted: PD 13(e0x16/s15) mfi0: 20865 (boot + 28s/0x0002/info) - Inserted: PD 13(e0x16/s15) Info: enclPd=16, scsiType=0, portMap=00, sasAddr=500003937813d37e,0000000000000000 mfi0: 20866 (boot + 28s/0x0002/info) - Inserted: PD 14(e0x16/s16) mfi0: 20867 (boot + 28s/0x0002/info) - Inserted: PD 14(e0x16/s16) Info: enclPd=16, scsiType=0, portMap=00, sasAddr=500003937813d3e6,0000000000000000 mfi0: 20868 (boot + 28s/0x0002/info) - Inserted: PD 15(e0x16/s17) mfi0: 20869 (boot + 28s/0x0002/info) - Inserted: PD 15(e0x16/s17) Info: enclPd=16, scsiType=0, portMap=00, sasAddr=500003937813d33a,0000000000000000 mfi0: 20870 (boot + 28s/0x0002/info) - Inserted: PD 17(e0x16/s18) mfi0: 20871 (boot + 28s/0x0002/info) - Inserted: PD 17(e0x16/s18) Info: enclPd=16, scsiType=0, portMap=00, sasAddr=500304800000005e,0000000000000000 mfi0: 20872 (boot + 28s/0x0002/info) - Inserted: PD 18(e0x16/s19) mfi0: 20873 (boot + 28s/0x0002/info) - Inserted: PD 18(e0x16/s19) Info: enclPd=16, scsiType=0, portMap=00, sasAddr=500304800000005f,0000000000000000 mfi0: 20874 (420788325s/0x0020/info) - Time established as 05/02/13 5:38:45; (62 seconds since power on) mfi0: 20875 (420788327s/0x0008/info) - Battery started charging mfi0: 20876 (420788327s/0x0008/info) - Battery temperature is normal mfi0: 20877 (420788327s/0x0008/info) - Periodic Battery Relearn was missed, and rescheduled to 05/05/13 9:19:30. mfi0: 20878 (420788374s/0x0020/info) - Host driver is loaded and operational mfi0: 20879 (420788384s/0x0002/info) - Unexpected sense: Encl PD 16 Path 500304800000007d, CDB: 1a 00 0a 00 14 00, Sense: 5/24/00 mfi0: 20880 (420887972s/0x0008/info) - Battery relearn will start in 2 day mfi0: 20881 (420951597s/0x0020/info) - Patrol Read started mfi0: 21052 (420965623s/0x0020/info) - Patrol Read complete mfi0: 21053 (420974422s/0x0008/info) - Battery relearn will start in 1 day mfi0: 21054 (421015567s/0x0008/info) - Battery charge complete mfi0: 21055 (421042802s/0x0008/info) - Battery relearn will start in 5 hours mfi0: 21056 (421133867s/0x0008/info) - Battery started charging mfi0: 21057 (boot + 3s/0x0020/info) - Firmware initialization started (PCI ID 0079/1000/9260/1000) mfi0: 21058 (boot + 3s/0x0020/info) - Firmware version 2.130.363-1846 mfi0: 21059 (boot + 9s/0x0008/info) - Battery Present mfi0: 21060 (boot + 9s/0x0020/info) - Package version 12.12.0-0124 mfi0: 21061 (boot + 9s/0x0020/info) - Board Revision 61A mfi0: 21062 (boot + 28s/0x0004/info) - Enclosure (SES) discovered on PD 16(c Port 0 - 3/p1) mfi0: 21063 (boot + 28s/0x0004/info) - Enclosure PD 16(c Port 0 - 3/p1) communication restored mfi0: 21064 (boot + 28s/0x0002/info) - Inserted: Encl PD 16 The GEOM class LABEL is already loaded. usbus0: 12Mbps Full Speed USB v1.0 usbus1: 12Mbps Full Speed USB v1.0 usbus2: 12Mbps Full Speed USB v1.0 usbus3: 480Mbps High Speed USB v2.0 usbus4: 12Mbps Full Speed USB v1.0 usbus5: 12Mbps Full Speed USB v1.0 usbus6: 12Mbps Full Speed USB v1.0 usbus7: 480Mbps High Speed USB v2.0 ugen0.1: at usbus0 uhub0: on usbus0 ugen1.1: at usbus1 uhub1: on usbus1 ugen2.1: at usbus2 uhub2: on usbus2 ugen3.1: at usbus3 uhub3: on usbus3 ugen4.1: at usbus4 uhub4: on usbus4 ugen5.1: at usbus5 uhub5: on usbus5 ugen6.1: at usbus6 uhub6: on usbus6 ugen7.1: at usbus7 uhub7: on usbus7 mfid0 on mfi0 mfid0: 285568MB (584843264 sectors) RAID volume (no label) is optimal mfid1 on mfi0 mfid1: 285568MB (584843264 sectors) RAID volume (no label) is optimal mfid2 on mfi0 mfid2: 285568MB (584843264 sectors) RAID volume (no label) is optimal mfid3 on mfi0 mfid3: 285568MB (584843264 sectors) RAID volume (no label) is optimal mfid4 on mfi0 mfid4: 285568MB (584843264 sectors) RAID volume (no label) is optimal mfid5 on mfi0 mfid5: 285568MB (584843264 sectors) RAID volume (no label) is optimal mfid6 on mfi0 mfid6: 285568MB (584843264 sectors) RAID volume (no label) is optimal mfid7 on mfi0 mfid7: 285568MB (584843264 sectors) RAID volume (no label) is optimal mfid8 on mfi0 mfid8: 285568MB (584843264 sectors) RAID volume (no label) is optimal mfid9 on mfi0 mfid9: 285568MB (584843264 sectors) RAID volume (no label) is optimal mfid10 on mfi0 mfid10: 285568MB (584843264 sectors) RAID volume (no label) is optimal mfid11 on mfi0 mfid11: 285568MB (584843264 sectors) RAID volume (no label) is optimal mfid12 on mfi0 mfid12: 285568MB (584843264 sectors) RAID volume (no label) is optimal mfid13 on mfi0 mfid13: 285568MB (584843264 sectors) RAID volume (no label) is optimal mfid14 on mfi0 mfid14: 285568MB (584843264 sectors) RAID volume (no label) is optimal mfid15 on mfi0 mfid15: 285568MB (584843264 sectors) RAID volume (no label) is optimal mfid16 on mfi0 mfid16: 953344MB (1952448512 sectors) RAID volume (no label) is optimal mfid17 on mfi0 mfid17: 113952MB (233373696 sectors) RAID volume (no label) is optimal mfid18 on mfi0 mfid18: 113952MB (233373696 sectors) RAID volume (no label) is optimal mfi0: 21065 (boot + 28s/0x0002/info) - Inserted: PD 16(c Port 0 - 3/p1) Info: enclPd=16, scsiType=d, portMap=00, sasAddr=500304800000007d,0000000000000000 mfi0: 21066 (boot + 28s/0x0002/info) - Inserted: PD 04(e0x16/s0) mfi0: 21067 (boot + 28s/0x0002/info) - Inserted: PD 04(e0x16/s0) Info: enclPd=16, scsiType=0, portMap=00, sasAddr=500304800000004c,0000000000000000 mfi0: 21068 (boot + 28s/0x0002/info) - Inserted: PD 05(e0x16/s1) mfi0: 21069 (boot + 28s/0x0002/info) - Inserted: PD 05(e0x16/s1) Info: enclPd=16, scsiType=0, portMap=00, sasAddr=500304800000004d,0000000000000000 mfi0: 21070 (boot + 28s/0x0002/info) - Inserted: PD 06(e0x16/s2) mfi0: 21071 (boot + 28s/0x0002/info) - Inserted: PD 06(e0x16/s2) Info: enclPd=16, scsiType=0, portMap=00, sasAddr=5000c5003a5439ed,0000000000000000 mfi0: 21072 (boot + 28s/0x0002/info) - Inserted: PD 07(e0x16/s3) mfi0: 21073 (boot + 28s/0x0002/info) - Inserted: PD 07(e0x16/s3) Info: enclPd=16, scsiType=0, portMap=00, sasAddr=5000c5003a4dcafd,0000000000000000 mfi0: 21074 (boot + 28s/0x0002/info) - Inserted: PD 08(e0x16/s4) mfi0: 21075 (boot + 28s/0x0002/info) - Inserted: PD 08(e0x16/s4) Info: enclPd=16, scsiType=0, portMap=00, sasAddr=5000c50039d51041,0000000000000000 mfi0: 21076 (boot + 28s/0x0002/info) - Inserted: PD 09(e0x16/s5) mfi0: 21077 (boot + 28s/0x0002/info) - Inserted: PD 09(e0x16/s5) Info: enclPd=16, scsiType=0, portMap=00, sasAddr=500003937813d41a,0000000000000000 mfi0: 21078 (boot + 28s/0x0002/info) - Inserted: PD 0a(e0x16/s6) mfi0: 21079 (boot + 28s/0x0002/info) - Inserted: PD 0a(e0x16/s6) Info: enclPd=16, scsiType=0, portMap=00, sasAddr=500003937813d3be,0000000000000000 mfi0: 21080 (boot + 28s/0x0002/info) - Inserted: PD 0b(e0x16/s7) mfi0: 21081 (boot + 28s/0x0002/info) - Inserted: PD 0b(e0x16/s7) Info: enclPd=16, scsiType=0, portMap=00, sasAddr=500003937813d372,0000000000000000 mfi0: 21082 (boot + 28s/0x0002/info) - Inserted: PD 0c(e0x16/s8) mfi0: 21083 (boot + 28s/0x0002/info) - Inserted: PD 0c(e0x16/s8) Info: enclPd=16, scsiType=0, portMap=00, sasAddr=500003937813d3ea,0000000000000000 mfi0: 21084 (boot + 28s/0x0002/info) - Inserted: PD 0d(e0x16/s9) mfi0: 21085 (boot + 28s/0x0002/info) - Inserted: PD 0d(e0x16/s9) Info: enclPd=16, scsiType=0, portMap=00, sasAddr=500003937813d37a,0000000000000000 mfi0: 21086 (boot + 28s/0x0002/info) - Inserted: PD 0e(e0x16/s10) mfi0: 21087 (boot + 28s/0x0002/info) - Inserted: PD 0e(e0x16/s10) Info: enclPd=16, scsiType=0, portMap=00, sasAddr=500003937813d352,0000000000000000 mfi0: 21088 (boot + 28s/0x0002/info) - Inserted: PD 0f(e0x16/s11) mfi0: 21089 (boot + 28s/0x0002/info) - Inserted: PD 0f(e0x16/s11) Info: enclPd=16, scsiType=0, portMap=00, sasAddr=500003937813d406,0000000000000000 mfi0: 21090 (boot + 28s/0x0002/info) - Inserted: PD 10(e0x16/s12) mfi0: 21091 (boot + 28s/0x0002/info) - Inserted: PD 10(e0x16/s12) Info: enclPd=16, scsiType=0, portMap=00, sasAddr=500003937813d33e,0000000000000000 mfi0: 21092 (boot + 28s/0x0002/info) - Inserted: PD 11(e0x16/s13) mfi0: 21093 (boot + 28s/0x0002/info) - Inserted: PD 11(e0x16/s13) Info: enclPd=16, scsiType=0, portMap=00, sasAddr=500003937813d3de,0000000000000000 mfi0: 21094 (boot + 28s/0x0002/info) - Inserted: PD 12(e0x16/s14) mfi0: 21095 (boot + 28s/0x0002/info) - Inserted: PD 12(e0x16/s14) Info: enclPd=16, scsiType=0, portMap=00, sasAddr=500003937813d3da,0000000000000000 mfi0: 21096 (boot + 28s/0x0002/info) - Inserted: PD 13(e0x16/s15) mfi0: 21097 (boot + 28s/0x0002/info) - Inserted: PD 13(e0x16/s15) Info: enclPd=16, scsiType=0, portMap=00, sasAddr=500003937813d37e,0000000000000000 mfi0: 21098 (boot + 28s/0x0002/info) - Inserted: PD 14(e0x16/s16) mfi0: 21099 (boot + 28s/0x0002/info) - Inserted: PD 14(e0x16/s16) Info: enclPd=16, scsiType=0, portMap=00, sasAddr=500003937813d3e6,0000000000000000 mfi0: 21100 (boot + 28s/0x0002/info) - Inserted: PD 15(e0x16/s17) mfi0: 21101 (boot + 28s/0x0002/info) - Inserted: PD 15(e0x16/s17) Info: enclPd=16, scsiType=0, portMap=00, sasAddr=500003937813d33a,0000000000000000 mfi0: 21102 (boot + 28s/0x0002/info) - Inserted: PD 17(e0x16/s18) mfi0: 21103 (boot + 28s/0x0002/info) - Inserted: PD 17(e0x16/s18) Info: enclPd=16, scsiType=0, portMap=00, sasAddr=500304800000005e,0000000000000000 mfi0: 21104 (boot + 28s/0x0002/info) - Inserted: PD 18(e0x16/s19) mfi0: 21105 (boot + 28s/0x0002/info) - Inserted: PD 18(e0x16/s19) Info: enclPd=16, scsiType=0, portMap=00, sasAddr=500304800000005f,0000000000000000 mfi0: 21106 (421479053s/0x0020/info) - Time established as 05/10/13 5:30:53; (62 seconds since power on) mfi0: 21107 (421479055s/0x0008/info) - Battery started charging mfi0: 21108 (421479055s/0x0008/info) - Battery temperature is normal mfi0: 21109 (421479055s/0x0008/info) - Periodic Battery Relearn was missed, and rescheduled to 05/12/13 9:19:30. mfi0: 21110 (421479109s/0x0020/info) - Host driver is loaded and operational ipmi0: IPMI device rev. 1, firmware rev. 2.04, version 2.0 ipmi0: Number of channels 2 ipmi0: Attached watchdog GEOM: mfid2: corrupt or invalid GPT detected. GEOM: mfid2: GPT rejected -- may not be recoverable. GEOM: mfid3: corrupt or invalid GPT detected. GEOM: mfid3: GPT rejected -- may not be recoverable. uhub0: 2 ports with 2 removable, self powered uhub1: 2 ports with 2 removable, self powered uhub2: 2 ports with 2 removable, self powered uhub4: 2 ports with 2 removable, self powered uhub5: 2 ports with 2 removable, self powered GEOM: mfid4: corrupt or invalid GPT detected. GEOM: mfid4: GPT rejected -- may not be recoverable. uhub6: 2 ports with 2 removable, self powered GEOM: mfid5: corrupt or invalid GPT detected. GEOM: mfid5: GPT rejected -- may not be recoverable. GEOM: mfid6: corrupt or invalid GPT detected. GEOM: mfid6: GPT rejected -- may not be recoverable. GEOM: mfid7: corrupt or invalid GPT detected. GEOM: mfid7: GPT rejected -- may not be recoverable. GEOM: mfid8: corrupt or invalid GPT detected. GEOM: mfid8: GPT rejected -- may not be recoverable. GEOM: mfid9: corrupt or invalid GPT detected. GEOM: mfid9: GPT rejected -- may not be recoverable. GEOM: mfid10: corrupt or invalid GPT detected. GEOM: mfid10: GPT rejected -- may not be recoverable. GEOM: mfid11: corrupt or invalid GPT detected. GEOM: mfid11: GPT rejected -- may not be recoverable. GEOM: mfid12: corrupt or invalid GPT detected. GEOM: mfid12: GPT rejected -- may not be recoverable. GEOM: mfid13: corrupt or invalid GPT detected. GEOM: mfid13: GPT rejected -- may not be recoverable. GEOM: mfid14: corrupt or invalid GPT detected. GEOM: mfid14: GPT rejected -- may not be recoverable. GEOM: mfid15: corrupt or invalid GPT detected. GEOM: mfid15: GPT rejected -- may not be recoverable. uhub3: 6 ports with 6 removable, self powered uhub7: 6 ports with 6 removable, self powered mfi0: 21111 (421479119s/0x0002/info) - Unexpected sense: Encl PD 16 Path 500304800000007d, CDB: 1a 00 0a 00 14 00, Sense: 5/24/00 ada0 at ahcich0 bus 0 scbus0 target 0 lun 0 ada0: ATA-7 SATA 2.x device ada0: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 512bytes) ada0: 3775MB (7732368 512 byte sectors: 16H 63S/T 7671C) ada0: Previously was known as ad4 ses0 at mfi0 bus 0 scbus6 target 22 lun 0 ses0: Fixed Enclosure Services SCSI-5 device ses0: 150.000MB/s transfers ses0: SCSI-3 SES Device pass1 at mfi0 bus 0 scbus6 target 4 lun 0 pass1: Fixed Uninstalled SCSI-5 device pass1: 150.000MB/s transfers pass2 at mfi0 bus 0 scbus6 target 5 lun 0 pass2: Fixed Uninstalled SCSI-5 device pass2: 150.000MB/s transfers pass3 at mfi0 bus 0 scbus6 target 6 lun 0 pass3: Fixed Uninstalled SCSI-5 device pass3: 150.000MB/s transfers pass4 at mfi0 bus 0 scbus6 target 7 lun 0 pass4: Fixed Uninstalled SCSI-5 device pass4: 150.000MB/s transfers pass5 at mfi0 bus 0 scbus6 target 8 lun 0 pass5: Fixed Uninstalled SCSI-5 device pass5: 150.000MB/s transfers pass6 at mfi0 bus 0 scbus6 target 9 lun 0 pass6: Fixed Uninstalled SCSI-5 device pass6: 150.000MB/s transfers pass7 at mfi0 bus 0 scbus6 target 10 lun 0 pass7: Fixed Uninstalled SCSI-5 device pass7: 150.000MB/s transfers pass8 at mfi0 bus 0 scbus6 target 11 lun 0 pass8: Fixed Uninstalled SCSI-5 device pass8: 150.000MB/s transfers pass9 at mfi0 bus 0 scbus6 target 12 lun 0 pass9: Fixed Uninstalled SCSI-5 device pass9: 150.000MB/s transfers pass10 at mfi0 bus 0 scbus6 target 13 lun 0 pass10: Fixed Uninstalled SCSI-5 device pass10: 150.000MB/s transfers pass11 at mfi0 bus 0 scbus6 target 14 lun 0 pass11: Fixed Uninstalled SCSI-5 device pass11: 150.000MB/s transfers pass12 at mfi0 bus 0 scbus6 target 15 lun 0 pass12: Fixed Uninstalled SCSI-5 device pass12: 150.000MB/s transfers pass13 at mfi0 bus 0 scbus6 target 16 lun 0 pass13: Fixed Uninstalled SCSI-5 device pass13: 150.000MB/s transfers pass14 at mfi0 bus 0 scbus6 target 17 lun 0 pass14: Fixed Uninstalled SCSI-5 device pass14: 150.000MB/s transfers pass15 at mfi0 bus 0 scbus6 target 18 lun 0 pass15: Fixed Uninstalled SCSI-5 device pass15: 150.000MB/s transfers pass16 at mfi0 bus 0 scbus6 target 19 lun 0 pass16: Fixed Uninstalled SCSI-5 device pass16: 150.000MB/s transfers pass17 at mfi0 bus 0 scbus6 target 20 lun 0 pass17: Fixed Uninstalled SCSI-5 device pass17: 150.000MB/s transfers pass18 at mfi0 bus 0 scbus6 target 21 lun 0 pass18: Fixed Uninstalled SCSI-5 device pass18: 150.000MB/s transfers pass20 at mfi0 bus 0 scbus6 target 23 lun 0 pass20: Fixed Uninstalled SCSI-5 device pass20: 150.000MB/s transfers pass21 at mfi0 bus 0 scbus6 target 24 lun 0 pass21: Fixed Uninstalled SCSI-5 device pass21: 150.000MB/s transfers SMP: AP CPU #1 Launched! SMP: AP CPU #15 Launched! SMP: AP CPU #6 Launched! SMP: AP CPU #11 Launched! SMP: AP CPU #7 Launched! SMP: AP CPU #12 Launched! SMP: AP CPU #5 Launched! SMP: AP CPU #8 Launched! SMP: AP CPU #2 Launched! SMP: AP CPU #13 Launched! SMP: AP CPU #3 Launched! SMP: AP CPU #9 Launched! SMP: AP CPU #4 Launched! SMP: AP CPU #14 Launched! SMP: AP CPU #10 Launched! Timecounter "TSC-low" frequency 9375545 Hz quality 1000 Trying to mount root from ufs:/dev/ufs/rootfs []... WARNING: / was not properly dismounted ugen1.2: at usbus1 ukbd0: on usbus1 kbd2 at ukbd0 ums0: on usbus1 ZFS filesystem version 5 ZFS storage pool version 28 --Apple-Mail-36--527606426 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii ------------- END System information------------ --Apple-Mail-36--527606426-- From owner-freebsd-stable@FreeBSD.ORG Wed May 15 17:08:28 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 190BFFB1 for ; Wed, 15 May 2013 17:08:28 +0000 (UTC) (envelope-from jfvogel@gmail.com) Received: from mail-ve0-x230.google.com (mail-ve0-x230.google.com [IPv6:2607:f8b0:400c:c01::230]) by mx1.freebsd.org (Postfix) with ESMTP id D0C65D8C for ; Wed, 15 May 2013 17:08:27 +0000 (UTC) Received: by mail-ve0-f176.google.com with SMTP id jz10so1024668veb.21 for ; Wed, 15 May 2013 10:08:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=8xMpKP7JGyIhMT27B4YTPSq9NU7Z9Gx4JBo6j0K8wFU=; b=pTwEWkRM0HMiqbFzj/c3g/cuSpUXBHTJ+W9qu5YeG0cPOSuiTiZ649Oj/L26F9BsN8 50EpIhEugj35/QoDhVW5PNgWYxBS9m2olbW4KmKraCa5gV4psNC27LaXAnYtLgjtteO0 62BArBlVFJcOaxV9vDBeAHzBuaqSpj25O5Jb4vskM4f0vLqmIz3KZa/8OPs8pYbZ3JLr ppVTjayoFH0WC7vQNv0C6VS73tt6UYWdbr0RPo4O2646Evbw9lLyr4fywjp2povyjovx JSzoiNj2yI0IrQAucbl8pOsyQs2+ql7hDvmhCTpSRlHK1GW62QYpsWtpR9j6MWk0V6ny W8NQ== MIME-Version: 1.0 X-Received: by 10.52.230.164 with SMTP id sz4mr22192852vdc.118.1368637238590; Wed, 15 May 2013 10:00:38 -0700 (PDT) Received: by 10.220.55.143 with HTTP; Wed, 15 May 2013 10:00:38 -0700 (PDT) In-Reply-To: References: Date: Wed, 15 May 2013 10:00:38 -0700 Message-ID: Subject: Re: still mbuf leak in 9.0 / 9.1? From: Jack Vogel To: dennis berger Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: FreeBSD stable X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 15 May 2013 17:08:28 -0000 So, you stop getting 10G transmission and so you are looking at mbuf leaks? I don't see anything in your data that makes it look like you've run out of available mbufs. You said you're running jumbos, what size? You do realize that if you do this the clusters are coming from different pools and you are not displaying those. What are all your nmb limits set to? So, this is 9.1 RELEASE, or stable? If you are using the driver from release I would first off suggest you test the code from HEAD. What is the 10G device, I see its using Twinax, and I have been told there is a problem at times with those that is corrected in recent shared code, this is why you should try the latest code. Cheers, Jack On Wed, May 15, 2013 at 2:00 AM, dennis berger wrote: > Hi list, > since we activated 10gbe on ixgbe cards + jumbo frames(9k) on 9.0 and now > on 9.1 we recognize that after a random period of time, sometimes a week, > sometimes only a day, the > system doesn't send any packets out. The phenomenon is that you can't > login via ssh, nfs and istgt is not operative. Yet you can login on the > console and execute commands. > A clean shutdown isn't possible though. It hangs after vnode cleaning, > normally you would see detaching of usb devices here, or other devices > maybe? > I've read the other post on this ML about mbuf leak in the arp handling > code in if_ether.c line 558. We don't see any of those notices in dmesg s= o > I don't think that glebius fix would apply for us. > I'm collecting system and memory information every hour. > > > Script looks like this. > less /etc/periodic/hourly/100.report-memory.sh > #!/bin/sh > > reporttimestamp=3D`date +%d-%m-%Y-%H-%M` > reportname=3D${reporttimestamp}.txt > > cd /root/memory-mon > > top -b > $reportname > echo "" >> $reportname > vmstat -m >> $reportname > echo "" >> $reportname > vmstat -z >> $reportname > echo "" >> $reportname > netstat -Q >> $reportname > echo "" >> $reportname > netstat -n -x >> $reportname > echo "" >> $reportname > netstat -m >> $reportname > /usr/bin/perl /usr/local/bin/zfs-stats -a >> $reportname > > When you grep for mbuf or mbuf usage you will see this for example: > > root@freenas:/root/memory-mon # grep mbuf_packet: * > 14-05-2013-14-09.txt:mbuf_packet: 256, 0, 9246, > 2786,201700429, 0, 0 > 14-05-2013-15-09.txt:mbuf_packet: 256, 0, 9256, > 2776,201773122, 0, 0 > 14-05-2013-16-09.txt:mbuf_packet: 256, 0, 9266, > 2766,201871553, 0, 0 > 14-05-2013-17-09.txt:mbuf_packet: 256, 0, 9276, > 2756,201915405, 0, 0 > 14-05-2013-18-09.txt:mbuf_packet: 256, 0, 9286, > 2746,201927956, 0, 0 > 14-05-2013-19-09.txt:mbuf_packet: 256, 0, 9296, > 2352,201935681, 0, 0 > 14-05-2013-20-09.txt:mbuf_packet: 256, 0, 9306, > 2342,201943754, 0, 0 > 14-05-2013-21-09.txt:mbuf_packet: 256, 0, 9316, > 2332,201950961, 0, 0 > 14-05-2013-22-09.txt:mbuf_packet: 256, 0, 9326, > 2450,201958150, 0, 0 > 14-05-2013-23-09.txt:mbuf_packet: 256, 0, 9336, > 2440,201967178, 0, 0 > 15-05-2013-00-09.txt:mbuf_packet: 256, 0, 9346, > 2430,201974561, 0, 0 > 15-05-2013-01-09.txt:mbuf_packet: 256, 0, 9356, > 2420,201982105, 0, 0 > 15-05-2013-02-09.txt:mbuf_packet: 256, 0, 9366, > 2410,201989463, 0, 0 > 15-05-2013-03-09.txt:mbuf_packet: 256, 0, 9378, > 1502,203019168, 0, 0 > 15-05-2013-04-09.txt:mbuf_packet: 256, 0, 9384, > 1624,205953601, 0, 0 > 15-05-2013-05-09.txt:mbuf_packet: 256, 0, 9394, > 1870,205959258, 0, 0 > 15-05-2013-06-09.txt:mbuf_packet: 256, 0, 9404, > 2500,205969396, 0, 0 > 15-05-2013-07-09.txt:mbuf_packet: 256, 0, 9414, > 3386,207945161, 0, 0 > 15-05-2013-08-09.txt:mbuf_packet: 256, 0, 9424, > 3376,208094689, 0, 0 > 15-05-2013-09-09.txt:mbuf_packet: 256, 0, 9434, > 2982,208172465, 0, 0 > 15-05-2013-10-09.txt:mbuf_packet: 256, 0, 9444, > 3100,208270369, 0, 0 > > and > > root@freenas:/root/memory-mon # grep "mbufs in use" * > 14-05-2013-14-09.txt:58444/5816/64260 mbufs in use (current/cache/total) > 14-05-2013-15-09.txt:58455/5805/64260 mbufs in use (current/cache/total) > 14-05-2013-16-09.txt:58464/5796/64260 mbufs in use (current/cache/total) > 14-05-2013-17-09.txt:58475/5785/64260 mbufs in use (current/cache/total) > 14-05-2013-18-09.txt:58484/5776/64260 mbufs in use (current/cache/total) > 14-05-2013-19-09.txt:58493/5767/64260 mbufs in use (current/cache/total) > 14-05-2013-20-09.txt:58503/5757/64260 mbufs in use (current/cache/total) > 14-05-2013-21-09.txt:58513/5747/64260 mbufs in use (current/cache/total) > 14-05-2013-22-09.txt:58523/5737/64260 mbufs in use (current/cache/total) > 14-05-2013-23-09.txt:58533/5727/64260 mbufs in use (current/cache/total) > 15-05-2013-00-09.txt:58543/5717/64260 mbufs in use (current/cache/total) > 15-05-2013-01-09.txt:58554/5706/64260 mbufs in use (current/cache/total) > 15-05-2013-02-09.txt:58563/5697/64260 mbufs in use (current/cache/total) > 15-05-2013-03-09.txt:58639/5621/64260 mbufs in use (current/cache/total) > 15-05-2013-04-09.txt:58581/5679/64260 mbufs in use (current/cache/total) > 15-05-2013-05-09.txt:58591/5669/64260 mbufs in use (current/cache/total) > 15-05-2013-06-09.txt:58602/5658/64260 mbufs in use (current/cache/total) > 15-05-2013-07-09.txt:58613/5647/64260 mbufs in use (current/cache/total) > 15-05-2013-08-09.txt:58623/6027/64650 mbufs in use (current/cache/total) > 15-05-2013-09-09.txt:58634/6016/64650 mbufs in use (current/cache/total) > 15-05-2013-10-09.txt:58645/6005/64650 mbufs in use (current/cache/total) > > > This increasing number of used mbuf_packets and mbufs in use makes me > nervous. > See the complete reports http://knownhosts.org:/reports-14-15.tgz > > Thanks for help, > > -dennis > > > > --------------BEGIN System information--------------- > It's a stock FreeBSD 9.1, yet the hostname is called freenas. Don't be > confused. > > > igb0: flags=3D8c02 metric 0 mtu 1500 > > options=3D401bb > ether 00:25:90:34:c1:12 > nd6 options=3D21 > media: Ethernet autoselect (1000baseT ) > status: active > igb1: flags=3D8843 metric 0 mtu 1= 500 > > options=3D401bb > ether 00:25:90:34:c1:13 > inet 172.16.1.6 netmask 0xfffff000 broadcast 172.16.15.255 > inet6 fe80::225:90ff:fe34:c113%igb1 prefixlen 64 scopeid 0x2 > nd6 options=3D21 > media: Ethernet autoselect (1000baseT ) > status: active > ix0: flags=3D8843 metric 0 mtu 90= 00 > > options=3D401bb > ether 00:1b:21:cc:12:8b > inet 10.254.254.242 netmask 0xfffffffc broadcast 10.254.254.243 > inet6 fe80::21b:21ff:fecc:128b%ix0 prefixlen 64 scopeid 0xb > nd6 options=3D21 > media: Ethernet autoselect (10Gbase-Twinax ) > status: active > ix1: flags=3D8843 metric 0 mtu 90= 00 > > options=3D401bb > ether 00:1b:21:cc:12:8a > inet 10.254.254.254 netmask 0xfffffffc broadcast 10.254.254.255 > inet6 fe80::21b:21ff:fecc:128a%ix1 prefixlen 64 scopeid 0xc > nd6 options=3D21 > media: Ethernet autoselect (10Gbase-Twinax ) > status: active > ix2: flags=3D8843 metric 0 mtu 90= 00 > > options=3D401bb > ether 00:1b:21:cc:12:b3 > inet 10.254.254.246 netmask 0xfffffffc broadcast 10.254.254.247 > inet6 fe80::21b:21ff:fecc:12b3%ix2 prefixlen 64 scopeid 0xd > nd6 options=3D21 > media: Ethernet autoselect > status: no carrier > ix3: flags=3D8802 metric 0 mtu 1500 > > options=3D401bb > ether 00:1b:21:cc:12:b2 > nd6 options=3D21 > media: Ethernet autoselect > status: no carrier > lo0: flags=3D8049 metric 0 mtu 16384 > options=3D600003 > inet6 ::1 prefixlen 128 > inet6 fe80::1%lo0 prefixlen 64 scopeid 0xf > inet 127.0.0.1 netmask 0xff000000 > nd6 options=3D21 > > #dmesg > =85.. > mfi0: 21294 (421879975s/0x0008/info) - Battery started charging > ix1: link state changed to DOWN > ix1: link state changed to UP > ix1: link state changed to DOWN > ix1: link state changed to UP > ix1: link state changed to DOWN > ix1: link state changed to UP > ix1: link state changed to DOWN > ix1: link state changed to UP > ix1: link state changed to DOWN > ix1: link state changed to UP > ix1: link state changed to DOWN > ix1: link state changed to UP > ix1: link state changed to DOWN > ix1: link state changed to UP > ix1: link state changed to DOWN > ix1: link state changed to UP > ix1: link state changed to DOWN > ix1: link state changed to UP > ix1: link state changed to DOWN > ix1: link state changed to UP > ix1: link state changed to DOWN > ix1: link state changed to UP > ix1: link state changed to DOWN > ix1: link state changed to UP > ix1: link state changed to DOWN > ix1: link state changed to UP > ix1: link state changed to DOWN > ix1: link state changed to UP > ix1: link state changed to DOWN > ix1: link state changed to UP > ix1: link state changed to DOWN > ix1: link state changed to UP > ix1: link state changed to DOWN > ix1: link state changed to UP > ix1: link state changed to DOWN > ix1: link state changed to UP > ix1: link state changed to DOWN > ix1: link state changed to UP > ix1: link state changed to DOWN > ix1: link state changed to UP > ix1: link state changed to DOWN > ix1: link state changed to UP > > > I should add that the servers that are directly connected to this freebsd > server reboot every night. This is why you see ix0 UP/DOWN > messages in dmesg. > > > > > > > ------------- END System information------------ > > > > _______________________________________________ > 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 May 15 20:14:26 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 1A105E13 for ; Wed, 15 May 2013 20:14:26 +0000 (UTC) (envelope-from db@nipsi.de) Received: from fop.bsdsystems.de (mx.bsdsystems.de [88.198.57.43]) by mx1.freebsd.org (Postfix) with ESMTP id E04B9908 for ; Wed, 15 May 2013 20:14:23 +0000 (UTC) Received: from [172.16.10.253] (d015075.adsl.hansenet.de [80.171.15.75]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by fop.bsdsystems.de (Postfix) with ESMTP id 7C82654C63; Wed, 15 May 2013 22:13:13 +0200 (CEST) Subject: Re: still mbuf leak in 9.0 / 9.1? Mime-Version: 1.0 (Apple Message framework v1085) From: dennis berger In-Reply-To: Date: Wed, 15 May 2013 22:13:04 +0200 Message-Id: <004BC6EA-D8E6-473E-851C-9CDA7578510A@nipsi.de> References: To: Jack Vogel X-Mailer: Apple Mail (2.1085) Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: FreeBSD stable X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 15 May 2013 20:14:26 -0000 Hi jack, so the increasing number of "mbufs in use" or mbuf clusters in use is = normal, you would say? jumbo frames are of size 9k. I know that they're from different pools, I = also checked that pool. nmb are: #cat loader.conf #tuning network hw.intr_storm_threshold=3D9000 kern.ipc.nmbclusters=3D262144 kern.ipc.nmbjumbop=3D262144 kern.ipc.nmbjumbo9=3D65536 kern.ipc.nmbjumbo16=3D32768 14-05-2013-14-09.txt:9246/4918/14164/262144 mbuf clusters in use = (current/cache/total/max) 14-05-2013-15-09.txt:9256/4856/14112/262144 mbuf clusters in use = (current/cache/total/max) 14-05-2013-16-09.txt:9266/4846/14112/262144 mbuf clusters in use = (current/cache/total/max) 14-05-2013-17-09.txt:9276/4836/14112/262144 mbuf clusters in use = (current/cache/total/max) 14-05-2013-18-09.txt:9286/4826/14112/262144 mbuf clusters in use = (current/cache/total/max) 14-05-2013-19-09.txt:9296/4734/14030/262144 mbuf clusters in use = (current/cache/total/max) 14-05-2013-20-09.txt:9306/4724/14030/262144 mbuf clusters in use = (current/cache/total/max) 14-05-2013-21-09.txt:9316/4714/14030/262144 mbuf clusters in use = (current/cache/total/max) 14-05-2013-22-09.txt:9326/4704/14030/262144 mbuf clusters in use = (current/cache/total/max) 14-05-2013-23-09.txt:9336/4694/14030/262144 mbuf clusters in use = (current/cache/total/max) 15-05-2013-00-09.txt:9346/4684/14030/262144 mbuf clusters in use = (current/cache/total/max) 15-05-2013-01-09.txt:9356/4674/14030/262144 mbuf clusters in use = (current/cache/total/max) 15-05-2013-02-09.txt:9366/4664/14030/262144 mbuf clusters in use = (current/cache/total/max) 15-05-2013-03-09.txt:9379/4279/13658/262144 mbuf clusters in use = (current/cache/total/max) 15-05-2013-04-09.txt:9384/4086/13470/262144 mbuf clusters in use = (current/cache/total/max) 15-05-2013-05-09.txt:9394/4076/13470/262144 mbuf clusters in use = (current/cache/total/max) 15-05-2013-06-09.txt:9404/4066/13470/262144 mbuf clusters in use = (current/cache/total/max) 15-05-2013-07-09.txt:9414/5040/14454/262144 mbuf clusters in use = (current/cache/total/max) 15-05-2013-08-09.txt:9424/5030/14454/262144 mbuf clusters in use = (current/cache/total/max) 15-05-2013-09-09.txt:9434/4898/14332/262144 mbuf clusters in use = (current/cache/total/max) 15-05-2013-10-09.txt:9444/4850/14294/262144 mbuf clusters in use = (current/cache/total/max) 15-05-2013-11-09.txt:9454/5000/14454/262144 mbuf clusters in use = (current/cache/total/max) 15-05-2013-12-09.txt:9464/4874/14338/262144 mbuf clusters in use = (current/cache/total/max) 15-05-2013-13-09.txt:9474/4856/14330/262144 mbuf clusters in use = (current/cache/total/max) 15-05-2013-14-09.txt:17674/4460/22134/262144 mbuf clusters in use = (current/cache/total/max) 15-05-2013-15-09.txt:17684/4450/22134/262144 mbuf clusters in use = (current/cache/total/max) 15-05-2013-16-09.txt:17694/4696/22390/262144 mbuf clusters in use = (current/cache/total/max) 15-05-2013-17-09.txt:17704/4686/22390/262144 mbuf clusters in use = (current/cache/total/max) 15-05-2013-18-09.txt:17714/4658/22372/262144 mbuf clusters in use = (current/cache/total/max) 15-05-2013-19-09.txt:17724/4648/22372/262144 mbuf clusters in use = (current/cache/total/max) 15-05-2013-20-09.txt:17734/4638/22372/262144 mbuf clusters in use = (current/cache/total/max) 15-05-2013-21-09.txt:17744/4628/22372/262144 mbuf clusters in use = (current/cache/total/max) Please see the link to http://knownhosts.org/reports-14-15.tgz in my = original post, there is the full information including 9k jumbo frames. it's the driver version 2.4.8 which should be from 9.1-release directly yes TWINAX is correct. I'll replace the driver with the latest one. best regards and thanks, dennis Am 15.05.2013 um 19:00 schrieb Jack Vogel: > So, you stop getting 10G transmission and so you are looking at mbuf = leaks? I don't see > anything in your data that makes it look like you've run out of = available mbufs. You said > you're running jumbos, what size? You do realize that if you do this = the clusters are coming > from different pools and you are not displaying those. What are all = your nmb limits set to? >=20 > So, this is 9.1 RELEASE, or stable? If you are using the driver from = release I would first off > suggest you test the code from HEAD. >=20 > What is the 10G device, I see its using Twinax, and I have been told = there is a problem at > times with those that is corrected in recent shared code, this is why = you should try the > latest code. >=20 > Cheers, >=20 > Jack >=20 >=20 >=20 > On Wed, May 15, 2013 at 2:00 AM, dennis berger wrote: > Hi list, > since we activated 10gbe on ixgbe cards + jumbo frames(9k) on 9.0 and = now on 9.1 we recognize that after a random period of time, sometimes a = week, sometimes only a day, the > system doesn't send any packets out. The phenomenon is that you can't = login via ssh, nfs and istgt is not operative. Yet you can login on the = console and execute commands. > A clean shutdown isn't possible though. It hangs after vnode cleaning, = normally you would see detaching of usb devices here, or other devices = maybe? > I've read the other post on this ML about mbuf leak in the arp = handling code in if_ether.c line 558. We don't see any of those notices = in dmesg so I don't think that glebius fix would apply for us. > I'm collecting system and memory information every hour. >=20 >=20 > Script looks like this. > less /etc/periodic/hourly/100.report-memory.sh > #!/bin/sh >=20 > reporttimestamp=3D`date +%d-%m-%Y-%H-%M` > reportname=3D${reporttimestamp}.txt >=20 > cd /root/memory-mon >=20 > top -b > $reportname > echo "" >> $reportname > vmstat -m >> $reportname > echo "" >> $reportname > vmstat -z >> $reportname > echo "" >> $reportname > netstat -Q >> $reportname > echo "" >> $reportname > netstat -n -x >> $reportname > echo "" >> $reportname > netstat -m >> $reportname > /usr/bin/perl /usr/local/bin/zfs-stats -a >> $reportname >=20 > When you grep for mbuf or mbuf usage you will see this for example: >=20 > root@freenas:/root/memory-mon # grep mbuf_packet: * > 14-05-2013-14-09.txt:mbuf_packet: 256, 0, 9246, = 2786,201700429, 0, 0 > 14-05-2013-15-09.txt:mbuf_packet: 256, 0, 9256, = 2776,201773122, 0, 0 > 14-05-2013-16-09.txt:mbuf_packet: 256, 0, 9266, = 2766,201871553, 0, 0 > 14-05-2013-17-09.txt:mbuf_packet: 256, 0, 9276, = 2756,201915405, 0, 0 > 14-05-2013-18-09.txt:mbuf_packet: 256, 0, 9286, = 2746,201927956, 0, 0 > 14-05-2013-19-09.txt:mbuf_packet: 256, 0, 9296, = 2352,201935681, 0, 0 > 14-05-2013-20-09.txt:mbuf_packet: 256, 0, 9306, = 2342,201943754, 0, 0 > 14-05-2013-21-09.txt:mbuf_packet: 256, 0, 9316, = 2332,201950961, 0, 0 > 14-05-2013-22-09.txt:mbuf_packet: 256, 0, 9326, = 2450,201958150, 0, 0 > 14-05-2013-23-09.txt:mbuf_packet: 256, 0, 9336, = 2440,201967178, 0, 0 > 15-05-2013-00-09.txt:mbuf_packet: 256, 0, 9346, = 2430,201974561, 0, 0 > 15-05-2013-01-09.txt:mbuf_packet: 256, 0, 9356, = 2420,201982105, 0, 0 > 15-05-2013-02-09.txt:mbuf_packet: 256, 0, 9366, = 2410,201989463, 0, 0 > 15-05-2013-03-09.txt:mbuf_packet: 256, 0, 9378, = 1502,203019168, 0, 0 > 15-05-2013-04-09.txt:mbuf_packet: 256, 0, 9384, = 1624,205953601, 0, 0 > 15-05-2013-05-09.txt:mbuf_packet: 256, 0, 9394, = 1870,205959258, 0, 0 > 15-05-2013-06-09.txt:mbuf_packet: 256, 0, 9404, = 2500,205969396, 0, 0 > 15-05-2013-07-09.txt:mbuf_packet: 256, 0, 9414, = 3386,207945161, 0, 0 > 15-05-2013-08-09.txt:mbuf_packet: 256, 0, 9424, = 3376,208094689, 0, 0 > 15-05-2013-09-09.txt:mbuf_packet: 256, 0, 9434, = 2982,208172465, 0, 0 > 15-05-2013-10-09.txt:mbuf_packet: 256, 0, 9444, = 3100,208270369, 0, 0 >=20 > and >=20 > root@freenas:/root/memory-mon # grep "mbufs in use" * > 14-05-2013-14-09.txt:58444/5816/64260 mbufs in use = (current/cache/total) > 14-05-2013-15-09.txt:58455/5805/64260 mbufs in use = (current/cache/total) > 14-05-2013-16-09.txt:58464/5796/64260 mbufs in use = (current/cache/total) > 14-05-2013-17-09.txt:58475/5785/64260 mbufs in use = (current/cache/total) > 14-05-2013-18-09.txt:58484/5776/64260 mbufs in use = (current/cache/total) > 14-05-2013-19-09.txt:58493/5767/64260 mbufs in use = (current/cache/total) > 14-05-2013-20-09.txt:58503/5757/64260 mbufs in use = (current/cache/total) > 14-05-2013-21-09.txt:58513/5747/64260 mbufs in use = (current/cache/total) > 14-05-2013-22-09.txt:58523/5737/64260 mbufs in use = (current/cache/total) > 14-05-2013-23-09.txt:58533/5727/64260 mbufs in use = (current/cache/total) > 15-05-2013-00-09.txt:58543/5717/64260 mbufs in use = (current/cache/total) > 15-05-2013-01-09.txt:58554/5706/64260 mbufs in use = (current/cache/total) > 15-05-2013-02-09.txt:58563/5697/64260 mbufs in use = (current/cache/total) > 15-05-2013-03-09.txt:58639/5621/64260 mbufs in use = (current/cache/total) > 15-05-2013-04-09.txt:58581/5679/64260 mbufs in use = (current/cache/total) > 15-05-2013-05-09.txt:58591/5669/64260 mbufs in use = (current/cache/total) > 15-05-2013-06-09.txt:58602/5658/64260 mbufs in use = (current/cache/total) > 15-05-2013-07-09.txt:58613/5647/64260 mbufs in use = (current/cache/total) > 15-05-2013-08-09.txt:58623/6027/64650 mbufs in use = (current/cache/total) > 15-05-2013-09-09.txt:58634/6016/64650 mbufs in use = (current/cache/total) > 15-05-2013-10-09.txt:58645/6005/64650 mbufs in use = (current/cache/total) >=20 >=20 > This increasing number of used mbuf_packets and mbufs in use makes me = nervous. > See the complete reports http://knownhosts.org:/reports-14-15.tgz >=20 > Thanks for help, >=20 > -dennis >=20 >=20 >=20 > --------------BEGIN System information--------------- > It's a stock FreeBSD 9.1, yet the hostname is called freenas. Don't be = confused. >=20 >=20 > igb0: flags=3D8c02 metric 0 mtu = 1500 > = options=3D401bb > ether 00:25:90:34:c1:12 > nd6 options=3D21 > media: Ethernet autoselect (1000baseT ) > status: active > igb1: flags=3D8843 metric 0 = mtu 1500 > = options=3D401bb > ether 00:25:90:34:c1:13 > inet 172.16.1.6 netmask 0xfffff000 broadcast 172.16.15.255 > inet6 fe80::225:90ff:fe34:c113%igb1 prefixlen 64 scopeid 0x2 > nd6 options=3D21 > media: Ethernet autoselect (1000baseT ) > status: active > ix0: flags=3D8843 metric 0 mtu = 9000 > = options=3D401bb > ether 00:1b:21:cc:12:8b > inet 10.254.254.242 netmask 0xfffffffc broadcast = 10.254.254.243 > inet6 fe80::21b:21ff:fecc:128b%ix0 prefixlen 64 scopeid 0xb > nd6 options=3D21 > media: Ethernet autoselect (10Gbase-Twinax ) > status: active > ix1: flags=3D8843 metric 0 mtu = 9000 > = options=3D401bb > ether 00:1b:21:cc:12:8a > inet 10.254.254.254 netmask 0xfffffffc broadcast = 10.254.254.255 > inet6 fe80::21b:21ff:fecc:128a%ix1 prefixlen 64 scopeid 0xc > nd6 options=3D21 > media: Ethernet autoselect (10Gbase-Twinax ) > status: active > ix2: flags=3D8843 metric 0 mtu = 9000 > = options=3D401bb > ether 00:1b:21:cc:12:b3 > inet 10.254.254.246 netmask 0xfffffffc broadcast = 10.254.254.247 > inet6 fe80::21b:21ff:fecc:12b3%ix2 prefixlen 64 scopeid 0xd > nd6 options=3D21 > media: Ethernet autoselect > status: no carrier > ix3: flags=3D8802 metric 0 mtu 1500 > = options=3D401bb > ether 00:1b:21:cc:12:b2 > nd6 options=3D21 > media: Ethernet autoselect > status: no carrier > lo0: flags=3D8049 metric 0 mtu 16384 > options=3D600003 > inet6 ::1 prefixlen 128 > inet6 fe80::1%lo0 prefixlen 64 scopeid 0xf > inet 127.0.0.1 netmask 0xff000000 > nd6 options=3D21 >=20 > #dmesg > =85.. > mfi0: 21294 (421879975s/0x0008/info) - Battery started charging > ix1: link state changed to DOWN > ix1: link state changed to UP > ix1: link state changed to DOWN > ix1: link state changed to UP > ix1: link state changed to DOWN > ix1: link state changed to UP > ix1: link state changed to DOWN > ix1: link state changed to UP > ix1: link state changed to DOWN > ix1: link state changed to UP > ix1: link state changed to DOWN > ix1: link state changed to UP > ix1: link state changed to DOWN > ix1: link state changed to UP > ix1: link state changed to DOWN > ix1: link state changed to UP > ix1: link state changed to DOWN > ix1: link state changed to UP > ix1: link state changed to DOWN > ix1: link state changed to UP > ix1: link state changed to DOWN > ix1: link state changed to UP > ix1: link state changed to DOWN > ix1: link state changed to UP > ix1: link state changed to DOWN > ix1: link state changed to UP > ix1: link state changed to DOWN > ix1: link state changed to UP > ix1: link state changed to DOWN > ix1: link state changed to UP > ix1: link state changed to DOWN > ix1: link state changed to UP > ix1: link state changed to DOWN > ix1: link state changed to UP > ix1: link state changed to DOWN > ix1: link state changed to UP > ix1: link state changed to DOWN > ix1: link state changed to UP > ix1: link state changed to DOWN > ix1: link state changed to UP > ix1: link state changed to DOWN > ix1: link state changed to UP >=20 >=20 > I should add that the servers that are directly connected to this = freebsd server reboot every night. This is why you see ix0 UP/DOWN > messages in dmesg. >=20 >=20 >=20 >=20 >=20 >=20 > ------------- END System information------------ >=20 >=20 >=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 Dipl.-Inform. (FH) Dennis Berger email: db@bsdsystems.de mobile: +491791231509 fon: +494054001817 From owner-freebsd-stable@FreeBSD.ORG Wed May 15 21:14:39 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 387FBF69 for ; Wed, 15 May 2013 21:14:39 +0000 (UTC) (envelope-from jdc@koitsu.org) Received: from qmta03.emeryville.ca.mail.comcast.net (qmta03.emeryville.ca.mail.comcast.net [IPv6:2001:558:fe2d:43:76:96:30:32]) by mx1.freebsd.org (Postfix) with ESMTP id 0E2D5B5D for ; Wed, 15 May 2013 21:14:39 +0000 (UTC) Received: from omta05.emeryville.ca.mail.comcast.net ([76.96.30.43]) by qmta03.emeryville.ca.mail.comcast.net with comcast id cDBF1l0030vp7WLA3MEefX; Wed, 15 May 2013 21:14:38 +0000 Received: from koitsu.strangled.net ([67.180.84.87]) by omta05.emeryville.ca.mail.comcast.net with comcast id cMEc1l00c1t3BNj8RMEdlc; Wed, 15 May 2013 21:14:37 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id 9DA4273A33; Wed, 15 May 2013 14:14:36 -0700 (PDT) Date: Wed, 15 May 2013 14:14:36 -0700 From: Jeremy Chadwick To: dennis berger Subject: Re: still mbuf leak in 9.0 / 9.1? Message-ID: <20130515211436.GA42790@icarus.home.lan> References: <004BC6EA-D8E6-473E-851C-9CDA7578510A@nipsi.de> MIME-Version: 1.0 Content-Type: text/plain; charset=unknown-8bit Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <004BC6EA-D8E6-473E-851C-9CDA7578510A@nipsi.de> User-Agent: Mutt/1.5.21 (2010-09-15) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1368652478; bh=c7prFNXjhZem9uCHH9FbegMuijy7OPezY7yhtJrdnGs=; h=Received:Received:Received:Date:From:To:Subject:Message-ID: MIME-Version:Content-Type; b=aLspMfDFhmeaqfAuA6pWXQeM7LkGpDwaTpkfgDZsBzUDs7KT24YZjH4cgklxzepCT uVVheKdMNyXN3gvEhp9jQeWAy1X15FiPSFfR1X7aNU9uoTSDBXEc82Qy8Zay4+uzbR fPPlcaga19/gf4MkUz4XGkN544ml4wral3wC8kxwPJQsf6OTDKpT6nBYB8tnesbYDs NspI5ixjXZGZVJkF6izy6zNbwggR+fAxi2zcnGCIDNQVgsKnjCQdUycIa852IS8QsW Gx4HsiEOqXzcI5bKygS90oRXIaY4U/Yvl8u3FqeqRctR0bT+wiANGC2QFOv5Xl5rqD kPQ1ftyMo41cQ== Cc: FreeBSD stable , Jack Vogel X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 15 May 2013 21:14:39 -0000 On Wed, May 15, 2013 at 10:13:04PM +0200, dennis berger wrote: > Hi jack, > > so the increasing number of "mbufs in use" or mbuf clusters in use is normal, you would say? > jumbo frames are of size 9k. I know that they're from different pools, I also checked that pool. > nmb are: > > #cat loader.conf > > #tuning network > hw.intr_storm_threshold=9000 > kern.ipc.nmbclusters=262144 > kern.ipc.nmbjumbop=262144 > kern.ipc.nmbjumbo9=65536 > kern.ipc.nmbjumbo16=32768 > > > 14-05-2013-14-09.txt:9246/4918/14164/262144 mbuf clusters in use (current/cache/total/max) > 14-05-2013-15-09.txt:9256/4856/14112/262144 mbuf clusters in use (current/cache/total/max) > 14-05-2013-16-09.txt:9266/4846/14112/262144 mbuf clusters in use (current/cache/total/max) > 14-05-2013-17-09.txt:9276/4836/14112/262144 mbuf clusters in use (current/cache/total/max) > 14-05-2013-18-09.txt:9286/4826/14112/262144 mbuf clusters in use (current/cache/total/max) > 14-05-2013-19-09.txt:9296/4734/14030/262144 mbuf clusters in use (current/cache/total/max) > 14-05-2013-20-09.txt:9306/4724/14030/262144 mbuf clusters in use (current/cache/total/max) > 14-05-2013-21-09.txt:9316/4714/14030/262144 mbuf clusters in use (current/cache/total/max) > 14-05-2013-22-09.txt:9326/4704/14030/262144 mbuf clusters in use (current/cache/total/max) > 14-05-2013-23-09.txt:9336/4694/14030/262144 mbuf clusters in use (current/cache/total/max) > 15-05-2013-00-09.txt:9346/4684/14030/262144 mbuf clusters in use (current/cache/total/max) > 15-05-2013-01-09.txt:9356/4674/14030/262144 mbuf clusters in use (current/cache/total/max) > 15-05-2013-02-09.txt:9366/4664/14030/262144 mbuf clusters in use (current/cache/total/max) > 15-05-2013-03-09.txt:9379/4279/13658/262144 mbuf clusters in use (current/cache/total/max) > 15-05-2013-04-09.txt:9384/4086/13470/262144 mbuf clusters in use (current/cache/total/max) > 15-05-2013-05-09.txt:9394/4076/13470/262144 mbuf clusters in use (current/cache/total/max) > 15-05-2013-06-09.txt:9404/4066/13470/262144 mbuf clusters in use (current/cache/total/max) > 15-05-2013-07-09.txt:9414/5040/14454/262144 mbuf clusters in use (current/cache/total/max) > 15-05-2013-08-09.txt:9424/5030/14454/262144 mbuf clusters in use (current/cache/total/max) > 15-05-2013-09-09.txt:9434/4898/14332/262144 mbuf clusters in use (current/cache/total/max) > 15-05-2013-10-09.txt:9444/4850/14294/262144 mbuf clusters in use (current/cache/total/max) > 15-05-2013-11-09.txt:9454/5000/14454/262144 mbuf clusters in use (current/cache/total/max) > 15-05-2013-12-09.txt:9464/4874/14338/262144 mbuf clusters in use (current/cache/total/max) > 15-05-2013-13-09.txt:9474/4856/14330/262144 mbuf clusters in use (current/cache/total/max) > 15-05-2013-14-09.txt:17674/4460/22134/262144 mbuf clusters in use (current/cache/total/max) > 15-05-2013-15-09.txt:17684/4450/22134/262144 mbuf clusters in use (current/cache/total/max) > 15-05-2013-16-09.txt:17694/4696/22390/262144 mbuf clusters in use (current/cache/total/max) > 15-05-2013-17-09.txt:17704/4686/22390/262144 mbuf clusters in use (current/cache/total/max) > 15-05-2013-18-09.txt:17714/4658/22372/262144 mbuf clusters in use (current/cache/total/max) > 15-05-2013-19-09.txt:17724/4648/22372/262144 mbuf clusters in use (current/cache/total/max) > 15-05-2013-20-09.txt:17734/4638/22372/262144 mbuf clusters in use (current/cache/total/max) > 15-05-2013-21-09.txt:17744/4628/22372/262144 mbuf clusters in use (current/cache/total/max) > > Please see the link to http://knownhosts.org/reports-14-15.tgz in my original post, there is the full information including 9k jumbo frames. > > it's the driver version 2.4.8 which should be from 9.1-release directly > yes TWINAX is correct. > > I'll replace the driver with the latest one. > > best regards and thanks, > dennis > > > Am 15.05.2013 um 19:00 schrieb Jack Vogel: > > > So, you stop getting 10G transmission and so you are looking at mbuf leaks? I don't see > > anything in your data that makes it look like you've run out of available mbufs. You said > > you're running jumbos, what size? You do realize that if you do this the clusters are coming > > from different pools and you are not displaying those. What are all your nmb limits set to? > > > > So, this is 9.1 RELEASE, or stable? If you are using the driver from release I would first off > > suggest you test the code from HEAD. > > > > What is the 10G device, I see its using Twinax, and I have been told there is a problem at > > times with those that is corrected in recent shared code, this is why you should try the > > latest code. > > > > Cheers, > > > > Jack > > > > > > > > On Wed, May 15, 2013 at 2:00 AM, dennis berger wrote: > > Hi list, > > since we activated 10gbe on ixgbe cards + jumbo frames(9k) on 9.0 and now on 9.1 we recognize that after a random period of time, sometimes a week, sometimes only a day, the > > system doesn't send any packets out. The phenomenon is that you can't login via ssh, nfs and istgt is not operative. Yet you can login on the console and execute commands. > > A clean shutdown isn't possible though. It hangs after vnode cleaning, normally you would see detaching of usb devices here, or other devices maybe? > > I've read the other post on this ML about mbuf leak in the arp handling code in if_ether.c line 558. We don't see any of those notices in dmesg so I don't think that glebius fix would apply for us. > > I'm collecting system and memory information every hour. > > > > > > Script looks like this. > > less /etc/periodic/hourly/100.report-memory.sh > > #!/bin/sh > > > > reporttimestamp=`date +%d-%m-%Y-%H-%M` > > reportname=${reporttimestamp}.txt > > > > cd /root/memory-mon > > > > top -b > $reportname > > echo "" >> $reportname > > vmstat -m >> $reportname > > echo "" >> $reportname > > vmstat -z >> $reportname > > echo "" >> $reportname > > netstat -Q >> $reportname > > echo "" >> $reportname > > netstat -n -x >> $reportname > > echo "" >> $reportname > > netstat -m >> $reportname > > /usr/bin/perl /usr/local/bin/zfs-stats -a >> $reportname > > > > When you grep for mbuf or mbuf usage you will see this for example: > > > > root@freenas:/root/memory-mon # grep mbuf_packet: * > > 14-05-2013-14-09.txt:mbuf_packet: 256, 0, 9246, 2786,201700429, 0, 0 > > 14-05-2013-15-09.txt:mbuf_packet: 256, 0, 9256, 2776,201773122, 0, 0 > > 14-05-2013-16-09.txt:mbuf_packet: 256, 0, 9266, 2766,201871553, 0, 0 > > 14-05-2013-17-09.txt:mbuf_packet: 256, 0, 9276, 2756,201915405, 0, 0 > > 14-05-2013-18-09.txt:mbuf_packet: 256, 0, 9286, 2746,201927956, 0, 0 > > 14-05-2013-19-09.txt:mbuf_packet: 256, 0, 9296, 2352,201935681, 0, 0 > > 14-05-2013-20-09.txt:mbuf_packet: 256, 0, 9306, 2342,201943754, 0, 0 > > 14-05-2013-21-09.txt:mbuf_packet: 256, 0, 9316, 2332,201950961, 0, 0 > > 14-05-2013-22-09.txt:mbuf_packet: 256, 0, 9326, 2450,201958150, 0, 0 > > 14-05-2013-23-09.txt:mbuf_packet: 256, 0, 9336, 2440,201967178, 0, 0 > > 15-05-2013-00-09.txt:mbuf_packet: 256, 0, 9346, 2430,201974561, 0, 0 > > 15-05-2013-01-09.txt:mbuf_packet: 256, 0, 9356, 2420,201982105, 0, 0 > > 15-05-2013-02-09.txt:mbuf_packet: 256, 0, 9366, 2410,201989463, 0, 0 > > 15-05-2013-03-09.txt:mbuf_packet: 256, 0, 9378, 1502,203019168, 0, 0 > > 15-05-2013-04-09.txt:mbuf_packet: 256, 0, 9384, 1624,205953601, 0, 0 > > 15-05-2013-05-09.txt:mbuf_packet: 256, 0, 9394, 1870,205959258, 0, 0 > > 15-05-2013-06-09.txt:mbuf_packet: 256, 0, 9404, 2500,205969396, 0, 0 > > 15-05-2013-07-09.txt:mbuf_packet: 256, 0, 9414, 3386,207945161, 0, 0 > > 15-05-2013-08-09.txt:mbuf_packet: 256, 0, 9424, 3376,208094689, 0, 0 > > 15-05-2013-09-09.txt:mbuf_packet: 256, 0, 9434, 2982,208172465, 0, 0 > > 15-05-2013-10-09.txt:mbuf_packet: 256, 0, 9444, 3100,208270369, 0, 0 > > > > and > > > > root@freenas:/root/memory-mon # grep "mbufs in use" * > > 14-05-2013-14-09.txt:58444/5816/64260 mbufs in use (current/cache/total) > > 14-05-2013-15-09.txt:58455/5805/64260 mbufs in use (current/cache/total) > > 14-05-2013-16-09.txt:58464/5796/64260 mbufs in use (current/cache/total) > > 14-05-2013-17-09.txt:58475/5785/64260 mbufs in use (current/cache/total) > > 14-05-2013-18-09.txt:58484/5776/64260 mbufs in use (current/cache/total) > > 14-05-2013-19-09.txt:58493/5767/64260 mbufs in use (current/cache/total) > > 14-05-2013-20-09.txt:58503/5757/64260 mbufs in use (current/cache/total) > > 14-05-2013-21-09.txt:58513/5747/64260 mbufs in use (current/cache/total) > > 14-05-2013-22-09.txt:58523/5737/64260 mbufs in use (current/cache/total) > > 14-05-2013-23-09.txt:58533/5727/64260 mbufs in use (current/cache/total) > > 15-05-2013-00-09.txt:58543/5717/64260 mbufs in use (current/cache/total) > > 15-05-2013-01-09.txt:58554/5706/64260 mbufs in use (current/cache/total) > > 15-05-2013-02-09.txt:58563/5697/64260 mbufs in use (current/cache/total) > > 15-05-2013-03-09.txt:58639/5621/64260 mbufs in use (current/cache/total) > > 15-05-2013-04-09.txt:58581/5679/64260 mbufs in use (current/cache/total) > > 15-05-2013-05-09.txt:58591/5669/64260 mbufs in use (current/cache/total) > > 15-05-2013-06-09.txt:58602/5658/64260 mbufs in use (current/cache/total) > > 15-05-2013-07-09.txt:58613/5647/64260 mbufs in use (current/cache/total) > > 15-05-2013-08-09.txt:58623/6027/64650 mbufs in use (current/cache/total) > > 15-05-2013-09-09.txt:58634/6016/64650 mbufs in use (current/cache/total) > > 15-05-2013-10-09.txt:58645/6005/64650 mbufs in use (current/cache/total) > > > > > > This increasing number of used mbuf_packets and mbufs in use makes me nervous. > > See the complete reports http://knownhosts.org:/reports-14-15.tgz > > > > Thanks for help, > > > > -dennis > > > > > > > > --------------BEGIN System information--------------- > > It's a stock FreeBSD 9.1, yet the hostname is called freenas. Don't be confused. > > > > > > igb0: flags=8c02 metric 0 mtu 1500 > > options=401bb > > ether 00:25:90:34:c1:12 > > nd6 options=21 > > media: Ethernet autoselect (1000baseT ) > > status: active > > igb1: flags=8843 metric 0 mtu 1500 > > options=401bb > > ether 00:25:90:34:c1:13 > > inet 172.16.1.6 netmask 0xfffff000 broadcast 172.16.15.255 > > inet6 fe80::225:90ff:fe34:c113%igb1 prefixlen 64 scopeid 0x2 > > nd6 options=21 > > media: Ethernet autoselect (1000baseT ) > > status: active > > ix0: flags=8843 metric 0 mtu 9000 > > options=401bb > > ether 00:1b:21:cc:12:8b > > inet 10.254.254.242 netmask 0xfffffffc broadcast 10.254.254.243 > > inet6 fe80::21b:21ff:fecc:128b%ix0 prefixlen 64 scopeid 0xb > > nd6 options=21 > > media: Ethernet autoselect (10Gbase-Twinax ) > > status: active > > ix1: flags=8843 metric 0 mtu 9000 > > options=401bb > > ether 00:1b:21:cc:12:8a > > inet 10.254.254.254 netmask 0xfffffffc broadcast 10.254.254.255 > > inet6 fe80::21b:21ff:fecc:128a%ix1 prefixlen 64 scopeid 0xc > > nd6 options=21 > > media: Ethernet autoselect (10Gbase-Twinax ) > > status: active > > ix2: flags=8843 metric 0 mtu 9000 > > options=401bb > > ether 00:1b:21:cc:12:b3 > > inet 10.254.254.246 netmask 0xfffffffc broadcast 10.254.254.247 > > inet6 fe80::21b:21ff:fecc:12b3%ix2 prefixlen 64 scopeid 0xd > > nd6 options=21 > > media: Ethernet autoselect > > status: no carrier > > ix3: flags=8802 metric 0 mtu 1500 > > options=401bb > > ether 00:1b:21:cc:12:b2 > > nd6 options=21 > > media: Ethernet autoselect > > status: no carrier > > lo0: flags=8049 metric 0 mtu 16384 > > options=600003 > > inet6 ::1 prefixlen 128 > > inet6 fe80::1%lo0 prefixlen 64 scopeid 0xf > > inet 127.0.0.1 netmask 0xff000000 > > nd6 options=21 > > > > #dmesg > > ….. > > mfi0: 21294 (421879975s/0x0008/info) - Battery started charging > > ix1: link state changed to DOWN > > ix1: link state changed to UP > > ix1: link state changed to DOWN > > ix1: link state changed to UP > > ix1: link state changed to DOWN > > ix1: link state changed to UP > > ix1: link state changed to DOWN > > ix1: link state changed to UP > > ix1: link state changed to DOWN > > ix1: link state changed to UP > > ix1: link state changed to DOWN > > ix1: link state changed to UP > > ix1: link state changed to DOWN > > ix1: link state changed to UP > > ix1: link state changed to DOWN > > ix1: link state changed to UP > > ix1: link state changed to DOWN > > ix1: link state changed to UP > > ix1: link state changed to DOWN > > ix1: link state changed to UP > > ix1: link state changed to DOWN > > ix1: link state changed to UP > > ix1: link state changed to DOWN > > ix1: link state changed to UP > > ix1: link state changed to DOWN > > ix1: link state changed to UP > > ix1: link state changed to DOWN > > ix1: link state changed to UP > > ix1: link state changed to DOWN > > ix1: link state changed to UP > > ix1: link state changed to DOWN > > ix1: link state changed to UP > > ix1: link state changed to DOWN > > ix1: link state changed to UP > > ix1: link state changed to DOWN > > ix1: link state changed to UP > > ix1: link state changed to DOWN > > ix1: link state changed to UP > > ix1: link state changed to DOWN > > ix1: link state changed to UP > > ix1: link state changed to DOWN > > ix1: link state changed to UP > > > > > > I should add that the servers that are directly connected to this freebsd server reboot every night. This is why you see ix0 UP/DOWN > > messages in dmesg. > > > > > > > > > > > > > > ------------- END System information------------ 1. You appear convinced that the issue is related to mbuf exhaustion, but you haven't provided evidence that you're hitting the mbuf maximum (in your case 262144). What you *have* shown is your mbuf count gradually increasing (sans 15-05-2013-13-09.txt vs. 15-05-2013-14-09.txt which shows mbufs almost doubling (!)), which could indicate a leak but then again might not. If you reach mbuf maximum, then yes, network I/O can cease or stall (possibly indefinitely). However, broken/busted network I/O can also happen due to other issues unrelated to mbufs, such as network stack issues, firewall stack issues, or network driver bugs. Are you using pf, ipfw, or ipfilter on this system? 2. I think we'd all appreciate if you disclosed **exactly** what version of FreeBSD you're using (Subject says "9.0 or 9.1" which is insufficient). Please provide "uname -a" output (you can XXX out the hostname if you want) -- and if you're still using csup/cvsup and built your own kernel/world, we'll need to know exactly what date your src files were from when you rebuilt. I'm wary of CC'ing folks who can help troubleshoot mbuf exhaustion issues until answers to the above can be provided, as I don't want to waste their time. 3. Regarding this: > > A clean shutdown isn't possible though. It hangs after vnode > > cleaning, normally you would see detaching of usb devices here, or > > other devices maybe? Please don't conflate this with your above issue. This is almost certainly unrelated. Please start a new thread about that if desired. -- | Jeremy Chadwick jdc@koitsu.org | | UNIX Systems Administrator http://jdc.koitsu.org/ | | Mountain View, CA, US | | Making life hard for others since 1977. PGP 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Wed May 15 21:47:22 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 880B1BB6 for ; Wed, 15 May 2013 21:47:22 +0000 (UTC) (envelope-from db@nipsi.de) Received: from fop.bsdsystems.de (mx.bsdsystems.de [88.198.57.43]) by mx1.freebsd.org (Postfix) with ESMTP id 5712ED93 for ; Wed, 15 May 2013 21:47:20 +0000 (UTC) Received: from [172.16.10.253] (d015075.adsl.hansenet.de [80.171.15.75]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by fop.bsdsystems.de (Postfix) with ESMTP id A8C3054C7C; Wed, 15 May 2013 23:47:18 +0200 (CEST) Subject: Re: still mbuf leak in 9.0 / 9.1? Mime-Version: 1.0 (Apple Message framework v1085) From: dennis berger In-Reply-To: <20130515211436.GA42790@icarus.home.lan> Date: Wed, 15 May 2013 23:47:17 +0200 Message-Id: <696B5622-A95D-4187-A027-07ECC9B5AD1F@nipsi.de> References: <004BC6EA-D8E6-473E-851C-9CDA7578510A@nipsi.de> <20130515211436.GA42790@icarus.home.lan> To: Jeremy Chadwick X-Mailer: Apple Mail (2.1085) Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: FreeBSD stable , Jack Vogel X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 15 May 2013 21:47:22 -0000 Am 15.05.2013 um 23:14 schrieb Jeremy Chadwick: > On Wed, May 15, 2013 at 10:13:04PM +0200, dennis berger wrote: >> Hi jack, >>=20 >> so the increasing number of "mbufs in use" or mbuf clusters in use is = normal, you would say? >> jumbo frames are of size 9k. I know that they're from different = pools, I also checked that pool. >> nmb are: >>=20 >> #cat loader.conf >>=20 >> #tuning network >> hw.intr_storm_threshold=3D9000 >> kern.ipc.nmbclusters=3D262144 >> kern.ipc.nmbjumbop=3D262144 >> kern.ipc.nmbjumbo9=3D65536 >> kern.ipc.nmbjumbo16=3D32768 >>=20 >>=20 >> 14-05-2013-14-09.txt:9246/4918/14164/262144 mbuf clusters in use = (current/cache/total/max) >> 14-05-2013-15-09.txt:9256/4856/14112/262144 mbuf clusters in use = (current/cache/total/max) >> 14-05-2013-16-09.txt:9266/4846/14112/262144 mbuf clusters in use = (current/cache/total/max) >> 14-05-2013-17-09.txt:9276/4836/14112/262144 mbuf clusters in use = (current/cache/total/max) >> 14-05-2013-18-09.txt:9286/4826/14112/262144 mbuf clusters in use = (current/cache/total/max) >> 14-05-2013-19-09.txt:9296/4734/14030/262144 mbuf clusters in use = (current/cache/total/max) >> 14-05-2013-20-09.txt:9306/4724/14030/262144 mbuf clusters in use = (current/cache/total/max) >> 14-05-2013-21-09.txt:9316/4714/14030/262144 mbuf clusters in use = (current/cache/total/max) >> 14-05-2013-22-09.txt:9326/4704/14030/262144 mbuf clusters in use = (current/cache/total/max) >> 14-05-2013-23-09.txt:9336/4694/14030/262144 mbuf clusters in use = (current/cache/total/max) >> 15-05-2013-00-09.txt:9346/4684/14030/262144 mbuf clusters in use = (current/cache/total/max) >> 15-05-2013-01-09.txt:9356/4674/14030/262144 mbuf clusters in use = (current/cache/total/max) >> 15-05-2013-02-09.txt:9366/4664/14030/262144 mbuf clusters in use = (current/cache/total/max) >> 15-05-2013-03-09.txt:9379/4279/13658/262144 mbuf clusters in use = (current/cache/total/max) >> 15-05-2013-04-09.txt:9384/4086/13470/262144 mbuf clusters in use = (current/cache/total/max) >> 15-05-2013-05-09.txt:9394/4076/13470/262144 mbuf clusters in use = (current/cache/total/max) >> 15-05-2013-06-09.txt:9404/4066/13470/262144 mbuf clusters in use = (current/cache/total/max) >> 15-05-2013-07-09.txt:9414/5040/14454/262144 mbuf clusters in use = (current/cache/total/max) >> 15-05-2013-08-09.txt:9424/5030/14454/262144 mbuf clusters in use = (current/cache/total/max) >> 15-05-2013-09-09.txt:9434/4898/14332/262144 mbuf clusters in use = (current/cache/total/max) >> 15-05-2013-10-09.txt:9444/4850/14294/262144 mbuf clusters in use = (current/cache/total/max) >> 15-05-2013-11-09.txt:9454/5000/14454/262144 mbuf clusters in use = (current/cache/total/max) >> 15-05-2013-12-09.txt:9464/4874/14338/262144 mbuf clusters in use = (current/cache/total/max) >> 15-05-2013-13-09.txt:9474/4856/14330/262144 mbuf clusters in use = (current/cache/total/max) >> 15-05-2013-14-09.txt:17674/4460/22134/262144 mbuf clusters in use = (current/cache/total/max) >> 15-05-2013-15-09.txt:17684/4450/22134/262144 mbuf clusters in use = (current/cache/total/max) >> 15-05-2013-16-09.txt:17694/4696/22390/262144 mbuf clusters in use = (current/cache/total/max) >> 15-05-2013-17-09.txt:17704/4686/22390/262144 mbuf clusters in use = (current/cache/total/max) >> 15-05-2013-18-09.txt:17714/4658/22372/262144 mbuf clusters in use = (current/cache/total/max) >> 15-05-2013-19-09.txt:17724/4648/22372/262144 mbuf clusters in use = (current/cache/total/max) >> 15-05-2013-20-09.txt:17734/4638/22372/262144 mbuf clusters in use = (current/cache/total/max) >> 15-05-2013-21-09.txt:17744/4628/22372/262144 mbuf clusters in use = (current/cache/total/max) >>=20 >> Please see the link to http://knownhosts.org/reports-14-15.tgz in my = original post, there is the full information including 9k jumbo frames. >>=20 >> it's the driver version 2.4.8 which should be from 9.1-release = directly >> yes TWINAX is correct. >>=20 >> I'll replace the driver with the latest one. >>=20 >> best regards and thanks, >> dennis >>=20 >>=20 >> Am 15.05.2013 um 19:00 schrieb Jack Vogel: >>=20 >>> So, you stop getting 10G transmission and so you are looking at mbuf = leaks? I don't see >>> anything in your data that makes it look like you've run out of = available mbufs. You said >>> you're running jumbos, what size? You do realize that if you do this = the clusters are coming >>> from different pools and you are not displaying those. What are all = your nmb limits set to? >>>=20 >>> So, this is 9.1 RELEASE, or stable? If you are using the driver from = release I would first off >>> suggest you test the code from HEAD. >>>=20 >>> What is the 10G device, I see its using Twinax, and I have been told = there is a problem at >>> times with those that is corrected in recent shared code, this is = why you should try the >>> latest code. >>>=20 >>> Cheers, >>>=20 >>> Jack >>>=20 >>>=20 >>>=20 >>> On Wed, May 15, 2013 at 2:00 AM, dennis berger wrote: >>> Hi list, >>> since we activated 10gbe on ixgbe cards + jumbo frames(9k) on 9.0 = and now on 9.1 we recognize that after a random period of time, = sometimes a week, sometimes only a day, the >>> system doesn't send any packets out. The phenomenon is that you = can't login via ssh, nfs and istgt is not operative. Yet you can login = on the console and execute commands. >>> A clean shutdown isn't possible though. It hangs after vnode = cleaning, normally you would see detaching of usb devices here, or other = devices maybe? >>> I've read the other post on this ML about mbuf leak in the arp = handling code in if_ether.c line 558. We don't see any of those notices = in dmesg so I don't think that glebius fix would apply for us. >>> I'm collecting system and memory information every hour. >>>=20 >>>=20 >>> Script looks like this. >>> less /etc/periodic/hourly/100.report-memory.sh >>> #!/bin/sh >>>=20 >>> reporttimestamp=3D`date +%d-%m-%Y-%H-%M` >>> reportname=3D${reporttimestamp}.txt >>>=20 >>> cd /root/memory-mon >>>=20 >>> top -b > $reportname >>> echo "" >> $reportname >>> vmstat -m >> $reportname >>> echo "" >> $reportname >>> vmstat -z >> $reportname >>> echo "" >> $reportname >>> netstat -Q >> $reportname >>> echo "" >> $reportname >>> netstat -n -x >> $reportname >>> echo "" >> $reportname >>> netstat -m >> $reportname >>> /usr/bin/perl /usr/local/bin/zfs-stats -a >> $reportname >>>=20 >>> When you grep for mbuf or mbuf usage you will see this for example: >>>=20 >>> root@freenas:/root/memory-mon # grep mbuf_packet: * >>> 14-05-2013-14-09.txt:mbuf_packet: 256, 0, 9246, = 2786,201700429, 0, 0 >>> 14-05-2013-15-09.txt:mbuf_packet: 256, 0, 9256, = 2776,201773122, 0, 0 >>> 14-05-2013-16-09.txt:mbuf_packet: 256, 0, 9266, = 2766,201871553, 0, 0 >>> 14-05-2013-17-09.txt:mbuf_packet: 256, 0, 9276, = 2756,201915405, 0, 0 >>> 14-05-2013-18-09.txt:mbuf_packet: 256, 0, 9286, = 2746,201927956, 0, 0 >>> 14-05-2013-19-09.txt:mbuf_packet: 256, 0, 9296, = 2352,201935681, 0, 0 >>> 14-05-2013-20-09.txt:mbuf_packet: 256, 0, 9306, = 2342,201943754, 0, 0 >>> 14-05-2013-21-09.txt:mbuf_packet: 256, 0, 9316, = 2332,201950961, 0, 0 >>> 14-05-2013-22-09.txt:mbuf_packet: 256, 0, 9326, = 2450,201958150, 0, 0 >>> 14-05-2013-23-09.txt:mbuf_packet: 256, 0, 9336, = 2440,201967178, 0, 0 >>> 15-05-2013-00-09.txt:mbuf_packet: 256, 0, 9346, = 2430,201974561, 0, 0 >>> 15-05-2013-01-09.txt:mbuf_packet: 256, 0, 9356, = 2420,201982105, 0, 0 >>> 15-05-2013-02-09.txt:mbuf_packet: 256, 0, 9366, = 2410,201989463, 0, 0 >>> 15-05-2013-03-09.txt:mbuf_packet: 256, 0, 9378, = 1502,203019168, 0, 0 >>> 15-05-2013-04-09.txt:mbuf_packet: 256, 0, 9384, = 1624,205953601, 0, 0 >>> 15-05-2013-05-09.txt:mbuf_packet: 256, 0, 9394, = 1870,205959258, 0, 0 >>> 15-05-2013-06-09.txt:mbuf_packet: 256, 0, 9404, = 2500,205969396, 0, 0 >>> 15-05-2013-07-09.txt:mbuf_packet: 256, 0, 9414, = 3386,207945161, 0, 0 >>> 15-05-2013-08-09.txt:mbuf_packet: 256, 0, 9424, = 3376,208094689, 0, 0 >>> 15-05-2013-09-09.txt:mbuf_packet: 256, 0, 9434, = 2982,208172465, 0, 0 >>> 15-05-2013-10-09.txt:mbuf_packet: 256, 0, 9444, = 3100,208270369, 0, 0 >>>=20 >>> and >>>=20 >>> root@freenas:/root/memory-mon # grep "mbufs in use" * >>> 14-05-2013-14-09.txt:58444/5816/64260 mbufs in use = (current/cache/total) >>> 14-05-2013-15-09.txt:58455/5805/64260 mbufs in use = (current/cache/total) >>> 14-05-2013-16-09.txt:58464/5796/64260 mbufs in use = (current/cache/total) >>> 14-05-2013-17-09.txt:58475/5785/64260 mbufs in use = (current/cache/total) >>> 14-05-2013-18-09.txt:58484/5776/64260 mbufs in use = (current/cache/total) >>> 14-05-2013-19-09.txt:58493/5767/64260 mbufs in use = (current/cache/total) >>> 14-05-2013-20-09.txt:58503/5757/64260 mbufs in use = (current/cache/total) >>> 14-05-2013-21-09.txt:58513/5747/64260 mbufs in use = (current/cache/total) >>> 14-05-2013-22-09.txt:58523/5737/64260 mbufs in use = (current/cache/total) >>> 14-05-2013-23-09.txt:58533/5727/64260 mbufs in use = (current/cache/total) >>> 15-05-2013-00-09.txt:58543/5717/64260 mbufs in use = (current/cache/total) >>> 15-05-2013-01-09.txt:58554/5706/64260 mbufs in use = (current/cache/total) >>> 15-05-2013-02-09.txt:58563/5697/64260 mbufs in use = (current/cache/total) >>> 15-05-2013-03-09.txt:58639/5621/64260 mbufs in use = (current/cache/total) >>> 15-05-2013-04-09.txt:58581/5679/64260 mbufs in use = (current/cache/total) >>> 15-05-2013-05-09.txt:58591/5669/64260 mbufs in use = (current/cache/total) >>> 15-05-2013-06-09.txt:58602/5658/64260 mbufs in use = (current/cache/total) >>> 15-05-2013-07-09.txt:58613/5647/64260 mbufs in use = (current/cache/total) >>> 15-05-2013-08-09.txt:58623/6027/64650 mbufs in use = (current/cache/total) >>> 15-05-2013-09-09.txt:58634/6016/64650 mbufs in use = (current/cache/total) >>> 15-05-2013-10-09.txt:58645/6005/64650 mbufs in use = (current/cache/total) >>>=20 >>>=20 >>> This increasing number of used mbuf_packets and mbufs in use makes = me nervous. >>> See the complete reports http://knownhosts.org:/reports-14-15.tgz >>>=20 >>> Thanks for help, >>>=20 >>> -dennis >>>=20 >>>=20 >>>=20 >>> --------------BEGIN System information--------------- >>> It's a stock FreeBSD 9.1, yet the hostname is called freenas. Don't = be confused. >>>=20 >>>=20 >>> igb0: flags=3D8c02 metric 0 mtu = 1500 >>> = options=3D401bb >>> ether 00:25:90:34:c1:12 >>> nd6 options=3D21 >>> media: Ethernet autoselect (1000baseT ) >>> status: active >>> igb1: flags=3D8843 metric 0 = mtu 1500 >>> = options=3D401bb >>> ether 00:25:90:34:c1:13 >>> inet 172.16.1.6 netmask 0xfffff000 broadcast 172.16.15.255 >>> inet6 fe80::225:90ff:fe34:c113%igb1 prefixlen 64 scopeid 0x2 >>> nd6 options=3D21 >>> media: Ethernet autoselect (1000baseT ) >>> status: active >>> ix0: flags=3D8843 metric 0 = mtu 9000 >>> = options=3D401bb >>> ether 00:1b:21:cc:12:8b >>> inet 10.254.254.242 netmask 0xfffffffc broadcast = 10.254.254.243 >>> inet6 fe80::21b:21ff:fecc:128b%ix0 prefixlen 64 scopeid 0xb >>> nd6 options=3D21 >>> media: Ethernet autoselect (10Gbase-Twinax ) >>> status: active >>> ix1: flags=3D8843 metric 0 = mtu 9000 >>> = options=3D401bb >>> ether 00:1b:21:cc:12:8a >>> inet 10.254.254.254 netmask 0xfffffffc broadcast = 10.254.254.255 >>> inet6 fe80::21b:21ff:fecc:128a%ix1 prefixlen 64 scopeid 0xc >>> nd6 options=3D21 >>> media: Ethernet autoselect (10Gbase-Twinax ) >>> status: active >>> ix2: flags=3D8843 metric 0 = mtu 9000 >>> = options=3D401bb >>> ether 00:1b:21:cc:12:b3 >>> inet 10.254.254.246 netmask 0xfffffffc broadcast = 10.254.254.247 >>> inet6 fe80::21b:21ff:fecc:12b3%ix2 prefixlen 64 scopeid 0xd >>> nd6 options=3D21 >>> media: Ethernet autoselect >>> status: no carrier >>> ix3: flags=3D8802 metric 0 mtu 1500 >>> = options=3D401bb >>> ether 00:1b:21:cc:12:b2 >>> nd6 options=3D21 >>> media: Ethernet autoselect >>> status: no carrier >>> lo0: flags=3D8049 metric 0 mtu 16384 >>> options=3D600003 >>> inet6 ::1 prefixlen 128 >>> inet6 fe80::1%lo0 prefixlen 64 scopeid 0xf >>> inet 127.0.0.1 netmask 0xff000000 >>> nd6 options=3D21 >>>=20 >>> #dmesg >>> =85.. >>> mfi0: 21294 (421879975s/0x0008/info) - Battery started charging >>> ix1: link state changed to DOWN >>> ix1: link state changed to UP >>> ix1: link state changed to DOWN >>> ix1: link state changed to UP >>> ix1: link state changed to DOWN >>> ix1: link state changed to UP >>> ix1: link state changed to DOWN >>> ix1: link state changed to UP >>> ix1: link state changed to DOWN >>> ix1: link state changed to UP >>> ix1: link state changed to DOWN >>> ix1: link state changed to UP >>> ix1: link state changed to DOWN >>> ix1: link state changed to UP >>> ix1: link state changed to DOWN >>> ix1: link state changed to UP >>> ix1: link state changed to DOWN >>> ix1: link state changed to UP >>> ix1: link state changed to DOWN >>> ix1: link state changed to UP >>> ix1: link state changed to DOWN >>> ix1: link state changed to UP >>> ix1: link state changed to DOWN >>> ix1: link state changed to UP >>> ix1: link state changed to DOWN >>> ix1: link state changed to UP >>> ix1: link state changed to DOWN >>> ix1: link state changed to UP >>> ix1: link state changed to DOWN >>> ix1: link state changed to UP >>> ix1: link state changed to DOWN >>> ix1: link state changed to UP >>> ix1: link state changed to DOWN >>> ix1: link state changed to UP >>> ix1: link state changed to DOWN >>> ix1: link state changed to UP >>> ix1: link state changed to DOWN >>> ix1: link state changed to UP >>> ix1: link state changed to DOWN >>> ix1: link state changed to UP >>> ix1: link state changed to DOWN >>> ix1: link state changed to UP >>>=20 >>>=20 >>> I should add that the servers that are directly connected to this = freebsd server reboot every night. This is why you see ix0 UP/DOWN >>> messages in dmesg. >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>> ------------- END System information------------ >=20 > 1. You appear convinced that the issue is related to mbuf exhaustion, > but you haven't provided evidence that you're hitting the mbuf maximum > (in your case 262144). >=20 > What you *have* shown is your mbuf count gradually increasing (sans > 15-05-2013-13-09.txt vs. 15-05-2013-14-09.txt which shows mbufs almost > doubling (!)), which could indicate a leak but then again might not. >=20 > If you reach mbuf maximum, then yes, network I/O can cease or stall > (possibly indefinitely). However, broken/busted network I/O can also > happen due to other issues unrelated to mbufs, such as network stack > issues, firewall stack issues, or network driver bugs. Are you using > pf, ipfw, or ipfilter on this system? I'll watch this over a longer period of time and come back. No pf, ipfw etc. on the system.=20 >=20 > 2. I think we'd all appreciate if you disclosed **exactly** what = version > of FreeBSD you're using (Subject says "9.0 or 9.1" which is > insufficient). Please provide "uname -a" output (you can XXX out the > hostname if you want) -- and if you're still using csup/cvsup and = built > your own kernel/world, we'll need to know exactly what date your src > files were from when you rebuilt. >=20 > I'm wary of CC'ing folks who can help troubleshoot mbuf exhaustion > issues until answers to the above can be provided, as I don't want to > waste their time. FreeBSD 9.1-RELEASE FreeBSD 9.1-RELEASE #0 r243825: Tue Dec 4 09:23:10 = UTC 2012 root@farrell.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC = amd64 >=20 > 3. Regarding this: >=20 >>> A clean shutdown isn't possible though. It hangs after vnode >>> cleaning, normally you would see detaching of usb devices here, or >>> other devices maybe? >=20 > Please don't conflate this with your above issue. This is almost > certainly unrelated. Please start a new thread about that if desired. Maybe this is a misunderstanding normally this system will shutdown = cleanly, of course. This hang only appears after the network problem above. -dennis >=20 > --=20 > | Jeremy Chadwick jdc@koitsu.org | > | UNIX Systems Administrator http://jdc.koitsu.org/ | > | Mountain View, CA, US | > | Making life hard for others since 1977. PGP 4BD6C0CB | > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to = "freebsd-stable-unsubscribe@freebsd.org" Dipl.-Inform. (FH) Dennis Berger email: db@bsdsystems.de mobile: +491791231509 fon: +494054001817 From owner-freebsd-stable@FreeBSD.ORG Wed May 15 22:03:21 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id AC5B0EEF for ; Wed, 15 May 2013 22:03:21 +0000 (UTC) (envelope-from prvs=1847987112=killing@multiplay.co.uk) Received: from mail1.multiplay.co.uk (mail1.multiplay.co.uk [85.236.96.23]) by mx1.freebsd.org (Postfix) with ESMTP id 4A702E31 for ; Wed, 15 May 2013 22:03:20 +0000 (UTC) Received: from r2d2 ([46.65.172.4]) by mail1.multiplay.co.uk (mail1.multiplay.co.uk [85.236.96.23]) (MDaemon PRO v10.0.4) with ESMTP id md50003826275.msg for ; Wed, 15 May 2013 23:03:19 +0100 X-Spam-Processed: mail1.multiplay.co.uk, Wed, 15 May 2013 23:03:19 +0100 (not processed: message from valid local sender) X-MDDKIM-Result: neutral (mail1.multiplay.co.uk) X-MDRemoteIP: 46.65.172.4 X-Return-Path: prvs=1847987112=killing@multiplay.co.uk X-Envelope-From: killing@multiplay.co.uk X-MDaemon-Deliver-To: freebsd-stable@freebsd.org Message-ID: From: "Steven Hartland" To: "dennis berger" , "Jeremy Chadwick" References: <004BC6EA-D8E6-473E-851C-9CDA7578510A@nipsi.de> <20130515211436.GA42790@icarus.home.lan> <696B5622-A95D-4187-A027-07ECC9B5AD1F@nipsi.de> Subject: Re: still mbuf leak in 9.0 / 9.1? Date: Wed, 15 May 2013 23:03:15 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="Windows-1252"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 Cc: FreeBSD stable X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 15 May 2013 22:03:21 -0000 ----- Original Message ----- From: "dennis berger" > FreeBSD 9.1-RELEASE FreeBSD 9.1-RELEASE #0 r243825: Tue Dec 4 09:23:10 UTC 2012 > > >> 3. Regarding this: >> >>>> A clean shutdown isn't possible though. It hangs after vnode >>>> cleaning, normally you would see detaching of usb devices here, or >>>> other devices maybe? >> >> Please don't conflate this with your above issue. This is almost >> certainly unrelated. Please start a new thread about that if desired. > > Maybe this is a misunderstanding normally this system will shutdown cleanly, of course. > This hang only appears after the network problem above. If this is a ZFS system, its a known issue which is fixed in current, stable-9, stable-8 and the upcoming 8.4 release. If not and you have USB devices see if the following sysctl helps: hw.usb.no_shutdown_wait=1 Regards Steve ================================================ This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. In the event of misdirection, illegible or incomplete transmission please telephone +44 845 868 1337 or return the E.mail to postmaster@multiplay.co.uk. From owner-freebsd-stable@FreeBSD.ORG Thu May 16 07:34:52 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 56C6475A for ; Thu, 16 May 2013 07:34:52 +0000 (UTC) (envelope-from db@nipsi.de) Received: from fop.bsdsystems.de (mx.bsdsystems.de [88.198.57.43]) by mx1.freebsd.org (Postfix) with ESMTP id 2BAD9313 for ; Thu, 16 May 2013 07:34:50 +0000 (UTC) Received: from [172.16.10.253] (d015075.adsl.hansenet.de [80.171.15.75]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by fop.bsdsystems.de (Postfix) with ESMTP id 040B554CDE; Thu, 16 May 2013 09:34:47 +0200 (CEST) Subject: Re: still mbuf leak in 9.0 / 9.1? Mime-Version: 1.0 (Apple Message framework v1085) From: dennis berger In-Reply-To: Date: Wed, 15 May 2013 22:13:04 +0200 Message-Id: <004BC6EA-D8E6-473E-851C-9CDA7578510A@nipsi.de> References: To: Jack Vogel X-Mailer: Apple Mail (2.1085) Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: FreeBSD stable X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 16 May 2013 07:34:52 -0000 Hi jack, so the increasing number of "mbufs in use" or mbuf clusters in use is = normal, you would say? jumbo frames are of size 9k. I know that they're from different pools, I = also checked that pool. nmb are: #cat loader.conf #tuning network hw.intr_storm_threshold=3D9000 kern.ipc.nmbclusters=3D262144 kern.ipc.nmbjumbop=3D262144 kern.ipc.nmbjumbo9=3D65536 kern.ipc.nmbjumbo16=3D32768 14-05-2013-14-09.txt:9246/4918/14164/262144 mbuf clusters in use = (current/cache/total/max) 14-05-2013-15-09.txt:9256/4856/14112/262144 mbuf clusters in use = (current/cache/total/max) 14-05-2013-16-09.txt:9266/4846/14112/262144 mbuf clusters in use = (current/cache/total/max) 14-05-2013-17-09.txt:9276/4836/14112/262144 mbuf clusters in use = (current/cache/total/max) 14-05-2013-18-09.txt:9286/4826/14112/262144 mbuf clusters in use = (current/cache/total/max) 14-05-2013-19-09.txt:9296/4734/14030/262144 mbuf clusters in use = (current/cache/total/max) 14-05-2013-20-09.txt:9306/4724/14030/262144 mbuf clusters in use = (current/cache/total/max) 14-05-2013-21-09.txt:9316/4714/14030/262144 mbuf clusters in use = (current/cache/total/max) 14-05-2013-22-09.txt:9326/4704/14030/262144 mbuf clusters in use = (current/cache/total/max) 14-05-2013-23-09.txt:9336/4694/14030/262144 mbuf clusters in use = (current/cache/total/max) 15-05-2013-00-09.txt:9346/4684/14030/262144 mbuf clusters in use = (current/cache/total/max) 15-05-2013-01-09.txt:9356/4674/14030/262144 mbuf clusters in use = (current/cache/total/max) 15-05-2013-02-09.txt:9366/4664/14030/262144 mbuf clusters in use = (current/cache/total/max) 15-05-2013-03-09.txt:9379/4279/13658/262144 mbuf clusters in use = (current/cache/total/max) 15-05-2013-04-09.txt:9384/4086/13470/262144 mbuf clusters in use = (current/cache/total/max) 15-05-2013-05-09.txt:9394/4076/13470/262144 mbuf clusters in use = (current/cache/total/max) 15-05-2013-06-09.txt:9404/4066/13470/262144 mbuf clusters in use = (current/cache/total/max) 15-05-2013-07-09.txt:9414/5040/14454/262144 mbuf clusters in use = (current/cache/total/max) 15-05-2013-08-09.txt:9424/5030/14454/262144 mbuf clusters in use = (current/cache/total/max) 15-05-2013-09-09.txt:9434/4898/14332/262144 mbuf clusters in use = (current/cache/total/max) 15-05-2013-10-09.txt:9444/4850/14294/262144 mbuf clusters in use = (current/cache/total/max) 15-05-2013-11-09.txt:9454/5000/14454/262144 mbuf clusters in use = (current/cache/total/max) 15-05-2013-12-09.txt:9464/4874/14338/262144 mbuf clusters in use = (current/cache/total/max) 15-05-2013-13-09.txt:9474/4856/14330/262144 mbuf clusters in use = (current/cache/total/max) 15-05-2013-14-09.txt:17674/4460/22134/262144 mbuf clusters in use = (current/cache/total/max) 15-05-2013-15-09.txt:17684/4450/22134/262144 mbuf clusters in use = (current/cache/total/max) 15-05-2013-16-09.txt:17694/4696/22390/262144 mbuf clusters in use = (current/cache/total/max) 15-05-2013-17-09.txt:17704/4686/22390/262144 mbuf clusters in use = (current/cache/total/max) 15-05-2013-18-09.txt:17714/4658/22372/262144 mbuf clusters in use = (current/cache/total/max) 15-05-2013-19-09.txt:17724/4648/22372/262144 mbuf clusters in use = (current/cache/total/max) 15-05-2013-20-09.txt:17734/4638/22372/262144 mbuf clusters in use = (current/cache/total/max) 15-05-2013-21-09.txt:17744/4628/22372/262144 mbuf clusters in use = (current/cache/total/max) Please see the link to http://knownhosts.org/reports-14-15.tgz in my = original post, there is the full information including 9k jumbo frames. it's the driver version 2.4.8 which should be from 9.1-release directly yes TWINAX is correct. I'll replace the driver with the latest one. best regards and thanks, dennis Am 15.05.2013 um 19:00 schrieb Jack Vogel: > So, you stop getting 10G transmission and so you are looking at mbuf = leaks? I don't see > anything in your data that makes it look like you've run out of = available mbufs. You said > you're running jumbos, what size? You do realize that if you do this = the clusters are coming > from different pools and you are not displaying those. What are all = your nmb limits set to? >=20 > So, this is 9.1 RELEASE, or stable? If you are using the driver from = release I would first off > suggest you test the code from HEAD. >=20 > What is the 10G device, I see its using Twinax, and I have been told = there is a problem at > times with those that is corrected in recent shared code, this is why = you should try the > latest code. >=20 > Cheers, >=20 > Jack >=20 >=20 >=20 > On Wed, May 15, 2013 at 2:00 AM, dennis berger wrote: > Hi list, > since we activated 10gbe on ixgbe cards + jumbo frames(9k) on 9.0 and = now on 9.1 we recognize that after a random period of time, sometimes a = week, sometimes only a day, the > system doesn't send any packets out. The phenomenon is that you can't = login via ssh, nfs and istgt is not operative. Yet you can login on the = console and execute commands. > A clean shutdown isn't possible though. It hangs after vnode cleaning, = normally you would see detaching of usb devices here, or other devices = maybe? > I've read the other post on this ML about mbuf leak in the arp = handling code in if_ether.c line 558. We don't see any of those notices = in dmesg so I don't think that glebius fix would apply for us. > I'm collecting system and memory information every hour. >=20 >=20 > Script looks like this. > less /etc/periodic/hourly/100.report-memory.sh > #!/bin/sh >=20 > reporttimestamp=3D`date +%d-%m-%Y-%H-%M` > reportname=3D${reporttimestamp}.txt >=20 > cd /root/memory-mon >=20 > top -b > $reportname > echo "" >> $reportname > vmstat -m >> $reportname > echo "" >> $reportname > vmstat -z >> $reportname > echo "" >> $reportname > netstat -Q >> $reportname > echo "" >> $reportname > netstat -n -x >> $reportname > echo "" >> $reportname > netstat -m >> $reportname > /usr/bin/perl /usr/local/bin/zfs-stats -a >> $reportname >=20 > When you grep for mbuf or mbuf usage you will see this for example: >=20 > root@freenas:/root/memory-mon # grep mbuf_packet: * > 14-05-2013-14-09.txt:mbuf_packet: 256, 0, 9246, = 2786,201700429, 0, 0 > 14-05-2013-15-09.txt:mbuf_packet: 256, 0, 9256, = 2776,201773122, 0, 0 > 14-05-2013-16-09.txt:mbuf_packet: 256, 0, 9266, = 2766,201871553, 0, 0 > 14-05-2013-17-09.txt:mbuf_packet: 256, 0, 9276, = 2756,201915405, 0, 0 > 14-05-2013-18-09.txt:mbuf_packet: 256, 0, 9286, = 2746,201927956, 0, 0 > 14-05-2013-19-09.txt:mbuf_packet: 256, 0, 9296, = 2352,201935681, 0, 0 > 14-05-2013-20-09.txt:mbuf_packet: 256, 0, 9306, = 2342,201943754, 0, 0 > 14-05-2013-21-09.txt:mbuf_packet: 256, 0, 9316, = 2332,201950961, 0, 0 > 14-05-2013-22-09.txt:mbuf_packet: 256, 0, 9326, = 2450,201958150, 0, 0 > 14-05-2013-23-09.txt:mbuf_packet: 256, 0, 9336, = 2440,201967178, 0, 0 > 15-05-2013-00-09.txt:mbuf_packet: 256, 0, 9346, = 2430,201974561, 0, 0 > 15-05-2013-01-09.txt:mbuf_packet: 256, 0, 9356, = 2420,201982105, 0, 0 > 15-05-2013-02-09.txt:mbuf_packet: 256, 0, 9366, = 2410,201989463, 0, 0 > 15-05-2013-03-09.txt:mbuf_packet: 256, 0, 9378, = 1502,203019168, 0, 0 > 15-05-2013-04-09.txt:mbuf_packet: 256, 0, 9384, = 1624,205953601, 0, 0 > 15-05-2013-05-09.txt:mbuf_packet: 256, 0, 9394, = 1870,205959258, 0, 0 > 15-05-2013-06-09.txt:mbuf_packet: 256, 0, 9404, = 2500,205969396, 0, 0 > 15-05-2013-07-09.txt:mbuf_packet: 256, 0, 9414, = 3386,207945161, 0, 0 > 15-05-2013-08-09.txt:mbuf_packet: 256, 0, 9424, = 3376,208094689, 0, 0 > 15-05-2013-09-09.txt:mbuf_packet: 256, 0, 9434, = 2982,208172465, 0, 0 > 15-05-2013-10-09.txt:mbuf_packet: 256, 0, 9444, = 3100,208270369, 0, 0 >=20 > and >=20 > root@freenas:/root/memory-mon # grep "mbufs in use" * > 14-05-2013-14-09.txt:58444/5816/64260 mbufs in use = (current/cache/total) > 14-05-2013-15-09.txt:58455/5805/64260 mbufs in use = (current/cache/total) > 14-05-2013-16-09.txt:58464/5796/64260 mbufs in use = (current/cache/total) > 14-05-2013-17-09.txt:58475/5785/64260 mbufs in use = (current/cache/total) > 14-05-2013-18-09.txt:58484/5776/64260 mbufs in use = (current/cache/total) > 14-05-2013-19-09.txt:58493/5767/64260 mbufs in use = (current/cache/total) > 14-05-2013-20-09.txt:58503/5757/64260 mbufs in use = (current/cache/total) > 14-05-2013-21-09.txt:58513/5747/64260 mbufs in use = (current/cache/total) > 14-05-2013-22-09.txt:58523/5737/64260 mbufs in use = (current/cache/total) > 14-05-2013-23-09.txt:58533/5727/64260 mbufs in use = (current/cache/total) > 15-05-2013-00-09.txt:58543/5717/64260 mbufs in use = (current/cache/total) > 15-05-2013-01-09.txt:58554/5706/64260 mbufs in use = (current/cache/total) > 15-05-2013-02-09.txt:58563/5697/64260 mbufs in use = (current/cache/total) > 15-05-2013-03-09.txt:58639/5621/64260 mbufs in use = (current/cache/total) > 15-05-2013-04-09.txt:58581/5679/64260 mbufs in use = (current/cache/total) > 15-05-2013-05-09.txt:58591/5669/64260 mbufs in use = (current/cache/total) > 15-05-2013-06-09.txt:58602/5658/64260 mbufs in use = (current/cache/total) > 15-05-2013-07-09.txt:58613/5647/64260 mbufs in use = (current/cache/total) > 15-05-2013-08-09.txt:58623/6027/64650 mbufs in use = (current/cache/total) > 15-05-2013-09-09.txt:58634/6016/64650 mbufs in use = (current/cache/total) > 15-05-2013-10-09.txt:58645/6005/64650 mbufs in use = (current/cache/total) >=20 >=20 > This increasing number of used mbuf_packets and mbufs in use makes me = nervous. > See the complete reports http://knownhosts.org:/reports-14-15.tgz >=20 > Thanks for help, >=20 > -dennis >=20 >=20 >=20 > --------------BEGIN System information--------------- > It's a stock FreeBSD 9.1, yet the hostname is called freenas. Don't be = confused. >=20 >=20 > igb0: flags=3D8c02 metric 0 mtu = 1500 > = options=3D401bb > ether 00:25:90:34:c1:12 > nd6 options=3D21 > media: Ethernet autoselect (1000baseT ) > status: active > igb1: flags=3D8843 metric 0 = mtu 1500 > = options=3D401bb > ether 00:25:90:34:c1:13 > inet 172.16.1.6 netmask 0xfffff000 broadcast 172.16.15.255 > inet6 fe80::225:90ff:fe34:c113%igb1 prefixlen 64 scopeid 0x2 > nd6 options=3D21 > media: Ethernet autoselect (1000baseT ) > status: active > ix0: flags=3D8843 metric 0 mtu = 9000 > = options=3D401bb > ether 00:1b:21:cc:12:8b > inet 10.254.254.242 netmask 0xfffffffc broadcast = 10.254.254.243 > inet6 fe80::21b:21ff:fecc:128b%ix0 prefixlen 64 scopeid 0xb > nd6 options=3D21 > media: Ethernet autoselect (10Gbase-Twinax ) > status: active > ix1: flags=3D8843 metric 0 mtu = 9000 > = options=3D401bb > ether 00:1b:21:cc:12:8a > inet 10.254.254.254 netmask 0xfffffffc broadcast = 10.254.254.255 > inet6 fe80::21b:21ff:fecc:128a%ix1 prefixlen 64 scopeid 0xc > nd6 options=3D21 > media: Ethernet autoselect (10Gbase-Twinax ) > status: active > ix2: flags=3D8843 metric 0 mtu = 9000 > = options=3D401bb > ether 00:1b:21:cc:12:b3 > inet 10.254.254.246 netmask 0xfffffffc broadcast = 10.254.254.247 > inet6 fe80::21b:21ff:fecc:12b3%ix2 prefixlen 64 scopeid 0xd > nd6 options=3D21 > media: Ethernet autoselect > status: no carrier > ix3: flags=3D8802 metric 0 mtu 1500 > = options=3D401bb > ether 00:1b:21:cc:12:b2 > nd6 options=3D21 > media: Ethernet autoselect > status: no carrier > lo0: flags=3D8049 metric 0 mtu 16384 > options=3D600003 > inet6 ::1 prefixlen 128 > inet6 fe80::1%lo0 prefixlen 64 scopeid 0xf > inet 127.0.0.1 netmask 0xff000000 > nd6 options=3D21 >=20 > #dmesg > =85.. > mfi0: 21294 (421879975s/0x0008/info) - Battery started charging > ix1: link state changed to DOWN > ix1: link state changed to UP > ix1: link state changed to DOWN > ix1: link state changed to UP > ix1: link state changed to DOWN > ix1: link state changed to UP > ix1: link state changed to DOWN > ix1: link state changed to UP > ix1: link state changed to DOWN > ix1: link state changed to UP > ix1: link state changed to DOWN > ix1: link state changed to UP > ix1: link state changed to DOWN > ix1: link state changed to UP > ix1: link state changed to DOWN > ix1: link state changed to UP > ix1: link state changed to DOWN > ix1: link state changed to UP > ix1: link state changed to DOWN > ix1: link state changed to UP > ix1: link state changed to DOWN > ix1: link state changed to UP > ix1: link state changed to DOWN > ix1: link state changed to UP > ix1: link state changed to DOWN > ix1: link state changed to UP > ix1: link state changed to DOWN > ix1: link state changed to UP > ix1: link state changed to DOWN > ix1: link state changed to UP > ix1: link state changed to DOWN > ix1: link state changed to UP > ix1: link state changed to DOWN > ix1: link state changed to UP > ix1: link state changed to DOWN > ix1: link state changed to UP > ix1: link state changed to DOWN > ix1: link state changed to UP > ix1: link state changed to DOWN > ix1: link state changed to UP > ix1: link state changed to DOWN > ix1: link state changed to UP >=20 >=20 > I should add that the servers that are directly connected to this = freebsd server reboot every night. This is why you see ix0 UP/DOWN > messages in dmesg. >=20 >=20 >=20 >=20 >=20 >=20 > ------------- END System information------------ >=20 >=20 >=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 Dipl.-Inform. (FH) Dennis Berger email: db@bsdsystems.de mobile: +491791231509 fon: +494054001817 From owner-freebsd-stable@FreeBSD.ORG Thu May 16 09:42:33 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 3999E5C0 for ; Thu, 16 May 2013 09:42:33 +0000 (UTC) (envelope-from db@nipsi.de) Received: from fop.bsdsystems.de (mx.bsdsystems.de [88.198.57.43]) by mx1.freebsd.org (Postfix) with ESMTP id 63CA1A80 for ; Thu, 16 May 2013 09:42:31 +0000 (UTC) Received: from [172.16.6.25] (p579A6028.dip0.t-ipconnect.de [87.154.96.40]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by fop.bsdsystems.de (Postfix) with ESMTP id ECC4C53E11; Thu, 16 May 2013 11:42:23 +0200 (CEST) Subject: Re: still mbuf leak in 9.0 / 9.1? Mime-Version: 1.0 (Apple Message framework v1085) From: dennis berger X-Priority: 3 In-Reply-To: Date: Thu, 16 May 2013 11:42:23 +0200 Message-Id: <4F319A22-E611-4EE6-A970-98315B15C12F@nipsi.de> References: <004BC6EA-D8E6-473E-851C-9CDA7578510A@nipsi.de> <20130515211436.GA42790@icarus.home.lan> <696B5622-A95D-4187-A027-07ECC9B5AD1F@nipsi.de> To: Steven Hartland X-Mailer: Apple Mail (2.1085) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: Jeremy Chadwick , FreeBSD stable X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 16 May 2013 09:42:33 -0000 This is indeed a ZFS+NFS system and I can see that istgt and nfs are = stuck in some ZIO state. Maybe it's this.=20 Thank's for pointing out.=20 Is it this ZFS+NFS deadlock? --- a/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/arc.c=20 +++ b/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/arc.c=20 @@ -3720,8 +3720,16 @@ arc_lowmem(void *arg __unused, int howto = __unused)=20 mutex_enter(&arc_reclaim_thr_lock);=20 needfree =3D 1;=20 cv_signal(&arc_reclaim_thr_cv);=20 - while (needfree)=20 - msleep(&needfree, &arc_reclaim_thr_lock, 0, "zfs:lowmem", 0);=20= +=20 + /*=20 + * It is unsafe to block here in arbitrary threads, because we = can come=20 + * here from ARC itself and may hold ARC locks and thus risk a = deadlock=20 + * with ARC reclaim thread.=20 + */=20 + if (curproc =3D=3D pageproc) {=20 + while (needfree)=20 + msleep(&needfree, &arc_reclaim_thr_lock, 0, "zfs:lowmem", 0);=20= + }=20 mutex_exit(&arc_reclaim_thr_lock);=20 mutex_exit(&arc_lowmem_lock);=20 } I'll try to crash our testsystem. I'll assume that stressing NFS backed = with ZFS a lot might trigger this bug? -dennis Am 16.05.2013 um 00:03 schrieb Steven Hartland: > ----- Original Message ----- From: "dennis berger" >> FreeBSD 9.1-RELEASE FreeBSD 9.1-RELEASE #0 r243825: Tue Dec 4 = 09:23:10 UTC 2012 >>=20 >>> 3. Regarding this: >>>>> A clean shutdown isn't possible though. It hangs after vnode >>>>> cleaning, normally you would see detaching of usb devices here, or >>>>> other devices maybe? >>> Please don't conflate this with your above issue. This is almost >>> certainly unrelated. Please start a new thread about that if = desired. >>=20 >> Maybe this is a misunderstanding normally this system will shutdown = cleanly, of course. >> This hang only appears after the network problem above. >=20 > If this is a ZFS system, its a known issue which is fixed in current, > stable-9, stable-8 and the upcoming 8.4 release. >=20 > If not and you have USB devices see if the following sysctl helps: > hw.usb.no_shutdown_wait=3D1 >=20 > Regards > Steve >=20 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > This e.mail is private and confidential between Multiplay (UK) Ltd. = and the person or entity to whom it is addressed. In the event of = misdirection, the recipient is prohibited from using, copying, printing = or otherwise disseminating it or any information contained in it.=20 > In the event of misdirection, illegible or incomplete transmission = please telephone +44 845 868 1337 > or return the E.mail to postmaster@multiplay.co.uk. >=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" From owner-freebsd-stable@FreeBSD.ORG Thu May 16 15:12:41 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id B081437A; Thu, 16 May 2013 15:12:41 +0000 (UTC) (envelope-from mikes@siralan.org) Received: from mail.suso.org (mail.suso.org [66.244.94.5]) by mx1.freebsd.org (Postfix) with ESMTP id 8F4D0DC9; Thu, 16 May 2013 15:12:41 +0000 (UTC) Received: from c-98-223-197-163.hsd1.in.comcast.net (c-98-223-197-163.hsd1.in.comcast.net [98.223.197.163]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.suso.org (Postfix) with ESMTP id ADB3913814C; Thu, 16 May 2013 15:12:33 +0000 (GMT) Date: Thu, 16 May 2013 11:11:42 -0400 (EDT) From: "Michael L. Squires" X-X-Sender: mikes@familysquires.net To: Craig Rodrigues Subject: Re: Apparent fxp regression in FreeBSD 8.4-RC3 In-Reply-To: Message-ID: References: <20130508174721.GD1651@glenbarber.us> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII Cc: Glen Barber , freebsd-stable@freebsd.org, FreeBSD Release Engineering Team X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 16 May 2013 15:12:41 -0000 The problem is not with the kernel/motherboard combination but with the world/motherboard combination. 8.3-R p8 with the 8.3R p8 world works fine. 8.4-Prerelease (what I get using cvsup "8_4") works fine. 8.3R p8 with the 8.4 Pre world has DHCP problems (see example below) 8.4 Pre with the 8.4 Pre world has the same problems. I'm currently running 8.3R p8 while trying to get the backup 1U to work, having problems with booting (8.4 RC3 installs fine). May 12 19:00:01 familysquires kernel: fxp0: link state changed to UP May 12 19:00:01 familysquires kernel: fxp0: link state changed to DOWN May 12 19:00:01 familysquires dhclient: New IP Address (fxp0): xx.xxx.xxx.163 May 12 19:00:01 familysquires dhclient: New Subnet Mask (fxp0): 255.255.240.0 May 12 19:00:01 familysquires dhclient: New Broadcast Address (fxp0): 255.255.25 5.255 May 12 19:00:01 familysquires dhclient: New Routers (fxp0): xxx.xxx.xxx.1 May 12 19:00:03 familysquires kernel: fxp0: link state changed to UP May 12 19:00:03 familysquires dhclient: New IP Address (fxp0): xx.xxx.xxx.163 May 12 19:00:03 familysquires kernel: fxp0: link state changed to DOWN May 12 19:00:03 familysquires dhclient: New Subnet Mask (fxp0): 255.255.240.0 May 12 19:00:03 familysquires dhclient: New Broadcast Address (fxp0): 255.255.25 5.255 May 12 19:00:03 familysquires dhclient: New Routers (fxp0): xxx.xxx.xxx.1 It will be next Wednesday before I can get to replacing the existing 8.3R p8 box. The suggestion to use "synchronous_dhclient="YEs"" did not help. I'll be trying fixed IP briefly this afternoon. Mike Squires mikes@siralan.org UNI*X at home since 1986 From owner-freebsd-stable@FreeBSD.ORG Fri May 17 01:01:49 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 366AE7B for ; Fri, 17 May 2013 01:01:49 +0000 (UTC) (envelope-from jozze.zepl@hotmail.com) Received: from dub0-omc2-s35.dub0.hotmail.com (dub0-omc2-s35.dub0.hotmail.com [157.55.1.174]) by mx1.freebsd.org (Postfix) with ESMTP id CBF319BA for ; Fri, 17 May 2013 01:01:48 +0000 (UTC) Received: from DUB121-W37 ([157.55.1.136]) by dub0-omc2-s35.dub0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 16 May 2013 18:00:41 -0700 X-TMN: [/EFTFPzAXc75f17Hs3wkWcf3CCGeVEj9] X-Originating-Email: [jozze.zepl@hotmail.com] Message-ID: From: =?iso-8859-2?B?Sm++ZSBab2JlYw==?= To: "freebsd-stable@freebsd.org" Subject: revision higher than 250508 breaks webcam support Date: Fri, 17 May 2013 03:00:41 +0200 Importance: Normal In-Reply-To: References: MIME-Version: 1.0 X-OriginalArrivalTime: 17 May 2013 01:00:41.0391 (UTC) FILETIME=[F3CA2BF0:01CE5299] Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.14 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 17 May 2013 01:01:49 -0000 Sorry=2C for waiting this long to post this problem=2C I thought it would b= e dealt with this week=2C but since it wasn't better to report it now. I ho= pe this is the right mailing list for this particular problem. I am running FreeBSD 9.1-STABLE and using Logitech Webcam C525. I it's not = listed amongst the supported hardware=2C but it was working perfectly until= the updates that came this Sunday=2C 2013-05-12. The problem I'm getting is this:=20 I keep getting this error message from the kernel=2C if I'm using 9.1-STABL= E r250707 ... pcm6: detached ugen7.2: at asbus7 uaudio0: on usbus7 uaudio0: No playback. uaudio0: Record: 48000 Hz=2C 1 ch=2C 16-bit S-LE PCM format=2C 2x8ms buffer= . uaudio0: Record: 32000 Hz=2C 1 ch=2C 16-bit S-LE PCM format=2C 2x8ms buffer= . uaudio0: Record: 24000 Hz=2C 1 ch=2C 16-bit S-LE PCM format=2C 2x8ms buffer= . uaudio0: Record: 16000 Hz=2C 1 ch=2C 16-bit S-LE PCM format=2C 2x8ms buffer= . uaudio: No MIDI squencer. pcm6: on uaudio0 uaudio0: No HID volume keys found. ugen7.2: at usbus7 (disconnected) uaudio0: at uhub7=2C port4=2C addr 2 (disconnected) pcm6: detached ... This message is displayed periodically "ad infinitum" or at least until I u= nplug the webcam. It stays this way=2C even if I use the GENERIC kernel. In= a "healthy" case=2C revision 250508=2C kernel message upon plugging the we= bcam=2C is ... ugen7.2: at usbus7 uaudio0: on usbus7 uaudio: No playback. uaudio: Record: 48000 Hz=2C 1 ch=2C 16 bit S-LE PCM format=2C 2x8ms buffer. uaudio: No MIDI sequencer. pcm6: on uaudio0 uaudio0: No HID volume keys found. And there it stops=2C and the webcam works in Skype. = From owner-freebsd-stable@FreeBSD.ORG Fri May 17 01:43:27 2013 Return-Path: Delivered-To: stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id F0A9D813 for ; Fri, 17 May 2013 01:43:27 +0000 (UTC) (envelope-from bdrewery@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by mx1.freebsd.org (Postfix) with ESMTP id C1C3EB27 for ; Fri, 17 May 2013 01:43:27 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.7/8.14.7) with ESMTP id r4H1hRGr065603 for ; Fri, 17 May 2013 01:43:27 GMT (envelope-from bdrewery@freefall.freebsd.org) Received: (from bdrewery@localhost) by freefall.freebsd.org (8.14.7/8.14.7/Submit) id r4H1hRvI065601 for stable@FreeBSD.org; Fri, 17 May 2013 01:43:27 GMT (envelope-from bdrewery) Received: (qmail 60060 invoked from network); 16 May 2013 20:43:24 -0500 Received: from unknown (HELO ?10.5.209.75?) (freebsd@shatow.net@137.122.64.51) by sweb.xzibition.com with ESMTPA; 16 May 2013 20:43:24 -0500 Message-ID: <51958B3B.6080206@FreeBSD.org> Date: Thu, 16 May 2013 21:43:23 -0400 From: Bryan Drewery Organization: FreeBSD User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: pkg@FreeBSD.org, FreeBSD Ports Subject: [HEADS UP] New pkgng git location X-Enigmail-Version: 1.5.1 OpenPGP: id=3C9B0CF9; url=http://www.shatow.net/bryan/bryan.asc Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="----enig2MTXXWCUEAVEFCQVITCHX" Cc: stable@FreeBSD.org, current@freebsd.org, uqs@FreeBSD.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 17 May 2013 01:43:28 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) ------enig2MTXXWCUEAVEFCQVITCHX Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Pkg has moved from http://github.com/pkgng/pkgng to http://github.com/freebsd/pkg Please update any links or git checkouts you have. You can update your git checkout with: > git remote set-url origin git://github.com/freebsd/pkg.git pkgng/pkgng --=20 Regards, Bryan Drewery ------enig2MTXXWCUEAVEFCQVITCHX Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJRlYs7AAoJEG54KsA8mwz5o9UQAIDvCGOFsfHXJAM+q3D/kNbj VoiwUwDqJeykqC+jE8y60T0INxadNe7u05KQc8LZleR2F3dOiOoyR6Kbgcct8Q9U VRALdiW7/CMJZJZ+pwsxJgDjZksMRXLhsg73CWmN5gqYAsbJEl9fyLz+gB47I/J1 mwDO/SB0Wy8tHxeoaWZsb8pfG7o5V/XLNOhQPoHmtFRU6ds4khOgixkgt9NJavDM Qf91J4xU6CcDNgH9bAlwZL7kwNyNWxcj9VimgwC7Ks5J89DgBqJrsSq5Of1jhIo9 PH95Uv3bRD4guqBrIP87DOZpNq502Cximc0O6d8+XDA8a8rVls7X2SOtlB9ZDzCt hB0fYjbJRnO7u+hIXOMKQcAdNMZfvUfmye5eWG+z6B8fdwH7srnrJ/eVoQoUuwJk JgvW1sbz+k9Ko8by8ges5APgNwmZ+zQiRYa9l9CEO20ZzoGRcqz7KGWnPEZ+4tpl pDmsW5D4JK29HXsptskcoit7O8wtpeEUZIaVk3B2MfIfPLlpMc7FnsqjxPX3rZNl thPVHJgngYYfIfAR0N1WN8dUzynjffa04wb9FN+H/CyzA6onv7RotHgfMKRoe0VF TzGbqrIMo6QDFzMEv9Nd50f5/WlBM2Xk6x1KLP8QO3/hJPGMg1nNlBs+pZSNI+2M ubMyC96JILxQ4zbiOcz3 =2wFa -----END PGP SIGNATURE----- ------enig2MTXXWCUEAVEFCQVITCHX-- From owner-freebsd-stable@FreeBSD.ORG Fri May 17 03:38:40 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id CE520FCF for ; Fri, 17 May 2013 03:38:40 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-wg0-x22c.google.com (mail-wg0-x22c.google.com [IPv6:2a00:1450:400c:c00::22c]) by mx1.freebsd.org (Postfix) with ESMTP id 69B151E2 for ; Fri, 17 May 2013 03:38:40 +0000 (UTC) Received: by mail-wg0-f44.google.com with SMTP id a12so1022981wgh.35 for ; Thu, 16 May 2013 20:38:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=c8oTvA3u+RQGYL8pJi+O+xjeW9hfCeeAWedusCxbWmo=; b=CwROjyFJ/1lw2OyML6Xi/npx8Mltg4bXuDCzVwEWRS4466YuzNDYa1cEnz7YCfWKHC AnLe2lGhS7R3COZahy0R2iWYu23kPygv9pmeouw1xQqWNmkfV8VHrH3BIerDgrQoT+5G ungdjIVfA8cpeyHYtrhbmUNn4f3rrN4P04wv7oKmUo2z8sy/ZUAyJf5OezCM66NX4NWF f4Pd6OEUOlOJx81Ckro2nm15aBBEtnPiCsM6d0/PII+e8pT8Gq8nKP70hWT6OjV3jmTX RJm1PUGfb5U4WFYk56qMp/kF5nMkq/pZ8itT5IJlhld8FSWmTZuRorw1uwvWivbNMLvq MRdA== MIME-Version: 1.0 X-Received: by 10.180.212.3 with SMTP id ng3mr30262675wic.22.1368761919619; Thu, 16 May 2013 20:38:39 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.217.58.138 with HTTP; Thu, 16 May 2013 20:38:39 -0700 (PDT) In-Reply-To: References: Date: Thu, 16 May 2013 20:38:39 -0700 X-Google-Sender-Auth: LsSFbIhyF5FvZMFLl-nrYeEqf0o Message-ID: Subject: Re: revision higher than 250508 breaks webcam support From: Adrian Chadd To: =?UTF-8?Q?Jo=C5=BEe_Zobec?= Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "freebsd-stable@freebsd.org" X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 17 May 2013 03:38:40 -0000 Are you able to narrow down the specific commit along 9-stable that broke i= t? Thanks! Adrian On 16 May 2013 18:00, Jo=C5=BEe Zobec wrote: > Sorry, for waiting this long to post this problem, I thought it would be = dealt with this week, but since it wasn't better to report it now. I hope t= his is the right mailing list for this particular problem. > > I am running FreeBSD 9.1-STABLE and using Logitech Webcam C525. I it's no= t listed amongst the supported hardware, but it was working perfectly until= the updates that came this Sunday, 2013-05-12. > > The problem I'm getting is this: > > I keep getting this error message from the kernel, if I'm using 9.1-STABL= E r250707 > > ... > pcm6: detached > ugen7.2: at asbus7 > uaudio0: on usbus7 > uaudio0: No playback. > uaudio0: Record: 48000 Hz, 1 ch, 16-bit S-LE PCM format, 2x8ms buffer. > uaudio0: Record: 32000 Hz, 1 ch, 16-bit S-LE PCM format, 2x8ms buffer. > uaudio0: Record: 24000 Hz, 1 ch, 16-bit S-LE PCM format, 2x8ms buffer. > uaudio0: Record: 16000 Hz, 1 ch, 16-bit S-LE PCM format, 2x8ms buffer. > uaudio: No MIDI squencer. > pcm6: on uaudio0 > uaudio0: No HID volume keys found. > ugen7.2: at usbus7 (disconnected) > uaudio0: at uhub7, port4, addr 2 (disconnected) > pcm6: detached > ... > > This message is displayed periodically "ad infinitum" or at least until I= unplug the webcam. It stays this way, even if I use the GENERIC kernel. In= a "healthy" case, revision 250508, kernel message upon plugging the webcam= , is > > ... > ugen7.2: at usbus7 > uaudio0: on usbus7 > uaudio: No playback. > uaudio: Record: 48000 Hz, 1 ch, 16 bit S-LE PCM format, 2x8ms buffer. > uaudio: No MIDI sequencer. > pcm6: on uaudio0 > uaudio0: No HID volume keys found. > > And there it stops, and the webcam works in Skype. > > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" From owner-freebsd-stable@FreeBSD.ORG Fri May 17 04:03:33 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id A3E726A3 for ; Fri, 17 May 2013 04:03:33 +0000 (UTC) (envelope-from jdc@koitsu.org) Received: from qmta09.emeryville.ca.mail.comcast.net (qmta09.emeryville.ca.mail.comcast.net [IPv6:2001:558:fe2d:43:76:96:30:96]) by mx1.freebsd.org (Postfix) with ESMTP id 4EAA8325 for ; Fri, 17 May 2013 04:03:33 +0000 (UTC) Received: from omta23.emeryville.ca.mail.comcast.net ([76.96.30.90]) by qmta09.emeryville.ca.mail.comcast.net with comcast id crzj1l0021wfjNsA9s3YPh; Fri, 17 May 2013 04:03:32 +0000 Received: from koitsu.strangled.net ([67.180.84.87]) by omta23.emeryville.ca.mail.comcast.net with comcast id cs3X1l00W1t3BNj8js3XuM; Fri, 17 May 2013 04:03:32 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id 9500373A33; Thu, 16 May 2013 21:03:31 -0700 (PDT) Date: Thu, 16 May 2013 21:03:31 -0700 From: Jeremy Chadwick To: Adrian Chadd Subject: Re: revision higher than 250508 breaks webcam support Message-ID: <20130517040331.GA73930@icarus.home.lan> References: MIME-Version: 1.0 Content-Type: text/plain; charset=unknown-8bit Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1368763412; bh=n3N7Gf4jTn2BNpdsbAvNVQscrnOXtvTG0BlUN681Ldk=; h=Received:Received:Received:Date:From:To:Subject:Message-ID: MIME-Version:Content-Type; b=fpSo9gIvwaAVX5JFw5O0Y0Sak8+zH56wmcveivd0G223rMPH69om6qxoNe6XJtKNF Ia9XL/F7DSeNm48SctRrATr2TFPpbV+I59Uu2gt9cQmjH6xR/DvQ7WuIYDWgfzTxJm cZE3VEDpk33Qiv3TDtzdN9f+LUEKba4pFKODkcLzC9xvhJTVdMIgxg5nhQlCjkOV3J L8NyBiI7iTY8X+qtMBgMpYTmYIbn/anBD5cDQwNseQv6quMMtA/NS8WXILNZf7au4y Y99+aApHzZZce0lyB6GG19sT55e7Gwri85JSbaBxOwhQ4apzvwZO57oJxMpnsNQDvx Gm/rCuUhjq8KA== Cc: "freebsd-stable@freebsd.org" , =?unknown-8bit?B?Sm/FvmU=?= Zobec X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 17 May 2013 04:03:33 -0000 On Thu, May 16, 2013 at 08:38:39PM -0700, Adrian Chadd wrote: > Are you able to narrow down the specific commit along 9-stable that broke it? > > Thanks! > > > > Adrian > > On 16 May 2013 18:00, Jože Zobec wrote: > > Sorry, for waiting this long to post this problem, I thought it would be dealt with this week, but since it wasn't better to report it now. I hope this is the right mailing list for this particular problem. > > > > I am running FreeBSD 9.1-STABLE and using Logitech Webcam C525. I it's not listed amongst the supported hardware, but it was working perfectly until the updates that came this Sunday, 2013-05-12. > > > > The problem I'm getting is this: > > > > I keep getting this error message from the kernel, if I'm using 9.1-STABLE r250707 > > > > ... > > pcm6: detached > > ugen7.2: at asbus7 > > uaudio0: on usbus7 > > uaudio0: No playback. > > uaudio0: Record: 48000 Hz, 1 ch, 16-bit S-LE PCM format, 2x8ms buffer. > > uaudio0: Record: 32000 Hz, 1 ch, 16-bit S-LE PCM format, 2x8ms buffer. > > uaudio0: Record: 24000 Hz, 1 ch, 16-bit S-LE PCM format, 2x8ms buffer. > > uaudio0: Record: 16000 Hz, 1 ch, 16-bit S-LE PCM format, 2x8ms buffer. > > uaudio: No MIDI squencer. > > pcm6: on uaudio0 > > uaudio0: No HID volume keys found. > > ugen7.2: at usbus7 (disconnected) > > uaudio0: at uhub7, port4, addr 2 (disconnected) > > pcm6: detached > > ... > > > > This message is displayed periodically "ad infinitum" or at least until I unplug the webcam. It stays this way, even if I use the GENERIC kernel. In a "healthy" case, revision 250508, kernel message upon plugging the webcam, is > > > > ... > > ugen7.2: at usbus7 > > uaudio0: on usbus7 > > uaudio: No playback. > > uaudio: Record: 48000 Hz, 1 ch, 16 bit S-LE PCM format, 2x8ms buffer. > > uaudio: No MIDI sequencer. > > pcm6: on uaudio0 > > uaudio0: No HID volume keys found. > > > > And there it stops, and the webcam works in Skype. Note: I told Joe to mail freebsd-usb@ about this, since it looks like it pertains to the USB stack, and Hans tends to respond to stuff there. That said... Looking at commits between r250508 and r250707, my gut says it's very likely one of these (with the most probable being marked with arrows): http://www.freshbsd.org/commit/freebsd/r250581 http://www.freshbsd.org/commit/freebsd/r250561 <--- http://www.freshbsd.org/commit/freebsd/r250560 <--- http://www.freshbsd.org/commit/freebsd/r250559 How I got that list was by manually reviewing the following: http://www.freshbsd.org/?branch=RELENG_9&project=freebsd So I would recommend rolling back to r250558 (the last stable/9 commit to happen before r250559) and see if things improve. Again, my gut feeling says that they will, and that r250561 or r250560 are responsible. -- | Jeremy Chadwick jdc@koitsu.org | | UNIX Systems Administrator http://jdc.koitsu.org/ | | Mountain View, CA, US | | Making life hard for others since 1977. PGP 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Fri May 17 09:37:28 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 4083934C for ; Fri, 17 May 2013 09:37:28 +0000 (UTC) (envelope-from db@bsdsystems.de) Received: from fop.bsdsystems.de (mx.bsdsystems.de [88.198.57.43]) by mx1.freebsd.org (Postfix) with ESMTP id 7B75CFB5 for ; Fri, 17 May 2013 09:37:26 +0000 (UTC) Received: from hamstedm238281.global.intra.guj.com (unknown [194.12.218.135]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by fop.bsdsystems.de (Postfix) with ESMTP id 3877154EDF; Fri, 17 May 2013 11:37:24 +0200 (CEST) Subject: Re: still mbuf leak in 9.0 / 9.1? Mime-Version: 1.0 (Apple Message framework v1085) From: dennis berger X-Priority: 3 In-Reply-To: <4F319A22-E611-4EE6-A970-98315B15C12F@nipsi.de> Date: Fri, 17 May 2013 11:37:23 +0200 Message-Id: <1186B7CE-EC84-42F6-8904-EDD0C4A5FFBD@bsdsystems.de> References: <004BC6EA-D8E6-473E-851C-9CDA7578510A@nipsi.de> <20130515211436.GA42790@icarus.home.lan> <696B5622-A95D-4187-A027-07ECC9B5AD1F@nipsi.de> <4F319A22-E611-4EE6-A970-98315B15C12F@nipsi.de> To: Steven Hartland X-Mailer: Apple Mail (2.1085) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: Jeremy Chadwick , FreeBSD stable X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 17 May 2013 09:37:28 -0000 Hi List, I can confirm that it is the bug you mentioned steven. Here is how I found it. I recorded hourly zfskern and nfsd stats. like this. echo "PROCSTAT" >> $reportname pgrep -S "(zfskern|nfsd)" | xargs procstat -kk >> $reportname luckily it crashed this night and logged this. 1910 101508 nfsd nfsd: service mi_switch+0x186 = sleepq_wait+0x42 _sleep+0x376 arc_lowmem+0x77 kmem_malloc+0xc1 = uma_large_malloc+0x4a malloc+0xd9 arc_get_data_buf+0xb5 = arc_read_nolock+0x1ec arc_read+0x93 dbuf_prefetch+0x12c = dmu_zfetch_dofetch+0x10b dmu_zfetch+0xaf8 dbuf_read+0x4a7 = dmu_buf_hold_array_by_dnode+0x16b dmu_buf_hold_array+0x67 = dmu_read_uio+0x3f zfs_freebsd_read+0x3e3=20 Maybe it would be good to merge this fix into RELENG_9_1 and distribute = a fix via freebsd-update what do you think? best, -dennis Am 16.05.2013 um 11:42 schrieb dennis berger: > This is indeed a ZFS+NFS system and I can see that istgt and nfs are = stuck in some ZIO state. Maybe it's this.=20 > Thank's for pointing out.=20 >=20 > Is it this ZFS+NFS deadlock? >=20 > --- a/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/arc.c=20 > +++ b/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/arc.c=20 > @@ -3720,8 +3720,16 @@ arc_lowmem(void *arg __unused, int howto = __unused)=20 > mutex_enter(&arc_reclaim_thr_lock);=20 > needfree =3D 1;=20 > cv_signal(&arc_reclaim_thr_cv);=20 > - while (needfree)=20 > - msleep(&needfree, &arc_reclaim_thr_lock, 0, "zfs:lowmem", 0);=20= > +=20 > + /*=20 > + * It is unsafe to block here in arbitrary threads, because we = can come=20 > + * here from ARC itself and may hold ARC locks and thus risk a = deadlock=20 > + * with ARC reclaim thread.=20 > + */=20 > + if (curproc =3D=3D pageproc) {=20 > + while (needfree)=20 > + msleep(&needfree, &arc_reclaim_thr_lock, 0, "zfs:lowmem", 0);=20= > + }=20 > mutex_exit(&arc_reclaim_thr_lock);=20 > mutex_exit(&arc_lowmem_lock);=20 > } >=20 > I'll try to crash our testsystem. I'll assume that stressing NFS = backed with ZFS a lot might trigger this bug? >=20 > -dennis >=20 >=20 > Am 16.05.2013 um 00:03 schrieb Steven Hartland: >=20 >> ----- Original Message ----- From: "dennis berger" >>> FreeBSD 9.1-RELEASE FreeBSD 9.1-RELEASE #0 r243825: Tue Dec 4 = 09:23:10 UTC 2012 >>>=20 >>>> 3. Regarding this: >>>>>> A clean shutdown isn't possible though. It hangs after vnode >>>>>> cleaning, normally you would see detaching of usb devices here, = or >>>>>> other devices maybe? >>>> Please don't conflate this with your above issue. This is almost >>>> certainly unrelated. Please start a new thread about that if = desired. >>>=20 >>> Maybe this is a misunderstanding normally this system will shutdown = cleanly, of course. >>> This hang only appears after the network problem above. >>=20 >> If this is a ZFS system, its a known issue which is fixed in current, >> stable-9, stable-8 and the upcoming 8.4 release. >>=20 >> If not and you have USB devices see if the following sysctl helps: >> hw.usb.no_shutdown_wait=3D1 >>=20 >> Regards >> Steve >>=20 >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >> This e.mail is private and confidential between Multiplay (UK) Ltd. = and the person or entity to whom it is addressed. In the event of = misdirection, the recipient is prohibited from using, copying, printing = or otherwise disseminating it or any information contained in it.=20 >> In the event of misdirection, illegible or incomplete transmission = please telephone +44 845 868 1337 >> or return the E.mail to postmaster@multiplay.co.uk. >>=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 >=20 >=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" From owner-freebsd-stable@FreeBSD.ORG Fri May 17 11:51:09 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 4CC04A84; Fri, 17 May 2013 11:51:09 +0000 (UTC) (envelope-from jozze.zepl@gmail.com) Received: from mail-vc0-f175.google.com (mail-vc0-f175.google.com [209.85.220.175]) by mx1.freebsd.org (Postfix) with ESMTP id F15947B1; Fri, 17 May 2013 11:51:08 +0000 (UTC) Received: by mail-vc0-f175.google.com with SMTP id hv10so3545979vcb.20 for ; Fri, 17 May 2013 04:51:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:content-type; bh=5CkJyxM4j6U6rRL5fythol38prJu+c35q55QLlLgV+Y=; b=wGeXy7QfK5MHSa3OB+qGGbr0iGIQK3fqJhJWjtOJPYirUWhqXMfv+Fzadpyv8/U97G 23urC46kL6w3jgH8Ogl6fLue1uCHgFtzjk3msN4LHmYZsi/k1RjuadoR2ZdT+HIg/L2+ /Z8jR+BNcaxsHF5EY8oNspiBaaKSP+Nnpux9EmXU2K19ZYlgciT7GD9TiIiNvRAvq4sY G2JmwmXVX5itdY/CqEtdGBKXTqTiAugoNfpJIYxs0VSGu3VwkwnVXg7P+p8qlnI9RJA2 dwMV21jExSiu55b+aOd+cKhQS7+egll409JVL6aEe7yq5rDhOg+6OESl2OWiKKLHqDX+ vc5A== MIME-Version: 1.0 X-Received: by 10.52.69.40 with SMTP id b8mr25009724vdu.130.1368791468295; Fri, 17 May 2013 04:51:08 -0700 (PDT) Received: by 10.58.95.233 with HTTP; Fri, 17 May 2013 04:51:08 -0700 (PDT) In-Reply-To: References: <20130517040331.GA73930@icarus.home.lan> Date: Fri, 17 May 2013 13:51:08 +0200 Message-ID: Subject: Fwd: revision higher than 250508 breaks webcam support From: =?ISO-8859-2?Q?Jo=BEe_Zobec?= To: freebsd-usb@freebsd.org, freebsd-stable@freebsd.org Content-Type: text/plain; charset=ISO-8859-2 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.14 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 17 May 2013 11:51:09 -0000 ---------- Forwarded message ---------- From: Jo=BEe Zobec Date: 2013/5/17 Subject: Re: revision higher than 250508 breaks webcam support To: Jeremy Chadwick , Adrian Chadd OK, I compiled and tried different revisions r250559 -- OK r250560 -- OK r250561 -- error Upon updating from r250560 to r250561, svn gave me ... U /usr/src/sys/dev/sound/usb/uaudio.c U /usr/src/sys/dev U /usr/src/sys ... I tried # svn diff -r 250560:250561 /usr/src | less to see if I could localize the problem even further, but there are a lot of changes so I don't know where it could go wrong, since I'm not the one who wrote it. I am looking forward to your fast reply, Jo=BEe From owner-freebsd-stable@FreeBSD.ORG Fri May 17 14:30:29 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 678E78BA; Fri, 17 May 2013 14:30:29 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-wg0-x22e.google.com (mail-wg0-x22e.google.com [IPv6:2a00:1450:400c:c00::22e]) by mx1.freebsd.org (Postfix) with ESMTP id CD254F89; Fri, 17 May 2013 14:30:28 +0000 (UTC) Received: by mail-wg0-f46.google.com with SMTP id n11so63751wgh.25 for ; Fri, 17 May 2013 07:30:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=HBLd1TAx1RG2eFS3GoOP2Yz7eLTpXq0dpT+0lMcwTQQ=; b=dGrJeVuENlN7+gK2lNgBRug7+EVGVVKU88sZI7scXylkyHhs6MRu+XuN5BZx1Qxatf /2Uyp6z6QVxm5J+vdw2+ZXzyUZ+BksIJMBCJjNprFz7TfsyaZ90S45y23lmFUFKQ4Eix CEuQfhPYTaDxlNaydoymC2bONW71QLNw0MPQjtpwgoFKvYPJrawewzwfMpM/4wvZ719P C7JgbzHXqBXSp7nv04zjGFIMuDqdIKl1pxFug7UA/1P0S6HI56EB3Cny5tg1c9og1UBN jUtI+mOLL+dODtV97n52q2kE/lU24ubPWNCzu6irRAqi4/VL0gK0Xd7T420FB24ioVnZ AFPg== MIME-Version: 1.0 X-Received: by 10.194.21.101 with SMTP id u5mr904053wje.56.1368801027836; Fri, 17 May 2013 07:30:27 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.217.58.138 with HTTP; Fri, 17 May 2013 07:30:27 -0700 (PDT) In-Reply-To: References: <20130517040331.GA73930@icarus.home.lan> Date: Fri, 17 May 2013 07:30:27 -0700 X-Google-Sender-Auth: t2r0XMGAgOteqVjtpBgXKx_Y4mc Message-ID: Subject: Re: revision higher than 250508 breaks webcam support From: Adrian Chadd To: =?UTF-8?Q?Jo=C5=BEe_Zobec?= Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: Jeremy Chadwick , FreeBSD Stable Mailing List , freebsd-usb@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 17 May 2013 14:30:29 -0000 'ola! Cool, you've nailed it down to a specific revision. Can you create a PR (www.freebsd.org/send-pr.html) with all of this informa= tion? Hans/USB folk - here's an interesting problem. The original email is below. =3D=3D=3D Sorry, for waiting this long to post this problem, I thought it would be dealt with this week, but since it wasn't better to report it now. I hope this is the right mailing list for this particular problem. I am running FreeBSD 9.1-STABLE and using Logitech Webcam C525. I it's not listed amongst the supported hardware, but it was working perfectly until the updates that came this Sunday, 2013-05-12. The problem I'm getting is this: I keep getting this error message from the kernel, if I'm using 9.1-STABLE r250707 ... pcm6: detached ugen7.2: at asbus7 uaudio0: on usbus7 uaudio0: No playback. uaudio0: Record: 48000 Hz, 1 ch, 16-bit S-LE PCM format, 2x8ms buffer. uaudio0: Record: 32000 Hz, 1 ch, 16-bit S-LE PCM format, 2x8ms buffer. uaudio0: Record: 24000 Hz, 1 ch, 16-bit S-LE PCM format, 2x8ms buffer. uaudio0: Record: 16000 Hz, 1 ch, 16-bit S-LE PCM format, 2x8ms buffer. uaudio: No MIDI squencer. pcm6: on uaudio0 uaudio0: No HID volume keys found. ugen7.2: at usbus7 (disconnected) uaudio0: at uhub7, port4, addr 2 (disconnected) pcm6: detached ... This message is displayed periodically "ad infinitum" or at least until I unplug the webcam. It stays this way, even if I use the GENERIC kernel. In a "healthy" case, revision 250508, kernel message upon plugging the webcam, is ... ugen7.2: at usbus7 uaudio0: on usbus7 uaudio: No playback. uaudio: Record: 48000 Hz, 1 ch, 16 bit S-LE PCM format, 2x8ms buffer. uaudio: No MIDI sequencer. pcm6: on uaudio0 uaudio0: No HID volume keys found. And there it stops, and the webcam works in Skype. =3D=3D=3D adrian On 17 May 2013 04:14, Jo=C5=BEe Zobec wrote: > OK, I compiled and tried different revisions > r250559 -- OK > r250560 -- OK > r250561 -- error > > Upon updating from r250560 to r250561, svn give me > > ... > U /usr/src/sys/dev/sound/usb/uaudio.c > U /usr/src/sys/dev > U /usr/src/sys > ... > > I tried > > # svn diff -r 250560:250561 /usr/src | less > > to see if I could localize the problem even further, but there are a lot = of > changes so I don't know where it could go wrong, since I'm not the one wh= o > wrote it. > > I am looking forward to your fast reply, > > Jo=C5=BEe From owner-freebsd-stable@FreeBSD.ORG Fri May 17 14:31:48 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 16E19A0E; Fri, 17 May 2013 14:31:48 +0000 (UTC) (envelope-from guru@unixarea.de) Received: from ms16-1.1blu.de (ms16-1.1blu.de [89.202.0.34]) by mx1.freebsd.org (Postfix) with ESMTP id A7DE9FAE; Fri, 17 May 2013 14:31:47 +0000 (UTC) Received: from [93.104.28.93] (helo=localhost.my.domain) by ms16-1.1blu.de with esmtpsa (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from ) id 1UdLh9-00079r-OZ; Fri, 17 May 2013 16:31:44 +0200 Received: from localhost.my.domain (localhost [127.0.0.1]) by localhost.my.domain (8.14.7/8.14.3) with ESMTP id r4HGVkOG006385; Fri, 17 May 2013 16:31:46 GMT (envelope-from guru@unixarea.de) Received: (from guru@localhost) by localhost.my.domain (8.14.7/8.14.3/Submit) id r4HGVknf006384; Fri, 17 May 2013 16:31:46 GMT (envelope-from guru@unixarea.de) X-Authentication-Warning: localhost.my.domain: guru set sender to guru@unixarea.de using -f Date: Fri, 17 May 2013 16:31:45 +0000 From: Matthias Apitz To: freebsd-usb@freebsd.org, freebsd-stable@freebsd.org, freebsd-multimedia@freebsd.org Subject: Re: revision higher than 250508 breaks webcam support Message-ID: <20130517163145.GA6348@La-Habana> References: <20130517040331.GA73930@icarus.home.lan> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-Operating-System: FreeBSD 9.0-CURRENT r214444 (i386) User-Agent: Mutt/1.5.21 (2010-09-15) X-Con-Id: 51246 X-Con-U: 0-guru X-Originating-IP: 93.104.28.93 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: Matthias Apitz List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 May 2013 14:31:48 -0000 El día Friday, May 17, 2013 a las 01:51:08PM +0200, Jože Zobec escribió: > ---------- Forwarded message ---------- > From: Jože Zobec > Date: 2013/5/17 > Subject: Re: revision higher than 250508 breaks webcam support > To: Jeremy Chadwick , Adrian Chadd > > > OK, I compiled and tried different revisions > r250559 -- OK > r250560 -- OK > r250561 -- error > > Upon updating from r250560 to r250561, svn gave me > > ... > U /usr/src/sys/dev/sound/usb/uaudio.c > U /usr/src/sys/dev > U /usr/src/sys > ... > Hello, I have the following set of laptops which are all running the same SVN revision of the ports r315646 and only the last one was updated today to a new base/head revision r250588: | name | kernel | date | ports (r or date) | remarks +--------------+----------+--------------+-------------------+-------- | Aurora | r235646 | May 19, 2012 | r315646 20130401 | | tiny | r235646 | May 19, 2012 | r315646 20130401 | cloned Aurora | Perlach | r235646 | May 19, 2012 | r315646 20130401 | cloned Aurora | La-Habana | r250588 | May 13, 2013 | r315646 20130401 | the ports have been compiled on Aurora and moved via pkg_create(8) to the other hosts (around 1200 ports); on 'La-Habana' where the new kernel is running I have had to rebuild only cuse4bsd-kmod-0.1.27, because it's a kmod and depends on the sources of the running kernel; on all systems of r235646, Skype is fine with the cams I have, on r250588 my cams are working with pwcview(1) but not with Skype. What can we do to debug this? We should move this thread to freebsd-multimedia only, I suggest. Thanks matthias -- Matthias Apitz | /"\ ASCII Ribbon Campaign: www.asciiribbon.org E-mail: guru@unixarea.de | \ / - No HTML/RTF in E-mail WWW: http://www.unixarea.de/ | X - No proprietary attachments phone: +49-170-4527211 | / \ - Respect for open standards From owner-freebsd-stable@FreeBSD.ORG Fri May 17 17:31:04 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 13878375 for ; Fri, 17 May 2013 17:31:04 +0000 (UTC) (envelope-from jdc@koitsu.org) Received: from qmta10.emeryville.ca.mail.comcast.net (qmta10.emeryville.ca.mail.comcast.net [IPv6:2001:558:fe2d:43:76:96:30:17]) by mx1.freebsd.org (Postfix) with ESMTP id DE5E4CEF for ; Fri, 17 May 2013 17:31:03 +0000 (UTC) Received: from omta11.emeryville.ca.mail.comcast.net ([76.96.30.36]) by qmta10.emeryville.ca.mail.comcast.net with comcast id d4Lk1l0060mlR8UAA5X37b; Fri, 17 May 2013 17:31:03 +0000 Received: from koitsu.strangled.net ([67.180.84.87]) by omta11.emeryville.ca.mail.comcast.net with comcast id d5X11l00Y1t3BNj8X5X1xD; Fri, 17 May 2013 17:31:02 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id 75D4673A33; Fri, 17 May 2013 10:31:01 -0700 (PDT) Date: Fri, 17 May 2013 10:31:01 -0700 From: Jeremy Chadwick To: dennis berger Subject: Re: still mbuf leak in 9.0 / 9.1? Message-ID: <20130517173101.GB87223@icarus.home.lan> References: <004BC6EA-D8E6-473E-851C-9CDA7578510A@nipsi.de> <20130515211436.GA42790@icarus.home.lan> <696B5622-A95D-4187-A027-07ECC9B5AD1F@nipsi.de> <4F319A22-E611-4EE6-A970-98315B15C12F@nipsi.de> <1186B7CE-EC84-42F6-8904-EDD0C4A5FFBD@bsdsystems.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1186B7CE-EC84-42F6-8904-EDD0C4A5FFBD@bsdsystems.de> User-Agent: Mutt/1.5.21 (2010-09-15) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1368811863; bh=+xPAKdZqrJmVeJHOisYG5z2xpNeroG1twtIJxkGqFIg=; h=Received:Received:Received:Date:From:To:Subject:Message-ID: MIME-Version:Content-Type; b=WDbz/3assegZBPtFVECMMbA+36MVWS98t+sICb2CdB56FgVfY4zZBfhst1KgH14MW ErAeTD6BAGlH8EHSPhq6iBjmGYmXA1F8xnrwbjS+yAeThZnCemnehiE7w/YlKpSb0H P1hP+n2aSRy5yuremalqqjy9mqCOdewq+4BYQO6vlDkUeuaEjHzGxzeh8tl1vrQLeM 1nCp5MnVBimMdf7KM/Jf7NHzk3IhKM199D2mQDdHN6hP2Yau7ZFt+uuLQ08yvvMnVj xOgv4NLHwAsFlSPP/R8/h6cWNdMiSwcJF2dSEd2SygpF9WA5+P7QvVJxivFp6i/1jw apI/J4+EhE0ZQ== Cc: FreeBSD stable , Steven Hartland X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 17 May 2013 17:31:04 -0000 On Fri, May 17, 2013 at 11:37:23AM +0200, dennis berger wrote: > Hi List, > I can confirm that it is the bug you mentioned steven. > Here is how I found it. > > I recorded hourly zfskern and nfsd stats. like this. > > echo "PROCSTAT" >> $reportname > pgrep -S "(zfskern|nfsd)" | xargs procstat -kk >> $reportname > > luckily it crashed this night and logged this. > > 1910 101508 nfsd nfsd: service mi_switch+0x186 sleepq_wait+0x42 _sleep+0x376 arc_lowmem+0x77 kmem_malloc+0xc1 uma_large_malloc+0x4a malloc+0xd9 arc_get_data_buf+0xb5 arc_read_nolock+0x1ec arc_read+0x93 dbuf_prefetch+0x12c dmu_zfetch_dofetch+0x10b dmu_zfetch+0xaf8 dbuf_read+0x4a7 dmu_buf_hold_array_by_dnode+0x16b dmu_buf_hold_array+0x67 dmu_read_uio+0x3f zfs_freebsd_read+0x3e3 > > Maybe it would be good to merge this fix into RELENG_9_1 and distribute a fix via freebsd-update what do you think? > > best, > -dennis > > > Am 16.05.2013 um 11:42 schrieb dennis berger: > > > This is indeed a ZFS+NFS system and I can see that istgt and nfs are stuck in some ZIO state. Maybe it's this. > > Thank's for pointing out. > > > > Is it this ZFS+NFS deadlock? > > > > --- a/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/arc.c > > +++ b/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/arc.c > > @@ -3720,8 +3720,16 @@ arc_lowmem(void *arg __unused, int howto __unused) > > mutex_enter(&arc_reclaim_thr_lock); > > needfree = 1; > > cv_signal(&arc_reclaim_thr_cv); > > - while (needfree) > > - msleep(&needfree, &arc_reclaim_thr_lock, 0, "zfs:lowmem", 0); > > + > > + /* > > + * It is unsafe to block here in arbitrary threads, because we can come > > + * here from ARC itself and may hold ARC locks and thus risk a deadlock > > + * with ARC reclaim thread. > > + */ > > + if (curproc == pageproc) { > > + while (needfree) > > + msleep(&needfree, &arc_reclaim_thr_lock, 0, "zfs:lowmem", 0); > > + } > > mutex_exit(&arc_reclaim_thr_lock); > > mutex_exit(&arc_lowmem_lock); > > } > > > > I'll try to crash our testsystem. I'll assume that stressing NFS backed with ZFS a lot might trigger this bug? > > > > -dennis > > > > > > Am 16.05.2013 um 00:03 schrieb Steven Hartland: > > > >> ----- Original Message ----- From: "dennis berger" > >>> FreeBSD 9.1-RELEASE FreeBSD 9.1-RELEASE #0 r243825: Tue Dec 4 09:23:10 UTC 2012 > >>> > >>>> 3. Regarding this: > >>>>>> A clean shutdown isn't possible though. It hangs after vnode > >>>>>> cleaning, normally you would see detaching of usb devices here, or > >>>>>> other devices maybe? > >>>> Please don't conflate this with your above issue. This is almost > >>>> certainly unrelated. Please start a new thread about that if desired. > >>> > >>> Maybe this is a misunderstanding normally this system will shutdown cleanly, of course. > >>> This hang only appears after the network problem above. > >> > >> If this is a ZFS system, its a known issue which is fixed in current, > >> stable-9, stable-8 and the upcoming 8.4 release. > >> > >> If not and you have USB devices see if the following sysctl helps: > >> hw.usb.no_shutdown_wait=1 I'm sorry to say it won't happen. The only updates that the -RELEASE branches get are for security. If you want fixes for other things, you need to follow/run stables branches (i.e. stable/9), otherwise you will need to wait until 9.2-RELEASE comes out. -- | Jeremy Chadwick jdc@koitsu.org | | UNIX Systems Administrator http://jdc.koitsu.org/ | | Mountain View, CA, US | | Making life hard for others since 1977. PGP 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Fri May 17 18:12:01 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id D16F8D76 for ; Fri, 17 May 2013 18:12:01 +0000 (UTC) (envelope-from MGASS@csbsju.edu) Received: from smtp2.computing.csbsju.edu (smtp2.computing.csbsju.edu [152.65.184.23]) by mx1.freebsd.org (Postfix) with ESMTP id 7DBA7E77 for ; Fri, 17 May 2013 18:12:01 +0000 (UTC) X-AuditID: ac10425c-b7fed6d0000007e2-41-51966f655376 Received: from Mail-HTCAS2.ad.csbsju.edu (Unknown_Domain [172.16.66.44]) by smtp2.computing.csbsju.edu (Symantec Messaging Gateway) with SMTP id 19.B8.02018.56F66915; Fri, 17 May 2013 12:56:53 -0500 (CDT) Received: from nx.csbsju.edu (172.16.66.48) by MAIL-HTCAS2.ad.csbsju.edu (172.16.66.44) with Microsoft SMTP Server id 14.3.123.3; Fri, 17 May 2013 12:56:53 -0500 Received: by nx.csbsju.edu (Postfix, from userid 1401) id 7EB1A180804; Fri, 17 May 2013 12:56:53 -0500 (CDT) Date: Fri, 17 May 2013 12:56:53 -0500 From: Michael Gass To: Subject: Command line not responding Message-ID: <20130517175653.GA15498@csbsju.edu> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) X-Brightmail-Tracker: H4sIAAAAAAAAA11Ta0xTZxjm6wVOaz89nBb6Uq3DkxkzxAIN3jKyOZeZZdkS6tySTSdr4azt 6M2e1sEwTmShG47pJrBKFE3QSJiswhICssjWXbAqMsgG06EsGZjBjGMwzTYG7pzTFg7+e/M8 7/s87+X7CCk1otARdpeP8brMDjpRKTtHbs1cx7jrTNkfTW/e9HUFtQU9G5w6KctHryrzihiH fS/jzXridaXt/uETEs9peUnD6FXpAVQhq0IKAshciBz/Wx6NU+H7W6FEPqbIawiaA9IqpOTi Mwg6w5+hKOGC/hPXhFhGrobjVS0SPk7k4sC3HwqiGjIdygNBQUhNPgq/3h4TcjCZBb2zwVic DJFjo0K+lMyEU11TXD7Bxcvh7BzBwylcaU2kPdaPHuqODEuPoGX1oup6UXX9QvUpJG1GOtbp 8xgNhW6nx++zu6yGQtbCvuk3MEX+NhTd264O1NO/IYxIAtEqPPlMnYmSm/eypc4wKiYktA7v u1ljotQWd1GpzczaCli/xWlnWbvbRafgQieXvnSe8/odDEtrsNPFwXgetvgdxfRKrBysNVFa kRDrsRfa3X62wO91hBEQUq60508uCReZS99mvO6oYBgtJ2S0Fg+9eyefIq1mH1PMMB7GG2ff Ighaj1FCQgKV6mWsTMkbdgf3NMSdAjbzLSWL6WizWrzUzjGkmBH6XYVvbj5qonSLFRe3LCEU YWQlVHRa1J5iPWYna7eKrTV4t7CNOBW1VWMFvzpVHBUs9fhnfkWpCypiu8toj24F/qOCu0YK n2HzuxZPqdPi/bwVKWIFN10qbj/IlS0TEbyhLh138XjaIjmx5wQ6JOHeBeAy/hEkc1/uoenU uJi3VMWY6HAUzuPBJTFQmG0F7hI6n5cQ2xjPIAKRw1LovtKE4N7gmAyOzn4gh8+/7JDDpc7f kyDY+KkC7lz/dwl8PHIZQ6jxHwwTD77Swo3hiwChuWoa3jtYuRam736TA4MzF4zQMPCbEbrv zqyH/wItj8PcQOsWOPfXladg5P4PW+GnykMmeH+q6RXoaurZCW39Q69Bd/XVApi8eJ6B0fFj LmibGXVxHufdEGzo9cCNSM2eCe7YkoVj+8wPr0OD5fwFcZyKH3sjj6riaOzY2dFjz6uIN6I7 gB7Z0VH9MhrbKNtvOb0j9+zajN0vbN/W0un9MW966MXvtCHDvsrmJ98xrrydW/5L/i3NvYSX khofk32x0zJgIJ/rC5UpL+S0Ep+M02jdrt6hwdqkBmpyfHvmNtOmVnXWhvJu/Zo1Twdq08ez 2/sSV6/Pef5wGZmhj5T0XVI+uN4zm1aTR8tYmzknQ+plzf8DuhKW2HIFAAA= X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 17 May 2013 18:12:01 -0000 Running 9.0-Stable on an i386. Whenever I type a command at the prompt I get the output /usr/local/lib/libintl.so.9: Undefined symbol "_ThreadRuneLocale" and nothing else - the command will not run. Just the above output. Commands like "ls" and "exit" work, but not much else. This happends whether I am logged in a user or as root. Cannot even halt the system from the command line. Started to happen after trying to update the freetype2 port. Got an error msg while updating libXft-2.1.14. From that point on I cannot use the command line. I have no idea what to try. Any suggestions. -- Michael Gass mgass@csbsju.edu From owner-freebsd-stable@FreeBSD.ORG Fri May 17 18:35:00 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id BF6A8356 for ; Fri, 17 May 2013 18:35:00 +0000 (UTC) (envelope-from matthew@FreeBSD.org) Received: from smtp.infracaninophile.co.uk (smtp6.infracaninophile.co.uk [IPv6:2001:8b0:151:1:3cd3:cd67:fafa:3d78]) by mx1.freebsd.org (Postfix) with ESMTP id 2D047F1B for ; Fri, 17 May 2013 18:34:59 +0000 (UTC) Received: from seedling.black-earth.co.uk (seedling.black-earth.co.uk [81.2.117.99]) (authenticated bits=0) by smtp.infracaninophile.co.uk (8.14.7/8.14.7) with ESMTP id r4HIYjZi028072 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Fri, 17 May 2013 19:34:45 +0100 (BST) (envelope-from matthew@FreeBSD.org) DKIM-Filter: OpenDKIM Filter v2.8.3 smtp.infracaninophile.co.uk r4HIYjZi028072 Authentication-Results: smtp.infracaninophile.co.uk/r4HIYjZi028072; dkim=none reason="no signature"; dkim-adsp=none (unprotected policy) Message-ID: <5196783C.1080107@FreeBSD.org> Date: Fri, 17 May 2013 19:34:36 +0100 From: Matthew Seaman User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Michael Gass Subject: Re: Command line not responding References: <20130517175653.GA15498@csbsju.edu> In-Reply-To: <20130517175653.GA15498@csbsju.edu> X-Enigmail-Version: 1.5.1 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="----enig2TQELGRTPJXTUCJTJKMVD" X-Virus-Scanned: clamav-milter 0.97.8 at lucid-nonsense.infracaninophile.co.uk X-Virus-Status: Clean X-Spam-Status: No, score=-1.6 required=5.0 tests=AWL,BAYES_00,SPF_SOFTFAIL autolearn=no version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on lucid-nonsense.infracaninophile.co.uk Cc: freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 17 May 2013 18:35:00 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) ------enig2TQELGRTPJXTUCJTJKMVD Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 17/05/2013 18:56, Michael Gass wrote: > Running 9.0-Stable on an i386. >=20 > Whenever I type a command at the prompt I get > the output >=20 > /usr/local/lib/libintl.so.9: Undefined symbol "_ThreadRuneLocale" >=20 > and nothing else - the command will not run. Just the > above output. Commands like "ls" and "exit" work, but not much > else. This happends whether I am logged in a user or as root. > Cannot even halt the system from the command line. >=20 > Started to happen after trying to update the freetype2 port. > Got an error msg while updating libXft-2.1.14. From that point > on I cannot use the command line. >=20 > I have no idea what to try. Any suggestions. It's only things you installed from ports that would be affected. There was a problem with the freetype2 port earlier today, but it has been fixed now. Update your ports and try again at updating. Cheers, Matthew --=20 Dr Matthew J Seaman MA, D.Phil. PGP: http://www.infracaninophile.co.uk/pgpkey ------enig2TQELGRTPJXTUCJTJKMVD Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.16 (Darwin) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlGWeEQACgkQ8Mjk52CukIysxwCaAxFATsx+BiirCPzXEoUuwlSx RjUAn1NE7TziazCopeKC/0fD/0kGlGK0 =uGYV -----END PGP SIGNATURE----- ------enig2TQELGRTPJXTUCJTJKMVD-- From owner-freebsd-stable@FreeBSD.ORG Fri May 17 18:55:14 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id AF977C3F for ; Fri, 17 May 2013 18:55:14 +0000 (UTC) (envelope-from jdc@koitsu.org) Received: from qmta01.emeryville.ca.mail.comcast.net (qmta01.emeryville.ca.mail.comcast.net [IPv6:2001:558:fe2d:43:76:96:30:16]) by mx1.freebsd.org (Postfix) with ESMTP id 8CC66FCD for ; Fri, 17 May 2013 18:55:14 +0000 (UTC) Received: from omta20.emeryville.ca.mail.comcast.net ([76.96.30.87]) by qmta01.emeryville.ca.mail.comcast.net with comcast id d6JT1l00B1smiN4A16vEKw; Fri, 17 May 2013 18:55:14 +0000 Received: from koitsu.strangled.net ([67.180.84.87]) by omta20.emeryville.ca.mail.comcast.net with comcast id d6vD1l00N1t3BNj8g6vD5v; Fri, 17 May 2013 18:55:13 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id 4FE1E73A33; Fri, 17 May 2013 11:55:13 -0700 (PDT) Date: Fri, 17 May 2013 11:55:13 -0700 From: Jeremy Chadwick To: Michael Gass Subject: Re: Command line not responding Message-ID: <20130517185513.GA88287@icarus.home.lan> References: <20130517175653.GA15498@csbsju.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20130517175653.GA15498@csbsju.edu> User-Agent: Mutt/1.5.21 (2010-09-15) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1368816914; bh=Pzmqmplpdo1twMb8JgPiBNFYeUSodeI+g9dNLkQdPZQ=; h=Received:Received:Received:Date:From:To:Subject:Message-ID: MIME-Version:Content-Type; b=ocLgXH+WaZqDFXWWHnQnqsMb1mqBv9q9hI703bAHzsjXSlawCQkqvBADPQghrV/ri 8QxuD8ib8kTfL9pZkX/nUXOPVMDBYjscBozCOkJnaKxXmguJmbPtN7mXAMS42Wqnlv DnwrZnZ/+rPvsuSuicLVFqvAClGWGZDYHV+dRrYso3noauMjOeL8TOx/NpbvtMigew DIoD/X30b+um+HzMywUwop123oMcUkXgjRP/HGS3A4XZ7R1SnjOSUAXmObOSPnoQQI RKMBuKOMESG62qhQqubTS1QH19okNArMQUTLrosKNLbIN70MO/YSWZtWbp8QAO9wSN 956q1xu3f+Ltw== Cc: freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 17 May 2013 18:55:14 -0000 On Fri, May 17, 2013 at 12:56:53PM -0500, Michael Gass wrote: > Running 9.0-Stable on an i386. > > Whenever I type a command at the prompt I get > the output > > /usr/local/lib/libintl.so.9: Undefined symbol "_ThreadRuneLocale" > > and nothing else - the command will not run. Just the > above output. Commands like "ls" and "exit" work, but not much > else. This happends whether I am logged in a user or as root. > Cannot even halt the system from the command line. > > Started to happen after trying to update the freetype2 port. > Got an error msg while updating libXft-2.1.14. From that point > on I cannot use the command line. > > I have no idea what to try. Any suggestions. First provide the contents of /etc/make.conf and /etc/src.conf. The _ThreadRuneLocale thing has come up before, but on -CURRENT circa early 2012. It happened to a user when trying to build kernel (really) and that user was tinkering about in make.conf and src.conf heavily, messing with Clang. I personally remove Clang from my systems entirely for many reasons, by simply doing WITHOUT_CLANG=true in src.conf and thus rely entirely on gcc. My recommendation, and this isn't going to make you happy: Boot into single-user, mount your filesystems, and try commands there, in hopes that they work. If they do: pkg_delete -a -f cp -pR /usr/local /usr/local.old rm -fr /usr/local/* reboot Boot into multi-user, log in, and things should be fine. Next: rm -fr /var/db/ports/* rm -fr /usr/ports/distfiles/* find /usr/ports -type d -name "work" -exec rm -fr {} \; Now begin rebuilding your ports. If you prefer to use packages, go right ahead, given that this was just announced a few days ago: http://lists.freebsd.org/pipermail/freebsd-announce/2013-May/001476.html But I tend to build everything from source, barring large-ish packages (things like cmake, python27, perl) which I pkg_add -r. My attitude has always been when something catastrophic impacts a very large number of commands (particularly a library with a missing symbol that a very large number of programs link to), start fresh. It's not worth scrambling around with leftover cruft in place that could appear months later and make you say "I thought I fixed that!", where you then have to follow up to a thread months old and admit "actually there is more breakage..." Footnote: I am likely to get a large amount of backlash for proposing the above, with claims that will equate it to fixing a minor cut by amputating the entire limb. My response to such: that's nice. -- | Jeremy Chadwick jdc@koitsu.org | | UNIX Systems Administrator http://jdc.koitsu.org/ | | Mountain View, CA, US | | Making life hard for others since 1977. PGP 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Fri May 17 19:27:06 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 7242CB94 for ; Fri, 17 May 2013 19:27:06 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from tensor.andric.com (tensor.andric.com [IPv6:2001:7b8:3a7:1:2d0:b7ff:fea0:8c26]) by mx1.freebsd.org (Postfix) with ESMTP id 3DE231A8 for ; Fri, 17 May 2013 19:27:06 +0000 (UTC) Received: from [IPv6:2001:7b8:3a7::f50f:aff0:929b:1a2e] (unknown [IPv6:2001:7b8:3a7:0:f50f:aff0:929b:1a2e]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id 184F05C44; Fri, 17 May 2013 21:27:03 +0200 (CEST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) Subject: Re: Command line not responding From: Dimitry Andric In-Reply-To: <20130517175653.GA15498@csbsju.edu> Date: Fri, 17 May 2013 21:26:58 +0200 Content-Transfer-Encoding: 7bit Message-Id: References: <20130517175653.GA15498@csbsju.edu> To: Michael Gass X-Mailer: Apple Mail (2.1503) Cc: freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 17 May 2013 19:27:06 -0000 On May 17, 2013, at 19:56, Michael Gass wrote: > Running 9.0-Stable on an i386. > > Whenever I type a command at the prompt I get > the output > > /usr/local/lib/libintl.so.9: Undefined symbol "_ThreadRuneLocale" > > and nothing else - the command will not run. Are you running bash, by any chance? Because bash is usually linked to libintl, for its internationalized messages. In any case, it looks like there is a mismatch between your libc.so, and your ports. Did you recently update your base system? > Started to happen after trying to update the freetype2 port. > Got an error msg while updating libXft-2.1.14. From that point > on I cannot use the command line. How did you update those ports? Did you rebuild them, or install precompiled binary packages? If the latter, where exactly did you retrieve those packages from? -Dimitry From owner-freebsd-stable@FreeBSD.ORG Sat May 18 03:01:36 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 13E78F25 for ; Sat, 18 May 2013 03:01:36 +0000 (UTC) (envelope-from jdc@koitsu.org) Received: from qmta14.emeryville.ca.mail.comcast.net (qmta14.emeryville.ca.mail.comcast.net [IPv6:2001:558:fe2d:44:76:96:27:212]) by mx1.freebsd.org (Postfix) with ESMTP id D599EB23 for ; Sat, 18 May 2013 03:01:35 +0000 (UTC) Received: from omta12.emeryville.ca.mail.comcast.net ([76.96.30.44]) by qmta14.emeryville.ca.mail.comcast.net with comcast id dEP91l0040x6nqcAEF1a6L; Sat, 18 May 2013 03:01:34 +0000 Received: from koitsu.strangled.net ([67.180.84.87]) by omta12.emeryville.ca.mail.comcast.net with comcast id dF1Z1l0061t3BNj8YF1ZkS; Sat, 18 May 2013 03:01:33 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id 086F273A33; Fri, 17 May 2013 20:01:33 -0700 (PDT) Date: Fri, 17 May 2013 20:01:33 -0700 From: Jeremy Chadwick To: Michael Gass Subject: Re: Command line not responding Message-ID: <20130518030132.GA96549@icarus.home.lan> References: <20130517175653.GA15498@csbsju.edu> <20130517185513.GA88287@icarus.home.lan> <20130518024920.GA32753@csbsju.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20130518024920.GA32753@csbsju.edu> User-Agent: Mutt/1.5.21 (2010-09-15) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1368846094; bh=2+GPt91KrSKoQCRlVFMdryG0po6v0o/FvzNUJojMan8=; h=Received:Received:Received:Date:From:To:Subject:Message-ID: MIME-Version:Content-Type; b=b0lD/Zg3Y6SM1VcumORUeO2zRWojZhDE8YITu4ib8U7yuXJNMb0xmgHQtUdBiNkb7 91qe6hTsjfspAUovXx3Mj+NY39L+005AbyVge7HbL0MGY8Y8ff9x5EddgENpmD0JXb Q2/kb73KFwmTzVPcwjIbgqQWT6iUlbrb7LNRSryYeRFwxoth3Wlk4MOLrC5wcKaUeX YXoYEKmL3epZ94+N7kY2jgW9wKxq8RFG0oBOYSoy9c+bd+7p/eeLlH8eFYbh1xUE8k q9GTGJCk9QzHSUnEaR47WXOhzR1+7MawfoDqaGenFHZh2iwfWDheORWMpYkImViF1m KYSLA1fTXAmZA== Cc: freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 18 May 2013 03:01:36 -0000 On Fri, May 17, 2013 at 09:49:20PM -0500, Michael Gass wrote: > On Fri, May 17, 2013 at 11:55:13AM -0700, Jeremy Chadwick wrote: > > On Fri, May 17, 2013 at 12:56:53PM -0500, Michael Gass wrote: > > > Running 9.0-Stable on an i386. > > > > > > Whenever I type a command at the prompt I get > > > the output > > > > > > /usr/local/lib/libintl.so.9: Undefined symbol "_ThreadRuneLocale" > > > > > > and nothing else - the command will not run. Just the > > > above output. Commands like "ls" and "exit" work, but not much > > > else. This happends whether I am logged in a user or as root. > > > Cannot even halt the system from the command line. > > > > > > Started to happen after trying to update the freetype2 port. > > > Got an error msg while updating libXft-2.1.14. From that point > > > on I cannot use the command line. > > > > > > I have no idea what to try. Any suggestions. > > > > > > First provide the contents of /etc/make.conf and /etc/src.conf. > > > > Thanks for getting back to me. Here are the contents of the two > files. I rebuilt the kernel last fall and have updated ports > fairly regularly since. Things have worked fine until today when > I tried to update ports. > > # File: make.conf > # The ? in the below is for buildworld > CPUTYPE?=pentium2 > # Uncomment the below for general builds. > CFLAGS= -O -pipe > # Uncomment the below for kernel builds. > # COPTFLAGS= -O -pipe > NO_PROFILE=true > INSTALL_NODEBUG=true > #WITHOUT_DILLO_IPV6=yes > #WITH_DILLO_DLGUI=yes > # added by use.perl 2013-05-17 11:04:30 > PERL_VERSION=5.12.4 > > # File: src.conf > WITHOUT_PROFILE=true > WITHOUT_BLUETOOTH=true These confs look generally good, meaning there isn't the "messing about" that the other user had. I did catch one thing, however. Speaking strictly about CFLAGS: This should be CFLAGS+= (plus-equals), not CFLAGS= (equals). Otherwise you're effectively overriding CFLAGS for everything, which could cause issues (some portions of the build infrastructure may set or adjust the optimiser flags to something other than -O, and you'd be forcing it to do it anyway). I obviously don't know if that could/would explain the missing symbol issue, but it's still something that's erroneous and major. In general I recommend people *do not* tinker with CFLAGS at all in make.conf -- it's not worth the hassle on i386/amd64 if something goes wrong. If you ever want to know which syntaxes to use (for example, your CPUTYPE?= is correct, and your COPTFLAGS= is correct), review /usr/share/examples/etc/make.conf or src/share/examples/etc/make.conf. Unrelated to all of this (just a useful comment in passing): NO_PROFILE serves no purpose there, just keep WITHOUT_PROFILE=true in src.conf like you have. NO_PROFILE in make.conf would be from "old" FreeBSD days (i.e. prior to src.conf existing). Your src.conf looks fine. Sorry I can't be of more help. :-( -- | Jeremy Chadwick jdc@koitsu.org | | UNIX Systems Administrator http://jdc.koitsu.org/ | | Mountain View, CA, US | | Making life hard for others since 1977. PGP 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Sat May 18 03:02:40 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 39D17EE; Sat, 18 May 2013 03:02:40 +0000 (UTC) (envelope-from MGASS@csbsju.edu) Received: from smtp1.computing.csbsju.edu (smtp1.computing.csbsju.edu [152.65.184.22]) by mx1.freebsd.org (Postfix) with ESMTP id C42E3B6E; Sat, 18 May 2013 03:02:39 +0000 (UTC) X-AuditID: ac10425b-b7f726d000006b64-cf-5196ef4ec546 Received: from Mail-HTCAS1.ad.csbsju.edu (Unknown_Domain [172.16.66.43]) by smtp1.computing.csbsju.edu (Symantec Messaging Gateway) with SMTP id 0C.7E.27492.E4FE6915; Fri, 17 May 2013 22:02:38 -0500 (CDT) Received: from nx.csbsju.edu (172.16.66.48) by MAIL-HTCAS1.ad.csbsju.edu (172.16.66.43) with Microsoft SMTP Server id 14.3.123.3; Fri, 17 May 2013 22:02:38 -0500 Received: by nx.csbsju.edu (Postfix, from userid 1401) id 2FC5618092E; Fri, 17 May 2013 22:02:38 -0500 (CDT) Date: Fri, 17 May 2013 22:02:38 -0500 From: Michael Gass To: Matthew Seaman Subject: Re: Command line not responding Message-ID: <20130518030238.GB32753@csbsju.edu> References: <20130517175653.GA15498@csbsju.edu> <5196783C.1080107@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline In-Reply-To: <5196783C.1080107@FreeBSD.org> User-Agent: Mutt/1.5.21 (2010-09-15) X-Brightmail-Tracker: H4sIAAAAAAAAA11TbUxbZRTm7Re3LS9cboEeCjV4M9kEB4NoNhanhsyFRLdQf+mWOFq4tpW2 dL3tBBcTssEkjGEFZKxmsGUsfswEdEhQ4ti6iXwkVNnsVAbqgoIFwRT5wRaZ9/ZSuOzfyfOc 8zzn430JKXVSpSOsDjfjchhttEIl+4wszN5+YLHVsOP2mW27bpygds0FHypekBS1hTtkxeig 6tkyxmY9yrhynytRWb758D25sw1XVjf+FluNTqnqkZIA8mlYCp9GQpwC3091KeqRiqDIMQTh 2XNSnqDISwhWzzqF2AE1wZ5YPpaRT8CdH31yPlZw8bvfNsrqEUEkkdugs4XhYSmZAd7eW5F0 DQeH//xBxseYzIXQYrtEkCyGms6GNTwRhs9Oy4Tap+B8f1jBS0rJNPholeBhJZkNXzZMRlKS yS3QMtyrEGT00Oq9K/UiyidS8omUfBtK55H0U6Rj7W5nXk5phd3pcVsd5pxS1sS+6clhyjxf IGG/h/pQ+1KeH5EEouPwPy+2Gii58ShbZfejckJC6/CxyRYDpTFVlFVZjKzlMOsx2a0sa61w 0Mk4MM+lx69zLo+NYekkXLfAwXgdNnls5fRjWBX8wEBpRUKs01pqrfCwhz0umx8BIeVKZ1i+ tMxY9TbjqhAE/SiNkNFafKdmvpgizUY3U84wTsYVZd8iCFqPUUxMDJXiYsxM5RtWG/eExJ0C 3su3lCimhWa1uJCfgRQzkX4fx5MFzQZKt1lxc8sSQulHZiKOThXsKdZptLNWs9g6CadFthGl BFsN/ou3jYuiEUs9nuBXlLKhIrYbQUd06XjxBHeNZD7D4nFsnlKnxfG8FSliI266FNx7nCtL EBG8oS4D9/N46iY5sWcI1Uu4dwHCI0jkvuYj02lwAW8Zt8YIw1FYxYPqNTAyWzruj3S+LiG2 ye9EBCIHCKjreQ0GRj9GsBz8QwbN/zXI4cq1Pjk0Lc8oYOiruViou1erhLaLl5XQMbishPmf 76uh6dcRDF0XVzAMec8lwNLY/URYHuug4PPBAQpCD69r4Ze7VwGGe5pSOZVAOvxU7dPDSkdA D12rp2kY/+TMVuibDm6FuuMns6G987tsWFq4mQfBB1/nQ/v4bD4MLDx4JsTdWrJxa7fx0W0k YTl/QBylorfeyaNxUXTt1juEW6+riBeiq0aN02ODq+F39tgzR2aOPa/OStDH77swmjlqfuWW r0h7qrj79tS15hsd+686Sm6+XlO7f09IstLarZ76/UpJRt/uwMShv3cvSl/dciG3sjzBftlk r91eEAgNOb0Hs/ZOeGdnMo+8f2+OGvcNd/c+qfJrdiZVvtSpvq6If/nfZl3R7GhhIS1jLca8 LKmLNf4PiV4UsZkFAAA= Cc: freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 18 May 2013 03:02:40 -0000 On Fri, May 17, 2013 at 07:34:36PM +0100, Matthew Seaman wrote: > On 17/05/2013 18:56, Michael Gass wrote: > > Running 9.0-Stable on an i386. > > > > Whenever I type a command at the prompt I get > > the output > > > > /usr/local/lib/libintl.so.9: Undefined symbol "_ThreadRuneLocale" > > > > and nothing else - the command will not run. Just the > > above output. Commands like "ls" and "exit" work, but not much > > else. This happends whether I am logged in a user or as root. > > Cannot even halt the system from the command line. > > > > Started to happen after trying to update the freetype2 port. > > Got an error msg while updating libXft-2.1.14. From that point > > on I cannot use the command line. > > > > I have no idea what to try. Any suggestions. > > It's only things you installed from ports that would be affected. > There was a problem with the freetype2 port earlier today, but it has > been fixed now. > > Update your ports and try again at updating. > Thanks for getting back to me. I updated the ports tree via portsnap and then tried installing freetype2. Same problem: right the various prebuild checks for things like gcc I get the following lines config.status: executing libtool commands /usr/local/lib/libintl.so.9: Undefined symbol "_ThreadRuneLocale" *** Error code 1 Now, like you said, seems anything installed from ports will not run on the command line. I just get the above error message instead. > Cheers, > > Matthew > > -- > Dr Matthew J Seaman MA, D.Phil. > PGP: http://www.infracaninophile.co.uk/pgpkey > > -- Michael Gass mgass@csbsju.edu From owner-freebsd-stable@FreeBSD.ORG Sat May 18 03:04:28 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 859AE229 for ; Sat, 18 May 2013 03:04:28 +0000 (UTC) (envelope-from MGASS@csbsju.edu) Received: from smtp1.computing.csbsju.edu (smtp1.computing.csbsju.edu [152.65.184.22]) by mx1.freebsd.org (Postfix) with ESMTP id 3CFA5C11 for ; Sat, 18 May 2013 03:04:27 +0000 (UTC) X-AuditID: ac10425b-b7f726d000006b64-59-5196ec30c034 Received: from Mail-HTCAS1.ad.csbsju.edu (Unknown_Domain [172.16.66.43]) by smtp1.computing.csbsju.edu (Symantec Messaging Gateway) with SMTP id 15.6E.27492.03CE6915; Fri, 17 May 2013 21:49:20 -0500 (CDT) Received: from nx.csbsju.edu (172.16.66.48) by MAIL-HTCAS1.ad.csbsju.edu (172.16.66.43) with Microsoft SMTP Server id 14.3.123.3; Fri, 17 May 2013 21:49:20 -0500 Received: by nx.csbsju.edu (Postfix, from userid 1401) id 6D12818092E; Fri, 17 May 2013 21:49:20 -0500 (CDT) Date: Fri, 17 May 2013 21:49:20 -0500 From: Michael Gass To: Jeremy Chadwick Subject: Re: Command line not responding Message-ID: <20130518024920.GA32753@csbsju.edu> References: <20130517175653.GA15498@csbsju.edu> <20130517185513.GA88287@icarus.home.lan> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline In-Reply-To: <20130517185513.GA88287@icarus.home.lan> User-Agent: Mutt/1.5.21 (2010-09-15) X-Brightmail-Tracker: H4sIAAAAAAAAA11TbUxTVxjm9OP2UnrY7aW0r0WMu9Fk2QYCmdEljripmfHHYn9sWXCZtPTS dpTS9bYOdMlEHF9Dx9AxZQxUcDDEmFXGx/hRLGwZkChki4KKw2zKKFQYG9uc2ce9vRQu/rl5 z/Oc93nej3NJOV2lNpIOl5f1uMxOhlAr2qmXnklJm601pd2o3ba1v4Te+uiLV7fLdp9aaFTs rqg4p9wry1Jvs7JOxwHWsykzW23vK2kj3J3rClsrQvLDqNlQiWJJoJ6DD8+WycRYDyN3LhGV SE3S1FUEF65NKsTDeQQ3w2dRJSL5gwvKij1CgoLaCOFAh1KICT4u++a4Qoh11AZomp5QCbGc Wg/Vnd9H4gTqKVi4Pxq5g6lN0PJ1c8SYprKgPRRQibgWBk//rBBzn4UzvQuEYCunkqDlX1KA Y6nNMN/2HyHEibzVycFOQpRJhtrq2/JqRNdJlOokSnUrSmeQvA0ZuXyvOz01pyDf7fM6XLbU HM7CveVLZa0+PxKHvK8bNfyWHkQUiRgNnt9Va6KV5gNcUX4Q5ZEyxogPTZw00QmWAmuR3czZ 93M+S76D4xwFLiYRX5nmr8cvcx6fk+UYHR4M8TBehi0+Zx6zDquvf2yiDRIhzu3IcRT4uP0+ jzOIgJTzqVOckGo1Fx1kPQWiYBAlkQrGgG8cnd1LUzazl81jWTfribLvkCSTjFFMTAyt97A2 tjDX4eTfkbRSwO8LJWmltFisAXuEHigpE6n3STzx/AkTbVytuLpkGRkbRDZSw6wR7WnObc7n HDaptQ6PRqYRpUTbBPyRgGqiaMQyGd8SRqRfUZHaDaG3jWvxXAm/jUThht3nWt2l0YADgigl YSNuRj3uPMKnPSEhBEPjetwr4GtWyUk9Q+gDGf8uQHwEWv7/fKy7BHwx0scSIzZH464ZHoxb AiO9rcW9kcqXJaQ2GecRiajJRAgMtyJorfhKBvfCQzJo/bJFDovX7yngxD9VSrjc162E5j8X ldAwdoyAQLiPgJ7WAQJqFqcIaDhSroLvemZUcHqynIRTTRdi4Zc712Lh+HCpGhpCj9Tw4O79 OJgd/zsObk4f00D9lXoMNT8OYbjU9JD/XC6Ph9ufPYgH/9W/4qGjo1EL3WNNWvCHO2gYn6zX hfhly1aW7TU/Pg4dVgobxFEquuwtAqqJokvLThOXvawinYjxMCqqmSnNHjh4q19v+n1j2ecv Hi2umhtN8m+OGUliVBdzf9jgTx0o3q7pqp1SpbyXWZhxaGfXyLw9q7MkO7wlbUKb+ab318Ey +o/c9tdadvawKbvoPVUvZ7xief1dbeiTgczk0kbrG+d2aB7u+0neOO9Kf2HH5PincLe9v2Ru z/BYxXjet4yCs5vTn5Z7OPP/Ntuyqp8FAAA= Cc: freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 18 May 2013 03:04:28 -0000 On Fri, May 17, 2013 at 11:55:13AM -0700, Jeremy Chadwick wrote: > On Fri, May 17, 2013 at 12:56:53PM -0500, Michael Gass wrote: > > Running 9.0-Stable on an i386. > > > > Whenever I type a command at the prompt I get > > the output > > > > /usr/local/lib/libintl.so.9: Undefined symbol "_ThreadRuneLocale" > > > > and nothing else - the command will not run. Just the > > above output. Commands like "ls" and "exit" work, but not much > > else. This happends whether I am logged in a user or as root. > > Cannot even halt the system from the command line. > > > > Started to happen after trying to update the freetype2 port. > > Got an error msg while updating libXft-2.1.14. From that point > > on I cannot use the command line. > > > > I have no idea what to try. Any suggestions. > > First provide the contents of /etc/make.conf and /etc/src.conf. > Thanks for getting back to me. Here are the contents of the two files. I rebuilt the kernel last fall and have updated ports fairly regularly since. Things have worked fine until today when I tried to update ports. # File: make.conf # The ? in the below is for buildworld CPUTYPE?=pentium2 # Uncomment the below for general builds. CFLAGS= -O -pipe # Uncomment the below for kernel builds. # COPTFLAGS= -O -pipe NO_PROFILE=true INSTALL_NODEBUG=true #WITHOUT_DILLO_IPV6=yes #WITH_DILLO_DLGUI=yes # added by use.perl 2013-05-17 11:04:30 PERL_VERSION=5.12.4 # File: src.conf WITHOUT_PROFILE=true WITHOUT_BLUETOOTH=true > The _ThreadRuneLocale thing has come up before, but on -CURRENT circa > early 2012. It happened to a user when trying to build kernel (really) > and that user was tinkering about in make.conf and src.conf heavily, > messing with Clang. I personally remove Clang from my systems entirely > for many reasons, by simply doing WITHOUT_CLANG=true in src.conf and > thus rely entirely on gcc. > > My recommendation, and this isn't going to make you happy: > I may do this if I cannot get things to work otherwise. I appreciate the advice. > Boot into single-user, mount your filesystems, and try commands there, > in hopes that they work. If they do: > > pkg_delete -a -f > cp -pR /usr/local /usr/local.old > rm -fr /usr/local/* > reboot > > Boot into multi-user, log in, and things should be fine. Next: > > rm -fr /var/db/ports/* > rm -fr /usr/ports/distfiles/* > find /usr/ports -type d -name "work" -exec rm -fr {} \; > > Now begin rebuilding your ports. If you prefer to use packages, go > right ahead, given that this was just announced a few days ago: > > http://lists.freebsd.org/pipermail/freebsd-announce/2013-May/001476.html > > But I tend to build everything from source, barring large-ish packages > (things like cmake, python27, perl) which I pkg_add -r. > > My attitude has always been when something catastrophic impacts a very > large number of commands (particularly a library with a missing symbol > that a very large number of programs link to), start fresh. It's > not worth scrambling around with leftover cruft in place that could > appear months later and make you say "I thought I fixed that!", where > you then have to follow up to a thread months old and admit "actually > there is more breakage..." > > Footnote: I am likely to get a large amount of backlash for proposing > the above, with claims that will equate it to fixing a minor cut by > amputating the entire limb. My response to such: that's nice. > > -- > | Jeremy Chadwick jdc@koitsu.org | > | UNIX Systems Administrator http://jdc.koitsu.org/ | > | Mountain View, CA, US | > | Making life hard for others since 1977. PGP 4BD6C0CB | -- Michael Gass mgass@csbsju.edu From owner-freebsd-stable@FreeBSD.ORG Sat May 18 03:20:38 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 4E56E4C8; Sat, 18 May 2013 03:20:38 +0000 (UTC) (envelope-from MGASS@csbsju.edu) Received: from smtp1.computing.csbsju.edu (smtp1.computing.csbsju.edu [152.65.184.22]) by mx1.freebsd.org (Postfix) with ESMTP id D9049D41; Sat, 18 May 2013 03:20:37 +0000 (UTC) X-AuditID: ac10425b-b7f726d000006b64-65-5196f384a734 Received: from Mail-HTCAS2.ad.csbsju.edu (Unknown_Domain [172.16.66.44]) by smtp1.computing.csbsju.edu (Symantec Messaging Gateway) with SMTP id 04.9E.27492.483F6915; Fri, 17 May 2013 22:20:36 -0500 (CDT) Received: from nx.csbsju.edu (172.16.66.48) by MAIL-HTCAS2.ad.csbsju.edu (172.16.66.44) with Microsoft SMTP Server id 14.3.123.3; Fri, 17 May 2013 22:20:36 -0500 Received: by nx.csbsju.edu (Postfix, from userid 1401) id 590FF18092E; Fri, 17 May 2013 22:20:36 -0500 (CDT) Date: Fri, 17 May 2013 22:20:36 -0500 From: Michael Gass To: Dimitry Andric Subject: Re: Command line not responding Message-ID: <20130518032036.GD32753@csbsju.edu> References: <20130517175653.GA15498@csbsju.edu> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-Brightmail-Tracker: H4sIAAAAAAAAA11TbUxTZxTmbQvelr7jcoH2cBXCbliyGERwEjAuiDO4xV/WH8s2krFCL21H W7reVmVLnCBIEOcahlVYQBZ04kS+klWkfozuA4oyRDM3md32w2kCRrTo4jKB3dtL4eK/k+c5 53nOx/sScqpORRNmm5N12PQWJkal6CLfyFhXM+vRZY1NrM07eegyyvv+AFUge+t46IRiJ3pP 9bqBtZh3s471+R+oTO2/3ET2f1R7u9tH0H7UQxxCSgLIjXCpe0Auxhq4/kdPjBBT5M8IPp/g cRUfn0LgubewSiRsMHP4UrhAQb4C/VOTYTyGj+t+PKIQ4kQyHeZaLoaF5GQauL03wzkJ5KsQ ujcRzsHkejh4+Hm0qGmAuuqv5SIeD4HmuwqxNgPafSFeh+Dj1XB6nhBCJbkF+lqLhIwk3qkp 4F1sOQU87jtyN6JaJEItEqGWZaF2JP8G0ZzVac/OLK2w2l1Os82YWcqVcB+6MlmDqx+J+y0a QG2z2X5EEohR40eFHh0Vrd/NVVr9qJyQMTT+JNikoxJKKgyVJj1nKuZcJVYzx5krbEwSVj3m 019a4hwuC8sxiTiOvxiFl+ASl6WcScWqW0d1lFYixNnNpeYKF1fsclj8CAg5X3qfE0oN+sqP WUeFKOhHqwkFo8W/1jzYSZFGvZMtZ1k764iwewiCScEoKiqK0jhYI7u3zGzhn5C0U8CFIV43 XkqLzWrxXWEGUsqE+30ZBzd9oaPolYorW5YRSj8yEmomWbSnOLveypmNUutEPCZY4wgl2ibg ZsFWHUHDlin4d2FFmmUVqd0o+oheg2cO8NdIEjJMLtvKKWktHhKsSAkbdqM12FvNl8VJCMGQ TsM+AU9eISf1nEINMv5dgPgI4vmv+cJ0CbhTsFQvMuJwFC57xIOxi2B4tjXYF+58SUJqs+EU IhA5GA2zMz8o4OmtvxXQ+PR+DIxcmF4Fz75bIOB4x1kl+H66EAv1XTdiofHPUQw9Hf9iGHG3 xsHUwpAWJu9cBpjvvkhDz/xnDASeHM2Ex33XsuDKw/9y4MxZby74T1blQX9922Z4XnduMzRV h/Jh/kZfAVwZ8xZA15OrW2Gk8/Y2mBz/awf8drBBB41Tp3dBfajzXfB1DhdN8ceWLR/bqX9x HYk4WrggjlCRY+cKqDqCLh47Szz2kop0I/R+pBoPltmSFalz/c3BOc9YT1USU7th11f+XBLn t+XsyRmYToY3g9ma2n2+4V5NonK4r/ftzPdrBof6bBvPjR+7/jAw+uzbwnT3a9vP3y7esq0j INNpjtHTA+evnRnd986n6x5sPzL4ZVV6efrVrowaalOqtTeqIbk2rZWIy9qaHa8/wSg4kz57 rdzB6f8HSAsofJoFAAA= Cc: freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 18 May 2013 03:20:38 -0000 On Fri, May 17, 2013 at 09:26:58PM +0200, Dimitry Andric wrote: > On May 17, 2013, at 19:56, Michael Gass wrote: > > Running 9.0-Stable on an i386. > > > > Whenever I type a command at the prompt I get > > the output > > > > /usr/local/lib/libintl.so.9: Undefined symbol "_ThreadRuneLocale" > > > > and nothing else - the command will not run. > > Are you running bash, by any chance? Because bash is usually linked to > libintl, for its internationalized messages. > Not running bash. Running csh. > In any case, it looks like there is a mismatch between your libc.so, and > your ports. Did you recently update your base system? > Updated the ports tree with portsnap and was in the process of updating my ports when the problem occurred with updating freetype2. > > > Started to happen after trying to update the freetype2 port. > > Got an error msg while updating libXft-2.1.14. From that point > > on I cannot use the command line. > > How did you update those ports? Did you rebuild them, or install > precompiled binary packages? If the latter, where exactly did you > retrieve those packages from? > I use portmaster with the -P option to use a package if available. So some are built and some are downloaded as packages. Thanks for getting back to me. -- Michael Gass mgass@csbsju.edu From owner-freebsd-stable@FreeBSD.ORG Sat May 18 10:14:34 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id E3303433 for ; Sat, 18 May 2013 10:14:34 +0000 (UTC) (envelope-from ronald-freebsd8@klop.yi.org) Received: from smarthost1.greenhost.nl (smarthost1.greenhost.nl [195.190.28.78]) by mx1.freebsd.org (Postfix) with ESMTP id 7B02DA6D for ; Sat, 18 May 2013 10:14:33 +0000 (UTC) Received: from smtp.greenhost.nl ([213.108.104.138]) by smarthost1.greenhost.nl with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from ) id 1Ude9m-0003GE-GU; Sat, 18 May 2013 12:14:31 +0200 Received: from dhcp-077-251-158-153.chello.nl ([77.251.158.153] helo=ronaldradial) by smtp.greenhost.nl with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1Ude9k-0003Ou-T4; Sat, 18 May 2013 12:14:28 +0200 Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes To: "dennis berger" , "Jeremy Chadwick" Subject: Re: still mbuf leak in 9.0 / 9.1? References: <004BC6EA-D8E6-473E-851C-9CDA7578510A@nipsi.de> <20130515211436.GA42790@icarus.home.lan> <696B5622-A95D-4187-A027-07ECC9B5AD1F@nipsi.de> <4F319A22-E611-4EE6-A970-98315B15C12F@nipsi.de> <1186B7CE-EC84-42F6-8904-EDD0C4A5FFBD@bsdsystems.de> <20130517173101.GB87223@icarus.home.lan> Date: Sat, 18 May 2013 12:14:28 +0200 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit From: "Ronald Klop" Message-ID: In-Reply-To: <20130517173101.GB87223@icarus.home.lan> User-Agent: Opera Mail/12.15 (Win32) X-Virus-Scanned: by clamav at smarthost1.samage.net X-Spam-Level: / X-Spam-Score: 0.8 X-Spam-Status: No, score=0.8 required=5.0 tests=BAYES_50 autolearn=disabled version=3.3.1 X-Scan-Signature: a9e4b997d6a751f3e45cb47a3c2b1d2c Cc: Steven Hartland , FreeBSD stable X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 18 May 2013 10:14:34 -0000 On Fri, 17 May 2013 19:31:01 +0200, Jeremy Chadwick wrote: > On Fri, May 17, 2013 at 11:37:23AM +0200, dennis berger wrote: >> Hi List, >> I can confirm that it is the bug you mentioned steven. >> Here is how I found it. >> >> I recorded hourly zfskern and nfsd stats. like this. >> >> echo "PROCSTAT" >> $reportname >> pgrep -S "(zfskern|nfsd)" | xargs procstat -kk >> $reportname >> >> luckily it crashed this night and logged this. >> >> 1910 101508 nfsd nfsd: service mi_switch+0x186 >> sleepq_wait+0x42 _sleep+0x376 arc_lowmem+0x77 kmem_malloc+0xc1 >> uma_large_malloc+0x4a malloc+0xd9 arc_get_data_buf+0xb5 >> arc_read_nolock+0x1ec arc_read+0x93 dbuf_prefetch+0x12c >> dmu_zfetch_dofetch+0x10b dmu_zfetch+0xaf8 dbuf_read+0x4a7 >> dmu_buf_hold_array_by_dnode+0x16b dmu_buf_hold_array+0x67 >> dmu_read_uio+0x3f zfs_freebsd_read+0x3e3 >> >> Maybe it would be good to merge this fix into RELENG_9_1 and distribute >> a fix via freebsd-update what do you think? >> >> best, >> -dennis >> >> >> Am 16.05.2013 um 11:42 schrieb dennis berger: >> >> > This is indeed a ZFS+NFS system and I can see that istgt and nfs are >> stuck in some ZIO state. Maybe it's this. >> > Thank's for pointing out. >> > >> > Is it this ZFS+NFS deadlock? >> > >> > --- a/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/arc.c >> > +++ b/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/arc.c >> > @@ -3720,8 +3720,16 @@ arc_lowmem(void *arg __unused, int howto >> __unused) >> > mutex_enter(&arc_reclaim_thr_lock); >> > needfree = 1; >> > cv_signal(&arc_reclaim_thr_cv); >> > - while (needfree) >> > - msleep(&needfree, &arc_reclaim_thr_lock, 0, "zfs:lowmem", 0); >> > + >> > + /* >> > + * It is unsafe to block here in arbitrary threads, because we can >> come >> > + * here from ARC itself and may hold ARC locks and thus risk a >> deadlock >> > + * with ARC reclaim thread. >> > + */ >> > + if (curproc == pageproc) { >> > + while (needfree) >> > + msleep(&needfree, &arc_reclaim_thr_lock, 0, "zfs:lowmem", 0); >> > + } >> > mutex_exit(&arc_reclaim_thr_lock); >> > mutex_exit(&arc_lowmem_lock); >> > } >> > >> > I'll try to crash our testsystem. I'll assume that stressing NFS >> backed with ZFS a lot might trigger this bug? >> > >> > -dennis >> > >> > >> > Am 16.05.2013 um 00:03 schrieb Steven Hartland: >> > >> >> ----- Original Message ----- From: "dennis berger" >> >>> FreeBSD 9.1-RELEASE FreeBSD 9.1-RELEASE #0 r243825: Tue Dec 4 >> 09:23:10 UTC 2012 >> >>> >> >>>> 3. Regarding this: >> >>>>>> A clean shutdown isn't possible though. It hangs after vnode >> >>>>>> cleaning, normally you would see detaching of usb devices here, >> or >> >>>>>> other devices maybe? >> >>>> Please don't conflate this with your above issue. This is almost >> >>>> certainly unrelated. Please start a new thread about that if >> desired. >> >>> >> >>> Maybe this is a misunderstanding normally this system will shutdown >> cleanly, of course. >> >>> This hang only appears after the network problem above. >> >> >> >> If this is a ZFS system, its a known issue which is fixed in current, >> >> stable-9, stable-8 and the upcoming 8.4 release. >> >> >> >> If not and you have USB devices see if the following sysctl helps: >> >> hw.usb.no_shutdown_wait=1 > > I'm sorry to say it won't happen. The only updates that the -RELEASE > branches get are for security. If you want fixes for other things, you > need to follow/run stables branches (i.e. stable/9), otherwise you will > need to wait until 9.2-RELEASE comes out. > And errata notices? Are they for security? Ronald. From owner-freebsd-stable@FreeBSD.ORG Sat May 18 15:35:40 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 87C1EB0D for ; Sat, 18 May 2013 15:35:40 +0000 (UTC) (envelope-from jdc@koitsu.org) Received: from qmta14.emeryville.ca.mail.comcast.net (qmta14.emeryville.ca.mail.comcast.net [IPv6:2001:558:fe2d:44:76:96:27:212]) by mx1.freebsd.org (Postfix) with ESMTP id 5C8306EA for ; Sat, 18 May 2013 15:35:40 +0000 (UTC) Received: from omta01.emeryville.ca.mail.comcast.net ([76.96.30.11]) by qmta14.emeryville.ca.mail.comcast.net with comcast id dTPr1l0040EPchoAETbfm8; Sat, 18 May 2013 15:35:39 +0000 Received: from koitsu.strangled.net ([67.180.84.87]) by omta01.emeryville.ca.mail.comcast.net with comcast id dTbe1l00Y1t3BNj8MTbePZ; Sat, 18 May 2013 15:35:39 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id 7E97773A33; Sat, 18 May 2013 08:35:38 -0700 (PDT) Date: Sat, 18 May 2013 08:35:38 -0700 From: Jeremy Chadwick To: Ronald Klop Subject: Re: still mbuf leak in 9.0 / 9.1? Message-ID: <20130518153538.GA9228@icarus.home.lan> References: <004BC6EA-D8E6-473E-851C-9CDA7578510A@nipsi.de> <20130515211436.GA42790@icarus.home.lan> <696B5622-A95D-4187-A027-07ECC9B5AD1F@nipsi.de> <4F319A22-E611-4EE6-A970-98315B15C12F@nipsi.de> <1186B7CE-EC84-42F6-8904-EDD0C4A5FFBD@bsdsystems.de> <20130517173101.GB87223@icarus.home.lan> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1368891339; bh=H8oHoGHxSo4yXfgxvoE5To5HO+ns2GFDoobENtX/Z7g=; h=Received:Received:Received:Date:From:To:Subject:Message-ID: MIME-Version:Content-Type; b=QrW4HpYq2QV+zVnrAIz0ofWBhEOFpOZPg+noJVsIoBkQCc/URebKUetWwTUOUv7CN SGdKMLdltvqxVjNFKFaDTJpiaPU6cfabAdCTiufUutq3uRwgnQnyGAGUyQhZH05FHh U+9fEKsACXoCK17edf0kvJlBrsg+9Bm4bLK94HxaOZwCTAKZf7+owpYswobMdYwTmY 2qZu0eKQDBUKj4CCbBIgyigPgI9rYEcuA6lgUOzD7h2Z+dnGGc75g1ACpLa80kR0ta HrHqiGinAix+QBuvnHrml9PUuR1gC0Gi/0f7pQW7oUDE6jaMPktMmkrMSjpy/FhjF1 hOmRex2Yxp5Eg== Cc: FreeBSD stable , dennis berger , Steven Hartland X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 18 May 2013 15:35:40 -0000 On Sat, May 18, 2013 at 12:14:28PM +0200, Ronald Klop wrote: > On Fri, 17 May 2013 19:31:01 +0200, Jeremy Chadwick wrote: > > >On Fri, May 17, 2013 at 11:37:23AM +0200, dennis berger wrote: > >>Hi List, > >>I can confirm that it is the bug you mentioned steven. > >>Here is how I found it. > >> > >>I recorded hourly zfskern and nfsd stats. like this. > >> > >>echo "PROCSTAT" >> $reportname > >>pgrep -S "(zfskern|nfsd)" | xargs procstat -kk >> $reportname > >> > >>luckily it crashed this night and logged this. > >> > >> 1910 101508 nfsd nfsd: service mi_switch+0x186 > >>sleepq_wait+0x42 _sleep+0x376 arc_lowmem+0x77 kmem_malloc+0xc1 > >>uma_large_malloc+0x4a malloc+0xd9 arc_get_data_buf+0xb5 > >>arc_read_nolock+0x1ec arc_read+0x93 dbuf_prefetch+0x12c > >>dmu_zfetch_dofetch+0x10b dmu_zfetch+0xaf8 dbuf_read+0x4a7 > >>dmu_buf_hold_array_by_dnode+0x16b dmu_buf_hold_array+0x67 > >>dmu_read_uio+0x3f zfs_freebsd_read+0x3e3 > >> > >>Maybe it would be good to merge this fix into RELENG_9_1 and > >>distribute a fix via freebsd-update what do you think? > >> > >>best, > >>-dennis > >> > >> > >>Am 16.05.2013 um 11:42 schrieb dennis berger: > >> > >>> This is indeed a ZFS+NFS system and I can see that istgt and > >>nfs are stuck in some ZIO state. Maybe it's this. > >>> Thank's for pointing out. > >>> > >>> Is it this ZFS+NFS deadlock? > >>> > >>> --- a/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/arc.c > >>> +++ b/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/arc.c > >>> @@ -3720,8 +3720,16 @@ arc_lowmem(void *arg __unused, int > >>howto __unused) > >>> mutex_enter(&arc_reclaim_thr_lock); > >>> needfree = 1; > >>> cv_signal(&arc_reclaim_thr_cv); > >>> - while (needfree) > >>> - msleep(&needfree, &arc_reclaim_thr_lock, 0, "zfs:lowmem", 0); > >>> + > >>> + /* > >>> + * It is unsafe to block here in arbitrary threads, because > >>we can come > >>> + * here from ARC itself and may hold ARC locks and thus risk > >>a deadlock > >>> + * with ARC reclaim thread. > >>> + */ > >>> + if (curproc == pageproc) { > >>> + while (needfree) > >>> + msleep(&needfree, &arc_reclaim_thr_lock, 0, "zfs:lowmem", 0); > >>> + } > >>> mutex_exit(&arc_reclaim_thr_lock); > >>> mutex_exit(&arc_lowmem_lock); > >>> } > >>> > >>> I'll try to crash our testsystem. I'll assume that stressing > >>NFS backed with ZFS a lot might trigger this bug? > >>> > >>> -dennis > >>> > >>> > >>> Am 16.05.2013 um 00:03 schrieb Steven Hartland: > >>> > >>>> ----- Original Message ----- From: "dennis berger" > >>>>> FreeBSD 9.1-RELEASE FreeBSD 9.1-RELEASE #0 r243825: Tue Dec > >>4 09:23:10 UTC 2012 > >>>>> > >>>>>> 3. Regarding this: > >>>>>>>> A clean shutdown isn't possible though. It hangs after vnode > >>>>>>>> cleaning, normally you would see detaching of usb devices > >>here, or > >>>>>>>> other devices maybe? > >>>>>> Please don't conflate this with your above issue. This is almost > >>>>>> certainly unrelated. Please start a new thread about that > >>if desired. > >>>>> > >>>>> Maybe this is a misunderstanding normally this system will > >>shutdown cleanly, of course. > >>>>> This hang only appears after the network problem above. > >>>> > >>>> If this is a ZFS system, its a known issue which is fixed in current, > >>>> stable-9, stable-8 and the upcoming 8.4 release. > >>>> > >>>> If not and you have USB devices see if the following sysctl helps: > >>>> hw.usb.no_shutdown_wait=1 > > > >I'm sorry to say it won't happen. The only updates that the -RELEASE > >branches get are for security. If you want fixes for other things, you > >need to follow/run stables branches (i.e. stable/9), otherwise you will > >need to wait until 9.2-RELEASE comes out. > > > > And errata notices? Are they for security? Example case: http://www.freebsd.org/releases/9.1R/errata.html Only the items in section "Security Advisories" would get actual updates pushed out to the 9.1-RELEASE branch (e.g. RELENG_9_1); the items in sections "Open Issues" and "Late-breaking News" are purely FYIs. There are always hundreds of bugs that never show up in either of those sections but are mentioned in the next official versions' Release Notes. I can speculate all day and night as to why this is, but it's easier for me to just say "that's just the way it is". For example, compare the "Open Issues" in the 9.0-RELEASE errata to all the bugfixes in the 9.1-RELEASE Release Notes (you'll have to go through each item by hand and read it): http://www.freebsd.org/releases/9.0R/errata.html http://www.freebsd.org/releases/9.1R/relnotes-detailed.html ...and you'll see what I mean. So to recap: when you run a -RELEASE branch, you should only expect fixes related to security. For any other problems, you are expected to run stable/X (e.g. stable/9) or get to backport the fix yourself. And because I am certain someone will bring it up: no, the fixes done in stable/X cannot necessarily be turned into a patch file for a -RELEASE branch. The reason is that there are often other commits to stable/X branches which are for things other than bugfixes (i.e. re-engineering/refactoring of code, semantics changes, or entire portions nuked altogether). Sometimes "backported" patches can be made, but it isn't always the case -- it is not always as simple as "the patch applied cleanly". ZFS and NFS are two (of many) things which have been undergoing constant change. -- | Jeremy Chadwick jdc@koitsu.org | | UNIX Systems Administrator http://jdc.koitsu.org/ | | Mountain View, CA, US | | Making life hard for others since 1977. PGP 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Sat May 18 18:49:12 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id B620B599 for ; Sat, 18 May 2013 18:49:12 +0000 (UTC) (envelope-from MGASS@csbsju.edu) Received: from smtp1.computing.csbsju.edu (smtp1.computing.csbsju.edu [152.65.184.22]) by mx1.freebsd.org (Postfix) with ESMTP id 60DD1E29 for ; Sat, 18 May 2013 18:49:11 +0000 (UTC) X-AuditID: ac10425b-b7f726d000006b64-1e-5197cd26ba51 Received: from Mail-HTCAS2.ad.csbsju.edu (Unknown_Domain [172.16.66.44]) by smtp1.computing.csbsju.edu (Symantec Messaging Gateway) with SMTP id 54.45.27492.62DC7915; Sat, 18 May 2013 13:49:10 -0500 (CDT) Received: from nx.csbsju.edu (172.16.66.48) by MAIL-HTCAS2.ad.csbsju.edu (172.16.66.44) with Microsoft SMTP Server id 14.3.123.3; Sat, 18 May 2013 13:49:09 -0500 Received: by nx.csbsju.edu (Postfix, from userid 1401) id 00AA718092E; Sat, 18 May 2013 13:49:09 -0500 (CDT) Date: Sat, 18 May 2013 13:49:09 -0500 From: Michael Gass To: Subject: Is there a library issue between 9.0 and 9.1 -ThreadRuneLocale ? Message-ID: <20130518184909.GA23083@csbsju.edu> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) X-Brightmail-Tracker: H4sIAAAAAAAAA11Tf0wbZRjma0t3sH7uekB5OcBsF1HR8XMmYmIMMZowlygkC4kaZAcc7Y3S Nr2WDaKmgzF+KAgIAzFhS9BAGGRhm4AyttBlCh3IXHTIhmwkTOIcGz/cxvYH8b6WwrH/nnue e9/ned97j1Izq0EsJVocgt3CmzltsKabfnt33IvjzRmJK8NsyqUyJhWltSyf0KSjj4LfzBPM YpFgT3jrQLBp9kIbstVoDv/TOaF2oS/U1YiigH4N/nqqr0ZBMjTA1ZnT2moUTDH0rwh+nJlG vofvEXgWVgLJWwxtgauPxhHBGjoGuh4/UhGslXHF5VoNwaH0TjhS0aIlOITeC672G14e0wkw 9FUZ8mE9jH4z5+XV9G44ObisJYHUdCR0rFGEDqNfgMbRPq3PNhqO102r69COVkV1q6K6dbP6 JFJ3IVYqdNiS4nOthTanQ7QY43OlHOmgM17Ic55Bvr19PIDaVpLciKYQp8OL7x7PYAL5Iqm4 0I0KKBXH4tLK5gwmJMeaV2ziJVO25MwpFCVJtFq4MMx7ZO25Dc3uNAsSF4qPXZFpvEHnOM0F 3PM4+HpTBhOuaCTZxFzR6pSynXazGwGllkvLM0lpHl9cItitvoZuFElpuHA8efReOkMbeYdQ IAg2we5XD1EUF41RQEAAY7ALRuFwvmiWT0OZFHAdiaRXyr6w4TiSzEArFW/eXbgzVhbYrR23 RlZRQW5kpHRchM+ekWx8oSQaldahOH6MjOSXfLYh2EkC6fys1zIa3yQrMmx2Udp50GfUL+ca 7yNGY7FaBDYKPyhrzGDCyNsmp2XrxGw4vk0MaIXqdWYNuK9ULtuhEIg5uxMPEj5iSzul/13U opJvBPARchB6+fd7ZtIQPOedaV3xDcrgQ4Tcvk5654zCg97kGy2UNslnEIXof1Xw8PodDTwZ rsTQcMuD4XT7ExnNVNGw6moPhdFzDRHQUDPEwlJvRyxcHO+Lg7PH6tPh6PzjTKha7vwQzo8s fgJNsz1GWC79QYS6sSobdD9dKIHfF+6XwMPb82UIvhzqr0Aw4umtRDBxZ7VWxov99Qj+7LnU hGC6a6QVwdzUtW9l5ucbbQgGJpdOISitvzWMYK323ggiacbQXfkKVJtX4OCf3U0oDiSfFvsl /xW8Tlidn12/gkTfFWx0Ua6HdaF3GmIvz008GLi21x2YYNDbpxINWTG/pe3q1Oh6Pbp979cs GbelZE51p71a3ZiWFMN3nS+KTskezAr8I3lPrO1ifvra8Mv7v17Lynec3V7xeXODy8PUdfSU 30z96Ur5hbTqyakP5iOiDh44Mc1lvfT37KdvRIqj2/qTxe8sce/pUvdk/8dpJBOf9IraLvH/ AzPP6YiLBQAA X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 18 May 2013 18:49:12 -0000 Cannot update my ports. Run portsnap followed by portmaster -a and various ports will not update. Keep getting error msg of Undefined symbol: "_ThreadRuneLocale" This happens for instance in updating to png-1.5.15 or to freetype2. Are there library issues between 9.0 and 9.1? I am running 9.0-stable on an i386 Last time I updated was in March and that went well. Do I need to uninstall all my ports and start over? Do I need to move up to 9.1? -- Michael Gass mgass@csbsju.edu