From owner-freebsd-current@FreeBSD.ORG Sun Oct 25 00:47:04 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BD5CC1065694; Sun, 25 Oct 2009 00:47:04 +0000 (UTC) (envelope-from mavbsd@gmail.com) Received: from mail-fx0-f210.google.com (mail-fx0-f210.google.com [209.85.220.210]) by mx1.freebsd.org (Postfix) with ESMTP id F1DEE8FC15; Sun, 25 Oct 2009 00:47:03 +0000 (UTC) Received: by fxm6 with SMTP id 6so10598596fxm.43 for ; Sat, 24 Oct 2009 17:47:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :user-agent:mime-version:to:cc:subject:x-enigmail-version :content-type; bh=Jgo1oz91UzhC843uO4oDPHCEx3xYbfGTO5obJor8JiY=; b=NMyVlcMhjlrx1g4JF1b23Rqb68DpBNJoryQGkuPvphDF/FdDed6Maz1ry1bh2qh+Jj LKaa/AAdEvQ6w+6SKUfiTa4I0u5FxiwrNNpStU7Weego9uzlYc9iRcQ2BfKRKE3xmqIt 5x9X+j4O62k19ghfoHJCyr1sBPoi611zel79w= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :x-enigmail-version:content-type; b=N7esZVe7qQIxTvIkTUn/ymbu2aHA+uvRqTV+YAkTaTRzDQjpH/Mm86IUUsKScqqPzJ Cz5hYVHNUKlkpRJOLpwC4iZQzmLNkMKbtykBfdvP0XNnuvXn5L2zUCTN+5QhysgF9Q3I okd7cTSdTrTMo/Kj2OjFCrj8P2VwR4GFzKgGQ= Received: by 10.103.127.32 with SMTP id e32mr1830525mun.70.1256431622913; Sat, 24 Oct 2009 17:47:02 -0700 (PDT) Received: from mavbook.mavhome.dp.ua (pc.mavhome.dp.ua [212.86.226.226]) by mx.google.com with ESMTPS id 7sm9023256mup.42.2009.10.24.17.46.58 (version=SSLv3 cipher=RC4-MD5); Sat, 24 Oct 2009 17:47:02 -0700 (PDT) Sender: Alexander Motin Message-ID: <4AE3A001.8000205@FreeBSD.org> Date: Sun, 25 Oct 2009 03:46:57 +0300 From: Alexander Motin User-Agent: Thunderbird 2.0.0.23 (X11/20090901) MIME-Version: 1.0 To: FreeBSD-Current X-Enigmail-Version: 0.96.0 Content-Type: multipart/mixed; boundary="------------040203050503000402040302" Cc: icegloom dem , FreeBSD Stable , freebsd-amd64@freebsd.org Subject: MCP55 SATA solution to test X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Oct 2009 00:47:04 -0000 This is a multi-part message in MIME format. --------------040203050503000402040302 Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: 7bit Hi. Thanks to one man who provided access to his machine, I seem to found how to fix device detection on nVidia MCP55 SATA controller on amd64 8.0. Looks like this controller need some time (very short) to enable BAR(5) memory access after PCI configuration register written. Probably some changes in PCI code exposed this issue. Also it explains why setting hw.pci.mcfg to 0 helps. Attached patch solves problem for that machine. Testers are welcome. -- Alexander Motin --------------040203050503000402040302 Content-Type: text/plain; name="mcp55.sata.patch" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="mcp55.sata.patch" --- ata-nvidia.c.prev 2009-10-25 03:13:57.000000000 +0300 +++ ata-nvidia.c 2009-10-25 03:15:52.000000000 +0300 @@ -165,7 +165,8 @@ ata_nvidia_chipinit(device_t dev) /* enable control access */ pci_write_config(dev, 0x50, pci_read_config(dev, 0x50, 1) | 0x04,1); - + /* MCP55 seems to need some time to allow r_res2 read. */ + DELAY(10); if (ctlr->chip->cfg1 & NVQ) { /* clear interrupt status */ ATA_OUTL(ctlr->r_res2, offset, 0x00ff00ff); --------------040203050503000402040302-- From owner-freebsd-current@FreeBSD.ORG Sun Oct 25 02:00:54 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5EBA0106566B for ; Sun, 25 Oct 2009 02:00:54 +0000 (UTC) (envelope-from wblock@wonkity.com) Received: from wonkity.com (wonkity.com [67.158.26.137]) by mx1.freebsd.org (Postfix) with ESMTP id 1E7108FC0C for ; Sun, 25 Oct 2009 02:00:53 +0000 (UTC) Received: from wonkity.com (localhost [127.0.0.1]) by wonkity.com (8.14.3/8.14.3) with ESMTP id n9P20rRH023974 for ; Sat, 24 Oct 2009 20:00:53 -0600 (MDT) (envelope-from wblock@wonkity.com) Received: from localhost (wblock@localhost) by wonkity.com (8.14.3/8.14.3/Submit) with ESMTP id n9P20rP4023971 for ; Sat, 24 Oct 2009 20:00:53 -0600 (MDT) (envelope-from wblock@wonkity.com) Date: Sat, 24 Oct 2009 20:00:53 -0600 (MDT) From: Warren Block To: current@freebsd.org Message-ID: User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.2 (wonkity.com [127.0.0.1]); Sat, 24 Oct 2009 20:00:53 -0600 (MDT) Cc: Subject: Creating /dev links to dynamic devices X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Oct 2009 02:00:54 -0000 devfs.conf allows creating static device links: link acd0 cdrom This only runs on devfs startup, so it's useless for creating a link to a dynamic device. The specific example is for scanners. My scanner is ugen2.3, but only as long as it is plugged into the same USB hub/port each time. I can manually create a uscanner0 link in /dev with devd.conf: attach 20 { device-name "ugen[0-9]+"; match "vendor" "0x04b8"; match "product" "0x010a"; action "/bin/ln -sf /dev/$device-name /dev/uscanner0; /sbin/devfs rule applyset"; }; Using /dev/uscanner0 then works in place of ugen2.3. Now the second part of the example: I want devd to recognize the attach or creation of uscanner0. But it's not a true devfs device; devd doesn't see an attach event, or a notify CDEV/CREATE event. Is there a method to create a true devfs link to a dynamic device? -Warren Block * Rapid City, South Dakota USA From owner-freebsd-current@FreeBSD.ORG Sun Oct 25 02:29:48 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9CD05106566B for ; Sun, 25 Oct 2009 02:29:48 +0000 (UTC) (envelope-from doug@polands.org) Received: from hrndva-omtalb.mail.rr.com (hrndva-omtalb.mail.rr.com [71.74.56.122]) by mx1.freebsd.org (Postfix) with ESMTP id 5E83B8FC0C for ; Sun, 25 Oct 2009 02:29:48 +0000 (UTC) Received: from haran.polands.org ([75.87.219.217]) by hrndva-omta02.mail.rr.com with ESMTP id <20091025021016351.LBCR1670@hrndva-omta02.mail.rr.com> for ; Sun, 25 Oct 2009 02:10:16 +0000 Received: from email.polands.org (ammon.polands.org [172.16.1.7]) by haran.polands.org (8.14.3/8.14.3) with ESMTP id n9P2AFbd067846 for ; Sat, 24 Oct 2009 21:10:15 -0500 (CDT) (envelope-from doug@polands.org) Received: from 172.16.1.37 (SquirrelMail authenticated user djp) by email.polands.org with HTTP; Sat, 24 Oct 2009 21:10:15 -0500 Message-ID: <46e678eb1eeca98033b15979e034a765.squirrel@email.polands.org> Date: Sat, 24 Oct 2009 21:10:15 -0500 From: "Doug Poland" To: freebsd-current@freebsd.org User-Agent: SquirrelMail/1.4.20-RC2 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Subject: Fatal trap 12 on ZFS in 8.0-RC1 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Oct 2009 02:29:48 -0000 Hello, I'm experimenting with ZFS on 8-0-RC1 (amd64) in a VMWare virtual machine w/2GB RAM. In installed ZFS on GPT root using the excellent instructions at http://wiki.freebsd.org/RootOnZFS/GPTZFSBoot/RAIDZ1. All was well until I tried some benchmarking with benchmarks/unixbench. I kept getting kmem_map too small panics on the filesystem tests so starting playing with vm.kmem_size. I finally got unixbench through the first 6 Filesystem Throughput tests with: vm.kmem_size="1296M" vm.kmem_size_max="1296M" vfs.zfs.arc_max="128M" vfs.zfs.vdev.cache.size="24M" (i think) Unfortunately, ZFS paniced with: Fatal trap 12: page fault while in kernel mode. Now, when I attempt to restart the VM, as soon as the "boot menu" is gone, I immediately get the same Fatal trap 12 panics again and cannot get past this point. I've got the 8.0-RC1 DVD and can run Fixit, but have no idea how to repair this broken ZFS installation. Suggestions welcome. -- Regards, Doug From owner-freebsd-current@FreeBSD.ORG Sun Oct 25 02:39:38 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E84A4106566C for ; Sun, 25 Oct 2009 02:39:38 +0000 (UTC) (envelope-from chmeeedalf@gmail.com) Received: from mail-gx0-f218.google.com (mail-gx0-f218.google.com [209.85.217.218]) by mx1.freebsd.org (Postfix) with ESMTP id 9F01E8FC0C for ; Sun, 25 Oct 2009 02:39:38 +0000 (UTC) Received: by gxk10 with SMTP id 10so9330561gxk.3 for ; Sat, 24 Oct 2009 19:39:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to:cc :content-type; bh=DFe8f2NAMa5wVMVObmPtYaqoalELVqQFOqj+Ludux18=; b=yGSbG5fvmhcO8Zns1NAbJC+vXD/AsUWr9m31fCsvkvIbu3o4u2fBwN4QBIJckpbPzo dCLRgKev23j8Brnya8B3+HhIE9C2/8g36Sh+vGiaTYYXUyE7zzESCcNAzp1A3cepDqtV YvPK10VzA099gfR0U5dETR69CE4W6dRJtkxEs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; b=VWP6kKWwzOLgDpPJj6NfxKMK1NL1dYWRIU+H/0wlrSRCA4zl7DX5CiGHeehx8GAfmo 62gY0CjCSZ70Ova0PlfnDtjJ+QGSjssrE7IkP4jbANcVSBbML23SIGLoySeqr3HpYm14 ZJf2yRTENxYuUrebhtosrs75UHBSGPeez6ppU= MIME-Version: 1.0 Sender: chmeeedalf@gmail.com Received: by 10.101.49.11 with SMTP id b11mr611905ank.121.1256436422821; Sat, 24 Oct 2009 19:07:02 -0700 (PDT) In-Reply-To: References: Date: Sat, 24 Oct 2009 22:07:02 -0400 X-Google-Sender-Auth: 6936e7bf4e33478b Message-ID: From: Justin Hibbits To: Warren Block Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: current@freebsd.org Subject: Re: Creating /dev links to dynamic devices X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Oct 2009 02:39:39 -0000 On Sat, Oct 24, 2009 at 10:00 PM, Warren Block wrote: > devfs.conf allows creating static device links: > > link acd0 cdrom > > This only runs on devfs startup, so it's useless for creating a link to a > dynamic device. > > The specific example is for scanners. My scanner is ugen2.3, but only as > long as it is plugged into the same USB hub/port each time. I can manually > create a uscanner0 link in /dev with devd.conf: > > attach 20 { > device-name "ugen[0-9]+"; > match "vendor" "0x04b8"; > match "product" "0x010a"; > action "/bin/ln -sf /dev/$device-name /dev/uscanner0; /sbin/devfs > rule applyset"; > }; > > Using /dev/uscanner0 then works in place of ugen2.3. > > Now the second part of the example: I want devd to recognize the attach or > creation of uscanner0. But it's not a true devfs device; devd doesn't see > an attach event, or a notify CDEV/CREATE event. > > Is there a method to create a true devfs link to a dynamic device? > > -Warren Block * Rapid City, South Dakota USA > Check devfs.rules(5) From owner-freebsd-current@FreeBSD.ORG Sun Oct 25 03:19:44 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 31255106566B for ; Sun, 25 Oct 2009 03:19:44 +0000 (UTC) (envelope-from wblock@wonkity.com) Received: from wonkity.com (wonkity.com [67.158.26.137]) by mx1.freebsd.org (Postfix) with ESMTP id E3C8F8FC0A for ; Sun, 25 Oct 2009 03:19:43 +0000 (UTC) Received: from wonkity.com (localhost [127.0.0.1]) by wonkity.com (8.14.3/8.14.3) with ESMTP id n9P3JdD9024186; Sat, 24 Oct 2009 21:19:39 -0600 (MDT) (envelope-from wblock@wonkity.com) Received: from localhost (wblock@localhost) by wonkity.com (8.14.3/8.14.3/Submit) with ESMTP id n9P3JdId024183; Sat, 24 Oct 2009 21:19:39 -0600 (MDT) (envelope-from wblock@wonkity.com) Date: Sat, 24 Oct 2009 21:19:39 -0600 (MDT) From: Warren Block To: Justin Hibbits In-Reply-To: Message-ID: References: User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.2 (wonkity.com [127.0.0.1]); Sat, 24 Oct 2009 21:19:39 -0600 (MDT) Cc: current@freebsd.org Subject: Re: Creating /dev links to dynamic devices X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Oct 2009 03:19:44 -0000 On Sat, 24 Oct 2009, Justin Hibbits wrote: > On Sat, Oct 24, 2009 at 10:00 PM, Warren Block wrote: > >> devfs.conf allows creating static device links: >> >> link acd0 cdrom >> >> This only runs on devfs startup, so it's useless for creating a link to a >> dynamic device. >> >> The specific example is for scanners. My scanner is ugen2.3, but only as >> long as it is plugged into the same USB hub/port each time. I can manually >> create a uscanner0 link in /dev with devd.conf: >> >> attach 20 { >> device-name "ugen[0-9]+"; >> match "vendor" "0x04b8"; >> match "product" "0x010a"; >> action "/bin/ln -sf /dev/$device-name /dev/uscanner0; /sbin/devfs >> rule applyset"; >> }; >> >> Using /dev/uscanner0 then works in place of ugen2.3. >> >> Now the second part of the example: I want devd to recognize the attach or >> creation of uscanner0. But it's not a true devfs device; devd doesn't see >> an attach event, or a notify CDEV/CREATE event. >> >> Is there a method to create a true devfs link to a dynamic device? > > Check devfs.rules(5) I did, but maybe missed the relevant information. There are conditions to match and modify (perm/owner) a node, but none to create or delete one. Maybe something with unhide? Could you post an example? -Warren Block * Rapid City, South Dakota USA From owner-freebsd-current@FreeBSD.ORG Sun Oct 25 03:26:42 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EDC96106566B for ; Sun, 25 Oct 2009 03:26:42 +0000 (UTC) (envelope-from chmeeedalf@gmail.com) Received: from mail-yx0-f171.google.com (mail-yx0-f171.google.com [209.85.210.171]) by mx1.freebsd.org (Postfix) with ESMTP id A48A48FC13 for ; Sun, 25 Oct 2009 03:26:42 +0000 (UTC) Received: by yxe1 with SMTP id 1so8998454yxe.3 for ; Sat, 24 Oct 2009 20:26:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to:cc :content-type; bh=EfWAu8b6wkI5rJyOx+pdZ4M5xOwmnqvWAAFpOSfh7B0=; b=AuCMqrQUJTlW9Id6BIhJzAWFb4fDomwmLj9SWBF1f50inswb4/YmmD/Qar61/nDpOq zfOI+TUTUCU3GvEzUfdiD2v2xkLfRi1zvPBcs1IgDaBVO6ihkV01shPMK2feGJXQsNac xQDFpvtq4jzFDRzHBSl5YJepapvq5fcrMoogo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; b=Nrhm9GiXrvkWvFIjBqdDLtZ+NBaQ3hhY5zJDS3p0kchwWmqIGF/fA1HDmbWryYfvX4 kcqpcNHqlT9xPSOTknwV6Bmrylk9jDFQmqMFZZHKoFOijh3Ji8hG9AjV6XlO5AmrxYQ+ MwOXTNyfIYnd8kcrM6C1h4FJKIJsyCKs1kF3g= MIME-Version: 1.0 Sender: chmeeedalf@gmail.com Received: by 10.100.56.17 with SMTP id e17mr2861566ana.100.1256441201954; Sat, 24 Oct 2009 20:26:41 -0700 (PDT) In-Reply-To: References: Date: Sat, 24 Oct 2009 23:26:41 -0400 X-Google-Sender-Auth: a71b709e72e17168 Message-ID: From: Justin Hibbits To: Warren Block Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: current@freebsd.org Subject: Re: Creating /dev links to dynamic devices X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Oct 2009 03:26:43 -0000 On Sat, Oct 24, 2009 at 11:19 PM, Warren Block wrote: > On Sat, 24 Oct 2009, Justin Hibbits wrote: > > On Sat, Oct 24, 2009 at 10:00 PM, Warren Block >> wrote: >> >> devfs.conf allows creating static device links: >>> >>> link acd0 cdrom >>> >>> This only runs on devfs startup, so it's useless for creating a link to a >>> dynamic device. >>> >>> The specific example is for scanners. My scanner is ugen2.3, but only as >>> long as it is plugged into the same USB hub/port each time. I can >>> manually >>> create a uscanner0 link in /dev with devd.conf: >>> >>> attach 20 { >>> device-name "ugen[0-9]+"; >>> match "vendor" "0x04b8"; >>> match "product" "0x010a"; >>> action "/bin/ln -sf /dev/$device-name /dev/uscanner0; /sbin/devfs >>> rule applyset"; >>> }; >>> >>> Using /dev/uscanner0 then works in place of ugen2.3. >>> >>> Now the second part of the example: I want devd to recognize the attach >>> or >>> creation of uscanner0. But it's not a true devfs device; devd doesn't >>> see >>> an attach event, or a notify CDEV/CREATE event. >>> >>> Is there a method to create a true devfs link to a dynamic device? >>> >> >> Check devfs.rules(5) >> > > I did, but maybe missed the relevant information. There are conditions to > match and modify (perm/owner) a node, but none to create or delete one. > Maybe something with unhide? Could you post an example? > > > -Warren Block * Rapid City, South Dakota USA > I guess I misread your original post. Why do you want to add actions based on the creation of the uscanner node? From owner-freebsd-current@FreeBSD.ORG Sun Oct 25 03:46:03 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E4A83106566B; Sun, 25 Oct 2009 03:46:03 +0000 (UTC) (envelope-from rnoland@FreeBSD.org) Received: from gizmo.2hip.net (gizmo.2hip.net [64.74.207.195]) by mx1.freebsd.org (Postfix) with ESMTP id 98DF48FC1C; Sun, 25 Oct 2009 03:46:03 +0000 (UTC) Received: from [192.168.1.4] (adsl-150-102-19.bna.bellsouth.net [72.150.102.19]) (authenticated bits=0) by gizmo.2hip.net (8.14.3/8.14.3) with ESMTP id n9P3jvdr012717 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Sat, 24 Oct 2009 23:45:58 -0400 (EDT) (envelope-from rnoland@FreeBSD.org) From: Robert Noland To: Radek =?iso-8859-2?Q?Val=E1=B9ek?= In-Reply-To: <4AE33CF9.3050308@buchlovice.org> References: <4AD710D6.70404@buchlovice.org> <1255633430.2175.12.camel@balrog.2hip.net> <4AD779FC.1070204@buchlovice.org> <1256146709.2310.9.camel@balrog.2hip.net> <4AE33CF9.3050308@buchlovice.org> Content-Type: text/plain; charset="iso-8859-2" Organization: FreeBSD Date: Sat, 24 Oct 2009 22:45:52 -0500 Message-Id: <1256442352.3303.10.camel@balrog.2hip.net> Mime-Version: 1.0 X-Mailer: Evolution 2.26.3 FreeBSD GNOME Team Port Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-1.6 required=5.0 tests=AWL,BAYES_00, RCVD_IN_SORBS_DUL, RDNS_DYNAMIC, SPF_SOFTFAIL autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on gizmo.2hip.net Cc: freebsd-fs@freebsd.org, freebsd-current@freebsd.org Subject: Re: GPT boot with ZFS RAIDZ "ZFS: i/o error - all block copies unavailable" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Oct 2009 03:46:04 -0000 On Sat, 2009-10-24 at 19:44 +0200, Radek Valášek wrote: > Robert Noland napsal(a): > > On Thu, 2009-10-15 at 21:37 +0200, Radek Valášek wrote: > > > >> Robert Noland napsal(a): > >> > >>> On Thu, 2009-10-15 at 14:08 +0200, Radek Valášek wrote: > >>> > >>> > >>>> Hi, > >>>> > >>>> I want to ask if there is something new in adding support to > >>>> gptzfsboot/zfsboot for reading gang-blocks? > >>>> > >>>> > > > > I think that the gang block patch will work, though still haven't gotten > > it tested. However, I'm fairly confident that the issue is not gang > > block related. Right now, I have setup a disk like this: > > > > => 34 1953525101 ada1 GPT (932G) > > 34 128 1 freebsd-boot (64K) > > 162 8388608 2 freebsd-swap (4.0G) > > 8388770 648019968 3 freebsd-zfs (309G) > > 656408738 648019968 4 freebsd-zfs (309G) > > 1304428706 648019968 5 freebsd-zfs (309G) > > 1952448674 1076461 - free - (526M) > > > > Note that this is not a raidz pool right now. It is just 3 toplevel > > partitions setup as a single pool. I finally have this configuration > > working reliably. At least in this case, the issue is due to all of the > > partitions not being probed during early boot and so not being added to > > the list of vdevs for the pool. When zio_read finds a dva that points > > to a device it doesn't know about, it gives up and whines. > > > > Can you detail for me how you have everything configured, so that I can > > try to replicate it. gpart show, zpool status and zpool get all > > would be good. I'm not sure that I have enough spare disks lying around > > to do this properly, but maybe I can use virtual disks or something. > > > > robert. > > > > > > Sorry for not responding so long. Here are details you want from me: > > # gpart show > => 34 1953525101 ad6 GPT (932G) > 34 128 1 freebsd-boot (64K) > 162 1953524973 2 freebsd-zfs (932G) > > => 34 1953525101 ad8 GPT (932G) > 34 128 1 freebsd-boot (64K) > 162 1953524973 2 freebsd-zfs (932G) > > => 34 1953525101 ad10 GPT (932G) > 34 128 1 freebsd-boot (64K) > 162 1953524973 2 freebsd-zfs (932G) > > => 34 1953525101 ad12 GPT (932G) > 34 128 1 freebsd-boot (64K) > 162 1953524973 2 freebsd-zfs (932G) > > # zpool status > pool: z > state: ONLINE > scrub: none requested > config: > > NAME STATE READ WRITE CKSUM > z ONLINE 0 0 0 > raidz1 ONLINE 0 0 0 > ad6p2 ONLINE 0 0 0 > ad8p2 ONLINE 0 0 0 > ad10p2 ONLINE 0 0 0 > ad12p2 ONLINE 0 0 0 > > errors: No known data errors > > # zpool get all z > NAME PROPERTY VALUE SOURCE > z size 3.62T - > z used 4.62G - > z available 3.62T - > z capacity 0% - > z altroot - default > z health ONLINE - > z guid 17857007133862981114 - > z version 13 default > z bootfs z/system local > z delegation on default > z autoreplace off default > z cachefile - default > z failmode wait default > z listsnapshots off default > > I've tested your patches but it seems that you're right and it's not > gang related issue. I was able to discover these things on a fully > functional zfs pool (system compiled with your patches): > > 1, If I overwrite the file /boot/loader.conf (with copy of itself, or > when upgrading kernel/world), next reboot comes with these messages: > > BTX loader 1.00 BTX version is 1.02 > Consoles: internal video/keyboard > BIOS drive C: is disk0 > BIOS drive D: is disk1 > BIOS drive E: is disk2 > BIOS drive F: is disk3 > BIOS 627kB/3405248kB available memory > > FreeBSD/i386 bootstrap loader, Revision 1.1 > (root@ztest, Thu Oct 22 22:27:22 CEST 2009) > Loading /boot/defaults/loader.conf > ZFS: i/o error - all block copies unavailable > Warning: error reading file /boot/loader.conf > > Then I'm still able to boot the system, but I must set the boot > variables included in loader.conf by hand > > 2, Next I overwrite the file /boot/loader (with copy of itself, or when > upgrading kernel/world) and reboot comes with these messages: > > BTX loader 1.00 BTX version is 1.02 > Consoles: internal video/keyboard > BIOS drive C: is disk0 > BIOS drive D: is disk1 > BIOS drive E: is disk2 > BIOS drive F: is disk3 > BIOS 627kB/3405248kB available memory > > FreeBSD/i386 bootstrap loader, Revision 1.1 > (root@ztest, Thu Oct 22 22:27:22 CEST 2009) > Loading /boot/defaults/loader.conf > ZFS: i/o error - all block copies unavailable > Warning: error reading file /boot/loader.conf > ZFS: i/o error - all block copies unavailable > ZFS: i/o error - all block copies unavailable > ZFS: i/o error - all block copies unavailable > ZFS: i/o error - all block copies unavailable > ZFS: i/o error - all block copies unavailable > ZFS: i/o error - all block copies unavailable > ZFS: i/o error - all block copies unavailable > ZFS: i/o error - all block copies unavailable > Unable to load a kernel! > > After that I'm no longer able to boot the system from zfs pool. > > Hope you have some ideas... Ok, can you retest with -CURRENT? I just committed some fixes on Friday. I'm having real difficulty in reproducing these issues. Most of the problems that I've run into so far had to do with the system not knowing about all of the vdevs when it wanted to read something. In your case, it looks like you are making it to boot3 and it appears to be seeing all 4 of your disks. Right now, I've been trying to track down an issue wher the MOS can't be read, which basically means that we have screwed up the root block pointer somehow. I haven't been able to reproduce that issue in qemu, I have been able to reproduce it with VirtualBox, but it is really time consuming trying to work in vbox since I have to reconvert all of the disk images every time I make a change. I'm actually a bit concerned that it hinges on how many drives are visible to the bios at various points in time. robert. > vaLin > > >>> Ok, I can't figure out any way to test this... beyond the fact that it > >>> builds and doesn't break my currently working setup. Can you give this > >>> a try? It should still report if it finds gang blocks, but hopefully > >>> now will read them as well. > >>> > >>> robert. > >>> > >>> > >>> > >> Big thanks for the patches Robert, I will definitely test them as soon > >> as possible (tomorrow) and report the results immediately to list. I can > >> repeat this issue probably at any time (up to cca 30 times tested with > >> the same result), so don't bother about the broken booting, I'm prepared > >> for it... > >> > >> vaLin > >> > >>>> From Sun's docs: > >>>> > >>>> Gang blocks > >>>> > >>>> When there is not enough contiguous space to write a complete block, the ZIO > >>>> pipeline will break the I/O up into smaller 'gang blocks' which can later be > >>>> assembled transparently to appear as complete blocks. > >>>> > >>>> Everything works fine for me, until I rewrite kernel/world after system > >>>> upgrade to latest one (releng_8). After this am I no longer able to boot > >>>> from zfs raidz1 pool with following messages: > >>>> > >>>> >/ ZFS: i/o error - all block copies unavailable > >>>> />/ ZFS: can't read MOS > >>>> />/ ZFS: unexpected object set type lld > >>>> />/ ZFS: unexpected object set type lld > >>>> />/ > >>>> />/ FreeBSD/i386 boot > >>>> />/ Default: z:/boot/kernel/kernel > >>>> />/ boot: > >>>> />/ ZFS: unexpected object set type lld > >>>> />/ > >>>> />/ FreeBSD/i386 boot > >>>> />/ Default: tank:/boot/kernel/kernel > >>>> />/ boot: > >>>> // > >>>> /I presume it's the same issue as talked in june-2009 current mailing > >>>> list > >>>> http://lists.freebsd.org/pipermail/freebsd-current/2009-June/008589.html > >>>> > >>>> Any success in that matter? > >>>> > >>>> Thnx for answer. > >>>> > >>>> vaLin > >>>> _______________________________________________ > >>>> 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" > >>>> > >>>> > -- Robert Noland FreeBSD From owner-freebsd-current@FreeBSD.ORG Sun Oct 25 03:52:32 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DECF9106568B for ; Sun, 25 Oct 2009 03:52:32 +0000 (UTC) (envelope-from wblock@wonkity.com) Received: from wonkity.com (wonkity.com [67.158.26.137]) by mx1.freebsd.org (Postfix) with ESMTP id 992CB8FC18 for ; Sun, 25 Oct 2009 03:52:32 +0000 (UTC) Received: from wonkity.com (localhost [127.0.0.1]) by wonkity.com (8.14.3/8.14.3) with ESMTP id n9P3qV5g024302; Sat, 24 Oct 2009 21:52:31 -0600 (MDT) (envelope-from wblock@wonkity.com) Received: from localhost (wblock@localhost) by wonkity.com (8.14.3/8.14.3/Submit) with ESMTP id n9P3qUUK024299; Sat, 24 Oct 2009 21:52:31 -0600 (MDT) (envelope-from wblock@wonkity.com) Date: Sat, 24 Oct 2009 21:52:30 -0600 (MDT) From: Warren Block To: Justin Hibbits In-Reply-To: Message-ID: References: User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="-902635197-712873081-1256442751=:24264" X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.2 (wonkity.com [127.0.0.1]); Sat, 24 Oct 2009 21:52:31 -0600 (MDT) Cc: current@freebsd.org Subject: Re: Creating /dev links to dynamic devices X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Oct 2009 03:52:33 -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. ---902635197-712873081-1256442751=:24264 Content-Type: TEXT/PLAIN; format=flowed; charset=ISO-8859-15 Content-Transfer-Encoding: 8BIT On Sat, 24 Oct 2009, Justin Hibbits wrote: > On Sat, Oct 24, 2009 at 11:19 PM, Warren Block wrote: > On Sat, 24 Oct 2009, Justin Hibbits wrote: > > On Sat, Oct 24, 2009 at 10:00 PM, Warren Block wrote: > > devfs.conf allows creating static device links: > > link    acd0    cdrom > > This only runs on devfs startup, so it's useless for creating a link to a > dynamic device. > > I guess I misread your original post.  Why do you want to add actions based on the creation of the uscanner node?  In this case, so I can run scanbuttond on creation of uscanner0. Yes, that could be done on detection of the vendor and product IDs and using the ugen device for this example. But it seems to show that either the ability to dynamically create "static device links" isn't there, or I just haven't found it yet. -Warren Block * Rapid City, South Dakota USA ---902635197-712873081-1256442751=:24264-- From owner-freebsd-current@FreeBSD.ORG Sun Oct 25 05:38:36 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9823C1065670 for ; Sun, 25 Oct 2009 05:38:36 +0000 (UTC) (envelope-from swhetzel@gmail.com) Received: from mail-vw0-f189.google.com (mail-vw0-f189.google.com [209.85.212.189]) by mx1.freebsd.org (Postfix) with ESMTP id 4D2B38FC1D for ; Sun, 25 Oct 2009 05:38:35 +0000 (UTC) Received: by vws27 with SMTP id 27so4138397vws.3 for ; Sat, 24 Oct 2009 22:38:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=5zF035l394xMO6oCSFUaqneqLc2cpa6g0rwzqP1RuI4=; b=txUka7qfZlDsjqMu7OiwXPgMgMmgIKbFV8tSPMWReLItapLJQzjZZyq/ZAE5RrXDjw 8K0MY1hJlW+jEKELUmaznmnDmEBHLHOqkhstJU/YLknaBgT3NyvQoYrSBWnltcxYSv9c yi53abtTReh1YZbOEFtWKy0imVwHi1f4MWsPE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=cVaycQjIsUmoMKbVeYk2w0+qr/pp4hFGIX0cNFXXjvZmEF81Ozb901EVnd6tiJ7Bjc x4UwqLa8hZEjTBSWFHck9WaHY24KejM6a9rXB2QTwZIi308X61MR9c6lAu4Tx0CziDM6 P1xeN3OsvXzq21zMaQyKLgqUFdl3EYo7/H58E= MIME-Version: 1.0 Received: by 10.220.89.83 with SMTP id d19mr2173870vcm.0.1256449115512; Sat, 24 Oct 2009 22:38:35 -0700 (PDT) In-Reply-To: <46e678eb1eeca98033b15979e034a765.squirrel@email.polands.org> References: <46e678eb1eeca98033b15979e034a765.squirrel@email.polands.org> Date: Sun, 25 Oct 2009 00:38:35 -0500 Message-ID: <790a9fff0910242238h1c2966a6kd4f7edce34b7e47a@mail.gmail.com> From: Scot Hetzel To: Doug Poland Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-current@freebsd.org Subject: Re: Fatal trap 12 on ZFS in 8.0-RC1 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Oct 2009 05:38:36 -0000 On Sat, Oct 24, 2009 at 9:10 PM, Doug Poland wrote: > Hello, > > I'm experimenting with ZFS on 8-0-RC1 (amd64) in a VMWare virtual > machine w/2GB RAM. =A0In installed ZFS on GPT root using the excellent > instructions at http://wiki.freebsd.org/RootOnZFS/GPTZFSBoot/RAIDZ1. > > All was well until I tried some benchmarking with > benchmarks/unixbench. =A0I kept getting kmem_map too small panics on the > filesystem tests so starting playing with vm.kmem_size. > > I finally got unixbench through the first 6 Filesystem Throughput > tests with: > vm.kmem_size=3D"1296M" > vm.kmem_size_max=3D"1296M" > vfs.zfs.arc_max=3D"128M" > vfs.zfs.vdev.cache.size=3D"24M" (i think) > > Unfortunately, ZFS paniced with: > Fatal trap 12: page fault while in kernel mode. Now, when I attempt to > restart the VM, as soon as the "boot menu" is gone, I immediately get > the same Fatal trap 12 panics again and cannot get past this point. > > I've got the 8.0-RC1 DVD and can run Fixit, but have no idea how to > repair this broken ZFS installation. =A0Suggestions welcome. > Try this to import your zpool in the Fixit environment: Fixit# kldload /mnt2/boot/kernel/opensolaris.ko Fixit# kldload /mnt2/boot/kernel/zfs.ko Fixit# zpool import -f -R /zroot zroot Scot From owner-freebsd-current@FreeBSD.ORG Sun Oct 25 06:07:49 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D4AF2106566C for ; Sun, 25 Oct 2009 06:07:49 +0000 (UTC) (envelope-from serenity@exscape.org) Received: from ch-smtp01.sth.basefarm.net (ch-smtp01.sth.basefarm.net [80.76.149.212]) by mx1.freebsd.org (Postfix) with ESMTP id 8F0CF8FC18 for ; Sun, 25 Oct 2009 06:07:49 +0000 (UTC) Received: from c83-253-248-99.bredband.comhem.se ([83.253.248.99]:58012 helo=mx.exscape.org) by ch-smtp01.sth.basefarm.net with esmtp (Exim 4.68) (envelope-from ) id 1N1wGC-0002lU-3o; Sun, 25 Oct 2009 07:07:26 +0100 Received: from [192.168.1.5] (macbookpro [192.168.1.5]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mx.exscape.org (Postfix) with ESMTPSA id 587F226E6EC; Sun, 25 Oct 2009 07:07:10 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1076) Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes From: Thomas Backman X-Priority: 3 (Normal) In-Reply-To: <46e678eb1eeca98033b15979e034a765.squirrel@email.polands.org> Date: Sun, 25 Oct 2009 07:07:07 +0100 Content-Transfer-Encoding: 7bit Message-Id: <2D80E5CB-71E5-4F4F-A84B-A95C18B50F47@exscape.org> References: <46e678eb1eeca98033b15979e034a765.squirrel@email.polands.org> To: Doug Poland X-Mailer: Apple Mail (2.1076) X-Originating-IP: 83.253.248.99 X-Scan-Result: No virus found in message 1N1wGC-0002lU-3o. X-Scan-Signature: ch-smtp01.sth.basefarm.net 1N1wGC-0002lU-3o 4baac6354517e20f71d1682c9118890d Cc: freebsd-current@freebsd.org Subject: Re: Fatal trap 12 on ZFS in 8.0-RC1 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Oct 2009 06:07:49 -0000 On Oct 25, 2009, at 3:10 AM, Doug Poland wrote: > Hello, > > I'm experimenting with ZFS on 8-0-RC1 (amd64) in a VMWare virtual > machine w/2GB RAM. In installed ZFS on GPT root using the excellent > instructions at http://wiki.freebsd.org/RootOnZFS/GPTZFSBoot/RAIDZ1. > > All was well until I tried some benchmarking with > benchmarks/unixbench. I kept getting kmem_map too small panics on the > filesystem tests so starting playing with vm.kmem_size. > > I finally got unixbench through the first 6 Filesystem Throughput > tests with: > vm.kmem_size="1296M" > vm.kmem_size_max="1296M" > vfs.zfs.arc_max="128M" > vfs.zfs.vdev.cache.size="24M" (i think) > > Unfortunately, ZFS paniced with: > Fatal trap 12: page fault while in kernel mode. Now, when I attempt to > restart the VM, as soon as the "boot menu" is gone, I immediately get > the same Fatal trap 12 panics again and cannot get past this point. > > I've got the 8.0-RC1 DVD and can run Fixit, but have no idea how to > repair this broken ZFS installation. Suggestions welcome. You should be able to break into the loader prompt (choice #6 IIRC) and do unset vm.kmem_size unset vm... ... etc. boot That way, you'll be back to the earlier panics, but at least it'll boot. Oh, and the settings aren't permanent, so make editing /boot/ loader.conf your first prority. Regards, Thomas From owner-freebsd-current@FreeBSD.ORG Sun Oct 25 08:02:58 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 29EF9106568F for ; Sun, 25 Oct 2009 08:02:58 +0000 (UTC) (envelope-from sziszi@bsd.hu) Received: from mail.rubicom.hu (mail.rubicom.hu [89.147.80.28]) by mx1.freebsd.org (Postfix) with ESMTP id CF6D58FC0A for ; Sun, 25 Oct 2009 08:02:57 +0000 (UTC) Received: from localhost ([127.0.0.1] helo=mail.rubicom.hu) by mail.rubicom.hu with smtp (Exim 4.63) (envelope-from ) id 1N1y3z-0002bX-Q1 for freebsd-current@freebsd.org; Sun, 25 Oct 2009 09:02:55 +0100 Received: from ip59935289.rubicom.hu ([89.147.82.137] helo=baranyfelhocske.buza.adamsfamily.xx) by mail.rubicom.hu with esmtp (Exim 4.63) (envelope-from ) id 1N1y3z-0002bO-J9 for freebsd-current@freebsd.org; Sun, 25 Oct 2009 09:02:55 +0100 Received: from baranyfelhocske.buza.adamsfamily.xx (localhost [127.0.0.1]) by baranyfelhocske.buza.adamsfamily.xx (8.14.3/8.14.3) with ESMTP id n9P92tpK002686 for ; Sun, 25 Oct 2009 10:02:55 +0100 (CET) (envelope-from sziszi@bsd.hu) Received: (from sziszi@localhost) by baranyfelhocske.buza.adamsfamily.xx (8.14.3/8.14.3/Submit) id n9P92tDn002685 for freebsd-current@freebsd.org; Sun, 25 Oct 2009 10:02:55 +0100 (CET) (envelope-from sziszi@bsd.hu) X-Authentication-Warning: baranyfelhocske.buza.adamsfamily.xx: sziszi set sender to sziszi@bsd.hu using -f Date: Sun, 25 Oct 2009 10:02:55 +0100 From: Szilveszter Adam To: freebsd-current@freebsd.org Message-ID: <20091025090255.GA1999@baranyfelhocske.buza.adamsfamily.xx> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) Subject: Re: Creating /dev links to dynamic devices X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Oct 2009 08:02:58 -0000 On Sat, Oct 24, 2009 at 09:52:30PM -0600, Warren Block wrote: > > In this case, so I can run scanbuttond on creation of uscanner0. Yes, > that could be done on detection of the vendor and product IDs and using > the ugen device for this example. > > But it seems to show that either the ability to dynamically create > "static device links" isn't there, or I just haven't found it yet. Looks like you are right. The creation of links as specified in devfs.conf is handled by custom code in /etc/rc.d/devfs, it cannot be specified as the "action" part of a devfs rule at this time. Your best bet is to use devd.conf, there you have more freedom (but you have already hinted at this yourself) -- Regards: Szilveszter ADAM Budapest Hungary From owner-freebsd-current@FreeBSD.ORG Sun Oct 25 08:34:16 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8F2B3106566C for ; Sun, 25 Oct 2009 08:34:16 +0000 (UTC) (envelope-from guru@unixarea.de) Received: from dd12710.kasserver.com (dd12710.kasserver.com [85.13.134.233]) by mx1.freebsd.org (Postfix) with ESMTP id 1F5FC8FC13 for ; Sun, 25 Oct 2009 08:34:15 +0000 (UTC) Received: from current.Sisis.de (ppp-62-216-211-242.dynamic.mnet-online.de [62.216.211.242]) by dd12710.kasserver.com (Postfix) with ESMTP id EBF3218385EF7; Sun, 25 Oct 2009 09:34:15 +0100 (CET) Received: (from guru@localhost) by current.Sisis.de (8.14.3/8.14.3/Submit) id n9P8YDsN002706; Sun, 25 Oct 2009 09:34:13 +0100 (CET) (envelope-from guru@unixarea.de) X-Authentication-Warning: current.Sisis.de: guru set sender to guru@unixarea.de using -f Date: Sun, 25 Oct 2009 09:34:13 +0100 From: Matthias Apitz To: Tijl Coosemans , freebsd-current@freebsd.org Message-ID: <20091025083413.GA2671@current.Sisis.de> References: <20091024134855.GA3888@current.Sisis.de> <200910241625.58982.tijl@fastmail.fm> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <200910241625.58982.tijl@fastmail.fm> User-Agent: Mutt/1.4.2.3i X-Operating-System: FreeBSD 8.0-CURRENT (i386) Cc: Subject: Re: Flash10 in -current: missing shared libs X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Matthias Apitz List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Oct 2009 08:34:16 -0000 El día Saturday, October 24, 2009 a las 04:25:57PM +0200, Tijl Coosemans escribió: > > is stilling missing shared objects; step-by-step I have installed in > > addition: > > > > linux-f10-gtk2-2.14.7.tbz > > linux-f10-xorg-libs-7.4_1.tbz > > linux-f10-pango-1.22.3.tbz > > > > (btw: why www/linux-f10-flashplugin10 is not wanting them to install by > > its own) > > > > but still have at least one open dependency: > > > > $ nspluginwrapper -v -i > > /usr/local/lib/npapi/linux-f10-flashplugin/libflashplayer.so > > /usr/local/lib/nspluginwrapper/i386/linux/npviewer.bin: error while > > loading shared libraries: libatk-1.0.so.0: cannot open shared object > > file: No such file or directory > > > > Any idea what is wrong? /usr/ports is very recent (from CVS October 6) > > Those are all dependencies of nspluginwrapper so something must have > gone wrong when you installed that package. Correct. And I know what went wrong. Because of this problem with artsd, on October 16 I compiled all my ports again and before this I removed /usr/local/* and /var/db/pkg/* to have a clean environment. The log of the port of www/nspluginwrapper I conserved (like all other logs) and it says: ... ===> Patching for nspluginwrapper-1.2.2_4 ===> Applying FreeBSD patches for nspluginwrapper-1.2.2_4 /bin/rm /usr/ports/www/nspluginwrapper/work/nspluginwrapper-1.2.2/usr/lib/nspluginwrapper/i386/linux/npviewer.ori g ===> nspluginwrapper-1.2.2_4 depends on executable: gmake - found ===> nspluginwrapper-1.2.2_4 depends on file: /usr/local/libdata/pkgconfig/x11.pc - found ===> nspluginwrapper-1.2.2_4 depends on file: /usr/local/libdata/pkgconfig/xext.pc - found ===> nspluginwrapper-1.2.2_4 depends on file: /usr/local/libdata/pkgconfig/xt.pc - found ===> nspluginwrapper-1.2.2_4 depends on file: /usr/local/bin/intltool-extract - found ===> nspluginwrapper-1.2.2_4 depends on executable: pkg-config - found ===> nspluginwrapper-1.2.2_4 depends on shared library: curl.5 - found ===> nspluginwrapper-1.2.2_4 depends on shared library: atk-1.0.0 - found ===> nspluginwrapper-1.2.2_4 depends on shared library: glib-2.0.0 - found ===> nspluginwrapper-1.2.2_4 depends on shared library: gtk-x11-2.0.0 - found ===> nspluginwrapper-1.2.2_4 depends on shared library: pango-1.0.0 - found ===> Configuring for nspluginwrapper-1.2.2_4 ... as you see it is happy with its shared libs; this is because they are looked up in /compat/linux/lib where they have been sitting since the 1st compile of the ports on October, 8; and so later the packages have not been created because there was no linux-f10-curl-7.19.4_4 (for example) in /var/db/pkg; this means for such a clean restart one should also remove all in /compat/linux/ Lession learned. Thanks for pointing me in the right direction. Flash10 is working now as it should (and even without any freeze on terminating a stream). matthias -- Matthias Apitz t +49-89-61308 351 - f +49-89-61308 399 - m +49-170-4527211 e - w http://www.unixarea.de/ Vote NO to EU The Lisbon Treaty: http://www.no-means-no.eu From owner-freebsd-current@FreeBSD.ORG Sun Oct 25 13:45:59 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4DA361065692 for ; Sun, 25 Oct 2009 13:45:59 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe11.swip.net [212.247.155.65]) by mx1.freebsd.org (Postfix) with ESMTP id D306B8FC14 for ; Sun, 25 Oct 2009 13:45:58 +0000 (UTC) X-Cloudmark-Score: 0.000000 [] X-Cloudmark-Analysis: v=1.0 c=1 a=4TrS-n8VG_gA:10 a=RERtC8nhXGhYvIZhK0yWrQ==:17 a=JJvLCbRIHrlZXHH6958A:9 a=46HQuZGnkkr6QcLnJxcFvC-j5IYA:4 Received: from [90.149.203.35] (account mc467741@c2i.net HELO laptop.adsl.tele2.no) by mailfe11.swip.net (CommuniGate Pro SMTP 5.2.16) with ESMTPA id 1154249806; Sun, 25 Oct 2009 14:45:56 +0100 From: Hans Petter Selasky To: freebsd-current@freebsd.org Date: Sun, 25 Oct 2009 14:47:06 +0100 User-Agent: KMail/1.11.4 (FreeBSD/9.0-CURRENT; KDE/4.2.4; i386; ; ) References: <1256383742548@koleman_gmail.com> In-Reply-To: <1256383742548@koleman_gmail.com> X-Face: (%:6u[ldzJ`0qjD7sCkfdMmD*RxpOwEEQ+KWt[{J#x6ow~JO:,zwp.(t; @Aq :4:&nFCgDb8[3oIeTb^'",;u{5{}C9>"PuY\)!=#\u9SSM-nz8+SR~B\!qBv MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200910251447.07084.hselasky@c2i.net> Cc: Antti Kolehmainen Subject: Re: problems with usb if you unload and reload kernel modules X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Oct 2009 13:45:59 -0000 On Saturday 24 October 2009 13:29:02 Antti Kolehmainen wrote: Can you describe the problem a little bit more? --HPS From owner-freebsd-current@FreeBSD.ORG Sun Oct 25 14:16:53 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2027F106568B for ; Sun, 25 Oct 2009 14:16:53 +0000 (UTC) (envelope-from dsuzukisanders@gmail.com) Received: from mail-fx0-f210.google.com (mail-fx0-f210.google.com [209.85.220.210]) by mx1.freebsd.org (Postfix) with ESMTP id ACB338FC15 for ; Sun, 25 Oct 2009 14:16:52 +0000 (UTC) Received: by fxm6 with SMTP id 6so10779372fxm.43 for ; Sun, 25 Oct 2009 07:16:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type; bh=KCiMHJRa3Gplpupn6JyZ5N/whO0jhhOVQw32YIRms2M=; b=JalcnC5RZ2YG6nQ6XP8iQg789H1LXzc+IYWC59RUTSNgavxmABP0N+aoTufPOZHaaV C3IKK0YTgP8gu8gjK9xRb4o9vgQ46qiviYSgDcSerSP/5e+LjqVOys4eS9qK+iqUKPqz nIOB7LD5Iun2jlqzTMdoqN1cxlc/f5yMY8DBU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=hUgkt/+CZ3a/NtjUNbShaFL1X7ILRlYrT/olrjnrbwBcr/k673wgfRwqUhAyb4PXYT gYC3xNZRdKvP94RgXwyYDN2WF6uUUm2GfnjXbNCYta+U3q5y7RRpFP8IpSkzto//0zY8 5Hb/h+C7sqxhsLdp8/o4EEVfl1QQ9ir77euE0= MIME-Version: 1.0 Received: by 10.239.146.77 with SMTP id v13mr1078896hba.61.1256478540763; Sun, 25 Oct 2009 06:49:00 -0700 (PDT) In-Reply-To: <200910251447.07084.hselasky@c2i.net> References: <1256383742548@koleman_gmail.com> <200910251447.07084.hselasky@c2i.net> Date: Sun, 25 Oct 2009 14:49:00 +0100 Message-ID: <6228eb140910250649x35e94eecx68378fe7b92a3574@mail.gmail.com> From: David Sanders To: freebsd-current@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Subject: Re: problems with usb if you unload and reload kernel modules X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Oct 2009 14:16:53 -0000 2009/10/25 Hans Petter Selasky : > On Saturday 24 October 2009 13:29:02 Antti Kolehmainen wrote: > > Can you describe the problem a little bit more? It's so bad he can't even type it out, you insensitive clod! From owner-freebsd-current@FreeBSD.ORG Sun Oct 25 15:50:48 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BBE92106566C for ; Sun, 25 Oct 2009 15:50:48 +0000 (UTC) (envelope-from guru@unixarea.de) Received: from dd12710.kasserver.com (dd12710.kasserver.com [85.13.134.233]) by mx1.freebsd.org (Postfix) with ESMTP id 7AA6D8FC0C for ; Sun, 25 Oct 2009 15:50:48 +0000 (UTC) Received: from current.Sisis.de (ppp-62-216-211-242.dynamic.mnet-online.de [62.216.211.242]) by dd12710.kasserver.com (Postfix) with ESMTP id A63A818386CC3 for ; Sun, 25 Oct 2009 16:50:49 +0100 (CET) Received: (from guru@localhost) by current.Sisis.de (8.14.3/8.14.3/Submit) id n9PFojUR006107 for freebsd-current@freebsd.org; Sun, 25 Oct 2009 16:50:45 +0100 (CET) (envelope-from guru@unixarea.de) X-Authentication-Warning: current.Sisis.de: guru set sender to guru@unixarea.de using -f Date: Sun, 25 Oct 2009 16:50:45 +0100 From: Matthias Apitz To: freebsd-current@freebsd.org Message-ID: <20091025155045.GA6012@current.Sisis.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.3i X-Operating-System: FreeBSD 8.0-CURRENT (i386) Subject: DVD: kernel: g_vfs_done():acd0[READ(offset=32768, length=2048)]error = 5 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Matthias Apitz List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Oct 2009 15:50:48 -0000 Hello, I have a problem with one DVD (i.e. others mount fine on 9.0-CURRENT r197801). The DVD was 2-3 times burned on a 8-CURRENT system with: # growisofs -speed=1 -Z /dev/cd0 -r -T -J -joliet-long -v 9-CURRENT-distfiles and in ./9-CURRENT-distfiles are some 1500 distfiles (a typical content of /usr/ports/distfiles). I can't mount this DVD+RW on a 9.0-CURRENT #0 r197801, it always gives: Oct 25 16:42:56 LaHabana kernel: g_vfs_done():acd0[READ(offset=32768, length=2048)]error = 5 It mounts fine on the burning system itself and on some older 7.0-REL system. Any ideas? Thx matthias -- Matthias Apitz t +49-89-61308 351 - f +49-89-61308 399 - m +49-170-4527211 e - w http://www.unixarea.de/ Vote NO to EU The Lisbon Treaty: http://www.no-means-no.eu From owner-freebsd-current@FreeBSD.ORG Sun Oct 25 16:38:39 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AFC191065679 for ; Sun, 25 Oct 2009 16:38:39 +0000 (UTC) (envelope-from jhs@berklix.com) Received: from tower.berklix.org (tower.berklix.org [83.236.223.114]) by mx1.freebsd.org (Postfix) with ESMTP id 2A53D8FC1B for ; Sun, 25 Oct 2009 16:38:38 +0000 (UTC) Received: from park.js.berklix.net (p549A61B7.dip.t-dialin.net [84.154.97.183]) (authenticated bits=0) by tower.berklix.org (8.14.2/8.14.2) with ESMTP id n9PGcZXu068555; Sun, 25 Oct 2009 16:38:36 GMT (envelope-from jhs@berklix.com) Received: from fire.js.berklix.net (fire.js.berklix.net [192.168.91.41]) by park.js.berklix.net (8.13.8/8.13.8) with ESMTP id n9PGcSFG087158; Sun, 25 Oct 2009 17:38:28 +0100 (CET) (envelope-from jhs@berklix.com) Received: from fire.js.berklix.net (localhost [127.0.0.1]) by fire.js.berklix.net (8.14.3/8.14.3) with ESMTP id n9PGbGTq062659; Sun, 25 Oct 2009 17:37:21 +0100 (CET) (envelope-from jhs@fire.js.berklix.net) Message-Id: <200910251637.n9PGbGTq062659@fire.js.berklix.net> To: Matthias Apitz From: "Julian H. Stacey" Organization: http://www.berklix.com BSD Unix Linux Consultancy, Munich Germany User-agent: EXMH on FreeBSD http://www.berklix.com/free/ X-URL: http://www.berklix.com In-reply-to: Your message "Sun, 25 Oct 2009 16:50:45 +0100." <20091025155045.GA6012@current.Sisis.de> Date: Sun, 25 Oct 2009 17:37:16 +0100 Sender: jhs@berklix.com Cc: freebsd-current@freebsd.org Subject: Re: DVD: kernel: g_vfs_done():acd0[READ(offset=32768, length=2048)]error = 5 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Oct 2009 16:38:39 -0000 Hi, Reference: > From: Matthias Apitz > Reply-to: Matthias Apitz > Date: Sun, 25 Oct 2009 16:50:45 +0100 > Message-id: <20091025155045.GA6012@current.Sisis.de> Matthias Apitz wrote: > > Hello, > > I have a problem with one DVD (i.e. others mount fine on 9.0-CURRENT > r197801). > > The DVD was 2-3 times burned on a 8-CURRENT system with: > > # growisofs -speed=1 -Z /dev/cd0 -r -T -J -joliet-long -v 9-CURRENT-distfiles > > and in ./9-CURRENT-distfiles are some 1500 distfiles (a typical content of > /usr/ports/distfiles). > > I can't mount this DVD+RW on a 9.0-CURRENT #0 r197801, it always gives: > > Oct 25 16:42:56 LaHabana kernel: g_vfs_done():acd0[READ(offset=32768, length=2048)]error = 5 > > It mounts fine on the burning system itself and on some older 7.0-REL system. > Any ideas? Thx -RW media needs more read sensitivity that -R media. Maybe its just chance if your -rw drive is on 7 & can read what it writes, & maybe you have a less sensitive drive -R on your current box ? If theyre external USB, easy to swop & try. PS Might possibly even be power, affecting digital levels, (I once had an old box would crash on CD access" the spin up surge pulled power too low for CPU :-) Cheers, Julian -- Julian Stacey: BSD Unix Linux C Sys Eng Consultants Munich http://berklix.com Mail plain text not quoted-printable, HTML or Base64: http://asciiribbon.org From owner-freebsd-current@FreeBSD.ORG Sun Oct 25 16:58:42 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C791F106566B for ; Sun, 25 Oct 2009 16:58:42 +0000 (UTC) (envelope-from mlobo@digiart.art.br) Received: from sv4.hmnoc.net (sv4.hmnoc.net [63.247.76.174]) by mx1.freebsd.org (Postfix) with ESMTP id A50BF8FC39 for ; Sun, 25 Oct 2009 16:58:42 +0000 (UTC) Received: from [187.78.72.104] (port=50999 helo=papi.localnet) by sv4.hmnoc.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1N26QU-0007g8-0q for freebsd-current@freebsd.org; Sun, 25 Oct 2009 14:58:42 -0200 From: Mario Lobo To: freebsd-current@freebsd.org Date: Sun, 25 Oct 2009 13:58:25 -0300 User-Agent: KMail/1.12.1 (FreeBSD/8.0-RC1; KDE/4.3.1; amd64; ; ) MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Message-Id: <200910251358.25572.mlobo@digiart.art.br> X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - sv4.hmnoc.net X-AntiAbuse: Original Domain - freebsd.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - digiart.art.br Subject: Marvell Yukon 88E8042 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Oct 2009 16:58:42 -0000 Hi; I have just acquired an HP 510 Laptop that came with this board. I installed FBSD 8 amd64 on it and the msk driver didn't recognized this chip, so I ran pciconf -l to get the chip id and added is identification to the source msk code as follows: if_msk.c: added this to the msk_products[] struc: { VENDORID_MARVELL, DEVICEID_MRVL_8042, "Marvell Yukon 88E8042 Gigabit Ethernet" }, if_mskreg.h: Added: #define DEVICEID_MRVL_8042 0x4357 After this, the chip was properly detected and the driver has been working flawlessly since. -- Mario Lobo http://www.mallavoodoo.com.br FreeBSD since version 2.2.8 [not Pro-Audio.... YET!!] (99,7% winedows FREE) From owner-freebsd-current@FreeBSD.ORG Sun Oct 25 16:37:17 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 942B01065676 for ; Sun, 25 Oct 2009 16:37:17 +0000 (UTC) (envelope-from marco.broeder@gmx.eu) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by mx1.freebsd.org (Postfix) with SMTP id DAB3C8FC1C for ; Sun, 25 Oct 2009 16:37:16 +0000 (UTC) Received: (qmail invoked by alias); 25 Oct 2009 16:10:35 -0000 Received: from port-92-195-123-16.dynamic.qsc.de (EHLO localhost) [92.195.123.16] by mail.gmx.net (mp019) with SMTP; 25 Oct 2009 17:10:35 +0100 X-Authenticated: #23197544 X-Provags-ID: V01U2FsdGVkX18Wh+8h1qoWtyZnSbXhhnuO+jSsS1a4OAfYoY75bY qQD+JcnL9fpMsG From: Marco =?utf-8?q?Br=C3=B6der?= To: freebsd-stable@freebsd.org Date: Sun, 25 Oct 2009 17:09:49 +0100 User-Agent: KMail (FreeBSD) References: <4AE3A001.8000205@FreeBSD.org> In-Reply-To: <4AE3A001.8000205@FreeBSD.org> MIME-Version: 1.0 Message-Id: <200910251709.49850.marco.broeder@gmx.eu> Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Y-GMX-Trusted: 0 X-FuHaFi: 0.66 X-Mailman-Approved-At: Sun, 25 Oct 2009 17:29:53 +0000 Cc: Alexander Motin , FreeBSD-Current , icegloom dem , freebsd-amd64@freebsd.org Subject: Re: MCP55 SATA solution to test X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: marco.broeder@gmx.eu List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Oct 2009 16:37:17 -0000 On Sun October 25 2009 02:46:57 Alexander Motin wrote: > Hi. >=20 > Thanks to one man who provided access to his machine, I seem to found > how to fix device detection on nVidia MCP55 SATA controller on amd64 > 8.0. Looks like this controller need some time (very short) to enable > BAR(5) memory access after PCI configuration register written. Probably > some changes in PCI code exposed this issue. Also it explains why > setting hw.pci.mcfg to 0 helps. >=20 > Attached patch solves problem for that machine. Testers are welcome. >=20 Success! I tested your patch and everything is working fine with hw.pci.mcfg set to 1, now. Please commit it. Many thanks! =2D-=20 Regards, Marco Br=C3=B6der OpenPGP key fingerprint: 5615 106E 031A F3D3 64CC 0F9E 4DCE 6524 F595 082F From owner-freebsd-current@FreeBSD.ORG Sun Oct 25 21:29:59 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5C21E106566B; Sun, 25 Oct 2009 21:29:59 +0000 (UTC) (envelope-from ehrmann@gmail.com) Received: from mail-iw0-f189.google.com (mail-iw0-f189.google.com [209.85.223.189]) by mx1.freebsd.org (Postfix) with ESMTP id 108D08FC21; Sun, 25 Oct 2009 21:29:58 +0000 (UTC) Received: by iwn27 with SMTP id 27so5662049iwn.7 for ; Sun, 25 Oct 2009 14:29:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=/Ya4D23i3Ej9XaogAYhmGRDJpIxgo5lbumGqWkiOKL8=; b=g38lM6Ev9uoGDYNjs15Bzs8y9uwWpIQLLWOyj1r+y6swHi55VKJt9oopzuNuXq0DYo i3jD7Q8/xHLZ1Pyi0q125DIr43IwJUvqPMwG80T2fkVs85QXCXR4NzTfZjxF/eqetxri F/NRkNRmYyjCmJ2eh08IcGuxOmQhU4NnoRsho= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=uxT3y7MPvSlj8dvEcUEHCZXARs0jnBGwSS2SjtdZIXO7dDu3Pg3tB3YSBOMs8/y3J+ pdyJJoG+rZ43u+oU/DikMzduMxgbxJqNmCOJQzf/D3FSuYp3aneyieq1RZPtLiQiDOyN iWHZjWOSdP1nhfoml1CFmb4uY6RU76z/iCo3Q= MIME-Version: 1.0 Received: by 10.231.83.75 with SMTP id e11mr7422157ibl.11.1256506198171; Sun, 25 Oct 2009 14:29:58 -0700 (PDT) In-Reply-To: <6e0e5340910231531n737ac71ds11a07117c3f7667e@mail.gmail.com> References: <4ADF70F1.5060300@gmail.com> <4AE0DCDF.7090604@gmail.com> <20091023183708.GA6050@michelle.cdnetworks.com> <6e0e5340910231237v3f19b27ex1cbefd3f9a01af54@mail.gmail.com> <20091023194755.GC6050@michelle.cdnetworks.com> <20091023202604.GD6050@michelle.cdnetworks.com> <6e0e5340910231531n737ac71ds11a07117c3f7667e@mail.gmail.com> Date: Sun, 25 Oct 2009 14:29:58 -0700 Message-ID: <6e0e5340910251429n7b95143emb9a97b29d329ab1c@mail.gmail.com> From: David Ehrmann To: pyunyh@gmail.com Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-current@freebsd.org, Ivan Voras Subject: Re: Strange issue with Samba on 8.0rc1 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Oct 2009 21:29:59 -0000 On Fri, Oct 23, 2009 at 3:31 PM, David Ehrmann wrote: > I just gave my other ethernet device, vr0, an IP and netmask. I'm seeing > the same problem if I access the samba share via that IP. Unless FreeBSD is > doing something funny and trying to guess that the two IP addresses are on > the same network and sending all data out on the faster interface, I think > the vge driver is off the hook. > > I also switched my laptop over from wifi to ethernet, but that also didn't > change things. > I rebuilt FreeBSD 8.0rc1 from source, copied it to my machine, and "upgraded." I'm still having the problem, and I noticed a similar flavor of problem when an XP client connects and transfers a file. But for now, I'll ignore that. I can't csup the stable supfile. The only change I made to the one in /usr/share/examples/cvsup was setting the host to cvsup10.us.freebsd.org. Everything else is the same. Here's what happens when I run it: # csup stable-supfile Connected to 69.147.83.48 Updating collection src-all/cvs Checkout src/COPYRIGHT Checkout src/LOCKS Checkout src/MAINTAINERS Receiver: Connection reset by peer Will retry at 13:51:34 Retrying Connected to 69.147.83.48 Protocol error during collection exchange cvsup fails, too. It's probably not my internet connection because I was able to use csup on another machine, and things like pkg_add -r work on this one. Maybe the compact flash FreeBSD is on has worn out where something important is stored, or maybe there's a strange networking bug. Any other ideas? How can I debug this? From owner-freebsd-current@FreeBSD.ORG Sun Oct 25 21:41:05 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B800E1065698 for ; Sun, 25 Oct 2009 21:41:05 +0000 (UTC) (envelope-from ivoras@gmail.com) Received: from ey-out-2122.google.com (ey-out-2122.google.com [74.125.78.26]) by mx1.freebsd.org (Postfix) with ESMTP id 4469D8FC28 for ; Sun, 25 Oct 2009 21:41:04 +0000 (UTC) Received: by ey-out-2122.google.com with SMTP id 9so569076eyd.3 for ; Sun, 25 Oct 2009 14:41:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:from:date:x-google-sender-auth:message-id:subject:to:cc :content-type:content-transfer-encoding; bh=Y/fLYnBB6Ro97uMwuEz2wE4w5bwK9AQDeJLhuDitnS4=; b=gztpu75uDc5PG0j2nmi+H7Mh80g+qbOk750fuhqu9o2x7PSjVwHCxfQlqK9bKnSy3d iIAuMWwzMq0yDKfsGgNxXS49Vd36c0y8jJtBBxt1lvH6E/xPiZCnZMcsPEs++Z3BCoX6 xpK9HlzMdCq9lDtayn9eN+nYLAya+MSt2mM0Y= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type :content-transfer-encoding; b=bBbnGo8E4WbdE8RFd/rz9y1yPGn0Sxmg5jVEJsx3sICXqRvFYuYpiiPRYFIl9q1mez +oTxp2Wbj6CXNZda99lF1yLVGWCDfvgxpON1/nq7OjK001ZeXEacGPZSwp5uifaL4zEP sB4cvCjLVCSkheTgcJZnL86QWrqIzZc9WMY4s= MIME-Version: 1.0 Sender: ivoras@gmail.com Received: by 10.216.93.12 with SMTP id k12mr345145wef.195.1256506864154; Sun, 25 Oct 2009 14:41:04 -0700 (PDT) In-Reply-To: <6e0e5340910251429n7b95143emb9a97b29d329ab1c@mail.gmail.com> References: <4ADF70F1.5060300@gmail.com> <4AE0DCDF.7090604@gmail.com> <20091023183708.GA6050@michelle.cdnetworks.com> <6e0e5340910231237v3f19b27ex1cbefd3f9a01af54@mail.gmail.com> <20091023194755.GC6050@michelle.cdnetworks.com> <20091023202604.GD6050@michelle.cdnetworks.com> <6e0e5340910231531n737ac71ds11a07117c3f7667e@mail.gmail.com> <6e0e5340910251429n7b95143emb9a97b29d329ab1c@mail.gmail.com> From: Ivan Voras Date: Sun, 25 Oct 2009 22:40:44 +0100 X-Google-Sender-Auth: 70102041808e89f8 Message-ID: <9bbcef730910251440y30c05f45w149a3e4ab06849df@mail.gmail.com> To: David Ehrmann Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: pyunyh@gmail.com, freebsd-current@freebsd.org Subject: Re: Strange issue with Samba on 8.0rc1 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Oct 2009 21:41:05 -0000 2009/10/25 David Ehrmann : > # csup stable-supfile > Connected to 69.147.83.48 > Updating collection src-all/cvs > =C2=A0Checkout src/COPYRIGHT > =C2=A0Checkout src/LOCKS > =C2=A0Checkout src/MAINTAINERS > Receiver: Connection reset by peer > Will retry at 13:51:34 > Retrying > Connected to 69.147.83.48 > Protocol error during collection exchange > > cvsup fails, too.=C2=A0 It's probably not my internet connection because = I was > able to use csup on another machine, and things like pkg_add -r work on t= his > one.=C2=A0 Maybe the compact flash FreeBSD is on has worn out where somet= hing > important is stored, or maybe there's a strange networking bug. > > Any other ideas?=C2=A0 How can I debug this? Sorry, but I can only give you generic ideas: - It is unlikely that the storage media (flash) with FreeBSD has errors in such a way that would cause this subtle error - Can you try a "known good" FreeBSD 8 configuration? I.e. from a Live CD or USB media? The "live" edition has csup and everything else you could need. - Can you try a simple cheap "known good" NIC? I see that retail Realtek-based PCI NICs sell for less than $10. From owner-freebsd-current@FreeBSD.ORG Sun Oct 25 21:52:59 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0EC1E106568D for ; Sun, 25 Oct 2009 21:52:59 +0000 (UTC) (envelope-from lulf@pvv.ntnu.no) Received: from hylle01.itea.ntnu.no (hylle01.itea.ntnu.no [IPv6:2001:700:300:3::100]) by mx1.freebsd.org (Postfix) with ESMTP id 8D6888FC13 for ; Sun, 25 Oct 2009 21:52:58 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by hylle01.itea.ntnu.no (Postfix) with ESMTP id 02DFC31E039; Sun, 25 Oct 2009 22:52:57 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at hylle01.itea.ntnu.no Received: from nobby.geeknest.org (caracal.stud.ntnu.no [IPv6:2001:700:300:3::185]) by hylle01.itea.ntnu.no (Postfix) with ESMTP id AC8FF31E027; Sun, 25 Oct 2009 22:52:56 +0100 (CET) Date: Sun, 25 Oct 2009 23:52:17 +0100 From: Ulf Lilleengen To: Mario Lobo Message-ID: <20091025225217.GA19203@nobby.geeknest.org> References: <200910251358.25572.mlobo@digiart.art.br> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200910251358.25572.mlobo@digiart.art.br> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: freebsd-current@freebsd.org Subject: Re: Marvell Yukon 88E8042 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Oct 2009 21:52:59 -0000 On Sun, Oct 25, 2009 at 01:58:25PM -0300, Mario Lobo wrote: > Hi; > > I have just acquired an HP 510 Laptop that came with this board. > I installed FBSD 8 amd64 on it and the msk driver didn't recognized this chip, > so I ran pciconf -l to get the chip id and added is identification to the > source msk code as follows: > > if_msk.c: > > added this to the msk_products[] struc: > > { VENDORID_MARVELL, DEVICEID_MRVL_8042, > "Marvell Yukon 88E8042 Gigabit Ethernet" }, > > if_mskreg.h: > > Added: > > #define DEVICEID_MRVL_8042 0x4357 > > After this, the chip was properly detected and the driver has been working > flawlessly since. > > Committed, thanks! -- Ulf Lilleengen From owner-freebsd-current@FreeBSD.ORG Sun Oct 25 21:49:05 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8A12D106566B for ; Sun, 25 Oct 2009 21:49:05 +0000 (UTC) (envelope-from lulf@pvv.ntnu.no) Received: from hylle02.itea.ntnu.no (hylle02.itea.ntnu.no [IPv6:2001:700:300:3::101]) by mx1.freebsd.org (Postfix) with ESMTP id 139F98FC18 for ; Sun, 25 Oct 2009 21:49:05 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by hylle02.itea.ntnu.no (Postfix) with ESMTP id AD2862C60C; Sun, 25 Oct 2009 22:49:03 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at hylle02.itea.ntnu.no Received: from nobby.geeknest.org (caracal.stud.ntnu.no [IPv6:2001:700:300:3::185]) by hylle02.itea.ntnu.no (Postfix) with ESMTP id 1FE5C2C035; Sun, 25 Oct 2009 22:49:03 +0100 (CET) Date: Sun, 25 Oct 2009 23:48:23 +0100 From: Ulf Lilleengen To: Mario Lobo Message-ID: <20091025224823.GA19129@nobby.geeknest.org> References: <200910251358.25572.mlobo@digiart.art.br> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200910251358.25572.mlobo@digiart.art.br> User-Agent: Mutt/1.5.20 (2009-06-14) X-Mailman-Approved-At: Sun, 25 Oct 2009 22:02:40 +0000 Cc: freebsd-current@freebsd.org Subject: Re: Marvell Yukon 88E8042 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Oct 2009 21:49:05 -0000 On Sun, Oct 25, 2009 at 01:58:25PM -0300, Mario Lobo wrote: > Hi; > > I have just acquired an HP 510 Laptop that came with this board. > I installed FBSD 8 amd64 on it and the msk driver didn't recognized this chip, > so I ran pciconf -l to get the chip id and added is identification to the > source msk code as follows: > > if_msk.c: > > added this to the msk_products[] struc: > > { VENDORID_MARVELL, DEVICEID_MRVL_8042, > "Marvell Yukon 88E8042 Gigabit Ethernet" }, > > if_mskreg.h: > > Added: > > #define DEVICEID_MRVL_8042 0x4357 > > After this, the chip was properly detected and the driver has been working > flawlessly since. > Committed, thanks! -- Ulf Lilleengen From owner-freebsd-current@FreeBSD.ORG Sun Oct 25 22:05:12 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9697B106568D; Sun, 25 Oct 2009 22:05:12 +0000 (UTC) (envelope-from ehrmann@gmail.com) Received: from mail-iw0-f189.google.com (mail-iw0-f189.google.com [209.85.223.189]) by mx1.freebsd.org (Postfix) with ESMTP id 491798FC19; Sun, 25 Oct 2009 22:05:11 +0000 (UTC) Received: by iwn27 with SMTP id 27so5670485iwn.7 for ; Sun, 25 Oct 2009 15:05:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=DyU+7TX5FOgog0sVtmCBDClWwNjVnmyb4Ipl4p0eq0A=; b=E4rOu9MEvWt4t3h3ck/RVPfTIj2hT/Bbk/rnkfvTTnNAbxDzcHd0rCp8mWNDu+5ToU 0cQ0OGRh3zKmyFcubw2Hqwp16wyOdljrX7hAqmJyGmaLSuBk+000jTW99GOcQKix5J+w fE7a8pDXJYoeKiNwX0lExIL3/mTGw6CTT7w3M= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=eA7n2EhuvDLcT6O7+waW4VuzOkaBxH2nb00itE0wOhUe4vUalzgy2cV0kMpICs0Emn Zo8PsS91usGsAS2d9YKns3LN8ZQIyGPkOIc1+VvZqjs7npCiTSL7vd4j1bbEfWYy0RlY Rc7fmWtz/XmA0kJRoo4y4aAW++XJW4od/yAg8= MIME-Version: 1.0 Received: by 10.231.122.162 with SMTP id l34mr7636564ibr.20.1256508311527; Sun, 25 Oct 2009 15:05:11 -0700 (PDT) In-Reply-To: <9bbcef730910251440y30c05f45w149a3e4ab06849df@mail.gmail.com> References: <4ADF70F1.5060300@gmail.com> <4AE0DCDF.7090604@gmail.com> <20091023183708.GA6050@michelle.cdnetworks.com> <6e0e5340910231237v3f19b27ex1cbefd3f9a01af54@mail.gmail.com> <20091023194755.GC6050@michelle.cdnetworks.com> <20091023202604.GD6050@michelle.cdnetworks.com> <6e0e5340910231531n737ac71ds11a07117c3f7667e@mail.gmail.com> <6e0e5340910251429n7b95143emb9a97b29d329ab1c@mail.gmail.com> <9bbcef730910251440y30c05f45w149a3e4ab06849df@mail.gmail.com> Date: Sun, 25 Oct 2009 15:05:11 -0700 Message-ID: <6e0e5340910251505r15614b7bqb9d42c0055d8f940@mail.gmail.com> From: David Ehrmann To: Ivan Voras Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: pyunyh@gmail.com, freebsd-current@freebsd.org Subject: Re: Strange issue with Samba on 8.0rc1 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Oct 2009 22:05:12 -0000 On Sun, Oct 25, 2009 at 2:40 PM, Ivan Voras wrote: > > Sorry, but I can only give you generic ideas: > - It is unlikely that the storage media (flash) with FreeBSD has > errors in such a way that would cause this subtle error > I agree about the flash. I would expect it to fail in blocks, and if it were out of spare blocks, almost everything would be acting strange. I can probably test for this by comparing files in /usr/obj and /usr. - Can you try a "known good" FreeBSD 8 configuration? I.e. from a Live > CD or USB media? The "live" edition has csup and everything else you > could need. > That's a good idea, and the next thing I'll try. - Can you try a simple cheap "known good" NIC? I see that retail > Realtek-based PCI NICs sell for less than $10. > I'd have to choose between PCI-E and USB, and the PCI-E is tricky because the case doesn't have a cutout for it. I did try the vr0 interface, too (but not exclusively; I left the vge interface up), and it had the same problems. Since these things are usually wired directly to the Southbridge, a problem in the Southbridge driver would show up with any PCI(E) device. From owner-freebsd-current@FreeBSD.ORG Mon Oct 26 00:02:39 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 401D41065679 for ; Mon, 26 Oct 2009 00:02:39 +0000 (UTC) (envelope-from merijn@inconsistent.nl) Received: from smtp-vbr10.xs4all.nl (smtp-vbr10.xs4all.nl [194.109.24.30]) by mx1.freebsd.org (Postfix) with ESMTP id B98ED8FC1B for ; Mon, 26 Oct 2009 00:02:38 +0000 (UTC) Received: from localhost (inconsistent.nl [83.163.46.169]) (authenticated bits=0) by smtp-vbr10.xs4all.nl (8.13.8/8.13.8) with ESMTP id n9PNjibK023645 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for ; Mon, 26 Oct 2009 00:45:44 +0100 (CET) (envelope-from merijn@inconsistent.nl) Content-Type: text/plain; charset=utf-8; format=flowed; delsp=yes Organization: Inconsistent To: "freebsd-current@freebsd.org" Date: Mon, 26 Oct 2009 00:45:44 +0100 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit From: "Merijn Verstraaten" Message-ID: User-Agent: Opera Mail/10.00 (MacIntel) X-Virus-Scanned: by XS4ALL Virus Scanner Subject: GPT boot with ZFS RAIDZ "ZFS: i/o error - all block copies unavailable" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: merijn@inconsistent.nl List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Oct 2009 00:02:39 -0000 > Ok, can you retest with -CURRENT? I just committed some fixes on > Friday. I'm having real difficulty in reproducing these issues. Most > of the problems that I've run into so far had to do with the system not > knowing about all of the vdevs when it wanted to read something. In > your case, it looks like you are making it to boot3 and it appears to be > seeing all 4 of your disks. Right now, I've been trying to track down > an issue wher the MOS can't be read, which basically means that we have > screwed up the root block pointer somehow. I haven't been able to > reproduce that issue in qemu, I have been able to reproduce it with > VirtualBox, but it is really time consuming trying to work in vbox since > I have to reconvert all of the disk images every time I make a change. > I'm actually a bit concerned that it hinges on how many drives are > visible to the bios at various points in time. > robert. I noticed this thread in the archives and I've been having the same problems as Radek (see belw) with root on ZFS RAID-Z not booting the machine. When I install world from the 8.0-RC1 USB image I can boot from RAID-Z with no problems. But when I csup'ed to RELENG_8 yesterday (Saturday, so this should be after you committed the new changes) and build+installed world booting from RAID-Z broke with the exact same problems as Radek describes below. I just tried again to be absolutely sure (It just occured to me I perhaps should have done "gpart show", "zpool status" and "zpool get all z" before breaking the system, but oh well...). I have 4 SATA disks ad4, ad6, ad8 and ad10 with three partitions each, adXp1 is a freebsd-boot partition like Radek has, adXp2 is a 1GB freebsd-swap partition and adXp3 has the rest of the disk as a freebsd-zfs partition. These 4 p3 partitions are placed in a single RAID-Z vdev. zpool status looks pretty much like that of Radek too. I have my root partition in tank/root and mount things like tank/usr and tank/var inside tank/root. After installing 8.0-RC1 (amd64) from USB stick this installation works fine. If I csup to RELENG_8 (amd64) and compile + install world and kernel booting from the ZFS fails. The initial installation I did just this, on another attempt I ran "gpart bootcode -b /boot/pbmr -p /boot/gptzfsboot adX" on all disks before rebooting to see if that had any effect. The end result is the same. After rebooting the machine I get the following prompt(s): ZFS: i/o error - all block copies unavailable Invalid format FreeBSD/i386 boot Default: tank:/boot/kernel/kernel boot: If I wait a while this prompt repeats itself. I've beent rying to test inside VirtualBox to see if I could report more detail on what's going wrong but I ran into the same problem as you with the "MOS can't be read" error. This machine and zpool don't (at this time) contain any valuable data, so if you need someone to test anything for you I'd gladly volunteer my box if it helps resolve things faster. Kind regards, Merijn Verstraaten On Sat, 2009-10-24 at 19:44 +0200, Radek ValĂĄĹĄek wrote: > Robert Noland napsal(a): > > On Thu, 2009-10-15 at 21:37 +0200, Radek ValĂĄĹĄek wrote: > > >> Robert Noland napsal(a): > >> >>> On Thu, 2009-10-15 at 14:08 +0200, Radek ValĂĄĹĄek wrote: > >>> >>> >>>> Hi, > >>>> > >>>> I want to ask if there is something new in adding support to>>>> > gptzfsboot/zfsboot for reading gang-blocks? > >>>> >>>> > > > I think that the gang block patch will work, though still haven't > gotten > > it tested. However, I'm fairly confident that the issue is not gang > > block related. Right now, I have setup a disk like this: > > > > => 34 1953525101 ada1 GPT (932G) > > 34 128 1 freebsd-boot (64K) > > 162 8388608 2 freebsd-swap (4.0G) > > 8388770 648019968 3 freebsd-zfs (309G) > > 656408738 648019968 4 freebsd-zfs (309G) > > 1304428706 648019968 5 freebsd-zfs (309G) > > 1952448674 1076461 - free - (526M) > > > > Note that this is not a raidz pool right now. It is just 3 toplevel > > partitions setup as a single pool. I finally have this configuration > > working reliably. At least in this case, the issue is due to all of > the > > partitions not being probed during early boot and so not being added to > > the list of vdevs for the pool. When zio_read finds a dva that points > > to a device it doesn't know about, it gives up and whines. > > > > Can you detail for me how you have everything configured, so that I can > > try to replicate it. gpart show, zpool status and zpool get all > > would be good. I'm not sure that I have enough spare disks lying > around > > to do this properly, but maybe I can use virtual disks or something. > > > > robert. > > > > Sorry for not responding so long. Here are details you want from me: > # gpart show > => 34 1953525101 ad6 GPT (932G) > 34 128 1 freebsd-boot (64K) > 162 1953524973 2 freebsd-zfs (932G) > => 34 1953525101 ad8 GPT (932G) > 34 128 1 freebsd-boot (64K) > 162 1953524973 2 freebsd-zfs (932G) > => 34 1953525101 ad10 GPT (932G) > 34 128 1 freebsd-boot (64K) > 162 1953524973 2 freebsd-zfs (932G) > => 34 1953525101 ad12 GPT (932G) > 34 128 1 freebsd-boot (64K) > 162 1953524973 2 freebsd-zfs (932G) > # zpool status > pool: z > state: ONLINE > scrub: none requested > config: > NAME STATE READ WRITE CKSUM > z ONLINE 0 0 0 > raidz1 ONLINE 0 0 0 > ad6p2 ONLINE 0 0 0 > ad8p2 ONLINE 0 0 0 > ad10p2 ONLINE 0 0 0 > ad12p2 ONLINE 0 0 0 > errors: No known data errors > # zpool get all z > NAME PROPERTY VALUE SOURCE > z size 3.62T - > z used 4.62G - > z available 3.62T - > z capacity 0% - > z altroot - default > z health ONLINE - > z guid 17857007133862981114 - > z version 13 default > z bootfs z/system local > z delegation on default > z autoreplace off default > z cachefile - default > z failmode wait default > z listsnapshots off default > I've tested your patches but it seems that you're right and it's notgang > related issue. I was able to discover these things on a fullyfunctional > zfs pool (system compiled with your patches): > 1, If I overwrite the file /boot/loader.conf (with copy of itself, or > when upgrading kernel/world), next reboot comes with these messages: > BTX loader 1.00 BTX version is 1.02 > Consoles: internal video/keyboard > BIOS drive C: is disk0 > BIOS drive D: is disk1 > BIOS drive E: is disk2 > BIOS drive F: is disk3 > BIOS 627kB/3405248kB available memory > FreeBSD/i386 bootstrap loader, Revision 1.1 > (root at ztest, Thu Oct 22 22:27:22 CEST 2009) > Loading /boot/defaults/loader.conf > ZFS: i/o error - all block copies unavailable > Warning: error reading file /boot/loader.conf > Then I'm still able to boot the system, but I must set the bootvariables > included in loader.conf by hand > 2, Next I overwrite the file /boot/loader (with copy of itself, or when > upgrading kernel/world) and reboot comes with these messages: > BTX loader 1.00 BTX version is 1.02 > Consoles: internal video/keyboard > BIOS drive C: is disk0 > BIOS drive D: is disk1 > BIOS drive E: is disk2 > BIOS drive F: is disk3 > BIOS 627kB/3405248kB available memory > FreeBSD/i386 bootstrap loader, Revision 1.1 > (root at ztest, Thu Oct 22 22:27:22 CEST 2009) > Loading /boot/defaults/loader.conf > ZFS: i/o error - all block copies unavailable > Warning: error reading file /boot/loader.conf > ZFS: i/o error - all block copies unavailable > ZFS: i/o error - all block copies unavailable > ZFS: i/o error - all block copies unavailable > ZFS: i/o error - all block copies unavailable > ZFS: i/o error - all block copies unavailable > ZFS: i/o error - all block copies unavailable > ZFS: i/o error - all block copies unavailable > ZFS: i/o error - all block copies unavailable > Unable to load a kernel! > After that I'm no longer able to boot the system from zfs pool. > Hope you have some ideas... From owner-freebsd-current@FreeBSD.ORG Mon Oct 26 00:32:03 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 768EA1065692 for ; Mon, 26 Oct 2009 00:32:03 +0000 (UTC) (envelope-from rnoland@FreeBSD.org) Received: from gizmo.2hip.net (gizmo.2hip.net [64.74.207.195]) by mx1.freebsd.org (Postfix) with ESMTP id 365FC8FC15 for ; Mon, 26 Oct 2009 00:32:02 +0000 (UTC) Received: from [192.168.1.4] (adsl-150-102-19.bna.bellsouth.net [72.150.102.19]) (authenticated bits=0) by gizmo.2hip.net (8.14.3/8.14.3) with ESMTP id n9Q0Vqau019619 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Sun, 25 Oct 2009 20:31:58 -0400 (EDT) (envelope-from rnoland@FreeBSD.org) From: Robert Noland To: merijn@inconsistent.nl In-Reply-To: References: Content-Type: text/plain; charset="iso-8859-2" Organization: FreeBSD Date: Sun, 25 Oct 2009 19:31:46 -0500 Message-Id: <1256517106.2502.205.camel@balrog.2hip.net> Mime-Version: 1.0 X-Mailer: Evolution 2.26.3 FreeBSD GNOME Team Port Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-1.9 required=5.0 tests=AWL,BAYES_00, RCVD_IN_SORBS_DUL, RDNS_DYNAMIC, SPF_SOFTFAIL autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on gizmo.2hip.net Cc: "freebsd-current@freebsd.org" Subject: Re: GPT boot with ZFS RAIDZ "ZFS: i/o error - all block copies unavailable" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Oct 2009 00:32:03 -0000 On Mon, 2009-10-26 at 00:45 +0100, Merijn Verstraaten wrote: > > Ok, can you retest with -CURRENT? I just committed some fixes on > > Friday. I'm having real difficulty in reproducing these issues. Most > > of the problems that I've run into so far had to do with the system not > > knowing about all of the vdevs when it wanted to read something. In > > your case, it looks like you are making it to boot3 and it appears to be > > seeing all 4 of your disks. Right now, I've been trying to track down > > an issue wher the MOS can't be read, which basically means that we have > > screwed up the root block pointer somehow. I haven't been able to > > reproduce that issue in qemu, I have been able to reproduce it with > > VirtualBox, but it is really time consuming trying to work in vbox since > > I have to reconvert all of the disk images every time I make a change. > > I'm actually a bit concerned that it hinges on how many drives are > > visible to the bios at various points in time. > > robert. > > I noticed this thread in the archives and I've been having the same > problems as Radek (see belw) with root on ZFS RAID-Z not booting the > machine. When I install world from the 8.0-RC1 USB image I can boot from > RAID-Z with no problems. But when I csup'ed to RELENG_8 yesterday > (Saturday, so this should be after you committed the new changes) and > build+installed world booting from RAID-Z broke with the exact same > problems as Radek describes below. I just tried again to be absolutely > sure (It just occured to me I perhaps should have done "gpart show", > "zpool status" and "zpool get all z" before breaking the system, but oh > well...). > > I have 4 SATA disks ad4, ad6, ad8 and ad10 with three partitions each, > adXp1 is a freebsd-boot partition like Radek has, adXp2 is a 1GB > freebsd-swap partition and adXp3 has the rest of the disk as a freebsd-zfs > partition. These 4 p3 partitions are placed in a single RAID-Z vdev. zpool > status looks pretty much like that of Radek too. I have my root partition > in tank/root and mount things like tank/usr and tank/var inside tank/root. > > After installing 8.0-RC1 (amd64) from USB stick this installation works > fine. If I csup to RELENG_8 (amd64) and compile + install world and kernel > booting from the ZFS fails. The initial installation I did just this, on > another attempt I ran "gpart bootcode -b /boot/pbmr -p /boot/gptzfsboot > adX" on all disks before rebooting to see if that had any effect. The end > result is the same. After rebooting the machine I get the following > prompt(s): > > ZFS: i/o error - all block copies unavailable > Invalid format > > FreeBSD/i386 boot > Default: tank:/boot/kernel/kernel > boot: Could you type "status" at this point and tell what it shows? I'm convinced that almost all of these issues have to do with what drives are visible at any given time. We actually probe for all the drives twice, once during the early boot (gptzfsboot) and again in stage 3... They don't find the same set of drives in at least some cases. In order to successfully boot, we need to see all of the drives at both stages. The more drives that you have the more likely it is that we run into issues. > If I wait a while this prompt repeats itself. I've beent rying to test > inside VirtualBox to see if I could report more detail on what's going > wrong but I ran into the same problem as you with the "MOS can't be read" > error. So, something about the virtual box bios and our loader, don't get along well. I finally have it booting from a 6 drive raidz2, but what drives are detected during the early boot depend on what controllers I've told vbox to use to host the drives. Basically in order to get it to work, I had to tell it that the first two drives are on ide and the remaining 4 drives are on sata/scsi. Once we get to stage 3, the current code only finds a single hard drive, so at best you have a 25% chance of booting... As the blocks get spread around on the drives, we start reading block pointers that point to devices that we don't know about. My current hacked up code is now seeing 30 drives in stage 3, which is also not correct... but it is booting... robert. > This machine and zpool don't (at this time) contain any valuable data, so > if you need someone to test anything for you I'd gladly volunteer my box > if it helps resolve things faster. > > Kind regards, > Merijn Verstraaten > > > On Sat, 2009-10-24 at 19:44 +0200, Radek Valášek wrote: > > Robert Noland napsal(a): > > > On Thu, 2009-10-15 at 21:37 +0200, Radek Valášek wrote: > > > >> Robert Noland napsal(a): > > >> >>> On Thu, 2009-10-15 at 14:08 +0200, Radek Valášek wrote: > > >>> >>> >>>> Hi, > > >>>> > > >>>> I want to ask if there is something new in adding support to>>>> > > gptzfsboot/zfsboot for reading gang-blocks? > > >>>> >>>> > > > > I think that the gang block patch will work, though still haven't > > gotten > > > it tested. However, I'm fairly confident that the issue is not gang > > > block related. Right now, I have setup a disk like this: > > > > > > => 34 1953525101 ada1 GPT (932G) > > > 34 128 1 freebsd-boot (64K) > > > 162 8388608 2 freebsd-swap (4.0G) > > > 8388770 648019968 3 freebsd-zfs (309G) > > > 656408738 648019968 4 freebsd-zfs (309G) > > > 1304428706 648019968 5 freebsd-zfs (309G) > > > 1952448674 1076461 - free - (526M) > > > > > > Note that this is not a raidz pool right now. It is just 3 toplevel > > > partitions setup as a single pool. I finally have this configuration > > > working reliably. At least in this case, the issue is due to all of > > the > > > partitions not being probed during early boot and so not being added to > > > the list of vdevs for the pool. When zio_read finds a dva that points > > > to a device it doesn't know about, it gives up and whines. > > > > > > Can you detail for me how you have everything configured, so that I can > > > try to replicate it. gpart show, zpool status and zpool get all > > > would be good. I'm not sure that I have enough spare disks lying > > around > > > to do this properly, but maybe I can use virtual disks or something. > > > > > > robert. > > > > > > Sorry for not responding so long. Here are details you want from me: > > # gpart show > > => 34 1953525101 ad6 GPT (932G) > > 34 128 1 freebsd-boot (64K) > > 162 1953524973 2 freebsd-zfs (932G) > > => 34 1953525101 ad8 GPT (932G) > > 34 128 1 freebsd-boot (64K) > > 162 1953524973 2 freebsd-zfs (932G) > > => 34 1953525101 ad10 GPT (932G) > > 34 128 1 freebsd-boot (64K) > > 162 1953524973 2 freebsd-zfs (932G) > > => 34 1953525101 ad12 GPT (932G) > > 34 128 1 freebsd-boot (64K) > > 162 1953524973 2 freebsd-zfs (932G) > > # zpool status > > pool: z > > state: ONLINE > > scrub: none requested > > config: > > NAME STATE READ WRITE CKSUM > > z ONLINE 0 0 0 > > raidz1 ONLINE 0 0 0 > > ad6p2 ONLINE 0 0 0 > > ad8p2 ONLINE 0 0 0 > > ad10p2 ONLINE 0 0 0 > > ad12p2 ONLINE 0 0 0 > > errors: No known data errors > > # zpool get all z > > NAME PROPERTY VALUE SOURCE > > z size 3.62T - > > z used 4.62G - > > z available 3.62T - > > z capacity 0% - > > z altroot - default > > z health ONLINE - > > z guid 17857007133862981114 - > > z version 13 default > > z bootfs z/system local > > z delegation on default > > z autoreplace off default > > z cachefile - default > > z failmode wait default > > z listsnapshots off default > > I've tested your patches but it seems that you're right and it's notgang > > related issue. I was able to discover these things on a fullyfunctional > > zfs pool (system compiled with your patches): > > 1, If I overwrite the file /boot/loader.conf (with copy of itself, or > > when upgrading kernel/world), next reboot comes with these messages: > > BTX loader 1.00 BTX version is 1.02 > > Consoles: internal video/keyboard > > BIOS drive C: is disk0 > > BIOS drive D: is disk1 > > BIOS drive E: is disk2 > > BIOS drive F: is disk3 > > BIOS 627kB/3405248kB available memory > > FreeBSD/i386 bootstrap loader, Revision 1.1 > > (root at ztest, Thu Oct 22 22:27:22 CEST 2009) > > Loading /boot/defaults/loader.conf > > ZFS: i/o error - all block copies unavailable > > Warning: error reading file /boot/loader.conf > > Then I'm still able to boot the system, but I must set the bootvariables > > included in loader.conf by hand > > 2, Next I overwrite the file /boot/loader (with copy of itself, or when > > upgrading kernel/world) and reboot comes with these messages: > > BTX loader 1.00 BTX version is 1.02 > > Consoles: internal video/keyboard > > BIOS drive C: is disk0 > > BIOS drive D: is disk1 > > BIOS drive E: is disk2 > > BIOS drive F: is disk3 > > BIOS 627kB/3405248kB available memory > > FreeBSD/i386 bootstrap loader, Revision 1.1 > > (root at ztest, Thu Oct 22 22:27:22 CEST 2009) > > Loading /boot/defaults/loader.conf > > ZFS: i/o error - all block copies unavailable > > Warning: error reading file /boot/loader.conf > > ZFS: i/o error - all block copies unavailable > > ZFS: i/o error - all block copies unavailable > > ZFS: i/o error - all block copies unavailable > > ZFS: i/o error - all block copies unavailable > > ZFS: i/o error - all block copies unavailable > > ZFS: i/o error - all block copies unavailable > > ZFS: i/o error - all block copies unavailable > > ZFS: i/o error - all block copies unavailable > > Unable to load a kernel! > > After that I'm no longer able to boot the system from zfs pool. > > Hope you have some ideas... > _______________________________________________ > 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" -- Robert Noland FreeBSD From owner-freebsd-current@FreeBSD.ORG Mon Oct 26 04:38:16 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BA1AC106566B for ; Mon, 26 Oct 2009 04:38:16 +0000 (UTC) (envelope-from john.marshall@riverwillow.com.au) Received: from mail1.riverwillow.net.au (mail1.riverwillow.net.au [203.58.93.36]) by mx1.freebsd.org (Postfix) with ESMTP id 1D9BB8FC12 for ; Mon, 26 Oct 2009 04:38:15 +0000 (UTC) Received: from rwpc12.mby.riverwillow.net.au (rwpc12.mby.riverwillow.net.au [172.25.24.168]) (authenticated bits=0) by mail1.riverwillow.net.au (8.14.3/8.14.3) with ESMTP id n9Q4cAa6016693 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Mon, 26 Oct 2009 15:38:11 +1100 (AEDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=riverwillow.com.au; s=m1001; t=1256531891; bh=lcA0BUxeKrbIqoyKcx8ANiqiJbzHRN1mP2K5w4djw5o=; h=Date:From:To:Subject:Message-ID:Mime-Version:Content-Type; b=jzI/Bo579U0gt7hxwI1q+U6LJyZtYNUCVz87oxCX+w9AQ8Dj4ORl57JDvhoZkZAJr Qkoy8V4GoOA2XNRcdjV+wZ1BjTRckBBV3wPpChgo+SyvlFnP/zZIeiMZ9/uWyKT3oV 26mefUP3z94ervBvBKjZyJfDQjZ6FrxHXZ2CLLyQ= Received: from rwpc12.mby.riverwillow.net.au (localhost [127.0.0.1]) by rwpc12.mby.riverwillow.net.au (8.14.3/8.14.3) with ESMTP id n9Q4cAWe048483 for ; Mon, 26 Oct 2009 15:38:10 +1100 (AEDT) (envelope-from john.marshall@riverwillow.com.au) Received: (from john@localhost) by rwpc12.mby.riverwillow.net.au (8.14.3/8.14.3/Submit) id n9Q4c9lC048482 for freebsd-current@freebsd.org; Mon, 26 Oct 2009 15:38:09 +1100 (AEDT) (envelope-from john) Date: Mon, 26 Oct 2009 15:38:09 +1100 From: John Marshall To: freebsd-current@freebsd.org Message-ID: <20091026043808.GA1064@rwpc12.mby.riverwillow.net.au> Mail-Followup-To: freebsd-current@freebsd.org Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="ZGiS0Q5IWpPtfppv" Content-Disposition: inline User-Agent: Mutt/1.4.2.3i OpenPGP: id=A29A84A2; url=http://pki.riverwillow.net.au/pgp/johnmarshall.asc Subject: Kernel Build Knob for kgssapi_krb5? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Oct 2009 04:38:16 -0000 --ZGiS0Q5IWpPtfppv Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Is there a knob somewhere to enable building of the kgssapi_krb5 module? I have just built 8.0-RC2/i386 and decided to have a look at the (experimental) NFSv4 stuff. I included options NFSD and NFSCL in my kernel configuration. nfsd(8) indicates that gssd(8) has to be running in order for the server to provide gss/krb5 access control. If I try starting gssd(8) it complains of a missing kgssapi_krb5 kernel module. The module hasn't been built. I've checked the GENERIC and NOTES files and can't find any reference to kgssapi_krb5. Is there an undocumented configuration option for this? Also, is there a "getting started" or "how to test" page somewhere to give us some clues to get this going? Thank you. --=20 John Marshall --ZGiS0Q5IWpPtfppv Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.13 (FreeBSD) iEYEARECAAYFAkrlJ7AACgkQw/tAaKKahKLH0QCeMrSnS58KsDqxnERF59BxVIWm vowAnRPdLBasZSq5p2eAUv5db7JpDbAb =BUrQ -----END PGP SIGNATURE----- --ZGiS0Q5IWpPtfppv-- From owner-freebsd-current@FreeBSD.ORG Mon Oct 26 06:16:24 2009 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3CA78106568D for ; Mon, 26 Oct 2009 06:16:24 +0000 (UTC) (envelope-from bf1783@googlemail.com) Received: from mail-ew0-f218.google.com (mail-ew0-f218.google.com [209.85.219.218]) by mx1.freebsd.org (Postfix) with ESMTP id CA6C58FC14 for ; Mon, 26 Oct 2009 06:16:23 +0000 (UTC) Received: by ewy18 with SMTP id 18so10196522ewy.43 for ; Sun, 25 Oct 2009 23:16:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:cc:content-type; bh=qEjHU1nTmlh6EmBwEoO+/sIZLm817ENZoT+E6g1DLks=; b=LI4aG5GYLoaz3SokIxxsJCSIFUMhBzVPIEYfDYk/T/DCj0dS5I42rAZY1t/mS9HEbU crJhJ7uY+mK4dI0RWYiaskxjuBgCcx6Roie705rigsKV1jBS9rlE0aBA4HrIhW+g1lvX I1YlFpPc7AvbadxLfmZvo4v9FWt0dL7IESiPM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:cc:content-type; b=XeLX2tw8O82Z10+5sZtCj4hXgXllLPepxHsLtW5n+n5HGiRzbORalPzWIRjo9befI9 gwj16RBNxQtvD2wUezYfQhlMzFvpSkXEpooHo8MnGJFMuXCf1EJesbWQMopK2ajwDtol C+vRArwb8EJnFekI9PzAV7G3oplzUdwrnW8zY= MIME-Version: 1.0 Received: by 10.216.88.71 with SMTP id z49mr1408626wee.90.1256537782656; Sun, 25 Oct 2009 23:16:22 -0700 (PDT) Date: Mon, 26 Oct 2009 06:16:22 +0000 Message-ID: From: "b. f." To: john.marshall@riverwillow.com.au Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-current@FreeBSD.org Subject: Re: Kernel Build Knob for kgssapi_krb5? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Oct 2009 06:16:24 -0000 >Is there a knob somewhere to enable building of the kgssapi_krb5 module? > I don't see any for the module -- Doug Rabson doesn't seem to have added it to /usr/src/sys/modules/Makefile in r184588: http://svn.freebsd.org/viewvc/base?view=revision&revision=184588 And I see that it has some implicit dependencies, like INET6, so the kinks have not been ironed out of this portion of the code. You could try: cd /usr/src/sys/modules/kgssapi_krb5 && make obj && make depend && make && make install >I have just built 8.0-RC2/i386 and decided to have a look at the >(experimental) NFSv4 stuff. I included options NFSD and NFSCL in my >kernel configuration. nfsd(8) indicates that gssd(8) has to be running >in order for the server to provide gss/krb5 access control. If I try >starting gssd(8) it complains of a missing kgssapi_krb5 kernel module. >The module hasn't been built. I've checked the GENERIC and NOTES files >and can't find any reference to kgssapi_krb5. Is there an undocumented >configuration option for this? > >Also, is there a "getting started" or "how to test" page somewhere to >give us some clues to get this going? See the commit message mentioned above. Also, the primary author, Rick Macklem, has a tutorial: http://code.google.com/p/macnfsv4/wiki/FreeBSD8KerberizedNFSSetup b. From owner-freebsd-current@FreeBSD.ORG Mon Oct 26 09:23:37 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9F3D41065670 for ; Mon, 26 Oct 2009 09:23:37 +0000 (UTC) (envelope-from merijn@inconsistent.nl) Received: from smtp-vbr5.xs4all.nl (smtp-vbr5.xs4all.nl [194.109.24.25]) by mx1.freebsd.org (Postfix) with ESMTP id 39D6E8FC1E for ; Mon, 26 Oct 2009 09:23:36 +0000 (UTC) Received: from localhost (inconsistent.nl [83.163.46.169]) (authenticated bits=0) by smtp-vbr5.xs4all.nl (8.13.8/8.13.8) with ESMTP id n9Q9NZWQ081927 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for ; Mon, 26 Oct 2009 10:23:35 +0100 (CET) (envelope-from merijn@inconsistent.nl) Content-Type: text/plain; charset=utf-8; format=flowed; delsp=yes To: "freebsd-current@freebsd.org" References: <1256517106.2502.205.camel@balrog.2hip.net> Date: Mon, 26 Oct 2009 10:23:36 +0100 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit From: "Merijn Verstraaten" Organization: Inconsistent Message-ID: In-Reply-To: <1256517106.2502.205.camel@balrog.2hip.net> User-Agent: Opera Mail/10.00 (MacIntel) X-Virus-Scanned: by XS4ALL Virus Scanner Subject: Re: GPT boot with ZFS RAIDZ "ZFS: i/o error - all block copies unavailable" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: merijn@inconsistent.nl List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Oct 2009 09:23:37 -0000 On Mon, 26 Oct 2009 01:31:46 +0100, Robert Noland wrote: >> After installing 8.0-RC1 (amd64) from USB stick this installation works >> fine. If I csup to RELENG_8 (amd64) and compile + install world and >> kernel >> booting from the ZFS fails. The initial installation I did just this, on >> another attempt I ran "gpart bootcode -b /boot/pbmr -p /boot/gptzfsboot >> adX" on all disks before rebooting to see if that had any effect. The >> end >> result is the same. After rebooting the machine I get the following >> prompt(s): >> >> ZFS: i/o error - all block copies unavailable >> Invalid format >> >> FreeBSD/i386 boot >> Default: tank:/boot/kernel/kernel >> boot: > > Could you type "status" at this point and tell what it shows? If I type status at this point I get: pool: tank config: NAME STATE tank ONLINE raidz1 ONLINE ad4p3 ONLINE ad6p3 ONLINE ad8p3 ONLINE ad10p3 ONLINE Which seems odd, since that's all the drives there are. So if it finds these it's already found all drives. My optimistic "Oh! I'll try and boot again" spirit was however crushed since it just results in the same error. Kind regards, Merijn From owner-freebsd-current@FreeBSD.ORG Mon Oct 26 13:33:57 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3B2BC1065679 for ; Mon, 26 Oct 2009 13:33:57 +0000 (UTC) (envelope-from remko@elvandar.org) Received: from mailgate.jr-hosting.nl (mailgate.jr-hosting.nl [78.46.126.30]) by mx1.freebsd.org (Postfix) with ESMTP id E782E8FC17 for ; Mon, 26 Oct 2009 13:33:56 +0000 (UTC) Received: from websrv01.jr-hosting.nl (websrv01 [78.47.69.233]) by mailgate.jr-hosting.nl (Postfix) with ESMTP id 805591CD41; Mon, 26 Oct 2009 14:15:32 +0100 (CET) Received: from milamber.elvandar.org ([78.47.44.222] helo=[10.0.3.2]) by websrv01.jr-hosting.nl with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1N2PQ4-000O4k-FJ; Mon, 26 Oct 2009 14:15:32 +0100 Mime-Version: 1.0 (Apple Message framework v1076) Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes From: Remko Lodder In-Reply-To: <6e0e5340910231531n737ac71ds11a07117c3f7667e@mail.gmail.com> Date: Mon, 26 Oct 2009 14:15:32 +0100 Content-Transfer-Encoding: 7bit Message-Id: References: <4ADF70F1.5060300@gmail.com> <4AE0DCDF.7090604@gmail.com> <20091023183708.GA6050@michelle.cdnetworks.com> <6e0e5340910231237v3f19b27ex1cbefd3f9a01af54@mail.gmail.com> <20091023194755.GC6050@michelle.cdnetworks.com> <20091023202604.GD6050@michelle.cdnetworks.com> <6e0e5340910231531n737ac71ds11a07117c3f7667e@mail.gmail.com> To: David Ehrmann X-Mailer: Apple Mail (2.1076) X-Mailman-Approved-At: Mon, 26 Oct 2009 14:10:01 +0000 Cc: pyunyh@gmail.com, freebsd-current@freebsd.org, Ivan Voras Subject: Re: Strange issue with Samba on 8.0rc1 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Oct 2009 13:33:57 -0000 On Oct 24, 2009, at 12:31 AM, David Ehrmann wrote: > On Fri, Oct 23, 2009 at 1:26 PM, Pyun YongHyeon > wrote: >> >> >> Forgot to say one thing. >> AFAIK there is one bug which tries to adjust buffer length after >> loading dma map when frame length is less than 60 bytes. However >> I'm not sure whether this causes your Samba related issue. >> > > I just gave my other ethernet device, vr0, an IP and netmask. I'm > seeing > the same problem if I access the samba share via that IP. Unless > FreeBSD is > doing something funny and trying to guess that the two IP addresses > are on > the same network and sending all data out on the faster interface, I > think > the vge driver is off the hook. > > I also switched my laptop over from wifi to ethernet, but that also > didn't > change things. > _______________________________________________ Wait.. Are you telling us you have a vr and an vge card in the same network? that would surely generate problems. One of them will reply for the ARP address of the requested IP, because they both know the address for that. That could mean that sometimes the traffic goes to the vge, and sometimes to the vr device. The thing to avoid that is by unsetting ARP questions on the interface, and statically assigning it to your devices (arp -S/-s) so that they will only talk with the correct interface. The way I read this, it will never generate a good working test... -- /"\ Best regards, | remko@FreeBSD.org \ / Remko Lodder | remko@EFnet X http://www.evilcoder.org/ | / \ ASCII Ribbon Campaign | Against HTML Mail and News From owner-freebsd-current@FreeBSD.ORG Mon Oct 26 14:18:37 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DFA18106566C; Mon, 26 Oct 2009 14:18:37 +0000 (UTC) (envelope-from caelian@gmail.com) Received: from mail-ew0-f209.google.com (mail-ew0-f209.google.com [209.85.219.209]) by mx1.freebsd.org (Postfix) with ESMTP id 034128FC0C; Mon, 26 Oct 2009 14:18:36 +0000 (UTC) Received: by ewy5 with SMTP id 5so7328502ewy.36 for ; Mon, 26 Oct 2009 07:18:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=s7CuXtAViH8/zd7q9viw0dmeUggNfOFnmE33U+4RhVE=; b=qLGbLgjnxVMb9uFcsZ7IGVyHuDrCaPL+yjD0SW9jIt9mU8NShZA6RsTpcDtDWJCqOu Jx2aZwUUTQDD7ZLhxqNftdmoDjVCPMTPnaMrd1fX1ceru4ieOIwcPtZ/xJZEoJpXMmrB tgG+qK2sKWWmRdPqE6Gpms+Bit/SC1HAgoXiw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=TJ3/Q6SBwBCn+IIyVndNc3w42DvCyIAOecAZKKB552l5j06aforApHA3J6kK+1kDKL Ab1fTAnw0r+cRiqglggTYEo8S4bExZYZCcsu3Gmnze3mXxI1x/DH67jVEQkWWP6bjaKk MqPTXbJke+1RIoMlTrRe/F1CF7V9D3qSB8w7k= MIME-Version: 1.0 Received: by 10.211.146.5 with SMTP id y5mr2225643ebn.41.1256566716074; Mon, 26 Oct 2009 07:18:36 -0700 (PDT) In-Reply-To: <4AE3A001.8000205@FreeBSD.org> References: <4AE3A001.8000205@FreeBSD.org> Date: Mon, 26 Oct 2009 15:18:36 +0100 Message-ID: From: Pascal Hofstee To: Alexander Motin Content-Type: text/plain; charset=ISO-8859-1 Cc: icegloom dem , FreeBSD-Current , FreeBSD Stable , freebsd-amd64@freebsd.org Subject: Re: MCP55 SATA solution to test X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Oct 2009 14:18:38 -0000 2009/10/25 Alexander Motin : > Hi. > > Thanks to one man who provided access to his machine, I seem to found > how to fix device detection on nVidia MCP55 SATA controller on amd64 > 8.0. Looks like this controller need some time (very short) to enable > BAR(5) memory access after PCI configuration register written. Probably > some changes in PCI code exposed this issue. Also it explains why > setting hw.pci.mcfg to 0 helps. > > Attached patch solves problem for that machine. Testers are welcome. Confirmed this also fixes the SATA detection on my MSI K9N Neo on 9.0-CURRENT. Please commit :) From owner-freebsd-current@FreeBSD.ORG Mon Oct 26 15:00:32 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9DF9A106568B for ; Mon, 26 Oct 2009 15:00:32 +0000 (UTC) (envelope-from doug@polands.org) Received: from atlmtaow03.cingularme.com (atlmtaow03.cingularme.com [66.102.165.8]) by mx1.freebsd.org (Postfix) with ESMTP id 1DDBF8FC20 for ; Mon, 26 Oct 2009 15:00:31 +0000 (UTC) Received: from [10.215.16.57] (really [166.137.135.185]) by atlmtaow02.cingularme.com (InterMail vM.6.01.04.00 201-2131-118-20041027) with ESMTP id <20091026143632.OMTW27583.atlmtaow02.cingularme.com@[10.215.16.57]>; Mon, 26 Oct 2009 10:36:32 -0400 References: <46e678eb1eeca98033b15979e034a765.squirrel@email.polands.org> <2D80E5CB-71E5-4F4F-A84B-A95C18B50F47@exscape.org> Message-Id: <67BF95AE-2294-4249-9F22-487E6652E53E@polands.org> From: Doug Poland To: Thomas Backman In-Reply-To: <2D80E5CB-71E5-4F4F-A84B-A95C18B50F47@exscape.org> Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit X-Mailer: iPhone Mail (7D11) Mime-Version: 1.0 (iPhone Mail 7D11) Date: Mon, 26 Oct 2009 09:36:52 -0500 X-Cloudmark-Analysis: v=1.0 c=1 a=rr91BCKx9YgA:10 a=cgSqiB6BYjiz3vxIx17AKQ==:17 a=r-KksaJNAAAA:8 a=6I5d2MoRAAAA:8 a=nSrfBVD6MWPTn3FBk80A:9 a=ihJiw0rkUu-XBz7QCMr-_fLf_OwA:4 a=XSp_zfTBMSoA:10 Cc: "freebsd-current@freebsd.org" Subject: Re: Fatal trap 12 on ZFS in 8.0-RC1 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Oct 2009 15:00:32 -0000 On Oct 25, 2009, at 1:07, Thomas Backman wrote: > On Oct 25, 2009, at 3:10 AM, Doug Poland wrote: > >> Hello, >> >> I'm experimenting with ZFS on 8-0-RC1 (amd64) in a VMWare virtual >> machine w/2GB RAM. In installed ZFS on GPT root using the excellent >> instructions at http://wiki.freebsd.org/RootOnZFS/GPTZFSBoot/RAIDZ1. >> >> All was well until I tried some benchmarking with >> benchmarks/unixbench. I kept getting kmem_map too small panics on >> the >> filesystem tests so starting playing with vm.kmem_size. >> >> I finally got unixbench through the first 6 Filesystem Throughput >> tests with: >> vm.kmem_size="1296M" >> vm.kmem_size_max="1296M" >> vfs.zfs.arc_max="128M" >> vfs.zfs.vdev.cache.size="24M" (i think) >> >> Unfortunately, ZFS paniced with: >> Fatal trap 12: page fault while in kernel mode. Now, when I attempt >> to >> restart the VM, as soon as the "boot menu" is gone, I immediately get >> the same Fatal trap 12 panics again and cannot get past this point. >> >> I've got the 8.0-RC1 DVD and can run Fixit, but have no idea how to >> repair this broken ZFS installation. Suggestions welcome. > > You should be able to break into the loader prompt (choice #6 IIRC) > and do > unset vm.kmem_size > unset vm... > ... etc. > boot > > That way, you'll be back to the earlier panics, but at least it'll > boot. Oh, and the settings aren't permanent, so make editing /boot/ > loader.conf your first prority. > > Regards, > Thomas Thank you, that worked nicely. From owner-freebsd-current@FreeBSD.ORG Mon Oct 26 15:17:57 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 30337106566C for ; Mon, 26 Oct 2009 15:17:57 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from esa-annu.mail.uoguelph.ca (esa-annu.mail.uoguelph.ca [131.104.91.36]) by mx1.freebsd.org (Postfix) with ESMTP id D59B98FC1A for ; Mon, 26 Oct 2009 15:17:56 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAMJa5UqDaFvI/2dsb2JhbADYY4Q/BIFe X-IronPort-AV: E=Sophos;i="4.44,626,1249272000"; d="scan'208";a="51258520" Received: from darling.cs.uoguelph.ca ([131.104.91.200]) by esa-annu-pri.mail.uoguelph.ca with ESMTP; 26 Oct 2009 11:17:55 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by darling.cs.uoguelph.ca (Postfix) with ESMTP id 266559400CE; Mon, 26 Oct 2009 11:17:55 -0400 (EDT) X-Virus-Scanned: amavisd-new at darling.cs.uoguelph.ca Received: from darling.cs.uoguelph.ca ([127.0.0.1]) by localhost (darling.cs.uoguelph.ca [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id retJVPRwe3zG; Mon, 26 Oct 2009 11:17:54 -0400 (EDT) Received: from muncher.cs.uoguelph.ca (muncher.cs.uoguelph.ca [131.104.91.102]) by darling.cs.uoguelph.ca (Postfix) with ESMTP id 2D7A294009E; Mon, 26 Oct 2009 11:17:54 -0400 (EDT) Received: from localhost (rmacklem@localhost) by muncher.cs.uoguelph.ca (8.11.7p3+Sun/8.11.6) with ESMTP id n9QFOtt03589; Mon, 26 Oct 2009 11:24:55 -0400 (EDT) X-Authentication-Warning: muncher.cs.uoguelph.ca: rmacklem owned process doing -bs Date: Mon, 26 Oct 2009 11:24:55 -0400 (EDT) From: Rick Macklem X-X-Sender: rmacklem@muncher.cs.uoguelph.ca To: John Marshall In-Reply-To: <20091026043808.GA1064@rwpc12.mby.riverwillow.net.au> Message-ID: References: <20091026043808.GA1064@rwpc12.mby.riverwillow.net.au> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-current@freebsd.org Subject: Re: Kernel Build Knob for kgssapi_krb5? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Oct 2009 15:17:57 -0000 On Mon, 26 Oct 2009, John Marshall wrote: > Is there a knob somewhere to enable building of the kgssapi_krb5 module? > > I have just built 8.0-RC2/i386 and decided to have a look at the > (experimental) NFSv4 stuff. I included options NFSD and NFSCL in my > kernel configuration. nfsd(8) indicates that gssd(8) has to be running > in order for the server to provide gss/krb5 access control. If I try > starting gssd(8) it complains of a missing kgssapi_krb5 kernel module. > The module hasn't been built. I've checked the GENERIC and NOTES files > and can't find any reference to kgssapi_krb5. Is there an undocumented > configuration option for this? > > Also, is there a "getting started" or "how to test" page somewhere to > give us some clues to get this going? > You can try this wiki page (and feel free to add to it): http://code.google.com/p/macnfsv4/wiki/FreeBSD8KerberizedNFSSetup The kernel build options are: options KGSSAPI device crypto Good luck with it, rick ps: Btw, if you are going to use NFSv3, the regular client and server should work as well, although you are welcome to test NFSD and NFSCL (only needed for NFSv4). From owner-freebsd-current@FreeBSD.ORG Mon Oct 26 15:24:39 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5B8C3106568D for ; Mon, 26 Oct 2009 15:24:39 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from esa-annu.mail.uoguelph.ca (esa-annu.mail.uoguelph.ca [131.104.91.36]) by mx1.freebsd.org (Postfix) with ESMTP id 8951D8FC1E for ; Mon, 26 Oct 2009 15:24:38 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAO9b5UqDaFvJ/2dsb2JhbADYaYQ/BIFe X-IronPort-AV: E=Sophos;i="4.44,626,1249272000"; d="scan'208";a="51259732" Received: from ganges.cs.uoguelph.ca ([131.104.91.201]) by esa-annu-pri.mail.uoguelph.ca with ESMTP; 26 Oct 2009 11:24:37 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by ganges.cs.uoguelph.ca (Postfix) with ESMTP id 994B3FB808B; Mon, 26 Oct 2009 11:24:37 -0400 (EDT) X-Virus-Scanned: amavisd-new at ganges.cs.uoguelph.ca Received: from ganges.cs.uoguelph.ca ([127.0.0.1]) by localhost (ganges.cs.uoguelph.ca [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WAUj0TgZGeJa; Mon, 26 Oct 2009 11:24:36 -0400 (EDT) Received: from muncher.cs.uoguelph.ca (muncher.cs.uoguelph.ca [131.104.91.102]) by ganges.cs.uoguelph.ca (Postfix) with ESMTP id 0FB2DFB801F; Mon, 26 Oct 2009 11:24:36 -0400 (EDT) Received: from localhost (rmacklem@localhost) by muncher.cs.uoguelph.ca (8.11.7p3+Sun/8.11.6) with ESMTP id n9QFVbB05488; Mon, 26 Oct 2009 11:31:37 -0400 (EDT) X-Authentication-Warning: muncher.cs.uoguelph.ca: rmacklem owned process doing -bs Date: Mon, 26 Oct 2009 11:31:37 -0400 (EDT) From: Rick Macklem X-X-Sender: rmacklem@muncher.cs.uoguelph.ca To: "b. f." In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-current@FreeBSD.org, john.marshall@riverwillow.com.au Subject: Re: Kernel Build Knob for kgssapi_krb5? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Oct 2009 15:24:39 -0000 On Mon, 26 Oct 2009, b. f. wrote: >> Is there a knob somewhere to enable building of the kgssapi_krb5 module? >> > > I don't see any for the module -- Doug Rabson doesn't seem to have > added it to /usr/src/sys/modules/Makefile in r184588: > > http://svn.freebsd.org/viewvc/base?view=revision&revision=184588 > > And I see that it has some implicit dependencies, like INET6, so the > kinks have not been ironed out of this portion of the code. You could > try: > > cd /usr/src/sys/modules/kgssapi_krb5 && make obj && make depend && > make && make install > At this point, both the regular nfs and experimental nfs subsystems only know to use the gssapi stuff if they're built with options KGSSAPI in the kernel config. I've never tried to build it as a module, but I do know it needs: device crypto >> I have just built 8.0-RC2/i386 and decided to have a look at the >> (experimental) NFSv4 stuff. I included options NFSD and NFSCL in my >> kernel configuration. nfsd(8) indicates that gssd(8) has to be running >> in order for the server to provide gss/krb5 access control. If I try >> starting gssd(8) it complains of a missing kgssapi_krb5 kernel module. >> The module hasn't been built. I've checked the GENERIC and NOTES files >> and can't find any reference to kgssapi_krb5. Is there an undocumented >> configuration option for this? >> >> Also, is there a "getting started" or "how to test" page somewhere to >> give us some clues to get this going? > > See the commit message mentioned above. Also, the primary author, > Rick Macklem, has a tutorial: > > http://code.google.com/p/macnfsv4/wiki/FreeBSD8KerberizedNFSSetup > Just fyi, although I can't avoid blame for the NFSD/NFSCL code, I wasn't the author of the Kernel GSSAPI code, just a happy user. Hopefully you'll find the wiki page useful. Feel free to add things to it and/or email me with changes. rick From owner-freebsd-current@FreeBSD.ORG Mon Oct 26 15:35:07 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 630751065676 for ; Mon, 26 Oct 2009 15:35:07 +0000 (UTC) (envelope-from rnoland@FreeBSD.org) Received: from gizmo.2hip.net (gizmo.2hip.net [64.74.207.195]) by mx1.freebsd.org (Postfix) with ESMTP id 08F918FC30 for ; Mon, 26 Oct 2009 15:35:06 +0000 (UTC) Received: from [192.168.1.4] (adsl-150-102-19.bna.bellsouth.net [72.150.102.19]) (authenticated bits=0) by gizmo.2hip.net (8.14.3/8.14.3) with ESMTP id n9QFZ4j8069565 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Mon, 26 Oct 2009 11:35:05 -0400 (EDT) (envelope-from rnoland@FreeBSD.org) From: Robert Noland To: merijn@inconsistent.nl In-Reply-To: References: <1256517106.2502.205.camel@balrog.2hip.net> Content-Type: text/plain Organization: FreeBSD Date: Mon, 26 Oct 2009 10:34:59 -0500 Message-Id: <1256571299.2502.219.camel@balrog.2hip.net> Mime-Version: 1.0 X-Mailer: Evolution 2.26.3 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-1.9 required=5.0 tests=AWL,BAYES_00, RCVD_IN_SORBS_DUL, RDNS_DYNAMIC, SPF_SOFTFAIL autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on gizmo.2hip.net Cc: "freebsd-current@freebsd.org" Subject: Re: GPT boot with ZFS RAIDZ "ZFS: i/o error - all block copies unavailable" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Oct 2009 15:35:07 -0000 On Mon, 2009-10-26 at 10:23 +0100, Merijn Verstraaten wrote: > On Mon, 26 Oct 2009 01:31:46 +0100, Robert Noland > wrote: > >> After installing 8.0-RC1 (amd64) from USB stick this installation works > >> fine. If I csup to RELENG_8 (amd64) and compile + install world and > >> kernel > >> booting from the ZFS fails. The initial installation I did just this, on > >> another attempt I ran "gpart bootcode -b /boot/pbmr -p /boot/gptzfsboot > >> adX" on all disks before rebooting to see if that had any effect. The > >> end > >> result is the same. After rebooting the machine I get the following > >> prompt(s): > >> > >> ZFS: i/o error - all block copies unavailable > >> Invalid format > >> > >> FreeBSD/i386 boot > >> Default: tank:/boot/kernel/kernel > >> boot: > > > > Could you type "status" at this point and tell what it shows? > > If I type status at this point I get: > > pool: tank > config: > NAME STATE > tank ONLINE > raidz1 ONLINE > ad4p3 ONLINE > ad6p3 ONLINE > ad8p3 ONLINE > ad10p3 ONLINE > > Which seems odd, since that's all the drives there are. So if it finds > these it's already found all drives. My optimistic "Oh! I'll try and boot > again" spirit was however crushed since it just results in the same error. Ok, that is both good and frustrating... I haven't produced any boot failures with all of the drives visible. Do, note that I just added support for reading gang blocks to the loader. (basically untested, since I haven't managed to create them at will) You will need to update your partition boot code for it to be supported during early boot. i.e. gpart bootcode -p /boot/gptzfsboot -i The "all block copies unavailable" is a frustrating error, since all it means is a failed read, but we don't get a clue what failed or why. With the code that is in -CURRENT it will report gang blocks if found, even if it fails to read them. robert. > Kind regards, > Merijn > _______________________________________________ > 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" -- Robert Noland FreeBSD From owner-freebsd-current@FreeBSD.ORG Mon Oct 26 17:31:19 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 71D2F1065698; Mon, 26 Oct 2009 17:31:19 +0000 (UTC) (envelope-from ehrmann@gmail.com) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) by mx1.freebsd.org (Postfix) with ESMTP id 3F7EA8FC0C; Mon, 26 Oct 2009 17:31:19 +0000 (UTC) Received: from exobytes-macbook-pro.local (unknown [64.9.236.71]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id A7B2C22E258; Mon, 26 Oct 2009 13:31:17 -0400 (EDT) Message-ID: <4AE5DCE4.9060408@gmail.com> Date: Mon, 26 Oct 2009 10:31:16 -0700 From: David Ehrmann User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: Remko Lodder References: <4ADF70F1.5060300@gmail.com> <4AE0DCDF.7090604@gmail.com> <20091023183708.GA6050@michelle.cdnetworks.com> <6e0e5340910231237v3f19b27ex1cbefd3f9a01af54@mail.gmail.com> <20091023194755.GC6050@michelle.cdnetworks.com> <20091023202604.GD6050@michelle.cdnetworks.com> <6e0e5340910231531n737ac71ds11a07117c3f7667e@mail.gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: pyunyh@gmail.com, freebsd-current@freebsd.org, Ivan Voras Subject: Re: Strange issue with Samba on 8.0rc1 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Oct 2009 17:31:19 -0000 Remko Lodder wrote: > Wait.. Are you telling us you have a > > vr and an vge card in the same network? that would surely generate > problems. One of them will reply for the ARP address of the requested > IP, because they both know the address for > that. That could mean that sometimes the traffic goes to the vge, and > sometimes to the vr device. > > The thing to avoid that is by unsetting ARP questions on the > interface, and statically assigning it to your devices (arp -S/-s) so > that they will only talk with the correct interface. > > The way I read this, it will never generate a good working test... > Yes, but I only set it up to see if the problem is with vge, so it was down when I initially saw the problem. They do have different IP addresses, so while the ARP reply might come from either, I would think that it would be correct, and all incoming traffic would go to the right interface. I'm not sure about outgoing traffic. There weren't any warnings in dmesg or /var/log/messages about my configuration. From owner-freebsd-current@FreeBSD.ORG Mon Oct 26 19:51:21 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7B604106566B; Mon, 26 Oct 2009 19:51:21 +0000 (UTC) (envelope-from valin@buchlovice.org) Received: from smtp-sfn.sitkom.cz (smtp-sfn.sitkom.cz [88.146.175.4]) by mx1.freebsd.org (Postfix) with ESMTP id 0359A8FC15; Mon, 26 Oct 2009 19:51:20 +0000 (UTC) Received: from osiris.buchlovice.sfn (osiris.buchlovice.sfn [10.6.193.10]) by smtp-sfn.sitkom.cz (Postfix) with ESMTP id 08B731FA61B; Mon, 26 Oct 2009 20:51:19 +0100 (CET) Message-ID: <4AE5FDB4.20101@buchlovice.org> Date: Mon, 26 Oct 2009 20:51:16 +0100 From: =?UTF-8?B?UmFkZWsgVmFsw6HFoWVr?= User-Agent: Thunderbird 2.0.0.23 (X11/20091015) MIME-Version: 1.0 To: Robert Noland References: <1256517106.2502.205.camel@balrog.2hip.net> <1256571299.2502.219.camel@balrog.2hip.net> In-Reply-To: <1256571299.2502.219.camel@balrog.2hip.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-fs@freebsd.org, "freebsd-current@freebsd.org" , merijn@inconsistent.nl Subject: Re: GPT boot with ZFS RAIDZ "ZFS: i/o error - all block copies unavailable" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Oct 2009 19:51:21 -0000 Robert Noland napsal(a): > On Mon, 2009-10-26 at 10:23 +0100, Merijn Verstraaten wrote: > >> On Mon, 26 Oct 2009 01:31:46 +0100, Robert Noland >> wrote: >> >>>> After installing 8.0-RC1 (amd64) from USB stick this installation works >>>> fine. If I csup to RELENG_8 (amd64) and compile + install world and >>>> kernel >>>> booting from the ZFS fails. The initial installation I did just this, on >>>> another attempt I ran "gpart bootcode -b /boot/pbmr -p /boot/gptzfsboot >>>> adX" on all disks before rebooting to see if that had any effect. The >>>> end >>>> result is the same. After rebooting the machine I get the following >>>> prompt(s): >>>> >>>> ZFS: i/o error - all block copies unavailable >>>> Invalid format >>>> >>>> FreeBSD/i386 boot >>>> Default: tank:/boot/kernel/kernel >>>> boot: >>>> >>> Could you type "status" at this point and tell what it shows? >>> >> If I type status at this point I get: >> >> pool: tank >> config: >> NAME STATE >> tank ONLINE >> raidz1 ONLINE >> ad4p3 ONLINE >> ad6p3 ONLINE >> ad8p3 ONLINE >> ad10p3 ONLINE >> >> Which seems odd, since that's all the drives there are. So if it finds >> these it's already found all drives. My optimistic "Oh! I'll try and boot >> again" spirit was however crushed since it just results in the same error. >> > > Ok, that is both good and frustrating... I haven't produced any boot > failures with all of the drives visible. Do, note that I just added > support for reading gang blocks to the loader. (basically untested, > since I haven't managed to create them at will) You will need to update > your partition boot code for it to be supported during early boot. i.e. > gpart bootcode -p /boot/gptzfsboot -i > > The "all block copies unavailable" is a frustrating error, since all it > means is a failed read, but we don't get a clue what failed or why. > With the code that is in -CURRENT it will report gang blocks if found, > even if it fails to read them. > > robert. > So I switched to -CURRENT: 1, overwriting /boot/loader.conf results with: BTX loader 1.00 BTX version is 1.02 Consoles: internal video/keyboard BIOS drive C: is disk0 BIOS drive D: is disk1 BIOS drive E: is disk2 BIOS drive F: is disk3 BIOS 627kB/3405248kB available memory FreeBSD/i386 bootstrap loader, Revision 1.1 (root@ztest, Mon Oct 26 14:01:44 CEST 2009) Loading /boot/defaults/loader.conf ZFS: i/o error - all block copies unavailable Warning: error reading file /boot/loader.conf so basically the same as in RELENG_8 2, + overwriting /boot/loader results with: ZFS: i/o error - all block copies unavailable Invalid format FreeBSD/i386 boot Default: z:/boot/kernel/kernel boot: \ int=00000001 err=00000000 efl=00000087 eip=0018d27d eax=0018d2af ebx=18bf9925 ecx=540d8ef2 edx=00000000 esi=00009401 edi=000919d0 ebp=36571125 esp=80000000 cs=0008 ds=0010 es=0010 fs=0010 gs=0010 ss=0010 cs:eip=1f 68 e2 c6 7d 75 0c 5d-45 58 c7 80 f5 99 bd 9e fe 68 2d 3e 3c 35 5e 67-61 12 fe 50 c9 0b e4 70 ss:esp=00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 BTX halted 3, I also try the 'status' as you told to Merijn before BTX halted: ZFS: i/o error - all block copies unavailable Invalid format FreeBSD/i386 boot Default: z:/boot/kernel/kernel boot: status pool: z config: NAME STATE z ONLINE raidz1 ONLINE ad6p2 ONLINE ad8p2 ONLINE ad10p2 ONLINE ad12p2 ONLINE radek. > > >> Kind regards, >> Merijn >> _______________________________________________ >> 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-current@FreeBSD.ORG Tue Oct 27 02:31:34 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B97D8106566B for ; Tue, 27 Oct 2009 02:31:34 +0000 (UTC) (envelope-from john.marshall@riverwillow.com.au) Received: from mail1.riverwillow.net.au (mail1.riverwillow.net.au [203.58.93.36]) by mx1.freebsd.org (Postfix) with ESMTP id 395D58FC18 for ; Tue, 27 Oct 2009 02:31:33 +0000 (UTC) Received: from rwpc12.mby.riverwillow.net.au (rwpc12.mby.riverwillow.net.au [172.25.24.168]) (authenticated bits=0) by mail1.riverwillow.net.au (8.14.3/8.14.3) with ESMTP id n9R2VKPk058182 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 27 Oct 2009 13:31:21 +1100 (AEDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=riverwillow.com.au; s=m1001; t=1256610681; bh=Z99jKm9fCdSxMvuwna0/pMCoVqvU19zKEoGwONKduH0=; h=Date:From:To:Cc:Subject:Message-ID:References:Mime-Version: Content-Type:In-Reply-To; b=F4/JpPHFJ1l4LeDIe9plRVj3RszBSmf2h/l5XxXXgNELtHrpCXB/wF2/1QMcp6wvZ H9wrnzicXM6COZcF+CBHV9kJgS6PbV1BjY+Nw5PrmsnFyJsZiUvDJ4XYKw7UW4GSRY ZwnhUHeswZSsM4BvbT01lZZmzzP6jYSkGEOtYzs0= Received: from rwpc12.mby.riverwillow.net.au (localhost [127.0.0.1]) by rwpc12.mby.riverwillow.net.au (8.14.3/8.14.3) with ESMTP id n9R2VJY9053207; Tue, 27 Oct 2009 13:31:19 +1100 (AEDT) (envelope-from john.marshall@riverwillow.com.au) Received: (from john@localhost) by rwpc12.mby.riverwillow.net.au (8.14.3/8.14.3/Submit) id n9R2VI7t053206; Tue, 27 Oct 2009 13:31:18 +1100 (AEDT) (envelope-from john) Date: Tue, 27 Oct 2009 13:31:18 +1100 From: John Marshall To: Rick Macklem Message-ID: <20091027023118.GD1064@rwpc12.mby.riverwillow.net.au> Mail-Followup-To: Rick Macklem , "b. f." , freebsd-current@freebsd.org References: Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="nmemrqcdn5VTmUEE" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i OpenPGP: id=A29A84A2; url=http://pki.riverwillow.net.au/pgp/johnmarshall.asc Cc: freebsd-current@freebsd.org, "b. f." Subject: Re: Kernel Build Knob for kgssapi_krb5? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Oct 2009 02:31:34 -0000 --nmemrqcdn5VTmUEE Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, 26 Oct 2009, 11:31 -0400, Rick Macklem wrote: > On Mon, 26 Oct 2009, b. f. wrote: > >>Is there a knob somewhere to enable building of the kgssapi_krb5 module? > > > >I don't see any for the module -- Doug Rabson doesn't seem to have > >added it to /usr/src/sys/modules/Makefile in r184588: > > > >http://svn.freebsd.org/viewvc/base?view=3Drevision&revision=3D184588 > > > >And I see that it has some implicit dependencies, like INET6, so the > >kinks have not been ironed out of this portion of the code. You could > >try: > > > >cd /usr/src/sys/modules/kgssapi_krb5 && make obj && make depend && > >make && make install >=20 > At this point, both the regular nfs and experimental nfs subsystems > only know to use the gssapi stuff if they're built with > options KGSSAPI > in the kernel config. >=20 > I've never tried to build it as a module, but I do know it needs: > device crypto I didn't try building as a separate kernel module but configuring it in the kernel with 'options KGSSAPI' and 'device crypto' worked for me. The kernel build didn't complain that I don't have INET6 included. > >>Also, is there a "getting started" or "how to test" page somewhere to > >>give us some clues to get this going? > > > >http://code.google.com/p/macnfsv4/wiki/FreeBSD8KerberizedNFSSetup > > > Just fyi, although I can't avoid blame for the NFSD/NFSCL code, I > wasn't the author of the Kernel GSSAPI code, just a happy user. >=20 > Hopefully you'll find the wiki page useful. Feel free to add things > to it and/or email me with changes. Thank you! Might I suggest that a link to this work from the FreeBSD wiki and the 8.0 Release Notes would be a good idea? More people are going to want to know how to go about using/testing this now that it is included in a release. --=20 John Marshall --nmemrqcdn5VTmUEE Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.13 (FreeBSD) iEYEARECAAYFAkrmW3YACgkQw/tAaKKahKLWvwCdFCQVJvmRuX57N9oFB11esHaO SMYAn2iQkUzHbvWTbhOGxCE79nnGEjMq =2Mj6 -----END PGP SIGNATURE----- --nmemrqcdn5VTmUEE-- From owner-freebsd-current@FreeBSD.ORG Tue Oct 27 05:58:11 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7B1F5106566C for ; Tue, 27 Oct 2009 05:58:11 +0000 (UTC) (envelope-from bf1783@googlemail.com) Received: from mail-ew0-f218.google.com (mail-ew0-f218.google.com [209.85.219.218]) by mx1.freebsd.org (Postfix) with ESMTP id 11D5D8FC0A for ; Tue, 27 Oct 2009 05:58:10 +0000 (UTC) Received: by ewy18 with SMTP id 18so11180347ewy.43 for ; Mon, 26 Oct 2009 22:58:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type; bh=HLZ1MK/xVKtxAmaJiCnUZKqVg0E60MxvRZrhcBT3nm8=; b=X5jHL5OrZnOciRdF1iVfylGg+qkCV5Q40ilo1cty/0WFNIJLw2GnV0Wcn1OsCYRdc0 q8WtTl+RBA+xfq9WEZggBRj2tQ1WU7BaHVhL4/qQ3ulGNBPMl+roNQq3p+pw3lHVkg26 sjntaRSEIjZJW0yhI+G5EgdlFt8S50If5yrCI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=FYNNlqqMZH2c8bYIHsfTjJ+oQaOWPT2cUAKXUPud/uI0xGrhUpRTcE1aJ+47hMrWP/ d5Zor2C+V09gdt3Q0GdglBGmrzIhs6+IFL6dmBTluRFL90l+izoOq6aYr4a9/09974gz sT4nbLvt3KxWnd+lVzmuRbKYQRb5KVzCrWY6Y= MIME-Version: 1.0 Received: by 10.216.90.196 with SMTP id e46mr635815wef.194.1256623089960; Mon, 26 Oct 2009 22:58:09 -0700 (PDT) In-Reply-To: <20091027023118.GD1064@rwpc12.mby.riverwillow.net.au> References: <20091027023118.GD1064@rwpc12.mby.riverwillow.net.au> Date: Tue, 27 Oct 2009 05:58:09 +0000 Message-ID: From: "b. f." To: freebsd-current@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Subject: Re: Kernel Build Knob for kgssapi_krb5? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Oct 2009 05:58:11 -0000 On 10/27/09, John Marshall wrote: > On Mon, 26 Oct 2009, 11:31 -0400, Rick Macklem wrote: >> On Mon, 26 Oct 2009, b. f. wrote: >> >And I see that it has some implicit dependencies, like INET6, so the >> >kinks have not been ironed out of this portion of the code. You could >> >try: ... > > I didn't try building as a separate kernel module but configuring it in > the kernel with 'options KGSSAPI' and 'device crypto' worked for me. > The kernel build didn't complain that I don't have INET6 included. > I should have been more careful in what I wrote: all I meant was that the inclusion of opt_inet6.h in src/sys/kgssapi/krb5/krb5_mech.c can break the build of the kgssapi_krb5 module, and if this header is really needed, then the module Makefile should probably be changed to handle this header in the same way as is now done in other modules, something along the lines of: SRCS+= opt_inet6.h .if !defined(KERNBUILDDIR) .if ${MK_INET6_SUPPORT} != "no" opt_inet6.h: echo "#define INET6 1" > ${.TARGET} .endif .endif This may not be the only problem with the module, as Rick Macklem suggested. >> Just fyi, although I can't avoid blame for the NFSD/NFSCL code, I >> wasn't the author of the Kernel GSSAPI code, just a happy user. I meant, and should have written, "primary author of the NFSv4 code". Obviously, from the commit message I cited, Doug Rabson and Isilon were responsible for most of the kernel GSSAPI code. > > Thank you! Might I suggest that a link to this work from the FreeBSD > wiki and the 8.0 Release Notes would be a good idea? More people are > going to want to know how to go about using/testing this now that it is > included in a release. > Seconded: a reference in the FreeBSD wiki would be helpful. b. From owner-freebsd-current@FreeBSD.ORG Tue Oct 27 10:15:24 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F1C231065692; Tue, 27 Oct 2009 10:15:23 +0000 (UTC) (envelope-from valin@buchlovice.org) Received: from smtp-sfn.sitkom.cz (smtp-sfn.sitkom.cz [88.146.175.4]) by mx1.freebsd.org (Postfix) with ESMTP id 7C25B8FC15; Tue, 27 Oct 2009 10:15:23 +0000 (UTC) Received: from osiris.buchlovice.sfn (valin-osiris-lan.brestek.sfn [10.8.20.3]) by smtp-sfn.sitkom.cz (Postfix) with ESMTP id 13E991FA638; Tue, 27 Oct 2009 11:15:22 +0100 (CET) Message-ID: <4AE6C836.2070708@buchlovice.org> Date: Tue, 27 Oct 2009 11:15:18 +0100 From: =?UTF-8?B?UmFkZWsgVmFsw6HFoWVr?= User-Agent: Thunderbird 2.0.0.23 (X11/20091015) MIME-Version: 1.0 To: Robert Noland References: <1256517106.2502.205.camel@balrog.2hip.net> <1256571299.2502.219.camel@balrog.2hip.net> In-Reply-To: <1256571299.2502.219.camel@balrog.2hip.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-fs@freebsd.org, "freebsd-current@freebsd.org" , merijn@inconsistent.nl Subject: Re: GPT boot with ZFS RAIDZ "ZFS: i/o error - all block copies unavailable" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Oct 2009 10:15:24 -0000 Robert Noland napsal(a): > On Mon, 2009-10-26 at 10:23 +0100, Merijn Verstraaten wrote: > >> On Mon, 26 Oct 2009 01:31:46 +0100, Robert Noland >> wrote: >> >>>> After installing 8.0-RC1 (amd64) from USB stick this installation works >>>> fine. If I csup to RELENG_8 (amd64) and compile + install world and >>>> kernel >>>> booting from the ZFS fails. The initial installation I did just this, on >>>> another attempt I ran "gpart bootcode -b /boot/pbmr -p /boot/gptzfsboot >>>> adX" on all disks before rebooting to see if that had any effect. The >>>> end >>>> result is the same. After rebooting the machine I get the following >>>> prompt(s): >>>> >>>> ZFS: i/o error - all block copies unavailable >>>> Invalid format >>>> >>>> FreeBSD/i386 boot >>>> Default: tank:/boot/kernel/kernel >>>> boot: >>>> >>> Could you type "status" at this point and tell what it shows? >>> >> If I type status at this point I get: >> >> pool: tank >> config: >> NAME STATE >> tank ONLINE >> raidz1 ONLINE >> ad4p3 ONLINE >> ad6p3 ONLINE >> ad8p3 ONLINE >> ad10p3 ONLINE >> >> Which seems odd, since that's all the drives there are. So if it finds >> these it's already found all drives. My optimistic "Oh! I'll try and boot >> again" spirit was however crushed since it just results in the same error. >> > > Ok, that is both good and frustrating... I haven't produced any boot > failures with all of the drives visible. Do, note that I just added > support for reading gang blocks to the loader. (basically untested, > since I haven't managed to create them at will) You will need to update > your partition boot code for it to be supported during early boot. i.e. > gpart bootcode -p /boot/gptzfsboot -i > > The "all block copies unavailable" is a frustrating error, since all it > means is a failed read, but we don't get a clue what failed or why. > With the code that is in -CURRENT it will report gang blocks if found, > even if it fails to read them. > > robert. > So I switched to -CURRENT: 1, overwriting /boot/loader.conf results with: BTX loader 1.00 BTX version is 1.02 Consoles: internal video/keyboard BIOS drive C: is disk0 BIOS drive D: is disk1 BIOS drive E: is disk2 BIOS drive F: is disk3 BIOS 627kB/3405248kB available memory FreeBSD/i386 bootstrap loader, Revision 1.1 (root@ztest, Mon Oct 26 14:01:44 CEST 2009) Loading /boot/defaults/loader.conf ZFS: i/o error - all block copies unavailable Warning: error reading file /boot/loader.conf so basically the same as in RELENG_8 2, + overwriting /boot/loader results with: ZFS: i/o error - all block copies unavailable Invalid format FreeBSD/i386 boot Default: z:/boot/kernel/kernel boot: \ int=00000001 err=00000000 efl=00000087 eip=0018d27d eax=0018d2af ebx=18bf9925 ecx=540d8ef2 edx=00000000 esi=00009401 edi=000919d0 ebp=36571125 esp=80000000 cs=0008 ds=0010 es=0010 fs=0010 gs=0010 ss=0010 cs:eip=1f 68 e2 c6 7d 75 0c 5d-45 58 c7 80 f5 99 bd 9e fe 68 2d 3e 3c 35 5e 67-61 12 fe 50 c9 0b e4 70 ss:esp=00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 BTX halted 3, I also try the 'status' as you told to Merijn before BTX halted: ZFS: i/o error - all block copies unavailable Invalid format FreeBSD/i386 boot Default: z:/boot/kernel/kernel boot: status pool: z config: NAME STATE z ONLINE raidz1 ONLINE ad6p2 ONLINE ad8p2 ONLINE ad10p2 ONLINE ad12p2 ONLINE radek. > > >> Kind regards, >> Merijn >> _______________________________________________ >> 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-current@FreeBSD.ORG Tue Oct 27 10:17:42 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7FA5C106568B for ; Tue, 27 Oct 2009 10:17:42 +0000 (UTC) (envelope-from merijn@inconsistent.nl) Received: from smtp-vbr4.xs4all.nl (smtp-vbr4.xs4all.nl [194.109.24.24]) by mx1.freebsd.org (Postfix) with ESMTP id 143138FC25 for ; Tue, 27 Oct 2009 10:17:41 +0000 (UTC) Received: from localhost (inconsistent.nl [83.163.46.169]) (authenticated bits=0) by smtp-vbr4.xs4all.nl (8.13.8/8.13.8) with ESMTP id n9RAHeUT035277 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for ; Tue, 27 Oct 2009 11:17:40 +0100 (CET) (envelope-from merijn@inconsistent.nl) Content-Type: text/plain; charset=utf-8; format=flowed; delsp=yes In-Reply-To: <1256571299.2502.219.camel@balrog.2hip.net> Organization: Inconsistent References: <1256517106.2502.205.camel@balrog.2hip.net> <1256571299.2502.219.camel@balrog.2hip.net> To: "freebsd-current@freebsd.org" Date: Tue, 27 Oct 2009 11:17:40 +0100 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit From: "Merijn Verstraaten" Message-ID: User-Agent: Opera Mail/10.00 (MacIntel) X-Virus-Scanned: by XS4ALL Virus Scanner Subject: Re: GPT boot with ZFS RAIDZ "ZFS: i/o error - all block copies unavailable" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: merijn@inconsistent.nl List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Oct 2009 10:17:42 -0000 My apologies to Robert for the double message, mis-addressed the first reply to him instead of the list. On Mon, 26 Oct 2009 16:34:59 +0100, Robert Noland wrote: >> If I type status at this point I get: >> >> pool: tank >> config: >> NAME STATE >> tank ONLINE >> raidz1 ONLINE >> ad4p3 ONLINE >> ad6p3 ONLINE >> ad8p3 ONLINE >> ad10p3 ONLINE >> >> Which seems odd, since that's all the drives there are. So if it finds >> these it's already found all drives. My optimistic "Oh! I'll try and >> boot >> again" spirit was however crushed since it just results in the same >> error. > > Ok, that is both good and frustrating... I haven't produced any boot > failures with all of the drives visible. Do, note that I just added > support for reading gang blocks to the loader. (basically untested, > since I haven't managed to create them at will) You will need to update > your partition boot code for it to be supported during early boot. i.e. > gpart bootcode -p /boot/gptzfsboot -i I tried again yesterday evening by recompiling RELENG_8 and -CURRENT. I somehow managed to boot into RELENG_8 the first time, but after that this error comes up: ZFS: i/o error - all block copies unavailable ZFS: can't read object set for dataset ldd Can't find root filesystem - giving up ZFS: unexpected object set type ldd ZFS: unexpected object set type ldd FreeBSD/i386 boot Default:/ tank:/boot/kernel/kernel boot: ZFS: unexpected object set type ldd FreeBSD/i386 boot Default:/ tank:/boot/kernel/kernel boot: status pool: tank config: NAME STATE tank ONLINE raidz1 ONLINE ad4p3 ONLINE ad6p3 ONLINE ad8p3 ONLINE ad10p3 ONLINE After recompiling world/kernel for -CURRENT I get roughly the same error: ZFS: i/o error - all block copies unavailable ZFS: can't read object set for dataset 30 Can't find root filesystem - giving up ZFS: unexpected object set type 0 ZFS: unexpected object set type 0 FreeBSD/i386 boot Default:/ tank:/boot/kernel/kernel boot: ZFS: unexpected object set type ldd FreeBSD/i386 boot Default:/ tank:/boot/kernel/kernel boot: status pool: tank config: NAME STATE tank ONLINE raidz1 ONLINE ad4p3 ONLINE ad6p3 ONLINE ad8p3 ONLINE ad10p3 ONLINE > The "all block copies unavailable" is a frustrating error, since all it > means is a failed read, but we don't get a clue what failed or why. > With the code that is in -CURRENT it will report gang blocks if found, > even if it fails to read them. > robert. I've seen no mention of gang blocks in the errors so far. Kind regards, Merijn From owner-freebsd-current@FreeBSD.ORG Tue Oct 27 14:49:46 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4B73D106566B for ; Tue, 27 Oct 2009 14:49:46 +0000 (UTC) (envelope-from rnoland@FreeBSD.org) Received: from gizmo.2hip.net (gizmo.2hip.net [64.74.207.195]) by mx1.freebsd.org (Postfix) with ESMTP id 112098FC15 for ; Tue, 27 Oct 2009 14:49:45 +0000 (UTC) Received: from [192.168.1.4] (adsl-150-102-19.bna.bellsouth.net [72.150.102.19]) (authenticated bits=0) by gizmo.2hip.net (8.14.3/8.14.3) with ESMTP id n9REngGv003096 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Tue, 27 Oct 2009 10:49:43 -0400 (EDT) (envelope-from rnoland@FreeBSD.org) From: Robert Noland To: merijn@inconsistent.nl In-Reply-To: References: <1256517106.2502.205.camel@balrog.2hip.net> <1256571299.2502.219.camel@balrog.2hip.net> Content-Type: text/plain Organization: FreeBSD Date: Tue, 27 Oct 2009 09:49:36 -0500 Message-Id: <1256654976.2497.29.camel@balrog.2hip.net> Mime-Version: 1.0 X-Mailer: Evolution 2.26.3 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-1.7 required=5.0 tests=AWL,BAYES_00, RCVD_IN_SORBS_DUL, RDNS_DYNAMIC, SPF_SOFTFAIL autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on gizmo.2hip.net Cc: "freebsd-current@freebsd.org" Subject: Re: GPT boot with ZFS RAIDZ "ZFS: i/o error - all block copies unavailable" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Oct 2009 14:49:46 -0000 On Tue, 2009-10-27 at 11:17 +0100, Merijn Verstraaten wrote: > My apologies to Robert for the double message, mis-addressed the first > reply to him instead of the list. > > On Mon, 26 Oct 2009 16:34:59 +0100, Robert Noland > wrote: > >> If I type status at this point I get: > >> > >> pool: tank > >> config: > >> NAME STATE > >> tank ONLINE > >> raidz1 ONLINE > >> ad4p3 ONLINE > >> ad6p3 ONLINE > >> ad8p3 ONLINE > >> ad10p3 ONLINE > >> > >> Which seems odd, since that's all the drives there are. So if it finds > >> these it's already found all drives. My optimistic "Oh! I'll try and > >> boot > >> again" spirit was however crushed since it just results in the same > >> error. > > > > Ok, that is both good and frustrating... I haven't produced any boot > > failures with all of the drives visible. Do, note that I just added > > support for reading gang blocks to the loader. (basically untested, > > since I haven't managed to create them at will) You will need to update > > your partition boot code for it to be supported during early boot. i.e. > > gpart bootcode -p /boot/gptzfsboot -i > > I tried again yesterday evening by recompiling RELENG_8 and -CURRENT. I > somehow managed to boot into RELENG_8 the first time, but after that this > error comes up: > > ZFS: i/o error - all block copies unavailable > ZFS: can't read object set for dataset ldd > Can't find root filesystem - giving up > ZFS: unexpected object set type ldd > ZFS: unexpected object set type ldd > > FreeBSD/i386 boot > Default:/ tank:/boot/kernel/kernel > boot: > ZFS: unexpected object set type ldd > > FreeBSD/i386 boot > Default:/ tank:/boot/kernel/kernel > boot: status > > pool: tank > config: > NAME STATE > tank ONLINE > raidz1 ONLINE > ad4p3 ONLINE > ad6p3 ONLINE > ad8p3 ONLINE > ad10p3 ONLINE > > After recompiling world/kernel for -CURRENT I get roughly the same error: > > ZFS: i/o error - all block copies unavailable > ZFS: can't read object set for dataset 30 > Can't find root filesystem - giving up > ZFS: unexpected object set type 0 > ZFS: unexpected object set type 0 > > FreeBSD/i386 boot > Default:/ tank:/boot/kernel/kernel ^^ This looks strange... Do you have bootfs set to /, or something in loader.conf? Does it work if you just type "tank:/boot/kernel/kernel" at this point? robert. > boot: > ZFS: unexpected object set type ldd > > FreeBSD/i386 boot > Default:/ tank:/boot/kernel/kernel > boot: status > > pool: tank > config: > NAME STATE > tank ONLINE > raidz1 ONLINE > ad4p3 ONLINE > ad6p3 ONLINE > ad8p3 ONLINE > ad10p3 ONLINE > > > The "all block copies unavailable" is a frustrating error, since all it > > means is a failed read, but we don't get a clue what failed or why. > > With the code that is in -CURRENT it will report gang blocks if found, > > even if it fails to read them. > > robert. > > I've seen no mention of gang blocks in the errors so far. > > Kind regards, > Merijn > _______________________________________________ > 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" -- Robert Noland FreeBSD From owner-freebsd-current@FreeBSD.ORG Tue Oct 27 14:54:10 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 29AD71065692 for ; Tue, 27 Oct 2009 14:54:10 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from esa-annu.mail.uoguelph.ca (esa-annu.mail.uoguelph.ca [131.104.91.36]) by mx1.freebsd.org (Postfix) with ESMTP id D26328FC1B for ; Tue, 27 Oct 2009 14:54:09 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAHam5kqDaFvK/2dsb2JhbADaCIQ/BA X-IronPort-AV: E=Sophos;i="4.44,633,1249272000"; d="scan'208";a="51395832" Received: from fraser.cs.uoguelph.ca ([131.104.91.202]) by esa-annu-pri.mail.uoguelph.ca with ESMTP; 27 Oct 2009 10:54:08 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by fraser.cs.uoguelph.ca (Postfix) with ESMTP id 2B17E109C263; Tue, 27 Oct 2009 10:54:08 -0400 (EDT) X-Virus-Scanned: amavisd-new at fraser.cs.uoguelph.ca Received: from fraser.cs.uoguelph.ca ([127.0.0.1]) by localhost (fraser.cs.uoguelph.ca [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ASVfMNxab7S4; Tue, 27 Oct 2009 10:54:07 -0400 (EDT) Received: from muncher.cs.uoguelph.ca (muncher.cs.uoguelph.ca [131.104.91.102]) by fraser.cs.uoguelph.ca (Postfix) with ESMTP id 8D310109C25D; Tue, 27 Oct 2009 10:54:07 -0400 (EDT) Received: from localhost (rmacklem@localhost) by muncher.cs.uoguelph.ca (8.11.7p3+Sun/8.11.6) with ESMTP id n9RF1C404999; Tue, 27 Oct 2009 11:01:12 -0400 (EDT) X-Authentication-Warning: muncher.cs.uoguelph.ca: rmacklem owned process doing -bs Date: Tue, 27 Oct 2009 11:01:12 -0400 (EDT) From: Rick Macklem X-X-Sender: rmacklem@muncher.cs.uoguelph.ca To: John Marshall In-Reply-To: <20091027023118.GD1064@rwpc12.mby.riverwillow.net.au> Message-ID: References: <20091027023118.GD1064@rwpc12.mby.riverwillow.net.au> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-current@freebsd.org, "b. f." Subject: Re: Kernel Build Knob for kgssapi_krb5? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Oct 2009 14:54:10 -0000 On Tue, 27 Oct 2009, John Marshall wrote: > >>>> Also, is there a "getting started" or "how to test" page somewhere to >>>> give us some clues to get this going? >>> >>> http://code.google.com/p/macnfsv4/wiki/FreeBSD8KerberizedNFSSetup >>> >> Just fyi, although I can't avoid blame for the NFSD/NFSCL code, I >> wasn't the author of the Kernel GSSAPI code, just a happy user. >> >> Hopefully you'll find the wiki page useful. Feel free to add things >> to it and/or email me with changes. > > Thank you! Might I suggest that a link to this work from the FreeBSD > wiki and the 8.0 Release Notes would be a good idea? More people are > going to want to know how to go about using/testing this now that it is > included in a release. > Well, my understanding is that the freebsd wiki is for development only. As for referencing it in Release Notes, I have no problem with that, but I don't know how it's done? (I was hoping that the page would "mature" as people start to use it and that "your favourite search engine would find it". It's under "google" only because that's where I have free source hosting, so it was a convenient place. ie. I'm not trying to suggest that google should or shouldn't be your favourite search engine:-) rick From owner-freebsd-current@FreeBSD.ORG Tue Oct 27 15:03:01 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6064E1065679; Tue, 27 Oct 2009 15:03:01 +0000 (UTC) (envelope-from merijn@inconsistent.nl) Received: from smtp-vbr14.xs4all.nl (smtp-vbr14.xs4all.nl [194.109.24.34]) by mx1.freebsd.org (Postfix) with ESMTP id 0D17B8FC1F; Tue, 27 Oct 2009 15:03:00 +0000 (UTC) Received: from localhost (inconsistent.nl [83.163.46.169]) (authenticated bits=0) by smtp-vbr14.xs4all.nl (8.13.8/8.13.8) with ESMTP id n9RF2wGs024499 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Tue, 27 Oct 2009 16:02:59 +0100 (CET) (envelope-from merijn@inconsistent.nl) Content-Type: text/plain; charset=utf-8; format=flowed; delsp=yes To: "Robert Noland" References: <1256517106.2502.205.camel@balrog.2hip.net> <1256571299.2502.219.camel@balrog.2hip.net> <1256654976.2497.29.camel@balrog.2hip.net> Date: Tue, 27 Oct 2009 16:02:58 +0100 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit From: "Merijn Verstraaten" Organization: Inconsistent Message-ID: In-Reply-To: <1256654976.2497.29.camel@balrog.2hip.net> User-Agent: Opera Mail/10.00 (MacIntel) X-Virus-Scanned: by XS4ALL Virus Scanner Cc: "freebsd-current@freebsd.org" Subject: Re: GPT boot with ZFS RAIDZ "ZFS: i/o error - all block copies unavailable" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: merijn@inconsistent.nl List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Oct 2009 15:03:01 -0000 On Tue, 27 Oct 2009 15:49:36 +0100, Robert Noland wrote: >> I tried again yesterday evening by recompiling RELENG_8 and -CURRENT. I >> somehow managed to boot into RELENG_8 the first time, but after that >> this >> error comes up: >> >> ZFS: i/o error - all block copies unavailable >> ZFS: can't read object set for dataset ldd >> Can't find root filesystem - giving up >> ZFS: unexpected object set type ldd >> ZFS: unexpected object set type ldd >> >> FreeBSD/i386 boot >> Default:/ tank:/boot/kernel/kernel >> boot: >> ZFS: unexpected object set type ldd >> >> FreeBSD/i386 boot >> Default:/ tank:/boot/kernel/kernel >> boot: status >> >> pool: tank >> config: >> NAME STATE >> tank ONLINE >> raidz1 ONLINE >> ad4p3 ONLINE >> ad6p3 ONLINE >> ad8p3 ONLINE >> ad10p3 ONLINE >> >> After recompiling world/kernel for -CURRENT I get roughly the same >> error: >> >> ZFS: i/o error - all block copies unavailable >> ZFS: can't read object set for dataset 30 >> Can't find root filesystem - giving up >> ZFS: unexpected object set type 0 >> ZFS: unexpected object set type 0 >> >> FreeBSD/i386 boot >> Default:/ tank:/boot/kernel/kernel > ^^ > This looks strange... Do you have bootfs set to /, or something in > loader.conf? Does it work if you just type "tank:/boot/kernel/kernel" > at this point? > > robert. I think this might be user error. I just checked and the leading / is absent on my screen: ZFS: i/o error - all block copies unavailable ZFS: can't read object set for dataset 30 Can't find root filesystem - giving up ZFS: unexpected object set type 0 ZFS: unexpected object set type 0 FreeBSD/i386 boot Default: tank:/boot/kernel/kernel boot: I probably just typo'ed it this morning. As clarification I have vfs.root.mountfrom="zfs:tank/root" in loader.conf with my root filesystem installed on tank/root and then tank/usr, tank/var etc mounted on tank/root. If you need more detail my current setup procedure is: "gpart create -s GPT " "gpart add -b 34 -s 128 -t freebsd-boot " "gpart add -b 162 -s 1G -t freebsd-swap " "gpart add -t freebsd-zfs " "zpool create tank raidz " "zfs set checksum=fletcher4 tank" "zfs create -o reserv=512m tank/root" "zfs create -o mountpoint=/tank/root/usr tank/usr" "zfs create -o mountpoint=/tank/root/tmp tank/tmp" "zfs create -o mountpoint=/tank/root/var tank/var" "zfs create -o mountpoint=/tank/root/home tank/home" "zfs create tank/usr/obj" "zfs create tank/usr/src" "zfs create tank/usr/ports" export DESTDIR=/tank/root Run the ./install.sh scripts in the various directories of the dist "mkdir /boot/zfs" "zpool export tank && zpool import tank" "cp /boot/zfs/zpool.cache /tank/root/boot/zfs/" Set 'LOADER_ZFS_SUPPORT=yes' in /tank/root/etc/src.conf "chroot /tank/root" "mount -t devfs devfs /dev" "unset DESTDIR" "cd /usr/src/sys/boot/" "make obj" "make depend" "make" "cd i386/loader" "make install" "umount /dev" "exit" "export LD_LIBRARY_PATH=/dist/lib" "gpart bootcode -b /tank/root/boot/pmbr -p /tank/root/boot/gptzfsboot -i 1 " /boot/loader.conf: zfs_load="YES" vfs.root.mountfrom="zfs:tank/root" /etc/rc.conf: zfs_enable="YES" "zfs umount -a" "zfs set mountpoint=legacy tank" "zfs set mountpoint=/tmp tank/tmp" "zfs set mountpoint=/var tank/var" "zfs set mountpoint=/usr tank/usr" "zfs set mountpoint=/home tank/home" "zpool set bootfs=tank/root tank" Then reboot, csup sources to whatever version to test and build world/kernel, install and watch things breaks. Kind regards, Merijn From owner-freebsd-current@FreeBSD.ORG Tue Oct 27 15:39:02 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CB285106566B for ; Tue, 27 Oct 2009 15:39:02 +0000 (UTC) (envelope-from weldon@excelsusphoto.com) Received: from mx0.excelsus.net (emmett.excelsus.com [74.93.113.252]) by mx1.freebsd.org (Postfix) with ESMTP id 65D9D8FC13 for ; Tue, 27 Oct 2009 15:39:01 +0000 (UTC) Received: (qmail 9957 invoked by uid 89); 27 Oct 2009 15:12:19 -0000 Received: from unknown (HELO localhost) (127.0.0.1) by localhost.excelsus.com with SMTP; 27 Oct 2009 15:12:19 -0000 Date: Tue, 27 Oct 2009 11:12:19 -0400 (EDT) From: Weldon S Godfrey 3 X-X-Sender: weldon@emmett.excelsus.com To: freebsd-current@freebsd.org Message-ID: User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII X-Mailman-Approved-At: Tue, 27 Oct 2009 15:50:29 +0000 Subject: dell 2950/ FreeBSD 8.0-RC2 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Oct 2009 15:39:02 -0000 Has anyone else seen this? I am trying to upgrade from FreeBSD 7.0 to 8.0-RC2. AFter install and during the boot, it locks up after: Pci1. Pci bus on pcib7 The info LCD on the server says E1410 cpu1 ierr. E1410. Cpu2. Ierr I believe it did this with RC1 as well but I gave up since RC2 was getting ready to come out. (I put back in the drives with 7.0 and let it run with that) HW info: It is a Dell PowerEdge 2950-iii with 2x4 core processors and 8GB RAM. It has a Perc SATA/SAS RAID controller. From owner-freebsd-current@FreeBSD.ORG Tue Oct 27 15:41:21 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 43B2B106566C for ; Tue, 27 Oct 2009 15:41:21 +0000 (UTC) (envelope-from weldon@excelsusphoto.com) Received: from mx0.excelsus.net (emmett.excelsus.com [74.93.113.252]) by mx1.freebsd.org (Postfix) with ESMTP id D1B438FC23 for ; Tue, 27 Oct 2009 15:41:20 +0000 (UTC) Received: (qmail 10001 invoked by uid 89); 27 Oct 2009 15:13:18 -0000 Received: from unknown (HELO localhost) (127.0.0.1) by localhost.excelsus.com with SMTP; 27 Oct 2009 15:13:18 -0000 Date: Tue, 27 Oct 2009 11:13:18 -0400 (EDT) From: Weldon S Godfrey 3 X-X-Sender: weldon@emmett.excelsus.com To: freebsd-current@freebsd.org In-Reply-To: Message-ID: References: User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Mailman-Approved-At: Tue, 27 Oct 2009 15:50:49 +0000 Subject: Re: dell 2950/ FreeBSD 8.0-RC2 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Oct 2009 15:41:21 -0000 i am sorry, i am also using amd64 If memory serves me right, sometime around 11:12am, Weldon S Godfrey 3 told me: > > Has anyone else seen this? > > I am trying to upgrade from FreeBSD 7.0 to 8.0-RC2. AFter install and during > the boot, it locks up after: Pci1. Pci bus on pcib7 > > The info LCD on the server says > E1410 cpu1 ierr. E1410. Cpu2. Ierr > > I believe it did this with RC1 as well but I gave up since RC2 was getting > ready to come out. (I put back in the drives with 7.0 and let it run with > that) > > HW info: > It is a Dell PowerEdge 2950-iii with 2x4 core processors and 8GB RAM. It has > a Perc SATA/SAS RAID controller. > From owner-freebsd-current@FreeBSD.ORG Tue Oct 27 16:19:07 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6038310656AB for ; Tue, 27 Oct 2009 16:19:07 +0000 (UTC) (envelope-from roberto@keltia.freenix.fr) Received: from keltia.freenix.fr (keltia.freenix.org [IPv6:2001:660:330f:f820:213:72ff:fe15:f44]) by mx1.freebsd.org (Postfix) with ESMTP id E4C8A8FC1D for ; Tue, 27 Oct 2009 16:19:06 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by keltia.freenix.fr (Postfix/TLS) with ESMTP id 795803B9C8 for ; Tue, 27 Oct 2009 17:19:05 +0100 (CET) X-Virus-Scanned: amavisd-new at keltia.freenix.fr Received: from keltia.freenix.fr ([127.0.0.1]) by localhost (keltia.freenix.fr [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8-yvExGy8dCK for ; Tue, 27 Oct 2009 17:19:05 +0100 (CET) Received: from roberto-al.eurocontrol.fr (aran.keltia.net [88.191.250.24]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: roberto) by keltia.freenix.fr (Postfix/TLS) with ESMTPSA id 00DFB3B9BC for ; Tue, 27 Oct 2009 17:19:04 +0100 (CET) Date: Tue, 27 Oct 2009 17:18:28 +0100 From: Ollivier Robert To: freebsd-current@freebsd.org Message-ID: <20091027161828.GA3939@roberto-al.eurocontrol.fr> References: <4ADE995A.8080009@ish.com.au> <1256174188.2309.22.camel@balrog.2hip.net> <4ADFCFF3.1030201@ish.com.au> <790a9fff0910220001m3d7df03j127b51d7d0696271@mail.gmail.com> <4AE01342.4000303@ish.com.au> <790a9fff0910221049n130c5b00x66071a5a718eb6ab@mail.gmail.com> <8AC915BF-E826-4D90-8DD3-00E7FF7F4295@exscape.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <8AC915BF-E826-4D90-8DD3-00E7FF7F4295@exscape.org> X-Operating-System: MacOS X / Macbook Pro - FreeBSD 7.2 / Dell D820 SMP User-Agent: Mutt/1.5.20 (2009-06-14) Subject: Re: gpart, bsdlabel and fdisk X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Oct 2009 16:19:07 -0000 According to Thomas Backman: > Actually, there's a typo in the guide. When you specify 1G, that > means 1 GiB, not "1 gigasectors". > "gpart add -b 162 -s 1G -t freebsd-swap da0..da1 512 MB swap" > ^ should read 1G(i)B swap. "1G" = 1 GiB = 1024*1024*1024 bytes. Yes, it is a typo in the comment part. I think I did correct it though a few days ago. Please do not hesitate to contact me if you find any typo or error. -- Ollivier ROBERT -=- FreeBSD: The Power to Serve! -=- roberto@keltia.freenix.fr In memoriam to Ondine : http://ondine.keltia.net/ From owner-freebsd-current@FreeBSD.ORG Tue Oct 27 16:28:18 2009 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8EA39106566C for ; Tue, 27 Oct 2009 16:28:18 +0000 (UTC) (envelope-from scf@FreeBSD.org) Received: from mail.farley.org (mail.farley.org [IPv6:2001:470:1f0f:20:2::11]) by mx1.freebsd.org (Postfix) with ESMTP id 582108FC08 for ; Tue, 27 Oct 2009 16:28:18 +0000 (UTC) Received: from thor.farley.org (HPooka@thor.farley.org [IPv6:2001:470:1f0f:20:1::5]) by mail.farley.org (8.14.3/8.14.3) with ESMTP id n9RGSHbE070218 for ; Tue, 27 Oct 2009 11:28:17 -0500 (CDT) (envelope-from scf@FreeBSD.org) Date: Tue, 27 Oct 2009 11:28:17 -0500 (CDT) From: "Sean C. Farley" To: freebsd-current@FreeBSD.org In-Reply-To: <4AE0BA63.2000804@haruhiism.net> Message-ID: References: <4AE0BA63.2000804@haruhiism.net> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Status: No, score=-3.0 required=4.0 tests=AWL,BAYES_00,NO_RELAYS autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on mail.farley.org Cc: Subject: Re: Trouble booting system with root within gvinum volume X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Oct 2009 16:28:18 -0000 On Fri, 23 Oct 2009, Kamigishi Rei wrote: > On 22.10.2009 18:41, Sean C. Farley wrote: >> now the answer to the question about striped swap being able to save >> a core dump from a panic? Are there any other issues with using a >> stripe (gvinum, gstripe or zfs) for swap? > > Impossible; you can't cleanly save core dumps to zfs and GEOM_STRIPE > swap devices because zfs and GEOM layers are already dead during > doadump(). That makes sense. Thank you. I will make a swap outside of any GEOM device. Sean -- scf@FreeBSD.org From owner-freebsd-current@FreeBSD.ORG Tue Oct 27 18:38:28 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7C3B5106566B for ; Tue, 27 Oct 2009 18:38:28 +0000 (UTC) (envelope-from cedric.tabary@gmail.com) Received: from mail-yx0-f171.google.com (mail-yx0-f171.google.com [209.85.210.171]) by mx1.freebsd.org (Postfix) with ESMTP id 301D18FC0C for ; Tue, 27 Oct 2009 18:38:27 +0000 (UTC) Received: by yxe1 with SMTP id 1so14336yxe.3 for ; Tue, 27 Oct 2009 11:38:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to :content-type:content-transfer-encoding; bh=dSexM/LF8p/PFZAibaS1B54vcGTxkesOgt54f1XL4Rs=; b=U6mMsGlvU/AdYToGr8nzVw7AqS8qQg3RzYFys/BhDzevSqpIz0aRQ7SFt8ZGI/rPXJ dQNPv6TQYYcLfR3ZwFjCDwaNTFsTnrv0YsD5bJTJYTHv+qZo/uKSTaayvn0as8QfSYcA zqqgVcOvuSGuOH87U4RIozPNRSRT7gKLgefJw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type :content-transfer-encoding; b=cfgCgvLjWmwVwjw07FuTqY+7HNULgMOn2zfGUXK+K6Q+MlPNfqDYG/HbCbDWBVPNeA Mjl38YfNN70PXo/TkikBKK7SxW1pkcqwLeEkwUpBfoN9TWm1fP6yQN2KYegti9RfnVQ8 n6oGE3XHUnRHC6j66bOtdX7qXU159ltpgPJf4= MIME-Version: 1.0 Sender: cedric.tabary@gmail.com Received: by 10.90.58.2 with SMTP id g2mr20467007aga.73.1256667273566; Tue, 27 Oct 2009 11:14:33 -0700 (PDT) In-Reply-To: References: Date: Tue, 27 Oct 2009 19:14:33 +0100 X-Google-Sender-Auth: 5039189f72be64f7 Message-ID: <52c7f0c80910271114w27929312mc06aead560aa73bc@mail.gmail.com> From: =?ISO-8859-1?Q?C=E9dric_Tabary?= To: freebsd-current@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: dell 2950/ FreeBSD 8.0-RC2 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Oct 2009 18:38:28 -0000 Hello >> Has anyone else seen this? Yes I have the exact same error messages on LCD and kernel freeze on same e= rror. Dell PowerEdge 1950, after 8.0-RC2 install Install CD boots ok, but GENERIC kernel freeze. >> I am trying to upgrade from FreeBSD 7.0 to 8.0-RC2. =A0AFter install and >> during the boot, it locks up after: Pci1. Pci bus on pcib7 >> >> The info LCD on the server says >> E1410 cpu1 ierr. =A0E1410. Cpu2. Ierr >> >> I believe it did this with RC1 as well but I gave up since RC2 was getti= ng >> ready to come out. (I put back in the drives with 7.0 and let it run wit= h >> that) >> >> HW info: >> It is a Dell PowerEdge 2950-iii with 2x4 core processors and 8GB RAM. = =A0It >> has a Perc SATA/SAS RAID controller. >> > _______________________________________________ > 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-current@FreeBSD.ORG Tue Oct 27 20:34:46 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6D36F106566C for ; Tue, 27 Oct 2009 20:34:46 +0000 (UTC) (envelope-from triosoft@triosoft.com.ua) Received: from lynx.bereg.net.ua (ns.ein.uz.ua [194.88.152.1]) by mx1.freebsd.org (Postfix) with ESMTP id 23E378FC19 for ; Tue, 27 Oct 2009 20:34:45 +0000 (UTC) Received: from bobooka.local (252-91-124-91.pool.ukrtel.net [91.124.91.252]) by lynx.bereg.net.ua (Postfix) with ESMTPA id 6A40161E55 for ; Tue, 27 Oct 2009 22:16:08 +0200 (EET) Message-ID: <4AE754FB.7090007@triosoft.com.ua> Date: Tue, 27 Oct 2009 22:15:55 +0200 From: "Alexander V. Ribchansky" User-Agent: Thunderbird 2.0.0.23 (X11/20090825) MIME-Version: 1.0 To: freebsd-current@freebsd.org Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: ZFS pool bootfs property and vfs.root.mountfrom X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Oct 2009 20:34:46 -0000 Hello, zfs gurus! I wonder, is it hard to implement some kind of auto-sensing vfs.root.mountfrom from zfs's pool's bootfs property, which normally points to dataset that should be root FS? I dig into sys/boot and find out that we "just" :) need do place setenv("vfs.root.mountfrom",ZFS_GET_POOL_PROP("bootfs") <- some kind of metacode in a RIGHT place. But by all means I cannot gather whole picture of freebsd booting process (mean in sources who calls what) and find that magical RIGHT place. So may be zfs-gurus can say something? Is it possible to implement such thing? Is it hard? May be some hints of what to dig deeper in? thanks! -- AVR39-RIPE From owner-freebsd-current@FreeBSD.ORG Tue Oct 27 22:02:45 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3901F106568F for ; Tue, 27 Oct 2009 22:02:45 +0000 (UTC) (envelope-from jhs@berklix.com) Received: from tower.berklix.org (tower.berklix.org [83.236.223.114]) by mx1.freebsd.org (Postfix) with ESMTP id 885B88FC0C for ; Tue, 27 Oct 2009 22:02:42 +0000 (UTC) Received: from park.js.berklix.net (p549A39A8.dip.t-dialin.net [84.154.57.168]) (authenticated bits=0) by tower.berklix.org (8.14.2/8.14.2) with ESMTP id n9RM2csi016554; Tue, 27 Oct 2009 22:02:39 GMT (envelope-from jhs@berklix.com) Received: from fire.js.berklix.net (fire.js.berklix.net [192.168.91.41]) by park.js.berklix.net (8.13.8/8.13.8) with ESMTP id n9RM2R1V003991; Tue, 27 Oct 2009 23:02:27 +0100 (CET) (envelope-from jhs@berklix.com) Received: from fire.js.berklix.net (localhost [127.0.0.1]) by fire.js.berklix.net (8.14.3/8.14.3) with ESMTP id n9RM1Kh4005460; Tue, 27 Oct 2009 23:01:25 +0100 (CET) (envelope-from jhs@fire.js.berklix.net) Message-Id: <200910272201.n9RM1Kh4005460@fire.js.berklix.net> To: =?ISO-8859-1?Q?C=E9dric_Tabary?= From: "Julian H. Stacey" Organization: http://www.berklix.com BSD Unix Linux Consultancy, Munich Germany User-agent: EXMH on FreeBSD http://www.berklix.com/free/ X-URL: http://www.berklix.com In-reply-to: Your message "Tue, 27 Oct 2009 19:14:33 +0100." <52c7f0c80910271114w27929312mc06aead560aa73bc@mail.gmail.com> Date: Tue, 27 Oct 2009 23:01:20 +0100 Sender: jhs@berklix.com Cc: freebsd-current@freebsd.org Subject: Re: dell 2950/ FreeBSD 8.0-RC2 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Oct 2009 22:02:45 -0000 > Yes I have the exact same error messages on LCD and kernel freeze on same error. > Dell PowerEdge 1950, after 8.0-RC2 install Puzzled ... I saw a mail ref to RC2 last night & checked ftp on .de & USA to download, but saw just saw RC1, now a night later I still see at Tue Oct 27 22:56:07 CET 2009 just ftp.freebsd.org Remote directory: /pub/FreeBSD/releases/i386/ISO-IMAGES/8.0 8.0-RC1-i386-* I guess your running from ?what? self compiled, & it hasnt hit ftp repo. yet. (I recall CVS too doesnt get those RC tags, that' just subversion I assume) Cheers, Julian -- Julian Stacey: BSD Unix Linux C Sys Eng Consultants Munich http://berklix.com Mail plain text not quoted-printable, HTML or Base64: http://asciiribbon.org From owner-freebsd-current@FreeBSD.ORG Tue Oct 27 22:17:42 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6223B106568F; Tue, 27 Oct 2009 22:17:42 +0000 (UTC) (envelope-from nork@ninth-nine.com) Received: from sakura.ninth-nine.com (unknown [IPv6:2001:2f0:104:80a1::25]) by mx1.freebsd.org (Postfix) with ESMTP id D33738FC1B; Tue, 27 Oct 2009 22:17:41 +0000 (UTC) Received: from nadesico.ninth-nine.com (ns1.ninth-nine.com [219.127.74.121] (may be forged)) (authenticated bits=0) by sakura.ninth-nine.com (8.14.3/8.14.3/NinthNine) with ESMTP id n9RMHZbZ098445; Wed, 28 Oct 2009 07:17:40 +0900 (JST) (envelope-from nork@ninth-nine.com) Date: Wed, 28 Oct 2009 07:17:34 +0900 From: Norikatsu Shigemura To: Robert Noland Message-Id: <20091028071734.e92e8e49.nork@ninth-nine.com> In-Reply-To: <1256571299.2502.219.camel@balrog.2hip.net> References: <1256517106.2502.205.camel@balrog.2hip.net> <1256571299.2502.219.camel@balrog.2hip.net> X-Mailer: Sylpheed 2.7.1 (GTK+ 2.16.6; i386-portbld-freebsd8.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: GPT boot with ZFS RAIDZ "ZFS: i/o error - all block copies unavailable" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Oct 2009 22:17:42 -0000 Hi rnoland. On Mon, 26 Oct 2009 10:34:59 -0500 Robert Noland wrote: > > >> ZFS: i/o error - all block copies unavailable > > >> Invalid format > > >> FreeBSD/i386 boot > > >> Default: tank:/boot/kernel/kernel > > >> boot: > > > Could you type "status" at this point and tell what it shows? > > If I type status at this point I get: > > pool: tank > > config: > > NAME STATE > > tank ONLINE > > raidz1 ONLINE > > ad4p3 ONLINE > > ad6p3 ONLINE > > ad8p3 ONLINE > > ad10p3 ONLINE > > Which seems odd, since that's all the drives there are. So if it finds > > these it's already found all drives. My optimistic "Oh! I'll try and boot > > again" spirit was however crushed since it just results in the same error. > Ok, that is both good and frustrating... I haven't produced any boot > failures with all of the drives visible. Do, note that I just added > support for reading gang blocks to the loader. (basically untested, > since I haven't managed to create them at will) You will need to update > your partition boot code for it to be supported during early boot. i.e. > gpart bootcode -p /boot/gptzfsboot -i > The "all block copies unavailable" is a frustrating error, since all it > means is a failed read, but we don't get a clue what failed or why. > With the code that is in -CURRENT it will report gang blocks if found, > even if it fails to read them. I confirmed reproduce. 1. zpool list, and get SIZE and CAP. $ zpool list NAME SIZE USED AVAIL CAP HEALTH ALTROOT tank 59.5G 48.4G 11.1G 81% ONLINE - 2. reduce AVAIL < 10% with creating dummy file like ... $ dd if=/dev/zero of=$HOME/DUMMY.FILE bs=1m count=5632 5632+0 records in 5632+0 records out 5905580032 bytes transferred in 49.822200 secs (118533104 bytes/sec) $ zpool list NAME SIZE USED AVAIL CAP HEALTH ALTROOT tank 59.5G 53.9G 5.61G 90% ONLINE - 3. cd /boot/; cp -pr kernel kernel.err In this time, if reboot, we can get boot time error. 4. rm $HOME/DUMMY.FILE, and reboot 5. boot kernel.err on new-loader. I can get "ZFS: gang block detected!" message and overrun:D. From owner-freebsd-current@FreeBSD.ORG Tue Oct 27 23:19:23 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AD3A3106566B for ; Tue, 27 Oct 2009 23:19:23 +0000 (UTC) (envelope-from rnoland@FreeBSD.org) Received: from gizmo.2hip.net (gizmo.2hip.net [64.74.207.195]) by mx1.freebsd.org (Postfix) with ESMTP id 74DE38FC15 for ; Tue, 27 Oct 2009 23:19:23 +0000 (UTC) Received: from [192.168.1.4] (adsl-150-102-19.bna.bellsouth.net [72.150.102.19]) (authenticated bits=0) by gizmo.2hip.net (8.14.3/8.14.3) with ESMTP id n9RNJKc8058659 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Tue, 27 Oct 2009 19:19:21 -0400 (EDT) (envelope-from rnoland@FreeBSD.org) From: Robert Noland To: Norikatsu Shigemura In-Reply-To: <20091028071734.e92e8e49.nork@ninth-nine.com> References: <1256517106.2502.205.camel@balrog.2hip.net> <1256571299.2502.219.camel@balrog.2hip.net> <20091028071734.e92e8e49.nork@ninth-nine.com> Content-Type: text/plain Organization: FreeBSD Date: Tue, 27 Oct 2009 18:19:15 -0500 Message-Id: <1256685555.2315.9.camel@balrog.2hip.net> Mime-Version: 1.0 X-Mailer: Evolution 2.26.3 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-1.7 required=5.0 tests=AWL,BAYES_00, RCVD_IN_SORBS_DUL, RDNS_DYNAMIC, SPF_SOFTFAIL autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on gizmo.2hip.net Cc: freebsd-current@freebsd.org Subject: Re: GPT boot with ZFS RAIDZ "ZFS: i/o error - all block copies unavailable" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Oct 2009 23:19:23 -0000 On Wed, 2009-10-28 at 07:17 +0900, Norikatsu Shigemura wrote: > Hi rnoland. > > On Mon, 26 Oct 2009 10:34:59 -0500 > Robert Noland wrote: > > > >> ZFS: i/o error - all block copies unavailable > > > >> Invalid format > > > >> FreeBSD/i386 boot > > > >> Default: tank:/boot/kernel/kernel > > > >> boot: > > > > Could you type "status" at this point and tell what it shows? > > > If I type status at this point I get: > > > pool: tank > > > config: > > > NAME STATE > > > tank ONLINE > > > raidz1 ONLINE > > > ad4p3 ONLINE > > > ad6p3 ONLINE > > > ad8p3 ONLINE > > > ad10p3 ONLINE > > > Which seems odd, since that's all the drives there are. So if it finds > > > these it's already found all drives. My optimistic "Oh! I'll try and boot > > > again" spirit was however crushed since it just results in the same error. > > Ok, that is both good and frustrating... I haven't produced any boot > > failures with all of the drives visible. Do, note that I just added > > support for reading gang blocks to the loader. (basically untested, > > since I haven't managed to create them at will) You will need to update > > your partition boot code for it to be supported during early boot. i.e. > > gpart bootcode -p /boot/gptzfsboot -i > > The "all block copies unavailable" is a frustrating error, since all it > > means is a failed read, but we don't get a clue what failed or why. > > With the code that is in -CURRENT it will report gang blocks if found, > > even if it fails to read them. > > I confirmed reproduce. > > 1. zpool list, and get SIZE and CAP. > $ zpool list > NAME SIZE USED AVAIL CAP HEALTH ALTROOT > tank 59.5G 48.4G 11.1G 81% ONLINE - > > 2. reduce AVAIL < 10% with creating dummy file like ... > $ dd if=/dev/zero of=$HOME/DUMMY.FILE bs=1m count=5632 > 5632+0 records in > 5632+0 records out > 5905580032 bytes transferred in 49.822200 secs (118533104 bytes/sec) > $ zpool list > NAME SIZE USED AVAIL CAP HEALTH ALTROOT > tank 59.5G 53.9G 5.61G 90% ONLINE - > > 3. cd /boot/; cp -pr kernel kernel.err > In this time, if reboot, we can get boot time error. > > 4. rm $HOME/DUMMY.FILE, and reboot > > 5. boot kernel.err on new-loader. > I can get "ZFS: gang block detected!" message and overrun:D. Ok, so does it still boot? Or do you still get an error? robert. -- Robert Noland FreeBSD From owner-freebsd-current@FreeBSD.ORG Wed Oct 28 00:25:41 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 56E79106568D for ; Wed, 28 Oct 2009 00:25:41 +0000 (UTC) (envelope-from kaduk@MIT.EDU) Received: from biscayne-one-station.mit.edu (BISCAYNE-ONE-STATION.MIT.EDU [18.7.7.80]) by mx1.freebsd.org (Postfix) with ESMTP id 1683D8FC14 for ; Wed, 28 Oct 2009 00:25:40 +0000 (UTC) Received: from outgoing.mit.edu (OUTGOING-AUTH.MIT.EDU [18.7.22.103]) by biscayne-one-station.mit.edu (8.13.6/8.9.2) with ESMTP id n9S0PR4f014719; Tue, 27 Oct 2009 20:25:28 -0400 (EDT) Received: from multics.mit.edu (MULTICS.MIT.EDU [18.187.1.73]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.6/8.12.4) with ESMTP id n9S0Pbnk019890 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 27 Oct 2009 20:25:39 -0400 (EDT) Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id n9S0PZnH024516; Tue, 27 Oct 2009 20:25:35 -0400 (EDT) Date: Tue, 27 Oct 2009 20:25:35 -0400 (EDT) From: Benjamin Kaduk To: tuezen@freebsd.org, freebsd-current@freebsd.org Message-ID: User-Agent: Alpine 1.10 (GSO 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII X-Scanned-By: MIMEDefang 2.42 X-Spam-Flag: NO X-Spam-Score: 0.00 Cc: bzeeb+freebsd+lor@zabbadoz.net Subject: lock order reversal on startup (rtentry, ifnet_sx) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Oct 2009 00:25:41 -0000 Hi all, I don't see this explicitly mentioned before, nor on http://sources.zabbadoz.net/freebsd/lor.html It shows up on startup with a -current from two days ago. Looking at the svn logs, maybe it was introduced with r197328? lock order reversal: (sleepable after non-sleepable) 1st 0xffffff0002d360a8 rtentry (rtentry) @ /usr/src/sys/net/route.c:1474 2nd 0xffffffff80e00b00 ifnet_sx (ifnet_sx) @ /usr/src/sys/netinet/sctp_bsd_addr.c:212 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2a _witness_debugger() at _witness_debugger+0x2e witness_checkorder() at witness_checkorder+0x81e _sx_slock() at _sx_slock+0x55 sctp_init_ifns_for_vrf() at sctp_init_ifns_for_vrf+0x2e sctp_addr_change() at sctp_addr_change+0xce rt_newaddrmsg() at rt_newaddrmsg+0x54 rtinit() at rtinit+0x358 in_ifinit() at in_ifinit+0x2fd in_control() at in_control+0x1047 ifioctl() at ifioctl+0xfc1 kern_ioctl() at kern_ioctl+0xc5 ioctl() at ioctl+0xfd syscall() at syscall+0x1af Xfast_syscall() at Xfast_syscall+0xe1 --- syscall (54, FreeBSD ELF64, ioctl), rip = 0x800b8072c, rsp = 0x7fffffffe4e8, rbp = 0x7fffffffef6a --- -Ben Kaduk From owner-freebsd-current@FreeBSD.ORG Wed Oct 28 05:13:33 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B3328106566C for ; Wed, 28 Oct 2009 05:13:33 +0000 (UTC) (envelope-from areilly@bigpond.net.au) Received: from nschwqsrv02p.mx.bigpond.com (nschwqsrv02p.mx.bigpond.com [61.9.189.234]) by mx1.freebsd.org (Postfix) with ESMTP id 42AB38FC15 for ; Wed, 28 Oct 2009 05:13:33 +0000 (UTC) Received: from nschwotgx02p.mx.bigpond.com ([124.188.161.100]) by nschwmtas05p.mx.bigpond.com with ESMTP id <20091028040357.RVXR28093.nschwmtas05p.mx.bigpond.com@nschwotgx02p.mx.bigpond.com>; Wed, 28 Oct 2009 04:03:57 +0000 Received: from duncan.reilly.home ([124.188.161.100]) by nschwotgx02p.mx.bigpond.com with ESMTP id <20091028040356.NWEP9934.nschwotgx02p.mx.bigpond.com@duncan.reilly.home>; Wed, 28 Oct 2009 04:03:56 +0000 Date: Wed, 28 Oct 2009 15:03:56 +1100 From: Andrew Reilly To: freebsd-current@freebsd.org, bzeeb+freebsd+lor@zabbadoz.net Message-ID: <20091028040356.GA68328@duncan.reilly.home> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.3i X-Authentication-Info: Submitted using SMTP AUTH LOGIN at nschwotgx02p.mx.bigpond.com from [124.188.161.100] using ID areilly@bigpond.net.au at Wed, 28 Oct 2009 04:03:56 +0000 X-RPD-ScanID: Class unknown; VirusThreatLevel unknown, RefID str=0001.0A150201.4AE7C2AD.00D1,ss=1,fgs=0 X-SIH-MSG-ID: rBg1E9P8TAD0zmQs0WyzOwJxyArnqyN48Z4QX81loRIGTUDCp8DeQ9rEJvdRvt2ixDxEJhqBNGEjaanjTY3RstCK Cc: Subject: LOR 1st rtentry, 2nd ifnet_sx X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Oct 2009 05:13:33 -0000 Hi there, I've just joined the bumpy road of -current, in order to answer a qustion about USB attached drives (see -stable and -fs), and am now learning about reporting lock order reversals. Here's my first, from the last dmesg.boot. Doesn't seem to be in the lor database or PRs. I'm running -current on amd64: FreeBSD duncan.reilly.home 9.0-CURRENT FreeBSD 9.0-CURRENT #0: Mon Oct 26 20:19:29 EST 2009 root@duncan.reilly.home:/usr/obj/usr/src/sys/DUNCAN amd64 lock order reversal: (sleepable after non-sleepable) 1st 0xffffff0002cc30a8 rtentry (rtentry) @ /usr/src/sys/net/route.c:1474 2nd 0xffffffff80e00b00 ifnet_sx (ifnet_sx) @ /usr/src/sys/netinet/sctp_bsd_addr.c:212 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2a _witness_debugger() at _witness_debugger+0x2e witness_checkorder() at witness_checkorder+0x81e _sx_slock() at _sx_slock+0x55 sctp_init_ifns_for_vrf() at sctp_init_ifns_for_vrf+0x2e sctp_addr_change() at sctp_addr_change+0xce rt_newaddrmsg() at rt_newaddrmsg+0x54 rtinit() at rtinit+0x358 in_ifinit() at in_ifinit+0x2fd in_control() at in_control+0x1047 ifioctl() at ifioctl+0xfc1 kern_ioctl() at kern_ioctl+0xc5 ioctl() at ioctl+0xfd syscall() at syscall+0x1af Xfast_syscall() at Xfast_syscall+0xe1 --- syscall (54, FreeBSD ELF64, ioctl), rip = 0x800b8084c, rsp = 0x7fffffffe4e8, rbp = 0x7fffffffef6a --- From owner-freebsd-current@FreeBSD.ORG Wed Oct 28 08:12:10 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 62082106568D for ; Wed, 28 Oct 2009 08:12:10 +0000 (UTC) (envelope-from alteriks@gmail.com) Received: from mail.agora.pl (mail.agora.pl [193.42.230.55]) by mx1.freebsd.org (Postfix) with ESMTP id CC9D68FC23 for ; Wed, 28 Oct 2009 08:12:09 +0000 (UTC) Received: from agpost.agora.pl (agpost.agora.pl [10.205.39.149]) by mail.agora.pl (8.13.8/8.11.1) with ESMTP id n9S7hPZU011246 for ; Wed, 28 Oct 2009 08:43:25 +0100 Received: from t42.localnet ([10.201.55.193]) by agpost.agora.pl with ESMTP; Wed, 28 Oct 2009 08:42:58 +0100 From: "alteriks@gmail.com" To: freebsd-current@freebsd.org Date: Wed, 28 Oct 2009 09:42:50 +0200 User-Agent: KMail/1.12.2 (Linux/2.6.30-1-686; KDE/4.3.2; i686; ; ) MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Message-Id: <200910280842.50919.alteriks@gmail.com> Subject: GPT boot with ZFS RAIDZ "ZFS: i/o error - all block copies unavailable" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Oct 2009 08:12:10 -0000 Hi, I'm having same problem as Radek Val=C3=A1=C5=A1ek. I tried to install FreeBSD-8.0-RC1 on 3 GPT disks. I did step by step 'manual' from=20 http://wiki.freebsd.org/RootOnZFS/GPTZFSBoot/RAIDZ2 I'd like to ask if this problem could be related to setting AHCI host=20 controller on? ZFS: i/o error - all block copies unavailable ZFS: can't read MOS ZFS: unexpected object set type lld ZFS: unexpected object set type lld =46reeBSD/i386 boot Default: z:/boot/kernel/kernel boot: ZFS: unexpected object set type lld =46reeBSD/i386 boot Default: tank:/boot/kernel/kernel boot: =46reeBSD/i386 boot Default: tank:/boot/kernel/kernel boot: From owner-freebsd-current@FreeBSD.ORG Wed Oct 28 08:55:14 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CCD851065676 for ; Wed, 28 Oct 2009 08:55:14 +0000 (UTC) (envelope-from roberto@keltia.freenix.fr) Received: from keltia.freenix.fr (keltia.freenix.org [IPv6:2001:660:330f:f820:213:72ff:fe15:f44]) by mx1.freebsd.org (Postfix) with ESMTP id 7F1368FC22 for ; Wed, 28 Oct 2009 08:55:14 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by keltia.freenix.fr (Postfix/TLS) with ESMTP id 5FD523B9D2 for ; Wed, 28 Oct 2009 09:55:13 +0100 (CET) X-Virus-Scanned: amavisd-new at keltia.freenix.fr Received: from keltia.freenix.fr ([127.0.0.1]) by localhost (keltia.freenix.fr [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WLFLOv04AvCs for ; Wed, 28 Oct 2009 09:55:12 +0100 (CET) Received: from roberto-al.eurocontrol.fr (aran.keltia.net [88.191.250.24]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: roberto) by keltia.freenix.fr (Postfix/TLS) with ESMTPSA id A9D373B9BC for ; Wed, 28 Oct 2009 09:55:12 +0100 (CET) Date: Wed, 28 Oct 2009 09:54:36 +0100 From: Ollivier Robert To: freebsd-current@freebsd.org Message-ID: <20091028085436.GA5467@roberto-al.eurocontrol.fr> References: <4AE0BA63.2000804@haruhiism.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Operating-System: MacOS X / Macbook Pro - FreeBSD 7.2 / Dell D820 SMP User-Agent: Mutt/1.5.20 (2009-06-14) Subject: Re: Trouble booting system with root within gvinum volume X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Oct 2009 08:55:14 -0000 According to Sean C. Farley: > That makes sense. Thank you. I will make a swap outside of any > GEOM device. That's also why I did not use a zvol for swap in my ZFS setup. -- Ollivier ROBERT -=- FreeBSD: The Power to Serve! -=- roberto@keltia.freenix.fr In memoriam to Ondine : http://ondine.keltia.net/ From owner-freebsd-current@FreeBSD.ORG Wed Oct 28 09:36:15 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 672A71065670 for ; Wed, 28 Oct 2009 09:36:15 +0000 (UTC) (envelope-from aw1@swelter.hanley.stade.co.uk) Received: from v-smtp-auth-relay-2.gradwell.net (v-smtp-auth-relay-2.gradwell.net [79.135.125.41]) by mx1.freebsd.org (Postfix) with ESMTP id C98208FC1B for ; Wed, 28 Oct 2009 09:36:14 +0000 (UTC) Received: from 93-97-22-18.zone5.bethere.co.uk ([93.97.22.18] helo=swelter.hanley.stade.co.uk ident=postmaster#pop3*stade*co&uk) by v-smtp-auth-relay-2.gradwell.net with esmtpa (Gradwell gwh-smtpd 1.290) id 4ae807d0.50fb.e; Wed, 28 Oct 2009 08:58:56 +0000 (envelope-sender ) Received: from swelter.hanley.stade.co.uk (localhost [127.0.0.1]) by swelter.hanley.stade.co.uk (8.14.3/8.14.3) with ESMTP id n9S8wq7M025758; Wed, 28 Oct 2009 08:58:52 GMT (envelope-from aw1@swelter.hanley.stade.co.uk) Received: (from aw1@localhost) by swelter.hanley.stade.co.uk (8.14.3/8.14.3/Submit) id n9S8wpDu025727; Wed, 28 Oct 2009 08:58:51 GMT (envelope-from aw1) Date: Wed, 28 Oct 2009 08:58:51 +0000 From: Adrian Wontroba To: "Julian H. Stacey" Message-ID: <20091028085850.GA1670@swelter.hanley.stade.co.uk> Mail-Followup-To: Adrian Wontroba , "Julian H. Stacey" , freebsd-current@freebsd.org References: <52c7f0c80910271114w27929312mc06aead560aa73bc@mail.gmail.com> <200910272201.n9RM1Kh4005460@fire.js.berklix.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200910272201.n9RM1Kh4005460@fire.js.berklix.net> User-Agent: Mutt/1.4.2.3i X-Operating-System: FreeBSD 8.0-RC2 Organization: Oh dear, I've joined one again. X-Virus-Scanned: clamav-milter 0.95.2 at swelter.hanley.stade.co.uk X-Virus-Status: Clean Cc: freebsd-current@freebsd.org Subject: Re: dell 2950/ FreeBSD 8.0-RC2 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: aw1@stade.co.uk List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Oct 2009 09:36:15 -0000 On Tue, Oct 27, 2009 at 11:01:20PM +0100, Julian H. Stacey wrote: > Puzzled ... I saw a mail ref to RC2 last night & checked ftp on .de > & USA to download, but saw just saw RC1, now a night later I still > see at Tue Oct 27 22:56:07 CET 2009 just ftp.freebsd.org Remote > directory: /pub/FreeBSD/releases/i386/ISO-IMAGES/8.0 8.0-RC1-i386-* > I guess your running from ?what? self compiled, & it hasnt hit ftp > repo. yet. (I recall CVS too doesnt get those RC tags, that' just > subversion I assume) Yes, RC2 hit svs/cvs a few days ago: Date: Sun Oct 25 00:28:01 2009 New Revision: 198456 URL: http://svn.freebsd.org/changeset/base/198456 Log: Prepare for 8.0-RC2 builds. So, if you build it yourself you can have what is likely to be RC2 now too. I'm running (on this machine): FreeBSD swelter.hanley.stade.co.uk 8.0-RC2 FreeBSD 8.0-RC2 #0: Tue Oct 27 18:14:56 GMT 2009 root@swelter.hanley.stade.co.uk:/usr/obj/usr/src/sys/GENERIC amd64 The last time I rsync'd i386 and amd65 stable packages had recently been updated. [aw1@swelter /home/ftp/pub/FreeBSD/ports]$ ls -l */*-stable/INDEX -rw-rw-r-- 1 500 450 18068940 21 Oct 17:32 amd64/packages-8-stable/INDEX -rw-rw-r-- 1 500 450 18450778 23 Oct 18:36 i386/packages-8-stable/INDEX I'd imagine that the RC2 announcement isn't far off. 8.0 is looking pretty good, and the ports / packages I use are in fair shape too. I am seriously considering switching my works machines to 8-stable once 8.0-release is out. -- Adrian Wontroba I know you believe you understand what you think this fortune says, but I'm not sure you realize that what you are reading is not what it means. From owner-freebsd-current@FreeBSD.ORG Wed Oct 28 11:10:27 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 15C451065676 for ; Wed, 28 Oct 2009 11:10:27 +0000 (UTC) (envelope-from rnoland@FreeBSD.org) Received: from gizmo.2hip.net (gizmo.2hip.net [64.74.207.195]) by mx1.freebsd.org (Postfix) with ESMTP id D005B8FC17 for ; Wed, 28 Oct 2009 11:10:26 +0000 (UTC) Received: from [192.168.1.4] (adsl-150-102-19.bna.bellsouth.net [72.150.102.19]) (authenticated bits=0) by gizmo.2hip.net (8.14.3/8.14.3) with ESMTP id n9SBAGkA082873 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Wed, 28 Oct 2009 07:10:20 -0400 (EDT) (envelope-from rnoland@FreeBSD.org) From: Robert Noland To: "alteriks@gmail.com" In-Reply-To: <200910280842.50919.alteriks@gmail.com> References: <200910280842.50919.alteriks@gmail.com> Content-Type: text/plain; charset="iso-8859-2" Organization: FreeBSD Date: Wed, 28 Oct 2009 06:10:10 -0500 Message-Id: <1256728210.2315.21.camel@balrog.2hip.net> Mime-Version: 1.0 X-Mailer: Evolution 2.26.3 FreeBSD GNOME Team Port Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-1.7 required=5.0 tests=AWL,BAYES_00, RCVD_IN_SORBS_DUL, RDNS_DYNAMIC, SPF_SOFTFAIL autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on gizmo.2hip.net Cc: freebsd-current@freebsd.org Subject: Re: GPT boot with ZFS RAIDZ "ZFS: i/o error - all block copies unavailable" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Oct 2009 11:10:27 -0000 On Wed, 2009-10-28 at 09:42 +0200, alteriks@gmail.com wrote: > Hi, > I'm having same problem as Radek Valášek. > I tried to install FreeBSD-8.0-RC1 on 3 GPT disks. > I did step by step 'manual' from > http://wiki.freebsd.org/RootOnZFS/GPTZFSBoot/RAIDZ2 > I'd like to ask if this problem could be related to setting AHCI host > controller on? I think that is unlikely. If you type status at this point, does it show all of your drives ONLINE? > ZFS: i/o error - all block copies unavailable > ZFS: can't read MOS > ZFS: unexpected object set type lld > ZFS: unexpected object set type lld I'm trying to find the "can't read MOS" issue now. This is pretty much the first thing that we try to get once all of the drives are online. I can't produce this issue locally, so I'm trying to get enough debugging to see what is going on with the root block pointer. Basically, if we can't read the MOS, we aren't going to read anything. Thanks to ps@, we have a wrapper program that lets us debug this from userland which helps a lot. I just wish that I could figure out how to replicate the problem, but I guess if I could do that... we could figure out how to fix it. robert. > FreeBSD/i386 boot > Default: z:/boot/kernel/kernel > boot: > ZFS: unexpected object set type lld > > FreeBSD/i386 boot > Default: tank:/boot/kernel/kernel > boot: > > FreeBSD/i386 boot > Default: tank:/boot/kernel/kernel > boot: > _______________________________________________ > 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" -- Robert Noland FreeBSD From owner-freebsd-current@FreeBSD.ORG Wed Oct 28 06:37:37 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 01BC6106568D for ; Wed, 28 Oct 2009 06:37:37 +0000 (UTC) (envelope-from tuexen@fh-muenster.de) Received: from mail-n.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) by mx1.freebsd.org (Postfix) with ESMTP id 633228FC1D for ; Wed, 28 Oct 2009 06:37:36 +0000 (UTC) Received: from [IPv6:2002:508f:ee96::224:36ff:feef:67d1] (unknown [IPv6:2002:508f:ee96:0:224:36ff:feef:67d1]) by mail-n.franken.de (Postfix) with ESMTP id 6FD0F1C0B4612; Wed, 28 Oct 2009 07:37:32 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1076) Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes From: Michael Tuexen In-Reply-To: Date: Wed, 28 Oct 2009 07:37:31 +0100 Content-Transfer-Encoding: 7bit Message-Id: References: To: Benjamin Kaduk X-Mailer: Apple Mail (2.1076) X-Mailman-Approved-At: Wed, 28 Oct 2009 11:25:28 +0000 Cc: bzeeb+freebsd+lor@zabbadoz.net, freebsd-current@freebsd.org Subject: Re: lock order reversal on startup (rtentry, ifnet_sx) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Oct 2009 06:37:37 -0000 Hi Ben, does Index: route.c =================================================================== --- route.c (revision 197953) +++ route.c (working copy) @@ -1497,7 +1497,11 @@ ((struct sockaddr_dl *)rt->rt_gateway)->sdl_index = rt->rt_ifp->if_index; } + RT_ADDREF(rt); + RT_UNLOCK(rt); rt_newaddrmsg(cmd, ifa, error, rt); + RT_LOCK(rt); + RT_REMREF(rt); if (cmd == RTM_DELETE) { /* * If we are deleting, and we found an entry, fix the issue? Best regards Michael On Oct 28, 2009, at 1:25 AM, Benjamin Kaduk wrote: > Hi all, > > I don't see this explicitly mentioned before, nor on > http://sources.zabbadoz.net/freebsd/lor.html > > It shows up on startup with a -current from two days ago. > Looking at the svn logs, maybe it was introduced with r197328? > > > lock order reversal: (sleepable after non-sleepable) > 1st 0xffffff0002d360a8 rtentry (rtentry) @ /usr/src/sys/net/route.c: > 1474 > 2nd 0xffffffff80e00b00 ifnet_sx (ifnet_sx) @ /usr/src/sys/netinet/ > sctp_bsd_addr.c:212 > KDB: stack backtrace: > db_trace_self_wrapper() at db_trace_self_wrapper+0x2a > _witness_debugger() at _witness_debugger+0x2e > witness_checkorder() at witness_checkorder+0x81e > _sx_slock() at _sx_slock+0x55 > sctp_init_ifns_for_vrf() at sctp_init_ifns_for_vrf+0x2e > sctp_addr_change() at sctp_addr_change+0xce > rt_newaddrmsg() at rt_newaddrmsg+0x54 > rtinit() at rtinit+0x358 > in_ifinit() at in_ifinit+0x2fd > in_control() at in_control+0x1047 > ifioctl() at ifioctl+0xfc1 > kern_ioctl() at kern_ioctl+0xc5 > ioctl() at ioctl+0xfd > syscall() at syscall+0x1af > Xfast_syscall() at Xfast_syscall+0xe1 > --- syscall (54, FreeBSD ELF64, ioctl), rip = 0x800b8072c, rsp = > 0x7fffffffe4e8, rbp = 0x7fffffffef6a --- > > > -Ben Kaduk > > From owner-freebsd-current@FreeBSD.ORG Wed Oct 28 08:43:39 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C8F761065670 for ; Wed, 28 Oct 2009 08:43:39 +0000 (UTC) (envelope-from a.agarwal@jach.hawaii.edu) Received: from mailhost.jach.hawaii.edu (mailhost.jach.HAWAII.EDU [128.171.90.17]) by mx1.freebsd.org (Postfix) with ESMTP id AC75A8FC0A for ; Wed, 28 Oct 2009 08:43:39 +0000 (UTC) Date: Tue, 27 Oct 2009 22:25:51 -1000 From: a.agarwal@jach.hawaii.edu To: freebsd-current@freebsd.org Message-ID: <20091028082551.GA27015@uluhe.jach.hawaii.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Mailman-Approved-At: Wed, 28 Oct 2009 11:25:47 +0000 Subject: Installing RELEASE_8 alongside RELEASE_7 on respective slices X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Oct 2009 08:43:39 -0000 Hi there, (Please CC me as I am not currently subscribed with this address.) Currently I have RELEASE_7 installed on one slice, and have copied the file structure from there to a different slice which currently contains the RELEASE_8 source ... (Actual partition names may be different as I type them from memory.) ad4s2a / base RELEASE_7 install /{,boot,root,usr} etc. ad4s3a /current contains copy of / & RELEASE_8 source ad4s4a /misc will contain what would have gone in /{usr/ports,usr/local,home} ... swap partition is on ad4s2. While running RELEASE_7 system, I want to install RELEASE_8 such that it puts/overwrites the files in /current. How do I go about that without affecting / with RELEASE_7 installation? -- From owner-freebsd-current@FreeBSD.ORG Wed Oct 28 11:26:03 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 634031065695 for ; Wed, 28 Oct 2009 11:26:03 +0000 (UTC) (envelope-from alteriks@gmail.com) Received: from mail.agora.pl (mail.agora.pl [193.42.230.53]) by mx1.freebsd.org (Postfix) with ESMTP id CB8FE8FC27 for ; Wed, 28 Oct 2009 11:26:02 +0000 (UTC) Received: from agpost.agora.pl (agpost.agora.pl [10.205.39.149]) by mail.agora.pl (8.13.8/8.11.1) with ESMTP id n9SBQ1AJ013312; Wed, 28 Oct 2009 12:26:01 +0100 Received: from t42.localnet ([10.201.55.193]) by agpost.agora.pl with ESMTP; Wed, 28 Oct 2009 12:25:58 +0100 From: "alteriks@gmail.com" To: Robert Noland Date: Wed, 28 Oct 2009 13:25:53 +0200 User-Agent: KMail/1.12.2 (Linux/2.6.30-1-686; KDE/4.3.2; i686; ; ) References: <200910280842.50919.alteriks@gmail.com> <1256728210.2315.21.camel@balrog.2hip.net> In-Reply-To: <1256728210.2315.21.camel@balrog.2hip.net> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-2" Content-Transfer-Encoding: 7bit Message-Id: <200910281225.53591.alteriks@gmail.com> Cc: freebsd-current@freebsd.org Subject: Re: GPT boot with ZFS RAIDZ "ZFS: i/o error - all block copies unavailable" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Oct 2009 11:26:03 -0000 On Wednesday 28 October 2009 12:10:10 you wrote: > I think that is unlikely. If you type status at this point, does it > show all of your drives ONLINE? > Yes, they we're online. >>ZFS: can't read MOS I'm not quite sure about this line because I copy/pasted from Radek's post. I will check it and post later when I'll get home. From owner-freebsd-current@FreeBSD.ORG Wed Oct 28 12:43:26 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3E6E5106566C for ; Wed, 28 Oct 2009 12:43:26 +0000 (UTC) (envelope-from shuvaev@physik.uni-wuerzburg.de) Received: from mailrelay.rz.uni-wuerzburg.de (mailrelay.rz.uni-wuerzburg.de [132.187.3.28]) by mx1.freebsd.org (Postfix) with ESMTP id E64578FC0C for ; Wed, 28 Oct 2009 12:43:25 +0000 (UTC) Received: from virusscan.mail (localhost [127.0.0.1]) by mailrelay.mail (Postfix) with ESMTP id A52A25BC46; Wed, 28 Oct 2009 13:43:23 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by virusscan.mail (Postfix) with ESMTP id A2BD25BC3F; Wed, 28 Oct 2009 13:43:23 +0100 (CET) X-Virus-Scanned: by amavisd-new at uni-wuerzburg.de Received: from mail.physik.uni-wuerzburg.de (wthp192.physik.uni-wuerzburg.de [132.187.40.192]) by mailmaster.uni-wuerzburg.de (Postfix) with ESMTP id 78CB25D6C5; Wed, 28 Oct 2009 13:43:23 +0100 (CET) Received: from wep4035 ([132.187.37.35]) by mail.physik.uni-wuerzburg.de (Lotus Domino Release 8.0.2FP1HF244) with ESMTP id 2009102813432247-225089 ; Wed, 28 Oct 2009 13:43:22 +0100 Received: by wep4035 (sSMTP sendmail emulation); Wed, 28 Oct 2009 13:43:22 +0100 Date: Wed, 28 Oct 2009 13:43:22 +0100 From: Alexey Shuvaev To: a.agarwal@jach.hawaii.edu Message-ID: <20091028124322.GA22422@wep4035.physik.uni-wuerzburg.de> Mail-Followup-To: a.agarwal@jach.hawaii.edu, freebsd-current@freebsd.org References: <20091028082551.GA27015@uluhe.jach.hawaii.edu> Mime-Version: 1.0 In-Reply-To: <20091028082551.GA27015@uluhe.jach.hawaii.edu> User-Agent: Mutt/1.4.2.3i Organization: Universitaet Wuerzburg X-MIMETrack: Itemize by SMTP Server on domino1/uni-wuerzburg(Release 8.0.2FP1HF244 | April 7, 2009) at 10/28/2009 01:43:22 PM, Serialize by Router on domino1/uni-wuerzburg(Release 8.0.2FP1HF244 | April 7, 2009) at 10/28/2009 01:43:22 PM, Serialize complete at 10/28/2009 01:43:22 PM Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Cc: freebsd-current@freebsd.org Subject: Re: Installing RELEASE_8 alongside RELEASE_7 on respective slices X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Oct 2009 12:43:26 -0000 On Tue, Oct 27, 2009 at 10:25:51PM -1000, a.agarwal@jach.hawaii.edu wrote: > Hi there, > > (Please CC me as I am not currently subscribed with this address.) > > Currently I have RELEASE_7 installed on one slice, and have copied > the file structure from there to a different slice which currently > contains the RELEASE_8 source ... > > (Actual partition names may be different as I type them from > memory.) > > ad4s2a / base RELEASE_7 install /{,boot,root,usr} etc. > ad4s3a /current contains copy of / & RELEASE_8 source > ad4s4a /misc will contain what would have gone in > /{usr/ports,usr/local,home} > > ... swap partition is on ad4s2. > > While running RELEASE_7 system, I want to install RELEASE_8 such that > it puts/overwrites the files in /current. How do I go about that > without affecting / with RELEASE_7 installation? > One of the possible ways (compile from sources): Say, /path/to/src8 is path where your RELEASE_8 sources are and /path/to/root8 is path where you have mounted partition dedicated to RELEASE_8. cd /path/to/src8 make buildworld make buildkernel make DESTDIR=/path/to/root8 installkernel make DESTDIR=/path/to/root8 installworld make DESTDIR=/path/to/root8 distribution You have to manualy edit /path/to/root8/etc/fstab and figure out how will you boot new system. Also note that it is better to make new partition clean before the above mentioned procedure (you don't need the copy of RELEASE_7). It is also irrelevant where do you have RELEASE_8 sources. HTH, Alexey. From owner-freebsd-current@FreeBSD.ORG Wed Oct 28 14:38:49 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8B5E91065693 for ; Wed, 28 Oct 2009 14:38:49 +0000 (UTC) (envelope-from tom@tomjudge.com) Received: from tomjudge.vm.bytemark.co.uk (tomjudge.vm.bytemark.co.uk [80.68.91.100]) by mx1.freebsd.org (Postfix) with ESMTP id 4D1208FC23 for ; Wed, 28 Oct 2009 14:38:49 +0000 (UTC) Received: from localhost (localhost.localdomain [127.0.0.1]) by tomjudge.vm.bytemark.co.uk (Postfix) with ESMTP id 3D4DE48A7D for ; Wed, 28 Oct 2009 14:38:48 +0000 (GMT) X-Virus-Scanned: Debian amavisd-new at tomjudge.vm.bytemark.co.uk Received: from tomjudge.vm.bytemark.co.uk ([127.0.0.1]) by localhost (tomjudge.vm.bytemark.co.uk [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FKyoeYDnjU-C for ; Wed, 28 Oct 2009 14:38:43 +0000 (GMT) Received: from rita.nodomain (unknown [192.168.205.6]) by tomjudge.vm.bytemark.co.uk (Postfix) with ESMTP id 957D648A7C for ; Wed, 28 Oct 2009 14:38:42 +0000 (GMT) Message-ID: <4AE85740.8010003@tomjudge.com> Date: Wed, 28 Oct 2009 14:37:52 +0000 From: Tom Judge User-Agent: Thunderbird 2.0.0.23 (X11/20090822) MIME-Version: 1.0 To: freebsd-current@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: USB Attach Failures (USB_ERR_STALLED) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Oct 2009 14:38:49 -0000 Hi, As of yesterday (not yesterdays current) I have been having issues when booting my D630 on the dock and having the USB devices attach correctly, this was all working before the weekend and I have not changed anything. My src tree is at r197709. If I disconnect the usb keyboard and mouse then re attach them to the same ports on the dock they are detected correctly. Is this a known issue? Tom --- dmesg --- uhub0: 2 ports with 2 removable, self powered uhub1: 2 ports with 2 removable, self powered uhub3: 2 ports with 2 removable, self powered uhub4: 2 ports with 2 removable, self powered uhub5: 2 ports with 2 removable, self powered uhub2: 4 ports with 4 removable, self powered uhub6: 6 ports with 6 removable, self powered ugen2.2: at usbus2 uhub7: on usbus2 uhub7: 4 ports with 4 removable, self powered ugen5.2: at usbus5 uhub8: on usbus5 SMP: AP CPU #1 Launched! Root mount waiting for: usbus2 ugen2.3: <(null)> at usbus2 (disconnected) uhub_reattach_port:435: could not allocate new device! uhub8: 4 ports with 3 removable, self powered Root mount waiting for: usbus2 usb_alloc_device:1624: getting device descriptor at addr 3 failed, USB_ERR_STALLED! ugen5.3: at usbus5 usbd_req_re_enumerate:1553: getting device descriptor at addr 3 failed, USB_ERR_STALLED! Root mount waiting for: usbus2 usbd_req_re_enumerate:1553: getting device descriptor at addr 3 failed, USB_ERR_STALLED! ugen2.3: <(null)> at usbus2 (disconnected) uhub_reattach_port:435: could not allocate new device! ugen5.4: at usbus5 usb_alloc_device:1624: getting device descriptor at addr 3 failed, USB_ERR_STALLED! Root mount waiting for: usbus2 usbd_req_re_enumerate:1553: getting device descriptor at addr 3 failed, USB_ERR_STALLED! Root mount waiting for: usbus2 usbd_req_re_enumerate:1553: getting device descriptor at addr 3 failed, USB_ERR_STALLED! ugen2.3: <(null)> at usbus2 (disconnected) uhub_reattach_port:435: could not allocate new device! ugen2.3: at usbus2 uhub9: on usbus2 Root mount waiting for: usbus2 uhub9: 4 ports with 3 removable, self powered --- src version --- tj@rita '14:32:30' '/data/home/tj' > $ svn info /usr/src Path: /usr/src URL: http://svn.freebsd.org/base/head Repository Root: http://svn.freebsd.org/base Repository UUID: ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f Revision: 197709 Node Kind: directory Schedule: normal Last Changed Author: nyan Last Changed Rev: 197709 Last Changed Date: 2009-10-02 12:47:01 +0000 (Fri, 02 Oct 2009) From owner-freebsd-current@FreeBSD.ORG Wed Oct 28 14:45:20 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C7D7A1065696; Wed, 28 Oct 2009 14:45:20 +0000 (UTC) (envelope-from kensmith@buffalo.edu) Received: from localmailC.acsu.buffalo.edu (localmail.buffalo.edu [128.205.5.204]) by mx1.freebsd.org (Postfix) with ESMTP id 91DC68FC25; Wed, 28 Oct 2009 14:45:20 +0000 (UTC) Received: from localmailC.acsu.buffalo.edu (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 88C9591739; Wed, 28 Oct 2009 10:45:18 -0400 (EDT) Received: from localmailC.acsu.buffalo.edu (localhost [127.0.0.1]) by localmailC.acsu.buffalo.edu (Postfix) with ESMTP id 133F591734; Wed, 28 Oct 2009 10:45:17 -0400 (EDT) Received: from mweb2.acsu.buffalo.edu (mweb2.acsu.buffalo.edu [128.205.5.239]) by localmailC.acsu.buffalo.edu (Prefixe) with ESMTP id 0DB7791732; Wed, 28 Oct 2009 10:45:17 -0400 (EDT) Received: from [128.205.32.76] (bauer.cse.Buffalo.EDU [128.205.32.76]) by mweb2.acsu.buffalo.edu (Postfix) with ESMTP id F14B6203CD; Wed, 28 Oct 2009 10:45:16 -0400 (EDT) From: Ken Smith To: freebsd-current , freebsd-stable Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-RbAKYK74sc0NzEaHee2Y" Date: Wed, 28 Oct 2009 10:45:16 -0400 Message-Id: <1256741116.13258.61.camel@bauer.cse.buffalo.edu> Mime-Version: 1.0 X-Mailer: Evolution 2.24.5 FreeBSD GNOME Team Port X-PM-EL-Spam-Prob: : 8% Cc: Subject: 8.0-RC2 Available X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Oct 2009 14:45:21 -0000 --=-RbAKYK74sc0NzEaHee2Y Content-Type: text/plain Content-Transfer-Encoding: quoted-printable The second of the Release Candidates for the FreeBSD 8.0 release cycle is now available. At this point we feel most of what has been discovered during public testing that is feasible to fix as part of the release process has been addressed. So the current plan is to have 8.0-RC3 in about two weeks. Details about the current target schedule along with much more detail about the current status of the release is available here: http://wiki.freebsd.org/8.0TODO If you notice problems you can report them through the normal Gnats PR system or on the freebsd-current mailing list. I do cross-post announcements to freebsd-stable because this particular release is "about to become a stable branch" but when it comes to watching for issues related to the release most of the developers pay more attention to the freebsd-current list. ISO images for all supported architectures are available on the FTP sites, and a "memory stick" image is available for amd64/i386 architectures. For amd64/i386 architectures the cdrom and memstick images include the documentation packages but no other packages. The DVD image includes the packages that will probably be available on the official release media but is subject to change between now and release. For sparc64 there is now a livefs cdrom, disc1 includes the documentation packages, and the DVD image has the set of packages that currently build for sparc64 (which is a sub-set of the set provided for amd64/i386). If you are using csup/cvsup methods to update an older system the branch tag to use is RELENG_8_0. The freebsd-update(8) utility supports binary upgrades of i386 and amd64 systems running earlier FreeBSD releases. Systems running 7.0-RELEASE, 7.1-RELEASE, 7.2-RELEASE, 8.0-BETA1, 8.0-BETA2, 8.0-BETA3, 8.0-BETA4, or 8.0-RC1 can upgrade as follows: =20 # freebsd-update upgrade -r 8.0-RC2 =20 During this process, FreeBSD Update may ask the user to help by merging some configuration files or by confirming that the automatically performed merging was done correctly. Systems running 8.0-BETA3 may print the warning INDEX-OLD.all: Invalid arguments when downloading updates; this warning is a harmless bug (fixed in 8.0-BETA4) and can be safely ignored. # freebsd-update install =20 The system must be rebooted with the newly installed kernel before continui= ng. =20 # shutdown -r now =20 After rebooting, freebsd-update needs to be run again to install the new userland components: # freebsd-update install =20 At this point, users of systems being upgraded from FreeBSD 8.0-BETA2 or earlier will be prompted by freebsd-update to rebuild all third-party applications (e.g., ports installed from the ports tree) due to updates in system libraries. See: http://www.daemonology.net/blog/2009-07-11-freebsd-update-to-8.0-beta1.html for mode details. After updating installed third-party applications (and again, only if freebsd-update printed a message indicating that this was necessary), run freebsd-update again so that it can delete the old (no longer used) system libraries: # freebsd-update install =20 Finally, reboot into 8.0-RC2: =20 # shutdown -r now MD5/SHA256 checksums for the image files: MD5 (8.0-RC2-amd64-bootonly.iso) =3D d8b4a402dd510446d7bec239cb2a5add MD5 (8.0-RC2-amd64-disc1.iso) =3D 74ae55d888589d759339d736db4e4e15 MD5 (8.0-RC2-amd64-dvd1.iso) =3D c1772eb971b9c451ebbdd9e82b09b7b7 MD5 (8.0-RC2-amd64-livefs.iso) =3D ef34d58bc1c6c47acb69d8a772de364a MD5 (8.0-RC2-amd64-memstick.img) =3D 295815f1b358706a8f39f09f3240dde2 MD5 (8.0-RC2-i386-bootonly.iso) =3D 2d9e62645603a2d284c787f3505060fa MD5 (8.0-RC2-i386-disc1.iso) =3D 8883ed3b408b67a265d82467d0659ced MD5 (8.0-RC2-i386-dvd1.iso) =3D 484792f88bae31fca2846bc2a78d8e95 MD5 (8.0-RC2-i386-livefs.iso) =3D 7053f9ea329d4751c3361112d33b3caa MD5 (8.0-RC2-i386-memstick.img) =3D b6a703e47e184e2eef63defd60f11abe MD5 (8.0-RC2-ia64-bootonly.iso) =3D 803d1d48e4a7c52f028cdd9335f63e95 MD5 (8.0-RC2-ia64-disc1.iso) =3D eb0a6aea681ae605f1a291e17e92342c MD5 (8.0-RC2-ia64-disc2.iso) =3D 67471992168e3c93095dae45ae0be773 MD5 (8.0-RC2-ia64-disc3.iso) =3D 6a076b1abda6ff843b8e8745d8068906 MD5 (8.0-RC2-ia64-dvd1.iso) =3D caf585b43277c22d6b5da1725764eccb MD5 (8.0-RC2-ia64-livefs.iso) =3D 7c2251519fd99236af1d6bbda2606c3f MD5 (8.0-RC2-pc98-bootonly.iso) =3D 37bbc89727b0927b8075573133d0fb9f MD5 (8.0-RC2-pc98-disc1.iso) =3D 0d1f6a48ebcbac485df40f8825d54863 MD5 (8.0-RC2-pc98-livefs.iso) =3D 018d7f8d716e2a7a53f3263a4debef4d MD5 (8.0-RC2-powerpc-bootonly.iso) =3D b481aa9d1b66060ae21f427e4aa2a529 MD5 (8.0-RC2-powerpc-disc1.iso) =3D 0cc7590fe4a0933d54d0deecf9112129 MD5 (8.0-RC2-powerpc-disc2.iso) =3D e7a89d93be2bc8a69b54558c9d424c5c MD5 (8.0-RC2-powerpc-disc3.iso) =3D c549a90991122421dcb631d78ab8f312 MD5 (8.0-RC2-sparc64-bootonly.iso) =3D 3033c3b3c92eec90ad21b772b4ccd970 MD5 (8.0-RC2-sparc64-disc1.iso) =3D e4b3470481eb94baa2df115b85a23002 MD5 (8.0-RC2-sparc64-dvd1.iso) =3D a6571c2735c52dc8e5f83384e827c1ff SHA256 (8.0-RC2-amd64-bootonly.iso) =3D 0c72b0248a689df99b3aa76b7ed148b7bd7= 4a9de2577950231120ac4403bdb4c SHA256 (8.0-RC2-amd64-disc1.iso) =3D a20b72acf3990f6b4a71941c576d5dc395260a= 98287bdfe4455cbf15555015e0 SHA256 (8.0-RC2-amd64-dvd1.iso) =3D f29f6a65d08190d946d38412cc199b7ad3d001c= cd05e66b396cdb1339f45b3fd SHA256 (8.0-RC2-amd64-livefs.iso) =3D 59f3feb88ea35e8ec075b59ff1eeac8df36df= 219a375058966eab2b4deb1350a SHA256 (8.0-RC2-amd64-memstick.img) =3D 60a91e82223169fabf445b227f75cdc3495= 045a764285a0e7023bdf20478931a SHA256 (8.0-RC2-i386-bootonly.iso) =3D b160f47b2b7baa69acca8c5e5d45dccb8fa3= 582ade676f69b44638c956f92f38 SHA256 (8.0-RC2-i386-disc1.iso) =3D c7edabc1fe1429f396978b4699b41fff9e4a175= 74dfa2658499a6f9f2bd91a1d SHA256 (8.0-RC2-i386-dvd1.iso) =3D 34ae54a05ad5c0ac4a2d208edec95c218b0bf4e0= a2458c97317f2cbebe4ce93b SHA256 (8.0-RC2-i386-livefs.iso) =3D e58b2b922ee1ee8fb56eeac36fe5e8eb35d7c9= d7824535d770a7066faaafa8a4 SHA256 (8.0-RC2-i386-memstick.img) =3D aed885993e742a6c5ec17b4339ffab174492= 19e588d2e80457a0b7137d333f52 SHA256 (8.0-RC2-ia64-bootonly.iso) =3D 16967168e7eb1ea95d2aac1334d5046b307d= 06318613de329fc68fa65670e703 SHA256 (8.0-RC2-ia64-disc1.iso) =3D 6134adc5f124e397a5783a4d9ff8c94a3b942a0= 6e2682e489ff484c8a87ea8d3 SHA256 (8.0-RC2-ia64-disc2.iso) =3D a4b471b71da9d4a047d6dbbdd2029ec2ec3ac6e= 7ebf96d993ded7917b0b8649b SHA256 (8.0-RC2-ia64-disc3.iso) =3D 4e44fb8dd42bab1775318ba6608656739533dfb= 60bccd5800877e1d693dd67a6 SHA256 (8.0-RC2-ia64-dvd1.iso) =3D db586139a60465d125ab89adcf28283528d0d62d= d5ee6ef5dba6e90b0761107b SHA256 (8.0-RC2-ia64-livefs.iso) =3D 0a2d497a400166e4ea4a4191a92bb5d37959be= dc53b2dea04b35c0cd0681ee66 SHA256 (8.0-RC2-pc98-bootonly.iso) =3D 62f4af328fbb3660b49b4ca75158731de457= 781b41f6f1fd15f8cb58c8e2769d SHA256 (8.0-RC2-pc98-disc1.iso) =3D 5551baa1205ad356c87ccc7685241d463dd8a26= bde366fd8bdb4bde44188bf72 SHA256 (8.0-RC2-pc98-livefs.iso) =3D 2f195b71d73eaf4a76ac00522431e674f5a9b8= 272bb002c90c2c6d2a5491c4f5 SHA256 (8.0-RC2-powerpc-bootonly.iso) =3D d268f4cebd71bfbe7a6532270097b4934= f49da518a51754429448ef30bf57db0 SHA256 (8.0-RC2-powerpc-disc1.iso) =3D b847889e72d5134b7ac6bf06244e7c919639= d7d80a0001f6cfea5fc0c4c2847d SHA256 (8.0-RC2-powerpc-disc2.iso) =3D 2fe8a8f97821d2695b0f795eda62422433ea= e23dc1e6f5b7c38983e6c2431b25 SHA256 (8.0-RC2-powerpc-disc3.iso) =3D 24ccace776b897705ad10115287c9819bc33= 01aedaa4afd253addbc038178f0a SHA256 (8.0-RC2-sparc64-bootonly.iso) =3D ce24a908fce56afa6a7a29687d9fcc63f= fe724d59014851344349702a1df5fd2 SHA256 (8.0-RC2-sparc64-disc1.iso) =3D d4b3974421b52ed89699422d916039675824= 9ddd8f82fa12a0339cbf023cf32e SHA256 (8.0-RC2-sparc64-dvd1.iso) =3D 999f52fe73d32be3008eb5b289882d50eee35= f469e4bb122268dfacd2f1508f0 SHA256 (8.0-RC2-sparc64-livefs.iso) =3D 7e22429d82bce3c3b7e927a380c6ce136ce= 30811653fec94f369eef496810725 --=20 Ken Smith - From there to here, from here to | kensmith@buffalo.edu there, funny things are everywhere. | - Theodore Geisel | --=-RbAKYK74sc0NzEaHee2Y Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (FreeBSD) iEYEABECAAYFAkroWPQACgkQ/G14VSmup/bVfwCggwqBABp1O+Z62zTuXrIYLpre FlcAniRiMs9WzbfAV8/ENZuSyDOlxgmy =Dndp -----END PGP SIGNATURE----- --=-RbAKYK74sc0NzEaHee2Y-- From owner-freebsd-current@FreeBSD.ORG Wed Oct 28 15:01:18 2009 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6A7781065710 for ; Wed, 28 Oct 2009 15:01:18 +0000 (UTC) (envelope-from Johan@double-l.nl) Received: from smtp-vbr14.xs4all.nl (smtp-vbr14.xs4all.nl [194.109.24.34]) by mx1.freebsd.org (Postfix) with ESMTP id F34358FC1B for ; Wed, 28 Oct 2009 15:01:17 +0000 (UTC) Received: from w2003s01.double-l.local (double-l.xs4all.nl [80.126.205.144]) by smtp-vbr14.xs4all.nl (8.13.8/8.13.8) with ESMTP id n9SF12cp030267; Wed, 28 Oct 2009 16:01:13 +0100 (CET) (envelope-from Johan@double-l.nl) MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Content-class: urn:content-classes:message Date: Wed, 28 Oct 2009 16:01:01 +0100 Message-ID: <57200BF94E69E54880C9BB1AF714BBCBA57105@w2003s01.double-l.local> X-MimeOLE: Produced By Microsoft Exchange V6.5 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: 8.0-RC2 Available Thread-Index: AcpX3fEUKwpCi7inSVC/nPgJtv2ZqQAARSGA References: <1256741116.13258.61.camel@bauer.cse.buffalo.edu> From: "Johan Hendriks" To: "Ken Smith" X-Virus-Scanned: by XS4ALL Virus Scanner Cc: freebsd-current@FreeBSD.org Subject: RE: 8.0-RC2 Available X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Oct 2009 15:01:18 -0000 > > > > >Details about the current target schedule along with much more detail >about the current status of the release is available here: > > http://wiki.freebsd.org/8.0TODO > > > On the wiki i read under Branch status that CVS: RELENG_8_0 created is not done. I use RELENG_8_0 in my csup file it it works great, or do I have another version now? Regards, Johan No virus found in this outgoing message. Checked by AVG - www.avg.com=20 Version: 8.5.423 / Virus Database: 270.14.36/2465 - Release Date: 10/28/09 09:34:00 From owner-freebsd-current@FreeBSD.ORG Wed Oct 28 15:04:52 2009 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9D1BA106566B for ; Wed, 28 Oct 2009 15:04:52 +0000 (UTC) (envelope-from kensmith@buffalo.edu) Received: from localmailC.acsu.buffalo.edu (localmailC.acsu.buffalo.edu [128.205.5.204]) by mx1.freebsd.org (Postfix) with ESMTP id 679878FC1D for ; Wed, 28 Oct 2009 15:04:52 +0000 (UTC) Received: from localmailC.acsu.buffalo.edu (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 8CC195ED08; Wed, 28 Oct 2009 11:04:51 -0400 (EDT) Received: from localmailC.acsu.buffalo.edu (localhost [127.0.0.1]) by localmailC.acsu.buffalo.edu (Postfix) with ESMTP id CDCA15ED02; Wed, 28 Oct 2009 11:04:50 -0400 (EDT) Received: from mweb2.acsu.buffalo.edu (mweb2.acsu.buffalo.edu [128.205.5.239]) by localmailC.acsu.buffalo.edu (Prefixe) with ESMTP id C82FF5ECF2; Wed, 28 Oct 2009 11:04:50 -0400 (EDT) Received: from [128.205.32.76] (bauer.cse.Buffalo.EDU [128.205.32.76]) by mweb2.acsu.buffalo.edu (Postfix) with ESMTP id B5574203CD; Wed, 28 Oct 2009 11:04:50 -0400 (EDT) From: Ken Smith To: Johan Hendriks In-Reply-To: <57200BF94E69E54880C9BB1AF714BBCBA57105@w2003s01.double-l.local> References: <1256741116.13258.61.camel@bauer.cse.buffalo.edu> <57200BF94E69E54880C9BB1AF714BBCBA57105@w2003s01.double-l.local> Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-M2a6gBJG8wNFk6Nn49oT" Date: Wed, 28 Oct 2009 11:04:50 -0400 Message-Id: <1256742290.13258.63.camel@bauer.cse.buffalo.edu> Mime-Version: 1.0 X-Mailer: Evolution 2.24.5 FreeBSD GNOME Team Port X-PM-EL-Spam-Prob: : 8% Cc: freebsd-current@FreeBSD.org Subject: RE: 8.0-RC2 Available X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Oct 2009 15:04:52 -0000 --=-M2a6gBJG8wNFk6Nn49oT Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Wed, 2009-10-28 at 16:01 +0100, Johan Hendriks wrote: > > > > > > > > > >Details about the current target schedule along with much more detail > >about the current status of the release is available here: > > > > http://wiki.freebsd.org/8.0TODO > > > > > > >=20 > On the wiki i read under Branch status that CVS: RELENG_8_0 created is > not done. > I use RELENG_8_0 in my csup file it it works great, or do I have another > version now? >=20 > Regards, > Johan >=20 > No virus found in this outgoing message. > Checked by AVG - www.avg.com=20 > Version: 8.5.423 / Virus Database: 270.14.36/2465 - Release Date: > 10/28/09 09:34:00 >=20 >=20 I wanted to take care of getting the announcement email out before getting around to updating the wiki so the wiki is trailing behind a little bit. I'll take care of updating that shortly. Yes, RELENG_8_0 is what to use now. --=20 Ken Smith - From there to here, from here to | kensmith@buffalo.edu there, funny things are everywhere. | - Theodore Geisel | --=-M2a6gBJG8wNFk6Nn49oT Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (FreeBSD) iEYEABECAAYFAkroXYAACgkQ/G14VSmup/YNagCfSpwU8LQ+SpHxA2s7NhsZ1mnO NagAnjwVZ5CAuW7zkDvdZOp+BFbtiw8d =cvn5 -----END PGP SIGNATURE----- --=-M2a6gBJG8wNFk6Nn49oT-- From owner-freebsd-current@FreeBSD.ORG Wed Oct 28 13:41:40 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 27F82106568B for ; Wed, 28 Oct 2009 13:41:40 +0000 (UTC) (envelope-from a.agarwal@jach.hawaii.edu) Received: from mailhost.jach.hawaii.edu (mailhost.jach.HAWAII.EDU [128.171.90.17]) by mx1.freebsd.org (Postfix) with ESMTP id 07D1F8FC23 for ; Wed, 28 Oct 2009 13:41:39 +0000 (UTC) Date: Wed, 28 Oct 2009 03:41:38 -1000 From: a.agarwal@jach.hawaii.edu To: freebsd-current@freebsd.org Message-ID: <20091028134138.GA27425@uluhe.jach.hawaii.edu> References: <20091028082551.GA27015@uluhe.jach.hawaii.edu> <20091028124322.GA22422@wep4035.physik.uni-wuerzburg.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20091028124322.GA22422@wep4035.physik.uni-wuerzburg.de> X-Mailman-Approved-At: Wed, 28 Oct 2009 15:43:48 +0000 Subject: Re: Installing RELEASE_8 alongside RELEASE_7 on respective slices X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Oct 2009 13:41:40 -0000 Around 03.15am wrote 'Alexey Shuvaev' on fateful day of Oct 28, 2009 thusly in message <20091028124322.GA22422@wep4035.physik.uni-wuerzburg.de> ... > > On Tue, Oct 27, 2009 at 10:25:51PM -1000, a.agarwal@jach.hawaii.edu wrote: ... > > (Please CC me as I am not currently subscribed with this > > address.) > > > > Currently I have RELEASE_7 installed on one slice, and have > > copied the file structure from there to a different slice which > > currently contains the RELEASE_8 source ... ... > > ad4s2a / base RELEASE_7 install /{,boot,root,usr} etc. > > ad4s3a /current contains copy of / & RELEASE_8 source ... > > While running RELEASE_7 system, I want to install RELEASE_8 such > > that it puts/overwrites the files in /current. How do I go > > about that without affecting / with RELEASE_7 installation? > > > One of the possible ways Another way one of the private replies mentioned was ... by mounting devfs to /current, chroot and then do freebsd-update upgrade > (compile from sources): Say, /path/to/src8 is path where your > RELEASE_8 sources are and /path/to/root8 is path where you have > mounted partition dedicated to RELEASE_8. > > cd /path/to/src8 > make buildworld > make buildkernel > make DESTDIR=/path/to/root8 installkernel > make DESTDIR=/path/to/root8 installworld > make DESTDIR=/path/to/root8 distribution Ah, DESTDIR. I got a private reply which mentioned that; above expands on that. I might have missed the "make distribution" step. > You have to manualy edit /path/to/root8/etc/fstab and figure out > how will you boot new system. Yes; shouldn't be too hard to think of the mount points. I would just need to think about that. > Also note that it is better to make new partition clean before the > above mentioned procedure (you don't need the copy of RELEASE_7). > It is also irrelevant where do you have RELEASE_8 sources. I was loosely thinking that the plan might call for making /path/to/root8 (with RELEASE_7 copy) as the root mount point during bootup; then running the compilation steps there, /path/to/root7 possibly unmounted. Your suggestion simplifies a ton. > HTH, Indeed that does; thanks much. -- From owner-freebsd-current@FreeBSD.ORG Wed Oct 28 16:22:09 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 008A7106566B for ; Wed, 28 Oct 2009 16:22:09 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe12.swip.net [212.247.155.97]) by mx1.freebsd.org (Postfix) with ESMTP id 8AE318FC21 for ; Wed, 28 Oct 2009 16:22:07 +0000 (UTC) X-Cloudmark-Score: 0.000000 [] X-Cloudmark-Analysis: v=1.0 c=1 a=ct4AtyFzAYoA:10 a=MnI1ikcADjEx7bvsp0jZvQ==:17 a=WG6TwoNrQuXNO5vmVc8A:9 a=hEAqCbYxDVjdp1ckyQTzickaDXYA:4 Received: from [188.126.201.140] (account mc467741@c2i.net HELO laptop.adsl.tele2.no) by mailfe12.swip.net (CommuniGate Pro SMTP 5.2.16) with ESMTPA id 1143479708; Wed, 28 Oct 2009 17:22:04 +0100 From: Hans Petter Selasky To: freebsd-current@freebsd.org, Andrew Thompson Date: Wed, 28 Oct 2009 17:23:16 +0100 User-Agent: KMail/1.11.4 (FreeBSD/9.0-CURRENT; KDE/4.2.4; i386; ; ) References: <4AE85740.8010003@tomjudge.com> In-Reply-To: <4AE85740.8010003@tomjudge.com> X-Face: (%:6u[ldzJ`0qjD7sCkfdMmD*RxpOwEEQ+KWt[{J#x6ow~JO:,zwp.(t; @Aq :4:&nFCgDb8[3oIeTb^'",;u{5{}C9>"PuY\)!=#\u9SSM-nz8+SR~B\!qBv MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200910281723.17481.hselasky@c2i.net> Cc: Tom Judge Subject: Re: USB Attach Failures (USB_ERR_STALLED) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Oct 2009 16:22:09 -0000 On Wednesday 28 October 2009 15:37:52 Tom Judge wrote: > Hi, > > As of yesterday (not yesterdays current) I have been having issues when > booting my D630 on the dock and having the USB devices attach correctly, > this was all working before the weekend and I have not changed > anything. My src tree is at r197709. > > If I disconnect the usb keyboard and mouse then re attach them to the > same ports on the dock they are detected correctly. > > Is this a known issue? > > Tom Hi, Your issue is possibly related to some recent BIOS USB handover patches. Try disabling USB in the BIOS. Else I think Andrew has more details. --HPS From owner-freebsd-current@FreeBSD.ORG Wed Oct 28 17:16:25 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 94BDF1065694 for ; Wed, 28 Oct 2009 17:16:25 +0000 (UTC) (envelope-from ale@FreeBSD.org) Received: from andxor.it (relay.andxor.it [195.223.2.3]) by mx1.freebsd.org (Postfix) with SMTP id 2FFAE8FC39 for ; Wed, 28 Oct 2009 17:16:24 +0000 (UTC) Received: (qmail 62252 invoked from network); 28 Oct 2009 17:16:23 -0000 Received: from unknown (HELO ale.andxor.it) (192.168.2.5) by andxor.it with SMTP; 28 Oct 2009 17:16:23 -0000 Message-ID: <4AE87C66.6010908@FreeBSD.org> Date: Wed, 28 Oct 2009 18:16:22 +0100 From: Alex Dupre User-Agent: Thunderbird 2.0.0.22 (X11/20090624) MIME-Version: 1.0 To: freebsd-current@freebsd.org Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 7bit Subject: if_bridge and ipv6 link-local X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Oct 2009 17:16:25 -0000 Historically, ipv6 link-local addressess were not set for bridge interfaces. Is it still a problem with current if_bridge implementation that doesn't inherit the mac address by default? The current behaviour avoids using rtadvd on the bridge interface with the rc scripts. FWIW, I tried to manually set the link-local address and all other required aliases, started rtadvd, etc., and all seems to work correctly. -- Alex Dupre From owner-freebsd-current@FreeBSD.ORG Wed Oct 28 17:56:19 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B502C106566B for ; Wed, 28 Oct 2009 17:56:19 +0000 (UTC) (envelope-from jhs@berklix.com) Received: from tower.berklix.org (tower.berklix.org [83.236.223.114]) by mx1.freebsd.org (Postfix) with ESMTP id 41A638FC08 for ; Wed, 28 Oct 2009 17:56:18 +0000 (UTC) Received: from park.js.berklix.net (p549A3CF9.dip.t-dialin.net [84.154.60.249]) (authenticated bits=0) by tower.berklix.org (8.14.2/8.14.2) with ESMTP id n9SHuGTF036550; Wed, 28 Oct 2009 17:56:17 GMT (envelope-from jhs@berklix.com) Received: from fire.js.berklix.net (fire.js.berklix.net [192.168.91.41]) by park.js.berklix.net (8.13.8/8.13.8) with ESMTP id n9SHu62K010533; Wed, 28 Oct 2009 18:56:06 +0100 (CET) (envelope-from jhs@berklix.com) Received: from fire.js.berklix.net (localhost [127.0.0.1]) by fire.js.berklix.net (8.14.3/8.14.3) with ESMTP id n9SHt3hg026829; Wed, 28 Oct 2009 18:55:08 +0100 (CET) (envelope-from jhs@fire.js.berklix.net) Message-Id: <200910281755.n9SHt3hg026829@fire.js.berklix.net> To: aw1@stade.co.uk From: "Julian H. Stacey" Organization: http://www.berklix.com BSD Unix Linux Consultancy, Munich Germany User-agent: EXMH on FreeBSD http://www.berklix.com/free/ X-URL: http://www.berklix.com In-reply-to: Your message "Wed, 28 Oct 2009 08:58:51 GMT." <20091028085850.GA1670@swelter.hanley.stade.co.uk> Date: Wed, 28 Oct 2009 18:55:03 +0100 Sender: jhs@berklix.com Cc: freebsd-current@freebsd.org Subject: Re: dell 2950/ FreeBSD 8.0-RC2 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Oct 2009 17:56:19 -0000 Hi, > From: Adrian Wontroba Adrian Wontroba wrote: > On Tue, Oct 27, 2009 at 11:01:20PM +0100, Julian H. Stacey wrote: > > Puzzled ... I saw a mail ref to RC2 last night & checked ftp on .de > > & USA to download, but saw just saw RC1, now a night later I still > > see at Tue Oct 27 22:56:07 CET 2009 just ftp.freebsd.org Remote > > directory: /pub/FreeBSD/releases/i386/ISO-IMAGES/8.0 8.0-RC1-i386-* > > I guess your running from ?what? self compiled, & it hasnt hit ftp > > repo. yet. (I recall CVS too doesnt get those RC tags, that' just > > subversion I assume) > > Yes, RC2 hit svs/cvs a few days ago: Subversiion maybe (I dont have a local repository for that, But find /usr/cvs -type f | xargs grep RC1 shows no RC tags of sort Makefile,v symbols RELENG_7_2_0_RELEASE:1.341.2.7.2.1 So no local export with CVS & build here. No prob. Thanks Julian -- Julian Stacey: BSD Unix Linux C Sys Eng Consultants Munich http://berklix.com Mail plain text not quoted-printable, HTML or Base64: http://asciiribbon.org From owner-freebsd-current@FreeBSD.ORG Wed Oct 28 18:55:47 2009 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 450C51065676; Wed, 28 Oct 2009 18:55:47 +0000 (UTC) (envelope-from nork@ninth-nine.com) Received: from sakura.ninth-nine.com (unknown [IPv6:2001:2f0:104:80a1::25]) by mx1.freebsd.org (Postfix) with ESMTP id E6CC08FC0A; Wed, 28 Oct 2009 18:55:46 +0000 (UTC) Received: from nadesico.ninth-nine.com (ns1.ninth-nine.com [219.127.74.121] (may be forged)) (authenticated bits=0) by sakura.ninth-nine.com (8.14.3/8.14.3/NinthNine) with ESMTP id n9SItesj057501; Thu, 29 Oct 2009 03:55:45 +0900 (JST) (envelope-from nork@ninth-nine.com) Date: Thu, 29 Oct 2009 03:55:39 +0900 From: Norikatsu Shigemura To: Robert Noland Message-Id: <20091029035539.945aa7fb.nork@ninth-nine.com> In-Reply-To: <1256685555.2315.9.camel@balrog.2hip.net> References: <1256517106.2502.205.camel@balrog.2hip.net> <1256571299.2502.219.camel@balrog.2hip.net> <20091028071734.e92e8e49.nork@ninth-nine.com> <1256685555.2315.9.camel@balrog.2hip.net> X-Mailer: Sylpheed 2.7.1 (GTK+ 2.16.6; i386-portbld-freebsd8.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: freebsd-current@FreeBSD.org Subject: Re: GPT boot with ZFS RAIDZ "ZFS: i/o error - all block copies unavailable" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Oct 2009 18:55:47 -0000 Hi rnoland. On Tue, 27 Oct 2009 18:19:15 -0500 Robert Noland wrote: > > 2. reduce AVAIL < 10% with creating dummy file like ... > > $ dd if=/dev/zero of=$HOME/DUMMY.FILE bs=1m count=5632 > > 5632+0 records in > > 5632+0 records out > > 5905580032 bytes transferred in 49.822200 secs (118533104 bytes/sec) > > $ zpool list > > NAME SIZE USED AVAIL CAP HEALTH ALTROOT > > tank 59.5G 53.9G 5.61G 90% ONLINE - > > 3. cd /boot/; cp -pr kernel kernel.err > > In this time, if reboot, we can get boot time error. > > 4. rm $HOME/DUMMY.FILE, and reboot > > 5. boot kernel.err on new-loader. > > I can get "ZFS: gang block detected!" message and overrun:D. > Ok, so does it still boot? Or do you still get an error? After reboot: OK: boot kernel NG: boot kernel.err Sorry, kernel.err is ganged kernel. I should be called as kernel.gang. From owner-freebsd-current@FreeBSD.ORG Wed Oct 28 19:01:44 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 56672106566C; Wed, 28 Oct 2009 19:01:44 +0000 (UTC) (envelope-from alteriks@gmail.com) Received: from mail-bw0-f213.google.com (mail-bw0-f213.google.com [209.85.218.213]) by mx1.freebsd.org (Postfix) with ESMTP id B18BB8FC0C; Wed, 28 Oct 2009 19:01:43 +0000 (UTC) Received: by bwz5 with SMTP id 5so1380899bwz.3 for ; Wed, 28 Oct 2009 12:01:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=UUGG0wNpBINGvvxevQDWVFSto1dyoPb7vuIyNGOoNNI=; b=P4PisQQaSYJaSPBBvhor0wXOnuUVuE0QmWUxhsin98hXWhQZ+D2Lwup0qoAuuO95M4 fsZ9PPK7OVFa4REo71jv67GJM7JRrjuFHatGkq7CxyUrXyFO3tRxTO1C+KNvKhfcIgT1 saqCnSLCmLk9hnrMaApFEBskjdRLIn1VKptJ4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=Pwa5sd2K5alEHjM3jOrSpO1UoPFGX7QGdAZYxNmvUmpjkEMDBo432fcTb/uI3Td35y 6UN08z9wwQ7kTX5bmGVkZQDkgkXVNXMPg9Hw+FllGNJcSlvElBXo38CTlWkbDkx9KHXk unktrLbhI7pPxIyYPFxKDUaMTt02qKUKvGd38= MIME-Version: 1.0 Received: by 10.204.25.152 with SMTP id z24mr1841511bkb.44.1256754856055; Wed, 28 Oct 2009 11:34:16 -0700 (PDT) In-Reply-To: <200910281225.53591.alteriks@gmail.com> References: <200910280842.50919.alteriks@gmail.com> <1256728210.2315.21.camel@balrog.2hip.net> <200910281225.53591.alteriks@gmail.com> Date: Wed, 28 Oct 2009 19:34:16 +0100 Message-ID: <684e57ec0910281134q568bb2c2s9faca5d924efaba3@mail.gmail.com> From: Krzysztof Dajka To: Robert Noland Content-Type: text/plain; charset=UTF-8 Cc: freebsd-current@freebsd.org Subject: Re: GPT boot with ZFS RAIDZ "ZFS: i/o error - all block copies unavailable" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Oct 2009 19:01:44 -0000 I managed to boot FreeBSD with raidz1 on gpt drives on my workstation. Well I didn't quite finished booting yet... But from the beginning. I tried to install FreeBSD once again instead of raidz2 I chose raidz1, but it's not the answer. I think that It could be related to what Norikatsu Shigemura reproduced http://lists.freebsd.org/pipermail/freebsd-current/2009-October/012935.html When I used gpart to create my boot slices on 3 drives I increased size of that slice to 400 sectors. Now my system boots and >ZFS: i/o error - all block copies unavailable error is missing. But I haven't really finish boot part. Now I'm getting: Trying to mount root from zfs:zroot ROOT MOUNT ERROR So I'll have to figure out what went wrong during fixit installation, maybe some typo On 10/28/09, alteriks@gmail.com wrote: > On Wednesday 28 October 2009 12:10:10 you wrote: >> I think that is unlikely. If you type status at this point, does it >> show all of your drives ONLINE? >> > Yes, they we're online. > >>>ZFS: can't read MOS > I'm not quite sure about this line because I copy/pasted from Radek's post. > I > will check it and post later when I'll get home. > From owner-freebsd-current@FreeBSD.ORG Wed Oct 28 19:04:24 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4313C1065696; Wed, 28 Oct 2009 19:04:24 +0000 (UTC) (envelope-from alteriks@gmail.com) Received: from mail-bw0-f213.google.com (mail-bw0-f213.google.com [209.85.218.213]) by mx1.freebsd.org (Postfix) with ESMTP id 9C3518FC17; Wed, 28 Oct 2009 19:04:23 +0000 (UTC) Received: by bwz5 with SMTP id 5so1383706bwz.3 for ; Wed, 28 Oct 2009 12:04:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=Ae0FvcbT9WdAZB8kl2i3AzT37REPJxkIn7RXMU4oe5Y=; b=kQCDhXBA2Gk9X9rv5FZOUkYaEm/ErFQj54r6T6HCXzyOFtKRaG6sJbnaTC0LNyRW54 Ylac3lSI0z5lyppBOBWX+ckzEBXL46i9BGvDjMYr8vPk+C0kk5wDnm3XMKk8saLr8ef5 VUlRZG2i3ySKHYEYUAYXBnH7WF8HWM0xHb7mA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=VkzYPbF7ee4bqGrBAQzqRvZXqjWArlcXGf8sCCom24p+lCrWdPhK048YXBQ83e6VTL rA1qR3/rOKENukf2iUZH2Pnp9QMq5R4b8BQ0IeA5jLjda8B41bNHmrSrZY7Mw/EhVFTH nxxQGgZ1syEVtrdfDbXupyVARR+pn4M5ClDNo= MIME-Version: 1.0 Received: by 10.204.10.2 with SMTP id n2mr923047bkn.91.1256754721441; Wed, 28 Oct 2009 11:32:01 -0700 (PDT) In-Reply-To: <200910281225.53591.alteriks@gmail.com> References: <200910280842.50919.alteriks@gmail.com> <1256728210.2315.21.camel@balrog.2hip.net> <200910281225.53591.alteriks@gmail.com> Date: Wed, 28 Oct 2009 19:32:01 +0100 Message-ID: <684e57ec0910281132i7be34062te6ae806b4e634f60@mail.gmail.com> From: Krzysztof Dajka To: Robert Noland Content-Type: text/plain; charset=UTF-8 Cc: freebsd-current@freebsd.org Subject: Re: GPT boot with ZFS RAIDZ "ZFS: i/o error - all block copies unavailable" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Oct 2009 19:04:24 -0000 I managed to boot FreeBSD with raidz1 on gpt drives on my workstation. Well I didn't quite finished booting yet... But from the beginning. I tried to install FreeBSD once again instead of raidz2 I chose raidz1, but it's not the answer. I think that When I used gpart to create my boot slices on 3 drives I increased size of that slice to 400 sectors. Now my system boots and >ZFS: i/o error - all block copies unavailable error is missing. But I haven't really finish boot part. Now I'm getting: Trying to mount root from zfs:zroot ROOT MOUNT ERROR So I'll have to figure out what went wrong during fixit installation, maybe some typo On 10/28/09, alteriks@gmail.com wrote: > On Wednesday 28 October 2009 12:10:10 you wrote: >> I think that is unlikely. If you type status at this point, does it >> show all of your drives ONLINE? >> > Yes, they we're online. > >>>ZFS: can't read MOS > I'm not quite sure about this line because I copy/pasted from Radek's post. > I > will check it and post later when I'll get home. > From owner-freebsd-current@FreeBSD.ORG Wed Oct 28 20:11:08 2009 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4870C10656AA for ; Wed, 28 Oct 2009 20:11:08 +0000 (UTC) (envelope-from dlt@mebtel.net) Received: from mail940c35.nsolutionszone.com (mail940c35.nsolutionszone.com [209.235.152.130]) by mx1.freebsd.org (Postfix) with ESMTP id F083B8FC1B for ; Wed, 28 Oct 2009 20:11:07 +0000 (UTC) X-POP-User: dlt.mebtel.net Received: from localhost (66-79-79-178.dsl.mebtel.net [66.79.79.178]) by mail940c35.nsolutionszone.com (8.13.6/8.13.1) with ESMTP id n9SHtmAB011524 for ; Wed, 28 Oct 2009 17:55:49 GMT Date: Wed, 28 Oct 2009 13:55:47 -0400 From: Derek Tattersall To: current@FreeBSD.org Message-ID: <20091028175547.GA91758@oriental.arm.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.20 (2009-06-14) Cc: Subject: Odd behavior at end of file X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: dlt@mebtel.net List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Oct 2009 20:11:08 -0000 Using prts/sysutils/pwsafe to maintain and display the encrypted database of password and user IDs that I keep on a flash drive, my current system gives the following messages after printing the last entry: terminate called after throwing an instance of 'ExitEx' Abort trap: 6 (core dumped) [Exit 134 (SIGABRT)] However 7.2 - STABLE and 8.0 - RC2 system don't exhibit this behavior. I'm at a loss to know where to begin on this one. Does anyone have any ideas? -- Best regards, Derek Tattersall dlt@mebtel.net dlt666@yahoo.com dtatters@gmail.com From owner-freebsd-current@FreeBSD.ORG Wed Oct 28 20:13:03 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5F7851065695 for ; Wed, 28 Oct 2009 20:13:03 +0000 (UTC) (envelope-from alteriks@gmail.com) Received: from mail-bw0-f209.google.com (mail-bw0-f209.google.com [209.85.218.209]) by mx1.freebsd.org (Postfix) with ESMTP id D9D648FC12 for ; Wed, 28 Oct 2009 20:13:02 +0000 (UTC) Received: by bwz1 with SMTP id 1so1547221bwz.13 for ; Wed, 28 Oct 2009 13:13:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type; bh=IY9WjsoFo3XX2Ag7EqH+fdnX4YaoREyZRg6KrOMXgUo=; b=dcLecw3JCFQrNdL1bXBryts7r90DIZTl3EInOoL/33RUuvdU0wI54ZvxUOOoCqtmcO 58x2zjtiZU60c55oXRpjnsqpYqY39YwiZvLu2bz//ev+BD39IqsnUEIwm4BXKNw9saAg cDSr+yW40xJ3w+EIDm3UWbiUhbIQz7wiGjQFc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=hYz/LojO83fGg3gBGSOBWkCqncrXMEcsYsUrULuknAdRdB5HvuSQTtkF5YTcC0ItXQ rbn0eYy8PDk3/HPcPQX5fPxVue436PBcFNcVHDC9Pn01ITbfT2gptyKnTcXIAszFglqf QnFfHt9+Cg8d2/nwfeY43Wser8Kz6zKkBaOAA= MIME-Version: 1.0 Received: by 10.204.151.210 with SMTP id d18mr5628284bkw.203.1256760781603; Wed, 28 Oct 2009 13:13:01 -0700 (PDT) In-Reply-To: <20091029035539.945aa7fb.nork@ninth-nine.com> References: <1256517106.2502.205.camel@balrog.2hip.net> <1256571299.2502.219.camel@balrog.2hip.net> <20091028071734.e92e8e49.nork@ninth-nine.com> <1256685555.2315.9.camel@balrog.2hip.net> <20091029035539.945aa7fb.nork@ninth-nine.com> Date: Wed, 28 Oct 2009 21:13:01 +0100 Message-ID: <684e57ec0910281313r6e9ac8d7x24a39035be6db888@mail.gmail.com> From: Krzysztof Dajka To: freebsd-current@freebsd.org Content-Type: text/plain; charset=UTF-8 Subject: Re: GPT boot with ZFS RAIDZ "ZFS: i/o error - all block copies unavailable" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Oct 2009 20:13:03 -0000 I still can't boot. I don't know whether I missed it in first time, but I'm getting >ZFS: i/o error - all block copies unavailable x6 before seeing boot manager. I tried booting with verbose option, but there was only laconic >Trying to mount root from zfs:zroot >ROOT MOUNT ERROR When I execute lsdev I'm getting .... disk devices: disk0: BIOS drive C: disk0p1: FreeBSD boot disk0p2: FreeBSD swap disk0p3: FreeBSD ZFS disk1: BIOS drive D: disk1p1: FreeBSD boot disk1p2: FreeBSD swap disk1p3: FreeBSD ZFS disk2: BIOS drive E: disk2p1: FreeBSD boot disk2p2: FreeBSD swap disk2p3: FreeBSD ZFS pxe devices: zfs devices: zfs0: zroot I can also do `ls` and I can browse whole zroot, and everything seems to be there. At least for the boot loader. From owner-freebsd-current@FreeBSD.ORG Wed Oct 28 20:25:16 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 93003106568D for ; Wed, 28 Oct 2009 20:25:16 +0000 (UTC) (envelope-from rnoland@FreeBSD.org) Received: from gizmo.2hip.net (gizmo.2hip.net [64.74.207.195]) by mx1.freebsd.org (Postfix) with ESMTP id 405848FC2A for ; Wed, 28 Oct 2009 20:25:15 +0000 (UTC) Received: from [192.168.1.4] (adsl-150-102-19.bna.bellsouth.net [72.150.102.19]) (authenticated bits=0) by gizmo.2hip.net (8.14.3/8.14.3) with ESMTP id n9SKP9Iq085654 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Wed, 28 Oct 2009 16:25:12 -0400 (EDT) (envelope-from rnoland@FreeBSD.org) From: Robert Noland To: Krzysztof Dajka In-Reply-To: <684e57ec0910281132i7be34062te6ae806b4e634f60@mail.gmail.com> References: <200910280842.50919.alteriks@gmail.com> <1256728210.2315.21.camel@balrog.2hip.net> <200910281225.53591.alteriks@gmail.com> <684e57ec0910281132i7be34062te6ae806b4e634f60@mail.gmail.com> Content-Type: text/plain Organization: FreeBSD Date: Wed, 28 Oct 2009 15:25:04 -0500 Message-Id: <1256761504.2315.27.camel@balrog.2hip.net> Mime-Version: 1.0 X-Mailer: Evolution 2.26.3 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-1.7 required=5.0 tests=AWL,BAYES_00, RCVD_IN_SORBS_DUL, RDNS_DYNAMIC, SPF_SOFTFAIL autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on gizmo.2hip.net Cc: freebsd-current@freebsd.org Subject: Re: GPT boot with ZFS RAIDZ "ZFS: i/o error - all block copies unavailable" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Oct 2009 20:25:16 -0000 On Wed, 2009-10-28 at 19:32 +0100, Krzysztof Dajka wrote: > I managed to boot FreeBSD with raidz1 on gpt drives on my workstation. > Well I didn't quite finished booting yet... > But from the beginning. > I tried to install FreeBSD once again instead of raidz2 I chose > raidz1, but it's not the answer. I think that > When I used gpart to create my boot slices on 3 drives I increased > size of that slice to 400 sectors. Now my system boots and if you mean the freebsd-boot partition, that isn't part of zfs. That is just an empty partition to hold gptzfsboot. So, that isn't relevant. This does work for me... I still haven't been able to produce a non-working system. Other than the case where the BIOS doesn't pick up all the drives. I've built booting systems with single and multiple root devices as well as raidz1 or raidz2. I'm not saying that there isn't an issue, just that I haven't been able find a failure that I can reproduce. robert. > >ZFS: i/o error - all block copies unavailable > error is missing. > But I haven't really finish boot part. > Now I'm getting: > Trying to mount root from zfs:zroot > ROOT MOUNT ERROR > > So I'll have to figure out what went wrong during fixit installation, > maybe some typo > > On 10/28/09, alteriks@gmail.com wrote: > > On Wednesday 28 October 2009 12:10:10 you wrote: > >> I think that is unlikely. If you type status at this point, does it > >> show all of your drives ONLINE? > >> > > Yes, they we're online. > > > >>>ZFS: can't read MOS > > I'm not quite sure about this line because I copy/pasted from Radek's post. > > I > > will check it and post later when I'll get home. > > -- Robert Noland FreeBSD From owner-freebsd-current@FreeBSD.ORG Wed Oct 28 20:31:25 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B21B51065670; Wed, 28 Oct 2009 20:31:25 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from esa-annu.mail.uoguelph.ca (esa-annu.mail.uoguelph.ca [131.104.91.36]) by mx1.freebsd.org (Postfix) with ESMTP id 390798FC1A; Wed, 28 Oct 2009 20:31:24 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAKdG6EqDaFvG/2dsb2JhbADbE4Q/BIFh X-IronPort-AV: E=Sophos;i="4.44,641,1249272000"; d="scan'208";a="51586191" Received: from amazon.cs.uoguelph.ca ([131.104.91.198]) by esa-annu-pri.mail.uoguelph.ca with ESMTP; 28 Oct 2009 16:31:24 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by amazon.cs.uoguelph.ca (Postfix) with ESMTP id 287472100BD; Wed, 28 Oct 2009 16:31:24 -0400 (EDT) X-Virus-Scanned: amavisd-new at amazon.cs.uoguelph.ca Received: from amazon.cs.uoguelph.ca ([127.0.0.1]) by localhost (amazon.cs.uoguelph.ca [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0+LaL0L1LktN; Wed, 28 Oct 2009 16:31:20 -0400 (EDT) Received: from muncher.cs.uoguelph.ca (muncher.cs.uoguelph.ca [131.104.91.102]) by amazon.cs.uoguelph.ca (Postfix) with ESMTP id 5029F210192; Wed, 28 Oct 2009 16:31:20 -0400 (EDT) Received: from localhost (rmacklem@localhost) by muncher.cs.uoguelph.ca (8.11.7p3+Sun/8.11.6) with ESMTP id n9SKcRo21396; Wed, 28 Oct 2009 16:38:28 -0400 (EDT) X-Authentication-Warning: muncher.cs.uoguelph.ca: rmacklem owned process doing -bs Date: Wed, 28 Oct 2009 16:38:27 -0400 (EDT) From: Rick Macklem X-X-Sender: rmacklem@muncher.cs.uoguelph.ca To: Olaf Seibert In-Reply-To: <20091027164159.GU841@twoquid.cs.ru.nl> Message-ID: References: <20091027164159.GU841@twoquid.cs.ru.nl> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: dfr@freebsd.org, freebsd-current@freebsd.org, freebsd-stable@freebsd.org Subject: Re: 8.0-RC1 NFS client timeout issue X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Oct 2009 20:31:25 -0000 First off, I know that cross posting is evil, but I wanted to try and make sure developers saw it. On Tue, 27 Oct 2009, Olaf Seibert wrote: > I see an annoying behaviour with NFS over TCP. It happens both with nfs > and newnfs. This is with FreeBSD/amd64 8.0-RC1 as client. The server is > some Linux or perhaps Solaris, I'm not entirely sure. > > After trying to find something in packet traces, I think I have found > something. > > The scenario seems to be as follows. Sorry for the width of the lines. > > > No. Time Source Destination Protocol Info > 2296 2992.216855 xxx.xxx.31.43 xxx.xxx.16.142 NFS V3 LOOKUP Call (Reply In 2297), DH:0x3819da36/w > 2297 2992.217107 xxx.xxx.16.142 xxx.xxx.31.43 NFS V3 LOOKUP Reply (Call In 2296) Error:NFS3ERR_NOENT > 2298 2992.217141 xxx.xxx.31.43 xxx.xxx.16.142 NFS V3 LOOKUP Call (Reply In 2299), DH:0x170cb16a/bin > 2299 2992.217334 xxx.xxx.16.142 xxx.xxx.31.43 NFS V3 LOOKUP Reply (Call In 2298), FH:0x61b8eb12 > 2300 2992.217361 xxx.xxx.31.43 xxx.xxx.16.142 NFS V3 ACCESS Call (Reply In 2301), FH:0x61b8eb12 > 2301 2992.217582 xxx.xxx.16.142 xxx.xxx.31.43 NFS V3 ACCESS Reply (Call In 2300) > 2302 2992.217605 xxx.xxx.31.43 xxx.xxx.16.142 NFS V3 LOOKUP Call (Reply In 2303), DH:0x61b8eb12/w > 2303 2992.217860 xxx.xxx.16.142 xxx.xxx.31.43 NFS V3 LOOKUP Reply (Call In 2302) Error:NFS3ERR_NOENT > 2304 2992.318770 xxx.xxx.31.43 xxx.xxx.16.142 TCP 934 > nfs [ACK] Seq=238293 Ack=230289 Win=8192 Len=0 TSV=86492342 TSER=12393434 > 2306 3011.537520 xxx.xxx.16.142 xxx.xxx.31.43 NFS V3 GETATTR Reply (Call In 2305) Directory mode:2755 uid:4100 gid:4100 > 2307 3011.637744 xxx.xxx.31.43 xxx.xxx.16.142 TCP 934 > nfs [ACK] Seq=238429 Ack=230405 Win=8192 Len=0 TSV=86511662 TSER=12395366 > 2308 3371.534980 xxx.xxx.16.142 xxx.xxx.31.43 TCP nfs > 934 [FIN, ACK] Seq=230405 Ack=238429 Win=49232 Len=0 TSV=12431366 TSER=86511662 > > The server decides, for whatever reason, to terminate the > connection and sends a FIN. > > 2309 3371.535018 xxx.xxx.31.43 xxx.xxx.16.142 TCP 934 > nfs [ACK] Seq=238429 Ack=230406 Win=8192 Len=0 TSV=86871578 TSER=12431366 > > Client acknowledges this, > > 2310 3375.379693 xxx.xxx.31.43 xxx.xxx.16.142 NFS V3 ACCESS Call, FH:0x008002a2 > > but tries to sneak in another call anyway. [A] > Probably not the best behaviour, but I think it is technically allowed by TCP. (My TCP is very rusty, but I think the socket should be in TCPS_CLOSE_WAIT at this point and the BSD code will have called socantrcvmore(), but not socantsndmore().) > 2311 3375.474788 xxx.xxx.16.142 xxx.xxx.31.43 TCP nfs > 934 [ACK] Seq=230406 Ack=238569 Win=49232 Len=0 TSV=12431760 TSER=86875423 > > Server ACKs but doesn't send anything else... [B] > > Time passes... > This is where it seems interesting. It looks to me like the socket upcall for receiving the FIN would have happened before this point, setting the ct_error.re_status to RPC_CANTRECV, but the code in clnt_vc_call() doesn't check for this. (It does check for it happening during and after the sosend(), but not before it, from what I can see.) > > [B] would be a bug of the server in my opinion. If it ACKs a call, it > should send a reply. And if it can't, it shouldn't. > I'll leave this one for the TCP wizzards. I'm not sure what the correct behaviour is when data is received on a connection. (I think it is waiting for a FIN from the client side at this point.) If you could try the following patch and see if it helps, that would be appreciated, rick ps: I'll try to reproduce the situation here, but I'm not sure if I can. --- rpc/clnt_vc.c.sav 2009-10-28 15:44:20.000000000 -0400 +++ rpc/clnt_vc.c 2009-10-28 15:49:57.000000000 -0400 @@ -413,6 +413,19 @@ cr->cr_xid = xid; mtx_lock(&ct->ct_lock); + /* + * Check to see if the other end has already started to close down + * the connection. If it happens after this point, it will be + * detected below, when cr->cr_error is checked. + */ + if (ct->ct_error.re_status == RPC_CANTRECV) { + if (errp != &ct->ct_error) { + errp->re_errno = ct->ct_error.re_errno; + errp->re_status = RPC_CANTRECV; + } + stat = RPC_CANTRECV; + goto out; + } TAILQ_INSERT_TAIL(&ct->ct_pending, cr, cr_link); mtx_unlock(&ct->ct_lock); From owner-freebsd-current@FreeBSD.ORG Wed Oct 28 20:43:15 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7B0BD106566C for ; Wed, 28 Oct 2009 20:43:15 +0000 (UTC) (envelope-from rnoland@FreeBSD.org) Received: from gizmo.2hip.net (gizmo.2hip.net [64.74.207.195]) by mx1.freebsd.org (Postfix) with ESMTP id 265508FC1A for ; Wed, 28 Oct 2009 20:43:14 +0000 (UTC) Received: from [192.168.1.4] (adsl-150-102-19.bna.bellsouth.net [72.150.102.19]) (authenticated bits=0) by gizmo.2hip.net (8.14.3/8.14.3) with ESMTP id n9SKhCWk085738 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Wed, 28 Oct 2009 16:43:13 -0400 (EDT) (envelope-from rnoland@FreeBSD.org) From: Robert Noland To: Krzysztof Dajka In-Reply-To: <684e57ec0910281313r6e9ac8d7x24a39035be6db888@mail.gmail.com> References: <1256517106.2502.205.camel@balrog.2hip.net> <1256571299.2502.219.camel@balrog.2hip.net> <20091028071734.e92e8e49.nork@ninth-nine.com> <1256685555.2315.9.camel@balrog.2hip.net> <20091029035539.945aa7fb.nork@ninth-nine.com> <684e57ec0910281313r6e9ac8d7x24a39035be6db888@mail.gmail.com> Content-Type: text/plain Organization: FreeBSD Date: Wed, 28 Oct 2009 15:43:07 -0500 Message-Id: <1256762587.2315.29.camel@balrog.2hip.net> Mime-Version: 1.0 X-Mailer: Evolution 2.26.3 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-1.8 required=5.0 tests=AWL,BAYES_00, RCVD_IN_SORBS_DUL, RDNS_DYNAMIC, SPF_SOFTFAIL autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on gizmo.2hip.net Cc: freebsd-current@freebsd.org Subject: Re: GPT boot with ZFS RAIDZ "ZFS: i/o error - all block copies unavailable" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Oct 2009 20:43:15 -0000 On Wed, 2009-10-28 at 21:13 +0100, Krzysztof Dajka wrote: > I still can't boot. I don't know whether I missed it in first time, > but I'm getting > >ZFS: i/o error - all block copies unavailable > x6 before seeing boot manager. I tried booting with verbose option, > but there was only laconic If you hit a key very early then you will land in boot2, where you can type "status" and it will list the zfs pool. robert. > >Trying to mount root from zfs:zroot > >ROOT MOUNT ERROR > > When I execute lsdev I'm getting > .... > disk devices: > disk0: BIOS drive C: > disk0p1: FreeBSD boot > disk0p2: FreeBSD swap > disk0p3: FreeBSD ZFS > disk1: BIOS drive D: > disk1p1: FreeBSD boot > disk1p2: FreeBSD swap > disk1p3: FreeBSD ZFS > disk2: BIOS drive E: > disk2p1: FreeBSD boot > disk2p2: FreeBSD swap > disk2p3: FreeBSD ZFS > pxe devices: > zfs devices: > zfs0: zroot > > I can also do `ls` and I can browse whole zroot, and everything seems > to be there. At least for the boot loader. > _______________________________________________ > 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" -- Robert Noland FreeBSD From owner-freebsd-current@FreeBSD.ORG Wed Oct 28 22:25:39 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CD089106566C for ; Wed, 28 Oct 2009 22:25:39 +0000 (UTC) (envelope-from sfourman@gmail.com) Received: from mail-pw0-f44.google.com (mail-pw0-f44.google.com [209.85.160.44]) by mx1.freebsd.org (Postfix) with ESMTP id A80B58FC20 for ; Wed, 28 Oct 2009 22:25:39 +0000 (UTC) Received: by pwj8 with SMTP id 8so1140562pwj.3 for ; Wed, 28 Oct 2009 15:25:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:content-type; bh=BMwsUGNN4GASneNSxwW3nCtg+4d/ecXTMKR7bAgV3pU=; b=mHPFKV6NT47rZs53sgxhlnyOx0D5M2fSCS2AuQGsVU4dFWlLf/Wqmtg/SUpk0pBiyn HBJqpnkSS3RO6y/83ls+a3GmSPdBu8x/ZJ6P/Ra8+Sqp6fWKyLd3SV94mLslQxiscYDw eHE6QEE/7SBXmzskU0t7nNajr4Iye0QpECUto= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=G7NxkJigj2jUVLTP0iA3GhEctRoiF6PtASRVTN2N9Mfkc5M4EZMnOo8d6mjQW3Ktdj JDiWfXcLkyy942n7PeOlPX+G2hCcfihJoEuzyLrqRBhNqsPXzQJJI8n8wuBEKpVtCtmO pxf0oOo4Bs0afIIva/dXkq6zYORK4xqhIyaiQ= MIME-Version: 1.0 Received: by 10.142.55.20 with SMTP id d20mr71308wfa.37.1256768739274; Wed, 28 Oct 2009 15:25:39 -0700 (PDT) Date: Wed, 28 Oct 2009 17:25:39 -0500 Message-ID: <11167f520910281525s472e115era377fffd769cc9e8@mail.gmail.com> From: "Sam Fourman Jr." To: FreeBSD Current Content-Type: text/plain; charset=ISO-8859-1 Subject: 8.0 RC2 amd64 compile X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Oct 2009 22:25:40 -0000 hello list, What am i doing wrong? I can not get FreeBSD 8.0RC2 amd64 to compile (using 8.0 RC1) I am using a GENERIC kernel with VIMAGE added. here is a cut and paste from my console r/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/spa.c /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/spa_config.c /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/spa_errlog.c /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/spa_history.c /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/spa_misc.c /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/space_map.c /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/txg.c /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/uberblock.c /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/unique.c /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/vdev.c /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/vdev_cache.c /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/vdev_file.c /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/vdev_label.c /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/vdev_mirror.c /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/vdev_missing.c /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/vdev_queue.c /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/vdev_raidz.c /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/vdev_root.c /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/zap.c /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/zap_leaf.c /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/zap_micro.c /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_byteswap.c /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_fm.c /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_fuid.c /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_znode.c /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/zil.c /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/zio.c /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/zio_checksum.c /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/zio_compress.c /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/zio_inject.c /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/common/zfs/zfs_namecheck.c /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/common/zfs/zfs_deleg.c /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/common/zfs/zfs_prop.c /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/common/zfs/zfs_comutil.c /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/common/zfs/zpool_prop.c /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/common/zfs/zprop_common.c /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_acl.c /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_ctldir.c /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_dir.c /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_ioctl.c /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_log.c /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_replay.c /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_rlock.c /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/rrwlock.c /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vfsops.c /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vnops.c /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/zvol.c /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/vdev_geom.c ===> zlib (depend) @ -> /usr/src/sys machine -> /usr/src/sys/amd64/include rm -f .depend mkdep -f .depend -a -nostdinc -D_KERNEL -DKLD_MODULE -DHAVE_KERNEL_OPTION_HEADERS -I. -I@ -I@/contrib/altq -I/usr/obj/usr/src/sys/VIMAGE /usr/src/sys/modules/zlib/../../net/zlib.c 1 error *** Error code 2 1 error *** Error code 2 1 error # mkdep usage: mkdep [-ap] [-f file] [flags] file ... # mkdep -f .depend -a -nostdinc -D_KERNEL -DKLD_MODULE -DHAVE_KERNEL_OPTION_HEADERS -I. -I@ -I@/contrib/altq -I/usr/obj/usr/src/sys/VIMAGE /usr/src/sys/modules/zlib/../../net/zlib.c /usr/src/sys/modules/zlib/../../net/zlib.c:50:22: error: net/zlib.h: No such file or directory /usr/src/sys/modules/zlib/../../net/zlib.c:57:23: error: sys/types.h: No such file or directory /usr/src/sys/modules/zlib/../../net/zlib.c:58:22: error: sys/time.h: No such file or directory /usr/src/sys/modules/zlib/../../net/zlib.c:59:23: error: sys/systm.h: No such file or directory /usr/src/sys/modules/zlib/../../net/zlib.c:60:23: error: sys/param.h: No such file or directory /usr/src/sys/modules/zlib/../../net/zlib.c:61:24: error: sys/kernel.h: No such file or directory /usr/src/sys/modules/zlib/../../net/zlib.c:62:24: error: sys/module.h: No such file or directory mkdep: compile failed # Sam Fourman Jr. Fourman Networks From owner-freebsd-current@FreeBSD.ORG Wed Oct 28 23:38:39 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E2F3C1065670 for ; Wed, 28 Oct 2009 23:38:39 +0000 (UTC) (envelope-from sfourman@gmail.com) Received: from mail-pz0-f202.google.com (mail-pz0-f202.google.com [209.85.222.202]) by mx1.freebsd.org (Postfix) with ESMTP id BDE948FC13 for ; Wed, 28 Oct 2009 23:38:39 +0000 (UTC) Received: by pzk40 with SMTP id 40so887054pzk.7 for ; Wed, 28 Oct 2009 16:38:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:content-type; bh=8fjNWm0Tsgon7ls73wThPUweZfbJB6mB+9uv/xSVcUw=; b=wPUVR4C9Tlz/N+P+7Lkjn5lvjfe9eJFr9rDBxxwqKkwEl1UX5yFrd/rbXvj08MHKvT Fgu290TNlN14UBuaZSwhkHdlg4i9JmbcXxzbr2KowMNZOzG5aC1b7NM37L3hICSIaeYH 5DSgoC+4X+pknCXRc9BgyBQcFGuYTdv0ok5J0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=tI6Wbo1SNoB8ea8XoGuE2D1nxluJ7mC2glsweA09uHS5iiowexBjGwuQAQHCTW7CPu 3uyytiOreGYRCF4xwaSZDDNQiPe3x3rF5Ph8Oq26aP1eaLGOCBvmFwTeVA3HgGkcabff hjBiaDFgDClHEpbRMVaQEkIH8BVjC/CIPFNiU= MIME-Version: 1.0 Received: by 10.142.6.11 with SMTP id 11mr1483604wff.68.1256773119176; Wed, 28 Oct 2009 16:38:39 -0700 (PDT) Date: Wed, 28 Oct 2009 18:38:39 -0500 Message-ID: <11167f520910281638o769c756am4931fbb420a6952c@mail.gmail.com> From: "Sam Fourman Jr." To: FreeBSD Current Content-Type: text/plain; charset=ISO-8859-1 Subject: traceroute inside FreeBSD 8.0 RC2 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Oct 2009 23:38:40 -0000 hello, dev# traceroute www.google.com traceroute: Warning: www.google.com has multiple addresses; using 74.125.95.106 traceroute: findsaddr: write: No such process dev# security.jail.allow_raw_sockets=1 is set in sysctl.conf I found the problem is documented here for FreeBSD 7.2 http://www.freebsd.org/cgi/query-pr.cgi?pr=139454 this is just to confirm that it happens on 8.0 RC2 as well Sam Fourman Jr. Fourman Networks From owner-freebsd-current@FreeBSD.ORG Thu Oct 29 00:02:30 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A73F5106566B for ; Thu, 29 Oct 2009 00:02:30 +0000 (UTC) (envelope-from bruce@cran.org.uk) Received: from muon.cran.org.uk (muon.cran.org.uk [66.246.138.153]) by mx1.freebsd.org (Postfix) with ESMTP id 815248FC0A for ; Thu, 29 Oct 2009 00:02:30 +0000 (UTC) Received: from unknown (87-194-158-129.bethere.co.uk [87.194.158.129]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by muon.cran.org.uk (Postfix) with ESMTPSA id 6F17B8334; Thu, 29 Oct 2009 00:02:29 +0000 (UTC) Date: Thu, 29 Oct 2009 00:01:15 +0000 From: Bruce Cran To: current@freebsd.org, bzeeb+freebsd+lor@zabbadoz.net Message-ID: <20091029000115.00005baf@unknown> X-Mailer: Claws Mail 3.7.2cvs15 (GTK+ 2.16.0; i586-pc-mingw32msvc) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: Subject: LOR: rtentry (route.c) and ifnet_sx (sctp_bsd_addr.c) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Oct 2009 00:02:30 -0000 I installed the 9.0-CURRENT snapshot from 26th October on my iBook and saw this LOR on bootup: lock order reversal: (sleepable after non-sleepable) 1st 0x12f5058 rtentry (rtentry) @ /usr/src/sys/net/route.c:1474 2nd 0x9a0730 ifnet_sx (ifnet_sx) @ /usr/src/sys/netinet/sctp_bsd_addr.c:212 KDB: stack backtrace: 0xdd4b1560: at kdb_backtrace+0x4c 0xdd4b1580: at _witness_debugger+0x3c 0xdd4b15a0: at witness_checkorder+0x8d0 0xdd4b1600: at _sx_slock+0x90 0xdd4b1630: at sctp_init_ifns_for_vrf+0x50 0xdd4b1670: at sctp_addr_change+0x4c 0xdd4b16a0: at rt_newaddrmsg+0x78 0xdd4b1710: at rtinit+0x300 0xdd4b1830: at in_ifinit+0x8ac 0xdd4b1900: at in_control+0xca4 0xdd4b1960: at ifioctl+0x11f0 0xdd4b1a00: at soo_ioctl+0x3b4 0xdd4b1a20: at kern_ioctl+0x2a4 0xdd4b1a60: at ioctl+0x128 0xdd4b1aa0: at trap+0x37c 0xdd4b1b60: at powerpc_interrupt+0x11c 0xdd4b1b90: user SC trap by 0x219f6228: srr1=0xd032 r1=0x7fffd630 cr=0x48222022 xer=0x20000000 ctr=0x219f6220 -- Bruce Cran From owner-freebsd-current@FreeBSD.ORG Thu Oct 29 09:44:36 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E7A321065693; Thu, 29 Oct 2009 09:44:36 +0000 (UTC) (envelope-from alteriks@gmail.com) Received: from mail.agora.pl (mail.agora.pl [193.42.230.55]) by mx1.freebsd.org (Postfix) with ESMTP id 5541B8FC1D; Thu, 29 Oct 2009 09:44:35 +0000 (UTC) Received: from agpost.agora.pl (agpost.agora.pl [10.205.39.149]) by mail.agora.pl (8.13.8/8.11.1) with ESMTP id n9T9iXnV031805; Thu, 29 Oct 2009 10:44:33 +0100 Received: from t42.localnet ([10.201.55.193]) by agpost.agora.pl with ESMTP; Thu, 29 Oct 2009 10:44:27 +0100 From: "alteriks@gmail.com" To: Robert Noland Date: Thu, 29 Oct 2009 10:44:21 +0100 User-Agent: KMail/1.12.2 (Linux/2.6.30-1-686; KDE/4.3.2; i686; ; ) References: <684e57ec0910281313r6e9ac8d7x24a39035be6db888@mail.gmail.com> <1256762587.2315.29.camel@balrog.2hip.net> In-Reply-To: <1256762587.2315.29.camel@balrog.2hip.net> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-2" Content-Transfer-Encoding: 7bit Message-Id: <200910291044.21818.alteriks@gmail.com> Cc: freebsd-current@freebsd.org Subject: Re: GPT boot with ZFS RAIDZ "ZFS: i/o error - all block copies unavailable" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Oct 2009 09:44:37 -0000 On Wednesday 28 October 2009 21:43:07 Robert Noland wrote: > If you hit a key very early then you will land in boot2, where you can > type "status" and it will list the zfs pool. I haven't tried it yet. Would it allow me to mount root? I tried to install from fixit once again, but I've made a script to eliminate all typo's I could made. I amde script using most of: http://wiki.freebsd.org/RootOnZFS/GPTZFSBoot/RAIDZ1 After rebooting it could even load bootloader: > ZFS: i/o error - all block copies unavailable > ZFS: can't read MOS > ZFS: unexpected object set type lld > ZFS: unexpected object set type lld So in my opinion increasing number of sectors for first slice containing bootcode, helped at least in my case. I'll try to install FreeBSD in tuesday with new iso, as I suspect that something went wrong during burning dvd, also I didn't check md5. So maybe those problems are only related to defuncted dvd, I hope so. From owner-freebsd-current@FreeBSD.ORG Thu Oct 29 09:44:56 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 85A071065740 for ; Thu, 29 Oct 2009 09:44:56 +0000 (UTC) (envelope-from kamikaze@bsdforen.de) Received: from mail.bsdforen.de (bsdforen.de [212.204.60.79]) by mx1.freebsd.org (Postfix) with ESMTP id 443358FC28 for ; Thu, 29 Oct 2009 09:44:56 +0000 (UTC) Received: from mobileKamikaze.norad (vpn-cl-165-230.rz.uni-karlsruhe.de [141.3.165.230]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.bsdforen.de (Postfix) with ESMTP id E45FB8A0DAF for ; Thu, 29 Oct 2009 10:12:53 +0100 (CET) Message-ID: <4AE95C94.4040000@bsdforen.de> Date: Thu, 29 Oct 2009 10:12:52 +0100 From: Dominic Fandrey User-Agent: Thunderbird 2.0.0.23 (X11/20091024) MIME-Version: 1.0 To: freebsd-current@freebsd.org X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: 8.0-RC2 mangles msdosfs X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Oct 2009 09:44:56 -0000 Every time I perform write operations on msdosfs, the file system gets mangled. This is after writing a single file: > fsck_msdosfs -y /dev/msdosfs/VALHALLA ** /dev/msdosfs/VALHALLA ** Phase 1 - Read and Compare FATs ** Phase 2 - Check Cluster Chains ** Phase 3 - Checking Directories ** Phase 4 - Checking for Lost Files Lost cluster chain at cluster 4 49 Cluster(s) lost Reconnect? yes No LOST.DIR directory Clear? yes Lost cluster chain at cluster 53 37 Cluster(s) lost Reconnect? yes No LOST.DIR directory Clear? yes Lost cluster chain at cluster 90 9 Cluster(s) lost Reconnect? yes No LOST.DIR directory Clear? yes Lost cluster chain at cluster 99 9 Cluster(s) lost Reconnect? yes No LOST.DIR directory Clear? yes Lost cluster chain at cluster 108 1126 Cluster(s) lost Reconnect? yes No LOST.DIR directory Clear? yes Lost cluster chain at cluster 1234 9 Cluster(s) lost Reconnect? yes No LOST.DIR directory Clear? yes Lost cluster chain at cluster 1244 5 Cluster(s) lost Reconnect? yes No LOST.DIR directory Clear? yes Lost cluster chain at cluster 1248 49 Cluster(s) lost Reconnect? yes No LOST.DIR directory Clear? yes Lost cluster chain at cluster 1297 282 Cluster(s) lost Reconnect? yes No LOST.DIR directory Clear? yes Lost cluster chain at cluster 1600 5 Cluster(s) lost Reconnect? yes No LOST.DIR directory Clear? yes Lost cluster chain at cluster 1605 59 Cluster(s) lost Reconnect? yes No LOST.DIR directory Clear? yes Lost cluster chain at cluster 449483 1 Cluster(s) lost Reconnect? yes No LOST.DIR directory Clear? yes Update FATs? yes 2058 files, 783768 free (622259 clusters) ***** FILE SYSTEM WAS MODIFIED ***** If I start windows and run a chkdsk there, it will find cross-linked files and other filesystem nightmares. FreeBSD mobileKamikaze.norad 8.0-RC2 FreeBSD 8.0-RC2 #0: Tue Oct 27 10:52:14 CET 2009 root@mobileKamikaze.norad:/usr/obj/HP6510b-8/amd64/usr/src/sys/HP6510b-8 amd64 This is a dual Core2 Duo machine. In my opinion this is a show stopper. Regards -- A: Because it fouls the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing on usenet and in e-mail? From owner-freebsd-current@FreeBSD.ORG Thu Oct 29 10:22:08 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 844DC106566B for ; Thu, 29 Oct 2009 10:22:08 +0000 (UTC) (envelope-from valin@buchlovice.org) Received: from smtp-sfn.sitkom.cz (smtp-sfn.sitkom.cz [88.146.175.4]) by mx1.freebsd.org (Postfix) with ESMTP id 44FDB8FC1C for ; Thu, 29 Oct 2009 10:22:08 +0000 (UTC) Received: from osiris.buchlovice.sfn (valin-osiris-lan.brestek.sfn [10.8.20.3]) by smtp-sfn.sitkom.cz (Postfix) with ESMTP id 1B3C21FA6A1; Thu, 29 Oct 2009 11:22:04 +0100 (CET) Message-ID: <4AE96CCA.2080501@buchlovice.org> Date: Thu, 29 Oct 2009 11:22:02 +0100 From: =?ISO-8859-2?Q?Radek_Val=E1=B9ek?= User-Agent: Thunderbird 2.0.0.23 (X11/20091015) MIME-Version: 1.0 To: "alteriks@gmail.com" References: <684e57ec0910281313r6e9ac8d7x24a39035be6db888@mail.gmail.com> <1256762587.2315.29.camel@balrog.2hip.net> <200910291044.21818.alteriks@gmail.com> In-Reply-To: <200910291044.21818.alteriks@gmail.com> Content-Type: text/plain; charset=ISO-8859-2; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: GPT boot with ZFS RAIDZ "ZFS: i/o error - all block copies unavailable" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Oct 2009 10:22:08 -0000 alteriks@gmail.com napsal(a): > On Wednesday 28 October 2009 21:43:07 Robert Noland wrote: > >> If you hit a key very early then you will land in boot2, where you can >> type "status" and it will list the zfs pool. >> > > I haven't tried it yet. Would it allow me to mount root? > I tried to install from fixit once again, but I've made a script to eliminate > all typo's I could made. I amde script using most of: > http://wiki.freebsd.org/RootOnZFS/GPTZFSBoot/RAIDZ1 > > After rebooting it could even load bootloader: > >> ZFS: i/o error - all block copies unavailable >> ZFS: can't read MOS >> ZFS: unexpected object set type lld >> ZFS: unexpected object set type lld >> > > So in my opinion increasing number of sectors for first slice containing > bootcode, helped at least in my case. > > OK, so what's your current size of the first slice ? Could you paste here the result of 'gpart show' on your instalation? > I'll try to install FreeBSD in tuesday with new iso, as I suspect that > something went wrong during burning dvd, also I didn't check md5. So maybe > those problems are only related to defuncted dvd, I hope so. > _______________________________________________ > 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-current@FreeBSD.ORG Thu Oct 29 10:36:49 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 119891065692 for ; Thu, 29 Oct 2009 10:36:49 +0000 (UTC) (envelope-from rnoland@FreeBSD.org) Received: from gizmo.2hip.net (gizmo.2hip.net [64.74.207.195]) by mx1.freebsd.org (Postfix) with ESMTP id DD4868FC19 for ; Thu, 29 Oct 2009 10:36:48 +0000 (UTC) Received: from [192.168.1.4] (adsl-150-102-19.bna.bellsouth.net [72.150.102.19]) (authenticated bits=0) by gizmo.2hip.net (8.14.3/8.14.3) with ESMTP id n9TAaiYY089670 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Thu, 29 Oct 2009 06:36:46 -0400 (EDT) (envelope-from rnoland@FreeBSD.org) From: Robert Noland To: "alteriks@gmail.com" In-Reply-To: <200910291044.21818.alteriks@gmail.com> References: <684e57ec0910281313r6e9ac8d7x24a39035be6db888@mail.gmail.com> <1256762587.2315.29.camel@balrog.2hip.net> <200910291044.21818.alteriks@gmail.com> Content-Type: text/plain Organization: FreeBSD Date: Thu, 29 Oct 2009 05:36:38 -0500 Message-Id: <1256812598.39726.22.camel@balrog.2hip.net> Mime-Version: 1.0 X-Mailer: Evolution 2.26.3 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-1.8 required=5.0 tests=AWL,BAYES_00, RCVD_IN_SORBS_DUL, RDNS_DYNAMIC, SPF_SOFTFAIL autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on gizmo.2hip.net Cc: freebsd-current@freebsd.org Subject: Re: GPT boot with ZFS RAIDZ "ZFS: i/o error - all block copies unavailable" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Oct 2009 10:36:49 -0000 On Thu, 2009-10-29 at 10:44 +0100, alteriks@gmail.com wrote: > On Wednesday 28 October 2009 21:43:07 Robert Noland wrote: > > If you hit a key very early then you will land in boot2, where you can > > type "status" and it will list the zfs pool. > > I haven't tried it yet. Would it allow me to mount root? > I tried to install from fixit once again, but I've made a script to eliminate > all typo's I could made. I amde script using most of: > http://wiki.freebsd.org/RootOnZFS/GPTZFSBoot/RAIDZ1 This seems pretty accurate. I've never tried to do this with labeled disks though. For my current setups, I create the pools using ada0p3, etc... And once they get imported after boot, they end up using gpt id's. balrog% zpool status test pool: test state: ONLINE scrub: none requested config: NAME STATE READ WRITE CKSUM test ONLINE 0 0 0 raidz2 ONLINE 0 0 0 gptid/c56f3303-be79-11de-813c-002215ea6216 ONLINE 0 0 0 gptid/c70a07c6-be79-11de-813c-002215ea6216 ONLINE 0 0 0 gptid/c915d03c-be79-11de-813c-002215ea6216 ONLINE 0 0 0 gptid/0e4cf049-c0ce-11de-8c99-002215ea6216 ONLINE 0 0 0 gptid/0ff739a0-c0ce-11de-8c99-002215ea6216 ONLINE 0 0 0 gptid/10f4e873-c0ce-11de-8c99-002215ea6216 ONLINE 0 0 0 errors: No known data errors This pool continues to boot fine under qemu, and with my hacks to the BIOS drive detection, it boots under VBox as well. > After rebooting it could even load bootloader: > > ZFS: i/o error - all block copies unavailable > > ZFS: can't read MOS > > ZFS: unexpected object set type lld > > ZFS: unexpected object set type lld Ok, if you are getting this... It may be helpful if you can run "zdb -uuu zroot", so I can see what is going on with the root block pointer. I think you should be able to do that from fixit. Also note that you don't have the latest version of the loader if it is printing "lld", though as long as all of the drives are detected it likely won't make a difference. The "can't read MOS" error is the first attempt to read from the pool after probing all of the devices to sort out the configuration. Everything up to this point reads data directly from the vdev labels on each drive, so this is the first time that it tries to read from the pool. > So in my opinion increasing number of sectors for first slice containing > bootcode, helped at least in my case. -rw-r--r-- 1 rnoland rnoland 25671 Oct 24 13:56 gptzfsboot Even with all the debugging that I have enabled at the moment, gptzfsboot still only requires 51 sectors, so the usual 128 (64k) should be more than enough. robert. > I'll try to install FreeBSD in tuesday with new iso, as I suspect that > something went wrong during burning dvd, also I didn't check md5. So maybe > those problems are only related to defuncted dvd, I hope so. -- Robert Noland FreeBSD From owner-freebsd-current@FreeBSD.ORG Thu Oct 29 18:17:23 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5A6B91065676 for ; Thu, 29 Oct 2009 18:17:23 +0000 (UTC) (envelope-from marck@rinet.ru) Received: from woozle.rinet.ru (woozle.rinet.ru [195.54.192.68]) by mx1.freebsd.org (Postfix) with ESMTP id D2D068FC16 for ; Thu, 29 Oct 2009 18:17:22 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by woozle.rinet.ru (8.14.3/8.14.3) with ESMTP id n9TIHKrW048910; Thu, 29 Oct 2009 21:17:20 +0300 (MSK) (envelope-from marck@rinet.ru) Date: Thu, 29 Oct 2009 21:17:20 +0300 (MSK) From: Dmitry Morozovsky To: Stefan Bethke In-Reply-To: <6A973ECE-83E7-4653-BBE7-CC3093361D19@lassitu.de> Message-ID: References: <6A973ECE-83E7-4653-BBE7-CC3093361D19@lassitu.de> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) X-NCC-RegID: ru.rinet X-OpenPGP-Key-ID: 6B691B03 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.3 (woozle.rinet.ru [0.0.0.0]); Thu, 29 Oct 2009 21:17:20 +0300 (MSK) Cc: freebsd-current@freebsd.org Subject: Re: ZFS on entire disks setup X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Oct 2009 18:17:23 -0000 On Sat, 26 Sep 2009, Stefan Bethke wrote: SB> > is there a way to configure ZFS-only setup without partitions? SB> > SB> > I tried to reproduce the trick with `skip=1 seek=1024', and have SB> > loot/loader SB> > running, but it does not see the pool. SB> SB> This sequence is working for me: SB> dd if=/boot/zfsboot of=/dev/da0 count=1 SB> dd if=/boot/zfsboot of=/dev/da0 skip=1 seek=1024 SB> zpool create zroot /dev/da0 SB> zpool set bootfs=zroot zroot SB> cd /usr/src && make installworld installkernel distribution DESTDIR=/zroot SB> cp /boot/loader.conf /zroot/boot/loader.conf SB> cp /etc/rc.conf /zroot/etc/ SB> touch /zroot/etc/fstab SB> echo 'zfs_load="YES"' >>/zroot/boot/loader.conf SB> echo 'vfs.root.mountfrom="zfs:zroot"' >>/zroot/boot/loader.conf SB> zpool export zroot SB> zpool import zroot SB> cp /boot/zfs/zpool.cache /zroot/boot/zfs/ SB> zfs set mountpoint=legacy zroot SB> SB> ... except that it doesn't anymore. I saw this working about two months SB> ago, but now it fails to mount root. Verbose boot doesn't give any SB> indication why ZFS can't find the pool. Well, after all, I've managed to boot 8.0-RC2/amd64 from 1+0 zpool without either UFS or GPT/MBR. Will test further. As for the source of previous failure -- It seems bootfs property in my previous experiment did not set properly... -- Sincerely, D.Marck [DM5020, MCK-RIPE, DM3-RIPN] [ FreeBSD committer: marck@FreeBSD.org ] ------------------------------------------------------------------------ *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- marck@rinet.ru *** ------------------------------------------------------------------------ From owner-freebsd-current@FreeBSD.ORG Thu Oct 29 18:18:55 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9A52A1065692 for ; Thu, 29 Oct 2009 18:18:55 +0000 (UTC) (envelope-from freebsd-current@m.gmane.org) Received: from lo.gmane.org (lo.gmane.org [80.91.229.12]) by mx1.freebsd.org (Postfix) with ESMTP id 2CED18FC17 for ; Thu, 29 Oct 2009 18:18:54 +0000 (UTC) Received: from list by lo.gmane.org with local (Exim 4.50) id 1N3ZaG-00048Y-1M for freebsd-current@freebsd.org; Thu, 29 Oct 2009 19:18:52 +0100 Received: from 207.155.204.151.ptr.us.xo.net ([207.155.204.151]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 29 Oct 2009 19:18:52 +0100 Received: from atkin901 by 207.155.204.151.ptr.us.xo.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 29 Oct 2009 19:18:52 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-current@freebsd.org From: Mark Atkinson Date: Thu, 29 Oct 2009 11:18:29 -0700 Lines: 76 Message-ID: Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: 207.155.204.151.ptr.us.xo.net User-Agent: Thunderbird 2.0.0.23 (X11/20091009) Sender: news Subject: panic: _mtx_lock_sleep: recursed on non-recursive mutex process lock @ /usr/src/sys/kern/kern_sig.c:981 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Oct 2009 18:18:55 -0000 I got this panic this morning, after a fresh upgrade to svn current during concurrent NFS access from a couple of clients: FreeBSD 9.0-CURRENT #7 r198588: Thu Oct 29 08:55:09 PDT 2009 Unread portion of the kernel message buffer: panic: _mtx_lock_sleep: recursed on non-recursive mutex process lock @ /usr/src/sys/kern/kern_sig.c:981 cpuid = 3 KDB: enter: panic Physical memory: 2031 MB Dumping 196 MB: 181 165 149 133 117 101 85 69 53 37 21 5 #0 doadump () at pcpu.h:246 246 __asm __volatile("movl %%fs:0,%0" : "=r" (td)); (kgdb) where #0 doadump () at pcpu.h:246 #1 0xc04d7ff9 in db_fncall (dummy1=1, dummy2=0, dummy3=-1056878112, dummy4=0xe831a994 "") at /usr/src/sys/ddb/db_command.c:548 #2 0xc04d83f1 in db_command (last_cmdp=0xc0e0c29c, cmd_table=0x0, dopager=1) at /usr/src/sys/ddb/db_command.c:445 #3 0xc04d8555 in db_command_loop () at /usr/src/sys/ddb/db_command.c:498 #4 0xc04da49c in db_trap (type=3, code=0) at /usr/src/sys/ddb/db_main.c:229 #5 0xc08cfbe1 in kdb_trap (type=3, code=0, tf=0xe831ab38) at /usr/src/sys/kern/subr_kdb.c:535 #6 0xc0c0bb17 in trap (frame=0xe831ab38) at /usr/src/sys/i386/i386/trap.c:690 #7 0xc0bedc7b in calltrap () at /usr/src/sys/i386/i386/exception.s:165 #8 0xc08cfd7a in kdb_enter (why=0xc0ce0a27 "panic", msg=0xc0ce0a27 "panic") at cpufunc.h:71 #9 0xc089e998 in panic (fmt=0xc0cdf3fe "_mtx_lock_sleep: recursed on non-recursive mutex %s @ %s:%d\n") at /usr/src/sys/kern/kern_shutdown.c:562 #10 0xc088ed5a in _mtx_lock_sleep (m=0xc73065d8, tid=3341857888, opts=0, file=0xc0ce0a96 "/usr/src/sys/kern/kern_sig.c", line=981) at /usr/src/sys/kern/kern_mutex.c:341 #11 0xc088ef87 in _mtx_lock_flags (m=0xc73065d8, opts=0, file=0xc0ce0a96 "/usr/src/sys/kern/kern_sig.c", line=981) at /usr/src/sys/kern/kern_mutex.c:203 #12 0xc08a107b in kern_sigprocmask (td=0xc730b460, how=1, set=0xe831ac80, oset=0x0, flags=0) at /usr/src/sys/kern/kern_sig.c:981 #13 0xc08a4bfb in trapsignal (td=0xc730b460, ksi=0xe831accc) at /usr/src/sys/kern/kern_sig.c:1866 #14 0xc0c0bc07 in trap (frame=0xe831ad38) at /usr/src/sys/i386/i386/trap.c:738 #15 0xc0bedc7b in calltrap () at /usr/src/sys/i386/i386/exception.s:165 #16 (kgdb) frame 10 #10 0xc088ed5a in _mtx_lock_sleep (m=0xc73065d8, tid=3341857888, opts=0, file=0xc0ce0a96 "/usr/src/sys/kern/kern_sig.c", line=981) at /usr/src/sys/kern/kern_mutex.c:341 341 KASSERT((m->lock_object.lo_flags & LO_RECURSABLE) != 0, (kgdb) list 336 uint64_t sleep_cnt = 0; 337 int64_t sleep_time = 0; 338 #endif 339 340 if (mtx_owned(m)) { 341 KASSERT((m->lock_object.lo_flags & LO_RECURSABLE) != 0, 342 ("_mtx_lock_sleep: recursed on non-recursive mutex %s @ %s:%d\n", 343 m->lock_object.lo_name, file, line)); 344 m->mtx_recurse++; 345 atomic_set_ptr(&m->mtx_lock, MTX_RECURSED); (kgdb) p *m $2 = {lock_object = {lo_name = 0xc0cdf492 "process lock", lo_flags = 21168128, lo_data = 0, lo_witness = 0xc5934340}, mtx_lock = 3341857888} From owner-freebsd-current@FreeBSD.ORG Thu Oct 29 19:14:26 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5B8B1106568D for ; Thu, 29 Oct 2009 19:14:26 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.zoral.com.ua (skuns.zoral.com.ua [91.193.166.194]) by mx1.freebsd.org (Postfix) with ESMTP id B24808FC13 for ; Thu, 29 Oct 2009 19:14:25 +0000 (UTC) Received: from deviant.kiev.zoral.com.ua (root@deviant.kiev.zoral.com.ua [10.1.1.148]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id n9TJEBF6008450 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 29 Oct 2009 21:14:11 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.3/8.14.3) with ESMTP id n9TJEBZL077092; Thu, 29 Oct 2009 21:14:11 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.3/8.14.3/Submit) id n9TJEBFC077091; Thu, 29 Oct 2009 21:14:11 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Thu, 29 Oct 2009 21:14:10 +0200 From: Kostik Belousov To: Mark Atkinson Message-ID: <20091029191410.GC2147@deviant.kiev.zoral.com.ua> References: Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="oJ71EGRlYNjSvfq7" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: clamav-milter 0.95.2 at skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-4.4 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua Cc: freebsd-current@freebsd.org Subject: Re: panic: _mtx_lock_sleep: recursed on non-recursive mutex process lock @ /usr/src/sys/kern/kern_sig.c:981 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Oct 2009 19:14:26 -0000 --oJ71EGRlYNjSvfq7 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Oct 29, 2009 at 11:18:29AM -0700, Mark Atkinson wrote: > I got this panic this morning, after a fresh upgrade to svn current > during concurrent NFS access from a couple of clients: >=20 > FreeBSD 9.0-CURRENT #7 r198588: Thu Oct 29 08:55:09 PDT 2009 This is supposedly fixed by r198590. >=20 > Unread portion of the kernel message buffer: > panic: _mtx_lock_sleep: recursed on non-recursive mutex process lock @ > /usr/src/sys/kern/kern_sig.c:981 --oJ71EGRlYNjSvfq7 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (FreeBSD) iEYEARECAAYFAkrp6YIACgkQC3+MBN1Mb4g1uQCgqpwN3qSdeqIRFMqINo12bSnO rTgAoK8YIO+vyWQ8hlv0sCweRJ1h6N/a =z5JR -----END PGP SIGNATURE----- --oJ71EGRlYNjSvfq7-- From owner-freebsd-current@FreeBSD.ORG Thu Oct 29 19:39:46 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A093C106568F for ; Thu, 29 Oct 2009 19:39:46 +0000 (UTC) (envelope-from freebsd-current@m.gmane.org) Received: from lo.gmane.org (lo.gmane.org [80.91.229.12]) by mx1.freebsd.org (Postfix) with ESMTP id 5BE348FC1F for ; Thu, 29 Oct 2009 19:39:45 +0000 (UTC) Received: from list by lo.gmane.org with local (Exim 4.50) id 1N3aqQ-0006kI-Rf for freebsd-current@freebsd.org; Thu, 29 Oct 2009 20:39:38 +0100 Received: from 207.155.204.151.ptr.us.xo.net ([207.155.204.151]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 29 Oct 2009 20:39:38 +0100 Received: from atkin901 by 207.155.204.151.ptr.us.xo.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 29 Oct 2009 20:39:38 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-current@freebsd.org From: Mark Atkinson Date: Thu, 29 Oct 2009 12:39:17 -0700 Lines: 15 Message-ID: References: <20091029191410.GC2147@deviant.kiev.zoral.com.ua> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: 207.155.204.151.ptr.us.xo.net User-Agent: Thunderbird 2.0.0.23 (X11/20091009) In-Reply-To: <20091029191410.GC2147@deviant.kiev.zoral.com.ua> Sender: news Subject: Re: panic: _mtx_lock_sleep: recursed on non-recursive mutex process lock @ /usr/src/sys/kern/kern_sig.c:981 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Oct 2009 19:39:48 -0000 Kostik Belousov wrote: > On Thu, Oct 29, 2009 at 11:18:29AM -0700, Mark Atkinson wrote: >> I got this panic this morning, after a fresh upgrade to svn current >> during concurrent NFS access from a couple of clients: >> >> FreeBSD 9.0-CURRENT #7 r198588: Thu Oct 29 08:55:09 PDT 2009 > This is supposedly fixed by r198590. What amazingly bad timing on my part. Or, if not, it should be considered for an earlier MFC. Thanks! > >> Unread portion of the kernel message buffer: >> panic: _mtx_lock_sleep: recursed on non-recursive mutex process lock @ >> /usr/src/sys/kern/kern_sig.c:981 From owner-freebsd-current@FreeBSD.ORG Thu Oct 29 14:10:48 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3B40B106568F; Thu, 29 Oct 2009 14:10:48 +0000 (UTC) (envelope-from O.Seibert@cs.ru.nl) Received: from rustug.science.ru.nl (rustug.science.ru.nl [131.174.16.158]) by mx1.freebsd.org (Postfix) with ESMTP id C83F88FC19; Thu, 29 Oct 2009 14:10:47 +0000 (UTC) Received: from kookpunt.science.ru.nl (kookpunt.science.ru.nl [131.174.30.61]) by rustug.science.ru.nl (8.13.7/5.30) with ESMTP id n9TDqgHV005036; Thu, 29 Oct 2009 14:52:42 +0100 (MET) Received: from twoquid.cs.ru.nl (twoquid.cs.ru.nl [131.174.142.38]) by kookpunt.science.ru.nl (8.13.7/5.30) with ESMTP id n9TDqddE018549; Thu, 29 Oct 2009 14:52:39 +0100 (MET) Received: by twoquid.cs.ru.nl (Postfix, from userid 4100) id 74A192E059; Thu, 29 Oct 2009 14:52:39 +0100 (CET) Date: Thu, 29 Oct 2009 14:52:39 +0100 From: Olaf Seibert To: Rick Macklem Message-ID: <20091029135239.GX841@twoquid.cs.ru.nl> References: <20091027164159.GU841@twoquid.cs.ru.nl> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.19 (2009-01-05) X-Spam-Score: -1.799 () ALL_TRUSTED,BAYES_50 X-Scanned-By: MIMEDefang 2.63 on 131.174.30.61 X-Mailman-Approved-At: Thu, 29 Oct 2009 20:01:45 +0000 Cc: freebsd-stable@freebsd.org, dfr@freebsd.org, freebsd-current@freebsd.org, Olaf Seibert Subject: Re: 8.0-RC1 NFS client timeout issue X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Oct 2009 14:10:48 -0000 On Wed 28 Oct 2009 at 16:38:27 -0400, Rick Macklem wrote: > I'll leave this one for the TCP wizzards. I'm not sure what the > correct behaviour is when data is received on a connection. (I think > it is waiting for a FIN from the client side at this point.) After writing, I realised that it is indeed perfectly allowed for the client to send data. But since the server already sent its FIN, it can't send anything more, not even an error message. So with that in mind, the client shouldn't send anything any more either. > If you could try the following patch and see if it helps, that would be > appreciated, rick Thanks, it looks like it should do the trick. I can't try it before monday, though. -Olaf. -- From owner-freebsd-current@FreeBSD.ORG Thu Oct 29 20:03:46 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8DED7106568B for ; Thu, 29 Oct 2009 20:03:46 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from esa-annu.mail.uoguelph.ca (esa-annu.mail.uoguelph.ca [131.104.91.36]) by mx1.freebsd.org (Postfix) with ESMTP id 441F08FC1A for ; Thu, 29 Oct 2009 20:03:46 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqoEABqS6UqDaFvJ/2dsb2JhbACQHgHPS4IzB4IDBIFi X-IronPort-AV: E=Sophos;i="4.44,648,1249272000"; d="scan'208";a="51726886" Received: from ganges.cs.uoguelph.ca ([131.104.91.201]) by esa-annu-pri.mail.uoguelph.ca with ESMTP; 29 Oct 2009 16:03:44 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by ganges.cs.uoguelph.ca (Postfix) with ESMTP id 9BFBEFB8063; Thu, 29 Oct 2009 16:03:44 -0400 (EDT) X-Virus-Scanned: amavisd-new at ganges.cs.uoguelph.ca Received: from ganges.cs.uoguelph.ca ([127.0.0.1]) by localhost (ganges.cs.uoguelph.ca [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7at6sgRIAlBS; Thu, 29 Oct 2009 16:03:43 -0400 (EDT) Received: from muncher.cs.uoguelph.ca (muncher.cs.uoguelph.ca [131.104.91.102]) by ganges.cs.uoguelph.ca (Postfix) with ESMTP id 59D2BFB8042; Thu, 29 Oct 2009 16:03:43 -0400 (EDT) Received: from localhost (rmacklem@localhost) by muncher.cs.uoguelph.ca (8.11.7p3+Sun/8.11.6) with ESMTP id n9TKAqP21213; Thu, 29 Oct 2009 16:10:52 -0400 (EDT) X-Authentication-Warning: muncher.cs.uoguelph.ca: rmacklem owned process doing -bs Date: Thu, 29 Oct 2009 16:10:52 -0400 (EDT) From: Rick Macklem X-X-Sender: rmacklem@muncher.cs.uoguelph.ca To: freebsd-current@freebsd.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: O.Seibert@cs.ru.nl Subject: NFS over TCP patch testing/review, please!! X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Oct 2009 20:03:46 -0000 I think the following patch fixes the problem reported by O. Seibert w.r.t. NFS over TCP taking 5min to reconnect to a server after a period of inactivity. (I think there have been others bit by this, but they were vague reports of trouble with NFS over TCP.) I didn't see the problem, because I was mainly testing against a FreeBSD server and/or using NFSv4 (NFSv4 does a Renew every 30sec, so the TCP connection isn't inactive for long enough for a Solaris server to disconnect it.) clnt_vc_call() in sys/rpc/clnt_vc.c checks for the server closing down the connection while the RPC is in progress, but doesn't check to see if it has already happened. If it has already happened, there would be no upcall to prompt a wakeup of the msleep() waiting for a reply, etc. This patch adds a check for the connection being closed by the server, just before queuing the request and sending it. (I think this fixes the problem.) What I really need is some people to test NFS over TCP with the patch applied to their kernel. It doesn't matter if you aren't seeing the problem (ie. using a FreeBSD server), since I am more concerned with the patch breaking something else than fixing the problem. (This seems serious enough that I'd like to try and get a fix into 8.0, which is why I'm hoping some folks can test this quickly?) Thanks in advance for help with this, rick --- patch for sys/rpc/clnt_vc.c --- --- rpc/clnt_vc.c.sav 2009-10-28 15:44:20.000000000 -0400 +++ rpc/clnt_vc.c 2009-10-29 15:40:37.000000000 -0400 @@ -413,6 +413,22 @@ cr->cr_xid = xid; mtx_lock(&ct->ct_lock); + /* + * Check to see if the other end has already started to close down + * the connection. The upcall will have set ct_error.re_status + * to RPC_CANTRECV if this is the case. + * If the other end starts to close down the connection after this + * point, it will be detected later when cr_error is checked, + * since the request is in the ct_pending queue. + */ + if (ct->ct_error.re_status == RPC_CANTRECV) { + if (errp != &ct->ct_error) { + errp->re_errno = ct->ct_error.re_errno; + errp->re_status = RPC_CANTRECV; + } + stat = RPC_CANTRECV; + goto out; + } TAILQ_INSERT_TAIL(&ct->ct_pending, cr, cr_link); mtx_unlock(&ct->ct_lock); From owner-freebsd-current@FreeBSD.ORG Thu Oct 29 20:49:01 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9B5A11065670 for ; Thu, 29 Oct 2009 20:49:01 +0000 (UTC) (envelope-from kraduk@googlemail.com) Received: from gv-out-0910.google.com (gv-out-0910.google.com [216.239.58.187]) by mx1.freebsd.org (Postfix) with ESMTP id 2657A8FC0C for ; Thu, 29 Oct 2009 20:49:00 +0000 (UTC) Received: by gv-out-0910.google.com with SMTP id p33so56839gvf.39 for ; Thu, 29 Oct 2009 13:48:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=d7QMdzjgCBOzRUvz9oxFtybd8DnwNl7mo082bVuUh74=; b=G+lvIjGbjBsH1Ipic37itDIjAsAPvd1hp+6FQgZxD+VnZNMhjTyFY0LsJdqn8GFlGK hpW4bVFP9tnx7YhkgdgtZ2wx0XtJz19O7R7iuIoNU2h6YgscT4i3TdqSRGwHmqwTRfzV lSU3bQaSI1Xba7YmRUWitDREAQhPl94GcuGjI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=Wg+xr++GHUL31pf5UyhRi1SzATqZebqobU5pr7tiFWUiNkcvkrnxqZJ1kCuSDhDXn9 kJJYtB+d6d1vEX3ZJiNYvZuUEs088zXyznfzu2ZNvfvROJZZ/On2qCBcmp1CvEqM8bsN bRdbgyOuTV7wUfGdQN6Tgd/VuS0IICjf1N+/s= MIME-Version: 1.0 Received: by 10.239.145.144 with SMTP id s16mr63167hba.145.1256849339487; Thu, 29 Oct 2009 13:48:59 -0700 (PDT) In-Reply-To: References: <6A973ECE-83E7-4653-BBE7-CC3093361D19@lassitu.de> Date: Thu, 29 Oct 2009 20:48:59 +0000 Message-ID: From: krad To: Dmitry Morozovsky Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-current@freebsd.org, Stefan Bethke Subject: Re: ZFS on entire disks setup X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Oct 2009 20:49:01 -0000 2009/10/29 Dmitry Morozovsky > On Sat, 26 Sep 2009, Stefan Bethke wrote: > > SB> > is there a way to configure ZFS-only setup without partitions? > SB> > > SB> > I tried to reproduce the trick with `skip=1 seek=1024', and have > SB> > loot/loader > SB> > running, but it does not see the pool. > SB> > SB> This sequence is working for me: > SB> dd if=/boot/zfsboot of=/dev/da0 count=1 > SB> dd if=/boot/zfsboot of=/dev/da0 skip=1 seek=1024 > SB> zpool create zroot /dev/da0 > SB> zpool set bootfs=zroot zroot > SB> cd /usr/src && make installworld installkernel distribution > DESTDIR=/zroot > SB> cp /boot/loader.conf /zroot/boot/loader.conf > SB> cp /etc/rc.conf /zroot/etc/ > SB> touch /zroot/etc/fstab > SB> echo 'zfs_load="YES"' >>/zroot/boot/loader.conf > SB> echo 'vfs.root.mountfrom="zfs:zroot"' >>/zroot/boot/loader.conf > SB> zpool export zroot > SB> zpool import zroot > SB> cp /boot/zfs/zpool.cache /zroot/boot/zfs/ > SB> zfs set mountpoint=legacy zroot > SB> > SB> ... except that it doesn't anymore. I saw this working about two > months > SB> ago, but now it fails to mount root. Verbose boot doesn't give any > SB> indication why ZFS can't find the pool. > > Well, after all, I've managed to boot 8.0-RC2/amd64 from 1+0 zpool without > either UFS or GPT/MBR. Will test further. > > As for the source of previous failure -- It seems bootfs property in my > previous experiment did not set properly... > > -- > Sincerely, > D.Marck [DM5020, MCK-RIPE, DM3-RIPN] > [ FreeBSD committer: marck@FreeBSD.org ] > ------------------------------------------------------------------------ > *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- marck@rinet.ru *** > ------------------------------------------------------------------------ > _______________________________________________ > 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" > why do you want to use it without a partition label? From owner-freebsd-current@FreeBSD.ORG Thu Oct 29 21:38:33 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 678F0106566C for ; Thu, 29 Oct 2009 21:38:33 +0000 (UTC) (envelope-from marck@rinet.ru) Received: from woozle.rinet.ru (woozle.rinet.ru [195.54.192.68]) by mx1.freebsd.org (Postfix) with ESMTP id DD3938FC0A for ; Thu, 29 Oct 2009 21:38:32 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by woozle.rinet.ru (8.14.3/8.14.3) with ESMTP id n9TLcVKG052482; Fri, 30 Oct 2009 00:38:31 +0300 (MSK) (envelope-from marck@rinet.ru) Date: Fri, 30 Oct 2009 00:38:31 +0300 (MSK) From: Dmitry Morozovsky To: krad In-Reply-To: Message-ID: References: <6A973ECE-83E7-4653-BBE7-CC3093361D19@lassitu.de> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) X-NCC-RegID: ru.rinet X-OpenPGP-Key-ID: 6B691B03 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.3 (woozle.rinet.ru [0.0.0.0]); Fri, 30 Oct 2009 00:38:31 +0300 (MSK) Cc: freebsd-current@freebsd.org, Stefan Bethke Subject: Re: ZFS on entire disks setup X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Oct 2009 21:38:33 -0000 On Thu, 29 Oct 2009, krad wrote: k> > SB> > is there a way to configure ZFS-only setup without partitions? [snip] k> > Well, after all, I've managed to boot 8.0-RC2/amd64 from 1+0 zpool without k> > either UFS or GPT/MBR. Will test further. k> > k> > As for the source of previous failure -- It seems bootfs property in my k> > previous experiment did not set properly... k> k> why do you want to use it without a partition label? Well, consider it brain-damaged (though successful) experiment ;-P Seriously, making dedicated machine, I'd betted skip unneeded layers. All our servers currently work without real MBRs, and previous ZFS based ones are GPT. -- Sincerely, D.Marck [DM5020, MCK-RIPE, DM3-RIPN] [ FreeBSD committer: marck@FreeBSD.org ] ------------------------------------------------------------------------ *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- marck@rinet.ru *** ------------------------------------------------------------------------ From owner-freebsd-current@FreeBSD.ORG Thu Oct 29 21:54:07 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 07AAC1065670 for ; Thu, 29 Oct 2009 21:54:07 +0000 (UTC) (envelope-from rdivacky@vlk.vlakno.cz) Received: from vlakno.cz (77-93-215-190.static.masterinter.net [77.93.215.190]) by mx1.freebsd.org (Postfix) with ESMTP id B4FA18FC1C for ; Thu, 29 Oct 2009 21:54:06 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by vlakno.cz (Postfix) with ESMTP id 4DC199CB3DC for ; Thu, 29 Oct 2009 22:53:15 +0100 (CET) X-Virus-Scanned: amavisd-new at vlakno.cz Received: from vlakno.cz ([127.0.0.1]) by localhost (lev.vlakno.cz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1DAf8Lztu4li for ; Thu, 29 Oct 2009 22:53:13 +0100 (CET) Received: from vlk.vlakno.cz (localhost [127.0.0.1]) by vlakno.cz (Postfix) with ESMTP id ED1739CB480 for ; Thu, 29 Oct 2009 22:53:12 +0100 (CET) Received: (from rdivacky@localhost) by vlk.vlakno.cz (8.14.3/8.14.3/Submit) id n9TLrCrq035188 for current@freebsd.org; Thu, 29 Oct 2009 22:53:12 +0100 (CET) (envelope-from rdivacky) Date: Thu, 29 Oct 2009 22:53:12 +0100 From: Roman Divacky To: current@freebsd.org Message-ID: <20091029215312.GA34302@freebsd.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="nFreZHaLTZJo0R7j" Content-Disposition: inline User-Agent: Mutt/1.4.2.3i Cc: Subject: [RFC]: m4 update X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Oct 2009 21:54:07 -0000 --nFreZHaLTZJo0R7j Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable hi I made a patch that updates our in-tree m4 to the version from OpenBSD. Their version contains some gnu extensions and generally is modernized and rewritten. The patch (you have to in src/usr.bin/m4 for it to apply): http://vlakno.cz/~rdivacky/m4.patch I added their ohash* implementation to the m4 subdir as it uses it. I am not sure this is the correct way but it works for now.=20 So the question is - do we want this at all? If so, is this the way we=20 want it? I am open to all comments, thank you! roman --nFreZHaLTZJo0R7j Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.13 (FreeBSD) iEYEARECAAYFAkrqDsgACgkQLVEj6D3CBEykXgCdGmDbLxoO93S5XVvs9NTcKNjM 86sAoIN3lzj55rQGSh+QdwkgKZTpfViN =L0IN -----END PGP SIGNATURE----- --nFreZHaLTZJo0R7j-- From owner-freebsd-current@FreeBSD.ORG Thu Oct 29 21:51:00 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AB6B310656A3 for ; Thu, 29 Oct 2009 21:51:00 +0000 (UTC) (envelope-from nwf@cs.jhu.edu) Received: from blaze.cs.jhu.edu (blaze.cs.jhu.edu [128.220.13.50]) by mx1.freebsd.org (Postfix) with ESMTP id 265278FC12 for ; Thu, 29 Oct 2009 21:50:59 +0000 (UTC) Received: from gradx.cs.jhu.edu (gradx.cs.jhu.edu [128.220.13.52]) by blaze.cs.jhu.edu (8.14.3/8.14.3) with ESMTP id n9TLdTox012785 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Thu, 29 Oct 2009 17:39:29 -0400 (EDT) Received: from gradx.cs.jhu.edu (localhost.localdomain [127.0.0.1]) by gradx.cs.jhu.edu (8.14.2/8.13.1) with ESMTP id n9TLdTC1017820 for ; Thu, 29 Oct 2009 17:39:29 -0400 Received: (from nwf@localhost) by gradx.cs.jhu.edu (8.14.2/8.13.8/Submit) id n9TLdTNA017819 for freebsd-current@freebsd.org; Thu, 29 Oct 2009 17:39:29 -0400 Date: Thu, 29 Oct 2009 17:39:29 -0400 From: Nathaniel W Filardo To: freebsd-current@freebsd.org Message-ID: <20091029213929.GD19125@gradx.cs.jhu.edu> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="eqp4TxRxnD4KrmFZ" Content-Disposition: inline User-Agent: Mutt/1.5.18 (2008-05-17) X-Mailman-Approved-At: Thu, 29 Oct 2009 22:02:15 +0000 Subject: SATA disk error and hang until "atacontrol reinit" ? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Oct 2009 21:51:00 -0000 --eqp4TxRxnD4KrmFZ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable I have a FreeBSD/SPARC FreeBSD hydra.priv.oc.ietfng.org 9.0-CURRENT FreeBSD 9.0-CURRENT #11: Mon Oct 19 22:08:50 EDT 2009 root@hydra.priv.oc.ietfng.org:/systank/obj/systank/src/sys/NWFKERN sparc64 with a atapci1: port 0x300-0x3ff mem 0x600000-0x6fffff,0x800000-0xbfffff at device 1.0 on pci3 and eight SATA2 disks: ad0: 305245MB at ata4-master SATA300 ad1: 305245MB at ata5-master SATA300 ad2: 305245MB at ata6-master SATA300 ad3: 305245MB at ata7-master SATA300 ad4: 715404MB at ata8-master SATA300 ad5: 715404MB at ata9-master SATA300 ad6: 715404MB at ata10-master SATA300 ad7: 715404MB at ata11-master SATA300 The two sets of four disks are each RAIDZ'd together, and the two RAIDZs are in one storage pool. I've been stress-testing the disks by scrubbing and find that after a few days of uptime, I will get ad0: FAILURE - READ_DMA status=3D51 error=3D0 LBA=3D1032= 00892 (It's always ad0 that fails) and all I/O directed at this storage pool thro= ugh ZFS hangs. (I have not yet tested with dd from the raw disks; didn't think to do it, sorry.) During this period, zpool status reports 1 checksum error =66rom ad0, though I don't know if this is occurs before, after, or in synchrony with the ad0 READ_DMA FAILURE. Previously, I just rebooted, but this time I thought to run "atacontrol reinit ata4" (which is the channel holding ad0). That caused the kernel to say ad0: WARNING - WRITE_DMA48 requeued due to channel reset LBA=3D625104384 ad0: FAILURE - already active DMA on this device ad0: setting up DMA failed zpool status now indicates that the scrub is proceeding again, and that ad0 has suffered 3 read, 1 write, and 1 checksum error. I/O directed at the storage tank works again. Is my disk going bad or is there something more funny here? Even if the disk is going bad, shouldn't the controller time out the request eventually? Thanks much in advance. --nwf; --eqp4TxRxnD4KrmFZ Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAkrqC5EACgkQTeQabvr9Tc/uRwCePfRQSFIhG4i6E3BSV7f54+u/ uEcAnA/f70fQSym13X0RbWg1HuagzqKK =buS0 -----END PGP SIGNATURE----- --eqp4TxRxnD4KrmFZ-- From owner-freebsd-current@FreeBSD.ORG Thu Oct 29 22:32:33 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EEBFA1065676 for ; Thu, 29 Oct 2009 22:32:32 +0000 (UTC) (envelope-from ubm.freebsd@googlemail.com) Received: from mail-bw0-f213.google.com (mail-bw0-f213.google.com [209.85.218.213]) by mx1.freebsd.org (Postfix) with ESMTP id 7D3BD8FC12 for ; Thu, 29 Oct 2009 22:32:32 +0000 (UTC) Received: by bwz5 with SMTP id 5so2915841bwz.3 for ; Thu, 29 Oct 2009 15:32:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:received:received:date:from:to:subject :message-id:x-mailer:mime-version:content-type :content-transfer-encoding; bh=TDLJOO2grM34i6HlRKHDREkF5hyry9JKXM3OGNcJBLY=; b=T/zaAE95iBqGlwuwCLRoexznXHMh78yob/b9CqW7lftbRjfAhE6jLSkUlGWQ2EfeVn sSxF9bBV6zTLeab3Khe0yDkVo6998Gtetw1gxBQB/5wf+k+uf2ZfLyg6Ioqdjtf//4QN eS5XB0/JfQSShM6QgDFmOrKipVD9l4U8ZBARM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=date:from:to:subject:message-id:x-mailer:mime-version:content-type :content-transfer-encoding; b=R4G9TWe5oYNy0jpZEZHGgytN2eP6aKsXxR7eCfkUkZYFGMbg+amBHhWSP9oa1NGOLS 0DvCz6EUB2cXuIyUe24Pasm2MjaF4hwHfz1K5okLNcxF8QnqKaYr2C/7/bg0NlUp6Qah 1wRUC54DNdE4x5fM3sgriQjCgkQQqfmCDgyIs= Received: by 10.204.25.71 with SMTP id y7mr500778bkb.67.1256855551197; Thu, 29 Oct 2009 15:32:31 -0700 (PDT) Received: from greatsheep.chaos.base (e181050040.adsl.alicedsl.de [85.181.50.40]) by mx.google.com with ESMTPS id p17sm5137020fka.42.2009.10.29.15.32.30 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 29 Oct 2009 15:32:30 -0700 (PDT) Date: Thu, 29 Oct 2009 23:32:29 +0100 From: Marc UBM Bocklet To: current@freebsd.org Message-Id: <20091029233229.ab475d24.ubm.freebsd@gmail.com> X-Mailer: Sylpheed 2.7.0 (GTK+ 2.16.4; i386-portbld-freebsd8.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Thu, 29 Oct 2009 22:50:15 +0000 Cc: Subject: gjournal crash with external usb drive after unclean shutdown X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Oct 2009 22:32:33 -0000 Hiho! :-) Following an unclean shutdown (panic, related to a bad network card in another machine), my gjournaled external usb drive reliably crashes my system when I connect it. I got a core dump available for poking around further. Textdump info is attached. I'm not sure if the disk is dying or the journal somehow got into a really bad state. textdump is available on request! :-) Some information: FreeBSD greatsheep.chaos.base 9.0-CURRENT FreeBSD 9.0-CURRENT #16: Fri Sep 25 19:16:18 CEST 2009 sheep@ubm.mine.nu:/usr/obj/usr/src/sys/SUBMARINE_SMP i386 Panic message: Fatal trap 12: page fault while in kernel mode cpuid = 0; apic id = 00 fault virtual address = 0x8a6c7000 fault code = supervisor read, page not present instruction pointer = 0x20:0x8086d3fe stack pointer = 0x28:0xdc71e964 frame pointer = 0x28:0xdc71e9e0 code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 2087 (g_journal da0) kgdb backtrace: (kgdb) bt #0 doadump () at pcpu.h:246 #1 0x804a4509 in db_fncall (dummy1=1, dummy2=0, dummy3=-2137208096, #dummy4=0xdc71e6fc "") at /usr/src/sys/ddb/db_command.c:548 2 #0x804a4901 in db_command (last_cmdp=0x809495bc, cmd_table=0x0, #dopager=1) at /usr/src/sys/ddb/db_command.c:445 3 0x804a4a5a in #db_command_loop () at /usr/src/sys/ddb/db_command.c:498 4 0x804a68cd #in db_trap (type=12, code=0) at /usr/src/sys/ddb/db_main.c:229 5 #0x806358e6 in kdb_trap (type=12, code=0, tf=0xdc71e924) #at /usr/src/sys/kern/subr_kdb.c:535 6 0x8086f40f in trap_fatal #(frame=0xdc71e924, eva=2322362368) #at /usr/src/sys/i386/i386/trap.c:929 7 0x8086f6b0 in trap_pfault #(frame=0xdc71e924, usermode=0, eva=2322362368) #at /usr/src/sys/i386/i386/trap.c:851 8 0x808700c3 in trap #(frame=0xdc71e924) at /usr/src/sys/i386/i386/trap.c:533 9 0x80852feb #in calltrap () at /usr/src/sys/i386/i386/exception.s:165 10 0x8086d3fe #in generic_bcopy () at /usr/src/sys/i386/i386/support.s:498 Previous frame inner to this frame (corrupt stack?) dmesg lines leading up to the panic: ugen2.2: at usbus2 umass0: on usbus2 umass0: SCSI over Bulk-Only; quirks = 0x0800 umass0:1:0:-1: Attached to scbus1 da0 at umass-sim0 bus 0 scbus1 target 0 lun 0 da0: Fixed Direct Access SCSI-0 device da0: 40.000MB/s transfers da0: 238475MB (488397168 512 byte sectors: 255H 63S/T 30401C) GEOM_JOURNAL: Journal 1159150689: da0 contains data. GEOM_JOURNAL: Journal 1159150689: da0 contains journal. GEOM_JOURNAL: Journal da0 consistent. (da0:umass-sim0:0:0:0): SYNCHRONIZE CACHE(10). CDB: 35 0 0 0 0 0 0 0 0 0 (da0:umass-sim0:0:0:0): CAM Status: SCSI Status Error (da0:umass-sim0:0:0:0): SCSI Status: Check Condition (da0:umass-sim0:0:0:0): ILLEGAL REQUEST asc:20,0 (da0:umass-sim0:0:0:0): Invalid command operation code (da0:umass-sim0:0:0:0): Unretryable error GEOM_JOURNAL: BIO_FLUSH not supported by da0. GEOM_JOURNAL: Error while reading data from da0 (error=5). GEOM_JOURNAL: Error while reading data from da0 (error=5). Any help or pointers are appreciated, thanks in advance! :-) Bye Marc From owner-freebsd-current@FreeBSD.ORG Fri Oct 30 03:49:36 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6F702106566C; Fri, 30 Oct 2009 03:49:36 +0000 (UTC) (envelope-from james-freebsd-current@jrv.org) Received: from mail.jrv.org (adsl-70-243-84-13.dsl.austtx.swbell.net [70.243.84.13]) by mx1.freebsd.org (Postfix) with ESMTP id C968B8FC21; Fri, 30 Oct 2009 03:49:35 +0000 (UTC) Received: from kremvax.housenet.jrv (kremvax.housenet.jrv [192.168.3.124]) by mail.jrv.org (8.14.3/8.14.3) with ESMTP id n9U3nXwf040791; Thu, 29 Oct 2009 22:49:34 -0500 (CDT) (envelope-from james-freebsd-current@jrv.org) Authentication-Results: mail.jrv.org; domainkeys=pass (testing) header.from=james-freebsd-current@jrv.org DomainKey-Signature: a=rsa-sha1; s=enigma; d=jrv.org; c=nofws; q=dns; h=message-id:date:from:user-agent:mime-version:to:cc:subject: content-type:content-transfer-encoding; b=Rn7jRehyjtewWF/wsJv4kvz0/NxXlVv4rsQqTeS8IRVoENR5uNylrveWBiD4t+unD 0kS/So79ztzTWkH8gH8LVpUwbrBGmaFKkx3hiNuS4OS+Dp/AUeyJLDGKnCobVXOJNjJ MAW2pWujrHTxFUiOON4twt4v8t4N8c3CB/ujgVM= Message-ID: <4AEA624D.10602@jrv.org> Date: Thu, 29 Oct 2009 22:49:33 -0500 From: "James R. Van Artsdalen" User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: FreeBSD Current Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Alexander Motin Subject: CAM/SIIS CAM_CMD_TIMEOUT hangs X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Oct 2009 03:49:36 -0000 I have problems with I/O hanging due to CAM/SIIS not handling the CAM_CMD_TIMEOUT error. Hangs happen every few hundred GB to every few TB. The disks are behind SATA port multipliers. This command un-hangs the drive and lets things run again: # camcontrol reset all I assume this is sending a soft reset to the disk drive but haven't checked yet. Is there a way xpt_done() or such might notice a CAM_CMD_TIMEOUT and inject a "soft reset" request at the head of the I/O queue (to run before the timed-out command retries)? From owner-freebsd-current@FreeBSD.ORG Fri Oct 30 07:18:10 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3F8091065670 for ; Fri, 30 Oct 2009 07:18:10 +0000 (UTC) (envelope-from ehrmann@gmail.com) Received: from mail-iw0-f189.google.com (mail-iw0-f189.google.com [209.85.223.189]) by mx1.freebsd.org (Postfix) with ESMTP id 086958FC12 for ; Fri, 30 Oct 2009 07:18:09 +0000 (UTC) Received: by iwn27 with SMTP id 27so1926681iwn.7 for ; Fri, 30 Oct 2009 00:18:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:content-type; bh=XYWNlKOV96kNECLUNbm+rePut0eTjkggmBCOVbWYPhU=; b=R03nCc61r9OmVAe3yTnogq8cT/tQ2LTRwGLK7XCTgLbQsmxoC7851X1GB2ztm/5jNj y2N4aClq3+u46FuqidNpISAZb/Vmo1V2uc93ddfoSrwg8FodG3LsRLL54B8IVlBisajt pokqDVV75w9her0wB5N0h7mubFE1odsKvWiw4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=Pr+FKL0+WtmpLIt/8cxO8vfa4Zqt4ZKW+oqhnlSyruI87WI5KKaEYsB/l6b3kM2f7K HtMsYKruSEedLLjU1k/DcUlz/sR254GCpGVBCLSHGCJxYH2zxHnHUFAy5xzzrT7Lfzvy Fir2hoJNv1TivOd59koowTl+qDWBIvEk6iMEI= MIME-Version: 1.0 Received: by 10.231.122.208 with SMTP id m16mr3458094ibr.16.1256887089213; Fri, 30 Oct 2009 00:18:09 -0700 (PDT) Date: Fri, 30 Oct 2009 00:18:09 -0700 Message-ID: <6e0e5340910300018j58a631e1r9d6d72d223621a00@mail.gmail.com> From: David Ehrmann To: freebsd-current@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Re: Strange issue with Samba and csup on 8.0rc1 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Oct 2009 07:18:10 -0000 I finally got around to restarting my machine and trying the live CD. First, with the current installation, I took vge0 down to make sure everything was going through vr0. I had the same problem, so I changed the configuration on my openwrt box, put tcpdump on it, and watched. Running csup (which regularly gave me problems), I saw two sets of packets going to the csup server, but never a reply, so each set was just four packets with the usual TCP retry falloff. It worked fine with the live cd on vr0. I rebooted, but kept the CD in. I mounted it, created some ram-backed filesystems on /cdrom/usr/src, /cdrom/tmp, and /cdrom/var/db, chrooted into /cdrom, and did the csup again. It failed, again. I diffed the csups and the libraries csup depends on; only /lib/libthr.so.3 /lib/libc.so.7 differed. They could be bad, or they could have been updated between the live CD being built and me updating. I didn't have any zfs stuff mounted, yet, so it should have been off. Here's loader.conf: padlock_load="YES" vm.kmem_size="1024M" I have seen geli and padlock (Via's on-CPU cryptographic accelerator) have issues where it decrypts wrong. Maybe csup uses FreeBSD crypto, and that takes advantage of padlock (but Samba, too?) Here's how my kernel differs from GENERIC: 79,81d78 < # for zfs < options KVA_PAGES=512 It's worth mentioning that my internet connection isn't quite stable, but I was able to get other machines to csup just fine, so unless my timing was extremely unlucky, there's something up, here. The OS is installed on flash, so I made a few changes. Here's my fstab: # Device Mountpoint FStype Options Dump Pass# /dev/ad0s1a / ufs rw 1 1 /dev/ad0s1f /usr ufs rw 2 2 # var setup /dev/ad0s1e /var ufs rw 2 2 md /var/log mfs rw,-s32M md /var/run mfs rw,-s8M md /var/msgs mfs rw,-s8M md /var/spool/clientmqueue mfs rw,-s16M # tmp md /tmp mfs rw,-s128M I have 2GB of memory, so I didn't bother with swap. I mount /var, but then put things that don't seem to be all that important (and change a lot) in mds so they don't wear the flash too much. None of them seemed *that* important, but I'm listing every weird thing about my system. Memtest said my memory is fine. Ideas? From owner-freebsd-current@FreeBSD.ORG Fri Oct 30 07:24:30 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5E3E1106568B for ; Fri, 30 Oct 2009 07:24:30 +0000 (UTC) (envelope-from ari@ish.com.au) Received: from fish.ish.com.au (eth5921.nsw.adsl.internode.on.net [59.167.240.32]) by mx1.freebsd.org (Postfix) with ESMTP id EBA108FC16 for ; Fri, 30 Oct 2009 07:24:29 +0000 (UTC) Received: from ip-149.ish.com.au ([203.29.62.149]:52808) by fish.ish.com.au with esmtpa (Exim 4.69) (envelope-from ) id 1N3lwI-0005Jq-1A; Fri, 30 Oct 2009 18:30:26 +1100 Message-ID: <4AEA94A8.8030104@ish.com.au> Date: Fri, 30 Oct 2009 18:24:24 +1100 From: Aristedes Maniatis User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.5pre) Gecko/20091025 Shredder/3.0pre MIME-Version: 1.0 To: Scot Hetzel References: <4ADE995A.8080009@ish.com.au> <1256174188.2309.22.camel@balrog.2hip.net> <4ADFCFF3.1030201@ish.com.au> <790a9fff0910220001m3d7df03j127b51d7d0696271@mail.gmail.com> In-Reply-To: <790a9fff0910220001m3d7df03j127b51d7d0696271@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: gpart, bsdlabel and fdisk X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Oct 2009 07:24:30 -0000 On 22/10/09 6:01 PM, Scot Hetzel wrote: > http://wiki.freebsd.org/RootOnZFS > > If anyone notices a problem with them, either let me know or update > the wiki page. I've got some problems when following your instructions (http://wiki.freebsd.org/RootOnZFS/GPTZFSBoot/Mirror ) 1. gpart set -a active -i 1 ad0 This throws an error: gpart: attrib active: device not configured 2. zpool create zroot mirror /dev/gpt/disk0 /dev/gpt/disk1 Those devices don't exist. /dev/ad8p3 exists and can be used. But there isn't even a /dev/gpt directory. 3. cd /dist/8.0-20090628-SNAP and then install base, catpages, etc We are using 8.0-RC2 and those folders do not exist in that location. Instead /dist contains a regular FreeBSD intallation, not install packages on the Fixit CD. Unfortunately when we work around all the above issues, the resulting installed system will not boot from the ZFS drives. Ari Maniatis -- --------------------------> ish http://www.ish.com.au Level 1, 30 Wilson Street Newtown 2042 Australia phone +61 2 9550 5001 fax +61 2 9550 4001 GPG fingerprint CBFB 84B4 738D 4E87 5E5C 5EFA EF6A 7D2E 3E49 102A From owner-freebsd-current@FreeBSD.ORG Fri Oct 30 07:53:07 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B833F106566C for ; Fri, 30 Oct 2009 07:53:07 +0000 (UTC) (envelope-from mavbsd@gmail.com) Received: from mail-bw0-f213.google.com (mail-bw0-f213.google.com [209.85.218.213]) by mx1.freebsd.org (Postfix) with ESMTP id 4302C8FC0A for ; Fri, 30 Oct 2009 07:53:06 +0000 (UTC) Received: by bwz5 with SMTP id 5so3255783bwz.3 for ; Fri, 30 Oct 2009 00:53:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :x-enigmail-version:content-type:content-transfer-encoding; bh=7RQ6y/nI6dhp+2OGCCpx1ZmTp47tavtnIeg1B/k1uxE=; b=H6VYuv0ft2IbWV5Iks02tCxOiedwYYbX7oYIEKWYrsli39obJWjjqKr6tR2GLqoVTU ExY9F0oXkYKoFI2Bhqp6QbBYG29lAIWq6rzMSSw5BRlOBgn4rj5dHo+jh9uHMcE1Uvsb b5Cwmacn9dieE1lP1Efrr8MwP9w0w+jY63ZNA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:content-type :content-transfer-encoding; b=UK8vRbCvM2L8ZIIx71D/1HAx8EUknpmhNcGVMeeHaHrhXz5dMynxsPYVsl8RvABzb7 ZHW3qF2Fx8ffB0hr7cWfU19W15xXxP+CnHgOBAC/J8pGHNs9aJVh843goKd9+RohcFMG ask2eICAvNLQuD2Nt6OlRQYpoVJVla+MQZFds= Received: by 10.103.125.23 with SMTP id c23mr485426mun.41.1256889185872; Fri, 30 Oct 2009 00:53:05 -0700 (PDT) Received: from mavbook.mavhome.dp.ua (pc.mavhome.dp.ua [212.86.226.226]) by mx.google.com with ESMTPS id s11sm2603454mue.11.2009.10.30.00.53.04 (version=SSLv3 cipher=RC4-MD5); Fri, 30 Oct 2009 00:53:05 -0700 (PDT) Sender: Alexander Motin Message-ID: <4AEA9B5E.3080402@FreeBSD.org> Date: Fri, 30 Oct 2009 09:53:02 +0200 From: Alexander Motin User-Agent: Thunderbird 2.0.0.23 (X11/20090901) MIME-Version: 1.0 To: "James R. Van Artsdalen" References: <4AEA624D.10602@jrv.org> In-Reply-To: <4AEA624D.10602@jrv.org> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: FreeBSD Current Subject: Re: CAM/SIIS CAM_CMD_TIMEOUT hangs X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Oct 2009 07:53:07 -0000 James R. Van Artsdalen wrote: > I have problems with I/O hanging due to CAM/SIIS not handling the > CAM_CMD_TIMEOUT error. > Hangs happen every few hundred GB to every few TB. > The disks are behind SATA port multipliers. > > This command un-hangs the drive and lets things run again: > > # camcontrol reset all > > I assume this is sending a soft reset to the disk drive but haven't > checked yet. > > Is there a way xpt_done() or such might notice a CAM_CMD_TIMEOUT and > inject a "soft reset" request at the head of the I/O queue (to run > before the timed-out command retries)? Try my latest patch against HEAD: http://people.freebsd.org/~mav/cam-ata.20091028.patch It does hard reset after timeout, and what is important, it reinitializes PMP after reset, to re-enable it's ports back. -- Alexander Motin From owner-freebsd-current@FreeBSD.ORG Fri Oct 30 10:25:08 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 271821065670 for ; Fri, 30 Oct 2009 10:25:08 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from mail.cksoft.de (mail.cksoft.de [195.88.108.3]) by mx1.freebsd.org (Postfix) with ESMTP id D500E8FC08 for ; Fri, 30 Oct 2009 10:25:07 +0000 (UTC) Received: from localhost (amavis.fra.cksoft.de [192.168.74.71]) by mail.cksoft.de (Postfix) with ESMTP id 67C9E41C6F2; Fri, 30 Oct 2009 11:25:06 +0100 (CET) X-Virus-Scanned: amavisd-new at cksoft.de Received: from mail.cksoft.de ([195.88.108.3]) by localhost (amavis.fra.cksoft.de [192.168.74.71]) (amavisd-new, port 10024) with ESMTP id LqxqmqpRD2Du; Fri, 30 Oct 2009 11:25:06 +0100 (CET) Received: by mail.cksoft.de (Postfix, from userid 66) id 0888041C67E; Fri, 30 Oct 2009 11:25:06 +0100 (CET) Received: from maildrop.int.zabbadoz.net (maildrop.int.zabbadoz.net [10.111.66.10]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.int.zabbadoz.net (Postfix) with ESMTP id 1A9954448E6; Fri, 30 Oct 2009 10:20:31 +0000 (UTC) Date: Fri, 30 Oct 2009 10:20:31 +0000 (UTC) From: "Bjoern A. Zeeb" X-X-Sender: bz@maildrop.int.zabbadoz.net To: "Sam Fourman Jr." In-Reply-To: <11167f520910281638o769c756am4931fbb420a6952c@mail.gmail.com> Message-ID: <20091030101929.I91695@maildrop.int.zabbadoz.net> References: <11167f520910281638o769c756am4931fbb420a6952c@mail.gmail.com> X-OpenPGP-Key: 0x14003F198FEFA3E77207EE8D2B58B8F83CCF1842 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: FreeBSD Current Subject: Re: traceroute inside FreeBSD 8.0 RC2 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Oct 2009 10:25:08 -0000 On Wed, 28 Oct 2009, Sam Fourman Jr. wrote: Hi, > dev# traceroute www.google.com > traceroute: Warning: www.google.com has multiple addresses; using 74.125.95.106 > traceroute: findsaddr: write: No such process > dev# > > security.jail.allow_raw_sockets=1 is set in sysctl.conf > > I found the problem is documented here for FreeBSD 7.2 > http://www.freebsd.org/cgi/query-pr.cgi?pr=139454 > > this is just to confirm that it happens on 8.0 RC2 as well Yes, that's known; it happens for 7.2 and anything later. /bz -- Bjoern A. Zeeb It will not break if you know what you are doing. From owner-freebsd-current@FreeBSD.ORG Fri Oct 30 10:30:07 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 43342106568B for ; Fri, 30 Oct 2009 10:30:07 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from mail.cksoft.de (mail.cksoft.de [195.88.108.3]) by mx1.freebsd.org (Postfix) with ESMTP id EF09D8FC26 for ; Fri, 30 Oct 2009 10:30:06 +0000 (UTC) Received: from localhost (amavis.fra.cksoft.de [192.168.74.71]) by mail.cksoft.de (Postfix) with ESMTP id 4417F41C71D; Fri, 30 Oct 2009 11:30:06 +0100 (CET) X-Virus-Scanned: amavisd-new at cksoft.de Received: from mail.cksoft.de ([195.88.108.3]) by localhost (amavis.fra.cksoft.de [192.168.74.71]) (amavisd-new, port 10024) with ESMTP id cYWbgdctdgFX; Fri, 30 Oct 2009 11:30:05 +0100 (CET) Received: by mail.cksoft.de (Postfix, from userid 66) id C003041C711; Fri, 30 Oct 2009 11:30:05 +0100 (CET) Received: from maildrop.int.zabbadoz.net (maildrop.int.zabbadoz.net [10.111.66.10]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.int.zabbadoz.net (Postfix) with ESMTP id 3A3374448E6; Fri, 30 Oct 2009 10:25:34 +0000 (UTC) Date: Fri, 30 Oct 2009 10:25:34 +0000 (UTC) From: "Bjoern A. Zeeb" X-X-Sender: bz@maildrop.int.zabbadoz.net To: Roman Divacky In-Reply-To: <20091029215312.GA34302@freebsd.org> Message-ID: <20091030102131.T91695@maildrop.int.zabbadoz.net> References: <20091029215312.GA34302@freebsd.org> X-OpenPGP-Key: 0x14003F198FEFA3E77207EE8D2B58B8F83CCF1842 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: FreeBSD current mailing list Subject: Re: [RFC]: m4 update X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Oct 2009 10:30:07 -0000 On Thu, 29 Oct 2009, Roman Divacky wrote: > hi > > I made a patch that updates our in-tree m4 to the version from OpenBSD. > Their version contains some gnu extensions and generally is modernized > and rewritten. > > The patch (you have to in src/usr.bin/m4 for it to apply): > > > http://vlakno.cz/~rdivacky/m4.patch > > > I added their ohash* implementation to the m4 subdir as it uses it. I > am not sure this is the correct way but it works for now. > > So the question is - do we want this at all? If so, is this the way we > want it? > > I am open to all comments, thank you! The only comment I have at this point is that this is a huge update to a somewhat fragile tool. It'll need a lot of testing before it should be comitted this way; not sure how many ports use this rather than gm4 or if they could be switched over after that. I'd at least ask portmgr for an exp run. /bz -- Bjoern A. Zeeb It will not break if you know what you are doing. From owner-freebsd-current@FreeBSD.ORG Fri Oct 30 13:08:13 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 94CF5106568D for ; Fri, 30 Oct 2009 13:08:13 +0000 (UTC) (envelope-from rnoland@FreeBSD.org) Received: from gizmo.2hip.net (gizmo.2hip.net [64.74.207.195]) by mx1.freebsd.org (Postfix) with ESMTP id 5DE698FC14 for ; Fri, 30 Oct 2009 13:08:13 +0000 (UTC) Received: from [192.168.1.4] (adsl-150-102-19.bna.bellsouth.net [72.150.102.19]) (authenticated bits=0) by gizmo.2hip.net (8.14.3/8.14.3) with ESMTP id n9UD8Au9097709 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Fri, 30 Oct 2009 09:08:11 -0400 (EDT) (envelope-from rnoland@FreeBSD.org) From: Robert Noland To: Aristedes Maniatis In-Reply-To: <4AEA94A8.8030104@ish.com.au> References: <4ADE995A.8080009@ish.com.au> <1256174188.2309.22.camel@balrog.2hip.net> <4ADFCFF3.1030201@ish.com.au> <790a9fff0910220001m3d7df03j127b51d7d0696271@mail.gmail.com> <4AEA94A8.8030104@ish.com.au> Content-Type: text/plain Organization: FreeBSD Date: Fri, 30 Oct 2009 08:08:05 -0500 Message-Id: <1256908085.39726.30.camel@balrog.2hip.net> Mime-Version: 1.0 X-Mailer: Evolution 2.26.3 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-1.8 required=5.0 tests=AWL,BAYES_00, RCVD_IN_SORBS_DUL, RDNS_DYNAMIC, SPF_SOFTFAIL autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on gizmo.2hip.net Cc: Scot Hetzel , freebsd-current@freebsd.org Subject: Re: gpart, bsdlabel and fdisk X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Oct 2009 13:08:13 -0000 On Fri, 2009-10-30 at 18:24 +1100, Aristedes Maniatis wrote: > On 22/10/09 6:01 PM, Scot Hetzel wrote: > > http://wiki.freebsd.org/RootOnZFS > > > > If anyone notices a problem with them, either let me know or update > > the wiki page. > > I've got some problems when following your instructions (http://wiki.freebsd.org/RootOnZFS/GPTZFSBoot/Mirror ) > > > 1. gpart set -a active -i 1 ad0 > > This throws an error: > gpart: attrib active: device not configured This is what I was saying... This doesn't work on GPT labeled disks. You only need to do this if your BIOS requires it. If you are using -CURRENT, it will be marked active when you install bootcode with gpart. > > 2. zpool create zroot mirror /dev/gpt/disk0 /dev/gpt/disk1 > > Those devices don't exist. /dev/ad8p3 exists and can be used. But there isn't even a /dev/gpt directory. He labeled the disks when he created the partitions. See the -l option. Using the actual dev entry or the gptid is fine though. > > 3. cd /dist/8.0-20090628-SNAP and then install base, catpages, etc > > We are using 8.0-RC2 and those folders do not exist in that location. Instead /dist contains a regular FreeBSD intallation, not install packages on the Fixit CD. > > > > Unfortunately when we work around all the above issues, the resulting installed system will not boot from the ZFS drives. What error is reported? robert. > > Ari Maniatis > -- Robert Noland FreeBSD From owner-freebsd-current@FreeBSD.ORG Fri Oct 30 13:56:02 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8D706106566B for ; Fri, 30 Oct 2009 13:56:02 +0000 (UTC) (envelope-from rdivacky@vlk.vlakno.cz) Received: from vlakno.cz (77-93-215-190.static.masterinter.net [77.93.215.190]) by mx1.freebsd.org (Postfix) with ESMTP id 472ED8FC13 for ; Fri, 30 Oct 2009 13:56:01 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by vlakno.cz (Postfix) with ESMTP id E979F9CB0EC; Fri, 30 Oct 2009 14:55:08 +0100 (CET) X-Virus-Scanned: amavisd-new at vlakno.cz Received: from vlakno.cz ([127.0.0.1]) by localhost (lev.vlakno.cz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MtCIXgU15HJn; Fri, 30 Oct 2009 14:55:06 +0100 (CET) Received: from vlk.vlakno.cz (localhost [127.0.0.1]) by vlakno.cz (Postfix) with ESMTP id 9C4DE9CB3D9; Fri, 30 Oct 2009 14:55:06 +0100 (CET) Received: (from rdivacky@localhost) by vlk.vlakno.cz (8.14.3/8.14.3/Submit) id n9UDt6EQ070120; Fri, 30 Oct 2009 14:55:06 +0100 (CET) (envelope-from rdivacky) Date: Fri, 30 Oct 2009 14:55:06 +0100 From: Roman Divacky To: "Bjoern A. Zeeb" Message-ID: <20091030135506.GA69931@freebsd.org> References: <20091029215312.GA34302@freebsd.org> <20091030102131.T91695@maildrop.int.zabbadoz.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20091030102131.T91695@maildrop.int.zabbadoz.net> User-Agent: Mutt/1.4.2.3i Cc: FreeBSD current mailing list Subject: Re: [RFC]: m4 update X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Oct 2009 13:56:02 -0000 On Fri, Oct 30, 2009 at 10:25:34AM +0000, Bjoern A. Zeeb wrote: > On Thu, 29 Oct 2009, Roman Divacky wrote: > > >hi > > > >I made a patch that updates our in-tree m4 to the version from OpenBSD. > >Their version contains some gnu extensions and generally is modernized > >and rewritten. > > > >The patch (you have to in src/usr.bin/m4 for it to apply): > > > > > > http://vlakno.cz/~rdivacky/m4.patch > > > > > >I added their ohash* implementation to the m4 subdir as it uses it. I > >am not sure this is the correct way but it works for now. > > > >So the question is - do we want this at all? If so, is this the way we > >want it? > > > >I am open to all comments, thank you! > > The only comment I have at this point is that this is a huge update to > a somewhat fragile tool. It'll need a lot of testing before it should > be comitted this way; not sure how many ports use this rather than gm4 > or if they could be switched over after that. I'd at least ask portmgr > for an exp run. yes.. I already have one exp ports build queued for unzip enabling. I also kind of hoped that people would test this patch if I announce it ;) fwiw - netbsd and openbsd use this version of m4 From owner-freebsd-current@FreeBSD.ORG Fri Oct 30 19:20:27 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EF6211065676 for ; Fri, 30 Oct 2009 19:20:26 +0000 (UTC) (envelope-from spambox@haruhiism.net) Received: from mail.haruhiism.net (remilia.fujibayashi.jp [92.243.64.6]) by mx1.freebsd.org (Postfix) with ESMTP id 6B55F8FC14 for ; Fri, 30 Oct 2009 19:20:24 +0000 (UTC) Received: from [192.168.0.10] (datacenter.telecombusinessconsulting.net [77.221.137.211]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mail.haruhiism.net (Postfix) with ESMTPSA id 9E20E10108D for ; Sat, 31 Oct 2009 04:20:21 +0900 (JST) Message-ID: <4AEB3C7E.8040801@haruhiism.net> Date: Fri, 30 Oct 2009 22:20:30 +0300 From: Kamigishi Rei User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.4pre) Gecko/20090915 Thunderbird/3.0b4 MIME-Version: 1.0 To: FreeBSD-Current Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Weird CAM-ATA behaviour (8.0-RC1): disk cloning X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Oct 2009 19:20:27 -0000 Hello, I just noticed something weird in my device list (actually, I noticed it in "glabel status" output, but then confirmed via camcontrol devlist): I got a 7th HDD, ada6, which is, surprisingly, ada0. This is how it appeared (I've checked the logs): Oct 27 01:26:38 ameagari sudo: fujibayashi : TTY=pts/3 ; PWD=/usr/home/fujibayashi ; USER=root ; COMMAND=/sbin/camcontrol rescan 0:0:1 Oct 27 01:26:38 ameagari kernel: (aprobe0:ahcich0:0:0:1): SIGNATURE: 0000 Oct 27 01:26:38 ameagari kernel: ada6 at ahcich0 bus 0 target 0 lun 1 Oct 27 01:26:38 ameagari kernel: ada6: ATA/ATAPI-8 SATA 2.x device Oct 27 01:26:38 ameagari kernel: ada6: 300.000MB/s transfers Oct 27 01:26:38 ameagari kernel: ada6: 476940MB (976773168 512 byte sectors: 16H 63S/T 16383C) Oct 27 01:26:38 ameagari kernel: ada6: Native Command Queueing enabled Oct 27 01:26:38 ameagari kernel: GEOM_MIRROR: Cannot add disk ada6 to gm0 (error=17). While I know I made a mistake there (specifying 0:0:1 instead of 1:0:0), is this behaviour really correct? I don't see why we should add a 'cloned' disk device on a rescan of LUNs that do not really exist in the first place. This is repeatable and I can create as many clones as I want (by doing "camcontrol rescan X:Y:Z" where Y and Z can vary and X is the AHCI bus number): Oct 31 04:15:55 ameagari sudo: fujibayashi : TTY=pts/3 ; PWD=/usr/src ; USER=root ; COMMAND=/sbin/camcontrol rescan 0:1:1 Oct 31 04:15:55 ameagari kernel: (aprobe0:ahcich0:0:1:1): SIGNATURE: 0000 Oct 31 04:15:55 ameagari kernel: ada7 at ahcich0 bus 0 target 1 lun 1 Oct 31 04:15:55 ameagari kernel: ada7: ATA/ATAPI-8 SATA 2.x device Oct 31 04:15:55 ameagari kernel: ada7: 300.000MB/s transfers Oct 31 04:15:55 ameagari kernel: ada7: 476940MB (976773168 512 byte sectors: 16H 63S/T 16383C) Oct 31 04:15:55 ameagari kernel: ada7: Native Command Queueing enabled Oct 31 04:15:55 ameagari kernel: GEOM_MIRROR: Cannot add disk ada7 to gm0 (error=17). Oct 31 04:15:55 ameagari kernel: GEOM: ada7s1: geometry does not match label (255h,63s != 16h,63s). Here's camcontrol output before rescan of 0:1:1: fujibayashi@ameagari /usr/src % sudo camcontrol devlist -v scbus0 on ahcich0 bus 0: at scbus0 target 0 lun 0 (pass0,ada0) at scbus0 target 0 lun 1 (ada6,pass6) <> at scbus0 target -1 lun -1 () scbus1 on ahcich1 bus 0: at scbus1 target 0 lun 0 (pass1,ada1) <> at scbus1 target -1 lun -1 () scbus2 on ahcich2 bus 0: at scbus2 target 0 lun 0 (pass2,ada2) <> at scbus2 target -1 lun -1 () scbus3 on ahcich3 bus 0: at scbus3 target 0 lun 0 (pass3,ada3) <> at scbus3 target -1 lun -1 () scbus4 on ahcich4 bus 0: at scbus4 target 0 lun 0 (pass4,ada4) <> at scbus4 target -1 lun -1 () scbus5 on ahcich5 bus 0: at scbus5 target 0 lun 0 (pass5,ada5) <> at scbus5 target -1 lun -1 () scbus-1 on xpt0 bus 0: <> at scbus-1 target -1 lun -1 (xpt0) fujibayashi@ameagari /usr/src % uname -a FreeBSD ameagari.fujibayashi.jp 8.0-RC1 FreeBSD 8.0-RC1 #29 r198327: Fri Oct 23 05:29:41 JST 2009 root@ameagari.fujibayashi.jp:/usr/obj/usr/src/sys/Ameagari amd64 -- Kamigishi Rei KREI-RIPE From owner-freebsd-current@FreeBSD.ORG Fri Oct 30 20:09:02 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 43CBF1065697; Fri, 30 Oct 2009 20:09:02 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from esa-annu.mail.uoguelph.ca (esa-annu.mail.uoguelph.ca [131.104.91.36]) by mx1.freebsd.org (Postfix) with ESMTP id B10AE8FC16; Fri, 30 Oct 2009 20:09:01 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAPfk6kqDaFvK/2dsb2JhbADge4Q9BIFi X-IronPort-AV: E=Sophos;i="4.44,655,1249272000"; d="scan'208";a="51868984" Received: from fraser.cs.uoguelph.ca ([131.104.91.202]) by esa-annu-pri.mail.uoguelph.ca with ESMTP; 30 Oct 2009 16:09:00 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by fraser.cs.uoguelph.ca (Postfix) with ESMTP id C9F1A109C2CF; Fri, 30 Oct 2009 16:09:00 -0400 (EDT) X-Virus-Scanned: amavisd-new at fraser.cs.uoguelph.ca Received: from fraser.cs.uoguelph.ca ([127.0.0.1]) by localhost (fraser.cs.uoguelph.ca [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LXlBgRckm0Tn; Fri, 30 Oct 2009 16:09:00 -0400 (EDT) Received: from muncher.cs.uoguelph.ca (muncher.cs.uoguelph.ca [131.104.91.102]) by fraser.cs.uoguelph.ca (Postfix) with ESMTP id 25BB2109C257; Fri, 30 Oct 2009 16:09:00 -0400 (EDT) Received: from localhost (rmacklem@localhost) by muncher.cs.uoguelph.ca (8.11.7p3+Sun/8.11.6) with ESMTP id n9UKGCP29254; Fri, 30 Oct 2009 16:16:13 -0400 (EDT) X-Authentication-Warning: muncher.cs.uoguelph.ca: rmacklem owned process doing -bs Date: Fri, 30 Oct 2009 16:16:12 -0400 (EDT) From: Rick Macklem X-X-Sender: rmacklem@muncher.cs.uoguelph.ca To: Olaf Seibert In-Reply-To: <20091029135239.GX841@twoquid.cs.ru.nl> Message-ID: References: <20091027164159.GU841@twoquid.cs.ru.nl> <20091029135239.GX841@twoquid.cs.ru.nl> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: dfr@freebsd.org, freebsd-current@freebsd.org, freebsd-stable@freebsd.org Subject: Re: 8.0-RC1 NFS client timeout issue X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Oct 2009 20:09:02 -0000 On Thu, 29 Oct 2009, Olaf Seibert wrote: > > After writing, I realised that it is indeed perfectly allowed for the > client to send data. But since the server already sent its FIN, it can't > send anything more, not even an error message. So with that in mind, the > client shouldn't send anything any more either. > Here is what I am seeing without and with the patch. The client is a pretty recent FreeBSD-CURRENT (nfsv4-test) and the server Solaris10 (nfsv4-solaris). I don't get the 5 minute reconnect delay without the patch. I think the reason is that the resets (Rst's) "inspire" the FreeBSD-CURRENT TCP to do the new connection. (I don't remember seeing any RSTs in your tcpdump?) I deleted a few irrelevant lines (packets not between nfsv4-test and nfsv4-solaris), which is why the packet #s aren't contiguous. (and appologies for the long lines) Hopefully someone with TCP expertise will know if the RSTs are done correctly and whether or not your server should be generating them. After the patch things look fine to me. Hopefully your (and others) testing will go ok. Snoop trace without the patch (what FreeBSD-CURRENT will do now): 2 209.18617 nfsv4-solaris -> nfsv4-test.cis.uoguelph.ca TCP D=699 S=2049 Fin Ack=1066292217 Seq=1580479914 Len=0 Win=49232 Options= 3 209.18645 nfsv4-test.cis.uoguelph.ca -> nfsv4-solaris TCP D=2049 S=699 Ack=1580479915 Seq=1066292217 Len=0 Win=16588 Options= 4 209.18656 nfsv4-test.cis.uoguelph.ca -> nfsv4-solaris TCP D=2049 S=699 Rst Ack=1580479915 Seq=1066292217 Len=0 Win=0 5 209.18662 nfsv4-test.cis.uoguelph.ca -> nfsv4-solaris TCP D=2049 S=699 Rst Ack=1580479915 Seq=1066292217 Len=0 Win=0 7 528.97250 nfsv4-test.cis.uoguelph.ca -> nfsv4-solaris NFS C FSSTAT3 FH=9D01 8 528.97261 nfsv4-solaris -> nfsv4-test.cis.uoguelph.ca TCP D=699 S=2049 Rst Seq=1580479915 Len=0 Win=0 9 528.97311 nfsv4-test.cis.uoguelph.ca -> nfsv4-solaris TCP D=2049 S=818 Syn Seq=3293207355 Len=0 Win=65535 Options= 10 528.97329 nfsv4-solaris -> nfsv4-test.cis.uoguelph.ca TCP D=818 S=2049 Syn Ack=3293207356 Seq=1757551152 Len=0 Win=49232 Options= 11 528.97354 nfsv4-test.cis.uoguelph.ca -> nfsv4-solaris TCP D=2049 S=818 Ack=1757551153 Seq=3293207356 Len=0 Win=8326 Options= 12 528.97375 nfsv4-test.cis.uoguelph.ca -> nfsv4-solaris NFS C FSSTAT3 FH=9D01 13 528.97382 nfsv4-test.cis.uoguelph.ca -> nfsv4-solaris TCP D=2049 S=818 Rst Ack=1757551153 Seq=3293207356 Len=0 Win=0 14 528.97439 nfsv4-solaris -> nfsv4-test.cis.uoguelph.ca TCP D=818 S=2049 Ack=3293207488 Seq=1757551153 Len=0 Win=49100 Options= 15 528.97524 nfsv4-solaris -> nfsv4-test.cis.uoguelph.ca NFS R FSSTAT3 OK 16 529.07565 nfsv4-test.cis.uoguelph.ca -> nfsv4-solaris TCP D=2049 S=818 Ack=1757551325 Seq=3293207488 Len=0 Win=16588 Options= and what happens after the patch is applied: 6 1.35481 nfsv4-test.cis.uoguelph.ca -> nfsv4-solaris NFS C FSSTAT3 FH=9D01 7 1.35516 nfsv4-solaris -> nfsv4-test.cis.uoguelph.ca NFS R FSSTAT3 OK 8 1.45564 nfsv4-test.cis.uoguelph.ca -> nfsv4-solaris TCP D=2049 S=651 Ack=2612339569 Seq=837212133 Len=0 Win=16588 Options= 9 361.34400 nfsv4-solaris -> nfsv4-test.cis.uoguelph.ca TCP D=651 S=2049 Fin Ack=837212133 Seq=2612339569 Len=0 Win=49232 Options= 10 361.34434 nfsv4-test.cis.uoguelph.ca -> nfsv4-solaris TCP D=2049 S=651 Ack=2612339570 Seq=837212133 Len=0 Win=16588 Options= 11 361.34441 nfsv4-test.cis.uoguelph.ca -> nfsv4-solaris TCP D=2049 S=651 Rst Ack=2612339570 Seq=837212133 Len=0 Win=0 12 361.34447 nfsv4-test.cis.uoguelph.ca -> nfsv4-solaris TCP D=2049 S=651 Rst Ack=2612339570 Seq=837212133 Len=0 Win=0 14 501.80966 nfsv4-test.cis.uoguelph.ca -> nfsv4-solaris TCP D=2049 S=881 Syn Seq=1926848102 Len=0 Win=65535 Options= 15 501.80979 nfsv4-solaris -> nfsv4-test.cis.uoguelph.ca TCP D=881 S=2049 Syn Ack=1926848103 Seq=2754679721 Len=0 Win=49232 Options= 16 501.81006 nfsv4-test.cis.uoguelph.ca -> nfsv4-solaris TCP D=2049 S=881 Ack=2754679722 Seq=1926848103 Len=0 Win=8326 Options= 17 501.81024 nfsv4-test.cis.uoguelph.ca -> nfsv4-solaris NFS C FSSTAT3 FH=9D01 18 501.81089 nfsv4-solaris -> nfsv4-test.cis.uoguelph.ca TCP D=881 S=2049 Ack=1926848235 Seq=2754679722 Len=0 Win=49100 Options= 19 501.81169 nfsv4-solaris -> nfsv4-test.cis.uoguelph.ca NFS R FSSTAT3 OK 20 501.91218 nfsv4-test.cis.uoguelph.ca -> nfsv4-solaris TCP D=2049 S=881 Ack=2754679894 Seq=1926848235 Len=0 Win=16588 Options= Anyone with TCP expertise have opinions on these? rick From owner-freebsd-current@FreeBSD.ORG Sat Oct 31 00:05:13 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BFC87106568D for ; Sat, 31 Oct 2009 00:05:13 +0000 (UTC) (envelope-from a_best01@uni-muenster.de) Received: from zivm-exrelay3.uni-muenster.de (ZIVM-EXRELAY3.UNI-MUENSTER.DE [128.176.192.20]) by mx1.freebsd.org (Postfix) with ESMTP id 557758FC25 for ; Sat, 31 Oct 2009 00:05:12 +0000 (UTC) X-IronPort-AV: E=Sophos;i="4.44,657,1249250400"; d="scan'208";a="17233768" Received: from zivmaildisp1.uni-muenster.de (HELO ZIVMAILUSER04.UNI-MUENSTER.DE) ([128.176.188.85]) by zivm-relay3.uni-muenster.de with ESMTP; 31 Oct 2009 01:05:11 +0100 Received: by ZIVMAILUSER04.UNI-MUENSTER.DE (Postfix, from userid 149459) id 7F9FC1B07BE; Sat, 31 Oct 2009 01:05:11 +0100 (CET) Date: Sat, 31 Oct 2009 01:05:11 +0100 (CET) From: Alexander Best Sender: Organization: Westfaelische Wilhelms-Universitaet Muenster To: Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: 8.0-RC2 mangles msdosfs X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 31 Oct 2009 00:05:13 -0000 i've experienced similar issues with msdosfs. it seems especially /sbin/fsck_msdosfs needs some updating. cheers. alex From owner-freebsd-current@FreeBSD.ORG Sat Oct 31 01:26:40 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4462D106566C for ; Sat, 31 Oct 2009 01:26:40 +0000 (UTC) (envelope-from mlobo@digiart.art.br) Received: from sv4.hmnoc.net (sv4.hmnoc.net [63.247.76.174]) by mx1.freebsd.org (Postfix) with ESMTP id 0D31F8FC16 for ; Sat, 31 Oct 2009 01:26:39 +0000 (UTC) Received: from [187.78.149.206] (port=64915 helo=papi.localnet) by sv4.hmnoc.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1N42jm-0004Qq-OU for freebsd-current@freebsd.org; Fri, 30 Oct 2009 23:26:39 -0200 From: Mario Lobo To: freebsd-current@freebsd.org Date: Fri, 30 Oct 2009 22:26:12 -0300 User-Agent: KMail/1.12.1 (FreeBSD/8.0-RC1; KDE/4.3.1; amd64; ; ) MIME-Version: 1.0 Content-Type: Multipart/Mixed; boundary="Boundary-00=_0I56KLXnoCaS443" Message-Id: <200910302226.12729.mlobo@digiart.art.br> X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - sv4.hmnoc.net X-AntiAbuse: Original Domain - freebsd.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - digiart.art.br Subject: Patch for amdtemp X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 31 Oct 2009 01:26:40 -0000 --Boundary-00=_0I56KLXnoCaS443 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi; Recently I bought a Phenom II quad and I noticed that amdtemp.ko only displayed 2 temp sysctl values. I started digging the net for some clues and I found a patch from a guy (sorry, don't remember his name any longer) that changed amdtemp for his 3 core amd cpu. I expanded HIS idea to 4 cores and it worked fine, so I'm submitting the patch for testing by other members. [~]>sysctl -a | grep temp hw.usb.template: 0 dev.amdtemp.0.%desc: AMD K8 Thermal Sensors dev.amdtemp.0.%driver: amdtemp dev.amdtemp.0.%parent: hostb4 dev.cpu.0.temperature: 48.0C dev.cpu.1.temperature: 48.0C dev.cpu.2.temperature: 48.0C dev.cpu.3.temperature: 47.8C Since I know before hand how many cores my cpu has, I changed the code for the exact amount of cores but maybe there is a way to detect how many cores the CPU has before creating the sysctl variables. BW -- Mario Lobo http://www.mallavoodoo.com.br FreeBSD since version 2.2.8 [not Pro-Audio.... YET!!] (99,7% winedows FREE) --Boundary-00=_0I56KLXnoCaS443 Content-Type: text/x-patch; charset="ISO-8859-1"; name="amdtemp.c.diff" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="amdtemp.c.diff" --- amdtemp.c.ori 2009-08-20 17:23:28.000000000 -0300 +++ amdtemp.c.new 2009-10-04 22:42:03.000000000 -0300 @@ -52,10 +52,16 @@ typedef enum { SENSOR0_CORE0, SENSOR0_CORE1, + SENSOR0_CORE2, + SENSOR0_CORE3, SENSOR1_CORE0, SENSOR1_CORE1, + SENSOR1_CORE2, + SENSOR1_CORE3, CORE0, - CORE1 + CORE1, + CORE2, + CORE3 } amdsensor_t; struct amdtemp_softc { @@ -63,7 +69,7 @@ int sc_temps[4]; int sc_ntemps; struct sysctl_oid *sc_oid; - struct sysctl_oid *sc_sysctl_cpu[2]; + struct sysctl_oid *sc_sysctl_cpu[4]; struct intr_config_hook sc_ich; int32_t (*sc_gettemp)(device_t, amdsensor_t); }; @@ -236,7 +242,19 @@ dev, SENSOR0_CORE1, amdtemp_sysctl, "IK", "Sensor 0 / Core 1 temperature"); - sysctlnode = SYSCTL_ADD_NODE(sysctlctx, + SYSCTL_ADD_PROC(sysctlctx, + SYSCTL_CHILDREN(sysctlnode), + OID_AUTO, "core2", CTLTYPE_INT | CTLFLAG_RD, + dev, SENSOR0_CORE2, amdtemp_sysctl, "IK", + "Sensor 0 / Core 2 temperature"); + + SYSCTL_ADD_PROC(sysctlctx, + SYSCTL_CHILDREN(sysctlnode), + OID_AUTO, "core3", CTLTYPE_INT | CTLFLAG_RD, + dev, SENSOR0_CORE3, amdtemp_sysctl, "IK", + "Sensor 0 / Core 3 temperature"); + + sysctlnode = SYSCTL_ADD_NODE(sysctlctx, SYSCTL_CHILDREN(device_get_sysctl_tree(dev)), OID_AUTO, "sensor1", CTLFLAG_RD, 0, "Sensor 1"); @@ -252,7 +270,19 @@ dev, SENSOR1_CORE1, amdtemp_sysctl, "IK", "Sensor 1 / Core 1 temperature"); - return (0); + SYSCTL_ADD_PROC(sysctlctx, + SYSCTL_CHILDREN(sysctlnode), + OID_AUTO, "core2", CTLTYPE_INT | CTLFLAG_RD, + dev, SENSOR1_CORE2, amdtemp_sysctl, "IK", + "Sensor 1 / Core 2 temperature"); + + SYSCTL_ADD_PROC(sysctlctx, + SYSCTL_CHILDREN(sysctlnode), + OID_AUTO, "core3", CTLTYPE_INT | CTLFLAG_RD, + dev, SENSOR1_CORE3, amdtemp_sysctl, "IK", + "Sensor 1 / Core 3 temperature"); + + return (0); } void @@ -272,7 +302,7 @@ nexus = device_find_child(root_bus, "nexus", 0); acpi = device_find_child(nexus, "acpi", 0); - for (i = 0; i < 2; i++) { + for (i = 0; i < 4; i++) { cpu = device_find_child(acpi, "cpu", device_get_unit(dev) * 2 + i); if (cpu) { @@ -323,6 +353,16 @@ auxtemp[1] = sc->sc_gettemp(dev, SENSOR1_CORE1); temp = imax(auxtemp[0], auxtemp[1]); break; + case CORE2: + auxtemp[0] = sc->sc_gettemp(dev, SENSOR0_CORE2); + auxtemp[1] = sc->sc_gettemp(dev, SENSOR1_CORE2); + temp = imax(auxtemp[0], auxtemp[1]); + break; + case CORE3: + auxtemp[0] = sc->sc_gettemp(dev, SENSOR0_CORE3); + auxtemp[1] = sc->sc_gettemp(dev, SENSOR1_CORE3); + temp = imax(auxtemp[0], auxtemp[1]); + break; default: temp = sc->sc_gettemp(dev, arg2); break; @@ -347,6 +387,14 @@ cfg &= ~AMDTEMP_REG_SELSENSOR; cfg |= AMDTEMP_REG_SELCORE; break; + case SENSOR0_CORE2: + cfg &= ~AMDTEMP_REG_SELSENSOR; + cfg |= AMDTEMP_REG_SELCORE; + break; + case SENSOR0_CORE3: + cfg &= ~AMDTEMP_REG_SELSENSOR; + cfg |= AMDTEMP_REG_SELCORE; + break; case SENSOR1_CORE0: cfg &= ~AMDTEMP_REG_SELCORE; cfg |= AMDTEMP_REG_SELSENSOR; @@ -354,6 +402,12 @@ case SENSOR1_CORE1: cfg |= (AMDTEMP_REG_SELSENSOR | AMDTEMP_REG_SELCORE); break; + case SENSOR1_CORE2: + cfg |= (AMDTEMP_REG_SELSENSOR | AMDTEMP_REG_SELCORE); + break; + case SENSOR1_CORE3: + cfg |= (AMDTEMP_REG_SELSENSOR | AMDTEMP_REG_SELCORE); + break; default: cfg = 0; break; --Boundary-00=_0I56KLXnoCaS443-- From owner-freebsd-current@FreeBSD.ORG Sat Oct 31 01:31:31 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 05D40106568D for ; Sat, 31 Oct 2009 01:31:31 +0000 (UTC) (envelope-from a_best01@uni-muenster.de) Received: from zivm-exrelay2.uni-muenster.de (ZIVM-EXRELAY2.UNI-MUENSTER.DE [128.176.192.15]) by mx1.freebsd.org (Postfix) with ESMTP id 908428FC1D for ; Sat, 31 Oct 2009 01:31:30 +0000 (UTC) X-IronPort-AV: E=Sophos;i="4.44,657,1249250400"; d="scan'208";a="227685899" Received: from zivmaildisp1.uni-muenster.de (HELO ZIVMAILUSER04.UNI-MUENSTER.DE) ([128.176.188.85]) by zivm-relay2.uni-muenster.de with ESMTP; 31 Oct 2009 02:31:29 +0100 Received: by ZIVMAILUSER04.UNI-MUENSTER.DE (Postfix, from userid 149459) id F21291B07BE; Sat, 31 Oct 2009 02:31:28 +0100 (CET) Date: Sat, 31 Oct 2009 02:31:28 +0100 (CET) From: Alexander Best Sender: Organization: Westfaelische Wilhelms-Universitaet Muenster To: Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: Subject: fdisk: unable to get correct path for /: Inappropriate file type or format X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 31 Oct 2009 01:31:31 -0000 hi there, i'm gettings fdisk: unable to get correct path for /: Inappropriate file type or format under FreeBSD otaku 9.0-CURRENT FreeBSD 9.0-CURRENT #0 r198677: Fri Oct 30 18:27:50 CET 2009 root@otaku:/usr/obj/usr/src/sys/ARUNDEL i386 `mount`: /dev/label/rootfs on / (ufs, local, noatime, soft-updates) devfs on /dev (devfs, local) /dev/label/usr on /usr (ufs, local, noatime, soft-updates) procfs on /proc (procfs, local) linprocfs on /usr/compat/linux/proc (linprocfs, local) linsysfs on /usr/compat/linux/sys (linsysfs, local) devfs on /usr/compat/linux/dev (devfs, local) linprocfs on /usr/local/gentoo-stage3/proc (linprocfs, local) linsysfs on /usr/local/gentoo-stage3/sys (linsysfs, local) devfs on /usr/local/gentoo-stage3/dev (devfs, local) /dev/md0 on /tmp (ufs, local) `mount -p`: /dev/label/rootfs / ufs noatime 1 1 devfs /dev devfs rw 0 0 /dev/label/usr /usr ufs noatime 1 1 procfs /proc procfs rw 0 0 linprocfs /usr/compat/linux/proc linprocfs rw 0 0 linsysfs /usr/compat/linux/sys linsysfs rw 0 0 devfs /usr/compat/linux/dev devfs rw 0 0 linprocfs /usr/local/gentoo-stage3/proc linprocfs rw 0 0 linsysfs /usr/local/gentoo-stage3/sys linsysfs rw 0 0 devfs /usr/local/gentoo-stage3/dev devfs rw 0 0 /dev/md0 /tmp ufs rw 0 0 `gpart list`: Geom name: ad0 fwheads: 16 fwsectors: 63 last: 321672926 first: 34 entries: 128 scheme: GPT Providers: 1. Name: ad0p1 Mediasize: 65536 (64K) Sectorsize: 512 Mode: r0w0e0 rawtype: 83bd6b9d-7f41-11dc-be0b-001560b84f0f label: boot length: 65536 offset: 17408 type: freebsd-boot index: 1 end: 161 start: 34 2. Name: ad0p2 Mediasize: 164696455680 (153G) Sectorsize: 512 Mode: r1w1e2 rawtype: 516e7cb6-6ecf-11d6-8ff8-00022d09712b label: rootfs length: 164696455680 offset: 82944 type: freebsd-ufs index: 2 end: 321672926 start: 162 Consumers: 1. Name: ad0 Mediasize: 164696555520 (153G) Sectorsize: 512 Mode: r1w1e3 Geom name: ada0 fwheads: 16 fwsectors: 63 last: 488395021 first: 34 entries: 128 scheme: GPT Providers: 1. Name: ada0p1 Mediasize: 10737400832 (10G) Sectorsize: 512 Mode: r1w1e1 rawtype: 516e7cb5-6ecf-11d6-8ff8-00022d09712b label: swap length: 10737400832 offset: 17408 type: freebsd-swap index: 1 end: 20971519 start: 34 2. Name: ada0p2 Mediasize: 239320833024 (223G) Sectorsize: 512 Mode: r1w1e2 rawtype: 516e7cb6-6ecf-11d6-8ff8-00022d09712b label: usr length: 239320833024 offset: 10737418240 type: freebsd-ufs index: 2 end: 488395021 start: 20971520 Consumers: 1. Name: ada0 Mediasize: 250058268160 (233G) Sectorsize: 512 Mode: r2w2e5 cheers. alex From owner-freebsd-current@FreeBSD.ORG Sat Oct 31 06:49:32 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5E66D106568B; Sat, 31 Oct 2009 06:49:32 +0000 (UTC) (envelope-from mavbsd@gmail.com) Received: from mail-bw0-f213.google.com (mail-bw0-f213.google.com [209.85.218.213]) by mx1.freebsd.org (Postfix) with ESMTP id B2F5C8FC1C; Sat, 31 Oct 2009 06:49:31 +0000 (UTC) Received: by bwz5 with SMTP id 5so4405052bwz.3 for ; Fri, 30 Oct 2009 23:49:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=QjZMv07uJIMg5m1r3qo/nQavXE/jJu8ZPeBQQOs71eM=; b=HBF7pVily4i3Zt0/e7vD8qDNZaqQfxOLARzhM5oEjzLs790XFoA1d3qLrWvcyCSrw6 ZapZzCkb/S8fDYslEfwUmm/XudxFNCclrzcK0fe/Y5Yul2yHtuHgv/9rWlD6jhFFBffs iBS/IoEyrWBVDfHftGsefMbwkjqOIrn75YKhk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=vWbEPuFqpsGngtz8WmuK+htFv3zvEU6U9bVkdUrNPWNIMBOCc6PeegXqk9wPoLSSsd XJHXt3Dv5c2sGlYe2IuIxx/NNgY2wdxY9Lhhvs6nrEwdmBS9ZYvvpaClwWAIB6uDGUXU KPz8jK+VPttpbtjuFlAlFGem6hzEOUqlSzstY= Received: by 10.103.86.23 with SMTP id o23mr996569mul.116.1256971770790; Fri, 30 Oct 2009 23:49:30 -0700 (PDT) Received: from mavbook.mavhome.dp.ua (pc.mavhome.dp.ua [212.86.226.226]) by mx.google.com with ESMTPS id y6sm3096746mug.10.2009.10.30.23.49.29 (version=SSLv3 cipher=RC4-MD5); Fri, 30 Oct 2009 23:49:30 -0700 (PDT) Sender: Alexander Motin Message-ID: <4AEBDDF8.8060609@FreeBSD.org> Date: Sat, 31 Oct 2009 08:49:28 +0200 From: Alexander Motin User-Agent: Thunderbird 2.0.0.23 (X11/20090901) MIME-Version: 1.0 To: Kamigishi Rei References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: FreeBSD-Current , Scott Long Subject: Re: Weird CAM-ATA behaviour (8.0-RC1): disk cloning X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 31 Oct 2009 06:49:32 -0000 Kamigishi Rei wrote: > I just noticed something weird in my device list (actually, I noticed it > in "glabel status" output, but then confirmed via camcontrol devlist): I > got a 7th HDD, ada6, which is, surprisingly, ada0. > > This is how it appeared (I've checked the logs): > > Oct 27 01:26:38 ameagari sudo: fujibayashi : TTY=pts/3 ; > PWD=/usr/home/fujibayashi ; USER=root ; COMMAND=/sbin/camcontrol rescan > 0:0:1 > Oct 27 01:26:38 ameagari kernel: (aprobe0:ahcich0:0:0:1): SIGNATURE: 0000 > Oct 27 01:26:38 ameagari kernel: ada6 at ahcich0 bus 0 target 0 lun 1 > Oct 27 01:26:38 ameagari kernel: ada6: ATA/ATAPI-8 > SATA 2.x device > Oct 27 01:26:38 ameagari kernel: ada6: 300.000MB/s transfers > Oct 27 01:26:38 ameagari kernel: ada6: 476940MB (976773168 512 byte > sectors: 16H 63S/T 16383C) > Oct 27 01:26:38 ameagari kernel: ada6: Native Command Queueing enabled > Oct 27 01:26:38 ameagari kernel: GEOM_MIRROR: Cannot add disk ada6 to > gm0 (error=17). > > While I know I made a mistake there (specifying 0:0:1 instead of 1:0:0), > is this behaviour really correct? I don't see why we should add a > 'cloned' disk device on a rescan of LUNs that do not really exist in the > first place. > > This is repeatable and I can create as many clones as I want (by doing > "camcontrol rescan X:Y:Z" where Y and Z can vary and X is the AHCI bus > number): Interesting effect. CAM ATA implementation doesn't use LUNs, in fact it ignores them. Also you may scan PMP port's target IDs when not PMP present with alike effect, as without PMP present nobody handles FIS port field. Probably we need some per-bus local storage (at SIM or may be XPT) to keep device's current status, reported by PMP driver. Thank you. -- Alexander Motin From owner-freebsd-current@FreeBSD.ORG Sat Oct 31 07:39:38 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CBA4D106566B; Sat, 31 Oct 2009 07:39:38 +0000 (UTC) (envelope-from mavbsd@gmail.com) Received: from mail-bw0-f213.google.com (mail-bw0-f213.google.com [209.85.218.213]) by mx1.freebsd.org (Postfix) with ESMTP id 2E0498FC19; Sat, 31 Oct 2009 07:39:37 +0000 (UTC) Received: by bwz5 with SMTP id 5so4426256bwz.3 for ; Sat, 31 Oct 2009 00:39:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :x-enigmail-version:content-type:content-transfer-encoding; bh=h8oHvHbjpLC/V1Ig/HZg3/ESdd/aIN1byN55ToKbZ2o=; b=nocwIHm3IJpGfi4WXSKg1VdtLQw5NlcJi/A0A9+HnEXaqAFZYePSbn0Y6XSxvfPVDK rLpXv/2HfGj5FBfzXfL+A8jPpBqWZUYWxM7Sj4FDPaWysM81oDnOIpVaZJqTy8MMF9vd WQOQVmb+aKLtGiaGC4xZ7U7fniNI4HROIKCWA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:content-type :content-transfer-encoding; b=sLgLRUpbUm6r6QSbYeZJO0yXerwNXGBE+ntE8wMwjBc98PsTSgZo00qYOB4xQSaq6A o+HJ2RA6oz0oexC0OA6LMEA/LsmGajPfWUpNuGZw1OqY2q7OKzdlTKtcib8seftGlbu2 g2K8uAMgkLKXmwBUYpJWMwqn92z3MHo+RVm1E= Received: by 10.103.78.22 with SMTP id f22mr1048160mul.14.1256974777077; Sat, 31 Oct 2009 00:39:37 -0700 (PDT) Received: from mavbook.mavhome.dp.ua (pc.mavhome.dp.ua [212.86.226.226]) by mx.google.com with ESMTPS id n7sm2516634mue.27.2009.10.31.00.39.36 (version=SSLv3 cipher=RC4-MD5); Sat, 31 Oct 2009 00:39:36 -0700 (PDT) Sender: Alexander Motin Message-ID: <4AEBE9B6.6050007@FreeBSD.org> Date: Sat, 31 Oct 2009 09:39:34 +0200 From: Alexander Motin User-Agent: Thunderbird 2.0.0.23 (X11/20090901) MIME-Version: 1.0 To: Kamigishi Rei References: <4AEBDDF8.8060609@FreeBSD.org> In-Reply-To: <4AEBDDF8.8060609@FreeBSD.org> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: FreeBSD-Current , Scott Long Subject: Re: Weird CAM-ATA behaviour (8.0-RC1): disk cloning X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 31 Oct 2009 07:39:39 -0000 Alexander Motin wrote: > Kamigishi Rei wrote: >> I just noticed something weird in my device list (actually, I noticed it >> in "glabel status" output, but then confirmed via camcontrol devlist): I >> got a 7th HDD, ada6, which is, surprisingly, ada0. >> >> This is how it appeared (I've checked the logs): >> >> Oct 27 01:26:38 ameagari sudo: fujibayashi : TTY=pts/3 ; >> PWD=/usr/home/fujibayashi ; USER=root ; COMMAND=/sbin/camcontrol rescan >> 0:0:1 >> Oct 27 01:26:38 ameagari kernel: (aprobe0:ahcich0:0:0:1): SIGNATURE: 0000 >> Oct 27 01:26:38 ameagari kernel: ada6 at ahcich0 bus 0 target 0 lun 1 >> Oct 27 01:26:38 ameagari kernel: ada6: ATA/ATAPI-8 >> SATA 2.x device >> Oct 27 01:26:38 ameagari kernel: ada6: 300.000MB/s transfers >> Oct 27 01:26:38 ameagari kernel: ada6: 476940MB (976773168 512 byte >> sectors: 16H 63S/T 16383C) >> Oct 27 01:26:38 ameagari kernel: ada6: Native Command Queueing enabled >> Oct 27 01:26:38 ameagari kernel: GEOM_MIRROR: Cannot add disk ada6 to >> gm0 (error=17). >> >> While I know I made a mistake there (specifying 0:0:1 instead of 1:0:0), >> is this behaviour really correct? I don't see why we should add a >> 'cloned' disk device on a rescan of LUNs that do not really exist in the >> first place. >> >> This is repeatable and I can create as many clones as I want (by doing >> "camcontrol rescan X:Y:Z" where Y and Z can vary and X is the AHCI bus >> number): > > Interesting effect. By the way it is not an ATA-specific problem. Here is ahc SCSI: %camcontrol devlist at scbus0 target 1 lun 0 (sa0,pass0) at scbus0 target 1 lun 256 (pass3,sa2) at scbus0 target 17 lun 0 (pass2,sa1) -- Alexander Motin From owner-freebsd-current@FreeBSD.ORG Sat Oct 31 08:51:51 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EF9E7106566B for ; Sat, 31 Oct 2009 08:51:51 +0000 (UTC) (envelope-from kamikaze@bsdforen.de) Received: from mail.bsdforen.de (bsdforen.de [212.204.60.79]) by mx1.freebsd.org (Postfix) with ESMTP id 7ABCD8FC1B for ; Sat, 31 Oct 2009 08:51:51 +0000 (UTC) Received: from mobileKamikaze.norad (unknown [88.130.205.86]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.bsdforen.de (Postfix) with ESMTP id CC9B68A0DDD; Sat, 31 Oct 2009 09:51:49 +0100 (CET) Message-ID: <4AEBFAA3.9020003@bsdforen.de> Date: Sat, 31 Oct 2009 09:51:47 +0100 From: Dominic Fandrey User-Agent: Thunderbird 2.0.0.23 (X11/20091024) MIME-Version: 1.0 To: Alexander Best References: In-Reply-To: X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: 8.0-RC2 mangles msdosfs X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 31 Oct 2009 08:51:52 -0000 Alexander Best wrote: > i've experienced similar issues with msdosfs. it seems especially > /sbin/fsck_msdosfs needs some updating. > > cheers. > alex Not only that, write access is really broken. -- A: Because it fouls the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing on usenet and in e-mail? From owner-freebsd-current@FreeBSD.ORG Sat Oct 31 09:16:35 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 97D30106566C; Sat, 31 Oct 2009 09:16:35 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from kabab.cs.huji.ac.il (kabab.cs.huji.ac.il [132.65.16.84]) by mx1.freebsd.org (Postfix) with ESMTP id 4964A8FC0C; Sat, 31 Oct 2009 09:16:35 +0000 (UTC) Received: from pampa.cs.huji.ac.il ([132.65.80.32]) by kabab.cs.huji.ac.il with esmtp id 1N4A4U-000Ay9-Kc; Sat, 31 Oct 2009 11:16:30 +0200 X-Mailer: exmh version 2.7.2 01/07/2005 with nmh-1.2 To: Rick Macklem In-reply-to: References: <20091027164159.GU841@twoquid.cs.ru.nl> Comments: In-reply-to Rick Macklem message dated "Wed, 28 Oct 2009 16:38:27 -0400." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 31 Oct 2009 11:16:30 +0200 From: Daniel Braniss Message-ID: Cc: freebsd-stable@freebsd.org, dfr@freebsd.org, freebsd-current@freebsd.org, Olaf Seibert Subject: Re: 8.0-RC1 NFS client timeout issue X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 31 Oct 2009 09:16:35 -0000 > > First off, I know that cross posting is evil, but I wanted to try > and make sure developers saw it. > > On Tue, 27 Oct 2009, Olaf Seibert wrote: > > > I see an annoying behaviour with NFS over TCP. It happens both with nfs > > and newnfs. This is with FreeBSD/amd64 8.0-RC1 as client. The server is > > some Linux or perhaps Solaris, I'm not entirely sure. > > > > After trying to find something in packet traces, I think I have found > > something. > > > > The scenario seems to be as follows. Sorry for the width of the lines. > > > > > > No. Time Source Destination Protocol Info > > 2296 2992.216855 xxx.xxx.31.43 xxx.xxx.16.142 NFS V3 LOOKUP Call (Reply In 2297), DH:0x3819da36/w > > 2297 2992.217107 xxx.xxx.16.142 xxx.xxx.31.43 NFS V3 LOOKUP Reply (Call In 2296) Error:NFS3ERR_NOENT > > 2298 2992.217141 xxx.xxx.31.43 xxx.xxx.16.142 NFS V3 LOOKUP Call (Reply In 2299), DH:0x170cb16a/bin > > 2299 2992.217334 xxx.xxx.16.142 xxx.xxx.31.43 NFS V3 LOOKUP Reply (Call In 2298), FH:0x61b8eb12 > > 2300 2992.217361 xxx.xxx.31.43 xxx.xxx.16.142 NFS V3 ACCESS Call (Reply In 2301), FH:0x61b8eb12 > > 2301 2992.217582 xxx.xxx.16.142 xxx.xxx.31.43 NFS V3 ACCESS Reply (Call In 2300) > > 2302 2992.217605 xxx.xxx.31.43 xxx.xxx.16.142 NFS V3 LOOKUP Call (Reply In 2303), DH:0x61b8eb12/w > > 2303 2992.217860 xxx.xxx.16.142 xxx.xxx.31.43 NFS V3 LOOKUP Reply (Call In 2302) Error:NFS3ERR_NOENT > > 2304 2992.318770 xxx.xxx.31.43 xxx.xxx.16.142 TCP 934 > nfs [ACK] Seq=238293 Ack=230289 Win=8192 Len=0 TSV=86492342 TSER=12393434 > > 2306 3011.537520 xxx.xxx.16.142 xxx.xxx.31.43 NFS V3 GETATTR Reply (Call In 2305) Directory mode:2755 uid:4100 gid:4100 > > 2307 3011.637744 xxx.xxx.31.43 xxx.xxx.16.142 TCP 934 > nfs [ACK] Seq=238429 Ack=230405 Win=8192 Len=0 TSV=86511662 TSER=12395366 > > 2308 3371.534980 xxx.xxx.16.142 xxx.xxx.31.43 TCP nfs > 934 [FIN, ACK] Seq=230405 Ack=238429 Win=49232 Len=0 TSV=12431366 TSER=86511662 > > > > The server decides, for whatever reason, to terminate the > > connection and sends a FIN. > > > > 2309 3371.535018 xxx.xxx.31.43 xxx.xxx.16.142 TCP 934 > nfs [ACK] Seq=238429 Ack=230406 Win=8192 Len=0 TSV=86871578 TSER=12431366 > > > > Client acknowledges this, > > > > 2310 3375.379693 xxx.xxx.31.43 xxx.xxx.16.142 NFS V3 ACCESS Call, FH:0x008002a2 > > > > but tries to sneak in another call anyway. [A] > > > Probably not the best behaviour, but I think it is technically allowed by > TCP. (My TCP is very rusty, but I think the socket should be in > TCPS_CLOSE_WAIT at this point and the BSD code will have called > socantrcvmore(), but not socantsndmore().) > > > 2311 3375.474788 xxx.xxx.16.142 xxx.xxx.31.43 TCP nfs > 934 [ACK] Seq=230406 Ack=238569 Win=49232 Len=0 TSV=12431760 TSER=86875423 > > > > Server ACKs but doesn't send anything else... [B] > > > > Time passes... > > > This is where it seems interesting. It looks to me like the socket upcall > for receiving the FIN would have happened before this point, setting the > ct_error.re_status to RPC_CANTRECV, but the code in clnt_vc_call() doesn't > check for this. (It does check for it happening during and after the > sosend(), but not before it, from what I can see.) > > > > > [B] would be a bug of the server in my opinion. If it ACKs a call, it > > should send a reply. And if it can't, it shouldn't. > > > I'll leave this one for the TCP wizzards. I'm not sure what the > correct behaviour is when data is received on a connection. (I think > it is waiting for a FIN from the client side at this point.) > > If you could try the following patch and see if it helps, that would be > appreciated, rick > ps: I'll try to reproduce the situation here, but I'm not sure if I can. > --- rpc/clnt_vc.c.sav 2009-10-28 15:44:20.000000000 -0400 > +++ rpc/clnt_vc.c 2009-10-28 15:49:57.000000000 -0400 > @@ -413,6 +413,19 @@ > > cr->cr_xid = xid; > mtx_lock(&ct->ct_lock); > + /* > + * Check to see if the other end has already started to close down > + * the connection. If it happens after this point, it will be > + * detected below, when cr->cr_error is checked. > + */ > + if (ct->ct_error.re_status == RPC_CANTRECV) { > + if (errp != &ct->ct_error) { > + errp->re_errno = ct->ct_error.re_errno; > + errp->re_status = RPC_CANTRECV; > + } > + stat = RPC_CANTRECV; > + goto out; > + } > TAILQ_INSERT_TAIL(&ct->ct_pending, cr, cr_link); > mtx_unlock(&ct->ct_lock); Did a make buildworld -j8, using as server netapp, freebsd, and all seems ok. danny From owner-freebsd-current@FreeBSD.ORG Sat Oct 31 15:01:33 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 62E6110656A7; Sat, 31 Oct 2009 15:01:33 +0000 (UTC) (envelope-from scottl@samsco.org) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.freebsd.org (Postfix) with ESMTP id ECC4E8FC12; Sat, 31 Oct 2009 15:01:32 +0000 (UTC) Received: from [IPv6:::1] (pooker.samsco.org [168.103.85.57]) (authenticated bits=0) by pooker.samsco.org (8.14.2/8.14.2) with ESMTP id n9VF1RXm013084; Sat, 31 Oct 2009 09:01:27 -0600 (MDT) (envelope-from scottl@samsco.org) Mime-Version: 1.0 (Apple Message framework v1076) Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes From: Scott Long In-Reply-To: <4AEBE9B6.6050007@FreeBSD.org> Date: Sat, 31 Oct 2009 09:01:27 -0600 Content-Transfer-Encoding: 7bit Message-Id: References: <4AEBDDF8.8060609@FreeBSD.org> <4AEBE9B6.6050007@FreeBSD.org> To: Alexander Motin X-Mailer: Apple Mail (2.1076) X-Spam-Status: No, score=-4.3 required=3.8 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.1.8 X-Spam-Checker-Version: SpamAssassin 3.1.8 (2007-02-13) on pooker.samsco.org Cc: Scott Long , FreeBSD-Current Subject: Re: Weird CAM-ATA behaviour (8.0-RC1): disk cloning X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 31 Oct 2009 15:01:33 -0000 On Oct 31, 2009, at 1:39 AM, Alexander Motin wrote: > Alexander Motin wrote: >> Kamigishi Rei wrote: >>> I just noticed something weird in my device list (actually, I >>> noticed it >>> in "glabel status" output, but then confirmed via camcontrol >>> devlist): I >>> got a 7th HDD, ada6, which is, surprisingly, ada0. >>> >>> This is how it appeared (I've checked the logs): >>> >>> Oct 27 01:26:38 ameagari sudo: fujibayashi : TTY=pts/3 ; >>> PWD=/usr/home/fujibayashi ; USER=root ; COMMAND=/sbin/camcontrol >>> rescan >>> 0:0:1 >>> Oct 27 01:26:38 ameagari kernel: (aprobe0:ahcich0:0:0:1): >>> SIGNATURE: 0000 >>> Oct 27 01:26:38 ameagari kernel: ada6 at ahcich0 bus 0 target 0 >>> lun 1 >>> Oct 27 01:26:38 ameagari kernel: ada6: ATA/ >>> ATAPI-8 >>> SATA 2.x device >>> Oct 27 01:26:38 ameagari kernel: ada6: 300.000MB/s transfers >>> Oct 27 01:26:38 ameagari kernel: ada6: 476940MB (976773168 512 byte >>> sectors: 16H 63S/T 16383C) >>> Oct 27 01:26:38 ameagari kernel: ada6: Native Command Queueing >>> enabled >>> Oct 27 01:26:38 ameagari kernel: GEOM_MIRROR: Cannot add disk ada6 >>> to >>> gm0 (error=17). >>> >>> While I know I made a mistake there (specifying 0:0:1 instead of >>> 1:0:0), >>> is this behaviour really correct? I don't see why we should add a >>> 'cloned' disk device on a rescan of LUNs that do not really exist >>> in the >>> first place. >>> >>> This is repeatable and I can create as many clones as I want (by >>> doing >>> "camcontrol rescan X:Y:Z" where Y and Z can vary and X is the AHCI >>> bus >>> number): >> >> Interesting effect. > > By the way it is not an ATA-specific problem. Here is ahc SCSI: > > %camcontrol devlist > at scbus0 target 1 lun 0 (sa0,pass0) > at scbus0 target 1 lun 256 > (pass3,sa2) > at scbus0 target 17 lun 0 > (pass2,sa1) > It's not finding these on it's own is, it? Rather, you're forcing it to scan a particular bus:target:lun, yes? The problem here isn't that it's seeing phantom devices, it's that you're overflowing the ranges for the fields and getting wrap-around. I don't know if the SIM or the XPT should be doing the range checking, and I don't know if checking was done in the past but is now broken. I can't say that this problem is the same ATA. Scott From owner-freebsd-current@FreeBSD.ORG Sat Oct 31 16:05:50 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 663921065676 for ; Sat, 31 Oct 2009 16:05:50 +0000 (UTC) (envelope-from a_best01@uni-muenster.de) Received: from zivm-exrelay3.uni-muenster.de (ZIVM-EXRELAY3.UNI-MUENSTER.DE [128.176.192.20]) by mx1.freebsd.org (Postfix) with ESMTP id F11BA8FC13 for ; Sat, 31 Oct 2009 16:05:49 +0000 (UTC) X-IronPort-AV: E=Sophos;i="4.44,658,1249250400"; d="scan'208";a="17270083" Received: from zivmaildisp1.uni-muenster.de (HELO ZIVMAILUSER01.UNI-MUENSTER.DE) ([128.176.188.85]) by zivm-relay3.uni-muenster.de with ESMTP; 31 Oct 2009 17:05:48 +0100 Received: by ZIVMAILUSER01.UNI-MUENSTER.DE (Postfix, from userid 149459) id 5F1E41B0766; Sat, 31 Oct 2009 17:05:48 +0100 (CET) Date: Sat, 31 Oct 2009 17:05:47 +0100 (CET) From: Alexander Best Sender: Organization: Westfaelische Wilhelms-Universitaet Muenster To: Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: linux 3d applications keep crashing X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 31 Oct 2009 16:05:50 -0000 sorry to dig out this old thread. i just wanted to close the discussion with the following statement: the problem still exists. the problems mentioned in connection with the nvidia drivers were however just the symptoms of a more complex problem which is related to linux threading models. installing the latest nvidia drivers no longer causes this problem since the driver picks one of 2 available libs (which are being compiled against different threading models). further discussion concerning this problem should happen either under freebsd-emulation@ or as a followup to this PR: http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/133144 again: the problem is not related to the nvidia drivers! the driver was merely a victim of a linuxulator bug related to linux threading! although the nvidia drivers no longer segfault the problem still exists under 8-STABLE and 9-CURRENT! cheers. alex From owner-freebsd-current@FreeBSD.ORG Sat Oct 31 16:10:11 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BDAE710656C7 for ; Sat, 31 Oct 2009 16:10:11 +0000 (UTC) (envelope-from onemda@gmail.com) Received: from mail-bw0-f213.google.com (mail-bw0-f213.google.com [209.85.218.213]) by mx1.freebsd.org (Postfix) with ESMTP id 538DE8FC0C for ; Sat, 31 Oct 2009 16:10:11 +0000 (UTC) Received: by mail-bw0-f213.google.com with SMTP id 5so4735667bwz.3 for ; Sat, 31 Oct 2009 09:10:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:content-type; bh=8HL+o0yqdwuJzRGfcEe6VVhSn34rMZS8CWQMTbGmisQ=; b=v9HH3hA0ocvTSKhq1PcB38AGDcp563LRnuNmqUbtGOwyakTI4P9Md/OHzOABsAg50M LNPtlVTlnNFICpDshtgRfuYp27lk6JkFZ1JSEqNBJmM17A8YG9IQS+L4rLfZUs//sY6Z 8nawykKNIsx8A2S9cUa2hxaiI0hbBVdwt7vwY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=SCfG+pSBWjT5NLPowRAIeMn6z4HjosHG8s+5GEQRr9tBXhz9VWLAnBKri7/42z2OKF aqiegRWc3wtMyOenWE77GYiiaYB47MICGbmES2bA/vZ4uodzho6zmj8GXf1zHNXPkEAQ 1s0d4lwTHuv9oo8OET5i0oUXt/MQGl9qTkISk= MIME-Version: 1.0 Received: by 10.103.125.36 with SMTP id c36mr1207750mun.126.1257005410879; Sat, 31 Oct 2009 09:10:10 -0700 (PDT) Date: Sat, 31 Oct 2009 17:10:10 +0100 Message-ID: <3a142e750910310910p69c33c9xddb28e93327da37a@mail.gmail.com> From: Paul B Mahol To: current@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Cc: Subject: rum(4) crash with adhoc X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 31 Oct 2009 16:10:11 -0000 While testing adhoc with rum and ndis I got hit with this one: Kernel page fault with the following non-sleepable locks held: exclusive sleep mutex rum0 (network driver) r = 0 (0xc405e1a4) locked @ /usr/src/sys/modules/usb/usb/../../../dev/usb/usb_request.c:540 KDB: stack backtrace: db_trace_self_wrapper(c062f6f1,e63e6a94,c04e7ddf,21c,0,...) at db_trace_self_wrapper+0x26 kdb_backtrace(21c,0,ffffffff,c07dd8f4,e63e6acc,...) at kdb_backtrace+0x29 _witness_debugger(c0631b57,e63e6ae0,4,1,0,...) at _witness_debugger+0x1e witness_warn(5,0,c064f703,c04e6f77,c069bba0,...) at witness_warn+0x1e9 trap(e63e6b6c) at trap+0x179 calltrap() at calltrap+0x6 --- trap 0xc, eip = 0xc451c3af, esp = 0xe63e6bac, ebp = 0xe63e6bb8 --- ieee80211_getcapinfo(c41a8000,ffff,c450c616,c41a887c,c4566400,...) at ieee80211_getcapinfo+0x78 ieee80211_beacon_construct(c4561000,18,676,43014,c3e5d800,...) at ieee80211_beacon_construct+0x67 ieee80211_beacon_alloc(c4561000,c41a887c,6,2cb,e63e6c48,...) at ieee80211_beacon_alloc+0x99 rum_newstate(c41a8000,5,ffffffff,654,e63e6ca8,...) at rum_newstate+0x2e7 ieee80211_newstate_cb(c41a8000,2,c0630f47,51,c4486418,...) at ieee80211_newstate_cb+0xac taskqueue_run(c4486400,c4486418,0,c0621864,0,...) at taskqueue_run+0xfd taskqueue_thread_loop(c455a074,e63e6d38,c0627aba,343,c069bba0,...) at taskqueue_thread_loop+0x65 fork_exit(c04e159c,c455a074,e63e6d38) at fork_exit+0xb8 fork_trampoline() at fork_trampoline+0x8 --- trap 0, eip = 0, esp = 0xe63e6d70, ebp = 0 --- Only what I were trying to do is to set SSID for rum0 adhoc wlanmode. Looks like it will not crash if same SSID is already available on network. From owner-freebsd-current@FreeBSD.ORG Sat Oct 31 20:06:59 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 13649106566B for ; Sat, 31 Oct 2009 20:06:59 +0000 (UTC) (envelope-from matthias.rampke@googlemail.com) Received: from mail-bw0-f213.google.com (mail-bw0-f213.google.com [209.85.218.213]) by mx1.freebsd.org (Postfix) with ESMTP id 9A42F8FC18 for ; Sat, 31 Oct 2009 20:06:58 +0000 (UTC) Received: by bwz5 with SMTP id 5so4904525bwz.3 for ; Sat, 31 Oct 2009 13:06:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :from:date:message-id:subject:to:content-type; bh=th2lMcRpWQsyt3PDXpUD2HRJ+qV6U+lf1ohEWmr23wE=; b=UhdkTthmk2EJwX3L6aJLQY0BctY2GOTOEHQv7qtilxPD9DiZMXRjUrlIXjfSr3c9+O /MFXhtEIBxsLp0jE3tw8eqWI8Kb8STQq0csOr2el3MvKopfmqDSOJcRvh+XYsTfuZPZ0 zNqwb1qUnoN+EdKCZfrgWHMmo1ges/HtzZ0fE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type; b=soxUUpH0oYBcWrLZyW2D+OuhaB6xNnQv+9OwXOt/A79ZGRuhRpwYQWHO01RChMtClG bRVpkZIjcB8xKg3bwWxPwLlahbUWGkiIl63AZ4sCqRn6IroXM7ZkxQwT7gNz2+yuLzJV Fd6BNDphn+OTDOvuiJ2QsTi/CgO1P2UCvNXYU= MIME-Version: 1.0 Received: by 10.204.34.20 with SMTP id j20mr2349686bkd.57.1257019616162; Sat, 31 Oct 2009 13:06:56 -0700 (PDT) In-Reply-To: <31d643300910311245r593326e1me8574bdff5198b51@mail.gmail.com> References: <31d643300910311245r593326e1me8574bdff5198b51@mail.gmail.com> From: Matthias Rampke Date: Sat, 31 Oct 2009 21:06:36 +0100 Message-ID: <31d643300910311306m6caa73cfi8930465e43773ff4@mail.gmail.com> To: freebsd-current@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Subject: Re: Host OS (OS X 10.6.1) panic when booting 8.0-RC2 in VirtualBox 3.0.10 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 31 Oct 2009 20:06:59 -0000 On Sat, Oct 31, 2009 at 8:45 PM, Matthias Rampke wrote: > Hello, > > I have been experiencing reproducible kernel panics in Mac OS X 10.6.1 > when booting 8.0-RC1 and -RC2 (amd64) in a VirtualBox VM. > > I had a (mostly pristine) 7.2-RELEASE running in this VM and tried to > upgrade to 8.0-RC2 with freebsd-update. This does not happen in a new, freshly installed VM. Now it hangs at usbus initialization, but I suppose that's a different story (the pains of using USB with VirtualBox, they never end). Any ideas what went wrong with the update? thx, M. -- Matthias Rampke +49 179 - 166 09 18 http://www.matthias-rampke.de/ From owner-freebsd-current@FreeBSD.ORG Sat Oct 31 20:08:21 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9A38C1065696 for ; Sat, 31 Oct 2009 20:08:21 +0000 (UTC) (envelope-from matthias.rampke@googlemail.com) Received: from mail-bw0-f213.google.com (mail-bw0-f213.google.com [209.85.218.213]) by mx1.freebsd.org (Postfix) with ESMTP id 3A2CF8FC08 for ; Sat, 31 Oct 2009 20:08:20 +0000 (UTC) Received: by bwz5 with SMTP id 5so4905360bwz.3 for ; Sat, 31 Oct 2009 13:08:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:from:date:message-id :subject:to:content-type; bh=0TgPq9V6u9W5MNF7NoCuQOXJs7jnJh2yNbE8r5bFj0A=; b=NWD87FxvaiblFuXrnpIhiuEbfijwWCpkxpxS7csuBMzfRq6OfIsDcdQHkOvVS+7xAY abFYwwpn+xcYUg81Kr0+woHkERo12uPyruYYsDMs8DN4hr63FabZTURY1LWX6Z0YAQmc hfHoIqk3veJeWwApiwp3lGajBAecV7J+w7ipw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:from:date:message-id:subject:to:content-type; b=RlcdFgFs/vFM+ezbVP9wOFjXoVHqdOmP8m1HR47BmpGarWRPFvG6J6dpvlg/4GImLq rdXU6PGhc8tlbqvRHjrs2DWeJ81jdGkcFLNZ1Sj6YaJ3On9PY/ZW0h4E8b0ZG26ZcQog ePPy6TX0AtKw370zy+qcmFKryAACOEuqbwVIA= MIME-Version: 1.0 Received: by 10.204.3.22 with SMTP id 22mr2302188bkl.181.1257018364180; Sat, 31 Oct 2009 12:46:04 -0700 (PDT) From: Matthias Rampke Date: Sat, 31 Oct 2009 20:45:44 +0100 Message-ID: <31d643300910311245r593326e1me8574bdff5198b51@mail.gmail.com> To: freebsd-current@freebsd.org Content-Type: multipart/mixed; boundary=0015174bec1c12b8350477406512 Subject: Host OS (OS X 10.6.1) panic when booting 8.0-RC2 in VirtualBox 3.0.10 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 31 Oct 2009 20:08:21 -0000 --0015174bec1c12b8350477406512 Content-Type: text/plain; charset=ISO-8859-1 Hello, I have been experiencing reproducible kernel panics in Mac OS X 10.6.1 when booting 8.0-RC1 and -RC2 (amd64) in a VirtualBox VM. I had a (mostly pristine) 7.2-RELEASE running in this VM and tried to upgrade to 8.0-RC2 with freebsd-update. after the second freebsd-update install and reboot, when the loader tries to load the kernel, it fails a) if I select boot with ACPI, it stops with "ACPI autoload failed - no such file or directory" b) if I select boot without ACPI, the host OS panics (grey screen of death). This is reproducible and independent of whether hardware virtualization (VT-x) is active or not. I remember having the same problem with -RC1, but did not follow up on that and instead reverted to a snapshot of the VM just before the upgrade due to lack of time then. VBox.log for both cases and the OS X panic report are attached. I have created a ticket in the VirtualBox bugtracker for this [1] I will try a clean installation now. Suggestions are welcome... thx, Matthias [1] http://www.virtualbox.org/ticket/5359 -- Matthias Rampke +49 179 - 166 09 18 http://www.matthias-rampke.de/ --0015174bec1c12b8350477406512 Content-Type: text/plain; charset=UTF-8; name="osx-panic-freebsd8rc2.txt" Content-Disposition: attachment; filename="osx-panic-freebsd8rc2.txt" Content-Transfer-Encoding: base64 X-Attachment-Id: f_g1gs421f0 SW50ZXJ2YWwgU2luY2UgTGFzdCBQYW5pYyBSZXBvcnQ6ICA3NDE1Mzggc2VjClBhbmljcyBTaW5j ZSBMYXN0IFJlcG9ydDogICAgICAgICAgMwpBbm9ueW1vdXMgVVVJRDogICAgICAgICAgICAgICAg ICAgIDE5OUY1MjJBLUI0RDUtNDJENS1BMkE3LUE1MTEyMkQ1Q0I2QQoKU2F0IE9jdCAzMSAxOToz Njo0MSAyMDA5CnBhbmljKGNwdSAxIGNhbGxlciAweDJhNmFjMik6IEtlcm5lbCB0cmFwIGF0IDB4 NWE1OTMwOGEsIHR5cGUgMTQ9cGFnZSBmYXVsdCwgcmVnaXN0ZXJzOgpDUjA6IDB4ODAwMTAwM2Is IENSMjogMHgwMDAwMDAwNCwgQ1IzOiAweDAwMTAwMDAwLCBDUjQ6IDB4MDAwMDI2NjAKRUFYOiAw eDAwMDAwMDA0LCBFQlg6IDB4MDAwMDUzZjAsIEVDWDogMHgwMDAwNTNmMCwgRURYOiAweDAwMDAw MDA0CkNSMjogMHgwMDAwMDAwNCwgRUJQOiAweDQ4NDdlZDc4LCBFU0k6IDB4MDBlOTg3ZjAsIEVE STogMHgwMDAwNTNmMApFRkw6IDB4MDAwMTAyMDIsIEVJUDogMHg1YTU5MzA4YSwgQ1M6ICAweDAw MDAwMDA4LCBEUzogIDB4MDAwMDAwMTAKRXJyb3IgY29kZTogMHgwMDAwMDAwMAoKQmFja3RyYWNl IChDUFUgMSksIEZyYW1lIDogUmV0dXJuIEFkZHJlc3MgKDQgcG90ZW50aWFsIGFyZ3Mgb24gc3Rh Y2spCjB4NDg0N2ViOTggOiAweDIxYWNmYSAoMHg1Y2U2NTAgMHg0ODQ3ZWJjYyAweDIyMzE1NiAw eDApIAoweDQ4NDdlYmU4IDogMHgyYTZhYzIgKDB4NTkwYTUwIDB4NWE1OTMwOGEgMHhlIDB4NTkw YzFhKSAKMHg0ODQ3ZWNjOCA6IDB4MjljOTY4ICgweDQ4NDdlY2UwIDB4MCAweDQ4NDdlZDc4IDB4 NWE1OTMwOGEpIAoweDQ4NDdlY2Q4IDogMHg1YTU5MzA4YSAoMHhlIDB4NDggMHg0NzAwMTAgMHgx MCkgCjB4NDg0N2VkNzggOiAweDVhNTQ5NjRlICgweDQgMHg1M2YwIDB4NDg0N2VkYTggMHg0ODQ3 ZWRhMCkgCjB4NDg0N2VkYzggOiAweDVhNTQ5YjRmICgweGU5ODdmMCAweDUzZjAgMHhmZjUzZmYg MHhmODk2ZjApIAoweDQ4NDdlZTU4IDogMHhmZWE1ZjAgKDB4ZTk4N2YwIDB4ZmY1M2YwIDB4ZmY1 M2YwIDB4ZmY1M2YwKSAKMHhmZjUzZjAgOiAweDAgKDB4MCAweDAgMHgwIDB4MCkgCgpCU0QgcHJv Y2VzcyBuYW1lIGNvcnJlc3BvbmRpbmcgdG8gY3VycmVudCB0aHJlYWQ6IFZpcnR1YWxCb3hWTQoK TWFjIE9TIHZlcnNpb246CjEwQjUwNAoKS2VybmVsIHZlcnNpb246CkRhcndpbiBLZXJuZWwgVmVy c2lvbiAxMC4wLjA6IEZyaSBKdWwgMzEgMjI6NDc6MzQgUERUIDIwMDk7IHJvb3Q6eG51LTE0NTYu MS4yNX4xL1JFTEVBU0VfSTM4NgpTeXN0ZW0gbW9kZWwgbmFtZTogTWFjQm9vazIsMSAoTWFjLUY0 MjA4Q0E5KQoKU3lzdGVtIHVwdGltZSBpbiBuYW5vc2Vjb25kczogOTE5Njg4NDY4MTg3CnVubG9h ZGVkIGtleHRzOgpvcmcudmlydHVhbGJveC5rZXh0LlZCb3hEcnYJMy4wLjggKGFkZHIgMHg1YTY2 MjAwMCwgc2l6ZSAweDEzNTE2OCkgLSBsYXN0IHVubG9hZGVkIDcwMzUwMzEyNjczNApsb2FkZWQg a2V4dHM6Cm9yZy52aXJ0dWFsYm94LmtleHQuVkJveE5ldEFkcAkzLjAuMTAgLSBsYXN0IGxvYWRl ZCA3MDU1MzIxNzYzODYKb3JnLnZpcnR1YWxib3gua2V4dC5WQm94TmV0Rmx0CTMuMC4xMApvcmcu dmlydHVhbGJveC5rZXh0LlZCb3hVU0IJMy4wLjEwCm9yZy52aXJ0dWFsYm94LmtleHQuVkJveERy dgkzLjAuMTAKZm9vLnR1bgkxLjAKZm9vLnRhcAkxLjAKY29tLmFwcGxlLmZpbGVzeXN0ZW1zLmF1 dG9mcwkyLjEuMApjb20uYXBwbGUuZHJpdmVyLkludGVybmFsTW9kZW1TdXBwb3J0CTIuNi4wCmNv bS5hcHBsZS5kcml2ZXIuQXBwbGVUeU1DRURyaXZlcgkxLjAuMWQ4CmNvbS5hcHBsZS5Eb250X1N0 ZWFsX01hY19PU19YCTcuMC4wCmNvbS5hcHBsZS5kcml2ZXIuSU9CbHVldG9vdGhCTkVQRHJpdmVy CTIuMi4xZjcKY29tLmFwcGxlLmlva2l0LkNIVURVdGlscwkyMDEKY29tLmFwcGxlLmRyaXZlci5B cHBsZUludGVsWW9uYWhQcm9maWxlCTE0CmNvbS5hcHBsZS5pb2tpdC5DSFVEUHJvZgkyMTIKY29t LmFwcGxlLmRyaXZlci5BcHBsZUludGVsUGVucnluUHJvZmlsZQkxNwpjb20uYXBwbGUuZHJpdmVy LkFwcGxlSW50ZWxHTUE5NTAJNi4wLjIKY29tLmFwcGxlLmRyaXZlci5BcHBsZUludGVsTmVoYWxl bVByb2ZpbGUJMTEKY29tLmFwcGxlLmRyaXZlci5BdWRpb0lQQ0RyaXZlcgkxLjEuMApjb20uYXBw bGUuZHJpdmVyLkFwcGxlSERBCTEuNy40YTEKY29tLmFwcGxlLmRyaXZlci5BcHBsZUdyYXBoaWNz Q29udHJvbAkyLjguMTYKY29tLmFwcGxlLmRyaXZlci5BcHBsZVVwc3RyZWFtVXNlckNsaWVudAkz LjAuNQpjb20uYXBwbGUuaW9raXQuQXBwbGVZdWtvbjIJMy4xLjE0YjEKY29tLmFwcGxlLmRyaXZl ci5BcHBsZUludGVsSW50ZWdyYXRlZEZyYW1lYnVmZmVyCTYuMC4yCmNvbS5hcHBsZS5kcml2ZXIu U01DTW90aW9uU2Vuc29yCTMuMC4wZDQKY29tLmFwcGxlLmRyaXZlci5BaXJQb3J0LkF0aGVyb3MJ NDExLjE5LjQKY29tLmFwcGxlLmRyaXZlci5BcHBsZUludGVsTWVyb21Qcm9maWxlCTE5CmNvbS5h cHBsZS5kcml2ZXIuQXBwbGVJUkNvbnRyb2xsZXIJMTYxCmNvbS5hcHBsZS5kcml2ZXIuQUNQSV9T TUNfUGxhdGZvcm1QbHVnaW4JMy40LjBhMjAKY29tLmFwcGxlLmRyaXZlci5BcHBsZUxQQwkxLjQu Ngpjb20uYXBwbGUuZHJpdmVyLkFwcGxlQmFja2xpZ2h0CTE3MC4wLjIKY29tLmFwcGxlLmRyaXZl ci5pUG9kU0JDRHJpdmVyCTEuNS4wCmNvbS5hcHBsZS5kcml2ZXIuQ1NSSElEVHJhbnNpdGlvbkRy aXZlcgkyLjIuMWY3CmNvbS5hcHBsZS5kcml2ZXIuQXBwbGVVU0JUcmFja3BhZAkxLjguMGI0CmNv bS5hcHBsZS5kcml2ZXIuQXBwbGVVU0JUQ0tleUV2ZW50RHJpdmVyCTEuOC4wYjQKY29tLmFwcGxl LmRyaXZlci5BcHBsZVVTQlRDS2V5Ym9hcmQJMS44LjBiNApjb20uYXBwbGUuZHJpdmVyLlVTQkNh bWVyYUZpcm13YXJlTG9hZGVyCTEuMS4wCmNvbS5hcHBsZS5pb2tpdC5TQ1NJVGFza1VzZXJDbGll bnQJMi41LjEKY29tLmFwcGxlLmlva2l0LklPQUhDSUJsb2NrU3RvcmFnZQkxLjUuMApjb20uYXBw bGUuZHJpdmVyLkFwcGxlVVNCSHViCTMuNy44CmNvbS5hcHBsZS5Cb290Q2FjaGUJMzEKY29tLmFw cGxlLkFwcGxlRlNDb21wcmVzc2lvbi5BcHBsZUZTQ29tcHJlc3Npb25UeXBlWmxpYgkxLjAuMGQx CmNvbS5hcHBsZS5kcml2ZXIuQXBwbGVFRklOVlJBTQkxLjMuMApjb20uYXBwbGUuZHJpdmVyLkFw cGxlQUhDSVBvcnQJMi4wLjAKY29tLmFwcGxlLmRyaXZlci5BcHBsZUludGVsUElJWEFUQQkyLjUu MApjb20uYXBwbGUuZHJpdmVyLkFwcGxlVVNCRUhDSQkzLjcuNQpjb20uYXBwbGUuZHJpdmVyLkFw cGxlRldPSENJCTQuMy40CmNvbS5hcHBsZS5kcml2ZXIuQXBwbGVVU0JVSENJCTMuNy41CmNvbS5h cHBsZS5kcml2ZXIuQXBwbGVSVEMJMS4zCmNvbS5hcHBsZS5kcml2ZXIuQXBwbGVIUEVUCTEuNApj b20uYXBwbGUuZHJpdmVyLkFwcGxlU21hcnRCYXR0ZXJ5TWFuYWdlcgkxNjAuMC4wCmNvbS5hcHBs ZS5kcml2ZXIuQXBwbGVBQ1BJQnV0dG9ucwkxLjMKY29tLmFwcGxlLmRyaXZlci5BcHBsZVNNQklP UwkxLjQKY29tLmFwcGxlLmRyaXZlci5BcHBsZUFDUElFQwkxLjMKY29tLmFwcGxlLmRyaXZlci5B cHBsZUFQSUMJMS40CmNvbS5hcHBsZS5kcml2ZXIuQXBwbGVJbnRlbENQVVBvd2VyTWFuYWdlbWVu dENsaWVudAk5MC4wLjAKY29tLmFwcGxlLnNlY3VyaXR5LnNhbmRib3gJMApjb20uYXBwbGUuc2Vj dXJpdHkucXVhcmFudGluZQkwCmNvbS5hcHBsZS5ua2UuYXBwbGljYXRpb25maXJld2FsbAkyLjAu MTEKY29tLmFwcGxlLmRyaXZlci5BcHBsZUludGVsQ1BVUG93ZXJNYW5hZ2VtZW50CTkwLjAuMApj b20uYXBwbGUuZHJpdmVyLkFwcGxlUHJvZmlsZVJlYWRDb3VudGVyQWN0aW9uCTE3CmNvbS5hcHBs ZS5kcml2ZXIuQXBwbGVQcm9maWxlVGltZXN0YW1wQWN0aW9uCTEwCmNvbS5hcHBsZS5kcml2ZXIu QXBwbGVQcm9maWxlVGhyZWFkSW5mb0FjdGlvbgkxNApjb20uYXBwbGUuZHJpdmVyLkFwcGxlUHJv ZmlsZVJlZ2lzdGVyU3RhdGVBY3Rpb24JMTAKY29tLmFwcGxlLmRyaXZlci5BcHBsZVByb2ZpbGVL RXZlbnRBY3Rpb24JMTAKY29tLmFwcGxlLmRyaXZlci5BcHBsZVByb2ZpbGVDYWxsc3RhY2tBY3Rp b24JMjAKY29tLmFwcGxlLmlva2l0LklPU3VyZmFjZQk3My4wCmNvbS5hcHBsZS5pb2tpdC5JT0Js dWV0b290aFNlcmlhbE1hbmFnZXIJMi4yLjFmNwpjb20uYXBwbGUuaW9raXQuSU9TZXJpYWxGYW1p bHkJMTAuMC4yCmNvbS5hcHBsZS5kcml2ZXIuQXBwbGVIREFQbGF0Zm9ybURyaXZlcgkxLjcuNGEx CmNvbS5hcHBsZS5pb2tpdC5DSFVES2VybkxpYgkyMDMKY29tLmFwcGxlLmRyaXZlci5BcHBsZUhE QUhhcmR3YXJlQ29uZmlnRHJpdmVyCTEuNy40YTEKY29tLmFwcGxlLmRyaXZlci5Ec3BGdW5jTGli CTEuNy40YTEKY29tLmFwcGxlLmlva2l0LklPQXVkaW9GYW1pbHkJMS43LjBmYzE2CmNvbS5hcHBs ZS5rZXh0Lk9Tdktlcm5EU1BMaWIJMS4zCmNvbS5hcHBsZS5pb2tpdC5JT0ZpcmVXaXJlSVAJMi4w LjMKY29tLmFwcGxlLmlva2l0LklPODAyMTFGYW1pbHkJMzAwLjIwCmNvbS5hcHBsZS5pb2tpdC5J T05ldHdvcmtpbmdGYW1pbHkJMS44CmNvbS5hcHBsZS5pb2tpdC5BcHBsZVByb2ZpbGVGYW1pbHkJ NDAKY29tLmFwcGxlLmRyaXZlci5BcHBsZUhEQUNvbnRyb2xsZXIJMS43LjRhMQpjb20uYXBwbGUu aW9raXQuSU9IREFGYW1pbHkJMS43LjRhMQpjb20uYXBwbGUuZHJpdmVyLkFwcGxlU01DCTMuMC4x ZDIKY29tLmFwcGxlLmRyaXZlci5JT1BsYXRmb3JtUGx1Z2luRmFtaWx5CTMuNC4wYTIwCmNvbS5h cHBsZS5pb2tpdC5JT05EUlZTdXBwb3J0CTIuMApjb20uYXBwbGUuaW9raXQuSU9HcmFwaGljc0Zh bWlseQkyLjAKY29tLmFwcGxlLmRyaXZlci5DU1JVU0JCbHVldG9vdGhIQ0lDb250cm9sbGVyCTIu Mi4xZjcKY29tLmFwcGxlLmRyaXZlci5BcHBsZVVTQkJsdWV0b290aEhDSUNvbnRyb2xsZXIJMi4y LjFmNwpjb20uYXBwbGUuaW9raXQuSU9CbHVldG9vdGhGYW1pbHkJMi4yLjFmNwpjb20uYXBwbGUu aW9raXQuSU9TQ1NJQmxvY2tDb21tYW5kc0RldmljZQkyLjUuMQpjb20uYXBwbGUuaW9raXQuSU9V U0JNYXNzU3RvcmFnZUNsYXNzCTIuNS4wCmNvbS5hcHBsZS5kcml2ZXIuQXBwbGVVU0JNZXJnZU51 YgkzLjcuNQpjb20uYXBwbGUuaW9raXQuSU9VU0JISUREcml2ZXIJMy43LjUKY29tLmFwcGxlLmRy aXZlci5BcHBsZVVTQkNvbXBvc2l0ZQkzLjcuNQpjb20uYXBwbGUuaW9raXQuSU9TQ1NJTXVsdGlt ZWRpYUNvbW1hbmRzRGV2aWNlCTIuNS4xCmNvbS5hcHBsZS5pb2tpdC5JT0JEU3RvcmFnZUZhbWls eQkxLjYKY29tLmFwcGxlLmlva2l0LklPRFZEU3RvcmFnZUZhbWlseQkxLjYKY29tLmFwcGxlLmlv a2l0LklPQ0RTdG9yYWdlRmFtaWx5CTEuNgpjb20uYXBwbGUuZHJpdmVyLlhzYW5GaWx0ZXIJNDAy LjEKY29tLmFwcGxlLmlva2l0LklPQVRBUElQcm90b2NvbFRyYW5zcG9ydAkyLjUuMApjb20uYXBw bGUuaW9raXQuSU9TQ1NJQXJjaGl0ZWN0dXJlTW9kZWxGYW1pbHkJMi41LjEKY29tLmFwcGxlLmlv a2l0LklPVVNCVXNlckNsaWVudAkzLjcuNQpjb20uYXBwbGUuZHJpdmVyLkFwcGxlRmlsZVN5c3Rl bURyaXZlcgkyLjAKY29tLmFwcGxlLmRyaXZlci5BcHBsZUVGSVJ1bnRpbWUJMS4zLjAKY29tLmFw cGxlLmlva2l0LklPQUhDSUZhbWlseQkyLjAuMApjb20uYXBwbGUuaW9raXQuSU9BVEFGYW1pbHkJ Mi41LjAKY29tLmFwcGxlLmlva2l0LklPRmlyZVdpcmVGYW1pbHkJNC4xLjcKY29tLmFwcGxlLmlv a2l0LklPVVNCRmFtaWx5CTMuNy44CmNvbS5hcHBsZS5pb2tpdC5JT0hJREZhbWlseQkxLjYuMApj b20uYXBwbGUuaW9raXQuSU9TTUJ1c0ZhbWlseQkxLjEKY29tLmFwcGxlLnNlY3VyaXR5LlRNU2Fm ZXR5TmV0CTYKY29tLmFwcGxlLmtleHQuQXBwbGVNYXRjaAkxLjAuMGQxCmNvbS5hcHBsZS5kcml2 ZXIuRGlza0ltYWdlcwkyODEKY29tLmFwcGxlLmlva2l0LklPU3RvcmFnZUZhbWlseQkxLjYKY29t LmFwcGxlLmRyaXZlci5BcHBsZUFDUElQbGF0Zm9ybQkxLjMKY29tLmFwcGxlLmlva2l0LklPUENJ RmFtaWx5CTIuNgpjb20uYXBwbGUuaW9raXQuSU9BQ1BJRmFtaWx5CTEuMy4wClVuYWJsZSB0byBn YXRoZXIgc3lzdGVtIGNvbmZpZ3VyYXRpb24gaW5mb3JtYXRpb24uTW9kZWw6IE1hY0Jvb2syLDEs IEJvb3RST00gTUIyMS4wMEE1LkIwNywgMiBwcm9jZXNzb3JzLCBJbnRlbCBDb3JlIDIgRHVvLCAy IEdIeiwgNCBHQiwgU01DIDEuMTNmMwpHcmFwaGljczogSW50ZWwgR01BIDk1MCwgR01BIDk1MCwg QnVpbHQtSW4sIHNwZGlzcGxheXNfaW50ZWdyYXRlZF92cmFtCk1lbW9yeSBNb2R1bGU6IGdsb2Jh bF9uYW1lCkFpclBvcnQ6IEFpclBvcnQgRXh0cmVtZSwgQXRoZXJvcyA1NDE2OiAyLjAuMTkuNApC bHVldG9vdGg6IFZlcnNpb24gMi4yLjFmNywgMiBzZXJ2aWNlLCAxIGRldmljZXMsIDEgaW5jb21p bmcgc2VyaWFsIHBvcnRzCk5ldHdvcmsgU2VydmljZTogRXRoZXJuZXQsIEV0aGVybmV0LCBlbjAK U2VyaWFsIEFUQSBEZXZpY2U6IFNBTVNVTkcgSE0yNTBKSSwgMjMyLDg5IEdCClBhcmFsbGVsIEFU QSBEZXZpY2U6IE1BVFNISVRBRFZELVIgICBVSi04NTdEClVTQiBEZXZpY2U6IEJ1aWx0LWluIGlT aWdodCwgMHgwNWFjICAoQXBwbGUgSW5jLiksIDB4ODUwMSwgMHhmZDQwMDAwMApVU0IgRGV2aWNl OiBVU0IyLjAgSHViLCAweDA1ZTMgIChHZW5lc3lzIExvZ2ljLCBJbmMuKSwgMHgwNjA4LCAweGZk MTAwMDAwClVTQiBEZXZpY2U6IFVTQjIuMCBIdWIsIDB4MDVlMyAgKEdlbmVzeXMgTG9naWMsIElu Yy4pLCAweDA2MDgsIDB4ZmQxNDAwMDAKVVNCIERldmljZTogVVNCMi4wIFN0b3JhZ2UgRGV2aWNl LCAweDA0YjQgIChDeXByZXNzIFNlbWljb25kdWN0b3IpLCAweDY4MzAsIDB4ZmQxNDMwMDAKVVNC IERldmljZTogTXkgQm9vaywgMHgxMDU4ICAoV2VzdGVybiBEaWdpdGFsIFRlY2hub2xvZ2llcywg SW5jLiksIDB4MTEwMCwgMHhmZDE0MjAwMApVU0IgRGV2aWNlOiBocCBzY2FuamV0LCAweDAzZjAg IChIZXdsZXR0IFBhY2thcmQpLCAweDMwMDUsIDB4ZmQxNDEwMDAKVVNCIERldmljZTogaVBvZCwg MHgwNWFjICAoQXBwbGUgSW5jLiksIDB4MTIwOSwgMHhmZDEzMDAwMApVU0IgRGV2aWNlOiBpUDQz MDAsIDB4MDRhOSAgKENhbm9uIEluYy4pLCAweDEwYjYsIDB4ZmQxMjAwMDAKVVNCIERldmljZTog TWljcm9zb2Z0IEludGVsbGlNb3VzZcKuIE9wdGljYWwsIDB4MDQ1ZSAgKE1pY3Jvc29mdCBDb3Jw b3JhdGlvbiksIDB4MDAyOSwgMHhmZDExMDAwMApVU0IgRGV2aWNlOiBJUiBSZWNlaXZlciwgMHgw NWFjICAoQXBwbGUgSW5jLiksIDB4ODI0MCwgMHg1ZDIwMDAwMApVU0IgRGV2aWNlOiBCbHVldG9v dGggVVNCIEhvc3QgQ29udHJvbGxlciwgMHgwNWFjICAoQXBwbGUgSW5jLiksIDB4ODIwNSwgMHg3 ZDEwMDAwMApVU0IgRGV2aWNlOiBBcHBsZSBJbnRlcm5hbCBLZXlib2FyZCAvIFRyYWNrcGFkLCAw eDA1YWMgIChBcHBsZSBJbmMuKSwgMHgwMjFiLCAweDFkMjAwMDAwCgo= --0015174bec1c12b8350477406512 Content-Type: application/octet-stream; name="VBox.log.with-ACPI.log" Content-Disposition: attachment; filename="VBox.log.with-ACPI.log" Content-Transfer-Encoding: base64 X-Attachment-Id: f_g1gs4ijk1 MDA6MDA6MDEuMjkyIFZpcnR1YWxCb3ggMy4wLjEwIHI1NDA5NyBkYXJ3aW4ueDg2IChPY3QgMjkg MjAwOSAxNDoyNjo0NCkgcmVsZWFzZSBsb2cKMDA6MDA6MDEuMjkyIExvZyBvcGVuZWQgMjAwOS0x MC0zMVQxOTowMjo0NS45NTMwMjYwMDBaCjAwOjAwOjAxLjI5MiBPUyBQcm9kdWN0OiBEYXJ3aW4K MDA6MDA6MDEuMjkyIE9TIFJlbGVhc2U6IDEwLjAuMAowMDowMDowMS4yOTIgT1MgVmVyc2lvbjog RGFyd2luIEtlcm5lbCBWZXJzaW9uIDEwLjAuMDogRnJpIEp1bCAzMSAyMjo0NzozNCBQRFQgMjAw OTsgcm9vdDp4bnUtMTQ1Ni4xLjI1fjEvUkVMRUFTRV9JMzg2CjAwOjAwOjAxLjI5MiBIb3N0IFJB TTogNDA5Nk1CIFJBTSwgYXZhaWxhYmxlOiAxMjYwTUIKMDA6MDA6MDEuMjkyIEV4ZWN1dGFibGU6 IC9BcHBsaWNhdGlvbnMvVmlydHVhbEJveC5hcHAvQ29udGVudHMvTWFjT1MvLi4vUmVzb3VyY2Vz L1ZpcnR1YWxCb3hWTS5hcHAvQ29udGVudHMvTWFjT1MvVmlydHVhbEJveFZNCjAwOjAwOjAxLjI5 MiBQcm9jZXNzIElEOiAxMDM0CjAwOjAwOjAxLjI5MiBQYWNrYWdlIHR5cGU6IERBUldJTl8zMkJJ VFNfR0VORVJJQwowMDowMDowMS40NDIgU1VQOiBMb2FkZWQgVk1NUjAucjAgKC9BcHBsaWNhdGlv bnMvVmlydHVhbEJveC5hcHAvQ29udGVudHMvTWFjT1MvVk1NUjAucjApIGF0IDB4NThkZjQwNjAg LSBNb2R1bGVJbml0IGF0IDAwMDAwMDAwNThlMDc2MDAgYW5kIE1vZHVsZVRlcm0gYXQgMDAwMDAw MDA1OGUwNzY5MAowMDowMDowMS40NDIgU1VQOiBWTU1SMEVudHJ5RXggbG9jYXRlZCBhdCAwMDAw MDAwMDU4ZTA4NDcwLCBWTU1SMEVudHJ5RmFzdCBhdCAwMDAwMDAwMDU4ZTA4NWEwIGFuZCBWTU1S MEVudHJ5SW50IGF0IDAwMDAwMDAwNThlMDc3MjAKMDA6MDA6MDEuNTUyIFZCb3hTaGFyZWRDbGlw Ym9hcmQgbW9kZTogQmlkaXJlY3Rpb25hbAowMDowMDowMS43NDkgKioqKioqKioqKioqKioqKioq KioqKioqKiBDRkdNIGR1bXAgKioqKioqKioqKioqKioqKioqKioqKioqKgowMDowMDowMS43NDkg cFJvb3Q9MDIzOTFiNzA6ey99CjAwOjAwOjAxLjc0OSBbL10gKGxldmVsIDApCjAwOjAwOjAxLjc0 OSAgIE5hbWUgICAgICAgICAgICAgICA8c3RyaW5nPiAgPSAiRnJlZUJTRCBrbGVpbiIgKGNjaD0x NCkKMDA6MDA6MDEuNzQ5ICAgVVVJRCAgICAgICAgICAgICAgIDxieXRlcz4gICA9ICJkZSBiZSBk MiBiMyBjYSBlMCA5NyA0YiBhMyA4NCBhOCA2MiA3ZSA3YiA2OCA0ZCIgKGNiPTE2KQowMDowMDow MS43NDkgICBSYW1TaXplICAgICAgICAgICAgPGludGVnZXI+ID0gMHgwMDAwMDAwMDIwMDAwMDAw ICg1MzY4NzA5MTIpCjAwOjAwOjAxLjc0OSAgIFJhbUhvbGVTaXplICAgICAgICA8aW50ZWdlcj4g PSAweDAwMDAwMDAwMjAwMDAwMDAgKDUzNjg3MDkxMikKMDA6MDA6MDEuNzQ5ICAgTnVtQ1BVcyAg ICAgICAgICAgIDxpbnRlZ2VyPiA9IDB4MDAwMDAwMDAwMDAwMDAwMSAoMSkKMDA6MDA6MDEuNzQ5 ICAgVGltZXJNaWxsaWVzICAgICAgIDxpbnRlZ2VyPiA9IDB4MDAwMDAwMDAwMDAwMDAwYSAoMTAp CjAwOjAwOjAxLjc0OSAgIFJhd1IzRW5hYmxlZCAgICAgICA8aW50ZWdlcj4gPSAweDAwMDAwMDAw MDAwMDAwMDEgKDEpCjAwOjAwOjAxLjc0OSAgIFJhd1IwRW5hYmxlZCAgICAgICA8aW50ZWdlcj4g PSAweDAwMDAwMDAwMDAwMDAwMDEgKDEpCjAwOjAwOjAxLjc0OSAgIFBBVE1FbmFibGVkICAgICAg ICA8aW50ZWdlcj4gPSAweDAwMDAwMDAwMDAwMDAwMDEgKDEpCjAwOjAwOjAxLjc0OSAgIENTQU1F bmFibGVkICAgICAgICA8aW50ZWdlcj4gPSAweDAwMDAwMDAwMDAwMDAwMDEgKDEpCjAwOjAwOjAx Ljc0OSAgIEh3VmlydEV4dEZvcmNlZCAgICA8aW50ZWdlcj4gPSAweDAwMDAwMDAwMDAwMDAwMDEg KDEpCjAwOjAwOjAxLjc0OSAgIEVuYWJsZU5lc3RlZFBhZ2luZyA8aW50ZWdlcj4gPSAweDAwMDAw MDAwMDAwMDAwMDAgKDApCjAwOjAwOjAxLjc0OSAgIEVuYWJsZVZQSUQgICAgICAgICA8aW50ZWdl cj4gPSAweDAwMDAwMDAwMDAwMDAwMDAgKDApCjAwOjAwOjAxLjc0OSAgIEVuYWJsZVBBRSAgICAg ICAgICA8aW50ZWdlcj4gPSAweDAwMDAwMDAwMDAwMDAwMDAgKDApCjAwOjAwOjAxLjc0OSAKMDA6 MDA6MDEuNzQ5IFsvSFdWaXJ0RXh0L10gKGxldmVsIDEpCjAwOjAwOjAxLjc0OSAgIEVuYWJsZWQg ICAgICA8aW50ZWdlcj4gPSAweDAwMDAwMDAwMDAwMDAwMDEgKDEpCjAwOjAwOjAxLjc0OSAgIDY0 Yml0RW5hYmxlZCA8aW50ZWdlcj4gPSAweDAwMDAwMDAwMDAwMDAwMDEgKDEpCjAwOjAwOjAxLjc0 OSAKMDA6MDA6MDEuNzQ5IFsvUkVNL10gKGxldmVsIDEpCjAwOjAwOjAxLjc0OSAgIDY0Yml0RW5h YmxlZCA8aW50ZWdlcj4gPSAweDAwMDAwMDAwMDAwMDAwMDEgKDEpCjAwOjAwOjAxLjc0OSAKMDA6 MDA6MDEuNzQ5IFsvUERNL10gKGxldmVsIDEpCjAwOjAwOjAxLjc0OSAKMDA6MDA6MDEuNzQ5IFsv UERNL0RyaXZlcnMvXSAobGV2ZWwgMikKMDA6MDA6MDEuNzQ5IAowMDowMDowMS43NDkgWy9QRE0v RHJpdmVycy9WQm94Qy9dIChsZXZlbCAzKQowMDowMDowMS43NDkgICBQYXRoIDxzdHJpbmc+ICA9 ICIvQXBwbGljYXRpb25zL1ZpcnR1YWxCb3guYXBwL0NvbnRlbnRzL01hY09TL2NvbXBvbmVudHMv VkJveEMiIChjY2g9NjEpCjAwOjAwOjAxLjc0OSAKMDA6MDA6MDEuNzQ5IFsvRGV2aWNlcy9dIChs ZXZlbCAxKQowMDowMDowMS43NDkgCjAwOjAwOjAxLjc0OSBbL0RldmljZXMvcGNhcmNoL10gKGxl dmVsIDIpCjAwOjAwOjAxLjc0OSAKMDA6MDA6MDEuNzQ5IFsvRGV2aWNlcy9wY2FyY2gvMC9dIChs ZXZlbCAzKQowMDowMDowMS43NDkgICBUcnVzdGVkIDxpbnRlZ2VyPiA9IDB4MDAwMDAwMDAwMDAw MDAwMSAoMSkKMDA6MDA6MDEuNzQ5IAowMDowMDowMS43NDkgWy9EZXZpY2VzL3BjYXJjaC8wL0Nv bmZpZy9dIChsZXZlbCA0KQowMDowMDowMS43NDkgCjAwOjAwOjAxLjc0OSBbL0RldmljZXMvcGNi aW9zL10gKGxldmVsIDIpCjAwOjAwOjAxLjc0OSAKMDA6MDA6MDEuNzQ5IFsvRGV2aWNlcy9wY2Jp b3MvMC9dIChsZXZlbCAzKQowMDowMDowMS43NDkgICBUcnVzdGVkIDxpbnRlZ2VyPiA9IDB4MDAw MDAwMDAwMDAwMDAwMSAoMSkKMDA6MDA6MDEuNzQ5IAowMDowMDowMS43NDkgWy9EZXZpY2VzL3Bj Ymlvcy8wL0NvbmZpZy9dIChsZXZlbCA0KQowMDowMDowMS43NTAgICBSYW1TaXplICAgICAgICA8 aW50ZWdlcj4gPSAweDAwMDAwMDAwMjAwMDAwMDAgKDUzNjg3MDkxMikKMDA6MDA6MDEuNzUwICAg UmFtSG9sZVNpemUgICAgPGludGVnZXI+ID0gMHgwMDAwMDAwMDIwMDAwMDAwICg1MzY4NzA5MTIp CjAwOjAwOjAxLjc1MCAgIE51bUNQVXMgICAgICAgIDxpbnRlZ2VyPiA9IDB4MDAwMDAwMDAwMDAw MDAwMSAoMSkKMDA6MDA6MDEuNzUwICAgSGFyZERpc2tEZXZpY2UgPHN0cmluZz4gID0gInBpaXgz aWRlIiAoY2NoPTkpCjAwOjAwOjAxLjc1MCAgIEZsb3BweURldmljZSAgIDxzdHJpbmc+ICA9ICJp ODIwNzgiIChjY2g9NykKMDA6MDA6MDEuNzUwICAgSU9BUElDICAgICAgICAgPGludGVnZXI+ID0g MHgwMDAwMDAwMDAwMDAwMDAxICgxKQowMDowMDowMS43NTAgICBQWEVEZWJ1ZyAgICAgICA8aW50 ZWdlcj4gPSAweDAwMDAwMDAwMDAwMDAwMDAgKDApCjAwOjAwOjAxLjc1MCAgIFVVSUQgICAgICAg ICAgIDxieXRlcz4gICA9ICJkZSBiZSBkMiBiMyBjYSBlMCA5NyA0YiBhMyA4NCBhOCA2MiA3ZSA3 YiA2OCA0ZCIgKGNiPTE2KQowMDowMDowMS43NTAgICBCb290RGV2aWNlMCAgICA8c3RyaW5nPiAg PSAiRkxPUFBZIiAoY2NoPTcpCjAwOjAwOjAxLjc1MCAgIEJvb3REZXZpY2UxICAgIDxzdHJpbmc+ ICA9ICJEVkQiIChjY2g9NCkKMDA6MDA6MDEuNzUwICAgQm9vdERldmljZTIgICAgPHN0cmluZz4g ID0gIklERSIgKGNjaD00KQowMDowMDowMS43NTAgICBCb290RGV2aWNlMyAgICA8c3RyaW5nPiAg PSAiTk9ORSIgKGNjaD01KQowMDowMDowMS43NTAgCjAwOjAwOjAxLjc1MCBbL0RldmljZXMvODIz N0EvXSAobGV2ZWwgMikKMDA6MDA6MDEuNzUwIAowMDowMDowMS43NTAgWy9EZXZpY2VzLzgyMzdB LzAvXSAobGV2ZWwgMykKMDA6MDA6MDEuNzUwICAgVHJ1c3RlZCA8aW50ZWdlcj4gPSAweDAwMDAw MDAwMDAwMDAwMDEgKDEpCjAwOjAwOjAxLjc1MCAKMDA6MDA6MDEuNzUwIFsvRGV2aWNlcy9wY2kv XSAobGV2ZWwgMikKMDA6MDA6MDEuNzUwIAowMDowMDowMS43NTAgWy9EZXZpY2VzL3BjaS8wL10g KGxldmVsIDMpCjAwOjAwOjAxLjc1MCAgIFRydXN0ZWQgPGludGVnZXI+ID0gMHgwMDAwMDAwMDAw MDAwMDAxICgxKQowMDowMDowMS43NTAgCjAwOjAwOjAxLjc1MCBbL0RldmljZXMvcGNpLzAvQ29u ZmlnL10gKGxldmVsIDQpCjAwOjAwOjAxLjc1MCAgIElPQVBJQyA8aW50ZWdlcj4gPSAweDAwMDAw MDAwMDAwMDAwMDEgKDEpCjAwOjAwOjAxLjc1MCAKMDA6MDA6MDEuNzUwIFsvRGV2aWNlcy9wY2ti ZC9dIChsZXZlbCAyKQowMDowMDowMS43NTAgCjAwOjAwOjAxLjc1MCBbL0RldmljZXMvcGNrYmQv MC9dIChsZXZlbCAzKQowMDowMDowMS43NTAgICBUcnVzdGVkIDxpbnRlZ2VyPiA9IDB4MDAwMDAw MDAwMDAwMDAwMSAoMSkKMDA6MDA6MDEuNzUwIAowMDowMDowMS43NTAgWy9EZXZpY2VzL3Bja2Jk LzAvQ29uZmlnL10gKGxldmVsIDQpCjAwOjAwOjAxLjc1MCAKMDA6MDA6MDEuNzUwIFsvRGV2aWNl cy9wY2tiZC8wL0xVTiMwL10gKGxldmVsIDQpCjAwOjAwOjAxLjc1MCAgIERyaXZlciA8c3RyaW5n PiAgPSAiS2V5Ym9hcmRRdWV1ZSIgKGNjaD0xNCkKMDA6MDA6MDEuNzUwIAowMDowMDowMS43NTAg Wy9EZXZpY2VzL3Bja2JkLzAvTFVOIzAvQ29uZmlnL10gKGxldmVsIDUpCjAwOjAwOjAxLjc1MCAg IFF1ZXVlU2l6ZSA8aW50ZWdlcj4gPSAweDAwMDAwMDAwMDAwMDAwNDAgKDY0KQowMDowMDowMS43 NTAgCjAwOjAwOjAxLjc1MCBbL0RldmljZXMvcGNrYmQvMC9MVU4jMC9BdHRhY2hlZERyaXZlci9d IChsZXZlbCA1KQowMDowMDowMS43NTAgICBEcml2ZXIgPHN0cmluZz4gID0gIk1haW5LZXlib2Fy ZCIgKGNjaD0xMykKMDA6MDA6MDEuNzUwIAowMDowMDowMS43NTAgWy9EZXZpY2VzL3Bja2JkLzAv TFVOIzAvQXR0YWNoZWREcml2ZXIvQ29uZmlnL10gKGxldmVsIDYpCjAwOjAwOjAxLjc1MCAgIE9i amVjdCA8aW50ZWdlcj4gPSAweDAwMDAwMDAwMDAxM2U5NDAgKDEzMDQ4OTYpCjAwOjAwOjAxLjc1 MCAKMDA6MDA6MDEuNzUwIFsvRGV2aWNlcy9wY2tiZC8wL0xVTiMxL10gKGxldmVsIDQpCjAwOjAw OjAxLjc1MCAgIERyaXZlciA8c3RyaW5nPiAgPSAiTW91c2VRdWV1ZSIgKGNjaD0xMSkKMDA6MDA6 MDEuNzUwIAowMDowMDowMS43NTAgWy9EZXZpY2VzL3Bja2JkLzAvTFVOIzEvQ29uZmlnL10gKGxl dmVsIDUpCjAwOjAwOjAxLjc1MSAgIFF1ZXVlU2l6ZSA8aW50ZWdlcj4gPSAweDAwMDAwMDAwMDAw MDAwODAgKDEyOCkKMDA6MDA6MDEuNzUxIAowMDowMDowMS43NTEgWy9EZXZpY2VzL3Bja2JkLzAv TFVOIzEvQXR0YWNoZWREcml2ZXIvXSAobGV2ZWwgNSkKMDA6MDA6MDEuNzUxICAgRHJpdmVyIDxz dHJpbmc+ICA9ICJNYWluTW91c2UiIChjY2g9MTApCjAwOjAwOjAxLjc1MSAKMDA6MDA6MDEuNzUx IFsvRGV2aWNlcy9wY2tiZC8wL0xVTiMxL0F0dGFjaGVkRHJpdmVyL0NvbmZpZy9dIChsZXZlbCA2 KQowMDowMDowMS43NTEgICBPYmplY3QgPGludGVnZXI+ID0gMHgwMDAwMDAwMDAwMTNlOWMwICgx MzA1MDI0KQowMDowMDowMS43NTEgCjAwOjAwOjAxLjc1MSBbL0RldmljZXMvaTgyMDc4L10gKGxl dmVsIDIpCjAwOjAwOjAxLjc1MSAKMDA6MDA6MDEuNzUxIFsvRGV2aWNlcy9pODIwNzgvMC9dIChs ZXZlbCAzKQowMDowMDowMS43NTEgICBUcnVzdGVkIDxpbnRlZ2VyPiA9IDB4MDAwMDAwMDAwMDAw MDAwMSAoMSkKMDA6MDA6MDEuNzUxIAowMDowMDowMS43NTEgWy9EZXZpY2VzL2k4MjA3OC8wL0Nv bmZpZy9dIChsZXZlbCA0KQowMDowMDowMS43NTEgICBJUlEgICAgICAgPGludGVnZXI+ID0gMHgw MDAwMDAwMDAwMDAwMDA2ICg2KQowMDowMDowMS43NTEgICBETUEgICAgICAgPGludGVnZXI+ID0g MHgwMDAwMDAwMDAwMDAwMDAyICgyKQowMDowMDowMS43NTEgICBNZW1NYXBwZWQgPGludGVnZXI+ ID0gMHgwMDAwMDAwMDAwMDAwMDAwICgwKQowMDowMDowMS43NTEgICBJT0Jhc2UgICAgPGludGVn ZXI+ID0gMHgwMDAwMDAwMDAwMDAwM2YwICgxMDA4KQowMDowMDowMS43NTEgCjAwOjAwOjAxLjc1 MSBbL0RldmljZXMvaTgyMDc4LzAvTFVOIzk5OS9dIChsZXZlbCA0KQowMDowMDowMS43NTEgICBE cml2ZXIgPHN0cmluZz4gID0gIk1haW5TdGF0dXMiIChjY2g9MTEpCjAwOjAwOjAxLjc1MSAKMDA6 MDA6MDEuNzUxIFsvRGV2aWNlcy9pODIwNzgvMC9MVU4jOTk5L0NvbmZpZy9dIChsZXZlbCA1KQow MDowMDowMS43NTEgICBwYXBMZWRzIDxpbnRlZ2VyPiA9IDB4MDAwMDAwMDAwMjg2ZmNlNCAoNDI0 MDA5OTYpCjAwOjAwOjAxLjc1MSAgIEZpcnN0ICAgPGludGVnZXI+ID0gMHgwMDAwMDAwMDAwMDAw MDAwICgwKQowMDowMDowMS43NTEgICBMYXN0ICAgIDxpbnRlZ2VyPiA9IDB4MDAwMDAwMDAwMDAw MDAwMCAoMCkKMDA6MDA6MDEuNzUxIAowMDowMDowMS43NTEgWy9EZXZpY2VzL2k4MjA3OC8wL0xV TiMwL10gKGxldmVsIDQpCjAwOjAwOjAxLjc1MSAgIERyaXZlciA8c3RyaW5nPiAgPSAiQmxvY2si IChjY2g9NikKMDA6MDA6MDEuNzUxIAowMDowMDowMS43NTEgWy9EZXZpY2VzL2k4MjA3OC8wL0xV TiMwL0NvbmZpZy9dIChsZXZlbCA1KQowMDowMDowMS43NTEgICBUeXBlICAgICAgPHN0cmluZz4g ID0gIkZsb3BweSAxLjQ0IiAoY2NoPTEyKQowMDowMDowMS43NTEgICBNb3VudGFibGUgPGludGVn ZXI+ID0gMHgwMDAwMDAwMDAwMDAwMDAxICgxKQowMDowMDowMS43NTEgCjAwOjAwOjAxLjc1MSBb L0RldmljZXMvYWNwaS9dIChsZXZlbCAyKQowMDowMDowMS43NTEgCjAwOjAwOjAxLjc1MSBbL0Rl dmljZXMvYWNwaS8wL10gKGxldmVsIDMpCjAwOjAwOjAxLjc1MSAgIFRydXN0ZWQgICAgICAgPGlu dGVnZXI+ID0gMHgwMDAwMDAwMDAwMDAwMDAxICgxKQowMDowMDowMS43NTEgICBQQ0lEZXZpY2VO byAgIDxpbnRlZ2VyPiA9IDB4MDAwMDAwMDAwMDAwMDAwNyAoNykKMDA6MDA6MDEuNzUxICAgUENJ RnVuY3Rpb25ObyA8aW50ZWdlcj4gPSAweDAwMDAwMDAwMDAwMDAwMDAgKDApCjAwOjAwOjAxLjc1 MSAKMDA6MDA6MDEuNzUxIFsvRGV2aWNlcy9hY3BpLzAvQ29uZmlnL10gKGxldmVsIDQpCjAwOjAw OjAxLjc1MSAgIFJhbVNpemUgICAgIDxpbnRlZ2VyPiA9IDB4MDAwMDAwMDAyMDAwMDAwMCAoNTM2 ODcwOTEyKQowMDowMDowMS43NTEgICBSYW1Ib2xlU2l6ZSA8aW50ZWdlcj4gPSAweDAwMDAwMDAw MjAwMDAwMDAgKDUzNjg3MDkxMikKMDA6MDA6MDEuNzUxICAgTnVtQ1BVcyAgICAgPGludGVnZXI+ ID0gMHgwMDAwMDAwMDAwMDAwMDAxICgxKQowMDowMDowMS43NTEgICBJT0FQSUMgICAgICA8aW50 ZWdlcj4gPSAweDAwMDAwMDAwMDAwMDAwMDEgKDEpCjAwOjAwOjAxLjc1MSAgIEZkY0VuYWJsZWQg IDxpbnRlZ2VyPiA9IDB4MDAwMDAwMDAwMDAwMDAwMSAoMSkKMDA6MDA6MDEuNzUxICAgSHBldEVu YWJsZWQgPGludGVnZXI+ID0gMHgwMDAwMDAwMDAwMDAwMDAwICgwKQowMDowMDowMS43NTEgICBT aG93UnRjICAgICA8aW50ZWdlcj4gPSAweDAwMDAwMDAwMDAwMDAwMDAgKDApCjAwOjAwOjAxLjc1 MSAgIFNob3dDcHUgICAgIDxpbnRlZ2VyPiA9IDB4MDAwMDAwMDAwMDAwMDAwMSAoMSkKMDA6MDA6 MDEuNzUxIAowMDowMDowMS43NTEgWy9EZXZpY2VzL2FjcGkvMC9MVU4jMC9dIChsZXZlbCA0KQow MDowMDowMS43NTEgICBEcml2ZXIgPHN0cmluZz4gID0gIkFDUElIb3N0IiAoY2NoPTkpCjAwOjAw OjAxLjc1MSAKMDA6MDA6MDEuNzUxIFsvRGV2aWNlcy9hY3BpLzAvTFVOIzAvQ29uZmlnL10gKGxl dmVsIDUpCjAwOjAwOjAxLjc1MSAKMDA6MDA6MDEuNzUxIFsvRGV2aWNlcy9pODI1NC9dIChsZXZl bCAyKQowMDowMDowMS43NTEgCjAwOjAwOjAxLjc1MSBbL0RldmljZXMvaTgyNTQvMC9dIChsZXZl bCAzKQowMDowMDowMS43NTEgCjAwOjAwOjAxLjc1MSBbL0RldmljZXMvaTgyNTQvMC9Db25maWcv XSAobGV2ZWwgNCkKMDA6MDA6MDEuNzUxIAowMDowMDowMS43NTIgWy9EZXZpY2VzL2k4MjU5L10g KGxldmVsIDIpCjAwOjAwOjAxLjc1MiAKMDA6MDA6MDEuNzUyIFsvRGV2aWNlcy9pODI1OS8wL10g KGxldmVsIDMpCjAwOjAwOjAxLjc1MiAgIFRydXN0ZWQgPGludGVnZXI+ID0gMHgwMDAwMDAwMDAw MDAwMDAxICgxKQowMDowMDowMS43NTIgCjAwOjAwOjAxLjc1MiBbL0RldmljZXMvaTgyNTkvMC9D b25maWcvXSAobGV2ZWwgNCkKMDA6MDA6MDEuNzUyIAowMDowMDowMS43NTIgWy9EZXZpY2VzL2Fw aWMvXSAobGV2ZWwgMikKMDA6MDA6MDEuNzUyIAowMDowMDowMS43NTIgWy9EZXZpY2VzL2FwaWMv MC9dIChsZXZlbCAzKQowMDowMDowMS43NTIgICBUcnVzdGVkIDxpbnRlZ2VyPiA9IDB4MDAwMDAw MDAwMDAwMDAwMSAoMSkKMDA6MDA6MDEuNzUyIAowMDowMDowMS43NTIgWy9EZXZpY2VzL2FwaWMv MC9Db25maWcvXSAobGV2ZWwgNCkKMDA6MDA6MDEuNzUyICAgSU9BUElDICA8aW50ZWdlcj4gPSAw eDAwMDAwMDAwMDAwMDAwMDEgKDEpCjAwOjAwOjAxLjc1MiAgIE51bUNQVXMgPGludGVnZXI+ID0g MHgwMDAwMDAwMDAwMDAwMDAxICgxKQowMDowMDowMS43NTIgCjAwOjAwOjAxLjc1MiBbL0Rldmlj ZXMvaW9hcGljL10gKGxldmVsIDIpCjAwOjAwOjAxLjc1MiAKMDA6MDA6MDEuNzUyIFsvRGV2aWNl cy9pb2FwaWMvMC9dIChsZXZlbCAzKQowMDowMDowMS43NTIgICBUcnVzdGVkIDxpbnRlZ2VyPiA9 IDB4MDAwMDAwMDAwMDAwMDAwMSAoMSkKMDA6MDA6MDEuNzUyIAowMDowMDowMS43NTIgWy9EZXZp Y2VzL2lvYXBpYy8wL0NvbmZpZy9dIChsZXZlbCA0KQowMDowMDowMS43NTIgCjAwOjAwOjAxLjc1 MiBbL0RldmljZXMvbWMxNDY4MTgvXSAobGV2ZWwgMikKMDA6MDA6MDEuNzUyIAowMDowMDowMS43 NTIgWy9EZXZpY2VzL21jMTQ2ODE4LzAvXSAobGV2ZWwgMykKMDA6MDA6MDEuNzUyIAowMDowMDow MS43NTIgWy9EZXZpY2VzL21jMTQ2ODE4LzAvQ29uZmlnL10gKGxldmVsIDQpCjAwOjAwOjAxLjc1 MiAKMDA6MDA6MDEuNzUyIFsvRGV2aWNlcy92Z2EvXSAobGV2ZWwgMikKMDA6MDA6MDEuNzUyIAow MDowMDowMS43NTIgWy9EZXZpY2VzL3ZnYS8wL10gKGxldmVsIDMpCjAwOjAwOjAxLjc1MiAgIFRy dXN0ZWQgICAgICAgPGludGVnZXI+ID0gMHgwMDAwMDAwMDAwMDAwMDAxICgxKQowMDowMDowMS43 NTIgICBQQ0lEZXZpY2VObyAgIDxpbnRlZ2VyPiA9IDB4MDAwMDAwMDAwMDAwMDAwMiAoMikKMDA6 MDA6MDEuNzUyICAgUENJRnVuY3Rpb25ObyA8aW50ZWdlcj4gPSAweDAwMDAwMDAwMDAwMDAwMDAg KDApCjAwOjAwOjAxLjc1MiAKMDA6MDA6MDEuNzUyIFsvRGV2aWNlcy92Z2EvMC9Db25maWcvXSAo bGV2ZWwgNCkKMDA6MDA6MDEuNzUyICAgVlJhbVNpemUgICAgICAgICA8aW50ZWdlcj4gPSAweDAw MDAwMDAwMDA1MDAwMDAgKDUyNDI4ODApCjAwOjAwOjAxLjc1MiAgIFIwRW5hYmxlZCAgICAgICAg PGludGVnZXI+ID0gMHgwMDAwMDAwMDAwMDAwMDAxICgxKQowMDowMDowMS43NTIgICBGYWRlSW4g ICAgICAgICAgIDxpbnRlZ2VyPiA9IDB4MDAwMDAwMDAwMDAwMDAwMSAoMSkKMDA6MDA6MDEuNzUy ICAgRmFkZU91dCAgICAgICAgICA8aW50ZWdlcj4gPSAweDAwMDAwMDAwMDAwMDAwMDEgKDEpCjAw OjAwOjAxLjc1MiAgIExvZ29UaW1lICAgICAgICAgPGludGVnZXI+ID0gMHgwMDAwMDAwMDAwMDAw MDAwICgwKQowMDowMDowMS43NTIgICBMb2dvRmlsZSAgICAgICAgIDxzdHJpbmc+ICA9ICIiIChj Y2g9MSkKMDA6MDA6MDEuNzUyICAgU2hvd0Jvb3RNZW51ICAgICA8aW50ZWdlcj4gPSAweDAwMDAw MDAwMDAwMDAwMDIgKDIpCjAwOjAwOjAxLjc1MiAgIEN1c3RvbVZpZGVvTW9kZXMgPGludGVnZXI+ ID0gMHgwMDAwMDAwMDAwMDAwMDAwICgwKQowMDowMDowMS43NTIgICBIZWlnaHRSZWR1Y3Rpb24g IDxpbnRlZ2VyPiA9IDB4MDAwMDAwMDAwMDAwMDAwMCAoMCkKMDA6MDA6MDEuNzUyIAowMDowMDow MS43NTIgWy9EZXZpY2VzL3ZnYS8wL0xVTiMwL10gKGxldmVsIDQpCjAwOjAwOjAxLjc1MiAgIERy aXZlciA8c3RyaW5nPiAgPSAiTWFpbkRpc3BsYXkiIChjY2g9MTIpCjAwOjAwOjAxLjc1MiAKMDA6 MDA6MDEuNzUyIFsvRGV2aWNlcy92Z2EvMC9MVU4jMC9Db25maWcvXSAobGV2ZWwgNSkKMDA6MDA6 MDEuNzUzICAgT2JqZWN0IDxpbnRlZ2VyPiA9IDB4MDAwMDAwMDAwMDg1N2UwMCAoODc0ODU0NCkK MDA6MDA6MDEuNzUzIAowMDowMDowMS43NTMgWy9EZXZpY2VzL3BpaXgzaWRlL10gKGxldmVsIDIp CjAwOjAwOjAxLjc1MyAKMDA6MDA6MDEuNzUzIFsvRGV2aWNlcy9waWl4M2lkZS8wL10gKGxldmVs IDMpCjAwOjAwOjAxLjc1MyAgIFRydXN0ZWQgICAgICAgPGludGVnZXI+ID0gMHgwMDAwMDAwMDAw MDAwMDAxICgxKQowMDowMDowMS43NTMgICBQQ0lEZXZpY2VObyAgIDxpbnRlZ2VyPiA9IDB4MDAw MDAwMDAwMDAwMDAwMSAoMSkKMDA6MDA6MDEuNzUzICAgUENJRnVuY3Rpb25ObyA8aW50ZWdlcj4g PSAweDAwMDAwMDAwMDAwMDAwMDEgKDEpCjAwOjAwOjAxLjc1MyAKMDA6MDA6MDEuNzUzIFsvRGV2 aWNlcy9waWl4M2lkZS8wL0NvbmZpZy9dIChsZXZlbCA0KQowMDowMDowMS43NTMgICBUeXBlIDxz dHJpbmc+ICA9ICJQSUlYNCIgKGNjaD02KQowMDowMDowMS43NTMgCjAwOjAwOjAxLjc1MyBbL0Rl dmljZXMvcGlpeDNpZGUvMC9MVU4jOTk5L10gKGxldmVsIDQpCjAwOjAwOjAxLjc1MyAgIERyaXZl ciA8c3RyaW5nPiAgPSAiTWFpblN0YXR1cyIgKGNjaD0xMSkKMDA6MDA6MDEuNzUzIAowMDowMDow MS43NTMgWy9EZXZpY2VzL3BpaXgzaWRlLzAvTFVOIzk5OS9Db25maWcvXSAobGV2ZWwgNSkKMDA6 MDA6MDEuNzUzICAgcGFwTGVkcyA8aW50ZWdlcj4gPSAweDAwMDAwMDAwMDI4NmZjZWMgKDQyNDAx MDA0KQowMDowMDowMS43NTMgICBGaXJzdCAgIDxpbnRlZ2VyPiA9IDB4MDAwMDAwMDAwMDAwMDAw MCAoMCkKMDA6MDA6MDEuNzUzICAgTGFzdCAgICA8aW50ZWdlcj4gPSAweDAwMDAwMDAwMDAwMDAw MDMgKDMpCjAwOjAwOjAxLjc1MyAKMDA6MDA6MDEuNzUzIFsvRGV2aWNlcy9waWl4M2lkZS8wL0xV TiMyL10gKGxldmVsIDQpCjAwOjAwOjAxLjc1MyAgIERyaXZlciA8c3RyaW5nPiAgPSAiQmxvY2si IChjY2g9NikKMDA6MDA6MDEuNzUzIAowMDowMDowMS43NTMgWy9EZXZpY2VzL3BpaXgzaWRlLzAv TFVOIzIvQ29uZmlnL10gKGxldmVsIDUpCjAwOjAwOjAxLjc1MyAgIFR5cGUgICAgICA8c3RyaW5n PiAgPSAiRFZEIiAoY2NoPTQpCjAwOjAwOjAxLjc1MyAgIE1vdW50YWJsZSA8aW50ZWdlcj4gPSAw eDAwMDAwMDAwMDAwMDAwMDEgKDEpCjAwOjAwOjAxLjc1MyAKMDA6MDA6MDEuNzUzIFsvRGV2aWNl cy9waWl4M2lkZS8wL0xVTiMwL10gKGxldmVsIDQpCjAwOjAwOjAxLjc1MyAgIERyaXZlciA8c3Ry aW5nPiAgPSAiQmxvY2siIChjY2g9NikKMDA6MDA6MDEuNzUzIAowMDowMDowMS43NTMgWy9EZXZp Y2VzL3BpaXgzaWRlLzAvTFVOIzAvQ29uZmlnL10gKGxldmVsIDUpCjAwOjAwOjAxLjc1MyAgIFR5 cGUgICAgICA8c3RyaW5nPiAgPSAiSGFyZERpc2siIChjY2g9OSkKMDA6MDA6MDEuNzUzICAgTW91 bnRhYmxlIDxpbnRlZ2VyPiA9IDB4MDAwMDAwMDAwMDAwMDAwMCAoMCkKMDA6MDA6MDEuNzUzIAow MDowMDowMS43NTMgWy9EZXZpY2VzL3BpaXgzaWRlLzAvTFVOIzAvQXR0YWNoZWREcml2ZXIvXSAo bGV2ZWwgNSkKMDA6MDA6MDEuNzUzICAgRHJpdmVyIDxzdHJpbmc+ICA9ICJWRCIgKGNjaD0zKQow MDowMDowMS43NTMgCjAwOjAwOjAxLjc1MyBbL0RldmljZXMvcGlpeDNpZGUvMC9MVU4jMC9BdHRh Y2hlZERyaXZlci9Db25maWcvXSAobGV2ZWwgNikKMDA6MDA6MDEuNzUzICAgUGF0aCAgIDxzdHJp bmc+ICA9ICIvVXNlcnMvbWF0dGhpYXMvTGlicmFyeS9WaXJ0dWFsQm94L01hY2hpbmVzL0ZyZWVC U0Qga2xlaW4vU25hcHNob3RzL3tlZTk3ZjBlZi05NjI1LTQyMWYtOWI3Yy1mOWRkYThkNGM3NjJ9 LnZkaSIgKGNjaD0xMTEpCjAwOjAwOjAxLjc1MyAgIEZvcm1hdCA8c3RyaW5nPiAgPSAiVkRJIiAo Y2NoPTQpCjAwOjAwOjAxLjc1MyAKMDA6MDA6MDEuNzUzIFsvRGV2aWNlcy9waWl4M2lkZS8wL0xV TiMwL0F0dGFjaGVkRHJpdmVyL0NvbmZpZy9QYXJlbnQvXSAobGV2ZWwgNykKMDA6MDA6MDEuNzUz ICAgUGF0aCAgIDxzdHJpbmc+ICA9ICIvVXNlcnMvbWF0dGhpYXMvTGlicmFyeS9WaXJ0dWFsQm94 L01hY2hpbmVzL0ZyZWVCU0Qga2xlaW4vU25hcHNob3RzL3tkOTcyMTJkMi0wMTliLTQ0NTgtODkz OS0yNTY4ZWY3MzZjMmZ9LnZkaSIgKGNjaD0xMTEpCjAwOjAwOjAxLjc1MyAgIEZvcm1hdCA8c3Ry aW5nPiAgPSAiVkRJIiAoY2NoPTQpCjAwOjAwOjAxLjc1MyAKMDA6MDA6MDEuNzUzIFsvRGV2aWNl cy9waWl4M2lkZS8wL0xVTiMwL0F0dGFjaGVkRHJpdmVyL0NvbmZpZy9QYXJlbnQvUGFyZW50L10g KGxldmVsIDgpCjAwOjAwOjAxLjc1MyAgIFBhdGggICA8c3RyaW5nPiAgPSAiL1VzZXJzL21hdHRo aWFzL0xpYnJhcnkvVmlydHVhbEJveC9IYXJkRGlza3MvRnJlZUJTRCBrbGVpbi52ZGkiIChjY2g9 NjMpCjAwOjAwOjAxLjc1MyAgIEZvcm1hdCA8c3RyaW5nPiAgPSAiVkRJIiAoY2NoPTQpCjAwOjAw OjAxLjc1MyAKMDA6MDA6MDEuNzUzIFsvRGV2aWNlcy9wY25ldC9dIChsZXZlbCAyKQowMDowMDow MS43NTMgCjAwOjAwOjAxLjc1MyBbL0RldmljZXMvZTEwMDAvXSAobGV2ZWwgMikKMDA6MDA6MDEu NzUzIAowMDowMDowMS43NTMgWy9EZXZpY2VzL2UxMDAwLzAvXSAobGV2ZWwgMykKMDA6MDA6MDEu NzUzICAgVHJ1c3RlZCAgICAgICA8aW50ZWdlcj4gPSAweDAwMDAwMDAwMDAwMDAwMDEgKDEpCjAw OjAwOjAxLjc1MyAgIFBDSURldmljZU5vICAgPGludGVnZXI+ID0gMHgwMDAwMDAwMDAwMDAwMDAz ICgzKQowMDowMDowMS43NTMgICBQQ0lGdW5jdGlvbk5vIDxpbnRlZ2VyPiA9IDB4MDAwMDAwMDAw MDAwMDAwMCAoMCkKMDA6MDA6MDEuNzUzIAowMDowMDowMS43NTMgWy9EZXZpY2VzL2UxMDAwLzAv Q29uZmlnL10gKGxldmVsIDQpCjAwOjAwOjAxLjc1NCAgIEFkYXB0ZXJUeXBlICAgIDxpbnRlZ2Vy PiA9IDB4MDAwMDAwMDAwMDAwMDAwMCAoMCkKMDA6MDA6MDEuNzU0ICAgTUFDICAgICAgICAgICAg PGJ5dGVzPiAgID0gIjA4IDAwIDI3IGJlIGVlIGNhIiAoY2I9NikKMDA6MDA6MDEuNzU0ICAgQ2Fi bGVDb25uZWN0ZWQgPGludGVnZXI+ID0gMHgwMDAwMDAwMDAwMDAwMDAxICgxKQowMDowMDowMS43 NTQgICBMaW5lU3BlZWQgICAgICA8aW50ZWdlcj4gPSAweDAwMDAwMDAwMDAwMDAwMDAgKDApCjAw OjAwOjAxLjc1NCAKMDA6MDA6MDEuNzU0IFsvRGV2aWNlcy9lMTAwMC8wL0xVTiM5OTkvXSAobGV2 ZWwgNCkKMDA6MDA6MDEuNzU0ICAgRHJpdmVyIDxzdHJpbmc+ICA9ICJNYWluU3RhdHVzIiAoY2No PTExKQowMDowMDowMS43NTQgCjAwOjAwOjAxLjc1NCBbL0RldmljZXMvZTEwMDAvMC9MVU4jOTk5 L0NvbmZpZy9dIChsZXZlbCA1KQowMDowMDowMS43NTQgICBwYXBMZWRzIDxpbnRlZ2VyPiA9IDB4 MDAwMDAwMDAwMjg2ZmRiNCAoNDI0MDEyMDQpCjAwOjAwOjAxLjc1NCAKMDA6MDA6MDEuNzU0IFsv RGV2aWNlcy9lMTAwMC8wL0xVTiMwL10gKGxldmVsIDQpCjAwOjAwOjAxLjc1NCAgIERyaXZlciA8 c3RyaW5nPiAgPSAiSW50TmV0IiAoY2NoPTcpCjAwOjAwOjAxLjc1NCAKMDA6MDA6MDEuNzU0IFsv RGV2aWNlcy9lMTAwMC8wL0xVTiMwL0NvbmZpZy9dIChsZXZlbCA1KQowMDowMDowMS43NTQgICBU cnVuayAgICAgPHN0cmluZz4gID0gImVuMCIgKGNjaD00KQowMDowMDowMS43NTQgICBUcnVua1R5 cGUgPGludGVnZXI+ID0gMHgwMDAwMDAwMDAwMDAwMDAzICgzKQowMDowMDowMS43NTQgICBOZXR3 b3JrICAgPHN0cmluZz4gID0gIkhvc3RJbnRlcmZhY2VOZXR3b3JraW5nLWVuMDogRXRoZXJuZXQi IChjY2g9MzgpCjAwOjAwOjAxLjc1NCAKMDA6MDA6MDEuNzU0IFsvRGV2aWNlcy9zZXJpYWwvXSAo bGV2ZWwgMikKMDA6MDA6MDEuNzU0IAowMDowMDowMS43NTQgWy9EZXZpY2VzL3BhcmFsbGVsL10g KGxldmVsIDIpCjAwOjAwOjAxLjc1NCAKMDA6MDA6MDEuNzU0IFsvRGV2aWNlcy9WTU1EZXYvXSAo bGV2ZWwgMikKMDA6MDA6MDEuNzU0IAowMDowMDowMS43NTQgWy9EZXZpY2VzL1ZNTURldi8wL10g KGxldmVsIDMpCjAwOjAwOjAxLjc1NCAgIFRydXN0ZWQgICAgICAgPGludGVnZXI+ID0gMHgwMDAw MDAwMDAwMDAwMDAxICgxKQowMDowMDowMS43NTQgICBQQ0lEZXZpY2VObyAgIDxpbnRlZ2VyPiA9 IDB4MDAwMDAwMDAwMDAwMDAwNCAoNCkKMDA6MDA6MDEuNzU0ICAgUENJRnVuY3Rpb25ObyA8aW50 ZWdlcj4gPSAweDAwMDAwMDAwMDAwMDAwMDAgKDApCjAwOjAwOjAxLjc1NCAKMDA6MDA6MDEuNzU0 IFsvRGV2aWNlcy9WTU1EZXYvMC9Db25maWcvXSAobGV2ZWwgNCkKMDA6MDA6MDEuNzU0IAowMDow MDowMS43NTQgWy9EZXZpY2VzL1ZNTURldi8wL0xVTiMwL10gKGxldmVsIDQpCjAwOjAwOjAxLjc1 NCAgIERyaXZlciA8c3RyaW5nPiAgPSAiTWFpblZNTURldiIgKGNjaD0xMSkKMDA6MDA6MDEuNzU0 IAowMDowMDowMS43NTQgWy9EZXZpY2VzL1ZNTURldi8wL0xVTiMwL0NvbmZpZy9dIChsZXZlbCA1 KQowMDowMDowMS43NTQgICBPYmplY3QgPGludGVnZXI+ID0gMHgwMDAwMDAwMDAyMzQzZjcwICgz Njk3ODU0NCkKMDA6MDA6MDEuNzU0IAowMDowMDowMS43NTQgWy9EZXZpY2VzL1ZNTURldi8wL0xV TiM5OTkvXSAobGV2ZWwgNCkKMDA6MDA6MDEuNzU0ICAgRHJpdmVyIDxzdHJpbmc+ICA9ICJNYWlu U3RhdHVzIiAoY2NoPTExKQowMDowMDowMS43NTQgCjAwOjAwOjAxLjc1NCBbL0RldmljZXMvVk1N RGV2LzAvTFVOIzk5OS9Db25maWcvXSAobGV2ZWwgNSkKMDA6MDA6MDEuNzU0ICAgcGFwTGVkcyA8 aW50ZWdlcj4gPSAweDAwMDAwMDAwMDI4NmZkZDQgKDQyNDAxMjM2KQowMDowMDowMS43NTQgICBG aXJzdCAgIDxpbnRlZ2VyPiA9IDB4MDAwMDAwMDAwMDAwMDAwMCAoMCkKMDA6MDA6MDEuNzU0ICAg TGFzdCAgICA8aW50ZWdlcj4gPSAweDAwMDAwMDAwMDAwMDAwMDAgKDApCjAwOjAwOjAxLjc1NCAK MDA6MDA6MDEuNzU0IFsvRGV2aWNlcy9BdWRpb1NuaWZmZXIvXSAobGV2ZWwgMikKMDA6MDA6MDEu NzU0IAowMDowMDowMS43NTQgWy9EZXZpY2VzL0F1ZGlvU25pZmZlci8wL10gKGxldmVsIDMpCjAw OjAwOjAxLjc1NCAKMDA6MDA6MDEuNzU0IFsvRGV2aWNlcy9BdWRpb1NuaWZmZXIvMC9Db25maWcv XSAobGV2ZWwgNCkKMDA6MDA6MDEuNzU0IAowMDowMDowMS43NTQgWy9EZXZpY2VzL0F1ZGlvU25p ZmZlci8wL0xVTiMwL10gKGxldmVsIDQpCjAwOjAwOjAxLjc1NCAgIERyaXZlciA8c3RyaW5nPiAg PSAiTWFpbkF1ZGlvU25pZmZlciIgKGNjaD0xNykKMDA6MDA6MDEuNzU0IAowMDowMDowMS43NTQg Wy9EZXZpY2VzL0F1ZGlvU25pZmZlci8wL0xVTiMwL0NvbmZpZy9dIChsZXZlbCA1KQowMDowMDow MS43NTUgICBPYmplY3QgPGludGVnZXI+ID0gMHgwMDAwMDAwMDAyMzU1ZDIwICgzNzA1MTY4MCkK MDA6MDA6MDEuNzU1IAowMDowMDowMS43NTUgWy9EZXZpY2VzL2ljaGFjOTcvXSAobGV2ZWwgMikK MDA6MDA6MDEuNzU1IAowMDowMDowMS43NTUgWy9EZXZpY2VzL2ljaGFjOTcvMC9dIChsZXZlbCAz KQowMDowMDowMS43NTUgICBUcnVzdGVkICAgICAgIDxpbnRlZ2VyPiA9IDB4MDAwMDAwMDAwMDAw MDAwMSAoMSkKMDA6MDA6MDEuNzU1ICAgUENJRGV2aWNlTm8gICA8aW50ZWdlcj4gPSAweDAwMDAw MDAwMDAwMDAwMDUgKDUpCjAwOjAwOjAxLjc1NSAgIFBDSUZ1bmN0aW9uTm8gPGludGVnZXI+ID0g MHgwMDAwMDAwMDAwMDAwMDAwICgwKQowMDowMDowMS43NTUgCjAwOjAwOjAxLjc1NSBbL0Rldmlj ZXMvaWNoYWM5Ny8wL0NvbmZpZy9dIChsZXZlbCA0KQowMDowMDowMS43NTUgCjAwOjAwOjAxLjc1 NSBbL0RldmljZXMvaWNoYWM5Ny8wL0xVTiMwL10gKGxldmVsIDQpCjAwOjAwOjAxLjc1NSAgIERy aXZlciA8c3RyaW5nPiAgPSAiQVVESU8iIChjY2g9NikKMDA6MDA6MDEuNzU1IAowMDowMDowMS43 NTUgWy9EZXZpY2VzL2ljaGFjOTcvMC9MVU4jMC9Db25maWcvXSAobGV2ZWwgNSkKMDA6MDA6MDEu NzU1ICAgQXVkaW9Ecml2ZXIgPHN0cmluZz4gID0gImNvcmVhdWRpbyIgKGNjaD0xMCkKMDA6MDA6 MDEuNzU1ICAgU3RyZWFtTmFtZSAgPHN0cmluZz4gID0gIkZyZWVCU0Qga2xlaW4iIChjY2g9MTQp CjAwOjAwOjAxLjc1NSAKMDA6MDA6MDEuNzU1IFsvRGV2aWNlcy91c2Itb2hjaS9dIChsZXZlbCAy KQowMDowMDowMS43NTUgCjAwOjAwOjAxLjc1NSBbL0RldmljZXMvdXNiLW9oY2kvMC9dIChsZXZl bCAzKQowMDowMDowMS43NTUgICBUcnVzdGVkICAgICAgIDxpbnRlZ2VyPiA9IDB4MDAwMDAwMDAw MDAwMDAwMSAoMSkKMDA6MDA6MDEuNzU1ICAgUENJRGV2aWNlTm8gICA8aW50ZWdlcj4gPSAweDAw MDAwMDAwMDAwMDAwMDYgKDYpCjAwOjAwOjAxLjc1NSAgIFBDSUZ1bmN0aW9uTm8gPGludGVnZXI+ ID0gMHgwMDAwMDAwMDAwMDAwMDAwICgwKQowMDowMDowMS43NTUgCjAwOjAwOjAxLjc1NSBbL0Rl dmljZXMvdXNiLW9oY2kvMC9Db25maWcvXSAobGV2ZWwgNCkKMDA6MDA6MDEuNzU1IAowMDowMDow MS43NTUgWy9EZXZpY2VzL3VzYi1vaGNpLzAvTFVOIzAvXSAobGV2ZWwgNCkKMDA6MDA6MDEuNzU1 ICAgRHJpdmVyIDxzdHJpbmc+ICA9ICJWVVNCUm9vdEh1YiIgKGNjaD0xMikKMDA6MDA6MDEuNzU1 IAowMDowMDowMS43NTUgWy9EZXZpY2VzL3VzYi1vaGNpLzAvTFVOIzAvQ29uZmlnL10gKGxldmVs IDUpCjAwOjAwOjAxLjc1NSAKMDA6MDA6MDEuNzU1IFsvRGV2aWNlcy91c2Itb2hjaS8wL0xVTiM5 OTkvXSAobGV2ZWwgNCkKMDA6MDA6MDEuNzU1ICAgRHJpdmVyIDxzdHJpbmc+ICA9ICJNYWluU3Rh dHVzIiAoY2NoPTExKQowMDowMDowMS43NTUgCjAwOjAwOjAxLjc1NSBbL0RldmljZXMvdXNiLW9o Y2kvMC9MVU4jOTk5L0NvbmZpZy9dIChsZXZlbCA1KQowMDowMDowMS43NTUgICBwYXBMZWRzIDxp bnRlZ2VyPiA9IDB4MDAwMDAwMDAwMjg2ZmRkOCAoNDI0MDEyNDApCjAwOjAwOjAxLjc1NSAgIEZp cnN0ICAgPGludGVnZXI+ID0gMHgwMDAwMDAwMDAwMDAwMDAwICgwKQowMDowMDowMS43NTUgICBM YXN0ICAgIDxpbnRlZ2VyPiA9IDB4MDAwMDAwMDAwMDAwMDAwMCAoMCkKMDA6MDA6MDEuNzU1IAow MDowMDowMS43NTUgWy9EZXZpY2VzL3VzYi1laGNpL10gKGxldmVsIDIpCjAwOjAwOjAxLjc1NSAK MDA6MDA6MDEuNzU1IFsvRGV2aWNlcy91c2ItZWhjaS8wL10gKGxldmVsIDMpCjAwOjAwOjAxLjc1 NSAgIFRydXN0ZWQgICAgICAgPGludGVnZXI+ID0gMHgwMDAwMDAwMDAwMDAwMDAxICgxKQowMDow MDowMS43NTUgICBQQ0lEZXZpY2VObyAgIDxpbnRlZ2VyPiA9IDB4MDAwMDAwMDAwMDAwMDAwYiAo MTEpCjAwOjAwOjAxLjc1NSAgIFBDSUZ1bmN0aW9uTm8gPGludGVnZXI+ID0gMHgwMDAwMDAwMDAw MDAwMDAwICgwKQowMDowMDowMS43NTUgCjAwOjAwOjAxLjc1NSBbL0RldmljZXMvdXNiLWVoY2kv MC9Db25maWcvXSAobGV2ZWwgNCkKMDA6MDA6MDEuNzU1IAowMDowMDowMS43NTUgWy9EZXZpY2Vz L3VzYi1laGNpLzAvTFVOIzAvXSAobGV2ZWwgNCkKMDA6MDA6MDEuNzU1ICAgRHJpdmVyIDxzdHJp bmc+ICA9ICJWVVNCUm9vdEh1YiIgKGNjaD0xMikKMDA6MDA6MDEuNzU1IAowMDowMDowMS43NTUg Wy9EZXZpY2VzL3VzYi1laGNpLzAvTFVOIzAvQ29uZmlnL10gKGxldmVsIDUpCjAwOjAwOjAxLjc1 NSAKMDA6MDA6MDEuNzU1IFsvRGV2aWNlcy91c2ItZWhjaS8wL0xVTiM5OTkvXSAobGV2ZWwgNCkK MDA6MDA6MDEuNzU1ICAgRHJpdmVyIDxzdHJpbmc+ICA9ICJNYWluU3RhdHVzIiAoY2NoPTExKQow MDowMDowMS43NTUgCjAwOjAwOjAxLjc1NSBbL0RldmljZXMvdXNiLWVoY2kvMC9MVU4jOTk5L0Nv bmZpZy9dIChsZXZlbCA1KQowMDowMDowMS43NTYgICBwYXBMZWRzIDxpbnRlZ2VyPiA9IDB4MDAw MDAwMDAwMjg2ZmRkYyAoNDI0MDEyNDQpCjAwOjAwOjAxLjc1NiAgIEZpcnN0ICAgPGludGVnZXI+ ID0gMHgwMDAwMDAwMDAwMDAwMDAwICgwKQowMDowMDowMS43NTYgICBMYXN0ICAgIDxpbnRlZ2Vy PiA9IDB4MDAwMDAwMDAwMDAwMDAwMCAoMCkKMDA6MDA6MDEuNzU2IAowMDowMDowMS43NTYgWy9U TS9dIChsZXZlbCAxKQowMDowMDowMS43NTYgICBVVENPZmZzZXQgPGludGVnZXI+ID0gMHgwMDAw MDAwMDAwMDAwMDAwICgwKQowMDowMDowMS43NTYgCjAwOjAwOjAxLjc1NiAqKioqKioqKioqKioq KioqKioqKiogRW5kIG9mIENGR00gZHVtcCAqKioqKioqKioqKioqKioqKioqKioqCjAwOjAwOjAx Ljc1NiBNTTogY2JIeXBlckhlYXA9MHhhMDAwMCAoNjU1MzYwKQowMDowMDowMS43NjggTG9naWNh bCBob3N0IHByb2Nlc3NvcnM6IDIsIHByb2Nlc3NvciBhY3RpdmUgbWFzazogMDAwMDAwMDAwMDAw MDAwMwowMDowMDowMS43NjggKioqKioqKioqKioqKioqKioqKioqKioqKiBDUFVJRCBkdW1wICoq KioqKioqKioqKioqKioqKioqKioqKgowMDowMDowMS43NjggICAgICAgICAgUkFXIFN0YW5kYXJk IENQVUlEcwowMDowMDowMS43NjggICAgICBGdW5jdGlvbiAgZWF4ICAgICAgZWJ4ICAgICAgZWN4 ICAgICAgZWR4CjAwOjAwOjAxLjc2OCBHc3Q6IDAwMDAwMDAwICAwMDAwMDAwNSA3NTZlNjU0NyA2 YzY1NzQ2ZSA0OTY1NmU2OQowMDowMDowMS43NjggSHN0OiAgICAgICAgICAgMDAwMDAwMGEgNzU2 ZTY1NDcgNmM2NTc0NmUgNDk2NTZlNjkKMDA6MDA6MDEuNzY4IEdzdDogMDAwMDAwMDEgIDAwMDAw NmY2IDAwMDAwODAwIDAwMDAwMDA5IDA3OGJmMWJmCjAwOjAwOjAxLjc2OCBIc3Q6ICAgICAgICAg ICAwMDAwMDZmNiAwMDAyMDgwMCAwMDAwZTNiZCBiZmViZmJmZgowMDowMDowMS43NjggR3N0OiAw MDAwMDAwMiAgMDViMGIxMDEgMDA1NjU3ZjAgMDAwMDAwMDAgMmNiNDMwNDkKMDA6MDA6MDEuNzY4 IEhzdDogICAgICAgICAgIDA1YjBiMTAxIDAwNTY1N2YwIDAwMDAwMDAwIDJjYjQzMDQ5CjAwOjAw OjAxLjc2OCBHc3Q6IDAwMDAwMDAzICAwMDAwMDAwMCAwMDAwMDAwMCAwMDAwMDAwMCAwMDAwMDAw MAowMDowMDowMS43NjggSHN0OiAgICAgICAgICAgMDAwMDAwMDAgMDAwMDAwMDAgMDAwMDAwMDAg MDAwMDAwMDAKMDA6MDA6MDEuNzY4IEdzdDogMDAwMDAwMDQgIDAwMDAwMDAwIDAwMDAwMDAwIDAw MDAwMDAwIDAwMDAwMDAwCjAwOjAwOjAxLjc2OCBIc3Q6ICAgICAgICAgICAwNDAwMDEyMSAwMWMw MDAzZiAwMDAwMDAzZiAwMDAwMDAwMQowMDowMDowMS43NjggR3N0OiAwMDAwMDAwNSAgMDAwMDAw NDAgMDAwMDAwNDAgMDAwMDAwMDAgMDAwMDAwMDAKMDA6MDA6MDEuNzY4IEhzdDogICAgICAgICAg IDAwMDAwMDQwIDAwMDAwMDQwIDAwMDAwMDAzIDAwMDIyMjIwCjAwOjAwOjAxLjc2OCBOYW1lOiAg ICAgICAgICAgICAgICAgICAgICAgICAgICBHZW51aW5lSW50ZWwKMDA6MDA6MDEuNzY4IFN1cHBv cnRzOiAgICAgICAgICAgICAgICAgICAgICAgIDAtNQowMDowMDowMS43NjggRmFtaWx5OiAgICAg ICAgICAgICAgICAgICAgICAgICAgNiAgCUV4dGVuZGVkOiAwIAlFZmZlY3RpdmU6IDYKMDA6MDA6 MDEuNzY4IE1vZGVsOiAgICAgICAgICAgICAgICAgICAgICAgICAgIDE1ICAJRXh0ZW5kZWQ6IDAg CUVmZmVjdGl2ZTogMTUKMDA6MDA6MDEuNzY4IFN0ZXBwaW5nOiAgICAgICAgICAgICAgICAgICAg ICAgIDYKMDA6MDA6MDEuNzY4IEFQSUMgSUQ6ICAgICAgICAgICAgICAgICAgICAgICAgIDB4MDAK MDA6MDA6MDEuNzY4IExvZ2ljYWwgQ1BVczogICAgICAgICAgICAgICAgICAgIDAKMDA6MDA6MDEu NzY4IENMRkxVU0ggU2l6ZTogICAgICAgICAgICAgICAgICAgIDgKMDA6MDA6MDEuNzY4IEJyYW5k IElEOiAgICAgICAgICAgICAgICAgICAgICAgIDB4MDAKMDA6MDA6MDEuNzY4IE1uZW1vbmljIC0g RGVzY3JpcHRpb24gICAgICAgICAgICAgICAgID0gZ3Vlc3QgKGhvc3QpCjAwOjAwOjAxLjc2OCBG UFUgLSB4ODcgRlBVIG9uIENoaXAgICAgICAgICAgICAgICAgICA9IDEgKDEpCjAwOjAwOjAxLjc2 OCBWTUUgLSBWaXJ0dWFsIDgwODYgTW9kZSBFbmhhbmNlbWVudHMgICA9IDEgKDEpCjAwOjAwOjAx Ljc2OCBERSAtIERlYnVnZ2luZyBleHRlbnNpb25zICAgICAgICAgICAgICA9IDEgKDEpCjAwOjAw OjAxLjc2OCBQU0UgLSBQYWdlIFNpemUgRXh0ZW5zaW9uICAgICAgICAgICAgICA9IDEgKDEpCjAw OjAwOjAxLjc2OCBUU0MgLSBUaW1lIFN0YW1wIENvdW50ZXIgICAgICAgICAgICAgICA9IDEgKDEp CjAwOjAwOjAxLjc2OCBNU1IgLSBNb2RlbCBTcGVjaWZpYyBSZWdpc3RlcnMgICAgICAgICA9IDEg KDEpCjAwOjAwOjAxLjc2OCBQQUUgLSBQaHlzaWNhbCBBZGRyZXNzIEV4dGVuc2lvbiAgICAgICA9 IDAgKDEpCjAwOjAwOjAxLjc2OCBNQ0UgLSBNYWNoaW5lIENoZWNrIEV4Y2VwdGlvbiAgICAgICAg ICA9IDEgKDEpCjAwOjAwOjAxLjc2OCBDWDggLSBDTVBYQ0hHOEIgaW5zdHJ1Y3Rpb24gICAgICAg ICAgICA9IDEgKDEpCjAwOjAwOjAxLjc2OCBBUElDIC0gQVBJQyBPbi1DaGlwICAgICAgICAgICAg ICAgICAgICA9IDAgKDEpCjAwOjAwOjAxLjc2OCBSZXNlcnZlZCAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICA9IDAgKDApCjAwOjAwOjAxLjc2OCBTRVAgLSBTWVNFTlRFUiBhbmQgU1lTRVhJ VCAgICAgICAgICAgICA9IDAgKDEpCjAwOjAwOjAxLjc2OCBNVFJSIC0gTWVtb3J5IFR5cGUgUmFu Z2UgUmVnaXN0ZXJzICAgICA9IDEgKDEpCjAwOjAwOjAxLjc2OCBQR0UgLSBQVEUgR2xvYmFsIEJp dCAgICAgICAgICAgICAgICAgICA9IDEgKDEpCjAwOjAwOjAxLjc2OCBNQ0EgLSBNYWNoaW5lIENo ZWNrIEFyY2hpdGVjdHVyZSAgICAgICA9IDEgKDEpCjAwOjAwOjAxLjc2OCBDTU9WIC0gQ29uZGl0 aW9uYWwgTW92ZSBJbnN0cnVjdGlvbnMgICA9IDEgKDEpCjAwOjAwOjAxLjc2OCBQQVQgLSBQYWdl IEF0dHJpYnV0ZSBUYWJsZSAgICAgICAgICAgICA9IDEgKDEpCjAwOjAwOjAxLjc2OCBQU0UtMzYg LSAzNi1iaXQgUGFnZSBTaXplIEV4dGVudGlvbiAgICA9IDEgKDEpCjAwOjAwOjAxLjc2OCBQU04g LSBQcm9jZXNzb3IgU2VyaWFsIE51bWJlciAgICAgICAgICA9IDAgKDApCjAwOjAwOjAxLjc2OCBD TEZTSCAtIENMRkxVU0ggSW5zdHJ1Y3Rpb24uICAgICAgICAgICA9IDEgKDEpCjAwOjAwOjAxLjc2 OCBSZXNlcnZlZCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICA9IDAgKDApCjAwOjAwOjAx Ljc2OCBEUyAtIERlYnVnIFN0b3JlICAgICAgICAgICAgICAgICAgICAgICA9IDAgKDEpCjAwOjAw OjAxLjc2OCBBQ1BJIC0gVGhlcm1hbCBNb24uICYgU29mdC4gQ2xvY2sgQ3RybC49IDAgKDEpCjAw OjAwOjAxLjc2OCBNTVggLSBJbnRlbCBNTVggVGVjaG5vbG9neSAgICAgICAgICAgICA9IDEgKDEp CjAwOjAwOjAxLjc2OCBGWFNSIC0gRlhTQVZFIGFuZCBGWFJTVE9SIEluc3RydWN0aW9ucyA9IDEg KDEpCjAwOjAwOjAxLjc2OCBTU0UgLSBTU0UgU3VwcG9ydCAgICAgICAgICAgICAgICAgICAgICA9 IDEgKDEpCjAwOjAwOjAxLjc2OCBTU0UyIC0gU1NFMiBTdXBwb3J0ICAgICAgICAgICAgICAgICAg ICA9IDEgKDEpCjAwOjAwOjAxLjc2OCBTUyAtIFNlbGYgU25vb3AgICAgICAgICAgICAgICAgICAg ICAgICA9IDAgKDEpCjAwOjAwOjAxLjc2OCBIVFQgLSBIeXBlci1UaHJlYWRpbmcgVGVjaG5vbG9n ICAgICAgICA9IDAgKDEpCjAwOjAwOjAxLjc2OCBUTSAtIFRoZXJtYWwgTW9uaXRvciAgICAgICAg ICAgICAgICAgICA9IDAgKDEpCjAwOjAwOjAxLjc2OCAzMCAtIFJlc2VydmVkICAgICAgICAgICAg ICAgICAgICAgICAgICA9IDAgKDApCjAwOjAwOjAxLjc2OCBQQkUgLSBQZW5kaW5nIEJyZWFrIEVu YWJsZSAgICAgICAgICAgICA9IDAgKDEpCjAwOjAwOjAxLjc2OCBTdXBwb3J0cyBTU0UzIG9yIG5v dCAgICAgICAgICAgICAgICAgICA9IDEgKDEpCjAwOjAwOjAxLjc2OCBSZXNlcnZlZCAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICA9IDAgKDApCjAwOjAwOjAxLjc2OCBEUyBBcmVhIDY0LWJp dCBsYXlvdXQgICAgICAgICAgICAgICAgICA9IDAgKDEpCjAwOjAwOjAxLjc2OCBTdXBwb3J0cyBN T05JVE9SL01XQUlUICAgICAgICAgICAgICAgICA9IDEgKDEpCjAwOjAwOjAxLjc2OCBDUEwtRFMg LSBDUEwgUXVhbGlmaWVkIERlYnVnIFN0b3JlICAgICA9IDAgKDEpCjAwOjAwOjAxLjc2OCBWTVgg LSBWaXJ0dWFsIE1hY2hpbmUgVGVjaG5vbG9neSAgICAgICA9IDAgKDEpCjAwOjAwOjAxLjc2OCBT TVggLSBTYWZlciBNb2RlIEV4dGVuc2lvbnMgICAgICAgICAgICA9IDAgKDApCjAwOjAwOjAxLjc2 OCBFbmhhbmNlZCBTcGVlZFN0ZXAgVGVjaG5vbG9neSAgICAgICAgICA9IDAgKDEpCjAwOjAwOjAx Ljc2OCBUZXJtaW5hbCBNb25pdG9yIDIgICAgICAgICAgICAgICAgICAgICA9IDAgKDEpCjAwOjAw OjAxLjc2OCBTdXBwb3J0cyBTdXBwbGVtZW50YWwgU1NFMyBvciBub3QgICAgICA9IDAgKDEpCjAw OjAwOjAxLjc2OCBMMSBDb250ZXh0IElEICAgICAgICAgICAgICAgICAgICAgICAgICA9IDAgKDAp CjAwOjAwOjAxLjc2OCBSZXNlcnZlZCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICA9IDB4 MCAoMHgwKQowMDowMDowMS43NjggQ01QWENIRzE2QiAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgPSAwICgxKQowMDowMDowMS43NjggeFRQUiBVcGRhdGUgQ29udHJvbCAgICAgICAgICAgICAg ICAgICAgPSAwICgxKQowMDowMDowMS43NjggUGVyZi9EZWJ1ZyBDYXBhYmlsaXR5IE1TUiAgICAg ICAgICAgICAgPSAwICgxKQowMDowMDowMS43NjggUmVzZXJ2ZWQgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgPSAweDAgKDB4MCkKMDA6MDA6MDEuNzY4IERpcmVjdCBDYWNoZSBBY2Nlc3Mg ICAgICAgICAgICAgICAgICAgID0gMCAoMCkKMDA6MDA6MDEuNzY4IFN1cHBvcnRzIFNTRTRfMSBv ciBub3QgICAgICAgICAgICAgICAgID0gMCAoMCkKMDA6MDA6MDEuNzY4IFN1cHBvcnRzIFNTRTRf MiBvciBub3QgICAgICAgICAgICAgICAgID0gMCAoMCkKMDA6MDA6MDEuNzY4IFN1cHBvcnRzIHRo ZSB4MkFQSUMgZXh0ZW5zaW9ucyAgICAgICAgID0gMCAoMCkKMDA6MDA6MDEuNzY4IFN1cHBvcnRz IE1PVkJFICAgICAgICAgICAgICAgICAgICAgICAgID0gMCAoMCkKMDA6MDA6MDEuNzY4IFN1cHBv cnRzIFBPUENOVCAgICAgICAgICAgICAgICAgICAgICAgID0gMCAoMCkKMDA6MDA6MDEuNzY5IFJl c2VydmVkICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgID0gMHgwICgweDApCjAwOjAwOjAx Ljc2OSBTdXBwb3J0cyBYU0FWRSAgICAgICAgICAgICAgICAgICAgICAgICA9IDAgKDApCjAwOjAw OjAxLjc2OSBTdXBwb3J0cyBPU1hTQVZFICAgICAgICAgICAgICAgICAgICAgICA9IDAgKDApCjAw OjAwOjAxLjc2OSBSZXNlcnZlZCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICA9IDB4MCAo MHgwKQowMDowMDowMS43NjkgCjAwOjAwOjAxLjc2OSAgICAgICAgICBSQVcgRXh0ZW5kZWQgQ1BV SURzCjAwOjAwOjAxLjc2OSAgICAgIEZ1bmN0aW9uICBlYXggICAgICBlYnggICAgICBlY3ggICAg ICBlZHgKMDA6MDA6MDEuNzY5IEdzdDogODAwMDAwMDAgIDgwMDAwMDA4IDAwMDAwMDAwIDAwMDAw MDAwIDAwMDAwMDAwCjAwOjAwOjAxLjc2OSBIc3Q6ICAgICAgICAgICA4MDAwMDAwOCAwMDAwMDAw MCAwMDAwMDAwMCAwMDAwMDAwMAowMDowMDowMS43NjkgR3N0OiA4MDAwMDAwMSAgMDAwMDAwMDAg MDAwMDAwMDAgMDAwMDAwMDAgMDAwMDAwMDAKMDA6MDA6MDEuNzY5IEhzdDogICAgICAgICAgIDAw MDAwMDAwIDAwMDAwMDAwIDAwMDAwMDAxIDIwMTAwMDAwCjAwOjAwOjAxLjc2OSBHc3Q6IDgwMDAw MDAyICA2NTc0NmU0OSAyOTUyMjg2YyA3MjZmNDMyMCA0ZDU0Mjg2NQowMDowMDowMS43NjkgSHN0 OiAgICAgICAgICAgNjU3NDZlNDkgMjk1MjI4NmMgNzI2ZjQzMjAgNGQ1NDI4NjUKMDA6MDA6MDEu NzY5IEdzdDogODAwMDAwMDMgIDQzMjAzMjI5IDIwMjA1NTUwIDIwMjAyMDIwIDU0MjAyMDIwCjAw OjAwOjAxLjc2OSBIc3Q6ICAgICAgICAgICA0MzIwMzIyOSAyMDIwNTU1MCAyMDIwMjAyMCA1NDIw MjAyMAowMDowMDowMS43NjkgR3N0OiA4MDAwMDAwNCAgMzAzMDMyMzcgMjA0MDIwMjAgMzAzMDJl MzIgMDA3YTQ4NDcKMDA6MDA6MDEuNzY5IEhzdDogICAgICAgICAgIDMwMzAzMjM3IDIwNDAyMDIw IDMwMzAyZTMyIDAwN2E0ODQ3CjAwOjAwOjAxLjc2OSBHc3Q6IDgwMDAwMDA1ICAwMDAwMDAwMCAw MDAwMDAwMCAwMDAwMDAwMCAwMDAwMDAwMAowMDowMDowMS43NjkgSHN0OiAgICAgICAgICAgMDAw MDAwMDAgMDAwMDAwMDAgMDAwMDAwMDAgMDAwMDAwMDAKMDA6MDA6MDEuNzY5IEdzdDogODAwMDAw MDYgIDAwMDAwMDAwIDAwMDAwMDAwIDEwMDA4MDQwIDAwMDAwMDAwCjAwOjAwOjAxLjc2OSBIc3Q6 ICAgICAgICAgICAwMDAwMDAwMCAwMDAwMDAwMCAxMDAwODA0MCAwMDAwMDAwMAowMDowMDowMS43 NjkgR3N0OiA4MDAwMDAwNyAgMDAwMDAwMDAgMDAwMDAwMDAgMDAwMDAwMDAgMDAwMDAwMDAKMDA6 MDA6MDEuNzY5IEhzdDogICAgICAgICAgIDAwMDAwMDAwIDAwMDAwMDAwIDAwMDAwMDAwIDAwMDAw MDAwCjAwOjAwOjAxLjc2OSBHc3Q6IDgwMDAwMDA4ICAwMDAwMzAyNCAwMDAwMDAwMCAwMDAwMDAw MCAwMDAwMDAwMAowMDowMDowMS43NjkgSHN0OiAgICAgICAgICAgMDAwMDMwMjQgMDAwMDAwMDAg MDAwMDAwMDAgMDAwMDAwMDAKMDA6MDA6MDEuNzY5IEdzdDogODAwMDAwMDkgIDA3MjgwMjAyIDAw MDAwMDAwIDAwMDAwMDAwIDAwMDAwMDAwKgowMDowMDowMS43NjkgSHN0OiAgICAgICAgICAgMDcy ODAyMDIgMDAwMDAwMDAgMDAwMDAwMDAgMDAwMDAwMDAKMDA6MDA6MDEuNzY5IEV4dCBOYW1lOiAg ICAgICAgICAgICAgICAgICAgICAgIAowMDowMDowMS43NjkgRXh0IFN1cHBvcnRzOiAgICAgICAg ICAgICAgICAgICAgMHg4MDAwMDAwMC0weDgwMDAwMDA4CjAwOjAwOjAxLjc2OSBGYW1pbHk6ICAg ICAgICAgICAgICAgICAgICAgICAgICAwICAJRXh0ZW5kZWQ6IDAgCUVmZmVjdGl2ZTogMAowMDow MDowMS43NjkgTW9kZWw6ICAgICAgICAgICAgICAgICAgICAgICAgICAgMCAgCUV4dGVuZGVkOiAw IAlFZmZlY3RpdmU6IDAKMDA6MDA6MDEuNzY5IFN0ZXBwaW5nOiAgICAgICAgICAgICAgICAgICAg ICAgIDAKMDA6MDA6MDEuNzY5IEJyYW5kIElEOiAgICAgICAgICAgICAgICAgICAgICAgIDB4MDAw CjAwOjAwOjAxLjc2OSBNbmVtb25pYyAtIERlc2NyaXB0aW9uICAgICAgICAgICAgICAgICA9IGd1 ZXN0IChob3N0KQowMDowMDowMS43NjkgRlBVIC0geDg3IEZQVSBvbiBDaGlwICAgICAgICAgICAg ICAgICAgPSAwICgwKQowMDowMDowMS43NjkgVk1FIC0gVmlydHVhbCA4MDg2IE1vZGUgRW5oYW5j ZW1lbnRzICAgPSAwICgwKQowMDowMDowMS43NjkgREUgLSBEZWJ1Z2dpbmcgZXh0ZW5zaW9ucyAg ICAgICAgICAgICAgPSAwICgwKQowMDowMDowMS43NjkgUFNFIC0gUGFnZSBTaXplIEV4dGVuc2lv biAgICAgICAgICAgICAgPSAwICgwKQowMDowMDowMS43NjkgVFNDIC0gVGltZSBTdGFtcCBDb3Vu dGVyICAgICAgICAgICAgICAgPSAwICgwKQowMDowMDowMS43NjkgTVNSIC0gSzg2IE1vZGVsIFNw ZWNpZmljIFJlZ2lzdGVycyAgICAgPSAwICgwKQowMDowMDowMS43NjkgUEFFIC0gUGh5c2ljYWwg QWRkcmVzcyBFeHRlbnNpb24gICAgICAgPSAwICgwKQowMDowMDowMS43NjkgTUNFIC0gTWFjaGlu ZSBDaGVjayBFeGNlcHRpb24gICAgICAgICAgPSAwICgwKQowMDowMDowMS43NjkgQ1g4IC0gQ01Q WENIRzhCIGluc3RydWN0aW9uICAgICAgICAgICAgPSAwICgwKQowMDowMDowMS43NjkgQVBJQyAt IEFQSUMgT24tQ2hpcCAgICAgICAgICAgICAgICAgICAgPSAwICgwKQowMDowMDowMS43NjkgMTAg LSBSZXNlcnZlZCAgICAgICAgICAgICAgICAgICAgICAgICAgPSAwICgwKQowMDowMDowMS43Njkg U0VQIC0gU1lTQ0FMTCBhbmQgU1lTUkVUICAgICAgICAgICAgICAgPSAwICgwKQowMDowMDowMS43 NjkgTVRSUiAtIE1lbW9yeSBUeXBlIFJhbmdlIFJlZ2lzdGVycyAgICAgPSAwICgwKQowMDowMDow MS43NjkgUEdFIC0gUFRFIEdsb2JhbCBCaXQgICAgICAgICAgICAgICAgICAgPSAwICgwKQowMDow MDowMS43NjkgTUNBIC0gTWFjaGluZSBDaGVjayBBcmNoaXRlY3R1cmUgICAgICAgPSAwICgwKQow MDowMDowMS43NjkgQ01PViAtIENvbmRpdGlvbmFsIE1vdmUgSW5zdHJ1Y3Rpb25zICAgPSAwICgw KQowMDowMDowMS43NjkgUEFUIC0gUGFnZSBBdHRyaWJ1dGUgVGFibGUgICAgICAgICAgICAgPSAw ICgwKQowMDowMDowMS43NjkgUFNFLTM2IC0gMzYtYml0IFBhZ2UgU2l6ZSBFeHRlbnRpb24gICAg PSAwICgwKQowMDowMDowMS43NjkgMTggLSBSZXNlcnZlZCAgICAgICAgICAgICAgICAgICAgICAg ICAgPSAwICgwKQowMDowMDowMS43NjkgMTkgLSBSZXNlcnZlZCAgICAgICAgICAgICAgICAgICAg ICAgICAgPSAwICgwKQowMDowMDowMS43NjkgTlggLSBOby1FeGVjdXRlIFBhZ2UgUHJvdGVjdGlv biAgICAgICAgPSAwICgxKQowMDowMDowMS43NjkgRFMgLSBEZWJ1ZyBTdG9yZSAgICAgICAgICAg ICAgICAgICAgICAgPSAwICgwKQowMDowMDowMS43NjkgQVhNTVggLSBBTUQgRXh0ZW5zaW9ucyB0 byBNTVggSW5zdHIuICAgPSAwICgwKQowMDowMDowMS43NjkgTU1YIC0gSW50ZWwgTU1YIFRlY2hu b2xvZ3kgICAgICAgICAgICAgPSAwICgwKQowMDowMDowMS43NjkgRlhTUiAtIEZYU0FWRSBhbmQg RlhSU1RPUiBJbnN0cnVjdGlvbnMgPSAwICgwKQowMDowMDowMS43NjkgMjUgLSBBTUQgZmFzdCBG WFNBVkUgYW5kIEZYUlNUT1IgSW5zdHIuPSAwICgwKQowMDowMDowMS43NjkgMjYgLSAxIEdCIGxh cmdlIHBhZ2Ugc3VwcG9ydCAgICAgICAgICAgPSAwICgwKQowMDowMDowMS43NjkgMjcgLSBSRFRT Q1AgaW5zdHJ1Y3Rpb24gICAgICAgICAgICAgICAgPSAwICgwKQowMDowMDowMS43NjkgMjggLSBS ZXNlcnZlZCAgICAgICAgICAgICAgICAgICAgICAgICAgPSAwICgwKQowMDowMDowMS43NjkgMjkg LSBBTUQgTG9uZyBNb2RlICAgICAgICAgICAgICAgICAgICAgPSAwICgxKQowMDowMDowMS43Njkg MzAgLSBBTUQgRXh0ZW5zaW9ucyB0byAzRE5vdyAgICAgICAgICAgPSAwICgwKQowMDowMDowMS43 NjkgMzEgLSBBTUQgM0ROb3cgICAgICAgICAgICAgICAgICAgICAgICAgPSAwICgwKQowMDowMDow MS43NjkgTGFoZlNhaGYgLSBMQUhGL1NBSEYgaW4gNjQtYml0IG1vZGUgICAgPSAwICgxKQowMDow MDowMS43NjkgQ21wTGVnYWN5IC0gQ29yZSBNUCBsZWdhY3kgbW9kZSAoZGVwcikgPSAwICgwKQow MDowMDowMS43NjkgU1ZNIC0gQU1EIFZNIEV4dGVuc2lvbnMgICAgICAgICAgICAgICAgPSAwICgw KQowMDowMDowMS43NjkgQVBJQyByZWdpc3RlcnMgc3RhcnRpbmcgYXQgMHg0MDAgICAgICAgPSAw ICgwKQowMDowMDowMS43NjkgQWx0TW92Q1I4IC0gTE9DSyBNT1YgQ1IwIG1lYW5zIE1PViBDUjgg PSAwICgwKQowMDowMDowMS43NjkgQWR2YW5jZWQgYml0IG1hbmlwdWxhdGlvbiAgICAgICAgICAg ICAgPSAwICgwKQowMDowMDowMS43NjkgU1NFNEEgaW5zdHJ1Y3Rpb24gc3VwcG9ydCAgICAgICAg ICAgICAgPSAwICgwKQowMDowMDowMS43NjkgTWlzYWxpZ25lZCBTU0UgbW9kZSAgICAgICAgICAg ICAgICAgICAgPSAwICgwKQowMDowMDowMS43NjkgUFJFRkVUQ0ggYW5kIFBSRUZFVENIVyBpbnN0 cnVjdGlvbiAgICAgPSAwICgwKQowMDowMDowMS43NjkgT1MgdmlzaWJsZSB3b3JrYXJvdW5kICAg ICAgICAgICAgICAgICAgPSAwICgwKQowMDowMDowMS43NjkgSW5zdHJ1Y3Rpb24gYmFzZWQgc2Ft cGxpbmcgICAgICAgICAgICAgPSAwICgwKQowMDowMDowMS43NjkgU1NFNSBzdXBwb3J0ICAgICAg ICAgICAgICAgICAgICAgICAgICAgPSAwICgwKQowMDowMDowMS43NjkgU0tJTklULCBTVEdJLCBh bmQgREVWIHN1cHBvcnQgICAgICAgICAgPSAwICgwKQowMDowMDowMS43NjkgV2F0Y2hkb2cgdGlt ZXIgc3VwcG9ydC4gICAgICAgICAgICAgICAgPSAwICgwKQowMDowMDowMS43NjkgMzE6MTQgLSBS ZXNlcnZlZCAgICAgICAgICAgICAgICAgICAgICAgPSAweDAgKDB4MCkKMDA6MDA6MDEuNzY5IEZ1 bGwgTmFtZTogICAgICAgICAgICAgICAgICAgICAgIEludGVsKFIpIENvcmUoVE0pMiBDUFUgICAg ICAgICBUNzIwMCAgQCAyLjAwR0h6CjAwOjAwOjAxLjc2OSBUTEIgMi80TSBJbnN0ci9Vbmk6ICAg ICAgICAgICAgICByZXMwICAgICAwIGVudHJpZXMKMDA6MDA6MDEuNzY5IFRMQiAyLzRNIERhdGE6 ICAgICAgICAgICAgICAgICAgIHJlczAgICAgIDAgZW50cmllcwowMDowMDowMS43NjkgVExCIDRL IEluc3RyL1VuaTogICAgICAgICAgICAgICAgcmVzMCAgICAgMCBlbnRyaWVzCjAwOjAwOjAxLjc2 OSBUTEIgNEsgRGF0YTogICAgICAgICAgICAgICAgICAgICByZXMwICAgICAwIGVudHJpZXMKMDA6 MDA6MDEuNzY5IEwxIEluc3RyIENhY2hlIExpbmUgU2l6ZTogICAgICAgIDAgYnl0ZXMKMDA6MDA6 MDEuNzY5IEwxIEluc3RyIENhY2hlIExpbmVzIFBlciBUYWc6ICAgIDAKMDA6MDA6MDEuNzY5IEwx IEluc3RyIENhY2hlIEFzc29jaWF0aXZpdHk6ICAgIHJlczAgIAowMDowMDowMS43NjkgTDEgSW5z dHIgQ2FjaGUgU2l6ZTogICAgICAgICAgICAgMCBLQgowMDowMDowMS43NjkgTDEgRGF0YSBDYWNo ZSBMaW5lIFNpemU6ICAgICAgICAgMCBieXRlcwowMDowMDowMS43NjkgTDEgRGF0YSBDYWNoZSBM aW5lcyBQZXIgVGFnOiAgICAgMAowMDowMDowMS43NjkgTDEgRGF0YSBDYWNoZSBBc3NvY2lhdGl2 aXR5OiAgICAgcmVzMCAgCjAwOjAwOjAxLjc2OSBMMSBEYXRhIENhY2hlIFNpemU6ICAgICAgICAg ICAgICAwIEtCCjAwOjAwOjAxLjc2OSBMMiBUTEIgMi80TSBJbnN0ci9Vbmk6ICAgICAgICAgICBv ZmYgICAgICAgMCBlbnRyaWVzCjAwOjAwOjAxLjc2OSBMMiBUTEIgMi80TSBEYXRhOiAgICAgICAg ICAgICAgICBvZmYgICAgICAgMCBlbnRyaWVzCjAwOjAwOjAxLjc2OSBMMiBUTEIgNEsgSW5zdHIv VW5pOiAgICAgICAgICAgICBvZmYgICAgICAgMCBlbnRyaWVzCjAwOjAwOjAxLjc2OSBMMiBUTEIg NEsgRGF0YTogICAgICAgICAgICAgICAgICBvZmYgICAgICAgMCBlbnRyaWVzCjAwOjAwOjAxLjc2 OSBMMiBDYWNoZSBMaW5lIFNpemU6ICAgICAgICAgICAgICAwIGJ5dGVzCjAwOjAwOjAxLjc2OSBM MiBDYWNoZSBMaW5lcyBQZXIgVGFnOiAgICAgICAgICAwCjAwOjAwOjAxLjc2OSBMMiBDYWNoZSBB c3NvY2lhdGl2aXR5OiAgICAgICAgICBvZmYgICAKMDA6MDA6MDEuNzY5IEwyIENhY2hlIFNpemU6 ICAgICAgICAgICAgICAgICAgIDAgS0IKMDA6MDA6MDEuNzY5IEFQTSBGZWF0dXJlczogICAgICAg ICAgICAgICAgICAgCjAwOjAwOjAxLjc2OSBQaHlzaWNhbCBBZGRyZXNzIFdpZHRoOiAgICAgICAg ICAzNiBiaXRzCjAwOjAwOjAxLjc2OSBWaXJ0dWFsIEFkZHJlc3MgV2lkdGg6ICAgICAgICAgICA0 OCBiaXRzCjAwOjAwOjAxLjc2OSBQaHlzaWNhbCBDb3JlIENvdW50OiAgICAgICAgICAgICAwCjAw OjAwOjAxLjc2OSAKMDA6MDA6MDEuNzY5ICAgICAgICAgIFJBVyBDZW50YXVyIENQVUlEcwowMDow MDowMS43NjkgICAgICBGdW5jdGlvbiAgZWF4ICAgICAgZWJ4ICAgICAgZWN4ICAgICAgZWR4CjAw OjAwOjAxLjc2OSBHc3Q6IGMwMDAwMDAwICAwNzI4MDIwMiAwMDAwMDAwMCAwMDAwMDAwMCAwMDAw MDAwMAowMDowMDowMS43NjkgSHN0OiAgICAgICAgICAgMDcyODAyMDIgMDAwMDAwMDAgMDAwMDAw MDAgMDAwMDAwMDAKMDA6MDA6MDEuNzY5IEdzdDogYzAwMDAwMDEgIDA3MjgwMjAyIDAwMDAwMDAw IDAwMDAwMDAwIDAwMDAwMDAwCjAwOjAwOjAxLjc2OSBIc3Q6ICAgICAgICAgICAwNzI4MDIwMiAw MDAwMDAwMCAwMDAwMDAwMCAwMDAwMDAwMAowMDowMDowMS43NjkgR3N0OiBjMDAwMDAwMiAgMDcy ODAyMDIgMDAwMDAwMDAgMDAwMDAwMDAgMDAwMDAwMDAKMDA6MDA6MDEuNzY5IEhzdDogICAgICAg ICAgIDA3MjgwMjAyIDAwMDAwMDAwIDAwMDAwMDAwIDAwMDAwMDAwCjAwOjAwOjAxLjc2OSBHc3Q6 IGMwMDAwMDAzICAwNzI4MDIwMiAwMDAwMDAwMCAwMDAwMDAwMCAwMDAwMDAwMAowMDowMDowMS43 NjkgSHN0OiAgICAgICAgICAgMDcyODAyMDIgMDAwMDAwMDAgMDAwMDAwMDAgMDAwMDAwMDAKMDA6 MDA6MDEuNzY5IENlbnRhdXIgU3VwcG9ydHM6ICAgICAgICAgICAgICAgIDB4YzAwMDAwMDAtMHgw NzI4MDIwMgowMDowMDowMS43NjkgTW5lbW9uaWMgLSBEZXNjcmlwdGlvbiAgICAgICAgICAgICAg ICAgPSBndWVzdCAoaG9zdCkKMDA6MDA6MDEuNzY5IEFJUyAtIEFsdGVybmF0ZSBJbnN0cnVjdGlv biBTZXQgICAgICAgID0gMCAoMCkKMDA6MDA6MDEuNzY5IEFJUy1FIC0gQUlTIGVuYWJsZWQgICAg ICAgICAgICAgICAgICAgID0gMCAoMCkKMDA6MDA6MDEuNzY5IFJORyAtIFJhbmRvbSBOdW1iZXIg R2VuZXJhdG9yICAgICAgICAgID0gMCAoMCkKMDA6MDA6MDEuNzY5IFJORy1FIC0gUk5HIGVuYWJs ZWQgICAgICAgICAgICAgICAgICAgID0gMCAoMCkKMDA6MDA6MDEuNzY5IExIIC0gTG9uZ0hhdWwg TVNSIDAwMDBfMTEwQWggICAgICAgICAgID0gMCAoMCkKMDA6MDA6MDEuNzY5IEZFTU1TIC0gRkVN TVMgICAgICAgICAgICAgICAgICAgICAgICAgID0gMCAoMCkKMDA6MDA6MDEuNzY5IEFDRSAtIEFk dmFuY2VkIENyeXB0b2dyYXBoeSBFbmdpbmUgICAgID0gMCAoMCkKMDA6MDA6MDEuNzY5IEFDRS1F IC0gQUNFIGVuYWJsZWQgICAgICAgICAgICAgICAgICAgID0gMCAoMCkKMDA6MDA6MDEuNzY5IEFD RTIgLSBBZHZhbmNlZCBDcnlwdG9ncmFwaHkgRW5naW5lIDIgID0gMCAoMCkKMDA6MDA6MDEuNzY5 IEFDRTItRSAtIEFDRSBlbmFibGVkICAgICAgICAgICAgICAgICAgID0gMCAoMCkKMDA6MDA6MDEu NzY5IFBIRSAtIEhhc2ggRW5naW5lICAgICAgICAgICAgICAgICAgICAgID0gMCAoMCkKMDA6MDA6 MDEuNzY5IFBIRS1FIC0gUEhFIGVuYWJsZWQgICAgICAgICAgICAgICAgICAgID0gMCAoMCkKMDA6 MDA6MDEuNzY5IFBNTSAtIE1vbnRnb21lcnkgTXVsdGlwbGllciAgICAgICAgICAgID0gMCAoMCkK MDA6MDA6MDEuNzY5IFBNTS1FIC0gUE1NIGVuYWJsZWQgICAgICAgICAgICAgICAgICAgID0gMCAo MCkKMDA6MDA6MDEuNzY5IAowMDowMDowMS43NjkgCjAwOjAwOjAxLjc2OSAqKioqKioqKioqKioq KioqKioqKiBFbmQgb2YgQ1BVSUQgZHVtcCAqKioqKioqKioqKioqKioqKioqKioqCjAwOjAwOjAx LjgxOSBSRU06IFZCb3hSRU02NAowMDowMDowMS44NDIgVXNpbmcgNjQtYml0IGF3YXJlIFJFTQow MDowMDowMS44NzEgVE06IEdJUCAtIHUzMk1vZGU9MSAoU3luY1RTQykgdTMyVXBkYXRlSHo9MTAw CjAwOjAwOjAxLjkwMyBUTTogY1RTQ1RpY2tzUGVyU2Vjb25kPTB4Nzc1ZmQxNDggKDIgMDAyIDc2 OCAyMDApIGZUU0NWaXJ0dWFsaXplZD10cnVlICBmVFNDVXNlUmVhbFRTQz1mYWxzZQowMDowMDow MS45MDMgVE06IGZNYXliZVVzZU9mZnNldHRlZEhvc3RUU0M9dHJ1ZSAgVFNDVGllZFRvRXhlY3V0 aW9uPWZhbHNlIFRTQ05vdFRpZWRUb0hhbHQ9ZmFsc2UKMDA6MDA6MDEuOTAzIENvcmVDb2RlOiBS Mz0wMDdmOTAwMCBSMD01OGNmZDAwMCBSQz1hMDMxMDAwMCBQaHlzPTAwMDAwMDAwMDZkOGUwMDAg Y2I9MHgzMDAwCjAwOjAwOjAyLjAxMCBbU01QXSBCSU9TIHdpdGggMSBDUFVzCjAwOjAwOjAyLjA0 NCBTVVA6IExvYWRlZCBWQm94RERSMC5yMCAoL0FwcGxpY2F0aW9ucy9WaXJ0dWFsQm94LmFwcC9D b250ZW50cy9NYWNPUy9WQm94RERSMC5yMCkgYXQgMHgzNTFlMDA2MCAtIE1vZHVsZUluaXQgYXQg MDAwMDAwMDAwMDAwMDAwMCBhbmQgTW9kdWxlVGVybSBhdCAwMDAwMDAwMDAwMDAwMDAwCjAwOjAw OjAyLjA2MSBTVVA6IExvYWRlZCBWQm94REQyUjAucjAgKC9BcHBsaWNhdGlvbnMvVmlydHVhbEJv eC5hcHAvQ29udGVudHMvTWFjT1MvVkJveEREMlIwLnIwKSBhdCAweDM1MjAwMDYwIC0gTW9kdWxl SW5pdCBhdCAwMDAwMDAwMDAwMDAwMDAwIGFuZCBNb2R1bGVUZXJtIGF0IDAwMDAwMDAwMDAwMDAw MDAKMDA6MDA6MDIuMDYxIEFjdGl2YXRpbmcgTG9jYWwgQVBJQwowMDowMDowMi4wNjEgQ1BVTVNl dEd1ZXN0Q3B1SWRGZWF0dXJlOiBFbmFibGVkIEFQSUMKMDA6MDA6MDIuMDYxIENQVU1TZXRHdWVz dENwdUlkRmVhdHVyZTogRGlzYWJsZWQgeDJBUElDCjAwOjAwOjAyLjA2MSBQSVQ6IG1vZGU9MyBj b3VudD0weDEwMDAwICg2NTUzNikgLSAxOC4yMCBIeiAoY2g9MCkKMDA6MDA6MDIuMDg3IFNoYXJl ZCBGb2xkZXJzIHNlcnZpY2UgbG9hZGVkLgowMDowMDowMi4xNDYgVkRJbml0IGZpbmlzaGVkCjAw OjAwOjAyLjE0NiBQSUlYMyBBVEE6IExVTiMwOiBkaXNrLCBQQ0hTPTgzMjIvMTYvNjMsIHRvdGFs IG51bWJlciBvZiBzZWN0b3JzIDgzODg2MDgKMDA6MDA6MDIuMTQ2IFBJSVgzIEFUQTogTFVOIzE6 IG5vIHVuaXQKMDA6MDA6MDIuMTQ3IFBJSVgzIEFUQTogTFVOIzI6IENEL0RWRCwgdG90YWwgbnVt YmVyIG9mIHNlY3RvcnMgMCwgcGFzc3Rocm91Z2ggZGlzYWJsZWQKMDA6MDA6MDIuMTQ3IFBJSVgz IEFUQTogTFVOIzM6IG5vIHVuaXQKMDA6MDA6MDIuMTQ3IFBJSVgzIEFUQTogQ3RsIzA6IGZpbmlz aGVkIHByb2Nlc3NpbmcgUkVTRVQKMDA6MDA6MDIuMTQ3IFBJSVgzIEFUQTogQ3RsIzE6IGZpbmlz aGVkIHByb2Nlc3NpbmcgUkVTRVQKMDA6MDA6MDIuMTQ3IEludE5ldCMwOiBzek5ldHdvcms9e0hv c3RJbnRlcmZhY2VOZXR3b3JraW5nLWVuMDogRXRoZXJuZXR9IGVubVRydW5rVHlwZT0zIHN6VHJ1 bms9e2VuMH0gZkZsYWdzPTB4MCBjYlJlY3Y9MjIzMjMyIGNiU2VuZD0zNjg2NAowMDowMDowMi4x NDggQXVkaW86IFRyeWluZyBkcml2ZXIgJ2NvcmVhdWRpbycuCjAwOjAwOjAyLjE1MCBBdWRpbzog c2V0X3JlY29yZF9zb3VyY2UgYXJzPTAgYWxzPTAgKG5vdCBpbXBsZW1lbnRlZCkKMDA6MDA6MDIu MTk4IERldlBjQmlvczogQVRBIExVTiMwIExDSFM9MTAyNC82LzYzCjAwOjAwOjAyLjE5OCBQR01S M0luaXRGaW5hbGl6ZTogNCBNQiBQU0UgbWFzayAwMDAwMDAwZmZmZmZmZmZmCjAwOjAwOjAyLjIx MSBIV0FDQ006IEhvc3QgQ1I0PTAwMDAwNjYwCjAwOjAwOjAyLjIxMSBIV0FDQ006IE1TUl9JQTMy X0ZFQVRVUkVfQ09OVFJPTCAgICAgID0gNQowMDowMDowMi4yMTEgSFdBQ0NNOiBNU1JfSUEzMl9W TVhfQkFTSUNfSU5GTyAgICAgICA9IDFhMDQwMDAwMDAwMDA3CjAwOjAwOjAyLjIxMSBIV0FDQ006 IFZNQ1MgaWQgICAgICAgICAgICAgICAgICAgICAgID0gNwowMDowMDowMi4yMTEgSFdBQ0NNOiBW TUNTIHNpemUgICAgICAgICAgICAgICAgICAgICA9IDQwMAowMDowMDowMi4yMTEgSFdBQ0NNOiBW TUNTIHBoeXNpY2FsIGFkZHJlc3MgbGltaXQgICA9IE5vbmUKMDA6MDA6MDIuMjExIEhXQUNDTTog Vk1DUyBtZW1vcnkgdHlwZSAgICAgICAgICAgICAgPSA2CjAwOjAwOjAyLjIxMSBIV0FDQ006IER1 YWwgbW9uaXRvciB0cmVhdG1lbnQgICAgICAgID0gMQowMDowMDowMi4yMTEgSFdBQ0NNOiBNU1Jf SUEzMl9WTVhfUElOQkFTRURfQ1RMUyAgICA9IDFmMDAwMDAwMTYKMDA6MDA6MDIuMjExIEhXQUND TTogICAgVk1YX1ZNQ1NfQ1RSTF9QSU5fRVhFQ19DT05UUk9MU19FWFRfSU5UX0VYSVQKMDA6MDA6 MDIuMjExIEhXQUNDTTogICAgVk1YX1ZNQ1NfQ1RSTF9QSU5fRVhFQ19DT05UUk9MU19OTUlfRVhJ VAowMDowMDowMi4yMTEgSFdBQ0NNOiBNU1JfSUEzMl9WTVhfUFJPQ0JBU0VEX0NUTFMgICA9IDc3 YjlmZmZlMDQwMWUxNzIKMDA6MDA6MDIuMjExIEhXQUNDTTogICAgVk1YX1ZNQ1NfQ1RSTF9QUk9D X0VYRUNfQ09OVFJPTFNfSVJRX1dJTkRPV19FWElUCjAwOjAwOjAyLjIxMSBIV0FDQ006ICAgIFZN WF9WTUNTX0NUUkxfUFJPQ19FWEVDX0NPTlRST0xTX1RTQ19PRkZTRVQKMDA6MDA6MDIuMjExIEhX QUNDTTogICAgVk1YX1ZNQ1NfQ1RSTF9QUk9DX0VYRUNfQ09OVFJPTFNfSExUX0VYSVQKMDA6MDA6 MDIuMjExIEhXQUNDTTogICAgVk1YX1ZNQ1NfQ1RSTF9QUk9DX0VYRUNfQ09OVFJPTFNfSU5WTFBH X0VYSVQKMDA6MDA6MDIuMjExIEhXQUNDTTogICAgVk1YX1ZNQ1NfQ1RSTF9QUk9DX0VYRUNfQ09O VFJPTFNfTVdBSVRfRVhJVAowMDowMDowMi4yMTEgSFdBQ0NNOiAgICBWTVhfVk1DU19DVFJMX1BS T0NfRVhFQ19DT05UUk9MU19SRFBNQ19FWElUCjAwOjAwOjAyLjIxMSBIV0FDQ006ICAgIFZNWF9W TUNTX0NUUkxfUFJPQ19FWEVDX0NPTlRST0xTX1JEVFNDX0VYSVQKMDA6MDA6MDIuMjExIEhXQUND TTogICAgVk1YX1ZNQ1NfQ1RSTF9QUk9DX0VYRUNfQ09OVFJPTFNfQ1IzX0xPQURfRVhJVAowMDow MDowMi4yMTEgSFdBQ0NNOiAgICBWTVhfVk1DU19DVFJMX1BST0NfRVhFQ19DT05UUk9MU19DUjNf U1RPUkVfRVhJVAowMDowMDowMi4yMTEgSFdBQ0NNOiAgICBWTVhfVk1DU19DVFJMX1BST0NfRVhF Q19DT05UUk9MU19DUjhfTE9BRF9FWElUCjAwOjAwOjAyLjIxMSBIV0FDQ006ICAgIFZNWF9WTUNT X0NUUkxfUFJPQ19FWEVDX0NPTlRST0xTX0NSOF9TVE9SRV9FWElUCjAwOjAwOjAyLjIxMSBIV0FD Q006ICAgIFZNWF9WTUNTX0NUUkxfUFJPQ19FWEVDX0NPTlRST0xTX1VTRV9UUFJfU0hBRE9XCjAw OjAwOjAyLjIxMSBIV0FDQ006ICAgIFZNWF9WTUNTX0NUUkxfUFJPQ19FWEVDX0NPTlRST0xTX01P Vl9EUl9FWElUCjAwOjAwOjAyLjIxMSBIV0FDQ006ICAgIFZNWF9WTUNTX0NUUkxfUFJPQ19FWEVD X0NPTlRST0xTX1VOQ09ORF9JT19FWElUCjAwOjAwOjAyLjIxMiBIV0FDQ006ICAgIFZNWF9WTUNT X0NUUkxfUFJPQ19FWEVDX0NPTlRST0xTX1VTRV9JT19CSVRNQVBTCjAwOjAwOjAyLjIxMiBIV0FD Q006ICAgIFZNWF9WTUNTX0NUUkxfUFJPQ19FWEVDX0NPTlRST0xTX1VTRV9NU1JfQklUTUFQUwow MDowMDowMi4yMTIgSFdBQ0NNOiAgICBWTVhfVk1DU19DVFJMX1BST0NfRVhFQ19DT05UUk9MU19N T05JVE9SX0VYSVQKMDA6MDA6MDIuMjEyIEhXQUNDTTogICAgVk1YX1ZNQ1NfQ1RSTF9QUk9DX0VY RUNfQ09OVFJPTFNfUEFVU0VfRVhJVAowMDowMDowMi4yMTIgSFdBQ0NNOiAgICBWTVhfVk1DU19D VFJMX1BST0NfRVhFQ19DT05UUk9MU19DUjNfTE9BRF9FWElUICptdXN0KiBiZSBzZXQKMDA6MDA6 MDIuMjEyIEhXQUNDTTogICAgVk1YX1ZNQ1NfQ1RSTF9QUk9DX0VYRUNfQ09OVFJPTFNfQ1IzX1NU T1JFX0VYSVQgKm11c3QqIGJlIHNldAowMDowMDowMi4yMTIgSFdBQ0NNOiBNU1JfSUEzMl9WTVhf RU5UUllfQ1RMUyAgICAgICA9IDFmZmYwMDAwMTFmZgowMDowMDowMi4yMTIgSFdBQ0NNOiAgICBW TVhfVk1DU19DVFJMX0VOVFJZX0NPTlRST0xTX0xPQURfREVCVUcKMDA6MDA6MDIuMjEyIEhXQUND TTogICAgVk1YX1ZNQ1NfQ1RSTF9FTlRSWV9DT05UUk9MU19JQTY0X01PREUKMDA6MDA6MDIuMjEy IEhXQUNDTTogICAgVk1YX1ZNQ1NfQ1RSTF9FTlRSWV9DT05UUk9MU19FTlRSWV9TTU0KMDA6MDA6 MDIuMjEyIEhXQUNDTTogICAgVk1YX1ZNQ1NfQ1RSTF9FTlRSWV9DT05UUk9MU19ERUFDVElWQVRF X0RVQUxNT04KMDA6MDA6MDIuMjEyIEhXQUNDTTogICAgVk1YX1ZNQ1NfQ1RSTF9FTlRSWV9DT05U Uk9MU19MT0FEX0RFQlVHICptdXN0KiBiZSBzZXQKMDA6MDA6MDIuMjEyIEhXQUNDTTogTVNSX0lB MzJfVk1YX0VYSVRfQ1RMUyAgICAgICAgPSAzZWZmZjAwMDM2ZGZmCjAwOjAwOjAyLjIxMiBIV0FD Q006ICAgIFZNWF9WTUNTX0NUUkxfRVhJVF9DT05UUk9MU19TQVZFX0RFQlVHCjAwOjAwOjAyLjIx MiBIV0FDQ006ICAgIFZNWF9WTUNTX0NUUkxfRVhJVF9DT05UUk9MU19IT1NUX0FNRDY0CjAwOjAw OjAyLjIxMiBIV0FDQ006ICAgIFZNWF9WTUNTX0NUUkxfRVhJVF9DT05UUk9MU19BQ0tfRVhURVJO QUxfSVJRCjAwOjAwOjAyLjIxMiBIV0FDQ006ICAgIFZNWF9WTUNTX0NUUkxfRVhJVF9DT05UUk9M U19TQVZFX0RFQlVHICptdXN0KiBiZSBzZXQKMDA6MDA6MDIuMjEyIEhXQUNDTTogTVNSX0lBMzJf Vk1YX01JU0MgICAgICAgICAgICAgPSA0MDNjMAowMDowMDowMi4yMTIgSFdBQ0NNOiAgICBNU1Jf SUEzMl9WTVhfTUlTQ19QUkVFTVBUX1RTQ19CSVQgMAowMDowMDowMi4yMTIgSFdBQ0NNOiAgICBN U1JfSUEzMl9WTVhfTUlTQ19BQ1RJVklUWV9TVEFURVMgNwowMDowMDowMi4yMTIgSFdBQ0NNOiAg ICBNU1JfSUEzMl9WTVhfTUlTQ19DUjNfVEFSR0VUICAgICAgNAowMDowMDowMi4yMTIgSFdBQ0NN OiAgICBNU1JfSUEzMl9WTVhfTUlTQ19NQVhfTVNSICAgICAgICAgMjAwCjAwOjAwOjAyLjIxMiBI V0FDQ006ICAgIE1TUl9JQTMyX1ZNWF9NSVNDX01TRUdfSUQgICAgICAgICAwCjAwOjAwOjAyLjIx MiBIV0FDQ006IE1TUl9JQTMyX1ZNWF9DUjBfRklYRUQwICAgICAgID0gODAwMDAwMjEKMDA6MDA6 MDIuMjEyIEhXQUNDTTogTVNSX0lBMzJfVk1YX0NSMF9GSVhFRDEgICAgICAgPSBmZmZmZmZmZgow MDowMDowMi4yMTIgSFdBQ0NNOiBNU1JfSUEzMl9WTVhfQ1I0X0ZJWEVEMCAgICAgICA9IDIwMDAK MDA6MDA6MDIuMjEyIEhXQUNDTTogTVNSX0lBMzJfVk1YX0NSNF9GSVhFRDEgICAgICAgPSAyN2Zm CjAwOjAwOjAyLjIxMiBIV0FDQ006IE1TUl9JQTMyX1ZNWF9WTUNTX0VOVU0gICAgICAgID0gMmMK MDA6MDA6MDIuMjEyIEhXQUNDTTogVFBSIHNoYWRvdyBwaHlzYWRkciAgICAgICAgICAgPSAwMDAw MDAwMDA2ZDkxMDAwCjAwOjAwOjAyLjIxMiBIV0FDQ006IFZDUFUwOiBNU1IgYml0bWFwIHBoeXNh ZGRyICAgICAgPSAwMDAwMDAwMDA2ZDk0MDAwCjAwOjAwOjAyLjIxMiBIV0FDQ006IFZDUFUwOiBW TUNTIHBoeXNhZGRyICAgICAgICAgICAgPSAwMDAwMDAwMDA2ZDkyMDAwCjAwOjAwOjAyLjIxMiBI V0FDQ006IFJlYWwgTW9kZSBUU1MgZ3Vlc3QgcGh5c2FkZHIgID0gMDAwMDAwMDBmMDgwMDAwMAow MDowMDowMi4yMTIgSFdBQ0NNOiBOb24tUGFnaW5nIE1vZGUgRVBUIENSMyAgICAgICA9IDAwMDAw MDAwZjA4MDMwMDAKMDA6MDA6MDIuMjEyIENQVU1TZXRHdWVzdENwdUlkRmVhdHVyZTogRW5hYmxl ZCBzeXNlbnRlci9leGl0CjAwOjAwOjAyLjIxMiBDUFVNU2V0R3Vlc3RDcHVJZEZlYXR1cmU6IEVu YWJsZWQgUEFFCjAwOjAwOjAyLjIxMiBDUFVNU2V0R3Vlc3RDcHVJZEZlYXR1cmU6IEVuYWJsZWQg TE9ORyBNT0RFCjAwOjAwOjAyLjIxMiBDUFVNU2V0R3Vlc3RDcHVJZEZlYXR1cmU6IEVuYWJsZWQg c3lzY2FsbC9yZXQKMDA6MDA6MDIuMjEyIENQVU1TZXRHdWVzdENwdUlkRmVhdHVyZTogRW5hYmxl ZCBMQUhGL1NBSEYKMDA6MDA6MDIuMjEyIENQVU1TZXRHdWVzdENwdUlkRmVhdHVyZTogRW5hYmxl ZCBOWEUKMDA6MDA6MDIuMjEyIEhXQUNDTTogMzItYml0IGFuZCA2NC1iaXQgZ3Vlc3RzIHN1cHBv cnRlZC4KMDA6MDA6MDIuMjEyIEhXQUNDTTogVk1YIGVuYWJsZWQhCjAwOjAwOjAyLjIxMiBIV0FD Q006ICAgIFZULXgvQU1ELVYgaW5pdCBtZXRob2Q6IExPQ0FMCjAwOjAwOjAyLjIyMyBWTTogSGFs dCBtZXRob2QgZ2xvYmFsMSAoNSkKMDA6MDA6MDIuMjIzIENoYW5naW5nIHRoZSBWTSBzdGF0ZSBm cm9tICdDUkVBVElORycgdG8gJ0NSRUFURUQnLgowMDowMDowMi4yMjQgQ2hhbmdpbmcgdGhlIFZN IHN0YXRlIGZyb20gJ0NSRUFURUQnIHRvICdSVU5OSU5HJy4KMDA6MDA6MDIuMjMwIEd1ZXN0IExv ZzogQklPUzogVmlydHVhbEJveCAzLjAuMTAKMDA6MDA6MDIuMjMwIFBJVDogbW9kZT0yIGNvdW50 PTB4MTAwMDAgKDY1NTM2KSAtIDE4LjIwIEh6IChjaD0wKQowMDowMDowMi40MTQgUElJWDMgQVRB OiBDdGwjMDogUkVTRVQsIERldlNlbD0wIEFJT0lmPTAgQ21kSWYwPTB4MDAgKC0xIHVzZWMgYWdv KSBDbWRJZjE9MHgwMCAoLTEgdXNlYyBhZ28pCjAwOjAwOjAyLjQxNCBQSUlYMyBBVEE6IEN0bCMw OiBmaW5pc2hlZCBwcm9jZXNzaW5nIFJFU0VUCjAwOjAwOjAyLjQxOSBHdWVzdCBMb2c6IEJJT1M6 IGF0YTAtMDogUENIUz04MzIyLzE2LzYzIExDSFM9MTAyNC82LzYzCjAwOjAwOjAyLjQxOSBQSUlY MyBBVEE6IEN0bCMxOiBSRVNFVCwgRGV2U2VsPTAgQUlPSWY9MCBDbWRJZjA9MHgwMCAoLTEgdXNl YyBhZ28pIENtZElmMT0weDAwICgtMSB1c2VjIGFnbykKMDA6MDA6MDIuNDE5IFBJSVgzIEFUQTog Q3RsIzE6IGZpbmlzaGVkIHByb2Nlc3NpbmcgUkVTRVQKMDA6MDA6MDIuNDIwIFBJVDogbW9kZT0y IGNvdW50PTB4NDhkMyAoMTg2NDMpIC0gNjQuMDAgSHogKGNoPTApCjAwOjAwOjAyLjQzOSBEaXNw bGF5OjpoYW5kbGVEaXNwbGF5UmVzaXplKCk6IHVTY3JlZW5JZCA9IDAsIHB2VlJBTT0xYTk1MzAw MCB3PTY0MCBoPTQ4MCBicHA9MzIgY2JMaW5lPTB4QTAwCjAwOjAwOjA0LjkxOSBEaXNwbGF5Ojpo YW5kbGVEaXNwbGF5UmVzaXplKCk6IHVTY3JlZW5JZCA9IDAsIHB2VlJBTT0wMDAwMDAwMCB3PTcy MCBoPTQwMCBicHA9MCBjYkxpbmU9MHgwCjAwOjAwOjA0Ljk0MCBQSVQ6IG1vZGU9MiBjb3VudD0w eDEwMDAwICg2NTUzNikgLSAxOC4yMCBIeiAoY2g9MCkKMDA6MDA6MDQuOTQyIEd1ZXN0IExvZzog QklPUzogQm9vdCBmcm9tIEZsb3BweSAwIGZhaWxlZAowMDowMDowNC45NDQgR3Vlc3QgTG9nOiBC SU9TOiBDRFJPTSBib290IGZhaWx1cmUgY29kZSA6IDAwMDMKMDA6MDA6MDQuOTQ1IEd1ZXN0IExv ZzogQklPUzogQm9vdCBmcm9tIENELVJPTSBmYWlsZWQKMDA6MDA6MDQuOTg2IEd1ZXN0IExvZzog QklPUzogQm9vdGluZyBmcm9tIEhhcmQgRGlzay4uLgowMDowMDoxOC43MTcgR3Vlc3QgTG9nOiBC SU9TOiBpbnQxM19kaXNrZXR0ZTogdW5zdXBwb3J0ZWQgQUg9NDEKMDA6MDA6NTkuMzM1IENoYW5n aW5nIHRoZSBWTSBzdGF0ZSBmcm9tICdSVU5OSU5HJyB0byAnU1VTUEVOREVEJy4KMDA6MDE6MDQu MDQ3IENoYW5naW5nIHRoZSBWTSBzdGF0ZSBmcm9tICdTVVNQRU5ERUQnIHRvICdSVU5OSU5HJy4K MDA6MDE6MTEuNTk5IENoYW5naW5nIHRoZSBWTSBzdGF0ZSBmcm9tICdSVU5OSU5HJyB0byAnU1VT UEVOREVEJy4KMDA6MDE6MTMuMzc5IENvbnNvbGU6OnBvd2VyRG93bigpOiBBIHJlcXVlc3QgdG8g cG93ZXIgb2ZmIHRoZSBWTSBoYXMgYmVlbiBpc3N1ZWQgKG1NYWNoaW5lU3RhdGU9OCwgSW5Vbmlu aXQ9MCkKMDA6MDE6MTMuNDAwICoqKioqKioqKioqKioqKioqKiBHdWVzdCBzdGF0ZSBhdCBwb3dl ciBvZmYgKioqKioqKioqKioqKioqKioqCjAwOjAxOjEzLjQwMCBHdWVzdCBDUFVNIChWQ1BVIDAp IHN0YXRlOiBzZQowMDowMToxMy40MDAgcmF4PWZmZmZmZmZmODAxOGEzNzAgcmJ4PTAwMDAwMDAw MDAwMDAwMDAgcmN4PTAwMDAwMDAwYzAwMDAwODAgcmR4PTAwMDAwMDAwMDAwMDAwMDAKMDA6MDE6 MTMuNDAwIHJzaT0wMDAwMDAwMDAwMDAwMDA0IHJkaT0wMDAwMDAwMDAwMDAwMDAxIHI4ID0wMDAw MDAwMDAwMDAwMDAwIHI5ID0wMDAwMDAwMDAwMDAwMDAwCjAwOjAxOjEzLjQwMCByMTA9MDAwMDAw MDAwMDAwMDAwMCByMTE9MDAwMDAwMDAwMDAwMDAwMCByMTI9MDAwMDAwMDAwMDAwMDAwMCByMTM9 MDAwMDAwMDAwMDAwMDAwMAowMDowMToxMy40MDAgcjE0PTAwMDAwMDAwMDAwMDAwMDAgcjE1PTAw MDAwMDAwMDAwMDAwMDAKMDA6MDE6MTMuNDAwIHJpcD0wMDAwMDAwMDAwMDA5MTk4IHJzcD0wMDAw MDAwMDAwMDNmMDEwIHJicD0wMDAwMDAwMDAwMDk0OWM4IGlvcGw9MCAgICAgIHJmIG92IHVwIGRp IHBsIHpyIGFjIHBlIG5jCjAwOjAxOjEzLjQwMCBjcz17MDAwOCBiYXNlPTAwMDAwMDAwMDAwMDAw MDAgbGltaXQ9MDAwMDAwMDAgZmxhZ3M9MDAwMDIwOTl9CjAwOjAxOjEzLjQwMCBkcz17MDAxMCBi YXNlPTAwMDAwMDAwMDAwMDAwMDAgbGltaXQ9ZmZmZmZmZmYgZmxhZ3M9MDAwMGMwOTN9CjAwOjAx OjEzLjQwMCBlcz17MDAxMCBiYXNlPTAwMDAwMDAwMDAwMDAwMDAgbGltaXQ9ZmZmZmZmZmYgZmxh Z3M9MDAwMGMwOTN9CjAwOjAxOjEzLjQwMCBmcz17MDAxMCBiYXNlPTAwMDAwMDAwMDAwMDAwMDAg bGltaXQ9ZmZmZmZmZmYgZmxhZ3M9MDAwMGMwOTN9CjAwOjAxOjEzLjQwMCBncz17MDAxMCBiYXNl PTAwMDAwMDAwMDAwMDAwMDAgbGltaXQ9ZmZmZmZmZmYgZmxhZ3M9MDAwMGMwOTN9CjAwOjAxOjEz LjQwMCBzcz17MDAxMCBiYXNlPTAwMDAwMDAwMDAwMDAwMDAgbGltaXQ9ZmZmZmZmZmYgZmxhZ3M9 MDAwMGMwOTN9CjAwOjAxOjEzLjQwMCBjcjA9MDAwMDAwMDBlMDAwMDAxMSBjcjI9MDAwMDAwMDAw MDAwMDAwMCBjcjM9MDAwMDAwMDAwMDAzYzAwMCBjcjQ9MDAwMDAwMDAwMDAwMDAzMAowMDowMTox My40MDAgZHIwPTAwMDAwMDAwMDAwMDAwMDAgZHIxPTAwMDAwMDAwMDAwMDAwMDAgZHIyPTAwMDAw MDAwMDAwMDAwMDAgZHIzPTAwMDAwMDAwMDAwMDAwMDAKMDA6MDE6MTMuNDAwIGRyND0wMDAwMDAw MDAwMDAwMDAwIGRyNT0wMDAwMDAwMDAwMDAwMDAwIGRyNj0wMDAwMDAwMGZmZmYwZmYwIGRyNz0w MDAwMDAwMDAwMDAwNDAwCjAwOjAxOjEzLjQwMCBnZHRyPTAwMDAwMDAwMDAwM2YwMGE6MDAxOCAg aWR0cj0wMDAwMDAwMDAwMDA1ZTAwOjAxOTcgIGVmbGFncz0wMDIxMDgxMgowMDowMToxMy40MDAg bGR0cj17MDAwMCBiYXNlPTAwMDAwMDAwIGxpbWl0PTAwMDAwMDAwIGZsYWdzPTAwMDAwMDgyfQow MDowMToxMy40MDAgdHIgID17MDAzOCBiYXNlPTAwMDA1Zjk4IGxpbWl0PTAwMDAyMDY3IGZsYWdz PTAwMDAwMDhifQowMDowMToxMy40MDAgU3lzRW50ZXI9e2NzPTAwMDAgZWlwPTAwMDAwMDAwMDAw MDAwMDAgZXNwPTAwMDAwMDAwMDAwMDAwMDB9CjAwOjAxOjEzLjQwMCBGUFU6CjAwOjAxOjEzLjQw MSBGQ1c9MDM3ZiBGU1c9MDAwMCBGVFc9MDAKMDA6MDE6MTMuNDAxIHJlczE9MDAgRk9QPTAwMDAg RlBVSVA9MDAwMDAwMDAgQ1M9MDAwMCBSc3ZyZDE9MDAwMAowMDowMToxMy40MDEgRlBVRFA9MDAw MCBEUz0wMDAwIFJzdnJkMj0wMDAwIE1YQ1NSPTAwMDAxZjgwIE1YQ1NSX01BU0s9MDAwMDAwMDAK MDA6MDE6MTMuNDAxIE1TUjoKMDA6MDE6MTMuNDAxIEVGRVIgICAgICAgICA9MDAwMDAwMDAwMDAw MDUwMAowMDowMToxMy40MDEgUEFUICAgICAgICAgID0wMDA3MDQwNjAwMDcwNDA2CjAwOjAxOjEz LjQwMSBTVEFSICAgICAgICAgPTAwMDAwMDAwMDAwMDAwMDAKMDA6MDE6MTMuNDAxIENTVEFSICAg ICAgICA9MDAwMDAwMDAwMDAwMDAwMAowMDowMToxMy40MDEgTFNUQVIgICAgICAgID0wMDAwMDAw MDAwMDAwMDAwCjAwOjAxOjEzLjQwMSBTRk1BU0sgICAgICAgPTAwMDAwMDAwMDAwMDAwMDAKMDA6 MDE6MTMuNDAxIEtFUk5FTEdTQkFTRSA9MDAwMDAwMDAwMDAwMDAwMAowMDowMToxMy40MDEgKioq CjAwOjAxOjEzLjQwMSBHdWVzdCBwYWdpbmcgbW9kZTogIEFNRDY0LCBjaGFuZ2VkIDQxODg3IHRp bWVzLCBBMjAgZW5hYmxlZAowMDowMToxMy40MDEgU2hhZG93IHBhZ2luZyBtb2RlOiBBTUQ2NAow MDowMToxMy40MDEgSG9zdCBwYWdpbmcgbW9kZTogICBBTUQ2NCtHK05YCjAwOjAxOjEzLjQwMSAq KioKMDA6MDE6MTMuNDAxIEFjdGl2ZSBUaW1lcnMgKHBWTT0xOGNmZDAwMCkKMDA6MDE6MTMuNDAx IHBUaW1lclIzIG9mZk5leHQgIG9mZlByZXYgIG9mZlNjaGVkIENsb2NrIFRpbWUgICAgICAgICAg ICAgICBFeHBpcmUgICAgICAgICAgICAgU3RhdGUgICAgICAgICAgICAgICAgICAgICBEZXNjcmlw dGlvbgowMDowMToxMy40MDEgMThkNDA0NDAgMDAwMGEwYTAgMDAwMDAwMDAgMDAwMDAwMDAgUmVh bCAgMDAwMDAwMDAwMDAxNjc5NTQyIDAwMDAwMDAwMDAwMTY3NzczNiAyLUFDVElWRSAgICAgICAg ICAgICAgICAgIFZHQSBSZWZyZXNoIFRpbWVyCjAwOjAxOjEzLjQwMSAxOGQ0YTRlMCAwMDAwMDAw MCBmZmZmNWY2MCAwMDAwMDAwMCBSZWFsICAwMDAwMDAwMDAwMDE2Nzk1NDIgMDAwMDAwMDAwMDAx Njc3NzQ3IDItQUNUSVZFICAgICAgICAgICAgICAgICAgRU1UIFlpZWxkZXIKMDA6MDE6MTMuNDAx IDE4ZDQ2NzMwIDAwMDAwMDAwIDAwMDAwMDAwIDAwMDAwMDAwIFZpcnQgIDAwMDAwMDA2NDY2NTcx Njg0NiAwMDAwMDAwNjQ2NjM3MTMzNjcgMi1BQ1RJVkUgICAgICAgICAgICAgICAgICBBdWRpbyB0 aW1lcgowMDowMToxMy40MDEgMThkMzU5YTAgMDAwMDAzYTAgMDAwMDAwMDAgMDAwMDAwMDAgVnJT eSAgMDAwMDAwMDY0NjE2MDE2MTgwIDAwMDAwMDA2NDY3MDk0MTU4MiAyLUFDVElWRSAgICAgICAg ICAgICAgICAgIGk4MjU0IFByb2dyYW1tYWJsZSBJbnRlcnZhbCBUaW1lcgowMDowMToxMy40MDEg MThkMzVkNDAgMDAwMTNjOTAgZmZmZmZjNjAgMDAwMDAwMDAgVnJTeSAgMDAwMDAwMDY0NjE2MDE2 MTgwIDAwMDAwMDA2NDk5MDAwMDAwMCAyLUFDVElWRSAgICAgICAgICAgICAgICAgIE1DMTQ2ODE4 IFJUQy9DTU9TIC0gU2Vjb25kCjAwOjAxOjEzLjQwMSAxOGQ0OTlkMCAwMDAwMDAwMCBmZmZlYzM3 MCAwMDAwMDAwMCBWclN5ICAwMDAwMDAwNjQ2MTYwMTYxODAgMDAwMDAxMTk5ODY0MDMxNjAxIDIt QUNUSVZFICAgICAgICAgICAgICAgICAgQUNQSSBUaW1lcgowMDowMToxMy40MDEgKioqCjAwOjAx OjEzLjQwMSBTaGFkb3cgR0RUIChHQ0FkZHI9ZmY3MTkwMDApOgowMDowMToxMy40MDEgZmZkOCAt IDk3MzgwMDg3IGZmMDA4OTQwIC0gYmFzZT1mZjQwOTczOCBsaW1pdD0wMDAwMDA4NyBkcGw9MCBU U1MzMkF2YWlsIFByZXNlbnQgMTYtYml0ICBIeXBlclRTU1RyYXAwOAowMDowMToxMy40MDEgZmZl MCAtIDk2YjAwMDg3IGZmMDA4OTQwIC0gYmFzZT1mZjQwOTZiMCBsaW1pdD0wMDAwMDA4NyBkcGw9 MCBUU1MzMkF2YWlsIFByZXNlbnQgMTYtYml0ICBIeXBlclRTUwowMDowMToxMy40MDEgZmZlOCAt IDAwMDBmZmZmIDAwYWY5YjAwIC0gYmFzZT0wMDAwMDAwMCBsaW1pdD1mZmZmZmZmZiBkcGw9MCBD b2RlRVIgQWNjZXNzZWQgUHJlc2VudCBQYWdlIDE2LWJpdCAgSHlwZXJDUzY0CjAwOjAxOjEzLjQw MSBmZmYwIC0gMDAwMGZmZmYgMDBjZjkzMDAgLSBiYXNlPTAwMDAwMDAwIGxpbWl0PWZmZmZmZmZm IGRwbD0wIERhdGFSVyBBY2Nlc3NlZCBQcmVzZW50IFBhZ2UgMzItYml0ICBIeXBlckRTCjAwOjAx OjEzLjQwMSBmZmY4IC0gMDAwMGZmZmYgMDBjZjliMDAgLSBiYXNlPTAwMDAwMDAwIGxpbWl0PWZm ZmZmZmZmIGRwbD0wIENvZGVFUiBBY2Nlc3NlZCBQcmVzZW50IFBhZ2UgMzItYml0ICBIeXBlckNT CjAwOjAxOjEzLjQwMSAqKioKMDA6MDE6MTMuNDAxICoqKioqKioqKioqKioqIEVuZCBvZiBHdWVz dCBzdGF0ZSBhdCBwb3dlciBvZmYgKioqKioqKioqKioqKioqCjAwOjAxOjEzLjQwMSBDaGFuZ2lu ZyB0aGUgVk0gc3RhdGUgZnJvbSAnU1VTUEVOREVEJyB0byAnT0ZGJy4KMDA6MDE6MTMuNDAyIENo YW5naW5nIHRoZSBWTSBzdGF0ZSBmcm9tICdPRkYnIHRvICdERVNUUk9ZSU5HJy4KMDA6MDE6MTMu NDAyICoqKioqKioqKioqKioqKioqKioqKioqKiogU3RhdGlzdGljcyAqKioqKioqKioqKioqKioq KioqKioqKioqCjAwOjAxOjEzLjQwMiAvRGV2aWNlcy9BVEEwL1VuaXQwL0F0YXBpRE1BICAgICAg ICAgICAgMCB0aW1lcwowMDowMToxMy40MDIgL0RldmljZXMvQVRBMC9Vbml0MC9BdGFwaVBJTyAg ICAgICAgICAgIDAgdGltZXMKMDA6MDE6MTMuNDAzIC9EZXZpY2VzL0FUQTAvVW5pdDAvRE1BICAg ICAgICAgICAgICAgICAwIHRpbWVzCjAwOjAxOjEzLjQwMyAvRGV2aWNlcy9BVEEwL1VuaXQwL1BJ TyAgICAgICAgICAgICAgMTAwNiB0aW1lcwowMDowMToxMy40MDMgL0RldmljZXMvQVRBMC9Vbml0 MC9SZWFkQnl0ZXMgICAgIDQ1ODQ0NDggYnl0ZXMKMDA6MDE6MTMuNDAzIC9EZXZpY2VzL0FUQTAv VW5pdDAvV3JpdHRlbkJ5dGVzICAgICAgICAwIGJ5dGVzCjAwOjAxOjEzLjQwMyAvRGV2aWNlcy9B VEEwL1VuaXQxL0F0YXBpRE1BICAgICAgICAgICAgMCB0aW1lcwowMDowMToxMy40MDMgL0Rldmlj ZXMvQVRBMC9Vbml0MS9BdGFwaVBJTyAgICAgICAgICAgIDAgdGltZXMKMDA6MDE6MTMuNDAzIC9E ZXZpY2VzL0FUQTAvVW5pdDEvRE1BICAgICAgICAgICAgICAgICAwIHRpbWVzCjAwOjAxOjEzLjQw MyAvRGV2aWNlcy9BVEEwL1VuaXQxL1BJTyAgICAgICAgICAgICAgICAgMCB0aW1lcwowMDowMTox My40MDMgL0RldmljZXMvQVRBMC9Vbml0MS9SZWFkQnl0ZXMgICAgICAgICAgIDAgYnl0ZXMKMDA6 MDE6MTMuNDAzIC9EZXZpY2VzL0FUQTAvVW5pdDEvV3JpdHRlbkJ5dGVzICAgICAgICAwIGJ5dGVz CjAwOjAxOjEzLjQwMyAvRGV2aWNlcy9BVEExL1VuaXQwL0F0YXBpRE1BICAgICAgICAgICAgMCB0 aW1lcwowMDowMToxMy40MDMgL0RldmljZXMvQVRBMS9Vbml0MC9BdGFwaVBJTyAgICAgICAgICAg IDAgdGltZXMKMDA6MDE6MTMuNDAzIC9EZXZpY2VzL0FUQTEvVW5pdDAvRE1BICAgICAgICAgICAg ICAgICAwIHRpbWVzCjAwOjAxOjEzLjQwMyAvRGV2aWNlcy9BVEExL1VuaXQwL1BJTyAgICAgICAg ICAgICAgICAgMCB0aW1lcwowMDowMToxMy40MDMgL0RldmljZXMvQVRBMS9Vbml0MC9SZWFkQnl0 ZXMgICAgICAgICAgIDAgYnl0ZXMKMDA6MDE6MTMuNDAzIC9EZXZpY2VzL0FUQTEvVW5pdDAvV3Jp dHRlbkJ5dGVzICAgICAgICAwIGJ5dGVzCjAwOjAxOjEzLjQwMyAvRGV2aWNlcy9BVEExL1VuaXQx L0F0YXBpRE1BICAgICAgICAgICAgMCB0aW1lcwowMDowMToxMy40MDMgL0RldmljZXMvQVRBMS9V bml0MS9BdGFwaVBJTyAgICAgICAgICAgIDAgdGltZXMKMDA6MDE6MTMuNDAzIC9EZXZpY2VzL0FU QTEvVW5pdDEvRE1BICAgICAgICAgICAgICAgICAwIHRpbWVzCjAwOjAxOjEzLjQwMyAvRGV2aWNl cy9BVEExL1VuaXQxL1BJTyAgICAgICAgICAgICAgICAgMCB0aW1lcwowMDowMToxMy40MDMgL0Rl dmljZXMvQVRBMS9Vbml0MS9SZWFkQnl0ZXMgICAgICAgICAgIDAgYnl0ZXMKMDA6MDE6MTMuNDAz IC9EZXZpY2VzL0FUQTEvVW5pdDEvV3JpdHRlbkJ5dGVzICAgICAgICAwIGJ5dGVzCjAwOjAxOjEz LjQwMyAvRGV2aWNlcy9FMWswL1JlY2VpdmVCeXRlcyAgICAgICAgICAgICAgMCBieXRlcwowMDow MToxMy40MDMgL0RldmljZXMvRTFrMC9UcmFuc21pdEJ5dGVzICAgICAgICAgICAgIDAgYnl0ZXMK MDA6MDE6MTMuNDAzIC9HVk1NL0VNVHMgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAxIGNh bGxzCjAwOjAxOjEzLjQwMyAvR1ZNTS9TdW0vSGFsdEJsb2NraW5nICAgICAgICAgICAgICAgIDcz OSBjYWxscwowMDowMToxMy40MDMgL0dWTU0vU3VtL0hhbHRDYWxscyAgICAgICAgICAgICAgICAg IDUxMDcgY2FsbHMKMDA6MDE6MTMuNDA0IC9HVk1NL1N1bS9IYWx0Tm90QmxvY2tpbmcgICAgICAg ICAgICA0MzY4IGNhbGxzCjAwOjAxOjEzLjQwNCAvR1ZNTS9TdW0vSGFsdFRpbWVvdXRzICAgICAg ICAgICAgICAgIDU1MiBjYWxscwowMDowMToxMy40MDQgL0dWTU0vU3VtL0hhbHRXYWtlVXBzICAg ICAgICAgICAgICAgICAgIDAgY2FsbHMKMDA6MDE6MTMuNDA0IC9HVk1NL1N1bS9Qb2tlQ2FsbHMg ICAgICAgICAgICAgICAgICAgICAwIGNhbGxzCjAwOjAxOjEzLjQwNCAvR1ZNTS9TdW0vUG9rZU5v dEJ1c3kgICAgICAgICAgICAgICAgICAgMCBjYWxscwowMDowMToxMy40MDQgL0dWTU0vU3VtL1Bv bGxDYWxscyAgICAgICAgICAgICAgICAgICAgIDEgY2FsbHMKMDA6MDE6MTMuNDA0IC9HVk1NL1N1 bS9Qb2xsSGFsdHMgICAgICAgICAgICAgICAgICAgICAwIGNhbGxzCjAwOjAxOjEzLjQwNCAvR1ZN TS9TdW0vUG9sbFdha2VVcHMgICAgICAgICAgICAgICAgICAgMCBjYWxscwowMDowMToxMy40MDQg L0dWTU0vU3VtL1dha2VVcENhbGxzICAgICAgICAgICAgICAgICAzNDQgY2FsbHMKMDA6MDE6MTMu NDA0IC9HVk1NL1N1bS9XYWtlVXBOb3RIYWx0ZWQgICAgICAgICAgICAgMjk0IGNhbGxzCjAwOjAx OjEzLjQwNCAvR1ZNTS9TdW0vV2FrZVVwV2FrZVVwcyAgICAgICAgICAgICAgICAgMCBjYWxscwow MDowMToxMy40MDQgL0dWTU0vVk0vSGFsdEJsb2NraW5nICAgICAgICAgICAgICAgICA3MzkgY2Fs bHMKMDA6MDE6MTMuNDA0IC9HVk1NL1ZNL0hhbHRDYWxscyAgICAgICAgICAgICAgICAgICA1MTA3 IGNhbGxzCjAwOjAxOjEzLjQwNCAvR1ZNTS9WTS9IYWx0Tm90QmxvY2tpbmcgICAgICAgICAgICAg NDM2OCBjYWxscwowMDowMToxMy40MDQgL0dWTU0vVk0vSGFsdFRpbWVvdXRzICAgICAgICAgICAg ICAgICA1NTIgY2FsbHMKMDA6MDE6MTMuNDA0IC9HVk1NL1ZNL0hhbHRXYWtlVXBzICAgICAgICAg ICAgICAgICAgICAwIGNhbGxzCjAwOjAxOjEzLjQwNCAvR1ZNTS9WTS9Qb2tlQ2FsbHMgICAgICAg ICAgICAgICAgICAgICAgMCBjYWxscwowMDowMToxMy40MDQgL0dWTU0vVk0vUG9rZU5vdEJ1c3kg ICAgICAgICAgICAgICAgICAgIDAgY2FsbHMKMDA6MDE6MTMuNDA0IC9HVk1NL1ZNL1BvbGxDYWxs cyAgICAgICAgICAgICAgICAgICAgICAxIGNhbGxzCjAwOjAxOjEzLjQwNCAvR1ZNTS9WTS9Qb2xs SGFsdHMgICAgICAgICAgICAgICAgICAgICAgMCBjYWxscwowMDowMToxMy40MDQgL0dWTU0vVk0v UG9sbFdha2VVcHMgICAgICAgICAgICAgICAgICAgIDAgY2FsbHMKMDA6MDE6MTMuNDA0IC9HVk1N L1ZNL1dha2VVcENhbGxzICAgICAgICAgICAgICAgICAgMzQ0IGNhbGxzCjAwOjAxOjEzLjQwNCAv R1ZNTS9WTS9XYWtlVXBOb3RIYWx0ZWQgICAgICAgICAgICAgIDI5NCBjYWxscwowMDowMToxMy40 MDQgL0dWTU0vVk0vV2FrZVVwV2FrZVVwcyAgICAgICAgICAgICAgICAgIDAgY2FsbHMKMDA6MDE6 MTMuNDA0IC9HVk1NL1ZNcyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAxIGNhbGxzCjAw OjAxOjEzLjQwNCAvTU0vSHlwZXJIZWFwL2NiRnJlZSAgICAgICAgICAgICAgIDQ3NzYwMCBieXRl cwowMDowMToxMy40MDQgL01NL0h5cGVySGVhcC9jYkhlYXAgICAgICAgICAgICAgICA2NTUxMDQg Ynl0ZXMKMDA6MDE6MTMuNDA0IC9OZXQvSW50TmV0MC9CeXRlcy9SZWNlaXZlZCAgICAgICAgICAx NjQ2IGJ5dGVzCjAwOjAxOjEzLjQwNCAvTmV0L0ludE5ldDAvQnl0ZXMvU2VudCAgICAgICAgICAg ICAgICAgMCBieXRlcwowMDowMToxMy40MDQgL05ldC9JbnROZXQwL1BhY2tldHMvTG9zdCAgICAg ICAgICAgICAgIDAgY291bnQKMDA6MDE6MTMuNDA0IC9OZXQvSW50TmV0MC9QYWNrZXRzL1JlY2Vp dmVkICAgICAgICAgIDIyIGNvdW50CjAwOjAxOjEzLjQwNCAvTmV0L0ludE5ldDAvUGFja2V0cy9T ZW50ICAgICAgICAgICAgICAgMCBjb3VudAowMDowMToxMy40MDQgL05ldC9JbnROZXQwL1lpZWxk Tm9rICAgICAgICAgICAgICAgICAgIDAgY291bnQKMDA6MDE6MTMuNDA0IC9QRE0vQ3JpdFNlY3Rz L0FUQTAvQ29udGVudGlvblIzICAgICAgICAwIHRpbWVzCjAwOjAxOjEzLjQwNCAvUERNL0NyaXRT ZWN0cy9BVEEwL0NvbnRlbnRpb25SWkxvY2sgICAgICAgIDYgdGltZXMKMDA6MDE6MTMuNDA0IC9Q RE0vQ3JpdFNlY3RzL0FUQTAvQ29udGVudGlvblJaVW5sb2NrICAgICAgICAwIHRpbWVzCjAwOjAx OjEzLjQwNCAvUERNL0NyaXRTZWN0cy9BVEExL0NvbnRlbnRpb25SMyAgICAgICAgMCB0aW1lcwow MDowMToxMy40MDQgL1BETS9Dcml0U2VjdHMvQVRBMS9Db250ZW50aW9uUlpMb2NrICAgICAgICAx IHRpbWVzCjAwOjAxOjEzLjQwNCAvUERNL0NyaXRTZWN0cy9BVEExL0NvbnRlbnRpb25SWlVubG9j ayAgICAgICAgMCB0aW1lcwowMDowMToxMy40MDQgL1BETS9Dcml0U2VjdHMvRTEwMDAjMC9Db250 ZW50aW9uUjMgICAgICAgIDAgdGltZXMKMDA6MDE6MTMuNDA0IC9QRE0vQ3JpdFNlY3RzL0UxMDAw IzAvQ29udGVudGlvblJaTG9jayAgICAgICAgMCB0aW1lcwowMDowMToxMy40MDQgL1BETS9Dcml0 U2VjdHMvRTEwMDAjMC9Db250ZW50aW9uUlpVbmxvY2sgICAgICAgIDAgdGltZXMKMDA6MDE6MTMu NDA0IC9QRE0vQ3JpdFNlY3RzL0UxMDAwIzBSWC9Db250ZW50aW9uUjMgICAgICAgIDAgdGltZXMK MDA6MDE6MTMuNDA0IC9QRE0vQ3JpdFNlY3RzL0UxMDAwIzBSWC9Db250ZW50aW9uUlpMb2NrICAg ICAgICAwIHRpbWVzCjAwOjAxOjEzLjQwNCAvUERNL0NyaXRTZWN0cy9FMTAwMCMwUlgvQ29udGVu dGlvblJaVW5sb2NrICAgICAgICAwIHRpbWVzCjAwOjAxOjEzLjQwNCAvUERNL0NyaXRTZWN0cy9F TS1SRU0vQ29udGVudGlvblIzICAgICAgICAwIHRpbWVzCjAwOjAxOjEzLjQwNCAvUERNL0NyaXRT ZWN0cy9FTS1SRU0vQ29udGVudGlvblJaTG9jayAgICAgICAgMCB0aW1lcwowMDowMToxMy40MDQg L1BETS9Dcml0U2VjdHMvRU0tUkVNL0NvbnRlbnRpb25SWlVubG9jayAgICAgICAgMCB0aW1lcwow MDowMToxMy40MDQgL1BETS9Dcml0U2VjdHMvSU9NIEVNVCBMb2NrL0NvbnRlbnRpb25SMyAgICAg ICAgMCB0aW1lcwowMDowMToxMy40MDQgL1BETS9Dcml0U2VjdHMvSU9NIEVNVCBMb2NrL0NvbnRl bnRpb25SWkxvY2sgICAgICAgIDAgdGltZXMKMDA6MDE6MTMuNDA0IC9QRE0vQ3JpdFNlY3RzL0lP TSBFTVQgTG9jay9Db250ZW50aW9uUlpVbmxvY2sgICAgICAgIDAgdGltZXMKMDA6MDE6MTMuNDA0 IC9QRE0vQ3JpdFNlY3RzL01NLUhZUEVSL0NvbnRlbnRpb25SMyAgICAgICAgMCB0aW1lcwowMDow MToxMy40MDQgL1BETS9Dcml0U2VjdHMvTU0tSFlQRVIvQ29udGVudGlvblJaTG9jayAgICAgICAg MCB0aW1lcwowMDowMToxMy40MDQgL1BETS9Dcml0U2VjdHMvTU0tSFlQRVIvQ29udGVudGlvblJa VW5sb2NrICAgICAgICAwIHRpbWVzCjAwOjAxOjEzLjQwNCAvUERNL0NyaXRTZWN0cy9QRE0vQ29u dGVudGlvblIzICAgICAgICAgMCB0aW1lcwowMDowMToxMy40MDQgL1BETS9Dcml0U2VjdHMvUERN L0NvbnRlbnRpb25SWkxvY2sgICAgICAgIDAgdGltZXMKMDA6MDE6MTMuNDA0IC9QRE0vQ3JpdFNl Y3RzL1BETS9Db250ZW50aW9uUlpVbmxvY2sgICAgICAgIDAgdGltZXMKMDA6MDE6MTMuNDA0IC9Q RE0vQ3JpdFNlY3RzL1BHTS9Db250ZW50aW9uUjMgICAgICAgICAwIHRpbWVzCjAwOjAxOjEzLjQw NCAvUERNL0NyaXRTZWN0cy9QR00vQ29udGVudGlvblJaTG9jayAgICAgICAgMCB0aW1lcwowMDow MToxMy40MDQgL1BETS9Dcml0U2VjdHMvUEdNL0NvbnRlbnRpb25SWlVubG9jayAgICAgICAgMCB0 aW1lcwowMDowMToxMy40MDQgL1BETS9Dcml0U2VjdHMvUFMyS00jMC9Db250ZW50aW9uUjMgICAg ICAgIDAgdGltZXMKMDA6MDE6MTMuNDA0IC9QRE0vQ3JpdFNlY3RzL1BTMktNIzAvQ29udGVudGlv blJaTG9jayAgICAgICAgMCB0aW1lcwowMDowMToxMy40MDQgL1BETS9Dcml0U2VjdHMvUFMyS00j MC9Db250ZW50aW9uUlpVbmxvY2sgICAgICAgIDAgdGltZXMKMDA6MDE6MTMuNDA0IC9QRE0vQ3Jp dFNlY3RzL1JFTS1SZWdpc3Rlci9Db250ZW50aW9uUjMgICAgICAgIDAgdGltZXMKMDA6MDE6MTMu NDA0IC9QRE0vQ3JpdFNlY3RzL1JFTS1SZWdpc3Rlci9Db250ZW50aW9uUlpMb2NrICAgICAgICAw IHRpbWVzCjAwOjAxOjEzLjQwNCAvUERNL0NyaXRTZWN0cy9SRU0tUmVnaXN0ZXIvQ29udGVudGlv blJaVW5sb2NrICAgICAgICAwIHRpbWVzCjAwOjAxOjEzLjQwNSAvUERNL0NyaXRTZWN0cy9UTSBU aW1lciBMb2NrL0NvbnRlbnRpb25SMyAgICAgICAgMCB0aW1lcwowMDowMToxMy40MDUgL1BETS9D cml0U2VjdHMvVE0gVGltZXIgTG9jay9Db250ZW50aW9uUlpMb2NrICAgICAgICAwIHRpbWVzCjAw OjAxOjEzLjQwNSAvUERNL0NyaXRTZWN0cy9UTSBUaW1lciBMb2NrL0NvbnRlbnRpb25SWlVubG9j ayAgICAgICAgMCB0aW1lcwowMDowMToxMy40MDUgL1BETS9Dcml0U2VjdHMvVE0gVmlydHVhbFN5 bmMgTG9jay9Db250ZW50aW9uUjMgICAgICAgIDAgdGltZXMKMDA6MDE6MTMuNDA1IC9QRE0vQ3Jp dFNlY3RzL1RNIFZpcnR1YWxTeW5jIExvY2svQ29udGVudGlvblJaTG9jayAgICAgICAgMCB0aW1l cwowMDowMToxMy40MDUgL1BETS9Dcml0U2VjdHMvVE0gVmlydHVhbFN5bmMgTG9jay9Db250ZW50 aW9uUlpVbmxvY2sgICAgICAgIDAgdGltZXMKMDA6MDE6MTMuNDA1IC9QRE0vQ3JpdFNlY3RzL1ZH QS9Db250ZW50aW9uUjMgICAgICAgICAwIHRpbWVzCjAwOjAxOjEzLjQwNSAvUERNL0NyaXRTZWN0 cy9WR0EvQ29udGVudGlvblJaTG9jayAgICAgICAgMCB0aW1lcwowMDowMToxMy40MDUgL1BETS9D cml0U2VjdHMvVkdBL0NvbnRlbnRpb25SWlVubG9jayAgICAgICAgMCB0aW1lcwowMDowMToxMy40 MDUgL1BETS9Dcml0U2VjdHMvVk1NRGV2L0NvbnRlbnRpb25SMyAgICAgICAgMCB0aW1lcwowMDow MToxMy40MDUgL1BETS9Dcml0U2VjdHMvVk1NRGV2L0NvbnRlbnRpb25SWkxvY2sgICAgICAgIDAg dGltZXMKMDA6MDE6MTMuNDA1IC9QRE0vQ3JpdFNlY3RzL1ZNTURldi9Db250ZW50aW9uUlpVbmxv Y2sgICAgICAgIDAgdGltZXMKMDA6MDE6MTMuNDA1IC9QR00vQ1BVMC9jR3Vlc3RNb2RlQ2hhbmdl cyAgICAgICAgIDQxODg3IHRpbWVzCjAwOjAxOjEzLjQwNSAvUEdNL0NodW5rUjNNYXAvYyAgICAg ICAgICAgICAgICAgICAgICAxNSB0aW1lcwowMDowMToxMy40MDUgL1BHTS9DaHVua1IzTWFwL2NN YXggICAgICAgICAgICAgNDI5NDk2NzI5NSB0aW1lcwowMDowMToxMy40MDUgL1BHTS9QYWdlL2NB bGxQYWdlcyAgICAgICAgICAgICAgICAxMzM0ODcgdGltZXMKMDA6MDE6MTMuNDA1IC9QR00vUGFn ZS9jSGFuZHlQYWdlcyAgICAgICAgICAgICAgICAgIDM5IHRpbWVzCjAwOjAxOjEzLjQwNSAvUEdN L1BhZ2UvY1ByaXZhdGVQYWdlcyAgICAgICAgICAgICAgNTk0NiB0aW1lcwowMDowMToxMy40MDUg L1BHTS9QYWdlL2NTaGFyZWRQYWdlcyAgICAgICAgICAgICAgICAgIDAgdGltZXMKMDA6MDE6MTMu NDA1IC9QR00vUGFnZS9jWmVyb1BhZ2VzICAgICAgICAgICAgICAgMTI3NTQxIHRpbWVzCjAwOjAx OjEzLjQwNSAvUEdNL2NSZWxvY2F0aW9ucyAgICAgICAgICAgICAgICAgICAgICAgMCB0aW1lcwow MDowMToxMy40MDUgL1BST0YvQ1BVMC9FTS9Gb3JjZWRBY3Rpb25zICAgICAgIDIwODIwMDIgdGlt ZXMKMDA6MDE6MTMuNDA1IC9QUk9GL0NQVTAvRU0vSGFsdGVkICAgICAgICAgICAgICAgICAgMTg4 IHRpbWVzCjAwOjAxOjEzLjQwNSAvUFJPRi9DUFUwL0VNL1JBV1RvdGFsICAgICAgICAgICAgICAg ICAgMCB0aW1lcwowMDowMToxMy40MDUgL1BST0YvQ1BVMC9FTS9SRU1Ub3RhbCAgICAgICAgICAg ICAgMjA5NDIgdGltZXMKMDA6MDE6MTMuNDA1IC9QUk9GL0NQVTAvRU0vVG90YWwgICAgICAgICAg ICAgIDYzMjQxMTg4Njg0IHRpY2tzL2NhbGwgKDEyNjQ4MjM3NzM2OCB0aWNrcywgICAgICAgMiB0 aW1lcywgbWF4IDExMTQxNDg4NjM1NiwgbWluIDE1MDY3NDkxMDEyKQowMDowMToxMy40MDUgL1BS T0YvVk0vQ1BVMC9IYWx0L0Jsb2NrICAgICAgICAgICAzOTMyMzkgdGlja3MvY2FsbCAoICAyMDAy NzY2MjkyIHRpY2tzLCAgICA1MDkzIHRpbWVzLCBtYXggIDIxMjEzODA0LCBtaW4gICAgNjc0NCkK MDA6MDE6MTMuNDA2IC9QUk9GL1ZNL0NQVTAvSGFsdC9UaW1lcnMgICAgICAgICAgICA5OTYxIHRp Y2tzL2NhbGwgKCAgICA2NzI4OTU0NCB0aWNrcywgICAgNjc1NSB0aW1lcywgbWF4ICAgODM4Njk5 MiwgbWluICAgIDIwNjQpCjAwOjAxOjEzLjQwNiAvUFJPRi9WTS9DUFUwL0hhbHQvWWllbGQgICAg ICAgICAgICAgOTg2NCB0aWNrcy9jYWxsICggICAgICAgIDk4NjQgdGlja3MsICAgICAgIDEgdGlt ZXMsIG1heCAgICAgIDk4NjQsIG1pbiAgICA5ODY0KQowMDowMToxMy40MDYgL1JFTS9UYkZsdXNo Q291bnQgICAgICAgICAgICAgICAgICAgMjA5NDIgdGltZXMKMDA6MDE6MTMuNDA2IC9SRU0vVGJQ aHlzSW52bGRDb3VudCAgICAgICAgICAgICAgICAgMjk5IHRpbWVzCjAwOjAxOjEzLjQwNiAvUkVN L1RsYkZsdXNoQ291bnQgICAgICAgICAgICAgICAgICAyMDk3NCB0aW1lcwowMDowMToxMy40MDYg L1RNL1IwLzFuc1N0ZXBzICAgICAgICAgICAgICAgICAgICAgMTMxNDMgdGltZXMKMDA6MDE6MTMu NDA2IC9UTS9SMy8xbnNTdGVwcyAgICAgICAgICAgICAgICAgICAgIDE2OTM4IHRpbWVzCjAwOjAx OjEzLjQwNiAvVE0vVFNDL29mZkNQVTAgICAgICAgICAgICAgICAgICAgICAgICAgMCB0aWNrcwow MDowMToxMy40MDYgL1RNL1ZpcnR1YWxTeW5jL0N1cnJlbnRPZmZzZXQgICAgICA3MzMxMTkgbnMK MDA6MDE6MTMuNDA2IC9WVVNCLzAvY1VyYnNJblBvb2wgICAgICAgICAgICAgICAgICAgICAwIGNv dW50CjAwOjAxOjEzLjQwNiAvVlVTQi8xL2NVcmJzSW5Qb29sICAgICAgICAgICAgICAgICAgICAg MCBjb3VudAowMDowMToxMy40MDYgKioqKioqKioqKioqKioqKioqKioqIEVuZCBvZiBzdGF0aXN0 aWNzICoqKioqKioqKioqKioqKioqKioqKioKMDA6MDE6MTMuNDIyIENoYW5naW5nIHRoZSBWTSBz dGF0ZSBmcm9tICdERVNUUk9ZSU5HJyB0byAnVEVSTUlOQVRFRCcuCg== --0015174bec1c12b8350477406512 Content-Type: application/octet-stream; name="VBox.log.without-ACPI" Content-Disposition: attachment; filename="VBox.log.without-ACPI" Content-Transfer-Encoding: base64 X-Attachment-Id: f_g1gs4iju2 MDA6MDA6MDEuNjczIFZpcnR1YWxCb3ggMy4wLjEwIHI1NDA5NyBkYXJ3aW4ueDg2IChPY3QgMjkg MjAwOSAxNDoyNjo0NCkgcmVsZWFzZSBsb2cKMDA6MDA6MDEuNjczIExvZyBvcGVuZWQgMjAwOS0x MC0zMVQxODozMzowOC4yMzU5NDIwMDBaCjAwOjAwOjAxLjY3MyBPUyBQcm9kdWN0OiBEYXJ3aW4K MDA6MDA6MDEuNjczIE9TIFJlbGVhc2U6IDEwLjAuMAowMDowMDowMS42NzMgT1MgVmVyc2lvbjog RGFyd2luIEtlcm5lbCBWZXJzaW9uIDEwLjAuMDogRnJpIEp1bCAzMSAyMjo0NzozNCBQRFQgMjAw OTsgcm9vdDp4bnUtMTQ1Ni4xLjI1fjEvUkVMRUFTRV9JMzg2CjAwOjAwOjAxLjY3MyBIb3N0IFJB TTogNDA5Nk1CIFJBTSwgYXZhaWxhYmxlOiAxNDU2TUIKMDA6MDA6MDEuNjczIEV4ZWN1dGFibGU6 IC9BcHBsaWNhdGlvbnMvVmlydHVhbEJveC5hcHAvQ29udGVudHMvTWFjT1MvLi4vUmVzb3VyY2Vz L1ZpcnR1YWxCb3hWTS5hcHAvQ29udGVudHMvTWFjT1MvVmlydHVhbEJveFZNCjAwOjAwOjAxLjY3 MyBQcm9jZXNzIElEOiA3MzEKMDA6MDA6MDEuNjczIFBhY2thZ2UgdHlwZTogREFSV0lOXzMyQklU U19HRU5FUklDCjAwOjAwOjAxLjg0OCBTVVA6IExvYWRlZCBWTU1SMC5yMCAoL0FwcGxpY2F0aW9u cy9WaXJ0dWFsQm94LmFwcC9Db250ZW50cy9NYWNPUy9WTU1SMC5yMCkgYXQgMHg1YTUyZDA2MCAt IE1vZHVsZUluaXQgYXQgMDAwMDAwMDA1YTU0MDYwMCBhbmQgTW9kdWxlVGVybSBhdCAwMDAwMDAw MDVhNTQwNjkwCjAwOjAwOjAxLjg0OCBTVVA6IFZNTVIwRW50cnlFeCBsb2NhdGVkIGF0IDAwMDAw MDAwNWE1NDE0NzAsIFZNTVIwRW50cnlGYXN0IGF0IDAwMDAwMDAwNWE1NDE1YTAgYW5kIFZNTVIw RW50cnlJbnQgYXQgMDAwMDAwMDA1YTU0MDcyMAowMDowMDowMS45NjggVkJveFNoYXJlZENsaXBi b2FyZCBtb2RlOiBCaWRpcmVjdGlvbmFsCjAwOjAwOjAyLjE4MyAqKioqKioqKioqKioqKioqKioq KioqKioqIENGR00gZHVtcCAqKioqKioqKioqKioqKioqKioqKioqKioqCjAwOjAwOjAyLjE4MyBw Um9vdD0wMjM3N2Q2MDp7L30KMDA6MDA6MDIuMTgzIFsvXSAobGV2ZWwgMCkKMDA6MDA6MDIuMTgz ICAgTmFtZSAgICAgICAgICAgICAgIDxzdHJpbmc+ICA9ICJGcmVlQlNEIGtsZWluIiAoY2NoPTE0 KQowMDowMDowMi4xODMgICBVVUlEICAgICAgICAgICAgICAgPGJ5dGVzPiAgID0gImRlIGJlIGQy IGIzIGNhIGUwIDk3IDRiIGEzIDg0IGE4IDYyIDdlIDdiIDY4IDRkIiAoY2I9MTYpCjAwOjAwOjAy LjE4MyAgIFJhbVNpemUgICAgICAgICAgICA8aW50ZWdlcj4gPSAweDAwMDAwMDAwMjAwMDAwMDAg KDUzNjg3MDkxMikKMDA6MDA6MDIuMTgzICAgUmFtSG9sZVNpemUgICAgICAgIDxpbnRlZ2VyPiA9 IDB4MDAwMDAwMDAyMDAwMDAwMCAoNTM2ODcwOTEyKQowMDowMDowMi4xODMgICBOdW1DUFVzICAg ICAgICAgICAgPGludGVnZXI+ID0gMHgwMDAwMDAwMDAwMDAwMDAxICgxKQowMDowMDowMi4xODMg ICBUaW1lck1pbGxpZXMgICAgICAgPGludGVnZXI+ID0gMHgwMDAwMDAwMDAwMDAwMDBhICgxMCkK MDA6MDA6MDIuMTgzICAgUmF3UjNFbmFibGVkICAgICAgIDxpbnRlZ2VyPiA9IDB4MDAwMDAwMDAw MDAwMDAwMSAoMSkKMDA6MDA6MDIuMTgzICAgUmF3UjBFbmFibGVkICAgICAgIDxpbnRlZ2VyPiA9 IDB4MDAwMDAwMDAwMDAwMDAwMSAoMSkKMDA6MDA6MDIuMTgzICAgUEFUTUVuYWJsZWQgICAgICAg IDxpbnRlZ2VyPiA9IDB4MDAwMDAwMDAwMDAwMDAwMSAoMSkKMDA6MDA6MDIuMTgzICAgQ1NBTUVu YWJsZWQgICAgICAgIDxpbnRlZ2VyPiA9IDB4MDAwMDAwMDAwMDAwMDAwMSAoMSkKMDA6MDA6MDIu MTgzICAgSHdWaXJ0RXh0Rm9yY2VkICAgIDxpbnRlZ2VyPiA9IDB4MDAwMDAwMDAwMDAwMDAwMSAo MSkKMDA6MDA6MDIuMTg0ICAgRW5hYmxlTmVzdGVkUGFnaW5nIDxpbnRlZ2VyPiA9IDB4MDAwMDAw MDAwMDAwMDAwMCAoMCkKMDA6MDA6MDIuMTg0ICAgRW5hYmxlVlBJRCAgICAgICAgIDxpbnRlZ2Vy PiA9IDB4MDAwMDAwMDAwMDAwMDAwMCAoMCkKMDA6MDA6MDIuMTg0ICAgRW5hYmxlUEFFICAgICAg ICAgIDxpbnRlZ2VyPiA9IDB4MDAwMDAwMDAwMDAwMDAwMCAoMCkKMDA6MDA6MDIuMTg0IAowMDow MDowMi4xODQgWy9IV1ZpcnRFeHQvXSAobGV2ZWwgMSkKMDA6MDA6MDIuMTg0ICAgRW5hYmxlZCAg ICAgIDxpbnRlZ2VyPiA9IDB4MDAwMDAwMDAwMDAwMDAwMSAoMSkKMDA6MDA6MDIuMTg0ICAgNjRi aXRFbmFibGVkIDxpbnRlZ2VyPiA9IDB4MDAwMDAwMDAwMDAwMDAwMSAoMSkKMDA6MDA6MDIuMTg0 IAowMDowMDowMi4xODQgWy9SRU0vXSAobGV2ZWwgMSkKMDA6MDA6MDIuMTg0ICAgNjRiaXRFbmFi bGVkIDxpbnRlZ2VyPiA9IDB4MDAwMDAwMDAwMDAwMDAwMSAoMSkKMDA6MDA6MDIuMTg0IAowMDow MDowMi4xODQgWy9QRE0vXSAobGV2ZWwgMSkKMDA6MDA6MDIuMTg0IAowMDowMDowMi4xODQgWy9Q RE0vRHJpdmVycy9dIChsZXZlbCAyKQowMDowMDowMi4xODQgCjAwOjAwOjAyLjE4NCBbL1BETS9E cml2ZXJzL1ZCb3hDL10gKGxldmVsIDMpCjAwOjAwOjAyLjE4NCAgIFBhdGggPHN0cmluZz4gID0g Ii9BcHBsaWNhdGlvbnMvVmlydHVhbEJveC5hcHAvQ29udGVudHMvTWFjT1MvY29tcG9uZW50cy9W Qm94QyIgKGNjaD02MSkKMDA6MDA6MDIuMTg0IAowMDowMDowMi4xODQgWy9EZXZpY2VzL10gKGxl dmVsIDEpCjAwOjAwOjAyLjE4NCAKMDA6MDA6MDIuMTg0IFsvRGV2aWNlcy9wY2FyY2gvXSAobGV2 ZWwgMikKMDA6MDA6MDIuMTg0IAowMDowMDowMi4xODQgWy9EZXZpY2VzL3BjYXJjaC8wL10gKGxl dmVsIDMpCjAwOjAwOjAyLjE4NCAgIFRydXN0ZWQgPGludGVnZXI+ID0gMHgwMDAwMDAwMDAwMDAw MDAxICgxKQowMDowMDowMi4xODQgCjAwOjAwOjAyLjE4NCBbL0RldmljZXMvcGNhcmNoLzAvQ29u ZmlnL10gKGxldmVsIDQpCjAwOjAwOjAyLjE4NCAKMDA6MDA6MDIuMTg0IFsvRGV2aWNlcy9wY2Jp b3MvXSAobGV2ZWwgMikKMDA6MDA6MDIuMTg0IAowMDowMDowMi4xODQgWy9EZXZpY2VzL3BjYmlv cy8wL10gKGxldmVsIDMpCjAwOjAwOjAyLjE4NCAgIFRydXN0ZWQgPGludGVnZXI+ID0gMHgwMDAw MDAwMDAwMDAwMDAxICgxKQowMDowMDowMi4xODQgCjAwOjAwOjAyLjE4NCBbL0RldmljZXMvcGNi aW9zLzAvQ29uZmlnL10gKGxldmVsIDQpCjAwOjAwOjAyLjE4NCAgIFJhbVNpemUgICAgICAgIDxp bnRlZ2VyPiA9IDB4MDAwMDAwMDAyMDAwMDAwMCAoNTM2ODcwOTEyKQowMDowMDowMi4xODQgICBS YW1Ib2xlU2l6ZSAgICA8aW50ZWdlcj4gPSAweDAwMDAwMDAwMjAwMDAwMDAgKDUzNjg3MDkxMikK MDA6MDA6MDIuMTg0ICAgTnVtQ1BVcyAgICAgICAgPGludGVnZXI+ID0gMHgwMDAwMDAwMDAwMDAw MDAxICgxKQowMDowMDowMi4xODQgICBIYXJkRGlza0RldmljZSA8c3RyaW5nPiAgPSAicGlpeDNp ZGUiIChjY2g9OSkKMDA6MDA6MDIuMTg0ICAgRmxvcHB5RGV2aWNlICAgPHN0cmluZz4gID0gImk4 MjA3OCIgKGNjaD03KQowMDowMDowMi4xODQgICBJT0FQSUMgICAgICAgICA8aW50ZWdlcj4gPSAw eDAwMDAwMDAwMDAwMDAwMDEgKDEpCjAwOjAwOjAyLjE4NCAgIFBYRURlYnVnICAgICAgIDxpbnRl Z2VyPiA9IDB4MDAwMDAwMDAwMDAwMDAwMCAoMCkKMDA6MDA6MDIuMTg0ICAgVVVJRCAgICAgICAg ICAgPGJ5dGVzPiAgID0gImRlIGJlIGQyIGIzIGNhIGUwIDk3IDRiIGEzIDg0IGE4IDYyIDdlIDdi IDY4IDRkIiAoY2I9MTYpCjAwOjAwOjAyLjE4NCAgIEJvb3REZXZpY2UwICAgIDxzdHJpbmc+ICA9 ICJGTE9QUFkiIChjY2g9NykKMDA6MDA6MDIuMTg0ICAgQm9vdERldmljZTEgICAgPHN0cmluZz4g ID0gIkRWRCIgKGNjaD00KQowMDowMDowMi4xODQgICBCb290RGV2aWNlMiAgICA8c3RyaW5nPiAg PSAiSURFIiAoY2NoPTQpCjAwOjAwOjAyLjE4NCAgIEJvb3REZXZpY2UzICAgIDxzdHJpbmc+ICA9 ICJOT05FIiAoY2NoPTUpCjAwOjAwOjAyLjE4NCAKMDA6MDA6MDIuMTg0IFsvRGV2aWNlcy84MjM3 QS9dIChsZXZlbCAyKQowMDowMDowMi4xODQgCjAwOjAwOjAyLjE4NCBbL0RldmljZXMvODIzN0Ev MC9dIChsZXZlbCAzKQowMDowMDowMi4xODQgICBUcnVzdGVkIDxpbnRlZ2VyPiA9IDB4MDAwMDAw MDAwMDAwMDAwMSAoMSkKMDA6MDA6MDIuMTg1IAowMDowMDowMi4xODUgWy9EZXZpY2VzL3BjaS9d IChsZXZlbCAyKQowMDowMDowMi4xODUgCjAwOjAwOjAyLjE4NSBbL0RldmljZXMvcGNpLzAvXSAo bGV2ZWwgMykKMDA6MDA6MDIuMTg1ICAgVHJ1c3RlZCA8aW50ZWdlcj4gPSAweDAwMDAwMDAwMDAw MDAwMDEgKDEpCjAwOjAwOjAyLjE4NSAKMDA6MDA6MDIuMTg1IFsvRGV2aWNlcy9wY2kvMC9Db25m aWcvXSAobGV2ZWwgNCkKMDA6MDA6MDIuMTg1ICAgSU9BUElDIDxpbnRlZ2VyPiA9IDB4MDAwMDAw MDAwMDAwMDAwMSAoMSkKMDA6MDA6MDIuMTg1IAowMDowMDowMi4xODUgWy9EZXZpY2VzL3Bja2Jk L10gKGxldmVsIDIpCjAwOjAwOjAyLjE4NSAKMDA6MDA6MDIuMTg1IFsvRGV2aWNlcy9wY2tiZC8w L10gKGxldmVsIDMpCjAwOjAwOjAyLjE4NSAgIFRydXN0ZWQgPGludGVnZXI+ID0gMHgwMDAwMDAw MDAwMDAwMDAxICgxKQowMDowMDowMi4xODUgCjAwOjAwOjAyLjE4NSBbL0RldmljZXMvcGNrYmQv MC9Db25maWcvXSAobGV2ZWwgNCkKMDA6MDA6MDIuMTg1IAowMDowMDowMi4xODUgWy9EZXZpY2Vz L3Bja2JkLzAvTFVOIzAvXSAobGV2ZWwgNCkKMDA6MDA6MDIuMTg1ICAgRHJpdmVyIDxzdHJpbmc+ ICA9ICJLZXlib2FyZFF1ZXVlIiAoY2NoPTE0KQowMDowMDowMi4xODUgCjAwOjAwOjAyLjE4NSBb L0RldmljZXMvcGNrYmQvMC9MVU4jMC9Db25maWcvXSAobGV2ZWwgNSkKMDA6MDA6MDIuMTg1ICAg UXVldWVTaXplIDxpbnRlZ2VyPiA9IDB4MDAwMDAwMDAwMDAwMDA0MCAoNjQpCjAwOjAwOjAyLjE4 NSAKMDA6MDA6MDIuMTg1IFsvRGV2aWNlcy9wY2tiZC8wL0xVTiMwL0F0dGFjaGVkRHJpdmVyL10g KGxldmVsIDUpCjAwOjAwOjAyLjE4NSAgIERyaXZlciA8c3RyaW5nPiAgPSAiTWFpbktleWJvYXJk IiAoY2NoPTEzKQowMDowMDowMi4xODUgCjAwOjAwOjAyLjE4NSBbL0RldmljZXMvcGNrYmQvMC9M VU4jMC9BdHRhY2hlZERyaXZlci9Db25maWcvXSAobGV2ZWwgNikKMDA6MDA6MDIuMTg1ICAgT2Jq ZWN0IDxpbnRlZ2VyPiA9IDB4MDAwMDAwMDAwMjM0NzUzMCAoMzY5OTIzMDQpCjAwOjAwOjAyLjE4 NSAKMDA6MDA6MDIuMTg1IFsvRGV2aWNlcy9wY2tiZC8wL0xVTiMxL10gKGxldmVsIDQpCjAwOjAw OjAyLjE4NSAgIERyaXZlciA8c3RyaW5nPiAgPSAiTW91c2VRdWV1ZSIgKGNjaD0xMSkKMDA6MDA6 MDIuMTg1IAowMDowMDowMi4xODUgWy9EZXZpY2VzL3Bja2JkLzAvTFVOIzEvQ29uZmlnL10gKGxl dmVsIDUpCjAwOjAwOjAyLjE4NSAgIFF1ZXVlU2l6ZSA8aW50ZWdlcj4gPSAweDAwMDAwMDAwMDAw MDAwODAgKDEyOCkKMDA6MDA6MDIuMTg1IAowMDowMDowMi4xODUgWy9EZXZpY2VzL3Bja2JkLzAv TFVOIzEvQXR0YWNoZWREcml2ZXIvXSAobGV2ZWwgNSkKMDA6MDA6MDIuMTg1ICAgRHJpdmVyIDxz dHJpbmc+ICA9ICJNYWluTW91c2UiIChjY2g9MTApCjAwOjAwOjAyLjE4NSAKMDA6MDA6MDIuMTg1 IFsvRGV2aWNlcy9wY2tiZC8wL0xVTiMxL0F0dGFjaGVkRHJpdmVyL0NvbmZpZy9dIChsZXZlbCA2 KQowMDowMDowMi4xODUgICBPYmplY3QgPGludGVnZXI+ID0gMHgwMDAwMDAwMDAwMTRkNDgwICgx MzY1MTIwKQowMDowMDowMi4xODUgCjAwOjAwOjAyLjE4NSBbL0RldmljZXMvaTgyMDc4L10gKGxl dmVsIDIpCjAwOjAwOjAyLjE4NiAKMDA6MDA6MDIuMTg2IFsvRGV2aWNlcy9pODIwNzgvMC9dIChs ZXZlbCAzKQowMDowMDowMi4xODYgICBUcnVzdGVkIDxpbnRlZ2VyPiA9IDB4MDAwMDAwMDAwMDAw MDAwMSAoMSkKMDA6MDA6MDIuMTg2IAowMDowMDowMi4xODYgWy9EZXZpY2VzL2k4MjA3OC8wL0Nv bmZpZy9dIChsZXZlbCA0KQowMDowMDowMi4xODYgICBJUlEgICAgICAgPGludGVnZXI+ID0gMHgw MDAwMDAwMDAwMDAwMDA2ICg2KQowMDowMDowMi4xODYgICBETUEgICAgICAgPGludGVnZXI+ID0g MHgwMDAwMDAwMDAwMDAwMDAyICgyKQowMDowMDowMi4xODYgICBNZW1NYXBwZWQgPGludGVnZXI+ ID0gMHgwMDAwMDAwMDAwMDAwMDAwICgwKQowMDowMDowMi4xODYgICBJT0Jhc2UgICAgPGludGVn ZXI+ID0gMHgwMDAwMDAwMDAwMDAwM2YwICgxMDA4KQowMDowMDowMi4xODYgCjAwOjAwOjAyLjE4 NiBbL0RldmljZXMvaTgyMDc4LzAvTFVOIzk5OS9dIChsZXZlbCA0KQowMDowMDowMi4xODYgICBE cml2ZXIgPHN0cmluZz4gID0gIk1haW5TdGF0dXMiIChjY2g9MTEpCjAwOjAwOjAyLjE4NiAKMDA6 MDA6MDIuMTg2IFsvRGV2aWNlcy9pODIwNzgvMC9MVU4jOTk5L0NvbmZpZy9dIChsZXZlbCA1KQow MDowMDowMi4xODYgICBwYXBMZWRzIDxpbnRlZ2VyPiA9IDB4MDAwMDAwMDAwMjg0MWNlNCAoNDIy MTI1ODApCjAwOjAwOjAyLjE4NiAgIEZpcnN0ICAgPGludGVnZXI+ID0gMHgwMDAwMDAwMDAwMDAw MDAwICgwKQowMDowMDowMi4xODYgICBMYXN0ICAgIDxpbnRlZ2VyPiA9IDB4MDAwMDAwMDAwMDAw MDAwMCAoMCkKMDA6MDA6MDIuMTg2IAowMDowMDowMi4xODYgWy9EZXZpY2VzL2k4MjA3OC8wL0xV TiMwL10gKGxldmVsIDQpCjAwOjAwOjAyLjE4NiAgIERyaXZlciA8c3RyaW5nPiAgPSAiQmxvY2si IChjY2g9NikKMDA6MDA6MDIuMTg2IAowMDowMDowMi4xODYgWy9EZXZpY2VzL2k4MjA3OC8wL0xV TiMwL0NvbmZpZy9dIChsZXZlbCA1KQowMDowMDowMi4xODYgICBUeXBlICAgICAgPHN0cmluZz4g ID0gIkZsb3BweSAxLjQ0IiAoY2NoPTEyKQowMDowMDowMi4xODYgICBNb3VudGFibGUgPGludGVn ZXI+ID0gMHgwMDAwMDAwMDAwMDAwMDAxICgxKQowMDowMDowMi4xODYgCjAwOjAwOjAyLjE4NiBb L0RldmljZXMvYWNwaS9dIChsZXZlbCAyKQowMDowMDowMi4xODYgCjAwOjAwOjAyLjE4NiBbL0Rl dmljZXMvYWNwaS8wL10gKGxldmVsIDMpCjAwOjAwOjAyLjE4NiAgIFRydXN0ZWQgICAgICAgPGlu dGVnZXI+ID0gMHgwMDAwMDAwMDAwMDAwMDAxICgxKQowMDowMDowMi4xODYgICBQQ0lEZXZpY2VO byAgIDxpbnRlZ2VyPiA9IDB4MDAwMDAwMDAwMDAwMDAwNyAoNykKMDA6MDA6MDIuMTg2ICAgUENJ RnVuY3Rpb25ObyA8aW50ZWdlcj4gPSAweDAwMDAwMDAwMDAwMDAwMDAgKDApCjAwOjAwOjAyLjE4 NiAKMDA6MDA6MDIuMTg2IFsvRGV2aWNlcy9hY3BpLzAvQ29uZmlnL10gKGxldmVsIDQpCjAwOjAw OjAyLjE4NiAgIFJhbVNpemUgICAgIDxpbnRlZ2VyPiA9IDB4MDAwMDAwMDAyMDAwMDAwMCAoNTM2 ODcwOTEyKQowMDowMDowMi4xODYgICBSYW1Ib2xlU2l6ZSA8aW50ZWdlcj4gPSAweDAwMDAwMDAw MjAwMDAwMDAgKDUzNjg3MDkxMikKMDA6MDA6MDIuMTg2ICAgTnVtQ1BVcyAgICAgPGludGVnZXI+ ID0gMHgwMDAwMDAwMDAwMDAwMDAxICgxKQowMDowMDowMi4xODYgICBJT0FQSUMgICAgICA8aW50 ZWdlcj4gPSAweDAwMDAwMDAwMDAwMDAwMDEgKDEpCjAwOjAwOjAyLjE4NiAgIEZkY0VuYWJsZWQg IDxpbnRlZ2VyPiA9IDB4MDAwMDAwMDAwMDAwMDAwMSAoMSkKMDA6MDA6MDIuMTg2ICAgSHBldEVu YWJsZWQgPGludGVnZXI+ID0gMHgwMDAwMDAwMDAwMDAwMDAwICgwKQowMDowMDowMi4xODYgICBT aG93UnRjICAgICA8aW50ZWdlcj4gPSAweDAwMDAwMDAwMDAwMDAwMDAgKDApCjAwOjAwOjAyLjE4 NiAgIFNob3dDcHUgICAgIDxpbnRlZ2VyPiA9IDB4MDAwMDAwMDAwMDAwMDAwMSAoMSkKMDA6MDA6 MDIuMTg2IAowMDowMDowMi4xODYgWy9EZXZpY2VzL2FjcGkvMC9MVU4jMC9dIChsZXZlbCA0KQow MDowMDowMi4xODYgICBEcml2ZXIgPHN0cmluZz4gID0gIkFDUElIb3N0IiAoY2NoPTkpCjAwOjAw OjAyLjE4NiAKMDA6MDA6MDIuMTg2IFsvRGV2aWNlcy9hY3BpLzAvTFVOIzAvQ29uZmlnL10gKGxl dmVsIDUpCjAwOjAwOjAyLjE4NiAKMDA6MDA6MDIuMTg2IFsvRGV2aWNlcy9pODI1NC9dIChsZXZl bCAyKQowMDowMDowMi4xODYgCjAwOjAwOjAyLjE4NiBbL0RldmljZXMvaTgyNTQvMC9dIChsZXZl bCAzKQowMDowMDowMi4xODYgCjAwOjAwOjAyLjE4NiBbL0RldmljZXMvaTgyNTQvMC9Db25maWcv XSAobGV2ZWwgNCkKMDA6MDA6MDIuMTg2IAowMDowMDowMi4xODYgWy9EZXZpY2VzL2k4MjU5L10g KGxldmVsIDIpCjAwOjAwOjAyLjE4NiAKMDA6MDA6MDIuMTg2IFsvRGV2aWNlcy9pODI1OS8wL10g KGxldmVsIDMpCjAwOjAwOjAyLjE4NiAgIFRydXN0ZWQgPGludGVnZXI+ID0gMHgwMDAwMDAwMDAw MDAwMDAxICgxKQowMDowMDowMi4xODYgCjAwOjAwOjAyLjE4NiBbL0RldmljZXMvaTgyNTkvMC9D b25maWcvXSAobGV2ZWwgNCkKMDA6MDA6MDIuMTg2IAowMDowMDowMi4xODYgWy9EZXZpY2VzL2Fw aWMvXSAobGV2ZWwgMikKMDA6MDA6MDIuMTg2IAowMDowMDowMi4xODcgWy9EZXZpY2VzL2FwaWMv MC9dIChsZXZlbCAzKQowMDowMDowMi4xODcgICBUcnVzdGVkIDxpbnRlZ2VyPiA9IDB4MDAwMDAw MDAwMDAwMDAwMSAoMSkKMDA6MDA6MDIuMTg3IAowMDowMDowMi4xODcgWy9EZXZpY2VzL2FwaWMv MC9Db25maWcvXSAobGV2ZWwgNCkKMDA6MDA6MDIuMTg3ICAgSU9BUElDICA8aW50ZWdlcj4gPSAw eDAwMDAwMDAwMDAwMDAwMDEgKDEpCjAwOjAwOjAyLjE4NyAgIE51bUNQVXMgPGludGVnZXI+ID0g MHgwMDAwMDAwMDAwMDAwMDAxICgxKQowMDowMDowMi4xODcgCjAwOjAwOjAyLjE4NyBbL0Rldmlj ZXMvaW9hcGljL10gKGxldmVsIDIpCjAwOjAwOjAyLjE4NyAKMDA6MDA6MDIuMTg3IFsvRGV2aWNl cy9pb2FwaWMvMC9dIChsZXZlbCAzKQowMDowMDowMi4xODcgICBUcnVzdGVkIDxpbnRlZ2VyPiA9 IDB4MDAwMDAwMDAwMDAwMDAwMSAoMSkKMDA6MDA6MDIuMTg3IAowMDowMDowMi4xODcgWy9EZXZp Y2VzL2lvYXBpYy8wL0NvbmZpZy9dIChsZXZlbCA0KQowMDowMDowMi4xODcgCjAwOjAwOjAyLjE4 NyBbL0RldmljZXMvbWMxNDY4MTgvXSAobGV2ZWwgMikKMDA6MDA6MDIuMTg3IAowMDowMDowMi4x ODcgWy9EZXZpY2VzL21jMTQ2ODE4LzAvXSAobGV2ZWwgMykKMDA6MDA6MDIuMTg3IAowMDowMDow Mi4xODcgWy9EZXZpY2VzL21jMTQ2ODE4LzAvQ29uZmlnL10gKGxldmVsIDQpCjAwOjAwOjAyLjE4 NyAKMDA6MDA6MDIuMTg3IFsvRGV2aWNlcy92Z2EvXSAobGV2ZWwgMikKMDA6MDA6MDIuMTg3IAow MDowMDowMi4xODcgWy9EZXZpY2VzL3ZnYS8wL10gKGxldmVsIDMpCjAwOjAwOjAyLjE4NyAgIFRy dXN0ZWQgICAgICAgPGludGVnZXI+ID0gMHgwMDAwMDAwMDAwMDAwMDAxICgxKQowMDowMDowMi4x ODcgICBQQ0lEZXZpY2VObyAgIDxpbnRlZ2VyPiA9IDB4MDAwMDAwMDAwMDAwMDAwMiAoMikKMDA6 MDA6MDIuMTg3ICAgUENJRnVuY3Rpb25ObyA8aW50ZWdlcj4gPSAweDAwMDAwMDAwMDAwMDAwMDAg KDApCjAwOjAwOjAyLjE4NyAKMDA6MDA6MDIuMTg3IFsvRGV2aWNlcy92Z2EvMC9Db25maWcvXSAo bGV2ZWwgNCkKMDA6MDA6MDIuMTg3ICAgVlJhbVNpemUgICAgICAgICA8aW50ZWdlcj4gPSAweDAw MDAwMDAwMDA1MDAwMDAgKDUyNDI4ODApCjAwOjAwOjAyLjE4NyAgIFIwRW5hYmxlZCAgICAgICAg PGludGVnZXI+ID0gMHgwMDAwMDAwMDAwMDAwMDAxICgxKQowMDowMDowMi4xODcgICBGYWRlSW4g ICAgICAgICAgIDxpbnRlZ2VyPiA9IDB4MDAwMDAwMDAwMDAwMDAwMSAoMSkKMDA6MDA6MDIuMTg3 ICAgRmFkZU91dCAgICAgICAgICA8aW50ZWdlcj4gPSAweDAwMDAwMDAwMDAwMDAwMDEgKDEpCjAw OjAwOjAyLjE4NyAgIExvZ29UaW1lICAgICAgICAgPGludGVnZXI+ID0gMHgwMDAwMDAwMDAwMDAw MDAwICgwKQowMDowMDowMi4xODcgICBMb2dvRmlsZSAgICAgICAgIDxzdHJpbmc+ICA9ICIiIChj Y2g9MSkKMDA6MDA6MDIuMTg3ICAgU2hvd0Jvb3RNZW51ICAgICA8aW50ZWdlcj4gPSAweDAwMDAw MDAwMDAwMDAwMDIgKDIpCjAwOjAwOjAyLjE4NyAgIEN1c3RvbVZpZGVvTW9kZXMgPGludGVnZXI+ ID0gMHgwMDAwMDAwMDAwMDAwMDAwICgwKQowMDowMDowMi4xODcgICBIZWlnaHRSZWR1Y3Rpb24g IDxpbnRlZ2VyPiA9IDB4MDAwMDAwMDAwMDAwMDAwMCAoMCkKMDA6MDA6MDIuMTg3IAowMDowMDow Mi4xODcgWy9EZXZpY2VzL3ZnYS8wL0xVTiMwL10gKGxldmVsIDQpCjAwOjAwOjAyLjE4NyAgIERy aXZlciA8c3RyaW5nPiAgPSAiTWFpbkRpc3BsYXkiIChjY2g9MTIpCjAwOjAwOjAyLjE4NyAKMDA6 MDA6MDIuMTg3IFsvRGV2aWNlcy92Z2EvMC9MVU4jMC9Db25maWcvXSAobGV2ZWwgNSkKMDA6MDA6 MDIuMTg3ICAgT2JqZWN0IDxpbnRlZ2VyPiA9IDB4MDAwMDAwMDAwMDg4YWEwMCAoODk1NjQxNikK MDA6MDA6MDIuMTg3IAowMDowMDowMi4xODcgWy9EZXZpY2VzL3BpaXgzaWRlL10gKGxldmVsIDIp CjAwOjAwOjAyLjE4NyAKMDA6MDA6MDIuMTg3IFsvRGV2aWNlcy9waWl4M2lkZS8wL10gKGxldmVs IDMpCjAwOjAwOjAyLjE4NyAgIFRydXN0ZWQgICAgICAgPGludGVnZXI+ID0gMHgwMDAwMDAwMDAw MDAwMDAxICgxKQowMDowMDowMi4xODcgICBQQ0lEZXZpY2VObyAgIDxpbnRlZ2VyPiA9IDB4MDAw MDAwMDAwMDAwMDAwMSAoMSkKMDA6MDA6MDIuMTg3ICAgUENJRnVuY3Rpb25ObyA8aW50ZWdlcj4g PSAweDAwMDAwMDAwMDAwMDAwMDEgKDEpCjAwOjAwOjAyLjE4NyAKMDA6MDA6MDIuMTg3IFsvRGV2 aWNlcy9waWl4M2lkZS8wL0NvbmZpZy9dIChsZXZlbCA0KQowMDowMDowMi4xODcgICBUeXBlIDxz dHJpbmc+ICA9ICJQSUlYNCIgKGNjaD02KQowMDowMDowMi4xODcgCjAwOjAwOjAyLjE4NyBbL0Rl dmljZXMvcGlpeDNpZGUvMC9MVU4jOTk5L10gKGxldmVsIDQpCjAwOjAwOjAyLjE4NyAgIERyaXZl ciA8c3RyaW5nPiAgPSAiTWFpblN0YXR1cyIgKGNjaD0xMSkKMDA6MDA6MDIuMTg3IAowMDowMDow Mi4xODcgWy9EZXZpY2VzL3BpaXgzaWRlLzAvTFVOIzk5OS9Db25maWcvXSAobGV2ZWwgNSkKMDA6 MDA6MDIuMTg3ICAgcGFwTGVkcyA8aW50ZWdlcj4gPSAweDAwMDAwMDAwMDI4NDFjZWMgKDQyMjEy NTg4KQowMDowMDowMi4xODcgICBGaXJzdCAgIDxpbnRlZ2VyPiA9IDB4MDAwMDAwMDAwMDAwMDAw MCAoMCkKMDA6MDA6MDIuMTg3ICAgTGFzdCAgICA8aW50ZWdlcj4gPSAweDAwMDAwMDAwMDAwMDAw MDMgKDMpCjAwOjAwOjAyLjE4NyAKMDA6MDA6MDIuMTg3IFsvRGV2aWNlcy9waWl4M2lkZS8wL0xV TiMyL10gKGxldmVsIDQpCjAwOjAwOjAyLjE4OCAgIERyaXZlciA8c3RyaW5nPiAgPSAiQmxvY2si IChjY2g9NikKMDA6MDA6MDIuMTg4IAowMDowMDowMi4xODggWy9EZXZpY2VzL3BpaXgzaWRlLzAv TFVOIzIvQ29uZmlnL10gKGxldmVsIDUpCjAwOjAwOjAyLjE4OCAgIFR5cGUgICAgICA8c3RyaW5n PiAgPSAiRFZEIiAoY2NoPTQpCjAwOjAwOjAyLjE4OCAgIE1vdW50YWJsZSA8aW50ZWdlcj4gPSAw eDAwMDAwMDAwMDAwMDAwMDEgKDEpCjAwOjAwOjAyLjE4OCAKMDA6MDA6MDIuMTg4IFsvRGV2aWNl cy9waWl4M2lkZS8wL0xVTiMwL10gKGxldmVsIDQpCjAwOjAwOjAyLjE4OCAgIERyaXZlciA8c3Ry aW5nPiAgPSAiQmxvY2siIChjY2g9NikKMDA6MDA6MDIuMTg4IAowMDowMDowMi4xODggWy9EZXZp Y2VzL3BpaXgzaWRlLzAvTFVOIzAvQ29uZmlnL10gKGxldmVsIDUpCjAwOjAwOjAyLjE4OCAgIFR5 cGUgICAgICA8c3RyaW5nPiAgPSAiSGFyZERpc2siIChjY2g9OSkKMDA6MDA6MDIuMTg4ICAgTW91 bnRhYmxlIDxpbnRlZ2VyPiA9IDB4MDAwMDAwMDAwMDAwMDAwMCAoMCkKMDA6MDA6MDIuMTg4IAow MDowMDowMi4xODggWy9EZXZpY2VzL3BpaXgzaWRlLzAvTFVOIzAvQXR0YWNoZWREcml2ZXIvXSAo bGV2ZWwgNSkKMDA6MDA6MDIuMTg4ICAgRHJpdmVyIDxzdHJpbmc+ICA9ICJWRCIgKGNjaD0zKQow MDowMDowMi4xODggCjAwOjAwOjAyLjE4OCBbL0RldmljZXMvcGlpeDNpZGUvMC9MVU4jMC9BdHRh Y2hlZERyaXZlci9Db25maWcvXSAobGV2ZWwgNikKMDA6MDA6MDIuMTg4ICAgUGF0aCAgIDxzdHJp bmc+ICA9ICIvVXNlcnMvbWF0dGhpYXMvTGlicmFyeS9WaXJ0dWFsQm94L01hY2hpbmVzL0ZyZWVC U0Qga2xlaW4vU25hcHNob3RzL3tlZTk3ZjBlZi05NjI1LTQyMWYtOWI3Yy1mOWRkYThkNGM3NjJ9 LnZkaSIgKGNjaD0xMTEpCjAwOjAwOjAyLjE4OCAgIEZvcm1hdCA8c3RyaW5nPiAgPSAiVkRJIiAo Y2NoPTQpCjAwOjAwOjAyLjE4OCAKMDA6MDA6MDIuMTg4IFsvRGV2aWNlcy9waWl4M2lkZS8wL0xV TiMwL0F0dGFjaGVkRHJpdmVyL0NvbmZpZy9QYXJlbnQvXSAobGV2ZWwgNykKMDA6MDA6MDIuMTg4 ICAgUGF0aCAgIDxzdHJpbmc+ICA9ICIvVXNlcnMvbWF0dGhpYXMvTGlicmFyeS9WaXJ0dWFsQm94 L01hY2hpbmVzL0ZyZWVCU0Qga2xlaW4vU25hcHNob3RzL3tkOTcyMTJkMi0wMTliLTQ0NTgtODkz OS0yNTY4ZWY3MzZjMmZ9LnZkaSIgKGNjaD0xMTEpCjAwOjAwOjAyLjE4OCAgIEZvcm1hdCA8c3Ry aW5nPiAgPSAiVkRJIiAoY2NoPTQpCjAwOjAwOjAyLjE4OCAKMDA6MDA6MDIuMTg4IFsvRGV2aWNl cy9waWl4M2lkZS8wL0xVTiMwL0F0dGFjaGVkRHJpdmVyL0NvbmZpZy9QYXJlbnQvUGFyZW50L10g KGxldmVsIDgpCjAwOjAwOjAyLjE4OCAgIFBhdGggICA8c3RyaW5nPiAgPSAiL1VzZXJzL21hdHRo aWFzL0xpYnJhcnkvVmlydHVhbEJveC9IYXJkRGlza3MvRnJlZUJTRCBrbGVpbi52ZGkiIChjY2g9 NjMpCjAwOjAwOjAyLjE4OCAgIEZvcm1hdCA8c3RyaW5nPiAgPSAiVkRJIiAoY2NoPTQpCjAwOjAw OjAyLjE4OCAKMDA6MDA6MDIuMTg4IFsvRGV2aWNlcy9wY25ldC9dIChsZXZlbCAyKQowMDowMDow Mi4xODggCjAwOjAwOjAyLjE4OCBbL0RldmljZXMvZTEwMDAvXSAobGV2ZWwgMikKMDA6MDA6MDIu MTg4IAowMDowMDowMi4xODggWy9EZXZpY2VzL2UxMDAwLzAvXSAobGV2ZWwgMykKMDA6MDA6MDIu MTg4ICAgVHJ1c3RlZCAgICAgICA8aW50ZWdlcj4gPSAweDAwMDAwMDAwMDAwMDAwMDEgKDEpCjAw OjAwOjAyLjE4OCAgIFBDSURldmljZU5vICAgPGludGVnZXI+ID0gMHgwMDAwMDAwMDAwMDAwMDAz ICgzKQowMDowMDowMi4xODggICBQQ0lGdW5jdGlvbk5vIDxpbnRlZ2VyPiA9IDB4MDAwMDAwMDAw MDAwMDAwMCAoMCkKMDA6MDA6MDIuMTg4IAowMDowMDowMi4xODggWy9EZXZpY2VzL2UxMDAwLzAv Q29uZmlnL10gKGxldmVsIDQpCjAwOjAwOjAyLjE4OCAgIEFkYXB0ZXJUeXBlICAgIDxpbnRlZ2Vy PiA9IDB4MDAwMDAwMDAwMDAwMDAwMCAoMCkKMDA6MDA6MDIuMTg4ICAgTUFDICAgICAgICAgICAg PGJ5dGVzPiAgID0gIjA4IDAwIDI3IGJlIGVlIGNhIiAoY2I9NikKMDA6MDA6MDIuMTg4ICAgQ2Fi bGVDb25uZWN0ZWQgPGludGVnZXI+ID0gMHgwMDAwMDAwMDAwMDAwMDAxICgxKQowMDowMDowMi4x ODggICBMaW5lU3BlZWQgICAgICA8aW50ZWdlcj4gPSAweDAwMDAwMDAwMDAwMDAwMDAgKDApCjAw OjAwOjAyLjE4OCAKMDA6MDA6MDIuMTg4IFsvRGV2aWNlcy9lMTAwMC8wL0xVTiM5OTkvXSAobGV2 ZWwgNCkKMDA6MDA6MDIuMTg4ICAgRHJpdmVyIDxzdHJpbmc+ICA9ICJNYWluU3RhdHVzIiAoY2No PTExKQowMDowMDowMi4xODggCjAwOjAwOjAyLjE4OCBbL0RldmljZXMvZTEwMDAvMC9MVU4jOTk5 L0NvbmZpZy9dIChsZXZlbCA1KQowMDowMDowMi4xODggICBwYXBMZWRzIDxpbnRlZ2VyPiA9IDB4 MDAwMDAwMDAwMjg0MWRiNCAoNDIyMTI3ODgpCjAwOjAwOjAyLjE4OCAKMDA6MDA6MDIuMTg4IFsv RGV2aWNlcy9lMTAwMC8wL0xVTiMwL10gKGxldmVsIDQpCjAwOjAwOjAyLjE4OCAgIERyaXZlciA8 c3RyaW5nPiAgPSAiSW50TmV0IiAoY2NoPTcpCjAwOjAwOjAyLjE4OCAKMDA6MDA6MDIuMTg4IFsv RGV2aWNlcy9lMTAwMC8wL0xVTiMwL0NvbmZpZy9dIChsZXZlbCA1KQowMDowMDowMi4xODggICBU cnVuayAgICAgPHN0cmluZz4gID0gImVuMCIgKGNjaD00KQowMDowMDowMi4xODggICBUcnVua1R5 cGUgPGludGVnZXI+ID0gMHgwMDAwMDAwMDAwMDAwMDAzICgzKQowMDowMDowMi4xODggICBOZXR3 b3JrICAgPHN0cmluZz4gID0gIkhvc3RJbnRlcmZhY2VOZXR3b3JraW5nLWVuMDogRXRoZXJuZXQi IChjY2g9MzgpCjAwOjAwOjAyLjE4OCAKMDA6MDA6MDIuMTg5IFsvRGV2aWNlcy9zZXJpYWwvXSAo bGV2ZWwgMikKMDA6MDA6MDIuMTg5IAowMDowMDowMi4xODkgWy9EZXZpY2VzL3BhcmFsbGVsL10g KGxldmVsIDIpCjAwOjAwOjAyLjE4OSAKMDA6MDA6MDIuMTg5IFsvRGV2aWNlcy9WTU1EZXYvXSAo bGV2ZWwgMikKMDA6MDA6MDIuMTg5IAowMDowMDowMi4xODkgWy9EZXZpY2VzL1ZNTURldi8wL10g KGxldmVsIDMpCjAwOjAwOjAyLjE4OSAgIFRydXN0ZWQgICAgICAgPGludGVnZXI+ID0gMHgwMDAw MDAwMDAwMDAwMDAxICgxKQowMDowMDowMi4xODkgICBQQ0lEZXZpY2VObyAgIDxpbnRlZ2VyPiA9 IDB4MDAwMDAwMDAwMDAwMDAwNCAoNCkKMDA6MDA6MDIuMTg5ICAgUENJRnVuY3Rpb25ObyA8aW50 ZWdlcj4gPSAweDAwMDAwMDAwMDAwMDAwMDAgKDApCjAwOjAwOjAyLjE4OSAKMDA6MDA6MDIuMTg5 IFsvRGV2aWNlcy9WTU1EZXYvMC9Db25maWcvXSAobGV2ZWwgNCkKMDA6MDA6MDIuMTg5IAowMDow MDowMi4xODkgWy9EZXZpY2VzL1ZNTURldi8wL0xVTiMwL10gKGxldmVsIDQpCjAwOjAwOjAyLjE4 OSAgIERyaXZlciA8c3RyaW5nPiAgPSAiTWFpblZNTURldiIgKGNjaD0xMSkKMDA6MDA6MDIuMTg5 IAowMDowMDowMi4xODkgWy9EZXZpY2VzL1ZNTURldi8wL0xVTiMwL0NvbmZpZy9dIChsZXZlbCA1 KQowMDowMDowMi4xODkgICBPYmplY3QgPGludGVnZXI+ID0gMHgwMDAwMDAwMDAwMTRkMGYwICgx MzY0MjA4KQowMDowMDowMi4xODkgCjAwOjAwOjAyLjE4OSBbL0RldmljZXMvVk1NRGV2LzAvTFVO Izk5OS9dIChsZXZlbCA0KQowMDowMDowMi4xODkgICBEcml2ZXIgPHN0cmluZz4gID0gIk1haW5T dGF0dXMiIChjY2g9MTEpCjAwOjAwOjAyLjE4OSAKMDA6MDA6MDIuMTg5IFsvRGV2aWNlcy9WTU1E ZXYvMC9MVU4jOTk5L0NvbmZpZy9dIChsZXZlbCA1KQowMDowMDowMi4xODkgICBwYXBMZWRzIDxp bnRlZ2VyPiA9IDB4MDAwMDAwMDAwMjg0MWRkNCAoNDIyMTI4MjApCjAwOjAwOjAyLjE4OSAgIEZp cnN0ICAgPGludGVnZXI+ID0gMHgwMDAwMDAwMDAwMDAwMDAwICgwKQowMDowMDowMi4xODkgICBM YXN0ICAgIDxpbnRlZ2VyPiA9IDB4MDAwMDAwMDAwMDAwMDAwMCAoMCkKMDA6MDA6MDIuMTg5IAow MDowMDowMi4xODkgWy9EZXZpY2VzL0F1ZGlvU25pZmZlci9dIChsZXZlbCAyKQowMDowMDowMi4x ODkgCjAwOjAwOjAyLjE4OSBbL0RldmljZXMvQXVkaW9TbmlmZmVyLzAvXSAobGV2ZWwgMykKMDA6 MDA6MDIuMTg5IAowMDowMDowMi4xODkgWy9EZXZpY2VzL0F1ZGlvU25pZmZlci8wL0NvbmZpZy9d IChsZXZlbCA0KQowMDowMDowMi4xODkgCjAwOjAwOjAyLjE4OSBbL0RldmljZXMvQXVkaW9Tbmlm ZmVyLzAvTFVOIzAvXSAobGV2ZWwgNCkKMDA6MDA6MDIuMTg5ICAgRHJpdmVyIDxzdHJpbmc+ICA9 ICJNYWluQXVkaW9TbmlmZmVyIiAoY2NoPTE3KQowMDowMDowMi4xODkgCjAwOjAwOjAyLjE4OSBb L0RldmljZXMvQXVkaW9TbmlmZmVyLzAvTFVOIzAvQ29uZmlnL10gKGxldmVsIDUpCjAwOjAwOjAy LjE4OSAgIE9iamVjdCA8aW50ZWdlcj4gPSAweDAwMDAwMDAwMDAxNGM0YTAgKDEzNjEwNTYpCjAw OjAwOjAyLjE4OSAKMDA6MDA6MDIuMTg5IFsvRGV2aWNlcy9pY2hhYzk3L10gKGxldmVsIDIpCjAw OjAwOjAyLjE4OSAKMDA6MDA6MDIuMTg5IFsvRGV2aWNlcy9pY2hhYzk3LzAvXSAobGV2ZWwgMykK MDA6MDA6MDIuMTg5ICAgVHJ1c3RlZCAgICAgICA8aW50ZWdlcj4gPSAweDAwMDAwMDAwMDAwMDAw MDEgKDEpCjAwOjAwOjAyLjE4OSAgIFBDSURldmljZU5vICAgPGludGVnZXI+ID0gMHgwMDAwMDAw MDAwMDAwMDA1ICg1KQowMDowMDowMi4xODkgICBQQ0lGdW5jdGlvbk5vIDxpbnRlZ2VyPiA9IDB4 MDAwMDAwMDAwMDAwMDAwMCAoMCkKMDA6MDA6MDIuMTg5IAowMDowMDowMi4xODkgWy9EZXZpY2Vz L2ljaGFjOTcvMC9Db25maWcvXSAobGV2ZWwgNCkKMDA6MDA6MDIuMTg5IAowMDowMDowMi4xODkg Wy9EZXZpY2VzL2ljaGFjOTcvMC9MVU4jMC9dIChsZXZlbCA0KQowMDowMDowMi4xOTAgICBEcml2 ZXIgPHN0cmluZz4gID0gIkFVRElPIiAoY2NoPTYpCjAwOjAwOjAyLjE5MCAKMDA6MDA6MDIuMTkw IFsvRGV2aWNlcy9pY2hhYzk3LzAvTFVOIzAvQ29uZmlnL10gKGxldmVsIDUpCjAwOjAwOjAyLjE5 MCAgIEF1ZGlvRHJpdmVyIDxzdHJpbmc+ICA9ICJjb3JlYXVkaW8iIChjY2g9MTApCjAwOjAwOjAy LjE5MCAgIFN0cmVhbU5hbWUgIDxzdHJpbmc+ICA9ICJGcmVlQlNEIGtsZWluIiAoY2NoPTE0KQow MDowMDowMi4xOTAgCjAwOjAwOjAyLjE5MCBbL0RldmljZXMvdXNiLW9oY2kvXSAobGV2ZWwgMikK MDA6MDA6MDIuMTkwIAowMDowMDowMi4xOTAgWy9EZXZpY2VzL3VzYi1vaGNpLzAvXSAobGV2ZWwg MykKMDA6MDA6MDIuMTkwICAgVHJ1c3RlZCAgICAgICA8aW50ZWdlcj4gPSAweDAwMDAwMDAwMDAw MDAwMDEgKDEpCjAwOjAwOjAyLjE5MCAgIFBDSURldmljZU5vICAgPGludGVnZXI+ID0gMHgwMDAw MDAwMDAwMDAwMDA2ICg2KQowMDowMDowMi4xOTAgICBQQ0lGdW5jdGlvbk5vIDxpbnRlZ2VyPiA9 IDB4MDAwMDAwMDAwMDAwMDAwMCAoMCkKMDA6MDA6MDIuMTkwIAowMDowMDowMi4xOTAgWy9EZXZp Y2VzL3VzYi1vaGNpLzAvQ29uZmlnL10gKGxldmVsIDQpCjAwOjAwOjAyLjE5MCAKMDA6MDA6MDIu MTkwIFsvRGV2aWNlcy91c2Itb2hjaS8wL0xVTiMwL10gKGxldmVsIDQpCjAwOjAwOjAyLjE5MCAg IERyaXZlciA8c3RyaW5nPiAgPSAiVlVTQlJvb3RIdWIiIChjY2g9MTIpCjAwOjAwOjAyLjE5MCAK MDA6MDA6MDIuMTkwIFsvRGV2aWNlcy91c2Itb2hjaS8wL0xVTiMwL0NvbmZpZy9dIChsZXZlbCA1 KQowMDowMDowMi4xOTAgCjAwOjAwOjAyLjE5MCBbL0RldmljZXMvdXNiLW9oY2kvMC9MVU4jOTk5 L10gKGxldmVsIDQpCjAwOjAwOjAyLjE5MCAgIERyaXZlciA8c3RyaW5nPiAgPSAiTWFpblN0YXR1 cyIgKGNjaD0xMSkKMDA6MDA6MDIuMTkwIAowMDowMDowMi4xOTAgWy9EZXZpY2VzL3VzYi1vaGNp LzAvTFVOIzk5OS9Db25maWcvXSAobGV2ZWwgNSkKMDA6MDA6MDIuMTkwICAgcGFwTGVkcyA8aW50 ZWdlcj4gPSAweDAwMDAwMDAwMDI4NDFkZDggKDQyMjEyODI0KQowMDowMDowMi4xOTAgICBGaXJz dCAgIDxpbnRlZ2VyPiA9IDB4MDAwMDAwMDAwMDAwMDAwMCAoMCkKMDA6MDA6MDIuMTkwICAgTGFz dCAgICA8aW50ZWdlcj4gPSAweDAwMDAwMDAwMDAwMDAwMDAgKDApCjAwOjAwOjAyLjE5MCAKMDA6 MDA6MDIuMTkwIFsvRGV2aWNlcy91c2ItZWhjaS9dIChsZXZlbCAyKQowMDowMDowMi4xOTAgCjAw OjAwOjAyLjE5MCBbL0RldmljZXMvdXNiLWVoY2kvMC9dIChsZXZlbCAzKQowMDowMDowMi4xOTAg ICBUcnVzdGVkICAgICAgIDxpbnRlZ2VyPiA9IDB4MDAwMDAwMDAwMDAwMDAwMSAoMSkKMDA6MDA6 MDIuMTkwICAgUENJRGV2aWNlTm8gICA8aW50ZWdlcj4gPSAweDAwMDAwMDAwMDAwMDAwMGIgKDEx KQowMDowMDowMi4xOTAgICBQQ0lGdW5jdGlvbk5vIDxpbnRlZ2VyPiA9IDB4MDAwMDAwMDAwMDAw MDAwMCAoMCkKMDA6MDA6MDIuMTkwIAowMDowMDowMi4xOTAgWy9EZXZpY2VzL3VzYi1laGNpLzAv Q29uZmlnL10gKGxldmVsIDQpCjAwOjAwOjAyLjE5MCAKMDA6MDA6MDIuMTkwIFsvRGV2aWNlcy91 c2ItZWhjaS8wL0xVTiMwL10gKGxldmVsIDQpCjAwOjAwOjAyLjE5MCAgIERyaXZlciA8c3RyaW5n PiAgPSAiVlVTQlJvb3RIdWIiIChjY2g9MTIpCjAwOjAwOjAyLjE5MCAKMDA6MDA6MDIuMTkwIFsv RGV2aWNlcy91c2ItZWhjaS8wL0xVTiMwL0NvbmZpZy9dIChsZXZlbCA1KQowMDowMDowMi4xOTAg CjAwOjAwOjAyLjE5MCBbL0RldmljZXMvdXNiLWVoY2kvMC9MVU4jOTk5L10gKGxldmVsIDQpCjAw OjAwOjAyLjE5MCAgIERyaXZlciA8c3RyaW5nPiAgPSAiTWFpblN0YXR1cyIgKGNjaD0xMSkKMDA6 MDA6MDIuMTkwIAowMDowMDowMi4xOTAgWy9EZXZpY2VzL3VzYi1laGNpLzAvTFVOIzk5OS9Db25m aWcvXSAobGV2ZWwgNSkKMDA6MDA6MDIuMTkxICAgcGFwTGVkcyA8aW50ZWdlcj4gPSAweDAwMDAw MDAwMDI4NDFkZGMgKDQyMjEyODI4KQowMDowMDowMi4xOTEgICBGaXJzdCAgIDxpbnRlZ2VyPiA9 IDB4MDAwMDAwMDAwMDAwMDAwMCAoMCkKMDA6MDA6MDIuMTkxICAgTGFzdCAgICA8aW50ZWdlcj4g PSAweDAwMDAwMDAwMDAwMDAwMDAgKDApCjAwOjAwOjAyLjE5MSAKMDA6MDA6MDIuMTkxIFsvVE0v XSAobGV2ZWwgMSkKMDA6MDA6MDIuMTkxICAgVVRDT2Zmc2V0IDxpbnRlZ2VyPiA9IDB4MDAwMDAw MDAwMDAwMDAwMCAoMCkKMDA6MDA6MDIuMTkxIAowMDowMDowMi4xOTEgKioqKioqKioqKioqKioq KioqKioqIEVuZCBvZiBDRkdNIGR1bXAgKioqKioqKioqKioqKioqKioqKioqKgowMDowMDowMi4x OTEgTU06IGNiSHlwZXJIZWFwPTB4YTAwMDAgKDY1NTM2MCkKMDA6MDA6MDIuMjI4IExvZ2ljYWwg aG9zdCBwcm9jZXNzb3JzOiAyLCBwcm9jZXNzb3IgYWN0aXZlIG1hc2s6IDAwMDAwMDAwMDAwMDAw MDMKMDA6MDA6MDIuMjI4ICoqKioqKioqKioqKioqKioqKioqKioqKiogQ1BVSUQgZHVtcCAqKioq KioqKioqKioqKioqKioqKioqKioKMDA6MDA6MDIuMjI4ICAgICAgICAgIFJBVyBTdGFuZGFyZCBD UFVJRHMKMDA6MDA6MDIuMjI4ICAgICAgRnVuY3Rpb24gIGVheCAgICAgIGVieCAgICAgIGVjeCAg ICAgIGVkeAowMDowMDowMi4yMjggR3N0OiAwMDAwMDAwMCAgMDAwMDAwMDUgNzU2ZTY1NDcgNmM2 NTc0NmUgNDk2NTZlNjkKMDA6MDA6MDIuMjI4IEhzdDogICAgICAgICAgIDAwMDAwMDBhIDc1NmU2 NTQ3IDZjNjU3NDZlIDQ5NjU2ZTY5CjAwOjAwOjAyLjIyOCBHc3Q6IDAwMDAwMDAxICAwMDAwMDZm NiAwMDAwMDgwMCAwMDAwMDAwOSAwNzhiZjFiZgowMDowMDowMi4yMjggSHN0OiAgICAgICAgICAg MDAwMDA2ZjYgMDEwMjA4MDAgMDAwMGUzYmQgYmZlYmZiZmYKMDA6MDA6MDIuMjI4IEdzdDogMDAw MDAwMDIgIDA1YjBiMTAxIDAwNTY1N2YwIDAwMDAwMDAwIDJjYjQzMDQ5CjAwOjAwOjAyLjIyOCBI c3Q6ICAgICAgICAgICAwNWIwYjEwMSAwMDU2NTdmMCAwMDAwMDAwMCAyY2I0MzA0OQowMDowMDow Mi4yMjggR3N0OiAwMDAwMDAwMyAgMDAwMDAwMDAgMDAwMDAwMDAgMDAwMDAwMDAgMDAwMDAwMDAK MDA6MDA6MDIuMjI4IEhzdDogICAgICAgICAgIDAwMDAwMDAwIDAwMDAwMDAwIDAwMDAwMDAwIDAw MDAwMDAwCjAwOjAwOjAyLjIyOCBHc3Q6IDAwMDAwMDA0ICAwMDAwMDAwMCAwMDAwMDAwMCAwMDAw MDAwMCAwMDAwMDAwMAowMDowMDowMi4yMjggSHN0OiAgICAgICAgICAgMDQwMDAxMjEgMDFjMDAw M2YgMDAwMDAwM2YgMDAwMDAwMDEKMDA6MDA6MDIuMjI4IEdzdDogMDAwMDAwMDUgIDAwMDAwMDQw IDAwMDAwMDQwIDAwMDAwMDAwIDAwMDAwMDAwCjAwOjAwOjAyLjIyOCBIc3Q6ICAgICAgICAgICAw MDAwMDA0MCAwMDAwMDA0MCAwMDAwMDAwMyAwMDAyMjIyMAowMDowMDowMi4yMjggTmFtZTogICAg ICAgICAgICAgICAgICAgICAgICAgICAgR2VudWluZUludGVsCjAwOjAwOjAyLjIyOCBTdXBwb3J0 czogICAgICAgICAgICAgICAgICAgICAgICAwLTUKMDA6MDA6MDIuMjI4IEZhbWlseTogICAgICAg ICAgICAgICAgICAgICAgICAgIDYgIAlFeHRlbmRlZDogMCAJRWZmZWN0aXZlOiA2CjAwOjAwOjAy LjIyOCBNb2RlbDogICAgICAgICAgICAgICAgICAgICAgICAgICAxNSAgCUV4dGVuZGVkOiAwIAlF ZmZlY3RpdmU6IDE1CjAwOjAwOjAyLjIyOCBTdGVwcGluZzogICAgICAgICAgICAgICAgICAgICAg ICA2CjAwOjAwOjAyLjIyOCBBUElDIElEOiAgICAgICAgICAgICAgICAgICAgICAgICAweDAwCjAw OjAwOjAyLjIyOCBMb2dpY2FsIENQVXM6ICAgICAgICAgICAgICAgICAgICAwCjAwOjAwOjAyLjIy OCBDTEZMVVNIIFNpemU6ICAgICAgICAgICAgICAgICAgICA4CjAwOjAwOjAyLjIyOCBCcmFuZCBJ RDogICAgICAgICAgICAgICAgICAgICAgICAweDAwCjAwOjAwOjAyLjIyOCBNbmVtb25pYyAtIERl c2NyaXB0aW9uICAgICAgICAgICAgICAgICA9IGd1ZXN0IChob3N0KQowMDowMDowMi4yMjggRlBV IC0geDg3IEZQVSBvbiBDaGlwICAgICAgICAgICAgICAgICAgPSAxICgxKQowMDowMDowMi4yMjgg Vk1FIC0gVmlydHVhbCA4MDg2IE1vZGUgRW5oYW5jZW1lbnRzICAgPSAxICgxKQowMDowMDowMi4y MjggREUgLSBEZWJ1Z2dpbmcgZXh0ZW5zaW9ucyAgICAgICAgICAgICAgPSAxICgxKQowMDowMDow Mi4yMjggUFNFIC0gUGFnZSBTaXplIEV4dGVuc2lvbiAgICAgICAgICAgICAgPSAxICgxKQowMDow MDowMi4yMjggVFNDIC0gVGltZSBTdGFtcCBDb3VudGVyICAgICAgICAgICAgICAgPSAxICgxKQow MDowMDowMi4yMjggTVNSIC0gTW9kZWwgU3BlY2lmaWMgUmVnaXN0ZXJzICAgICAgICAgPSAxICgx KQowMDowMDowMi4yMjkgUEFFIC0gUGh5c2ljYWwgQWRkcmVzcyBFeHRlbnNpb24gICAgICAgPSAw ICgxKQowMDowMDowMi4yMjkgTUNFIC0gTWFjaGluZSBDaGVjayBFeGNlcHRpb24gICAgICAgICAg PSAxICgxKQowMDowMDowMi4yMjkgQ1g4IC0gQ01QWENIRzhCIGluc3RydWN0aW9uICAgICAgICAg ICAgPSAxICgxKQowMDowMDowMi4yMjkgQVBJQyAtIEFQSUMgT24tQ2hpcCAgICAgICAgICAgICAg ICAgICAgPSAwICgxKQowMDowMDowMi4yMjkgUmVzZXJ2ZWQgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgPSAwICgwKQowMDowMDowMi4yMjkgU0VQIC0gU1lTRU5URVIgYW5kIFNZU0VYSVQg ICAgICAgICAgICAgPSAwICgxKQowMDowMDowMi4yMjkgTVRSUiAtIE1lbW9yeSBUeXBlIFJhbmdl IFJlZ2lzdGVycyAgICAgPSAxICgxKQowMDowMDowMi4yMjkgUEdFIC0gUFRFIEdsb2JhbCBCaXQg ICAgICAgICAgICAgICAgICAgPSAxICgxKQowMDowMDowMi4yMjkgTUNBIC0gTWFjaGluZSBDaGVj ayBBcmNoaXRlY3R1cmUgICAgICAgPSAxICgxKQowMDowMDowMi4yMjkgQ01PViAtIENvbmRpdGlv bmFsIE1vdmUgSW5zdHJ1Y3Rpb25zICAgPSAxICgxKQowMDowMDowMi4yMjkgUEFUIC0gUGFnZSBB dHRyaWJ1dGUgVGFibGUgICAgICAgICAgICAgPSAxICgxKQowMDowMDowMi4yMjkgUFNFLTM2IC0g MzYtYml0IFBhZ2UgU2l6ZSBFeHRlbnRpb24gICAgPSAxICgxKQowMDowMDowMi4yMjkgUFNOIC0g UHJvY2Vzc29yIFNlcmlhbCBOdW1iZXIgICAgICAgICAgPSAwICgwKQowMDowMDowMi4yMjkgQ0xG U0ggLSBDTEZMVVNIIEluc3RydWN0aW9uLiAgICAgICAgICAgPSAxICgxKQowMDowMDowMi4yMjkg UmVzZXJ2ZWQgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgPSAwICgwKQowMDowMDowMi4y MjkgRFMgLSBEZWJ1ZyBTdG9yZSAgICAgICAgICAgICAgICAgICAgICAgPSAwICgxKQowMDowMDow Mi4yMjkgQUNQSSAtIFRoZXJtYWwgTW9uLiAmIFNvZnQuIENsb2NrIEN0cmwuPSAwICgxKQowMDow MDowMi4yMjkgTU1YIC0gSW50ZWwgTU1YIFRlY2hub2xvZ3kgICAgICAgICAgICAgPSAxICgxKQow MDowMDowMi4yMjkgRlhTUiAtIEZYU0FWRSBhbmQgRlhSU1RPUiBJbnN0cnVjdGlvbnMgPSAxICgx KQowMDowMDowMi4yMjkgU1NFIC0gU1NFIFN1cHBvcnQgICAgICAgICAgICAgICAgICAgICAgPSAx ICgxKQowMDowMDowMi4yMjkgU1NFMiAtIFNTRTIgU3VwcG9ydCAgICAgICAgICAgICAgICAgICAg PSAxICgxKQowMDowMDowMi4yMjkgU1MgLSBTZWxmIFNub29wICAgICAgICAgICAgICAgICAgICAg ICAgPSAwICgxKQowMDowMDowMi4yMjkgSFRUIC0gSHlwZXItVGhyZWFkaW5nIFRlY2hub2xvZyAg ICAgICAgPSAwICgxKQowMDowMDowMi4yMjkgVE0gLSBUaGVybWFsIE1vbml0b3IgICAgICAgICAg ICAgICAgICAgPSAwICgxKQowMDowMDowMi4yMjkgMzAgLSBSZXNlcnZlZCAgICAgICAgICAgICAg ICAgICAgICAgICAgPSAwICgwKQowMDowMDowMi4yMjkgUEJFIC0gUGVuZGluZyBCcmVhayBFbmFi bGUgICAgICAgICAgICAgPSAwICgxKQowMDowMDowMi4yMjkgU3VwcG9ydHMgU1NFMyBvciBub3Qg ICAgICAgICAgICAgICAgICAgPSAxICgxKQowMDowMDowMi4yMjkgUmVzZXJ2ZWQgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgPSAwICgwKQowMDowMDowMi4yMjkgRFMgQXJlYSA2NC1iaXQg bGF5b3V0ICAgICAgICAgICAgICAgICAgPSAwICgxKQowMDowMDowMi4yMjkgU3VwcG9ydHMgTU9O SVRPUi9NV0FJVCAgICAgICAgICAgICAgICAgPSAxICgxKQowMDowMDowMi4yMjkgQ1BMLURTIC0g Q1BMIFF1YWxpZmllZCBEZWJ1ZyBTdG9yZSAgICAgPSAwICgxKQowMDowMDowMi4yMjkgVk1YIC0g VmlydHVhbCBNYWNoaW5lIFRlY2hub2xvZ3kgICAgICAgPSAwICgxKQowMDowMDowMi4yMjkgU01Y IC0gU2FmZXIgTW9kZSBFeHRlbnNpb25zICAgICAgICAgICAgPSAwICgwKQowMDowMDowMi4yMjkg RW5oYW5jZWQgU3BlZWRTdGVwIFRlY2hub2xvZ3kgICAgICAgICAgPSAwICgxKQowMDowMDowMi4y MjkgVGVybWluYWwgTW9uaXRvciAyICAgICAgICAgICAgICAgICAgICAgPSAwICgxKQowMDowMDow Mi4yMjkgU3VwcG9ydHMgU3VwcGxlbWVudGFsIFNTRTMgb3Igbm90ICAgICAgPSAwICgxKQowMDow MDowMi4yMjkgTDEgQ29udGV4dCBJRCAgICAgICAgICAgICAgICAgICAgICAgICAgPSAwICgwKQow MDowMDowMi4yMjkgUmVzZXJ2ZWQgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgPSAweDAg KDB4MCkKMDA6MDA6MDIuMjI5IENNUFhDSEcxNkIgICAgICAgICAgICAgICAgICAgICAgICAgICAg ID0gMCAoMSkKMDA6MDA6MDIuMjI5IHhUUFIgVXBkYXRlIENvbnRyb2wgICAgICAgICAgICAgICAg ICAgID0gMCAoMSkKMDA6MDA6MDIuMjI5IFBlcmYvRGVidWcgQ2FwYWJpbGl0eSBNU1IgICAgICAg ICAgICAgID0gMCAoMSkKMDA6MDA6MDIuMjI5IFJlc2VydmVkICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgID0gMHgwICgweDApCjAwOjAwOjAyLjIyOSBEaXJlY3QgQ2FjaGUgQWNjZXNzICAg ICAgICAgICAgICAgICAgICA9IDAgKDApCjAwOjAwOjAyLjIyOSBTdXBwb3J0cyBTU0U0XzEgb3Ig bm90ICAgICAgICAgICAgICAgICA9IDAgKDApCjAwOjAwOjAyLjIyOSBTdXBwb3J0cyBTU0U0XzIg b3Igbm90ICAgICAgICAgICAgICAgICA9IDAgKDApCjAwOjAwOjAyLjIyOSBTdXBwb3J0cyB0aGUg eDJBUElDIGV4dGVuc2lvbnMgICAgICAgICA9IDAgKDApCjAwOjAwOjAyLjIyOSBTdXBwb3J0cyBN T1ZCRSAgICAgICAgICAgICAgICAgICAgICAgICA9IDAgKDApCjAwOjAwOjAyLjIyOSBTdXBwb3J0 cyBQT1BDTlQgICAgICAgICAgICAgICAgICAgICAgICA9IDAgKDApCjAwOjAwOjAyLjIyOSBSZXNl cnZlZCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICA9IDB4MCAoMHgwKQowMDowMDowMi4y MjkgU3VwcG9ydHMgWFNBVkUgICAgICAgICAgICAgICAgICAgICAgICAgPSAwICgwKQowMDowMDow Mi4yMjkgU3VwcG9ydHMgT1NYU0FWRSAgICAgICAgICAgICAgICAgICAgICAgPSAwICgwKQowMDow MDowMi4yMjkgUmVzZXJ2ZWQgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgPSAweDAgKDB4 MCkKMDA6MDA6MDIuMjI5IAowMDowMDowMi4yMjkgICAgICAgICAgUkFXIEV4dGVuZGVkIENQVUlE cwowMDowMDowMi4yMjkgICAgICBGdW5jdGlvbiAgZWF4ICAgICAgZWJ4ICAgICAgZWN4ICAgICAg ZWR4CjAwOjAwOjAyLjIyOSBHc3Q6IDgwMDAwMDAwICA4MDAwMDAwOCAwMDAwMDAwMCAwMDAwMDAw MCAwMDAwMDAwMAowMDowMDowMi4yMjkgSHN0OiAgICAgICAgICAgODAwMDAwMDggMDAwMDAwMDAg MDAwMDAwMDAgMDAwMDAwMDAKMDA6MDA6MDIuMjI5IEdzdDogODAwMDAwMDEgIDAwMDAwMDAwIDAw MDAwMDAwIDAwMDAwMDAwIDAwMDAwMDAwCjAwOjAwOjAyLjIyOSBIc3Q6ICAgICAgICAgICAwMDAw MDAwMCAwMDAwMDAwMCAwMDAwMDAwMSAyMDEwMDAwMAowMDowMDowMi4yMjkgR3N0OiA4MDAwMDAw MiAgNjU3NDZlNDkgMjk1MjI4NmMgNzI2ZjQzMjAgNGQ1NDI4NjUKMDA6MDA6MDIuMjI5IEhzdDog ICAgICAgICAgIDY1NzQ2ZTQ5IDI5NTIyODZjIDcyNmY0MzIwIDRkNTQyODY1CjAwOjAwOjAyLjIy OSBHc3Q6IDgwMDAwMDAzICA0MzIwMzIyOSAyMDIwNTU1MCAyMDIwMjAyMCA1NDIwMjAyMAowMDow MDowMi4yMjkgSHN0OiAgICAgICAgICAgNDMyMDMyMjkgMjAyMDU1NTAgMjAyMDIwMjAgNTQyMDIw MjAKMDA6MDA6MDIuMjI5IEdzdDogODAwMDAwMDQgIDMwMzAzMjM3IDIwNDAyMDIwIDMwMzAyZTMy IDAwN2E0ODQ3CjAwOjAwOjAyLjIyOSBIc3Q6ICAgICAgICAgICAzMDMwMzIzNyAyMDQwMjAyMCAz MDMwMmUzMiAwMDdhNDg0NwowMDowMDowMi4yMjkgR3N0OiA4MDAwMDAwNSAgMDAwMDAwMDAgMDAw MDAwMDAgMDAwMDAwMDAgMDAwMDAwMDAKMDA6MDA6MDIuMjI5IEhzdDogICAgICAgICAgIDAwMDAw MDAwIDAwMDAwMDAwIDAwMDAwMDAwIDAwMDAwMDAwCjAwOjAwOjAyLjIyOSBHc3Q6IDgwMDAwMDA2 ICAwMDAwMDAwMCAwMDAwMDAwMCAxMDAwODA0MCAwMDAwMDAwMAowMDowMDowMi4yMjkgSHN0OiAg ICAgICAgICAgMDAwMDAwMDAgMDAwMDAwMDAgMTAwMDgwNDAgMDAwMDAwMDAKMDA6MDA6MDIuMjI5 IEdzdDogODAwMDAwMDcgIDAwMDAwMDAwIDAwMDAwMDAwIDAwMDAwMDAwIDAwMDAwMDAwCjAwOjAw OjAyLjIyOSBIc3Q6ICAgICAgICAgICAwMDAwMDAwMCAwMDAwMDAwMCAwMDAwMDAwMCAwMDAwMDAw MAowMDowMDowMi4yMjkgR3N0OiA4MDAwMDAwOCAgMDAwMDMwMjQgMDAwMDAwMDAgMDAwMDAwMDAg MDAwMDAwMDAKMDA6MDA6MDIuMjI5IEhzdDogICAgICAgICAgIDAwMDAzMDI0IDAwMDAwMDAwIDAw MDAwMDAwIDAwMDAwMDAwCjAwOjAwOjAyLjIyOSBHc3Q6IDgwMDAwMDA5ICAwNzI4MDIwMiAwMDAw MDAwMCAwMDAwMDAwMCAwMDAwMDAwMCoKMDA6MDA6MDIuMjI5IEhzdDogICAgICAgICAgIDA3Mjgw MjAyIDAwMDAwMDAwIDAwMDAwMDAwIDAwMDAwMDAwCjAwOjAwOjAyLjIyOSBFeHQgTmFtZTogICAg ICAgICAgICAgICAgICAgICAgICAKMDA6MDA6MDIuMjI5IEV4dCBTdXBwb3J0czogICAgICAgICAg ICAgICAgICAgIDB4ODAwMDAwMDAtMHg4MDAwMDAwOAowMDowMDowMi4yMjkgRmFtaWx5OiAgICAg ICAgICAgICAgICAgICAgICAgICAgMCAgCUV4dGVuZGVkOiAwIAlFZmZlY3RpdmU6IDAKMDA6MDA6 MDIuMjI5IE1vZGVsOiAgICAgICAgICAgICAgICAgICAgICAgICAgIDAgIAlFeHRlbmRlZDogMCAJ RWZmZWN0aXZlOiAwCjAwOjAwOjAyLjIyOSBTdGVwcGluZzogICAgICAgICAgICAgICAgICAgICAg ICAwCjAwOjAwOjAyLjIyOSBCcmFuZCBJRDogICAgICAgICAgICAgICAgICAgICAgICAweDAwMAow MDowMDowMi4yMjkgTW5lbW9uaWMgLSBEZXNjcmlwdGlvbiAgICAgICAgICAgICAgICAgPSBndWVz dCAoaG9zdCkKMDA6MDA6MDIuMjI5IEZQVSAtIHg4NyBGUFUgb24gQ2hpcCAgICAgICAgICAgICAg ICAgID0gMCAoMCkKMDA6MDA6MDIuMjI5IFZNRSAtIFZpcnR1YWwgODA4NiBNb2RlIEVuaGFuY2Vt ZW50cyAgID0gMCAoMCkKMDA6MDA6MDIuMjI5IERFIC0gRGVidWdnaW5nIGV4dGVuc2lvbnMgICAg ICAgICAgICAgID0gMCAoMCkKMDA6MDA6MDIuMjI5IFBTRSAtIFBhZ2UgU2l6ZSBFeHRlbnNpb24g ICAgICAgICAgICAgID0gMCAoMCkKMDA6MDA6MDIuMjI5IFRTQyAtIFRpbWUgU3RhbXAgQ291bnRl ciAgICAgICAgICAgICAgID0gMCAoMCkKMDA6MDA6MDIuMjI5IE1TUiAtIEs4NiBNb2RlbCBTcGVj aWZpYyBSZWdpc3RlcnMgICAgID0gMCAoMCkKMDA6MDA6MDIuMjI5IFBBRSAtIFBoeXNpY2FsIEFk ZHJlc3MgRXh0ZW5zaW9uICAgICAgID0gMCAoMCkKMDA6MDA6MDIuMjI5IE1DRSAtIE1hY2hpbmUg Q2hlY2sgRXhjZXB0aW9uICAgICAgICAgID0gMCAoMCkKMDA6MDA6MDIuMjMwIENYOCAtIENNUFhD SEc4QiBpbnN0cnVjdGlvbiAgICAgICAgICAgID0gMCAoMCkKMDA6MDA6MDIuMjMwIEFQSUMgLSBB UElDIE9uLUNoaXAgICAgICAgICAgICAgICAgICAgID0gMCAoMCkKMDA6MDA6MDIuMjMwIDEwIC0g UmVzZXJ2ZWQgICAgICAgICAgICAgICAgICAgICAgICAgID0gMCAoMCkKMDA6MDA6MDIuMjMwIFNF UCAtIFNZU0NBTEwgYW5kIFNZU1JFVCAgICAgICAgICAgICAgID0gMCAoMCkKMDA6MDA6MDIuMjMw IE1UUlIgLSBNZW1vcnkgVHlwZSBSYW5nZSBSZWdpc3RlcnMgICAgID0gMCAoMCkKMDA6MDA6MDIu MjMwIFBHRSAtIFBURSBHbG9iYWwgQml0ICAgICAgICAgICAgICAgICAgID0gMCAoMCkKMDA6MDA6 MDIuMjMwIE1DQSAtIE1hY2hpbmUgQ2hlY2sgQXJjaGl0ZWN0dXJlICAgICAgID0gMCAoMCkKMDA6 MDA6MDIuMjMwIENNT1YgLSBDb25kaXRpb25hbCBNb3ZlIEluc3RydWN0aW9ucyAgID0gMCAoMCkK MDA6MDA6MDIuMjMwIFBBVCAtIFBhZ2UgQXR0cmlidXRlIFRhYmxlICAgICAgICAgICAgID0gMCAo MCkKMDA6MDA6MDIuMjMwIFBTRS0zNiAtIDM2LWJpdCBQYWdlIFNpemUgRXh0ZW50aW9uICAgID0g MCAoMCkKMDA6MDA6MDIuMjMwIDE4IC0gUmVzZXJ2ZWQgICAgICAgICAgICAgICAgICAgICAgICAg ID0gMCAoMCkKMDA6MDA6MDIuMjMwIDE5IC0gUmVzZXJ2ZWQgICAgICAgICAgICAgICAgICAgICAg ICAgID0gMCAoMCkKMDA6MDA6MDIuMjMwIE5YIC0gTm8tRXhlY3V0ZSBQYWdlIFByb3RlY3Rpb24g ICAgICAgID0gMCAoMSkKMDA6MDA6MDIuMjMwIERTIC0gRGVidWcgU3RvcmUgICAgICAgICAgICAg ICAgICAgICAgID0gMCAoMCkKMDA6MDA6MDIuMjMwIEFYTU1YIC0gQU1EIEV4dGVuc2lvbnMgdG8g TU1YIEluc3RyLiAgID0gMCAoMCkKMDA6MDA6MDIuMjMwIE1NWCAtIEludGVsIE1NWCBUZWNobm9s b2d5ICAgICAgICAgICAgID0gMCAoMCkKMDA6MDA6MDIuMjMwIEZYU1IgLSBGWFNBVkUgYW5kIEZY UlNUT1IgSW5zdHJ1Y3Rpb25zID0gMCAoMCkKMDA6MDA6MDIuMjMwIDI1IC0gQU1EIGZhc3QgRlhT QVZFIGFuZCBGWFJTVE9SIEluc3RyLj0gMCAoMCkKMDA6MDA6MDIuMjMwIDI2IC0gMSBHQiBsYXJn ZSBwYWdlIHN1cHBvcnQgICAgICAgICAgID0gMCAoMCkKMDA6MDA6MDIuMjMwIDI3IC0gUkRUU0NQ IGluc3RydWN0aW9uICAgICAgICAgICAgICAgID0gMCAoMCkKMDA6MDA6MDIuMjMwIDI4IC0gUmVz ZXJ2ZWQgICAgICAgICAgICAgICAgICAgICAgICAgID0gMCAoMCkKMDA6MDA6MDIuMjMwIDI5IC0g QU1EIExvbmcgTW9kZSAgICAgICAgICAgICAgICAgICAgID0gMCAoMSkKMDA6MDA6MDIuMjMwIDMw IC0gQU1EIEV4dGVuc2lvbnMgdG8gM0ROb3cgICAgICAgICAgID0gMCAoMCkKMDA6MDA6MDIuMjMw IDMxIC0gQU1EIDNETm93ICAgICAgICAgICAgICAgICAgICAgICAgID0gMCAoMCkKMDA6MDA6MDIu MjMwIExhaGZTYWhmIC0gTEFIRi9TQUhGIGluIDY0LWJpdCBtb2RlICAgID0gMCAoMSkKMDA6MDA6 MDIuMjMwIENtcExlZ2FjeSAtIENvcmUgTVAgbGVnYWN5IG1vZGUgKGRlcHIpID0gMCAoMCkKMDA6 MDA6MDIuMjMwIFNWTSAtIEFNRCBWTSBFeHRlbnNpb25zICAgICAgICAgICAgICAgID0gMCAoMCkK MDA6MDA6MDIuMjMwIEFQSUMgcmVnaXN0ZXJzIHN0YXJ0aW5nIGF0IDB4NDAwICAgICAgID0gMCAo MCkKMDA6MDA6MDIuMjMwIEFsdE1vdkNSOCAtIExPQ0sgTU9WIENSMCBtZWFucyBNT1YgQ1I4ID0g MCAoMCkKMDA6MDA6MDIuMjMwIEFkdmFuY2VkIGJpdCBtYW5pcHVsYXRpb24gICAgICAgICAgICAg ID0gMCAoMCkKMDA6MDA6MDIuMjMwIFNTRTRBIGluc3RydWN0aW9uIHN1cHBvcnQgICAgICAgICAg ICAgID0gMCAoMCkKMDA6MDA6MDIuMjMwIE1pc2FsaWduZWQgU1NFIG1vZGUgICAgICAgICAgICAg ICAgICAgID0gMCAoMCkKMDA6MDA6MDIuMjMwIFBSRUZFVENIIGFuZCBQUkVGRVRDSFcgaW5zdHJ1 Y3Rpb24gICAgID0gMCAoMCkKMDA6MDA6MDIuMjMwIE9TIHZpc2libGUgd29ya2Fyb3VuZCAgICAg ICAgICAgICAgICAgID0gMCAoMCkKMDA6MDA6MDIuMjMwIEluc3RydWN0aW9uIGJhc2VkIHNhbXBs aW5nICAgICAgICAgICAgID0gMCAoMCkKMDA6MDA6MDIuMjMwIFNTRTUgc3VwcG9ydCAgICAgICAg ICAgICAgICAgICAgICAgICAgID0gMCAoMCkKMDA6MDA6MDIuMjMwIFNLSU5JVCwgU1RHSSwgYW5k IERFViBzdXBwb3J0ICAgICAgICAgID0gMCAoMCkKMDA6MDA6MDIuMjMwIFdhdGNoZG9nIHRpbWVy IHN1cHBvcnQuICAgICAgICAgICAgICAgID0gMCAoMCkKMDA6MDA6MDIuMjMwIDMxOjE0IC0gUmVz ZXJ2ZWQgICAgICAgICAgICAgICAgICAgICAgID0gMHgwICgweDApCjAwOjAwOjAyLjIzMCBGdWxs IE5hbWU6ICAgICAgICAgICAgICAgICAgICAgICBJbnRlbChSKSBDb3JlKFRNKTIgQ1BVICAgICAg ICAgVDcyMDAgIEAgMi4wMEdIegowMDowMDowMi4yMzAgVExCIDIvNE0gSW5zdHIvVW5pOiAgICAg ICAgICAgICAgcmVzMCAgICAgMCBlbnRyaWVzCjAwOjAwOjAyLjIzMCBUTEIgMi80TSBEYXRhOiAg ICAgICAgICAgICAgICAgICByZXMwICAgICAwIGVudHJpZXMKMDA6MDA6MDIuMjMwIFRMQiA0SyBJ bnN0ci9Vbmk6ICAgICAgICAgICAgICAgIHJlczAgICAgIDAgZW50cmllcwowMDowMDowMi4yMzAg VExCIDRLIERhdGE6ICAgICAgICAgICAgICAgICAgICAgcmVzMCAgICAgMCBlbnRyaWVzCjAwOjAw OjAyLjIzMCBMMSBJbnN0ciBDYWNoZSBMaW5lIFNpemU6ICAgICAgICAwIGJ5dGVzCjAwOjAwOjAy LjIzMCBMMSBJbnN0ciBDYWNoZSBMaW5lcyBQZXIgVGFnOiAgICAwCjAwOjAwOjAyLjIzMCBMMSBJ bnN0ciBDYWNoZSBBc3NvY2lhdGl2aXR5OiAgICByZXMwICAKMDA6MDA6MDIuMjMwIEwxIEluc3Ry IENhY2hlIFNpemU6ICAgICAgICAgICAgIDAgS0IKMDA6MDA6MDIuMjMwIEwxIERhdGEgQ2FjaGUg TGluZSBTaXplOiAgICAgICAgIDAgYnl0ZXMKMDA6MDA6MDIuMjMwIEwxIERhdGEgQ2FjaGUgTGlu ZXMgUGVyIFRhZzogICAgIDAKMDA6MDA6MDIuMjMwIEwxIERhdGEgQ2FjaGUgQXNzb2NpYXRpdml0 eTogICAgIHJlczAgIAowMDowMDowMi4yMzAgTDEgRGF0YSBDYWNoZSBTaXplOiAgICAgICAgICAg ICAgMCBLQgowMDowMDowMi4yMzAgTDIgVExCIDIvNE0gSW5zdHIvVW5pOiAgICAgICAgICAgb2Zm ICAgICAgIDAgZW50cmllcwowMDowMDowMi4yMzAgTDIgVExCIDIvNE0gRGF0YTogICAgICAgICAg ICAgICAgb2ZmICAgICAgIDAgZW50cmllcwowMDowMDowMi4yMzAgTDIgVExCIDRLIEluc3RyL1Vu aTogICAgICAgICAgICAgb2ZmICAgICAgIDAgZW50cmllcwowMDowMDowMi4yMzAgTDIgVExCIDRL IERhdGE6ICAgICAgICAgICAgICAgICAgb2ZmICAgICAgIDAgZW50cmllcwowMDowMDowMi4yMzAg TDIgQ2FjaGUgTGluZSBTaXplOiAgICAgICAgICAgICAgMCBieXRlcwowMDowMDowMi4yMzAgTDIg Q2FjaGUgTGluZXMgUGVyIFRhZzogICAgICAgICAgMAowMDowMDowMi4yMzAgTDIgQ2FjaGUgQXNz b2NpYXRpdml0eTogICAgICAgICAgb2ZmICAgCjAwOjAwOjAyLjIzMCBMMiBDYWNoZSBTaXplOiAg ICAgICAgICAgICAgICAgICAwIEtCCjAwOjAwOjAyLjIzMCBBUE0gRmVhdHVyZXM6ICAgICAgICAg ICAgICAgICAgIAowMDowMDowMi4yMzAgUGh5c2ljYWwgQWRkcmVzcyBXaWR0aDogICAgICAgICAg MzYgYml0cwowMDowMDowMi4yMzAgVmlydHVhbCBBZGRyZXNzIFdpZHRoOiAgICAgICAgICAgNDgg Yml0cwowMDowMDowMi4yMzAgUGh5c2ljYWwgQ29yZSBDb3VudDogICAgICAgICAgICAgMAowMDow MDowMi4yMzAgCjAwOjAwOjAyLjIzMCAgICAgICAgICBSQVcgQ2VudGF1ciBDUFVJRHMKMDA6MDA6 MDIuMjMwICAgICAgRnVuY3Rpb24gIGVheCAgICAgIGVieCAgICAgIGVjeCAgICAgIGVkeAowMDow MDowMi4yMzAgR3N0OiBjMDAwMDAwMCAgMDcyODAyMDIgMDAwMDAwMDAgMDAwMDAwMDAgMDAwMDAw MDAKMDA6MDA6MDIuMjMwIEhzdDogICAgICAgICAgIDA3MjgwMjAyIDAwMDAwMDAwIDAwMDAwMDAw IDAwMDAwMDAwCjAwOjAwOjAyLjIzMCBHc3Q6IGMwMDAwMDAxICAwNzI4MDIwMiAwMDAwMDAwMCAw MDAwMDAwMCAwMDAwMDAwMAowMDowMDowMi4yMzAgSHN0OiAgICAgICAgICAgMDcyODAyMDIgMDAw MDAwMDAgMDAwMDAwMDAgMDAwMDAwMDAKMDA6MDA6MDIuMjMwIEdzdDogYzAwMDAwMDIgIDA3Mjgw MjAyIDAwMDAwMDAwIDAwMDAwMDAwIDAwMDAwMDAwCjAwOjAwOjAyLjIzMCBIc3Q6ICAgICAgICAg ICAwNzI4MDIwMiAwMDAwMDAwMCAwMDAwMDAwMCAwMDAwMDAwMAowMDowMDowMi4yMzAgR3N0OiBj MDAwMDAwMyAgMDcyODAyMDIgMDAwMDAwMDAgMDAwMDAwMDAgMDAwMDAwMDAKMDA6MDA6MDIuMjMw IEhzdDogICAgICAgICAgIDA3MjgwMjAyIDAwMDAwMDAwIDAwMDAwMDAwIDAwMDAwMDAwCjAwOjAw OjAyLjIzMCBDZW50YXVyIFN1cHBvcnRzOiAgICAgICAgICAgICAgICAweGMwMDAwMDAwLTB4MDcy ODAyMDIKMDA6MDA6MDIuMjMwIE1uZW1vbmljIC0gRGVzY3JpcHRpb24gICAgICAgICAgICAgICAg ID0gZ3Vlc3QgKGhvc3QpCjAwOjAwOjAyLjIzMCBBSVMgLSBBbHRlcm5hdGUgSW5zdHJ1Y3Rpb24g U2V0ICAgICAgICA9IDAgKDApCjAwOjAwOjAyLjIzMCBBSVMtRSAtIEFJUyBlbmFibGVkICAgICAg ICAgICAgICAgICAgICA9IDAgKDApCjAwOjAwOjAyLjIzMCBSTkcgLSBSYW5kb20gTnVtYmVyIEdl bmVyYXRvciAgICAgICAgICA9IDAgKDApCjAwOjAwOjAyLjIzMCBSTkctRSAtIFJORyBlbmFibGVk ICAgICAgICAgICAgICAgICAgICA9IDAgKDApCjAwOjAwOjAyLjIzMCBMSCAtIExvbmdIYXVsIE1T UiAwMDAwXzExMEFoICAgICAgICAgICA9IDAgKDApCjAwOjAwOjAyLjIzMCBGRU1NUyAtIEZFTU1T ICAgICAgICAgICAgICAgICAgICAgICAgICA9IDAgKDApCjAwOjAwOjAyLjIzMCBBQ0UgLSBBZHZh bmNlZCBDcnlwdG9ncmFwaHkgRW5naW5lICAgICA9IDAgKDApCjAwOjAwOjAyLjIzMCBBQ0UtRSAt IEFDRSBlbmFibGVkICAgICAgICAgICAgICAgICAgICA9IDAgKDApCjAwOjAwOjAyLjIzMCBBQ0Uy IC0gQWR2YW5jZWQgQ3J5cHRvZ3JhcGh5IEVuZ2luZSAyICA9IDAgKDApCjAwOjAwOjAyLjIzMCBB Q0UyLUUgLSBBQ0UgZW5hYmxlZCAgICAgICAgICAgICAgICAgICA9IDAgKDApCjAwOjAwOjAyLjIz MCBQSEUgLSBIYXNoIEVuZ2luZSAgICAgICAgICAgICAgICAgICAgICA9IDAgKDApCjAwOjAwOjAy LjIzMCBQSEUtRSAtIFBIRSBlbmFibGVkICAgICAgICAgICAgICAgICAgICA9IDAgKDApCjAwOjAw OjAyLjIzMCBQTU0gLSBNb250Z29tZXJ5IE11bHRpcGxpZXIgICAgICAgICAgICA9IDAgKDApCjAw OjAwOjAyLjIzMCBQTU0tRSAtIFBNTSBlbmFibGVkICAgICAgICAgICAgICAgICAgICA9IDAgKDAp CjAwOjAwOjAyLjIzMCAKMDA6MDA6MDIuMjMxIAowMDowMDowMi4yMzEgKioqKioqKioqKioqKioq KioqKiogRW5kIG9mIENQVUlEIGR1bXAgKioqKioqKioqKioqKioqKioqKioqKgowMDowMDowMi4y ODAgUkVNOiBWQm94UkVNNjQKMDA6MDA6MDIuMzAzIFVzaW5nIDY0LWJpdCBhd2FyZSBSRU0KMDA6 MDA6MDIuMzM4IFRNOiBHSVAgLSB1MzJNb2RlPTEgKFN5bmNUU0MpIHUzMlVwZGF0ZUh6PTEwMAow MDowMDowMi4zNzAgVE06IGNUU0NUaWNrc1BlclNlY29uZD0weDc3NDhhZWEwICgyIDAwMSAyNTIg MDAwKSBmVFNDVmlydHVhbGl6ZWQ9dHJ1ZSAgZlRTQ1VzZVJlYWxUU0M9ZmFsc2UKMDA6MDA6MDIu MzcwIFRNOiBmTWF5YmVVc2VPZmZzZXR0ZWRIb3N0VFNDPXRydWUgIFRTQ1RpZWRUb0V4ZWN1dGlv bj1mYWxzZSBUU0NOb3RUaWVkVG9IYWx0PWZhbHNlCjAwOjAwOjAyLjM3MCBDb3JlQ29kZTogUjM9 MDA3ZmIwMDAgUjA9NDgzYWEwMDAgUkM9YTAzMTAwMDAgUGh5cz0wMDAwMDAwMDA3MTk3MDAwIGNi PTB4MzAwMAowMDowMDowMi40ODIgW1NNUF0gQklPUyB3aXRoIDEgQ1BVcwowMDowMDowMi41MjMg U1VQOiBMb2FkZWQgVkJveEREUjAucjAgKC9BcHBsaWNhdGlvbnMvVmlydHVhbEJveC5hcHAvQ29u dGVudHMvTWFjT1MvVkJveEREUjAucjApIGF0IDB4MzUxZTkwNjAgLSBNb2R1bGVJbml0IGF0IDAw MDAwMDAwMDAwMDAwMDAgYW5kIE1vZHVsZVRlcm0gYXQgMDAwMDAwMDAwMDAwMDAwMAowMDowMDow Mi41MzMgU1VQOiBMb2FkZWQgVkJveEREMlIwLnIwICgvQXBwbGljYXRpb25zL1ZpcnR1YWxCb3gu YXBwL0NvbnRlbnRzL01hY09TL1ZCb3hERDJSMC5yMCkgYXQgMHgzNTFjODA2MCAtIE1vZHVsZUlu aXQgYXQgMDAwMDAwMDAwMDAwMDAwMCBhbmQgTW9kdWxlVGVybSBhdCAwMDAwMDAwMDAwMDAwMDAw CjAwOjAwOjAyLjUzMyBBY3RpdmF0aW5nIExvY2FsIEFQSUMKMDA6MDA6MDIuNTMzIENQVU1TZXRH dWVzdENwdUlkRmVhdHVyZTogRW5hYmxlZCBBUElDCjAwOjAwOjAyLjUzNCBDUFVNU2V0R3Vlc3RD cHVJZEZlYXR1cmU6IERpc2FibGVkIHgyQVBJQwowMDowMDowMi41MzQgUElUOiBtb2RlPTMgY291 bnQ9MHgxMDAwMCAoNjU1MzYpIC0gMTguMjAgSHogKGNoPTApCjAwOjAwOjAyLjU1OSBTaGFyZWQg Rm9sZGVycyBzZXJ2aWNlIGxvYWRlZC4KMDA6MDA6MDIuNjE4IFZESW5pdCBmaW5pc2hlZAowMDow MDowMi42MjQgUElJWDMgQVRBOiBMVU4jMDogZGlzaywgUENIUz04MzIyLzE2LzYzLCB0b3RhbCBu dW1iZXIgb2Ygc2VjdG9ycyA4Mzg4NjA4CjAwOjAwOjAyLjYyNCBQSUlYMyBBVEE6IExVTiMxOiBu byB1bml0CjAwOjAwOjAyLjYyNCBQSUlYMyBBVEE6IExVTiMyOiBDRC9EVkQsIHRvdGFsIG51bWJl ciBvZiBzZWN0b3JzIDAsIHBhc3N0aHJvdWdoIGRpc2FibGVkCjAwOjAwOjAyLjYyNCBQSUlYMyBB VEE6IExVTiMzOiBubyB1bml0CjAwOjAwOjAyLjYyNCBQSUlYMyBBVEE6IEN0bCMwOiBmaW5pc2hl ZCBwcm9jZXNzaW5nIFJFU0VUCjAwOjAwOjAyLjYyNCBQSUlYMyBBVEE6IEN0bCMxOiBmaW5pc2hl ZCBwcm9jZXNzaW5nIFJFU0VUCjAwOjAwOjAyLjYyNCBJbnROZXQjMDogc3pOZXR3b3JrPXtIb3N0 SW50ZXJmYWNlTmV0d29ya2luZy1lbjA6IEV0aGVybmV0fSBlbm1UcnVua1R5cGU9MyBzelRydW5r PXtlbjB9IGZGbGFncz0weDAgY2JSZWN2PTIyMzIzMiBjYlNlbmQ9MzY4NjQKMDA6MDA6MDIuNjI2 IEF1ZGlvOiBUcnlpbmcgZHJpdmVyICdjb3JlYXVkaW8nLgowMDowMDowMi42MjcgQXVkaW86IHNl dF9yZWNvcmRfc291cmNlIGFycz0wIGFscz0wIChub3QgaW1wbGVtZW50ZWQpCjAwOjAwOjAyLjc3 OSBEZXZQY0Jpb3M6IEFUQSBMVU4jMCBMQ0hTPTEwMjQvNi82MwowMDowMDowMi43NzkgUEdNUjNJ bml0RmluYWxpemU6IDQgTUIgUFNFIG1hc2sgMDAwMDAwMGZmZmZmZmZmZgowMDowMDowMi43OTIg SFdBQ0NNOiBIb3N0IENSND0wMDAwMDY2MAowMDowMDowMi43OTIgSFdBQ0NNOiBNU1JfSUEzMl9G RUFUVVJFX0NPTlRST0wgICAgICA9IDUKMDA6MDA6MDIuNzkyIEhXQUNDTTogTVNSX0lBMzJfVk1Y X0JBU0lDX0lORk8gICAgICAgPSAxYTA0MDAwMDAwMDAwNwowMDowMDowMi43OTIgSFdBQ0NNOiBW TUNTIGlkICAgICAgICAgICAgICAgICAgICAgICA9IDcKMDA6MDA6MDIuNzkyIEhXQUNDTTogVk1D UyBzaXplICAgICAgICAgICAgICAgICAgICAgPSA0MDAKMDA6MDA6MDIuNzkyIEhXQUNDTTogVk1D UyBwaHlzaWNhbCBhZGRyZXNzIGxpbWl0ICAgPSBOb25lCjAwOjAwOjAyLjc5MiBIV0FDQ006IFZN Q1MgbWVtb3J5IHR5cGUgICAgICAgICAgICAgID0gNgowMDowMDowMi43OTIgSFdBQ0NNOiBEdWFs IG1vbml0b3IgdHJlYXRtZW50ICAgICAgICA9IDEKMDA6MDA6MDIuNzkyIEhXQUNDTTogTVNSX0lB MzJfVk1YX1BJTkJBU0VEX0NUTFMgICAgPSAxZjAwMDAwMDE2CjAwOjAwOjAyLjc5MiBIV0FDQ006 ICAgIFZNWF9WTUNTX0NUUkxfUElOX0VYRUNfQ09OVFJPTFNfRVhUX0lOVF9FWElUCjAwOjAwOjAy Ljc5MiBIV0FDQ006ICAgIFZNWF9WTUNTX0NUUkxfUElOX0VYRUNfQ09OVFJPTFNfTk1JX0VYSVQK MDA6MDA6MDIuNzkyIEhXQUNDTTogTVNSX0lBMzJfVk1YX1BST0NCQVNFRF9DVExTICAgPSA3N2I5 ZmZmZTA0MDFlMTcyCjAwOjAwOjAyLjc5MiBIV0FDQ006ICAgIFZNWF9WTUNTX0NUUkxfUFJPQ19F WEVDX0NPTlRST0xTX0lSUV9XSU5ET1dfRVhJVAowMDowMDowMi43OTIgSFdBQ0NNOiAgICBWTVhf Vk1DU19DVFJMX1BST0NfRVhFQ19DT05UUk9MU19UU0NfT0ZGU0VUCjAwOjAwOjAyLjc5MiBIV0FD Q006ICAgIFZNWF9WTUNTX0NUUkxfUFJPQ19FWEVDX0NPTlRST0xTX0hMVF9FWElUCjAwOjAwOjAy Ljc5MiBIV0FDQ006ICAgIFZNWF9WTUNTX0NUUkxfUFJPQ19FWEVDX0NPTlRST0xTX0lOVkxQR19F WElUCjAwOjAwOjAyLjc5MiBIV0FDQ006ICAgIFZNWF9WTUNTX0NUUkxfUFJPQ19FWEVDX0NPTlRS T0xTX01XQUlUX0VYSVQKMDA6MDA6MDIuNzkyIEhXQUNDTTogICAgVk1YX1ZNQ1NfQ1RSTF9QUk9D X0VYRUNfQ09OVFJPTFNfUkRQTUNfRVhJVAowMDowMDowMi43OTIgSFdBQ0NNOiAgICBWTVhfVk1D U19DVFJMX1BST0NfRVhFQ19DT05UUk9MU19SRFRTQ19FWElUCjAwOjAwOjAyLjc5MiBIV0FDQ006 ICAgIFZNWF9WTUNTX0NUUkxfUFJPQ19FWEVDX0NPTlRST0xTX0NSM19MT0FEX0VYSVQKMDA6MDA6 MDIuNzkyIEhXQUNDTTogICAgVk1YX1ZNQ1NfQ1RSTF9QUk9DX0VYRUNfQ09OVFJPTFNfQ1IzX1NU T1JFX0VYSVQKMDA6MDA6MDIuNzkyIEhXQUNDTTogICAgVk1YX1ZNQ1NfQ1RSTF9QUk9DX0VYRUNf Q09OVFJPTFNfQ1I4X0xPQURfRVhJVAowMDowMDowMi43OTIgSFdBQ0NNOiAgICBWTVhfVk1DU19D VFJMX1BST0NfRVhFQ19DT05UUk9MU19DUjhfU1RPUkVfRVhJVAowMDowMDowMi43OTIgSFdBQ0NN OiAgICBWTVhfVk1DU19DVFJMX1BST0NfRVhFQ19DT05UUk9MU19VU0VfVFBSX1NIQURPVwowMDow MDowMi43OTIgSFdBQ0NNOiAgICBWTVhfVk1DU19DVFJMX1BST0NfRVhFQ19DT05UUk9MU19NT1Zf RFJfRVhJVAowMDowMDowMi43OTIgSFdBQ0NNOiAgICBWTVhfVk1DU19DVFJMX1BST0NfRVhFQ19D T05UUk9MU19VTkNPTkRfSU9fRVhJVAowMDowMDowMi43OTIgSFdBQ0NNOiAgICBWTVhfVk1DU19D VFJMX1BST0NfRVhFQ19DT05UUk9MU19VU0VfSU9fQklUTUFQUwowMDowMDowMi43OTIgSFdBQ0NN OiAgICBWTVhfVk1DU19DVFJMX1BST0NfRVhFQ19DT05UUk9MU19VU0VfTVNSX0JJVE1BUFMKMDA6 MDA6MDIuNzkyIEhXQUNDTTogICAgVk1YX1ZNQ1NfQ1RSTF9QUk9DX0VYRUNfQ09OVFJPTFNfTU9O SVRPUl9FWElUCjAwOjAwOjAyLjc5MiBIV0FDQ006ICAgIFZNWF9WTUNTX0NUUkxfUFJPQ19FWEVD X0NPTlRST0xTX1BBVVNFX0VYSVQKMDA6MDA6MDIuNzkyIEhXQUNDTTogICAgVk1YX1ZNQ1NfQ1RS TF9QUk9DX0VYRUNfQ09OVFJPTFNfQ1IzX0xPQURfRVhJVCAqbXVzdCogYmUgc2V0CjAwOjAwOjAy Ljc5MiBIV0FDQ006ICAgIFZNWF9WTUNTX0NUUkxfUFJPQ19FWEVDX0NPTlRST0xTX0NSM19TVE9S RV9FWElUICptdXN0KiBiZSBzZXQKMDA6MDA6MDIuNzkyIEhXQUNDTTogTVNSX0lBMzJfVk1YX0VO VFJZX0NUTFMgICAgICAgPSAxZmZmMDAwMDExZmYKMDA6MDA6MDIuNzkyIEhXQUNDTTogICAgVk1Y X1ZNQ1NfQ1RSTF9FTlRSWV9DT05UUk9MU19MT0FEX0RFQlVHCjAwOjAwOjAyLjc5MiBIV0FDQ006 ICAgIFZNWF9WTUNTX0NUUkxfRU5UUllfQ09OVFJPTFNfSUE2NF9NT0RFCjAwOjAwOjAyLjc5MiBI V0FDQ006ICAgIFZNWF9WTUNTX0NUUkxfRU5UUllfQ09OVFJPTFNfRU5UUllfU01NCjAwOjAwOjAy Ljc5MiBIV0FDQ006ICAgIFZNWF9WTUNTX0NUUkxfRU5UUllfQ09OVFJPTFNfREVBQ1RJVkFURV9E VUFMTU9OCjAwOjAwOjAyLjc5MiBIV0FDQ006ICAgIFZNWF9WTUNTX0NUUkxfRU5UUllfQ09OVFJP TFNfTE9BRF9ERUJVRyAqbXVzdCogYmUgc2V0CjAwOjAwOjAyLjc5MiBIV0FDQ006IE1TUl9JQTMy X1ZNWF9FWElUX0NUTFMgICAgICAgID0gM2VmZmYwMDAzNmRmZgowMDowMDowMi43OTIgSFdBQ0NN OiAgICBWTVhfVk1DU19DVFJMX0VYSVRfQ09OVFJPTFNfU0FWRV9ERUJVRwowMDowMDowMi43OTIg SFdBQ0NNOiAgICBWTVhfVk1DU19DVFJMX0VYSVRfQ09OVFJPTFNfSE9TVF9BTUQ2NAowMDowMDow Mi43OTIgSFdBQ0NNOiAgICBWTVhfVk1DU19DVFJMX0VYSVRfQ09OVFJPTFNfQUNLX0VYVEVSTkFM X0lSUQowMDowMDowMi43OTIgSFdBQ0NNOiAgICBWTVhfVk1DU19DVFJMX0VYSVRfQ09OVFJPTFNf U0FWRV9ERUJVRyAqbXVzdCogYmUgc2V0CjAwOjAwOjAyLjc5MiBIV0FDQ006IE1TUl9JQTMyX1ZN WF9NSVNDICAgICAgICAgICAgID0gNDAzYzAKMDA6MDA6MDIuNzkyIEhXQUNDTTogICAgTVNSX0lB MzJfVk1YX01JU0NfUFJFRU1QVF9UU0NfQklUIDAKMDA6MDA6MDIuNzkyIEhXQUNDTTogICAgTVNS X0lBMzJfVk1YX01JU0NfQUNUSVZJVFlfU1RBVEVTIDcKMDA6MDA6MDIuNzkyIEhXQUNDTTogICAg TVNSX0lBMzJfVk1YX01JU0NfQ1IzX1RBUkdFVCAgICAgIDQKMDA6MDA6MDIuNzkyIEhXQUNDTTog ICAgTVNSX0lBMzJfVk1YX01JU0NfTUFYX01TUiAgICAgICAgIDIwMAowMDowMDowMi43OTIgSFdB Q0NNOiAgICBNU1JfSUEzMl9WTVhfTUlTQ19NU0VHX0lEICAgICAgICAgMAowMDowMDowMi43OTIg SFdBQ0NNOiBNU1JfSUEzMl9WTVhfQ1IwX0ZJWEVEMCAgICAgICA9IDgwMDAwMDIxCjAwOjAwOjAy Ljc5MiBIV0FDQ006IE1TUl9JQTMyX1ZNWF9DUjBfRklYRUQxICAgICAgID0gZmZmZmZmZmYKMDA6 MDA6MDIuNzkyIEhXQUNDTTogTVNSX0lBMzJfVk1YX0NSNF9GSVhFRDAgICAgICAgPSAyMDAwCjAw OjAwOjAyLjc5MiBIV0FDQ006IE1TUl9JQTMyX1ZNWF9DUjRfRklYRUQxICAgICAgID0gMjdmZgow MDowMDowMi43OTIgSFdBQ0NNOiBNU1JfSUEzMl9WTVhfVk1DU19FTlVNICAgICAgICA9IDJjCjAw OjAwOjAyLjc5MiBIV0FDQ006IFRQUiBzaGFkb3cgcGh5c2FkZHIgICAgICAgICAgID0gMDAwMDAw MDAwNzE5YTAwMAowMDowMDowMi43OTIgSFdBQ0NNOiBWQ1BVMDogTVNSIGJpdG1hcCBwaHlzYWRk ciAgICAgID0gMDAwMDAwMDAwNzE5ZDAwMAowMDowMDowMi43OTIgSFdBQ0NNOiBWQ1BVMDogVk1D UyBwaHlzYWRkciAgICAgICAgICAgID0gMDAwMDAwMDAwNzE5YjAwMAowMDowMDowMi43OTIgSFdB Q0NNOiBSZWFsIE1vZGUgVFNTIGd1ZXN0IHBoeXNhZGRyICA9IDAwMDAwMDAwZjA4MDAwMDAKMDA6 MDA6MDIuNzkyIEhXQUNDTTogTm9uLVBhZ2luZyBNb2RlIEVQVCBDUjMgICAgICAgPSAwMDAwMDAw MGYwODAzMDAwCjAwOjAwOjAyLjc5MyBDUFVNU2V0R3Vlc3RDcHVJZEZlYXR1cmU6IEVuYWJsZWQg c3lzZW50ZXIvZXhpdAowMDowMDowMi43OTMgQ1BVTVNldEd1ZXN0Q3B1SWRGZWF0dXJlOiBFbmFi bGVkIFBBRQowMDowMDowMi43OTMgQ1BVTVNldEd1ZXN0Q3B1SWRGZWF0dXJlOiBFbmFibGVkIExP TkcgTU9ERQowMDowMDowMi43OTMgQ1BVTVNldEd1ZXN0Q3B1SWRGZWF0dXJlOiBFbmFibGVkIHN5 c2NhbGwvcmV0CjAwOjAwOjAyLjc5MyBDUFVNU2V0R3Vlc3RDcHVJZEZlYXR1cmU6IEVuYWJsZWQg TEFIRi9TQUhGCjAwOjAwOjAyLjc5MyBDUFVNU2V0R3Vlc3RDcHVJZEZlYXR1cmU6IEVuYWJsZWQg TlhFCjAwOjAwOjAyLjc5MyBIV0FDQ006IDMyLWJpdCBhbmQgNjQtYml0IGd1ZXN0cyBzdXBwb3J0 ZWQuCjAwOjAwOjAyLjc5MyBIV0FDQ006IFZNWCBlbmFibGVkIQowMDowMDowMi43OTMgSFdBQ0NN OiAgICBWVC14L0FNRC1WIGluaXQgbWV0aG9kOiBMT0NBTAowMDowMDowMi44MDMgVk06IEhhbHQg bWV0aG9kIGdsb2JhbDEgKDUpCjAwOjAwOjAyLjgwNCBDaGFuZ2luZyB0aGUgVk0gc3RhdGUgZnJv bSAnQ1JFQVRJTkcnIHRvICdDUkVBVEVEJy4KMDA6MDA6MDIuODA0IENoYW5naW5nIHRoZSBWTSBz dGF0ZSBmcm9tICdDUkVBVEVEJyB0byAnUlVOTklORycuCjAwOjAwOjAyLjgxOCBHdWVzdCBMb2c6 IEJJT1M6IFZpcnR1YWxCb3ggMy4wLjEwCjAwOjAwOjAyLjgxOCBQSVQ6IG1vZGU9MiBjb3VudD0w eDEwMDAwICg2NTUzNikgLSAxOC4yMCBIeiAoY2g9MCkKMDA6MDA6MDMuMDU3IFBJSVgzIEFUQTog Q3RsIzA6IFJFU0VULCBEZXZTZWw9MCBBSU9JZj0wIENtZElmMD0weDAwICgtMSB1c2VjIGFnbykg Q21kSWYxPTB4MDAgKC0xIHVzZWMgYWdvKQowMDowMDowMy4wNTggUElJWDMgQVRBOiBDdGwjMDog ZmluaXNoZWQgcHJvY2Vzc2luZyBSRVNFVAowMDowMDowMy4wNTkgR3Vlc3QgTG9nOiBCSU9TOiBh dGEwLTA6IFBDSFM9ODMyMi8xNi82MyBMQ0hTPTEwMjQvNi82MwowMDowMDowMy4wNTkgUElJWDMg QVRBOiBDdGwjMTogUkVTRVQsIERldlNlbD0wIEFJT0lmPTAgQ21kSWYwPTB4MDAgKC0xIHVzZWMg YWdvKSBDbWRJZjE9MHgwMCAoLTEgdXNlYyBhZ28pCjAwOjAwOjAzLjA1OSBQSUlYMyBBVEE6IEN0 bCMxOiBmaW5pc2hlZCBwcm9jZXNzaW5nIFJFU0VUCjAwOjAwOjAzLjA2MCBQSVQ6IG1vZGU9MiBj b3VudD0weDQ4ZDMgKDE4NjQzKSAtIDY0LjAwIEh6IChjaD0wKQowMDowMDowMy4wNzcgRGlzcGxh eTo6aGFuZGxlRGlzcGxheVJlc2l6ZSgpOiB1U2NyZWVuSWQgPSAwLCBwdlZSQU09MWE5NzYwMDAg dz02NDAgaD00ODAgYnBwPTMyIGNiTGluZT0weEEwMAowMDowMDowNS41NDEgRGlzcGxheTo6aGFu ZGxlRGlzcGxheVJlc2l6ZSgpOiB1U2NyZWVuSWQgPSAwLCBwdlZSQU09MDAwMDAwMDAgdz03MjAg aD00MDAgYnBwPTAgY2JMaW5lPTB4MAowMDowMDowNS41NDMgUElUOiBtb2RlPTIgY291bnQ9MHgx MDAwMCAoNjU1MzYpIC0gMTguMjAgSHogKGNoPTApCjAwOjAwOjA1LjU0NyBHdWVzdCBMb2c6IEJJ T1M6IEJvb3QgZnJvbSBGbG9wcHkgMCBmYWlsZWQKMDA6MDA6MDUuNTUwIEd1ZXN0IExvZzogQklP UzogQ0RST00gYm9vdCBmYWlsdXJlIGNvZGUgOiAwMDAzCjAwOjAwOjA1LjU1MSBHdWVzdCBMb2c6 IEJJT1M6IEJvb3QgZnJvbSBDRC1ST00gZmFpbGVkCjAwOjAwOjA1LjYyMyBHdWVzdCBMb2c6IEJJ T1M6IEJvb3RpbmcgZnJvbSBIYXJkIERpc2suLi4KMDA6MDA6MTEuNDY2IEd1ZXN0IExvZzogQklP UzogaW50MTNfZGlza2V0dGU6IHVuc3VwcG9ydGVkIEFIPTQxCjAwOjAwOjI5LjM1OCBDaGFuZ2lu ZyB0aGUgVk0gc3RhdGUgZnJvbSAnUlVOTklORycgdG8gJ1JFU0VUVElORycuCjAwOjAwOjI5LjM2 MyBDUFVNU2V0R3Vlc3RDcHVJZEZlYXR1cmU6IEVuYWJsZWQgQVBJQwowMDowMDoyOS4zNjMgQ1BV TVNldEd1ZXN0Q3B1SWRGZWF0dXJlOiBEaXNhYmxlZCB4MkFQSUMKMDA6MDA6MjkuMzYzIFBJVDog bW9kZT0zIGNvdW50PTB4MTAwMDAgKDY1NTM2KSAtIDE4LjIwIEh6IChjaD0wKQowMDowMDoyOS4z NjkgUElJWDMgQVRBOiBDdGwjMDogZmluaXNoZWQgcHJvY2Vzc2luZyBSRVNFVAowMDowMDoyOS40 NjkgUElJWDMgQVRBOiBDdGwjMTogZmluaXNoZWQgcHJvY2Vzc2luZyBSRVNFVAowMDowMDoyOS41 NjkgQXVkaW86IHNldF9yZWNvcmRfc291cmNlIGFycz0wIGFscz0wIChub3QgaW1wbGVtZW50ZWQp CjAwOjAwOjI5LjU2OSBDaGFuZ2luZyB0aGUgVk0gc3RhdGUgZnJvbSAnUkVTRVRUSU5HJyB0byAn UlVOTklORycuCjAwOjAwOjI5LjU3MyBHdWVzdCBMb2c6IEJJT1M6IFZpcnR1YWxCb3ggMy4wLjEw CjAwOjAwOjI5LjU3MyBQSVQ6IG1vZGU9MiBjb3VudD0weDEwMDAwICg2NTUzNikgLSAxOC4yMCBI eiAoY2g9MCkKMDA6MDA6MjkuNjk2IFBJSVgzIEFUQTogQ3RsIzA6IFJFU0VULCBEZXZTZWw9MCBB SU9JZj0wIENtZElmMD0weDIwICgtMSB1c2VjIGFnbykgQ21kSWYxPTB4MDAgKC0xIHVzZWMgYWdv KQowMDowMDoyOS42OTYgUElJWDMgQVRBOiBDdGwjMDogZmluaXNoZWQgcHJvY2Vzc2luZyBSRVNF VAowMDowMDoyOS42OTggR3Vlc3QgTG9nOiBCSU9TOiBhdGEwLTA6IFBDSFM9ODMyMi8xNi82MyBM Q0hTPTEwMjQvNi82MwowMDowMDoyOS42OTggUElJWDMgQVRBOiBDdGwjMTogUkVTRVQsIERldlNl bD0wIEFJT0lmPTAgQ21kSWYwPTB4YTAgKC0xIHVzZWMgYWdvKSBDbWRJZjE9MHgwMCAoLTEgdXNl YyBhZ28pCjAwOjAwOjI5LjY5OCBQSUlYMyBBVEE6IEN0bCMxOiBmaW5pc2hlZCBwcm9jZXNzaW5n IFJFU0VUCjAwOjAwOjI5LjY5OSBQSVQ6IG1vZGU9MiBjb3VudD0weDQ4ZDMgKDE4NjQzKSAtIDY0 LjAwIEh6IChjaD0wKQowMDowMDoyOS43MTkgRGlzcGxheTo6aGFuZGxlRGlzcGxheVJlc2l6ZSgp OiB1U2NyZWVuSWQgPSAwLCBwdlZSQU09MWE5NzYwMDAgdz02NDAgaD00ODAgYnBwPTMyIGNiTGlu ZT0weEEwMAowMDowMDozMi4xOTggRGlzcGxheTo6aGFuZGxlRGlzcGxheVJlc2l6ZSgpOiB1U2Ny ZWVuSWQgPSAwLCBwdlZSQU09MDAwMDAwMDAgdz03MjAgaD00MDAgYnBwPTAgY2JMaW5lPTB4MAow MDowMDozMi4yMTcgUElUOiBtb2RlPTIgY291bnQ9MHgxMDAwMCAoNjU1MzYpIC0gMTguMjAgSHog KGNoPTApCjAwOjAwOjMyLjIyMSBHdWVzdCBMb2c6IEJJT1M6IEJvb3QgZnJvbSBGbG9wcHkgMCBm YWlsZWQKMDA6MDA6MzIuMjI0IEd1ZXN0IExvZzogQklPUzogQ0RST00gYm9vdCBmYWlsdXJlIGNv ZGUgOiAwMDAzCjAwOjAwOjMyLjIyNCBHdWVzdCBMb2c6IEJJT1M6IEJvb3QgZnJvbSBDRC1ST00g ZmFpbGVkCjAwOjAwOjMyLjIyNSBHdWVzdCBMb2c6IEJJT1M6IEJvb3RpbmcgZnJvbSBIYXJkIERp c2suLi4KMDA6MDA6NDUuMzgzIEd1ZXN0IExvZzogQklPUzogaW50MTNfZGlza2V0dGU6IHVuc3Vw cG9ydGVkIEFIPTQxCg== --0015174bec1c12b8350477406512-- From owner-freebsd-current@FreeBSD.ORG Sat Oct 31 21:21:22 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B9E331065676 for ; Sat, 31 Oct 2009 21:21:22 +0000 (UTC) (envelope-from rickvanderzwet@gmail.com) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.157]) by mx1.freebsd.org (Postfix) with ESMTP id 52E408FC13 for ; Sat, 31 Oct 2009 21:21:22 +0000 (UTC) Received: by fg-out-1718.google.com with SMTP id d23so61973fga.13 for ; Sat, 31 Oct 2009 14:21:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:date :x-google-sender-auth:message-id:subject:from:to:content-type; bh=oep41OlqKd6LaperG1mojPv2Pfub0i3SRxUQCTadQco=; b=G5d1wCGBs8MqhfrsLTut40GNn4xBhjhPJPh4ibSRT7FXHHQ8CrJ+fVjQv4rXMUSv/Z LGy1ng7LzepVJqj+SpcZq4uKjgIXixu2KvJm1yif3YDjssMx+QH0ney4OIsLXj08MZGs SPaR3pJkMDz70RrQxE3wtX+XtKNabuNGDvexM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:date:x-google-sender-auth:message-id:subject :from:to:content-type; b=h0xfTK+GkhogP2iFtjiAlYkuP9FugeEpWw4N2OnxuinyWHhKlmFUJsUO9xDDSA4yCz Xd5nKGRTE/vG4KywSVhXDKSmeFm7IhBmWPvIZR/1sovkc366Va/wTImMWOwFkP9+QcLl x2KuHz60uwlrnnPFIaUn74P4frUDRPy6dX468= MIME-Version: 1.0 Sender: rickvanderzwet@gmail.com Received: by 10.223.161.205 with SMTP id s13mr503518fax.70.1257022766198; Sat, 31 Oct 2009 13:59:26 -0700 (PDT) Date: Sat, 31 Oct 2009 21:59:26 +0100 X-Google-Sender-Auth: 6f6491b7fbf8b616 Message-ID: <5aaae08a0910311359v45cc9dc9h2826d8a29bfb5575@mail.gmail.com> From: Rick van der Zwet To: freebsd-current@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Subject: aue0 detected as ue0 on 8.0-RC2 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 31 Oct 2009 21:21:22 -0000 The first net interface of a aue(4) define used to be called aue0 afaik. But is now called ue0 (declared in usb/net/usb_ethernet.c). (no sign of ue(4) btw). I was looking in the UPDATING, man, mailinglists freebsd-usb@ and freebsd-current@. But I could not find the reason why the naming convention on this aue differs from the regular stuff, anybody? /Rick quick# dmesg | tail -8 ugen1.3: at usbus1 aue0: on usbus1 miibus1: on aue0 ukphy0: PHY 1 on miibus1 ukphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto ue0: on aue0 ue0: Ethernet address: 00:00:e8:00:11:36 ue0: link state changed to DOWN quick# ifconfig -l bfe0 lo0 ue0 -- http://rickvanderzwet.nl From owner-freebsd-current@FreeBSD.ORG Sat Oct 31 21:25:40 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7FD801065679 for ; Sat, 31 Oct 2009 21:25:40 +0000 (UTC) (envelope-from dmitriy@lebedew.ru) Received: from lebedew.ru (lebedew.ru [82.146.43.108]) by mx1.freebsd.org (Postfix) with ESMTP id 07EA28FC18 for ; Sat, 31 Oct 2009 21:25:39 +0000 (UTC) Received: from [77.243.98.202] (account dmitriy@lebedew.ru) by lebedew.ru (CommuniGate Pro XIMSS 5.2.15 _community_) with XIMSS id 4533977 for freebsd-current@freebsd.org; Sat, 31 Oct 2009 23:25:37 +0300 X-Mailer: CommuniGate Pro Pronto 2.7.2 From: "Dmitriy A Lebedev" To: freebsd-current@freebsd.org Date: Sat, 31 Oct 2009 23:25:37 +0300 Message-ID: Content-Type: text/plain;charset="utf-8"; format="flowed" Content-Transfer-Encoding: 8bit Subject: bwi driver issue X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 31 Oct 2009 21:25:40 -0000 Hi All! I'm using { PCI_VENDOR_BROADCOM, 0x4320,"Broadcom BCM4306 802.11b/g Wireless Lan"} network card. I have a little problem with bwi wireless driver at FreeBSD 8.0 RC2 (the same problem was at RC1 too). It doesn't worK for me: According to man bwi instructions, I have added if_bwi_load="YES" into /boot/defaults/loader.conf, and install /usr/ports/net/bwi-firmware-kmod port. Next, i have ran pciconf -lvcb to check hardware, and found the following output: none4@pci0:1:4:0: class=0x028000 card=0x12f8103c chip=0x432014e4 rev=0x03 hdr=0x00 vendor = 'Broadcom Corporation' device = '802.11b/g Wireless LAN Controller (BCM4309)' class = network bar [10] = type Memory, range 32, base 0xff7fc000, size 8192, enabled So, the hardware is recognized by system. Next, I have tried to find new bwi interface at ifconfig, but it wasn't appeared there. The results of kldload if_bwi were very strange: can't load if_bwi: No such file or directory Finally, there is no the appropriate file at /boot/kernel. So.. I suppose I need to use another method from man and compile this driver into kernel. But there is very clear information at man bwi instructions: " Alternatively, to load the driver as a module at boot time, place the following line in loader.conf(5): if_bwi_load="YES" And it doesn't work. Is it a some kind of bug, or mistake in documentation? Thanks in advance. Sincerely yours, Dmitriy A Lebedev From owner-freebsd-current@FreeBSD.ORG Sat Oct 31 22:03:01 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 009E2106566B for ; Sat, 31 Oct 2009 22:03:01 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id CF8678FC08 for ; Sat, 31 Oct 2009 22:03:00 +0000 (UTC) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by cyrus.watson.org (Postfix) with ESMTPS id 56AF246B03; Sat, 31 Oct 2009 18:03:00 -0400 (EDT) Date: Sat, 31 Oct 2009 22:03:00 +0000 (GMT) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Matthias Rampke In-Reply-To: <31d643300910311306m6caa73cfi8930465e43773ff4@mail.gmail.com> Message-ID: References: <31d643300910311245r593326e1me8574bdff5198b51@mail.gmail.com> <31d643300910311306m6caa73cfi8930465e43773ff4@mail.gmail.com> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-current@freebsd.org Subject: Re: Host OS (OS X 10.6.1) panic when booting 8.0-RC2 in VirtualBox 3.0.10 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 31 Oct 2009 22:03:01 -0000 On Sat, 31 Oct 2009, Matthias Rampke wrote: > On Sat, Oct 31, 2009 at 8:45 PM, Matthias Rampke > wrote: > >> I have been experiencing reproducible kernel panics in Mac OS X 10.6.1 when >> booting 8.0-RC1 and -RC2 (amd64) in a VirtualBox VM. >> >> I had a (mostly pristine) 7.2-RELEASE running in this VM and tried to >> upgrade to 8.0-RC2 with freebsd-update. It could well be that a bug in FreeBSD is triggering the bug in VirtualBox, but we're unlikely to make much headway debugging the FreeBSD bug (if any) until the bug in VirtualBox is diagnosed/fixed. I'm not sure what the normal debugging procedure for vbox panics on Mac OS X is, but I'd suggest making a backup copy of the bad VM so that you can trigger it on demand later. > This does not happen in a new, freshly installed VM. Now it hangs at usbus > initialization, but I suppose that's a different story (the pains of using > USB with VirtualBox, they never end). This, on the other hand, could be our bug; there's a new USB stack in 8.0. I suggest creating a new thread for that issue with a usb-related subject line to make sure the right folk see it. Robert From owner-freebsd-current@FreeBSD.ORG Sat Oct 31 22:42:29 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 514CD106566C for ; Sat, 31 Oct 2009 22:42:29 +0000 (UTC) (envelope-from gallasch@free.de) Received: from smtp.free.de (smtp.free.de [91.204.6.103]) by mx1.freebsd.org (Postfix) with ESMTP id C68EA8FC1D for ; Sat, 31 Oct 2009 22:42:28 +0000 (UTC) Received: (qmail 11075 invoked by uid 98); 31 Oct 2009 23:15:46 +0100 Received: from 91.204.4.103 by smtp.free.de (envelope-from , uid 82) with qmail-scanner-1.25 (clamdscan: 0.90.1/3618. Clear:RC:1(91.204.4.103):. Processed in 0.029565 secs); 31 Oct 2009 22:15:46 -0000 X-Qmail-Scanner-Mail-From: gallasch@free.de via smtp.free.de X-Qmail-Scanner: 1.25 (Clear:RC:1(91.204.4.103):. Processed in 0.029565 secs) Received: from smtp.free.de (HELO boiler.free.de) (gallasch@free.de@[91.204.4.103]) (envelope-sender ) by smtp.free.de (qmail-ldap-1.03) with AES128-SHA encrypted SMTP for ; 31 Oct 2009 23:15:46 +0100 Date: Sat, 31 Oct 2009 23:15:45 +0100 From: Kai Gallasch To: freebsd-current@freebsd.org Message-ID: <20091031231545.493cee89@boiler.free.de> X-Mailer: Claws Mail 3.6.1 (GTK+ 2.16.1; x86_64-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: 8.0RC2 amd64 - kernel panic running make buildworld X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 31 Oct 2009 22:42:29 -0000 Hi. I installed 8.0RC2-amd64 on an 8-core opteron server a few days ago. When I try to do a make buildworld or make buildkernel the server reboots without any message left in the logs. The same happens when building bigger ports (for example ruby18 or perl58) With 8.0-RC2 debug flags and witness seem to be disabled in the standard GENERIC kernel, so unfortunately it is not possible for me to build a debug kernel without my server crashing.. Now my idea was to install the old 8.0-BETA4 and upgrade to RC2 through makeworld + buildkernel (gdb+witness). But no luck. When trying to upgrade to RC2 the 8.0-BETA4 also crashes. At least 8.0-BETA4 has debug + witness active in the GENERIC kernel.. So below some debug output of 8.0-BETA4 crashing. Has a vfs/ffs LOR problem with the BETA4 already been fixed? Does it make sense to send in a pr with the old 8.0-BETA4? BTW. I installed 7.2-STABLE on this same server and did a "make buildworld" and "make buildkernel" which completed without any problem. Cheers, --Kai ----- make buildworld -j7 crash, freebsd 8.0-amd64-beta4 ----- lock order reversal: 1st 0xffffff00073d5ba8 ufs (ufs) @ /usr/src/sys/ufs/ffs/ffs_snapshot.c:423 2nd 0xffffff819d921558 bufwait (bufwait) @ /usr/src/sys/kern/vfs_bio.c:2559 3rd 0xffffff00070c19d0 ufs (ufs) @ /usr/src/sys/ufs/ffs/ffs_snapshot.c:544 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2a _witness_debugger() at _witness_debugger+0x2e witness_checkorder() at witness_checkorder+0x81e __lockmgr_args() at __lockmgr_args+0xcf3 ffs_lock() at ffs_lock+0x8c VOP_LOCK1_APV() at VOP_LOCK1_APV+0x9b _vn_lock() at _vn_lock+0x47 ffs_snapshot() at ffs_snapshot+0x1b9d ffs_mount() at ffs_mount+0x666 vfs_donmount() at vfs_donmount+0xcde nmount() at nmount+0x63 syscall() at syscall+0x1af Xfast_syscall() at Xfast_syscall+0xe1 --- syscall (378, FreeBSD ELF64, nmount), rip = 0x8007b14fc, rsp = 0x7fffffffe9b8, rbp = 0x800902530 --- lock order reversal: 1st 0xffffff819d921558 bufwait (bufwait) @ /usr/src/sys/kern/vfs_bio.c:2559 2nd 0xffffff0007d9fa30 snaplk (snaplk) @ /usr/src/sys/ufs/ffs/ffs_snapshot.c:793 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2a _witness_debugger() at _witness_debugger+0x2e witness_checkorder() at witness_checkorder+0x81e __lockmgr_args() at __lockmgr_args+0xcf3 ffs_lock() at ffs_lock+0x8c VOP_LOCK1_APV() at VOP_LOCK1_APV+0x9b _vn_lock() at _vn_lock+0x47 ffs_snapshot() at ffs_snapshot+0x1a6a ffs_mount() at ffs_mount+0x666 vfs_donmount() at vfs_donmount+0xcde nmount() at nmount+0x63 syscall() at syscall+0x1af Xfast_syscall() at Xfast_syscall+0xe1 --- syscall (378, FreeBSD ELF64, nmount), rip = 0x8007b14fc, rsp = 0x7fffffffe9b8, rbp = 0x800902530 --- lock order reversal: 1st 0xffffff0007d9fa30 snaplk (snaplk) @ /usr/src/sys/kern/vfs_vnops.c:296 2nd 0xffffff00073d5ba8 ufs (ufs) @ /usr/src/sys/ufs/ffs/ffs_snapshot.c:1587 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2a _witness_debugger() at _witness_debugger+0x2e witness_checkorder() at witness_checkorder+0x81e __lockmgr_args() at __lockmgr_args+0xcf3 ffs_snapremove() at ffs_snapremove+0xe7 softdep_releasefile() at softdep_releasefile+0x139 ufs_inactive() at ufs_inactive+0x1a5 vinactive() at vinactive+0x72 vput() at vput+0x230 vn_close() at vn_close+0x118 vn_closefile() at vn_closefile+0x5a _fdrop() at _fdrop+0x23 closef() at closef+0x5b kern_close() at kern_close+0x110 syscall() at syscall+0x1af Xfast_syscall() at Xfast_syscall+0xe1 --- syscall (6, FreeBSD ELF64, close), rip = 0x80084cf9c, rsp = 0x7fffffffe9b8, rbp = 0 ---