From owner-freebsd-current@FreeBSD.ORG Sun Mar 29 00:03: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 8A280106564A for ; Sun, 29 Mar 2009 00:03:38 +0000 (UTC) (envelope-from barney_cordoba@yahoo.com) Received: from web63902.mail.re1.yahoo.com (web63902.mail.re1.yahoo.com [69.147.97.117]) by mx1.freebsd.org (Postfix) with SMTP id 3496B8FC15 for ; Sun, 29 Mar 2009 00:03:38 +0000 (UTC) (envelope-from barney_cordoba@yahoo.com) Received: (qmail 49451 invoked by uid 60001); 29 Mar 2009 00:03:37 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1238285017; bh=RNzvGuuKNF8AF+cradZdKEMnTdhFk9RTYADj7Go7JQ0=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=MFDbMmd4b8Bfa0iVZ7X1X31NF5pDio3R877LbFxNr0RiRZDGW/WronMqkIRfFrpvI+/BtGO6bZAAYBazvP8awVHhjziZ3DFS8/I951geqxTX8FEnjCPzaFQixmP+xnqtuvrlKzXcbSV4X8aaxNmo1c7P1XuIOX3lbw3j3Pircow= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=l5wtrq4AMQGcdJi/qB3Hzd6+9ueYC+uD7QLAnajePjAb62acgmTMoktAYsL9r8A/+4asCpiiO5E8BUgwiTJs+tRGiPAWUFHejdScevabaq/1oPZUTdNIWVB7/GAkTH3vQ37H3tb8+90GGEQL7jEPu3aa0CxCYkYgRiSBAzsKqcg=; Message-ID: <706191.48959.qm@web63902.mail.re1.yahoo.com> X-YMail-OSG: SWmdGXAVM1n9kydxAtEWH5G46hMgj0gKl68Agyu3szW.uaUMxcRtD5wIIpXOEe.giscStSa0CcKFFy_niYl4KaThJYI9ykLgLEnG62EU388TxxvgUlDBL7UjVW6H5n2frykNMXXsCOhAplt24y2rnoHirZoB.g5SkPD9GxPeI6YK4LUiE6.h09Nq4gY95LDG9FtIVXmHRsdLverlIf2C85fNCaVMK6HTn0soNjXw27wWsQ7_.NQ- Received: from [98.242.222.229] by web63902.mail.re1.yahoo.com via HTTP; Sat, 28 Mar 2009 17:03:37 PDT X-Mailer: YahooMailWebService/0.7.289.1 Date: Sat, 28 Mar 2009 17:03:37 -0700 (PDT) From: Barney Cordoba To: current@freebsd.org In-Reply-To: <848052.92716.qm@web63907.mail.re1.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Subject: Re: Bus Resource busy panic X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: barney_cordoba@yahoo.com List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Mar 2009 00:03:38 -0000 --- On Sat, 3/28/09, Barney Cordoba wrote: > From: Barney Cordoba > Subject: Bus Resource busy panic > To: current@freebsd.org > Date: Saturday, March 28, 2009, 6:35 PM > I have a situation that results in a panic in 8 that runs > happily in 7. > Its a bus_alloc_resource of type SYS_RES_MEMORY that is > used by 2 > separate devices. > > I see there is an RF_SHAREABLE flag. That flag hadn't > been set, but is there > something in 8 that now requires it? > > As a side question, should a bus_alloc_resource call panic > the system just > because the resource is busy? > > Barney Some more info on this. The panic is in resource_list_alloc() and setting SHAREABLE doesn't fix it. I see the same code in 7 so I'm not sure why it would work in 7 and not 8. Basically there are 2 devices that need to do IO on a board, and they are both doing bus_alloc_resource_any(dev, SYS_RES_MEMORY,&rid, RF_ACTIVE); Barney From owner-freebsd-current@FreeBSD.ORG Sun Mar 29 00:14:54 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 017CB106564A for ; Sun, 29 Mar 2009 00:14:54 +0000 (UTC) (envelope-from wenji@fnal.gov) Received: from mailgw2.fnal.gov (mailgw2.fnal.gov [131.225.111.12]) by mx1.freebsd.org (Postfix) with ESMTP id C89408FC16 for ; Sun, 29 Mar 2009 00:14:53 +0000 (UTC) (envelope-from wenji@fnal.gov) Received: from mailav2.fnal.gov (mailav2.fnal.gov [131.225.111.20]) by mailgw2.fnal.gov (iPlanet Messaging Server 5.2 HotFix 2.06 (built Mar 28 2005)) with SMTP id <0KH800452RCKR2@mailgw2.fnal.gov>; Sat, 28 Mar 2009 19:14:53 -0500 (CDT) Received: from mailgw1.fnal.gov ([131.225.111.11]) by mailav2.fnal.gov (SAVSMTP 3.1.7.47) with SMTP id M2009032819145325484 ; Sat, 28 Mar 2009 19:14:53 -0500 Received: from conversion-daemon.mailgw1.fnal.gov by mailgw1.fnal.gov (iPlanet Messaging Server 5.2 HotFix 2.06 (built Mar 28 2005)) id <0KH800E01R9AG4@mailgw1.fnal.gov> (original mail from wenji@fnal.gov); Sat, 28 Mar 2009 19:14:53 -0500 (CDT) Received: from fnal.gov (imap2.fnal.gov [131.225.111.7]) by mailgw1.fnal.gov (iPlanet Messaging Server 5.2 HotFix 2.06 (built Mar 28 2005)) with ESMTP id <0KH8002RPRCTWB@mailgw1.fnal.gov>; Sat, 28 Mar 2009 19:14:53 -0500 (CDT) Received: from [67.184.224.143] by imap2.fnal.gov (mshttpd); Sat, 28 Mar 2009 19:14:53 -0500 Date: Sat, 28 Mar 2009 19:14:53 -0500 From: Wenji Wu In-reply-to: <49CE231C.9080609@FreeBSD.org> To: Kris Kennaway Message-id: MIME-version: 1.0 X-Mailer: Sun Java(tm) System Messenger Express 6.3-6.03 (built Mar 14 2008; 32bit) Content-type: text/plain; charset=us-ascii Content-language: en Content-transfer-encoding: 7BIT Content-disposition: inline X-Accept-Language: en Priority: normal References: <49CE231C.9080609@FreeBSD.org> Cc: freebsd-current@freebsd.org Subject: Re: LOCK_PROFILING does not work on FreeBSD 8.0-CURRENT 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, 29 Mar 2009 00:14:54 -0000 > It certainly does work in 8.0. Is it possible you forgot to install > the > rebuilt kernel? I have rebuilt everything (rebuild the world), just does not work for me. But if it works for you, i will retry to see what is going on. wenji From owner-freebsd-current@FreeBSD.ORG Sun Mar 29 00:35:54 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from alona.my.domain (localhost [127.0.0.1]) by hub.freebsd.org (Postfix) with ESMTP id 9E2191065670; Sun, 29 Mar 2009 00:35:48 +0000 (UTC) (envelope-from davidxu@freebsd.org) Message-ID: <49CEC261.4010803@freebsd.org> Date: Sun, 29 Mar 2009 08:35:45 +0800 From: David Xu User-Agent: Thunderbird 2.0.0.16 (X11/20080915) MIME-Version: 1.0 To: Julian Elischer References: <11609492.9579.1238167614335.JavaMail.root@vms070.mailsrvcs.net> <49CD0405.1060704@samsco.org> <49CD30E9.7030501@elischer.org> In-Reply-To: <49CD30E9.7030501@elischer.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: Sergey Babkin , freebsd-hackers@freebsd.org, attilio@freebsd.org, phk@phk.freebsd.dk, freebsd-current@freebsd.org, prashant.vaibhav@gmail.com Subject: Re: Improving the kernel/i386 timecounter performance (GSoC proposal) 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, 29 Mar 2009 00:35:54 -0000 Julian Elischer wrote: > Scott Long wrote: >> I've been talking about this for years. All I need is help with the >> VM magic to create the page on fork. I also want two pages, one global >> for gettimeofday (and any other global data we can think of) and one >> per-process for static data like getpid/getgid. > > interestingly it is even feasible to have a per-thread page.. > it requires that the scheduler change a page table entry tough. > I will knock his door at midnight if he added such a heavy weight task in the scheduler, TLB shutdown is horrible, and big code size squeezing out data from CPU cache is not idea model. scheduler should be as simple as just a context switching routine. :-) David Xu From owner-freebsd-current@FreeBSD.ORG Sun Mar 29 02:17: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 4A73E1065674; Sun, 29 Mar 2009 02:17:34 +0000 (UTC) (envelope-from ssouhlal@FreeBSD.org) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.freebsd.org (Postfix) with ESMTP id 2F9D98FC27; Sun, 29 Mar 2009 02:17:34 +0000 (UTC) (envelope-from ssouhlal@FreeBSD.org) Received: from [192.168.0.100] (c-67-188-86-214.hsd1.ca.comcast.net [67.188.86.214]) by elvis.mu.org (Postfix) with ESMTP id C181D1A3C1A; Sat, 28 Mar 2009 19:01:15 -0700 (PDT) In-Reply-To: <49CD1B3D.3030103@samsco.org> References: <11609492.9579.1238167614335.JavaMail.root@vms070.mailsrvcs.net> <49CD0405.1060704@samsco.org> <49CD1B3D.3030103@samsco.org> Mime-Version: 1.0 (Apple Message framework v753.1) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <04EDFED9-24B4-404C-96F7-2C96FBC300B4@FreeBSD.org> Content-Transfer-Encoding: 7bit From: Suleiman Souhlal Date: Sat, 28 Mar 2009 19:01:16 -0700 To: Scott Long X-Mailer: Apple Mail (2.753.1) Cc: Sergey Babkin , freebsd-hackers@FreeBSD.org, attilio@FreeBSD.org, phk@phk.freebsd.dk, freebsd-current@FreeBSD.org, Robert Watson , prashant.vaibhav@gmail.com Subject: Re: Improving the kernel/i386 timecounter performance (GSoC proposal) 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, 29 Mar 2009 02:17:34 -0000 On Mar 27, 2009, at 11:30 AM, Scott Long wrote: > Robert Watson wrote: >> On Fri, 27 Mar 2009, Scott Long wrote: >>> I've been talking about this for years. All I need is help with >>> the VM magic to create the page on fork. I also want two pages, >>> one global for gettimeofday (and any other global data we can >>> think of) and one per-process for static data like getpid/getgid. >> FWIW, there are some variations in schemes across OS's -- one >> extreme is the Linux approach, which actually exports a mini >> shared library in ELF format on the shared page, providing >> implementations of various services (such as entering system >> calls), time stuff, etc. Less extreme are the shared pages >> offered on Mac OS X, etc. > > Yes, but I'd like to start somewhere, and considering that it's been > impossible in _5_ years to get the 30 minutes of Peter or JeffR or JHB > time to get the basic VM magic done, I'm keeping my expectations as > modest as possible. > You can find a proof-of-concept implementation for amd64 of a global page mapped in every process at http://people.freebsd.org/~ssouhlal/ testing/syspage-20090328.diff . It exports ticks to userland at VM_MIN_KERNEL_ADDRESS (0xfffffffe40000000). In order for this to work on architectures without a direct map, the page will need to be mapped a second time as read/write (you might want to have a vm_offset_t pmap_map_syspage(vm_page_t m) function that does the right thing for each architecture). Unfortunately, this trick probably won't work for per-process pages without more work, because we wouldn't be able to just insert the page in kernel_map. -- Suleiman From owner-freebsd-current@FreeBSD.ORG Sun Mar 29 05:20: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 27CE41065678 for ; Sun, 29 Mar 2009 05:20:16 +0000 (UTC) (envelope-from julian@elischer.org) Received: from outN.internet-mail-service.net (outn.internet-mail-service.net [216.240.47.237]) by mx1.freebsd.org (Postfix) with ESMTP id 0305A8FC18 for ; Sun, 29 Mar 2009 05:20:15 +0000 (UTC) (envelope-from julian@elischer.org) Received: from idiom.com (mx0.idiom.com [216.240.32.160]) by out.internet-mail-service.net (Postfix) with ESMTP id A81CC39EC5; Sat, 28 Mar 2009 22:20:15 -0700 (PDT) X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e Received: from julian-mac.elischer.org (home.elischer.org [216.240.48.38]) by idiom.com (Postfix) with ESMTP id BB5042D6011; Sat, 28 Mar 2009 22:20:12 -0700 (PDT) Message-ID: <49CF0523.8020905@elischer.org> Date: Sat, 28 Mar 2009 22:20:35 -0700 From: Julian Elischer User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: David Xu References: <11609492.9579.1238167614335.JavaMail.root@vms070.mailsrvcs.net> <49CD0405.1060704@samsco.org> <49CD30E9.7030501@elischer.org> <49CEC261.4010803@freebsd.org> In-Reply-To: <49CEC261.4010803@freebsd.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: Sergey Babkin , freebsd-hackers@freebsd.org, attilio@freebsd.org, phk@phk.freebsd.dk, freebsd-current@freebsd.org, prashant.vaibhav@gmail.com Subject: Re: Improving the kernel/i386 timecounter performance (GSoC proposal) 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, 29 Mar 2009 05:20:16 -0000 David Xu wrote: > Julian Elischer wrote: >> Scott Long wrote: >>> I've been talking about this for years. All I need is help with the >>> VM magic to create the page on fork. I also want two pages, one global >>> for gettimeofday (and any other global data we can think of) and one >>> per-process for static data like getpid/getgid. >> >> interestingly it is even feasible to have a per-thread page.. >> it requires that the scheduler change a page table entry tough. >> > > I will knock his door at midnight if he added such a heavy weight > task in the scheduler, TLB shutdown is horrible, and big code size > squeezing out data from CPU cache is not idea model. > scheduler should be as simple as just a context switching routine. > :-) > > David Xu depends on the hardware. anyhow I was only saying it was possible, not necessarily good or even useful. From owner-freebsd-current@FreeBSD.ORG Sun Mar 29 05:58:54 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 0F716106564A for ; Sun, 29 Mar 2009 05:58:54 +0000 (UTC) (envelope-from lstewart@room52.net) Received: from outbound.icp-qv1-irony-out4.iinet.net.au (outbound.icp-qv1-irony-out4.iinet.net.au [203.59.1.150]) by mx1.freebsd.org (Postfix) with ESMTP id 85EE68FC08 for ; Sun, 29 Mar 2009 05:58:53 +0000 (UTC) (envelope-from lstewart@room52.net) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAL+jzkl8qF1T/2dsb2JhbADJWIIsgU4G X-IronPort-AV: E=Sophos;i="4.38,440,1233500400"; d="scan'208";a="332352878" Received: from unknown (HELO lawrence1.loshell.room52.net) ([124.168.93.83]) by outbound.icp-qv1-irony-out4.iinet.net.au with ESMTP; 29 Mar 2009 13:29:56 +0800 Message-ID: <49CF0754.9070907@room52.net> Date: Sun, 29 Mar 2009 16:29:56 +1100 From: Lawrence Stewart User-Agent: Thunderbird 2.0.0.21 (X11/20090326) MIME-Version: 1.0 To: mav@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: kernel panic with snd_hda "panic: Duplicate free of item 0xffffff00025f8c00 from zone 0xffffff00b697d400(1024)" 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, 29 Mar 2009 05:58:54 -0000 Hi Alexander and all, I'm getting a kernel panic with the snd_hda driver on fresh 8-CURRENT amd64 (r190518). I received this panic the other day when loading the module from the command line on a slightly older kernel revision (I think it was r190437). After putting the module load into /boot/loader.conf, the problem didn't occur again and sound worked just fine on subsequent reboots. A few minutes ago I installed the new r190518 kernel and now it panics consistently with the same message every time. It also panics if I unload the module at the loader prompt, boot the kernel and then kldload on the command line. Hardware is a Toshiba Portege R600 laptop. Details below are hand transcribed as the machine doesn't have a serial port. Relevant bit of verbose boot message when it panics: hdac0: at device 27.0 on pci0 hdac0: HDA driver revision: 20090316_0130 hdac0: Lazy allocation of 0x4000 bytes rid 0x10 type 3 at 0xb69a4000 hdac0: Reserved 0x4000 bytes for rid 0x10 type 3 at 0xb69a4000 hdac0: attempting to allocate 1 MSI vectors (1 supported) hdac0: using IRQ 257 for MSI msi: Assinging MSI IRQ 257 to local APIC 0 vector 53 hdac0: [MPSAFE] hdac0: [ITHREAD] hdac0: hdac_get_capabilities: Invalid corb size (0) device_attach: hdac0 attach returned 6 Slab at 0xffffff00025d5b18, freei 3 = 0. panic: Duplicate free of item 0xffffff00025f8c00 from zone 0xffffff00b697d400(1024) Backtrace at the ddb prompt looks like this: db> bt kdb_enter()+0x3d panic()+0x17b uma_dbg_free()+0x171 uma_zfree_arg()+0x68 free()+0xbd device_set_driver()+0x8e device_attach()+0x19b bus_generic_attach()+0x1a acpi_pci_attach()+0x147 device_attach()+0x69 bus_generic_attach()+0x1a acpi_pcib_attach()+0x1a7 acpi_pcib_acpi_attach()+0x1a5 device_attach()+0x69 bus_generic_attach()+0x1a acpi_attach()+0x9e4 device_attach()+0x69 bus_generic_attach()+0x1a device_attach()+0x69 root_bus_configure()+0x28 configure()+0xa mi_startup()+0x59 btext()+0x2c Relevant pciconf output: none1@pci0:0:27:0: class=0x040300 card=0x00011179 chip=0x293e8086 rev=0x03 hdr=0x00 vendor = 'Intel Corporation' device = '82801IB/IR/IH (ICH9 Family) HD Audio Controller' class = multimedia subclass = HDA cap 01[50] = powerspec 2 supports D0 D3 current D0 cap 05[60] = MSI supports 1 message, 64 bit cap 10[70] = PCI-Express 1 type 0 Any idea what the issue(s) might be? Cheers, Lawrence From owner-freebsd-current@FreeBSD.ORG Sun Mar 29 07:50: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 9E7C01065675 for ; Sun, 29 Mar 2009 07:50:23 +0000 (UTC) (envelope-from lstewart@room52.net) Received: from outbound.icp-qv1-irony-out4.iinet.net.au (outbound.icp-qv1-irony-out4.iinet.net.au [203.59.1.150]) by mx1.freebsd.org (Postfix) with ESMTP id 1891E8FC13 for ; Sun, 29 Mar 2009 07:50:22 +0000 (UTC) (envelope-from lstewart@room52.net) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAI/Ezkl8qF1T/2dsb2JhbAC7WwGNWIIsHAGBMQY X-IronPort-AV: E=Sophos;i="4.38,441,1233500400"; d="scan'208";a="332377691" Received: from unknown (HELO lawrence1.loshell.room52.net) ([124.168.93.83]) by outbound.icp-qv1-irony-out4.iinet.net.au with ESMTP; 29 Mar 2009 15:50:20 +0800 Message-ID: <49CF283C.6050003@room52.net> Date: Sun, 29 Mar 2009 18:50:20 +1100 From: Lawrence Stewart User-Agent: Thunderbird 2.0.0.21 (X11/20090326) MIME-Version: 1.0 To: Robert Noland References: <49CB70BD.3040607@boland.org> <1238086577.1792.30.camel@balrog.2hip.net> <49CC43C4.7030905@swin.edu.au> <1238126285.8491.2.camel@balrog.2hip.net> <179b97fb0903262114i511ec294ief17475d673e70c9@mail.gmail.com> <1238136987.8491.173.camel@balrog.2hip.net> <179b97fb0903270014u12e5fd10w46a18c36efa9ddf8@mail.gmail.com> <1238188110.8491.194.camel@balrog.2hip.net> In-Reply-To: <1238188110.8491.194.camel@balrog.2hip.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: Brandon Gooch , Michiel Boland , FreeBSD Current , Mattia Rossi Subject: Re: still problems with intel video 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, 29 Mar 2009 07:50:24 -0000 Robert Noland wrote: [snip] > > Ok, this is a complete patch against HEAD. It has even more debugging > around suspend/resume and also grabs the hardware lock when it starts to > suspend or resume. I'm tempted to just grab the lock when we start > suspend and not release it until resume is complete, but it looks like > something is triggering a vt switch and we could deadlock on that if I > don't drop the lock. I should be able to tell a little more from the > drm debug output of this patch. I'm having similar problems as described in this thread with 8-CURRENT amd64 r190518 on a Toshiba Portege R600 laptop which has a "Mobile Intel® GM45 Express Chipset". The machine is brand new and has been built using ports from scratch 2 days ago. Relevant pciconf output: vgapci1@pci0:0:2:1: class=0x038000 card=0x000c1179 chip=0x2a438086 rev=0x07 hdr=0x00 vendor = 'Intel Corporation' class = display cap 01[d0] = powerspec 3 supports D0 D3 current D0 With DRM MSI enabled, everything runs fine in kde4, but switching to console and back causes X to start running dog slow. On reboot/shutdown from kde, X doesn't die properly, and I get crazy psychedelic colours all over the LCD before reboot. Robert, I rejigged your patch to make it apply cleanly to r190518 (you can grab the new patch at the URL below) so that I could take it for a spin. I've created tons of debug output obtained with DRM_DEBUG in my kernel conf and with your patch. Grab the data along with some more general system info from: http://people.freebsd.org/~lstewart/misc/intel_debug/ Note that I start kdm at boot time from /etc/ttys. startup.txt captures debug output as X/kdm fire up. kdm_to_console.txt captures the debug output of a switch to console (ttyv1) from the kdm login prompt. console_to_kdm.txt captures the debug output of a switch from console (ttyv1) back to kdm login prompt on ttyv8. shutdown.txt captures debug output after I tell kdm to reboot the machine. This was done after the above 2 tests, so X is in the weird slow state. /var/log/messages says that X core dumps when it tries to shutdown. Running gdb on the core file yields some info. See Xorg_gdb.txt for the backtrace. I'm now set up to do any further debugging and patch testing on this machine so please let me know if there's anything I can do (beating Intel with a stick included). Cheers, Lawrence From owner-freebsd-current@FreeBSD.ORG Sun Mar 29 08:02: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 980701065678 for ; Sun, 29 Mar 2009 08:02:24 +0000 (UTC) (envelope-from mav@FreeBSD.org) Received: from cmail.optima.ua (cmail.optima.ua [195.248.191.121]) by mx1.freebsd.org (Postfix) with ESMTP id 21A588FC1D for ; Sun, 29 Mar 2009 08:02:23 +0000 (UTC) (envelope-from mav@FreeBSD.org) X-Spam-Flag: SKIP X-Spam-Yversion: Spamooborona-2.1.0 Received: from [212.86.226.226] (account mav@alkar.net HELO mavbook.mavhome.dp.ua) by cmail.optima.ua (CommuniGate Pro SMTP 5.2.9) with ESMTPSA id 238753930; Sun, 29 Mar 2009 11:02:23 +0300 Message-ID: <49CF2B0C.7050301@FreeBSD.org> Date: Sun, 29 Mar 2009 11:02:20 +0300 From: Alexander Motin User-Agent: Thunderbird 2.0.0.19 (X11/20090118) MIME-Version: 1.0 To: Lawrence Stewart References: <49CF0754.9070907@room52.net> In-Reply-To: <49CF0754.9070907@room52.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: kernel panic with snd_hda "panic: Duplicate free of item 0xffffff00025f8c00 from zone 0xffffff00b697d400(1024)" 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, 29 Mar 2009 08:02:25 -0000 Lawrence Stewart wrote: > I'm getting a kernel panic with the snd_hda driver on fresh 8-CURRENT > amd64 (r190518). I received this panic the other day when loading the > module from the command line on a slightly older kernel revision (I > think it was r190437). After putting the module load into > /boot/loader.conf, the problem didn't occur again and sound worked just > fine on subsequent reboots. > > A few minutes ago I installed the new r190518 kernel and now it panics > consistently with the same message every time. It also panics if I > unload the module at the loader prompt, boot the kernel and then kldload > on the command line. > > Hardware is a Toshiba Portege R600 laptop. Details below are hand > transcribed as the machine doesn't have a serial port. > > Relevant bit of verbose boot message when it panics: > > hdac0: at device 27.0 on > pci0 > hdac0: HDA driver revision: 20090316_0130 > hdac0: Lazy allocation of 0x4000 bytes rid 0x10 type 3 at 0xb69a4000 > hdac0: Reserved 0x4000 bytes for rid 0x10 type 3 at 0xb69a4000 > hdac0: attempting to allocate 1 MSI vectors (1 supported) > hdac0: using IRQ 257 for MSI > msi: Assinging MSI IRQ 257 to local APIC 0 vector 53 > hdac0: [MPSAFE] > hdac0: [ITHREAD] > hdac0: hdac_get_capabilities: Invalid corb size (0) > device_attach: hdac0 attach returned 6 > Slab at 0xffffff00025d5b18, freei 3 = 0. > panic: Duplicate free of item 0xffffff00025f8c00 from zone > 0xffffff00b697d400(1024) > > Any idea what the issue(s) might be? I can't reproduce neither "Invalid corb size (0)" error, nor the crash in case of it. I have tried to simulate that error, but system handled it correctly. But I have INVARIANTS disabled on my system. Can you try to disable MSI? Can you try to move hdac_irq_alloc() call after hdac_rirb_init() in hdac_attach()? May be interrupt shots while something is not yet initialized? -- Alexander Motin From owner-freebsd-current@FreeBSD.ORG Sun Mar 29 08:19: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 9F157106564A for ; Sun, 29 Mar 2009 08:19:46 +0000 (UTC) (envelope-from matthias.apitz@oclc.org) Received: from hunter.Sisis.de (hunter.sisis.de [193.31.11.194]) by mx1.freebsd.org (Postfix) with ESMTP id F17BA8FC08 for ; Sun, 29 Mar 2009 08:19:45 +0000 (UTC) (envelope-from matthias.apitz@oclc.org) Received: (from mail@localhost) by hunter.Sisis.de (8.8.8/8.8.8) id KAA11580 for ; Sun, 29 Mar 2009 10:10:05 +0200 (CEST) (envelope-from matthias.apitz@oclc.org) Received: from ppp-93-104-107-0.dynamic.mnet-online.de(93.104.107.0) by hunter.Sisis.de via smap (V2.1) id xma011572; Sun, 29 Mar 09 10:10:04 +0200 Received: (from guru@localhost) by rebelion.Sisis.de (8.14.2/8.13.8/Submit) id n2T8JgMt004924 for freebsd-current@freebsd.org; Sun, 29 Mar 2009 10:19:42 +0200 (CEST) (envelope-from matthias.apitz@oclc.org) X-Authentication-Warning: rebelion.Sisis.de: guru set sender to matthias.apitz@oclc.org using -f Date: Sun, 29 Mar 2009 10:19:42 +0200 From: Matthias Apitz To: freebsd-current@freebsd.org Message-ID: <20090329081942.GA4731@rebelion.Sisis.de> References: <20090328131724.GA11667@rebelion.Sisis.de> <3a142e750903280740j7120b896r40671c8c535922b4@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <3a142e750903280740j7120b896r40671c8c535922b4@mail.gmail.com> User-Agent: Mutt/1.4.2.3i X-Operating-System: FreeBSD 7.0-STABLE (i386) Subject: Re: missing lkm if_ppp in CURRENT 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, 29 Mar 2009 08:19:46 -0000 El día Saturday, March 28, 2009 a las 03:40:46PM +0100, Paul B. Mahol escribió: > On 3/28/09, Matthias Apitz wrote: > > > > Hi, > > > > What is the correct way to get the module if_ppp build during > > "make buildkernel KERNCONF=GENERIC"? > > thx > > None. Use userland ppp instead. > More about why is available via mailing list archive .... This is just to ACK that userland ppp works fine in CURRENT with the Huawei E220 USB datacard using the u3g / ucom drivers. Thx for the hint. Maybe the port net/pppd23 should be removed or marked as unusable. matthias -- Matthias Apitz Manager Technical Support - OCLC GmbH Gruenwalder Weg 28g - 82041 Oberhaching - Germany t +49-89-61308 351 - f +49-89-61308 399 - m +49-170-4527211 e - w http://www.oclc.org/ http://www.UnixArea.de/ From owner-freebsd-current@FreeBSD.ORG Sun Mar 29 10:32: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 4FFAF106566C for ; Sun, 29 Mar 2009 10:32:26 +0000 (UTC) (envelope-from kris@FreeBSD.org) Received: from kennaway-macbookpro.config (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id B0B5D8FC0A; Sun, 29 Mar 2009 10:32:25 +0000 (UTC) (envelope-from kris@FreeBSD.org) Message-ID: <49CF4E39.4010905@FreeBSD.org> Date: Sun, 29 Mar 2009 11:32:25 +0100 From: Kris Kennaway User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: Wenji Wu References: <49CE231C.9080609@FreeBSD.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: LOCK_PROFILING does not work on FreeBSD 8.0-CURRENT 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, 29 Mar 2009 10:32:26 -0000 Wenji Wu wrote: >> It certainly does work in 8.0. Is it possible you forgot to install >> the >> rebuilt kernel? > > I have rebuilt everything (rebuild the world), just does not work for me. But if it works for you, i will retry to see what is going on. Rebuilding the kernel (or world) only prepares a new version, it doesn't reinstall it. Unless you ran a separate 'make installkernel' you are still running the old kernel. You can confirm by looking at uname -a and checking the time when the running kernel was compiled. Kris From owner-freebsd-current@FreeBSD.ORG Sun Mar 29 11:22: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 3CEEC1065679 for ; Sun, 29 Mar 2009 11:22:10 +0000 (UTC) (envelope-from barney_cordoba@yahoo.com) Received: from web63906.mail.re1.yahoo.com (web63906.mail.re1.yahoo.com [69.147.97.121]) by mx1.freebsd.org (Postfix) with SMTP id 34D078FC29 for ; Sun, 29 Mar 2009 11:22:08 +0000 (UTC) (envelope-from barney_cordoba@yahoo.com) Received: (qmail 82606 invoked by uid 60001); 29 Mar 2009 11:22:07 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1238325727; bh=rlXhMZAceY2t4x3FLD9CbqPoPFsa8jWsSrrdGFqRFyM=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=YKc3oQ5cjOLL2xBduNGf5urKUu65qGUojIAm2LrJLyeOBgI7GePO2UZi4p+Z9Cz6Nu3l9v/uMyJOuKxuUTRieg4MqsiH65DQJ5t76zPvf2bh/UMZw9c7w6EiuOpjXyO62Gb1/6geZQ+TZpyWJPwzf364EJEq05xiVOpxWrslZrE= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=peq8WDpeT++NSeSL/y4D8bAOTc/DduAfrKpgJ9FRlo2wTIWRzd+MpWreca0djLtqSDJoc1UjYuosALa2x+/tp2uXRlF3t+fe6ptgVq6xVfFb2BMvLWQM2nzxpwI4zhXArNi7VVp3D2kbwc34piKMNZ9HHOHEldkL9xboWEHLzj8=; Message-ID: <567571.80318.qm@web63906.mail.re1.yahoo.com> X-YMail-OSG: 1.cz76wVM1m_8yp5G4TAsKVOikh_B1oUXJdvCnJN5LsbI1TtPPrlYUTyGMXoLMWQf1VxWp6.Zdh7FqYCJRHxU8XOzcY6BOymkxGElIlm2UuWeeUG1hCAptxFE4C13VYL146pnRiAEeQwDIedJ12IRWw_pcxFhK.lAdYf3wNN0F7sKpjzxBmXoizSpoPYdHd2ggpFlK5utMbFy9RxTn0GaSq2zkgo_aCSFM.7ucFBVgTWeg21BZZiog-- Received: from [98.242.222.229] by web63906.mail.re1.yahoo.com via HTTP; Sun, 29 Mar 2009 04:22:07 PDT X-Mailer: YahooMailWebService/0.7.289.1 Date: Sun, 29 Mar 2009 04:22:07 -0700 (PDT) From: Barney Cordoba To: freebsd-current@freebsd.org, Jakub Lach In-Reply-To: <22759116.post@talk.nabble.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Subject: Re: ACPI error X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: barney_cordoba@yahoo.com List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Mar 2009 11:22:10 -0000 --- On Sat, 3/28/09, Jakub Lach wrote: > From: Jakub Lach > Subject: Re: ACPI error > To: freebsd-current@freebsd.org > Date: Saturday, March 28, 2009, 1:12 PM > Barney Cordoba wrote: > > > > > > I'm getting an APIC error: > > > > kernel: ACPI Error (tbxfroot-0308): A valid RSDP was > not found [20070320] > > kernel: ACPI: Table initialisation failed: > AE_NOT_FOUND > > kernel: ACPI: Try disabling either ACPI or apic > support. > > > > Is there any hope for this? Unfortunately with ACPI > off, the Hard Drive > > is found at ad6 where its found at ad8 on 7, so > upgrading on this box > > will be more painful than usual. > > > > Its a relatively new (intel bigby) chipset. > > > > Barney > > They all seem older than the chipset. Wouldn't these fixes have been commited already? Barney From owner-freebsd-current@FreeBSD.ORG Sun Mar 29 11:39: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 0357B1065698 for ; Sun, 29 Mar 2009 11:39:26 +0000 (UTC) (envelope-from bounces@nabble.com) Received: from kuber.nabble.com (kuber.nabble.com [216.139.236.158]) by mx1.freebsd.org (Postfix) with ESMTP id 753A68FC16 for ; Sun, 29 Mar 2009 11:39:25 +0000 (UTC) (envelope-from bounces@nabble.com) Received: from isper.nabble.com ([192.168.236.156]) by kuber.nabble.com with esmtp (Exim 4.63) (envelope-from ) id 1LntMK-0004S7-E2 for freebsd-current@freebsd.org; Sun, 29 Mar 2009 04:39:24 -0700 Message-ID: <22766687.post@talk.nabble.com> Date: Sun, 29 Mar 2009 04:39:24 -0700 (PDT) From: Jakub Lach To: freebsd-current@freebsd.org In-Reply-To: <567571.80318.qm@web63906.mail.re1.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Nabble-From: jakub_lach@mailplus.pl References: <511792.14022.qm@web63903.mail.re1.yahoo.com> <22759116.post@talk.nabble.com> <567571.80318.qm@web63906.mail.re1.yahoo.com> Subject: Re: ACPI error 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, 29 Mar 2009 11:39:27 -0000 Commited ACPICA is from [20070320] Latest jkim's patch - http://people.freebsd.org/~jkim/acpica-import-20090320.diff.gz More about [20090320] http://www.nabble.com/ACPICA-version-20090320-released-td22628135.html#a22628135 I'm using it now. Barney Cordoba wrote: > > > --- On Sat, 3/28/09, Jakub Lach wrote: > >> From: Jakub Lach >> Subject: Re: ACPI error >> To: freebsd-current@freebsd.org >> Date: Saturday, March 28, 2009, 1:12 PM >> Barney Cordoba wrote: >> > >> > >> > I'm getting an APIC error: >> > >> > kernel: ACPI Error (tbxfroot-0308): A valid RSDP was >> not found [20070320] >> > kernel: ACPI: Table initialisation failed: >> AE_NOT_FOUND >> > kernel: ACPI: Try disabling either ACPI or apic >> support. >> > >> > Is there any hope for this? Unfortunately with ACPI >> off, the Hard Drive >> > is found at ad6 where its found at ad8 on 7, so >> upgrading on this box >> > will be more painful than usual. >> > >> > Its a relatively new (intel bigby) chipset. >> > >> > Barney >> > > > They all seem older than the chipset. Wouldn't these fixes have been > commited already? > > Barney > > > > _______________________________________________ > 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" > > -- View this message in context: http://www.nabble.com/ACPI-error-tp22756817p22766687.html Sent from the freebsd-current mailing list archive at Nabble.com. From owner-freebsd-current@FreeBSD.ORG Sun Mar 29 12:25: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 4F9A81065678 for ; Sun, 29 Mar 2009 12:25:45 +0000 (UTC) (envelope-from mav@FreeBSD.org) Received: from cmail.optima.ua (cmail.optima.ua [195.248.191.121]) by mx1.freebsd.org (Postfix) with ESMTP id CAF978FC17 for ; Sun, 29 Mar 2009 12:25:44 +0000 (UTC) (envelope-from mav@FreeBSD.org) X-Spam-Flag: SKIP X-Spam-Yversion: Spamooborona-2.1.0 Received: from [212.86.226.226] (account mav@alkar.net HELO mavbook.mavhome.dp.ua) by cmail.optima.ua (CommuniGate Pro SMTP 5.2.9) with ESMTPSA id 238762858; Sun, 29 Mar 2009 15:25:43 +0300 Message-ID: <49CF68C4.8020806@FreeBSD.org> Date: Sun, 29 Mar 2009 15:25:40 +0300 From: Alexander Motin User-Agent: Thunderbird 2.0.0.19 (X11/20090118) MIME-Version: 1.0 To: Lawrence Stewart References: <49CF0754.9070907@room52.net> <49CF2B0C.7050301@FreeBSD.org> <49CF6551.4080301@room52.net> In-Reply-To: <49CF6551.4080301@room52.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: kernel panic with snd_hda "panic: Duplicate free of item 0xffffff00025f8c00 from zone 0xffffff00b697d400(1024)" 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, 29 Mar 2009 12:25:45 -0000 Lawrence Stewart wrote: > Alexander Motin wrote: >> I can't reproduce neither "Invalid corb size (0)" error, nor the crash >> in case of it. I have tried to simulate that error, but system handled >> it correctly. But I have INVARIANTS disabled on my system. >> >> Can you try to disable MSI? > > Setting hw.pci.enable_msix=0 and hw.pci.enable_msi=0 at the loader > prompt made no difference. It could also be done with hint.hdac.0.msi=0. >> Can you try to move hdac_irq_alloc() call after hdac_rirb_init() in >> hdac_attach()? May be interrupt shots while something is not yet >> initialized? > > Running with the following patch made no difference either. > > Any other ideas I could try? I have none. I haven't changed anything significant last time, except enabling MSI. You can try to investigate both problems: original "Invalid corb size (0)" and the consequent crash. As I have said, I can't reproduce none of them. Try to put some debug printfs inside hdac_get_capabilities(), may be it give some new clues. -- Alexander Motin From owner-freebsd-current@FreeBSD.ORG Sun Mar 29 12:40: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 6DB2010656CA for ; Sun, 29 Mar 2009 12:40:31 +0000 (UTC) (envelope-from lstewart@room52.net) Received: from outbound.icp-qv1-irony-out2.iinet.net.au (outbound.icp-qv1-irony-out2.iinet.net.au [203.59.1.107]) by mx1.freebsd.org (Postfix) with ESMTP id E13928FC23 for ; Sun, 29 Mar 2009 12:40:30 +0000 (UTC) (envelope-from lstewart@room52.net) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEADMCz0l8qF1T/2dsb2JhbADIf4N6Bg X-IronPort-AV: E=Sophos;i="4.38,441,1233500400"; d="scan'208";a="457664170" Received: from unknown (HELO lawrence1.loshell.room52.net) ([124.168.93.83]) by outbound.icp-qv1-irony-out2.iinet.net.au with ESMTP; 29 Mar 2009 20:10:58 +0800 Message-ID: <49CF6551.4080301@room52.net> Date: Sun, 29 Mar 2009 23:10:57 +1100 From: Lawrence Stewart User-Agent: Thunderbird 2.0.0.21 (X11/20090326) MIME-Version: 1.0 To: Alexander Motin References: <49CF0754.9070907@room52.net> <49CF2B0C.7050301@FreeBSD.org> In-Reply-To: <49CF2B0C.7050301@FreeBSD.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: kernel panic with snd_hda "panic: Duplicate free of item 0xffffff00025f8c00 from zone 0xffffff00b697d400(1024)" 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, 29 Mar 2009 12:40:32 -0000 Alexander Motin wrote: > Lawrence Stewart wrote: >> I'm getting a kernel panic with the snd_hda driver on fresh 8-CURRENT >> amd64 (r190518). I received this panic the other day when loading the >> module from the command line on a slightly older kernel revision (I >> think it was r190437). After putting the module load into >> /boot/loader.conf, the problem didn't occur again and sound worked >> just fine on subsequent reboots. >> >> A few minutes ago I installed the new r190518 kernel and now it panics >> consistently with the same message every time. It also panics if I >> unload the module at the loader prompt, boot the kernel and then >> kldload on the command line. >> >> Hardware is a Toshiba Portege R600 laptop. Details below are hand >> transcribed as the machine doesn't have a serial port. >> >> Relevant bit of verbose boot message when it panics: >> >> hdac0: at device 27.0 on >> pci0 >> hdac0: HDA driver revision: 20090316_0130 >> hdac0: Lazy allocation of 0x4000 bytes rid 0x10 type 3 at 0xb69a4000 >> hdac0: Reserved 0x4000 bytes for rid 0x10 type 3 at 0xb69a4000 >> hdac0: attempting to allocate 1 MSI vectors (1 supported) >> hdac0: using IRQ 257 for MSI >> msi: Assinging MSI IRQ 257 to local APIC 0 vector 53 >> hdac0: [MPSAFE] >> hdac0: [ITHREAD] >> hdac0: hdac_get_capabilities: Invalid corb size (0) >> device_attach: hdac0 attach returned 6 >> Slab at 0xffffff00025d5b18, freei 3 = 0. >> panic: Duplicate free of item 0xffffff00025f8c00 from zone >> 0xffffff00b697d400(1024) >> >> Any idea what the issue(s) might be? > > I can't reproduce neither "Invalid corb size (0)" error, nor the crash > in case of it. I have tried to simulate that error, but system handled > it correctly. But I have INVARIANTS disabled on my system. > > Can you try to disable MSI? Setting hw.pci.enable_msix=0 and hw.pci.enable_msi=0 at the loader prompt made no difference. > > Can you try to move hdac_irq_alloc() call after hdac_rirb_init() in > hdac_attach()? May be interrupt shots while something is not yet > initialized? > Running with the following patch made no difference either. lstewart-laptop# svn diff dev/sound/pci/hda/hdac.c Index: dev/sound/pci/hda/hdac.c =================================================================== --- dev/sound/pci/hda/hdac.c (revision 190518) +++ dev/sound/pci/hda/hdac.c (working copy) @@ -4145,9 +4145,6 @@ result = hdac_mem_alloc(sc); if (result != 0) goto hdac_attach_fail; - result = hdac_irq_alloc(sc); - if (result != 0) - goto hdac_attach_fail; /* Get Capabilities */ result = hdac_get_capabilities(sc); @@ -4174,6 +4171,10 @@ hdac_corb_init(sc); hdac_rirb_init(sc); + result = hdac_irq_alloc(sc); + if (result != 0) + goto hdac_attach_fail; + /* Defer remaining of initialization until interrupts are enabled */ sc->intrhook.ich_func = hdac_attach2; sc->intrhook.ich_arg = (void *)sc; Any other ideas I could try? Cheers, Lawrence From owner-freebsd-current@FreeBSD.ORG Sun Mar 29 12:44: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 4478B1065674; Sun, 29 Mar 2009 12:44:16 +0000 (UTC) (envelope-from yanefbsd@gmail.com) Received: from mxout5.cac.washington.edu (mxout5.cac.washington.edu [140.142.32.135]) by mx1.freebsd.org (Postfix) with ESMTP id 1B9878FC18; Sun, 29 Mar 2009 12:44:16 +0000 (UTC) (envelope-from yanefbsd@gmail.com) Received: from smtp.washington.edu (smtp.washington.edu [140.142.32.141] (may be forged)) by mxout5.cac.washington.edu (8.14.3+UW09.03/8.14.3+UW09.01) with ESMTP id n2TCiFdm017303 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sun, 29 Mar 2009 05:44:15 -0700 X-Auth-Received: from [192.168.10.7] (adsl-99-170-148-155.dsl.pltn13.sbcglobal.net [99.170.148.155]) (authenticated authid=youshi10) by smtp.washington.edu (8.14.3+UW09.03/8.14.3+UW09.01) with ESMTP id n2TCiEZ1002358 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Sun, 29 Mar 2009 05:44:15 -0700 Message-Id: From: Garrett Cooper To: FreeBSD Current Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Sun, 29 Mar 2009 05:50:24 -0700 X-Mailer: Apple Mail (2.930.3) X-PMX-Version: 5.5.3.366731, Antispam-Engine: 2.7.0.366912, Antispam-Data: 2009.3.29.123124 X-Uwash-Spam: Gauge=IIIIIII, Probability=8%, Report='FORGED_FROM_GMAIL 0.1, BODY_SIZE_2000_2999 0, BODY_SIZE_5000_LESS 0, BODY_SIZE_7000_LESS 0, __CT 0, __CTE 0, __CT_TEXT_PLAIN 0, __FRAUD_419_WEBMAIL 0, __FRAUD_419_WEBMAIL_FROM 0, __FROM_GMAIL 0, __HAS_MSGID 0, __HAS_X_MAILER 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __PHISH_SPEAR_STRUCTURE_1 0, __SANE_MSGID 0' Cc: Garrett Cooper Subject: Stability issues / UFS based panic on recent CURRENT (03/22) 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, 29 Mar 2009 12:44:16 -0000 Hi guys, I'm noticing some stability issues in recent days with two cases: 1. I typically use vuze / xchat2, and when I bring the network interfaces down once, and poll a few times (ifconfig msk0) my system freezes, which forces me to reboot. Don't have any hard data right now, but I hit this ~10% of the time. 2. It takes about 15 minutes to fsck my entire system and sometimes I get impatient and startup x11 right away. Unfortunately when I was opening up my browser, my system froze again and subsequently panicked with UFS related tracebacks. Here's the output: [root@orangebox /scratch/crash]# kgdb /boot/kernel/kernel vmcore.3 GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i386-marcel-freebsd"... Unread portion of the kernel message buffer: dev = ad6s1g, block = 1446736, fs = /usr/home panic: ffs_blkfree: freeing free block cpuid = 1 Uptime: 32m29s Physical memory: 3318 MB Dumping 140 MB: 125 109 93 77 61 45 29 13 Reading symbols from /boot/kernel/vesa.ko...Reading symbols from /boot/ kernel/vesa.ko.symbols...done. done. Loaded symbols for /boot/kernel/vesa.ko #0 doadump () at pcpu.h:246 246 pcpu.h: No such file or directory. in pcpu.h (kgdb) bt #0 doadump () at pcpu.h:246 #1 0xc0620508 in boot (howto=260) at /usr/src/sys/kern/ kern_shutdown.c:420 #2 0xc06207ee in panic (fmt=Variable "fmt" is not available. ) at /usr/src/sys/kern/kern_shutdown.c:576 #3 0xc079e62a in ffs_blkfree (ump=0xc6c0bc00, fs=0xc6acc800, devvp=0xc6c50c90, bno=1446736, size=16384, inum=354012) at /usr/src/ sys/ufs/ffs/ffs_alloc.c:1914 #4 0xc07b1df2 in indir_trunc (freeblks=0xc7127b00, dbn=5737856, level=0, lbn=12, countp=0xe6c83c54) at /usr/src/sys/ufs/ffs/ ffs_softdep.c:2919 #5 0xc07b2057 in handle_workitem_freeblocks (freeblks=0xc7127b00, flags=0) at /usr/src/sys/ufs/ffs/ffs_softdep.c:2768 #6 0xc07b3618 in process_worklist_item (mp=0xc6bfda00, flags=Variable "flags" is not available. ) at /usr/src/sys/ufs/ffs/ffs_softdep.c:957 #7 0xc07b8662 in softdep_process_worklist (mp=0xc6bfda00, full=0) at / usr/src/sys/ufs/ffs/ffs_softdep.c:840 #8 0xc07b8c55 in softdep_flush () at /usr/src/sys/ufs/ffs/ ffs_softdep.c:751 #9 0xc05ff1f1 in fork_exit (callout=0xc07b8967 , arg=0x0, frame=0xe6c83d38) at /usr/src/sys/kern/kern_fork.c:821 #10 0xc082c350 in fork_trampoline () at /usr/src/sys/i386/i386/ exception.s:270 I'll be glad to provide additional data -- please CC my FreeBSD alias so I can keep track of when folks email me as this mailing address gets a fair amount of traffic. Thanks! -Garrett From owner-freebsd-current@FreeBSD.ORG Sun Mar 29 13:30: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 0C1D0106567A for ; Sun, 29 Mar 2009 13:30:45 +0000 (UTC) (envelope-from gavin.atkinson@ury.york.ac.uk) Received: from mail-gw1.york.ac.uk (mail-gw1.york.ac.uk [144.32.128.246]) by mx1.freebsd.org (Postfix) with ESMTP id 77D2A8FC15 for ; Sun, 29 Mar 2009 13:30:44 +0000 (UTC) (envelope-from gavin.atkinson@ury.york.ac.uk) Received: from mail-gw6.york.ac.uk (mail-gw6.york.ac.uk [144.32.129.26]) by mail-gw1.york.ac.uk (8.13.6/8.13.6) with ESMTP id n2TCxExD008101; Sun, 29 Mar 2009 13:59:14 +0100 (BST) Received: from ury.york.ac.uk ([144.32.108.81]) by mail-gw6.york.ac.uk with esmtps (TLSv1:AES256-SHA:256) (Exim 4.68) (envelope-from ) id 1LnubZ-0004Af-VM; Sun, 29 Mar 2009 13:59:13 +0100 Received: from ury.york.ac.uk (localhost.york.ac.uk [127.0.0.1]) by ury.york.ac.uk (8.14.3/8.14.3) with ESMTP id n2TCxDPR059849; Sun, 29 Mar 2009 13:59:13 +0100 (BST) (envelope-from gavin.atkinson@ury.york.ac.uk) Received: from localhost (gavin@localhost) by ury.york.ac.uk (8.14.3/8.14.3/Submit) with ESMTP id n2TCxDjV059846; Sun, 29 Mar 2009 13:59:13 +0100 (BST) (envelope-from gavin.atkinson@ury.york.ac.uk) X-Authentication-Warning: ury.york.ac.uk: gavin owned process doing -bs Date: Sun, 29 Mar 2009 13:59:13 +0100 (BST) From: Gavin Atkinson X-X-Sender: gavin@ury.york.ac.uk To: Mars G Miro In-Reply-To: Message-ID: <20090329135724.A13940@ury.york.ac.uk> References: MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="0-1304052899-1238331553=:13940" X-York-MailScanner: Found to be clean X-York-MailScanner-From: gavin.atkinson@ury.york.ac.uk Cc: freebsd-current@freebsd.org Subject: Re: booting from SATA DVD-RAM, no go 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, 29 Mar 2009 13:30:45 -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. --0-1304052899-1238331553=:13940 Content-Type: TEXT/PLAIN; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: QUOTED-PRINTABLE On Sat, 28 Mar 2009, Mars G Miro wrote: > On Sat, Mar 28, 2009 at 9:21 PM, Mars G Miro wro= te: >> Hi guys >> >> =A0 It just does: >> ... >> Building the boot loader arguments >> Looking up /BOOT/LOADER... Found >> Relocating the loader and the BTX >> ... >> >> =A0Then the screen goes blank. I've tried setting AHCI and unsetting it >> (IDE mode), still no go. Tried the 7-STABLE / 8-CURRENT (amd64) >> snapshots from February. >> >> =A0This is on an LG GH22LS40 on a Gigabyte MA78GM-S2H mobo w/ the latest >> BIOS from their website. >> >> =A0Clues? I'll prolly plug an old CD-ROM just to install FreeBSD on it. = Thanks. >> > > rrrrrrrrrr. plugging in an old CD-ROM still gives me the same thing. > > Next stop: PXE, or just install FreeBSD on the HD in a separate > machine altogether ... This was probably fixed by the most recent commits to=20 src/sys/boot/i386/libi386/bioscd.c - they were done within the last couple= =20 of weeks, so the March snapshot may well have these changes included. Gavin --0-1304052899-1238331553=:13940-- From owner-freebsd-current@FreeBSD.ORG Sun Mar 29 15:34: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 AD354106564A for ; Sun, 29 Mar 2009 15:34:33 +0000 (UTC) (envelope-from barney_cordoba@yahoo.com) Received: from web63907.mail.re1.yahoo.com (web63907.mail.re1.yahoo.com [69.147.97.122]) by mx1.freebsd.org (Postfix) with SMTP id 58D4D8FC08 for ; Sun, 29 Mar 2009 15:34:32 +0000 (UTC) (envelope-from barney_cordoba@yahoo.com) Received: (qmail 38086 invoked by uid 60001); 29 Mar 2009 15:34:32 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1238340872; bh=+gWe+TfcTl2UxrL2X/pQQSQgedVHhw/umRZz20SBnSg=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=OsFPQ3UnjUc4eVKDgky3iOC87GR75nPL1ATXYn0JReEWK9yhzxNUZpMm6croc3zcxLGMFGIq4951Fvke1KpgFUZG1B9XVfssfTU1Vc+ojMOu2Zpk5GOgBKBBnHK3yLpqNCzzAPU5UhGcsG2xMVyMVp6Iiiu2b/AFw1MlAJ0bPZM= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=iO7yTgBSh//IatwuctISSPw+RUMLoi1rOfU//bdUPNIe/N2lU9w1U6KuH2aNGUfmt+kdr1r0uHMsbeojVGDjBB6u7q4dqYS9w3NYjkTQewiboxn3dUBmkgo2o9NdNm1sGvWRNlKtBjmV2Crx/mJuMlmH8sSHOOlefbHvIkMf00Q=; Message-ID: <513261.38032.qm@web63907.mail.re1.yahoo.com> X-YMail-OSG: 9htqcpIVM1nB3aO0wC7WwAdsm8krbqp0ShQNI3zxnoFPps_UQioDAC3nSi8IvpdJ0qifSUvsYe_9NSv6.M9rWfpNiHwYke.RSa3sqYTCSQXxpf0cAJGqbaRq_tuXETW30lNkvI3W3UsE4qoGOGFQYBWTvNoUUfghMezZ3LGJz.DBHBpV8b4OcxmP9KTQ_1WnTmAtlPBMY3mzLXdwSd26AYoV8UXZ3enT_NBhYyDCNMI4fEEXCxeUtA-- Received: from [98.242.222.229] by web63907.mail.re1.yahoo.com via HTTP; Sun, 29 Mar 2009 08:34:32 PDT X-Mailer: YahooMailWebService/0.7.289.1 Date: Sun, 29 Mar 2009 08:34:32 -0700 (PDT) From: Barney Cordoba To: current@freebsd.org In-Reply-To: <706191.48959.qm@web63902.mail.re1.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Subject: pci_alloc_resource is broken X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: barney_cordoba@yahoo.com List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Mar 2009 15:34:34 -0000 --- On Sat, 3/28/09, Barney Cordoba wrote: > From: Barney Cordoba > Subject: Re: Bus Resource busy panic > To: current@freebsd.org > Date: Saturday, March 28, 2009, 8:03 PM > --- On Sat, 3/28/09, Barney Cordoba > wrote: > > > From: Barney Cordoba > > Subject: Bus Resource busy panic > > To: current@freebsd.org > > Date: Saturday, March 28, 2009, 6:35 PM > > I have a situation that results in a panic in 8 that > runs > > happily in 7. > > Its a bus_alloc_resource of type SYS_RES_MEMORY that > is > > used by 2 > > separate devices. > > > > I see there is an RF_SHAREABLE flag. That flag > hadn't > > been set, but is there > > something in 8 that now requires it? > > > > As a side question, should a bus_alloc_resource call > panic > > the system just > > because the resource is busy? > > > > Barney > > Some more info on this. The panic is in > resource_list_alloc() and > setting SHAREABLE doesn't fix it. I see the same code > in 7 so > I'm not sure why it would work in 7 and not 8. > > Basically there are 2 devices that need to do IO on a > board, and they > are both doing > > bus_alloc_resource_any(dev, SYS_RES_MEMORY,&rid, > RF_ACTIVE); > > > Barney > I'm not sure if anyone was reading the original thread, so I created another with my results. Someone broke pci_alloc_resource. In the SYS_RES_MEMORY case, when rman_get_device() != dev (but rle->res is set), it erroneously falls to resource_list_alloc which will panic on device resource busy. It seems that this would preclude the sharing of a resource, as any secondary request will not only fail, but panic the system Barney From owner-freebsd-current@FreeBSD.ORG Sun Mar 29 16:29: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 35FBF1065670; Sun, 29 Mar 2009 16:29:16 +0000 (UTC) (envelope-from kientzle@freebsd.org) Received: from kientzle.com (kientzle.com [66.166.149.50]) by mx1.freebsd.org (Postfix) with ESMTP id 93A588FC12; Sun, 29 Mar 2009 16:29:15 +0000 (UTC) (envelope-from kientzle@freebsd.org) Received: (from root@localhost) by kientzle.com (8.14.3/8.14.3) id n2TGTE3M077021; Sun, 29 Mar 2009 09:29:14 -0700 (PDT) (envelope-from kientzle@freebsd.org) Received: from dark.x.kientzle.com (fw2.kientzle.com [10.123.1.2]) by kientzle.com with SMTP id i3ppnv34i4ppvntihnffqip43a; Sun, 29 Mar 2009 09:29:14 -0700 (PDT) (envelope-from kientzle@freebsd.org) Message-ID: <49CFA1D9.1020604@freebsd.org> Date: Sun, 29 Mar 2009 09:29:13 -0700 From: Tim Kientzle User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.8.1.19) Gecko/20090226 SeaMonkey/1.1.14 MIME-Version: 1.0 To: Pawel Jakub Dawidek References: <20090312175345.Y80227@rust.salford.ac.uk> <20090312191333.GA97342@hyperion.scode.org> <49B97617.8010709@freebsd.org> <86r6124f2v.fsf@gmail.com> <3bbf2fe10903122035i20b2767cod2322c39c6f850ee@mail.gmail.com> <29C8FA04-D5B1-49B7-ACF0-4185537367B0@baldwin.cx> <3bbf2fe10903122156u650417f0s5c49b68bdf4ffa07@mail.gmail.com> <49BA9801.5080505@FreeBSD.org> <49BAA103.2060508@FreeBSD.org> <20090317070440.GE2012@garage.freebsd.pl> In-Reply-To: <20090317070440.GE2012@garage.freebsd.pl> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Attilio Rao , "freebsd-current@freebsd.org" , Mark Powell , Anonymous , Peter Schuller Subject: Re: repeatable ZFS panic: share->excl 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, 29 Mar 2009 16:29:16 -0000 Pawel Jakub Dawidek wrote: > On Fri, Mar 13, 2009 at 02:08:03PM -0400, John Baldwin wrote: >> John Baldwin wrote: >>> Yes, I think that is the real bug. Looking at this further I think >>> zfs_get_xattrdir() will return the vnode locked if it has to create a >>> new node via zfs_make_attrdir() but only returns it held and unlocked if >>> it finds an existing one. So my new patch is to just fix >>> zfs_get_xattrdir() to unlock the vnode if it creates a new one like so: >>> >>> (Sorry, TBird is probably going to butcher all the whitespace): >>> >>> --- >>> //depot/user/jhb/lock/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_dir.c >>> +++ >>> /Users/jhb/work/p4/lock/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_dir.c >>> >>> @@ -940,6 +940,7 @@ >>> /* NB: we already did dmu_tx_wait() if necessary */ >>> goto top; >>> } >>> + VOP_UNLOCK(*xvpp, 0); >>> >>> return (error); >>> } >>> >>> A non-butchered version is at www.FreeBSD.org/~jhb/patches/zfs_ea.patch. >> So lulf@ reports success with this patch. Pawel, can you review it? > > Yes, it works for me too and looks good. The only thing we need to > change is to check for error beeing 0 before unlocking the vnode. > The zfs_make_xattrdir() function can still return with EIO, so I'd add > something like this: > > if (error == 0) > VOP_UNLOCK(*xvpp, 0); > > Thank you John for spending time on tracking this one down. Any estimate on when this can be committed? I'm waiting to re-enable the extended attribute archiving support in tar until this is fixed. Tim From owner-freebsd-current@FreeBSD.ORG Sun Mar 29 18:07: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 508BB106566C; Sun, 29 Mar 2009 18:07:50 +0000 (UTC) (envelope-from peterjeremy@optushome.com.au) Received: from mail15.syd.optusnet.com.au (mail15.syd.optusnet.com.au [211.29.132.196]) by mx1.freebsd.org (Postfix) with ESMTP id D3D108FC08; Sun, 29 Mar 2009 18:07:49 +0000 (UTC) (envelope-from peterjeremy@optushome.com.au) Received: from server.vk2pj.dyndns.org (c122-106-216-167.belrs3.nsw.optusnet.com.au [122.106.216.167]) by mail15.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id n2TI7kiV007380 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 30 Mar 2009 05:07:47 +1100 X-Bogosity: Ham, spamicity=0.000000 Received: from server.vk2pj.dyndns.org (localhost.vk2pj.dyndns.org [127.0.0.1]) by server.vk2pj.dyndns.org (8.14.3/8.14.3) with ESMTP id n2TI7knH025279; Mon, 30 Mar 2009 05:07:46 +1100 (EST) (envelope-from peter@server.vk2pj.dyndns.org) Received: (from peter@localhost) by server.vk2pj.dyndns.org (8.14.3/8.14.3/Submit) id n2TI7je1025278; Mon, 30 Mar 2009 05:07:45 +1100 (EST) (envelope-from peter) Date: Mon, 30 Mar 2009 05:07:45 +1100 From: Peter Jeremy To: Alexander Sack Message-ID: <20090329180745.GB38985@server.vk2pj.dyndns.org> References: <49CD0405.1060704@samsco.org> <5739.1238175087@critter.freebsd.dk> <3c0b01820903271119l4161c7b8yf74613b184add487@mail.gmail.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="ADZbWkCsHQ7r3kzd" Content-Disposition: inline In-Reply-To: <3c0b01820903271119l4161c7b8yf74613b184add487@mail.gmail.com> X-PGP-Key: http://members.optusnet.com.au/peterjeremy/pubkey.asc User-Agent: Mutt/1.5.19 (2009-01-05) Cc: FreeBSD Hackers , freebsd-current@freebsd.org, prashant.vaibhav@gmail.com Subject: Re: Improving the kernel/i386 timecounter performance (GSoC proposal) 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, 29 Mar 2009 18:07:50 -0000 --ADZbWkCsHQ7r3kzd Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 2009-Mar-27 14:19:16 -0400, Alexander Sack wrote: >On Fri, Mar 27, 2009 at 1:31 PM, Poul-Henning Kamp wr= ote: >> In message <49CD0405.1060704@samsco.org>, Scott Long writes: >> >>>I've been talking about this for years. =A0All I need is help with the VM >>>magic to create the page on fork. =A0I also want two pages, one global >>>for gettimeofday (and any other global data we can think of) and one >>>per-process for static data like getpid/getgid. gettimeofday is likely to be a mixture of global and per-core data so possibly a 3rd page containing per-core data is warranted. >I'm assuming folks are still in love with the TSC because it still the >cheapest as oppose ACPI-fast or HPET to even contemplate this? That is its major advantage. It might be feasible to export all the data necessary to implement the complete CLOCK_*_FAST family. >Also I thought at least PHK's comment (Sergey mentioned it) was true >regardless of bus, that the TSC is not consistent across multiple >packages (and for that matter I suppose cores) due to I *think* its >ISA lineage so how does this work again? TSC is nothing to do with ISA. The easiest way to build a counter that runs at CPU clock rate is to put it very close to the CPU/core and have different counters for each CPU/core, without any synchronisation between the different counters. > Won't the rate in which you >tick up be sporadic over the course of the process scheduled on >different cores? (i.e. depending on what core RDTSC happened to land >on) RDTSC will wind up on the same core that your thread of execution is running on and this is defined by the scheduler. IE, it's up to the scheduler to ensure that the correct page of global (or per-cpu) data is mapped. --=20 Peter Jeremy --ADZbWkCsHQ7r3kzd Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.10 (FreeBSD) iEYEARECAAYFAknPuPEACgkQ/opHv/APuIdvSQCeNOrRWB5USFabAeGF0x/sFeHg RykAn3f5uD9lFiPLI5BlsXGtDRyiOQGM =Jqic -----END PGP SIGNATURE----- --ADZbWkCsHQ7r3kzd-- From owner-freebsd-current@FreeBSD.ORG Sun Mar 29 18:22: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 4ED751065676; Sun, 29 Mar 2009 18:22:23 +0000 (UTC) (envelope-from peterjeremy@optushome.com.au) Received: from mail36.syd.optusnet.com.au (mail36.syd.optusnet.com.au [211.29.133.76]) by mx1.freebsd.org (Postfix) with ESMTP id D0B6B8FC26; Sun, 29 Mar 2009 18:22:22 +0000 (UTC) (envelope-from peterjeremy@optushome.com.au) Received: from server.vk2pj.dyndns.org (c122-106-216-167.belrs3.nsw.optusnet.com.au [122.106.216.167]) by mail36.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id n2TIMKND000444 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 30 Mar 2009 05:22:21 +1100 X-Bogosity: Ham, spamicity=0.000000 Received: from server.vk2pj.dyndns.org (localhost.vk2pj.dyndns.org [127.0.0.1]) by server.vk2pj.dyndns.org (8.14.3/8.14.3) with ESMTP id n2TIMKZU025407; Mon, 30 Mar 2009 05:22:20 +1100 (EST) (envelope-from peter@server.vk2pj.dyndns.org) Received: (from peter@localhost) by server.vk2pj.dyndns.org (8.14.3/8.14.3/Submit) id n2TIMK5Q025406; Mon, 30 Mar 2009 05:22:20 +1100 (EST) (envelope-from peter) Date: Mon, 30 Mar 2009 05:22:20 +1100 From: Peter Jeremy To: David Xu Message-ID: <20090329182219.GC38985@server.vk2pj.dyndns.org> References: <11609492.9579.1238167614335.JavaMail.root@vms070.mailsrvcs.net> <49CD0405.1060704@samsco.org> <49CD30E9.7030501@elischer.org> <49CEC261.4010803@freebsd.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="YD3LsXFS42OYHhNZ" Content-Disposition: inline In-Reply-To: <49CEC261.4010803@freebsd.org> X-PGP-Key: http://members.optusnet.com.au/peterjeremy/pubkey.asc User-Agent: Mutt/1.5.19 (2009-01-05) Cc: freebsd-hackers@freebsd.org, freebsd-current@freebsd.org, prashant.vaibhav@gmail.com Subject: Re: Improving the kernel/i386 timecounter performance (GSoC proposal) 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, 29 Mar 2009 18:22:26 -0000 --YD3LsXFS42OYHhNZ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 2009-Mar-29 08:35:45 +0800, David Xu wrote: >Julian Elischer wrote: >> interestingly it is even feasible to have a per-thread page.. >> it requires that the scheduler change a page table entry tough. > >I will knock his door at midnight if he added such a heavy weight >task in the scheduler, TLB shutdown is horrible, and big code size >squeezing out data from CPU cache is not idea model. >scheduler should be as simple as just a context switching routine. If the TSC is not consistent between all cores (which is probably the most common situation at present), then using the TSC implies knowing which core you are executing on. From a userland perspective, the easiest way to do this is to have a page of data that varies depending on which core you are executing on. --=20 Peter Jeremy --YD3LsXFS42OYHhNZ Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.10 (FreeBSD) iEYEARECAAYFAknPvFsACgkQ/opHv/APuIeXKgCgviRrpnxRZFKKu/OZ8Q8LAt7d mOgAoIukrhlHkgJJmLZQMlFRBBO7yzbM =I94l -----END PGP SIGNATURE----- --YD3LsXFS42OYHhNZ-- From owner-freebsd-current@FreeBSD.ORG Sun Mar 29 18:26: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 153A61065679; Sun, 29 Mar 2009 18:26:08 +0000 (UTC) (envelope-from ken@mthelicon.com) Received: from hercules.mthelicon.com (hercules.mthelicon.com [IPv6:2001:49f0:2023::2]) by mx1.freebsd.org (Postfix) with ESMTP id D6CDC8FC0C; Sun, 29 Mar 2009 18:26:07 +0000 (UTC) (envelope-from ken@mthelicon.com) Received: from feathers.peganest.com (feathers.peganest.com [78.33.110.3]) (authenticated bits=0) by hercules.mthelicon.com (8.14.3/8.14.3) with ESMTP id n2TIQ5iK061131 (version=TLSv1/SSLv3 cipher=DHE-DSS-AES256-SHA bits=256 verify=NO); Sun, 29 Mar 2009 18:26:07 GMT (envelope-from ken@mthelicon.com) From: Pegasus Mc Cleaft Organization: Feathers To: current@freebsd.org, hackers@freebsd.org Date: Sun, 29 Mar 2009 18:26:04 +0000 User-Agent: KMail/1.11.1 (FreeBSD/8.0-CURRENT; KDE/4.2.1; amd64; ; ) MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200903291826.05152.ken@mthelicon.com> Cc: Subject: ping6 and traceroute6 trouble 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, 29 Mar 2009 18:26:08 -0000 Hi Current and Hackers, I have only seen this recently and was wondering if anyone else can confirm this as a bug or perhaps a setup problem on my end. I think it started to appear with 8-Current from about the 25th of march. Any time I do a ping6 or traceroute6 I receive an error stating "Invalid value for hints." However, I am able to do all other functions (telnet, ssh, etc.) feathers# ping6 ipv6.google.com ping6: Invalid value for hints feathers# traceroute6 ipv6.google.com traceroute6: Invalid value for hints my If config looks like: re0: flags=8843 metric 0 mtu 1500 options=389b ether 00:1d:7d:07:24:1a inet 78.33.110.3 netmask 0xffffffe0 broadcast 78.33.110.31 inet6 fe80::21d:7dff:fe07:241a%re0 prefixlen 64 scopeid 0x1 inet6 2001:4d48:ad51:32:21d:7dff:fe07:241a prefixlen 64 autoconf media: Ethernet autoselect (100baseTX ) status: active Thanks in advance, Peg From owner-freebsd-current@FreeBSD.ORG Sun Mar 29 18:48:31 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 E9B13106566B; Sun, 29 Mar 2009 18:48:31 +0000 (UTC) (envelope-from ume@mahoroba.org) Received: from asuka.mahoroba.org (unknown [IPv6:2001:2f0:104:8010::1]) by mx1.freebsd.org (Postfix) with ESMTP id 7F5948FC1C; Sun, 29 Mar 2009 18:48:31 +0000 (UTC) (envelope-from ume@mahoroba.org) Received: from ameno.mahoroba.org (IDENT:DWWFkZwriII45rtX8rf73jr/o2L6spu5MCjZLJoF7Q+12SO/nOmk9xrVaRY/PD8S@ameno.mahoroba.org [IPv6:2001:2f0:104:8010:20a:79ff:fe69:ee6b]) (user=ume mech=CRAM-MD5 bits=0) by asuka.mahoroba.org (8.14.3/8.14.3) with ESMTP/inet6 id n2TIli7h029877 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 30 Mar 2009 03:47:51 +0900 (JST) (envelope-from ume@mahoroba.org) Date: Mon, 30 Mar 2009 03:47:44 +0900 Message-ID: From: Hajimu UMEMOTO To: Pegasus Mc Cleaft In-Reply-To: <200903291826.05152.ken@mthelicon.com> References: <200903291826.05152.ken@mthelicon.com> User-Agent: xcite1.58> Wanderlust/2.14.0 (Africa) SEMI/1.14.6 (Maruoka) FLIM/1.14.8 (=?ISO-8859-4?Q?Shij=F2?=) APEL/10.7 Emacs/22.3 (i386-portbld-freebsd7.1) MULE/5.0 (SAKAKI) X-Operating-System: FreeBSD 7.1-RELEASE-p2 X-PGP-Key: http://www.imasy.or.jp/~ume/publickey.asc X-PGP-Fingerprint: 1F00 0B9E 2164 70FC 6DC5 BF5F 04E9 F086 BF90 71FE Organization: Internet Mutual Aid Society, YOKOHAMA MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (asuka.mahoroba.org [IPv6:2001:2f0:104:8010::1]); Mon, 30 Mar 2009 03:47:51 +0900 (JST) X-Virus-Scanned: by amavisd-new X-Virus-Status: Clean X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on asuka.mahoroba.org Cc: hackers@freebsd.org, current@freebsd.org Subject: Re: ping6 and traceroute6 trouble 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, 29 Mar 2009 18:48:32 -0000 Hi, >>>>> On Sun, 29 Mar 2009 18:26:04 +0000 >>>>> Pegasus Mc Cleaft said: ken> I have only seen this recently and was wondering if anyone else can confirm ken> this as a bug or perhaps a setup problem on my end. I think it started to ken> appear with 8-Current from about the 25th of march. ken> Any time I do a ping6 or traceroute6 I receive an error stating "Invalid ken> value for hints." However, I am able to do all other functions (telnet, ssh, ken> etc.) ken> feathers# ping6 ipv6.google.com ken> ping6: Invalid value for hints ken> feathers# traceroute6 ipv6.google.com ken> traceroute6: Invalid value for hints I've committed the change to lib/libc/net/getaddrinfo.c little while ago that also fixed the problem. Please re-cvsup and try it. http://svn.freebsd.org/viewvc/base/head/lib/libc/net/getaddrinfo.c?r1=190416&r2=190525&view=patch Sincerely, -- Hajimu UMEMOTO @ Internet Mutual Aid Society Yokohama, Japan ume@mahoroba.org ume@{,jp.}FreeBSD.org http://www.imasy.org/~ume/ From owner-freebsd-current@FreeBSD.ORG Sun Mar 29 18:19: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 ED672106564A for ; Sun, 29 Mar 2009 18:19:08 +0000 (UTC) (envelope-from spry@anarchy.in.the.ph) Received: from wf-out-1314.google.com (wf-out-1314.google.com [209.85.200.175]) by mx1.freebsd.org (Postfix) with ESMTP id D042C8FC29 for ; Sun, 29 Mar 2009 18:19:08 +0000 (UTC) (envelope-from spry@anarchy.in.the.ph) Received: by wf-out-1314.google.com with SMTP id 24so1912118wfg.7 for ; Sun, 29 Mar 2009 11:19:08 -0700 (PDT) MIME-Version: 1.0 Received: by 10.142.157.6 with SMTP id f6mr1772111wfe.317.1238350748202; Sun, 29 Mar 2009 11:19:08 -0700 (PDT) Date: Mon, 30 Mar 2009 02:19:08 +0800 Message-ID: From: Mars G Miro To: Gavin Atkinson Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Sun, 29 Mar 2009 19:05:51 +0000 Cc: freebsd-current@freebsd.org Subject: PHENOM II X4 940 BE Experience (was Re: booting from SATA DVD-RAM, no go SOLVED) 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, 29 Mar 2009 18:19:09 -0000 On Sun, Mar 29, 2009 at 8:59 PM, Gavin Atkinson wrote: > On Sat, 28 Mar 2009, Mars G Miro wrote: [snip] >> rrrrrrrrrr. plugging in an old CD-ROM still gives me the same thing. >> >> Next stop: PXE, or just install FreeBSD on the HD in a separate >> machine altogether ... > > This was probably fixed by the most recent commits to > src/sys/boot/i386/libi386/bioscd.c - they were done within the last couple > of weeks, so the March snapshot may well have these changes included. > I'll check on that once new snapshot ISOs are available. > Gavin Ok, I managed to bootstrap most recent CURRENT on the SSD (OCZ Core Series V2 SATA II 2.5") via its USB, from another CURRENT box (I have a set of scripts to do this). It's good to know the new USB2 stuff don't crash plugging a USB device anymore!! After I bootstrapped FreeBSD on it, I rsync'd /usr/src and /usr/obj and everything went fine. Previous experiences would crash (7.X). Also I notice this in dmesg: ad4: FAILURE - SET_MULTI status=51 error=4 but it seems to be harmless. Full verbose dmesg: http://pastebin.com/f2ae007e6 Rebuild stats: make -j8 buildworld 3379.225u 463.832s 19:27.34 329.2% 6637+2112k 21241+9092io 17130pf+0w make -j16 buildworld 3386.927u 467.825s 20:09.77 318.6% 6649+2115k 21301+9121io 17440pf+0w make -j8 buildkernel KERNCONF=BLACKBOX 728.654u 77.502s 6:35.60 203.7% 6446+2024k 7116+10170io 4pf+0w w/c is somehow at par w/ the 6-CORE DUNNINGTON stats I posted last October: http://markmail.org/message/vtadzdlvakflw33u#query:+page:1+mid:g64htyb5bxhfcbrq+state:results diskinfo -ctv: ad4 512 # sectorsize 64105742336 # mediasize in bytes (60G) 125206528 # mediasize in sectors 124212 # Cylinders according to firmware. 16 # Heads according to firmware. 63 # Sectors according to firmware. ad:MK06090307483000F # Disk ident. I/O command overhead: time to read 10MB block 0.078007 sec = 0.004 msec/sector time to read 20480 sectors 3.852412 sec = 0.188 msec/sector calculated command overhead = 0.184 msec/sector Seek times: Full stroke: 250 iter in 0.048635 sec = 0.195 msec Half stroke: 250 iter in 0.046734 sec = 0.187 msec Quarter stroke: 500 iter in 0.091953 sec = 0.184 msec Short forward: 400 iter in 0.072450 sec = 0.181 msec Short backward: 400 iter in 0.072721 sec = 0.182 msec Seq outer: 2048 iter in 0.401060 sec = 0.196 msec Seq inner: 2048 iter in 0.409373 sec = 0.200 msec Transfer rates: outside: 102400 kbytes in 0.726566 sec = 140937 kbytes/sec middle: 102400 kbytes in 0.729195 sec = 140429 kbytes/sec inside: 102400 kbytes in 0.742233 sec = 137962 kbytes/sec /me goes back building stuff on it ;-) Thanks guys!!! -- cheers mars ----- Yogi Berra - "A nickel ain't worth a dime anymore." From owner-freebsd-current@FreeBSD.ORG Sun Mar 29 19: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 2004F1065670 for ; Sun, 29 Mar 2009 19:41:40 +0000 (UTC) (envelope-from sam@freebsd.org) Received: from ebb.errno.com (ebb.errno.com [69.12.149.25]) by mx1.freebsd.org (Postfix) with ESMTP id E124A8FC1B for ; Sun, 29 Mar 2009 19:41:39 +0000 (UTC) (envelope-from sam@freebsd.org) Received: from Macintosh-4.local ([10.0.0.194]) (authenticated bits=0) by ebb.errno.com (8.13.6/8.12.6) with ESMTP id n2TJfdsx077471 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 29 Mar 2009 12:41:39 -0700 (PDT) (envelope-from sam@freebsd.org) Message-ID: <49CFCEF3.8020308@freebsd.org> Date: Sun, 29 Mar 2009 12:41:39 -0700 From: Sam Leffler Organization: FreeBSD Project User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: Daniel Thiele References: <49C83038.40300@gmx.net> <49CAC1C0.9030506@freebsd.org> <49CEA474.9020302@gmx.net> In-Reply-To: <49CEA474.9020302@gmx.net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-DCC-sonic.net-Metrics: ebb.errno.com; whitelist Cc: freebsd-current@freebsd.org Subject: Re: Wireless connection (WPA-EAP) stops working after a while 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, 29 Mar 2009 19:41:40 -0000 Daniel Thiele wrote: > Hi Sam, > > I ran tests with both a CURRENT from March 26 + (the manually updated) > wpa_supplicant 0.6.9 and an older CURRENT from March 1 2000h + > wpa_supplicant 0.5.11. I included the logs below. Unfortunately, in both > cases I get the "WPA: Failed to set PTK to the driver" error and the > wireless adapter stops working. > > wlan0: ieee80211_crypto_newkey: cipher 3 flags 0x3 keyix 4 > wlan0: ieee80211_crypto_newkey: unable to setup cipher AES-CCM Here's the issue. The request to plumb AES PTK uses a fixed key index and not IEEE80211_KEYIX_NONE (-1). This causes the ath driver to return an error. I'll need to review code to understand what's wrong. Odd that it doesn't happen with WPA-PSK as the mechanics are (should be) identical. Sam From owner-freebsd-current@FreeBSD.ORG Sun Mar 29 19:59:41 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 8D122106564A for ; Sun, 29 Mar 2009 19:59:41 +0000 (UTC) (envelope-from barney_cordoba@yahoo.com) Received: from web63906.mail.re1.yahoo.com (web63906.mail.re1.yahoo.com [69.147.97.121]) by mx1.freebsd.org (Postfix) with SMTP id 1BAE78FC12 for ; Sun, 29 Mar 2009 19:59:40 +0000 (UTC) (envelope-from barney_cordoba@yahoo.com) Received: (qmail 31359 invoked by uid 60001); 29 Mar 2009 19:59:40 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1238356780; bh=zcV4KwZd9nWXkGtNR+QDNySmZAyyn8xkO1+sK87g12w=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Reply-To:Subject:To:MIME-Version:Content-Type; b=l9ZeBhdQBSbcMg9OE0WROS3gmSxPNGxV42XEsJphKs5TSJyfyBoQHUIjLtinNjxFshwxqXWcLkTrRfaO9dLAVx5MwVvzXx2YC9PTgUPIwYEPwOc3m/qD3dayCnKlTrpEqv98CPYIA2Ye6ulUZrYSficHxMqpWbn76OGqnoPl8OU= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Reply-To:Subject:To:MIME-Version:Content-Type; b=C/+SyG9DiGkr7q8LIpcunIsgpY9/H0DQvEC7TSvzj9PUJ0jSTlmjUqQ1PDqfjgA9qjnmMEAy3DoZI+2o5YZNLlLIrUhvLdw/TepPZ7oK/IXPK/eIAqPseq5Y/hY8+zQWJdDfWySc9M/pv7ArsyKxw0/l6cS1RmRdCNJN3XcbqqM=; Message-ID: <483663.31171.qm@web63906.mail.re1.yahoo.com> X-YMail-OSG: OczKrdQVM1nc6WDcUnQyTtmIrGebJcjSZE3x5qAkjkaboX1Eann.DuxViLj37wrHlPVWZJgg7kbiIm3FgmIk146JsYExBsxKCBz5pm7u6.Y5lK5i5FpHB4dfxW9G8JxjUbXb2bzECSoBp.GGzrQr1ZrHIaJ100G7AypKvXZddu4E9pNrhFJzri7TbN4JJWJuG2skaWt_yqID4c3rbFYmcyYgyaQOO.AiulAC1i3bFYYw40H.9LsAwKLAlWjkCBhzVPjMEvBsIQ-- Received: from [98.242.222.229] by web63906.mail.re1.yahoo.com via HTTP; Sun, 29 Mar 2009 12:59:40 PDT X-Mailer: YahooMailWebService/0.7.289.1 Date: Sun, 29 Mar 2009 12:59:40 -0700 (PDT) From: Barney Cordoba To: current@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Subject: cpuset affinity control from within the kernel X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: barney_cordoba@yahoo.com List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Mar 2009 19:59:41 -0000 What tools are available for taskqueues, interrupts, etc from within the kernel? Barney From owner-freebsd-current@FreeBSD.ORG Sun Mar 29 20:06:06 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 4F6AF106566B; Sun, 29 Mar 2009 20:06:06 +0000 (UTC) (envelope-from pisymbol@gmail.com) Received: from yw-out-2324.google.com (yw-out-2324.google.com [74.125.46.29]) by mx1.freebsd.org (Postfix) with ESMTP id E54978FC14; Sun, 29 Mar 2009 20:06:05 +0000 (UTC) (envelope-from pisymbol@gmail.com) Received: by yw-out-2324.google.com with SMTP id 5so1207720ywh.13 for ; Sun, 29 Mar 2009 13:06:05 -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=k7IrVSdNAeqRKbo7esZm2n7TJ97MgYEoapVCKLVvQ34=; b=OosvWKqL4Prh0pXQrtBFGgPwPEramCOckO1C6Eso7TgPiEKsNHKupaxVMtB/+WdihW CG8OSXWG/AavqQck871uxE5qioKI/Zmwc8245MURVMFJ8mnFnMcn/0ifPUiF0maph3TU Beuxh/tUDNr+1g5b0xVQYcNdycdsdT1OI8iY4= 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=lLuX5dmt+ZOqIqGpK0jVnerjf6Iv4Sedu5fSumN5KGYLO/vmtb6Jy1pk3tnaZVrhgk pp13ENRFAFVjf2qCcwyRkVia0OE2YDZqTJVZNNyWp3zW9JdRRjvx3WxEl3RAsnZ3VJ7t iQbR+e3mZqRn9mgtZgrTPq7oDmR9vbdent8o0= MIME-Version: 1.0 Received: by 10.100.32.6 with SMTP id f6mr3366795anf.32.1238357165326; Sun, 29 Mar 2009 13:06:05 -0700 (PDT) In-Reply-To: <20090329180745.GB38985@server.vk2pj.dyndns.org> References: <49CD0405.1060704@samsco.org> <5739.1238175087@critter.freebsd.dk> <3c0b01820903271119l4161c7b8yf74613b184add487@mail.gmail.com> <20090329180745.GB38985@server.vk2pj.dyndns.org> Date: Sun, 29 Mar 2009 16:06:05 -0400 Message-ID: <3c0b01820903291306i49cf284etd10f693392b7b9a1@mail.gmail.com> From: Alexander Sack To: Peter Jeremy Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: FreeBSD Hackers , freebsd-current@freebsd.org, prashant.vaibhav@gmail.com Subject: Re: Improving the kernel/i386 timecounter performance (GSoC proposal) 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, 29 Mar 2009 20:06:06 -0000 On Sun, Mar 29, 2009 at 2:07 PM, Peter Jeremy wrote: > On 2009-Mar-27 14:19:16 -0400, Alexander Sack wrote: >>I'm assuming folks are still in love with the TSC because it still the >>cheapest as oppose ACPI-fast or HPET to even contemplate this? > > That is its major advantage. =A0It might be feasible to export all the > data necessary to implement the complete CLOCK_*_FAST family. Understood. >>Also I thought at least PHK's comment (Sergey mentioned it) was true >>regardless of bus, that the TSC is not consistent across multiple >>packages (and for that matter I suppose cores) due to I *think* its >>ISA lineage so how does this work again? > > TSC is nothing to do with ISA. =A0The easiest way to build a counter > that runs at CPU clock rate is to put it very close to the CPU/core > and have different counters for each CPU/core, without any > synchronisation between the different counters. Understood thanks. I don't know why ISA and TSC are in my head. Please ex= cuse. >> =A0Won't the rate in which you >>tick up be sporadic over the course of the process scheduled on >>different cores? =A0(i.e. depending on what core RDTSC happened to land >>on) > > RDTSC will wind up on the same core that your thread of execution is > running on and this is defined by the scheduler. =A0IE, it's up to the > scheduler to ensure that the correct page of global (or per-cpu) data > is mapped. OK. But then why not do what I *think* Solaris does in the first place, sync the cores using a master/slave to effectively create an invariant TSC i.e if you are going to buy the overhead in the scheduler why not do the dirty work at the source instead of all this overhead in either the scheduler or the logic to know that this thread of execution was on that core and is using this TSC etc. etc. I believe this topic has been re-hashed before I don't remember the outcome so again excuse... :D Thanks! -aps From owner-freebsd-current@FreeBSD.ORG Sun Mar 29 20:14: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 E04FE1065674; Sun, 29 Mar 2009 20:14:01 +0000 (UTC) (envelope-from gperez@entel.upc.edu) Received: from dash.upc.es (dash.upc.es [147.83.2.50]) by mx1.freebsd.org (Postfix) with ESMTP id 695348FC1B; Sun, 29 Mar 2009 20:14:01 +0000 (UTC) (envelope-from gperez@entel.upc.edu) Received: from hamilton.upcnetadm.upcnet.es (hamilton.upcnetadm.upcnet.es [147.83.2.240]) by dash.upc.es (8.14.1/8.13.1) with ESMTP id n2TKDtsB007025; Sun, 29 Mar 2009 22:13:59 +0200 Received: from portatil.upc.es ([88.11.103.61]) by hamilton.upcnetadm.upcnet.es (Lotus Domino Release 5.0.12) with ESMTP id 2009032922135562:216806 ; Sun, 29 Mar 2009 22:13:55 +0200 Message-ID: <49CFD66E.5030301@entel.upc.edu> Date: Sun, 29 Mar 2009 22:13:34 +0200 From: Gustau Perez User-Agent: Thunderbird 2.0.0.21 (X11/20090329) MIME-Version: 1.0 To: Jung-uk Kim References: <1236802980.00085518.1236789602@10.7.7.3> <200903241528.34902.jkim@FreeBSD.org> <49CAA201.7000205@entel.upc.edu> <200903251833.14825.jkim@FreeBSD.org> In-Reply-To: <200903251833.14825.jkim@FreeBSD.org> X-MIMETrack: Itemize by SMTP Server on hamilton/UPC(Release 5.0.12 |February 13, 2003) at 29/03/2009 22:13:56, Serialize by Router on hamilton/UPC(Release 5.0.12 |February 13, 2003) at 29/03/2009 22:13:59, Serialize complete at 29/03/2009 22:13:59 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=ISO-8859-1; format=flowed X-Mail-Scanned: Criba 2.0 + Clamd X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0 (dash.upc.es [147.83.2.50]); Sun, 29 Mar 2009 22:13:59 +0200 (CEST) Cc: freebsd-current@FreeBSD.org Subject: Re: [HEADSUP] amd64 suspend/resume code to be comitted 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, 29 Mar 2009 20:14:02 -0000 > Then, it is something else, e.g., acpi_video(4). You can try setting > debug.acpi.disabled="video" in /boot/loader.conf for example. > > Jung-uk Kim > Sorry for the delay. Tried loading acpi_video in /boot/loader.conf. After having a terminal, I checked the available mibs with sysctl -a | grep acpi.video. Only get hw.acpi.reset_video. The man page didn't throw the waited ray of light :) I also tried suspending from the terminal, without X's running. I tried vbetool (dpms off/on and post). I wasn't brave enought to try vbestate save and restore. Finally I decided it was time to use all the arsenal available :) so I decided to remove everything not necessary. So usb and friends, firewire, cbb and pccard, if_bge, if_rum, snd_hda and nouveau were removed from the kernel. Tried going single user mode, remove them and acpiconf -s 3. Guess what happened :) Checking messages doesn't show anything unsual. But if you want them or if I can try others things to debug, let me know. Greets, Gustau From owner-freebsd-current@FreeBSD.ORG Sun Mar 29 21:30: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 7B428106566B; Sun, 29 Mar 2009 21:30:01 +0000 (UTC) (envelope-from wenji@fnal.gov) Received: from mailgw2.fnal.gov (mailgw2.fnal.gov [131.225.111.12]) by mx1.freebsd.org (Postfix) with ESMTP id 4D3398FC16; Sun, 29 Mar 2009 21:30:01 +0000 (UTC) (envelope-from wenji@fnal.gov) Received: from mailav1.fnal.gov (mailav1.fnal.gov [131.225.111.18]) by mailgw2.fnal.gov (iPlanet Messaging Server 5.2 HotFix 2.06 (built Mar 28 2005)) with SMTP id <0KHA008W3EDHD3@mailgw2.fnal.gov>; Sun, 29 Mar 2009 16:30:01 -0500 (CDT) Received: from mailgw1.fnal.gov ([131.225.111.11]) by mailav1.fnal.gov (SAVSMTP 3.1.7.47) with SMTP id M2009032916300028482 ; Sun, 29 Mar 2009 16:30:00 -0500 Received: from conversion-daemon.mailgw1.fnal.gov by mailgw1.fnal.gov (iPlanet Messaging Server 5.2 HotFix 2.06 (built Mar 28 2005)) id <0KHA00201E1OGD@mailgw1.fnal.gov> (original mail from wenji@fnal.gov); Sun, 29 Mar 2009 16:30:00 -0500 (CDT) Received: from fnal.gov (imap2.fnal.gov [131.225.111.7]) by mailgw1.fnal.gov (iPlanet Messaging Server 5.2 HotFix 2.06 (built Mar 28 2005)) with ESMTP id <0KHA007R3EE0U7@mailgw1.fnal.gov>; Sun, 29 Mar 2009 16:30:00 -0500 (CDT) Received: from [131.225.2.15] by imap2.fnal.gov (mshttpd); Sun, 29 Mar 2009 21:30:00 +0000 (GMT) Date: Sun, 29 Mar 2009 21:30:00 +0000 (GMT) From: Wenji Wu In-reply-to: <49CF4E39.4010905@FreeBSD.org> To: Kris Kennaway Message-id: MIME-version: 1.0 X-Mailer: Sun Java(tm) System Messenger Express 6.3-6.03 (built Mar 14 2008; 32bit) Content-type: text/plain; charset=us-ascii Content-language: en Content-transfer-encoding: 7BIT Content-disposition: inline X-Accept-Language: en Priority: normal References: <49CE231C.9080609@FreeBSD.org> <49CF4E39.4010905@FreeBSD.org> Cc: freebsd-current@freebsd.org Subject: Re: LOCK_PROFILING does not work on FreeBSD 8.0-CURRENT 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, 29 Mar 2009 21:30:01 -0000 Here is my procedures: (1) run "cvsup supfile" to synchronize the latest kernel (2) edit my kernel configuration file, and add "options LOCK_PROFILING" to my kernel configuration file (3) run "make buildkernel KERNCONF=wenjikernel" (4) run "make installkernel kernconf=WENJIKERNEL" (5) run "reboot" to reboot my system. Here is the system printout after the reboot. (1) "$ uname -a" FreeBSD wan-koi.fnal.gov 8.0-CURRENT FreeBSD 8.0-CURRENT #8: Sun Mar 29 20:11:07 UTC 2009 root@wan-koi.fnal.gov:/usr/obj/usr/src/sys/wenjikernel amd64 (2) "sysctl -a|grep lock" $ sysctl -a|grep lock kern.clockrate: { hz = 1000, tick = 1000, profhz = 2000, stathz = 133 } vm.pageout_lock_miss: 0 net.inet.tcp.wlock_looped: 0 net.inet.tcp.wlock_relocked: 0 net.inet.tcp.wlock_upgraded: 56 net.inet.tcp.tcp_wlock_atfirst: 97 net.inet.tcp.rlock_atfirst: 757 net.inet.tcp.read_locking: 1 debug.acpi.reset_clock: 1 debug.rwlock.loops: 10000 debug.rwlock.retry: 10 debug.to_avg_lockcalls: 17 hw.clockrate: 2666 machdep.wall_cmos_clock: 0 p1003_1b.memlock: 0 p1003_1b.memlock_range: 0 dev.atrtc.0.%desc: AT realtime clock What else did I have miss? thanks wenji From owner-freebsd-current@FreeBSD.ORG Sun Mar 29 21:38: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 57F531065672 for ; Sun, 29 Mar 2009 21:38:42 +0000 (UTC) (envelope-from kris@FreeBSD.org) Received: from dhcp-172-28-76-41.eur.corp.google.com (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id AA76B8FC08; Sun, 29 Mar 2009 21:38:41 +0000 (UTC) (envelope-from kris@FreeBSD.org) Message-ID: <49CFEA61.8030005@FreeBSD.org> Date: Sun, 29 Mar 2009 22:38:41 +0100 From: Kris Kennaway User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: Wenji Wu References: <49CE231C.9080609@FreeBSD.org> <49CF4E39.4010905@FreeBSD.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: LOCK_PROFILING does not work on FreeBSD 8.0-CURRENT 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, 29 Mar 2009 21:38:42 -0000 Wenji Wu wrote: > Here is my procedures: > > (1) run "cvsup supfile" to synchronize the latest kernel > > (2) edit my kernel configuration file, and add "options LOCK_PROFILING" to my kernel configuration file > > (3) run "make buildkernel KERNCONF=wenjikernel" > > (4) run "make installkernel kernconf=WENJIKERNEL" KERNCONF and the value of this variable are both case-sensitive. Kris > > (5) run "reboot" to reboot my system. > > Here is the system printout after the reboot. > > (1) "$ uname -a" > FreeBSD wan-koi.fnal.gov 8.0-CURRENT FreeBSD 8.0-CURRENT #8: Sun Mar 29 20:11:07 UTC 2009 > root@wan-koi.fnal.gov:/usr/obj/usr/src/sys/wenjikernel amd64 > > (2) "sysctl -a|grep lock" > $ sysctl -a|grep lock > kern.clockrate: { hz = 1000, tick = 1000, profhz = 2000, stathz = 133 } > vm.pageout_lock_miss: 0 > net.inet.tcp.wlock_looped: 0 > net.inet.tcp.wlock_relocked: 0 > net.inet.tcp.wlock_upgraded: 56 > net.inet.tcp.tcp_wlock_atfirst: 97 > net.inet.tcp.rlock_atfirst: 757 > net.inet.tcp.read_locking: 1 > debug.acpi.reset_clock: 1 > debug.rwlock.loops: 10000 > debug.rwlock.retry: 10 > debug.to_avg_lockcalls: 17 > hw.clockrate: 2666 > machdep.wall_cmos_clock: 0 > p1003_1b.memlock: 0 > p1003_1b.memlock_range: 0 > dev.atrtc.0.%desc: AT realtime clock > > > What else did I have miss? > > thanks > > wenji > > > > From owner-freebsd-current@FreeBSD.ORG Sun Mar 29 21:38:48 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 6A2681065670; Sun, 29 Mar 2009 21:38:48 +0000 (UTC) (envelope-from marcus@FreeBSD.org) Received: from creme-brulee.marcuscom.com (marcuscom-pt.tunnel.tserv1.fmt.ipv6.he.net [IPv6:2001:470:1f00:ffff::1279]) by mx1.freebsd.org (Postfix) with ESMTP id 1E4BA8FC0C; Sun, 29 Mar 2009 21:38:48 +0000 (UTC) (envelope-from marcus@FreeBSD.org) Received: from [IPv6:2001:470:1f00:2464::4] (shumai.marcuscom.com [IPv6:2001:470:1f00:2464::4]) by creme-brulee.marcuscom.com (8.14.3/8.14.3) with ESMTP id n2TLg0Ld014064; Sun, 29 Mar 2009 17:42:00 -0400 (EDT) (envelope-from marcus@FreeBSD.org) From: Joe Marcus Clarke To: current Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-exyVlah01fXDdHZ2S7jt" Organization: FreeBSD, Inc. Date: Sun, 29 Mar 2009 17:38:48 -0400 Message-Id: <1238362728.73736.165.camel@shumai.marcuscom.com> Mime-Version: 1.0 X-Mailer: Evolution 2.24.5 FreeBSD GNOME Team Port X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,NO_RELAYS autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on creme-brulee.marcuscom.com Cc: David Schultz Subject: getline incompatibility with Linux 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, 29 Mar 2009 21:38:48 -0000 --=-exyVlah01fXDdHZ2S7jt Content-Type: text/plain Content-Transfer-Encoding: quoted-printable The new getline() function in FreeBSD is not completely compatible with Linux's implementation. The result is that programs which assume Linux getline may enter a tight infinite loop. According to the Linux getline(3) manpage, getline(3) returns -1 on error (including EOF). Our implementation returns 0 on EOF. Would it be possible to return -1 on EOF in our implementation? Joe --=20 Joe Marcus Clarke FreeBSD GNOME Team :: gnome@FreeBSD.org FreeNode / #freebsd-gnome http://www.FreeBSD.org/gnome --=-exyVlah01fXDdHZ2S7jt 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) iEYEABECAAYFAknP6mYACgkQb2iPiv4Uz4cTqACfVso80ClcvY0UmAcjsMicaMd6 WQEAoI1cQ/KTPY4pQYDmCGCyk1QNF5rO =Z+Mn -----END PGP SIGNATURE----- --=-exyVlah01fXDdHZ2S7jt-- From owner-freebsd-current@FreeBSD.ORG Sun Mar 29 21: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 B753C106566B; Sun, 29 Mar 2009 21:47:04 +0000 (UTC) (envelope-from wenji@fnal.gov) Received: from mailgw2.fnal.gov (mailgw2.fnal.gov [131.225.111.12]) by mx1.freebsd.org (Postfix) with ESMTP id 8C6AA8FC1C; Sun, 29 Mar 2009 21:47:04 +0000 (UTC) (envelope-from wenji@fnal.gov) Received: from mailav2.fnal.gov (mailav2.fnal.gov [131.225.111.20]) by mailgw2.fnal.gov (iPlanet Messaging Server 5.2 HotFix 2.06 (built Mar 28 2005)) with SMTP id <0KHA008WPF5CIF@mailgw2.fnal.gov>; Sun, 29 Mar 2009 16:47:04 -0500 (CDT) Received: from mailgw2.fnal.gov ([131.225.111.12]) by mailav2.fnal.gov (SAVSMTP 3.1.7.47) with SMTP id M2009032916470429243 ; Sun, 29 Mar 2009 16:47:04 -0500 Received: from conversion-daemon.mailgw2.fnal.gov by mailgw2.fnal.gov (iPlanet Messaging Server 5.2 HotFix 2.06 (built Mar 28 2005)) id <0KHA00C01F5XGI@mailgw2.fnal.gov> (original mail from wenji@fnal.gov); Sun, 29 Mar 2009 16:47:04 -0500 (CDT) Received: from [131.225.88.20] (null-002241fb8457.dhcp.fnal.gov [131.225.88.20]) by mailgw2.fnal.gov (iPlanet Messaging Server 5.2 HotFix 2.06 (built Mar 28 2005)) with ESMTP id <0KHA008GUF6BGY@mailgw2.fnal.gov>; Sun, 29 Mar 2009 16:47:00 -0500 (CDT) Date: Sun, 29 Mar 2009 16:46:59 -0500 From: wenji wu In-reply-to: <49CFEA61.8030005@FreeBSD.org> To: Kris Kennaway Message-id: MIME-version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Thread-topic: LOCK_PROFILING does not work on FreeBSD 8.0-CURRENT Thread-index: Acmwt+L1TwrG0jKCf0uyxlDKjAw73w== User-Agent: Microsoft-Entourage/12.15.0.081119 Cc: freebsd-current@freebsd.org Subject: Re: LOCK_PROFILING does not work on FreeBSD 8.0-CURRENT 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, 29 Mar 2009 21:47:05 -0000 That was my typo in the email. It was correct when I compiled the kernel. Otherwise, it can not go through the compiling. On 3/29/09 4:38 PM, "Kris Kennaway" wrote: > Wenji Wu wrote: >> Here is my procedures: >> >> (1) run "cvsup supfile" to synchronize the latest kernel >> >> (2) edit my kernel configuration file, and add "options LOCK_PROFILING" to >> my kernel configuration file >> >> (3) run "make buildkernel KERNCONF=wenjikernel" >> >> (4) run "make installkernel kernconf=WENJIKERNEL" > > KERNCONF and the value of this variable are both case-sensitive. > > Kris > >> >> (5) run "reboot" to reboot my system. >> >> Here is the system printout after the reboot. >> >> (1) "$ uname -a" >> FreeBSD wan-koi.fnal.gov 8.0-CURRENT FreeBSD 8.0-CURRENT #8: Sun Mar 29 >> 20:11:07 UTC 2009 >> root@wan-koi.fnal.gov:/usr/obj/usr/src/sys/wenjikernel amd64 >> >> (2) "sysctl -a|grep lock" >> $ sysctl -a|grep lock >> kern.clockrate: { hz = 1000, tick = 1000, profhz = 2000, stathz = 133 } >> vm.pageout_lock_miss: 0 >> net.inet.tcp.wlock_looped: 0 >> net.inet.tcp.wlock_relocked: 0 >> net.inet.tcp.wlock_upgraded: 56 >> net.inet.tcp.tcp_wlock_atfirst: 97 >> net.inet.tcp.rlock_atfirst: 757 >> net.inet.tcp.read_locking: 1 >> debug.acpi.reset_clock: 1 >> debug.rwlock.loops: 10000 >> debug.rwlock.retry: 10 >> debug.to_avg_lockcalls: 17 >> hw.clockrate: 2666 >> machdep.wall_cmos_clock: 0 >> p1003_1b.memlock: 0 >> p1003_1b.memlock_range: 0 >> dev.atrtc.0.%desc: AT realtime clock >> >> >> What else did I have miss? >> >> thanks >> >> wenji >> >> >> >> > > _______________________________________________ > 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 Sun Mar 29 21:56: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 5DFC3106566B; Sun, 29 Mar 2009 21:56:31 +0000 (UTC) (envelope-from ken@mthelicon.com) Received: from hercules.mthelicon.com (hercules.mthelicon.com [IPv6:2001:49f0:2023::2]) by mx1.freebsd.org (Postfix) with ESMTP id 27C058FC08; Sun, 29 Mar 2009 21:56:31 +0000 (UTC) (envelope-from ken@mthelicon.com) Received: from feathers.peganest.com (feathers.peganest.com [78.33.110.3]) (authenticated bits=0) by hercules.mthelicon.com (8.14.3/8.14.3) with ESMTP id n2TLuTV7062181 (version=TLSv1/SSLv3 cipher=DHE-DSS-AES256-SHA bits=256 verify=NO); Sun, 29 Mar 2009 21:56:30 GMT (envelope-from ken@mthelicon.com) From: Pegasus Mc Cleaft Organization: Feathers To: freebsd-current@freebsd.org Date: Sun, 29 Mar 2009 21:56:24 +0000 User-Agent: KMail/1.11.1 (FreeBSD/8.0-CURRENT; KDE/4.2.1; amd64; ; ) References: <200903291826.05152.ken@mthelicon.com> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200903292156.24202.ken@mthelicon.com> Cc: hackers@freebsd.org, Hajimu UMEMOTO Subject: Re: ping6 and traceroute6 trouble 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, 29 Mar 2009 21:56:31 -0000 Hi Hajimu, > ken> Any time I do a ping6 or traceroute6 I receive an error stating > "Invalid ken> value for hints." However, I am able to do all other > functions (telnet, ssh, ken> etc.) > > ken> feathers# ping6 ipv6.google.com > ken> ping6: Invalid value for hints > > ken> feathers# traceroute6 ipv6.google.com > ken> traceroute6: Invalid value for hints > > I've committed the change to lib/libc/net/getaddrinfo.c little while > ago that also fixed the problem. Please re-cvsup and try it. > > http://svn.freebsd.org/viewvc/base/head/lib/libc/net/getaddrinfo.c?r1=19041 >6&r2=190525&view=patch Yes, that fixed things nicely. Thank you. Best regards, Peg From owner-freebsd-current@FreeBSD.ORG Sun Mar 29 21:59: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 6D10F1065672 for ; Sun, 29 Mar 2009 21:59:58 +0000 (UTC) (envelope-from kris@FreeBSD.org) Received: from dhcp-172-28-76-41.eur.corp.google.com (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id BD9118FC0A; Sun, 29 Mar 2009 21:59:57 +0000 (UTC) (envelope-from kris@FreeBSD.org) Message-ID: <49CFEF5D.1040605@FreeBSD.org> Date: Sun, 29 Mar 2009 22:59:57 +0100 From: Kris Kennaway User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: wenji wu References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: LOCK_PROFILING does not work on FreeBSD 8.0-CURRENT 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, 29 Mar 2009 21:59:58 -0000 wenji wu wrote: > That was my typo in the email. > > It was correct when I compiled the kernel. Otherwise, it can not go through > the compiling. Do you have both wenjikernel and WENJIKERNEL config files? Kris > > > On 3/29/09 4:38 PM, "Kris Kennaway" wrote: > >> Wenji Wu wrote: >>> Here is my procedures: >>> >>> (1) run "cvsup supfile" to synchronize the latest kernel >>> >>> (2) edit my kernel configuration file, and add "options LOCK_PROFILING" to >>> my kernel configuration file >>> >>> (3) run "make buildkernel KERNCONF=wenjikernel" >>> >>> (4) run "make installkernel kernconf=WENJIKERNEL" >> KERNCONF and the value of this variable are both case-sensitive. >> >> Kris >> >>> (5) run "reboot" to reboot my system. >>> >>> Here is the system printout after the reboot. >>> >>> (1) "$ uname -a" >>> FreeBSD wan-koi.fnal.gov 8.0-CURRENT FreeBSD 8.0-CURRENT #8: Sun Mar 29 >>> 20:11:07 UTC 2009 >>> root@wan-koi.fnal.gov:/usr/obj/usr/src/sys/wenjikernel amd64 >>> >>> (2) "sysctl -a|grep lock" >>> $ sysctl -a|grep lock >>> kern.clockrate: { hz = 1000, tick = 1000, profhz = 2000, stathz = 133 } >>> vm.pageout_lock_miss: 0 >>> net.inet.tcp.wlock_looped: 0 >>> net.inet.tcp.wlock_relocked: 0 >>> net.inet.tcp.wlock_upgraded: 56 >>> net.inet.tcp.tcp_wlock_atfirst: 97 >>> net.inet.tcp.rlock_atfirst: 757 >>> net.inet.tcp.read_locking: 1 >>> debug.acpi.reset_clock: 1 >>> debug.rwlock.loops: 10000 >>> debug.rwlock.retry: 10 >>> debug.to_avg_lockcalls: 17 >>> hw.clockrate: 2666 >>> machdep.wall_cmos_clock: 0 >>> p1003_1b.memlock: 0 >>> p1003_1b.memlock_range: 0 >>> dev.atrtc.0.%desc: AT realtime clock >>> >>> >>> What else did I have miss? >>> >>> thanks >>> >>> wenji >>> >>> >>> >>> >> _______________________________________________ >> 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 Sun Mar 29 22:18:43 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 D681B106566B; Sun, 29 Mar 2009 22:18:43 +0000 (UTC) (envelope-from onemda@gmail.com) Received: from mail-ew0-f171.google.com (mail-ew0-f171.google.com [209.85.219.171]) by mx1.freebsd.org (Postfix) with ESMTP id 13FC28FC0A; Sun, 29 Mar 2009 22:18:42 +0000 (UTC) (envelope-from onemda@gmail.com) Received: by ewy19 with SMTP id 19so1659564ewy.43 for ; Sun, 29 Mar 2009 15:18: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 :content-transfer-encoding; bh=NTEIe5TNzxnfXFW3BfbAkQPAMVEzVIEKrxm1QhO/NTk=; b=asknnmy8T4YwxXAQa7NgHbuzRb/cTzVd5Qpsy5YYSFlwh2b4LnEbbtKamVPn2RcwAe cJ7XxXLX2fECPFHQoUFAFw2jCtfBBeDY1pkcAM5ldPljfwKWuUiSrs+PZ+AWcXdULnT5 J+66JhUdEXCpRTnuRbSA7zN1SzdLW56NxEAsw= 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=wGauumvwODuDtVvstw8WQZQyHLQhgpvbGlqeW2rI+vTtF82L8wdljOyc8Qj+52NPfB fp5h76lKZaBDzZNSOw6Sqw1rYDB1xr1IaHvGSzBx93duMpMgXZO96JIM57BHpe/Cgvc4 m08dDBloratvVluP7VUHUbCzrn/AbbIojf8DY= MIME-Version: 1.0 Received: by 10.210.130.13 with SMTP id c13mr2118032ebd.40.1238365122002; Sun, 29 Mar 2009 15:18:42 -0700 (PDT) In-Reply-To: <200903111233.14029.jkim@FreeBSD.org> References: <200903111233.14029.jkim@FreeBSD.org> Date: Sun, 29 Mar 2009 23:18:41 +0100 Message-ID: <3a142e750903291518x7f941c6ai6b27fae1472a9137@mail.gmail.com> From: "Paul B. Mahol" To: Jung-uk Kim Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org, freebsd-amd64@freebsd.org Subject: Re: [HEADSUP] amd64 suspend/resume code to be comitted 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, 29 Mar 2009 22:18:44 -0000 On 3/11/09, Jung-uk Kim wrote: > With popular demands, I will commit the following patch in next few > days unless a showstopper is found or "over-my-dead-body" type of > review is received. ;-) > > http://people.freebsd.org/~jkim/amd64_suspend-20090311.diff > > FYI, it was originally posted here: > > http://docs.freebsd.org/cgi/mid.cgi?200810211228.31028.jkim > > and here: > > http://docs.freebsd.org/cgi/mid.cgi?200812102120.03788.jkim > > Please read the original threads for more information about the patch. Just for the record: I tested amd64 SMP suspend/resume on HP nx7300 via usb stick and it works. (video is resumed if agp, drm and i915 are loaded) Now, if only same is going to happen with i386 .... -- Paul From owner-freebsd-current@FreeBSD.ORG Sun Mar 29 22:19: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 C1A201065692; Sun, 29 Mar 2009 22:19:29 +0000 (UTC) (envelope-from wenji@fnal.gov) Received: from mailgw2.fnal.gov (mailgw2.fnal.gov [131.225.111.12]) by mx1.freebsd.org (Postfix) with ESMTP id 940028FC30; Sun, 29 Mar 2009 22:19:29 +0000 (UTC) (envelope-from wenji@fnal.gov) Received: from mailav1.fnal.gov (mailav1.fnal.gov [131.225.111.18]) by mailgw2.fnal.gov (iPlanet Messaging Server 5.2 HotFix 2.06 (built Mar 28 2005)) with SMTP id <0KHA008FUGO4IF@mailgw2.fnal.gov>; Sun, 29 Mar 2009 17:19:29 -0500 (CDT) Received: from mailgw2.fnal.gov ([131.225.111.12]) by mailav1.fnal.gov (SAVSMTP 3.1.7.47) with SMTP id M2009032917192830127 ; Sun, 29 Mar 2009 17:19:28 -0500 Received: from conversion-daemon.mailgw2.fnal.gov by mailgw2.fnal.gov (iPlanet Messaging Server 5.2 HotFix 2.06 (built Mar 28 2005)) id <0KHA00D01GLQGA@mailgw2.fnal.gov> (original mail from wenji@fnal.gov); Sun, 29 Mar 2009 17:19:29 -0500 (CDT) Received: from [131.225.88.20] (null-002241fb8457.dhcp.fnal.gov [131.225.88.20]) by mailgw2.fnal.gov (iPlanet Messaging Server 5.2 HotFix 2.06 (built Mar 28 2005)) with ESMTP id <0KHA008B2GOGLW@mailgw2.fnal.gov>; Sun, 29 Mar 2009 17:19:28 -0500 (CDT) Date: Sun, 29 Mar 2009 17:19:28 -0500 From: wenji wu In-reply-to: <49CFEF5D.1040605@FreeBSD.org> To: Kris Kennaway Message-id: MIME-version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Thread-topic: LOCK_PROFILING does not work on FreeBSD 8.0-CURRENT Thread-index: AcmwvGynmQYBA2H1d0WeizAYpVA2gg== User-Agent: Microsoft-Entourage/12.15.0.081119 Cc: freebsd-current@freebsd.org Subject: Re: LOCK_PROFILING does not work on FreeBSD 8.0-CURRENT 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, 29 Mar 2009 22:19:32 -0000 > > Do you have both wenjikernel and WENJIKERNEL config files? >>>> (4) run "make installkernel kernconf=WENJIKERNEL" >>> KERNCONF and the value of this variable are both case-sensitive. No, I just have "wenjikernel". It was a typo in the email. As you know, even I have both wenjikernel and WENJIKERNEL config files, if I run "make installkernel kernconf xxxx", the install process won't go through. For a successful kernel installing, "kernconf" has to be upper-case as "KERNCONF". Nothing wrong with my compiling and installing process! It was an email typo. wenji From owner-freebsd-current@FreeBSD.ORG Sun Mar 29 23:29: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 B59E21065673 for ; Sun, 29 Mar 2009 23:29:49 +0000 (UTC) (envelope-from kris@FreeBSD.org) Received: from dhcp-172-28-76-41.eur.corp.google.com (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 16D908FC13; Sun, 29 Mar 2009 23:29:48 +0000 (UTC) (envelope-from kris@FreeBSD.org) Message-ID: <49D0046C.8020909@FreeBSD.org> Date: Mon, 30 Mar 2009 00:29:48 +0100 From: Kris Kennaway User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: wenji wu References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: LOCK_PROFILING does not work on FreeBSD 8.0-CURRENT 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, 29 Mar 2009 23:29:50 -0000 wenji wu wrote: >> Do you have both wenjikernel and WENJIKERNEL config files? > >>>>> (4) run "make installkernel kernconf=WENJIKERNEL" >>>> KERNCONF and the value of this variable are both case-sensitive. > > No, I just have "wenjikernel". > > It was a typo in the email. > > As you know, even I have both wenjikernel and WENJIKERNEL config files, if I > run "make installkernel kernconf xxxx", the install process won't go > through. For a successful kernel installing, "kernconf" has to be upper-case > as "KERNCONF". > > Nothing wrong with my compiling and installing process! It was an email > typo. OK, but you've still not shown that you didn't accidentally make a mistake somewhere along the way. I asked you to confirm the exact steps you took because something doesn't make sense, so it's important to show what you actually did rather than retyping from memory what you think you did, in case you had made a mistake without noticing it. Here is the output of a FreeBSD 8.0 system showing that LOCK_PROFILING does in fact work as expected: gohan10# uname -a FreeBSD gohan10.freebsd.org 8.0-CURRENT FreeBSD 8.0-CURRENT #8: Sun Mar 29 12:06:13 UTC 2009 gohan10# grep LOCK_PROFILING root@gohan10.freebsd.org:/usr/src/sys/amd64/compile/CLUSTER amd64 /usr/src/sys/amd64/conf/CLUSTER options LOCK_PROFILING gohan10# sysctl -a | grep debug.lock debug.lock.prof.enable: 0 debug.lock.prof.reset: 0 debug.lock.prof.stats: debug.lock.prof.rejected: 0 debug.lock.prof.skipcount: 0 debug.lock.prof.skipspin: 0 Kris From owner-freebsd-current@FreeBSD.ORG Sun Mar 29 23:41: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 7D5DD106564A for ; Sun, 29 Mar 2009 23:41:02 +0000 (UTC) (envelope-from kris@FreeBSD.org) Received: from dhcp-172-28-76-41.eur.corp.google.com (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id D1C068FC12; Sun, 29 Mar 2009 23:41:01 +0000 (UTC) (envelope-from kris@FreeBSD.org) Message-ID: <49D0070D.2060905@FreeBSD.org> Date: Mon, 30 Mar 2009 00:41:01 +0100 From: Kris Kennaway User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: wenji wu References: <49D0046C.8020909@FreeBSD.org> In-Reply-To: <49D0046C.8020909@FreeBSD.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: LOCK_PROFILING does not work on FreeBSD 8.0-CURRENT 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, 29 Mar 2009 23:41:02 -0000 Kris Kennaway wrote: > wenji wu wrote: >>> Do you have both wenjikernel and WENJIKERNEL config files? >> >>>>>> (4) run "make installkernel kernconf=WENJIKERNEL" >>>>> KERNCONF and the value of this variable are both case-sensitive. >> >> No, I just have "wenjikernel". >> >> It was a typo in the email. >> >> As you know, even I have both wenjikernel and WENJIKERNEL config >> files, if I >> run "make installkernel kernconf xxxx", the install process won't go >> through. For a successful kernel installing, "kernconf" has to be >> upper-case >> as "KERNCONF". >> >> Nothing wrong with my compiling and installing process! It was an email >> typo. > > OK, but you've still not shown that you didn't accidentally make a > mistake somewhere along the way. > > I asked you to confirm the exact steps you took because something > doesn't make sense, so it's important to show what you actually did > rather than retyping from memory what you think you did, in case you had > made a mistake without noticing it. > > Here is the output of a FreeBSD 8.0 system showing that LOCK_PROFILING > does in fact work as expected: > > gohan10# uname -a > FreeBSD gohan10.freebsd.org 8.0-CURRENT FreeBSD 8.0-CURRENT #8: Sun Mar > 29 12:06:13 UTC 2009 gohan10# grep LOCK_PROFILING > root@gohan10.freebsd.org:/usr/src/sys/amd64/compile/CLUSTER amd64 > /usr/src/sys/amd64/conf/CLUSTER > options LOCK_PROFILING Sorry, that pasted badly, it should have read: gohan10# uname -a FreeBSD gohan10.freebsd.org 8.0-CURRENT FreeBSD 8.0-CURRENT #8: Sun Mar 29 12:06:13 UTC 2009 root@gohan10.freebsd.org:/usr/src/sys/amd64/compile/CLUSTER amd64 gohan10# grep LOCK_PROFILING /usr/src/sys/amd64/conf/CLUSTER options LOCK_PROFILING > gohan10# sysctl -a | grep debug.lock > debug.lock.prof.enable: 0 > debug.lock.prof.reset: 0 > debug.lock.prof.stats: > debug.lock.prof.rejected: 0 > debug.lock.prof.skipcount: 0 > debug.lock.prof.skipspin: 0 > > Kris > _______________________________________________ > 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 Mon Mar 30 00:40: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 C4370106564A; Mon, 30 Mar 2009 00:40:50 +0000 (UTC) (envelope-from lstewart@room52.net) Received: from outbound.icp-qv1-irony-out2.iinet.net.au (outbound.icp-qv1-irony-out2.iinet.net.au [203.59.1.107]) by mx1.freebsd.org (Postfix) with ESMTP id F0BCC8FC13; Mon, 30 Mar 2009 00:40:49 +0000 (UTC) (envelope-from lstewart@room52.net) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAASyz0l8qF1T/2dsb2JhbADGU4IsgU4G X-IronPort-AV: E=Sophos;i="4.38,443,1233500400"; d="scan'208";a="457850208" Received: from unknown (HELO lawrence1.loshell.room52.net) ([124.168.93.83]) by outbound.icp-qv1-irony-out2.iinet.net.au with ESMTP; 30 Mar 2009 08:40:47 +0800 Message-ID: <49D0150E.8050601@room52.net> Date: Mon, 30 Mar 2009 11:40:46 +1100 From: Lawrence Stewart User-Agent: Thunderbird 2.0.0.21 (X11/20090326) MIME-Version: 1.0 To: Alexander Motin References: <49CF0754.9070907@room52.net> <49CF2B0C.7050301@FreeBSD.org> <49CF6551.4080301@room52.net> <49CF68C4.8020806@FreeBSD.org> In-Reply-To: <49CF68C4.8020806@FreeBSD.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@FreeBSD.org Subject: [SOLVED] Re: kernel panic with snd_hda "panic: Duplicate free of item 0xffffff00025f8c00 from zone 0xffffff00b697d400(1024)" 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, 30 Mar 2009 00:40:51 -0000 Alexander Motin wrote: > Lawrence Stewart wrote: >> Alexander Motin wrote: >>> I can't reproduce neither "Invalid corb size (0)" error, nor the >>> crash in case of it. I have tried to simulate that error, but system >>> handled it correctly. But I have INVARIANTS disabled on my system. >>> >>> Can you try to disable MSI? >> >> Setting hw.pci.enable_msix=0 and hw.pci.enable_msi=0 at the loader >> prompt made no difference. > > It could also be done with hint.hdac.0.msi=0. > >>> Can you try to move hdac_irq_alloc() call after hdac_rirb_init() in >>> hdac_attach()? May be interrupt shots while something is not yet >>> initialized? >> >> Running with the following patch made no difference either. >> >> Any other ideas I could try? > > I have none. I haven't changed anything significant last time, except > enabling MSI. You can try to investigate both problems: original > "Invalid corb size (0)" and the consequent crash. As I have said, I > can't reproduce none of them. Try to put some debug printfs inside > hdac_get_capabilities(), may be it give some new clues. > Seems to have been a red herring. I tried a couple of older kernel revisions which made no difference. Booting into windows, the sound card works fine. Then I booted into FreeBSD and it booted fine without the panic, although the hda driver spewed out a heap of error messages like this: Mar 30 09:50:12 lstewart-laptop kernel: hdac0: hdac_command_send_internal: TIMEOUT numcmd=1, sent=1, received=0 Mar 30 09:50:12 lstewart-laptop kernel: hdac0: hdac_command_send_internal: TIMEOUT numcmd=1, sent=1, received=0 Mar 30 09:50:12 lstewart-laptop kernel: hdac0: Codec #0 is not responding! Probing aborted. repeated up to: Mar 30 09:50:12 lstewart-laptop kernel: hdac0: hdac_command_send_internal: TIMEOUT numcmd=1, sent=0, received=0 Mar 30 09:50:12 lstewart-laptop kernel: hdac0: hdac_command_send_internal: TIMEOUT numcmd=1, sent=0, received=0 Mar 30 09:50:12 lstewart-laptop kernel: hdac0: Codec #14 is not responding! Probing aborted. Then I rebooted again and got the panic on every reboot. Weird. On a whim, I suspected fishy BIOS settings left over after a BIOS upgrade so I reset all BIOS values to factory defaults and now it seems to be working fine. There are no audio related options in the BIOS, so not sure what was broken but something must not have been happy or must have been left in an inconsistent state somehow. Sorry for not having thought of it sooner, but it looks like the case is closed. Cheers, Lawrence From owner-freebsd-current@FreeBSD.ORG Mon Mar 30 00:55: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 47FFE106566C; Mon, 30 Mar 2009 00:55:07 +0000 (UTC) (envelope-from wenji@fnal.gov) Received: from mailgw2.fnal.gov (mailgw2.fnal.gov [131.225.111.12]) by mx1.freebsd.org (Postfix) with ESMTP id 1A2768FC13; Mon, 30 Mar 2009 00:55:06 +0000 (UTC) (envelope-from wenji@fnal.gov) Received: from mailav1.fnal.gov (mailav1.fnal.gov [131.225.111.18]) by mailgw2.fnal.gov (iPlanet Messaging Server 5.2 HotFix 2.06 (built Mar 28 2005)) with SMTP id <0KHA008THNUMIF@mailgw2.fnal.gov>; Sun, 29 Mar 2009 19:55:06 -0500 (CDT) Received: from mailgw1.fnal.gov ([131.225.111.11]) by mailav1.fnal.gov (SAVSMTP 3.1.7.47) with SMTP id M2009032919550601446 ; Sun, 29 Mar 2009 19:55:06 -0500 Received: from conversion-daemon.mailgw1.fnal.gov by mailgw1.fnal.gov (iPlanet Messaging Server 5.2 HotFix 2.06 (built Mar 28 2005)) id <0KHA00L01NSESV@mailgw1.fnal.gov> (original mail from wenji@fnal.gov); Sun, 29 Mar 2009 19:55:06 -0500 (CDT) Received: from fnal.gov (imap2.fnal.gov [131.225.111.7]) by mailgw1.fnal.gov (iPlanet Messaging Server 5.2 HotFix 2.06 (built Mar 28 2005)) with ESMTP id <0KHA007S4NVURA@mailgw1.fnal.gov>; Sun, 29 Mar 2009 19:55:06 -0500 (CDT) Received: from [67.184.224.143] by imap2.fnal.gov (mshttpd); Sun, 29 Mar 2009 19:55:06 -0500 Date: Sun, 29 Mar 2009 19:55:06 -0500 From: Wenji Wu In-reply-to: <49D0070D.2060905@FreeBSD.org> To: Kris Kennaway Message-id: MIME-version: 1.0 X-Mailer: Sun Java(tm) System Messenger Express 6.3-6.03 (built Mar 14 2008; 32bit) Content-type: text/plain; charset=us-ascii Content-language: en Content-transfer-encoding: 7BIT Content-disposition: inline X-Accept-Language: en Priority: normal References: <49D0046C.8020909@FreeBSD.org> <49D0070D.2060905@FreeBSD.org> Cc: freebsd-current@freebsd.org Subject: Re: LOCK_PROFILING does not work on FreeBSD 8.0-CURRENT 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, 30 Mar 2009 00:55:07 -0000 > gohan10# grep LOCK_PROFILING /usr/src/sys/amd64/conf/CLUSTER > options LOCK_PROFILING Hi, kris, Your suspicion is granted. In the beginning, I also suspected I made some mistakes. So, I tried exactly the same procedures with FreeBSD 7.2. LOCK_PROFILING works for me. Surely, something is wrong with FreeBSD 8.0. I loaded my system with 7.2 first, then updated it to 8.0 with "cvsup supfile". I am thinking if something breaks that the LOCK_PROFILING is not really turned on even it is configured. I will check "grep LOCK_PROFILING /usr/src/sys/amd64/conf/CLUSTER" tomorrow. thanks, wenji From owner-freebsd-current@FreeBSD.ORG Mon Mar 30 01:40: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 B85001065676; Mon, 30 Mar 2009 01:40:04 +0000 (UTC) (envelope-from davidxu@freebsd.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 9CE958FC15; Mon, 30 Mar 2009 01:40:04 +0000 (UTC) (envelope-from davidxu@freebsd.org) Received: from apple.my.domain (root@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id n2U1dwlM047752; Mon, 30 Mar 2009 01:39:59 GMT (envelope-from davidxu@freebsd.org) Message-ID: <49D022EF.8030305@freebsd.org> Date: Mon, 30 Mar 2009 09:39:59 +0800 From: David Xu User-Agent: Thunderbird 2.0.0.9 (X11/20080612) MIME-Version: 1.0 To: Julian Elischer References: <11609492.9579.1238167614335.JavaMail.root@vms070.mailsrvcs.net> <49CD0405.1060704@samsco.org> <49CD30E9.7030501@elischer.org> <49CEC261.4010803@freebsd.org> <49CF0523.8020905@elischer.org> In-Reply-To: <49CF0523.8020905@elischer.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: Sergey Babkin , freebsd-hackers@freebsd.org, attilio@freebsd.org, phk@phk.freebsd.dk, freebsd-current@freebsd.org, prashant.vaibhav@gmail.com Subject: Re: Improving the kernel/i386 timecounter performance (GSoC proposal) 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, 30 Mar 2009 01:40:07 -0000 Julian Elischer wrote: > depends on the hardware. > anyhow I was only saying it was possible, not necessarily > good or even useful. > > I had done some works for thread private page shared by kernel and userland when I was doing userland spinlock, if userland asks a page, kernel will allocate it and put some interesting thing in it by scheduler etcs, these code may be useful. From owner-freebsd-current@FreeBSD.ORG Mon Mar 30 01:43: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 7B56E1065670; Mon, 30 Mar 2009 01:43:22 +0000 (UTC) (envelope-from davidxu@freebsd.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 646FC8FC08; Mon, 30 Mar 2009 01:43:22 +0000 (UTC) (envelope-from davidxu@freebsd.org) Received: from apple.my.domain (root@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id n2U1hHRS060570; Mon, 30 Mar 2009 01:43:18 GMT (envelope-from davidxu@freebsd.org) Message-ID: <49D023B7.8070402@freebsd.org> Date: Mon, 30 Mar 2009 09:43:19 +0800 From: David Xu User-Agent: Thunderbird 2.0.0.9 (X11/20080612) MIME-Version: 1.0 To: Julian Elischer References: <11609492.9579.1238167614335.JavaMail.root@vms070.mailsrvcs.net> <49CD0405.1060704@samsco.org> <49CD30E9.7030501@elischer.org> <49CEC261.4010803@freebsd.org> <49CF0523.8020905@elischer.org> <49D022EF.8030305@freebsd.org> In-Reply-To: <49D022EF.8030305@freebsd.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: Sergey Babkin , freebsd-hackers@freebsd.org, attilio@freebsd.org, phk@phk.freebsd.dk, freebsd-current@freebsd.org, prashant.vaibhav@gmail.com Subject: Re: Improving the kernel/i386 timecounter performance (GSoC proposal) 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, 30 Mar 2009 01:43:22 -0000 David Xu wrote: > Julian Elischer wrote: > >> depends on the hardware. >> anyhow I was only saying it was possible, not necessarily >> good or even useful. >> >> > > I had done some works for thread private page shared by kernel > and userland when I was doing userland spinlock, if userland asks > a page, kernel will allocate it and put some interesting thing in > it by scheduler etcs, these code may be useful. > FYI: http://people.freebsd.org/~davidxu/schedctl/ From owner-freebsd-current@FreeBSD.ORG Mon Mar 30 02:00: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 132C71065674 for ; Mon, 30 Mar 2009 02:00:12 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from wf-out-1314.google.com (wf-out-1314.google.com [209.85.200.173]) by mx1.freebsd.org (Postfix) with ESMTP id 6007D8FC13 for ; Mon, 30 Mar 2009 02:00:10 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: by wf-out-1314.google.com with SMTP id 24so2000555wfg.7 for ; Sun, 29 Mar 2009 19:00:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:received:from:date:to:cc :subject:message-id:reply-to:references:mime-version:content-type :content-disposition:in-reply-to:user-agent; bh=eCg2JSa1S1qzvbdpYI+7S2EEQ7WDWi3i14Jk0nGvDT0=; b=F6s7EtxK16zTEVz8UtdKH4sk15HHfyKQmW/t5bLBU+de9ZL1aIzKIQpuQBR/w5zP8X wW2Wxy78a2mhWyPsBg597bmI7vO6FpRheEletg+BL/fBRIChWXVIVGTdLgNgGJDoZEuA zoOOuQudNbOTpsX8z1c6MxkCpnOKveeDS2azE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:date:to:cc:subject:message-id:reply-to:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; b=CeiqmQS8CVafeB7oTO4k8p+CKtI2IZu9Hls6MyeBUqi2eN2iXc20wydNFzTR+8e891 1/8vXUJdFczLV1u12l4buLwh71LtBvy21dZs/z3PdK6MtZIRZ8IGIrtLgMrRwVfDeuiA MevPyWyFPqzpF+V0Ear8rGITHnK8m9B2hJZo8= Received: by 10.143.3.7 with SMTP id f7mr1903455wfi.92.1238378410031; Sun, 29 Mar 2009 19:00:10 -0700 (PDT) Received: from michelle.cdnetworks.co.kr ([114.111.62.249]) by mx.google.com with ESMTPS id l31sm8726070rvb.11.2009.03.29.19.00.08 (version=SSLv3 cipher=RC4-MD5); Sun, 29 Mar 2009 19:00:09 -0700 (PDT) Received: by michelle.cdnetworks.co.kr (sSMTP sendmail emulation); Mon, 30 Mar 2009 10:59:07 +0900 From: Pyun YongHyeon Date: Mon, 30 Mar 2009 10:59:07 +0900 To: Sebastiaan van Doesselaar Message-ID: <20090330015907.GB7076@michelle.cdnetworks.co.kr> References: <3DB40EE4-80C8-49D4-8094-27A6F424D601@akiha.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3DB40EE4-80C8-49D4-8094-27A6F424D601@akiha.nl> User-Agent: Mutt/1.4.2.3i Cc: freebsd-current@freebsd.org Subject: Re: Slow network problem X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: pyunyh@gmail.com List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Mar 2009 02:00:13 -0000 On Sat, Mar 28, 2009 at 10:41:17AM +0100, Sebastiaan van Doesselaar wrote: > Dear all, > > At the moment I'm running a CURRENT snapshot from February, yet > somehow my network speeds are quite low. I've tested this with iperf, > SMB and SCP, yet all give me more or less the same speeds, which is > about 50 - 60Mbps. The weird thing is that this is only the case when > the FreeBSD machine receives data, sending data is all fine. At least, > with a 100Mbps link iperf gives me quite decent speeds (>90Mbps) > > This is the case for gigabit as well as 100Mbps, depending on what > cable I use to the switch. > I've also tested this directly, with a cable to a machine, but this > was to no avail. I've tried changing some variables with sysctl > (net.inet.tcp.recvspace, sendspace, recvbuf_auto, > kern.ipc.maxsockbuf), yet those did not do anything. > > dmesg has this to say about the network card: > rgephy0: PHY 1 on miibus0 > rgephy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, > 1000baseT-FDX, aut > Show me complete dmesg output, the above just tells what PHY hardware is used. > I cannot say I've tested this with a STABLE release, but in Windows > and Gentoo Linux this worked fine. > > I have found one person with a seemingly similar problem, but this > person had the problem a couple of years ago and did not resolve it at > the time, or so it seems. See > http://kerneltrap.org/mailarchive/freebsd-hackers/2006/5/30/214298 for his > thread. > > I hope someone can give me some tips that will solve this problem. If > information is lacking, please do say so. > From owner-freebsd-current@FreeBSD.ORG Mon Mar 30 02:17: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 99E02106566B for ; Mon, 30 Mar 2009 02:17:51 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.229]) by mx1.freebsd.org (Postfix) with ESMTP id 5BDD78FC0A for ; Mon, 30 Mar 2009 02:17:51 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: by rv-out-0506.google.com with SMTP id l9so2505339rvb.43 for ; Sun, 29 Mar 2009 19:17:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:received:from:date:to:cc :subject:message-id:reply-to:references:mime-version:content-type :content-disposition:in-reply-to:user-agent; bh=8H9N+8fxM9oJowSmuAX2V75kvhlar/1CXu9jccWUEU4=; b=Ing66kDPFltFEEGSUlcgDTle96FeOZLqu1FOu+zZQWRF6l7kwjP0PVtV8mr7IXf15X uKdY2f3hL0tUucwmLRrpARbiFI0hr4ktLyIOtqDTEvLs9UvnSFFzg/uGaIo2fc14olH+ 4AfaEnbB8sFRViAsnjyG3R6uL4vIhAQiYCasE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:date:to:cc:subject:message-id:reply-to:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; b=pmhtaNzY+KCNOH/8iTy760LfXYyiHbtALhsq0Tua1zoEyinhsYywZxAaOEyQk33SpD fJiLx7zQQK/oG2chSkVcylvEVTtJWjXEcqTqHWZLB/nqe2thKFN+hyIGEZWLsYvI+oah JvLfmrFg9XrC7ixyqPZSQI2n2bDF//4ElKcok= Received: by 10.140.248.15 with SMTP id v15mr2522791rvh.165.1238379470766; Sun, 29 Mar 2009 19:17:50 -0700 (PDT) Received: from michelle.cdnetworks.co.kr ([114.111.62.249]) by mx.google.com with ESMTPS id g14sm11780206rvb.29.2009.03.29.19.17.49 (version=SSLv3 cipher=RC4-MD5); Sun, 29 Mar 2009 19:17:50 -0700 (PDT) Received: by michelle.cdnetworks.co.kr (sSMTP sendmail emulation); Mon, 30 Mar 2009 11:16:48 +0900 From: Pyun YongHyeon Date: Mon, 30 Mar 2009 11:16:48 +0900 To: Niki Denev Message-ID: <20090330021648.GE7076@michelle.cdnetworks.co.kr> References: <75656435-49E2-457A-9CFE-8706CD44916E@gmail.com> <20090328080924.GD99923@michelle.cdnetworks.co.kr> <2e77fc10903280259s5a761cacs398b88649a2367fe@mail.gmail.com> <20090328102735.GE99923@michelle.cdnetworks.co.kr> <2e77fc10903280942u7c934aa4w80176680e9dff6d7@mail.gmail.com> <2e77fc10903281539h7b713711w116a90fd2bfadbcf@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <2e77fc10903281539h7b713711w116a90fd2bfadbcf@mail.gmail.com> User-Agent: Mutt/1.4.2.3i Cc: Sepherosa Ziehau , freebsd-current@freebsd.org Subject: Re: axe(4) (Belkin F5D5055) problems X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: pyunyh@gmail.com List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Mar 2009 02:17:51 -0000 On Sun, Mar 29, 2009 at 12:39:22AM +0200, Niki Denev wrote: > On Sat, Mar 28, 2009 at 6:42 PM, Niki Denev wrote: > > On Sat, Mar 28, 2009 at 12:27 PM, Pyun YongHyeon wrote: > >> On Sat, Mar 28, 2009 at 11:59:13AM +0200, Niki Denev wrote: > >>> 2009/3/28 Pyun YongHyeon : > >>> > On Fri, Mar 27, 2009 at 09:14:06PM +0200, Nikolay Denev wrote: > >>> >> -----BEGIN PGP SIGNED MESSAGE----- > >>> >> Hash: SHA1 > >>> >> > >>> >> Hello, > >>> >> > >>> >> I'm running -current from 23.03.09 and I'm experiencing some axe(4) > >>> >> problems. > >>> >> Basically the network connection works but when some more serious > >>> >> traffic hits the > >>> >> interface (i.e. torrent download) it then dies, ifconfig down/up > >>> >> does not help, only replugging of the adapter. > >>> >> > >>> >> I've tried running with hw.usb2.axe.debug=15 and the output was many > >>> >> lines of: > >>> >> > >>> >> ? ?axe_bulk_write_callback:853: transfer complete > >>> >> > >>> >> then a pause of several seconds and the kernel begins to print : > >>> >> > >>> >> ? ?axe_bulk_write_callback:925: transfer error, USB_ERR_TIMEOUT > >>> >> > >>> >> Another strange thing that I noticed is that, while the interface > >>> >> seems to be > >>> >> connected and working, if I type many times ifconfig ue0 consecutively > >>> >> most of the time it would show different settings for the auto > >>> >> negotiated link. > >>> >> I.e. it would cycle between 100baseTX-FDX, 1000baseT-FDX, no carrier, > >>> >> 100BaseT-FDX hw-loopback and 1000BaseT-FDX hw-loopback. > >>> >> > >>> >> The switch does not seem to register link flaps. > >>> >> > >>> > > >>> > axe(4) requires exact link state/speed information from mii(4) to > >>> > reprogram controller to resolved speed/duplex. In this case > >>> > ukphy(4) seems to report fake link state/speed to axe(4). > >>> > > >>> >> The kernel messages for the interface are : > >>> >> > >>> >> ? ?ugen2.5: at usbus2 > >>> >> ? ?axe0: on usbus2 > >>> >> ? ?axe0: PHYADDR 0xe0:0x01 > >>> >> ? ?miibus0: on axe0 > >>> >> ? ?ukphy0: PHY 1 on miibus0 > >>> >> ? ?ukphy0: ?10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, > >>> >> 1000baseT, 1000baseT-FDX, auto > >>> >> ? ?ue0: on axe0 > >>> >> ? ?ue0: Ethernet address: 00:11:50:xx:xx:xx > >>> >> > >>> >> devinfo -vr | grep phy > >>> >> ukphy0 pnpinfo oui=0xa0bc model=0x1 rev=0x2 at phyno=1 > >>> >> > >>> > > >>> > This looks like Agere systems ET110C TruePHY. Would you try > >>> > attached patch? Because truephy(4) pokes some undocumented PHY > >>> > registers on PHY reset I'm not sure this model also requires that > >>> > magic to make it work though. > >>> > > >>> > >>> Hi Pyun, > >>> > >>> Thanks for the patch. > >>> > >>> With it the PHY is now detected as truephy. > >>> The only thing that i notice is that if the media status changes displayed with > >>> ifconfig are less frequent, and I mostly see 1000baseT-FDX and 100baseT-HDX > >>> The packet loss is still there, and the interface again stops to work > >>> after some time. > >>> > >> > >> Ok, revert previous patch and try attached one. This one does not > >> try to load ET1011C dsp codes. If this does not work next thing > >> would be try to load dsp code for ET1011C revision 1 model. > >> Not sure where I can find required dsp code. > >> > > > > There don't seem to be any improvement with the new patch. > > The packetloss and media status changes are still here. > > Maybe check Linux/Solaris/OtherBSD driver? > > > > -- > > Niki > > > > LSI seem to have several documents about this phy chip, including > datasheet (which you probably have) and errata : > http://www.lsi.com/DistributionSystem/AssetDocument/documentation/networking/ethernet/et1011c/DS06-161GPHY_ET1011C_09-28-2007.pdf > http://www.lsi.com/DistributionSystem/AssetDocument/documentation/networking/ethernet/et1011c/ET1011C_Errata_08June2007.pdf > Yes, but unfortunately it is for model 3 or model 4. Yours is model 1. In fact I have no idea whether model 1 is ET1011C. It seems that there are ET1011A or ET1011B PHYs. Sepherosa, do you have more information on ET1011A/ET1011B PHY? From owner-freebsd-current@FreeBSD.ORG Mon Mar 30 02:48: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 94D2B106564A; Mon, 30 Mar 2009 02:48:53 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.239]) by mx1.freebsd.org (Postfix) with ESMTP id 179658FC08; Mon, 30 Mar 2009 02:48:52 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: by rv-out-0506.google.com with SMTP id l9so2515714rvb.43 for ; Sun, 29 Mar 2009 19:48:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:received:from:date:to:cc :subject:message-id:reply-to:references:mime-version:content-type :content-disposition:in-reply-to:user-agent; bh=KJBJ5NlMihHws/d+P67W3w+Nn5MLb07HC9CmCPxqTNE=; b=IIZBZ6BxfnccAwyZd7SN3vlTydVBcsiMEhhkrCrf4G+tk77n5W7v48LBZHSTMyxWOX zTFyjU82pzBl3GfQvwOgujPPiZiCDopQ4sgyKxkVsddlZ5DQ8irZias1hGQ+dUEkG7aU TbszDgxMf6Ma9iz4+I4Jd69EPAhNxp2aGe2EU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:date:to:cc:subject:message-id:reply-to:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; b=rmnxCFyrmxc2PM3AuMGkx06X1gvs0K8vFnY6rGwBX59S/VZmxQMSZW784P/dsI2g2m Stz0gwTuYWY9YpIgcc2gNu7L0nCTrWzaPsLzPJxQAYSv0VzG6X95VO6l+mMjwqz2x2KY Z0z9JkkYnu/TQUsiyvPbeXV+hKlqTKpL9psgo= Received: by 10.140.164.1 with SMTP id m1mr2537728rve.174.1238381331091; Sun, 29 Mar 2009 19:48:51 -0700 (PDT) Received: from michelle.cdnetworks.co.kr ([114.111.62.249]) by mx.google.com with ESMTPS id l31sm8769847rvb.5.2009.03.29.19.48.48 (version=SSLv3 cipher=RC4-MD5); Sun, 29 Mar 2009 19:48:50 -0700 (PDT) Received: by michelle.cdnetworks.co.kr (sSMTP sendmail emulation); Mon, 30 Mar 2009 11:47:48 +0900 From: Pyun YongHyeon Date: Mon, 30 Mar 2009 11:47:48 +0900 To: Niki Denev Message-ID: <20090330024748.GF7076@michelle.cdnetworks.co.kr> References: <75656435-49E2-457A-9CFE-8706CD44916E@gmail.com> <20090328080924.GD99923@michelle.cdnetworks.co.kr> <2e77fc10903280259s5a761cacs398b88649a2367fe@mail.gmail.com> <20090328102735.GE99923@michelle.cdnetworks.co.kr> <2e77fc10903280942u7c934aa4w80176680e9dff6d7@mail.gmail.com> <2e77fc10903281539h7b713711w116a90fd2bfadbcf@mail.gmail.com> <20090330021648.GE7076@michelle.cdnetworks.co.kr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20090330021648.GE7076@michelle.cdnetworks.co.kr> User-Agent: Mutt/1.4.2.3i Cc: Sepherosa Ziehau , freebsd-current@freebsd.org, delphij@FreeBSD.org Subject: Re: axe(4) (Belkin F5D5055) problems X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: pyunyh@gmail.com List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Mar 2009 02:48:53 -0000 On Mon, Mar 30, 2009 at 11:16:48AM +0900, Pyun YongHyeon wrote: > On Sun, Mar 29, 2009 at 12:39:22AM +0200, Niki Denev wrote: > > On Sat, Mar 28, 2009 at 6:42 PM, Niki Denev wrote: > > > On Sat, Mar 28, 2009 at 12:27 PM, Pyun YongHyeon wrote: > > >> On Sat, Mar 28, 2009 at 11:59:13AM +0200, Niki Denev wrote: > > >>> 2009/3/28 Pyun YongHyeon : > > >>> > On Fri, Mar 27, 2009 at 09:14:06PM +0200, Nikolay Denev wrote: > > >>> >> -----BEGIN PGP SIGNED MESSAGE----- > > >>> >> Hash: SHA1 > > >>> >> > > >>> >> Hello, > > >>> >> > > >>> >> I'm running -current from 23.03.09 and I'm experiencing some axe(4) > > >>> >> problems. > > >>> >> Basically the network connection works but when some more serious > > >>> >> traffic hits the > > >>> >> interface (i.e. torrent download) it then dies, ifconfig down/up > > >>> >> does not help, only replugging of the adapter. > > >>> >> > > >>> >> I've tried running with hw.usb2.axe.debug=15 and the output was many > > >>> >> lines of: > > >>> >> > > >>> >> ? ?axe_bulk_write_callback:853: transfer complete > > >>> >> > > >>> >> then a pause of several seconds and the kernel begins to print : > > >>> >> > > >>> >> ? ?axe_bulk_write_callback:925: transfer error, USB_ERR_TIMEOUT > > >>> >> > > >>> >> Another strange thing that I noticed is that, while the interface > > >>> >> seems to be > > >>> >> connected and working, if I type many times ifconfig ue0 consecutively > > >>> >> most of the time it would show different settings for the auto > > >>> >> negotiated link. > > >>> >> I.e. it would cycle between 100baseTX-FDX, 1000baseT-FDX, no carrier, > > >>> >> 100BaseT-FDX hw-loopback and 1000BaseT-FDX hw-loopback. > > >>> >> > > >>> >> The switch does not seem to register link flaps. > > >>> >> > > >>> > > > >>> > axe(4) requires exact link state/speed information from mii(4) to > > >>> > reprogram controller to resolved speed/duplex. In this case > > >>> > ukphy(4) seems to report fake link state/speed to axe(4). > > >>> > > > >>> >> The kernel messages for the interface are : > > >>> >> > > >>> >> ? ?ugen2.5: at usbus2 > > >>> >> ? ?axe0: on usbus2 > > >>> >> ? ?axe0: PHYADDR 0xe0:0x01 > > >>> >> ? ?miibus0: on axe0 > > >>> >> ? ?ukphy0: PHY 1 on miibus0 > > >>> >> ? ?ukphy0: ?10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, > > >>> >> 1000baseT, 1000baseT-FDX, auto > > >>> >> ? ?ue0: on axe0 > > >>> >> ? ?ue0: Ethernet address: 00:11:50:xx:xx:xx > > >>> >> > > >>> >> devinfo -vr | grep phy > > >>> >> ukphy0 pnpinfo oui=0xa0bc model=0x1 rev=0x2 at phyno=1 > > >>> >> > > >>> > > > >>> > This looks like Agere systems ET110C TruePHY. Would you try > > >>> > attached patch? Because truephy(4) pokes some undocumented PHY > > >>> > registers on PHY reset I'm not sure this model also requires that > > >>> > magic to make it work though. > > >>> > > > >>> > > >>> Hi Pyun, > > >>> > > >>> Thanks for the patch. > > >>> > > >>> With it the PHY is now detected as truephy. > > >>> The only thing that i notice is that if the media status changes displayed with > > >>> ifconfig are less frequent, and I mostly see 1000baseT-FDX and 100baseT-HDX > > >>> The packet loss is still there, and the interface again stops to work > > >>> after some time. > > >>> > > >> > > >> Ok, revert previous patch and try attached one. This one does not > > >> try to load ET1011C dsp codes. If this does not work next thing > > >> would be try to load dsp code for ET1011C revision 1 model. > > >> Not sure where I can find required dsp code. > > >> > > > > > > There don't seem to be any improvement with the new patch. > > > The packetloss and media status changes are still here. > > > Maybe check Linux/Solaris/OtherBSD driver? > > > > > > -- > > > Niki > > > > > > > LSI seem to have several documents about this phy chip, including > > datasheet (which you probably have) and errata : > > http://www.lsi.com/DistributionSystem/AssetDocument/documentation/networking/ethernet/et1011c/DS06-161GPHY_ET1011C_09-28-2007.pdf > > http://www.lsi.com/DistributionSystem/AssetDocument/documentation/networking/ethernet/et1011c/ET1011C_Errata_08June2007.pdf > > > > Yes, but unfortunately it is for model 3 or model 4. Yours is model > 1. In fact I have no idea whether model 1 is ET1011C. It seems that I was wrong. The datasheet is for model 1, but revision number is 4. > there are ET1011A or ET1011B PHYs. > > Sepherosa, do you have more information on ET1011A/ET1011B PHY? It looks odd to me, by chance is model 4 typo? Does et(4) really recognize the PHY as truephy(4)? Also CCed to Xin Li who ported the et(4) to FreeBSD. From owner-freebsd-current@FreeBSD.ORG Mon Mar 30 04:49: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 AA8F31065688 for ; Mon, 30 Mar 2009 04:49:18 +0000 (UTC) (envelope-from julian@elischer.org) Received: from outF.internet-mail-service.net (outf.internet-mail-service.net [216.240.47.229]) by mx1.freebsd.org (Postfix) with ESMTP id 83CAE8FC17 for ; Mon, 30 Mar 2009 04:49:18 +0000 (UTC) (envelope-from julian@elischer.org) Received: from idiom.com (mx0.idiom.com [216.240.32.160]) by out.internet-mail-service.net (Postfix) with ESMTP id 3D8BCC234; Sun, 29 Mar 2009 21:49:19 -0700 (PDT) X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e Received: from julian-mac.elischer.org (home.elischer.org [216.240.48.38]) by idiom.com (Postfix) with ESMTP id 320642D603E; Sun, 29 Mar 2009 21:49:14 -0700 (PDT) Message-ID: <49D04F63.4010800@elischer.org> Date: Sun, 29 Mar 2009 21:49:39 -0700 From: Julian Elischer User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: David Xu References: <11609492.9579.1238167614335.JavaMail.root@vms070.mailsrvcs.net> <49CD0405.1060704@samsco.org> <49CD30E9.7030501@elischer.org> <49CEC261.4010803@freebsd.org> <49CF0523.8020905@elischer.org> <49D022EF.8030305@freebsd.org> <49D023B7.8070402@freebsd.org> In-Reply-To: <49D023B7.8070402@freebsd.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: Sergey Babkin , freebsd-hackers@freebsd.org, attilio@freebsd.org, phk@phk.freebsd.dk, freebsd-current@freebsd.org, prashant.vaibhav@gmail.com Subject: Re: Improving the kernel/i386 timecounter performance (GSoC proposal) 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, 30 Mar 2009 04:49:20 -0000 David Xu wrote: > David Xu wrote: >> Julian Elischer wrote: >> >>> depends on the hardware. >>> anyhow I was only saying it was possible, not necessarily >>> good or even useful. >>> >>> >> >> I had done some works for thread private page shared by kernel >> and userland when I was doing userland spinlock, if userland asks >> a page, kernel will allocate it and put some interesting thing in >> it by scheduler etcs, these code may be useful. >> > FYI: > http://people.freebsd.org/~davidxu/schedctl/ reading this quickly, you allocate a separately addressed page for each thread, but, how do you use it? From owner-freebsd-current@FreeBSD.ORG Mon Mar 30 04:58: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 4483F1065670; Mon, 30 Mar 2009 04:58:58 +0000 (UTC) (envelope-from davidxu@freebsd.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 2BBDE8FC17; Mon, 30 Mar 2009 04:58:58 +0000 (UTC) (envelope-from davidxu@freebsd.org) Received: from apple.my.domain (root@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id n2U4wpXn015146; Mon, 30 Mar 2009 04:58:52 GMT (envelope-from davidxu@freebsd.org) Message-ID: <49D0518D.4040000@freebsd.org> Date: Mon, 30 Mar 2009 12:58:53 +0800 From: David Xu User-Agent: Thunderbird 2.0.0.9 (X11/20080612) MIME-Version: 1.0 To: Julian Elischer References: <11609492.9579.1238167614335.JavaMail.root@vms070.mailsrvcs.net> <49CD0405.1060704@samsco.org> <49CD30E9.7030501@elischer.org> <49CEC261.4010803@freebsd.org> <49CF0523.8020905@elischer.org> <49D022EF.8030305@freebsd.org> <49D023B7.8070402@freebsd.org> <49D04F63.4010800@elischer.org> In-Reply-To: <49D04F63.4010800@elischer.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: Sergey Babkin , freebsd-hackers@freebsd.org, attilio@freebsd.org, phk@phk.freebsd.dk, freebsd-current@freebsd.org, prashant.vaibhav@gmail.com Subject: Re: Improving the kernel/i386 timecounter performance (GSoC proposal) 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, 30 Mar 2009 04:58:59 -0000 Julian Elischer wrote: > David Xu wrote: >> David Xu wrote: >>> Julian Elischer wrote: >>> >>>> depends on the hardware. >>>> anyhow I was only saying it was possible, not necessarily >>>> good or even useful. >>>> >>>> >>> >>> I had done some works for thread private page shared by kernel >>> and userland when I was doing userland spinlock, if userland asks >>> a page, kernel will allocate it and put some interesting thing in >>> it by scheduler etcs, these code may be useful. >>> >> FYI: >> http://people.freebsd.org/~davidxu/schedctl/ > > reading this quickly, you allocate a separately addressed page for > each thread, but, how do you use it? > > I store the address in userland TLS area, then get it when I want to check some scheduling informations. From owner-freebsd-current@FreeBSD.ORG Mon Mar 30 05:02: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 BA044106564A for ; Mon, 30 Mar 2009 05:02:53 +0000 (UTC) (envelope-from julian@elischer.org) Received: from outO.internet-mail-service.net (outo.internet-mail-service.net [216.240.47.238]) by mx1.freebsd.org (Postfix) with ESMTP id 97CD08FC1C for ; Mon, 30 Mar 2009 05:02:53 +0000 (UTC) (envelope-from julian@elischer.org) Received: from idiom.com (mx0.idiom.com [216.240.32.160]) by out.internet-mail-service.net (Postfix) with ESMTP id B250BD52C; Sun, 29 Mar 2009 22:02:53 -0700 (PDT) X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e Received: from julian-mac.elischer.org (home.elischer.org [216.240.48.38]) by idiom.com (Postfix) with ESMTP id C9F842D6023; Sun, 29 Mar 2009 22:02:49 -0700 (PDT) Message-ID: <49D05292.30701@elischer.org> Date: Sun, 29 Mar 2009 22:03:14 -0700 From: Julian Elischer User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: David Xu References: <11609492.9579.1238167614335.JavaMail.root@vms070.mailsrvcs.net> <49CD0405.1060704@samsco.org> <49CD30E9.7030501@elischer.org> <49CEC261.4010803@freebsd.org> <49CF0523.8020905@elischer.org> <49D022EF.8030305@freebsd.org> <49D023B7.8070402@freebsd.org> <49D04F63.4010800@elischer.org> <49D0518D.4040000@freebsd.org> In-Reply-To: <49D0518D.4040000@freebsd.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: Sergey Babkin , freebsd-hackers@freebsd.org, attilio@freebsd.org, phk@phk.freebsd.dk, freebsd-current@freebsd.org, prashant.vaibhav@gmail.com Subject: Re: Improving the kernel/i386 timecounter performance (GSoC proposal) 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, 30 Mar 2009 05:02:54 -0000 David Xu wrote: > Julian Elischer wrote: >> David Xu wrote: >>> David Xu wrote: >>>> Julian Elischer wrote: >>>> >>>>> depends on the hardware. >>>>> anyhow I was only saying it was possible, not necessarily >>>>> good or even useful. >>>>> >>>>> >>>> >>>> I had done some works for thread private page shared by kernel >>>> and userland when I was doing userland spinlock, if userland asks >>>> a page, kernel will allocate it and put some interesting thing in >>>> it by scheduler etcs, these code may be useful. >>>> >>> FYI: >>> http://people.freebsd.org/~davidxu/schedctl/ >> >> reading this quickly, you allocate a separately addressed page for >> each thread, but, how do you use it? >> >> > I store the address in userland TLS area, then get it when I want to > check some scheduling informations. and the scheduler writes out interesting information to that location?... From owner-freebsd-current@FreeBSD.ORG Mon Mar 30 05:03: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 52BBC1065672; Mon, 30 Mar 2009 05:03: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 E1F298FC17; Mon, 30 Mar 2009 05:03:32 +0000 (UTC) (envelope-from scottl@samsco.org) Received: from phobos.local ([192.168.254.200]) (authenticated bits=0) by pooker.samsco.org (8.14.2/8.14.2) with ESMTP id n2U53GDt073333; Sun, 29 Mar 2009 23:03:16 -0600 (MDT) (envelope-from scottl@samsco.org) Message-ID: <49D05294.6040200@samsco.org> Date: Sun, 29 Mar 2009 23:03:16 -0600 From: Scott Long User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:1.8.1.13) Gecko/20080313 SeaMonkey/1.1.9 MIME-Version: 1.0 To: David Xu References: <11609492.9579.1238167614335.JavaMail.root@vms070.mailsrvcs.net> <49CD0405.1060704@samsco.org> <49CD30E9.7030501@elischer.org> <49CEC261.4010803@freebsd.org> <49CF0523.8020905@elischer.org> <49D022EF.8030305@freebsd.org> <49D023B7.8070402@freebsd.org> <49D04F63.4010800@elischer.org> <49D0518D.4040000@freebsd.org> In-Reply-To: <49D0518D.4040000@freebsd.org> X-Enigmail-Version: 0.95.6 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-4.4 required=3.8 tests=ALL_TRUSTED,BAYES_00 autolearn=ham version=3.1.8 X-Spam-Checker-Version: SpamAssassin 3.1.8 (2007-02-13) on pooker.samsco.org Cc: Sergey Babkin , freebsd-hackers@freebsd.org, attilio@freebsd.org, phk@phk.freebsd.dk, freebsd-current@freebsd.org, Julian Elischer , prashant.vaibhav@gmail.com Subject: Re: Improving the kernel/i386 timecounter performance (GSoC proposal) 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, 30 Mar 2009 05:03:34 -0000 David Xu wrote: > Julian Elischer wrote: >> David Xu wrote: >>> David Xu wrote: >>>> Julian Elischer wrote: >>>> >>>>> depends on the hardware. >>>>> anyhow I was only saying it was possible, not necessarily >>>>> good or even useful. >>>>> >>>>> >>>> >>>> I had done some works for thread private page shared by kernel >>>> and userland when I was doing userland spinlock, if userland asks >>>> a page, kernel will allocate it and put some interesting thing in >>>> it by scheduler etcs, these code may be useful. >>>> >>> FYI: >>> http://people.freebsd.org/~davidxu/schedctl/ >> >> reading this quickly, you allocate a separately addressed page for >> each thread, but, how do you use it? >> >> > I store the address in userland TLS area, then get it when I want to > check some scheduling informations. > Interesting, I was wondering earlier today if pointing to the per-thread syspage in from the TLS area would save the TLB invalidate that you were concerned about. Scott From owner-freebsd-current@FreeBSD.ORG Mon Mar 30 05:05: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 7C0D11065730; Mon, 30 Mar 2009 05:05:37 +0000 (UTC) (envelope-from davidxu@freebsd.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 61F468FC20; Mon, 30 Mar 2009 05:05:37 +0000 (UTC) (envelope-from davidxu@freebsd.org) Received: from apple.my.domain (root@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id n2U55XxY033078; Mon, 30 Mar 2009 05:05:34 GMT (envelope-from davidxu@freebsd.org) Message-ID: <49D0531F.1000005@freebsd.org> Date: Mon, 30 Mar 2009 13:05:35 +0800 From: David Xu User-Agent: Thunderbird 2.0.0.9 (X11/20080612) MIME-Version: 1.0 To: Julian Elischer References: <11609492.9579.1238167614335.JavaMail.root@vms070.mailsrvcs.net> <49CD0405.1060704@samsco.org> <49CD30E9.7030501@elischer.org> <49CEC261.4010803@freebsd.org> <49CF0523.8020905@elischer.org> <49D022EF.8030305@freebsd.org> <49D023B7.8070402@freebsd.org> <49D04F63.4010800@elischer.org> <49D0518D.4040000@freebsd.org> <49D05292.30701@elischer.org> In-Reply-To: <49D05292.30701@elischer.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: Sergey Babkin , freebsd-hackers@freebsd.org, attilio@freebsd.org, phk@phk.freebsd.dk, freebsd-current@freebsd.org, prashant.vaibhav@gmail.com Subject: Re: Improving the kernel/i386 timecounter performance (GSoC proposal) 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, 30 Mar 2009 05:05:38 -0000 Julian Elischer wrote: > David Xu wrote: >> Julian Elischer wrote: >>> David Xu wrote: >>>> David Xu wrote: >>>>> Julian Elischer wrote: >>>>> >>>>>> depends on the hardware. >>>>>> anyhow I was only saying it was possible, not necessarily >>>>>> good or even useful. >>>>>> >>>>>> >>>>> >>>>> I had done some works for thread private page shared by kernel >>>>> and userland when I was doing userland spinlock, if userland asks >>>>> a page, kernel will allocate it and put some interesting thing in >>>>> it by scheduler etcs, these code may be useful. >>>>> >>>> FYI: >>>> http://people.freebsd.org/~davidxu/schedctl/ >>> >>> reading this quickly, you allocate a separately addressed page for >>> each thread, but, how do you use it? >>> >>> >> I store the address in userland TLS area, then get it when I want to >> check some scheduling informations. > > and the scheduler writes out interesting information to that > location?... > > Yes. From owner-freebsd-current@FreeBSD.ORG Mon Mar 30 06:10:43 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 43E06106564A for ; Mon, 30 Mar 2009 06:10:43 +0000 (UTC) (envelope-from thompsa@FreeBSD.org) Received: from pele.citylink.co.nz (pele.citylink.co.nz [202.8.44.226]) by mx1.freebsd.org (Postfix) with ESMTP id D41428FC0C for ; Mon, 30 Mar 2009 06:10:42 +0000 (UTC) (envelope-from thompsa@FreeBSD.org) Received: from localhost (localhost [127.0.0.1]) by pele.citylink.co.nz (Postfix) with ESMTP id A8228FF06; Mon, 30 Mar 2009 19:10:41 +1300 (NZDT) X-Virus-Scanned: Debian amavisd-new at citylink.co.nz Received: from pele.citylink.co.nz ([127.0.0.1]) by localhost (pele.citylink.co.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6DixjSaS81IR; Mon, 30 Mar 2009 19:10:37 +1300 (NZDT) Received: from citylink.fud.org.nz (unknown [202.8.44.45]) by pele.citylink.co.nz (Postfix) with ESMTP; Mon, 30 Mar 2009 19:10:37 +1300 (NZDT) Received: by citylink.fud.org.nz (Postfix, from userid 1001) id 4A1CA11432; Mon, 30 Mar 2009 19:10:37 +1300 (NZDT) Date: Sun, 29 Mar 2009 23:10:36 -0700 From: Andrew Thompson To: Robert Noland Message-ID: <20090330061036.GA83528@citylink.fud.org.nz> References: <1237804575.1771.7.camel@balrog.2hip.net> <1237884572.1771.28.camel@balrog.2hip.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1237884572.1771.28.camel@balrog.2hip.net> User-Agent: Mutt/1.5.17 (2007-11-01) Cc: freebsd-current@freebsd.org, Nenhum_de_Nos Subject: Re: Booting from usb hard disk 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, 30 Mar 2009 06:10:43 -0000 On Tue, Mar 24, 2009 at 03:49:32AM -0500, Robert Noland wrote: > On Mon, 2009-03-23 at 19:40 -0300, Nenhum_de_Nos wrote: > > On Mon, March 23, 2009 07:36, Robert Noland wrote: > > > So I have my i386 install on a usb hard disk, which I can only boot on > > > one machine now. The one machine that I can make work has a bios option > > > that reads "BIOS ehci handoff". This used to work with the old usb > > > stack. The machines that it doesn't work on, boot the kernel, but fail > > > to mount root, giving me the forbidding mountroot> prompt, which is > > > immediately followed by the message saying that da0 is attached. da0 is > > > however not listed in the available boot devices list. I tried playing > > > around with the timeout in vfs_mount.c, but that didn't seem to have any > > > impact. It has been suggested that this may be a "geom" timeout, but I > > > don't know anything about the boot system really. > > > > I had problem a while ago with via mini itx hardware, that was quite > > close. If I try boot from usb (installed in usb hdd), I get to the point > > of loader not finding my disk. > > > > I then used a small flash disk attached to the ata (44 pin ide) channel > > and formatted /boot in there. this way I get to the point of mount root > > you said, and da0 not being alive soon enough to mount root. list disks > > also couldn't find da0 though. > > > > I tried current from that time, and no good. > > > > if this is solved, I'll be happy to try whatever patch to current. (as > > long as I can install it from another box/or its ata channel, as it can't > > boot vanilla 7.1R) > > So, my solution was to set kern.cam.scsi_delay=10000 > in /boot/loader.conf The following patch should work. It creates interleaving root hold tokens from the CAM probe to disk_create and geom providor tasting. I had to add a malloc type flag as sleeping isnt allowed at the point I added the token alloc in CAM. http://people.freebsd.org/~thompsa/root_wait.diff It needs review by the various geom/cam ppls. Andrew From owner-freebsd-current@FreeBSD.ORG Mon Mar 30 07:32: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 3E9F210656BA; Mon, 30 Mar 2009 07:32:45 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) by mx1.freebsd.org (Postfix) with ESMTP id F413B8FC21; Mon, 30 Mar 2009 07:32:44 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (critter.freebsd.dk [192.168.61.3]) by phk.freebsd.dk (Postfix) with ESMTP id 9A32A78CCD; Mon, 30 Mar 2009 07:32:43 +0000 (UTC) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.14.3/8.14.3) with ESMTP id n2U7WgPO009970; Mon, 30 Mar 2009 07:32:43 GMT (envelope-from phk@critter.freebsd.dk) To: Peter Jeremy From: "Poul-Henning Kamp" In-Reply-To: Your message of "Mon, 30 Mar 2009 05:07:45 +1100." <20090329180745.GB38985@server.vk2pj.dyndns.org> Date: Mon, 30 Mar 2009 07:32:42 +0000 Message-ID: <9969.1238398362@critter.freebsd.dk> Sender: phk@critter.freebsd.dk Cc: Alexander Sack , FreeBSD Hackers , freebsd-current@freebsd.org, prashant.vaibhav@gmail.com Subject: Re: Improving the kernel/i386 timecounter performance (GSoC proposal) 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, 30 Mar 2009 07:32:47 -0000 In message <20090329180745.GB38985@server.vk2pj.dyndns.org>, Peter Jeremy write s: >>I'm assuming folks are still in love with the TSC because it still the >>cheapest as oppose ACPI-fast or HPET to even contemplate this? > >That is its major advantage. It might be feasible to export all the >data necessary to implement the complete CLOCK_*_FAST family. The general attraction is that it can be read from userland by unpriviledged programs. On systems where the ACPI or HPET hardware can be memory-mapped, I should be equally possible to map those read-only into userland processes. Now _THAT_ would be interesting. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From owner-freebsd-current@FreeBSD.ORG Mon Mar 30 07:45: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 2B8361065670 for ; Mon, 30 Mar 2009 07:45:07 +0000 (UTC) (envelope-from Matthias.Apitz@oclc.org) Received: from mail.pica.nl (mail.pica.nl [192.87.44.30]) by mx1.freebsd.org (Postfix) with ESMTP id AE7918FC13 for ; Mon, 30 Mar 2009 07:45:06 +0000 (UTC) (envelope-from Matthias.Apitz@oclc.org) Received: from rebelion.Sisis.de ([10.0.1.29]) by mail.pica.nl with Microsoft SMTPSVC(6.0.3790.3959); Mon, 30 Mar 2009 09:45:04 +0200 Received: (from guru@localhost) by rebelion.Sisis.de (8.14.2/8.13.8/Submit) id n2U7j2eT004296 for freebsd-current@freebsd.org; Mon, 30 Mar 2009 09:45:02 +0200 (CEST) (envelope-from matthias.apitz@oclc.org) X-Authentication-Warning: rebelion.Sisis.de: guru set sender to matthias.apitz@oclc.org using -f Date: Mon, 30 Mar 2009 09:45:02 +0200 From: Matthias Apitz To: freebsd-current@freebsd.org Message-ID: <20090330074502.GA4247@rebelion.Sisis.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable User-Agent: Mutt/1.4.2.3i X-Operating-System: FreeBSD 7.0-STABLE (i386) X-OriginalArrivalTime: 30 Mar 2009 07:45:05.0062 (UTC) FILETIME=[70B7CC60:01C9B10B] Subject: make installworld DESTDIR=/mnt fails 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: Mon, 30 Mar 2009 07:45:07 -0000 Hello, I have created a boot-able USB key with -CURRENT from CVS following this recipe: # mkdir -p /usr/src/myHEAD/obj # cd /usr/src/myHEAD # cvs checkout src # setenv MAKEOBJDIRPREFIX /usr/src/myHEAD/obj # cd /usr/src/myHEAD/src # make buildworld # make buildkernel KERNCONF=3DGENERIC (/dev/da0 is an empty USB key) # fdisk -I da0 # fdisk -B da0 # bsdlabel -w da0s1 auto # bsdlabel -B da0s1 # newfs /dev/da0s1a # mount /dev/da0s1a /mnt # make installworld DESTDIR=3D/mnt # make installkernel DESTDIR=3D/mnt KERNCONF=3DGENERIC INSTALL_NODEBUG=3Dt # make distrib-dirs DESTDIR=3D/mnt # make distribution DESTDIR=3D/mnt # echo /dev/da0s1a / ufs rw 1 1 > /mnt/etc/fstab # echo ifconfig_DEFAULT=3DDHCP > /mnt/etc/rc.conf # echo hostname=3Ddemo >> /mnt/etc/rc.conf the resulting USB key boots and works fine; I've enriched this USB key with the actual source tree and the compiled objects: # cd /usr/src/ # tar -cf - myHEAD | ( cd /mnt ; tar -xpf - ) now I wanted to install based on this booted CURRENT another PC, its empty disk is mounted below /mnt; the installation fails as shown below; what is the reason for this? and; if my procedure is wrong, what would be the best way to install CURRENT into a small EeePC having only SSD and being to slow for compiling full kernel and world? Thx matthias # setenv MAKEOBJDIRPREFIX /myHEAD/obj # cd /myHEAD/src # make installworld DESTDIR=3D/mnt mkdir -p /tmp/install.Hwzry4NV progs=3D$(for prog in [ awk cap_mkdb cat chflags chmod chown date echo egr= ep find grep install-info ln lockf make mkdir mtree mv pwd_mkdb rm sed sh = sysctl test true uname wc zic; do if progpath=3D`which $prog`; then echo= $progpath; else echo "Required tool $prog not found in PATH." >&2; exit= 1; fi; done); libs=3D$(ldd -f "%o %p\n" -f "%o %p\n" $progs 2>/dev/null= | sort -u | while read line; do set -- $line; if [ "$2 $3" !=3D "not fo= und" ]; then echo $2; else echo "Required library $1 not found." >&2; e= xit 1; fi; done); cp $libs $progs /tmp/install.Hwzry4NV cp -R ${PATH_LOCALE:-"/usr/share/locale"} /tmp/install.Hwzry4NV/locale cd /myHEAD/src; MAKEOBJDIRPREFIX=3D/usr/obj MACHINE_ARCH=3Di386 MACHINE= =3Di386 CPUTYPE=3D GROFF_BIN_PATH=3D/usr/obj/myHEAD/src/tmp/legacy/usr/bi= n GROFF_FONT_PATH=3D/usr/obj/myHEAD/src/tmp/legacy/usr/share/groff_font G= ROFF_TMAC_PATH=3D/usr/obj/myHEAD/src/tmp/legacy/usr/share/tmac PATH=3D/usr/= obj/myHEAD/src/tmp/legacy/usr/sbin:/usr/obj/myHEAD/src/tmp/legacy/usr/bin:/= usr/obj/myHEAD/src/tmp/legacy/usr/games:/usr/obj/myHEAD/src/tmp/usr/sbin:/u= sr/obj/myHEAD/src/tmp/usr/bin:/usr/obj/myHEAD/src/tmp/usr/games:/tmp/instal= l.Hwzry4NV LD_LIBRARY_PATH=3D/tmp/install.Hwzry4NV PATH_LOCALE=3D/tmp/ins= tall.Hwzry4NV/locale make -f Makefile.inc1 __MAKE_SHELL=3D/tmp/install.Hwzr= y4NV/sh reinstall; MAKEOBJDIRPREFIX=3D/usr/obj MACHINE_ARCH=3Di386 MACHI= NE=3Di386 CPUTYPE=3D GROFF_BIN_PATH=3D/usr/obj/myHEAD/src/tmp/legacy/usr/= bin GROFF_FONT_PATH=3D/usr/obj/myHEAD/src/tmp/legacy/usr/share/groff_font = GROFF_TMAC_PATH=3D/usr/obj/myHEAD/src/tmp/legacy/usr/share/tmac PATH=3D/us= r/obj/myHEAD/src/tmp/legacy/usr/sbin:/usr/obj/myHEAD/src/tmp/legacy/usr/bin= :/usr/obj/myHEAD/src/tmp/legacy/usr/games:/usr/obj/myHEAD/src/tmp/usr/sbin:= /usr/obj/myHEAD/src/tmp/usr/bin:/usr/obj/myHEAD/src/tmp/usr/games:/tmp/inst= all.Hwzry4NV LD_LIBRARY_PATH=3D/tmp/install.Hwzry4NV PATH_LOCALE=3D/tmp/i= nstall.Hwzry4NV/locale rm -rf /tmp/install.Hwzry4NV -------------------------------------------------------------- >>> Making hierarchy -------------------------------------------------------------- cd /myHEAD/src; make -f Makefile.inc1 hierarchy cd /myHEAD/src/etc; make distrib-dirs mtree -eU -f /myHEAD/src/etc/mtree/BSD.root.dist -p /mnt/ mtree -eU -f /myHEAD/src/etc/mtree/BSD.var.dist -p /mnt/var mtree -eU -f /myHEAD/src/etc/mtree/BSD.usr.dist -p /mnt/usr mtree -eU -f /myHEAD/src/etc/mtree/BSD.include.dist -p /mnt/usr/include mtree -deU -f /myHEAD/src/etc/mtree/BIND.chroot.dist -p /mnt/var/named mtree -deU -f /myHEAD/src/etc/mtree/BSD.sendmail.dist -p /mnt/ cd /mnt/; rm -f /mnt/sys; ln -s usr/src/sys sys cd /mnt/usr/share/man/en.ISO8859-1; ln -sf ../man* . cd /mnt/usr/share/man/en.UTF-8; ln -sf ../man* . cd /mnt/usr/share/man; set - `grep "^[a-zA-Z]" /myHEAD/src/etc/man.alias`;= while [ $# -gt 0 ] ; do rm -rf "$1"; ln -s "$2" "$1"; shift; shift; = done cd /mnt/usr/share/openssl/man; set - `grep "^[a-zA-Z]" /myHEAD/src/etc/man= .alias`; while [ $# -gt 0 ] ; do rm -rf "$1"; ln -s "$2" "$1"; shift; = shift; done cd /mnt/usr/share/openssl/man/en.ISO8859-1; ln -sf ../man* . cd /mnt/usr/share/nls; set - `grep "^[a-zA-Z]" /myHEAD/src/etc/nls.alias`;= while [ $# -gt 0 ] ; do rm -rf "$1"; ln -s "$2" "$1"; shift; shift; = done -------------------------------------------------------------- >>> Installing everything -------------------------------------------------------------- cd /myHEAD/src; make -f Makefile.inc1 install =3D=3D=3D> share/info (install) install -o root -g wheel -m 444 dir-tmpl /mnt/usr/share/info/dir install:No such file or directory *** Error code 1 there is no /mnt/usr/share/info/dir: # ls -l /mnt/usr/share/info total 0 I have created it: # mkdir /mnt/usr/share/info/dir but now compilation fails # make installworld DESTDIR=3D/mnt mkdir -p /tmp/install.TXKoAHr9 progs=3D$(for prog in [ awk cap_mkdb cat chflags chmod chown date echo egr= ep find grep install-info ln lockf make mkdir mtree mv pwd_mkdb rm sed sh = sysctl test true uname wc zic; do if progpath=3D`which $prog`; then echo= $progpath; else echo "Required tool $prog not found in PATH." >&2; exit= 1; fi; done); libs=3D$(ldd -f "%o %p\n" -f "%o %p\n" $progs 2>/dev/null= | sort -u | while read line; do set -- $line; if [ "$2 $3" !=3D "not fo= und" ]; then echo $2; else echo "Required library $1 not found." >&2; e= xit 1; fi; done); cp $libs $progs /tmp/install.TXKoAHr9 cp -R ${PATH_LOCALE:-"/usr/share/locale"} /tmp/install.TXKoAHr9/locale cp -R ${PATH_LOCALE:-"/usr/share/locale"} /tmp/install.TXKoAHr9/locale cd /myHEAD/src; MAKEOBJDIRPREFIX=3D/usr/obj MACHINE_ARCH=3Di386 MACHINE= =3Di386 CPUTYPE=3D GROFF_BIN_PATH=3D/usr/obj/myHEAD/src/tmp/legacy/usr/bi= n GROFF_FONT_PATH=3D/usr/obj/myHEAD/src/tmp/legacy/usr/share/groff_font G= ROFF_TMAC_PATH=3D/usr/obj/myHEAD/src/tmp/legacy/usr/share/tmac PATH=3D/usr/= obj/myHEAD/src/tmp/legacy/usr/sbin:/usr/obj/myHEAD/src/tmp/legacy/usr/bin:/= usr/obj/myHEAD/src/tmp/legacy/usr/games:/usr/obj/myHEAD/src/tmp/usr/sbin:/u= sr/obj/myHEAD/src/tmp/usr/bin:/usr/obj/myHEAD/src/tmp/usr/games:/tmp/instal= l.TXKoAHr9 LD_LIBRARY_PATH=3D/tmp/install.TXKoAHr9 PATH_LOCALE=3D/tmp/ins= tall.TXKoAHr9/locale make -f Makefile.inc1 __MAKE_SHELL=3D/tmp/install.TXKo= AHr9/sh reinstall; MAKEOBJDIRPREFIX=3D/usr/obj MACHINE_ARCH=3Di386 MACHI= NE=3Di386 CPUTYPE=3D GROFF_BIN_PATH=3D/usr/obj/myHEAD/src/tmp/legacy/usr/= bin GROFF_FONT_PATH=3D/usr/obj/myHEAD/src/tmp/legacy/usr/share/groff_font = GROFF_TMAC_PATH=3D/usr/obj/myHEAD/src/tmp/legacy/usr/share/tmac PATH=3D/us= r/obj/myHEAD/src/tmp/legacy/usr/sbin:/usr/obj/myHEAD/src/tmp/legacy/usr/bin= :/usr/obj/myHEAD/src/tmp/legacy/usr/games:/usr/obj/myHEAD/src/tmp/usr/sbin:= /usr/obj/myHEAD/src/tmp/usr/bin:/usr/obj/myHEAD/src/tmp/usr/games:/tmp/inst= all.TXKoAHr9 LD_LIBRARY_PATH=3D/tmp/install.TXKoAHr9 PATH_LOCALE=3D/tmp/i= nstall.TXKoAHr9/locale rm -rf /tmp/install.TXKoAHr9 -------------------------------------------------------------- >>> Making hierarchy -------------------------------------------------------------- cd /myHEAD/src; make -f Makefile.inc1 hierarchy cd /myHEAD/src/etc; make distrib-dirs mtree -eU -f /myHEAD/src/etc/mtree/BSD.root.dist -p /mnt/ mtree -eU -f /myHEAD/src/etc/mtree/BSD.var.dist -p /mnt/var mtree -eU -f /myHEAD/src/etc/mtree/BSD.usr.dist -p /mnt/usr mtree -eU -f /myHEAD/src/etc/mtree/BSD.include.dist -p /mnt/usr/include mtree -deU -f /myHEAD/src/etc/mtree/BIND.chroot.dist -p /mnt/var/named mtree -deU -f /myHEAD/src/etc/mtree/BSD.sendmail.dist -p /mnt/ cd /mnt/; rm -f /mnt/sys; ln -s usr/src/sys sys cd /mnt/usr/share/man/en.ISO8859-1; ln -sf ../man* . cd /mnt/usr/share/man/en.UTF-8; ln -sf ../man* . cd /mnt/usr/share/man; set - `grep "^[a-zA-Z]" /myHEAD/src/etc/man.alias`;= while [ $# -gt 0 ] ; do rm -rf "$1"; ln -s "$2" "$1"; shift; shift; = done cd /mnt/usr/share/openssl/man; set - `grep "^[a-zA-Z]" /myHEAD/src/etc/man= .alias`; while [ $# -gt 0 ] ; do rm -rf "$1"; ln -s "$2" "$1"; shift; = shift; done cd /mnt/usr/share/openssl/man/en.ISO8859-1; ln -sf ../man* . cd /mnt/usr/share/nls; set - `grep "^[a-zA-Z]" /myHEAD/src/etc/nls.alias`;= while [ $# -gt 0 ] ; do rm -rf "$1"; ln -s "$2" "$1"; shift; shift; = done -------------------------------------------------------------- >>> Installing everything -------------------------------------------------------------- cd /myHEAD/src; make -f Makefile.inc1 install =3D=3D=3D> share/info (install) =3D=3D=3D> lib (install) =3D=3D=3D> lib/csu/i386-elf (install) cc -O2 -pipe -I/myHEAD/src/lib/csu/i386-elf/../common -I/myHEAD/src/lib/c= su/i386-elf/../../libc/include -std=3Dgnu99 -Wsystem-headers -Werror -Wall= -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-pro= totypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch = -Wshadow -Wcast-align -Wunused-parameter -Wchar-subscripts -Winline -Wneste= d-externs -Wredundant-decls -Wno-pointer-sign -c crt1.c cc: not found *** Error code 127 the 'cc' is there: # cc cc: No input files specified --=20 Matthias Apitz Manager Technical Support - OCLC GmbH Gruenwalder Weg 28g - 82041 Oberhaching - Germany t +49-89-61308 351 - f +49-89-61308 399 - m +49-170-4527211 e - w http://www.oclc.org/ http://www.UnixArea.de/ From owner-freebsd-current@FreeBSD.ORG Mon Mar 30 08:50: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 60C2F106564A for ; Mon, 30 Mar 2009 08:50:21 +0000 (UTC) (envelope-from ccuiyyan@gmail.com) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.235]) by mx1.freebsd.org (Postfix) with ESMTP id 36A358FC1A for ; Mon, 30 Mar 2009 08:50:21 +0000 (UTC) (envelope-from ccuiyyan@gmail.com) Received: by rv-out-0506.google.com with SMTP id l9so2643041rvb.43 for ; Mon, 30 Mar 2009 01:50:20 -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=eG07/wYCaQOW2HaVAth03WPh0EM2jOn2+5Gn+7kWZQQ=; b=m6OyFdp913ma/WrQ3Dwx/3rMEbb4jVcb7v5230TUj2Q2yYtv8p+H2O3joTngM/71u+ 00kujoznLTCRxBGvENPeNPACiqSdovq2FeGTbAxEdtotJsSfimMAhj3vQHY1xXzEyRmH UGinUxbj88D7cvfX1M+MpTpjgPoH4JfT4aZ5c= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=bQzLsI62KNpzaEOhMUFEqkbFu0GIluY3sl/ZOp5VMN+ZFarBvp2LSvo/9latyO6NZm WX37j+6E7bo1sjPMR5D8cI5JvwVO9qGwmO+U84ws9+RNHJrAmXxNKYI5guQqDXIBFD4M /GuJf7Q5m+kmp2LTm4N7MiTpJu9a1luNCQ5C0= MIME-Version: 1.0 Received: by 10.114.124.1 with SMTP id w1mr3411022wac.135.1238401428803; Mon, 30 Mar 2009 01:23:48 -0700 (PDT) Date: Mon, 30 Mar 2009 16:23:48 +0800 Message-ID: <4451ccf20903300123p4df9c1d7k4c4138ad25d2d4af@mail.gmail.com> From: =?GB2312?B?tN7R0mNjdWl5eWFuQHNpbmEuY29t?= To: freebsd-current@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: loader prompt doesn't work 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, 30 Mar 2009 08:50:21 -0000 Dear all: A quick question for loader prompt in FreeBSD OS. Recently i do some benchmarking in the FreeBSD OS, and today i decide to enable some performance tools in the kernel which can be realized by building a new kernel. Before that, i refer to the FreeBSD handbook for howto. It says that if i fail to load the new kernel, we can select the "escape to a loader prompt" option. By loading the correct kernel, we can reboot the system. However, problem happens. When i select the "escape to a loader prompt" option, i can input in about just 3 sec. After that, the system cannot go on whatever key i hit. The whole system have 4 hard disks; and i install 3 OSes in the first 3 hard disks which are Linux, Solaris and FreeBSD in order. All systems are booted using grub. Any ideas? Best Wishes! Yan From owner-freebsd-current@FreeBSD.ORG Mon Mar 30 09:10:54 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 D8E1F1065717 for ; Mon, 30 Mar 2009 09:10:54 +0000 (UTC) (envelope-from astrodog@gmail.com) Received: from mail-gx0-f176.google.com (mail-gx0-f176.google.com [209.85.217.176]) by mx1.freebsd.org (Postfix) with ESMTP id 934898FC1B for ; Mon, 30 Mar 2009 09:10:54 +0000 (UTC) (envelope-from astrodog@gmail.com) Received: by gxk24 with SMTP id 24so5502903gxk.19 for ; Mon, 30 Mar 2009 02:10:53 -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 :content-transfer-encoding; bh=SjTK93UBp+dAjW6zW/Q8g7xX700ft+sVNA6Jpezp+l8=; b=hBn86y+iSrrNsD1vYkIzzfIWsM6SvluMpng2vhg/uizLcwWNXDOLijvwN+8/wkLU2Y SjzUGfXKt+ABFR0LBbGVMuf8t9kP36YjAvBZFKC15YGzvHieYCMwMKbUUnY1xhfyP+5o kgyT6L8EjN2a+cb+SajPAOzy4TfuxNNOn9zBg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; b=W+m3SxUNu8rSbHSkwhRB5SUcwk4xOCpDdyGexiUQDz037Sn7SpyMWk+G2xHyRPSZxv ENM/nc5mTcOMVJOEE17c4tKylzO0reAlw0xXVIqJ2VLA7Ix3ySREy4KEAbYhRVHJulrQ 6kVyN9akxDpL0KBJ+TrA1UJPnCYU5s5U8PFRo= MIME-Version: 1.0 Received: by 10.150.156.9 with SMTP id d9mr10143058ybe.182.1238404253804; Mon, 30 Mar 2009 02:10:53 -0700 (PDT) In-Reply-To: <2fd864e0903300207w33ee40f8k6fb96ffd9ac8bf01@mail.gmail.com> References: <4451ccf20903300123p4df9c1d7k4c4138ad25d2d4af@mail.gmail.com> <2fd864e0903300207w33ee40f8k6fb96ffd9ac8bf01@mail.gmail.com> Date: Mon, 30 Mar 2009 04:10:53 -0500 Message-ID: <2fd864e0903300210i740ab4aaqf7c4df27550d677c@mail.gmail.com> From: Astrodog To: freebsd-current@freebsd.org Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit Subject: loader prompt doesn't work 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, 30 Mar 2009 09:10:55 -0000 ---------- Forwarded message ---------- From: Astrodog Date: 2009/3/30 Subject: Re: loader prompt doesn't work To: "$BVC4d(Bccuiyyan@sina.com" 2009/3/30 $BVC4d(Bccuiyyan@sina.com : > Dear all: > > A quick question for loader prompt in FreeBSD OS. > > Recently i do some benchmarking in the FreeBSD OS, and today i decide > to enable some > > performance tools in the kernel which can be realized by building a new > kernel. > > Before that, i refer to the FreeBSD handbook for howto. > > It says that if i fail to load the new kernel, we can select the > "escape to a loader prompt" option. > > By loading the correct kernel, we can reboot the system. > > However, problem happens. When i select the "escape to a loader prompt" > option, i can input > > in about just 3 sec. After that, the system cannot go on whatever key i > hit. > > The whole system have 4 hard disks; and i install 3 OSes in the first 3 > hard disks which are > > Linux, Solaris and FreeBSD in order. All systems are booted using grub. > > > Any ideas? > > > > Best Wishes! > > Yan > _______________________________________________ > 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" > Are you using a USB keyboard, by chance? --- Harrison -- "A human being should be able to change a diaper, plan an invasion, butcher a hog, conn a ship, design a building, write a sonnet, balance accounts, build a wall, set a bone, comfort the dying, take orders, give orders, cooperate, act alone, solve equations, analyze a new problem, pitch manure, program a computer, cook a tasty meal, fight efficiently, die gallantly. Specialization is for insects." --- Robert A. Heinlein From owner-freebsd-current@FreeBSD.ORG Mon Mar 30 09:34: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 DF86B106564A for ; Mon, 30 Mar 2009 09:34:49 +0000 (UTC) (envelope-from sepherosa@gmail.com) Received: from yw-out-2324.google.com (yw-out-2324.google.com [74.125.46.29]) by mx1.freebsd.org (Postfix) with ESMTP id 7EE5D8FC15 for ; Mon, 30 Mar 2009 09:34:49 +0000 (UTC) (envelope-from sepherosa@gmail.com) Received: by yw-out-2324.google.com with SMTP id 5so1310440ywh.13 for ; Mon, 30 Mar 2009 02:34:48 -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=K7AzHb7AkmmfIMbyppTqaxf/PAqV37ZwG+SfgFVgAs8=; b=FC+iEh5qT1lB+NGv7WTGCqVdewLJh/g2z2qesPOYGroQDkM93DUyyXZoefTGdEfpIM FqSU8n63vZtXYUYGnshUYW9cXibv0yiozp+LBHJUcZ3+Er1JVRE2gxvYhY1YJ0+gh3qG ES6jSH+7IogxNYJv5/JBPGlrCs5njs2n26E7A= 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=bdG9kzNOWHTuNOIjrH6pj6ys+5jdAw+OGjdQkwXwhBc1yPPrT+nI5xpbIau203eS4W hxVIHquiQEAnMGhyuPttWIGf0O+KEJPZydlflnf4k/gpyQJ5NutY2A0bwsX0Ex5dO2Q0 nJ+QDbqcLKjjCYgqeoOfxEPoz6jkunF9zH9dU= MIME-Version: 1.0 Received: by 10.150.178.9 with SMTP id a9mr9842185ybf.60.1238405688783; Mon, 30 Mar 2009 02:34:48 -0700 (PDT) In-Reply-To: <20090330024748.GF7076@michelle.cdnetworks.co.kr> References: <75656435-49E2-457A-9CFE-8706CD44916E@gmail.com> <20090328080924.GD99923@michelle.cdnetworks.co.kr> <2e77fc10903280259s5a761cacs398b88649a2367fe@mail.gmail.com> <20090328102735.GE99923@michelle.cdnetworks.co.kr> <2e77fc10903280942u7c934aa4w80176680e9dff6d7@mail.gmail.com> <2e77fc10903281539h7b713711w116a90fd2bfadbcf@mail.gmail.com> <20090330021648.GE7076@michelle.cdnetworks.co.kr> <20090330024748.GF7076@michelle.cdnetworks.co.kr> Date: Mon, 30 Mar 2009 17:34:48 +0800 Message-ID: From: Sepherosa Ziehau To: pyunyh@gmail.com Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Niki Denev , freebsd-current@freebsd.org, delphij@freebsd.org Subject: Re: axe(4) (Belkin F5D5055) problems 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, 30 Mar 2009 09:34:50 -0000 On Mon, Mar 30, 2009 at 10:47 AM, Pyun YongHyeon wrote: > On Mon, Mar 30, 2009 at 11:16:48AM +0900, Pyun YongHyeon wrote: >> On Sun, Mar 29, 2009 at 12:39:22AM +0200, Niki Denev wrote: >> > On Sat, Mar 28, 2009 at 6:42 PM, Niki Denev wrote: >> > > On Sat, Mar 28, 2009 at 12:27 PM, Pyun YongHyeon wrote: >> > >> On Sat, Mar 28, 2009 at 11:59:13AM +0200, Niki Denev wrote: >> > >>> 2009/3/28 Pyun YongHyeon : >> > >>> > On Fri, Mar 27, 2009 at 09:14:06PM +0200, Nikolay Denev wrote: >> > >>> >> -----BEGIN PGP SIGNED MESSAGE----- >> > >>> >> Hash: SHA1 >> > >>> >> >> > >>> >> Hello, >> > >>> >> >> > >>> >> I'm running -current from 23.03.09 and I'm experiencing some axe(4) >> > >>> >> problems. >> > >>> >> Basically the network connection works but when some more serious >> > >>> >> traffic hits the >> > >>> >> interface (i.e. torrent download) it then dies, ifconfig down/up >> > >>> >> does not help, only replugging of the adapter. >> > >>> >> >> > >>> >> I've tried running with hw.usb2.axe.debug=15 and the output was many >> > >>> >> lines of: >> > >>> >> >> > >>> >> ? ?axe_bulk_write_callback:853: transfer complete >> > >>> >> >> > >>> >> then a pause of several seconds and the kernel begins to print : >> > >>> >> >> > >>> >> ? ?axe_bulk_write_callback:925: transfer error, USB_ERR_TIMEOUT >> > >>> >> >> > >>> >> Another strange thing that I noticed is that, while the interface >> > >>> >> seems to be >> > >>> >> connected and working, if I type many times ifconfig ue0 consecutively >> > >>> >> most of the time it would show different settings for the auto >> > >>> >> negotiated link. >> > >>> >> I.e. it would cycle between 100baseTX-FDX, 1000baseT-FDX, no carrier, >> > >>> >> 100BaseT-FDX hw-loopback and 1000BaseT-FDX hw-loopback. >> > >>> >> >> > >>> >> The switch does not seem to register link flaps. >> > >>> >> >> > >>> > >> > >>> > axe(4) requires exact link state/speed information from mii(4) to >> > >>> > reprogram controller to resolved speed/duplex. In this case >> > >>> > ukphy(4) seems to report fake link state/speed to axe(4). >> > >>> > >> > >>> >> The kernel messages for the interface are : >> > >>> >> >> > >>> >> ? ?ugen2.5: at usbus2 >> > >>> >> ? ?axe0: on usbus2 >> > >>> >> ? ?axe0: PHYADDR 0xe0:0x01 >> > >>> >> ? ?miibus0: on axe0 >> > >>> >> ? ?ukphy0: PHY 1 on miibus0 >> > >>> >> ? ?ukphy0: ?10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, >> > >>> >> 1000baseT, 1000baseT-FDX, auto >> > >>> >> ? ?ue0: on axe0 >> > >>> >> ? ?ue0: Ethernet address: 00:11:50:xx:xx:xx >> > >>> >> >> > >>> >> devinfo -vr | grep phy >> > >>> >> ukphy0 pnpinfo oui=0xa0bc model=0x1 rev=0x2 at phyno=1 >> > >>> >> >> > >>> > >> > >>> > This looks like Agere systems ET110C TruePHY. Would you try >> > >>> > attached patch? Because truephy(4) pokes some undocumented PHY >> > >>> > registers on PHY reset I'm not sure this model also requires that >> > >>> > magic to make it work though. >> > >>> > >> > >>> >> > >>> Hi Pyun, >> > >>> >> > >>> Thanks for the patch. >> > >>> >> > >>> With it the PHY is now detected as truephy. >> > >>> The only thing that i notice is that if the media status changes displayed with >> > >>> ifconfig are less frequent, and I mostly see 1000baseT-FDX and 100baseT-HDX >> > >>> The packet loss is still there, and the interface again stops to work >> > >>> after some time. >> > >>> >> > >> >> > >> Ok, revert previous patch and try attached one. This one does not >> > >> try to load ET1011C dsp codes. If this does not work next thing >> > >> would be try to load dsp code for ET1011C revision 1 model. >> > >> Not sure where I can find required dsp code. >> > >> >> > > >> > > There don't seem to be any improvement with the new patch. >> > > The packetloss and media status changes are still here. >> > > Maybe check Linux/Solaris/OtherBSD driver? >> > > >> > > -- >> > > Niki >> > > >> > >> > LSI seem to have several documents about this phy chip, including >> > datasheet (which you probably have) and errata : >> > http://www.lsi.com/DistributionSystem/AssetDocument/documentation/networking/ethernet/et1011c/DS06-161GPHY_ET1011C_09-28-2007.pdf >> > http://www.lsi.com/DistributionSystem/AssetDocument/documentation/networking/ethernet/et1011c/ET1011C_Errata_08June2007.pdf >> > >> >> Yes, but unfortunately it is for model 3 or model 4. Yours is model >> 1. In fact I have no idea whether model 1 is ET1011C. It seems that > > I was wrong. The datasheet is for model 1, but revision number is > 4. > >> there are ET1011A or ET1011B PHYs. >> >> Sepherosa, do you have more information on ET1011A/ET1011B PHY? Nope, LSI site only has et1011c data sheet. However, the model in the data sheet mismatches the PHY model on my available hardware. > It looks odd to me, by chance is model 4 typo? Does et(4) really Nah, its not typo, at least the hardwares I have (one OEM and one EVB) uses model 4. > recognize the PHY as truephy(4)? Also CCed to Xin Li who ported the > et(4) to FreeBSD. -- Live Free or Die From owner-freebsd-current@FreeBSD.ORG Mon Mar 30 09:56:54 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 87F511065675 for ; Mon, 30 Mar 2009 09:56:54 +0000 (UTC) (envelope-from mel.flynn+fbsd.current@mailing.thruhere.net) Received: from mailhub.rachie.is-a-geek.net (rachie.is-a-geek.net [66.230.99.27]) by mx1.freebsd.org (Postfix) with ESMTP id 3D0598FC20 for ; Mon, 30 Mar 2009 09:56:54 +0000 (UTC) (envelope-from mel.flynn+fbsd.current@mailing.thruhere.net) Received: from sarevok.dnr.servegame.org (gate.lan.rachie.is-a-geek.net [192.168.2.10]) by mailhub.rachie.is-a-geek.net (Postfix) with ESMTP id 588157E818; Mon, 30 Mar 2009 01:56:52 -0800 (AKDT) From: Mel Flynn To: freebsd-current@freebsd.org Date: Mon, 30 Mar 2009 11:55:25 +0200 User-Agent: KMail/1.11.0 (FreeBSD/8.0-CURRENT; KDE/4.2.0; i386; ; ) References: <20090330074502.GA4247@rebelion.Sisis.de> In-Reply-To: <20090330074502.GA4247@rebelion.Sisis.de> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200903301155.25530.mel.flynn+fbsd.current@mailing.thruhere.net> Cc: Matthias Apitz Subject: Re: make installworld DESTDIR=/mnt fails 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, 30 Mar 2009 09:56:56 -0000 On Monday 30 March 2009 09:45:02 Matthias Apitz wrote: > Hello, > > I have created a boot-able USB key with -CURRENT from CVS following > this recipe: > > # mkdir -p /usr/src/myHEAD/obj > # cd /usr/src/myHEAD > # cvs checkout src > # setenv MAKEOBJDIRPREFIX /usr/src/myHEAD/obj > # setenv MAKEOBJDIRPREFIX /myHEAD/obj There's your problem. Your .OBJDIR does not contain output of buildworld. -- Mel From owner-freebsd-current@FreeBSD.ORG Mon Mar 30 10:03: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 CA6691065672 for ; Mon, 30 Mar 2009 10:03:59 +0000 (UTC) (envelope-from Matthias.Apitz@oclc.org) Received: from mail.pica.nl (mail.pica.nl [192.87.44.30]) by mx1.freebsd.org (Postfix) with ESMTP id 66F718FC1A for ; Mon, 30 Mar 2009 10:03:58 +0000 (UTC) (envelope-from Matthias.Apitz@oclc.org) Received: from rebelion.Sisis.de ([10.0.1.29]) by mail.pica.nl with Microsoft SMTPSVC(6.0.3790.3959); Mon, 30 Mar 2009 12:03:57 +0200 Received: (from guru@localhost) by rebelion.Sisis.de (8.14.2/8.13.8/Submit) id n2UA3oKi008004; Mon, 30 Mar 2009 12:03:50 +0200 (CEST) (envelope-from matthias.apitz@oclc.org) X-Authentication-Warning: rebelion.Sisis.de: guru set sender to matthias.apitz@oclc.org using -f Date: Mon, 30 Mar 2009 12:03:45 +0200 From: Matthias Apitz To: Mel Flynn Message-ID: <20090330100345.GA7763@rebelion.Sisis.de> References: <20090330074502.GA4247@rebelion.Sisis.de> <200903301155.25530.mel.flynn+fbsd.current@mailing.thruhere.net> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <200903301155.25530.mel.flynn+fbsd.current@mailing.thruhere.net> User-Agent: Mutt/1.4.2.3i X-Operating-System: FreeBSD 7.0-STABLE (i386) X-OriginalArrivalTime: 30 Mar 2009 10:03:57.0997 (UTC) FILETIME=[D788C5D0:01C9B11E] Cc: freebsd-current@freebsd.org Subject: Re: make installworld DESTDIR=/mnt fails 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: Mon, 30 Mar 2009 10:04:00 -0000 El día Monday, March 30, 2009 a las 11:55:25AM +0200, Mel Flynn escribió: > On Monday 30 March 2009 09:45:02 Matthias Apitz wrote: > > Hello, > > > > I have created a boot-able USB key with -CURRENT from CVS following > > this recipe: > > > > # mkdir -p /usr/src/myHEAD/obj > > # cd /usr/src/myHEAD > > # cvs checkout src > > # setenv MAKEOBJDIRPREFIX /usr/src/myHEAD/obj > > > > # setenv MAKEOBJDIRPREFIX /myHEAD/obj > > There's your problem. Your .OBJDIR does not contain output of buildworld. Ofc it contains the output of the previous buildworld; I've copied it over with: # cd /usr/src/ # tar -cf - myHEAD | ( cd /mnt ; tar -xpf - ) before unmounting the key from the originator system; Why do you think it is not there? For example: # ls /myHEAD/obj/usr/src/myHEAD/src/usr.bin/make .depend for.o main.o proc.o util.o arch.o hash.o make shell.o var.o buf.o hash_tables.o make.1.gz str.o cond.o job.o make.o suff.o dir.o lst.o parse.o targ.o matthias -- Matthias Apitz Manager Technical Support - OCLC GmbH Gruenwalder Weg 28g - 82041 Oberhaching - Germany t +49-89-61308 351 - f +49-89-61308 399 - m +49-170-4527211 e - w http://www.oclc.org/ http://www.UnixArea.de/ From owner-freebsd-current@FreeBSD.ORG Mon Mar 30 11:11: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 D5A5C10657D6 for ; Mon, 30 Mar 2009 11:11:52 +0000 (UTC) (envelope-from alexander@leidinger.net) Received: from redbull.bpaserver.net (redbullneu.bpaserver.net [213.198.78.217]) by mx1.freebsd.org (Postfix) with ESMTP id 777CB8FC0C for ; Mon, 30 Mar 2009 11:11:52 +0000 (UTC) (envelope-from alexander@leidinger.net) Received: from outgoing.leidinger.net (pD9E2E42A.dip.t-dialin.net [217.226.228.42]) by redbull.bpaserver.net (Postfix) with ESMTP id 7DF7F2E0BC; Mon, 30 Mar 2009 13:11:48 +0200 (CEST) Received: from webmail.leidinger.net (webmail.leidinger.net [192.168.1.102]) by outgoing.leidinger.net (Postfix) with ESMTP id 041EFB159D; Mon, 30 Mar 2009 13:11:44 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=Leidinger.net; s=outgoing-alex; t=1238411505; bh=AEXuMqodg0YqEeDDgxT1FccOFg5U92fcT c4Fz2J+j2Y=; h=Message-ID:Date:From:To:Cc:Subject:References: In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=KDGnyYNPhjDMBaGVoATCHQId4EmZ44gFCKfiygWxh7VTtMUk8ioofy+wwn9fbVdOY VG9+4XjyZXYjAZlq1KBlvjfma6WysTUlvOEsyL0ECE281DsXLfvmXjpWEBZJQjM7XDm VJwm1AOF15xrh6dBvb55PRu6dJvKVqAZFwO5hm1JrW00KWEBZQpSLoe/JTzzyt1uJo+ ZOzOvhpA6M9IFxndsA2xNnZ+/Wgg8E+peuzRPp7Es2WqMZLi2yBbyIlF2C4/sMz6rrL aYn2IMNgKBBTL8CHHV3LuHMfM/dUxdrU/yqGYxoeeEoPvsTNQ/UAvjxv4nKDl3hGNkJ 1qNVaWD5w== Received: (from www@localhost) by webmail.leidinger.net (8.14.3/8.13.8/Submit) id n2UBBiX5045733; Mon, 30 Mar 2009 13:11:44 +0200 (CEST) (envelope-from Alexander@Leidinger.net) Received: from pslux.cec.eu.int (pslux.cec.eu.int [158.169.9.14]) by webmail.leidinger.net (Horde Framework) with HTTP; Mon, 30 Mar 2009 13:11:43 +0200 Message-ID: <20090330131143.47127dgnexe52iw4@webmail.leidinger.net> X-Priority: 3 (Normal) Date: Mon, 30 Mar 2009 13:11:43 +0200 From: Alexander Leidinger To: Matthias Apitz References: <20090330074502.GA4247@rebelion.Sisis.de> In-Reply-To: <20090330074502.GA4247@rebelion.Sisis.de> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; DelSp="Yes"; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: quoted-printable User-Agent: Internet Messaging Program (IMP) H3 (4.3) / FreeBSD-8.0 X-BPAnet-MailScanner-Information: Please contact the ISP for more information X-MailScanner-ID: 7DF7F2E0BC.17049 X-BPAnet-MailScanner: Found to be clean X-BPAnet-MailScanner-SpamCheck: not spam, ORDB-RBL, SpamAssassin (not cached, score=-14.823, required 6, BAYES_00 -15.00, DKIM_SIGNED 0.00, DKIM_VERIFIED -0.00, RDNS_DYNAMIC 0.10, TW_XP 0.08) X-BPAnet-MailScanner-From: alexander@leidinger.net X-Spam-Status: No Cc: freebsd-current@freebsd.org Subject: Re: make installworld DESTDIR=/mnt fails 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, 30 Mar 2009 11:12:05 -0000 Quoting Matthias Apitz (from Mon, 30 Mar 2009 =20 09:45:02 +0200): > > > Hello, > > I have created a boot-able USB key with -CURRENT from CVS following > this recipe: > > # mkdir -p /usr/src/myHEAD/obj > # cd /usr/src/myHEAD > # cvs checkout src > # setenv MAKEOBJDIRPREFIX /usr/src/myHEAD/obj > # cd /usr/src/myHEAD/src > # make buildworld > I've enriched this USB key with the actual source tree and the compiled > objects: > > # cd /usr/src/ > # tar -cf - myHEAD | ( cd /mnt ; tar -xpf - ) > > now I wanted to install based on this booted CURRENT another > PC, its empty disk is mounted below /mnt; the installation fails > as shown below; > > what is the reason for this? > # setenv MAKEOBJDIRPREFIX /myHEAD/obj > # cd /myHEAD/src You need to mv /myHEAD /usr/src/myHEAD setenv MAKEOBJDIRPREFIX /usr/src/myHEAD/obj and it should work. The realpath of the src dir is used when creating the obj tree. If =20 you look at myHEAD/obj/, you will see that there's an usr/src/myHEAD. =20 Alternatively it should work to mv /myHEAD/obj/usr/src/myHEAD to =20 /myHEAD/obj/, but I types this part out of my head without looking at =20 a real obj tree, so there could be something missing. Bye, Alexander. --=20 Democracy is the recurrent suspicion that more than half of the people are right more than half of the time. =09=09-- E. B. White http://www.Leidinger.net Alexander @ Leidinger.net: PGP ID =3D B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID =3D 72077137 From owner-freebsd-current@FreeBSD.ORG Mon Mar 30 14:50: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 7CBE710656D6 for ; Mon, 30 Mar 2009 14:50:58 +0000 (UTC) (envelope-from Matthias.Apitz@oclc.org) Received: from mail.pica.nl (mail.pica.nl [192.87.44.30]) by mx1.freebsd.org (Postfix) with ESMTP id 17A118FC1F for ; Mon, 30 Mar 2009 14:50:57 +0000 (UTC) (envelope-from Matthias.Apitz@oclc.org) Received: from rebelion.Sisis.de ([10.0.1.29]) by mail.pica.nl with Microsoft SMTPSVC(6.0.3790.3959); Mon, 30 Mar 2009 16:50:55 +0200 Received: (from guru@localhost) by rebelion.Sisis.de (8.14.2/8.13.8/Submit) id n2UEosk7015922; Mon, 30 Mar 2009 16:50:54 +0200 (CEST) (envelope-from matthias.apitz@oclc.org) X-Authentication-Warning: rebelion.Sisis.de: guru set sender to matthias.apitz@oclc.org using -f Date: Mon, 30 Mar 2009 16:50:54 +0200 From: Matthias Apitz To: Alexander Leidinger Message-ID: <20090330145054.GA15677@rebelion.Sisis.de> References: <20090330074502.GA4247@rebelion.Sisis.de> <20090330131143.47127dgnexe52iw4@webmail.leidinger.net> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20090330131143.47127dgnexe52iw4@webmail.leidinger.net> User-Agent: Mutt/1.4.2.3i X-Operating-System: FreeBSD 7.0-STABLE (i386) X-OriginalArrivalTime: 30 Mar 2009 14:50:56.0247 (UTC) FILETIME=[EE693870:01C9B146] Cc: freebsd-current@freebsd.org Subject: Re: make installworld DESTDIR=/mnt fails 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: Mon, 30 Mar 2009 14:50:59 -0000 El día Monday, March 30, 2009 a las 01:11:43PM +0200, Alexander Leidinger escribió: > >I've enriched this USB key with the actual source tree and the compiled > >objects: > > > ># cd /usr/src/ > ># tar -cf - myHEAD | ( cd /mnt ; tar -xpf - ) > > ... > > You need to > mv /myHEAD /usr/src/myHEAD > setenv MAKEOBJDIRPREFIX /usr/src/myHEAD/obj > and it should work. > > The realpath of the src dir is used when creating the obj tree. If > you look at myHEAD/obj/, you will see that there's an usr/src/myHEAD. ... Thanks this really helped and the installation went forward; I did not know that the realpath of the src was used some hard during 'make install'; now I run into the next problem: ... ===> usr.bin/ncplist (install) install -s -o root -g wheel -m 555 ncplist /test/usr/bin install -o root -g wheel -m 444 ncplist.1.gz /test/usr/share/man/man1 ===> usr.bin/ncplogin (install) make: don't know how to make install. Stop *** Error code 2 Stop in /usr/src/myHEAD/src/usr.bin. *** Error code 1 it turned out that the ASCII data on the USB is damaged: # file /usr/src/myHEAD/src/usr.bin/ncplogin/* /usr/src/myHEAD/src/usr.bin/ncplogin/CVS: directory /usr/src/myHEAD/src/usr.bin/ncplogin/Makefile: data /usr/src/myHEAD/src/usr.bin/ncplogin/ncplogin.1: data /usr/src/myHEAD/src/usr.bin/ncplogin/ncplogin.c: data /usr/src/myHEAD/src/usr.bin/ncplogin/ncplogout.1: troff or preprocessor input text on the originating system it is: $ file /usr/src/myHEAD/src/usr.bin/ncplogin/* /usr/src/myHEAD/src/usr.bin/ncplogin/CVS: directory /usr/src/myHEAD/src/usr.bin/ncplogin/Makefile: ASCII text /usr/src/myHEAD/src/usr.bin/ncplogin/ncplogin.1: troff or preprocessor input text /usr/src/myHEAD/src/usr.bin/ncplogin/ncplogin.c: ASCII C program text /usr/src/myHEAD/src/usr.bin/ncplogin/ncplogout.1: troff or preprocessor input text i.e the data in the USB key produced by # tar -cf - myHEAD | ( cd /mnt ; tar -xpf - ) is damaged :-(( maybe I should better use # cp -Rp /usr/src/myHEAD /mnt/usr/src and not tar(1) to copy the src/obj tree... Thx matthias -- Matthias Apitz Manager Technical Support - OCLC GmbH Gruenwalder Weg 28g - 82041 Oberhaching - Germany t +49-89-61308 351 - f +49-89-61308 399 - m +49-170-4527211 e - w http://www.oclc.org/ http://www.UnixArea.de/ From owner-freebsd-current@FreeBSD.ORG Mon Mar 30 15:04: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 E7897106566C; Mon, 30 Mar 2009 15:04:19 +0000 (UTC) (envelope-from onemda@gmail.com) Received: from mail-ew0-f171.google.com (mail-ew0-f171.google.com [209.85.219.171]) by mx1.freebsd.org (Postfix) with ESMTP id ECDEE8FC0A; Mon, 30 Mar 2009 15:04:18 +0000 (UTC) (envelope-from onemda@gmail.com) Received: by ewy19 with SMTP id 19so1910657ewy.43 for ; Mon, 30 Mar 2009 08:04:17 -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=fgKkxNEd5WidEKzCjOwu3EqX8dPGcweAqfFI9jlHrnY=; b=tvFyrY7gYLYAOvSlsS2XL+0lgcstusonffcZqFlYirdv8bzMPwxK83nToaHkymKaew fShcxYWYmKBFwOkSe4UPGdSGBS55SiP32i3NBIzFXVJb4/gT8hD6itl8YYQ1eUyRPzCR b8KWVUPL6c+SUyC1iUsFZqanC6KWjiyHWCsGQ= 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=hRbBmHbTQ/fL/PM6LrWCtQ+LKvfl2brErbWGGTkgwXdb+QBm+E3Vd0lwG2Y1vpKTKz MSkmh1x+57Mm6/pxuPWtNGIBxbpp5bNtfe8xVYJRdJhz6oQjlZg0FOpou4U65mQdXthi Q5jQcG+NnYInYZXyDJsl/pzVfBwevb5+MEt8Y= MIME-Version: 1.0 Received: by 10.210.139.15 with SMTP id m15mr4185052ebd.32.1238425457730; Mon, 30 Mar 2009 08:04:17 -0700 (PDT) In-Reply-To: <20090330061036.GA83528@citylink.fud.org.nz> References: <1237804575.1771.7.camel@balrog.2hip.net> <1237884572.1771.28.camel@balrog.2hip.net> <20090330061036.GA83528@citylink.fud.org.nz> Date: Mon, 30 Mar 2009 16:04:17 +0100 Message-ID: <3a142e750903300804r75d6ef81kae69cdfdb618b719@mail.gmail.com> From: "Paul B. Mahol" To: Andrew Thompson Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org, Nenhum_de_Nos , Robert Noland Subject: Re: Booting from usb hard disk 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, 30 Mar 2009 15:04:20 -0000 On 3/30/09, Andrew Thompson wrote: > On Tue, Mar 24, 2009 at 03:49:32AM -0500, Robert Noland wrote: >> On Mon, 2009-03-23 at 19:40 -0300, Nenhum_de_Nos wrote: >> > On Mon, March 23, 2009 07:36, Robert Noland wrote: >> > > So I have my i386 install on a usb hard disk, which I can only boot on >> > > one machine now. The one machine that I can make work has a bios >> > > option >> > > that reads "BIOS ehci handoff". This used to work with the old usb >> > > stack. The machines that it doesn't work on, boot the kernel, but >> > > fail >> > > to mount root, giving me the forbidding mountroot> prompt, which is >> > > immediately followed by the message saying that da0 is attached. da0 >> > > is >> > > however not listed in the available boot devices list. I tried >> > > playing >> > > around with the timeout in vfs_mount.c, but that didn't seem to have >> > > any >> > > impact. It has been suggested that this may be a "geom" timeout, but >> > > I >> > > don't know anything about the boot system really. >> > >> > I had problem a while ago with via mini itx hardware, that was quite >> > close. If I try boot from usb (installed in usb hdd), I get to the point >> > of loader not finding my disk. >> > >> > I then used a small flash disk attached to the ata (44 pin ide) channel >> > and formatted /boot in there. this way I get to the point of mount root >> > you said, and da0 not being alive soon enough to mount root. list disks >> > also couldn't find da0 though. >> > >> > I tried current from that time, and no good. >> > >> > if this is solved, I'll be happy to try whatever patch to current. (as >> > long as I can install it from another box/or its ata channel, as it >> > can't >> > boot vanilla 7.1R) >> >> So, my solution was to set kern.cam.scsi_delay=10000 >> in /boot/loader.conf > > The following patch should work. It creates interleaving root hold > tokens from the CAM probe to disk_create and geom providor tasting. > I had to add a malloc type flag as sleeping isnt allowed at the point I > added the token alloc in CAM. > > http://people.freebsd.org/~thompsa/root_wait.diff Hmm, this is supposed to fix issue when trying to boot from usb disk with UP kernel? -- Paul From owner-freebsd-current@FreeBSD.ORG Mon Mar 30 15:34: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 D00FC1065670 for ; Mon, 30 Mar 2009 15:34:48 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id A0C918FC16 for ; Mon, 30 Mar 2009 15:34:48 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Received: from server.baldwin.cx (pool-98-109-39-197.nwrknj.fios.verizon.net [98.109.39.197]) by cyrus.watson.org (Postfix) with ESMTPSA id 3784046B0D; Mon, 30 Mar 2009 11:34:48 -0400 (EDT) Received: from localhost (john@localhost [127.0.0.1]) (authenticated bits=0) by server.baldwin.cx (8.14.3/8.14.3) with ESMTP id n2UFYVHs023015; Mon, 30 Mar 2009 11:34:42 -0400 (EDT) (envelope-from jhb@FreeBSD.org) From: John Baldwin To: freebsd-current@FreeBSD.org, barney_cordoba@yahoo.com Date: Mon, 30 Mar 2009 10:59:13 -0400 User-Agent: KMail/1.9.7 References: <513261.38032.qm@web63907.mail.re1.yahoo.com> In-Reply-To: <513261.38032.qm@web63907.mail.re1.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200903301059.13428.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (server.baldwin.cx [127.0.0.1]); Mon, 30 Mar 2009 11:34:42 -0400 (EDT) X-Virus-Scanned: ClamAV 0.94.2/9180/Sun Mar 29 16:40:14 2009 on server.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-4.4 required=4.2 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.1.3 X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on server.baldwin.cx Cc: Subject: Re: pci_alloc_resource is broken 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, 30 Mar 2009 15:34:49 -0000 On Sunday 29 March 2009 11:34:32 am Barney Cordoba wrote: > > --- On Sat, 3/28/09, Barney Cordoba wrote: > > > From: Barney Cordoba > > Subject: Re: Bus Resource busy panic > > To: current@freebsd.org > > Date: Saturday, March 28, 2009, 8:03 PM > > --- On Sat, 3/28/09, Barney Cordoba > > wrote: > > > > > From: Barney Cordoba > > > Subject: Bus Resource busy panic > > > To: current@freebsd.org > > > Date: Saturday, March 28, 2009, 6:35 PM > > > I have a situation that results in a panic in 8 that > > runs > > > happily in 7. > > > Its a bus_alloc_resource of type SYS_RES_MEMORY that > > is > > > used by 2 > > > separate devices. > > > > > > I see there is an RF_SHAREABLE flag. That flag > > hadn't > > > been set, but is there > > > something in 8 that now requires it? > > > > > > As a side question, should a bus_alloc_resource call > > panic > > > the system just > > > because the resource is busy? > > > > > > Barney > > > > Some more info on this. The panic is in > > resource_list_alloc() and > > setting SHAREABLE doesn't fix it. I see the same code > > in 7 so > > I'm not sure why it would work in 7 and not 8. > > > > Basically there are 2 devices that need to do IO on a > > board, and they > > are both doing > > > > bus_alloc_resource_any(dev, SYS_RES_MEMORY,&rid, > > RF_ACTIVE); > > > > > > Barney > > > > I'm not sure if anyone was reading the original thread, so I > created another with my results. > > Someone broke pci_alloc_resource. In the SYS_RES_MEMORY case, when > rman_get_device() != dev (but rle->res is set), it erroneously > falls to resource_list_alloc which will panic on device resource busy. > > It seems that this would preclude the sharing of a resource, as any > secondary request will not only fail, but panic the system This was actually on purpose to prevent multiple allocations of a resource. Multiple allocations actually leak kernel memory since the resource only keeps track of the current mapping. My question is why are you having one device allocate resources of another device? If you have two functions of a multi-function PCI adapter that you want one logical driver for, then have each function's driver allocate its own resources and store the 'struct resource *' in a "global" softc. You can then use whichever resource you need for bus_read/write when you do bit-banging. -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Mon Mar 30 15:34:54 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 CA51E1065670 for ; Mon, 30 Mar 2009 15:34:54 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 98F898FC1C for ; Mon, 30 Mar 2009 15:34:54 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Received: from server.baldwin.cx (pool-98-109-39-197.nwrknj.fios.verizon.net [98.109.39.197]) by cyrus.watson.org (Postfix) with ESMTPSA id 4956E46B23; Mon, 30 Mar 2009 11:34:54 -0400 (EDT) Received: from localhost (john@localhost [127.0.0.1]) (authenticated bits=0) by server.baldwin.cx (8.14.3/8.14.3) with ESMTP id n2UFYVHt023015; Mon, 30 Mar 2009 11:34:48 -0400 (EDT) (envelope-from jhb@FreeBSD.org) From: John Baldwin To: freebsd-current@FreeBSD.org, barney_cordoba@yahoo.com Date: Mon, 30 Mar 2009 11:00:57 -0400 User-Agent: KMail/1.9.7 References: <483663.31171.qm@web63906.mail.re1.yahoo.com> In-Reply-To: <483663.31171.qm@web63906.mail.re1.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200903301100.57757.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (server.baldwin.cx [127.0.0.1]); Mon, 30 Mar 2009 11:34:48 -0400 (EDT) X-Virus-Scanned: ClamAV 0.94.2/9180/Sun Mar 29 16:40:14 2009 on server.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-4.4 required=4.2 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.1.3 X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on server.baldwin.cx Cc: Subject: Re: cpuset affinity control from within the kernel 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, 30 Mar 2009 15:34:55 -0000 On Sunday 29 March 2009 3:59:40 pm Barney Cordoba wrote: > > What tools are available for taskqueues, interrupts, etc from within the kernel? You can use BUS_BIND_INTR() for interrupts. You can use 'sched_bind() / sched_unbind()' in thread contexts. For example, to pin taskqueue threads (you should only do this for a private taskqueue you create though) you can simply enqueue a task to the thread that does a 'sched_bind()'. -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Mon Mar 30 15:35: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 CC3D31065760; Mon, 30 Mar 2009 15:35:01 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 878448FC1D; Mon, 30 Mar 2009 15:35:01 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Received: from server.baldwin.cx (pool-98-109-39-197.nwrknj.fios.verizon.net [98.109.39.197]) by cyrus.watson.org (Postfix) with ESMTPSA id 1AF8446B38; Mon, 30 Mar 2009 11:35:01 -0400 (EDT) Received: from localhost (john@localhost [127.0.0.1]) (authenticated bits=0) by server.baldwin.cx (8.14.3/8.14.3) with ESMTP id n2UFYVHu023015; Mon, 30 Mar 2009 11:34:54 -0400 (EDT) (envelope-from jhb@FreeBSD.org) From: John Baldwin To: Tim Kientzle Date: Mon, 30 Mar 2009 11:31:43 -0400 User-Agent: KMail/1.9.7 References: <20090312175345.Y80227@rust.salford.ac.uk> <20090317070440.GE2012@garage.freebsd.pl> <49CFA1D9.1020604@freebsd.org> In-Reply-To: <49CFA1D9.1020604@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200903301131.44164.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (server.baldwin.cx [127.0.0.1]); Mon, 30 Mar 2009 11:34:55 -0400 (EDT) X-Virus-Scanned: ClamAV 0.94.2/9180/Sun Mar 29 16:40:14 2009 on server.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-4.4 required=4.2 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.1.3 X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on server.baldwin.cx Cc: Pawel Jakub Dawidek , Attilio Rao , "freebsd-current@freebsd.org" , Mark Powell , Anonymous , Peter Schuller Subject: Re: repeatable ZFS panic: share->excl 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, 30 Mar 2009 15:35:02 -0000 On Sunday 29 March 2009 12:29:13 pm Tim Kientzle wrote: > Pawel Jakub Dawidek wrote: > > On Fri, Mar 13, 2009 at 02:08:03PM -0400, John Baldwin wrote: > >> John Baldwin wrote: > >>> Yes, I think that is the real bug. Looking at this further I think > >>> zfs_get_xattrdir() will return the vnode locked if it has to create a > >>> new node via zfs_make_attrdir() but only returns it held and unlocked if > >>> it finds an existing one. So my new patch is to just fix > >>> zfs_get_xattrdir() to unlock the vnode if it creates a new one like so: > >>> > >>> (Sorry, TBird is probably going to butcher all the whitespace): > >>> > >>> --- > >>> //depot/user/jhb/lock/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_dir.c > >>> +++ > >>> /Users/jhb/work/p4/lock/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_dir.c > >>> > >>> @@ -940,6 +940,7 @@ > >>> /* NB: we already did dmu_tx_wait() if necessary */ > >>> goto top; > >>> } > >>> + VOP_UNLOCK(*xvpp, 0); > >>> > >>> return (error); > >>> } > >>> > >>> A non-butchered version is at www.FreeBSD.org/~jhb/patches/zfs_ea.patch. > >> So lulf@ reports success with this patch. Pawel, can you review it? > > > > Yes, it works for me too and looks good. The only thing we need to > > change is to check for error beeing 0 before unlocking the vnode. > > The zfs_make_xattrdir() function can still return with EIO, so I'd add > > something like this: > > > > if (error == 0) > > VOP_UNLOCK(*xvpp, 0); > > > > Thank you John for spending time on tracking this one down. > > Any estimate on when this can be committed? > > I'm waiting to re-enable the extended attribute > archiving support in tar until this is fixed. Err, it went into the tree a while ago: Author: jhb Date: Wed Mar 18 16:19:44 2009 New Revision: 189967 URL: http://svn.freebsd.org/changeset/base/189967 Log: The zfs_get_xattrdir() function is used to find the extended attribute directory for a znode. When the directory already exists, it returns a referenced but unlocked vnode. When a directory does not yet exist, it calls zfs_make_xattrdir() to create a new one. zfs_make_xattrdir() returns the vnode both referenced and and locked and zfs_get_xattrdir() was leaking this vnode lock to its callers. Fix this by dropping the vnode lock if zfs_make_xattrdir() successfully creates a new extended attribute directory. Reviewed by: pjd -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Mon Mar 30 15:41: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 E302D10656DB for ; Mon, 30 Mar 2009 15:41:51 +0000 (UTC) (envelope-from aragon@phat.za.net) Received: from mail.geek.sh (decoder.geek.sh [196.36.198.81]) by mx1.freebsd.org (Postfix) with ESMTP id 7D95E8FC15 for ; Mon, 30 Mar 2009 15:41:51 +0000 (UTC) (envelope-from aragon@phat.za.net) Received: from igor.geek.sh (unknown [196.209.244.121]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.geek.sh (Postfix) with ESMTPSA id 7BEC13A6A4; Mon, 30 Mar 2009 17:25:01 +0200 (SAST) Message-ID: <49D0E44C.60103@phat.za.net> Date: Mon, 30 Mar 2009 17:25:00 +0200 From: Aragon Gouveia User-Agent: Thunderbird 2.0.0.19 (X11/20090309) MIME-Version: 1.0 To: =?UTF-8?B?IuW0lOWyqWNjdWl5eWFuQHNpbmEuY29tIg==?= References: <4451ccf20903300123p4df9c1d7k4c4138ad25d2d4af@mail.gmail.com> In-Reply-To: <4451ccf20903300123p4df9c1d7k4c4138ad25d2d4af@mail.gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: freebsd-current@freebsd.org Subject: Re: loader prompt doesn't work 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, 30 Mar 2009 15:41:53 -0000 崔岩ccuiyyan@sina.com wrote: > However, problem happens. When i select the "escape to a loader prompt" > option, i can input > > in about just 3 sec. After that, the system cannot go on whatever key i > hit. Same problem here and it's not USB/keyboard related in my case. What motherboard are you using? I'm on an Intel DG33BU. Regards, Aragon From owner-freebsd-current@FreeBSD.ORG Mon Mar 30 15:53: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 6CE4E1065670 for ; Mon, 30 Mar 2009 15:53:03 +0000 (UTC) (envelope-from barney_cordoba@yahoo.com) Received: from web63906.mail.re1.yahoo.com (web63906.mail.re1.yahoo.com [69.147.97.121]) by mx1.freebsd.org (Postfix) with SMTP id 27A718FC0C for ; Mon, 30 Mar 2009 15:53:02 +0000 (UTC) (envelope-from barney_cordoba@yahoo.com) Received: (qmail 10197 invoked by uid 60001); 30 Mar 2009 15:53:02 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1238428382; bh=skI2Fw1TQ8s9VczZInPPxvC6FjZj9y0aBBB6hxR5f8A=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=KCEK7EMEDpXCo9kvageNN+jP7FT742RaKMKhFUtMo1/XxVlnUNVcfg3bA9Jd11W1XsAbngiJZ0mDxVbF1lkz+BFMO/XDjcqPjZ0v81MYXK+q2/5X12Ofl+XSL2j9wYVoJN+xJzj17pOLNvijsdBVoMZAq2Y+Se8QxtdmTd453gk= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=kMsP0TDetVfjZ5J5VlB8gnYiqrNbPwDUw4K0R20/BWI6Dp5PlVrEVQIbD2e9dDnERyBNjr57Q4NKEKq/HPBMGOqNp8liyboSHkE/V2QYLkBy4pI+RmCmo267b0zUhuHPNWMfKO98q4wMPrc7eYTlB0PlDiQPCfmo2/PMcOix/qE=; Message-ID: <452083.9826.qm@web63906.mail.re1.yahoo.com> X-YMail-OSG: XcWJnLAVM1nPgikCDr6Qh5hNlVhF0m.YZUqGHyP47_YWkMzPq2aHnvXp4I92fZtee1Nam4Ox3v.BYpqXO4ZqQQm7KA0RXntk3ASZRL70LLcrCp7RdZSdkWDdcfrAtZxwLepwbOgIfH9qCrrqIfoj.mZ697ME_M93dl9vz6Dj7uTJTOGxGRhwhABVsmEPND9LVhddJ5MHaEijMScFmGk33Jmsnre36aMynuv0Xba.2CzFvlnkc.k6seRcOJcTGwV9hDJzeMYZXcJEM1eRDj6JcJ4- Received: from [98.242.222.229] by web63906.mail.re1.yahoo.com via HTTP; Mon, 30 Mar 2009 08:53:02 PDT X-Mailer: YahooMailWebService/0.7.289.1 Date: Mon, 30 Mar 2009 08:53:02 -0700 (PDT) From: Barney Cordoba To: freebsd-current@FreeBSD.org, John Baldwin In-Reply-To: <200903301059.13428.jhb@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Subject: Re: pci_alloc_resource is broken X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: barney_cordoba@yahoo.com List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Mar 2009 15:53:04 -0000 --- On Mon, 3/30/09, John Baldwin wrote: > From: John Baldwin > Subject: Re: pci_alloc_resource is broken > To: freebsd-current@FreeBSD.org, barney_cordoba@yahoo.com > Date: Monday, March 30, 2009, 10:59 AM > On Sunday 29 March 2009 11:34:32 am Barney Cordoba wrote: > > > > --- On Sat, 3/28/09, Barney Cordoba > wrote: > > > > > From: Barney Cordoba > > > > Subject: Re: Bus Resource busy panic > > > To: current@freebsd.org > > > Date: Saturday, March 28, 2009, 8:03 PM > > > --- On Sat, 3/28/09, Barney Cordoba > > > wrote: > > > > > > > From: Barney Cordoba > > > > > Subject: Bus Resource busy panic > > > > To: current@freebsd.org > > > > Date: Saturday, March 28, 2009, 6:35 PM > > > > I have a situation that results in a panic > in 8 that > > > runs > > > > happily in 7. > > > > Its a bus_alloc_resource of type > SYS_RES_MEMORY that > > > is > > > > used by 2 > > > > separate devices. > > > > > > > > I see there is an RF_SHAREABLE flag. That > flag > > > hadn't > > > > been set, but is there > > > > something in 8 that now requires it? > > > > > > > > As a side question, should a > bus_alloc_resource call > > > panic > > > > the system just > > > > because the resource is busy? > > > > > > > > Barney > > > > > > Some more info on this. The panic is in > > > resource_list_alloc() and > > > setting SHAREABLE doesn't fix it. I see the > same code > > > in 7 so > > > I'm not sure why it would work in 7 and not > 8. > > > > > > Basically there are 2 devices that need to do IO > on a > > > board, and they > > > are both doing > > > > > > bus_alloc_resource_any(dev, > SYS_RES_MEMORY,&rid, > > > RF_ACTIVE); > > > > > > > > > Barney > > > > > > > I'm not sure if anyone was reading the original > thread, so I > > created another with my results. > > > > Someone broke pci_alloc_resource. In the > SYS_RES_MEMORY case, when > > rman_get_device() != dev (but rle->res is set), it > erroneously > > falls to resource_list_alloc which will panic on > device resource busy. > > > > It seems that this would preclude the sharing of a > resource, as any > > secondary request will not only fail, but panic the > system > > This was actually on purpose to prevent multiple > allocations of a resource. > Multiple allocations actually leak kernel memory since the > resource only > keeps track of the current mapping. My question is why are > you having one > device allocate resources of another device? If you have > two functions of a > multi-function PCI adapter that you want one logical driver > for, then have > each function's driver allocate its own resources and > store the 'struct > resource *' in a "global" softc. You can > then use whichever resource you > need for bus_read/write when you do bit-banging. > > -- > John Baldwin We're remapping in another driver because in the commercial world, we don't always have access to kernel source, and there is a strong desire to separate the NIC driver from the secondary function so customers can get patches for the OS without having to worry about incompatibility with the secondary modules. I can add a function to the NIC driver also, but the goal is to be able to distribute a module that doesn't require modification to the stock driver for the system. Barney From owner-freebsd-current@FreeBSD.ORG Mon Mar 30 16:14: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 7A66410656C7 for ; Mon, 30 Mar 2009 16:14:44 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 4BA948FC18 for ; Mon, 30 Mar 2009 16:14:44 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from server.baldwin.cx (pool-98-109-39-197.nwrknj.fios.verizon.net [98.109.39.197]) by cyrus.watson.org (Postfix) with ESMTPSA id D61F146B38; Mon, 30 Mar 2009 12:14:43 -0400 (EDT) Received: from localhost (john@localhost [127.0.0.1]) (authenticated bits=0) by server.baldwin.cx (8.14.3/8.14.3) with ESMTP id n2UGEbUt023336; Mon, 30 Mar 2009 12:14:38 -0400 (EDT) (envelope-from jhb@freebsd.org) From: John Baldwin To: barney_cordoba@yahoo.com Date: Mon, 30 Mar 2009 12:14:32 -0400 User-Agent: KMail/1.9.7 References: <452083.9826.qm@web63906.mail.re1.yahoo.com> In-Reply-To: <452083.9826.qm@web63906.mail.re1.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200903301214.32493.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (server.baldwin.cx [127.0.0.1]); Mon, 30 Mar 2009 12:14:38 -0400 (EDT) X-Virus-Scanned: ClamAV 0.94.2/9180/Sun Mar 29 16:40:14 2009 on server.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-4.4 required=4.2 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.1.3 X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on server.baldwin.cx Cc: freebsd-current@freebsd.org Subject: Re: pci_alloc_resource is broken 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, 30 Mar 2009 16:14:44 -0000 On Monday 30 March 2009 11:53:02 am Barney Cordoba wrote: > > This was actually on purpose to prevent multiple > > allocations of a resource. > > Multiple allocations actually leak kernel memory since the > > resource only > > keeps track of the current mapping. My question is why are > > you having one > > device allocate resources of another device? If you have > > two functions of a > > multi-function PCI adapter that you want one logical driver > > for, then have > > each function's driver allocate its own resources and > > store the 'struct > > resource *' in a "global" softc. You can > > then use whichever resource you > > need for bus_read/write when you do bit-banging. > > > > -- > > John Baldwin > > We're remapping in another driver because in the commercial world, > we don't always have access to kernel source, and there is a strong > desire to separate the NIC driver from the secondary function so > customers can get patches for the OS without having to worry about > incompatibility with the secondary modules. > > I can add a function to the NIC driver also, but the goal is to be > able to distribute a module that doesn't require modification to the > stock driver for the system. In FreeBSD you do always have access to the source. :) (And fwiw, I have worked on proprietary FreeBSD drivers in the past including a driver for a multi-function card that actually managed two functions via one logical driver.) However, I am curious that you are able to make this work on "commercial" operating systems as well. On OS X only the IOService child of a PCI node can map the BARs of that node. Well, you can actually walk up to the parent PCI bus, find your sibling IOService node and get its BARs that way which does work. In Windows I'm not sure how you would make this work as when you attach to a FDO you get callbacks for each of your resources for tha tnode in BAR order. AFAIK, there isn't a good way to discover or use the resources of another device in WDM, at least not at the time of Windows XP. -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Mon Mar 30 16:15:32 2009 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from [127.0.0.1] (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by hub.freebsd.org (Postfix) with ESMTP id 1A4A810656CD; Mon, 30 Mar 2009 16:15:32 +0000 (UTC) (envelope-from jkim@FreeBSD.org) From: Jung-uk Kim To: freebsd-current@FreeBSD.org Date: Mon, 30 Mar 2009 12:15:15 -0400 User-Agent: KMail/1.6.2 References: <1236802980.00085518.1236789602@10.7.7.3> <200903251833.14825.jkim@FreeBSD.org> <49CFD66E.5030301@entel.upc.edu> In-Reply-To: <49CFD66E.5030301@entel.upc.edu> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200903301215.19629.jkim@FreeBSD.org> Cc: Gustau Perez Subject: Re: [HEADSUP] amd64 suspend/resume code to be comitted 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, 30 Mar 2009 16:15:33 -0000 On Sunday 29 March 2009 04:13 pm, Gustau Perez wrote: > > Then, it is something else, e.g., acpi_video(4). You can try > > setting debug.acpi.disabled="video" in /boot/loader.conf for > > example. > > > > Jung-uk Kim > > Sorry for the delay. Tried loading acpi_video in > /boot/loader.conf. After having a terminal, I checked the available > mibs with sysctl -a | grep acpi.video. Only get > hw.acpi.reset_video. The man page didn't throw the waited ray of > light :) So, its BIOS does not support ACPI video extension. :-) > I also tried suspending from the terminal, without X's running. > I tried vbetool (dpms off/on and post). I wasn't brave enought to > try vbestate save and restore. It seems many modern graphics boards do not support this function any way. :-( > Finally I decided it was time to use all the arsenal available > :) so I decided to remove everything not necessary. So usb and > friends, firewire, cbb and pccard, if_bge, if_rum, snd_hda and > nouveau were removed from the kernel. Tried going single user mode, > remove them and acpiconf -s 3. Guess what happened :) Let me guess, it worked? ;-) > Checking messages doesn't show anything unsual. But if you want > them or if I can try others things to debug, let me know. If it worked fine, you can try each driver and tell us what breaks suspend/resume process. If you can find the culprit, you can file a PR and you may able to work around it by adding 'kldunload whatever' and 'kldload whatever' from rc.suspend and rc.resume respectively. BTW, bge(4) is already known for suspend/resume problem if my memory serves. Jung-uk Kim From owner-freebsd-current@FreeBSD.ORG Mon Mar 30 16:22: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 CAF43106572D; Mon, 30 Mar 2009 16:22:34 +0000 (UTC) (envelope-from wenji@fnal.gov) Received: from mailgw2.fnal.gov (mailgw2.fnal.gov [131.225.111.12]) by mx1.freebsd.org (Postfix) with ESMTP id 9B7578FC14; Mon, 30 Mar 2009 16:22:34 +0000 (UTC) (envelope-from wenji@fnal.gov) Received: from mailav2.fnal.gov (mailav2.fnal.gov [131.225.111.20]) by mailgw2.fnal.gov (iPlanet Messaging Server 5.2 HotFix 2.06 (built Mar 28 2005)) with SMTP id <0KHB008OCULZK9@mailgw2.fnal.gov>; Mon, 30 Mar 2009 11:22:33 -0500 (CDT) Received: from mailgw1.fnal.gov ([131.225.111.11]) by mailav2.fnal.gov (SAVSMTP 3.1.7.47) with SMTP id M2009033011223316091 ; Mon, 30 Mar 2009 11:22:33 -0500 Received: from conversion-daemon.mailgw1.fnal.gov by mailgw1.fnal.gov (iPlanet Messaging Server 5.2 HotFix 2.06 (built Mar 28 2005)) id <0KHB00801USXTQ@mailgw1.fnal.gov> (original mail from wenji@fnal.gov); Mon, 30 Mar 2009 11:22:33 -0500 (CDT) Received: from fnal.gov (imap2.fnal.gov [131.225.111.7]) by mailgw1.fnal.gov (iPlanet Messaging Server 5.2 HotFix 2.06 (built Mar 28 2005)) with ESMTP id <0KHB007YNUTLSP@mailgw1.fnal.gov>; Mon, 30 Mar 2009 11:22:33 -0500 (CDT) Received: from [131.225.2.15] by imap2.fnal.gov (mshttpd); Mon, 30 Mar 2009 16:22:33 +0000 (GMT) Date: Mon, 30 Mar 2009 16:22:33 +0000 (GMT) From: Wenji Wu In-reply-to: <49D0070D.2060905@FreeBSD.org> To: Kris Kennaway Message-id: MIME-version: 1.0 X-Mailer: Sun Java(tm) System Messenger Express 6.3-6.03 (built Mar 14 2008; 32bit) Content-type: text/plain; charset=us-ascii Content-language: en Content-transfer-encoding: 7BIT Content-disposition: inline X-Accept-Language: en Priority: normal References: <49D0046C.8020909@FreeBSD.org> <49D0070D.2060905@FreeBSD.org> Cc: freebsd-current@freebsd.org Subject: Re: LOCK_PROFILING does not work on FreeBSD 8.0-CURRENT 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, 30 Mar 2009 16:22:36 -0000 Hi, Kris, I beleive something is wrong with FreeBSD 8.0's configuration or compiling. I just made "LOCK_PROFILING" work in my system. Here is my procedures, (1) $ uname -a FreeBSD wan-koi.fnal.gov 8.0-CURRENT FreeBSD 8.0-CURRENT #11: Mon Mar 30 14:17:49 UTC 2009 root@wan-koi.fnal.gov:/usr/obj/usr/src/sys/wenjikernel amd64 (2) go to "/usr/obj/usr/src/sys/wenjikernel", then run "vi config.c", and check "OPTIONS LOCK_PROFILING" is included. (3) go to "/usr/src", run "make buildkernel KERNCONF=wenjikernel", "make installkernel KERNCONF=wenjikernel", "reboot" (4) run "sysctl -a|grep lock", NO "LOCK_PROFILING" capability! (5) go to "/usr/obj/usr/src/sys/wenjikernel", then run "vi config.c", comment out ""#ifdef INCLUDE_CONFIG_FILE" (6) go to "/usr/src", run "make buildkernel KERNCONF=wenjikernel", "make installkernel KERNCONF=wenjikernel", "reboot" (7) run "sysctl -a|grep lock", NO "LOCK_PROFILING" capability! (8) $ uname -a FreeBSD wan-koi.fnal.gov 8.0-CURRENT FreeBSD 8.0-CURRENT #11: Mon Mar 30 14:17:49 UTC 2009 root@wan-koi.fnal.gov:/usr/obj/usr/src/sys/GENERIC amd64 please note here: "GENERIC", I was actually compiling and installing with "wenjikenrel". I do not know why it automatically goes with "GENERIC" (9) go to "/usr/src/sys/amd64/conf", add "OPTIONS LOCK_PROFILING" to GENERIC (10) go to "/usr/src", run "make buildkernel KERNCONF=wenjikernel", "make installkernel KERNCONF=wenjikernel", "reboot" (11) "uname -a" $ uname -a FreeBSD wan-koi.fnal.gov 8.0-CURRENT FreeBSD 8.0-CURRENT #11: Mon Mar 30 14:17:49 UTC 2009 root@wan-koi.fnal.gov:/usr/obj/usr/src/sys/wenjikernel amd64 (12) run "sysctl -a|grep lock|grep debug" $ sysctl -a|grep lock|grep debug debug.acpi.reset_clock: 1 debug.rwlock.loops: 10000 debug.rwlock.retry: 10 debug.to_avg_lockcalls: 11 debug.lock.prof.enable: 0 debug.lock.prof.reset: 0 debug.lock.prof.stats: debug.lock.prof.rejected: 0 debug.lock.prof.skipcount: 0 debug.lock.prof.skipspin: 0 Now you see, "LOCK_PROFILING" works now! I just repeat the procedures, So, something is wrong with the configuration and compling! wenji From owner-freebsd-current@FreeBSD.ORG Mon Mar 30 16:26: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 2E46E106566C; Mon, 30 Mar 2009 16:26:00 +0000 (UTC) (envelope-from thompsa@FreeBSD.org) Received: from pele.citylink.co.nz (pele.citylink.co.nz [202.8.44.226]) by mx1.freebsd.org (Postfix) with ESMTP id 4279D8FC08; Mon, 30 Mar 2009 16:26:00 +0000 (UTC) (envelope-from thompsa@FreeBSD.org) Received: from localhost (localhost [127.0.0.1]) by pele.citylink.co.nz (Postfix) with ESMTP id 82460FF2A; Tue, 31 Mar 2009 05:25:59 +1300 (NZDT) X-Virus-Scanned: Debian amavisd-new at citylink.co.nz Received: from pele.citylink.co.nz ([127.0.0.1]) by localhost (pele.citylink.co.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kH4AG1a4Ah+d; Tue, 31 Mar 2009 05:25:53 +1300 (NZDT) Received: from citylink.fud.org.nz (unknown [202.8.44.45]) by pele.citylink.co.nz (Postfix) with ESMTP; Tue, 31 Mar 2009 05:25:53 +1300 (NZDT) Received: by citylink.fud.org.nz (Postfix, from userid 1001) id 6F1041142F; Tue, 31 Mar 2009 05:25:53 +1300 (NZDT) Date: Mon, 30 Mar 2009 09:25:53 -0700 From: Andrew Thompson To: "Paul B. Mahol" Message-ID: <20090330162553.GA44858@citylink.fud.org.nz> References: <1237804575.1771.7.camel@balrog.2hip.net> <1237884572.1771.28.camel@balrog.2hip.net> <20090330061036.GA83528@citylink.fud.org.nz> <3a142e750903300804r75d6ef81kae69cdfdb618b719@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3a142e750903300804r75d6ef81kae69cdfdb618b719@mail.gmail.com> User-Agent: Mutt/1.5.17 (2007-11-01) Cc: freebsd-current@freebsd.org, Nenhum_de_Nos , Robert Noland Subject: Re: Booting from usb hard disk 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, 30 Mar 2009 16:26:01 -0000 On Mon, Mar 30, 2009 at 04:04:17PM +0100, Paul B. Mahol wrote: > On 3/30/09, Andrew Thompson wrote: > > On Tue, Mar 24, 2009 at 03:49:32AM -0500, Robert Noland wrote: > >> On Mon, 2009-03-23 at 19:40 -0300, Nenhum_de_Nos wrote: > >> > > >> > I had problem a while ago with via mini itx hardware, that was quite > >> > close. If I try boot from usb (installed in usb hdd), I get to the point > >> > of loader not finding my disk. > >> > > >> > I then used a small flash disk attached to the ata (44 pin ide) channel > >> > and formatted /boot in there. this way I get to the point of mount root > >> > you said, and da0 not being alive soon enough to mount root. list disks > >> > also couldn't find da0 though. > >> > > >> > I tried current from that time, and no good. > >> > > >> > if this is solved, I'll be happy to try whatever patch to current. (as > >> > long as I can install it from another box/or its ata channel, as it > >> > can't > >> > boot vanilla 7.1R) > >> > >> So, my solution was to set kern.cam.scsi_delay=10000 > >> in /boot/loader.conf > > > > The following patch should work. It creates interleaving root hold > > tokens from the CAM probe to disk_create and geom providor tasting. > > I had to add a malloc type flag as sleeping isnt allowed at the point I > > added the token alloc in CAM. > > > > http://people.freebsd.org/~thompsa/root_wait.diff > > Hmm, this is supposed to fix issue when trying to boot from usb disk > with UP kernel? This is to address the issue where the usb disk hasnt been attached by the time the root filesystem is mounted. ie, you are booting from usb. If your problem is different then please say. Andrew From owner-freebsd-current@FreeBSD.ORG Mon Mar 30 16:34: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 5BA851065675 for ; Mon, 30 Mar 2009 16:34:34 +0000 (UTC) (envelope-from barney_cordoba@yahoo.com) Received: from web63905.mail.re1.yahoo.com (web63905.mail.re1.yahoo.com [69.147.97.120]) by mx1.freebsd.org (Postfix) with SMTP id F19CA8FC1C for ; Mon, 30 Mar 2009 16:34:33 +0000 (UTC) (envelope-from barney_cordoba@yahoo.com) Received: (qmail 93414 invoked by uid 60001); 30 Mar 2009 16:34:33 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1238430873; bh=/40JYUMqagZQ2Kli8eDQK3ugTjSdCPIT5T/KG5OTUso=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=dmH75fNTCIgWGO2L6uCvW2FHZRA3iT9OzO+dDUY9Jt+uXryBkvwybomsuENQUHRVh8iUBHkXmqaaIOIF2dVLpBV9YfANHzc+jxIDHvfq11mfQTWo+2ctZZ+bHqvcITJVidVVG4vZGAvrqOnjpRwgkFQqzLawx24S0NKLROUSGbs= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=VtdhAxSBpv+ARxTSmKZMh8yz4eWmYdxSaQMoanx8c4PkCIuJ4gn1pU9HEx49iCurGpmgaWXDtm7BkJW6S/tYOQyiaOHf18JGb9ZToMorQUjQ9E3TlnbXnTwSMQkZh0T8Vn3Q/gVx1ttsieRRURM8rrt8fo7rWF4AY5H/iZdB8gw=; Message-ID: <285609.93285.qm@web63905.mail.re1.yahoo.com> X-YMail-OSG: gij5o1UVM1lzRG8gVAaaUNxp3xadsgQUJN.nojqhcngdwy62Pj3h5xaSsIR6G95wkoa0XOBXRu1Ns7wzPmjAiBNJwJzAcmIXl32ucZGYct7Qm3FZcSIQTNJcVnOFiPtR9xpH46saIBlwQABiW4cDkoe4m97TXfJTsQRPgzsBqIFMqQiGmLiARAkkfDFK386GbpFfHlfWL9MecYgqwk99lVDllZSUpfkQ_Yy0FvM2I5VtY_jM0s_ixSmr_DCABk6lb2vpHeGo0YhGQhEWmdp6UF0- Received: from [98.242.222.229] by web63905.mail.re1.yahoo.com via HTTP; Mon, 30 Mar 2009 09:34:33 PDT X-Mailer: YahooMailWebService/0.7.289.1 Date: Mon, 30 Mar 2009 09:34:33 -0700 (PDT) From: Barney Cordoba To: freebsd-current@FreeBSD.org, John Baldwin In-Reply-To: <200903301100.57757.jhb@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Subject: Re: cpuset affinity control from within the kernel X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: barney_cordoba@yahoo.com List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Mar 2009 16:34:34 -0000 --- On Mon, 3/30/09, John Baldwin wrote: > From: John Baldwin > Subject: Re: cpuset affinity control from within the kernel > To: freebsd-current@FreeBSD.org, barney_cordoba@yahoo.com > Date: Monday, March 30, 2009, 11:00 AM > On Sunday 29 March 2009 3:59:40 pm Barney Cordoba wrote: > > > > What tools are available for taskqueues, interrupts, > etc from within the > kernel? > > You can use BUS_BIND_INTR() for interrupts. You can use > 'sched_bind() / > sched_unbind()' in thread contexts. For example, to > pin taskqueue threads > (you should only do this for a private taskqueue you create > though) you can > simply enqueue a task to the thread that does a > 'sched_bind()'. > > -- > John Baldwin There doesn't seem to be a man page for those functions. Are there some docs somewhere? Can I bind to a set of cores as can be done with cpuset? Barney From owner-freebsd-current@FreeBSD.ORG Mon Mar 30 16:46: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 B80C4106564A for ; Mon, 30 Mar 2009 16:46:00 +0000 (UTC) (envelope-from Thomas.Sparrevohn@btinternet.com) Received: from smtp802.mail.ird.yahoo.com (smtp802.mail.ird.yahoo.com [217.146.188.62]) by mx1.freebsd.org (Postfix) with SMTP id 5E45C8FC16 for ; Mon, 30 Mar 2009 16:45:59 +0000 (UTC) (envelope-from Thomas.Sparrevohn@btinternet.com) Received: (qmail 42734 invoked from network); 30 Mar 2009 16:45:58 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=btinternet.com; h=Received:X-YMail-OSG:X-Yahoo-Newman-Property:From:To:Subject:Date:User-Agent:Cc:References:In-Reply-To:MIME-Version:Content-Type:Message-Id; b=xuFbG9bZSQSYhsNRvBGkWugTriKWebMjZRXl/lLs8KIl4OCggjaWeXknrCYT+7iIOL8xyh63Y8SD2NfK/Bu/rnRXHK2dCKppQOdzo+bfxP+FW01IraUeedvKOeAyX9a2XawYqD5hLWz/50Zu7OFiEH5n+okp3JFsa1JbX0EP60I= ; Received: from unknown (HELO w2fzz0vc03.aah-go-on.com) (Thomas.Sparrevohn@86.133.213.130 with login) by smtp802.mail.ird.yahoo.com with SMTP; 30 Mar 2009 16:45:53 -0000 X-YMail-OSG: 59SPwrsVM1m33fPaOd0CRoBRQ1THWIaCezH9q_5XpXtrUM6LORc_w8HXy0TftA5N8M4hiXRVIs51Pu6PUAT.zYPTu1tr_aRVE.vNJdxDpPPQg3QG7JB26xXJ9uX0jjG6jBtf.._XsE71l3ITCdAo7WqVbgnMMdofabC3sV5lWuyKBIGsBeHNTNo2pDp03MCpMx1FSC9AJPXEqjJtR.8hmWKTW2Rc0qBEeYlJ X-Yahoo-Newman-Property: ymail-3 From: Thomas Sparrevohn To: freebsd-current@freebsd.org Date: Mon, 30 Mar 2009 17:45:45 +0100 User-Agent: KMail/1.9.10 References: <49BD117B.2080706@163.com> <20090325090456.G92412@rust.salford.ac.uk> <49C9FC53.8070104@163.com> In-Reply-To: <49C9FC53.8070104@163.com> MIME-Version: 1.0 Content-Type: Multipart/Mixed; boundary="Boundary-00=_6cP0JlXZdTed/wM" Message-Id: <200903301745.46149.Thomas.Sparrevohn@btinternet.com> Cc: kevin , Mark Powell Subject: Re: ZFS data error without reasons 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, 30 Mar 2009 16:46:01 -0000 --Boundary-00=_6cP0JlXZdTed/wM Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Wednesday 25 March 2009 09:41:39 kevin wrote: > Mark Powell wrote: > > Kevin, > > Did you fix your ZFS CRC errors? > > I responded to your thread, but no-one got back to me. > > I'm gonna start another thread later. > > This time I re-made the zpool in 8 compatible with 7. Once the errors=20 > > started showing up in 8 I moved back to 7, on the same hardware, to=20 > > perform the scrub to prove the problem is with 8. The 1st scrub in 7=20 > > found some errors, but of course it would if 8 had messed up the data.= =20 > > Removed the few unimportant bad files (all were in snapshots). > > Just performing the 2nd scrub in 7 now. If this comes back with no=20 > > errors, then we have stronger proof that there is some wrong, which=20 > > seems quite intermittent, in 8 that randomly writes bad data. > > Cheers. > > > Yes=EF=BC=8CI can fix some ZFS CRC errors,and sometimes i can recover all= error=20 > files.Before i run "zpool import backup" to mount the zpool on a usb=20 > hard disk, "zpool status" return no errors. When i copy files to the usb= =20 > hard disk,soon I can get lots of file errors.After a reboot,if i run=20 > scrub,i can fix many errors. I just think copy files between two zpools,= =20 > one is on local hard disk and the other one is on a usb hard disk, may=20 > easily reproduce the bug. I have not been folloing the entire thread - but I can reproduce ZFS CRC co= rruption on the current kernel just by unpluging a USB disk drive - The is no errors on th= e disks - revert to and old kernel=20 FreeBSD w2fzz0vc03.aah-go-on.com 8.0-CURRENT FreeBSD 8.0-CURRENT #1 r18945= 4M: Fri Mar 6 18:46:25 GMT 2009 root@w2fzz0vc03.aah-go-on.com:/usr/obj= /usr/src/sys/GENERIC amd64 the problem can be solved - The weird thing is that it will give CRC errros= (and permenent errors) in blocks that has not been touched (or at least I = think so)=20 I suspect that It may have to do with the USB DMA bounce buffer as an examp= le see the message file included --Boundary-00=_6cP0JlXZdTed/wM Content-Type: text/plain; charset="iso 8859-15"; name="messages.error" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="messages.error" Mar 26 10:00:02 w2fzz0vc03 newsyslog[6294]: logfile turned over due to size>100K Mar 26 10:26:46 w2fzz0vc03 shutdown: reboot by root: Mar 26 10:26:53 w2fzz0vc03 mDNSResponder (Engineering Build) (Mar 15 2009 06:30:34) [1259]: stopping Mar 26 10:26:53 w2fzz0vc03 kernel: rum0: need multicast update callback Mar 26 10:26:54 w2fzz0vc03 kernel: rum0: need multicast update callback Mar 26 10:26:55 w2fzz0vc03 syslogd: exiting on signal 15 Mar 26 10:28:19 w2fzz0vc03 syslogd: kernel boot file is /boot/kernel/kernel Mar 26 10:28:19 w2fzz0vc03 kernel: Copyright (c) 1992-2009 The FreeBSD Project. Mar 26 10:28:19 w2fzz0vc03 kernel: Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 Mar 26 10:28:19 w2fzz0vc03 kernel: The Regents of the University of California. All rights reserved. Mar 26 10:28:19 w2fzz0vc03 kernel: FreeBSD is a registered trademark of The FreeBSD Foundation. Mar 26 10:28:19 w2fzz0vc03 kernel: FreeBSD 8.0-CURRENT #3 r190437: Thu Mar 26 09:06:51 GMT 2009 Mar 26 10:28:19 w2fzz0vc03 kernel: root@w2fzz0vc03.aah-go-on.com:/usr/obj/usr/src/sys/GENERIC Mar 26 10:28:19 w2fzz0vc03 kernel: WARNING: WITNESS option enabled, expect reduced performance. Mar 26 10:28:19 w2fzz0vc03 kernel: Timecounter "i8254" frequency 1193182 Hz quality 0 Mar 26 10:28:19 w2fzz0vc03 kernel: CPU: Intel(R) Core(TM)2 Quad CPU @ 2.66GHz (2660.04-MHz K8-class CPU) Mar 26 10:28:19 w2fzz0vc03 kernel: Origin = "GenuineIntel" Id = 0x6f7 Stepping = 7 Mar 26 10:28:19 w2fzz0vc03 kernel: Features=0xbfebfbff Mar 26 10:28:19 w2fzz0vc03 kernel: Features2=0xe3bd Mar 26 10:28:19 w2fzz0vc03 kernel: AMD Features=0x20100800 Mar 26 10:28:19 w2fzz0vc03 kernel: AMD Features2=0x1 Mar 26 10:28:19 w2fzz0vc03 kernel: TSC: P-state invariant Mar 26 10:28:19 w2fzz0vc03 kernel: Cores per package: 4 Mar 26 10:28:19 w2fzz0vc03 kernel: usable memory = 4275347456 (4077 MB) Mar 26 10:28:19 w2fzz0vc03 kernel: avail memory = 4090109952 (3900 MB) Mar 26 10:28:19 w2fzz0vc03 kernel: ACPI APIC Table: Mar 26 10:28:19 w2fzz0vc03 kernel: FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs Mar 26 10:28:19 w2fzz0vc03 kernel: cpu0 (BSP): APIC ID: 0 Mar 26 10:28:19 w2fzz0vc03 kernel: cpu1 (AP): APIC ID: 1 Mar 26 10:28:19 w2fzz0vc03 kernel: cpu2 (AP): APIC ID: 2 Mar 26 10:28:19 w2fzz0vc03 kernel: cpu3 (AP): APIC ID: 3 Mar 26 10:28:19 w2fzz0vc03 kernel: This module (opensolaris) contains code covered by the Mar 26 10:28:19 w2fzz0vc03 kernel: Common Development and Distribution License (CDDL) Mar 26 10:28:19 w2fzz0vc03 kernel: see http://opensolaris.org/os/licensing/opensolaris_license/ Mar 26 10:28:19 w2fzz0vc03 kernel: ioapic0: Changing APIC ID to 8 Mar 26 10:28:19 w2fzz0vc03 kernel: ioapic0 irqs 0-23 on motherboard Mar 26 10:28:19 w2fzz0vc03 kernel: lapic0: Forcing LINT1 to edge trigger Mar 26 10:28:19 w2fzz0vc03 kernel: kbd1 at kbdmux0 Mar 26 10:28:19 w2fzz0vc03 kernel: acpi0: on motherboard Mar 26 10:28:19 w2fzz0vc03 kernel: acpi0: [ITHREAD] Mar 26 10:28:19 w2fzz0vc03 kernel: acpi0: Power Button (fixed) Mar 26 10:28:19 w2fzz0vc03 kernel: acpi0: reservation of 0, a0000 (3) failed Mar 26 10:28:19 w2fzz0vc03 kernel: acpi0: reservation of 100000, f00000 (3) failed Mar 26 10:28:19 w2fzz0vc03 kernel: acpi0: reservation of 1000000, 9edbcc00 (3) failed Mar 26 10:28:19 w2fzz0vc03 kernel: Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 Mar 26 10:28:19 w2fzz0vc03 kernel: acpi_timer0: <24-bit timer at 3.579545MHz> port 0x4008-0x400b on acpi0 Mar 26 10:28:19 w2fzz0vc03 kernel: acpi_hpet0: iomem 0xfed00000-0xfed003ff on acpi0 Mar 26 10:28:19 w2fzz0vc03 kernel: Timecounter "HPET" frequency 25000000 Hz quality 900 Mar 26 10:28:19 w2fzz0vc03 kernel: acpi_button0: on acpi0 Mar 26 10:28:19 w2fzz0vc03 kernel: pcib0: port 0xcf8-0xcff on acpi0 Mar 26 10:28:19 w2fzz0vc03 kernel: pci0: on pcib0 Mar 26 10:28:19 w2fzz0vc03 kernel: pci0: at device 0.1 (no driver attached) Mar 26 10:28:19 w2fzz0vc03 kernel: pci0: at device 0.2 (no driver attached) Mar 26 10:28:19 w2fzz0vc03 kernel: pci0: at device 0.3 (no driver attached) Mar 26 10:28:19 w2fzz0vc03 kernel: pci0: at device 0.4 (no driver attached) Mar 26 10:28:19 w2fzz0vc03 kernel: pci0: at device 1.0 (no driver attached) Mar 26 10:28:19 w2fzz0vc03 kernel: pci0: at device 1.1 (no driver attached) Mar 26 10:28:19 w2fzz0vc03 kernel: pci0: at device 1.2 (no driver attached) Mar 26 10:28:19 w2fzz0vc03 kernel: pci0: at device 1.3 (no driver attached) Mar 26 10:28:19 w2fzz0vc03 kernel: pci0: at device 1.4 (no driver attached) Mar 26 10:28:19 w2fzz0vc03 kernel: pci0: at device 1.5 (no driver attached) Mar 26 10:28:19 w2fzz0vc03 kernel: pci0: at device 1.6 (no driver attached) Mar 26 10:28:19 w2fzz0vc03 kernel: pcib1: at device 2.0 on pci0 Mar 26 10:28:19 w2fzz0vc03 kernel: pci1: on pcib1 Mar 26 10:28:19 w2fzz0vc03 kernel: vgapci0: port 0xdc80-0xdcff mem 0xde000000-0xdeffffff,0xa0000000-0xafffffff,0xdc000000-0xddffffff irq 16 at device 0.0 on pci1 Mar 26 10:28:19 w2fzz0vc03 kernel: pcib2: at device 4.0 on pci0 Mar 26 10:28:19 w2fzz0vc03 kernel: pci2: on pcib2 Mar 26 10:28:19 w2fzz0vc03 kernel: pcib3: at device 5.0 on pci0 Mar 26 10:28:19 w2fzz0vc03 kernel: pci3: on pcib3 Mar 26 10:28:19 w2fzz0vc03 kernel: pci0: at device 9.0 (no driver attached) Mar 26 10:28:19 w2fzz0vc03 kernel: isab0: port 0x4f00-0x4fff at device 10.0 on pci0 Mar 26 10:28:19 w2fzz0vc03 kernel: isa0: on isab0 Mar 26 10:28:19 w2fzz0vc03 kernel: pci0: at device 10.1 (no driver attached) Mar 26 10:28:19 w2fzz0vc03 kernel: ohci0: mem 0xdfffc000-0xdfffcfff irq 21 at device 11.0 on pci0 Mar 26 10:28:19 w2fzz0vc03 kernel: ohci0: [ITHREAD] Mar 26 10:28:19 w2fzz0vc03 kernel: usbus0: on ohci0 Mar 26 10:28:19 w2fzz0vc03 kernel: ehci0: mem 0xdfffbf00-0xdfffbfff irq 22 at device 11.1 on pci0 Mar 26 10:28:19 w2fzz0vc03 kernel: ehci0: [ITHREAD] Mar 26 10:28:19 w2fzz0vc03 kernel: usbus1: waiting for BIOS to give up control Mar 26 10:28:19 w2fzz0vc03 kernel: usbus1: EHCI version 1.0 Mar 26 10:28:19 w2fzz0vc03 kernel: usbus1: on ehci0 Mar 26 10:28:19 w2fzz0vc03 kernel: atapci0: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xecf0-0xecff at device 13.0 on pci0 Mar 26 10:28:19 w2fzz0vc03 kernel: ata0: on atapci0 Mar 26 10:28:19 w2fzz0vc03 kernel: ata0: [ITHREAD] Mar 26 10:28:19 w2fzz0vc03 kernel: ata1: on atapci0 Mar 26 10:28:19 w2fzz0vc03 kernel: ata1: [ITHREAD] Mar 26 10:28:19 w2fzz0vc03 kernel: atapci1: port 0xfe00-0xfe07,0xfe10-0xfe13,0xfe20-0xfe27,0xfe30-0xfe33,0xfec0-0xfecf mem 0xdfffd000-0xdfffdfff irq 23 at device 14.0 on pci0 Mar 26 10:28:19 w2fzz0vc03 kernel: atapci1: [ITHREAD] Mar 26 10:28:19 w2fzz0vc03 kernel: ata2: on atapci1 Mar 26 10:28:19 w2fzz0vc03 kernel: ata2: [ITHREAD] Mar 26 10:28:19 w2fzz0vc03 kernel: ata3: on atapci1 Mar 26 10:28:19 w2fzz0vc03 kernel: ata3: [ITHREAD] Mar 26 10:28:19 w2fzz0vc03 kernel: atapci2: port 0xfe40-0xfe47,0xfe50-0xfe53,0xfe60-0xfe67,0xfe70-0xfe73,0xfed0-0xfedf mem 0xdfffe000-0xdfffefff irq 20 at device 14.1 on pci0 Mar 26 10:28:19 w2fzz0vc03 kernel: atapci2: [ITHREAD] Mar 26 10:28:19 w2fzz0vc03 kernel: ata4: on atapci2 Mar 26 10:28:19 w2fzz0vc03 kernel: ata4: [ITHREAD] Mar 26 10:28:19 w2fzz0vc03 kernel: ata5: on atapci2 Mar 26 10:28:19 w2fzz0vc03 kernel: ata5: [ITHREAD] Mar 26 10:28:19 w2fzz0vc03 kernel: atapci3: port 0xfe80-0xfe87,0xfe90-0xfe93,0xfea0-0xfea7,0xfeb0-0xfeb3,0xfef0-0xfeff mem 0xdffff000-0xdfffffff irq 21 at device 14.2 on pci0 Mar 26 10:28:19 w2fzz0vc03 kernel: atapci3: [ITHREAD] Mar 26 10:28:19 w2fzz0vc03 kernel: ata6: on atapci3 Mar 26 10:28:19 w2fzz0vc03 kernel: ata6: [ITHREAD] Mar 26 10:28:19 w2fzz0vc03 kernel: ata7: on atapci3 Mar 26 10:28:19 w2fzz0vc03 kernel: ata7: [ITHREAD] Mar 26 10:28:19 w2fzz0vc03 kernel: pcib4: at device 15.0 on pci0 Mar 26 10:28:19 w2fzz0vc03 kernel: pci4: on pcib4 Mar 26 10:28:19 w2fzz0vc03 kernel: pci4: at device 4.0 (no driver attached) Mar 26 10:28:19 w2fzz0vc03 kernel: pci4: at device 5.0 (no driver attached) Mar 26 10:28:19 w2fzz0vc03 kernel: fwohci0: mem 0xdadfb800-0xdadfbfff,0xdadfc000-0xdadfffff irq 18 at device 10.0 on pci4 Mar 26 10:28:19 w2fzz0vc03 kernel: fwohci0: [ITHREAD] Mar 26 10:28:19 w2fzz0vc03 kernel: fwohci0: OHCI version 1.10 (ROM=0) Mar 26 10:28:19 w2fzz0vc03 kernel: fwohci0: No. of Isochronous channels is 4. Mar 26 10:28:19 w2fzz0vc03 kernel: fwohci0: EUI64 80:00:00:00:00:00:00:00 Mar 26 10:28:19 w2fzz0vc03 kernel: fwohci0: Phy 1394a available S400, 2 ports. Mar 26 10:28:19 w2fzz0vc03 kernel: fwohci0: Link S400, max_rec 2048 bytes. Mar 26 10:28:19 w2fzz0vc03 kernel: firewire0: on fwohci0 Mar 26 10:28:19 w2fzz0vc03 kernel: dcons_crom0: on firewire0 Mar 26 10:28:19 w2fzz0vc03 kernel: dcons_crom0: bus_addr 0x113c000 Mar 26 10:28:19 w2fzz0vc03 kernel: fwe0: on firewire0 Mar 26 10:28:19 w2fzz0vc03 kernel: if_fwe0: Fake Ethernet address: 82:00:00:00:00:00 Mar 26 10:28:19 w2fzz0vc03 kernel: fwe0: Ethernet address: 82:00:00:00:00:00 Mar 26 10:28:19 w2fzz0vc03 kernel: fwip0: on firewire0 Mar 26 10:28:19 w2fzz0vc03 kernel: fwip0: Firewire address: 80:00:00:00:00:00:00:00 @ 0xfffe00000000, S400, maxrec 2048 Mar 26 10:28:19 w2fzz0vc03 kernel: sbp0: on firewire0 Mar 26 10:28:19 w2fzz0vc03 kernel: fwohci0: Initiate bus reset Mar 26 10:28:19 w2fzz0vc03 kernel: fwohci0: fwohci_intr_core: BUS reset Mar 26 10:28:19 w2fzz0vc03 kernel: fwohci0: fwohci_intr_core: node_id=0x00000000, SelfID Count=1, CYCLEMASTER mode Mar 26 10:28:19 w2fzz0vc03 kernel: pcib5: at device 19.0 on pci0 Mar 26 10:28:19 w2fzz0vc03 kernel: pci5: on pcib5 Mar 26 10:28:19 w2fzz0vc03 kernel: pcib6: at device 24.0 on pci0 Mar 26 10:28:19 w2fzz0vc03 kernel: pci6: on pcib6 Mar 26 10:28:19 w2fzz0vc03 kernel: vgapci1: port 0xbc80-0xbcff mem 0xd1000000-0xd1ffffff,0xc0000000-0xcfffffff,0xd2000000-0xd3ffffff irq 16 at device 0.0 on pci6 Mar 26 10:28:19 w2fzz0vc03 kernel: atrtc0: port 0x70-0x7f irq 8 on acpi0 Mar 26 10:28:19 w2fzz0vc03 kernel: atkbdc0: port 0x60,0x64 irq 1 on acpi0 Mar 26 10:28:19 w2fzz0vc03 kernel: atkbd0: irq 1 on atkbdc0 Mar 26 10:28:19 w2fzz0vc03 kernel: kbd0 at atkbd0 Mar 26 10:28:19 w2fzz0vc03 kernel: atkbd0: [GIANT-LOCKED] Mar 26 10:28:19 w2fzz0vc03 kernel: atkbd0: [ITHREAD] Mar 26 10:28:19 w2fzz0vc03 kernel: psm0: irq 12 on atkbdc0 Mar 26 10:28:19 w2fzz0vc03 kernel: psm0: [GIANT-LOCKED] Mar 26 10:28:19 w2fzz0vc03 kernel: psm0: [ITHREAD] Mar 26 10:28:19 w2fzz0vc03 kernel: psm0: model MouseMan+, device ID 0 Mar 26 10:28:19 w2fzz0vc03 kernel: uart0: <16550 or compatible> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 Mar 26 10:28:19 w2fzz0vc03 kernel: uart0: [FILTER] Mar 26 10:28:19 w2fzz0vc03 kernel: cpu0: on acpi0 Mar 26 10:28:19 w2fzz0vc03 kernel: est0: on cpu0 Mar 26 10:28:19 w2fzz0vc03 kernel: est: CPU supports Enhanced Speedstep, but is not recognized. Mar 26 10:28:19 w2fzz0vc03 kernel: est: cpu_vendor GenuineIntel, msr a2a0a2a86000a2a Mar 26 10:28:19 w2fzz0vc03 kernel: device_attach: est0 attach returned 6 Mar 26 10:28:19 w2fzz0vc03 kernel: p4tcc0: on cpu0 Mar 26 10:28:19 w2fzz0vc03 kernel: cpu1: on acpi0 Mar 26 10:28:19 w2fzz0vc03 kernel: est1: on cpu1 Mar 26 10:28:19 w2fzz0vc03 kernel: est: CPU supports Enhanced Speedstep, but is not recognized. Mar 26 10:28:19 w2fzz0vc03 kernel: est: cpu_vendor GenuineIntel, msr a2a0a2a86000a2a Mar 26 10:28:19 w2fzz0vc03 kernel: device_attach: est1 attach returned 6 Mar 26 10:28:19 w2fzz0vc03 kernel: p4tcc1: on cpu1 Mar 26 10:28:19 w2fzz0vc03 kernel: cpu2: on acpi0 Mar 26 10:28:19 w2fzz0vc03 kernel: est2: on cpu2 Mar 26 10:28:19 w2fzz0vc03 kernel: est: CPU supports Enhanced Speedstep, but is not recognized. Mar 26 10:28:19 w2fzz0vc03 kernel: est: cpu_vendor GenuineIntel, msr a2a0a2a86000a2a Mar 26 10:28:19 w2fzz0vc03 kernel: device_attach: est2 attach returned 6 Mar 26 10:28:19 w2fzz0vc03 kernel: p4tcc2: on cpu2 Mar 26 10:28:19 w2fzz0vc03 kernel: cpu3: on acpi0 Mar 26 10:28:19 w2fzz0vc03 kernel: est3: on cpu3 Mar 26 10:28:19 w2fzz0vc03 kernel: est: CPU supports Enhanced Speedstep, but is not recognized. Mar 26 10:28:19 w2fzz0vc03 kernel: est: cpu_vendor GenuineIntel, msr a2a0a2a86000a2a Mar 26 10:28:19 w2fzz0vc03 kernel: device_attach: est3 attach returned 6 Mar 26 10:28:19 w2fzz0vc03 kernel: p4tcc3: on cpu3 Mar 26 10:28:19 w2fzz0vc03 kernel: orm0: at iomem 0xc0000-0xcc7ff,0xcc800-0xce7ff,0xce800-0xcffff on isa0 Mar 26 10:28:19 w2fzz0vc03 kernel: sc0: at flags 0x100 on isa0 Mar 26 10:28:19 w2fzz0vc03 kernel: sc0: VGA <16 virtual consoles, flags=0x300> Mar 26 10:28:19 w2fzz0vc03 kernel: vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 Mar 26 10:28:19 w2fzz0vc03 kernel: ppc0: cannot reserve I/O port range Mar 26 10:28:19 w2fzz0vc03 kernel: WARNING: ZFS is considered to be an experimental feature in FreeBSD. Mar 26 10:28:19 w2fzz0vc03 kernel: Timecounters tick every 1.000 msec Mar 26 10:28:19 w2fzz0vc03 kernel: firewire0: 1 nodes, maxhop <= 0 cable IRM irm(0) (me) Mar 26 10:28:19 w2fzz0vc03 kernel: firewire0: bus manager 0 Mar 26 10:28:19 w2fzz0vc03 kernel: usbus0: 12Mbps Full Speed USB v1.0 Mar 26 10:28:19 w2fzz0vc03 kernel: usbus1: 480Mbps High Speed USB v2.0 Mar 26 10:28:19 w2fzz0vc03 kernel: ZFS filesystem version 13 Mar 26 10:28:19 w2fzz0vc03 kernel: ZFS storage pool version 13 Mar 26 10:28:19 w2fzz0vc03 kernel: ugen0.1: at usbus0 Mar 26 10:28:19 w2fzz0vc03 kernel: uhub0: on usbus0 Mar 26 10:28:19 w2fzz0vc03 kernel: ugen1.1: at usbus1 Mar 26 10:28:19 w2fzz0vc03 kernel: uhub1: on usbus1 Mar 26 10:28:19 w2fzz0vc03 kernel: ad4: 305245MB at ata2-master SATA300 Mar 26 10:28:19 w2fzz0vc03 kernel: GEOM: ad4s1: geometry does not match label (255h,63s != 16h,63s). Mar 26 10:28:19 w2fzz0vc03 kernel: ad6: 305245MB at ata3-master SATA300 Mar 26 10:28:19 w2fzz0vc03 kernel: acd0: CDRW at ata4-master SATA150 Mar 26 10:28:19 w2fzz0vc03 kernel: acd1: DVDR at ata5-master SATA150 Mar 26 10:28:19 w2fzz0vc03 kernel: GEOM_LABEL: Label for provider ad4s2 is ntfs/System. Mar 26 10:28:19 w2fzz0vc03 kernel: ad12: 305245MB at ata6-master SATA300 Mar 26 10:28:19 w2fzz0vc03 kernel: ad14: 305245MB at ata7-master SATA300 Mar 26 10:28:19 w2fzz0vc03 kernel: GEOM_LABEL: Label for provider ad12s1a is ufsid/48f26dd9908a0f3d. Mar 26 10:28:19 w2fzz0vc03 kernel: uhub0: 10 ports with 10 removable, self powered Mar 26 10:28:19 w2fzz0vc03 kernel: uhub1: 10 ports with 10 removable, self powered Mar 26 10:28:19 w2fzz0vc03 kernel: lapic1: Forcing LINT1 to edge trigger Mar 26 10:28:19 w2fzz0vc03 kernel: SMP: AP CPU #1 Launched! Mar 26 10:28:19 w2fzz0vc03 kernel: lapic3: Forcing LINT1 to edge trigger Mar 26 10:28:19 w2fzz0vc03 kernel: SMP: AP CPU #3 Launched! Mar 26 10:28:19 w2fzz0vc03 kernel: lapic2: Forcing LINT1 to edge trigger Mar 26 10:28:19 w2fzz0vc03 kernel: SMP: AP CPU #2 Launched! Mar 26 10:28:19 w2fzz0vc03 kernel: WARNING: WITNESS option enabled, expect reduced performance. Mar 26 10:28:19 w2fzz0vc03 kernel: Root mount waiting for: usbus1 Mar 26 10:28:19 w2fzz0vc03 kernel: ugen1.2: at usbus1 Mar 26 10:28:19 w2fzz0vc03 kernel: Root mount waiting for: usbus1 Mar 26 10:28:19 w2fzz0vc03 kernel: ugen1.3: at usbus1 Mar 26 10:28:19 w2fzz0vc03 kernel: uhub2: on usbus1 Mar 26 10:28:19 w2fzz0vc03 kernel: uhub2: 7 ports with 7 removable, self powered Mar 26 10:28:19 w2fzz0vc03 kernel: Root mount waiting for: usbus1 Mar 26 10:28:19 w2fzz0vc03 kernel: ugen1.4: at usbus1 Mar 26 10:28:19 w2fzz0vc03 kernel: umass0: on usbus1 Mar 26 10:28:19 w2fzz0vc03 kernel: umass0: SCSI over Bulk-Only; quirks = 0x0000 Mar 26 10:28:19 w2fzz0vc03 kernel: Root mount waiting for: usbus1 Mar 26 10:28:19 w2fzz0vc03 kernel: umass0:1:0:-1: Attached to scbus1 Mar 26 10:28:19 w2fzz0vc03 kernel: da0 at umass-sim0 bus 0 target 0 lun 0 Mar 26 10:28:19 w2fzz0vc03 kernel: da0: Fixed Direct Access SCSI-4 device Mar 26 10:28:19 w2fzz0vc03 kernel: da0: 40.000MB/s transfers Mar 26 10:28:19 w2fzz0vc03 kernel: da0: 476940MB (976773168 512 byte sectors: 255H 63S/T 60801C) Mar 26 10:28:19 w2fzz0vc03 kernel: GEOM: da0: partition 1 does not start on a track boundary. Mar 26 10:28:19 w2fzz0vc03 kernel: GEOM: da0: partition 1 does not end on a track boundary. Mar 26 10:28:19 w2fzz0vc03 kernel: GEOM_LABEL: Label for provider da0s1 is ntfs/Backup. Mar 26 10:28:19 w2fzz0vc03 kernel: Root mount waiting for: usbus1 Mar 26 10:28:19 w2fzz0vc03 kernel: ugen0.2: at usbus0 Mar 26 10:28:19 w2fzz0vc03 kernel: ugen1.5: at usbus1 Mar 26 10:28:19 w2fzz0vc03 kernel: umass1: on usbus1 Mar 26 10:28:19 w2fzz0vc03 kernel: umass1: SCSI over Bulk-Only; quirks = 0x0000 Mar 26 10:28:19 w2fzz0vc03 kernel: Root mount waiting for: usbus1 Mar 26 10:28:19 w2fzz0vc03 kernel: umass1:2:1:-1: Attached to scbus2 Mar 26 10:28:19 w2fzz0vc03 kernel: da1 at umass-sim1 bus 1 target 0 lun 0 Mar 26 10:28:19 w2fzz0vc03 kernel: da1: Removable Direct Access SCSI-2 device Mar 26 10:28:19 w2fzz0vc03 kernel: da1: 40.000MB/s transfers Mar 26 10:28:19 w2fzz0vc03 kernel: da1: 210MB (430848 512 byte sectors: 64H 32S/T 210C) Mar 26 10:28:19 w2fzz0vc03 kernel: (probe0:umass-sim1:1:0:1): TEST UNIT READY. CDB: 0 20 0 0 0 0 Mar 26 10:28:19 w2fzz0vc03 kernel: (probe0:umass-sim1:1:0:1): CAM Status: SCSI Status Error Mar 26 10:28:19 w2fzz0vc03 kernel: (probe0:umass-sim1:1:0:1): SCSI Status: Check Condition Mar 26 10:28:19 w2fzz0vc03 kernel: (probe0:umass-sim1:1:0:1): NOT READY asc:3a,0 Mar 26 10:28:19 w2fzz0vc03 kernel: (probe0:umass-sim1:1:0:1): Medium not present Mar 26 10:28:19 w2fzz0vc03 kernel: (probe0:umass-sim1:1:0:1): Unretryable error Mar 26 10:28:19 w2fzz0vc03 kernel: da2 at umass-sim1 bus 1 target 0 lun 1 Mar 26 10:28:19 w2fzz0vc03 kernel: da2: Removable Direct Access SCSI-2 device Mar 26 10:28:19 w2fzz0vc03 kernel: da2: 40.000MB/s transfers Mar 26 10:28:19 w2fzz0vc03 kernel: da2: Attempt to query device size failed: NOT READY, Medium not present Mar 26 10:28:19 w2fzz0vc03 kernel: (probe0:umass-sim1:1:0:2): TEST UNIT READY. CDB: 0 40 0 0 0 0 Mar 26 10:28:19 w2fzz0vc03 kernel: (probe0:umass-sim1:1:0:2): CAM Status: SCSI Status Error Mar 26 10:28:19 w2fzz0vc03 kernel: (probe0:umass-sim1:1:0:2): SCSI Status: Check Condition Mar 26 10:28:19 w2fzz0vc03 kernel: (probe0:umass-sim1:1:0:2): NOT READY asc:3a,0 Mar 26 10:28:19 w2fzz0vc03 kernel: (probe0:umass-sim1:1:0:2): Medium not present Mar 26 10:28:19 w2fzz0vc03 kernel: (probe0:umass-sim1:1:0:2): Unretryable error Mar 26 10:28:19 w2fzz0vc03 kernel: da3 at umass-sim1 bus 1 target 0 lun 2 Mar 26 10:28:19 w2fzz0vc03 kernel: da3: Removable Direct Access SCSI-2 device Mar 26 10:28:19 w2fzz0vc03 kernel: da3: 40.000MB/s transfers Mar 26 10:28:19 w2fzz0vc03 kernel: da3: 3886MB (7959552 512 byte sectors: 255H 63S/T 495C) Mar 26 10:28:19 w2fzz0vc03 kernel: GEOM_LABEL: Label for provider da1 is msdosfs/ . Mar 26 10:28:19 w2fzz0vc03 kernel: ugen1.6: at usbus1 Mar 26 10:28:19 w2fzz0vc03 kernel: rum0: on usbus1 Mar 26 10:28:19 w2fzz0vc03 kernel: Root mount waiting for: usbus1 Mar 26 10:28:19 w2fzz0vc03 kernel: rum0: MAC/BBP RT2573 (rev 0x2573a), RF RT2528 Mar 26 10:28:19 w2fzz0vc03 kernel: ugen1.7: at usbus1 Mar 26 10:28:19 w2fzz0vc03 kernel: umass2: on usbus1 Mar 26 10:28:19 w2fzz0vc03 kernel: umass2: SCSI over Bulk-Only; quirks = 0x0000 Mar 26 10:28:19 w2fzz0vc03 kernel: Root mount waiting for: usbus1 Mar 26 10:28:19 w2fzz0vc03 kernel: umass2:3:2:-1: Attached to scbus3 Mar 26 10:28:19 w2fzz0vc03 kernel: Trying to mount root from zfs:pool Mar 26 10:28:19 w2fzz0vc03 kernel: (probe0:umass-sim2:2:0:0): TEST UNIT READY. CDB: 0 0 0 0 0 0 Mar 26 10:28:19 w2fzz0vc03 kernel: (probe0:umass-sim2:2:0:0): CAM Status: SCSI Status Error Mar 26 10:28:19 w2fzz0vc03 kernel: (probe0:umass-sim2:2:0:0): SCSI Status: Check Condition Mar 26 10:28:19 w2fzz0vc03 kernel: (probe0:umass-sim2:2:0:0): NOT READY asc:3a,0 Mar 26 10:28:19 w2fzz0vc03 kernel: (probe0:umass-sim2:2:0:0): Medium not present Mar 26 10:28:19 w2fzz0vc03 kernel: (probe0:umass-sim2:2:0:0): Unretryable error Mar 26 10:28:19 w2fzz0vc03 kernel: da4 at umass-sim2 bus 2 target 0 lun 0 Mar 26 10:28:19 w2fzz0vc03 kernel: da4: Removable Direct Access SCSI-0 device Mar 26 10:28:19 w2fzz0vc03 kernel: da4: 40.000MB/s transfers Mar 26 10:28:19 w2fzz0vc03 kernel: da4: Attempt to query device size failed: NOT READY, Medium not present Mar 26 10:28:19 w2fzz0vc03 kernel: (probe0:umass-sim2:2:0:1): TEST UNIT READY. CDB: 0 20 0 0 0 0 Mar 26 10:28:19 w2fzz0vc03 kernel: (probe0:umass-sim2:2:0:1): CAM Status: SCSI Status Error Mar 26 10:28:19 w2fzz0vc03 kernel: (probe0:umass-sim2:2:0:1): SCSI Status: Check Condition Mar 26 10:28:19 w2fzz0vc03 kernel: (probe0:umass-sim2:2:0:1): NOT READY asc:3a,0 Mar 26 10:28:19 w2fzz0vc03 kernel: (probe0:umass-sim2:2:0:1): Medium not present Mar 26 10:28:19 w2fzz0vc03 kernel: (probe0:umass-sim2:2:0:1): Unretryable error Mar 26 10:28:19 w2fzz0vc03 kernel: da5 at umass-sim2 bus 2 target 0 lun 1 Mar 26 10:28:19 w2fzz0vc03 kernel: da5: Removable Direct Access SCSI-0 device Mar 26 10:28:19 w2fzz0vc03 kernel: da5: 40.000MB/s transfers Mar 26 10:28:19 w2fzz0vc03 kernel: da5: Attempt to query device size failed: NOT READY, Medium not present Mar 26 10:28:19 w2fzz0vc03 kernel: (probe0:umass-sim2:2:0:2): TEST UNIT READY. CDB: 0 40 0 0 0 0 Mar 26 10:28:19 w2fzz0vc03 kernel: (probe0:umass-sim2:2:0:2): CAM Status: SCSI Status Error Mar 26 10:28:19 w2fzz0vc03 kernel: (probe0:umass-sim2:2:0:2): SCSI Status: Check Condition Mar 26 10:28:19 w2fzz0vc03 kernel: (probe0:umass-sim2:2:0:2): NOT READY asc:3a,0 Mar 26 10:28:19 w2fzz0vc03 kernel: (probe0:umass-sim2:2:0:2): Medium not present Mar 26 10:28:19 w2fzz0vc03 kernel: (probe0:umass-sim2:2:0:2): Unretryable error Mar 26 10:28:19 w2fzz0vc03 kernel: da6 at umass-sim2 bus 2 target 0 lun 2 Mar 26 10:28:19 w2fzz0vc03 kernel: da6: Removable Direct Access SCSI-0 device Mar 26 10:28:19 w2fzz0vc03 kernel: da6: 40.000MB/s transfers Mar 26 10:28:19 w2fzz0vc03 kernel: da6: Attempt to query device size failed: NOT READY, Medium not present Mar 26 10:28:19 w2fzz0vc03 kernel: (probe0:umass-sim2:2:0:3): TEST UNIT READY. CDB: 0 60 0 0 0 0 Mar 26 10:28:19 w2fzz0vc03 kernel: (probe0:umass-sim2:2:0:3): CAM Status: SCSI Status Error Mar 26 10:28:19 w2fzz0vc03 kernel: (probe0:umass-sim2:2:0:3): SCSI Status: Check Condition Mar 26 10:28:19 w2fzz0vc03 kernel: (probe0:umass-sim2:2:0:3): NOT READY asc:3a,0 Mar 26 10:28:19 w2fzz0vc03 kernel: (probe0:umass-sim2:2:0:3): Medium not present Mar 26 10:28:19 w2fzz0vc03 kernel: (probe0:umass-sim2:2:0:3): Unretryable error Mar 26 10:28:19 w2fzz0vc03 kernel: da7 at umass-sim2 bus 2 target 0 lun 3 Mar 26 10:28:19 w2fzz0vc03 kernel: da7: Removable Direct Access SCSI-0 device Mar 26 10:28:19 w2fzz0vc03 kernel: da7: 40.000MB/s transfers Mar 26 10:28:19 w2fzz0vc03 kernel: da7: Attempt to query device size failed: NOT READY, Medium not present Mar 26 10:28:19 w2fzz0vc03 kernel: wlan0: Ethernet address: 00:17:3f:72:40:90 Mar 26 10:28:19 w2fzz0vc03 kernel: rum0: need multicast update callback Mar 26 10:28:20 w2fzz0vc03 kernel: wlan0: link state changed to UP Mar 26 10:28:29 w2fzz0vc03 auditd[1031]: Auditing disabled Mar 26 10:28:29 w2fzz0vc03 auditd[1031]: Auditing enabled Mar 26 10:28:29 w2fzz0vc03 auditd[1031]: New audit file is /var/audit/20090326102829.not_terminated Mar 26 10:28:29 w2fzz0vc03 auditd[1031]: audit_control(5) may be missing 'host:' field Mar 26 10:28:29 w2fzz0vc03 kernel: rum0: need multicast update callback Mar 26 10:28:32 w2fzz0vc03 mDNSResponder (Engineering Build) (Mar 15 2009 06:30:34) [1259]: starting Mar 26 10:28:32 w2fzz0vc03 kernel: rum0: need multicast update callback Mar 26 10:28:37 w2fzz0vc03 kernel: (da3:umass-sim1:1:0:2): READ(10). CDB: 28 40 0 79 56 3f 0 0 4 0 Mar 26 10:28:37 w2fzz0vc03 kernel: (da3:umass-sim1:1:0:2): CAM Status: SCSI Status Error Mar 26 10:28:37 w2fzz0vc03 kernel: (da3:umass-sim1:1:0:2): SCSI Status: Check Condition Mar 26 10:28:37 w2fzz0vc03 kernel: (da3:umass-sim1:1:0:2): MEDIUM ERROR info?:79563f asc:11,0 Mar 26 10:28:37 w2fzz0vc03 kernel: (da3:umass-sim1:1:0:2): Unrecovered read error Mar 26 10:28:37 w2fzz0vc03 kernel: (da3:umass-sim1:1:0:2): Retrying Command (per Sense Data) Mar 26 10:28:37 w2fzz0vc03 kernel: (da3:umass-sim1:1:0:2): READ(10). CDB: 28 40 0 79 56 3f 0 0 4 0 Mar 26 10:28:37 w2fzz0vc03 kernel: (da3:umass-sim1:1:0:2): CAM Status: SCSI Status Error Mar 26 10:28:37 w2fzz0vc03 kernel: (da3:umass-sim1:1:0:2): SCSI Status: Check Condition Mar 26 10:28:37 w2fzz0vc03 kernel: (da3:umass-sim1:1:0:2): MEDIUM ERROR info?:79563f asc:11,0 Mar 26 10:28:37 w2fzz0vc03 kernel: (da3:umass-sim1:1:0:2): Unrecovered read error Mar 26 10:28:37 w2fzz0vc03 kernel: (da3:umass-sim1:1:0:2): Retrying Command (per Sense Data) Mar 26 10:28:37 w2fzz0vc03 kernel: (da3:umass-sim1:1:0:2): READ(10). CDB: 28 40 0 79 56 3f 0 0 4 0 Mar 26 10:28:37 w2fzz0vc03 kernel: (da3:umass-sim1:1:0:2): CAM Status: SCSI Status Error Mar 26 10:28:37 w2fzz0vc03 kernel: (da3:umass-sim1:1:0:2): SCSI Status: Check Condition Mar 26 10:28:37 w2fzz0vc03 kernel: (da3:umass-sim1:1:0:2): MEDIUM ERROR info?:79563f asc:11,0 Mar 26 10:28:37 w2fzz0vc03 kernel: (da3:umass-sim1:1:0:2): Unrecovered read error Mar 26 10:28:37 w2fzz0vc03 kernel: (da3:umass-sim1:1:0:2): Retrying Command (per Sense Data) Mar 26 10:28:37 w2fzz0vc03 kernel: (da3:umass-sim1:1:0:2): READ(10). CDB: 28 40 0 79 56 3f 0 0 4 0 Mar 26 10:28:37 w2fzz0vc03 kernel: (da3:umass-sim1:1:0:2): CAM Status: SCSI Status Error Mar 26 10:28:37 w2fzz0vc03 kernel: (da3:umass-sim1:1:0:2): SCSI Status: Check Condition Mar 26 10:28:37 w2fzz0vc03 kernel: (da3:umass-sim1:1:0:2): MEDIUM ERROR info?:79563f asc:11,0 Mar 26 10:28:37 w2fzz0vc03 kernel: (da3:umass-sim1:1:0:2): Unrecovered read error Mar 26 10:28:37 w2fzz0vc03 kernel: (da3:umass-sim1:1:0:2): Retrying Command (per Sense Data) Mar 26 10:28:38 w2fzz0vc03 kernel: (da3:umass-sim1:1:0:2): READ(10). CDB: 28 40 0 79 56 3f 0 0 4 0 Mar 26 10:28:38 w2fzz0vc03 kernel: (da3:umass-sim1:1:0:2): CAM Status: SCSI Status Error Mar 26 10:28:38 w2fzz0vc03 kernel: (da3:umass-sim1:1:0:2): SCSI Status: Check Condition Mar 26 10:28:38 w2fzz0vc03 kernel: (da3:umass-sim1:1:0:2): MEDIUM ERROR info?:79563f asc:11,0 Mar 26 10:28:38 w2fzz0vc03 kernel: (da3:umass-sim1:1:0:2): Unrecovered read error Mar 26 10:28:38 w2fzz0vc03 kernel: (da3:umass-sim1:1:0:2): Retries Exhausted Mar 26 10:28:38 w2fzz0vc03 kernel: (da3:umass-sim1:1:0:2): READ(10). CDB: 28 40 0 79 57 1f 0 0 4 0 Mar 26 10:28:38 w2fzz0vc03 kernel: (da3:umass-sim1:1:0:2): CAM Status: SCSI Status Error Mar 26 10:28:38 w2fzz0vc03 kernel: (da3:umass-sim1:1:0:2): SCSI Status: Check Condition Mar 26 10:28:38 w2fzz0vc03 kernel: (da3:umass-sim1:1:0:2): MEDIUM ERROR info?:79571f asc:11,0 Mar 26 10:28:38 w2fzz0vc03 kernel: (da3:umass-sim1:1:0:2): Unrecovered read error Mar 26 10:28:38 w2fzz0vc03 kernel: (da3:umass-sim1:1:0:2): Retrying Command (per Sense Data) Mar 26 10:28:38 w2fzz0vc03 kernel: (da3:umass-sim1:1:0:2): READ(10). CDB: 28 40 0 79 57 1f 0 0 4 0 Mar 26 10:28:38 w2fzz0vc03 kernel: (da3:umass-sim1:1:0:2): CAM Status: SCSI Status Error Mar 26 10:28:38 w2fzz0vc03 kernel: (da3:umass-sim1:1:0:2): SCSI Status: Check Condition Mar 26 10:28:38 w2fzz0vc03 kernel: (da3:umass-sim1:1:0:2): MEDIUM ERROR info?:79571f asc:11,0 Mar 26 10:28:38 w2fzz0vc03 kernel: (da3:umass-sim1:1:0:2): Unrecovered read error Mar 26 10:28:38 w2fzz0vc03 kernel: (da3:umass-sim1:1:0:2): Retrying Command (per Sense Data) Mar 26 10:28:38 w2fzz0vc03 kernel: (da3:umass-sim1:1:0:2): READ(10). CDB: 28 40 0 79 57 1f 0 0 4 0 Mar 26 10:28:38 w2fzz0vc03 kernel: (da3:umass-sim1:1:0:2): CAM Status: SCSI Status Error Mar 26 10:28:38 w2fzz0vc03 kernel: (da3:umass-sim1:1:0:2): SCSI Status: Check Condition Mar 26 10:28:38 w2fzz0vc03 kernel: (da3:umass-sim1:1:0:2): MEDIUM ERROR info?:79571f asc:11,0 Mar 26 10:28:38 w2fzz0vc03 kernel: (da3:umass-sim1:1:0:2): Unrecovered read error Mar 26 10:28:38 w2fzz0vc03 kernel: (da3:umass-sim1:1:0:2): Retrying Command (per Sense Data) Mar 26 10:28:38 w2fzz0vc03 kernel: (da3:umass-sim1:1:0:2): READ(10). CDB: 28 40 0 79 57 1f 0 0 4 0 Mar 26 10:28:38 w2fzz0vc03 kernel: (da3:umass-sim1:1:0:2): CAM Status: SCSI Status Error Mar 26 10:28:38 w2fzz0vc03 kernel: (da3:umass-sim1:1:0:2): SCSI Status: Check Condition Mar 26 10:28:38 w2fzz0vc03 kernel: (da3:umass-sim1:1:0:2): MEDIUM ERROR info?:79571f asc:11,0 Mar 26 10:28:38 w2fzz0vc03 kernel: (da3:umass-sim1:1:0:2): Unrecovered read error Mar 26 10:28:38 w2fzz0vc03 kernel: (da3:umass-sim1:1:0:2): Retrying Command (per Sense Data) Mar 26 10:28:38 w2fzz0vc03 kernel: (da3:umass-sim1:1:0:2): READ(10). CDB: 28 40 0 79 57 1f 0 0 4 0 Mar 26 10:28:38 w2fzz0vc03 kernel: (da3:umass-sim1:1:0:2): CAM Status: SCSI Status Error Mar 26 10:28:38 w2fzz0vc03 kernel: (da3:umass-sim1:1:0:2): SCSI Status: Check Condition Mar 26 10:28:38 w2fzz0vc03 kernel: (da3:umass-sim1:1:0:2): MEDIUM ERROR info?:79571f asc:11,0 Mar 26 10:28:38 w2fzz0vc03 kernel: (da3:umass-sim1:1:0:2): Unrecovered read error Mar 26 10:28:38 w2fzz0vc03 kernel: (da3:umass-sim1:1:0:2): Retries Exhausted Mar 26 10:28:38 w2fzz0vc03 kernel: (da3:umass-sim1:1:0:2): READ(10). CDB: 28 40 0 79 56 f0 0 0 1 0 Mar 26 10:28:38 w2fzz0vc03 kernel: (da3:umass-sim1:1:0:2): CAM Status: SCSI Status Error Mar 26 10:28:38 w2fzz0vc03 kernel: (da3:umass-sim1:1:0:2): SCSI Status: Check Condition Mar 26 10:28:38 w2fzz0vc03 kernel: (da3:umass-sim1:1:0:2): MEDIUM ERROR info?:7956f0 asc:11,0 Mar 26 10:28:38 w2fzz0vc03 kernel: (da3:umass-sim1:1:0:2): Unrecovered read error Mar 26 10:28:38 w2fzz0vc03 kernel: (da3:umass-sim1:1:0:2): Retrying Command (per Sense Data) Mar 26 10:28:38 w2fzz0vc03 kernel: (da3:umass-sim1:1:0:2): READ(10). CDB: 28 40 0 79 56 f0 0 0 1 0 Mar 26 10:28:38 w2fzz0vc03 kernel: (da3:umass-sim1:1:0:2): CAM Status: SCSI Status Error Mar 26 10:28:38 w2fzz0vc03 kernel: (da3:umass-sim1:1:0:2): SCSI Status: Check Condition Mar 26 10:28:38 w2fzz0vc03 kernel: (da3:umass-sim1:1:0:2): MEDIUM ERROR info?:7956f0 asc:11,0 Mar 26 10:28:38 w2fzz0vc03 kernel: (da3:umass-sim1:1:0:2): Unrecovered read error Mar 26 10:28:38 w2fzz0vc03 kernel: (da3:umass-sim1:1:0:2): Retrying Command (per Sense Data) Mar 26 10:28:38 w2fzz0vc03 kernel: (da3:umass-sim1:1:0:2): READ(10). CDB: 28 40 0 79 56 f0 0 0 1 0 Mar 26 10:28:38 w2fzz0vc03 kernel: (da3:umass-sim1:1:0:2): CAM Status: SCSI Status Error Mar 26 10:28:38 w2fzz0vc03 kernel: (da3:umass-sim1:1:0:2): SCSI Status: Check Condition Mar 26 10:28:38 w2fzz0vc03 kernel: (da3:umass-sim1:1:0:2): MEDIUM ERROR info?:7956f0 asc:11,0 Mar 26 10:28:38 w2fzz0vc03 kernel: (da3:umass-sim1:1:0:2): Unrecovered read error Mar 26 10:28:38 w2fzz0vc03 kernel: (da3:umass-sim1:1:0:2): Retrying Command (per Sense Data) Mar 26 10:28:38 w2fzz0vc03 kernel: (da3:umass-sim1:1:0:2): READ(10). CDB: 28 40 0 79 56 f0 0 0 1 0 Mar 26 10:28:38 w2fzz0vc03 kernel: (da3:umass-sim1:1:0:2): CAM Status: SCSI Status Error Mar 26 10:28:38 w2fzz0vc03 kernel: (da3:umass-sim1:1:0:2): SCSI Status: Check Condition Mar 26 10:28:38 w2fzz0vc03 kernel: (da3:umass-sim1:1:0:2): MEDIUM ERROR info?:7956f0 asc:11,0 Mar 26 10:28:38 w2fzz0vc03 kernel: (da3:umass-sim1:1:0:2): Unrecovered read error Mar 26 10:28:38 w2fzz0vc03 kernel: (da3:umass-sim1:1:0:2): Retrying Command (per Sense Data) Mar 26 10:28:38 w2fzz0vc03 kernel: (da3:umass-sim1:1:0:2): READ(10). CDB: 28 40 0 79 56 f0 0 0 1 0 Mar 26 10:28:38 w2fzz0vc03 kernel: (da3:umass-sim1:1:0:2): CAM Status: SCSI Status Error Mar 26 10:28:38 w2fzz0vc03 kernel: (da3:umass-sim1:1:0:2): SCSI Status: Check Condition Mar 26 10:28:38 w2fzz0vc03 kernel: (da3:umass-sim1:1:0:2): MEDIUM ERROR info?:7956f0 asc:11,0 Mar 26 10:28:38 w2fzz0vc03 kernel: (da3:umass-sim1:1:0:2): Unrecovered read error Mar 26 10:28:38 w2fzz0vc03 kernel: (da3:umass-sim1:1:0:2): Retries Exhausted Mar 26 10:28:38 w2fzz0vc03 kernel: (da3:umass-sim1:1:0:2): READ(10). CDB: 28 40 0 79 57 24 0 0 1 0 Mar 26 10:28:38 w2fzz0vc03 kernel: (da3:umass-sim1:1:0:2): CAM Status: SCSI Status Error Mar 26 10:28:38 w2fzz0vc03 kernel: (da3:umass-sim1:1:0:2): SCSI Status: Check Condition Mar 26 10:28:38 w2fzz0vc03 kernel: (da3:umass-sim1:1:0:2): MEDIUM ERROR info?:795724 asc:11,0 Mar 26 10:28:38 w2fzz0vc03 kernel: (da3:umass-sim1:1:0:2): Unrecovered read error Mar 26 10:28:38 w2fzz0vc03 kernel: (da3:umass-sim1:1:0:2): Retrying Command (per Sense Data) Mar 26 10:28:39 w2fzz0vc03 kernel: (da3:umass-sim1:1:0:2): READ(10). CDB: 28 40 0 79 57 24 0 0 1 0 Mar 26 10:28:39 w2fzz0vc03 kernel: (da3:umass-sim1:1:0:2): CAM Status: SCSI Status Error Mar 26 10:28:39 w2fzz0vc03 kernel: (da3:umass-sim1:1:0:2): SCSI Status: Check Condition Mar 26 10:28:39 w2fzz0vc03 kernel: (da3:umass-sim1:1:0:2): MEDIUM ERROR info?:795724 asc:11,0 Mar 26 10:28:39 w2fzz0vc03 kernel: (da3:umass-sim1:1:0:2): Unrecovered read error Mar 26 10:28:39 w2fzz0vc03 kernel: (da3:umass-sim1:1:0:2): Retrying Command (per Sense Data) Mar 26 10:28:39 w2fzz0vc03 kernel: (da3:umass-sim1:1:0:2): READ(10). CDB: 28 40 0 79 57 24 0 0 1 0 Mar 26 10:28:39 w2fzz0vc03 kernel: (da3:umass-sim1:1:0:2): CAM Status: SCSI Status Error Mar 26 10:28:39 w2fzz0vc03 kernel: (da3:umass-sim1:1:0:2): SCSI Status: Check Condition Mar 26 10:28:39 w2fzz0vc03 kernel: (da3:umass-sim1:1:0:2): MEDIUM ERROR info?:795724 asc:11,0 Mar 26 10:28:39 w2fzz0vc03 kernel: (da3:umass-sim1:1:0:2): Unrecovered read error Mar 26 10:28:39 w2fzz0vc03 kernel: (da3:umass-sim1:1:0:2): Retrying Command (per Sense Data) Mar 26 10:28:39 w2fzz0vc03 kernel: (da3:umass-sim1:1:0:2): READ(10). CDB: 28 40 0 79 57 24 0 0 1 0 Mar 26 10:28:39 w2fzz0vc03 kernel: (da3:umass-sim1:1:0:2): CAM Status: SCSI Status Error Mar 26 10:28:39 w2fzz0vc03 kernel: (da3:umass-sim1:1:0:2): SCSI Status: Check Condition Mar 26 10:28:39 w2fzz0vc03 kernel: (da3:umass-sim1:1:0:2): MEDIUM ERROR info?:795724 asc:11,0 Mar 26 10:28:39 w2fzz0vc03 kernel: (da3:umass-sim1:1:0:2): Unrecovered read error Mar 26 10:28:39 w2fzz0vc03 kernel: (da3:umass-sim1:1:0:2): Retrying Command (per Sense Data) Mar 26 10:28:39 w2fzz0vc03 kernel: (da3:umass-sim1:1:0:2): READ(10). CDB: 28 40 0 79 57 24 0 0 1 0 Mar 26 10:28:39 w2fzz0vc03 kernel: (da3:umass-sim1:1:0:2): CAM Status: SCSI Status Error Mar 26 10:28:39 w2fzz0vc03 kernel: (da3:umass-sim1:1:0:2): SCSI Status: Check Condition Mar 26 10:28:39 w2fzz0vc03 kernel: (da3:umass-sim1:1:0:2): MEDIUM ERROR info?:795724 asc:11,0 Mar 26 10:28:39 w2fzz0vc03 kernel: (da3:umass-sim1:1:0:2): Unrecovered read error Mar 26 10:28:39 w2fzz0vc03 kernel: (da3:umass-sim1:1:0:2): Retries Exhausted Mar 26 10:28:49 w2fzz0vc03 login: ROOT LOGIN (root) ON ttyv0 Mar 26 11:31:35 w2fzz0vc03 kernel: umass0: at uhub1, port 4, addr 4 (disconnected) Mar 26 11:31:35 w2fzz0vc03 kernel: (da0:umassG-EsOiMm_0L:A0B:E0L::0 )L:a bleols tn tdfesv/iBcaecku Mar 26 11:31:35 w2fzz0vc03 kernel: p( drae0m:ouvmeads.s-s Mar 26 11:31:35 w2fzz0vc03 kernel: im0:0:0:0): removing device entry Mar 26 11:31:35 w2fzz0vc03 kernel: ugen1.4: at usbus1 (disconnected) Mar 26 11:31:35 w2fzz0vc03 kernel: (da3:umass-sim1:1:0:2): READ(10). CDB: 28 40 0 79 56 3f 0 0 4 0 Mar 26 11:31:35 w2fzz0vc03 kernel: (da3:umass-sim1:1:0:2): CAM Status: SCSI Status Error Mar 26 11:31:35 w2fzz0vc03 kernel: (da3:umass-sim1:1:0:2): SCSI Status: Check Condition Mar 26 11:31:35 w2fzz0vc03 kernel: (da3:umass-sim1:1:0:2): MEDIUM ERROR info?:79563f asc:11,0 Mar 26 11:31:35 w2fzz0vc03 kernel: (da3:umass-sim1:1:0:2): Unrecovered read error Mar 26 11:31:35 w2fzz0vc03 kernel: (da3:umass-sim1:1:0:2): Retrying Command (per Sense Data) Mar 26 11:31:35 w2fzz0vc03 kernel: (da3:umass-sim1:1:0:2): READ(10). CDB: 28 40 0 79 56 3f 0 0 4 0 Mar 26 11:31:35 w2fzz0vc03 kernel: (da3:umass-sim1:1:0:2): CAM Status: SCSI Status Error Mar 26 11:31:35 w2fzz0vc03 kernel: (da3:umass-sim1:1:0:2): SCSI Status: Check Condition Mar 26 11:31:35 w2fzz0vc03 kernel: (da3:umass-sim1:1:0:2): MEDIUM ERROR info?:79563f asc:11,0 Mar 26 11:31:35 w2fzz0vc03 kernel: (da3:umass-sim1:1:0:2): Unrecovered read error Mar 26 11:31:35 w2fzz0vc03 kernel: (da3:umass-sim1:1:0:2): Retrying Command (per Sense Data) Mar 26 11:31:35 w2fzz0vc03 kernel: (da3:umass-sim1:1:0:2): READ(10). CDB: 28 40 0 79 56 3f 0 0 4 0 Mar 26 11:31:35 w2fzz0vc03 kernel: (da3:umass-sim1:1:0:2): CAM Status: SCSI Status Error Mar 26 11:31:35 w2fzz0vc03 kernel: (da3:umass-sim1:1:0:2): SCSI Status: Check Condition Mar 26 11:31:35 w2fzz0vc03 kernel: (da3:umass-sim1:1:0:2): MEDIUM ERROR info?:79563f asc:11,0 Mar 26 11:31:35 w2fzz0vc03 kernel: (da3:umass-sim1:1:0:2): Unrecovered read error Mar 26 11:31:35 w2fzz0vc03 kernel: (da3:umass-sim1:1:0:2): Retrying Command (per Sense Data) Mar 26 11:31:35 w2fzz0vc03 kernel: (da3:umass-sim1:1:0:2): READ(10). CDB: 28 40 0 79 56 3f 0 0 4 0 Mar 26 11:31:35 w2fzz0vc03 kernel: (da3:umass-sim1:1:0:2): CAM Status: SCSI Status Error Mar 26 11:31:35 w2fzz0vc03 kernel: (da3:umass-sim1:1:0:2): SCSI Status: Check Condition Mar 26 11:31:35 w2fzz0vc03 kernel: (da3:umass-sim1:1:0:2): MEDIUM ERROR info?:79563f asc:11,0 Mar 26 11:31:35 w2fzz0vc03 kernel: (da3:umass-sim1:1:0:2): Unrecovered read error Mar 26 11:31:35 w2fzz0vc03 kernel: (da3:umass-sim1:1:0:2): Retrying Command (per Sense Data) Mar 26 11:31:35 w2fzz0vc03 kernel: (da3:umass-sim1:1:0:2): READ(10). CDB: 28 40 0 79 56 3f 0 0 4 0 Mar 26 11:31:35 w2fzz0vc03 kernel: (da3:umass-sim1:1:0:2): CAM Status: SCSI Status Error Mar 26 11:31:35 w2fzz0vc03 kernel: (da3:umass-sim1:1:0:2): SCSI Status: Check Condition Mar 26 11:31:35 w2fzz0vc03 kernel: (da3:umass-sim1:1:0:2): MEDIUM ERROR info?:79563f asc:11,0 Mar 26 11:31:35 w2fzz0vc03 kernel: (da3:umass-sim1:1:0:2): Unrecovered read error Mar 26 11:31:35 w2fzz0vc03 kernel: (da3:umass-sim1:1:0:2): Retries Exhausted Mar 26 11:31:36 w2fzz0vc03 kernel: (da3:umass-sim1:1:0:2): READ(10). CDB: 28 40 0 79 57 1f 0 0 4 0 Mar 26 11:31:36 w2fzz0vc03 kernel: (da3:umass-sim1:1:0:2): CAM Status: SCSI Status Error Mar 26 11:31:36 w2fzz0vc03 kernel: (da3:umass-sim1:1:0:2): SCSI Status: Check Condition Mar 26 11:31:36 w2fzz0vc03 kernel: (da3:umass-sim1:1:0:2): MEDIUM ERROR info?:79571f asc:11,0 Mar 26 11:31:36 w2fzz0vc03 kernel: (da3:umass-sim1:1:0:2): Unrecovered read error Mar 26 11:31:36 w2fzz0vc03 kernel: (da3:umass-sim1:1:0:2): Retrying Command (per Sense Data) Mar 26 11:31:36 w2fzz0vc03 kernel: (da3:umass-sim1:1:0:2): READ(10). CDB: 28 40 0 79 57 1f 0 0 4 0 Mar 26 11:31:36 w2fzz0vc03 kernel: (da3:umass-sim1:1:0:2): CAM Status: SCSI Status Error Mar 26 11:31:36 w2fzz0vc03 kernel: (da3:umass-sim1:1:0:2): SCSI Status: Check Condition Mar 26 11:31:36 w2fzz0vc03 kernel: (da3:umass-sim1:1:0:2): MEDIUM ERROR info?:79571f asc:11,0 Mar 26 11:31:36 w2fzz0vc03 kernel: (da3:umass-sim1:1:0:2): Unrecovered read error Mar 26 11:31:36 w2fzz0vc03 kernel: (da3:umass-sim1:1:0:2): Retrying Command (per Sense Data) Mar 26 11:31:36 w2fzz0vc03 kernel: (da3:umass-sim1:1:0:2): READ(10). CDB: 28 40 0 79 57 1f 0 0 4 0 Mar 26 11:31:36 w2fzz0vc03 kernel: (da3:umass-sim1:1:0:2): CAM Status: SCSI Status Error Mar 26 11:31:36 w2fzz0vc03 kernel: (da3:umass-sim1:1:0:2): SCSI Status: Check Condition Mar 26 11:31:36 w2fzz0vc03 kernel: (da3:umass-sim1:1:0:2): MEDIUM ERROR info?:79571f asc:11,0 Mar 26 11:31:36 w2fzz0vc03 kernel: (da3:umass-sim1:1:0:2): Unrecovered read error Mar 26 11:31:36 w2fzz0vc03 kernel: (da3:umass-sim1:1:0:2): Retrying Command (per Sense Data) Mar 26 11:31:36 w2fzz0vc03 kernel: (da3:umass-sim1:1:0:2): READ(10). CDB: 28 40 0 79 57 1f 0 0 4 0 Mar 26 11:31:36 w2fzz0vc03 kernel: (da3:umass-sim1:1:0:2): CAM Status: SCSI Status Error Mar 26 11:31:36 w2fzz0vc03 kernel: (da3:umass-sim1:1:0:2): SCSI Status: Check Condition Mar 26 11:31:36 w2fzz0vc03 kernel: (da3:umass-sim1:1:0:2): MEDIUM ERROR info?:79571f asc:11,0 Mar 26 11:31:36 w2fzz0vc03 kernel: (da3:umass-sim1:1:0:2): Unrecovered read error Mar 26 11:31:36 w2fzz0vc03 kernel: (da3:umass-sim1:1:0:2): Retrying Co Mar 26 11:31:36 w2fzz0vc03 kernel: mmand (per Se Mar 26 11:31:36 w2fzz0vc03 kernel: nse Data) Mar 26 11:31:36 w2fzz0vc03 kernel: Mar 26 11:31:36 w2fzz0vc03 kernel: (da3:umass-sim1:1:0:2): READ(10). CDB: 28 40 0 79 57 1f 0 0 4 0 Mar 26 11:31:36 w2fzz0vc03 kernel: (da3:umass-sim1:1:0:2): CAM Status: SCSI Status Error Mar 26 11:31:36 w2fzz0vc03 kernel: (da3:umass-sim1:1:0:2): SCSI Status: Check Condition Mar 26 11:31:36 w2fzz0vc03 kernel: (da3:umass-sim1:1:0:2): MEDIUM ERROR info?:79571f asc:11,0 Mar 26 11:31:36 w2fzz0vc03 kernel: (da3:umass-sim1:1:0:2): Unrecovered read error Mar 26 11:31:36 w2fzz0vc03 kernel: (da3:umass-sim1:1:0:2): Retries Exhausted Mar 26 11:31:36 w2fzz0vc03 kernel: (da3:umass-sim1:1:0:2): READ(10). CDB: 28 40 0 79 56 f0 0 0 1 0 Mar 26 11:31:36 w2fzz0vc03 kernel: (da3:umass-sim1:1:0:2): CAM Status: SCSI Status Error Mar 26 11:31:36 w2fzz0vc03 kernel: (da3:umass-sim1:1:0:2): SCSI Status: Check Condition Mar 26 11:31:36 w2fzz0vc03 kernel: (da3:umass-sim1:1:0:2): MEDIUM ERROR info?:7956f0 asc:11,0 Mar 26 11:31:36 w2fzz0vc03 kernel: (da3:umass-sim1:1:0:2): Unrecovered read error Mar 26 11:31:36 w2fzz0vc03 kernel: (da3:umass-sim1:1:0:2): Retrying Command (per Sense Data) Mar 26 11:31:36 w2fzz0vc03 kernel: (da3:umass-sim1:1:0:2): READ(10). CDB: 28 40 0 79 56 f0 0 0 1 0 Mar 26 11:31:36 w2fzz0vc03 kernel: (da3:umass-sim1:1:0:2): CAM Status: SCSI Status Error Mar 26 11:31:36 w2fzz0vc03 kernel: (da3:umass-sim1:1:0:2): SCSI Status: Check Condition Mar 26 11:31:36 w2fzz0vc03 kernel: (da3:umass-sim1:1:0:2): MEDIUM ERROR info?:7956f0 asc:11,0 Mar 26 11:31:36 w2fzz0vc03 kernel: (da3:umass-sim1:1:0:2): Unrecovered read error Mar 26 11:31:36 w2fzz0vc03 kernel: (da3:umass-sim1:1:0:2): Retrying Command (per Sense Data) Mar 26 11:31:36 w2fzz0vc03 kernel: (da3:umass-sim1:1:0:2): READ(10). CDB: 28 40 0 79 56 f0 0 0 1 0 Mar 26 11:31:36 w2fzz0vc03 kernel: (da3:umass-sim1:1:0:2): CAM Status: SCSI Status Error Mar 26 11:31:36 w2fzz0vc03 kernel: (da3:umass-sim1:1:0:2): SCSI Status: Check Condition Mar 26 11:31:36 w2fzz0vc03 kernel: (da3:umass-sim1:1:0:2): MEDIUM ERROR info?:7956f0 asc:11,0 Mar 26 11:31:36 w2fzz0vc03 kernel: (da3:umass-sim1:1:0:2): Unrecovered read error Mar 26 11:31:36 w2fzz0vc03 kernel: (da3:umass-sim1:1:0:2): Retrying Command (per Sense Data) Mar 26 11:31:36 w2fzz0vc03 kernel: (da3:umass-sim1:1:0:2): READ(10). CDB: 28 40 0 79 56 f0 0 0 1 0 Mar 26 11:31:36 w2fzz0vc03 kernel: (da3:umass-sim1:1:0:2): CAM Status: SCSI Status Error Mar 26 11:31:36 w2fzz0vc03 kernel: (da3:umass-sim1:1:0:2): SCSI Status: Check Condition Mar 26 11:31:36 w2fzz0vc03 kernel: (da3:umass-sim1:1:0:2): MEDIUM ERROR info?:7956f0 asc:11,0 Mar 26 11:31:36 w2fzz0vc03 kernel: (da3:umass-sim1:1:0:2): Unrecovered read error Mar 26 11:31:36 w2fzz0vc03 kernel: (da3:umass-sim1:1:0:2): Retrying Command (per Sense Data) Mar 26 11:31:36 w2fzz0vc03 kernel: (da3:umass-sim1:1:0:2): READ(10). CDB: 28 40 0 79 56 f0 0 0 1 0 Mar 26 11:31:36 w2fzz0vc03 kernel: (da3:umass-sim1:1:0:2): CAM Status: SCSI Status Error Mar 26 11:31:36 w2fzz0vc03 kernel: (da3:umass-sim1:1:0:2): SCSI Status: Check Condition Mar 26 11:31:36 w2fzz0vc03 kernel: (da3:umass-sim1:1:0:2): MEDIUM ERROR info?:7956f0 asc:11,0 Mar 26 11:31:36 w2fzz0vc03 kernel: (da3:umass-sim1:1:0:2): Unrecovered read error Mar 26 11:31:36 w2fzz0vc03 kernel: (da3:umass-sim1:1:0:2): Retries Exhausted Mar 26 11:31:36 w2fzz0vc03 kernel: (da3:umass-sim1:1:0:2): READ(10). CDB: 28 40 0 79 57 24 0 0 1 0 Mar 26 11:31:36 w2fzz0vc03 kernel: (da3:umass-sim1:1:0:2): CAM Status: SCSI Status Error Mar 26 11:31:36 w2fzz0vc03 kernel: (da3:umass-sim1:1:0:2): SCSI Status: Check Condition Mar 26 11:31:36 w2fzz0vc03 kernel: (da3:umass-sim1:1:0:2): MEDIUM ERROR info?:795724 asc:11,0 Mar 26 11:31:36 w2fzz0vc03 kernel: (da3:umass-sim1:1:0:2): Unrecovered read error Mar 26 11:31:36 w2fzz0vc03 kernel: (da3:umass-sim1:1:0:2): Retrying Command (per Sense Data) Mar 26 11:31:36 w2fzz0vc03 kernel: (da3:umass-sim1:1:0:2): READ(10). CDB: 28 40 0 79 57 24 0 0 1 0 Mar 26 11:31:36 w2fzz0vc03 kernel: (da3:umass-sim1:1:0:2): CAM Status: SCSI Status Error Mar 26 11:31:36 w2fzz0vc03 kernel: (da3:umass-sim1:1:0:2): SCSI Status: Check Condition Mar 26 11:31:36 w2fzz0vc03 kernel: (da3:umass-sim1:1:0:2): MEDIUM ERROR info?:795724 asc:11,0 Mar 26 11:31:36 w2fzz0vc03 kernel: (da3:umass-sim1:1:0:2): Unrecovered read error Mar 26 11:31:36 w2fzz0vc03 kernel: (da3:umass-sim1:1:0:2): Retrying Command (per Sense Data) Mar 26 11:31:37 w2fzz0vc03 kernel: (da3:umass-sim1:1:0:2): READ(10). CDB: 28 40 0 79 57 24 0 0 1 0 Mar 26 11:31:37 w2fzz0vc03 kernel: (da3:umass-sim1:1:0:2): CAM Status: SCSI Status Error Mar 26 11:31:37 w2fzz0vc03 kernel: (da3:umass-sim1:1:0:2): SCSI Status: Check Condition Mar 26 11:31:37 w2fzz0vc03 kernel: (da3:umass-sim1:1:0:2): MEDIUM ERROR info?:795724 asc:11,0 Mar 26 11:31:37 w2fzz0vc03 kernel: (da3:umass-sim1:1:0:2): Unrecovered read error Mar 26 11:31:37 w2fzz0vc03 kernel: (da3:umass-sim1:1:0:2): Retrying Command (per Sense Data) Mar 26 11:31:37 w2fzz0vc03 kernel: (da3:umass-sim1:1:0:2): READ(10). CDB: 28 40 0 79 57 24 0 0 1 0 Mar 26 11:31:37 w2fzz0vc03 kernel: (da3:umass-sim1:1:0:2): CAM Status: SCSI Status Error Mar 26 11:31:37 w2fzz0vc03 kernel: (da3:umass-sim1:1:0:2): SCSI Status: Check Condition Mar 26 11:31:37 w2fzz0vc03 kernel: (da3:umass-sim1:1:0:2): MEDIUM ERROR info?:795724 asc:11,0 Mar 26 11:31:37 w2fzz0vc03 kernel: (da3:umass-sim1:1:0:2): Unrecovered read error Mar 26 11:31:37 w2fzz0vc03 kernel: (da3:umass-sim1:1:0:2): Retrying Command (per Sense Data) Mar 26 11:31:37 w2fzz0vc03 kernel: (da3:umass-sim1:1:0:2): READ(10). CDB: 28 40 0 79 57 24 0 0 1 0 Mar 26 11:31:37 w2fzz0vc03 kernel: (da3:umass-sim1:1:0:2): CAM Status: SCSI Status Error Mar 26 11:31:37 w2fzz0vc03 kernel: (da3:umass-sim1:1:0:2): SCSI Status: Check Condition Mar 26 11:31:37 w2fzz0vc03 kernel: (da3:umass-sim1:1:0:2): MEDIUM ERROR info?:795724 asc:11,0 Mar 26 11:31:37 w2fzz0vc03 kernel: (da3:umass-sim1:1:0:2): Unrecovered read error Mar 26 11:31:37 w2fzz0vc03 kernel: (da3:umass-sim1:1:0:2): Retries Exhausted Mar 26 11:31:47 w2fzz0vc03 root: ZFS: checksum mismatch, zpool=pool path=/dev/ad14s1d offset=4520509952 size=43520 Mar 26 11:31:48 w2fzz0vc03 root: ZFS: checksum mismatch, zpool=pool path=/dev/ad12s1d offset=4812235264 size=43520 Mar 26 11:31:48 w2fzz0vc03 root: ZFS: checksum mismatch, zpool=pool path=/dev/ad14s1d offset=4366682112 size=43520 Mar 26 11:31:48 w2fzz0vc03 root: ZFS: checksum mismatch, zpool=pool path=/dev/ad14s1d offset=27226243584 size=43520 Mar 26 11:31:50 w2fzz0vc03 root: ZFS: checksum mismatch, zpool=pool path=/dev/ad6s1d offset=21925431808 size=43520 Mar 26 11:31:50 w2fzz0vc03 root: ZFS: checksum mismatch, zpool=pool path=/dev/ad12s1d offset=21830071296 size=43520 Mar 26 11:31:50 w2fzz0vc03 root: ZFS: checksum mismatch, zpool=pool path=/dev/ad6s1d offset=21951923712 size=43520 Mar 26 11:31:50 w2fzz0vc03 root: ZFS: checksum mismatch, zpool=pool path=/dev/ad12s1d offset=21952010752 size=44032 Mar 26 11:31:50 w2fzz0vc03 root: ZFS: checksum mismatch, zpool=pool path=/dev/ad14s1d offset=21952010752 size=44032 Mar 26 11:31:50 w2fzz0vc03 root: ZFS: checksum mismatch, zpool=pool path=/dev/ad4s1d offset=21952011264 size=43520 Mar 26 11:31:50 w2fzz0vc03 root: ZFS: checksum mismatch, zpool=pool path=/dev/ad6s1d offset=21952011264 size=43520 Mar 26 11:31:50 w2fzz0vc03 root: ZFS: checksum mismatch, zpool=pool path=/dev/ad12s1d offset=21952010752 size=44032 Mar 26 11:31:50 w2fzz0vc03 root: ZFS: checksum mismatch, zpool=pool path=/dev/ad14s1d offset=21952010752 size=44032 Mar 26 11:31:50 w2fzz0vc03 root: ZFS: checksum mismatch, zpool=pool path=/dev/ad4s1d offset=21952011264 size=43520 Mar 26 11:31:50 w2fzz0vc03 root: ZFS: checksum mismatch, zpool=pool path=/dev/ad6s1d offset=21952011264 size=43520 Mar 26 11:31:50 w2fzz0vc03 root: ZFS: zpool I/O failure, zpool=pool error=86 Mar 26 11:31:50 w2fzz0vc03 root: ZFS: checksum mismatch, zpool=pool path=/dev/ad12s1d offset=21952010752 size=44032 Mar 26 11:31:50 w2fzz0vc03 root: ZFS: checksum mismatch, zpool=pool path=/dev/ad14s1d offset=21952010752 size=44032 Mar 26 11:31:50 w2fzz0vc03 root: ZFS: checksum mismatch, zpool=pool path=/dev/ad4s1d offset=21952011264 size=43520 Mar 26 11:31:50 w2fzz0vc03 root: ZFS: checksum mismatch, zpool=pool path=/dev/ad6s1d offset=21952011264 size=43520 Mar 26 11:31:50 w2fzz0vc03 root: ZFS: checksum mismatch, zpool=pool path=/dev/ad12s1d offset=21952010752 size=44032 Mar 26 11:31:50 w2fzz0vc03 root: ZFS: checksum mismatch, zpool=pool path=/dev/ad14s1d offset=21952010752 size=44032 Mar 26 11:31:50 w2fzz0vc03 root: ZFS: checksum mismatch, zpool=pool path=/dev/ad4s1d offset=21952011264 size=43520 Mar 26 11:31:50 w2fzz0vc03 root: ZFS: checksum mismatch, zpool=pool path=/dev/ad6s1d offset=21952011264 size=43520 Mar 26 11:31:50 w2fzz0vc03 root: ZFS: zpool I/O failure, zpool=pool error=86 Mar 26 11:31:51 w2fzz0vc03 root: ZFS: checksum mismatch, zpool=pool path=/dev/ad12s1d offset=27132336640 size=43520 Mar 26 11:31:51 w2fzz0vc03 root: ZFS: checksum mismatch, zpool=pool path=/dev/ad14s1d offset=21932119040 size=44032 Mar 26 11:31:51 w2fzz0vc03 root: ZFS: checksum mismatch, zpool=pool path=/dev/ad14s1d offset=27012382208 size=43520 Mar 26 11:31:51 w2fzz0vc03 root: ZFS: checksum mismatch, zpool=pool path=/dev/ad6s1d offset=21663055872 size=43520 Mar 26 11:31:52 w2fzz0vc03 root: ZFS: checksum mismatch, zpool=pool path=/dev/ad14s1d offset=21562803200 size=43520 Mar 26 11:31:53 w2fzz0vc03 root: ZFS: checksum mismatch, zpool=pool path=/dev/ad14s1d offset=21707188736 size=44032 Mar 26 11:31:54 w2fzz0vc03 root: ZFS: checksum mismatch, zpool=pool path=/dev/ad14s1d offset=28133307392 size=44032 Mar 26 11:32:05 w2fzz0vc03 root: ZFS: checksum mismatch, zpool=pool path=/dev/ad12s1d offset=4481567232 size=44032 Mar 26 11:32:08 w2fzz0vc03 root: ZFS: checksum mismatch, zpool=pool path=/dev/ad14s1d offset=12910338048 size=43520 Mar 26 11:32:11 w2fzz0vc03 root: ZFS: checksum mismatch, zpool=pool path=/dev/ad12s1d offset=13005668864 size=43520 Mar 26 11:32:11 w2fzz0vc03 root: ZFS: checksum mismatch, zpool=pool path=/dev/ad12s1d offset=29152584704 size=43520 Mar 26 11:32:12 w2fzz0vc03 root: ZFS: checksum mismatch, zpool=pool path=/dev/ad12s1d offset=13390609408 size=44032 Mar 26 11:32:14 w2fzz0vc03 root: ZFS: checksum mismatch, zpool=pool path=/dev/ad6s1d offset=4792746496 size=43520 Mar 26 11:32:14 w2fzz0vc03 root: ZFS: checksum mismatch, zpool=pool path=/dev/ad14s1d offset=4792921088 size=44032 Mar 26 11:32:14 w2fzz0vc03 root: ZFS: checksum mismatch, zpool=pool path=/dev/ad12s1d offset=4792921088 size=44032 Mar 26 11:32:14 w2fzz0vc03 root: ZFS: checksum mismatch, zpool=pool path=/dev/ad4s1d offset=4792921600 size=43520 Mar 26 11:32:14 w2fzz0vc03 root: ZFS: checksum mismatch, zpool=pool path=/dev/ad6s1d offset=4792921600 size=43520 Mar 26 11:32:14 w2fzz0vc03 root: ZFS: checksum mismatch, zpool=pool path=/dev/ad14s1d offset=4792921088 size=44032 Mar 26 11:32:14 w2fzz0vc03 root: ZFS: checksum mismatch, zpool=pool path=/dev/ad12s1d offset=4792921088 size=44032 Mar 26 11:32:14 w2fzz0vc03 root: ZFS: checksum mismatch, zpool=pool path=/dev/ad4s1d offset=4792921600 size=43520 Mar 26 11:32:14 w2fzz0vc03 root: ZFS: checksum mismatch, zpool=pool path=/dev/ad6s1d offset=4792921600 size=43520 Mar 26 11:32:14 w2fzz0vc03 root: ZFS: zpool I/O failure, zpool=pool error=86 Mar 26 11:32:14 w2fzz0vc03 root: ZFS: checksum mismatch, zpool=pool path=/dev/ad6s1d offset=4792921600 size=43520 Mar 26 11:32:15 w2fzz0vc03 root: ZFS: checksum mismatch, zpool=pool path=/dev/ad12s1d offset=13191209984 size=44032 Mar 26 11:32:15 w2fzz0vc03 root: ZFS: checksum mismatch, zpool=pool path=/dev/ad14s1d offset=13191209984 size=44032 Mar 26 11:32:15 w2fzz0vc03 root: ZFS: checksum mismatch, zpool=pool path=/dev/ad4s1d offset=13191210496 size=43520 Mar 26 11:32:15 w2fzz0vc03 root: ZFS: checksum mismatch, zpool=pool path=/dev/ad6s1d offset=13191210496 size=43520 Mar 26 11:32:15 w2fzz0vc03 root: ZFS: checksum mismatch, zpool=pool path=/dev/ad14s1d offset=13191209984 size=44032 Mar 26 11:32:17 w2fzz0vc03 root: ZFS: checksum mismatch, zpool=pool path=/dev/ad6s1d offset=28034315776 size=43520 Mar 26 11:32:17 w2fzz0vc03 root: ZFS: checksum mismatch, zpool=pool path=/dev/ad4s1d offset=29022560256 size=43520 Mar 26 11:41:31 w2fzz0vc03 kernel: umass1: at uhub1, port 7, addr 5 (disconnected) Mar 26 11:41:31 w2fzz0vc03 kernel: (daG1E:OuMm_LasAsBE-siLm:1 :L1:a0b:e0l) :m sldoossfts /d e vriecmeov Mar 26 11:41:31 w2fzz0vc03 kernel: e(dd.a Mar 26 11:41:31 w2fzz0vc03 kernel: 1:umass-sim1:1:0:0): removing device entry Mar 26 11:41:31 w2fzz0vc03 kernel: (da2:umass-sim1:1:0:1): lost device Mar 26 11:41:31 w2fzz0vc03 kernel: (da2:umass-sim1:1:0:1): removing device entry Mar 26 11:41:31 w2fzz0vc03 kernel: (da3:umass-sim1:1:0:2): lost device Mar 26 11:41:31 w2fzz0vc03 kernel: (da3:umass-sim1:1:0:2): removing device entry Mar 26 11:41:31 w2fzz0vc03 kernel: ugen1.5: at usbus1 (disconnected) Mar 26 11:41:58 w2fzz0vc03 shutdown: reboot by root: Mar 26 11:42:05 w2fzz0vc03 mDNSResponder (Engineering Build) (Mar 15 2009 06:30:34) [1259]: stopping Mar 26 11:42:05 w2fzz0vc03 kernel: rum0: need multicast update callback Mar 26 11:42:06 w2fzz0vc03 kernel: rum0: need multicast update callback Mar 26 11:42:10 w2fzz0vc03 auditd[1031]: Auditing disabled Mar 26 11:42:10 w2fzz0vc03 auditd[1031]: renamed /var/audit/20090326102829.not_terminated to /var/audit/20090326102829.20090326114210 Mar 26 11:42:10 w2fzz0vc03 root: audit warning: closefile /var/audit/20090326102829.20090326114210 Mar 26 11:42:11 w2fzz0vc03 syslogd: exiting on signal 15 Mar 26 11:43:24 w2fzz0vc03 syslogd: kernel boot file is /boot/kernel.good/kernel Mar 26 11:43:24 w2fzz0vc03 kernel: Copyright (c) 1992-2009 The FreeBSD Project. Mar 26 11:43:24 w2fzz0vc03 kernel: Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 Mar 26 11:43:24 w2fzz0vc03 kernel: The Regents of the University of California. All rights reserved. Mar 26 11:43:24 w2fzz0vc03 kernel: FreeBSD is a registered trademark of The FreeBSD Foundation. Mar 26 11:43:24 w2fzz0vc03 kernel: FreeBSD 8.0-CURRENT #1 r189454M: Fri Mar 6 18:46:25 GMT 2009 Mar 26 11:43:24 w2fzz0vc03 kernel: root@w2fzz0vc03.aah-go-on.com:/usr/obj/usr/src/sys/GENERIC Mar 26 11:43:24 w2fzz0vc03 kernel: WARNING: WITNESS option enabled, expect reduced performance. Mar 26 11:43:24 w2fzz0vc03 kernel: Timecounter "i8254" frequency 1193182 Hz quality 0 Mar 26 11:43:24 w2fzz0vc03 kernel: CPU: Intel(R) Core(TM)2 Quad CPU @ 2.66GHz (2660.04-MHz K8-class CPU) Mar 26 11:43:24 w2fzz0vc03 kernel: Origin = "GenuineIntel" Id = 0x6f7 Stepping = 7 Mar 26 11:43:24 w2fzz0vc03 kernel: Features=0xbfebfbff Mar 26 11:43:24 w2fzz0vc03 kernel: Features2=0xe3bd Mar 26 11:43:24 w2fzz0vc03 kernel: AMD Features=0x20100800 Mar 26 11:43:24 w2fzz0vc03 kernel: AMD Features2=0x1 Mar 26 11:43:24 w2fzz0vc03 kernel: TSC: P-state invariant Mar 26 11:43:24 w2fzz0vc03 kernel: Cores per package: 4 Mar 26 11:43:24 w2fzz0vc03 kernel: usable memory = 4275412992 (4077 MB) Mar 26 11:43:24 w2fzz0vc03 kernel: avail memory = 4090191872 (3900 MB) Mar 26 11:43:24 w2fzz0vc03 kernel: ACPI APIC Table: Mar 26 11:43:24 w2fzz0vc03 kernel: FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs Mar 26 11:43:24 w2fzz0vc03 kernel: cpu0 (BSP): APIC ID: 0 Mar 26 11:43:24 w2fzz0vc03 kernel: cpu1 (AP): APIC ID: 1 Mar 26 11:43:24 w2fzz0vc03 kernel: cpu2 (AP): APIC ID: 2 Mar 26 11:43:24 w2fzz0vc03 kernel: cpu3 (AP): APIC ID: 3 Mar 26 11:43:24 w2fzz0vc03 kernel: This module (opensolaris) contains code covered by the Mar 26 11:43:24 w2fzz0vc03 kernel: Common Development and Distribution License (CDDL) Mar 26 11:43:24 w2fzz0vc03 kernel: see http://opensolaris.org/os/licensing/opensolaris_license/ Mar 26 11:43:24 w2fzz0vc03 kernel: ioapic0: Changing APIC ID to 8 Mar 26 11:43:24 w2fzz0vc03 kernel: ioapic0 irqs 0-23 on motherboard Mar 26 11:43:24 w2fzz0vc03 kernel: lapic0: Forcing LINT1 to edge trigger Mar 26 11:43:24 w2fzz0vc03 kernel: kbd1 at kbdmux0 Mar 26 11:43:24 w2fzz0vc03 kernel: acpi0: on motherboard Mar 26 11:43:24 w2fzz0vc03 kernel: acpi0: [ITHREAD] Mar 26 11:43:24 w2fzz0vc03 kernel: acpi0: Power Button (fixed) Mar 26 11:43:24 w2fzz0vc03 kernel: acpi0: reservation of 0, a0000 (3) failed Mar 26 11:43:24 w2fzz0vc03 kernel: acpi0: reservation of 100000, f00000 (3) failed Mar 26 11:43:24 w2fzz0vc03 kernel: acpi0: reservation of 1000000, 9edbcc00 (3) failed Mar 26 11:43:24 w2fzz0vc03 kernel: Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 Mar 26 11:43:24 w2fzz0vc03 kernel: acpi_timer0: <24-bit timer at 3.579545MHz> port 0x4008-0x400b on acpi0 Mar 26 11:43:24 w2fzz0vc03 kernel: acpi_hpet0: iomem 0xfed00000-0xfed003ff on acpi0 Mar 26 11:43:24 w2fzz0vc03 kernel: Timecounter "HPET" frequency 25000000 Hz quality 900 Mar 26 11:43:24 w2fzz0vc03 kernel: acpi_button0: on acpi0 Mar 26 11:43:24 w2fzz0vc03 kernel: pcib0: port 0xcf8-0xcff on acpi0 Mar 26 11:43:24 w2fzz0vc03 kernel: pci0: on pcib0 Mar 26 11:43:24 w2fzz0vc03 kernel: pci0: at device 0.1 (no driver attached) Mar 26 11:43:24 w2fzz0vc03 kernel: pci0: at device 0.2 (no driver attached) Mar 26 11:43:24 w2fzz0vc03 kernel: pci0: at device 0.3 (no driver attached) Mar 26 11:43:24 w2fzz0vc03 kernel: pci0: at device 0.4 (no driver attached) Mar 26 11:43:24 w2fzz0vc03 kernel: pci0: at device 1.0 (no driver attached) Mar 26 11:43:24 w2fzz0vc03 kernel: pci0: at device 1.1 (no driver attached) Mar 26 11:43:24 w2fzz0vc03 kernel: pci0: at device 1.2 (no driver attached) Mar 26 11:43:24 w2fzz0vc03 kernel: pci0: at device 1.3 (no driver attached) Mar 26 11:43:24 w2fzz0vc03 kernel: pci0: at device 1.4 (no driver attached) Mar 26 11:43:24 w2fzz0vc03 kernel: pci0: at device 1.5 (no driver attached) Mar 26 11:43:24 w2fzz0vc03 kernel: pci0: at device 1.6 (no driver attached) Mar 26 11:43:24 w2fzz0vc03 kernel: pcib1: at device 2.0 on pci0 Mar 26 11:43:24 w2fzz0vc03 kernel: pci1: on pcib1 Mar 26 11:43:24 w2fzz0vc03 kernel: vgapci0: port 0xdc80-0xdcff mem 0xde000000-0xdeffffff,0xa0000000-0xafffffff,0xdc000000-0xddffffff irq 16 at device 0.0 on pci1 Mar 26 11:43:24 w2fzz0vc03 kernel: pcib2: at device 4.0 on pci0 Mar 26 11:43:24 w2fzz0vc03 kernel: pci2: on pcib2 Mar 26 11:43:24 w2fzz0vc03 kernel: pcib3: at device 5.0 on pci0 Mar 26 11:43:24 w2fzz0vc03 kernel: pci3: on pcib3 Mar 26 11:43:24 w2fzz0vc03 kernel: pci0: at device 9.0 (no driver attached) Mar 26 11:43:24 w2fzz0vc03 kernel: isab0: port 0x4f00-0x4fff at device 10.0 on pci0 Mar 26 11:43:24 w2fzz0vc03 kernel: isa0: on isab0 Mar 26 11:43:24 w2fzz0vc03 kernel: pci0: at device 10.1 (no driver attached) Mar 26 11:43:24 w2fzz0vc03 kernel: ohci0: mem 0xdfffc000-0xdfffcfff irq 21 at device 11.0 on pci0 Mar 26 11:43:24 w2fzz0vc03 kernel: ohci0: [ITHREAD] Mar 26 11:43:24 w2fzz0vc03 kernel: usbus0: on ohci0 Mar 26 11:43:24 w2fzz0vc03 kernel: ehci0: mem 0xdfffbf00-0xdfffbfff irq 22 at device 11.1 on pci0 Mar 26 11:43:24 w2fzz0vc03 kernel: ehci0: [ITHREAD] Mar 26 11:43:24 w2fzz0vc03 kernel: usbus1: waiting for BIOS to give up control Mar 26 11:43:24 w2fzz0vc03 kernel: usbus1: EHCI version 1.0 Mar 26 11:43:24 w2fzz0vc03 kernel: usbus1: on ehci0 Mar 26 11:43:24 w2fzz0vc03 kernel: atapci0: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xecf0-0xecff at device 13.0 on pci0 Mar 26 11:43:24 w2fzz0vc03 kernel: ata0: on atapci0 Mar 26 11:43:24 w2fzz0vc03 kernel: ata0: [ITHREAD] Mar 26 11:43:24 w2fzz0vc03 kernel: ata1: on atapci0 Mar 26 11:43:24 w2fzz0vc03 kernel: ata1: [ITHREAD] Mar 26 11:43:24 w2fzz0vc03 kernel: atapci1: port 0xfe00-0xfe07,0xfe10-0xfe13,0xfe20-0xfe27,0xfe30-0xfe33,0xfec0-0xfecf mem 0xdfffd000-0xdfffdfff irq 23 at device 14.0 on pci0 Mar 26 11:43:24 w2fzz0vc03 kernel: atapci1: [ITHREAD] Mar 26 11:43:24 w2fzz0vc03 kernel: ata2: on atapci1 Mar 26 11:43:24 w2fzz0vc03 kernel: ata2: [ITHREAD] Mar 26 11:43:24 w2fzz0vc03 kernel: ata3: on atapci1 Mar 26 11:43:24 w2fzz0vc03 kernel: ata3: [ITHREAD] Mar 26 11:43:24 w2fzz0vc03 kernel: atapci2: port 0xfe40-0xfe47,0xfe50-0xfe53,0xfe60-0xfe67,0xfe70-0xfe73,0xfed0-0xfedf mem 0xdfffe000-0xdfffefff irq 20 at device 14.1 on pci0 Mar 26 11:43:24 w2fzz0vc03 kernel: atapci2: [ITHREAD] Mar 26 11:43:24 w2fzz0vc03 kernel: ata4: on atapci2 Mar 26 11:43:24 w2fzz0vc03 kernel: ata4: [ITHREAD] Mar 26 11:43:24 w2fzz0vc03 kernel: ata5: on atapci2 Mar 26 11:43:24 w2fzz0vc03 kernel: ata5: [ITHREAD] Mar 26 11:43:24 w2fzz0vc03 kernel: atapci3: port 0xfe80-0xfe87,0xfe90-0xfe93,0xfea0-0xfea7,0xfeb0-0xfeb3,0xfef0-0xfeff mem 0xdffff000-0xdfffffff irq 21 at device 14.2 on pci0 Mar 26 11:43:24 w2fzz0vc03 kernel: atapci3: [ITHREAD] Mar 26 11:43:24 w2fzz0vc03 kernel: ata6: on atapci3 Mar 26 11:43:24 w2fzz0vc03 kernel: ata6: [ITHREAD] Mar 26 11:43:24 w2fzz0vc03 kernel: ata7: on atapci3 Mar 26 11:43:24 w2fzz0vc03 kernel: ata7: [ITHREAD] Mar 26 11:43:24 w2fzz0vc03 kernel: pcib4: at device 15.0 on pci0 Mar 26 11:43:24 w2fzz0vc03 kernel: pci4: on pcib4 Mar 26 11:43:24 w2fzz0vc03 kernel: pci4: at device 4.0 (no driver attached) Mar 26 11:43:24 w2fzz0vc03 kernel: pci4: at device 5.0 (no driver attached) Mar 26 11:43:24 w2fzz0vc03 kernel: fwohci0: mem 0xdadfb800-0xdadfbfff,0xdadfc000-0xdadfffff irq 18 at device 10.0 on pci4 Mar 26 11:43:24 w2fzz0vc03 kernel: fwohci0: [ITHREAD] Mar 26 11:43:24 w2fzz0vc03 kernel: fwohci0: OHCI version 1.10 (ROM=0) Mar 26 11:43:24 w2fzz0vc03 kernel: fwohci0: No. of Isochronous channels is 4. Mar 26 11:43:24 w2fzz0vc03 kernel: fwohci0: EUI64 80:00:00:00:00:00:00:00 Mar 26 11:43:24 w2fzz0vc03 kernel: fwohci0: Phy 1394a available S400, 2 ports. Mar 26 11:43:24 w2fzz0vc03 kernel: fwohci0: Link S400, max_rec 2048 bytes. Mar 26 11:43:24 w2fzz0vc03 kernel: firewire0: on fwohci0 Mar 26 11:43:24 w2fzz0vc03 kernel: dcons_crom0: on firewire0 Mar 26 11:43:24 w2fzz0vc03 kernel: dcons_crom0: bus_addr 0x2578000 Mar 26 11:43:24 w2fzz0vc03 kernel: fwe0: on firewire0 Mar 26 11:43:24 w2fzz0vc03 kernel: if_fwe0: Fake Ethernet address: 82:00:00:00:00:00 Mar 26 11:43:24 w2fzz0vc03 kernel: fwe0: Ethernet address: 82:00:00:00:00:00 Mar 26 11:43:24 w2fzz0vc03 kernel: fwip0: on firewire0 Mar 26 11:43:24 w2fzz0vc03 kernel: fwip0: Firewire address: 80:00:00:00:00:00:00:00 @ 0xfffe00000000, S400, maxrec 2048 Mar 26 11:43:24 w2fzz0vc03 kernel: sbp0: on firewire0 Mar 26 11:43:24 w2fzz0vc03 kernel: fwohci0: Initiate bus reset Mar 26 11:43:24 w2fzz0vc03 kernel: fwohci0: fwohci_intr_core: BUS reset Mar 26 11:43:24 w2fzz0vc03 kernel: fwohci0: fwohci_intr_core: node_id=0x00000000, SelfID Count=1, CYCLEMASTER mode Mar 26 11:43:24 w2fzz0vc03 kernel: pcib5: at device 19.0 on pci0 Mar 26 11:43:24 w2fzz0vc03 kernel: pci5: on pcib5 Mar 26 11:43:24 w2fzz0vc03 kernel: pcib6: at device 24.0 on pci0 Mar 26 11:43:24 w2fzz0vc03 kernel: pci6: on pcib6 Mar 26 11:43:24 w2fzz0vc03 kernel: vgapci1: port 0xbc80-0xbcff mem 0xd1000000-0xd1ffffff,0xc0000000-0xcfffffff,0xd2000000-0xd3ffffff irq 16 at device 0.0 on pci6 Mar 26 11:43:24 w2fzz0vc03 kernel: atrtc0: port 0x70-0x7f irq 8 on acpi0 Mar 26 11:43:24 w2fzz0vc03 kernel: atkbdc0: port 0x60,0x64 irq 1 on acpi0 Mar 26 11:43:24 w2fzz0vc03 kernel: atkbd0: irq 1 on atkbdc0 Mar 26 11:43:24 w2fzz0vc03 kernel: kbd0 at atkbd0 Mar 26 11:43:24 w2fzz0vc03 kernel: atkbd0: [GIANT-LOCKED] Mar 26 11:43:24 w2fzz0vc03 kernel: atkbd0: [ITHREAD] Mar 26 11:43:24 w2fzz0vc03 kernel: psm0: irq 12 on atkbdc0 Mar 26 11:43:24 w2fzz0vc03 kernel: psm0: [GIANT-LOCKED] Mar 26 11:43:24 w2fzz0vc03 kernel: psm0: [ITHREAD] Mar 26 11:43:24 w2fzz0vc03 kernel: psm0: model MouseMan+, device ID 0 Mar 26 11:43:24 w2fzz0vc03 kernel: uart0: <16550 or compatible> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 Mar 26 11:43:24 w2fzz0vc03 kernel: uart0: [FILTER] Mar 26 11:43:24 w2fzz0vc03 kernel: cpu0: on acpi0 Mar 26 11:43:24 w2fzz0vc03 kernel: est0: on cpu0 Mar 26 11:43:24 w2fzz0vc03 kernel: est: CPU supports Enhanced Speedstep, but is not recognized. Mar 26 11:43:24 w2fzz0vc03 kernel: est: cpu_vendor GenuineIntel, msr a2a0a2a86000a2a Mar 26 11:43:24 w2fzz0vc03 kernel: device_attach: est0 attach returned 6 Mar 26 11:43:24 w2fzz0vc03 kernel: p4tcc0: on cpu0 Mar 26 11:43:24 w2fzz0vc03 kernel: cpu1: on acpi0 Mar 26 11:43:24 w2fzz0vc03 kernel: est1: on cpu1 Mar 26 11:43:24 w2fzz0vc03 kernel: est: CPU supports Enhanced Speedstep, but is not recognized. Mar 26 11:43:24 w2fzz0vc03 kernel: est: cpu_vendor GenuineIntel, msr a2a0a2a86000a2a Mar 26 11:43:24 w2fzz0vc03 kernel: device_attach: est1 attach returned 6 Mar 26 11:43:24 w2fzz0vc03 kernel: p4tcc1: on cpu1 Mar 26 11:43:24 w2fzz0vc03 kernel: cpu2: on acpi0 Mar 26 11:43:24 w2fzz0vc03 kernel: est2: on cpu2 Mar 26 11:43:24 w2fzz0vc03 kernel: est: CPU supports Enhanced Speedstep, but is not recognized. Mar 26 11:43:24 w2fzz0vc03 kernel: est: cpu_vendor GenuineIntel, msr a2a0a2a86000a2a Mar 26 11:43:24 w2fzz0vc03 kernel: device_attach: est2 attach returned 6 Mar 26 11:43:24 w2fzz0vc03 kernel: p4tcc2: on cpu2 Mar 26 11:43:24 w2fzz0vc03 kernel: cpu3: on acpi0 Mar 26 11:43:24 w2fzz0vc03 kernel: est3: on cpu3 Mar 26 11:43:24 w2fzz0vc03 kernel: est: CPU supports Enhanced Speedstep, but is not recognized. Mar 26 11:43:24 w2fzz0vc03 kernel: est: cpu_vendor GenuineIntel, msr a2a0a2a86000a2a Mar 26 11:43:24 w2fzz0vc03 kernel: device_attach: est3 attach returned 6 Mar 26 11:43:24 w2fzz0vc03 kernel: p4tcc3: on cpu3 Mar 26 11:43:24 w2fzz0vc03 kernel: orm0: at iomem 0xc0000-0xcc7ff,0xcc800-0xce7ff,0xce800-0xcffff on isa0 Mar 26 11:43:24 w2fzz0vc03 kernel: sc0: at flags 0x100 on isa0 Mar 26 11:43:24 w2fzz0vc03 kernel: sc0: VGA <16 virtual consoles, flags=0x300> Mar 26 11:43:24 w2fzz0vc03 kernel: vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 Mar 26 11:43:24 w2fzz0vc03 kernel: ppc0: cannot reserve I/O port range Mar 26 11:43:24 w2fzz0vc03 kernel: WARNING: ZFS is considered to be an experimental feature in FreeBSD. Mar 26 11:43:24 w2fzz0vc03 kernel: Timecounters tick every 1.000 msec Mar 26 11:43:24 w2fzz0vc03 kernel: firewire0: 1 nodes, maxhop <= 0 cable IRM irm(0) (me) Mar 26 11:43:24 w2fzz0vc03 kernel: firewire0: bus manager 0 Mar 26 11:43:24 w2fzz0vc03 kernel: usbus0: 12Mbps Full Speed USB v1.0 Mar 26 11:43:24 w2fzz0vc03 kernel: usbus1: 480Mbps High Speed USB v2.0 Mar 26 11:43:24 w2fzz0vc03 kernel: ZFS filesystem version 13 Mar 26 11:43:24 w2fzz0vc03 kernel: ZFS storage pool version 13 Mar 26 11:43:24 w2fzz0vc03 kernel: ugen0.1: at usbus0 Mar 26 11:43:24 w2fzz0vc03 kernel: uhub0: on usbus0 Mar 26 11:43:24 w2fzz0vc03 kernel: ugen1.1: at usbus1 Mar 26 11:43:24 w2fzz0vc03 kernel: uhub1: on usbus1 Mar 26 11:43:24 w2fzz0vc03 kernel: ad4: 305245MB at ata2-master SATA300 Mar 26 11:43:24 w2fzz0vc03 kernel: GEOM: ad4s1: geometry does not match label (255h,63s != 16h,63s). Mar 26 11:43:24 w2fzz0vc03 kernel: ad6: 305245MB at ata3-master SATA300 Mar 26 11:43:24 w2fzz0vc03 kernel: acd0: CDRW at ata4-master SATA150 Mar 26 11:43:24 w2fzz0vc03 kernel: acd1: DVDR at ata5-master SATA150 Mar 26 11:43:24 w2fzz0vc03 kernel: GEOM_LABEL: Label for provider ad4s2 is ntfs/System. Mar 26 11:43:24 w2fzz0vc03 kernel: ad12: 305245MB at ata6-master SATA300 Mar 26 11:43:24 w2fzz0vc03 kernel: ad14: 305245MB at ata7-master SATA300 Mar 26 11:43:24 w2fzz0vc03 kernel: uhub0: 10 ports with 10 removable, self powered Mar 26 11:43:24 w2fzz0vc03 kernel: uhub1: 10 ports with 10 removable, self powered Mar 26 11:43:24 w2fzz0vc03 kernel: lapic1: Forcing LINT1 to edge trigger Mar 26 11:43:24 w2fzz0vc03 kernel: SMP: AP CPU #1 Launched! Mar 26 11:43:24 w2fzz0vc03 kernel: lapic2: Forcing LINT1 to edge trigger Mar 26 11:43:24 w2fzz0vc03 kernel: SMP: AP CPU #2 Launched! Mar 26 11:43:24 w2fzz0vc03 kernel: lapic3: Forcing LINT1 to edge trigger Mar 26 11:43:24 w2fzz0vc03 kernel: SMP: AP CPU #3 Launched! Mar 26 11:43:24 w2fzz0vc03 kernel: WARNING: WITNESS option enabled, expect reduced performance. Mar 26 11:43:24 w2fzz0vc03 kernel: Root mount waiting for: usbus1 Mar 26 11:43:24 w2fzz0vc03 kernel: ugen1.2: at usbus1 Mar 26 11:43:24 w2fzz0vc03 kernel: Root mount waiting for: usbus1 Mar 26 11:43:24 w2fzz0vc03 kernel: ugen1.3: at usbus1 Mar 26 11:43:24 w2fzz0vc03 kernel: uhub2: on usbus1 Mar 26 11:43:24 w2fzz0vc03 kernel: uhub2: 7 ports with 7 removable, self powered Mar 26 11:43:24 w2fzz0vc03 kernel: Root mount waiting for: usbus1 Mar 26 11:43:24 w2fzz0vc03 kernel: ugen0.2: at usbus0 Mar 26 11:43:24 w2fzz0vc03 kernel: ugen1.4: at usbus1 Mar 26 11:43:24 w2fzz0vc03 kernel: rum0: on usbus1 Mar 26 11:43:24 w2fzz0vc03 kernel: rum0: MAC/BBP RT2573 (rev 0x2573a), RF RT2528 Mar 26 11:43:24 w2fzz0vc03 kernel: Root mount waiting for: usbus1 Mar 26 11:43:24 w2fzz0vc03 kernel: ugen1.5: at usbus1 Mar 26 11:43:24 w2fzz0vc03 kernel: umass0: on usbus1 Mar 26 11:43:24 w2fzz0vc03 kernel: umass0: SCSI over Bulk-Only; quirks = 0x0000 Mar 26 11:43:24 w2fzz0vc03 kernel: Root mount waiting for: usbus1 Mar 26 11:43:24 w2fzz0vc03 kernel: umass0:1:0:-1: Attached to scbus1 Mar 26 11:43:24 w2fzz0vc03 kernel: Trying to mount root from zfs:pool Mar 26 11:43:24 w2fzz0vc03 kernel: (probe0:umass-sim0:0:0:0): TEST UNIT READY. CDB: 0 0 0 0 0 0 Mar 26 11:43:24 w2fzz0vc03 kernel: (probe0:umass-sim0:0:0:0): CAM Status: SCSI Status Error Mar 26 11:43:24 w2fzz0vc03 kernel: (probe0:umass-sim0:0:0:0): SCSI Status: Check Condition Mar 26 11:43:24 w2fzz0vc03 kernel: (probe0:umass-sim0:0:0:0): NOT READY asc:3a,0 Mar 26 11:43:24 w2fzz0vc03 kernel: (probe0:umass-sim0:0:0:0): Medium not present Mar 26 11:43:24 w2fzz0vc03 kernel: (probe0:umass-sim0:0:0:0): Unretryable error Mar 26 11:43:24 w2fzz0vc03 kernel: da0 at umass-sim0 bus 0 target 0 lun 0 Mar 26 11:43:24 w2fzz0vc03 kernel: da0: Removable Direct Access SCSI-0 device Mar 26 11:43:24 w2fzz0vc03 kernel: da0: 40.000MB/s transfers Mar 26 11:43:24 w2fzz0vc03 kernel: da0: Attempt to query device size failed: NOT READY, Medium not present Mar 26 11:43:24 w2fzz0vc03 kernel: (probe0:umass-sim0:0:0:1): TEST UNIT READY. CDB: 0 20 0 0 0 0 Mar 26 11:43:24 w2fzz0vc03 kernel: (probe0:umass-sim0:0:0:1): CAM Status: SCSI Status Error Mar 26 11:43:24 w2fzz0vc03 kernel: (probe0:umass-sim0:0:0:1): SCSI Status: Check Condition Mar 26 11:43:24 w2fzz0vc03 kernel: (probe0:umass-sim0:0:0:1): NOT READY asc:3a,0 Mar 26 11:43:24 w2fzz0vc03 kernel: (probe0:umass-sim0:0:0:1): Medium not present Mar 26 11:43:24 w2fzz0vc03 kernel: (probe0:umass-sim0:0:0:1): Unretryable error Mar 26 11:43:24 w2fzz0vc03 kernel: da1 at umass-sim0 bus 0 target 0 lun 1 Mar 26 11:43:24 w2fzz0vc03 kernel: da1: Removable Direct Access SCSI-0 device Mar 26 11:43:24 w2fzz0vc03 kernel: da1: 40.000MB/s transfers Mar 26 11:43:24 w2fzz0vc03 kernel: da1: Attempt to query device size failed: NOT READY, Medium not present Mar 26 11:43:24 w2fzz0vc03 kernel: (probe0:umass-sim0:0:0:2): TEST UNIT READY. CDB: 0 40 0 0 0 0 Mar 26 11:43:24 w2fzz0vc03 kernel: (probe0:umass-sim0:0:0:2): CAM Status: SCSI Status Error Mar 26 11:43:24 w2fzz0vc03 kernel: (probe0:umass-sim0:0:0:2): SCSI Status: Check Condition Mar 26 11:43:24 w2fzz0vc03 kernel: (probe0:umass-sim0:0:0:2): NOT READY asc:3a,0 Mar 26 11:43:24 w2fzz0vc03 kernel: (probe0:umass-sim0:0:0:2): Medium not present Mar 26 11:43:24 w2fzz0vc03 kernel: (probe0:umass-sim0:0:0:2): Unretryable error Mar 26 11:43:24 w2fzz0vc03 kernel: da2 at umass-sim0 bus 0 target 0 lun 2 Mar 26 11:43:24 w2fzz0vc03 kernel: da2: Removable Direct Access SCSI-0 device Mar 26 11:43:24 w2fzz0vc03 kernel: da2: 40.000MB/s transfers Mar 26 11:43:24 w2fzz0vc03 kernel: da2: Attempt to query device size failed: NOT READY, Medium not present Mar 26 11:43:24 w2fzz0vc03 kernel: (probe0:umass-sim0:0:0:3): TEST UNIT READY. CDB: 0 60 0 0 0 0 Mar 26 11:43:24 w2fzz0vc03 kernel: (probe0:umass-sim0:0:0:3): CAM Status: SCSI Status Error Mar 26 11:43:24 w2fzz0vc03 kernel: (probe0:umass-sim0:0:0:3): SCSI Status: Check Condition Mar 26 11:43:24 w2fzz0vc03 kernel: (probe0:umass-sim0:0:0:3): NOT READY asc:3a,0 Mar 26 11:43:24 w2fzz0vc03 kernel: (probe0:umass-sim0:0:0:3): Medium not present Mar 26 11:43:24 w2fzz0vc03 kernel: (probe0:umass-sim0:0:0:3): Unretryable error Mar 26 11:43:24 w2fzz0vc03 kernel: da3 at umass-sim0 bus 0 target 0 lun 3 Mar 26 11:43:24 w2fzz0vc03 kernel: da3: Removable Direct Access SCSI-0 device Mar 26 11:43:24 w2fzz0vc03 kernel: da3: 40.000MB/s transfers Mar 26 11:43:24 w2fzz0vc03 kernel: da3: Attempt to query device size failed: NOT READY, Medium not present Mar 26 11:43:24 w2fzz0vc03 kernel: wlan0: Ethernet address: 00:17:3f:72:40:90 Mar 26 11:43:24 w2fzz0vc03 kernel: wlan0: link state changed to UP Mar 26 11:43:24 w2fzz0vc03 root: /etc/rc: WARNING: Unable to load kernel module linux Mar 26 11:43:24 w2fzz0vc03 kernel: KLD linux.ko: depends on kernel - not available Mar 26 11:43:24 w2fzz0vc03 kernel: linker_load_file: Unsupported file type Mar 26 11:43:34 w2fzz0vc03 auditd[1027]: Auditing disabled Mar 26 11:43:34 w2fzz0vc03 auditd[1027]: Auditing enabled Mar 26 11:43:34 w2fzz0vc03 auditd[1027]: New audit file is /var/audit/20090326114334.not_terminated Mar 26 11:43:34 w2fzz0vc03 auditd[1027]: audit_control(5) may be missing 'host:' field Mar 26 11:43:36 w2fzz0vc03 mDNSResponder (Engineering Build) (Mar 15 2009 06:30:34) [1257]: starting Mar 26 11:43:38 w2fzz0vc03 root: /etc/rc: WARNING: Unable to load kernel module daemon_saver Mar 26 11:43:38 w2fzz0vc03 kernel: KLD daemon_saver.ko: depends on kernel - not available Mar 26 11:43:38 w2fzz0vc03 kernel: linker_load_file: Unsupported file type Mar 26 11:43:44 w2fzz0vc03 login: ROOT LOGIN (root) ON ttyv0 Mar 26 11:44:38 w2fzz0vc03 root: ZFS: checksum mismatch, zpool=pool path=/dev/ad4s1d offset=10219988992 size=1024 Mar 26 11:44:38 w2fzz0vc03 root: ZFS: checksum mismatch, zpool=pool path=/dev/ad6s1d offset=10219988992 size=1024 Mar 26 11:44:38 w2fzz0vc03 root: ZFS: checksum mismatch, zpool=pool path=/dev/ad12s1d offset=10219988992 size=1024 Mar 26 11:44:38 w2fzz0vc03 root: ZFS: checksum mismatch, zpool=pool path=/dev/ad14s1d offset=10219988992 size=1024 Mar 26 11:44:38 w2fzz0vc03 root: ZFS: checksum mismatch, zpool=pool path=/dev/ad4s1d offset=10219987968 size=1024 Mar 26 11:44:38 w2fzz0vc03 root: ZFS: checksum mismatch, zpool=pool path=/dev/ad6s1d offset=10219987968 size=1024 Mar 26 11:44:38 w2fzz0vc03 root: ZFS: checksum mismatch, zpool=pool path=/dev/ad12s1d offset=10219987968 size=1024 Mar 26 11:44:38 w2fzz0vc03 root: ZFS: checksum mismatch, zpool=pool path=/dev/ad14s1d offset=10219987968 size=1024 Mar 26 11:46:41 w2fzz0vc03 root: ZFS: checksum mismatch, zpool=pool path=/dev/ad6s1d offset=21951923712 size=43520 Mar 26 11:54:15 w2fzz0vc03 root: ZFS: checksum mismatch, zpool=pool path=/dev/ad4s1d offset=24271335424 size=43520 Mar 26 11:54:15 w2fzz0vc03 root: ZFS: checksum mismatch, zpool=pool path=/dev/ad4s1d offset=24271571968 size=43520 Mar 26 11:54:20 w2fzz0vc03 root: ZFS: checksum mismatch, zpool=pool path=/dev/ad12s1d offset=13390609408 size=44032 Mar 26 11:54:20 w2fzz0vc03 root: ZFS: checksum mismatch, zpool=pool path=/dev/ad12s1d offset=13390653440 size=43520 Mar 26 11:54:20 w2fzz0vc03 root: ZFS: checksum mismatch, zpool=pool path=/dev/ad12s1d offset=13390696960 size=44032 Mar 26 11:54:20 w2fzz0vc03 root: ZFS: checksum mismatch, zpool=pool path=/dev/ad6s1d offset=28034315776 size=43520 Mar 26 11:54:20 w2fzz0vc03 root: ZFS: checksum mismatch, zpool=pool path=/dev/ad14s1d offset=21932119040 size=44032 Mar 26 11:54:22 w2fzz0vc03 root: ZFS: checksum mismatch, zpool=pool path=/dev/ad14s1d offset=27012382208 size=43520 Mar 26 11:54:22 w2fzz0vc03 root: ZFS: checksum mismatch, zpool=pool path=/dev/ad14s1d offset=27012425728 size=44032 Mar 26 11:54:22 w2fzz0vc03 root: ZFS: checksum mismatch, zpool=pool path=/dev/ad14s1d offset=27012469760 size=43520 Mar 26 11:54:25 w2fzz0vc03 root: ZFS: checksum mismatch, zpool=pool path=/dev/ad12s1d offset=21830071296 size=43520 Mar 26 11:54:25 w2fzz0vc03 root: ZFS: checksum mismatch, zpool=pool path=/dev/ad12s1d offset=29022763520 size=44032 Mar 26 11:54:28 w2fzz0vc03 root: ZFS: checksum mismatch, zpool=pool path=/dev/ad14s1d offset=21707188736 size=44032 Mar 26 11:54:28 w2fzz0vc03 root: ZFS: checksum mismatch, zpool=pool path=/dev/ad14s1d offset=21707276288 size=44032 Mar 26 11:54:29 w2fzz0vc03 root: ZFS: checksum mismatch, zpool=pool path=/dev/ad6s1d offset=21663055872 size=43520 Mar 26 11:54:29 w2fzz0vc03 root: ZFS: checksum mismatch, zpool=pool path=/dev/ad12s1d offset=27132336640 size=43520 Mar 26 11:54:30 w2fzz0vc03 root: ZFS: checksum mismatch, zpool=pool path=/dev/ad14s1d offset=4267522048 size=43520 Mar 26 11:54:32 w2fzz0vc03 root: ZFS: checksum mismatch, zpool=pool path=/dev/ad4s1d offset=4481742848 size=43520 Mar 26 11:54:32 w2fzz0vc03 root: ZFS: checksum mismatch, zpool=pool path=/dev/ad14s1d offset=4481698816 size=43520 Mar 26 11:54:32 w2fzz0vc03 root: ZFS: checksum mismatch, zpool=pool path=/dev/ad6s1d offset=21925431808 size=43520 Mar 26 11:54:32 w2fzz0vc03 root: ZFS: checksum mismatch, zpool=pool path=/dev/ad6s1d offset=21925519360 size=43520 Mar 26 11:54:32 w2fzz0vc03 root: ZFS: checksum mismatch, zpool=pool path=/dev/ad12s1d offset=21925562880 size=43520 Mar 26 11:54:34 w2fzz0vc03 root: ZFS: checksum mismatch, zpool=pool path=/dev/ad14s1d offset=13191209984 size=44032 Mar 26 11:54:37 w2fzz0vc03 root: ZFS: checksum mismatch, zpool=pool path=/dev/ad14s1d offset=4366682112 size=43520 Mar 26 11:54:41 w2fzz0vc03 root: ZFS: checksum mismatch, zpool=pool path=/dev/ad12s1d offset=4812235264 size=43520 Mar 26 11:54:41 w2fzz0vc03 root: ZFS: checksum mismatch, zpool=pool path=/dev/ad12s1d offset=4812278784 size=44032 Mar 26 12:05:34 w2fzz0vc03 root: ZFS: checksum mismatch, zpool=pool path=/dev/ad6s1d offset=10248565760 size=512 Mar 26 13:46:47 w2fzz0vc03 shutdown: reboot by root: Mar 26 13:46:53 w2fzz0vc03 mDNSResponder (Engineering Build) (Mar 15 2009 06:30:34) [1257]: stopping Mar 26 13:46:55 w2fzz0vc03 auditd[1027]: Auditing disabled Mar 26 13:46:55 w2fzz0vc03 auditd[1027]: renamed /var/audit/20090326114334.not_terminated to /var/audit/20090326114334.20090326134655 Mar 26 13:46:55 w2fzz0vc03 root: audit warning: closefile /var/audit/20090326114334.20090326134655 Mar 26 13:46:56 w2fzz0vc03 syslogd: exiting on signal 15 Mar 26 13:48:05 w2fzz0vc03 syslogd: kernel boot file is /boot/kernel.good/kernel Mar 26 13:48:05 w2fzz0vc03 kernel: Copyright (c) 1992-2009 The FreeBSD Project. Mar 26 13:48:05 w2fzz0vc03 kernel: Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 Mar 26 13:48:05 w2fzz0vc03 kernel: The Regents of the University of California. All rights reserved. Mar 26 13:48:05 w2fzz0vc03 kernel: FreeBSD is a registered trademark of The FreeBSD Foundation. Mar 26 13:48:05 w2fzz0vc03 kernel: FreeBSD 8.0-CURRENT #1 r189454M: Fri Mar 6 18:46:25 GMT 2009 Mar 26 13:48:05 w2fzz0vc03 kernel: root@w2fzz0vc03.aah-go-on.com:/usr/obj/usr/src/sys/GENERIC Mar 26 13:48:05 w2fzz0vc03 kernel: WARNING: WITNESS option enabled, expect reduced performance. Mar 26 13:48:05 w2fzz0vc03 kernel: Preloaded elf kernel "/boot/kernel.good/kernel" at 0xffffffff810ce000. Mar 26 13:48:05 w2fzz0vc03 kernel: Preloaded elf obj module "/boot/kernel.good/zfs.ko" at 0xffffffff810ce210. Mar 26 13:48:05 w2fzz0vc03 kernel: Preloaded elf obj module "/boot/kernel.good/opensolaris.ko" at 0xffffffff810ce880. Mar 26 13:48:05 w2fzz0vc03 kernel: Preloaded /boot/zfs/zpool.cache "/boot/zfs/zpool.cache" at 0xffffffff810cee78. Mar 26 13:48:05 w2fzz0vc03 kernel: Timecounter "i8254" frequency 1193182 Hz quality 0 Mar 26 13:48:05 w2fzz0vc03 kernel: Calibrating TSC clock ... TSC clock: 2660045340 Hz Mar 26 13:48:05 w2fzz0vc03 kernel: CPU: Intel(R) Core(TM)2 Quad CPU @ 2.66GHz (2660.05-MHz K8-class CPU) Mar 26 13:48:05 w2fzz0vc03 kernel: Origin = "GenuineIntel" Id = 0x6f7 Stepping = 7 Mar 26 13:48:05 w2fzz0vc03 kernel: Features=0xbfebfbff Mar 26 13:48:05 w2fzz0vc03 kernel: Features2=0xe3bd Mar 26 13:48:05 w2fzz0vc03 kernel: AMD Features=0x20100800 Mar 26 13:48:05 w2fzz0vc03 kernel: AMD Features2=0x1 Mar 26 13:48:05 w2fzz0vc03 kernel: TSC: P-state invariant Mar 26 13:48:05 w2fzz0vc03 kernel: Cores per package: 4 Mar 26 13:48:05 w2fzz0vc03 kernel: usable memory = 4275412992 (4077 MB) Mar 26 13:48:05 w2fzz0vc03 kernel: Physical memory chunk(s): Mar 26 13:48:05 w2fzz0vc03 kernel: 0x0000000000001000 - 0x000000000009bfff, 634880 bytes (155 pages) Mar 26 13:48:05 w2fzz0vc03 kernel: 0x00000000010fd000 - 0x0000000096333fff, 2502127616 bytes (610871 pages) Mar 26 13:48:05 w2fzz0vc03 kernel: 0x0000000100000000 - 0x000000015ffeffff, 1610547200 bytes (393200 pages) Mar 26 13:48:05 w2fzz0vc03 kernel: avail memory = 4090191872 (3900 MB) Mar 26 13:48:05 w2fzz0vc03 kernel: ACPI APIC Table: Mar 26 13:48:05 w2fzz0vc03 kernel: INTR: Adding local APIC 1 as a target Mar 26 13:48:05 w2fzz0vc03 kernel: INTR: Adding local APIC 2 as a target Mar 26 13:48:05 w2fzz0vc03 kernel: INTR: Adding local APIC 3 as a target Mar 26 13:48:05 w2fzz0vc03 kernel: FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs Mar 26 13:48:05 w2fzz0vc03 kernel: cpu0 (BSP): APIC ID: 0 Mar 26 13:48:05 w2fzz0vc03 kernel: cpu1 (AP): APIC ID: 1 Mar 26 13:48:05 w2fzz0vc03 kernel: cpu2 (AP): APIC ID: 2 Mar 26 13:48:05 w2fzz0vc03 kernel: cpu3 (AP): APIC ID: 3 Mar 26 13:48:05 w2fzz0vc03 kernel: APIC: CPU 0 has ACPI ID 1 Mar 26 13:48:05 w2fzz0vc03 kernel: APIC: CPU 1 has ACPI ID 2 Mar 26 13:48:05 w2fzz0vc03 kernel: APIC: CPU 2 has ACPI ID 3 Mar 26 13:48:05 w2fzz0vc03 kernel: APIC: CPU 3 has ACPI ID 4 Mar 26 13:48:05 w2fzz0vc03 kernel: ULE: setup cpu 0 Mar 26 13:48:05 w2fzz0vc03 kernel: ULE: setup cpu 1 Mar 26 13:48:05 w2fzz0vc03 kernel: ULE: setup cpu 2 Mar 26 13:48:05 w2fzz0vc03 kernel: ULE: setup cpu 3 Mar 26 13:48:05 w2fzz0vc03 kernel: This module (opensolaris) contains code covered by the Mar 26 13:48:05 w2fzz0vc03 kernel: Common Development and Distribution License (CDDL) Mar 26 13:48:05 w2fzz0vc03 kernel: see http://opensolaris.org/os/licensing/opensolaris_license/ Mar 26 13:48:05 w2fzz0vc03 kernel: ACPI: RSDP @ 0x0xfebf0/0x0024 (v 2 DELL ) Mar 26 13:48:05 w2fzz0vc03 kernel: ACPI: XSDT @ 0x0xfd0b9/0x0064 (v 1 DELL B8K 0x00000014 ASL 0x00000061) Mar 26 13:48:05 w2fzz0vc03 kernel: ACPI: FACP @ 0x0xfd191/0x00F4 (v 3 DELL B8K 0x00000014 ASL 0x00000061) Mar 26 13:48:05 w2fzz0vc03 kernel: ACPI: DSDT @ 0x0xfffc13b6/0x3F25 (v 1 DELL dt_ex 0x00001000 INTL 0x20050624) Mar 26 13:48:05 w2fzz0vc03 kernel: ACPI: FACS @ 0x0x9fdbcc00/0x0040 Mar 26 13:48:05 w2fzz0vc03 kernel: ACPI: SSDT @ 0x0xfffc52db/0x0099 (v 1 DELL st_ex 0x00001000 INTL 0x20050624) Mar 26 13:48:05 w2fzz0vc03 kernel: ACPI: APIC @ 0x0xfd285/0x0092 (v 1 DELL B8K 0x00000014 ASL 0x00000061) Mar 26 13:48:05 w2fzz0vc03 kernel: ACPI: BOOT @ 0x0xfd317/0x0028 (v 1 DELL B8K 0x00000014 ASL 0x00000061) Mar 26 13:48:05 w2fzz0vc03 kernel: ACPI: MCFG @ 0x0xfd33f/0x003E (v 1 DELL B8K 0x00000014 ASL 0x00000061) Mar 26 13:48:05 w2fzz0vc03 kernel: ACPI: HPET @ 0x0xfd37d/0x0038 (v 1 DELL B8K 0x00000014 ASL 0x00000061) Mar 26 13:48:05 w2fzz0vc03 kernel: ACPI: DUMY @ 0x0x9fdbec00/0x0024 (v 1 DELL B8K 0x00000014 ASL 0x00000061) Mar 26 13:48:05 w2fzz0vc03 kernel: ACPI: SLIC @ 0x0xfd3b5/0x0176 (v 1 DELL B8K 0x00000014 ASL 0x00000061) Mar 26 13:48:05 w2fzz0vc03 kernel: MADT: Found IO APIC ID 8, Interrupt 0 at 0xfec00000 Mar 26 13:48:05 w2fzz0vc03 kernel: ioapic0: Changing APIC ID to 8 Mar 26 13:48:05 w2fzz0vc03 kernel: ioapic0: Routing external 8259A's -> intpin 0 Mar 26 13:48:05 w2fzz0vc03 kernel: MADT: Interrupt override: source 0, irq 2 Mar 26 13:48:05 w2fzz0vc03 kernel: ioapic0: Routing IRQ 0 -> intpin 2 Mar 26 13:48:05 w2fzz0vc03 kernel: MADT: Interrupt override: source 9, irq 9 Mar 26 13:48:05 w2fzz0vc03 kernel: ioapic0: intpin 9 trigger: level Mar 26 13:48:05 w2fzz0vc03 kernel: lapic: Routing NMI -> LINT1 Mar 26 13:48:05 w2fzz0vc03 kernel: lapic: LINT1 trigger: level Mar 26 13:48:05 w2fzz0vc03 kernel: lapic: LINT1 polarity: high Mar 26 13:48:05 w2fzz0vc03 kernel: ioapic0 irqs 0-23 on motherboard Mar 26 13:48:05 w2fzz0vc03 kernel: lapic0: Forcing LINT1 to edge trigger Mar 26 13:48:05 w2fzz0vc03 kernel: cpu0 BSP: Mar 26 13:48:05 w2fzz0vc03 kernel: ID: 0x00000000 VER: 0x00050014 LDR: 0x00000000 DFR: 0xffffffff Mar 26 13:48:05 w2fzz0vc03 kernel: lint0: 0x00010700 lint1: 0x00008400 TPR: 0x00000000 SVR: 0x000001ff Mar 26 13:48:05 w2fzz0vc03 kernel: timer: 0x000100ef therm: 0x00010000 err: 0x00010000 pcm: 0x00000400 Mar 26 13:48:05 w2fzz0vc03 kernel: wlan: <802.11 Link Layer> Mar 26 13:48:05 w2fzz0vc03 kernel: random: Mar 26 13:48:05 w2fzz0vc03 kernel: nfslock: pseudo-device Mar 26 13:48:05 w2fzz0vc03 kernel: kbd: new array size 4 Mar 26 13:48:05 w2fzz0vc03 kernel: kbd1 at kbdmux0 Mar 26 13:48:05 w2fzz0vc03 kernel: mem: Mar 26 13:48:05 w2fzz0vc03 kernel: io: Mar 26 13:48:05 w2fzz0vc03 kernel: null: Mar 26 13:48:05 w2fzz0vc03 kernel: hptrr: RocketRAID 17xx/2xxx SATA controller driver v1.2 (Mar 6 2009 18:45:54) Mar 26 13:48:05 w2fzz0vc03 kernel: acpi0: on motherboard Mar 26 13:48:05 w2fzz0vc03 kernel: PCIe: Memory Mapped configuration base @ 0xe0000000 Mar 26 13:48:05 w2fzz0vc03 kernel: ioapic0: routing intpin 9 (ISA IRQ 9) to lapic 0 vector 48 Mar 26 13:48:05 w2fzz0vc03 kernel: acpi0: [MPSAFE] Mar 26 13:48:05 w2fzz0vc03 kernel: acpi0: [ITHREAD] Mar 26 13:48:05 w2fzz0vc03 kernel: acpi0: Power Button (fixed) Mar 26 13:48:05 w2fzz0vc03 kernel: acpi_bus_number: root bus has no _BBN, assuming 0 Mar 26 13:48:05 w2fzz0vc03 kernel: AcpiOsDerivePciId: \_SB_.PCI0.ISA_.P40C -> bus 0 dev 10 func 0 Mar 26 13:48:05 w2fzz0vc03 kernel: acpi0: reservation of 0, a0000 (3) failed Mar 26 13:48:05 w2fzz0vc03 kernel: acpi0: reservation of 100000, f00000 (3) failed Mar 26 13:48:05 w2fzz0vc03 kernel: acpi0: reservation of 1000000, 9edbcc00 (3) failed Mar 26 13:48:05 w2fzz0vc03 kernel: ACPI timer: 1/1 1/1 1/1 1/1 1/1 1/1 1/1 1/1 1/1 1/1 -> 10 Mar 26 13:48:05 w2fzz0vc03 kernel: Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 Mar 26 13:48:05 w2fzz0vc03 kernel: acpi_timer0: <24-bit timer at 3.579545MHz> port 0x4008-0x400b on acpi0 Mar 26 13:48:05 w2fzz0vc03 kernel: pci_link0: Index IRQ Rtd Ref IRQs Mar 26 13:48:05 w2fzz0vc03 kernel: Initial Probe 0 11 N 0 3 4 5 6 7 9 10 11 12 15 Mar 26 13:48:05 w2fzz0vc03 kernel: Validation 0 11 N 0 3 4 5 6 7 9 10 11 12 15 Mar 26 13:48:05 w2fzz0vc03 kernel: After Disable 0 255 N 0 3 4 5 6 7 9 10 11 12 15 Mar 26 13:48:05 w2fzz0vc03 kernel: pci_link1: Index IRQ Rtd Ref IRQs Mar 26 13:48:05 w2fzz0vc03 kernel: Initial Probe 0 10 N 0 3 4 5 6 7 9 10 11 12 15 Mar 26 13:48:05 w2fzz0vc03 kernel: Validation 0 10 N 0 3 4 5 6 7 9 10 11 12 15 Mar 26 13:48:05 w2fzz0vc03 kernel: After Disable 0 255 N 0 3 4 5 6 7 9 10 11 12 15 Mar 26 13:48:05 w2fzz0vc03 kernel: pci_link2: Index IRQ Rtd Ref IRQs Mar 26 13:48:05 w2fzz0vc03 kernel: Initial Probe 0 9 N 0 3 4 5 6 7 9 10 11 12 15 Mar 26 13:48:05 w2fzz0vc03 kernel: Validation 0 9 N 0 3 4 5 6 7 9 10 11 12 15 Mar 26 13:48:05 w2fzz0vc03 kernel: After Disable 0 255 N 0 3 4 5 6 7 9 10 11 12 15 Mar 26 13:48:05 w2fzz0vc03 kernel: pci_link3: Index IRQ Rtd Ref IRQs Mar 26 13:48:05 w2fzz0vc03 kernel: Initial Probe 0 255 N 0 3 4 5 6 7 9 10 11 12 15 Mar 26 13:48:05 w2fzz0vc03 kernel: Validation 0 255 N 0 3 4 5 6 7 9 10 11 12 15 Mar 26 13:48:05 w2fzz0vc03 kernel: After Disable 0 255 N 0 3 4 5 6 7 9 10 11 12 15 Mar 26 13:48:05 w2fzz0vc03 kernel: pci_link4: Index IRQ Rtd Ref IRQs Mar 26 13:48:05 w2fzz0vc03 kernel: Initial Probe 0 11 N 0 3 4 5 6 7 9 10 11 12 15 Mar 26 13:48:05 w2fzz0vc03 kernel: Validation 0 11 N 0 3 4 5 6 7 9 10 11 12 15 Mar 26 13:48:05 w2fzz0vc03 kernel: After Disable 0 255 N 0 3 4 5 6 7 9 10 11 12 15 Mar 26 13:48:05 w2fzz0vc03 kernel: pci_link5: Index IRQ Rtd Ref IRQs Mar 26 13:48:05 w2fzz0vc03 kernel: Initial Probe 0 10 N 0 3 4 5 6 7 9 10 11 12 15 Mar 26 13:48:05 w2fzz0vc03 kernel: Validation 0 10 N 0 3 4 5 6 7 9 10 11 12 15 Mar 26 13:48:05 w2fzz0vc03 kernel: After Disable 0 255 N 0 3 4 5 6 7 9 10 11 12 15 Mar 26 13:48:05 w2fzz0vc03 kernel: pci_link6: Index IRQ Rtd Ref IRQs Mar 26 13:48:05 w2fzz0vc03 kernel: Initial Probe 0 9 N 0 3 4 5 6 7 9 10 11 12 15 Mar 26 13:48:05 w2fzz0vc03 kernel: Validation 0 9 N 0 3 4 5 6 7 9 10 11 12 15 Mar 26 13:48:05 w2fzz0vc03 kernel: After Disable 0 255 N 0 3 4 5 6 7 9 10 11 12 15 Mar 26 13:48:05 w2fzz0vc03 kernel: pci_link7: Index IRQ Rtd Ref IRQs Mar 26 13:48:05 w2fzz0vc03 kernel: Initial Probe 0 255 N 0 3 4 5 6 7 9 10 11 12 15 Mar 26 13:48:05 w2fzz0vc03 kernel: Validation 0 255 N 0 3 4 5 6 7 9 10 11 12 15 Mar 26 13:48:05 w2fzz0vc03 kernel: After Disable 0 255 N 0 3 4 5 6 7 9 10 11 12 15 Mar 26 13:48:05 w2fzz0vc03 kernel: pci_link8: Index IRQ Rtd Ref IRQs Mar 26 13:48:05 w2fzz0vc03 kernel: Initial Probe 0 9 N 0 3 4 5 6 7 9 10 11 12 15 Mar 26 13:48:05 w2fzz0vc03 kernel: Validation 0 9 N 0 3 4 5 6 7 9 10 11 12 15 Mar 26 13:48:05 w2fzz0vc03 kernel: After Disable 0 255 N 0 3 4 5 6 7 9 10 11 12 15 Mar 26 13:48:05 w2fzz0vc03 kernel: pci_link9: Index IRQ Rtd Ref IRQs Mar 26 13:48:05 w2fzz0vc03 kernel: Initial Probe 0 10 N 0 3 4 5 6 7 9 10 11 12 15 Mar 26 13:48:05 w2fzz0vc03 kernel: Validation 0 10 N 0 3 4 5 6 7 9 10 11 12 15 Mar 26 13:48:05 w2fzz0vc03 kernel: After Disable 0 255 N 0 3 4 5 6 7 9 10 11 12 15 Mar 26 13:48:05 w2fzz0vc03 kernel: pci_link10: Index IRQ Rtd Ref IRQs Mar 26 13:48:05 w2fzz0vc03 kernel: Initial Probe 0 255 N 0 3 4 5 6 7 9 10 11 12 15 Mar 26 13:48:05 w2fzz0vc03 kernel: Validation 0 255 N 0 3 4 5 6 7 9 10 11 12 15 Mar 26 13:48:05 w2fzz0vc03 kernel: After Disable 0 255 N 0 3 4 5 6 7 9 10 11 12 15 Mar 26 13:48:05 w2fzz0vc03 kernel: pci_link11: Index IRQ Rtd Ref IRQs Mar 26 13:48:05 w2fzz0vc03 kernel: Initial Probe 0 11 N 0 3 4 5 6 7 9 10 11 12 15 Mar 26 13:48:05 w2fzz0vc03 kernel: Validation 0 11 N 0 3 4 5 6 7 9 10 11 12 15 Mar 26 13:48:05 w2fzz0vc03 kernel: After Disable 0 255 N 0 3 4 5 6 7 9 10 11 12 15 Mar 26 13:48:05 w2fzz0vc03 kernel: pci_link12: Index IRQ Rtd Ref IRQs Mar 26 13:48:05 w2fzz0vc03 kernel: Initial Probe 0 11 N 0 3 4 5 6 7 9 10 11 12 15 Mar 26 13:48:05 w2fzz0vc03 kernel: Validation 0 11 N 0 3 4 5 6 7 9 10 11 12 15 Mar 26 13:48:05 w2fzz0vc03 kernel: After Disable 0 255 N 0 3 4 5 6 7 9 10 11 12 15 Mar 26 13:48:05 w2fzz0vc03 kernel: pci_link13: Index IRQ Rtd Ref IRQs Mar 26 13:48:05 w2fzz0vc03 kernel: Initial Probe 0 10 N 0 3 4 5 6 7 9 10 11 12 15 Mar 26 13:48:05 w2fzz0vc03 kernel: Validation 0 10 N 0 3 4 5 6 7 9 10 11 12 15 Mar 26 13:48:05 w2fzz0vc03 kernel: After Disable 0 255 N 0 3 4 5 6 7 9 10 11 12 15 Mar 26 13:48:05 w2fzz0vc03 kernel: pci_link14: Index IRQ Rtd Ref IRQs Mar 26 13:48:05 w2fzz0vc03 kernel: Initial Probe 0 9 N 0 3 4 5 6 7 9 10 11 12 15 Mar 26 13:48:05 w2fzz0vc03 kernel: Validation 0 9 N 0 3 4 5 6 7 9 10 11 12 15 Mar 26 13:48:05 w2fzz0vc03 kernel: After Disable 0 255 N 0 3 4 5 6 7 9 10 11 12 15 Mar 26 13:48:05 w2fzz0vc03 kernel: pci_link15: Index IRQ Rtd Ref IRQs Mar 26 13:48:05 w2fzz0vc03 kernel: Initial Probe 0 14 N 0 3 4 5 6 7 9 10 11 12 15 Mar 26 13:48:05 w2fzz0vc03 kernel: Validation 0 255 N 0 3 4 5 6 7 9 10 11 12 15 Mar 26 13:48:05 w2fzz0vc03 kernel: After Disable 0 255 N 0 3 4 5 6 7 9 10 11 12 15 Mar 26 13:48:05 w2fzz0vc03 kernel: pci_link16: Index IRQ Rtd Ref IRQs Mar 26 13:48:05 w2fzz0vc03 kernel: Initial Probe 0 11 N 0 3 4 5 6 7 9 10 11 12 15 Mar 26 13:48:05 w2fzz0vc03 kernel: Validation 0 11 N 0 3 4 5 6 7 9 10 11 12 15 Mar 26 13:48:05 w2fzz0vc03 kernel: After Disable 0 255 N 0 3 4 5 6 7 9 10 11 12 15 Mar 26 13:48:05 w2fzz0vc03 kernel: pci_link17: Index IRQ Rtd Ref IRQs Mar 26 13:48:05 w2fzz0vc03 kernel: Initial Probe 0 255 N 0 16 Mar 26 13:48:05 w2fzz0vc03 kernel: Validation 0 255 N 0 16 Mar 26 13:48:05 w2fzz0vc03 kernel: After Disable 0 255 N 0 16 Mar 26 13:48:05 w2fzz0vc03 kernel: pci_link18: Index IRQ Rtd Ref IRQs Mar 26 13:48:05 w2fzz0vc03 kernel: Initial Probe 0 255 N 0 17 Mar 26 13:48:05 w2fzz0vc03 kernel: Validation 0 255 N 0 17 Mar 26 13:48:05 w2fzz0vc03 kernel: After Disable 0 255 N 0 17 Mar 26 13:48:05 w2fzz0vc03 kernel: pci_link19: Index IRQ Rtd Ref IRQs Mar 26 13:48:05 w2fzz0vc03 kernel: Initial Probe 0 255 N 0 18 Mar 26 13:48:05 w2fzz0vc03 kernel: Validation 0 255 N 0 18 Mar 26 13:48:05 w2fzz0vc03 kernel: After Disable 0 255 N 0 18 Mar 26 13:48:05 w2fzz0vc03 kernel: pci_link20: Index IRQ Rtd Ref IRQs Mar 26 13:48:05 w2fzz0vc03 kernel: Initial Probe 0 255 N 0 19 Mar 26 13:48:05 w2fzz0vc03 kernel: Validation 0 255 N 0 19 Mar 26 13:48:05 w2fzz0vc03 kernel: After Disable 0 255 N 0 19 Mar 26 13:48:05 w2fzz0vc03 kernel: pci_link21: Index IRQ Rtd Ref IRQs Mar 26 13:48:05 w2fzz0vc03 kernel: Initial Probe 0 255 N 0 16 Mar 26 13:48:05 w2fzz0vc03 kernel: Validation 0 255 N 0 16 Mar 26 13:48:05 w2fzz0vc03 kernel: After Disable 0 255 N 0 16 Mar 26 13:48:05 w2fzz0vc03 kernel: pci_link22: Index IRQ Rtd Ref IRQs Mar 26 13:48:05 w2fzz0vc03 kernel: Initial Probe 0 255 N 0 17 Mar 26 13:48:05 w2fzz0vc03 kernel: Validation 0 255 N 0 17 Mar 26 13:48:05 w2fzz0vc03 kernel: After Disable 0 255 N 0 17 Mar 26 13:48:05 w2fzz0vc03 kernel: pci_link23: Index IRQ Rtd Ref IRQs Mar 26 13:48:05 w2fzz0vc03 kernel: Initial Probe 0 255 N 0 18 Mar 26 13:48:05 w2fzz0vc03 kernel: Validation 0 255 N 0 18 Mar 26 13:48:05 w2fzz0vc03 kernel: After Disable 0 255 N 0 18 Mar 26 13:48:05 w2fzz0vc03 kernel: pci_link24: Index IRQ Rtd Ref IRQs Mar 26 13:48:05 w2fzz0vc03 kernel: Initial Probe 0 255 N 0 19 Mar 26 13:48:05 w2fzz0vc03 kernel: Validation 0 255 N 0 19 Mar 26 13:48:05 w2fzz0vc03 kernel: After Disable 0 255 N 0 19 Mar 26 13:48:05 w2fzz0vc03 kernel: pci_link25: Index IRQ Rtd Ref IRQs Mar 26 13:48:05 w2fzz0vc03 kernel: Initial Probe 0 255 N 0 20 21 22 23 Mar 26 13:48:05 w2fzz0vc03 kernel: Validation 0 255 N 0 20 21 22 23 Mar 26 13:48:05 w2fzz0vc03 kernel: After Disable 0 255 N 0 20 21 22 23 Mar 26 13:48:05 w2fzz0vc03 kernel: pci_link26: Index IRQ Rtd Ref IRQs Mar 26 13:48:05 w2fzz0vc03 kernel: Initial Probe 0 255 N 0 20 21 22 23 Mar 26 13:48:05 w2fzz0vc03 kernel: Validation 0 255 N 0 20 21 22 23 Mar 26 13:48:05 w2fzz0vc03 kernel: After Disable 0 255 N 0 20 21 22 23 Mar 26 13:48:05 w2fzz0vc03 kernel: pci_link27: Index IRQ Rtd Ref IRQs Mar 26 13:48:05 w2fzz0vc03 kernel: Initial Probe 0 255 N 0 20 21 22 23 Mar 26 13:48:05 w2fzz0vc03 kernel: Validation 0 255 N 0 20 21 22 23 Mar 26 13:48:05 w2fzz0vc03 kernel: After Disable 0 255 N 0 20 21 22 23 Mar 26 13:48:05 w2fzz0vc03 kernel: pci_link28: Index IRQ Rtd Ref IRQs Mar 26 13:48:05 w2fzz0vc03 kernel: Initial Probe 0 255 N 0 20 21 22 23 Mar 26 13:48:05 w2fzz0vc03 kernel: Validation 0 255 N 0 20 21 22 23 Mar 26 13:48:05 w2fzz0vc03 kernel: After Disable 0 255 N 0 20 21 22 23 Mar 26 13:48:05 w2fzz0vc03 kernel: pci_link29: Index IRQ Rtd Ref IRQs Mar 26 13:48:05 w2fzz0vc03 kernel: Initial Probe 0 255 N 0 20 21 22 23 Mar 26 13:48:05 w2fzz0vc03 kernel: Validation 0 255 N 0 20 21 22 23 Mar 26 13:48:05 w2fzz0vc03 kernel: After Disable 0 255 N 0 20 21 22 23 Mar 26 13:48:05 w2fzz0vc03 kernel: pci_link30: Index IRQ Rtd Ref IRQs Mar 26 13:48:05 w2fzz0vc03 kernel: Initial Probe 0 255 N 0 20 21 22 23 Mar 26 13:48:05 w2fzz0vc03 kernel: Validation 0 255 N 0 20 21 22 23 Mar 26 13:48:05 w2fzz0vc03 kernel: After Disable 0 255 N 0 20 21 22 23 Mar 26 13:48:05 w2fzz0vc03 kernel: pci_link31: Index IRQ Rtd Ref IRQs Mar 26 13:48:05 w2fzz0vc03 kernel: Initial Probe 0 255 N 0 20 21 22 23 Mar 26 13:48:05 w2fzz0vc03 kernel: Validation 0 255 N 0 20 21 22 23 Mar 26 13:48:05 w2fzz0vc03 kernel: After Disable 0 255 N 0 20 21 22 23 Mar 26 13:48:05 w2fzz0vc03 kernel: pci_link32: Index IRQ Rtd Ref IRQs Mar 26 13:48:05 w2fzz0vc03 kernel: Initial Probe 0 255 N 0 20 21 22 23 Mar 26 13:48:05 w2fzz0vc03 kernel: Validation 0 255 N 0 20 21 22 23 Mar 26 13:48:05 w2fzz0vc03 kernel: After Disable 0 255 N 0 20 21 22 23 Mar 26 13:48:05 w2fzz0vc03 kernel: pci_link33: Index IRQ Rtd Ref IRQs Mar 26 13:48:05 w2fzz0vc03 kernel: Initial Probe 0 255 N 0 20 21 22 23 Mar 26 13:48:05 w2fzz0vc03 kernel: Validation 0 255 N 0 20 21 22 23 Mar 26 13:48:05 w2fzz0vc03 kernel: After Disable 0 255 N 0 20 21 22 23 Mar 26 13:48:05 w2fzz0vc03 kernel: acpi_hpet0: iomem 0xfed00000-0xfed003ff on acpi0 Mar 26 13:48:05 w2fzz0vc03 kernel: acpi_hpet0: vend: 0x10de rev: 0x1 num: 2 hz: 25000000 opts: legacy_route Mar 26 13:48:05 w2fzz0vc03 kernel: Timecounter "HPET" frequency 25000000 Hz quality 900 Mar 26 13:48:05 w2fzz0vc03 kernel: acpi_button0: on acpi0 Mar 26 13:48:05 w2fzz0vc03 kernel: pcib0: port 0xcf8-0xcff on acpi0 Mar 26 13:48:05 w2fzz0vc03 kernel: pci0: on pcib0 Mar 26 13:48:05 w2fzz0vc03 kernel: pci0: domain=0, physical bus=0 Mar 26 13:48:05 w2fzz0vc03 kernel: found-> vendor=0x10de, dev=0x0071, revid=0xc1 Mar 26 13:48:05 w2fzz0vc03 kernel: domain=0, bus=0, slot=0, func=0 Mar 26 13:48:05 w2fzz0vc03 kernel: class=06-00-00, hdrtype=0x00, mfdev=1 Mar 26 13:48:05 w2fzz0vc03 kernel: cmdreg=0x0006, statreg=0x00b0, cachelnsz=0 (dwords) Mar 26 13:48:05 w2fzz0vc03 kernel: lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) Mar 26 13:48:05 w2fzz0vc03 kernel: found-> vendor=0x10de, dev=0x007f, revid=0xa1 Mar 26 13:48:05 w2fzz0vc03 kernel: domain=0, bus=0, slot=0, func=1 Mar 26 13:48:05 w2fzz0vc03 kernel: class=05-00-00, hdrtype=0x00, mfdev=1 Mar 26 13:48:05 w2fzz0vc03 kernel: cmdreg=0x0100, statreg=0x0020, cachelnsz=0 (dwords) Mar 26 13:48:05 w2fzz0vc03 kernel: lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) Mar 26 13:48:05 w2fzz0vc03 kernel: found-> vendor=0x10de, dev=0x0075, revid=0xa1 Mar 26 13:48:05 w2fzz0vc03 kernel: domain=0, bus=0, slot=0, func=2 Mar 26 13:48:05 w2fzz0vc03 kernel: class=05-00-00, hdrtype=0x00, mfdev=1 Mar 26 13:48:05 w2fzz0vc03 kernel: cmdreg=0x0000, statreg=0x0020, cachelnsz=0 (dwords) Mar 26 13:48:05 w2fzz0vc03 kernel: lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) Mar 26 13:48:05 w2fzz0vc03 kernel: found-> vendor=0x10de, dev=0x006f, revid=0xa1 Mar 26 13:48:05 w2fzz0vc03 kernel: domain=0, bus=0, slot=0, func=3 Mar 26 13:48:05 w2fzz0vc03 kernel: class=05-00-00, hdrtype=0x00, mfdev=0 Mar 26 13:48:05 w2fzz0vc03 kernel: cmdreg=0x0100, statreg=0x00a0, cachelnsz=0 (dwords) Mar 26 13:48:05 w2fzz0vc03 kernel: lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) Mar 26 13:48:05 w2fzz0vc03 kernel: found-> vendor=0x10de, dev=0x00b4, revid=0xa1 Mar 26 13:48:05 w2fzz0vc03 kernel: domain=0, bus=0, slot=0, func=4 Mar 26 13:48:05 w2fzz0vc03 kernel: class=05-00-00, hdrtype=0x00, mfdev=0 Mar 26 13:48:05 w2fzz0vc03 kernel: cmdreg=0x0106, statreg=0x00a0, cachelnsz=0 (dwords) Mar 26 13:48:05 w2fzz0vc03 kernel: lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) Mar 26 13:48:05 w2fzz0vc03 kernel: found-> vendor=0x10de, dev=0x0076, revid=0xa1 Mar 26 13:48:05 w2fzz0vc03 kernel: domain=0, bus=0, slot=1, func=0 Mar 26 13:48:05 w2fzz0vc03 kernel: class=05-00-00, hdrtype=0x00, mfdev=1 Mar 26 13:48:05 w2fzz0vc03 kernel: cmdreg=0x0000, statreg=0x0020, cachelnsz=0 (dwords) Mar 26 13:48:05 w2fzz0vc03 kernel: lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) Mar 26 13:48:05 w2fzz0vc03 kernel: found-> vendor=0x10de, dev=0x0078, revid=0xa1 Mar 26 13:48:05 w2fzz0vc03 kernel: domain=0, bus=0, slot=1, func=1 Mar 26 13:48:05 w2fzz0vc03 kernel: class=05-00-00, hdrtype=0x00, mfdev=1 Mar 26 13:48:05 w2fzz0vc03 kernel: cmdreg=0x0000, statreg=0x0020, cachelnsz=0 (dwords) Mar 26 13:48:05 w2fzz0vc03 kernel: lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) Mar 26 13:48:05 w2fzz0vc03 kernel: found-> vendor=0x10de, dev=0x0079, revid=0xa1 Mar 26 13:48:05 w2fzz0vc03 kernel: domain=0, bus=0, slot=1, func=2 Mar 26 13:48:05 w2fzz0vc03 kernel: class=05-00-00, hdrtype=0x00, mfdev=1 Mar 26 13:48:05 w2fzz0vc03 kernel: cmdreg=0x0000, statreg=0x0020, cachelnsz=0 (dwords) Mar 26 13:48:05 w2fzz0vc03 kernel: lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) Mar 26 13:48:05 w2fzz0vc03 kernel: found-> vendor=0x10de, dev=0x007a, revid=0xa1 Mar 26 13:48:05 w2fzz0vc03 kernel: domain=0, bus=0, slot=1, func=3 Mar 26 13:48:05 w2fzz0vc03 kernel: class=05-00-00, hdrtype=0x00, mfdev=1 Mar 26 13:48:05 w2fzz0vc03 kernel: cmdreg=0x0000, statreg=0x0020, cachelnsz=0 (dwords) Mar 26 13:48:05 w2fzz0vc03 kernel: lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) Mar 26 13:48:05 w2fzz0vc03 kernel: found-> vendor=0x10de, dev=0x007b, revid=0xa1 Mar 26 13:48:05 w2fzz0vc03 kernel: domain=0, bus=0, slot=1, func=4 Mar 26 13:48:05 w2fzz0vc03 kernel: class=05-00-00, hdrtype=0x00, mfdev=1 Mar 26 13:48:05 w2fzz0vc03 kernel: cmdreg=0x0000, statreg=0x0020, cachelnsz=0 (dwords) Mar 26 13:48:05 w2fzz0vc03 kernel: lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) Mar 26 13:48:05 w2fzz0vc03 kernel: found-> vendor=0x10de, dev=0x007c, revid=0xa1 Mar 26 13:48:05 w2fzz0vc03 kernel: domain=0, bus=0, slot=1, func=5 Mar 26 13:48:05 w2fzz0vc03 kernel: class=05-00-00, hdrtype=0x00, mfdev=1 Mar 26 13:48:05 w2fzz0vc03 kernel: cmdreg=0x0000, statreg=0x0020, cachelnsz=0 (dwords) Mar 26 13:48:05 w2fzz0vc03 kernel: lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) Mar 26 13:48:05 w2fzz0vc03 kernel: found-> vendor=0x10de, dev=0x007d, revid=0xa1 Mar 26 13:48:05 w2fzz0vc03 kernel: domain=0, bus=0, slot=1, func=6 Mar 26 13:48:05 w2fzz0vc03 kernel: class=05-00-00, hdrtype=0x00, mfdev=1 Mar 26 13:48:05 w2fzz0vc03 kernel: cmdreg=0x0000, statreg=0x0020, cachelnsz=0 (dwords) Mar 26 13:48:05 w2fzz0vc03 kernel: lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) Mar 26 13:48:05 w2fzz0vc03 kernel: found-> vendor=0x10de, dev=0x007e, revid=0xa2 Mar 26 13:48:05 w2fzz0vc03 kernel: domain=0, bus=0, slot=2, func=0 Mar 26 13:48:05 w2fzz0vc03 kernel: class=06-04-00, hdrtype=0x01, mfdev=0 Mar 26 13:48:05 w2fzz0vc03 kernel: cmdreg=0x0107, statreg=0x0010, cachelnsz=16 (dwords) Mar 26 13:48:05 w2fzz0vc03 kernel: lattimer=0x00 (0 ns), mingnt=0x0a (2500 ns), maxlat=0x00 (0 ns) Mar 26 13:48:05 w2fzz0vc03 kernel: powerspec 2 supports D0 D3 current D0 Mar 26 13:48:05 w2fzz0vc03 kernel: MSI supports 2 messages, 64 bit Mar 26 13:48:05 w2fzz0vc03 kernel: found-> vendor=0x10de, dev=0x007e, revid=0xa2 Mar 26 13:48:05 w2fzz0vc03 kernel: domain=0, bus=0, slot=4, func=0 Mar 26 13:48:05 w2fzz0vc03 kernel: class=06-04-00, hdrtype=0x01, mfdev=0 Mar 26 13:48:05 w2fzz0vc03 kernel: cmdreg=0x0107, statreg=0x0010, cachelnsz=16 (dwords) Mar 26 13:48:05 w2fzz0vc03 kernel: lattimer=0x00 (0 ns), mingnt=0x02 (500 ns), maxlat=0x00 (0 ns) Mar 26 13:48:05 w2fzz0vc03 kernel: powerspec 2 supports D0 D3 current D0 Mar 26 13:48:05 w2fzz0vc03 kernel: MSI supports 2 messages, 64 bit Mar 26 13:48:05 w2fzz0vc03 kernel: found-> vendor=0x10de, dev=0x007e, revid=0xa2 Mar 26 13:48:05 w2fzz0vc03 kernel: domain=0, bus=0, slot=5, func=0 Mar 26 13:48:05 w2fzz0vc03 kernel: class=06-04-00, hdrtype=0x01, mfdev=0 Mar 26 13:48:05 w2fzz0vc03 kernel: cmdreg=0x0107, statreg=0x0010, cachelnsz=16 (dwords) Mar 26 13:48:05 w2fzz0vc03 kernel: lattimer=0x00 (0 ns), mingnt=0x02 (500 ns), maxlat=0x00 (0 ns) Mar 26 13:48:05 w2fzz0vc03 kernel: powerspec 2 supports D0 D3 current D0 Mar 26 13:48:05 w2fzz0vc03 kernel: MSI supports 2 messages, 64 bit Mar 26 13:48:05 w2fzz0vc03 kernel: found-> vendor=0x10de, dev=0x0369, revid=0xa1 Mar 26 13:48:05 w2fzz0vc03 kernel: domain=0, bus=0, slot=9, func=0 Mar 26 13:48:05 w2fzz0vc03 kernel: class=05-00-00, hdrtype=0x00, mfdev=0 Mar 26 13:48:05 w2fzz0vc03 kernel: cmdreg=0x0106, statreg=0x00b0, cachelnsz=0 (dwords) Mar 26 13:48:05 w2fzz0vc03 kernel: lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) Mar 26 13:48:05 w2fzz0vc03 kernel: found-> vendor=0x10de, dev=0x0360, revid=0xa2 Mar 26 13:48:05 w2fzz0vc03 kernel: domain=0, bus=0, slot=10, func=0 Mar 26 13:48:05 w2fzz0vc03 kernel: class=06-01-00, hdrtype=0x00, mfdev=1 Mar 26 13:48:05 w2fzz0vc03 kernel: cmdreg=0x000f, statreg=0x00a0, cachelnsz=0 (dwords) Mar 26 13:48:05 w2fzz0vc03 kernel: lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) Mar 26 13:48:05 w2fzz0vc03 kernel: map[18]: type I/O Port, range 32, base 0x4f00, size 8, enabled Mar 26 13:48:05 w2fzz0vc03 kernel: found-> vendor=0x10de, dev=0x0368, revid=0xa2 Mar 26 13:48:05 w2fzz0vc03 kernel: domain=0, bus=0, slot=10, func=1 Mar 26 13:48:05 w2fzz0vc03 kernel: class=0c-05-00, hdrtype=0x00, mfdev=1 Mar 26 13:48:05 w2fzz0vc03 kernel: cmdreg=0x0001, statreg=0x00b0, cachelnsz=0 (dwords) Mar 26 13:48:05 w2fzz0vc03 kernel: lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) Mar 26 13:48:05 w2fzz0vc03 kernel: intpin=a, irq=9 Mar 26 13:48:05 w2fzz0vc03 kernel: powerspec 2 supports D0 D3 current D0 Mar 26 13:48:05 w2fzz0vc03 kernel: map[10]: type I/O Port, range 32, base 0x4c00, size 6, enabled Mar 26 13:48:05 w2fzz0vc03 kernel: map[20]: type I/O Port, range 32, base 0x5000, size 6, enabled Mar 26 13:48:05 w2fzz0vc03 kernel: map[24]: type I/O Port, range 32, base 0x5100, size 6, enabled Mar 26 13:48:05 w2fzz0vc03 kernel: pcib0: matched entry for 0.10.INTA (src \_SB_.AP12:0) Mar 26 13:48:05 w2fzz0vc03 kernel: pci_link25: Picked IRQ 20 with weight 0 Mar 26 13:48:05 w2fzz0vc03 kernel: pcib0: slot 10 INTA routed to irq 20 via \_SB_.AP12 Mar 26 13:48:05 w2fzz0vc03 kernel: found-> vendor=0x10de, dev=0x036c, revid=0xa1 Mar 26 13:48:05 w2fzz0vc03 kernel: domain=0, bus=0, slot=11, func=0 Mar 26 13:48:05 w2fzz0vc03 kernel: class=0c-03-10, hdrtype=0x00, mfdev=1 Mar 26 13:48:05 w2fzz0vc03 kernel: cmdreg=0x0007, statreg=0x00b0, cachelnsz=0 (dwords) Mar 26 13:48:05 w2fzz0vc03 kernel: lattimer=0x00 (0 ns), mingnt=0x03 (750 ns), maxlat=0x01 (250 ns) Mar 26 13:48:05 w2fzz0vc03 kernel: intpin=a, irq=10 Mar 26 13:48:05 w2fzz0vc03 kernel: powerspec 2 supports D0 D1 D2 D3 current D0 Mar 26 13:48:05 w2fzz0vc03 kernel: map[10]: type Memory, range 32, base 0xdfffc000, size 12, enabled Mar 26 13:48:05 w2fzz0vc03 kernel: pcib0: matched entry for 0.11.INTA (src \_SB_.AP20:0) Mar 26 13:48:05 w2fzz0vc03 kernel: pci_link30: Picked IRQ 21 with weight 0 Mar 26 13:48:05 w2fzz0vc03 kernel: pcib0: slot 11 INTA routed to irq 21 via \_SB_.AP20 Mar 26 13:48:05 w2fzz0vc03 kernel: found-> vendor=0x10de, dev=0x036d, revid=0xa2 Mar 26 13:48:05 w2fzz0vc03 kernel: domain=0, bus=0, slot=11, func=1 Mar 26 13:48:05 w2fzz0vc03 kernel: class=0c-03-20, hdrtype=0x00, mfdev=1 Mar 26 13:48:05 w2fzz0vc03 kernel: cmdreg=0x0006, statreg=0x00b0, cachelnsz=0 (dwords) Mar 26 13:48:05 w2fzz0vc03 kernel: lattimer=0x00 (0 ns), mingnt=0x03 (750 ns), maxlat=0x01 (250 ns) Mar 26 13:48:05 w2fzz0vc03 kernel: intpin=b, irq=10 Mar 26 13:48:05 w2fzz0vc03 kernel: powerspec 2 supports D0 D1 D2 D3 current D0 Mar 26 13:48:05 w2fzz0vc03 kernel: map[10]: type Memory, range 32, base 0xdfffbf00, size 8, enabled Mar 26 13:48:05 w2fzz0vc03 kernel: pcib0: matched entry for 0.11.INTB (src \_SB_.AP13:0) Mar 26 13:48:05 w2fzz0vc03 kernel: pci_link26: Picked IRQ 22 with weight 0 Mar 26 13:48:05 w2fzz0vc03 kernel: pcib0: slot 11 INTB routed to irq 22 via \_SB_.AP13 Mar 26 13:48:05 w2fzz0vc03 kernel: found-> vendor=0x10de, dev=0x036e, revid=0xa1 Mar 26 13:48:05 w2fzz0vc03 kernel: domain=0, bus=0, slot=13, func=0 Mar 26 13:48:05 w2fzz0vc03 kernel: class=01-01-8a, hdrtype=0x00, mfdev=0 Mar 26 13:48:05 w2fzz0vc03 kernel: cmdreg=0x0005, statreg=0x00b0, cachelnsz=0 (dwords) Mar 26 13:48:05 w2fzz0vc03 kernel: lattimer=0x00 (0 ns), mingnt=0x03 (750 ns), maxlat=0x01 (250 ns) Mar 26 13:48:05 w2fzz0vc03 kernel: powerspec 2 supports D0 D3 current D0 Mar 26 13:48:05 w2fzz0vc03 kernel: map[20]: type I/O Port, range 32, base 0xecf0, size 4, enabled Mar 26 13:48:05 w2fzz0vc03 kernel: found-> vendor=0x10de, dev=0x037f, revid=0xa2 Mar 26 13:48:05 w2fzz0vc03 kernel: domain=0, bus=0, slot=14, func=0 Mar 26 13:48:05 w2fzz0vc03 kernel: class=01-04-85, hdrtype=0x00, mfdev=1 Mar 26 13:48:05 w2fzz0vc03 kernel: cmdreg=0x0007, statreg=0x00b0, cachelnsz=0 (dwords) Mar 26 13:48:05 w2fzz0vc03 kernel: lattimer=0x00 (0 ns), mingnt=0x03 (750 ns), maxlat=0x01 (250 ns) Mar 26 13:48:05 w2fzz0vc03 kernel: intpin=a, irq=11 Mar 26 13:48:05 w2fzz0vc03 kernel: powerspec 2 supports D0 D3 current D0 Mar 26 13:48:05 w2fzz0vc03 kernel: MSI supports 4 messages, 64 bit Mar 26 13:48:05 w2fzz0vc03 kernel: map[10]: type I/O Port, range 32, base 0xfe00, size 3, enabled Mar 26 13:48:05 w2fzz0vc03 kernel: map[14]: type I/O Port, range 32, base 0xfe10, size 2, enabled Mar 26 13:48:05 w2fzz0vc03 kernel: map[18]: type I/O Port, range 32, base 0xfe20, size 3, enabled Mar 26 13:48:05 w2fzz0vc03 kernel: map[1c]: type I/O Port, range 32, base 0xfe30, size 2, enabled Mar 26 13:48:05 w2fzz0vc03 kernel: map[20]: type I/O Port, range 32, base 0xfec0, size 4, enabled Mar 26 13:48:05 w2fzz0vc03 kernel: map[24]: type Memory, range 32, base 0xdfffd000, size 12, enabled Mar 26 13:48:05 w2fzz0vc03 kernel: pcib0: matched entry for 0.14.INTA (src \_SB_.AP17:0) Mar 26 13:48:05 w2fzz0vc03 kernel: pci_link29: Picked IRQ 23 with weight 0 Mar 26 13:48:05 w2fzz0vc03 kernel: pcib0: slot 14 INTA routed to irq 23 via \_SB_.AP17 Mar 26 13:48:05 w2fzz0vc03 kernel: found-> vendor=0x10de, dev=0x037f, revid=0xa3 Mar 26 13:48:05 w2fzz0vc03 kernel: domain=0, bus=0, slot=14, func=1 Mar 26 13:48:05 w2fzz0vc03 kernel: class=01-04-85, hdrtype=0x00, mfdev=1 Mar 26 13:48:05 w2fzz0vc03 kernel: cmdreg=0x0007, statreg=0x00b0, cachelnsz=0 (dwords) Mar 26 13:48:05 w2fzz0vc03 kernel: lattimer=0x00 (0 ns), mingnt=0x03 (750 ns), maxlat=0x01 (250 ns) Mar 26 13:48:05 w2fzz0vc03 kernel: intpin=b, irq=11 Mar 26 13:48:05 w2fzz0vc03 kernel: powerspec 2 supports D0 D3 current D0 Mar 26 13:48:05 w2fzz0vc03 kernel: MSI supports 4 messages, 64 bit Mar 26 13:48:05 w2fzz0vc03 kernel: map[10]: type I/O Port, range 32, base 0xfe40, size 3, enabled Mar 26 13:48:05 w2fzz0vc03 kernel: map[14]: type I/O Port, range 32, base 0xfe50, size 2, enabled Mar 26 13:48:05 w2fzz0vc03 kernel: map[18]: type I/O Port, range 32, base 0xfe60, size 3, enabled Mar 26 13:48:05 w2fzz0vc03 kernel: map[1c]: type I/O Port, range 32, base 0xfe70, size 2, enabled Mar 26 13:48:05 w2fzz0vc03 kernel: map[20]: type I/O Port, range 32, base 0xfed0, size 4, enabled Mar 26 13:48:05 w2fzz0vc03 kernel: map[24]: type Memory, range 32, base 0xdfffe000, size 12, enabled Mar 26 13:48:05 w2fzz0vc03 kernel: pcib0: matched entry for 0.14.INTB (src \_SB_.AP16:0) Mar 26 13:48:05 w2fzz0vc03 kernel: pci_link28: Picked IRQ 20 with weight 1 Mar 26 13:48:05 w2fzz0vc03 kernel: pcib0: slot 14 INTB routed to irq 20 via \_SB_.AP16 Mar 26 13:48:05 w2fzz0vc03 kernel: found-> vendor=0x10de, dev=0x037f, revid=0xa4 Mar 26 13:48:05 w2fzz0vc03 kernel: domain=0, bus=0, slot=14, func=2 Mar 26 13:48:05 w2fzz0vc03 kernel: class=01-04-85, hdrtype=0x00, mfdev=1 Mar 26 13:48:05 w2fzz0vc03 kernel: cmdreg=0x0007, statreg=0x00b0, cachelnsz=0 (dwords) Mar 26 13:48:05 w2fzz0vc03 kernel: lattimer=0x00 (0 ns), mingnt=0x03 (750 ns), maxlat=0x01 (250 ns) Mar 26 13:48:05 w2fzz0vc03 kernel: intpin=c, irq=11 Mar 26 13:48:05 w2fzz0vc03 kernel: powerspec 2 supports D0 D3 current D0 Mar 26 13:48:05 w2fzz0vc03 kernel: MSI supports 4 messages, 64 bit Mar 26 13:48:05 w2fzz0vc03 kernel: map[10]: type I/O Port, range 32, base 0xfe80, size 3, enabled Mar 26 13:48:05 w2fzz0vc03 kernel: map[14]: type I/O Port, range 32, base 0xfe90, size 2, enabled Mar 26 13:48:05 w2fzz0vc03 kernel: map[18]: type I/O Port, range 32, base 0xfea0, size 3, enabled Mar 26 13:48:05 w2fzz0vc03 kernel: map[1c]: type I/O Port, range 32, base 0xfeb0, size 2, enabled Mar 26 13:48:05 w2fzz0vc03 kernel: map[20]: type I/O Port, range 32, base 0xfef0, size 4, enabled Mar 26 13:48:05 w2fzz0vc03 kernel: map[24]: type Memory, range 32, base 0xdffff000, size 12, enabled Mar 26 13:48:05 w2fzz0vc03 kernel: pcib0: matched entry for 0.14.INTC (src \_SB_.AP27:0) Mar 26 13:48:05 w2fzz0vc03 kernel: pci_link33: Picked IRQ 21 with weight 1 Mar 26 13:48:05 w2fzz0vc03 kernel: pcib0: slot 14 INTC routed to irq 21 via \_SB_.AP27 Mar 26 13:48:05 w2fzz0vc03 kernel: found-> vendor=0x10de, dev=0x0370, revid=0xa2 Mar 26 13:48:05 w2fzz0vc03 kernel: domain=0, bus=0, slot=15, func=0 Mar 26 13:48:05 w2fzz0vc03 kernel: class=06-04-01, hdrtype=0x01, mfdev=1 Mar 26 13:48:05 w2fzz0vc03 kernel: cmdreg=0x0107, statreg=0x00b0, cachelnsz=0 (dwords) Mar 26 13:48:05 w2fzz0vc03 kernel: lattimer=0x00 (0 ns), mingnt=0x02 (500 ns), maxlat=0x00 (0 ns) Mar 26 13:48:05 w2fzz0vc03 kernel: found-> vendor=0x10de, dev=0x0376, revid=0xa2 Mar 26 13:48:05 w2fzz0vc03 kernel: domain=0, bus=0, slot=19, func=0 Mar 26 13:48:05 w2fzz0vc03 kernel: class=06-04-00, hdrtype=0x01, mfdev=0 Mar 26 13:48:05 w2fzz0vc03 kernel: cmdreg=0x0107, statreg=0x0010, cachelnsz=16 (dwords) Mar 26 13:48:05 w2fzz0vc03 kernel: lattimer=0x00 (0 ns), mingnt=0x02 (500 ns), maxlat=0x00 (0 ns) Mar 26 13:48:05 w2fzz0vc03 kernel: powerspec 2 supports D0 D3 current D0 Mar 26 13:48:05 w2fzz0vc03 kernel: MSI supports 2 messages, 64 bit Mar 26 13:48:05 w2fzz0vc03 kernel: found-> vendor=0x10de, dev=0x0377, revid=0xa2 Mar 26 13:48:05 w2fzz0vc03 kernel: domain=0, bus=0, slot=24, func=0 Mar 26 13:48:05 w2fzz0vc03 kernel: class=06-04-00, hdrtype=0x01, mfdev=0 Mar 26 13:48:05 w2fzz0vc03 kernel: cmdreg=0x0107, statreg=0x0010, cachelnsz=16 (dwords) Mar 26 13:48:05 w2fzz0vc03 kernel: lattimer=0x00 (0 ns), mingnt=0x02 (500 ns), maxlat=0x00 (0 ns) Mar 26 13:48:05 w2fzz0vc03 kernel: powerspec 2 supports D0 D3 current D0 Mar 26 13:48:05 w2fzz0vc03 kernel: MSI supports 2 messages, 64 bit Mar 26 13:48:05 w2fzz0vc03 kernel: pci0: at device 0.1 (no driver attached) Mar 26 13:48:05 w2fzz0vc03 kernel: pci0: at device 0.2 (no driver attached) Mar 26 13:48:05 w2fzz0vc03 kernel: pci0: at device 0.3 (no driver attached) Mar 26 13:48:05 w2fzz0vc03 kernel: pci0: at device 0.4 (no driver attached) Mar 26 13:48:05 w2fzz0vc03 kernel: pci0: at device 1.0 (no driver attached) Mar 26 13:48:05 w2fzz0vc03 kernel: pci0: at device 1.1 (no driver attached) Mar 26 13:48:05 w2fzz0vc03 kernel: pci0: at device 1.2 (no driver attached) Mar 26 13:48:05 w2fzz0vc03 kernel: pci0: at device 1.3 (no driver attached) Mar 26 13:48:05 w2fzz0vc03 kernel: pci0: at device 1.4 (no driver attached) Mar 26 13:48:05 w2fzz0vc03 kernel: pci0: at device 1.5 (no driver attached) Mar 26 13:48:05 w2fzz0vc03 kernel: pci0: at device 1.6 (no driver attached) Mar 26 13:48:05 w2fzz0vc03 kernel: pcib1: at device 2.0 on pci0 Mar 26 13:48:05 w2fzz0vc03 kernel: pcib1: domain 0 Mar 26 13:48:05 w2fzz0vc03 kernel: pcib1: secondary bus 1 Mar 26 13:48:05 w2fzz0vc03 kernel: pcib1: subordinate bus 1 Mar 26 13:48:05 w2fzz0vc03 kernel: pcib1: I/O decode 0xd000-0xdfff Mar 26 13:48:05 w2fzz0vc03 kernel: pcib1: memory decode 0xdb000000-0xdeffffff Mar 26 13:48:05 w2fzz0vc03 kernel: pcib1: prefetched decode 0xa0000000-0xafffffff Mar 26 13:48:05 w2fzz0vc03 kernel: pci1: on pcib1 Mar 26 13:48:05 w2fzz0vc03 kernel: pci1: domain=0, physical bus=1 Mar 26 13:48:05 w2fzz0vc03 kernel: found-> vendor=0x10de, dev=0x0191, revid=0xa2 Mar 26 13:48:05 w2fzz0vc03 kernel: domain=0, bus=1, slot=0, func=0 Mar 26 13:48:05 w2fzz0vc03 kernel: class=03-00-00, hdrtype=0x00, mfdev=0 Mar 26 13:48:05 w2fzz0vc03 kernel: cmdreg=0x0003, statreg=0x0010, cachelnsz=16 (dwords) Mar 26 13:48:05 w2fzz0vc03 kernel: lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) Mar 26 13:48:05 w2fzz0vc03 kernel: intpin=a, irq=11 Mar 26 13:48:05 w2fzz0vc03 kernel: powerspec 2 supports D0 D3 current D0 Mar 26 13:48:05 w2fzz0vc03 kernel: MSI supports 1 message, 64 bit Mar 26 13:48:05 w2fzz0vc03 kernel: map[10]: type Memory, range 32, base 0xde000000, size 24, enabled Mar 26 13:48:05 w2fzz0vc03 kernel: pcib1: requested memory range 0xde000000-0xdeffffff: good Mar 26 13:48:05 w2fzz0vc03 kernel: map[14]: type Prefetchable Memory, range 64, base 0xa0000000, size 28, enabled Mar 26 13:48:05 w2fzz0vc03 kernel: pcib1: requested memory range 0xa0000000-0xafffffff: good Mar 26 13:48:05 w2fzz0vc03 kernel: map[1c]: type Memory, range 64, base 0xdc000000, size 25, enabled Mar 26 13:48:05 w2fzz0vc03 kernel: pcib1: requested memory range 0xdc000000-0xddffffff: good Mar 26 13:48:05 w2fzz0vc03 kernel: map[24]: type I/O Port, range 32, base 0xdc80, size 7, enabled Mar 26 13:48:05 w2fzz0vc03 kernel: pcib1: requested I/O range 0xdc80-0xdcff: in range Mar 26 13:48:05 w2fzz0vc03 kernel: pcib1: matched entry for 1.0.INTA (src \_SB_.AP04:0) Mar 26 13:48:05 w2fzz0vc03 kernel: pci_link21: Picked IRQ 16 with weight 0 Mar 26 13:48:05 w2fzz0vc03 kernel: pcib1: slot 0 INTA routed to irq 16 via \_SB_.AP04 Mar 26 13:48:05 w2fzz0vc03 kernel: vgapci0: port 0xdc80-0xdcff mem 0xde000000-0xdeffffff,0xa0000000-0xafffffff,0xdc000000-0xddffffff irq 16 at device 0.0 on pci1 Mar 26 13:48:05 w2fzz0vc03 kernel: pcib2: at device 4.0 on pci0 Mar 26 13:48:05 w2fzz0vc03 kernel: pcib2: domain 0 Mar 26 13:48:05 w2fzz0vc03 kernel: pcib2: secondary bus 2 Mar 26 13:48:05 w2fzz0vc03 kernel: pcib2: subordinate bus 2 Mar 26 13:48:05 w2fzz0vc03 kernel: pcib2: I/O decode 0xf000-0xfff Mar 26 13:48:05 w2fzz0vc03 kernel: pcib2: no prefetched decode Mar 26 13:48:05 w2fzz0vc03 kernel: pci2: on pcib2 Mar 26 13:48:05 w2fzz0vc03 kernel: pci2: domain=0, physical bus=2 Mar 26 13:48:05 w2fzz0vc03 kernel: pcib3: at device 5.0 on pci0 Mar 26 13:48:05 w2fzz0vc03 kernel: pcib3: domain 0 Mar 26 13:48:05 w2fzz0vc03 kernel: pcib3: secondary bus 3 Mar 26 13:48:05 w2fzz0vc03 kernel: pcib3: subordinate bus 3 Mar 26 13:48:05 w2fzz0vc03 kernel: pcib3: I/O decode 0xf000-0xfff Mar 26 13:48:05 w2fzz0vc03 kernel: pcib3: no prefetched decode Mar 26 13:48:05 w2fzz0vc03 kernel: pci3: on pcib3 Mar 26 13:48:05 w2fzz0vc03 kernel: pci3: domain=0, physical bus=3 Mar 26 13:48:05 w2fzz0vc03 kernel: pci0: at device 9.0 (no driver attached) Mar 26 13:48:05 w2fzz0vc03 kernel: isab0: port 0x4f00-0x4fff at device 10.0 on pci0 Mar 26 13:48:05 w2fzz0vc03 kernel: isa0: on isab0 Mar 26 13:48:05 w2fzz0vc03 kernel: pci0: at device 10.1 (no driver attached) Mar 26 13:48:05 w2fzz0vc03 kernel: ohci0: mem 0xdfffc000-0xdfffcfff irq 21 at device 11.0 on pci0 Mar 26 13:48:05 w2fzz0vc03 kernel: ohci0: Reserved 0x1000 bytes for rid 0x10 type 3 at 0xdfffc000 Mar 26 13:48:05 w2fzz0vc03 kernel: ioapic0: routing intpin 21 (PCI IRQ 21) to lapic 0 vector 49 Mar 26 13:48:05 w2fzz0vc03 kernel: ohci0: [MPSAFE] Mar 26 13:48:05 w2fzz0vc03 kernel: ohci0: [ITHREAD] Mar 26 13:48:05 w2fzz0vc03 kernel: usbus0: on ohci0 Mar 26 13:48:05 w2fzz0vc03 kernel: ehci0: mem 0xdfffbf00-0xdfffbfff irq 22 at device 11.1 on pci0 Mar 26 13:48:05 w2fzz0vc03 kernel: ehci0: Reserved 0x100 bytes for rid 0x10 type 3 at 0xdfffbf00 Mar 26 13:48:05 w2fzz0vc03 kernel: ioapic0: routing intpin 22 (PCI IRQ 22) to lapic 0 vector 50 Mar 26 13:48:05 w2fzz0vc03 kernel: ehci0: [MPSAFE] Mar 26 13:48:05 w2fzz0vc03 kernel: ehci0: [ITHREAD] Mar 26 13:48:05 w2fzz0vc03 kernel: usbus1: waiting for BIOS to give up control Mar 26 13:48:05 w2fzz0vc03 kernel: usbus1: EHCI version 1.0 Mar 26 13:48:05 w2fzz0vc03 kernel: usbus1: on ehci0 Mar 26 13:48:05 w2fzz0vc03 kernel: atapci0: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xecf0-0xecff at device 13.0 on pci0 Mar 26 13:48:05 w2fzz0vc03 kernel: atapci0: Reserved 0x10 bytes for rid 0x20 type 4 at 0xecf0 Mar 26 13:48:05 w2fzz0vc03 kernel: ata0: on atapci0 Mar 26 13:48:05 w2fzz0vc03 kernel: atapci0: Reserved 0x8 bytes for rid 0x10 type 4 at 0x1f0 Mar 26 13:48:05 w2fzz0vc03 kernel: atapci0: Reserved 0x1 bytes for rid 0x14 type 4 at 0x3f6 Mar 26 13:48:05 w2fzz0vc03 kernel: ata0: reset tp1 mask=03 ostat0=60 ostat1=70 Mar 26 13:48:05 w2fzz0vc03 kernel: ata0: stat0=0x20 err=0x20 lsb=0x20 msb=0x20 Mar 26 13:48:05 w2fzz0vc03 kernel: ata0: stat1=0x30 err=0x30 lsb=0x30 msb=0x30 Mar 26 13:48:05 w2fzz0vc03 kernel: ata0: reset tp2 stat0=20 stat1=30 devices=0x0 Mar 26 13:48:05 w2fzz0vc03 kernel: ioapic0: routing intpin 14 (ISA IRQ 14) to lapic 0 vector 51 Mar 26 13:48:05 w2fzz0vc03 kernel: ata0: [MPSAFE] Mar 26 13:48:05 w2fzz0vc03 kernel: ata0: [ITHREAD] Mar 26 13:48:05 w2fzz0vc03 kernel: ata1: on atapci0 Mar 26 13:48:05 w2fzz0vc03 kernel: atapci0: Reserved 0x8 bytes for rid 0x18 type 4 at 0x170 Mar 26 13:48:05 w2fzz0vc03 kernel: atapci0: Reserved 0x1 bytes for rid 0x1c type 4 at 0x376 Mar 26 13:48:05 w2fzz0vc03 kernel: ata1: reset tp1 mask=00 ostat0=ff ostat1=ff Mar 26 13:48:05 w2fzz0vc03 kernel: ioapic0: routing intpin 15 (ISA IRQ 15) to lapic 0 vector 52 Mar 26 13:48:05 w2fzz0vc03 kernel: ata1: [MPSAFE] Mar 26 13:48:05 w2fzz0vc03 kernel: ata1: [ITHREAD] Mar 26 13:48:05 w2fzz0vc03 kernel: atapci1: port 0xfe00-0xfe07,0xfe10-0xfe13,0xfe20-0xfe27,0xfe30-0xfe33,0xfec0-0xfecf mem 0xdfffd000-0xdfffdfff irq 23 at device 14.0 on pci0 Mar 26 13:48:05 w2fzz0vc03 kernel: atapci1: Reserved 0x10 bytes for rid 0x20 type 4 at 0xfec0 Mar 26 13:48:05 w2fzz0vc03 kernel: ioapic0: routing intpin 23 (PCI IRQ 23) to lapic 0 vector 53 Mar 26 13:48:05 w2fzz0vc03 kernel: atapci1: [MPSAFE] Mar 26 13:48:05 w2fzz0vc03 kernel: atapci1: [ITHREAD] Mar 26 13:48:05 w2fzz0vc03 kernel: atapci1: Reserved 0x1000 bytes for rid 0x24 type 3 at 0xdfffd000 Mar 26 13:48:05 w2fzz0vc03 kernel: ata2: on atapci1 Mar 26 13:48:05 w2fzz0vc03 kernel: atapci1: Reserved 0x8 bytes for rid 0x10 type 4 at 0xfe00 Mar 26 13:48:05 w2fzz0vc03 kernel: atapci1: Reserved 0x4 bytes for rid 0x14 type 4 at 0xfe10 Mar 26 13:48:05 w2fzz0vc03 kernel: ata2: SATA connect time=0ms Mar 26 13:48:05 w2fzz0vc03 kernel: ata2: reset tp1 mask=01 ostat0=50 ostat1=00 Mar 26 13:48:05 w2fzz0vc03 kernel: ata2: stat0=0x50 err=0x01 lsb=0x00 msb=0x00 Mar 26 13:48:05 w2fzz0vc03 kernel: ata2: reset tp2 stat0=50 stat1=00 devices=0x1 Mar 26 13:48:05 w2fzz0vc03 kernel: ata2: [MPSAFE] Mar 26 13:48:05 w2fzz0vc03 kernel: ata2: [ITHREAD] Mar 26 13:48:05 w2fzz0vc03 kernel: ata3: on atapci1 Mar 26 13:48:05 w2fzz0vc03 kernel: atapci1: Reserved 0x8 bytes for rid 0x18 type 4 at 0xfe20 Mar 26 13:48:05 w2fzz0vc03 kernel: atapci1: Reserved 0x4 bytes for rid 0x1c type 4 at 0xfe30 Mar 26 13:48:06 w2fzz0vc03 kernel: ata3: SATA connect time=0ms Mar 26 13:48:06 w2fzz0vc03 kernel: ata3: reset tp1 mask=01 ostat0=50 ostat1=00 Mar 26 13:48:06 w2fzz0vc03 kernel: ata3: stat0=0x50 err=0x01 lsb=0x00 msb=0x00 Mar 26 13:48:06 w2fzz0vc03 kernel: ata3: reset tp2 stat0=50 stat1=00 devices=0x1 Mar 26 13:48:06 w2fzz0vc03 kernel: ata3: [MPSAFE] Mar 26 13:48:06 w2fzz0vc03 kernel: ata3: [ITHREAD] Mar 26 13:48:06 w2fzz0vc03 kernel: atapci2: port 0xfe40-0xfe47,0xfe50-0xfe53,0xfe60-0xfe67,0xfe70-0xfe73,0xfed0-0xfedf mem 0xdfffe000-0xdfffefff irq 20 at device 14.1 on pci0 Mar 26 13:48:06 w2fzz0vc03 kernel: atapci2: Reserved 0x10 bytes for rid 0x20 type 4 at 0xfed0 Mar 26 13:48:06 w2fzz0vc03 kernel: ioapic0: routing intpin 20 (PCI IRQ 20) to lapic 0 vector 54 Mar 26 13:48:06 w2fzz0vc03 kernel: atapci2: [MPSAFE] Mar 26 13:48:06 w2fzz0vc03 kernel: atapci2: [ITHREAD] Mar 26 13:48:06 w2fzz0vc03 kernel: atapci2: Reserved 0x1000 bytes for rid 0x24 type 3 at 0xdfffe000 Mar 26 13:48:06 w2fzz0vc03 kernel: ata4: on atapci2 Mar 26 13:48:06 w2fzz0vc03 kernel: atapci2: Reserved 0x8 bytes for rid 0x10 type 4 at 0xfe40 Mar 26 13:48:06 w2fzz0vc03 kernel: atapci2: Reserved 0x4 bytes for rid 0x14 type 4 at 0xfe50 Mar 26 13:48:06 w2fzz0vc03 kernel: ata4: SATA connect time=0ms Mar 26 13:48:06 w2fzz0vc03 kernel: ata4: reset tp1 mask=01 ostat0=50 ostat1=00 Mar 26 13:48:06 w2fzz0vc03 kernel: ata4: stat0=0x10 err=0x01 lsb=0x14 msb=0xeb Mar 26 13:48:06 w2fzz0vc03 kernel: ata4: reset tp2 stat0=10 stat1=00 devices=0x10000 Mar 26 13:48:06 w2fzz0vc03 kernel: ata4: [MPSAFE] Mar 26 13:48:06 w2fzz0vc03 kernel: ata4: [ITHREAD] Mar 26 13:48:06 w2fzz0vc03 kernel: ata5: on atapci2 Mar 26 13:48:06 w2fzz0vc03 kernel: atapci2: Reserved 0x8 bytes for rid 0x18 type 4 at 0xfe60 Mar 26 13:48:06 w2fzz0vc03 kernel: atapci2: Reserved 0x4 bytes for rid 0x1c type 4 at 0xfe70 Mar 26 13:48:06 w2fzz0vc03 kernel: ata5: SATA connect time=0ms Mar 26 13:48:06 w2fzz0vc03 kernel: ata5: reset tp1 mask=01 ostat0=50 ostat1=00 Mar 26 13:48:06 w2fzz0vc03 kernel: ata5: stat0=0x00 err=0x01 lsb=0x14 msb=0xeb Mar 26 13:48:06 w2fzz0vc03 kernel: ata5: reset tp2 stat0=00 stat1=00 devices=0x10000 Mar 26 13:48:06 w2fzz0vc03 kernel: ata5: [MPSAFE] Mar 26 13:48:06 w2fzz0vc03 kernel: ata5: [ITHREAD] Mar 26 13:48:06 w2fzz0vc03 kernel: atapci3: port 0xfe80-0xfe87,0xfe90-0xfe93,0xfea0-0xfea7,0xfeb0-0xfeb3,0xfef0-0xfeff mem 0xdffff000-0xdfffffff irq 21 at device 14.2 on pci0 Mar 26 13:48:06 w2fzz0vc03 kernel: atapci3: Reserved 0x10 bytes for rid 0x20 type 4 at 0xfef0 Mar 26 13:48:06 w2fzz0vc03 kernel: atapci3: [MPSAFE] Mar 26 13:48:06 w2fzz0vc03 kernel: atapci3: [ITHREAD] Mar 26 13:48:06 w2fzz0vc03 kernel: atapci3: Reserved 0x1000 bytes for rid 0x24 type 3 at 0xdffff000 Mar 26 13:48:06 w2fzz0vc03 kernel: ata6: on atapci3 Mar 26 13:48:06 w2fzz0vc03 kernel: atapci3: Reserved 0x8 bytes for rid 0x10 type 4 at 0xfe80 Mar 26 13:48:06 w2fzz0vc03 kernel: atapci3: Reserved 0x4 bytes for rid 0x14 type 4 at 0xfe90 Mar 26 13:48:06 w2fzz0vc03 kernel: ata6: SATA connect time=0ms Mar 26 13:48:06 w2fzz0vc03 kernel: ata6: reset tp1 mask=01 ostat0=50 ostat1=00 Mar 26 13:48:06 w2fzz0vc03 kernel: ata6: stat0=0x50 err=0x01 lsb=0x00 msb=0x00 Mar 26 13:48:06 w2fzz0vc03 kernel: ata6: reset tp2 stat0=50 stat1=00 devices=0x1 Mar 26 13:48:06 w2fzz0vc03 kernel: ata6: [MPSAFE] Mar 26 13:48:06 w2fzz0vc03 kernel: ata6: [ITHREAD] Mar 26 13:48:06 w2fzz0vc03 kernel: ata7: on atapci3 Mar 26 13:48:06 w2fzz0vc03 kernel: atapci3: Reserved 0x8 bytes for rid 0x18 type 4 at 0xfea0 Mar 26 13:48:06 w2fzz0vc03 kernel: atapci3: Reserved 0x4 bytes for rid 0x1c type 4 at 0xfeb0 Mar 26 13:48:06 w2fzz0vc03 kernel: ata7: SATA connect time=0ms Mar 26 13:48:06 w2fzz0vc03 kernel: ata7: reset tp1 mask=01 ostat0=50 ostat1=00 Mar 26 13:48:06 w2fzz0vc03 kernel: ata7: stat0=0x50 err=0x01 lsb=0x00 msb=0x00 Mar 26 13:48:06 w2fzz0vc03 kernel: ata7: reset tp2 stat0=50 stat1=00 devices=0x1 Mar 26 13:48:06 w2fzz0vc03 kernel: ata7: [MPSAFE] Mar 26 13:48:06 w2fzz0vc03 kernel: ata7: [ITHREAD] Mar 26 13:48:06 w2fzz0vc03 kernel: pcib4: at device 15.0 on pci0 Mar 26 13:48:06 w2fzz0vc03 kernel: pcib4: domain 0 Mar 26 13:48:06 w2fzz0vc03 kernel: pcib4: secondary bus 4 Mar 26 13:48:06 w2fzz0vc03 kernel: pcib4: subordinate bus 4 Mar 26 13:48:06 w2fzz0vc03 kernel: pcib4: I/O decode 0xc000-0xcfff Mar 26 13:48:06 w2fzz0vc03 kernel: pcib4: memory decode 0xd4000000-0xdaffffff Mar 26 13:48:06 w2fzz0vc03 kernel: pcib4: prefetched decode 0xb0000000-0xb0ffffff Mar 26 13:48:06 w2fzz0vc03 kernel: pcib4: Subtractively decoded bridge. Mar 26 13:48:06 w2fzz0vc03 kernel: pci4: on pcib4 Mar 26 13:48:06 w2fzz0vc03 kernel: pci4: domain=0, physical bus=4 Mar 26 13:48:06 w2fzz0vc03 kernel: found-> vendor=0x1971, dev=0x1011, revid=0x00 Mar 26 13:48:06 w2fzz0vc03 kernel: domain=0, bus=4, slot=4, func=0 Mar 26 13:48:06 w2fzz0vc03 kernel: class=ff-00-00, hdrtype=0x00, mfdev=0 Mar 26 13:48:06 w2fzz0vc03 kernel: cmdreg=0x0117, statreg=0x0288, cachelnsz=16 (dwords) Mar 26 13:48:06 w2fzz0vc03 kernel: lattimer=0x40 (1920 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) Mar 26 13:48:06 w2fzz0vc03 kernel: intpin=a, irq=11 Mar 26 13:48:06 w2fzz0vc03 kernel: map[10]: type Prefetchable Memory, range 64, base 0xb0000000, size 24, enabled Mar 26 13:48:06 w2fzz0vc03 kernel: pcib4: requested memory range 0xb0000000-0xb0ffffff: good Mar 26 13:48:06 w2fzz0vc03 kernel: map[18]: type I/O Port, range 32, base 0xcc00, size 8, enabled Mar 26 13:48:06 w2fzz0vc03 kernel: pcib4: requested I/O range 0xcc00-0xccff: in range Mar 26 13:48:06 w2fzz0vc03 kernel: pcib4: matched entry for 4.4.INTA (src \_SB_.AP00:0) Mar 26 13:48:06 w2fzz0vc03 kernel: pci_link17: Picked IRQ 16 with weight 3 Mar 26 13:48:06 w2fzz0vc03 kernel: pcib4: slot 4 INTA routed to irq 16 via \_SB_.AP00 Mar 26 13:48:06 w2fzz0vc03 kernel: found-> vendor=0x1102, dev=0x0005, revid=0x00 Mar 26 13:48:06 w2fzz0vc03 kernel: domain=0, bus=4, slot=5, func=0 Mar 26 13:48:06 w2fzz0vc03 kernel: class=04-01-00, hdrtype=0x00, mfdev=0 Mar 26 13:48:06 w2fzz0vc03 kernel: cmdreg=0x0107, statreg=0x0210, cachelnsz=16 (dwords) Mar 26 13:48:06 w2fzz0vc03 kernel: lattimer=0x40 (1920 ns), mingnt=0x04 (1000 ns), maxlat=0x05 (1250 ns) Mar 26 13:48:06 w2fzz0vc03 kernel: intpin=a, irq=10 Mar 26 13:48:06 w2fzz0vc03 kernel: powerspec 2 supports D0 D1 D2 D3 current D0 Mar 26 13:48:06 w2fzz0vc03 kernel: MSI supports 1 message, 64 bit Mar 26 13:48:06 w2fzz0vc03 kernel: map[10]: type I/O Port, range 32, base 0xc8e0, size 5, enabled Mar 26 13:48:06 w2fzz0vc03 kernel: pcib4: requested I/O range 0xc8e0-0xc8ff: in range Mar 26 13:48:06 w2fzz0vc03 kernel: map[14]: type Memory, range 64, base 0xdae00000, size 21, enabled Mar 26 13:48:06 w2fzz0vc03 kernel: pcib4: requested memory range 0xdae00000-0xdaffffff: good Mar 26 13:48:06 w2fzz0vc03 kernel: map[1c]: type Memory, range 64, base 0xd4000000, size 26, enabled Mar 26 13:48:06 w2fzz0vc03 kernel: pcib4: requested memory range 0xd4000000-0xd7ffffff: good Mar 26 13:48:06 w2fzz0vc03 kernel: pcib4: matched entry for 4.5.INTA (src \_SB_.AP01:0) Mar 26 13:48:06 w2fzz0vc03 kernel: pci_link18: Picked IRQ 17 with weight 0 Mar 26 13:48:06 w2fzz0vc03 kernel: pcib4: slot 5 INTA routed to irq 17 via \_SB_.AP01 Mar 26 13:48:06 w2fzz0vc03 kernel: found-> vendor=0x104c, dev=0x8023, revid=0x00 Mar 26 13:48:06 w2fzz0vc03 kernel: domain=0, bus=4, slot=10, func=0 Mar 26 13:48:06 w2fzz0vc03 kernel: class=0c-00-10, hdrtype=0x00, mfdev=0 Mar 26 13:48:06 w2fzz0vc03 kernel: cmdreg=0x0116, statreg=0x0210, cachelnsz=16 (dwords) Mar 26 13:48:06 w2fzz0vc03 kernel: lattimer=0x40 (1920 ns), mingnt=0x02 (500 ns), maxlat=0x04 (1000 ns) Mar 26 13:48:06 w2fzz0vc03 kernel: intpin=a, irq=9 Mar 26 13:48:06 w2fzz0vc03 kernel: powerspec 2 supports D0 D1 D2 D3 current D0 Mar 26 13:48:06 w2fzz0vc03 kernel: map[10]: type Memory, range 32, base 0xdadfb800, size 11, enabled Mar 26 13:48:06 w2fzz0vc03 kernel: pcib4: requested memory range 0xdadfb800-0xdadfbfff: good Mar 26 13:48:06 w2fzz0vc03 kernel: map[14]: type Memory, range 32, base 0xdadfc000, size 14, enabled Mar 26 13:48:06 w2fzz0vc03 kernel: pcib4: requested memory range 0xdadfc000-0xdadfffff: good Mar 26 13:48:06 w2fzz0vc03 kernel: pcib4: matched entry for 4.10.INTA (src \_SB_.AP02:0) Mar 26 13:48:06 w2fzz0vc03 kernel: pci_link19: Picked IRQ 18 with weight 0 Mar 26 13:48:06 w2fzz0vc03 kernel: pcib4: slot 10 INTA routed to irq 18 via \_SB_.AP02 Mar 26 13:48:06 w2fzz0vc03 kernel: pci4: at device 4.0 (no driver attached) Mar 26 13:48:06 w2fzz0vc03 kernel: pci4: at device 5.0 (no driver attached) Mar 26 13:48:06 w2fzz0vc03 kernel: fwohci0: mem 0xdadfb800-0xdadfbfff,0xdadfc000-0xdadfffff irq 18 at device 10.0 on pci4 Mar 26 13:48:06 w2fzz0vc03 kernel: fwohci0: Reserved 0x800 bytes for rid 0x10 type 3 at 0xdadfb800 Mar 26 13:48:06 w2fzz0vc03 kernel: ioapic0: routing intpin 18 (PCI IRQ 18) to lapic 0 vector 55 Mar 26 13:48:06 w2fzz0vc03 kernel: fwohci0: [MPSAFE] Mar 26 13:48:06 w2fzz0vc03 kernel: fwohci0: [ITHREAD] Mar 26 13:48:06 w2fzz0vc03 kernel: fwohci0: OHCI version 1.10 (ROM=0) Mar 26 13:48:06 w2fzz0vc03 kernel: fwohci0: No. of Isochronous channels is 4. Mar 26 13:48:06 w2fzz0vc03 kernel: fwohci0: EUI64 80:00:00:00:00:00:00:00 Mar 26 13:48:06 w2fzz0vc03 kernel: fwohci0: Phy 1394a available S400, 2 ports. Mar 26 13:48:06 w2fzz0vc03 kernel: fwohci0: Link S400, max_rec 128 bytes. Mar 26 13:48:06 w2fzz0vc03 kernel: fwohci0: max_rec 128 -> 2048 Mar 26 13:48:06 w2fzz0vc03 kernel: firewire0: on fwohci0 Mar 26 13:48:06 w2fzz0vc03 kernel: dcons_crom0: on firewire0 Mar 26 13:48:06 w2fzz0vc03 kernel: dcons_crom0: bus_addr 0x2578000 Mar 26 13:48:06 w2fzz0vc03 kernel: fwe0: on firewire0 Mar 26 13:48:06 w2fzz0vc03 kernel: if_fwe0: Fake Ethernet address: 82:00:00:00:00:00 Mar 26 13:48:06 w2fzz0vc03 kernel: fwe0: bpf attached Mar 26 13:48:06 w2fzz0vc03 kernel: fwe0: Ethernet address: 82:00:00:00:00:00 Mar 26 13:48:06 w2fzz0vc03 kernel: fwip0: on firewire0 Mar 26 13:48:06 w2fzz0vc03 kernel: fwip0: bpf attached Mar 26 13:48:06 w2fzz0vc03 kernel: fwip0: Firewire address: 80:00:00:00:00:00:00:00 @ 0xfffe00000000, S400, maxrec 2048 Mar 26 13:48:06 w2fzz0vc03 kernel: sbp0: on firewire0 Mar 26 13:48:06 w2fzz0vc03 kernel: fwohci0: Initiate bus reset Mar 26 13:48:06 w2fzz0vc03 kernel: fwohci0: fwohci_intr_core: BUS reset Mar 26 13:48:06 w2fzz0vc03 kernel: fwohci0: fwohci_intr_core: node_id=0x00000000, SelfID Count=1, CYCLEMASTER mode Mar 26 13:48:06 w2fzz0vc03 kernel: pcib5: at device 19.0 on pci0 Mar 26 13:48:06 w2fzz0vc03 kernel: pcib5: domain 0 Mar 26 13:48:06 w2fzz0vc03 kernel: pcib5: secondary bus 5 Mar 26 13:48:06 w2fzz0vc03 kernel: pcib5: subordinate bus 5 Mar 26 13:48:06 w2fzz0vc03 kernel: pcib5: I/O decode 0xf000-0xfff Mar 26 13:48:06 w2fzz0vc03 kernel: pcib5: no prefetched decode Mar 26 13:48:06 w2fzz0vc03 kernel: pci5: on pcib5 Mar 26 13:48:06 w2fzz0vc03 kernel: pci5: domain=0, physical bus=5 Mar 26 13:48:06 w2fzz0vc03 kernel: pcib6: at device 24.0 on pci0 Mar 26 13:48:06 w2fzz0vc03 kernel: pcib6: domain 0 Mar 26 13:48:06 w2fzz0vc03 kernel: pcib6: secondary bus 6 Mar 26 13:48:06 w2fzz0vc03 kernel: pcib6: subordinate bus 6 Mar 26 13:48:06 w2fzz0vc03 kernel: pcib6: I/O decode 0xb000-0xbfff Mar 26 13:48:06 w2fzz0vc03 kernel: pcib6: memory decode 0xd0000000-0xd3ffffff Mar 26 13:48:06 w2fzz0vc03 kernel: pcib6: prefetched decode 0xb1000000-0xcfffffff Mar 26 13:48:06 w2fzz0vc03 kernel: pci6: on pcib6 Mar 26 13:48:06 w2fzz0vc03 kernel: pci6: domain=0, physical bus=6 Mar 26 13:48:06 w2fzz0vc03 kernel: found-> vendor=0x10de, dev=0x0191, revid=0xa2 Mar 26 13:48:06 w2fzz0vc03 kernel: domain=0, bus=6, slot=0, func=0 Mar 26 13:48:06 w2fzz0vc03 kernel: class=03-00-00, hdrtype=0x00, mfdev=0 Mar 26 13:48:06 w2fzz0vc03 kernel: cmdreg=0x0000, statreg=0x0010, cachelnsz=16 (dwords) Mar 26 13:48:06 w2fzz0vc03 kernel: lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) Mar 26 13:48:06 w2fzz0vc03 kernel: intpin=a, irq=11 Mar 26 13:48:06 w2fzz0vc03 kernel: powerspec 2 supports D0 D3 current D0 Mar 26 13:48:06 w2fzz0vc03 kernel: MSI supports 1 message, 64 bit Mar 26 13:48:06 w2fzz0vc03 kernel: map[10]: type Memory, range 32, base 0xd1000000, size 24, memory disabled Mar 26 13:48:06 w2fzz0vc03 kernel: pcib6: requested memory range 0xd1000000-0xd1ffffff: good Mar 26 13:48:06 w2fzz0vc03 kernel: map[14]: type Prefetchable Memory, range 64, base 0xc0000000, size 28, enabled Mar 26 13:48:06 w2fzz0vc03 kernel: pcib6: requested memory range 0xc0000000-0xcfffffff: good Mar 26 13:48:06 w2fzz0vc03 kernel: map[1c]: type Memory, range 64, base 0xd2000000, size 25, enabled Mar 26 13:48:06 w2fzz0vc03 kernel: pcib6: requested memory range 0xd2000000-0xd3ffffff: good Mar 26 13:48:06 w2fzz0vc03 kernel: map[24]: type I/O Port, range 32, base 0xbc80, size 7, port disabled Mar 26 13:48:06 w2fzz0vc03 kernel: pcib6: requested I/O range 0xbc80-0xbcff: in range Mar 26 13:48:06 w2fzz0vc03 kernel: pcib6: matched entry for 6.0.INTA (src \_SB_.AP04:0) Mar 26 13:48:06 w2fzz0vc03 kernel: pcib6: slot 0 INTA routed to irq 16 via \_SB_.AP04 Mar 26 13:48:06 w2fzz0vc03 kernel: vgapci1: port 0xbc80-0xbcff mem 0xd1000000-0xd1ffffff,0xc0000000-0xcfffffff,0xd2000000-0xd3ffffff irq 16 at device 0.0 on pci6 Mar 26 13:48:06 w2fzz0vc03 kernel: atrtc0: port 0x70-0x7f irq 8 on acpi0 Mar 26 13:48:06 w2fzz0vc03 kernel: atrtc0: registered as a time-of-day clock (resolution 1000000us) Mar 26 13:48:06 w2fzz0vc03 kernel: atkbdc0: port 0x60,0x64 irq 1 on acpi0 Mar 26 13:48:06 w2fzz0vc03 kernel: atkbd0: irq 1 on atkbdc0 Mar 26 13:48:06 w2fzz0vc03 kernel: atkbd: the current kbd controller command byte 0065 Mar 26 13:48:06 w2fzz0vc03 kernel: atkbd: keyboard ID 0x41ab (2) Mar 26 13:48:06 w2fzz0vc03 kernel: kbd0 at atkbd0 Mar 26 13:48:06 w2fzz0vc03 kernel: kbd0: atkbd0, AT 101/102 (2), config:0x0, flags:0x3d0000 Mar 26 13:48:06 w2fzz0vc03 kernel: ioapic0: routing intpin 1 (ISA IRQ 1) to lapic 0 vector 56 Mar 26 13:48:06 w2fzz0vc03 kernel: atkbd0: [GIANT-LOCKED] Mar 26 13:48:06 w2fzz0vc03 kernel: atkbd0: [ITHREAD] Mar 26 13:48:06 w2fzz0vc03 kernel: psm0: unable to allocate IRQ Mar 26 13:48:06 w2fzz0vc03 kernel: psmcpnp0: irq 12 on acpi0 Mar 26 13:48:06 w2fzz0vc03 kernel: psm0: current command byte:0065 Mar 26 13:48:06 w2fzz0vc03 kernel: psm0: irq 12 on atkbdc0 Mar 26 13:48:06 w2fzz0vc03 kernel: ioapic0: routing intpin 12 (ISA IRQ 12) to lapic 0 vector 57 Mar 26 13:48:06 w2fzz0vc03 kernel: psm0: [GIANT-LOCKED] Mar 26 13:48:06 w2fzz0vc03 kernel: psm0: [ITHREAD] Mar 26 13:48:06 w2fzz0vc03 kernel: psm0: model MouseMan+, device ID 0-83, 3 buttons Mar 26 13:48:06 w2fzz0vc03 kernel: psm0: config:00000000, flags:00000008, packet size:3 Mar 26 13:48:06 w2fzz0vc03 kernel: psm0: syncmask:08, syncbits:00 Mar 26 13:48:06 w2fzz0vc03 kernel: uart0: <16550 or compatible> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 Mar 26 13:48:06 w2fzz0vc03 kernel: ioapic0: routing intpin 4 (ISA IRQ 4) to lapic 0 vector 58 Mar 26 13:48:06 w2fzz0vc03 kernel: uart0: [FILTER] Mar 26 13:48:06 w2fzz0vc03 kernel: uart0: fast interrupt Mar 26 13:48:06 w2fzz0vc03 kernel: cpu0: on acpi0 Mar 26 13:48:06 w2fzz0vc03 kernel: cpu0: switching to generic Cx mode Mar 26 13:48:06 w2fzz0vc03 kernel: est0: enabling SpeedStep Mar 26 13:48:06 w2fzz0vc03 kernel: est0: on cpu0 Mar 26 13:48:06 w2fzz0vc03 kernel: est: CPU supports Enhanced Speedstep, but is not recognized. Mar 26 13:48:06 w2fzz0vc03 kernel: est: cpu_vendor GenuineIntel, msr a2a0a2a86000a2a Mar 26 13:48:06 w2fzz0vc03 kernel: device_attach: est0 attach returned 6 Mar 26 13:48:06 w2fzz0vc03 kernel: p4tcc0: on cpu0 Mar 26 13:48:06 w2fzz0vc03 kernel: cpu1: on acpi0 Mar 26 13:48:06 w2fzz0vc03 kernel: est1: on cpu1 Mar 26 13:48:06 w2fzz0vc03 kernel: est: CPU supports Enhanced Speedstep, but is not recognized. Mar 26 13:48:06 w2fzz0vc03 kernel: est: cpu_vendor GenuineIntel, msr a2a0a2a86000a2a Mar 26 13:48:06 w2fzz0vc03 kernel: device_attach: est1 attach returned 6 Mar 26 13:48:06 w2fzz0vc03 kernel: p4tcc1: on cpu1 Mar 26 13:48:06 w2fzz0vc03 kernel: cpu2: on acpi0 Mar 26 13:48:06 w2fzz0vc03 kernel: est2: on cpu2 Mar 26 13:48:06 w2fzz0vc03 kernel: est: CPU supports Enhanced Speedstep, but is not recognized. Mar 26 13:48:06 w2fzz0vc03 kernel: est: cpu_vendor GenuineIntel, msr a2a0a2a86000a2a Mar 26 13:48:06 w2fzz0vc03 kernel: device_attach: est2 attach returned 6 Mar 26 13:48:06 w2fzz0vc03 kernel: p4tcc2: on cpu2 Mar 26 13:48:06 w2fzz0vc03 kernel: cpu3: on acpi0 Mar 26 13:48:06 w2fzz0vc03 kernel: est3: on cpu3 Mar 26 13:48:06 w2fzz0vc03 kernel: est: CPU supports Enhanced Speedstep, but is not recognized. Mar 26 13:48:06 w2fzz0vc03 kernel: est: cpu_vendor GenuineIntel, msr a2a0a2a86000a2a Mar 26 13:48:06 w2fzz0vc03 kernel: device_attach: est3 attach returned 6 Mar 26 13:48:06 w2fzz0vc03 kernel: p4tcc3: on cpu3 Mar 26 13:48:06 w2fzz0vc03 kernel: ex_isa_identify() Mar 26 13:48:06 w2fzz0vc03 kernel: ahc_isa_probe 4: ioport 0x4c00 alloc failed Mar 26 13:48:06 w2fzz0vc03 kernel: ahc_isa_probe 5: ioport 0x5c00 alloc failed Mar 26 13:48:06 w2fzz0vc03 kernel: ahc_isa_probe 11: ioport 0xbc00 alloc failed Mar 26 13:48:06 w2fzz0vc03 kernel: ahc_isa_probe 12: ioport 0xcc00 alloc failed Mar 26 13:48:06 w2fzz0vc03 kernel: ahc_isa_probe 13: ioport 0xdc00 alloc failed Mar 26 13:48:06 w2fzz0vc03 kernel: ahc_isa_probe 14: ioport 0xec00 alloc failed Mar 26 13:48:06 w2fzz0vc03 kernel: isa_probe_children: disabling PnP devices Mar 26 13:48:06 w2fzz0vc03 kernel: atkbdc: atkbdc0 already exists; skipping it Mar 26 13:48:06 w2fzz0vc03 kernel: sc: sc0 already exists; skipping it Mar 26 13:48:06 w2fzz0vc03 kernel: uart: uart0 already exists; skipping it Mar 26 13:48:06 w2fzz0vc03 kernel: vga: vga0 already exists; skipping it Mar 26 13:48:06 w2fzz0vc03 kernel: isa_probe_children: probing non-PnP devices Mar 26 13:48:06 w2fzz0vc03 kernel: orm0: at iomem 0xc0000-0xcc7ff,0xcc800-0xce7ff,0xce800-0xcffff on isa0 Mar 26 13:48:06 w2fzz0vc03 kernel: sc0: at flags 0x100 on isa0 Mar 26 13:48:06 w2fzz0vc03 kernel: sc0: VGA <16 virtual consoles, flags=0x300> Mar 26 13:48:06 w2fzz0vc03 kernel: sc0: fb0, kbd1, terminal emulator: scteken (teken terminal) Mar 26 13:48:06 w2fzz0vc03 kernel: vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 Mar 26 13:48:06 w2fzz0vc03 kernel: fdc0 failed to probe at port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on isa0 Mar 26 13:48:06 w2fzz0vc03 kernel: ppc0: cannot reserve I/O port range Mar 26 13:48:06 w2fzz0vc03 kernel: ppc0: failed to probe at irq 7 on isa0 Mar 26 13:48:06 w2fzz0vc03 kernel: uart1: failed to probe at port 0x2f8-0x2ff irq 3 on isa0 Mar 26 13:48:06 w2fzz0vc03 kernel: uart2: not probed (disabled) Mar 26 13:48:06 w2fzz0vc03 kernel: uart3: not probed (disabled) Mar 26 13:48:06 w2fzz0vc03 kernel: isa_probe_children: probing PnP devices Mar 26 13:48:06 w2fzz0vc03 kernel: Device configuration finished. Mar 26 13:48:06 w2fzz0vc03 kernel: Reducing kern.maxvnodes 257220 -> 100000 Mar 26 13:48:06 w2fzz0vc03 kernel: procfs registered Mar 26 13:48:06 w2fzz0vc03 kernel: WARNING: ZFS is considered to be an experimental feature in FreeBSD. Mar 26 13:48:06 w2fzz0vc03 kernel: lapic: Divisor 2, Frequency 133002270 hz Mar 26 13:48:06 w2fzz0vc03 kernel: Timecounter "TSC" frequency 2660045340 Hz quality -100 Mar 26 13:48:06 w2fzz0vc03 kernel: Timecounters tick every 1.000 msec Mar 26 13:48:06 w2fzz0vc03 kernel: lo0: bpf attached Mar 26 13:48:06 w2fzz0vc03 kernel: hptrr: no controller detected.firewire0: 1 nodes, maxhop <= 0 cable IRM irm(0) (me) Mar 26 13:48:06 w2fzz0vc03 kernel: firewire0: bus manager 0 Mar 26 13:48:06 w2fzz0vc03 kernel: Mar 26 13:48:06 w2fzz0vc03 kernel: ata0: Identifying devices: 00000000 Mar 26 13:48:06 w2fzz0vc03 kernel: ata0: New devices: 00000000 Mar 26 13:48:06 w2fzz0vc03 kernel: ata1: Identifying devices: 00000000 Mar 26 13:48:06 w2fzz0vc03 kernel: ata1: New devices: 00000000 Mar 26 13:48:06 w2fzz0vc03 kernel: ata2: Identifying devices: 00000001 Mar 26 13:48:06 w2fzz0vc03 kernel: ata2: New devices: 00000001 Mar 26 13:48:06 w2fzz0vc03 kernel: usbus0: 12Mbps Full Speed USB v1.0 Mar 26 13:48:06 w2fzz0vc03 kernel: usbus1: 480Mbps High Speed USB v2.0 Mar 26 13:48:06 w2fzz0vc03 kernel: ZFS filesystem version 13 Mar 26 13:48:06 w2fzz0vc03 kernel: ZFS storage pool version 13 Mar 26 13:48:06 w2fzz0vc03 kernel: ugen0.1: at usbus0 Mar 26 13:48:06 w2fzz0vc03 kernel: uhub0: on usbus0 Mar 26 13:48:06 w2fzz0vc03 kernel: ugen1.1: at usbus1 Mar 26 13:48:06 w2fzz0vc03 kernel: uhub1: on usbus1 Mar 26 13:48:06 w2fzz0vc03 kernel: ata2-master: pio=PIO4 wdma=WDMA2 udma=UDMA133 cable=40 wire Mar 26 13:48:06 w2fzz0vc03 kernel: ad4: 305245MB at ata2-master SATA300 Mar 26 13:48:06 w2fzz0vc03 kernel: ad4: 625142448 sectors [620181C/16H/63S] 16 sectors/interrupt 1 depth queue Mar 26 13:48:06 w2fzz0vc03 kernel: GEOM: new disk ad4 Mar 26 13:48:06 w2fzz0vc03 kernel: ad4: nVidia check1 failed Mar 26 13:48:06 w2fzz0vc03 kernel: ad4: Adaptec check1 failed Mar 26 13:48:06 w2fzz0vc03 kernel: ad4: LSI (v3) check1 failed Mar 26 13:48:06 w2fzz0vc03 kernel: ad4: LSI (v2) check1 failed Mar 26 13:48:06 w2fzz0vc03 kernel: ad4: FreeBSGEOM: ad4s1: geometry does not match label (255h,63s != 16h,63s). Mar 26 13:48:06 w2fzz0vc03 kernel: D check1 failed Mar 26 13:48:06 w2fzz0vc03 kernel: ata3: Identifying devices: 00000001 Mar 26 13:48:06 w2fzz0vc03 kernel: ata3: New devices: 00000001 Mar 26 13:48:06 w2fzz0vc03 kernel: ata3-master: pio=PIO4 wdma=WDMA2 udma=UDMA133 cable=40 wire Mar 26 13:48:06 w2fzz0vc03 kernel: ad6: 305245MB at ata3-master SATA300 Mar 26 13:48:06 w2fzz0vc03 kernel: ad6: 625142448 sectors [620181C/16H/63S] 16 sectors/interrupt 1 depth queue Mar 26 13:48:06 w2fzz0vc03 kernel: ad6: nVidia check1 failed Mar 26 13:48:06 w2fzz0vc03 kernel: ad6: Adaptec check1 failed Mar 26 13:48:06 w2fzz0vc03 kernel: ad6: LSI (v3) check1 failed Mar 26 13:48:06 w2fzz0vc03 kernel: ad6: LSI (v2) check1 failed Mar 26 13:48:06 w2fzz0vc03 kernel: ad6: FreeBSD check1 failed Mar 26 13:48:06 w2fzz0vc03 kernel: ata4: Identifying devices: 00010000 Mar 26 13:48:06 w2fzz0vc03 kernel: ata4: New devices: 00010000 Mar 26 13:48:06 w2fzz0vc03 kernel: ata4-master: pio=PIO4 wdma=WDMA2 udma=UDMA33 cable=40 wire Mar 26 13:48:06 w2fzz0vc03 kernel: acd0: CDRW drive at ata4 as master Mar 26 13:48:06 w2fzz0vc03 kernel: acd0: read 1377KB/s (8268KB/s) write 8268KB/s (8268KB/s), 1536KB buffer, SATA150 Mar 26 13:48:06 w2fzz0vc03 kernel: acd0: Reads: CDR, CDRW, CDDA stream, DVDROM, DVDR, packet Mar 26 13:48:06 w2fzz0vc03 kernel: acd0: Writes: CDR, CDRW, test write, burnproof Mar 26 13:48:06 w2fzz0vc03 kernel: acd0: Audio: play, 256 volume levels Mar 26 13:48:06 w2fzz0vc03 kernel: acd0: Mechanism: ejectable tray, unlocked Mar 26 13:48:06 w2fzz0vc03 kernel: acd0: Medium: no/blank disc Mar 26 13:48:06 w2fzz0vc03 kernel: ata5: Identifying devices: 00010000 Mar 26 13:48:06 w2fzz0vc03 kernel: ata5: New devices: 00010000 Mar 26 13:48:06 w2fzz0vc03 kernel: ata5-master: pio=PIO4 wdma=WDMA2 udma=UDMA33 cable=40 wire Mar 26 13:48:06 w2fzz0vc03 kernel: acd1: DVDR drive at ata5 as master Mar 26 13:48:06 w2fzz0vc03 kernel: acd1: read 8269KB/s (8269KB/s) write 8269KB/s (8269KB/s), 2048KB buffer, SATA15GEOM_LABEL: Label for provider ad4s2 is ntfs/System. Mar 26 13:48:06 w2fzz0vc03 kernel: 0 Mar 26 13:48:06 w2fzz0vc03 kernel: acd1: Reads: CDR, CDRW, CDDA stream, DVDROM, DVDR, packet Mar 26 13:48:06 w2fzz0vc03 kernel: acd1: Writes: CDR, CDRW, DVDR, test write, burnproof Mar 26 13:48:06 w2fzz0vc03 kernel: acd1: Audio: play, 256 volume levels Mar 26 13:48:06 w2fzz0vc03 kernel: acd1: Mechanism: ejectable tray, unlocked Mar 26 13:48:06 w2fzz0vc03 kernel: acd1: Medium: CD-ROM unknown Mar 26 13:48:06 w2fzz0vc03 kernel: ata6: Identifying devices: 00000001 Mar 26 13:48:06 w2fzz0vc03 kernel: ata6: New devices: 00000001 Mar 26 13:48:06 w2fzz0vc03 kernel: ata6-master: pio=PIO4 wdma=WDMA2 udma=UDMA133 cable=40 wire Mar 26 13:48:06 w2fzz0vc03 kernel: ad12: 305245MB at ata6-master SATA300 Mar 26 13:48:06 w2fzz0vc03 kernel: ad12: 625142448 sectors [620181C/16H/63S] 16 sectors/interrupt 1 depth queue Mar 26 13:48:06 w2fzz0vc03 kernel: GEOM: new disk ad6 Mar 26 13:48:06 w2fzz0vc03 kernel: GEOM: new disk ad12 Mar 26 13:48:06 w2fzz0vc03 kernel: ad12: nVidia check1 failed Mar 26 13:48:06 w2fzz0vc03 kernel: ad12: Adaptec check1 failed Mar 26 13:48:06 w2fzz0vc03 kernel: ad12: LSI (v3) check1 failed Mar 26 13:48:06 w2fzz0vc03 kernel: ad12: LSI (v2) check1 failed Mar 26 13:48:06 w2fzz0vc03 kernel: ad12: FreeBSD check1 failed Mar 26 13:48:06 w2fzz0vc03 kernel: ata7: Identifying devices: 00000001 Mar 26 13:48:06 w2fzz0vc03 kernel: ata7: New devices: 00000001 Mar 26 13:48:06 w2fzz0vc03 kernel: ata7-master: pio=PIO4 wdma=WDMA2 udma=UDMA133 cable=40 wire Mar 26 13:48:06 w2fzz0vc03 kernel: ad14: 305245MB at ata7-master SATA300 Mar 26 13:48:06 w2fzz0vc03 kernel: ad14: 625142448 sectors [620181C/16H/63S] 16 sectors/interrupt 1 depth queue Mar 26 13:48:06 w2fzz0vc03 kernel: ad14: nVidia check1 failed Mar 26 13:48:06 w2fzz0vc03 kernel: ad14: Adaptec check1 failed Mar 26 13:48:06 w2fzz0vc03 kernel: ad14: LSI (v3) check1 failed Mar 26 13:48:06 w2fzz0vc03 kernel: ad14: LSI (v2) check1 failed Mar 26 13:48:06 w2fzz0vc03 kernel: ad14: FreeBSD check1 failed Mar 26 13:48:06 w2fzz0vc03 kernel: GEOM: new disk ad14 Mar 26 13:48:06 w2fzz0vc03 kernel: uhub0: 10 ports with 10 removable, self powered Mar 26 13:48:06 w2fzz0vc03 kernel: uhub1: 10 ports with 10 removable, self powered Mar 26 13:48:06 w2fzz0vc03 kernel: (probe0:sbp0:0:0:0): error 22 Mar 26 13:48:06 w2fzz0vc03 kernel: (probe0:sbp0:0:0:0): Unretryable Error Mar 26 13:48:06 w2fzz0vc03 kernel: (probe1:sbp0:0:1:0): error 22 Mar 26 13:48:06 w2fzz0vc03 kernel: (probe1:sbp0:0:1:0): Unretryable Error Mar 26 13:48:06 w2fzz0vc03 kernel: (probe2:sbp0:0:2:0): error 22 Mar 26 13:48:06 w2fzz0vc03 kernel: (probe2:sbp0:0:2:0): Unretryable Error Mar 26 13:48:06 w2fzz0vc03 kernel: (probe3:sbp0:0:3:0): error 22 Mar 26 13:48:06 w2fzz0vc03 kernel: (probe3:sbp0:0:3:0): Unretryable Error Mar 26 13:48:06 w2fzz0vc03 kernel: (probe4:sbp0:0:4:0): error 22 Mar 26 13:48:06 w2fzz0vc03 kernel: (probe4:sbp0:0:4:0): Unretryable Error Mar 26 13:48:06 w2fzz0vc03 kernel: (probe5:sbp0:0:5:0): error 22 Mar 26 13:48:06 w2fzz0vc03 kernel: (probe5:sbp0:0:5:0): Unretryable Error Mar 26 13:48:06 w2fzz0vc03 kernel: (probe6:sbp0:0:6:0): error 22 Mar 26 13:48:06 w2fzz0vc03 kernel: (probe6:sbp0:0:6:0): Unretryable Error Mar 26 13:48:06 w2fzz0vc03 kernel: ATA PseudoRAID loaded Mar 26 13:48:06 w2fzz0vc03 kernel: lapic1: Forcing LINT1 to edge trigger Mar 26 13:48:06 w2fzz0vc03 kernel: SMP: AP CPU #1 Launched! Mar 26 13:48:06 w2fzz0vc03 kernel: cpu1 AP: Mar 26 13:48:06 w2fzz0vc03 kernel: ID: 0x01000000 VER: 0x00050014 LDR: 0x00000000 DFR: 0xffffffff Mar 26 13:48:06 w2fzz0vc03 kernel: lint0: 0x00010700 lint1: 0x00008400 TPR: 0x00000000 SVR: 0x000001ff Mar 26 13:48:06 w2fzz0vc03 kernel: timer: 0x000200ef therm: 0x00010000 err: 0x00010000 pcm: 0x00000400 Mar 26 13:48:06 w2fzz0vc03 kernel: lapic3: Forcing LINT1 to edge trigger Mar 26 13:48:06 w2fzz0vc03 kernel: SMP: AP CPU #3 Launched! Mar 26 13:48:06 w2fzz0vc03 kernel: cpu3 AP: Mar 26 13:48:06 w2fzz0vc03 kernel: ID: 0x03000000 VER: 0x00050014 LDR: 0x00000000 DFR: 0xffffffff Mar 26 13:48:06 w2fzz0vc03 kernel: lint0: 0x00010700 lint1: 0x00008400 TPR: 0x00000000 SVR: 0x000001ff Mar 26 13:48:06 w2fzz0vc03 kernel: timer: 0x000200ef therm: 0x00010000 err: 0x00010000 pcm: 0x00000400 Mar 26 13:48:06 w2fzz0vc03 kernel: lapic2: Forcing LINT1 to edge trigger Mar 26 13:48:06 w2fzz0vc03 kernel: SMP: AP CPU #2 Launched! Mar 26 13:48:06 w2fzz0vc03 kernel: cpu2 AP: Mar 26 13:48:06 w2fzz0vc03 kernel: ID: 0x02000000 VER: 0x00050014 LDR: 0x00000000 DFR: 0xffffffff Mar 26 13:48:06 w2fzz0vc03 kernel: lint0: 0x00010700 lint1: 0x00008400 TPR: 0x00000000 SVR: 0x000001ff Mar 26 13:48:06 w2fzz0vc03 kernel: timer: 0x000200ef therm: 0x00010000 err: 0x00010000 pcm: 0x00000400 Mar 26 13:48:06 w2fzz0vc03 kernel: ioapic0: routing intpin 4 (ISA IRQ 4) to lapic 1 vector 48 Mar 26 13:48:06 w2fzz0vc03 kernel: ioapic0: routing intpin 9 (ISA IRQ 9) to lapic 2 vector 48 Mar 26 13:48:06 w2fzz0vc03 kernel: ioapic0: routing intpin 12 (ISA IRQ 12) to lapic 3 vector 48 Mar 26 13:48:06 w2fzz0vc03 kernel: ioapic0: routing intpin 15 (ISA IRQ 15) to lapic 1 vector 49 Mar 26 13:48:06 w2fzz0vc03 kernel: ioapic0: routing intpin 18 (PCI IRQ 18) to lapic 2 vector 49 Mar 26 13:48:06 w2fzz0vc03 kernel: ioapic0: routing intpin 20 (PCI IRQ 20) to lapic 3 vector 49 Mar 26 13:48:06 w2fzz0vc03 kernel: ioapic0: routing intpin 22 (PCI IRQ 22) to lapic 1 vector 50 Mar 26 13:48:06 w2fzz0vc03 kernel: ioapic0: routing intpin 23 (PCI IRQ 23) to lapic 2 vector 50 Mar 26 13:48:06 w2fzz0vc03 kernel: WARNING: WITNESS option enabled, expect reduced performance. Mar 26 13:48:06 w2fzz0vc03 kernel: Root mount waiting for: usbus1 Mar 26 13:48:06 w2fzz0vc03 kernel: ugen1.2: at usbus1 Mar 26 13:48:06 w2fzz0vc03 kernel: Root mount waiting for: usbus1 Mar 26 13:48:06 w2fzz0vc03 kernel: ugen1.3: at usbus1 Mar 26 13:48:06 w2fzz0vc03 kernel: uhub2: on usbus1 Mar 26 13:48:06 w2fzz0vc03 kernel: uhub2: 7 ports with 7 removable, self powered Mar 26 13:48:06 w2fzz0vc03 kernel: Root mount waiting for: usbus1 Mar 26 13:48:06 w2fzz0vc03 kernel: ugen0.2: at usbus0 Mar 26 13:48:06 w2fzz0vc03 kernel: ugen1.4: at usbus1 Mar 26 13:48:06 w2fzz0vc03 kernel: rum0: on usbus1 Mar 26 13:48:06 w2fzz0vc03 kernel: rum0: MAC/BBP RT2573 (rev 0x2573a), RF RT2528 Mar 26 13:48:06 w2fzz0vc03 kernel: Root mount waiting for: usbus1 Mar 26 13:48:06 w2fzz0vc03 kernel: rum0: bpf attached Mar 26 13:48:06 w2fzz0vc03 kernel: rum0: 11b rates: 1Mbps 2Mbps 5.5Mbps 11Mbps Mar 26 13:48:06 w2fzz0vc03 kernel: rum0: 11g rates: 1Mbps 2Mbps 5.5Mbps 11Mbps 6Mbps 9Mbps 12Mbps 18Mbps 24Mbps 36Mbps 48Mbps 54Mbps Mar 26 13:48:06 w2fzz0vc03 kernel: ugen1.5: at usbus1 Mar 26 13:48:06 w2fzz0vc03 kernel: umass0: on usbus1 Mar 26 13:48:06 w2fzz0vc03 kernel: umass0: SCSI over Bulk-Only; quirks = 0x0000 Mar 26 13:48:06 w2fzz0vc03 kernel: Root mount waiting for: usbus1 Mar 26 13:48:06 w2fzz0vc03 kernel: umass0:1:0:-1: Attached to scbus1 Mar 26 13:48:06 w2fzz0vc03 kernel: Trying to mount root from zfs:pool Mar 26 13:48:06 w2fzz0vc03 kernel: (probe0:umass-sim0:0:0:0): Down reving Protocol Version from 2 to 0? Mar 26 13:48:06 w2fzz0vc03 kernel: (probe0:umass-sim0:0:0:0): TEST UNIT READY. CDB: 0 0 0 0 0 0 Mar 26 13:48:06 w2fzz0vc03 kernel: (probe0:umass-sim0:0:0:0): CAM Status: SCSI Status Error Mar 26 13:48:06 w2fzz0vc03 kernel: (probe0:umass-sim0:0:0:0): SCSI Status: Check Condition Mar 26 13:48:06 w2fzz0vc03 kernel: (probe0:umass-sim0:0:0:0): NOT READY asc:3a,0 Mar 26 13:48:06 w2fzz0vc03 kernel: (probe0:umass-sim0:0:0:0): Medium not present Mar 26 13:48:06 w2fzz0vc03 kernel: (probe0:umass-sim0:0:0:0): (probe0:umass-sim0:0:0:0): TEST UNIT READY. CDB: 0 0 0 0 0 0 Mar 26 13:48:06 w2fzz0vc03 kernel: (probe0:umass-sim0:0:0:0): NOT READY asc:3a,0 Mar 26 13:48:06 w2fzz0vc03 kernel: (probe0:umass-sim0:0:0:0): Medium not present Mar 26 13:48:06 w2fzz0vc03 kernel: Unretryable error Mar 26 13:48:06 w2fzz0vc03 kernel: (probe0:umass-sim0:0:0:0): error 6 Mar 26 13:48:06 w2fzz0vc03 kernel: (probe0:umass-sim0:0:0:0): Unretryable Error Mar 26 13:48:06 w2fzz0vc03 kernel: pass0 at umass-sim0 bus 0 target 0 lun 0 Mar 26 13:48:06 w2fzz0vc03 kernel: pass0: Removable Direct Access SCSI-0 device Mar 26 13:48:06 w2fzz0vc03 kernel: pass0: 40.000MB/s transfers Mar 26 13:48:06 w2fzz0vc03 kernel: (da0:umass-sim0:0:0:0): error 6 Mar 26 13:48:06 w2fzz0vc03 kernel: (da0:umass-sim0:0:0:0): Unretryable Error Mar 26 13:48:06 w2fzz0vc03 kernel: da0 at umass-sim0 bus 0 target 0 lun 0 Mar 26 13:48:06 w2fzz0vc03 kernel: da0: Removable Direct Access SCSI-0 device Mar 26 13:48:06 w2fzz0vc03 kernel: da0: 40.000MB/s transfers Mar 26 13:48:06 w2fzz0vc03 kernel: da0: Attempt to query device size failed: NOT READY, Medium not present Mar 26 13:48:06 w2fzz0vc03 kernel: (probe0:umass-sim0:0:0:1): Down reving Protocol Version from 2 to 0? Mar 26 13:48:06 w2fzz0vc03 kernel: GEOM: new disk da0 Mar 26 13:48:06 w2fzz0vc03 kernel: (probe0:umass-sim0:0:0:1): TEST UNIT READY. CDB: 0 20 0 0 0 0 Mar 26 13:48:06 w2fzz0vc03 kernel: (probe0:umass-sim0:0:0:1): CAM Status: SCSI Status Error Mar 26 13:48:06 w2fzz0vc03 kernel: (probe0:umass-sim0:0:0:1): SCSI Status: Check Condition Mar 26 13:48:06 w2fzz0vc03 kernel: (probe0:umass-sim0:0:0:1): NOT READY asc:3a,0 Mar 26 13:48:06 w2fzz0vc03 kernel: (probe0:umass-sim0:0:0:1): Medium not present Mar 26 13:48:06 w2fzz0vc03 kernel: (probe0:umass-sim0:0:0:1): (probe0:umass-sim0:0:0:1): TEST UNIT READY. CDB: 0 20 0 0 0 0 Mar 26 13:48:06 w2fzz0vc03 kernel: (probe0:umass-sim0:0:0:1): NOT READY asc:3a,0 Mar 26 13:48:06 w2fzz0vc03 kernel: (probe0:umass-sim0:0:0:1): Medium not present Mar 26 13:48:06 w2fzz0vc03 kernel: Unretryable error Mar 26 13:48:06 w2fzz0vc03 kernel: (probe0:umass-sim0:0:0:1): error 6 Mar 26 13:48:06 w2fzz0vc03 kernel: (probe0:umass-sim0:0:0:1): Unretryable Error Mar 26 13:48:06 w2fzz0vc03 kernel: pass1 at umass-sim0 bus 0 target 0 lun 1 Mar 26 13:48:06 w2fzz0vc03 kernel: pass1: Removable Direct Access SCSI-0 device Mar 26 13:48:06 w2fzz0vc03 kernel: pass1: 40.000MB/s transfers Mar 26 13:48:06 w2fzz0vc03 kernel: (da0:umass-sim0:0:0:0): error 6 Mar 26 13:48:06 w2fzz0vc03 kernel: (da0:umass-sim0:0:0:0): Unretryable Error Mar 26 13:48:06 w2fzz0vc03 kernel: Opened disk da0 -> 6 Mar 26 13:48:06 w2fzz0vc03 kernel: (da1:umass-sim0:0:0:1): error 6 Mar 26 13:48:06 w2fzz0vc03 kernel: (da1:umass-sim0:0:0:1): Unretryable Error Mar 26 13:48:06 w2fzz0vc03 kernel: da1 at umass-sim0 bus 0 target 0 lun 1 Mar 26 13:48:06 w2fzz0vc03 kernel: da1: Removable Direct Access SCSI-0 device Mar 26 13:48:06 w2fzz0vc03 kernel: da1: 40.000MB/s transfers Mar 26 13:48:06 w2fzz0vc03 kernel: da1: Attempt to query device size failed: NOT READY, Medium not present Mar 26 13:48:06 w2fzz0vc03 kernel: (da0:umass-sim0:0:0:0): error 6 Mar 26 13:48:06 w2fzz0vc03 kernel: (da0:umass-sim0:0:0:0): Unretryable Error Mar 26 13:48:06 w2fzz0vc03 kernel: Opened disk da0 -> 6 Mar 26 13:48:06 w2fzz0vc03 kernel: GEOM: new disk da1 Mar 26 13:48:06 w2fzz0vc03 kernel: (da1:umass-sim0:0:0:1): error 6 Mar 26 13:48:06 w2fzz0vc03 kernel: (da1:umass-sim0:0:0:1): Unretryable Error Mar 26 13:48:06 w2fzz0vc03 kernel: Opened disk da1 -> 6 Mar 26 13:48:06 w2fzz0vc03 kernel: (da1:umass-sim0:0:0:1): error 6 Mar 26 13:48:06 w2fzz0vc03 kernel: (da1:umass-sim0:0:0:1): Unretryable Error Mar 26 13:48:06 w2fzz0vc03 kernel: Opened disk da1 -> 6 Mar 26 13:48:06 w2fzz0vc03 kernel: (probe0:umass-sim0:0:0:2): Down reving Protocol Version from 2 to 0? Mar 26 13:48:06 w2fzz0vc03 kernel: (probe0:umass-sim0:0:0:2): TEST UNIT READY. CDB: 0 40 0 0 0 0 Mar 26 13:48:06 w2fzz0vc03 kernel: (probe0:umass-sim0:0:0:2): CAM Status: SCSI Status Error Mar 26 13:48:06 w2fzz0vc03 kernel: (probe0:umass-sim0:0:0:2): SCSI Status: Check Condition Mar 26 13:48:06 w2fzz0vc03 kernel: (probe0:umass-sim0:0:0:2): NOT READY asc:3a,0 Mar 26 13:48:06 w2fzz0vc03 kernel: (probe0:umass-sim0:0:0:2): Medium not present Mar 26 13:48:06 w2fzz0vc03 kernel: (probe0:umass-sim0:0:0:2): (probe0:umass-sim0:0:0:2): TEST UNIT READY. CDB: 0 40 0 0 0 0 Mar 26 13:48:06 w2fzz0vc03 kernel: (probe0:umass-sim0:0:0:2): NOT READY asc:3a,0 Mar 26 13:48:06 w2fzz0vc03 kernel: (probe0:umass-sim0:0:0:2): Medium not present Mar 26 13:48:06 w2fzz0vc03 kernel: Unretryable error Mar 26 13:48:06 w2fzz0vc03 kernel: (probe0:umass-sim0:0:0:2): error 6 Mar 26 13:48:06 w2fzz0vc03 kernel: (probe0:umass-sim0:0:0:2): Unretryable Error Mar 26 13:48:06 w2fzz0vc03 kernel: pass2 at umass-sim0 bus 0 target 0 lun 2 Mar 26 13:48:06 w2fzz0vc03 kernel: pass2: Removable Direct Access SCSI-0 device Mar 26 13:48:06 w2fzz0vc03 kernel: pass2: 40.000MB/s transfers Mar 26 13:48:06 w2fzz0vc03 kernel: GEOM: new disk da2 Mar 26 13:48:06 w2fzz0vc03 kernel: (da2:umass-sim0:0:0:2): error 6 Mar 26 13:48:06 w2fzz0vc03 kernel: (da2:umass-sim0:0:0:2): Unretryable Error Mar 26 13:48:06 w2fzz0vc03 kernel: da2 at umass-sim0 bus 0 target 0 lun 2 Mar 26 13:48:06 w2fzz0vc03 kernel: da2: Removable Direct Access SCSI-0 device Mar 26 13:48:06 w2fzz0vc03 kernel: da2: 40.000MB/s transfers Mar 26 13:48:06 w2fzz0vc03 kernel: da2: Attempt to query device size failed: NOT READY, Medium not present Mar 26 13:48:06 w2fzz0vc03 kernel: (da2:umass-sim0:0:0:2): error 6 Mar 26 13:48:06 w2fzz0vc03 kernel: (da2:umass-sim0:0:0:2): Unretryable Error Mar 26 13:48:06 w2fzz0vc03 kernel: Opened disk da2 -> 6 Mar 26 13:48:06 w2fzz0vc03 kernel: (da2:umass-sim0:0:0:2): error 6 Mar 26 13:48:06 w2fzz0vc03 kernel: (da2:umass-sim0:0:0:2): Unretryable Error Mar 26 13:48:06 w2fzz0vc03 kernel: Opened disk da2 -> 6 Mar 26 13:48:06 w2fzz0vc03 kernel: (probe0:umass-sim0:0:0:3): Down reving Protocol Version from 2 to 0? Mar 26 13:48:06 w2fzz0vc03 kernel: ct_to_ts([2009-03-26 13:47:58]) = 1238075278.000000000 Mar 26 13:48:06 w2fzz0vc03 kernel: start_init: trying /sbin/init Mar 26 13:48:06 w2fzz0vc03 kernel: (probe0:umass-sim0:0:0:3): TEST UNIT READY. CDB: 0 60 0 0 0 0 Mar 26 13:48:06 w2fzz0vc03 kernel: (probe0:umass-sim0:0:0:3): CAM Status: SCSI Status Error Mar 26 13:48:06 w2fzz0vc03 kernel: (probe0:umass-sim0:0:0:3): SCSI Status: Check Condition Mar 26 13:48:06 w2fzz0vc03 kernel: (probe0:umass-sim0:0:0:3): NOT READY asc:3a,0 Mar 26 13:48:06 w2fzz0vc03 kernel: (probe0:umass-sim0:0:0:3): Medium not present Mar 26 13:48:06 w2fzz0vc03 kernel: (probe0:umass-sim0:0:0:3): (probe0:umass-sim0:0:0:3): TEST UNIT READY. CDB: 0 60 0 0 0 0 Mar 26 13:48:06 w2fzz0vc03 kernel: (probe0:umass-sim0:0:0:3): NOT READY asc:3a,0 Mar 26 13:48:06 w2fzz0vc03 kernel: (probe0:umass-sim0:0:0:3): Medium not present Mar 26 13:48:06 w2fzz0vc03 kernel: Unretryable error Mar 26 13:48:06 w2fzz0vc03 kernel: (probe0:umass-sim0:0:0:3): error 6 Mar 26 13:48:06 w2fzz0vc03 kernel: (probe0:umass-sim0:0:0:3): Unretryable Error Mar 26 13:48:06 w2fzz0vc03 kernel: pass3 at umass-sim0 bus 0 target 0 lun 3 Mar 26 13:48:06 w2fzz0vc03 kernel: pass3: Removable Direct Access SCSI-0 device Mar 26 13:48:06 w2fzz0vc03 kernel: pass3: 40.000MB/s transfers Mar 26 13:48:06 w2fzz0vc03 kernel: GEOM: new disk da3 Mar 26 13:48:06 w2fzz0vc03 kernel: (da3:umass-sim0:0:0:3): error 6 Mar 26 13:48:06 w2fzz0vc03 kernel: (da3:umass-sim0:0:0:3): Unretryable Error Mar 26 13:48:06 w2fzz0vc03 kernel: da3 at umass-sim0 bus 0 target 0 lun 3 Mar 26 13:48:06 w2fzz0vc03 kernel: da3: Removable Direct Access SCSI-0 device Mar 26 13:48:06 w2fzz0vc03 kernel: da3: 40.000MB/s transfers Mar 26 13:48:06 w2fzz0vc03 kernel: da3: Attempt to query device size failed: NOT READY, Medium not present Mar 26 13:48:06 w2fzz0vc03 kernel: (da3:umass-sim0:0:0:3): error 6 Mar 26 13:48:06 w2fzz0vc03 kernel: (da3:umass-sim0:0:0:3): Unretryable Error Mar 26 13:48:06 w2fzz0vc03 kernel: Opened disk da3 -> 6 Mar 26 13:48:06 w2fzz0vc03 kernel: (da3:umass-sim0:0:0:3): error 6 Mar 26 13:48:06 w2fzz0vc03 kernel: (da3:umass-sim0:0:0:3): Unretryable Error Mar 26 13:48:06 w2fzz0vc03 kernel: Opened disk da3 -> 6 Mar 26 13:48:06 w2fzz0vc03 kernel: wlan0: bpf attached Mar 26 13:48:06 w2fzz0vc03 kernel: wlan0: Ethernet address: 00:17:3f:72:40:90 Mar 26 13:48:06 w2fzz0vc03 kernel: wlan0: bpf attached Mar 26 13:48:06 w2fzz0vc03 kernel: wlan0: link state changed to UP Mar 26 13:48:06 w2fzz0vc03 root: /etc/rc: WARNING: Unable to load kernel module linux Mar 26 13:48:06 w2fzz0vc03 kernel: KLD linux.ko: depends on kernel - not available Mar 26 13:48:06 w2fzz0vc03 kernel: linker_load_file: Unsupported file type Mar 26 13:48:14 w2fzz0vc03 auditd[1027]: Auditing disabled Mar 26 13:48:14 w2fzz0vc03 auditd[1027]: Auditing enabled Mar 26 13:48:14 w2fzz0vc03 auditd[1027]: New audit file is /var/audit/20090326134814.not_terminated Mar 26 13:48:14 w2fzz0vc03 auditd[1027]: audit_control(5) may be missing 'host:' field Mar 26 13:48:17 w2fzz0vc03 mDNSResponder (Engineering Build) (Mar 15 2009 06:30:34) [1255]: starting Mar 26 13:48:18 w2fzz0vc03 root: /etc/rc: WARNING: Unable to load kernel module daemon_saver Mar 26 13:48:18 w2fzz0vc03 kernel: KLD daemon_saver.ko: depends on kernel - not available Mar 26 13:48:18 w2fzz0vc03 kernel: linker_load_file: Unsupported file type Mar 26 13:48:22 w2fzz0vc03 kernel: (da0:umass-sim0:0:0:0): error 6 Mar 26 13:48:22 w2fzz0vc03 kernel: (da0:umass-sim0:0:0:0): Unretryable Error Mar 26 13:48:22 w2fzz0vc03 kernel: Opened disk da0 -> 6 Mar 26 13:48:22 w2fzz0vc03 kernel: (da1 Mar 26 13:48:22 w2fzz0vc03 kernel: :umass-sim0:0:0:1): er Mar 26 13:48:22 w2fzz0vc03 kernel: ror 6 Mar 26 13:48:22 w2fzz0vc03 kernel: Mar 26 13:48:22 w2fzz0vc03 kernel: (da1:umass-sim0:0:0:1): Unretryable Error Mar 26 13:48:22 w2fzz0vc03 kernel: Opened disk da1 -> 6 Mar 26 13:48:22 w2fzz0vc03 kernel: (da2:umass-sim0:0:0:2): error 6 Mar 26 13:48:22 w2fzz0vc03 kernel: (da2:umass-sim0:0:0:2): Unretryable Error Mar 26 13:48:22 w2fzz0vc03 kernel: Opened disk da2 -> 6 Mar 26 13:48:22 w2fzz0vc03 kernel: (da3:umass-sim0:0:0:3): error 6 Mar 26 13:48:22 w2fzz0vc03 kernel: (da3:umass-sim0:0:0:3): Unretryable Error Mar 26 13:48:22 w2fzz0vc03 kernel: Opened disk da3 -> 6 Mar 26 13:49:01 w2fzz0vc03 login: ROOT LOGIN (root) ON ttyv0 Mar 26 13:49:21 w2fzz0vc03 kernel: Linux ELF exec handler installed Mar 26 13:49:32 w2fzz0vc03 kernel: splash: image decoder found: green_saver Mar 26 13:49:52 w2fzz0vc03 kernel: linprocfs registered Mar 26 13:49:56 w2fzz0vc03 kernel: linsysfs registered Mar 26 13:54:31 w2fzz0vc03 login: ROOT LOGIN (root) ON ttyv1 --Boundary-00=_6cP0JlXZdTed/wM-- From owner-freebsd-current@FreeBSD.ORG Mon Mar 30 16:48:55 2009 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from [127.0.0.1] (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by hub.freebsd.org (Postfix) with ESMTP id 66DA0106566B; Mon, 30 Mar 2009 16:48:55 +0000 (UTC) (envelope-from jkim@FreeBSD.org) From: Jung-uk Kim To: freebsd-current@FreeBSD.org Date: Mon, 30 Mar 2009 12:48:20 -0400 User-Agent: KMail/1.6.2 References: <200903111233.14029.jkim@FreeBSD.org> <3a142e750903291518x7f941c6ai6b27fae1472a9137@mail.gmail.com> In-Reply-To: <3a142e750903291518x7f941c6ai6b27fae1472a9137@mail.gmail.com> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200903301248.42966.jkim@FreeBSD.org> Cc: Robert Noland , freebsd-amd64@freebsd.org Subject: Re: [HEADSUP] amd64 suspend/resume code to be comitted 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, 30 Mar 2009 16:48:56 -0000 On Sunday 29 March 2009 06:18 pm, Paul B. Mahol wrote: > Just for the record: > > I tested amd64 SMP suspend/resume on HP nx7300 via usb stick and it > works. (video is resumed if agp, drm and i915 are loaded) Great. AFAIK, I believe drm(4) for Intel GPUs has proper suspend/resume code, i.e., rnoland moved the code to MI module and hooked it up to FreeBSD driver. Unfortunately, Linux crowd went crazy about KMS (Kernel Mode Setting) and didn't bother to implement it for other GPUs: https://fedoraproject.org/wiki/Features/KernelModesetting Since we don't have KMS, we have to implement the functionality in our MD driver modules, i.e., save/restore registers and VRAM. I believe rnoland is working on NVidia support code, though. > Now, if only same is going to happen with i386 .... I wish I had some free time... Thanks for the feed back! Jung-uk Kim From owner-freebsd-current@FreeBSD.ORG Mon Mar 30 17:02: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 2C6321065670 for ; Mon, 30 Mar 2009 17:02:00 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id EF61D8FC16 for ; Mon, 30 Mar 2009 17:01:59 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from server.baldwin.cx (pool-98-109-39-197.nwrknj.fios.verizon.net [98.109.39.197]) by cyrus.watson.org (Postfix) with ESMTPSA id 5B27E46B35; Mon, 30 Mar 2009 13:01:59 -0400 (EDT) Received: from localhost (john@localhost [127.0.0.1]) (authenticated bits=0) by server.baldwin.cx (8.14.3/8.14.3) with ESMTP id n2UH1reH023682; Mon, 30 Mar 2009 13:01:53 -0400 (EDT) (envelope-from jhb@freebsd.org) From: John Baldwin To: barney_cordoba@yahoo.com Date: Mon, 30 Mar 2009 12:49:58 -0400 User-Agent: KMail/1.9.7 References: <285609.93285.qm@web63905.mail.re1.yahoo.com> In-Reply-To: <285609.93285.qm@web63905.mail.re1.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200903301249.58983.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (server.baldwin.cx [127.0.0.1]); Mon, 30 Mar 2009 13:01:53 -0400 (EDT) X-Virus-Scanned: ClamAV 0.94.2/9181/Mon Mar 30 11:21:09 2009 on server.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-4.4 required=4.2 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.1.3 X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on server.baldwin.cx Cc: freebsd-current@freebsd.org Subject: Re: cpuset affinity control from within the kernel 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, 30 Mar 2009 17:02:00 -0000 On Monday 30 March 2009 12:34:33 pm Barney Cordoba wrote: > > --- On Mon, 3/30/09, John Baldwin wrote: > > > From: John Baldwin > > Subject: Re: cpuset affinity control from within the kernel > > To: freebsd-current@FreeBSD.org, barney_cordoba@yahoo.com > > Date: Monday, March 30, 2009, 11:00 AM > > On Sunday 29 March 2009 3:59:40 pm Barney Cordoba wrote: > > > > > > What tools are available for taskqueues, interrupts, > > etc from within the > > kernel? > > > > You can use BUS_BIND_INTR() for interrupts. You can use > > 'sched_bind() / > > sched_unbind()' in thread contexts. For example, to > > pin taskqueue threads > > (you should only do this for a private taskqueue you create > > though) you can > > simply enqueue a task to the thread that does a > > 'sched_bind()'. > > > > -- > > John Baldwin > > There doesn't seem to be a man page for those functions. Are there some > docs somewhere? Can I bind to a set of cores as can be done with cpuset? They both take a single CPU as the argument, so you can only bind to one. -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Mon Mar 30 17:03: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 12BF51065676; Mon, 30 Mar 2009 17:03:36 +0000 (UTC) (envelope-from onemda@gmail.com) Received: from mail-ew0-f171.google.com (mail-ew0-f171.google.com [209.85.219.171]) by mx1.freebsd.org (Postfix) with ESMTP id 1C6EE8FC18; Mon, 30 Mar 2009 17:03:34 +0000 (UTC) (envelope-from onemda@gmail.com) Received: by ewy19 with SMTP id 19so1972720ewy.43 for ; Mon, 30 Mar 2009 10:03:33 -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=bFTjVCWt7Vd+dlOtYMMYc9GPpG7Q/WwjDPjIm3yNnWU=; b=xEwkQt3iP7xSBl2zjvs7wxKKIIiseOt/hBGziaXO/B53W1o1DH6xMaq8+3uADJEqpR OP4luiMkOhi/Pqz7oy48oO2IzQaulQepA0yczk+x7j/SwL3iUy5j/6Kyefp3UBWQ94cZ UskzRNJ2lFi4DWLXg8/0DnhrEQHkIWTUx+2xk= 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=xyJRDvwaKXL4pSLY/Xxo2vRDvkqt5/XWWHOo3o+FNPZkMgfNO1kkKxEwvaYOcSPOJU 5rcwL2GL13KHqlaasVFbGmFw8jKiQr8SSgoXEDpb7y9X8vGGDDjjuM63zFj02PSmiH+3 70rGRMlLpk/kfGZfZ67OOfk26KAmByHRSWfW4= MIME-Version: 1.0 Received: by 10.210.56.9 with SMTP id e9mr595409eba.87.1238432613548; Mon, 30 Mar 2009 10:03:33 -0700 (PDT) In-Reply-To: <20090330162553.GA44858@citylink.fud.org.nz> References: <1237804575.1771.7.camel@balrog.2hip.net> <1237884572.1771.28.camel@balrog.2hip.net> <20090330061036.GA83528@citylink.fud.org.nz> <3a142e750903300804r75d6ef81kae69cdfdb618b719@mail.gmail.com> <20090330162553.GA44858@citylink.fud.org.nz> Date: Mon, 30 Mar 2009 18:03:33 +0100 Message-ID: <3a142e750903301003o27369595gaee12b5f8232ac6@mail.gmail.com> From: "Paul B. Mahol" To: Andrew Thompson Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org, Nenhum_de_Nos , Robert Noland Subject: Re: Booting from usb hard disk 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, 30 Mar 2009 17:03:36 -0000 On 3/30/09, Andrew Thompson wrote: > On Mon, Mar 30, 2009 at 04:04:17PM +0100, Paul B. Mahol wrote: >> On 3/30/09, Andrew Thompson wrote: >> > On Tue, Mar 24, 2009 at 03:49:32AM -0500, Robert Noland wrote: >> >> On Mon, 2009-03-23 at 19:40 -0300, Nenhum_de_Nos wrote: >> >> > >> >> > I had problem a while ago with via mini itx hardware, that was quite >> >> > close. If I try boot from usb (installed in usb hdd), I get to the >> >> > point >> >> > of loader not finding my disk. >> >> > >> >> > I then used a small flash disk attached to the ata (44 pin ide) >> >> > channel >> >> > and formatted /boot in there. this way I get to the point of mount >> >> > root >> >> > you said, and da0 not being alive soon enough to mount root. list >> >> > disks >> >> > also couldn't find da0 though. >> >> > >> >> > I tried current from that time, and no good. >> >> > >> >> > if this is solved, I'll be happy to try whatever patch to current. >> >> > (as >> >> > long as I can install it from another box/or its ata channel, as it >> >> > can't >> >> > boot vanilla 7.1R) >> >> >> >> So, my solution was to set kern.cam.scsi_delay=10000 >> >> in /boot/loader.conf >> > >> > The following patch should work. It creates interleaving root hold >> > tokens from the CAM probe to disk_create and geom providor tasting. >> > I had to add a malloc type flag as sleeping isnt allowed at the point I >> > added the token alloc in CAM. >> > >> > http://people.freebsd.org/~thompsa/root_wait.diff >> >> Hmm, this is supposed to fix issue when trying to boot from usb disk >> with UP kernel? > > This is to address the issue where the usb disk hasnt been attached by > the time the root filesystem is mounted. ie, you are booting from usb. > > If your problem is different then please say. On SMP booting from usb works (kern.cam.scsi_delay=2000), da0 will appear after user is asked to enter root mount point, and pressing ? will show ufs:da0s1a. On UP it doesnt work, ufs:da0s1a is not available. I thought it may be related to scsi_delay but increasing it was not solution. -- Paul From owner-freebsd-current@FreeBSD.ORG Mon Mar 30 17:14: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 0A0161065672; Mon, 30 Mar 2009 17:14:11 +0000 (UTC) (envelope-from thompsa@FreeBSD.org) Received: from pele.citylink.co.nz (pele.citylink.co.nz [202.8.44.226]) by mx1.freebsd.org (Postfix) with ESMTP id 8CD808FC13; Mon, 30 Mar 2009 17:14:10 +0000 (UTC) (envelope-from thompsa@FreeBSD.org) Received: from localhost (localhost [127.0.0.1]) by pele.citylink.co.nz (Postfix) with ESMTP id C46B3FEFD; Tue, 31 Mar 2009 06:14:09 +1300 (NZDT) X-Virus-Scanned: Debian amavisd-new at citylink.co.nz Received: from pele.citylink.co.nz ([127.0.0.1]) by localhost (pele.citylink.co.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q0WSLhmxDbvH; Tue, 31 Mar 2009 06:14:05 +1300 (NZDT) Received: from citylink.fud.org.nz (unknown [202.8.44.45]) by pele.citylink.co.nz (Postfix) with ESMTP; Tue, 31 Mar 2009 06:14:05 +1300 (NZDT) Received: by citylink.fud.org.nz (Postfix, from userid 1001) id 329121142F; Tue, 31 Mar 2009 06:14:05 +1300 (NZDT) Date: Mon, 30 Mar 2009 10:14:05 -0700 From: Andrew Thompson To: "Paul B. Mahol" Message-ID: <20090330171405.GB44858@citylink.fud.org.nz> References: <1237804575.1771.7.camel@balrog.2hip.net> <1237884572.1771.28.camel@balrog.2hip.net> <20090330061036.GA83528@citylink.fud.org.nz> <3a142e750903300804r75d6ef81kae69cdfdb618b719@mail.gmail.com> <20090330162553.GA44858@citylink.fud.org.nz> <3a142e750903301003o27369595gaee12b5f8232ac6@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3a142e750903301003o27369595gaee12b5f8232ac6@mail.gmail.com> User-Agent: Mutt/1.5.17 (2007-11-01) Cc: freebsd-current@freebsd.org, Nenhum_de_Nos , Robert Noland Subject: Re: Booting from usb hard disk 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, 30 Mar 2009 17:14:11 -0000 On Mon, Mar 30, 2009 at 06:03:33PM +0100, Paul B. Mahol wrote: > On 3/30/09, Andrew Thompson wrote: > > On Mon, Mar 30, 2009 at 04:04:17PM +0100, Paul B. Mahol wrote: > >> On 3/30/09, Andrew Thompson wrote: > >> > On Tue, Mar 24, 2009 at 03:49:32AM -0500, Robert Noland wrote: > >> >> On Mon, 2009-03-23 at 19:40 -0300, Nenhum_de_Nos wrote: > >> >> > > >> >> > I had problem a while ago with via mini itx hardware, that was quite > >> >> > close. If I try boot from usb (installed in usb hdd), I get to the > >> >> > point > >> >> > of loader not finding my disk. > >> >> > > >> >> > I then used a small flash disk attached to the ata (44 pin ide) > >> >> > channel > >> >> > and formatted /boot in there. this way I get to the point of mount > >> >> > root > >> >> > you said, and da0 not being alive soon enough to mount root. list > >> >> > disks > >> >> > also couldn't find da0 though. > >> >> > > >> >> > I tried current from that time, and no good. > >> >> > > >> >> > if this is solved, I'll be happy to try whatever patch to current. > >> >> > (as > >> >> > long as I can install it from another box/or its ata channel, as it > >> >> > can't > >> >> > boot vanilla 7.1R) > >> >> > >> >> So, my solution was to set kern.cam.scsi_delay=10000 > >> >> in /boot/loader.conf > >> > > >> > The following patch should work. It creates interleaving root hold > >> > tokens from the CAM probe to disk_create and geom providor tasting. > >> > I had to add a malloc type flag as sleeping isnt allowed at the point I > >> > added the token alloc in CAM. > >> > > >> > http://people.freebsd.org/~thompsa/root_wait.diff > >> > >> Hmm, this is supposed to fix issue when trying to boot from usb disk > >> with UP kernel? > > > > This is to address the issue where the usb disk hasnt been attached by > > the time the root filesystem is mounted. ie, you are booting from usb. > > > > If your problem is different then please say. > > On SMP booting from usb works (kern.cam.scsi_delay=2000), da0 will appear > after user is asked to enter root mount point, and pressing ? will show > ufs:da0s1a. On UP it doesnt work, ufs:da0s1a is not available. > I thought it may be related to scsi_delay but increasing it was not > solution. Well the patch should (hopefully) fix this and you will no longer need to set the scsi delay. Please test! :) Andrew From owner-freebsd-current@FreeBSD.ORG Mon Mar 30 17:23: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 1DE89106566C for ; Mon, 30 Mar 2009 17:23:52 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 5A45B8FC13 for ; Mon, 30 Mar 2009 17:23:51 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from odyssey.starpoint.kiev.ua (alpha-e.starpoint.kiev.ua [212.40.38.101]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id UAA07958; Mon, 30 Mar 2009 20:23:43 +0300 (EEST) (envelope-from avg@icyb.net.ua) Message-ID: <49D1001E.2050405@icyb.net.ua> Date: Mon, 30 Mar 2009 20:23:42 +0300 From: Andriy Gapon User-Agent: Thunderbird 2.0.0.21 (X11/20090323) MIME-Version: 1.0 To: Aragon Gouveia References: <4451ccf20903300123p4df9c1d7k4c4138ad25d2d4af@mail.gmail.com> <49D0E44C.60103@phat.za.net> In-Reply-To: <49D0E44C.60103@phat.za.net> X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Cc: freebsd-current@freebsd.org, ccuiyyan@gmail.com Subject: Re: loader prompt doesn't work 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, 30 Mar 2009 17:23:52 -0000 on 30/03/2009 18:25 Aragon Gouveia said the following: > 崔岩ccuiyyan@sina.com wrote: >> However, problem happens. When i select the "escape to a loader >> prompt" >> option, i can input >> >> in about just 3 sec. After that, the system cannot go on whatever >> key i >> hit. > > Same problem here and it's not USB/keyboard related in my case. What > motherboard are you using? I'm on an Intel DG33BU. There was a significant fix to boot code made recently by jhb. It is now in head, stable/7 and stable/6. So you need to update to the recent resources. What you also need (and what was not emphasized enough, IMO) is to actually install new boot code (/boot/boot) to your active slices after installworld completes. E.g.: $ gpart bootcode -b /boot/boot adXsY -- Andriy Gapon From owner-freebsd-current@FreeBSD.ORG Mon Mar 30 17:28: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 D614D1065674; Mon, 30 Mar 2009 17:28:08 +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 A54168FC13; Mon, 30 Mar 2009 17:28:08 +0000 (UTC) (envelope-from rnoland@FreeBSD.org) Received: from [192.168.1.156] (adsl-157-58-177.bna.bellsouth.net [70.157.58.177]) (authenticated bits=0) by gizmo.2hip.net (8.14.3/8.14.3) with ESMTP id n2UHQgai067625 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 30 Mar 2009 13:26:42 -0400 (EDT) (envelope-from rnoland@FreeBSD.org) From: Robert Noland To: "Paul B. Mahol" In-Reply-To: <3a142e750903301003o27369595gaee12b5f8232ac6@mail.gmail.com> References: <1237804575.1771.7.camel@balrog.2hip.net> <1237884572.1771.28.camel@balrog.2hip.net> <20090330061036.GA83528@citylink.fud.org.nz> <3a142e750903300804r75d6ef81kae69cdfdb618b719@mail.gmail.com> <20090330162553.GA44858@citylink.fud.org.nz> <3a142e750903301003o27369595gaee12b5f8232ac6@mail.gmail.com> Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-IPDIFVlzZgeJdvEDT0Xi" Organization: FreeBSD Date: Mon, 30 Mar 2009 12:27:29 -0500 Message-Id: <1238434049.8491.339.camel@balrog.2hip.net> Mime-Version: 1.0 X-Mailer: Evolution 2.24.5 FreeBSD GNOME Team Port X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00,RCVD_IN_PBL, RDNS_DYNAMIC 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, Nenhum_de_Nos , Andrew Thompson Subject: Re: Booting from usb hard disk 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, 30 Mar 2009 17:28:09 -0000 --=-IPDIFVlzZgeJdvEDT0Xi Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Mon, 2009-03-30 at 18:03 +0100, Paul B. Mahol wrote: > On 3/30/09, Andrew Thompson wrote: > > On Mon, Mar 30, 2009 at 04:04:17PM +0100, Paul B. Mahol wrote: > >> On 3/30/09, Andrew Thompson wrote: > >> > On Tue, Mar 24, 2009 at 03:49:32AM -0500, Robert Noland wrote: > >> >> On Mon, 2009-03-23 at 19:40 -0300, Nenhum_de_Nos wrote: > >> >> > > >> >> > I had problem a while ago with via mini itx hardware, that was qu= ite > >> >> > close. If I try boot from usb (installed in usb hdd), I get to th= e > >> >> > point > >> >> > of loader not finding my disk. > >> >> > > >> >> > I then used a small flash disk attached to the ata (44 pin ide) > >> >> > channel > >> >> > and formatted /boot in there. this way I get to the point of moun= t > >> >> > root > >> >> > you said, and da0 not being alive soon enough to mount root. list > >> >> > disks > >> >> > also couldn't find da0 though. > >> >> > > >> >> > I tried current from that time, and no good. > >> >> > > >> >> > if this is solved, I'll be happy to try whatever patch to current= . > >> >> > (as > >> >> > long as I can install it from another box/or its ata channel, as = it > >> >> > can't > >> >> > boot vanilla 7.1R) > >> >> > >> >> So, my solution was to set kern.cam.scsi_delay=3D10000 > >> >> in /boot/loader.conf > >> > > >> > The following patch should work. It creates interleaving root hold > >> > tokens from the CAM probe to disk_create and geom providor tasting. > >> > I had to add a malloc type flag as sleeping isnt allowed at the poin= t I > >> > added the token alloc in CAM. > >> > > >> > http://people.freebsd.org/~thompsa/root_wait.diff > >> > >> Hmm, this is supposed to fix issue when trying to boot from usb disk > >> with UP kernel? > > > > This is to address the issue where the usb disk hasnt been attached by > > the time the root filesystem is mounted. ie, you are booting from usb. > > > > If your problem is different then please say. >=20 > On SMP booting from usb works (kern.cam.scsi_delay=3D2000), da0 will appe= ar > after user is asked to enter root mount point, and pressing ? will show > ufs:da0s1a. On UP it doesnt work, ufs:da0s1a is not available. > I thought it may be related to scsi_delay but increasing it was not > solution. scsi_delay=3D10000 was working for me on UP, haven't gotten the new patch tested yet though. robert. --=20 Robert Noland FreeBSD --=-IPDIFVlzZgeJdvEDT0Xi Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.11 (FreeBSD) iEYEABECAAYFAknRAQEACgkQM4TrQ4qfRONe4gCfcg6mtWAKgeyqvPGvw4cEuhMy JHIAnj73fJc9SupyqeBfPRsrOrcNWSPE =439+ -----END PGP SIGNATURE----- --=-IPDIFVlzZgeJdvEDT0Xi-- From owner-freebsd-current@FreeBSD.ORG Mon Mar 30 18:34: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 E5315106566C; Mon, 30 Mar 2009 18:34:32 +0000 (UTC) (envelope-from onemda@gmail.com) Received: from mail-ew0-f171.google.com (mail-ew0-f171.google.com [209.85.219.171]) by mx1.freebsd.org (Postfix) with ESMTP id F306D8FC1F; Mon, 30 Mar 2009 18:34:31 +0000 (UTC) (envelope-from onemda@gmail.com) Received: by ewy19 with SMTP id 19so2016063ewy.43 for ; Mon, 30 Mar 2009 11:34:30 -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=g7pztWQPpNrbRFWZaM3Mx4qDQ2ku0BrUo1HF34czrNw=; b=bvzi9sbLXGFZAQiofaIXQsp8m4MMsvooEuIhN6of7HAhFr3unBVHarhn+hCJGUDAg/ bb8IMbZg7cYExeMFMKe6MlRE3u+6Oe26jUeJ/b4rlenouZv4HtIWhDUFRjcG3RAuvfAO lvQgG1oQ97m4nfSRN97va5SkC10jAJa17PwQE= 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=b2tzYHx6UgGKWkSW9BED7Op4UkWAvWC92n7Vta01HUJSWnStnywmQeR5QlwNyBWqG/ HVWYiznM57CFssqI4XJZbgWH0XLgJvq+ruKybjUtVxPRZfJbBhTfU24OlCcjU6dp1Ixo HZmsvMeTTBX70qGPi3DIzn63c0hesuc3Fm6F8= MIME-Version: 1.0 Received: by 10.210.127.13 with SMTP id z13mr2808036ebc.91.1238438070864; Mon, 30 Mar 2009 11:34:30 -0700 (PDT) In-Reply-To: <20090330171405.GB44858@citylink.fud.org.nz> References: <1237804575.1771.7.camel@balrog.2hip.net> <1237884572.1771.28.camel@balrog.2hip.net> <20090330061036.GA83528@citylink.fud.org.nz> <3a142e750903300804r75d6ef81kae69cdfdb618b719@mail.gmail.com> <20090330162553.GA44858@citylink.fud.org.nz> <3a142e750903301003o27369595gaee12b5f8232ac6@mail.gmail.com> <20090330171405.GB44858@citylink.fud.org.nz> Date: Mon, 30 Mar 2009 19:34:29 +0100 Message-ID: <3a142e750903301134i40328c88y1e150eb3859c009d@mail.gmail.com> From: "Paul B. Mahol" To: Andrew Thompson Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org, Nenhum_de_Nos , Robert Noland Subject: Re: Booting from usb hard disk 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, 30 Mar 2009 18:34:33 -0000 On 3/30/09, Andrew Thompson wrote: > On Mon, Mar 30, 2009 at 06:03:33PM +0100, Paul B. Mahol wrote: >> On 3/30/09, Andrew Thompson wrote: >> > On Mon, Mar 30, 2009 at 04:04:17PM +0100, Paul B. Mahol wrote: >> >> On 3/30/09, Andrew Thompson wrote: >> >> > On Tue, Mar 24, 2009 at 03:49:32AM -0500, Robert Noland wrote: >> >> >> On Mon, 2009-03-23 at 19:40 -0300, Nenhum_de_Nos wrote: >> >> >> > >> >> >> > I had problem a while ago with via mini itx hardware, that was >> >> >> > quite >> >> >> > close. If I try boot from usb (installed in usb hdd), I get to the >> >> >> > point >> >> >> > of loader not finding my disk. >> >> >> > >> >> >> > I then used a small flash disk attached to the ata (44 pin ide) >> >> >> > channel >> >> >> > and formatted /boot in there. this way I get to the point of mount >> >> >> > root >> >> >> > you said, and da0 not being alive soon enough to mount root. list >> >> >> > disks >> >> >> > also couldn't find da0 though. >> >> >> > >> >> >> > I tried current from that time, and no good. >> >> >> > >> >> >> > if this is solved, I'll be happy to try whatever patch to current. >> >> >> > (as >> >> >> > long as I can install it from another box/or its ata channel, as >> >> >> > it >> >> >> > can't >> >> >> > boot vanilla 7.1R) >> >> >> >> >> >> So, my solution was to set kern.cam.scsi_delay=10000 >> >> >> in /boot/loader.conf >> >> > >> >> > The following patch should work. It creates interleaving root hold >> >> > tokens from the CAM probe to disk_create and geom providor tasting. >> >> > I had to add a malloc type flag as sleeping isnt allowed at the point >> >> > I >> >> > added the token alloc in CAM. >> >> > >> >> > http://people.freebsd.org/~thompsa/root_wait.diff >> >> >> >> Hmm, this is supposed to fix issue when trying to boot from usb disk >> >> with UP kernel? >> > >> > This is to address the issue where the usb disk hasnt been attached by >> > the time the root filesystem is mounted. ie, you are booting from usb. >> > >> > If your problem is different then please say. >> >> On SMP booting from usb works (kern.cam.scsi_delay=2000), da0 will appear >> after user is asked to enter root mount point, and pressing ? will show >> ufs:da0s1a. On UP it doesnt work, ufs:da0s1a is not available. >> I thought it may be related to scsi_delay but increasing it was not >> solution. > > Well the patch should (hopefully) fix this and you will no longer need > to set the scsi delay. Please test! :) With 2000 it works for both UP & SMP but setting scsi_delay to 50000 caused text to scroll forever, waiting for CAM. Could scsi_delay get removed? -- Paul From owner-freebsd-current@FreeBSD.ORG Mon Mar 30 18:37:54 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 82F181065686; Mon, 30 Mar 2009 18:37:54 +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 4F3368FC12; Mon, 30 Mar 2009 18:37:54 +0000 (UTC) (envelope-from rnoland@FreeBSD.org) Received: from [192.168.1.156] (adsl-157-58-177.bna.bellsouth.net [70.157.58.177]) (authenticated bits=0) by gizmo.2hip.net (8.14.3/8.14.3) with ESMTP id n2UIaVqT067978 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 30 Mar 2009 14:36:31 -0400 (EDT) (envelope-from rnoland@FreeBSD.org) From: Robert Noland To: "Paul B. Mahol" In-Reply-To: <3a142e750903301134i40328c88y1e150eb3859c009d@mail.gmail.com> References: <1237804575.1771.7.camel@balrog.2hip.net> <1237884572.1771.28.camel@balrog.2hip.net> <20090330061036.GA83528@citylink.fud.org.nz> <3a142e750903300804r75d6ef81kae69cdfdb618b719@mail.gmail.com> <20090330162553.GA44858@citylink.fud.org.nz> <3a142e750903301003o27369595gaee12b5f8232ac6@mail.gmail.com> <20090330171405.GB44858@citylink.fud.org.nz> <3a142e750903301134i40328c88y1e150eb3859c009d@mail.gmail.com> Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-MaMPXF7l/lPsV90sDC77" Organization: FreeBSD Date: Mon, 30 Mar 2009 13:37:18 -0500 Message-Id: <1238438238.8491.349.camel@balrog.2hip.net> Mime-Version: 1.0 X-Mailer: Evolution 2.24.5 FreeBSD GNOME Team Port X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00,RCVD_IN_PBL, RDNS_DYNAMIC 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, Nenhum_de_Nos , Andrew Thompson Subject: Re: Booting from usb hard disk 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, 30 Mar 2009 18:37:57 -0000 --=-MaMPXF7l/lPsV90sDC77 Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Mon, 2009-03-30 at 19:34 +0100, Paul B. Mahol wrote: > On 3/30/09, Andrew Thompson wrote: > > On Mon, Mar 30, 2009 at 06:03:33PM +0100, Paul B. Mahol wrote: > >> On 3/30/09, Andrew Thompson wrote: > >> > On Mon, Mar 30, 2009 at 04:04:17PM +0100, Paul B. Mahol wrote: > >> >> On 3/30/09, Andrew Thompson wrote: > >> >> > On Tue, Mar 24, 2009 at 03:49:32AM -0500, Robert Noland wrote: > >> >> >> On Mon, 2009-03-23 at 19:40 -0300, Nenhum_de_Nos wrote: > >> >> >> > > >> >> >> > I had problem a while ago with via mini itx hardware, that was > >> >> >> > quite > >> >> >> > close. If I try boot from usb (installed in usb hdd), I get to= the > >> >> >> > point > >> >> >> > of loader not finding my disk. > >> >> >> > > >> >> >> > I then used a small flash disk attached to the ata (44 pin ide= ) > >> >> >> > channel > >> >> >> > and formatted /boot in there. this way I get to the point of m= ount > >> >> >> > root > >> >> >> > you said, and da0 not being alive soon enough to mount root. l= ist > >> >> >> > disks > >> >> >> > also couldn't find da0 though. > >> >> >> > > >> >> >> > I tried current from that time, and no good. > >> >> >> > > >> >> >> > if this is solved, I'll be happy to try whatever patch to curr= ent. > >> >> >> > (as > >> >> >> > long as I can install it from another box/or its ata channel, = as > >> >> >> > it > >> >> >> > can't > >> >> >> > boot vanilla 7.1R) > >> >> >> > >> >> >> So, my solution was to set kern.cam.scsi_delay=3D10000 > >> >> >> in /boot/loader.conf > >> >> > > >> >> > The following patch should work. It creates interleaving root hol= d > >> >> > tokens from the CAM probe to disk_create and geom providor tastin= g. > >> >> > I had to add a malloc type flag as sleeping isnt allowed at the p= oint > >> >> > I > >> >> > added the token alloc in CAM. > >> >> > > >> >> > http://people.freebsd.org/~thompsa/root_wait.diff > >> >> > >> >> Hmm, this is supposed to fix issue when trying to boot from usb dis= k > >> >> with UP kernel? > >> > > >> > This is to address the issue where the usb disk hasnt been attached = by > >> > the time the root filesystem is mounted. ie, you are booting from us= b. > >> > > >> > If your problem is different then please say. > >> > >> On SMP booting from usb works (kern.cam.scsi_delay=3D2000), da0 will a= ppear > >> after user is asked to enter root mount point, and pressing ? will sho= w > >> ufs:da0s1a. On UP it doesnt work, ufs:da0s1a is not available. > >> I thought it may be related to scsi_delay but increasing it was not > >> solution. > > > > Well the patch should (hopefully) fix this and you will no longer need > > to set the scsi delay. Please test! :) >=20 > With 2000 it works for both UP & SMP but setting scsi_delay to 50000 caus= ed > text to scroll forever, waiting for CAM. >=20 > Could scsi_delay get removed? Well, the default value on HEAD is 5000, I just doubled that and it worked for me... robert. >=20 --=20 Robert Noland FreeBSD --=-MaMPXF7l/lPsV90sDC77 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.11 (FreeBSD) iEYEABECAAYFAknREV4ACgkQM4TrQ4qfROPuEACfYzQZ9bCeE8ZwcE9Y2hVDKDRI qMYAnRqPgyLWAtf6E39VeGw2kkMaAFf6 =gUvq -----END PGP SIGNATURE----- --=-MaMPXF7l/lPsV90sDC77-- From owner-freebsd-current@FreeBSD.ORG Mon Mar 30 18:50: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 093741065678 for ; Mon, 30 Mar 2009 18:50:59 +0000 (UTC) (envelope-from freebsd-listen@fabiankeil.de) Received: from smtprelay04.ispgateway.de (smtprelay04.ispgateway.de [80.67.18.16]) by mx1.freebsd.org (Postfix) with ESMTP id 720228FC23 for ; Mon, 30 Mar 2009 18:50:58 +0000 (UTC) (envelope-from freebsd-listen@fabiankeil.de) Received: from [88.153.16.109] (helo=localhost) by smtprelay04.ispgateway.de with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.68) (envelope-from ) id 1LoMZU-00059c-Rs for freebsd-current@freebsd.org; Mon, 30 Mar 2009 20:50:57 +0200 Date: Mon, 30 Mar 2009 20:50:49 +0200 From: Fabian Keil To: freebsd-current@freebsd.org Message-ID: <20090330205049.0c28552c@fabiankeil.de> X-Mailer: Claws Mail 3.7.0 (GTK+ 2.14.7; i386-portbld-freebsd8.0) X-PGP-KEY-URL: http://www.fabiankeil.de/gpg-keys/freebsd-listen-2008-08-18.asc Mime-Version: 1.0 Content-Type: multipart/signed; boundary="Sig_/kp4DqCC0auUIc6DlwUxdkM_"; protocol="application/pgp-signature"; micalg=PGP-SHA1 X-Df-Sender: 775067 Subject: Fatal double fault in pf_pull_hdr() after ifconfig wlan0 mtu 100 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, 30 Mar 2009 18:50:59 -0000 --Sig_/kp4DqCC0auUIc6DlwUxdkM_ Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable A few seconds after changing wlan0's mtu to 100 (to debug an application problem), the system froze. Reproducing the problem without Xorg running I got: fk@TP51 /usr/crash $ kgdb /boot/kernel/kernel.symbols vmcore.4 GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain condition= s. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i386-marcel-freebsd"... Unread portion of the kernel message buffer: Fatal double fault: eip =3D 0xc04a63d4 esp =3D 0xf3c06ff4 ebp =3D 0xf3c07010 cpuid =3D 0; apic id =3D 00 panic: double fault cpuid =3D 0 KDB: enter: panic panic: from debugger cpuid =3D 0 Uptime: 4m54s Physical memory: 998 MB Dumping 138 MB: 123 107 91 75 59 43 27 11 Reading symbols from /boot/kernel/unionfs.ko...Reading symbols from /boot/k= ernel/unionfs.ko.symbols...done. done. Loaded symbols for /boot/kernel/unionfs.ko Reading symbols from /boot/kernel/if_tap.ko...Reading symbols from /boot/ke= rnel/if_tap.ko.symbols...done. done. Loaded symbols for /boot/kernel/if_tap.ko Reading symbols from /boot/kernel/if_iwi.ko...Reading symbols from /boot/ke= rnel/if_iwi.ko.symbols...done. done. Loaded symbols for /boot/kernel/if_iwi.ko Reading symbols from /boot/kernel/snd_ich.ko...Reading symbols from /boot/k= ernel/snd_ich.ko.symbols...done. done. Loaded symbols for /boot/kernel/snd_ich.ko Reading symbols from /boot/kernel/sound.ko...Reading symbols from /boot/ker= nel/sound.ko.symbols...done. done. Loaded symbols for /boot/kernel/sound.ko Reading symbols from /boot/kernel/acpi_video.ko...Reading symbols from /boo= t/kernel/acpi_video.ko.symbols...done. done. Loaded symbols for /boot/kernel/acpi_video.ko Reading symbols from /boot/kernel/radeon.ko...Reading symbols from /boot/ke= rnel/radeon.ko.symbols...done. done. Loaded symbols for /boot/kernel/radeon.ko Reading symbols from /boot/kernel/drm.ko...Reading symbols from /boot/kerne= l/drm.ko.symbols...done. done. Loaded symbols for /boot/kernel/drm.ko Reading symbols from /boot/kernel/acpi_ibm.ko...Reading symbols from /boot/= kernel/acpi_ibm.ko.symbols...done. done. Loaded symbols for /boot/kernel/acpi_ibm.ko Reading symbols from /boot/kernel/geom_eli.ko...Reading symbols from /boot/= kernel/geom_eli.ko.symbols...done. done. Loaded symbols for /boot/kernel/geom_eli.ko Reading symbols from /boot/kernel/nullfs.ko...Reading symbols from /boot/ke= rnel/nullfs.ko.symbols...done. done. Loaded symbols for /boot/kernel/nullfs.ko Reading symbols from /boot/kernel/zfs.ko...Reading symbols from /boot/kerne= l/zfs.ko.symbols...done. done. Loaded symbols for /boot/kernel/zfs.ko Reading symbols from /boot/kernel/opensolaris.ko...Reading symbols from /bo= ot/kernel/opensolaris.ko.symbols...done. done. Loaded symbols for /boot/kernel/opensolaris.ko Reading symbols from /boot/kernel/iwi_bss.ko...Reading symbols from /boot/k= ernel/iwi_bss.ko.symbols...done. done. Loaded symbols for /boot/kernel/iwi_bss.ko Reading symbols from /boot/kernel/fdescfs.ko...Reading symbols from /boot/k= ernel/fdescfs.ko.symbols...done. done. Loaded symbols for /boot/kernel/fdescfs.ko #0 doadump () at pcpu.h:246 246 pcpu.h: No such file or directory. in pcpu.h (kgdb) where #0 doadump () at pcpu.h:246 #1 0xc0648486 in boot (howto=3D260) at /usr/src/sys/kern/kern_shutdown.c:4= 20 #2 0xc06486c2 in panic (fmt=3DVariable "fmt" is not available. ) at /usr/src/sys/kern/kern_shutdown.c:576 #3 0xc04d5c87 in db_panic (addr=3DCould not find the frame base for "db_pa= nic". ) at /usr/src/sys/ddb/db_command.c:478 #4 0xc04d6211 in db_command (last_cmdp=3D0xc09b501c, cmd_table=3D0x0, dopa= ger=3D1) at /usr/src/sys/ddb/db_command.c:445 #5 0xc04d636a in db_command_loop () at /usr/src/sys/ddb/db_command.c:498 #6 0xc04d812d in db_trap (type=3D3, code=3D0) at /usr/src/sys/ddb/db_main.= c:229 #7 0xc0672626 in kdb_trap (type=3D3, code=3D0, tf=3D0xc172d170) at /usr/sr= c/sys/kern/subr_kdb.c:534 #8 0xc08be28b in trap (frame=3D0xc172d170) at /usr/src/sys/i386/i386/trap.= c:678 #9 0xc08a399b in calltrap () at /usr/src/sys/i386/i386/exception.s:165 #10 0xc06727aa in kdb_enter (why=3D0xc092aadd "panic", msg=3D0xc092aadd "pa= nic") at cpufunc.h:71 #11 0xc06486a6 in panic (fmt=3D0xc0954134 "double fault") at /usr/src/sys/k= ern/kern_shutdown.c:559 #12 0xc08bd236 in dblfault_handler () at /usr/src/sys/i386/i386/trap.c:959 #13 0xc04a63d4 in pf_pull_hdr (m=3D0xc50fd700, off=3D20, p=3D0xf3c07080, le= n=3D32, actionp=3D0x0, reasonp=3D0x0, af=3D2 '\002') at /usr/src/sys/contrib/pf/net/pf.c:5927 #14 0xc04c166e in pf_normalize_tcp_stateful (m=3D0xc50fd700, off=3D20, pd= =3D0xf3c07268, reason=3D0xf3c07264, th=3D0xf3c07240,=20 state=3D0xc69d18e0, src=3D0xc69d196c, dst=3D0xc69d1988, writeback=3D0xf= 3c0716c) at /usr/src/sys/contrib/pf/net/pf_norm.c:1645 #15 0xc04abd92 in pf_test_state_tcp (state=3D0xf3c07258, direction=3D2, kif= =3D0xc667e800, m=3D0xc50fd700, off=3D20, h=3D0xc50fd760,=20 pd=3D0xf3c07268, reason=3D0xf3c07264) at /usr/src/sys/contrib/pf/net/pf= .c:4952 #16 0xc04b2b0d in pf_test (dir=3D2, ifp=3D0xc5d5a400, m0=3D0xf3c07338, eh= =3D0x0, inp=3D0xc69bc000) at /usr/src/sys/contrib/pf/net/pf.c:6912 #17 0xc04b9a26 in pf_check_out (arg=3D0x0, m=3D0xf3c07338, ifp=3D0xc5d5a400= , dir=3D2, inp=3D0xc69bc000) at /usr/src/sys/contrib/pf/net/pf_ioctl.c:3689 #18 0xc06e1418 in pfil_run_hooks (ph=3D0xc16e2760, mp=3D0xf3c073a0, ifp=3D0= xc5d5a400, dir=3D2, inp=3D0xc69bc000) at /usr/src/sys/net/pfil.c:79 #19 0xc072f951 in ip_output (m=3D0xc50fd700, opt=3D0x0, ro=3D0xf3c073a8, fl= ags=3D0, imo=3D0x0, inp=3D0xc69bc000) at /usr/src/sys/netinet/ip_output.c:470 #20 0xc0790b8d in tcp_output (tp=3D0xc8cda5b8) at /usr/src/sys/netinet/tcp_= output.c:1189 #21 0xc0792c8f in tcp_mtudisc (inp=3D0xc69bc000, errno=3D0) at tcp_offload.= h:269 #22 0xc0790c85 in tcp_output (tp=3D0xc8cda5b8) at /usr/src/sys/netinet/tcp_= output.c:1250 #23 0xc0792c8f in tcp_mtudisc (inp=3D0xc69bc000, errno=3D0) at tcp_offload.= h:269 #24 0xc0790c85 in tcp_output (tp=3D0xc8cda5b8) at /usr/src/sys/netinet/tcp_= output.c:1250 #25 0xc0792c8f in tcp_mtudisc (inp=3D0xc69bc000, errno=3D0) at tcp_offload.= h:269 #26 0xc0790c85 in tcp_output (tp=3D0xc8cda5b8) at /usr/src/sys/netinet/tcp_= output.c:1250 #27 0xc0792c8f in tcp_mtudisc (inp=3D0xc69bc000, errno=3D0) at tcp_offload.= h:269 #28 0xc0790c85 in tcp_output (tp=3D0xc8cda5b8) at /usr/src/sys/netinet/tcp_= output.c:1250 #29 0xc0792c8f in tcp_mtudisc (inp=3D0xc69bc000, errno=3D0) at tcp_offload.= h:269 #30 0xc0790c85 in tcp_output (tp=3D0xc8cda5b8) at /usr/src/sys/netinet/tcp_= output.c:1250 #31 0xc0792c8f in tcp_mtudisc (inp=3D0xc69bc000, errno=3D0) at tcp_offload.= h:269 #32 0xc0790c85 in tcp_output (tp=3D0xc8cda5b8) at /usr/src/sys/netinet/tcp_= output.c:1250 #33 0xc0792c8f in tcp_mtudisc (inp=3D0xc69bc000, errno=3D0) at tcp_offload.= h:269 #34 0xc0790c85 in tcp_output (tp=3D0xc8cda5b8) at /usr/src/sys/netinet/tcp_= output.c:1250 #35 0xc0792c8f in tcp_mtudisc (inp=3D0xc69bc000, errno=3D0) at tcp_offload.= h:269 #36 0xc0790c85 in tcp_output (tp=3D0xc8cda5b8) at /usr/src/sys/netinet/tcp_= output.c:1250 #37 0xc0792c8f in tcp_mtudisc (inp=3D0xc69bc000, errno=3D0) at tcp_offload.= h:269 ---Type to continue, or q to quit---q Quit (kgdb) f 13 #13 0xc04a63d4 in pf_pull_hdr (m=3D0xc50fd700, off=3D20, p=3D0xf3c07080, le= n=3D32, actionp=3D0x0, reasonp=3D0x0, af=3D2 '\002') at /usr/src/sys/contrib/pf/net/pf.c:5927 5927 m_copydata(m, off, len, p); (kgdb) l 5922 } 5923 break; 5924 } 5925 #endif /* INET6 */ 5926 } 5927 m_copydata(m, off, len, p); 5928 return (p); 5929 } 5930=09 5931 int The kernel is FreeBSD 8.0-CURRENT #1: Fri Mar 27 18:07:57 CET 2009. Fabian --Sig_/kp4DqCC0auUIc6DlwUxdkM_ Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (FreeBSD) iEYEARECAAYFAknRFIoACgkQBYqIVf93VJ08GQCeKuWbXEC/ptUlFDWrR9ZNBtxG 9NoAoM0LW5OaWsSmYQ2EoQ6vafg4tDgi =4lMV -----END PGP SIGNATURE----- --Sig_/kp4DqCC0auUIc6DlwUxdkM_-- From owner-freebsd-current@FreeBSD.ORG Mon Mar 30 18:52: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 3FFDF1065677 for ; Mon, 30 Mar 2009 18:52:51 +0000 (UTC) (envelope-from chris@young-alumni.com) Received: from mail.oldschoolpunx.net (cpe-72-177-10-243.austin.res.rr.com [72.177.10.243]) by mx1.freebsd.org (Postfix) with ESMTP id 162B18FC28 for ; Mon, 30 Mar 2009 18:52:51 +0000 (UTC) (envelope-from chris@young-alumni.com) Received: by mail.oldschoolpunx.net (Postfix, from userid 58) id 86BF49809F; Mon, 30 Mar 2009 13:52:50 -0500 (CDT) Received: from [192.168.8.100] (unknown [192.168.8.100]) by mail.oldschoolpunx.net (Postfix) with ESMTPSA id D61E698070 for ; Mon, 30 Mar 2009 13:48:56 -0500 (CDT) Message-Id: <070C5562-5C6D-444D-9605-80D4579321EE@young-alumni.com> From: Chris Ruiz To: freebsd-current@freebsd.org In-Reply-To: <49D0E44C.60103@phat.za.net> Content-Type: text/plain; charset=UTF-8; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v930.3) Date: Mon, 30 Mar 2009 13:48:55 -0500 References: <4451ccf20903300123p4df9c1d7k4c4138ad25d2d4af@mail.gmail.com> <49D0E44C.60103@phat.za.net> X-Mailer: Apple Mail (2.930.3) Subject: Re: loader prompt doesn't work 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, 30 Mar 2009 18:52:53 -0000 On Mar 30, 2009, at 10:25 AM, Aragon Gouveia wrote: > =E5=B4=94=E5=B2=A9ccuiyyan@sina.com wrote: >> However, problem happens. When i select the "escape to a loader =20= >> prompt" >> option, i can input >> in about just 3 sec. After that, the system cannot go on =20 >> whatever key i >> hit. > > Same problem here and it's not USB/keyboard related in my case. =20 > What motherboard are you using? I'm on an Intel DG33BU. I have the same problem with a usb keyboard on an Intel DQ35JO. If I =20= need to use the loader prompt I have to continually rebooting until it =20= will let me type, which it eventually does. Chris Ruiz= From owner-freebsd-current@FreeBSD.ORG Mon Mar 30 19:29: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 D97E41065677; Mon, 30 Mar 2009 19:29:08 +0000 (UTC) (envelope-from kientzle@freebsd.org) Received: from kientzle.com (kientzle.com [66.166.149.50]) by mx1.freebsd.org (Postfix) with ESMTP id 6D0E58FC18; Mon, 30 Mar 2009 19:29:08 +0000 (UTC) (envelope-from kientzle@freebsd.org) Received: (from root@localhost) by kientzle.com (8.14.3/8.14.3) id n2UJT4Re092034; Mon, 30 Mar 2009 12:29:04 -0700 (PDT) (envelope-from kientzle@freebsd.org) Received: from dark.x.kientzle.com (fw2.kientzle.com [10.123.1.2]) by kientzle.com with SMTP id wyb3gig2xvn2yrzqw5jg5d3djs; Mon, 30 Mar 2009 12:29:03 -0700 (PDT) (envelope-from kientzle@freebsd.org) Message-ID: <49D11D7F.2020503@freebsd.org> Date: Mon, 30 Mar 2009 12:29:03 -0700 From: Tim Kientzle User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.8.1.19) Gecko/20090226 SeaMonkey/1.1.14 MIME-Version: 1.0 To: Poul-Henning Kamp References: <9969.1238398362@critter.freebsd.dk> In-Reply-To: <9969.1238398362@critter.freebsd.dk> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Alexander Sack , Peter Jeremy , freebsd-current@freebsd.org, prashant.vaibhav@gmail.com, FreeBSD Hackers Subject: Re: Improving the kernel/i386 timecounter performance (GSoC proposal) 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, 30 Mar 2009 19:29:09 -0000 Poul-Henning Kamp wrote: > In message <20090329180745.GB38985@server.vk2pj.dyndns.org>, Peter Jeremy write > s: > >>> I'm assuming folks are still in love with the TSC because it still the >>> cheapest as oppose ACPI-fast or HPET to even contemplate this? >> That is its major advantage. It might be feasible to export all the >> data necessary to implement the complete CLOCK_*_FAST family. > > The general attraction is that it can be read from userland by unpriviledged > programs. > > On systems where the ACPI or HPET hardware can be memory-mapped, I should > be equally possible to map those read-only into userland processes. > > Now _THAT_ would be interesting. Which brings us back to having a page of code provided by the kernel so that the kernel can determine the appropriate implementation (depending on the hardware availability) and so that userland can invoke the functions without going through a task switch. Libc can then either invoke these directly or, if the page is unavailable for any reason, use the system calls. Tim From owner-freebsd-current@FreeBSD.ORG Mon Mar 30 20:56: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 135591065795 for ; Mon, 30 Mar 2009 20:56:49 +0000 (UTC) (envelope-from doug@bitnix.ca) Received: from fep1.cogeco.net (smtp.cogeco.net [216.221.81.25]) by mx1.freebsd.org (Postfix) with ESMTP id 2CE8E8FC2C for ; Mon, 30 Mar 2009 20:56:44 +0000 (UTC) (envelope-from doug@bitnix.ca) Received: from srv.cnd.dundas.on.ca (d39-186-104.home1.cgocable.net [72.39.186.104]) by fep1.cogeco.net (Postfix) with ESMTP id 395E8254E; Mon, 30 Mar 2009 16:56:43 -0400 (EDT) Received: from monk.cnd.dundas.on.ca (monk.cnd.dundas.on.ca [10.87.0.20]) by srv.cnd.dundas.on.ca (8.14.3/8.14.3) with ESMTP id n2UKugE4039069; Mon, 30 Mar 2009 16:56:42 -0400 (EDT) (envelope-from doug@bitnix.ca) Received: from monk.cnd.dundas.on.ca (localhost [127.0.0.1]) by monk.cnd.dundas.on.ca (8.14.3/8.14.3) with ESMTP id n2UKugiR053464; Mon, 30 Mar 2009 16:56:42 -0400 (EDT) (envelope-from doug@monk.cnd.dundas.on.ca) Message-Id: <200903302056.n2UKugiR053464@monk.cnd.dundas.on.ca> To: Andrew Thompson In-reply-to: Your message of "Sun, 29 Mar 2009 23:10:36 PDT." <20090330061036.GA83528@citylink.fud.org.nz> From: "Douglas Berry" Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 30 Mar 2009 16:56:42 -0400 Sender: doug@bitnix.ca Cc: freebsd-current@freebsd.org Subject: Re: Booting from usb hard disk X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Douglas Berry List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Mar 2009 20:56:50 -0000 On Sun, 29 Mar 2009 23:10:36 PDT, Andrew Thompson wrote: > The following patch should work. It creates interleaving root hold > tokens from the CAM probe to disk_create and geom providor tasting. > I had to add a malloc type flag as sleeping isnt allowed at the > point I added the token alloc in CAM. > http://people.freebsd.org/~thompsa/root_wait.diff > It needs review by the various geom/cam ppls. Thanks! The patch fixes my problem where the disk was found, but the labels weren't found in time for mountroot. cheers, doug From owner-freebsd-current@FreeBSD.ORG Mon Mar 30 21:32: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 3BB1410656FB; Mon, 30 Mar 2009 21:32:35 +0000 (UTC) (envelope-from prashant.vaibhav@gmail.com) Received: from wf-out-1314.google.com (wf-out-1314.google.com [209.85.200.172]) by mx1.freebsd.org (Postfix) with ESMTP id F23AB8FC28; Mon, 30 Mar 2009 21:32:34 +0000 (UTC) (envelope-from prashant.vaibhav@gmail.com) Received: by wf-out-1314.google.com with SMTP id 24so2423872wfg.7 for ; Mon, 30 Mar 2009 14:32:34 -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=CKInX/R8Ktd0f1VtjI5LVRsFmzGf/4qZhPlwTq++mx8=; b=LoqjF2GPCmpYx0CXp/da+6UZr8ZlIFUrwKEBl8YWShnqB8YAKMYfJ/r/aOzizhUHeh t7Vcd01fEDbxSHr8gHZvV0Vn7NSioE3myo99et5gdeoD85Uze9eVFMvGeXPnZLFkWAcg EmRw7+TDhAA5pxYvbW/1yPYMTOS529Qr+41nY= 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=Uyq77qrWyhxSjfTakZB8MMYM/6ZDhyzgF3svEfKFvoq6SURi2O/dk/eMRbsJcEuyDc dyQcsazFEFIPPzFxRSgrfA+XG0CSuX/hCr65FZCDBjb4XRxePo0AVrTUOlGmsSl1synI 7KQSkPBv6y/0fa67Vg6SDCnaTO7PAlwOI/tag= MIME-Version: 1.0 Received: by 10.142.44.11 with SMTP id r11mr2280257wfr.186.1238448754471; Mon, 30 Mar 2009 14:32:34 -0700 (PDT) In-Reply-To: <49D11D7F.2020503@freebsd.org> References: <9969.1238398362@critter.freebsd.dk> <49D11D7F.2020503@freebsd.org> Date: Tue, 31 Mar 2009 03:02:34 +0530 Message-ID: <17560ccf0903301432t6a94dd86tb2f2a1a8d6edd7c2@mail.gmail.com> From: Prashant Vaibhav To: Tim Kientzle Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: FreeBSD Hackers , freebsd-current@freebsd.org Subject: Re: Improving the kernel/i386 timecounter performance (GSoC proposal) 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, 30 Mar 2009 21:32:37 -0000 ...and that is _exactly_ what I propose(d) in the beginning and what OSX already does. Further, keeping the shared page and functions fixed at the end of the memory space has advantages like not needing any special linking, being easily accessible for code jumps or data reads, and so on [1]. The TSC issues are but one part of the puzzle. After this week-long discussion I still can't decide whether this was something that's desirable at all: keeping in mind that it's among the few project ideas tagged as "Suggested for Google Summer of Code 2009" on the FreeBSD website. :-\ Though I've been reading mailing list archives, and the various handbooks, I'm not familiar well enough with other parts of the freebsd kernel to draft another concrete proposal on my own at this time. [1] *Mac OS X Internals: A Systems Approach,* p 595, Amit Singh, ISBN 0321278542 On Tue, Mar 31, 2009 at 12:59 AM, Tim Kientzle wrote: > Poul-Henning Kamp wrote: > >> In message <20090329180745.GB38985@server.vk2pj.dyndns.org>, Peter Jeremy >> write >> s: >> >> I'm assuming folks are still in love with the TSC because it still the >>>> cheapest as oppose ACPI-fast or HPET to even contemplate this? >>>> >>> That is its major advantage. It might be feasible to export all the >>> data necessary to implement the complete CLOCK_*_FAST family. >>> >> >> The general attraction is that it can be read from userland by >> unpriviledged >> programs. >> >> On systems where the ACPI or HPET hardware can be memory-mapped, I should >> be equally possible to map those read-only into userland processes. >> >> Now _THAT_ would be interesting. >> > > Which brings us back to having a page of code > provided by the kernel so that the kernel can > determine the appropriate implementation > (depending on the hardware availability) and so > that userland can invoke the functions without > going through a task switch. Libc can then > either invoke these directly or, if the page is > unavailable for any reason, use the system calls. > > Tim > > From owner-freebsd-current@FreeBSD.ORG Mon Mar 30 22:18: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 261AC1065672 for ; Mon, 30 Mar 2009 22:18:26 +0000 (UTC) (envelope-from barney_cordoba@yahoo.com) Received: from web63901.mail.re1.yahoo.com (web63901.mail.re1.yahoo.com [69.147.97.116]) by mx1.freebsd.org (Postfix) with SMTP id C627F8FC17 for ; Mon, 30 Mar 2009 22:18:25 +0000 (UTC) (envelope-from barney_cordoba@yahoo.com) Received: (qmail 54966 invoked by uid 60001); 30 Mar 2009 22:18:25 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1238451505; bh=ZjUaY2S2doPJYUEstNSETIvAux8+iVkWHj8WD2nepY4=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=AGY65FiMGcyOWmGXiGy+Dt9rfE7Li+/kogh5kPXohPErjjHvXa3UkTNY/1D2OFtylZ0UAElZ+OTqJisHF4FBvqs8I9AJXuk3RJqngp+uYtjPfzodLbA41COgMuWJPNcyv9zcEpme41xGL08q0pg+FnajUEOXPQ6jzVHZLGD7oKE= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=wdvBhEWlhJidS0ud5En5q/e8pbXEH53ujPko6/tzOUQVpW2HIRhJVKwubWgMOjR2PJriXdJq1sG69+pVuv2pAVrDNmr+lKb6CCtCStWnwadQiBelS8f0oNNQXFGxQDtlg05l7c6cEIB0PBG7dQ8JdyWG8SAv91xK7JqX/MTlxIk=; Message-ID: <105551.54281.qm@web63901.mail.re1.yahoo.com> X-YMail-OSG: gVwJVw4VM1n.Y8mUrgnZVTXH3Eq5g8Mi4_NbXCrCLrcVqGOjQmy5ImsBI48rD.XljEe1slEaLNo1.OMIrCickfgMXN93YA5.sbAY134g5m6HDo53hl_nA0pfGBqw1jMPj4bOsMhuCeq9sI0PdKSQtUiowUhj8i6Bn_dTJQUnapF154O.3EqGUMC.uplJMl5Hf2NfDAuUBpY6XKGD9fZ7F1FmAXdxti42g32JUTdOIA-- Received: from [98.242.222.229] by web63901.mail.re1.yahoo.com via HTTP; Mon, 30 Mar 2009 15:18:24 PDT X-Mailer: YahooMailWebService/0.7.289.1 Date: Mon, 30 Mar 2009 15:18:24 -0700 (PDT) From: Barney Cordoba To: John Baldwin In-Reply-To: <200903301214.32493.jhb@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: freebsd-current@freebsd.org Subject: Re: pci_alloc_resource is broken X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: barney_cordoba@yahoo.com List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Mar 2009 22:18:27 -0000 --- On Mon, 3/30/09, John Baldwin wrote: > From: John Baldwin > Subject: Re: pci_alloc_resource is broken > To: barney_cordoba@yahoo.com > Cc: freebsd-current@freebsd.org > Date: Monday, March 30, 2009, 12:14 PM > On Monday 30 March 2009 11:53:02 am Barney Cordoba wrote: > > > This was actually on purpose to prevent multiple > > > allocations of a resource. > > > Multiple allocations actually leak kernel memory > since the > > > resource only > > > keeps track of the current mapping. My question > is why are > > > you having one > > > device allocate resources of another device? If > you have > > > two functions of a > > > multi-function PCI adapter that you want one > logical driver > > > for, then have > > > each function's driver allocate its own > resources and > > > store the 'struct > > > resource *' in a "global" softc. > You can > > > then use whichever resource you > > > need for bus_read/write when you do bit-banging. > > > > > > -- > > > John Baldwin > > > > We're remapping in another driver because in the > commercial world, > > we don't always have access to kernel source, and > there is a strong > > desire to separate the NIC driver from the secondary > function so > > customers can get patches for the OS without having to > worry about > > incompatibility with the secondary modules. > > > > I can add a function to the NIC driver also, but the > goal is to be > > able to distribute a module that doesn't require > modification to the > > stock driver for the system. > > In FreeBSD you do always have access to the source. :) > (And fwiw, I have > worked on proprietary FreeBSD drivers in the past including > a driver for a > multi-function card that actually managed two functions via > one logical > driver.) > > However, I am curious that you are able to make this work > on "commercial" > operating systems as well. On OS X only the IOService > child of a PCI node > can map the BARs of that node. Well, you can actually walk > up to the parent > PCI bus, find your sibling IOService node and get its BARs > that way which > does work. In Windows I'm not sure how you would make > this work as when you > attach to a FDO you get callbacks for each of your > resources for tha tnode in > BAR order. AFAIK, there isn't a good way to discover > or use the resources of > another device in WDM, at least not at the time of Windows > XP. > > -- > John Baldwin I dunno, but its pretty lame that you can't read a register on a card without hacking the kernel. The entire point of having a generic bus management system is to create a relatively transparent mechanism for accessing such resources, but then if you try to share a resource you find out that the system doesn't support shared resources and requires proprietary hacking of the drivers. We don't want to have to make the ethernet functionality "proprietary" or required to be obtained from a static source. So if some dude in Pakistan wants to grab a bug fix he can do it without whining to the vendor that the code is proprietary, thus burdening the vendor to re-hack every iteration of code that some customer in some corner of the world wants to run for one reason or another. The alternative is telling the customer that he can't have the bug fix until the vendor gets around to releasing a version that has the latest patch. It doesn't have to run on other OSes. Its a logistic issue. Its a matter of streamlining the work flow. Having separate drivers makes upgrading easier. You don't have to hack 37 source files every time you decide to grab a -stable because some dude at freebsd.org decided to change a macro. Are you getting this? As a side issue, the number of panics I found along the way is a bit alarming. Its pretty lazy coding. Panic should really only be called when a condition is unrecoverable; not every time someone doesn't feel like writing the couple of lines of code to handle the condition. Is the kernel memory leaked on each access, or is there some leakage on allocation and release only? I can live with a static chunk lost, but not if its a continuous thing. Barney From owner-freebsd-current@FreeBSD.ORG Tue Mar 31 01:02: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 49CB81065675; Tue, 31 Mar 2009 01:02:11 +0000 (UTC) (envelope-from sobomax@FreeBSD.org) Received: from sippysoft.com (gk1.360sip.com [72.236.70.240]) by mx1.freebsd.org (Postfix) with ESMTP id 8CA0D8FC14; Tue, 31 Mar 2009 01:02:10 +0000 (UTC) (envelope-from sobomax@FreeBSD.org) Received: from [192.168.1.38] (S0106001372fd1e07.vs.shawcable.net [70.71.171.106]) (authenticated bits=0) by sippysoft.com (8.14.3/8.14.3) with ESMTP id n2V0OfJB053389 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 30 Mar 2009 17:24:42 -0700 (PDT) (envelope-from sobomax@FreeBSD.org) Message-ID: <49D162C4.3050006@FreeBSD.org> Date: Mon, 30 Mar 2009 17:24:36 -0700 From: Maxim Sobolev Organization: Sippy Software, Inc. User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Scott Long References: <11609492.9579.1238167614335.JavaMail.root@vms070.mailsrvcs.net> <49CD0405.1060704@samsco.org> In-Reply-To: <49CD0405.1060704@samsco.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: Sergey Babkin , freebsd-hackers@FreeBSD.org, attilio@FreeBSD.org, phk@phk.freebsd.dk, freebsd-current@FreeBSD.org, prashant.vaibhav@gmail.com Subject: Re: Improving the kernel/i386 timecounter performance (GSoC proposal) 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, 31 Mar 2009 01:02:11 -0000 Scott Long wrote: > I've been talking about this for years. All I need is help with the VM > magic to create the page on fork. I also want two pages, one global > for gettimeofday (and any other global data we can think of) and one > per-process for static data like getpid/getgid. I believe somebody suggested that no real VM magic is needed and the libc should be in charge of opening special pseudo-device and doing necessary mmap(2) magic to get the page mapped in when user calls gettimeofday()/getpid()/getid() etc for the first time. -Maxim From owner-freebsd-current@FreeBSD.ORG Tue Mar 31 01:17: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 E3E871065670 for ; Tue, 31 Mar 2009 01:17:47 +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 8D4368FC16 for ; Tue, 31 Mar 2009 01:17:47 +0000 (UTC) (envelope-from wblock@wonkity.com) Received: from wonkity.com (localhost [127.0.0.1]) by wonkity.com (8.14.3/8.14.3) with ESMTP id n2V0ov9e017474; Mon, 30 Mar 2009 18:50:57 -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 n2V0ouTh017471; Mon, 30 Mar 2009 18:50:57 -0600 (MDT) (envelope-from wblock@wonkity.com) Date: Mon, 30 Mar 2009 18:50:56 -0600 (MDT) From: User Wblock To: Andriy Gapon In-Reply-To: <49D1001E.2050405@icyb.net.ua> Message-ID: References: <4451ccf20903300123p4df9c1d7k4c4138ad25d2d4af@mail.gmail.com> <49D0E44C.60103@phat.za.net> <49D1001E.2050405@icyb.net.ua> 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.0.1 (wonkity.com [127.0.0.1]); Mon, 30 Mar 2009 18:50:57 -0600 (MDT) Cc: Aragon Gouveia , ccuiyyan@gmail.com, freebsd-current@freebsd.org Subject: Re: loader prompt doesn't work 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, 31 Mar 2009 01:17:48 -0000 On Mon, 30 Mar 2009, Andriy Gapon wrote: > on 30/03/2009 18:25 Aragon Gouveia said the following: >> ??ccuiyyan@sina.com wrote: >>> However, problem happens. When i select the "escape to a loader >>> prompt" >>> option, i can input >>> >>> in about just 3 sec. After that, the system cannot go on whatever >>> key i >>> hit. >> >> Same problem here and it's not USB/keyboard related in my case. What >> motherboard are you using? I'm on an Intel DG33BU. > > There was a significant fix to boot code made recently by jhb. > It is now in head, stable/7 and stable/6. > So you need to update to the recent resources. > What you also need (and what was not emphasized enough, IMO) is to actually > install new boot code (/boot/boot) to your active slices after installworld completes. > > E.g.: > $ gpart bootcode -b /boot/boot adXsY The gpart manpage just makes me more confused about this. I don't know what a "protective" MBR is, or if I've got one. Can you expand on this a little? For instance: * When did it happen? * Who needs to do this--everyone who has updated to a recent -CURRENT or -STABLE? Or just those using certain partitioning features? * There's no mention in /usr/src/UPDATING. Was it mentioned anywhere? -Warren Block * Rapid City, South Dakota USA From owner-freebsd-current@FreeBSD.ORG Tue Mar 31 01:31: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 E1CA71065672; Tue, 31 Mar 2009 01:31:13 +0000 (UTC) (envelope-from sobomax@FreeBSD.org) Received: from sippysoft.com (gk1.360sip.com [72.236.70.240]) by mx1.freebsd.org (Postfix) with ESMTP id 9FC298FC08; Tue, 31 Mar 2009 01:31:13 +0000 (UTC) (envelope-from sobomax@FreeBSD.org) Received: from [192.168.1.38] (S0106001372fd1e07.vs.shawcable.net [70.71.171.106]) (authenticated bits=0) by sippysoft.com (8.14.3/8.14.3) with ESMTP id n2V1VBvN053678 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 30 Mar 2009 18:31:12 -0700 (PDT) (envelope-from sobomax@FreeBSD.org) Message-ID: <49D1725A.1020005@FreeBSD.org> Date: Mon, 30 Mar 2009 18:31:06 -0700 From: Maxim Sobolev Organization: Sippy Software, Inc. User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Peter Jeremy References: <11609492.9579.1238167614335.JavaMail.root@vms070.mailsrvcs.net> <49CD0405.1060704@samsco.org> <49CD30E9.7030501@elischer.org> <49CEC261.4010803@freebsd.org> <20090329182219.GC38985@server.vk2pj.dyndns.org> In-Reply-To: <20090329182219.GC38985@server.vk2pj.dyndns.org> Content-Type: text/plain; charset=KOI8-U; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@FreeBSD.org, freebsd-current@FreeBSD.org, David Xu , prashant.vaibhav@gmail.com Subject: Re: Improving the kernel/i386 timecounter performance (GSoC proposal) 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, 31 Mar 2009 01:31:14 -0000 Peter Jeremy wrote: > On 2009-Mar-29 08:35:45 +0800, David Xu wrote: >> Julian Elischer wrote: >>> interestingly it is even feasible to have a per-thread page.. >>> it requires that the scheduler change a page table entry tough. >> I will knock his door at midnight if he added such a heavy weight >> task in the scheduler, TLB shutdown is horrible, and big code size >> squeezing out data from CPU cache is not idea model. >> scheduler should be as simple as just a context switching routine. > > If the TSC is not consistent between all cores (which is probably > the most common situation at present), then using the TSC implies > knowing which core you are executing on. From a userland perspective, > the easiest way to do this is to have a page of data that varies > depending on which core you are executing on. It's not that easy, unless you can pin thread to a specific core before reading that page. I.e. imagine the case when your thread reads per-cpu page, get preempted and scheduled to a different core, then executes RDTSC there, still thinking it got TSC reading from the first core. Even if it does re-read from that page again after reading TSC to determine if he has read the correct TSC, still it's possible (though not very likely) that it has been preempted again and scheduled to the first core after reading the TSC. -Maxim From owner-freebsd-current@FreeBSD.ORG Tue Mar 31 01:45: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 2A00A106564A; Tue, 31 Mar 2009 01:45:38 +0000 (UTC) (envelope-from sobomax@FreeBSD.org) Received: from sippysoft.com (gk1.360sip.com [72.236.70.240]) by mx1.freebsd.org (Postfix) with ESMTP id E1B248FC18; Tue, 31 Mar 2009 01:45:37 +0000 (UTC) (envelope-from sobomax@FreeBSD.org) Received: from [192.168.1.38] (S0106001372fd1e07.vs.shawcable.net [70.71.171.106]) (authenticated bits=0) by sippysoft.com (8.14.3/8.14.3) with ESMTP id n2V1jZkS053755 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 30 Mar 2009 18:45:36 -0700 (PDT) (envelope-from sobomax@FreeBSD.org) Message-ID: <49D175BA.6050307@FreeBSD.org> Date: Mon, 30 Mar 2009 18:45:30 -0700 From: Maxim Sobolev Organization: Sippy Software, Inc. User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Robert Watson References: <33531707.21385.1238188446396.JavaMail.root@vms074.mailsrvcs.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Sergey Babkin , freebsd-hackers@FreeBSD.org, attilio@FreeBSD.org, phk@phk.freebsd.dk, freebsd-current@FreeBSD.org, prashant.vaibhav@gmail.com Subject: Re: Improving the kernel/i386 timecounter performance (GSoC proposal) 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, 31 Mar 2009 01:45:38 -0000 Robert Watson wrote: > Part of the point of mapping in the page at execve()-time, or > fork()-time for per-process pages (which I'm not entirely convinced we > need yet) is to avoid the cost of an extra device open, mmap, etc, for > every execve(), which can be quite expensive. I stuck a prototype page You don't really need to do it on every execve() unconditionally. It could be done on demand in libc, so that only when thread pass certain threshold, the "common page optimization code" kicks in and does its open/mmap/etc magic. Otherwise, "normal" syscall is performed. The implementation could be as simple as counter in the appropriate libc routine, so that optimization engages after certain number of calls. For syscalls that return time it's also easy to do frequency thresholds, so that for example gettimeofday() only gets optimized if threads calls it more frequently that 1 call/sec. -Maxim From owner-freebsd-current@FreeBSD.ORG Tue Mar 31 02:38: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 8BC171065675; Tue, 31 Mar 2009 02:38:03 +0000 (UTC) (envelope-from davidxu@freebsd.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 769378FC08; Tue, 31 Mar 2009 02:38:03 +0000 (UTC) (envelope-from davidxu@freebsd.org) Received: from apple.my.domain (root@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id n2V2bx9l016060; Tue, 31 Mar 2009 02:38:00 GMT (envelope-from davidxu@freebsd.org) Message-ID: <49D18209.1020805@freebsd.org> Date: Tue, 31 Mar 2009 10:38:01 +0800 From: David Xu User-Agent: Thunderbird 2.0.0.9 (X11/20080612) MIME-Version: 1.0 To: Prashant Vaibhav References: <9969.1238398362@critter.freebsd.dk> <49D11D7F.2020503@freebsd.org> <17560ccf0903301432t6a94dd86tb2f2a1a8d6edd7c2@mail.gmail.com> In-Reply-To: <17560ccf0903301432t6a94dd86tb2f2a1a8d6edd7c2@mail.gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: FreeBSD Hackers , Tim Kientzle , freebsd-current@freebsd.org Subject: Re: Improving the kernel/i386 timecounter performance (GSoC proposal) 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, 31 Mar 2009 02:38:04 -0000 Prashant Vaibhav wrote: > ...and that is _exactly_ what I propose(d) in the beginning and what OSX > already does. Further, keeping the shared page and functions fixed at the > end of the memory space has advantages like not needing any special linking, > being easily accessible for code jumps or data reads, and so on [1]. The TSC > issues are but one part of the puzzle. > After this week-long discussion I still can't decide whether this was > something that's desirable at all: keeping in mind that it's among the few > project ideas tagged as "Suggested for Google Summer of Code 2009" on the > FreeBSD website. :-\ Though I've been reading mailing list archives, and > the various handbooks, I'm not familiar well enough with other parts of the > freebsd kernel to draft another concrete proposal on my own at this time. > > [1] *Mac OS X Internals: A Systems Approach,* p 595, Amit Singh, ISBN > 0321278542 > > Without using ELF, but using signal like trampoline code as we current do makes it very difficult for some language to do asynchronous stack unwinding, e.g pthread async cancellation and C++ objection destruction. See my recent work for pthread cancellation and stack unwinding: http://people.freebsd.org/~davidxu/patch/unwind.patch Check x86_64_fallback_frame_state() to see what hacking code should be written. Regards, David Xu From owner-freebsd-current@FreeBSD.ORG Tue Mar 31 03:30: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 E504C1065675 for ; Tue, 31 Mar 2009 03:30:44 +0000 (UTC) (envelope-from matheusber@gmail.com) Received: from an-out-0708.google.com (an-out-0708.google.com [209.85.132.246]) by mx1.freebsd.org (Postfix) with ESMTP id 8EF698FC22 for ; Tue, 31 Mar 2009 03:30:44 +0000 (UTC) (envelope-from matheusber@gmail.com) Received: by an-out-0708.google.com with SMTP id d11so1556845and.13 for ; Mon, 30 Mar 2009 20:30:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:received:received :message-id:in-reply-to:references:date:subject:from:to:user-agent :mime-version:content-type:content-transfer-encoding:x-priority :importance; bh=nZEHUKoO+gLwDd5Oh7jcqOhqZJ9IpAEecN8qYQIlX+o=; b=D+ytCtfycU5AEmuV859k2SA1y0V5HnBZh9MZvxyhC8BvQJlYi1NOLXmz8NEeFO8Qet u6ZQ8uMPOM3Muwa9XRVikUwkTTGtOKLmdYA6mFv00zMki55vb62GjYjCLAMBQ5sfAfgx kGkYUyc6PkvEA+PxESrhhU4r131PsryUymbtc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:in-reply-to:references:date:subject:from:to :user-agent:mime-version:content-type:content-transfer-encoding :x-priority:importance; b=cIYdfgtKp1hJw5iy0xJru9+ZfyILmpb2vw2oodL3zaObCyM1Jn0Iup5ECUpcPkrVN6 t/JdloE6rm+osXEsXV8RHw/6RkO9G5k5V35pqpTUXt5UNNYC4nwZ8WdqAdbqz1RqeJnR iwbrJbmp6iMWns5mMxcQR7jzEnC7LjU/XbrsE= Received: by 10.100.178.9 with SMTP id a9mr1523192anf.116.1238470243795; Mon, 30 Mar 2009 20:30:43 -0700 (PDT) Received: from cygnus.homeunix.com ([189.71.52.220]) by mx.google.com with ESMTPS id c29sm2894758anc.59.2009.03.30.20.30.42 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 30 Mar 2009 20:30:43 -0700 (PDT) Sender: Nenhum_de_Nos Received: by cygnus.homeunix.com (Postfix, from userid 80) id 7F348B8074; Tue, 31 Mar 2009 00:30:39 -0300 (BRT) Received: from 10.1.1.80 (SquirrelMail authenticated user matheus) by 10.1.1.10 with HTTP; Tue, 31 Mar 2009 00:30:39 -0300 (BRT) Message-ID: In-Reply-To: <20090330061036.GA83528@citylink.fud.org.nz> References: <1237804575.1771.7.camel@balrog.2hip.net> <1237884572.1771.28.camel@balrog.2hip.net> <20090330061036.GA83528@citylink.fud.org.nz> Date: Tue, 31 Mar 2009 00:30:39 -0300 (BRT) From: "Nenhum_de_Nos" To: freebsd-current@freebsd.org User-Agent: SquirrelMail/1.4.15 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Subject: Re: Booting from usb hard disk 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, 31 Mar 2009 03:30:45 -0000 On Mon, March 30, 2009 03:10, Andrew Thompson wrote: > On Tue, Mar 24, 2009 at 03:49:32AM -0500, Robert Noland wrote: >> On Mon, 2009-03-23 at 19:40 -0300, Nenhum_de_Nos wrote: >> > On Mon, March 23, 2009 07:36, Robert Noland wrote: >> > > So I have my i386 install on a usb hard disk, which I can only boot >> on >> > > one machine now. The one machine that I can make work has a bios >> option >> > > that reads "BIOS ehci handoff". This used to work with the old usb >> > > stack. The machines that it doesn't work on, boot the kernel, but >> fail >> > > to mount root, giving me the forbidding mountroot> prompt, which is >> > > immediately followed by the message saying that da0 is attached. >> da0 is >> > > however not listed in the available boot devices list. I tried >> playing >> > > around with the timeout in vfs_mount.c, but that didn't seem to have >> any >> > > impact. It has been suggested that this may be a "geom" timeout, >> but I >> > > don't know anything about the boot system really. >> > >> > I had problem a while ago with via mini itx hardware, that was quite >> > close. If I try boot from usb (installed in usb hdd), I get to the >> point >> > of loader not finding my disk. >> > >> > I then used a small flash disk attached to the ata (44 pin ide) >> channel >> > and formatted /boot in there. this way I get to the point of mount >> root >> > you said, and da0 not being alive soon enough to mount root. list >> disks >> > also couldn't find da0 though. >> > >> > I tried current from that time, and no good. >> > >> > if this is solved, I'll be happy to try whatever patch to current. (as >> > long as I can install it from another box/or its ata channel, as it >> can't >> > boot vanilla 7.1R) >> >> So, my solution was to set kern.cam.scsi_delay=10000 >> in /boot/loader.conf > > The following patch should work. It creates interleaving root hold > tokens from the CAM probe to disk_create and geom providor tasting. > I had to add a malloc type flag as sleeping isnt allowed at the point I > added the token alloc in CAM. > > http://people.freebsd.org/~thompsa/root_wait.diff > > It needs review by the various geom/cam ppls. > > > Andrew sorry for the delay. I had work issues. Thanks for the patch, I'll try it as soon as possible (plnas for Wednesday) thanks, matheus -- We will call you cygnus, The God of balance you shall be From owner-freebsd-current@FreeBSD.ORG Tue Mar 31 04:02:56 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 2C6E41065745 for ; Tue, 31 Mar 2009 04:02:55 +0000 (UTC) (envelope-from xcllnt@mac.com) Received: from asmtpout012.mac.com (asmtpout012.mac.com [17.148.16.87]) by mx1.freebsd.org (Postfix) with ESMTP id 534A18FC16 for ; Tue, 31 Mar 2009 04:02:55 +0000 (UTC) (envelope-from xcllnt@mac.com) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Received: from MacBook-Pro.lan.xcllnt.net (mail.xcllnt.net [75.101.29.67]) by asmtp012.mac.com (Sun Java(tm) System Messaging Server 6.3-8.01 (built Dec 16 2008; 32bit)) with ESMTPSA id <0KHC0056QOF0O350@asmtp012.mac.com> for current@freebsd.org; Mon, 30 Mar 2009 20:01:49 -0700 (PDT) Message-id: From: Marcel Moolenaar To: FreeBSD current mailing list Date: Mon, 30 Mar 2009 20:01:48 -0700 X-Mailer: Apple Mail (2.930.3) Cc: Subject: Removal of GEOM_BSD, GEOM_MBR, GEOM_PC98 and GEOM_SUNLABEL 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, 31 Mar 2009 04:02:56 -0000 All, I plan to remove the "old" partitioning GEOMs mentioned in the subject line some time this week. Let me know if any of these should remain for now due to issues with gpart. FYI, -- Marcel Moolenaar xcllnt@mac.com From owner-freebsd-current@FreeBSD.ORG Tue Mar 31 05:24:31 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 1A7DA1065676 for ; Tue, 31 Mar 2009 05:24:31 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) by mx1.freebsd.org (Postfix) with ESMTP id D2C568FC1B for ; Tue, 31 Mar 2009 05:24:30 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (critter.freebsd.dk [192.168.61.3]) by phk.freebsd.dk (Postfix) with ESMTP id 19DFB78D17; Tue, 31 Mar 2009 05:24:30 +0000 (UTC) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.14.3/8.14.3) with ESMTP id n2V5OTXC095892; Tue, 31 Mar 2009 05:24:29 GMT (envelope-from phk@critter.freebsd.dk) To: Marcel Moolenaar From: "Poul-Henning Kamp" In-Reply-To: Your message of "Mon, 30 Mar 2009 20:01:48 MST." Date: Tue, 31 Mar 2009 05:24:29 +0000 Message-ID: <95891.1238477069@critter.freebsd.dk> Sender: phk@critter.freebsd.dk Cc: FreeBSD current mailing list Subject: Re: Removal of GEOM_BSD, GEOM_MBR, GEOM_PC98 and GEOM_SUNLABEL 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, 31 Mar 2009 05:24:31 -0000 In message , Marcel Moolenaar wri tes: >I plan to remove the "old" partitioning GEOMs mentioned in the subject >line some time this week. Let me know if any of these should remain for now >due to issues with gpart. Never mind gpart, but don't we have some guidelines for how long time we leave stuff around before we rip it out ? -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From owner-freebsd-current@FreeBSD.ORG Tue Mar 31 06:11:43 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 BAAD3106564A for ; Tue, 31 Mar 2009 06:11:43 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from mail2.fluidhosting.com (mx22.fluidhosting.com [204.14.89.5]) by mx1.freebsd.org (Postfix) with ESMTP id 325128FC13 for ; Tue, 31 Mar 2009 06:11:43 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: (qmail 1561 invoked by uid 399); 31 Mar 2009 06:11:42 -0000 Received: from localhost (HELO 192-168-15-100.nohostname) (dougb@dougbarton.us@127.0.0.1) by localhost with ESMTPAM; 31 Mar 2009 06:11:42 -0000 X-Originating-IP: 127.0.0.1 X-Sender: dougb@dougbarton.us Message-ID: <49D1B261.6010406@FreeBSD.org> Date: Mon, 30 Mar 2009 23:04:17 -0700 From: Doug Barton Organization: http://www.FreeBSD.org/ User-Agent: Thunderbird 2.0.0.21 (X11/20090321) MIME-Version: 1.0 To: freebsd-current@freebsd.org X-Enigmail-Version: 0.95.7 OpenPGP: id=D5B2F0FB Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: New rc.d/named features for testing: auto-forwarding and wait on boot 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, 31 Mar 2009 06:11:44 -0000 Howdy, There has been some discussion recently about the idea of adding an option for the rc.d startup process to wait until name resolution comes on line. (There is also room for a more general "wait for the network to come on line" option, but I chose to focus on the named version since my time is limited atm.) The patch below has a fairly simple implementation of this feature with 2 knobs, named_wait to enable it, and the optional named_wait_host to specify what name to look up. It defaults to localhost. Garrett Wollman gets credit for the rough strokes on this one, though I refined it a bit (so blame for bugs goes to me). For a long time now there has also been discussion about configuring the local resolver to automatically forward to those name servers in /etc/resolv.conf. This bit is a lot trickier, primarily because it involves writing to /etc/namedb/ at boot time. However, the default is to chroot the named process to /var/named/ so this should be relatively safe. The patch has an implementation of the feature that works for the few networks I've tested it on. I feel that it is still a bit rough, but it's ready for wider review. The basic idea is that we parse /etc/resolv.conf for lines that begin with "nameserver" and try to make use of the information. It writes a temp file to /var/run/auto_forward.conf, then when it's done it compares the result to what's in [/var/named]/etc/namedb/auto_forward.conf. If it's different, the new one replaces the old. While it's being parsed, if the local named is not the first nameserver line in /etc/resolv.conf that is added, and if the new file differs from the existing one it will be replaced too. This uses roughly the same logic as is used in /sbin/dhclient-script. The part where this has the ability to go wonky is in the named.conf file. The patch has an update to that file with a _commented out_ line that you can uncomment to enable the support (along with enabling it in rc.conf of course). Where this _could_ go sideways is if you uncomment that line in named.conf but then turn off the auto_forward options. Fortunately, named supports 'include'ing empty files, so if either there is no /etc/resolv.conf, or if the named_auto_forward option is off and there is an existing /etc/namedb/auto_forward.conf file, the script empties that file out. I'm not thrilled with the idea of leaving an include of an empty file lying around in the options { }; section of named.conf, which is why it's commented out by default. However given the permissions it's no _more_ dangerous than the named.conf file itself. The user could shoot themselves in the foot if they disable the rc.conf option AND remove /etc/namedb/auto_forward.conf without commenting the line in named.conf, but that error is pretty obvious at named start-time. There is a not-directly-related change in this patch as well that I've had in the wings for a while to add named-checkconf to the pre-start routine. Given that if the named_auto_forward* options are on we will now be frobbing the conf behind the scenes I thought it was a good idea to add this support now. In addition to enabling auto_forward you can also enable auto_forward_only which changes from the default 'forward first' to (you guessed it) 'forward only'. Comments and suggestions are welcome, but remember I said this was rough. :) BTW, you should be able to test this on RELENG_[67] too if you really want to. I haven't tested the patch on those branches but it should apply pretty cleanly, and it's not that much to add anyway. Enjoy, Doug -- This .signature sanitized for your protection From owner-freebsd-current@FreeBSD.ORG Tue Mar 31 06:17: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 633061065672 for ; Tue, 31 Mar 2009 06:17:38 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from mail2.fluidhosting.com (mx22.fluidhosting.com [204.14.89.5]) by mx1.freebsd.org (Postfix) with ESMTP id 11E318FC16 for ; Tue, 31 Mar 2009 06:17:37 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: (qmail 8289 invoked by uid 399); 31 Mar 2009 06:17:36 -0000 Received: from localhost (HELO 192-168-15-100.nohostname) (dougb@dougbarton.us@127.0.0.1) by localhost with ESMTPAM; 31 Mar 2009 06:17:36 -0000 X-Originating-IP: 127.0.0.1 X-Sender: dougb@dougbarton.us Message-ID: <49D1B57F.8050903@FreeBSD.org> Date: Mon, 30 Mar 2009 23:17:35 -0700 From: Doug Barton Organization: http://www.FreeBSD.org/ User-Agent: Thunderbird 2.0.0.21 (X11/20090321) MIME-Version: 1.0 To: freebsd-current@freebsd.org References: <49D1B261.6010406@FreeBSD.org> In-Reply-To: <49D1B261.6010406@FreeBSD.org> X-Enigmail-Version: 0.95.7 OpenPGP: id=D5B2F0FB Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: New rc.d/named features for testing: auto-forwarding and wait on boot 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, 31 Mar 2009 06:17:38 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: RIPEMD160 Doug Barton wrote: > Howdy, > > There has been some discussion recently about the idea of adding an > option for the rc.d startup process to wait until name resolution > comes on line. (There is also room for a more general "wait for the > network to come on line" option, but I chose to focus on the named > version since my time is limited atm.) > > The patch below has a fairly simple implementation of this feature > with 2 knobs, named_wait to enable it, and the optional > named_wait_host to specify what name to look up. It defaults to > localhost. Garrett Wollman gets credit for the rough strokes on this > one, though I refined it a bit (so blame for bugs goes to me). > > For a long time now there has also been discussion about configuring > the local resolver to automatically forward to those name servers in > /etc/resolv.conf. This bit is a lot trickier, primarily because it > involves writing to /etc/namedb/ at boot time. However, the default is > to chroot the named process to /var/named/ so this should be > relatively safe. > > The patch has an implementation of the feature that works for the few > networks I've tested it on. I feel that it is still a bit rough, but > it's ready for wider review. The basic idea is that we parse > /etc/resolv.conf for lines that begin with "nameserver" and try to > make use of the information. It writes a temp file to > /var/run/auto_forward.conf, then when it's done it compares the result > to what's in [/var/named]/etc/namedb/auto_forward.conf. If it's > different, the new one replaces the old. While it's being parsed, if > the local named is not the first nameserver line in /etc/resolv.conf > that is added, and if the new file differs from the existing one it > will be replaced too. This uses roughly the same logic as is used in > /sbin/dhclient-script. > > The part where this has the ability to go wonky is in the named.conf > file. The patch has an update to that file with a _commented out_ line > that you can uncomment to enable the support (along with enabling it > in rc.conf of course). Where this _could_ go sideways is if you > uncomment that line in named.conf but then turn off the auto_forward > options. Fortunately, named supports 'include'ing empty files, so if > either there is no /etc/resolv.conf, or if the named_auto_forward > option is off and there is an existing /etc/namedb/auto_forward.conf > file, the script empties that file out. > > I'm not thrilled with the idea of leaving an include of an empty file > lying around in the options { }; section of named.conf, which is why > it's commented out by default. However given the permissions it's no > _more_ dangerous than the named.conf file itself. The user could shoot > themselves in the foot if they disable the rc.conf option AND remove > /etc/namedb/auto_forward.conf without commenting the line in > named.conf, but that error is pretty obvious at named start-time. > > There is a not-directly-related change in this patch as well that I've > had in the wings for a while to add named-checkconf to the pre-start > routine. Given that if the named_auto_forward* options are on we will > now be frobbing the conf behind the scenes I thought it was a good > idea to add this support now. > > In addition to enabling auto_forward you can also enable > auto_forward_only which changes from the default 'forward first' to > (you guessed it) 'forward only'. > > Comments and suggestions are welcome, but remember I said this was > rough. :) BTW, you should be able to test this on RELENG_[67] too if > you really want to. I haven't tested the patch on those branches but > it should apply pretty cleanly, and it's not that much to add anyway. > > > Enjoy, > > Doug And of course, the patch: http://dougbarton.us/Downloads/rcd-named.diff - -- This .signature sanitized for your protection -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.11 (FreeBSD) iEYEAREDAAYFAknRtX8ACgkQyIakK9Wy8PsdMQCeMDUoEp/waxAo2MtUql8CrYvo UF4AniOJwRHT4SfgEEgWqBgbZaANiXbo =4rKv -----END PGP SIGNATURE----- From owner-freebsd-current@FreeBSD.ORG Tue Mar 31 07:00: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 430881065675 for ; Tue, 31 Mar 2009 07:00:16 +0000 (UTC) (envelope-from crapsh@monkeybrains.net) Received: from ape.monkeybrains.net (mail.monkeybrains.net [208.69.40.9]) by mx1.freebsd.org (Postfix) with ESMTP id 2E0DB8FC1B for ; Tue, 31 Mar 2009 07:00:15 +0000 (UTC) (envelope-from crapsh@monkeybrains.net) Received: from [192.168.2.105] (adsl-76-203-172-200.dsl.pltn13.sbcglobal.net [76.203.172.200]) (authenticated bits=0) by ape.monkeybrains.net (8.14.1/8.14.1) with ESMTP id n2V6RT8u011653 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 30 Mar 2009 23:27:29 -0700 (PDT) (envelope-from crapsh@monkeybrains.net) Message-ID: <49D1B7CD.1080702@monkeybrains.net> Date: Mon, 30 Mar 2009 23:27:25 -0700 From: Rudy User-Agent: Thunderbird 2.0.0.19 (X11/20090105) MIME-Version: 1.0 To: freebsd-current@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on pita.monkeybrains.net X-Virus-Status: Clean Subject: Geli in a Jail? geli: Cannot lock memory: Operation not permitted. 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, 31 Mar 2009 07:00:17 -0000 I could't init a geli in a jail. Anyone know how? Here is what I tried jail# geli init -s 4096 -K /root/gelitest.key /dev/zvol/tank/testgeli geli: Cannot lock memory: Operation not permitted. [1] In the host, I created the volume: host# zfs create -V 4g tank/gelijar [2] made a custom devfs to show the zvol in the jail... [devfsrules_gelitest=5] add include $devfsrules_hide_all add include $devfsrules_unhide_basic add include $devfsrules_unhide_login add path zvol unhide add path tank unhide add path *gelijar unhide [3] tried to add the geli in the jail and failed. :( For now, I init/attach/newfs/mount the filesystem from the host into the jail, but I want to leave the attach to the customer in the jail... host# geli init -s 4096 -K /root/gelitest.key /dev/zvol/tank/testgeli host# geli attach -k /root/gelitest.key /dev/zvol/tank/testgeli host# newfs /dev/zvol/tank/testgeli.eli host# mount /dev/zvol/tank/testgeli.eli /tank/gelijar.monkeybrains.net/crypt host# df < -- I see it! jail# df <-- I don't see /crypt. :( Any way to fix that as well? Thanks, Rudy From owner-freebsd-current@FreeBSD.ORG Tue Mar 31 07:10:47 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 96DD71065670; Tue, 31 Mar 2009 07:10:47 +0000 (UTC) (envelope-from das@FreeBSD.ORG) Received: from zim.MIT.EDU (ZIM.MIT.EDU [18.95.3.101]) by mx1.freebsd.org (Postfix) with ESMTP id 575E48FC12; Tue, 31 Mar 2009 07:10:47 +0000 (UTC) (envelope-from das@FreeBSD.ORG) Received: from zim.MIT.EDU (localhost [127.0.0.1]) by zim.MIT.EDU (8.14.3/8.14.2) with ESMTP id n2V6oO63009937; Tue, 31 Mar 2009 02:50:24 -0400 (EDT) (envelope-from das@FreeBSD.ORG) Received: (from das@localhost) by zim.MIT.EDU (8.14.3/8.14.2/Submit) id n2V6oOHH009936; Tue, 31 Mar 2009 02:50:24 -0400 (EDT) (envelope-from das@FreeBSD.ORG) Date: Tue, 31 Mar 2009 02:50:24 -0400 From: David Schultz To: Joe Marcus Clarke Message-ID: <20090331065024.GA9671@zim.MIT.EDU> Mail-Followup-To: Joe Marcus Clarke , current References: <1238362728.73736.165.camel@shumai.marcuscom.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1238362728.73736.165.camel@shumai.marcuscom.com> Cc: current Subject: Re: getline incompatibility with Linux 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, 31 Mar 2009 07:10:47 -0000 On Sun, Mar 29, 2009, Joe Marcus Clarke wrote: > The new getline() function in FreeBSD is not completely compatible with > Linux's implementation. The result is that programs which assume Linux > getline may enter a tight infinite loop. > > According to the Linux getline(3) manpage, getline(3) returns -1 on > error (including EOF). Our implementation returns 0 on EOF. Would it > be possible to return -1 on EOF in our implementation? Good catch; even POSIX says (in its usual roundabout way) that getline() is supposed to return -1 on both error and EOF, and never return 0. Of course POSIX merely inherited this braindeadness from glibc... The following patch should fix it. I'll commit this soonish, but ENOTIME right now. Thanks for pointing this out. Index: getline.3 =================================================================== --- getline.3 (revision 190425) +++ getline.3 (working copy) @@ -24,7 +24,7 @@ .\" .\" $FreeBSD$ .\" -.Dd February 28, 2009 +.Dd March 29, 2009 .Dt GETLINE 3 .Os .Sh NAME @@ -79,7 +79,7 @@ functions return the number of characters written, excluding the terminating .Dv NUL . -The value \-1 is returned if an error occurs. +The value \-1 is returned if an error occurs, or if end-of-file is reached. .Sh EXAMPLES The following code fragment reads lines from a file and writes them to standard output. Index: getdelim.c =================================================================== --- getdelim.c (revision 190425) +++ getdelim.c (working copy) @@ -120,7 +120,6 @@ goto error; } - linelen = 0; if (*linecapp == 0) *linep = NULL; @@ -128,9 +127,12 @@ /* If fp is at EOF already, we just need space for the NUL. */ if (__sferror(fp) || expandtofit(linep, 1, linecapp)) goto error; - goto done; + FUNLOCKFILE(fp); + (*linep)[0] = '\0'; + return (-1); } + linelen = 0; while ((endp = memchr(fp->_p, delim, fp->_r)) == NULL) { if (sappend(linep, &linelen, linecapp, fp->_p, fp->_r)) goto error; From owner-freebsd-current@FreeBSD.ORG Tue Mar 31 07:19: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 CF57E106566B for ; Tue, 31 Mar 2009 07:19:34 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 153A38FC0C for ; Tue, 31 Mar 2009 07:19:33 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from porto.topspin.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id KAA23143; Tue, 31 Mar 2009 10:19:04 +0300 (EEST) (envelope-from avg@icyb.net.ua) Received: from localhost.topspin.kiev.ua ([127.0.0.1] helo=edge.pp.kiev.ua) by porto.topspin.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1LoYFU-000MHA-At; Tue, 31 Mar 2009 10:19:04 +0300 Message-ID: <49D1C3E6.3050207@icyb.net.ua> Date: Tue, 31 Mar 2009 10:19:02 +0300 From: Andriy Gapon User-Agent: Thunderbird 2.0.0.19 (X11/20090114) MIME-Version: 1.0 To: User Wblock References: <4451ccf20903300123p4df9c1d7k4c4138ad25d2d4af@mail.gmail.com> <49D0E44C.60103@phat.za.net> <49D1001E.2050405@icyb.net.ua> In-Reply-To: X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Aragon Gouveia , ccuiyyan@gmail.com, freebsd-current@freebsd.org Subject: Re: loader prompt doesn't work 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, 31 Mar 2009 07:19:35 -0000 on 31/03/2009 03:50 User Wblock said the following: > On Mon, 30 Mar 2009, Andriy Gapon wrote: >> There was a significant fix to boot code made recently by jhb. >> It is now in head, stable/7 and stable/6. >> So you need to update to the recent resources. >> What you also need (and what was not emphasized enough, IMO) is to >> actually >> install new boot code (/boot/boot) to your active slices after >> installworld completes. >> >> E.g.: >> $ gpart bootcode -b /boot/boot adXsY > > The gpart manpage just makes me more confused about this. Your reply is quite confusing too - you put many different things into the same heap. > I don't know > what a "protective" MBR is, or if I've got one. If you think that you have to know, then google is your friend. > Can you expand on this a little? On "this" what? > For instance: > > * When did it happen? "it" what? > * Who needs to do this--everyone who has updated to a recent -CURRENT or > -STABLE? If you don't have the problems described earlier in this thread than you don't have to do anything. > Or just those using certain partitioning features? > * There's no mention in /usr/src/UPDATING. Was it mentioned anywhere? -- Andriy Gapon From owner-freebsd-current@FreeBSD.ORG Tue Mar 31 07:20: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 40D3E106566C for ; Tue, 31 Mar 2009 07:20:37 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) by mx1.freebsd.org (Postfix) with ESMTP id F3D828FC13 for ; Tue, 31 Mar 2009 07:20:36 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (critter.freebsd.dk [192.168.61.3]) by phk.freebsd.dk (Postfix) with ESMTP id D810478CCA; Tue, 31 Mar 2009 07:20:35 +0000 (UTC) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.14.3/8.14.3) with ESMTP id n2V7KZxY096527; Tue, 31 Mar 2009 07:20:35 GMT (envelope-from phk@critter.freebsd.dk) To: Doug Barton From: "Poul-Henning Kamp" In-Reply-To: Your message of "Mon, 30 Mar 2009 23:04:17 MST." <49D1B261.6010406@FreeBSD.org> Date: Tue, 31 Mar 2009 07:20:35 +0000 Message-ID: <96526.1238484035@critter.freebsd.dk> Sender: phk@critter.freebsd.dk Cc: freebsd-current@FreeBSD.org Subject: Re: New rc.d/named features for testing: auto-forwarding and wait on boot 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, 31 Mar 2009 07:20:37 -0000 In message <49D1B261.6010406@FreeBSD.org>, Doug Barton writes: >There has been some discussion recently about the idea of adding an >option for the rc.d startup process to wait until name resolution >comes on line. (There is also room for a more general "wait for the >network to come on line" option, but I chose to focus on the named >version since my time is limited atm.) Maybe we need to do a more general mechanism, since many also would like us to have confirmed the wall-clock-time via NTP before we start anything that depends on it ? -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From owner-freebsd-current@FreeBSD.ORG Tue Mar 31 07:25:54 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 3385F106564A for ; Tue, 31 Mar 2009 07:25:54 +0000 (UTC) (envelope-from crapsh@monkeybrains.net) Received: from ape.monkeybrains.net (mail.monkeybrains.net [208.69.40.9]) by mx1.freebsd.org (Postfix) with ESMTP id 1D5BF8FC12 for ; Tue, 31 Mar 2009 07:25:54 +0000 (UTC) (envelope-from crapsh@monkeybrains.net) Received: from [192.168.2.105] (adsl-76-203-172-200.dsl.pltn13.sbcglobal.net [76.203.172.200]) (authenticated bits=0) by ape.monkeybrains.net (8.14.1/8.14.1) with ESMTP id n2V7PrMV017841 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 31 Mar 2009 00:25:53 -0700 (PDT) (envelope-from crapsh@monkeybrains.net) Message-ID: <49D1C57C.9050202@monkeybrains.net> Date: Tue, 31 Mar 2009 00:25:48 -0700 From: Rudy User-Agent: Thunderbird 2.0.0.19 (X11/20090105) MIME-Version: 1.0 To: freebsd-current@freebsd.org References: <49D1B7CD.1080702@monkeybrains.net> In-Reply-To: <49D1B7CD.1080702@monkeybrains.net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on pita.monkeybrains.net X-Virus-Status: Clean Subject: Re: Geli in a Jail? geli: Cannot lock memory: Operation not permitted. 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, 31 Mar 2009 07:25:54 -0000 Rudy wrote: > I could't init a geli in a jail. Anyone know how? > > Here is what I tried > > jail# geli init -s 4096 -K /root/gelitest.key /dev/zvol/tank/testgeli > geli: Cannot lock memory: Operation not permitted. > Running truss, it seems to be mlockall... mlockall(0x2,0x7fffffffb240,0x800e058b0,0x800ac1c9c,0xfffffffeee007d40,0x7fffffffadb8) ERR#1 'Operation not permitted' geli: write(2,"geli: ",6) = 6 (0x6) Cannot lock memory: Operation not permitted.write(2,"Cannot lock memory: Operation no"...,44) = 44 (0x2c) Is this a mlock() in jail issue or an can't talk to a kernel module issue? Rudy From owner-freebsd-current@FreeBSD.ORG Tue Mar 31 08:10: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 2163810656C6; Tue, 31 Mar 2009 08:10:57 +0000 (UTC) (envelope-from gperez@entel.upc.edu) Received: from dash.upc.es (dash.upc.es [147.83.2.50]) by mx1.freebsd.org (Postfix) with ESMTP id A08538FC1F; Tue, 31 Mar 2009 08:10:56 +0000 (UTC) (envelope-from gperez@entel.upc.edu) Received: from entelserver.upc.edu (entelserver.upc.es [147.83.39.4]) by dash.upc.es (8.14.1/8.13.1) with ESMTP id n2V8At2C001017; Tue, 31 Mar 2009 10:10:55 +0200 Received: from webmail.entel.upc.edu (webmail.entel.upc.es [147.83.39.6]) by entelserver.upc.edu (Postfix) with ESMTP id DB8442CBD06; Tue, 31 Mar 2009 10:10:49 +0200 (CEST) Received: from 147.83.40.214 by webmail.entel.upc.edu with HTTP; Tue, 31 Mar 2009 10:10:49 +0200 (CEST) Message-ID: <42605.147.83.40.214.1238487049.squirrel@webmail.entel.upc.edu> In-Reply-To: <200903301215.19629.jkim@FreeBSD.org> References: <1236802980.00085518.1236789602@10.7.7.3> <200903251833.14825.jkim@FreeBSD.org> <49CFD66E.5030301@entel.upc.edu> <200903301215.19629.jkim@FreeBSD.org> Date: Tue, 31 Mar 2009 10:10:49 +0200 (CEST) From: "Gustavo Perez Querol" To: "Jung-uk Kim" User-Agent: SquirrelMail/1.4.10a-1.fc6 MIME-Version: 1.0 Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal X-Mail-Scanned: Criba 2.0 + Clamd X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0 (dash.upc.es [147.83.2.50]); Tue, 31 Mar 2009 10:10:55 +0200 (CEST) Cc: freebsd-current@freebsd.org Subject: Re: [HEADSUP] amd64 suspend/resume code to be comitted 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, 31 Mar 2009 08:10:59 -0000 > If it worked fine, you can try each driver and tell us what breaks > suspend/resume process. If you can find the culprit, you can file a > PR and you may able to work around it by adding 'kldunload whatever' > and 'kldload whatever' from rc.suspend and rc.resume respectively. > BTW, bge(4) is already known for suspend/resume problem if my memory > serves. Well, finally I got my video back ! As you pointed bge(4) is giving problems. Kldunloading it solves them. In the other hand, I tried the following to get something working : 1.- In multiuser without X I tried acpiconf -s 3 2.- Bring the machine back to live. 3.- The screen shows some info about usb's and such, then it goes black. 4.- At this point I tried vidcontrol -s 0 < /dev/console. As you may note, it is a typo. Don't know what was in my mind in that moment. 5.- Success !!! The console came back, arguing that the console number was out of range. It is very strange. Looks like it is switching to and unknown mode. I'll try in graphics mode, I think some said nouveau is able to suspend/resume. Will see if it works. Finally report that kldloading if_bge after resume doesn't make the card work. Making pciconf -lv shows the card, but no driver attaches to the card. Greets, Gustau From owner-freebsd-current@FreeBSD.ORG Tue Mar 31 08:15: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 E40791065680 for ; Tue, 31 Mar 2009 08:15:07 +0000 (UTC) (envelope-from alexander@leidinger.net) Received: from redbull.bpaserver.net (redbullneu.bpaserver.net [213.198.78.217]) by mx1.freebsd.org (Postfix) with ESMTP id 8C4138FC18 for ; Tue, 31 Mar 2009 08:15:07 +0000 (UTC) (envelope-from alexander@leidinger.net) Received: from outgoing.leidinger.net (pD9E2E2C4.dip.t-dialin.net [217.226.226.196]) by redbull.bpaserver.net (Postfix) with ESMTP id 02C4E2E05E; Tue, 31 Mar 2009 10:15:00 +0200 (CEST) Received: from webmail.leidinger.net (webmail.leidinger.net [192.168.1.102]) by outgoing.leidinger.net (Postfix) with ESMTP id 13468120C9A; Tue, 31 Mar 2009 10:14:55 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=Leidinger.net; s=outgoing-alex; t=1238487296; bh=Nu8TPLp0jzsH+yyoStuP7TJ+3ujQ+L7Q3 UtKB99euyo=; h=Message-ID:Date:From:To:Cc:Subject:References: In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=x4vWXdDpkRCk6X1O2qzY804+jrMNWspv91eLtcsF0NtDtEsSwcVldZ4vG4ZLa+9Ae v7vKNRzU5M2cuAMUJAHVl9BxPhfS2au3eLHFCfGbLW1WogNVAQV+GZRMkt0iKvG6Va8 9bD0YAMVBzCi/NyP+2dqYWvtBgyzMNXf5Er3tDn0V7oboBL9FK1zsljniEGC2SKysFf wDhTKEUPY3vh72xSEMEpHxx2hBn+AyRqrIcXX2MPnodk2U7NZ5U8ppQrNc9lluKuwQS LD7t69kNVSRdxCbXm4QVs4KWuAy1gYqvUfuXsY6awukTuHNWjJQ/H4HzZSqYalnUVso P5yn3SKhg== Received: (from www@localhost) by webmail.leidinger.net (8.14.3/8.13.8/Submit) id n2V8Et9X095966; Tue, 31 Mar 2009 10:14:55 +0200 (CEST) (envelope-from Alexander@Leidinger.net) Received: from pslux.cec.eu.int (pslux.cec.eu.int [158.169.9.14]) by webmail.leidinger.net (Horde Framework) with HTTP; Tue, 31 Mar 2009 10:14:54 +0200 Message-ID: <20090331101454.16983mt8x4ru2xog@webmail.leidinger.net> X-Priority: 3 (Normal) Date: Tue, 31 Mar 2009 10:14:54 +0200 From: Alexander Leidinger To: Doug Barton References: <49D1B261.6010406@FreeBSD.org> In-Reply-To: <49D1B261.6010406@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; DelSp="Yes"; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: 7bit User-Agent: Internet Messaging Program (IMP) H3 (4.3) / FreeBSD-8.0 X-BPAnet-MailScanner-Information: Please contact the ISP for more information X-MailScanner-ID: 02C4E2E05E.B7574 X-BPAnet-MailScanner: Found to be clean X-BPAnet-MailScanner-SpamCheck: not spam, ORDB-RBL, SpamAssassin (not cached, score=-14.3, required 6, BAYES_00 -15.00, DKIM_SIGNED 0.00, DKIM_VERIFIED -0.00, J_CHICKENPOX_21 0.60, RDNS_DYNAMIC 0.10) X-BPAnet-MailScanner-From: alexander@leidinger.net X-Spam-Status: No Cc: freebsd-current@FreeBSD.org Subject: Re: New rc.d/named features for testing: auto-forwarding and wait on boot 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, 31 Mar 2009 08:15:08 -0000 Quoting Doug Barton (from Mon, 30 Mar 2009 23:04:17 -0700): > There has been some discussion recently about the idea of adding an > option for the rc.d startup process to wait until name resolution > comes on line. (There is also room for a more general "wait for the > network to come on line" option, but I chose to focus on the named > version since my time is limited atm.) I assume this is opt-in, and not on by default (this is not needed everywhere). At which place in the startup would this wait? Bye, Alexander. -- I have never been one to sacrifice my appetite on the altar of appearance. -- A. M. Readyhough http://www.Leidinger.net Alexander @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137 From owner-freebsd-current@FreeBSD.ORG Tue Mar 31 08:25: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 639561065676 for ; Tue, 31 Mar 2009 08:25:25 +0000 (UTC) (envelope-from mel.flynn+fbsd.current@mailing.thruhere.net) Received: from mailhub.rachie.is-a-geek.net (rachie.is-a-geek.net [66.230.99.27]) by mx1.freebsd.org (Postfix) with ESMTP id 2D52A8FC16 for ; Tue, 31 Mar 2009 08:25:24 +0000 (UTC) (envelope-from mel.flynn+fbsd.current@mailing.thruhere.net) Received: from sarevok.dnr.servegame.org (gate.lan.rachie.is-a-geek.net [192.168.2.10]) by mailhub.rachie.is-a-geek.net (Postfix) with ESMTP id 840737E818; Tue, 31 Mar 2009 00:25:23 -0800 (AKDT) From: Mel Flynn To: freebsd-current@freebsd.org Date: Tue, 31 Mar 2009 10:25:22 +0200 User-Agent: KMail/1.11.0 (FreeBSD/8.0-CURRENT; KDE/4.2.0; i386; ; ) References: <49D1B261.6010406@FreeBSD.org> <49D1B57F.8050903@FreeBSD.org> In-Reply-To: <49D1B57F.8050903@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200903311025.22219.mel.flynn+fbsd.current@mailing.thruhere.net> Cc: Doug Barton Subject: Re: New rc.d/named features for testing: auto-forwarding and wait on boot 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, 31 Mar 2009 08:25:25 -0000 Hi Doug, On Tuesday 31 March 2009 08:17:35 Doug Barton wrote: > > In addition to enabling auto_forward you can also enable > > auto_forward_only which changes from the default 'forward first' to > > (you guessed it) 'forward only'. > And of course, the patch: > http://dougbarton.us/Downloads/rcd-named.diff Snippet: + if [ -z "$firstns" ]; then + if [ ! "$nsip" = '127.0.0.1' ]; then + echo 'nameserver 127.0.0.1' + echo " ${nsip};" >> /var/run/auto_forward.conf + fi I think the hardcoded 127.0.0.1 should be configurable especially considering prepend-domain-nameservers option for dhclient.conf(5). Now you risk using yourself as forwarder if you expose the resolver to the internal network (whether it be through dhclient or statically). Also, maybe the combo of autoforward and dhclient should be guarded against, since there's no telling which comes up first and both dhclient and /etc/rc.d/named might be writing /etc/resolv.conf at the same time / after eachother. Lastly, 127.0.0.1 and ::1 aren't equal, yet they are the same thing ;) -- Mel From owner-freebsd-current@FreeBSD.ORG Tue Mar 31 09:11: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 1C2D91065670 for ; Tue, 31 Mar 2009 09:11:53 +0000 (UTC) (envelope-from M.S.Powell@salford.ac.uk) Received: from airy.salford.ac.uk (airy.salford.ac.uk [146.87.0.11]) by mx1.freebsd.org (Postfix) with SMTP id 78FC08FC12 for ; Tue, 31 Mar 2009 09:11:52 +0000 (UTC) (envelope-from M.S.Powell@salford.ac.uk) Received: (qmail 13166 invoked by uid 98); 31 Mar 2009 10:11:51 +0100 Received: from 146.87.255.121 by airy.salford.ac.uk (envelope-from , uid 401) with qmail-scanner-2.01 (clamdscan: 0.94.2/9185. spamassassin: 3.2.4. Clear:RC:1(146.87.255.121):. Processed in 0.038823 secs); 31 Mar 2009 09:11:51 -0000 Received: from rust.salford.ac.uk (HELO rust.salford.ac.uk) (146.87.255.121) by airy.salford.ac.uk (qpsmtpd/0.3x.614) with SMTP; Tue, 31 Mar 2009 10:11:50 +0100 Received: (qmail 48415 invoked by uid 1002); 31 Mar 2009 09:11:48 -0000 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 31 Mar 2009 09:11:48 -0000 Date: Tue, 31 Mar 2009 10:11:48 +0100 (BST) From: "Mark Powell" To: Thomas Sparrevohn In-Reply-To: <200903301745.46149.Thomas.Sparrevohn@btinternet.com> Message-ID: <20090331100328.H46640@rust.salford.ac.uk> References: <49BD117B.2080706@163.com> <20090325090456.G92412@rust.salford.ac.uk> <49C9FC53.8070104@163.com> <200903301745.46149.Thomas.Sparrevohn@btinternet.com> MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="0-1793810244-1238490296=:46640" Content-ID: <20090331100726.K46640@rust.salford.ac.uk> Cc: kevin , freebsd-current@freebsd.org Subject: Re: ZFS data error without reasons 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, 31 Mar 2009 09:11:53 -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. --0-1793810244-1238490296=:46640 Content-Type: TEXT/PLAIN; CHARSET=UTF-8; FORMAT=flowed Content-Transfer-Encoding: QUOTED-PRINTABLE Content-ID: <20090331100726.Y46640@rust.salford.ac.uk> On Mon, 30 Mar 2009, Thomas Sparrevohn wrote: > On Wednesday 25 March 2009 09:41:39 kevin wrote: >> Mark Powell wrote: >>> Kevin, >>> Did you fix your ZFS CRC errors? >>> I responded to your thread, but no-one got back to me. >>> I'm gonna start another thread later. >>> This time I re-made the zpool in 8 compatible with 7. Once the errors >>> started showing up in 8 I moved back to 7, on the same hardware, to >>> perform the scrub to prove the problem is with 8. The 1st scrub in 7 >>> found some errors, but of course it would if 8 had messed up the data. >>> Removed the few unimportant bad files (all were in snapshots). >>> Just performing the 2nd scrub in 7 now. If this comes back with no >>> errors, then we have stronger proof that there is some wrong, which >>> seems quite intermittent, in 8 that randomly writes bad data. >>> Cheers. >>> >> Yes=EF=BC=8CI can fix some ZFS CRC errors,and sometimes i can recover al= l error >> files.Before i run "zpool import backup" to mount the zpool on a usb >> hard disk, "zpool status" return no errors. When i copy files to the usb >> hard disk,soon I can get lots of file errors.After a reboot,if i run >> scrub,i can fix many errors. I just think copy files between two zpools, >> one is on local hard disk and the other one is on a usb hard disk, may >> easily reproduce the bug. I didn't write that! > I have not been folloing the entire thread - but I can reproduce ZFS CRC= =20 > corruption on the current kernel just by unpluging a USB disk drive -=20 > The is no errors on the disks - revert to and old kernel FreeBSD=20 > w2fzz0vc03.aah-go-on.com 8.0-CURRENT FreeBSD 8.0-CURRENT #1 r189454M:=20 > Fri Mar 6 18:46:25 GMT 2009=20 > root@w2fzz0vc03.aah-go-on.com:/usr/obj/usr/src/sys/GENERIC amd64 > > the problem can be solved - The weird thing is that it will give CRC=20 > errros (and permenent errors) in blocks that has not been touched (or at= =20 > least I think so) Can you be a little clearer? Perhaps some zpool status output with the=20 steps you've taken? > I suspect that It may have to do with the USB DMA bounce buffer as an=20 > example see the message file included I expect this is a red hering, but do you not have some kind of=20 kernel/module sync problem? Mar 26 13:48:18 w2fzz0vc03 root: /etc/rc: WARNING: Unable to load kernel mo= dule daemon_saver Mar 26 13:48:18 w2fzz0vc03 kernel: KLD daemon_saver.ko: depends on kernel -= not available Cheers. --=20 Mark Powell - UNIX System Administrator - The University of Salford Information & Learning Services, Clifford Whitworth Building, Salford University, Manchester, M5 4WT, UK. Tel: +44 161 295 6843 Fax: +44 161 295 5888 www.pgp.com for PGP key --0-1793810244-1238490296=:46640-- From owner-freebsd-current@FreeBSD.ORG Tue Mar 31 10: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 7562B1065670; Tue, 31 Mar 2009 10:20:27 +0000 (UTC) (envelope-from ohartman@zedat.fu-berlin.de) Received: from outpost1.zedat.fu-berlin.de (outpost1.zedat.fu-berlin.de [130.133.4.66]) by mx1.freebsd.org (Postfix) with ESMTP id 03DFC8FC26; Tue, 31 Mar 2009 10:20:26 +0000 (UTC) (envelope-from ohartman@zedat.fu-berlin.de) Received: from inpost2.zedat.fu-berlin.de ([130.133.4.69]) by outpost1.zedat.fu-berlin.de (Exim 4.69) with esmtp (envelope-from ) id <1Lob4z-0004Q6-Mo>; Tue, 31 Mar 2009 12:20:25 +0200 Received: from telesto.geoinf.fu-berlin.de ([130.133.86.198]) by inpost2.zedat.fu-berlin.de (Exim 4.69) with esmtpsa (envelope-from ) id <1Lob4z-0001H8-LY>; Tue, 31 Mar 2009 12:20:25 +0200 Message-ID: <49D1EE0F.1050901@zedat.fu-berlin.de> Date: Tue, 31 Mar 2009 10:18:55 +0000 From: "O. Hartmann" Organization: Freie =?ISO-8859-15?Q?Universit=E4t_Berlin?= User-Agent: Thunderbird 2.0.0.21 (X11/20090323) MIME-Version: 1.0 To: freebsd-questions@freebsd.org, freebsd-current@FreeBSD.org Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: 130.133.86.198 Cc: Subject: Issues with OpenLDAP 2.4.15 and FreeBSD 8.0-CUrrent as well as with FreeBSD 7.2-PRE using DB 4.7 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, 31 Mar 2009 10:20:28 -0000 I reported this earlier here and now I'm about to file a PR. Before that, I will ask whether there is a solution out here or someone can give a hint in case I ran into a hidden misconfiguration. First I see on all FreeBSD flavours (7.2 and 8.0) a coredump of LDAP clients when doing ldapsearch, ldappasswd. The client performs well, but at the end it terminates with some SIG 11. Another very severe issue is with Db 4.7 and OpenLDAP 2.4.15 as taken from ports. On FreeBSD 7.1/7.2 I was running a OpenLDAP 1.4.15 server, used with DB 4.6. Several experimental boxes with FreeBSD 8.0-CURRENT and FreeBSD 7.1/7.2 were referring to that LDAP server for user authetication. After backing up the database, installing DB 4.7, recompiling everything that depends on DB 4.X, recompiling at last OpenLDAP and doing a Db recover ends up in a problem. The clients which were willing to perform logins via ssh by autheticating users via this LDAP server refuses now authentication! The same client authenticates the users of the LDAP server via LDAP authentication when accessing protected webpages served by lighttpd. I also can enumerate /home with users taken from the LDAP server, except login in via ssh. I did not change sshd's config, so I suspect something else. Watching console log and slapd log I see no issues aside the slapd log, but console and sshd log tell something about an unknown user with uid XXXX. Googling for this error I find a lot of sshd/nss/ldap related issues - but no solution. Doinf a 'sudo' or 'su' on the same machine to users residing on LDAP db is possible. But connection via ssh isn't possible. Another very strange behaviour occurs on FreeBSD 8.0-CURRENT serving as OpenLDAP 2.4.15 server with cysrus-sasl compiled in and DB 4.7. Authentication to this server, even from the local host, takes approximately 20 - 30 seconds, connecting LUMA for administering also takes that long, even showing up the DIT in LUMA takes unconveniently long times to perform. This happens when this server was updated from FreeBSD 7.2-PRE to FreeBSD 8.0-CURRENT with all the stuff completely fresh installed. Before the upgrade, the OpenLDAP server was running 2.4.15 with DB 4.7 as well as it does now under FreeBSD 8.0-CUR. Well, even with fresh standard installations taken from the templates when using nss_ldap/pam_ldap/OpenLDAP shows those strange issues on all mentioned boxes and OS flavours. Now I think I ran into a severe issue with either OpenLDAP 2.4.15 and/or FreeBSD 8.0. Regards, Oliver From owner-freebsd-current@FreeBSD.ORG Tue Mar 31 10:53: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 92B77106564A; Tue, 31 Mar 2009 10:53:01 +0000 (UTC) (envelope-from admin@kkip.pl) Received: from mainframe.kkip.pl (kkip.pl [87.105.164.78]) by mx1.freebsd.org (Postfix) with ESMTP id 445D58FC17; Tue, 31 Mar 2009 10:53:01 +0000 (UTC) (envelope-from admin@kkip.pl) Received: from mb01.admin.lan.kkip.pl ([10.66.3.254]) by mainframe.kkip.pl with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1LobJ4-0005IO-Lj; Tue, 31 Mar 2009 12:35:01 +0200 Message-ID: <49D1F1D2.20102@kkip.pl> Date: Tue, 31 Mar 2009 12:34:58 +0200 From: Bartosz Stec User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: "O. Hartmann" References: <49D1EE0F.1050901@zedat.fu-berlin.de> In-Reply-To: <49D1EE0F.1050901@zedat.fu-berlin.de> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-Authenticated-User: admin@kkip.pl X-Authenticator: plain X-Sender-Verify: SUCCEEDED (sender exists & accepts mail) X-Spam-Score: -8.9 X-Spam-Score-Int: -88 X-Exim-Version: 4.69 (build at 30-Mar-2009 10:58:24) X-Date: 2009-03-31 12:35:01 X-Connected-IP: 10.66.3.254:3922 X-Message-Linecount: 36 X-Body-Linecount: 22 X-Message-Size: 1569 X-Body-Size: 972 X-Received-Count: 1 X-Recipient-Count: 3 X-Local-Recipient-Count: 3 X-Local-Recipient-Defer-Count: 0 X-Local-Recipient-Fail-Count: 0 Cc: freebsd-current@FreeBSD.org, freebsd-questions@freebsd.org Subject: Re: Issues with OpenLDAP 2.4.15 and FreeBSD 8.0-CUrrent as well as with FreeBSD 7.2-PRE using DB 4.7 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, 31 Mar 2009 10:53:02 -0000 O. Hartmann pisze: > I reported this earlier here and now I'm about to file a PR. Before > that, I will ask whether there is a solution out here or someone can > give a hint in case I ran into a hidden misconfiguration. > > First I see on all FreeBSD flavours (7.2 and 8.0) a coredump of LDAP > clients when doing ldapsearch, ldappasswd. The client performs well, > but at the end it terminates with some SIG 11. > That's really funny when ldapadd just do what you want it to do, and gives you core dump instead of "bye bye" ;) I have the same issue with FreeBSD 7.2 (I'm not using OpenLDAP on CURRENT). From my observations this behaviour depends on options checked with 'make config'. SIG 11 occurs with default settings, so I checked ONLY bdb, perl and SASL (just what I needed for shared address book). and now it is working like a charm. However it's not a SOLUTION for this problem, especially when you need other options from config. -- Bartosz Stec From owner-freebsd-current@FreeBSD.ORG Tue Mar 31 08:30: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 B0E2B106564A; Tue, 31 Mar 2009 08:30:03 +0000 (UTC) (envelope-from gjb@semihalf.com) Received: from semihalf.com (semihalf.com [206.130.101.55]) by mx1.freebsd.org (Postfix) with ESMTP id 900188FC12; Tue, 31 Mar 2009 08:30:03 +0000 (UTC) (envelope-from gjb@semihalf.com) Received: from mail.semihalf.com (mail.semihalf.com [83.15.139.206]) by semihalf.com (8.13.1/8.13.1) with ESMTP id n2V7x6w0000775; Tue, 31 Mar 2009 01:59:08 -0600 Message-ID: <49D1CD6F.7090003@semihalf.com> Date: Tue, 31 Mar 2009 09:59:43 +0200 From: Grzegorz Bernacki MIME-Version: 1.0 To: freebsd-current@FreeBSD.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Tue, 31 Mar 2009 11:25:15 +0000 Cc: jeff@FreeBSD.org Subject: LOR when UMA reclaims unused memory. 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, 31 Mar 2009 08:30:04 -0000 Hi, We have observed lock order reversal that shows up when pageout daemon is running. I could not find it FreeBSD LOR page. It started to occur after latest changes in uma_core.c file. Below is the backtrace of LOR ( I completed trace with names of functions which were not resolved by debugger). lock order reversal: 1st 0xc1089288 mbuf_cluster (UMA zone) @ /home/gjb/git/marvell/sys/vm/uma_core.c:2703 2nd 0xc0ea56a4 pmap (pmap) @ /home/gjb/git/marvell/sys/arm/arm/pmap.c:3628 KDB: stack backtrace: db_trace_thread() at db_trace_thread+0x10 scp=0xc0b46f7c rlv=0xc091e8d0 ($a+0x34) rsp=0xd115eb04 rfp=0xd115ec20 r10=0xc36e54b8 r9=0x00000e2c r8=0xc0e60270 r7=0xc36e52b0 r6=0xffffffff r5=0xc0ba1fc4 r4=0xd115eb0c $a() at $a+0x10 scp=0xc091e8ac rlv=0xc09e5698 (kdb_backtrace+0x3c) rsp=0xd115ec24 rfp=0xd115ec34 r4=0xc0d315d8 kdb_backtrace() at kdb_backtrace+0x10 scp=0xc09e566c rlv=0xc09f32d4 (_witness_debugger+0x5c) rsp=0xd115ec38 rfp=0xd115ec4c r4=0x00000001 _witness_debugger() at _witness_debugger+0x14 scp=0xc09f328c rlv=0xc09f3fe4 (witness_checkorder+0x664) rsp=0xd115ec50 rfp=0xd115ecf0 r5=0xc0ea56a4 r4=0x00000000 witness_checkorder() at witness_checkorder+0x10 scp=0xc09f3990 rlv=0xc09b1870 (_mtx_lock_flags+0x34) rsp=0xd115ecf4 rfp=0xd115ed1c r10=0xc0ea75d0 r9=0xc0ea75d0 r8=0x00000e2c r7=0xc0bdf97c r6=0x00000000 r5=0x00000000 r4=0xc0ea56a4 _mtx_lock_flags() at _mtx_lock_flags+0x10 scp=0xc09b184c rlv=0xc0b4c660 (pmap_extract+0x24) rsp=0xd115ed20 rfp=0xd115ed38 r10=0xc0e9bd60 r8=0xc3b43800 r7=0x00000000 r6=0xc0ea56a4 r5=0xc3b43800 r4=0xc108db7c pmap_extract() at pmap_extract+0x10 scp=0xc0b4c64c rlv=0xc0b25660 ($a+0x340) rsp=0xd115ed3c rfp=0xd115ed5c r6=0xc1092640 r5=0x00000000 r4=0xc108db7c $a() at $a+0x10 <======= bucket_drain() scp=0xc0b25330 rlv=0xc0b25ab0 ($a+0x60) rsp=0xd115ed60 rfp=0xd115ed78 r8=0x00000000 r7=0xc37a5828 r6=0xc0b25dc4 r5=0xc1092640 r4=0xc108db7c $a() at $a+0x10 scp=0xc0b25a60 rlv=0xc0b25c2c (bucket_cache_drain+0x54) rsp=0xd115ed7c rfp=0xd115ed90 r5=0xc1092640 r4=0xc108db7c bucket_cache_drain() at bucket_cache_drain+0x10 scp=0xc0b25be8 rlv=0xc0b25d3c ($a+0xa0) rsp=0xd115ed94 rfp=0xd115edac r5=0x00000001 r4=0xc1092640 $a() at $a+0x10 <====== zone_drain_wait() scp=0xc0b25cac rlv=0xc0b23f5c ($a+0x48) rsp=0xd115edb0 rfp=0xd115edc8 r5=0xc1089280 r4=0xc1092640 $a() at $a+0x10 <====== zone_foreach() scp=0xc0b23f24 rlv=0xc0b25de4 (uma_reclaim+0x18) rsp=0xd115edcc rfp=0xd115eddc r6=0xc36e1180 r5=0xc36e118c r4=0x00000000 uma_reclaim() at uma_reclaim+0x10 scp=0xc0b25ddc rlv=0xc0b39828 ($a+0x314) rsp=0xd115ede0 rfp=0xd115ee80 r4=0x00000000 $a() at $a+0x10 <==== vm_pageout() scp=0xc0b39524 rlv=0xc09a1f80 (fork_exit+0x64) rsp=0xd115ee84 rfp=0xd115eea8 r10=0xc0b39514 r9=0xc0ea75d0 r8=0x00000000 r7=0xc37a5828 r6=0xd115eeac r5=0xc0ea75d0 r4=0xc3840be0 fork_exit() at fork_exit+0x10 scp=0xc09a1f2c rlv=0xc0b56bdc (fork_trampoline+0x14) rsp=0xd115eeac rfp=0x00000000 r10=0xc0ea75d0 r8=0x00000104 r7=0xfeedfeed r6=0xfeedfeed r5=0x00000000 r4=0xc0b39514 Initial order between UMA zone and pmap locks is created when pmap allocates pv_entry. Below is function call sequence. fork_exit() start_init() data_abort_handler() vm_fault() pmap_enter() <== lock pmap (pmap) 1st pmap_enter_locked() uma_zalloc_arg() <== lock UMA zone (PV ENTRY) 2nd This LOR seems to be harmless cause it doesn't concern the same mutexes. However I am not sure if it is possible that some thread holds kernel pmap mutex and tries to get PV ENTRY and at the same moment pageout daemon holds PV ENTRY mutex (taken in zone_free_item()) and tries to call pmap_kextract() and get kernel pmap mutex. vtoslab() I've seen it on -current on arm machine with kernel configuration: DB-78XXX. regards, Grzesiek From owner-freebsd-current@FreeBSD.ORG Tue Mar 31 11:29: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 36E76106566C; Tue, 31 Mar 2009 11:29:53 +0000 (UTC) (envelope-from mav@FreeBSD.org) Received: from cmail.optima.ua (cmail.optima.ua [195.248.191.121]) by mx1.freebsd.org (Postfix) with ESMTP id 778E58FC0A; Tue, 31 Mar 2009 11:29:52 +0000 (UTC) (envelope-from mav@FreeBSD.org) X-Spam-Flag: SKIP X-Spam-Yversion: Spamooborona-2.1.0 Received: from [212.86.226.226] (account mav@alkar.net HELO mavbook.mavhome.dp.ua) by cmail.optima.ua (CommuniGate Pro SMTP 5.2.9) with ESMTPSA id 238947562; Tue, 31 Mar 2009 14:29:51 +0300 Message-ID: <49D1FEAE.4050006@FreeBSD.org> Date: Tue, 31 Mar 2009 14:29:50 +0300 From: Alexander Motin User-Agent: Thunderbird 2.0.0.21 (X11/20090329) MIME-Version: 1.0 To: Gustavo Perez Querol References: <1236802980.00085518.1236789602@10.7.7.3> <1238034181.00092378.1238020591@10.7.7.3> <1238368981.00093949.1238358002@10.7.7.3> <1238440994.00094295.1238430007@10.7.7.3> <1238498590.00094580.1238487605@10.7.7.3> In-Reply-To: <1238498590.00094580.1238487605@10.7.7.3> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org, Jung-uk Kim Subject: Re: [HEADSUP] amd64 suspend/resume code to be comitted 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, 31 Mar 2009 11:29:54 -0000 Gustavo Perez Querol wrote: > Finally report that kldloading if_bge after resume doesn't make the card > work. Making pciconf -lv shows the card, but no driver attaches to the > card. My bge suspends fine without unloading and works fine after resume. bge0@pci0:4:0:0: class=0x020000 card=0x011b1025 chip=0x169314e4 rev=0x02 hdr=0x00 -- Alexander Motin From owner-freebsd-current@FreeBSD.ORG Tue Mar 31 11: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 C6B3A106564A for ; Tue, 31 Mar 2009 11:31:34 +0000 (UTC) (envelope-from gary.jennejohn@freenet.de) Received: from mout1.freenet.de (mout1.freenet.de [IPv6:2001:748:100:40::2:3]) by mx1.freebsd.org (Postfix) with ESMTP id 5FE5E8FC12 for ; Tue, 31 Mar 2009 11:31:34 +0000 (UTC) (envelope-from gary.jennejohn@freenet.de) Received: from [195.4.92.17] (helo=7.mx.freenet.de) by mout1.freenet.de with esmtpa (ID gary.jennejohn@freenet.de) (port 25) (Exim 4.69 #79) id 1LocBp-0007Mz-6n for freebsd-current@freebsd.org; Tue, 31 Mar 2009 13:31:33 +0200 Received: from tc973.t.pppool.de ([89.55.201.115]:53894 helo=ernst.jennejohn.org) by 7.mx.freenet.de with esmtpa (ID gary.jennejohn@freenet.de) (port 25) (Exim 4.69 #79) id 1LocBo-00034T-VB for freebsd-current@freebsd.org; Tue, 31 Mar 2009 13:31:33 +0200 Date: Tue, 31 Mar 2009 13:31:32 +0200 From: Gary Jennejohn To: freebsd-current@freebsd.org Message-ID: <20090331133132.1e191836@ernst.jennejohn.org> In-Reply-To: <95891.1238477069@critter.freebsd.dk> References: <95891.1238477069@critter.freebsd.dk> X-Mailer: Claws Mail 3.7.1 (GTK+ 2.14.7; amd64-portbld-freebsd8.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: Re: Removal of GEOM_BSD, GEOM_MBR, GEOM_PC98 and GEOM_SUNLABEL X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: gary.jennejohn@freenet.de List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Mar 2009 11:31:35 -0000 On Tue, 31 Mar 2009 05:24:29 +0000 "Poul-Henning Kamp" wrote: > In message , Marcel Moolenaar wri > tes: > > >I plan to remove the "old" partitioning GEOMs mentioned in the subject > >line some time this week. Let me know if any of these should remain for now > >due to issues with gpart. > > Never mind gpart, but don't we have some guidelines for how long time > we leave stuff around before we rip it out ? > I have some disks which were partitioned before GEOM or gpart even existed. If this means that I can't use them any more I'll be very ticked off. --- Gary Jennejohn From owner-freebsd-current@FreeBSD.ORG Tue Mar 31 13:00: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 288D2106566B for ; Tue, 31 Mar 2009 13:00:08 +0000 (UTC) (envelope-from freebsd-current@m.gmane.org) Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by mx1.freebsd.org (Postfix) with ESMTP id 9083C8FC13 for ; Tue, 31 Mar 2009 13:00:07 +0000 (UTC) (envelope-from freebsd-current@m.gmane.org) Received: from root by ciao.gmane.org with local (Exim 4.43) id 1LodZS-0008Rq-TV for freebsd-current@freebsd.org; Tue, 31 Mar 2009 13:00:02 +0000 Received: from lara.cc.fer.hr ([161.53.72.113]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 31 Mar 2009 13:00:02 +0000 Received: from ivoras by lara.cc.fer.hr with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 31 Mar 2009 13:00:02 +0000 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-current@freebsd.org From: Ivan Voras Date: Tue, 31 Mar 2009 14:56:54 +0200 Lines: 50 Message-ID: References: <95891.1238477069@critter.freebsd.dk> <20090331133132.1e191836@ernst.jennejohn.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigB5947BBF177C35E1584CFB82" X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: lara.cc.fer.hr User-Agent: Thunderbird 2.0.0.21 (X11/20090318) In-Reply-To: <20090331133132.1e191836@ernst.jennejohn.org> X-Enigmail-Version: 0.95.0 Sender: news Subject: Re: Removal of GEOM_BSD, GEOM_MBR, GEOM_PC98 and GEOM_SUNLABEL 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, 31 Mar 2009 13:00:08 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigB5947BBF177C35E1584CFB82 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Gary Jennejohn wrote: > On Tue, 31 Mar 2009 05:24:29 +0000 > "Poul-Henning Kamp" wrote: >=20 >> In message , Marcel Mool= enaar wri >> tes: >> >>> I plan to remove the "old" partitioning GEOMs mentioned in the subjec= t =20 >>> line some time this week. Let me know if any of these should remain f= or now =20 >>> due to issues with gpart. >> Never mind gpart, but don't we have some guidelines for how long time >> we leave stuff around before we rip it out ? >> >=20 > I have some disks which were partitioned before GEOM or gpart even > existed. If this means that I can't use them any more I'll be very > ticked off. No, the question is which GEOM class to use to parse the partition table = :) gpart is new, shiny, but with some rough edges (most of which have been polished by now), GEOM_xxx were the old classes. 8-CURRENT doesn't use the old classes but they are still there if anyone needs them. --------------enigB5947BBF177C35E1584CFB82 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFJ0hMWldnAQVacBcgRAn32AKDwUL4GHoOW9eVU4ZWDin9u0aVWYwCfaRHH tai/XMsdIUg0LOPUzw+GXJo= =HfXc -----END PGP SIGNATURE----- --------------enigB5947BBF177C35E1584CFB82-- From owner-freebsd-current@FreeBSD.ORG Tue Mar 31 11:55: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 CB2DB106566B for ; Tue, 31 Mar 2009 11:55:12 +0000 (UTC) (envelope-from babkin@verizon.net) Received: from vms173019pub.verizon.net (vms173019pub.verizon.net [206.46.173.19]) by mx1.freebsd.org (Postfix) with ESMTP id AAA4D8FC1A for ; Tue, 31 Mar 2009 11:55:12 +0000 (UTC) (envelope-from babkin@verizon.net) Received: from vms244.mailsrvcs.net ([172.18.12.134]) by vms173019.mailsrvcs.net (Sun Java(tm) System Messaging Server 6.3-7.04 (built Sep 26 2008; 32bit)) with ESMTPA id <0KHD00JO4D3PU849@vms173019.mailsrvcs.net> for freebsd-current@FreeBSD.org; Tue, 31 Mar 2009 06:55:01 -0500 (CDT) Received: from 96.234.43.209 ([96.234.43.209]) by vms244.mailsrvcs.net (Verizon Webmail) with HTTP; Tue, 31 Mar 2009 06:55:01 -0500 (CDT) Date: Tue, 31 Mar 2009 06:55:01 -0500 (CDT) From: Sergey Babkin To: srinivasg@esntechnologies.co.in Message-id: <1762266444.173443.1238500501801.JavaMail.root@vms244.mailsrvcs.net> Content-transfer-encoding: quoted-printable X-Originating-IP: [96.234.43.209] X-Mailman-Approved-At: Tue, 31 Mar 2009 13:10:22 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-current@FreeBSD.org Subject: FreeBSD libthr on Redhat 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, 31 Mar 2009 11:55:13 -0000 No, you can not use the libthr from FreeBSD on Linux. You would not be = able to even compile it if you try, since it requires the kernel support= that is not available on Linux. For portability to different OSes, pthr= eads is your only choice. And there really should not be that much perfo= rmance difference anyway. BTW, for better luck with posting to the m= ailing lists, please write something sensible into the Subject field.Emp= ty or weird subject probably triggers the spam filter. -SB Ma= r 31, 2009 01:11:27 AM, [1]srinivasg@esntechnologies.co.in= wrote: Dear All, I am not able to post any message to the [2]freebsd-hackers@freebsd.org ID. When I post a message, I did= not get any error. However, I am able to receive the messages from all = of you. So, I am sending this message to you individually. Please, my re= quest is to forward this to the list. I have written an application = where I have used the libpthread library for creating the pthreads. Howe= ver, to get the maximum optimization, I want to use the libthr.a library= instead of libpthread library. However, when I tried to use on my Redha= t box, I end up with following errors. ../lib/linux/libthr.a(thr_sem= .o): In function `_sem_init': thr_sem.c:(.text+0x100): undefined referen= ce to `ksem_init' thr_sem.c:(.text+0x115): undefined reference to `ksem_= destroy' ../lib/linux/libthr.a(thr_sem.o): In function `_sem_destroy':thr_sem.c:(.text+0x216): undefined reference to `ksem_destroy' ../lib/= linux/libthr.a(thr_sem.o): In function `_sem_timedwait': thr_sem.c:(.tex= t+0x2ad): undefined reference to `ksem_timedwait' ../lib/linux/libthr.a(= thr_sem.o): In function `_sem_wait': .... .... .... collect= 2: ld returned 1 exit status make: *** [target] Error 1 I underst= and that the "ksem_init" is not available on the Redhat box. Then, I hav= e tried to use the libc.so.7 from FreeBSD. I have included the libc.so.7= in my application to getridof the above undefined references. Even thou= gh, I end up with the following errors. /usr/bin/ld: errno@@FBSD_1.0= : TLS definition in /lib/libc.so.6 section .tbss mismatches non-TLS defi= nition in ../lib/linux/libc.so section .bss /lib/libc.so.6: could not re= ad symbols: Bad value Here, the lib/libc.so.6 is a Redhat libc libra= ry where as ../lib/linux/libc.so is a FreeBSD library (libc.so.7). <= br>Is it possible to use the FreeBSD libthr.a library file on a Redhat L= inux box? Please let me know the whether it is possible to use the = libthr.a library on Redhat box or not. Thanks in advance. = With Regards, Srinivas G References 1. 3D"mailto:srinivasg@esntechnologies.co.in" 2. file://localhost/tmp/3D"mailt= From owner-freebsd-current@FreeBSD.ORG Tue Mar 31 13:55: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 AA61A1065675 for ; Tue, 31 Mar 2009 13:55:45 +0000 (UTC) (envelope-from gary.jennejohn@freenet.de) Received: from mout3.freenet.de (mout3.freenet.de [IPv6:2001:748:100:40::2:5]) by mx1.freebsd.org (Postfix) with ESMTP id 46D0F8FC17 for ; Tue, 31 Mar 2009 13:55:45 +0000 (UTC) (envelope-from gary.jennejohn@freenet.de) Received: from [195.4.92.23] (helo=13.mx.freenet.de) by mout3.freenet.de with esmtpa (ID gary.jennejohn@freenet.de) (port 25) (Exim 4.69 #79) id 1LoeRL-0003gQ-UH for freebsd-current@freebsd.org; Tue, 31 Mar 2009 15:55:44 +0200 Received: from tc973.t.pppool.de ([89.55.201.115]:52401 helo=ernst.jennejohn.org) by 13.mx.freenet.de with esmtpa (ID gary.jennejohn@freenet.de) (port 25) (Exim 4.69 #76) id 1LoeRL-0004bd-MQ for freebsd-current@freebsd.org; Tue, 31 Mar 2009 15:55:43 +0200 Date: Tue, 31 Mar 2009 15:55:42 +0200 From: Gary Jennejohn To: freebsd-current@freebsd.org Message-ID: <20090331155542.74d89d64@ernst.jennejohn.org> In-Reply-To: References: <95891.1238477069@critter.freebsd.dk> <20090331133132.1e191836@ernst.jennejohn.org> X-Mailer: Claws Mail 3.7.1 (GTK+ 2.14.7; amd64-portbld-freebsd8.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: Re: Removal of GEOM_BSD, GEOM_MBR, GEOM_PC98 and GEOM_SUNLABEL X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: gary.jennejohn@freenet.de List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Mar 2009 13:55:59 -0000 On Tue, 31 Mar 2009 14:56:54 +0200 Ivan Voras wrote: > Gary Jennejohn wrote: > > On Tue, 31 Mar 2009 05:24:29 +0000 > > "Poul-Henning Kamp" wrote: > > > >> In message , Marcel Moolenaar wri > >> tes: > >> > >>> I plan to remove the "old" partitioning GEOMs mentioned in the subject > >>> line some time this week. Let me know if any of these should remain for now > >>> due to issues with gpart. > >> Never mind gpart, but don't we have some guidelines for how long time > >> we leave stuff around before we rip it out ? > >> > > > > I have some disks which were partitioned before GEOM or gpart even > > existed. If this means that I can't use them any more I'll be very > > ticked off. > > No, the question is which GEOM class to use to parse the partition table :) > > gpart is new, shiny, but with some rough edges (most of which have been > polished by now), GEOM_xxx were the old classes. 8-CURRENT doesn't use > the old classes but they are still there if anyone needs them. > Well, that would be OK then, as long as I can still _use_ the old classes after the removal of the various GEOM_XXX options. --- Gary Jennejohn From owner-freebsd-current@FreeBSD.ORG Tue Mar 31 13:58: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 E581510656D1 for ; Tue, 31 Mar 2009 13:58:48 +0000 (UTC) (envelope-from gary.jennejohn@freenet.de) Received: from mout3.freenet.de (mout3.freenet.de [IPv6:2001:748:100:40::2:5]) by mx1.freebsd.org (Postfix) with ESMTP id A457D8FC08 for ; Tue, 31 Mar 2009 13:58:48 +0000 (UTC) (envelope-from gary.jennejohn@freenet.de) Received: from [195.4.92.21] (helo=11.mx.freenet.de) by mout3.freenet.de with esmtpa (ID gary.jennejohn@freenet.de) (port 25) (Exim 4.69 #79) id 1LoeUK-0000LH-2r; Tue, 31 Mar 2009 15:58:48 +0200 Received: from tc973.t.pppool.de ([89.55.201.115]:49688 helo=ernst.jennejohn.org) by 11.mx.freenet.de with esmtpa (ID gary.jennejohn@freenet.de) (port 25) (Exim 4.69 #76) id 1LoeUJ-0000rC-LO; Tue, 31 Mar 2009 15:58:48 +0200 Date: Tue, 31 Mar 2009 15:58:46 +0200 From: Gary Jennejohn To: freebsd-current@freebsd.org Message-ID: <20090331155846.7022bb49@ernst.jennejohn.org> In-Reply-To: <1762266444.173443.1238500501801.JavaMail.root@vms244.mailsrvcs.net> References: <1762266444.173443.1238500501801.JavaMail.root@vms244.mailsrvcs.net> X-Mailer: Claws Mail 3.7.1 (GTK+ 2.14.7; amd64-portbld-freebsd8.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: Sergey Babkin Subject: Re: FreeBSD libthr on Redhat X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: gary.jennejohn@freenet.de List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Mar 2009 13:58:51 -0000 On Tue, 31 Mar 2009 06:55:01 -0500 (CDT) Sergey Babkin wrote: > No, you can not use the libthr from FreeBSD on Linux. You would not be > it if you try, since it requires the kernel support available on Linux. > For portability to different OSes, pthr there really > should not be that much perfo BTW, for better luck with posting to the m something sensible > into the Subject field.Emp spam filter. > -SB > Ma Actually, srinivasg@esntechnologies.co.in wrote the stuff below here. > Dear All, > I am not able to post any message to the > [2]freebsd-hackers@freebsd.org ID. > When I post a message, I did to > receive the messages from all message to > you individually. Please, my re list. > I have written an application library > for creating the pthreads. Howe optimization, I > want to use the libthr.a library However, > when I tried to use on my Redha errors. > ../lib/linux/libthr.a(thr_sem thr_sem.c:(.text+0x100): undefined referen thr_sem.c:(.text+0x115): undefined reference to `ksem_ ../lib/linux/libthr.a(thr_sem.o): In function > `_sem_destroy':thr_sem.c:(.text+0x216): undefined reference to > `ksem_destroy' > ../lib/ thr_sem.c:(.tex ../lib/linux/libthr.a( .... > .... > .... > collect make: *** [target] Error 1 > I underst box. > Then, I hav included > the libc.so.7 references. Even thou /usr/bin/ld: errno@@FBSD_1.0 section > .tbss mismatches non-TLS defi section .bss > /lib/libc.so.6: could not re Here, the lib/libc.so.6 is a Redhat libc libra ../lib/linux/libc.so is a FreeBSD library (libc.so.7). > < Redhat > L Please let me know the whether it is possible to use the library on Redhat box or not. > Thanks in advance. > Srinivas G > > > References > > 1. 3D"mailto:srinivasg@esntechnologies.co.in" > 2. file://localhost/tmp/3D"mailt_______________________________________________ The formatting of your e-mails is totally fubar, which makes it very diffcult to read them. --- Gary Jennejohn From owner-freebsd-current@FreeBSD.ORG Tue Mar 31 15:03: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 23E911065776; Tue, 31 Mar 2009 15:03:41 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id E46948FC14; Tue, 31 Mar 2009 15:03:40 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from server.baldwin.cx (pool-98-109-39-197.nwrknj.fios.verizon.net [98.109.39.197]) by cyrus.watson.org (Postfix) with ESMTPSA id 92AA046B17; Tue, 31 Mar 2009 11:03:40 -0400 (EDT) Received: from localhost (john@localhost [127.0.0.1]) (authenticated bits=0) by server.baldwin.cx (8.14.3/8.14.3) with ESMTP id n2VF3Na2032302; Tue, 31 Mar 2009 11:03:34 -0400 (EDT) (envelope-from jhb@freebsd.org) From: John Baldwin To: freebsd-current@freebsd.org Date: Tue, 31 Mar 2009 10:45:26 -0400 User-Agent: KMail/1.9.7 References: <1236802980.00085518.1236789602@10.7.7.3> <1238498590.00094580.1238487605@10.7.7.3> <49D1FEAE.4050006@FreeBSD.org> In-Reply-To: <49D1FEAE.4050006@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200903311045.27391.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (server.baldwin.cx [127.0.0.1]); Tue, 31 Mar 2009 11:03:35 -0400 (EDT) X-Virus-Scanned: ClamAV 0.94.2/9186/Tue Mar 31 05:51:33 2009 on server.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-4.4 required=4.2 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.1.3 X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on server.baldwin.cx Cc: Alexander Motin , Gustavo Perez Querol , Jung-uk Kim Subject: Re: [HEADSUP] amd64 suspend/resume code to be comitted 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, 31 Mar 2009 15:03:41 -0000 On Tuesday 31 March 2009 7:29:50 am Alexander Motin wrote: > Gustavo Perez Querol wrote: > > Finally report that kldloading if_bge after resume doesn't make the card > > work. Making pciconf -lv shows the card, but no driver attaches to the > > card. > > My bge suspends fine without unloading and works fine after resume. > > bge0@pci0:4:0:0: class=0x020000 card=0x011b1025 chip=0x169314e4 > rev=0x02 hdr=0x00 It probably depends on the card. I used to have an HP nc6220 and it's bge0 would lose its mind after resume. I tried adding code to reset the phy on resume but that didn't help. The Linux tg3 driver actually has a good bit of code to manage suspend / resume. -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Tue Mar 31 15:03: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 8BFA3106570D for ; Tue, 31 Mar 2009 15:03:47 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 4AA5F8FC12 for ; Tue, 31 Mar 2009 15:03:47 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from server.baldwin.cx (pool-98-109-39-197.nwrknj.fios.verizon.net [98.109.39.197]) by cyrus.watson.org (Postfix) with ESMTPSA id CD64E46B58; Tue, 31 Mar 2009 11:03:46 -0400 (EDT) Received: from localhost (john@localhost [127.0.0.1]) (authenticated bits=0) by server.baldwin.cx (8.14.3/8.14.3) with ESMTP id n2VF3Na3032302; Tue, 31 Mar 2009 11:03:41 -0400 (EDT) (envelope-from jhb@freebsd.org) From: John Baldwin To: barney_cordoba@yahoo.com Date: Tue, 31 Mar 2009 10:55:47 -0400 User-Agent: KMail/1.9.7 References: <105551.54281.qm@web63901.mail.re1.yahoo.com> In-Reply-To: <105551.54281.qm@web63901.mail.re1.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200903311055.48136.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (server.baldwin.cx [127.0.0.1]); Tue, 31 Mar 2009 11:03:41 -0400 (EDT) X-Virus-Scanned: ClamAV 0.94.2/9186/Tue Mar 31 05:51:33 2009 on server.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-4.4 required=4.2 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.1.3 X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on server.baldwin.cx Cc: freebsd-current@freebsd.org Subject: Re: pci_alloc_resource is broken 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, 31 Mar 2009 15:03:47 -0000 On Monday 30 March 2009 6:18:24 pm Barney Cordoba wrote: > I dunno, but its pretty lame that you can't read a register on a card > without hacking the kernel. The entire point of having a generic bus > management system is to create a relatively transparent mechanism for > accessing such resources, but then if you try to share a resource > you find out that the system doesn't support shared resources and > requires proprietary hacking of the drivers. Most OS's tend to assume that a single driver is all that is needed for a single PCI function. Windows does allow filter drivers which you could use to have multiple drivers for a given PCI function. In FreeBSD we only allow you to have one. However, you are free to have your "one" driver actually be a virtual bus that allows for multiple leaf drivers. You can look at sys/dev/pci/vga_pci.c for an example of this. It allows drm, acpi_video, and agp to all attach to a VGA adapter. It even allows sharing of the BARs so the different sub-drivers can each allocate the BAR and use it. If you have designed your hardware such that it places multiple logical functions into a single PCI function (rather than having a separate PCI function for each logical function) then you can take the bus approach. You can even have both the virtual bus driver and the NIC driver "open" and the magic frobnitz driver in a binary foo.ko if you want. > We don't want to have to make the > ethernet functionality "proprietary" or required to be obtained from > a static source. So if some dude in Pakistan wants to grab a bug fix > he can do it without whining to the vendor that the code is proprietary, > thus burdening the vendor to re-hack every iteration of code that some > customer in some corner of the world wants to run for one reason or > another. The alternative is telling the customer that he can't have the > bug fix until the vendor gets around to releasing a version that has the > latest patch. It doesn't have to run on other OSes. Its a logistic issue. > Its a matter of streamlining the work flow. Having separate drivers > makes upgrading easier. You don't have to hack 37 source files every time > you decide to grab a -stable because some dude at freebsd.org decided to > change a macro. Are you getting this? You need more "commercial" experience because some "commercial" OS's are worse about changing macros than FreeBSD is. :) A word of advice: your condescending tone is not going to win you any friends or get your questions answered any sooner. Quite the contrary in fact. > As a side issue, the number of panics I found along the way is a bit > alarming. Its pretty lazy coding. Panic should really only be called > when a condition is unrecoverable; not every time someone doesn't feel > like writing the couple of lines of code to handle the condition. To be honest, in the case of device drivers it can be helpful to make the system panic more easily since many of them are lazy about checking return values from functions (I've had to deal with several out-of-tree drivers). Also, FWIW, other bus devices do panic in this particular case. The fact that PCI doesn't panic in 5.x - 7.x is actually due to a bug (resulting in the aforementioned resource leak) that I fixed in 8. > Is the kernel memory leaked on each access, or is there > some leakage on allocation and release only? I can live with a static > chunk lost, but not if its a continuous thing. Just on allocation. However, I think your longer term solution that fits into what "new-bus" wants for having multiple drivers share a single device is to make a virtual bus device. -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Tue Mar 31 16:01: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 82BB71065673 for ; Tue, 31 Mar 2009 16:01:03 +0000 (UTC) (envelope-from xcllnt@mac.com) Received: from asmtpout013.mac.com (asmtpout013.mac.com [17.148.16.88]) by mx1.freebsd.org (Postfix) with ESMTP id 6C4F48FC17 for ; Tue, 31 Mar 2009 16:01:03 +0000 (UTC) (envelope-from xcllnt@mac.com) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Received: from MacBook-Pro.lan.xcllnt.net (mail.xcllnt.net [75.101.29.67]) by asmtp013.mac.com (Sun Java(tm) System Messaging Server 6.3-8.01 (built Dec 16 2008; 32bit)) with ESMTPSA id <0KHD00E8TOHJVE50@asmtp013.mac.com> for freebsd-current@freebsd.org; Tue, 31 Mar 2009 09:00:56 -0700 (PDT) Message-id: <60084D1E-9F64-463A-A8E9-7A237D5C7661@mac.com> From: Marcel Moolenaar To: gary.jennejohn@freenet.de In-reply-to: <20090331155542.74d89d64@ernst.jennejohn.org> Date: Tue, 31 Mar 2009 09:00:55 -0700 References: <95891.1238477069@critter.freebsd.dk> <20090331133132.1e191836@ernst.jennejohn.org> <20090331155542.74d89d64@ernst.jennejohn.org> X-Mailer: Apple Mail (2.930.3) Cc: freebsd-current@freebsd.org Subject: Re: Removal of GEOM_BSD, GEOM_MBR, GEOM_PC98 and GEOM_SUNLABEL 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, 31 Mar 2009 16:01:04 -0000 On Mar 31, 2009, at 6:55 AM, Gary Jennejohn wrote: >>> >>> I have some disks which were partitioned before GEOM or gpart even >>> existed. If this means that I can't use them any more I'll be very >>> ticked off. >> >> No, the question is which GEOM class to use to parse the partition >> table :) >> >> gpart is new, shiny, but with some rough edges (most of which have >> been >> polished by now), GEOM_xxx were the old classes. 8-CURRENT doesn't >> use >> the old classes but they are still there if anyone needs them. >> > > Well, that would be OK then, as long as I can still _use_ the old > classes > after the removal of the various GEOM_XXX options. Why do you want to use the old classes when gpart can be used? BTW: it was my intention to remove the source files along with the options. So you wouldn't be able to use the old classes. FYI, -- Marcel Moolenaar xcllnt@mac.com From owner-freebsd-current@FreeBSD.ORG Tue Mar 31 16:10:49 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 23D131065670 for ; Tue, 31 Mar 2009 16:10:49 +0000 (UTC) (envelope-from xcllnt@mac.com) Received: from asmtpout020.mac.com (asmtpout020.mac.com [17.148.16.95]) by mx1.freebsd.org (Postfix) with ESMTP id 108268FC13 for ; Tue, 31 Mar 2009 16:10:48 +0000 (UTC) (envelope-from xcllnt@mac.com) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Received: from MacBook-Pro.lan.xcllnt.net (mail.xcllnt.net [75.101.29.67]) by asmtp020.mac.com (Sun Java(tm) System Messaging Server 6.3-8.01 (built Dec 16 2008; 32bit)) with ESMTPSA id <0KHD00ELFOXQ4420@asmtp020.mac.com> for current@freebsd.org; Tue, 31 Mar 2009 09:10:39 -0700 (PDT) Message-id: <034B39EF-524B-44F1-9E85-D6FB96F8D56F@mac.com> From: Marcel Moolenaar To: Poul-Henning Kamp In-reply-to: <95891.1238477069@critter.freebsd.dk> Date: Tue, 31 Mar 2009 09:10:37 -0700 References: <95891.1238477069@critter.freebsd.dk> X-Mailer: Apple Mail (2.930.3) Cc: FreeBSD current mailing list Subject: Re: Removal of GEOM_BSD, GEOM_MBR, GEOM_PC98 and GEOM_SUNLABEL 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, 31 Mar 2009 16:10:49 -0000 On Mar 30, 2009, at 10:24 PM, Poul-Henning Kamp wrote: > In message , Marcel > Moolenaar wri > tes: > >> I plan to remove the "old" partitioning GEOMs mentioned in the >> subject >> line some time this week. Let me know if any of these should remain >> for now >> due to issues with gpart. > > Never mind gpart, but don't we have some guidelines for how long time > we leave stuff around before we rip it out ? I took USB as a precedent. -- Marcel Moolenaar xcllnt@mac.com From owner-freebsd-current@FreeBSD.ORG Tue Mar 31 17:55: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 F2E49106567A for ; Tue, 31 Mar 2009 17:55:27 +0000 (UTC) (envelope-from barney_cordoba@yahoo.com) Received: from web63906.mail.re1.yahoo.com (web63906.mail.re1.yahoo.com [69.147.97.121]) by mx1.freebsd.org (Postfix) with SMTP id B05FA8FC1E for ; Tue, 31 Mar 2009 17:55:27 +0000 (UTC) (envelope-from barney_cordoba@yahoo.com) Received: (qmail 84287 invoked by uid 60001); 31 Mar 2009 17:55:27 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1238522127; bh=uyUZbh/zgDR3TmIm0YpYKl/dn74D9/fwia4wajMlusY=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=SDo2GAdkhuEZb9mbAHcafQJMqiZz/OD4GYue86F2I/SyxFh9KJbjYrVdCLZKFDFelcTUm7XdYzflOrHM6INHOoCS6GBejYbuOG2hb6iJJWlbJIJ6bZ9x/7fs5BI4jkXvO624t7PsqSqv0iH8Z8ujawVYy03BqIOHuLcqWXBV+lE= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=ppmTN5tTw8A6EciPOSBKWZWAb3NW1pNlLCrBqy56pc/rpZatmdoKS6R1WL3HmUlueyg1fremRAkWNey2Gx6yUpM9/Kfs4kbhHruNhYz2BZWAlS4Pxp8aHAK8nUErPfQ3a2QRuoL6VUxNHEGuFI8Yzq3e6N9Mn9GreRHll5GjGwI=; Message-ID: <208477.83685.qm@web63906.mail.re1.yahoo.com> X-YMail-OSG: yltjcWUVM1mVTKdmxcdhVF_XZ7Xoakm4HeQ6MpAwG6DfgaiTB2cZnTgxgtzAINjKiLRjctTWGduOXQIxaAMrvqP2dgxEqVBEf7ApnqgtFNnif71UUbo9CMNVI9IB8BhEKgHx4eVXA8J3V7mFWWhfGDMvRxJm.c2Qna4fvcKwZ5__STKRx6YsusaC8KFMnCo9V8gssEG.G7TCKCNJLxgIw76HBi_WaAnCk8qNvZMNN08T3j0ikQXGxqBUvYF3dVKIu43lFuBUgDXYKkIbGQ3FqmJtIbXDUjGBuRt6wf2j3bR757Zm56gcfYUW4up3zU0MIKhUQt__3rP1NckxdlP97YVqMtf4SjKx6g-- Received: from [98.242.222.229] by web63906.mail.re1.yahoo.com via HTTP; Tue, 31 Mar 2009 10:55:26 PDT X-Mailer: YahooMailWebService/0.7.289.1 Date: Tue, 31 Mar 2009 10:55:26 -0700 (PDT) From: Barney Cordoba To: John Baldwin In-Reply-To: <200903311055.48136.jhb@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: freebsd-current@freebsd.org Subject: Re: pci_alloc_resource is broken X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: barney_cordoba@yahoo.com List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Mar 2009 17:55:28 -0000 --- On Tue, 3/31/09, John Baldwin wrote: > From: John Baldwin > Subject: Re: pci_alloc_resource is broken > To: barney_cordoba@yahoo.com > Cc: freebsd-current@freebsd.org > Date: Tuesday, March 31, 2009, 10:55 AM > On Monday 30 March 2009 6:18:24 pm Barney Cordoba wrote: > > I dunno, but its pretty lame that you can't read a > register on a card > > without hacking the kernel. The entire point of having > a generic bus > > management system is to create a relatively > transparent mechanism for > > accessing such resources, but then if you try to share > a resource > > you find out that the system doesn't support > shared resources and > > requires proprietary hacking of the drivers. > > Most OS's tend to assume that a single driver is all > that is needed for a > single PCI function. Windows does allow filter drivers > which you could use > to have multiple drivers for a given PCI function. In > FreeBSD we only allow > you to have one. However, you are free to have your > "one" driver actually be > a virtual bus that allows for multiple leaf drivers. You > can look at > sys/dev/pci/vga_pci.c for an example of this. It allows > drm, acpi_video, and > agp to all attach to a VGA adapter. It even allows sharing > of the BARs so > the different sub-drivers can each allocate the BAR and use > it. If you have > designed your hardware such that it places multiple logical > functions into a > single PCI function (rather than having a separate PCI > function for each > logical function) then you can take the bus approach. You > can even have both > the virtual bus driver and the NIC driver "open" > and the magic frobnitz > driver in a binary foo.ko if you want. > > > We don't want to have to make the > > ethernet functionality "proprietary" or > required to be obtained from > > a static source. So if some dude in Pakistan wants to > grab a bug fix > > he can do it without whining to the vendor that the > code is proprietary, > > thus burdening the vendor to re-hack every iteration > of code that some > > customer in some corner of the world wants to run for > one reason or > > another. The alternative is telling the customer that > he can't have the > > bug fix until the vendor gets around to releasing a > version that has the > > latest patch. It doesn't have to run on other > OSes. Its a logistic issue. > > Its a matter of streamlining the work flow. Having > separate drivers > > makes upgrading easier. You don't have to hack 37 > source files every time > > you decide to grab a -stable because some dude at > freebsd.org decided to > > change a macro. Are you getting this? > > You need more "commercial" experience because > some "commercial" OS's are worse > about changing macros than FreeBSD is. :) A word of > advice: your > condescending tone is not going to win you any friends or > get your questions > answered any sooner. Quite the contrary in fact. Its really you who is being condescending. You're trying to justify bad coding by telling someone who has been in business for 20 years with 3000 active customers that he needs more commercial experience. If you were Bill Gates I'd accept that. But you're a programmer. Perhaps your idea of "commercial" is the Apple API. Commercial means not a toy. Not in a lab. People using your OS to earn a living. To feed their families. When an ISP's FreeBSD router panics it might cost him business; perhaps his livelihood. Try to be a bit less flippant about things. > As a side issue, the number of panics I found along > the way is a bit > > alarming. Its pretty lazy coding. Panic should really > only be called > > when a condition is unrecoverable; not every time > someone doesn't feel > > like writing the couple of lines of code to handle the > condition. > > To be honest, in the case of device drivers it can be > helpful to make the > system panic more easily since many of them are lazy about > checking return > values from functions (I've had to deal with several > out-of-tree drivers). > Also, FWIW, other bus devices do panic in this particular > case. The fact > that PCI doesn't panic in 5.x - 7.x is actually due to > a bug (resulting in > the aforementioned resource leak) that I fixed in 8. It can be helpful if you live in a lab. Here's what the man page for bus_alloc_resource says: "A pointer to struct resource is returned on success, a null pointer otherwise." Here is what the man page for panic says: "panic -- bring down system on fatal error" Now is a resource in use a "fatal" system error? Is falling into resource_list_alloc() when you know that the resource list exists quality coding? Face it please. You replaced one bug with another. If you spent half the effort doing it correctly as you are spending defending what you've done we'd all be a lot happier. Barney From owner-freebsd-current@FreeBSD.ORG Tue Mar 31 18:34: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 2189B1065670 for ; Tue, 31 Mar 2009 18:34:00 +0000 (UTC) (envelope-from olivier@gid0.org) Received: from mail-bw0-f164.google.com (mail-bw0-f164.google.com [209.85.218.164]) by mx1.freebsd.org (Postfix) with ESMTP id 85A6A8FC22 for ; Tue, 31 Mar 2009 18:33:59 +0000 (UTC) (envelope-from olivier@gid0.org) Received: by bwz8 with SMTP id 8so2408340bwz.43 for ; Tue, 31 Mar 2009 11:33:58 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.109.199 with SMTP id k7mr5362892fap.45.1238524438187; Tue, 31 Mar 2009 11:33:58 -0700 (PDT) Date: Tue, 31 Mar 2009 20:33:58 +0200 Message-ID: <367b2c980903311133v37833cabla4934f8b1a9b5e15@mail.gmail.com> From: Olivier SMEDTS To: freebsd-current Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: strange UFS labels behaviour 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, 31 Mar 2009 18:34:00 -0000 Hi, Since UFS labels were introduced, I've got strange behaviour when fsck-ing or mounting my UFS partitions. Here is the console output at boot : GEOM_LABEL: Label for provider ad0s4 is ext2fs/PH4T. GEOM_LABEL: Label for provider ad0s1a is ufsid/4867d45fa24cf28b. GEOM_LABEL: Label for provider ad0s1d is ufsid/4867d45fd76f0998. GEOM_LABEL: Label for provider ad0s1e is ufsid/4867d45fd3972203. GEOM_LABEL: Label for provider ad0s1f is ufsid/4867d45f6ac00d3f. GEOM_LABEL: Label for provider ad0s1g is ufsid/4867d45f91eb4111. GEOM_LABEL: Label for provider ad0s3a is ufsid/48b16a479410599a. Root mount waiting for: usbus7 usbus6 usbus5 usbus4 usbus3 usbus2 usbus1 usbus0 [snip] Trying to mount root from ufs:/dev/ad0s1a ugen5.2: at usbus5 ugen6.2: at usbus6 GEOM_LABEL: Label ufsid/4867d45fa24cf28b removed. ums0: on usbus6 GEOM_LABEL: Label for provider ad0s1a is ufsid/4867d45fa24cf28b. ums0: 5 buttons and [XYZ] coordinates GEOM_LABEL: Label ufsid/4867d45fd76f0998 removed. GEOM_LABEL: Label for provider ad0s1d is ufsid/4867d45fd76f0998. GEOM_LABEL: Label ufsid/4867d45fd3972203 removed. GEOM_LABEL: Label for provider ad0s1e is ufsid/4867d45fd3972203. GEOM_LABEL: Label ufsid/4867d45f6ac00d3f removed. GEOM_LABEL: Label for provider ad0s1f is ufsid/4867d45f6ac00d3f. GEOM_LABEL: Label ufsid/4867d45f91eb4111 removed. GEOM_LABEL: Label for provider ad0s1g is ufsid/4867d45f91eb4111. GEOM_LABEL: Label ufsid/48b16a479410599a removed. GEOM_LABEL: Label for provider ad0s3a is ufsid/48b16a479410599a. WARNING: TMPFS is considered to be a highly experimental feature in FreeBSD. GEOM_LABEL: Label ufsid/4867d45fd76f0998 removed. GEOM_LABEL: Label ufsid/4867d45f6ac00d3f removed. GEOM_LABEL: Label ufsid/4867d45f91eb4111 removed. Notice the removal of UFS labels (the first removals appear during "fsck -p" and the latter during mount). Then, in multi or single user, here is what I've got when remounting read-write or read-only (my root partition is mounted read-only at boot) : [20:19] root@q 167 ~# mount -u -o rw / GEOM_LABEL: Label ufsid/4867d45fa24cf28b removed. [20:19] root@q 169 ~# mount -u -o ro / GEOM_LABEL: Label for provider ad0s1a is ufsid/4867d45fa24cf28b. [20:19] root@q 170 ~# ll /dev/ufsid/ total 1 145 dr-xr-xr-x 2 root wheel - 512 31 mar 20:08 ./ 2 dr-xr-xr-x 8 root wheel - 512 31 mar 20:08 ../ 153 crw-r----- 1 root operator - 0, 153 31 mar 20:18 4867d45fa24cf28b 120 crw-r----- 1 root operator - 0, 120 31 mar 20:08 4867d45fd3972203 123 crw-r----- 1 root operator - 0, 123 31 mar 20:08 48b16a479410599a [20:20] root@q 171 ~# mount /dev/ad0s1a on / (ufs, local, read-only) devfs on /dev (devfs, local) tmpfs on /tmp (tmpfs, local) /dev/ad0s1d on /var (ufs, local, soft-updates) /dev/ad0s1e on /usr/local (ufs, local, noatime, read-only) /dev/ad0s1f on /usr/home (ufs, local, soft-updates) /dev/ad0s1g on /work (ufs, local, soft-updates) /dev/ad0s3a on /data (ufs, local, noatime, read-only) [20:23] root@q 176 ~# kldstat | grep geom 4 1 0xffffffff807bf000 7cf8 geom_label.ko 29 1 0xffffffff80a6d000 4fb8 geom_part_gpt.ko [20:23] root@q 177 ~# uname -a FreeBSD q.gid0.org 8.0-CURRENT FreeBSD 8.0-CURRENT #0 r190594M: Tue Mar 31 19:10:02 CEST 2009 root@q.gid0.org:/work/obj/work/src/sys/QUAD amd64 Is this expected ? -- Olivier Smedts _ ASCII ribbon campaign ( ) e-mail: olivier@gid0.org - against HTML email & vCards X www: http://www.gid0.org - against proprietary attachments / \ "Il y a seulement 10 sortes de gens dans le monde : ceux qui comprennent le binaire, et ceux qui ne le comprennent pas." From owner-freebsd-current@FreeBSD.ORG Tue Mar 31 18:44: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 04FE1106564A for ; Tue, 31 Mar 2009 18:44:37 +0000 (UTC) (envelope-from gb@unistra.fr) Received: from mailhost.u-strasbg.fr (mailhost.u-strasbg.fr [130.79.200.156]) by mx1.freebsd.org (Postfix) with ESMTP id 896FA8FC0C for ; Tue, 31 Mar 2009 18:44:36 +0000 (UTC) (envelope-from gb@unistra.fr) Received: from 6nq.u-strasbg.fr (mojito.u-strasbg.fr [IPv6:2001:660:4701:1002::3]) by mailhost.u-strasbg.fr (8.14.2/jtpda-5.5pre1) with ESMTP id n2VHfYGf079569 for ; Tue, 31 Mar 2009 19:41:34 +0200 (CEST) Received: by 6nq.u-strasbg.fr (Postfix, from userid 1001) id 8E7CD7537; Tue, 31 Mar 2009 19:39:40 +0200 (CEST) Date: Tue, 31 Mar 2009 19:39:40 +0200 From: Guy Brand To: freebsd-current@freebsd.org Message-ID: <20090331173940.GA77198@unistra.fr> References: <200903111233.14029.jkim@FreeBSD.org> <3a142e750903291518x7f941c6ai6b27fae1472a9137@mail.gmail.com> <200903301248.42966.jkim@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-15 Content-Disposition: inline In-Reply-To: <200903301248.42966.jkim@FreeBSD.org> Organization: Direction Informatique, =?iso-8859-15?Q?Un?= =?iso-8859-15?Q?iversit=E9?= de Strasbourg, France x-gpg-fingerprint: B423 4924 012E 52F3 BA9E 547F CC8C 0BC5 9C0E B1CA x-gpg-key: 9C0EB1CA User-Agent: Mutt/1.5.19 (2009-01-05) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.0.1 (mailhost.u-strasbg.fr [IPv6:2001:660:2402::156]); Tue, 31 Mar 2009 19:41:34 +0200 (CEST) X-Virus-Scanned: ClamAV 0.94.2/9187/Tue Mar 31 17:28:21 2009 on mr6.u-strasbg.fr X-Virus-Status: Clean X-Spam-Status: No, score=-100.0 required=5.0 tests=NO_RELAYS, USER_IN_WHITELIST autolearn=disabled version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on mr6.u-strasbg.fr Subject: Re: [HEADSUP] amd64 suspend/resume code to be comitted 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, 31 Mar 2009 18:44:37 -0000 Jung-uk Kim (jkim@freebsd.org) on 30/03/2009 at 12:48 wrote: Hello, > I wish I had some free time... > Thanks for the feed back! bug ~# uname -vm | sed "s/ *root@.*\// /" FreeBSD 8.0-CURRENT #0: Sun Mar 29 20:26:17 CEST 2009 GENERIC amd64 bug ~# fgrep acpi: /var/log/messages Mar 31 18:43:17 6nq acpi: suspend at 20090331 18:43:17 Mar 31 18:45:33 6nq acpi: resumed at 20090331 18:45:33 This is a success feedback report. Thanks to your work, my Lenovo X61s suspends and resumes without any trouble (including X on Intel GM965). Loaded modules: i915, drm, snd_hda, coretemp + zfs and wpi related. None of it needs unloading/reloading. All resume properly. Additional information is available if you wish. Thanks again. -- bug From owner-freebsd-current@FreeBSD.ORG Tue Mar 31 19:02: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 272591065672; Tue, 31 Mar 2009 19:02:27 +0000 (UTC) (envelope-from peterjeremy@optushome.com.au) Received: from mail17.syd.optusnet.com.au (mail17.syd.optusnet.com.au [211.29.132.198]) by mx1.freebsd.org (Postfix) with ESMTP id A596A8FC28; Tue, 31 Mar 2009 19:02:26 +0000 (UTC) (envelope-from peterjeremy@optushome.com.au) Received: from server.vk2pj.dyndns.org (c122-106-216-167.belrs3.nsw.optusnet.com.au [122.106.216.167]) by mail17.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id n2VJ2Nfd032728 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 1 Apr 2009 06:02:24 +1100 X-Bogosity: Ham, spamicity=0.000000 Received: from server.vk2pj.dyndns.org (localhost.vk2pj.dyndns.org [127.0.0.1]) by server.vk2pj.dyndns.org (8.14.3/8.14.3) with ESMTP id n2VJ2MqL007538; Wed, 1 Apr 2009 06:02:22 +1100 (EST) (envelope-from peter@server.vk2pj.dyndns.org) Received: (from peter@localhost) by server.vk2pj.dyndns.org (8.14.3/8.14.3/Submit) id n2VJ2MU3007537; Wed, 1 Apr 2009 06:02:22 +1100 (EST) (envelope-from peter) Date: Wed, 1 Apr 2009 06:02:22 +1100 From: Peter Jeremy To: Maxim Sobolev Message-ID: <20090331190222.GA2816@server.vk2pj.dyndns.org> References: <11609492.9579.1238167614335.JavaMail.root@vms070.mailsrvcs.net> <49CD0405.1060704@samsco.org> <49CD30E9.7030501@elischer.org> <49CEC261.4010803@freebsd.org> <20090329182219.GC38985@server.vk2pj.dyndns.org> <49D1725A.1020005@FreeBSD.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="82I3+IH0IqGh5yIs" Content-Disposition: inline In-Reply-To: <49D1725A.1020005@FreeBSD.org> X-PGP-Key: http://members.optusnet.com.au/peterjeremy/pubkey.asc User-Agent: Mutt/1.5.19 (2009-01-05) Cc: freebsd-hackers@FreeBSD.org, freebsd-current@FreeBSD.org, David Xu , prashant.vaibhav@gmail.com Subject: Re: Improving the kernel/i386 timecounter performance (GSoC proposal) 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, 31 Mar 2009 19:02:28 -0000 --82I3+IH0IqGh5yIs Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 2009-Mar-30 18:45:30 -0700, Maxim Sobolev wrote: >You don't really need to do it on every execve() unconditionally. It=20 >could be done on demand in libc, so that only when thread pass certain=20 >threshold, the "common page optimization code" kicks in and does its=20 >open/mmap/etc magic. Otherwise, "normal" syscall is performed. This "optimisation" is premature. First step is to implement an approach that always maps (or whatever) the data and then gather some information about its overheads in the real world. If they are deemed excessive, only then do we start looking at how to improve things. And IMO, the first step would be to lazily map the page - so it's not mapped by default but mapped the first time any of the information in it is used. >that for example gettimeofday() only gets optimized if threads calls it=20 >more frequently that 1 call/sec. Whilst this thread started talking about timecounters, once you have a shared page, there is a variety of other information that could be exported - PID being the most obvious. If the page is exported as code rather than data (as has been suggested) then you also have the possibility of exporting CPU-dependent optimised versions of some library functions (ala Solaris). The more stuff you export, the less you gain from supporting an export threshold. On 2009-Mar-30 18:31:06 -0700, Maxim Sobolev wrote: >It's not that easy, unless you can pin thread to a specific core before=20 >reading that page. I.e. imagine the case when your thread reads per-cpu=20 >page, get preempted and scheduled to a different core, then executes=20 >RDTSC there, still thinking it got TSC reading from the first core. Even= =20 >if it does re-read from that page again after reading TSC to determine=20 >if he has read the correct TSC, still it's possible (though not very=20 >likely) that it has been preempted again and scheduled to the first core= =20 >after reading the TSC. Good point. If you export code, rather than data, then the scheduler can just special-case threads where the return address is inside the magic page (this is a fairly cheap test and only needs to occur once you have decided to re-schedule that thread - so you are already in the "expensive" part of the scheduler and a few more instructions won't be noticable there). The most obvious approach would be to temporarily pin the thread whilst it's executing inside that page. --=20 Peter Jeremy --82I3+IH0IqGh5yIs Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.10 (FreeBSD) iEYEARECAAYFAknSaL4ACgkQ/opHv/APuIedoQCgipQ73bAx0NBwiaR5iZApBWgB GIkAn3H7KyYKduqSfyGKrWD126pk/lyO =xNgP -----END PGP SIGNATURE----- --82I3+IH0IqGh5yIs-- From owner-freebsd-current@FreeBSD.ORG Tue Mar 31 20:06:23 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 03B131065701 for ; Tue, 31 Mar 2009 20:06:23 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) by mx1.freebsd.org (Postfix) with ESMTP id BABD28FC1A for ; Tue, 31 Mar 2009 20:06:22 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (critter.freebsd.dk [192.168.61.3]) by phk.freebsd.dk (Postfix) with ESMTP id A0D9D78CCC; Tue, 31 Mar 2009 20:06:21 +0000 (UTC) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.14.3/8.14.3) with ESMTP id n2VK6KwS000974; Tue, 31 Mar 2009 20:06:20 GMT (envelope-from phk@critter.freebsd.dk) To: Garrett Wollman From: "Poul-Henning Kamp" In-Reply-To: Your message of "Tue, 31 Mar 2009 16:04:16 -0400." <200903312004.n2VK4G9s077941@hergotha.csail.mit.edu> Date: Tue, 31 Mar 2009 20:06:20 +0000 Message-ID: <973.1238529980@critter.freebsd.dk> Sender: phk@critter.freebsd.dk Cc: current@freebsd.org Subject: Re: New rc.d/named features for testing: auto-forwarding and wait on boot 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, 31 Mar 2009 20:06:24 -0000 In message <200903312004.n2VK4G9s077941@hergotha.csail.mit.edu>, Garrett Wollma n writes: >I'm not sure if this is fixed in more recent versions on ntpd. (I'm >also dubious that you'd really want to wait 3*MINPOLL for ntpd to >figure out what's going on before you finish booting, but that's more >an argument to have with Dave Mills.) I'm pretty sure everybody else than Dave Mills runs ntpdate before they start ntpd :-) -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From owner-freebsd-current@FreeBSD.ORG Tue Mar 31 20:38: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 A63EF1065687 for ; Tue, 31 Mar 2009 20:38:55 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from mail2.fluidhosting.com (mx22.fluidhosting.com [204.14.89.5]) by mx1.freebsd.org (Postfix) with ESMTP id 3F94C8FC0C for ; Tue, 31 Mar 2009 20:38:55 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: (qmail 10278 invoked by uid 399); 31 Mar 2009 20:38:52 -0000 Received: from localhost (HELO 192-168-15-100.nohostname) (dougb@dougbarton.us@127.0.0.1) by localhost with ESMTPAM; 31 Mar 2009 20:38:52 -0000 X-Originating-IP: 127.0.0.1 X-Sender: dougb@dougbarton.us Message-ID: <49D277B5.5040205@FreeBSD.org> Date: Tue, 31 Mar 2009 13:06:13 -0700 From: Doug Barton Organization: http://www.FreeBSD.org/ User-Agent: Thunderbird 2.0.0.21 (X11/20090321) MIME-Version: 1.0 To: Poul-Henning Kamp References: <96526.1238484035@critter.freebsd.dk> In-Reply-To: <96526.1238484035@critter.freebsd.dk> X-Enigmail-Version: 0.95.7 OpenPGP: id=D5B2F0FB Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: freebsd-current@FreeBSD.org Subject: Re: New rc.d/named features for testing: auto-forwarding and wait on boot 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, 31 Mar 2009 20:38:56 -0000 Poul-Henning Kamp wrote: > In message <49D1B261.6010406@FreeBSD.org>, Doug Barton writes: > >> There has been some discussion recently about the idea of adding an >> option for the rc.d startup process to wait until name resolution >> comes on line. (There is also room for a more general "wait for the >> network to come on line" option, but I chose to focus on the named >> version since my time is limited atm.) > > Maybe we need to do a more general mechanism, since many also > would like us to have confirmed the wall-clock-time via NTP before > we start anything that depends on it ? I am not opposed to that, I just don't have time to work on it. Doug -- This .signature sanitized for your protection From owner-freebsd-current@FreeBSD.ORG Tue Mar 31 20:39: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 30CD41065687 for ; Tue, 31 Mar 2009 20:39:15 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from mail2.fluidhosting.com (mx22.fluidhosting.com [204.14.89.5]) by mx1.freebsd.org (Postfix) with ESMTP id BCAC98FC0C for ; Tue, 31 Mar 2009 20:39:14 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: (qmail 10866 invoked by uid 399); 31 Mar 2009 20:39:08 -0000 Received: from localhost (HELO 192-168-15-100.nohostname) (dougb@dougbarton.us@127.0.0.1) by localhost with ESMTPAM; 31 Mar 2009 20:39:08 -0000 X-Originating-IP: 127.0.0.1 X-Sender: dougb@dougbarton.us Message-ID: <49D278BA.6070705@FreeBSD.org> Date: Tue, 31 Mar 2009 13:10:34 -0700 From: Doug Barton Organization: http://www.FreeBSD.org/ User-Agent: Thunderbird 2.0.0.21 (X11/20090321) MIME-Version: 1.0 To: Alexander Leidinger References: <49D1B261.6010406@FreeBSD.org> <20090331101454.16983mt8x4ru2xog@webmail.leidinger.net> In-Reply-To: <20090331101454.16983mt8x4ru2xog@webmail.leidinger.net> X-Enigmail-Version: 0.95.7 OpenPGP: id=D5B2F0FB Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: freebsd-current@FreeBSD.org Subject: Re: New rc.d/named features for testing: auto-forwarding and wait on boot 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, 31 Mar 2009 20:39:15 -0000 Alexander Leidinger wrote: > Quoting Doug Barton (from Mon, 30 Mar 2009 23:04:17 > -0700): > >> There has been some discussion recently about the idea of adding an >> option for the rc.d startup process to wait until name resolution >> comes on line. (There is also room for a more general "wait for the >> network to come on line" option, but I chose to focus on the named >> version since my time is limited atm.) > > I assume this is opt-in, and not on by default Careful reading of my post, or 2 seconds spent looking at the patch will answer this for you. > At which place in the startup would this wait? This would be answered by looking at the patch as well, but since I'm a nice guy I'll tell you that it waits right after named is started. On my system with essentially the default "local resolver" configuration plus a few things added the delay waiting for the host command to complete is almost unnoticeable. Doug -- This .signature sanitized for your protection From owner-freebsd-current@FreeBSD.ORG Tue Mar 31 20:39: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 4DE021065676 for ; Tue, 31 Mar 2009 20:39:35 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from mail2.fluidhosting.com (mx22.fluidhosting.com [204.14.89.5]) by mx1.freebsd.org (Postfix) with ESMTP id F225E8FC1F for ; Tue, 31 Mar 2009 20:39:34 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: (qmail 11658 invoked by uid 399); 31 Mar 2009 20:39:34 -0000 Received: from localhost (HELO 192-168-15-100.nohostname) (dougb@dougbarton.us@127.0.0.1) by localhost with ESMTPAM; 31 Mar 2009 20:39:34 -0000 X-Originating-IP: 127.0.0.1 X-Sender: dougb@dougbarton.us Message-ID: <49D27B95.7030209@FreeBSD.org> Date: Tue, 31 Mar 2009 13:22:45 -0700 From: Doug Barton Organization: http://www.FreeBSD.org/ User-Agent: Thunderbird 2.0.0.21 (X11/20090321) MIME-Version: 1.0 To: Mel Flynn References: <49D1B261.6010406@FreeBSD.org> <49D1B57F.8050903@FreeBSD.org> <200903311025.22219.mel.flynn+fbsd.current@mailing.thruhere.net> In-Reply-To: <200903311025.22219.mel.flynn+fbsd.current@mailing.thruhere.net> X-Enigmail-Version: 0.95.7 OpenPGP: id=D5B2F0FB Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: New rc.d/named features for testing: auto-forwarding and wait on boot 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, 31 Mar 2009 20:39:36 -0000 Mel Flynn wrote: > Hi Doug, > > On Tuesday 31 March 2009 08:17:35 Doug Barton wrote: > >>> In addition to enabling auto_forward you can also enable >>> auto_forward_only which changes from the default 'forward first' to >>> (you guessed it) 'forward only'. > >> And of course, the patch: >> http://dougbarton.us/Downloads/rcd-named.diff > > Snippet: > + if [ -z "$firstns" ]; then > + if [ ! "$nsip" = '127.0.0.1' ]; then > + echo 'nameserver 127.0.0.1' > + echo " ${nsip};" >> /var/run/auto_forward.conf > + fi > > I think the hardcoded 127.0.0.1 should be configurable especially considering > prepend-domain-nameservers option for dhclient.conf(5). I'm not sure you understand the goal. The idea here is to use the local resolver first, as a forwarder. If that usage would conflict with something that you prepend in dhclient.conf, don't enable both options. > Now you risk using > yourself as forwarder if you expose the resolver to the internal network Sorry, I'm not parsing this. The 127.0.0.1 address is not added to the forwarders list, if that's what you're concerned about. Come to think of it, the lines you pasted handle that address only if it's first. I just updated the patch to handle 127.0.0.1 coming later in the file, thanks! > (whether it be through dhclient or statically). > Also, maybe the combo of autoforward and dhclient should be guarded against, > since there's no telling which comes up first Ummmm.... that's completely false. rcorder determines that the network will be up first, so not only is there no harm in using both, it's how I've done all my testing. There is really no point in using this option if you are on a static network, you could just configure forwarders in named.conf yourself. > and both dhclient and > /etc/rc.d/named might be writing /etc/resolv.conf at the same time / after > eachother. Completely impossible, but I'm glad to see you're thinking about it at least. > Lastly, 127.0.0.1 and ::1 aren't equal, yet they are the same thing ;) I have no idea what you're trying to say here. However, we currently don't support (TMK anyway) IPv6-only configurations, although I'd like to see us do so sometime soon ... Doug -- This .signature sanitized for your protection From owner-freebsd-current@FreeBSD.ORG Tue Mar 31 20:04:18 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 8943E1065673 for ; Tue, 31 Mar 2009 20:04:18 +0000 (UTC) (envelope-from wollman@hergotha.csail.mit.edu) Received: from hergotha.csail.mit.edu (hergotha.csail.mit.edu [66.92.79.170]) by mx1.freebsd.org (Postfix) with ESMTP id 009A28FC27 for ; Tue, 31 Mar 2009 20:04:17 +0000 (UTC) (envelope-from wollman@hergotha.csail.mit.edu) Received: from hergotha.csail.mit.edu (localhost [127.0.0.1]) by hergotha.csail.mit.edu (8.14.2/8.14.2) with ESMTP id n2VK4Gs1077942; Tue, 31 Mar 2009 16:04:16 -0400 (EDT) (envelope-from wollman@hergotha.csail.mit.edu) Received: (from wollman@localhost) by hergotha.csail.mit.edu (8.14.2/8.13.8/Submit) id n2VK4G9s077941; Tue, 31 Mar 2009 16:04:16 -0400 (EDT) (envelope-from wollman) Date: Tue, 31 Mar 2009 16:04:16 -0400 (EDT) From: Garrett Wollman Message-Id: <200903312004.n2VK4G9s077941@hergotha.csail.mit.edu> To: phk@phk.freebsd.dk X-Newsgroups: mit.lcs.mail.freebsd-current In-Reply-To: <96526.1238484035@critter.freebsd.dk> References: <49D1B261.6010406@FreeBSD.org> Organization: None X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0 (hergotha.csail.mit.edu [127.0.0.1]); Tue, 31 Mar 2009 16:04:16 -0400 (EDT) X-Spam-Status: No, score=-1.4 required=5.0 tests=ALL_TRUSTED autolearn=disabled version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on hergotha.csail.mit.edu X-Mailman-Approved-At: Tue, 31 Mar 2009 20:47:30 +0000 Cc: current@freebsd.org Subject: Re: New rc.d/named features for testing: auto-forwarding and wait on boot 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, 31 Mar 2009 20:04:20 -0000 In article <96526.1238484035@critter.freebsd.dk>, phk@phk.freebsd.dk writes: >Maybe we need to do a more general mechanism, since many also >would like us to have confirmed the wall-clock-time via NTP before >we start anything that depends on it ? In my case, I needed something like this because ntpd can't resolve its servers until named is working, and if the resolution fails, ntpd simply gives up on those servers. The result is that ntpd starts with no associations configured and never synchronizes to anything. I'm not sure if this is fixed in more recent versions on ntpd. (I'm also dubious that you'd really want to wait 3*MINPOLL for ntpd to figure out what's going on before you finish booting, but that's more an argument to have with Dave Mills.) -GAWollman From owner-freebsd-current@FreeBSD.ORG Wed Apr 1 00:01: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 555411065678 for ; Wed, 1 Apr 2009 00:01:45 +0000 (UTC) (envelope-from blyon@blyon.com) Received: from blyon.com (blyon.com [63.236.138.5]) by mx1.freebsd.org (Postfix) with ESMTP id 4356B8FC12 for ; Wed, 1 Apr 2009 00:01:45 +0000 (UTC) (envelope-from blyon@blyon.com) Received: from [209.131.110.167] (helo=netops-167.sfo1.bitgravity.com) by blyon.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1LonNN-000Cxl-NB for freebsd-current@freebsd.org; Tue, 31 Mar 2009 16:28:13 -0700 Message-Id: From: Barrett Lyon To: freebsd-current@freebsd.org In-Reply-To: <20081223010902.GB1072@in-addr.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Tue, 31 Mar 2009 16:24:32 -0700 References: <20081223013626.2833a911@baby-jane> <20081223010902.GB1072@in-addr.com> X-Mailer: Apple Mail (2.930.3) Subject: Kip Macy 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, 01 Apr 2009 00:01:45 -0000 I'm sure this is the wrong place to post this, but I thought I would share anyway: http://digg.com/linux_unix/FreeBSD_developer_s_life_destroyed_by_squatter_from_hell It's Kip's story from the other side, I thought this community may like to read it and spread the digg story. -Barrett From owner-freebsd-current@FreeBSD.ORG Wed Apr 1 00:48: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 5DF1C106564A for ; Wed, 1 Apr 2009 00:48:12 +0000 (UTC) (envelope-from freebsd-current@m.gmane.org) Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by mx1.freebsd.org (Postfix) with ESMTP id 13BA08FC08 for ; Wed, 1 Apr 2009 00:48:11 +0000 (UTC) (envelope-from freebsd-current@m.gmane.org) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1Loock-0004gI-Nu for freebsd-current@freebsd.org; Wed, 01 Apr 2009 00:48:10 +0000 Received: from 89-186-142-125.dynamic.primacom.net ([89.186.142.125]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 01 Apr 2009 00:48:10 +0000 Received: from js by 89-186-142-125.dynamic.primacom.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 01 Apr 2009 00:48:10 +0000 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-current@freebsd.org From: Julian Stecklina Date: Wed, 01 Apr 2009 02:47:59 +0200 Lines: 18 Message-ID: <87y6ulkxmo.fsf@tabernacle.lan> References: <20081223013626.2833a911@baby-jane> <20081223010902.GB1072@in-addr.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: 89-186-142-125.dynamic.primacom.net X-Archive: encrypt User-Agent: Gnus/5.101 (Gnus v5.10.10) Cancel-Lock: sha1:tz3o38RpF9cM5QdbUzGNIzkHE5o= Sender: news Subject: Re: Kip Macy 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, 01 Apr 2009 00:48:12 -0000 Barrett Lyon writes: > I'm sure this is the wrong place to post this, but I thought I would > share anyway: > > http://digg.com/linux_unix/FreeBSD_developer_s_life_destroyed_by_squatter_from_hell > > It's Kip's story from the other side, I thought this community may > like to read it and spread the digg story. Is there any way to support him from outside the U.S.? Regards, -- Julian Stecklina The day Microsoft makes something that doesn't suck is probably the day they start making vacuum cleaners - Ernst Jan Plugge From owner-freebsd-current@FreeBSD.ORG Wed Apr 1 00:49: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 8111E1065677 for ; Wed, 1 Apr 2009 00:49:28 +0000 (UTC) (envelope-from chargen@gmail.com) Received: from mail-fx0-f167.google.com (mail-fx0-f167.google.com [209.85.220.167]) by mx1.freebsd.org (Postfix) with ESMTP id 102D38FC22 for ; Wed, 1 Apr 2009 00:49:27 +0000 (UTC) (envelope-from chargen@gmail.com) Received: by fxm11 with SMTP id 11so2584329fxm.43 for ; Tue, 31 Mar 2009 17:49:27 -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=X/lBAeNp7aJ2QnG/IoVhBrLtf1gC7BLyws5L0Lj7KBE=; b=xzMv67kU8LvtgRIjQkSt0uog+RtIyoCooUtzN3mRdKz5TO9P8zoCELijqbVGGoXDNi SvcUpaKOZgQF+p3cKOiaBTH5tSCA3oJWEe5dpg7WFcTsxnDR3Ltdq8OhAFItIZ65Fcsq gSaU2+JCt68E+gmj8mAXjROAAF0X0PgRm7P+w= 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=nXagLu6EfNy2i7Enxb2kNwUf9g9WDWdugG673E5YLYIi2Nc1z+vNYLTgMAfcHQMUna ZwQAdAEX7L4GnjBI4k/LFoLtf2pcu2GQvbPq/rwezykgG+2Cyv8WQRmoYrE6QNmYQwIw vfCfGhnhVnR1QFSELMi+bWOr61DFvQ5mKodoU= MIME-Version: 1.0 Received: by 10.204.31.77 with SMTP id x13mr2582246bkc.6.1238545635881; Tue, 31 Mar 2009 17:27:15 -0700 (PDT) In-Reply-To: References: <20081223013626.2833a911@baby-jane> <20081223010902.GB1072@in-addr.com> Date: Wed, 1 Apr 2009 02:27:15 +0200 Message-ID: <292361ab0903311727u7d81c9dei485d5be2262e66ba@mail.gmail.com> From: Chargen To: Barrett Lyon Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: Kip Macy 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, 01 Apr 2009 00:49:29 -0000 thanks for sharing. is there any way to financially support them (perhaps a call on the freebsd site?) rgd,s Edwin On Wed, Apr 1, 2009 at 1:24 AM, Barrett Lyon wrote: > I'm sure this is the wrong place to post this, but I thought I would share > anyway: > > http://digg.com/linux_unix/FreeBSD_developer_s_life_destroyed_by_squatter_from_hell > > It's Kip's story from the other side, I thought this community may like to > read it and spread the digg story. > > -Barrett > _______________________________________________ > 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 Wed Apr 1 00: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 3CC221065672 for ; Wed, 1 Apr 2009 00:51:51 +0000 (UTC) (envelope-from andy@siliconlandmark.com) Received: from lexi.siliconlandmark.com (lexi.siliconlandmark.com [66.184.117.4]) by mx1.freebsd.org (Postfix) with ESMTP id D6B268FC1D for ; Wed, 1 Apr 2009 00:51:50 +0000 (UTC) (envelope-from andy@siliconlandmark.com) Received: from [192.168.123.103] (rrcs-65-31-67-135.central.biz.rr.com [65.31.67.135]) (authenticated bits=0) by lexi.siliconlandmark.com (8.14.2/8.14.2) with ESMTP id n310Sh03033873 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 1 Apr 2009 00:28:46 GMT (envelope-from andy@siliconlandmark.com) Message-Id: From: Andre Guibert de Bruet To: Barrett Lyon In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Tue, 31 Mar 2009 20:28:42 -0400 References: <20081223013626.2833a911@baby-jane> <20081223010902.GB1072@in-addr.com> X-Mailer: Apple Mail (2.930.3) X-Virus-Scanned: ClamAV 0.94.1/9189/Tue Mar 31 21:37:49 2009 on lexi.siliconlandmark.com X-Virus-Status: Clean Cc: freebsd-current@freebsd.org Subject: Re: Kip Macy 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, 01 Apr 2009 00:51:51 -0000 On Mar 31, 2009, at 7:24 PM, Barrett Lyon wrote: > I'm sure this is the wrong place to post this, but I thought I would > share anyway: > > http://digg.com/linux_unix/FreeBSD_developer_s_life_destroyed_by_squatter_from_hell > > It's Kip's story from the other side, I thought this community may > like to read it and spread the digg story. I've seen good April Fools jokes in my time, but this is almost believable! Thanks for the laughs! :) Cheers, /* Andre Guibert de Bruet * 436f 6465 2070 6f65 742e 2042 6974 206a */ /* Managing Partner * 6f63 6b65 792e 2053 7973 4164 6d69 6e2e */ /* GSM: +1 734 846 8758 * 2055 4e49 5820 736c 6575 7468 2e00 0000 */ /* WWW: siliconlandmark.com * C/C++, Java, Perl, PHP, SQL, XHTML, XML */ From owner-freebsd-current@FreeBSD.ORG Wed Apr 1 01:01: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 170A11065674 for ; Wed, 1 Apr 2009 01:01:56 +0000 (UTC) (envelope-from julian@elischer.org) Received: from outU.internet-mail-service.net (outu.internet-mail-service.net [216.240.47.244]) by mx1.freebsd.org (Postfix) with ESMTP id EF9F18FC1A for ; Wed, 1 Apr 2009 01:01:55 +0000 (UTC) (envelope-from julian@elischer.org) Received: from idiom.com (mx0.idiom.com [216.240.32.160]) by out.internet-mail-service.net (Postfix) with ESMTP id D1F84C3F2; Tue, 31 Mar 2009 18:01:55 -0700 (PDT) X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e Received: from julian-mac.elischer.org (home.elischer.org [216.240.48.38]) by idiom.com (Postfix) with ESMTP id 9801D2D607B; Tue, 31 Mar 2009 18:01:52 -0700 (PDT) Message-ID: <49D2BD1C.40703@elischer.org> Date: Tue, 31 Mar 2009 18:02:20 -0700 From: Julian Elischer User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: Andre Guibert de Bruet References: <20081223013626.2833a911@baby-jane> <20081223010902.GB1072@in-addr.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org, Barrett Lyon Subject: Re: Kip Macy 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, 01 Apr 2009 01:01:56 -0000 Andre Guibert de Bruet wrote: > On Mar 31, 2009, at 7:24 PM, Barrett Lyon wrote: > >> I'm sure this is the wrong place to post this, but I thought I would >> share anyway: >> >> http://digg.com/linux_unix/FreeBSD_developer_s_life_destroyed_by_squatter_from_hell >> >> >> It's Kip's story from the other side, I thought this community may >> like to read it and spread the digg story. > > I've seen good April Fools jokes in my time, but this is almost believable! > > Thanks for the laughs! :) unfortunately it's true.. > > Cheers, > > /* Andre Guibert de Bruet * 436f 6465 2070 6f65 742e 2042 6974 206a */ > /* Managing Partner * 6f63 6b65 792e 2053 7973 4164 6d69 6e2e */ > /* GSM: +1 734 846 8758 * 2055 4e49 5820 736c 6575 7468 2e00 0000 */ > /* WWW: siliconlandmark.com * C/C++, Java, Perl, PHP, SQL, XHTML, XML */ > > > _______________________________________________ > 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 Wed Apr 1 01:03: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 B34FA1065675 for ; Wed, 1 Apr 2009 01:03:04 +0000 (UTC) (envelope-from wilkinsa@stlux550.dsto.defence.gov.au) Received: from digger1.defence.gov.au (digger1.defence.gov.au [203.5.217.4]) by mx1.freebsd.org (Postfix) with ESMTP id 139278FC0C for ; Wed, 1 Apr 2009 01:03:03 +0000 (UTC) (envelope-from wilkinsa@stlux550.dsto.defence.gov.au) Received: from ednmsw520.dsto.defence.gov.au (ednmsw520.dsto.defence.gov.au [131.185.68.60]) by digger1.defence.gov.au (DSTO/DSTO) with ESMTP id n310wKKM017583 for ; Wed, 1 Apr 2009 10:28:20 +0930 (CST) Received: from ednex510.dsto.defence.gov.au (ednex510.dsto.defence.gov.au) by ednmsw520.dsto.defence.gov.au (Clearswift SMTPRS 5.3.1) with ESMTP id for ; Wed, 1 Apr 2009 11:33:02 +1030 Received: from stlex511.dsto.defence.gov.au ([203.6.60.49]) by ednex510.dsto.defence.gov.au with Microsoft SMTPSVC(6.0.3790.3959); Wed, 1 Apr 2009 11:33:02 +1030 Received: from stlux550.dsto.defence.gov.au ([203.6.60.61]) by stlex511.dsto.defence.gov.au with Microsoft SMTPSVC(6.0.3790.3959); Wed, 1 Apr 2009 09:03:00 +0800 Received: from stlux550.dsto.defence.gov.au (localhost [127.0.0.1]) by stlux550.dsto.defence.gov.au (8.14.3/8.14.3) with ESMTP id n3112wbF091298 for ; Wed, 1 Apr 2009 09:02:58 +0800 (WST) (envelope-from wilkinsa@stlux550.dsto.defence.gov.au) Received: (from wilkinsa@localhost) by stlux550.dsto.defence.gov.au (8.14.3/8.14.3/Submit) id n3112vbD091297 for freebsd-current@freebsd.org; Wed, 1 Apr 2009 09:02:57 +0800 (WST) (envelope-from wilkinsa) Date: Wed, 1 Apr 2009 09:02:57 +0800 From: "Wilkinson, Alex" To: freebsd-current@freebsd.org Message-ID: <20090401010257.GK87477@stlux503.dsto.defence.gov.au> Mail-Followup-To: freebsd-current@freebsd.org References: <20081223013626.2833a911@baby-jane> <20081223010902.GB1072@in-addr.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline In-Reply-To: Organisation: Defence Science Technology Organisation User-Agent: Mutt/1.5.18 (2008-05-17) X-OriginalArrivalTime: 01 Apr 2009 01:03:00.0321 (UTC) FILETIME=[9A13F510:01C9B265] X-TM-AS-Product-Ver: SMEX-7.0.0.1584-5.6.1016-16552.005 X-TM-AS-Result: No--0.738000-0.000000-31 Content-Transfer-Encoding: 7bit Subject: Re: Kip Macy 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, 01 Apr 2009 01:03:04 -0000 0n Tue, Mar 31, 2009 at 08:28:42PM -0400, Andre Guibert de Bruet wrote: >On Mar 31, 2009, at 7:24 PM, Barrett Lyon wrote: > >> I'm sure this is the wrong place to post this, but I thought I would >> share anyway: >> >> http://digg.com/linux_unix/FreeBSD_developer_s_life_destroyed_by_squatter_from_hell >> >> It's Kip's story from the other side, I thought this community may >> like to read it and spread the digg story. > >I've seen good April Fools jokes in my time, but this is almost >believable! > >Thanks for the laughs! :) Yeah great joke! How pathetic! -aW IMPORTANT: This email remains the property of the Australian Defence Organisation and is subject to the jurisdiction of section 70 of the CRIMES ACT 1914. If you have received this email in error, you are requested to contact the sender and delete the email. From owner-freebsd-current@FreeBSD.ORG Wed Apr 1 01:07: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 53BE41065688 for ; Wed, 1 Apr 2009 01:07:31 +0000 (UTC) (envelope-from null@pozo.com) Received: from pozo.com (pozo.com [216.101.162.50]) by mx1.freebsd.org (Postfix) with ESMTP id 268518FC17 for ; Wed, 1 Apr 2009 01:07:31 +0000 (UTC) (envelope-from null@pozo.com) Received: from T61p.pozo.com (t61p.pozo.com [192.168.0.8]) (authenticated bits=0) by pozo.com (8.14.3/8.14.3) with ESMTP id n31176Wx014854 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 31 Mar 2009 18:07:07 -0700 (PDT) (envelope-from null@pozo.com) Message-Id: <200904010107.n31176Wx014854@pozo.com> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Tue, 31 Mar 2009 18:07:00 -0700 To: Julian Elischer , Andre Guibert de Bruet From: Manfred Antar In-Reply-To: <49D2BD1C.40703@elischer.org> References: <20081223013626.2833a911@baby-jane> <20081223010902.GB1072@in-addr.com> <49D2BD1C.40703@elischer.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Spam-Status: No, score=-101.4 required=5.0 tests=ALL_TRUSTED,MISSING_MID, USER_IN_WHITELIST autolearn=failed version=3.2.5, No X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on pozo.com X-pozo.com-MailScanner-Information: Please contact the ISP for more information X-MailScanner-ID: n31176Wx014854 X-pozo.com-MailScanner: Found to be clean X-pozo.com-MailScanner-From: null@pozo.com Cc: freebsd-current@freebsd.org, Barrett Lyon Subject: Re: Kip Macy 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, 01 Apr 2009 01:07:31 -0000 At 06:02 PM 3/31/2009, Julian Elischer wrote: >Andre Guibert de Bruet wrote: >>On Mar 31, 2009, at 7:24 PM, Barrett Lyon wrote: >> >>>I'm sure this is the wrong place to post this, but I thought I would share anyway: >>> >>>http://digg.com/linux_unix/FreeBSD_developer_s_life_destroyed_by_squatter_from_hell >>> >>>It's Kip's story from the other side, I thought this community may like to read it and spread the digg story. >>I've seen good April Fools jokes in my time, but this is almost believable! >>Thanks for the laughs! :) > >unfortunately it's true.. Yes I live in San Francisco, and Read about it in the paper. Never connected the two. So Sad. ================================== || null@pozo.com || || Ph. (415) 681-6235 || ================================== -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. From owner-freebsd-current@FreeBSD.ORG Wed Apr 1 01:42: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 80E8E106564A for ; Wed, 1 Apr 2009 01:42:38 +0000 (UTC) (envelope-from melanie.vonfange@gmail.com) Received: from qw-out-2122.google.com (qw-out-2122.google.com [74.125.92.24]) by mx1.freebsd.org (Postfix) with ESMTP id 4464B8FC0C for ; Wed, 1 Apr 2009 01:42:38 +0000 (UTC) (envelope-from melanie.vonfange@gmail.com) Received: by qw-out-2122.google.com with SMTP id 9so2078036qwb.7 for ; Tue, 31 Mar 2009 18:42:37 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: References: <20081223013626.2833a911@baby-jane> <20081223010902.GB1072@in-addr.com> Date: Tue, 31 Mar 2009 20:13:19 -0500 Received: by 10.220.91.148 with SMTP id n20mr2879618vcm.68.1238548415193; Tue, 31 Mar 2009 18:13:35 -0700 (PDT) Message-ID: <9df43a1e0903311813y5ef95aa9oc0ba5225f659de4d@mail.gmail.com> From: Melanie Vonfange To: Andre Guibert de Bruet Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Wed, 01 Apr 2009 02:27:14 +0000 Cc: freebsd-current@freebsd.org, Barrett Lyon Subject: Re: Kip Macy 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, 01 Apr 2009 01:42:38 -0000 On Tue, Mar 31, 2009 at 7:28 PM, Andre Guibert de Bruet wrote: > On Mar 31, 2009, at 7:24 PM, Barrett Lyon wrote: > >> I'm sure this is the wrong place to post this, but I thought I would sha= re >> anyway: >> >> >> http://digg.com/linux_unix/FreeBSD_developer_s_life_destroyed_by_squatte= r_from_hell >> >> It's Kip's story from the other side, I thought this community may like = to >> read it and spread the digg story. > > I've seen good April Fools jokes in my time, but this is almost believabl= e! > > Thanks for the laughs! :) > > Cheers, > > /* =A0Andre Guibert de Bruet =A0* 436f 6465 2070 6f65 742e 2042 6974 206a= */ > /* =A0 =A0 Managing Partner =A0 =A0 * 6f63 6b65 792e 2053 7973 4164 6d69 = 6e2e */ > /* =A0 GSM: +1 734 846 8758 =A0 * 2055 4e49 5820 736c 6575 7468 2e00 0000= */ > /* WWW: siliconlandmark.com * C/C++, Java, Perl, PHP, SQL, XHTML, XML */ > > > _______________________________________________ > 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= " > Unfortunately, it isn't a joke. It's all true and has been happening for a year. It's a tragedy. Melanie VonFange PC-BSD Project BSD Advocate From owner-freebsd-current@FreeBSD.ORG Wed Apr 1 02:42: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 D9C2410656BE for ; Wed, 1 Apr 2009 02:42:20 +0000 (UTC) (envelope-from andy@siliconlandmark.com) Received: from lexi.siliconlandmark.com (lexi.siliconlandmark.com [66.184.117.4]) by mx1.freebsd.org (Postfix) with ESMTP id 6DE158FC08 for ; Wed, 1 Apr 2009 02:42:20 +0000 (UTC) (envelope-from andy@siliconlandmark.com) Received: from [10.0.1.98] (c-76-112-231-135.hsd1.mi.comcast.net [76.112.231.135]) (authenticated bits=0) by lexi.siliconlandmark.com (8.14.2/8.14.2) with ESMTP id n312fw8a038065 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 1 Apr 2009 02:42:04 GMT (envelope-from andy@siliconlandmark.com) Message-Id: <2F50854E-012C-4949-85E3-EFD1221841C3@siliconlandmark.com> From: Andre Guibert de Bruet To: Julian Elischer In-Reply-To: <49D2BD1C.40703@elischer.org> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Tue, 31 Mar 2009 22:41:52 -0400 References: <20081223013626.2833a911@baby-jane> <20081223010902.GB1072@in-addr.com> <49D2BD1C.40703@elischer.org> X-Mailer: Apple Mail (2.930.3) X-Virus-Scanned: ClamAV 0.94.1/9189/Tue Mar 31 21:37:49 2009 on lexi.siliconlandmark.com X-Virus-Status: Clean Cc: freebsd-current@freebsd.org, Barrett Lyon Subject: Re: Kip Macy 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, 01 Apr 2009 02:42:21 -0000 On Mar 31, 2009, at 9:02 PM, Julian Elischer wrote: > Andre Guibert de Bruet wrote: >> On Mar 31, 2009, at 7:24 PM, Barrett Lyon wrote: >>> I'm sure this is the wrong place to post this, but I thought I >>> would share anyway: >>> >>> http://digg.com/linux_unix/FreeBSD_developer_s_life_destroyed_by_squatter_from_hell >>> >>> It's Kip's story from the other side, I thought this community may >>> like to read it and spread the digg story. >> I've seen good April Fools jokes in my time, but this is almost >> believable! >> Thanks for the laughs! :) > > unfortunately it's true.. Yikes! My apologies to kip@ if my comment came off as insensitive... Is there anything that can be done to help (From across the country)? Andy /* Andre Guibert de Bruet * 436f 6465 2070 6f65 742e 2042 6974 206a */ /* Managing Partner * 6f63 6b65 792e 2053 7973 4164 6d69 6e2e */ /* GSM: +1 734 846 8758 * 2055 4e49 5820 736c 6575 7468 2e00 0000 */ /* WWW: siliconlandmark.com * C/C++, Java, Perl, PHP, SQL, XHTML, XML */ From owner-freebsd-current@FreeBSD.ORG Wed Apr 1 03:56: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 9EC61106564A for ; Wed, 1 Apr 2009 03:56:05 +0000 (UTC) (envelope-from julian@elischer.org) Received: from outN.internet-mail-service.net (outn.internet-mail-service.net [216.240.47.237]) by mx1.freebsd.org (Postfix) with ESMTP id 821738FC0A for ; Wed, 1 Apr 2009 03:56:05 +0000 (UTC) (envelope-from julian@elischer.org) Received: from idiom.com (mx0.idiom.com [216.240.32.160]) by out.internet-mail-service.net (Postfix) with ESMTP id 479232C30C; Tue, 31 Mar 2009 20:56:05 -0700 (PDT) X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e Received: from julian-mac.elischer.org (home.elischer.org [216.240.48.38]) by idiom.com (Postfix) with ESMTP id 9F3922D6045; Tue, 31 Mar 2009 20:56:01 -0700 (PDT) Message-ID: <49D2E5ED.6050802@elischer.org> Date: Tue, 31 Mar 2009 20:56:29 -0700 From: Julian Elischer User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: Andre Guibert de Bruet References: <20081223013626.2833a911@baby-jane> <20081223010902.GB1072@in-addr.com> <49D2BD1C.40703@elischer.org> <2F50854E-012C-4949-85E3-EFD1221841C3@siliconlandmark.com> In-Reply-To: <2F50854E-012C-4949-85E3-EFD1221841C3@siliconlandmark.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org, Barrett Lyon Subject: Re: Kip Macy 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, 01 Apr 2009 03:56:05 -0000 Andre Guibert de Bruet wrote: > On Mar 31, 2009, at 9:02 PM, Julian Elischer wrote: > >> Andre Guibert de Bruet wrote: >>> On Mar 31, 2009, at 7:24 PM, Barrett Lyon wrote: >>>> I'm sure this is the wrong place to post this, but I thought I would >>>> share anyway: >>>> >>>> http://digg.com/linux_unix/FreeBSD_developer_s_life_destroyed_by_squatter_from_hell >>>> >>>> >>>> It's Kip's story from the other side, I thought this community may >>>> like to read it and spread the digg story. >>> I've seen good April Fools jokes in my time, but this is almost >>> believable! >>> Thanks for the laughs! :) >> >> unfortunately it's true.. > > Yikes! My apologies to kip@ if my comment came off as insensitive... Is > there anything that can be done to help (From across the country)? At this stage it would only help if you are good friends with a reporter who is interested in going against the flow. > > Andy > > /* Andre Guibert de Bruet * 436f 6465 2070 6f65 742e 2042 6974 206a */ > /* Managing Partner * 6f63 6b65 792e 2053 7973 4164 6d69 6e2e */ > /* GSM: +1 734 846 8758 * 2055 4e49 5820 736c 6575 7468 2e00 0000 */ > /* WWW: siliconlandmark.com * C/C++, Java, Perl, PHP, SQL, XHTML, XML */ From owner-freebsd-current@FreeBSD.ORG Wed Apr 1 04:40: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 8E9B3106566C for ; Wed, 1 Apr 2009 04:40:28 +0000 (UTC) (envelope-from dgerow@afflictions.org) Received: from relay4-v.mail.gandi.net (relay4-v.mail.gandi.net [217.70.178.78]) by mx1.freebsd.org (Postfix) with ESMTP id 130E88FC15 for ; Wed, 1 Apr 2009 04:40:28 +0000 (UTC) (envelope-from dgerow@afflictions.org) Received: from plebeian.afflictions.org (CPE0021296fd1ec-CM0019475d4056.cpe.net.cable.rogers.com [99.241.164.229]) by relay4-v.mail.gandi.net (Postfix) with ESMTP id A1093BA2D for ; Wed, 1 Apr 2009 06:40:26 +0200 (CEST) Received: by plebeian.afflictions.org (Postfix, from userid 1001) id AF6C5403B; Wed, 1 Apr 2009 00:40:11 -0400 (EDT) Date: Wed, 1 Apr 2009 00:40:11 -0400 From: Damian Gerow To: freebsd-current@freebsd.org Message-ID: <20090401044011.GA51164@plebeian.afflictions.org> References: <49BD117B.2080706@163.com> <20090325090456.G92412@rust.salford.ac.uk> <49C9FC53.8070104@163.com> <200903301745.46149.Thomas.Sparrevohn@btinternet.com> <20090331100328.H46640@rust.salford.ac.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20090331100328.H46640@rust.salford.ac.uk> User-Agent: Mutt/1.5.19 (2009-01-05) Subject: ZFS checksum errors on USB attach (Was: ZFS data error without reasons) 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, 01 Apr 2009 04:40:28 -0000 Mark Powell wrote: : > the problem can be solved - The weird thing is that it will give CRC : > errros (and permenent errors) in blocks that has not been touched (or at : > least I think so) : : Can you be a little clearer? Perhaps some zpool status output with the : steps you've taken? I've run into this problem four times in the past week or so. I haven't reliably been able to reproduce it (which isn't /that/ upsetting; I don't much like data loss, even if I can predict it), but my current hunch is that it has something to do with uptime: the longer the system is up, the more likely the bug is to trigger. Here's what happened an hour ago: I walked over to my laptop (Lenovo X200), and plugged in a Cowon D2 to charge up the battery. When I tried to do other things, I received a large number of input/output errors, so I knew I'd triggered the bug. Two things that I tried to do: - start sshd (this machine doesn't normally run sshd) - open a new urxvt session Appropriate snippets from /var/log/messages (note: nothing shows up in dmesg): ----- Mar 31 23:29:56 plebeian kernel: ugen7.2: at usbus7 Mar 31 23:29:56 plebeian kernel: umass0: on usbus7 Mar 31 23:29:56 plebeian kernel: umass0: SCSI over Bulk-Only; quirks = 0x0000 Mar 31 23:29:56 plebeian root: Unknown USB device: vendor 0x0e21 product 0x0800 bus uhub7 Mar 31 23:29:57 plebeian kernel: umass0:0:0:-1: Attached to scbus0 Mar 31 23:29:57 plebeian kernel: da0 at umass-sim0 bus 0 target 0 lun 0 Mar 31 23:29:57 plebeian kernel: da0: Removable Direct Access SCSI-0 device Mar 31 23:29:57 plebeian kernel: da0: 40.000MB/s transfers Mar 31 23:29:57 plebeian kernel: da0: 7808MB (15990784 512 byte sectors: 255H 63S/T 995C) Mar 31 23:29:57 plebeian kernel: da1 at umass-sim0 bus 0 target 0 lun 1 Mar 31 23:29:57 plebeian kernel: da1: Removable Direct Access SCSI-0 device Mar 31 23:29:57 plebeian kernel: da1: 40.000MB/s transfers Mar 31 23:29:57 plebeian kernel: da1: 15359MB (31456320 512 byte sectors: 255H 63S/T 1958C) Mar 31 23:29:57 plebeian kernel: GEOM_LABEL: Label for provider da0 is msdosfs/D2. Mar 31 23:29:57 plebeian kernel: GEOM: da1: partition 1 does not start on a track boundary. Mar 31 23:29:57 plebeian kernel: GEOM: da1: partition 1 does not end on a track boundary. Mar 31 23:30:50 plebeian root: ZFS: checksum mismatch, zpool=storage path=/dev/ad4s1d.eli offset=297610772480 size=131072 Mar 31 23:30:50 plebeian root: ZFS: checksum mismatch, zpool=storage path=/dev/ad4s1d.eli offset=297610772480 size=131072 Mar 31 23:30:50 plebeian root: ZFS: zpool I/O failure, zpool=storage error=86 Mar 31 23:31:20 plebeian root: ZFS: checksum mismatch, zpool=storage path=/dev/ad4s1d.eli offset=23159373824 size=131072 Mar 31 23:31:20 plebeian root: ZFS: checksum mismatch, zpool=storage path=/dev/ad4s1d.eli offset=23159373824 size=131072 Mar 31 23:31:20 plebeian root: ZFS: zpool I/O failure, zpool=storage error=86 Mar 31 23:31:34 plebeian root: ZFS: checksum mismatch, zpool=storage path=/dev/ad4s1d.eli offset=18063163392 size=131072 Mar 31 23:31:34 plebeian root: ZFS: checksum mismatch, zpool=storage path=/dev/ad4s1d.eli offset=18063163392 size=131072 Mar 31 23:31:34 plebeian root: ZFS: zpool I/O failure, zpool=storage error=86 Mar 31 23:31:34 plebeian root: ZFS: checksum mismatch, zpool=storage path=/dev/ad4s1d.eli offset=18062901248 size=131072 Mar 31 23:31:34 plebeian root: ZFS: checksum mismatch, zpool=storage path=/dev/ad4s1d.eli offset=18062901248 size=131072 Mar 31 23:31:34 plebeian root: ZFS: zpool I/O failure, zpool=storage error=86 Mar 31 23:31:35 plebeian root: ZFS: checksum mismatch, zpool=storage path=/dev/ad4s1d.eli offset=17453809664 size=131072 Mar 31 23:31:35 plebeian root: ZFS: checksum mismatch, zpool=storage path=/dev/ad4s1d.eli offset=17453809664 size=131072 Mar 31 23:31:35 plebeian root: ZFS: zpool I/O failure, zpool=storage error=86 Mar 31 23:31:35 plebeian root: ZFS: checksum mismatch, zpool=storage path=/dev/ad4s1d.eli offset=17453809664 size=131072 Mar 31 23:31:35 plebeian root: ZFS: checksum mismatch, zpool=storage path=/dev/ad4s1d.eli offset=17453809664 size=131072 Mar 31 23:31:35 plebeian root: ZFS: zpool I/O failure, zpool=storage error=86 Mar 31 23:31:40 plebeian sudo: dgerow : TTY=pts/4 ; PWD=/home/dgerow ; USER=root ; COMMAND=/etc/rc.d/sshd start Mar 31 23:31:50 plebeian sudo: dgerow : TTY=pts/4 ; PWD=/home/dgerow ; USER=root ; COMMAND=/etc/rc.d/sshd onestart Mar 31 23:31:51 plebeian root: ZFS: checksum mismatch, zpool=storage path=/dev/ad4s1d.eli offset=18045468672 size=131072 Mar 31 23:31:51 plebeian dgerow: /etc/rc.d/sshd: WARNING: failed to start sshd Mar 31 23:31:51 plebeian root: ZFS: checksum mismatch, zpool=storage path=/dev/ad4s1d.eli offset=18045468672 size=131072 Mar 31 23:31:51 plebeian root: ZFS: zpool I/O failure, zpool=storage error=86 ----- I explicitly received errors reading from /etc/termcap after this. So I shut everything down -- there is a strong tendancy for applications to core dump at this point -- and rebooted into single-user mode. Then I checked the status of the zfs pool (zpool status -v): ----- pool: storage state: ONLINE status: One or more devices has experienced an error resulting in data corruption. Applications may be affected. action: Restore the file in question if possible. Otherwise restore the entire pool from backup. see: http://www.sun.com/msg/ZFS-8000-8A scrub: none requested config: NAME STATE READ WRITE CKSUM storage ONLINE 0 0 0 ad4s1d.eli ONLINE 0 0 0 errors: Permanent errors have been detected in the following files: storage/usr:/local/share/zsh/4.3.9/functions/Completion/Debian.zwc storage/usr:/local/share/zsh/4.3.9/functions/Completion/Linux.zwc storage/usr:<0xf02d> storage/usr:/local/bin/mutt storage/usr:/sbin/sshd storage/usr:/local/sbin/cupsd storage/usr:/share/games/fortune/fortunes storage/usr:/local/lib/libgtk-x11-2.0.so.0 storage/usr:/local/lib/firefox3/chrome/browser.jar storage/usr:/share/misc/termcap storage/usr:/share/misc/termcap.db storage/usr:/local/bin/transmission storage/usr:/local/bin/openbox storage/home:<0x331d> storage/home:/dgerow/X-Files/402 - Home.mp4 storage/home:/dgerow/.mozilla/firefox/bk0ibcxu.default/urlclassifier3.sqlite storage/home:/dgerow/X-Files/705 - Rush.mp4 storage/home:/dgerow/.procmail.log ----- There doesn't seem to be a pattern as to which files are affected: mutt, openbox, cupsd, and transmission were all running before the checksum errors, whereas fortune, sshd, and procmail were all run post-checksum errors. zsh and firefox were running, of course, both before and after. Oddly, and as was noted as quoted above, I'm not sure what 0x331d would be. I didn't explicitly delete anything after plugging in the D2, though it is possible that a program removed a temporary file. The scrub found an additional five errors, and post scrub, my pool now looks like this: ----- pool: storage state: ONLINE status: One or more devices has experienced an error resulting in data corruption. Applications may be affected. action: Restore the file in question if possible. Otherwise restore the entire pool from backup. see: http://www.sun.com/msg/ZFS-8000-8A scrub: scrub completed after 0h34m with 6 errors on Wed Apr 1 00:22:25 2009 config: NAME STATE READ WRITE CKSUM storage ONLINE 0 0 6 ad4s1d.eli ONLINE 0 0 12 errors: Permanent errors have been detected in the following files: storage/home:/dgerow/.mozilla/firefox/bk0ibcxu.default/urlclassifier3.sqlite storage/home:/dgerow/.config/transmission/resume/X-Files.2a82218f000bc93d.resume storage/home:/dgerow/.mozilla/firefox/bk0ibcxu.default/Cache/_CACHE_001_ storage/home:/dgerow/mutt.core storage/home:/dgerow/X-Files/707 - Orison.mp4 ----- To finish fixing this, I've already deleted all these files, and another scrub should clean things up, with one final command to tell zfs to ignore remaining errors (I forget what it is, it shows up in 'action'.) Thankfully, I maintain regular backups, and nothing affected (this time around) was important. : I expect this is a red hering, but do you not have some kind of : kernel/module sync problem? I don't. I'm running a GENERIC kernel from this morning in this case, with no special modules loaded: ----- plebeian% sysctl kern.osreldate kern.osrevision kern.osreldate: 800074 kern.osrevision: 199506 plebeian% uname -a FreeBSD plebeian.afflictions.org 8.0-CURRENT FreeBSD 8.0-CURRENT #0: Tue Mar 31 08:41:28 EDT 2009 dgerow@plebeian.afflictions.org:/usr/obj/usr/src/sys/GENERIC amd64 plebeian% kldstat Id Refs Address Size Name 1 20 0xffffffff80100000 e48440 kernel 2 1 0xffffffff81022000 a5c7 geom_eli.ko 3 1 0xffffffff8102d000 1b446 crypto.ko 4 1 0xffffffff81049000 a192 zlib.ko 5 1 0xffffffff81054000 f0a64 zfs.ko 6 1 0xffffffff81145000 1914 opensolaris.ko 7 1 0xffffffff81147000 771a i915.ko 8 1 0xffffffff8114f000 111a8 drm.ko plebeian% ----- - Damian From owner-freebsd-current@FreeBSD.ORG Wed Apr 1 05:52: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 EEA2510656D5; Wed, 1 Apr 2009 05:52:56 +0000 (UTC) (envelope-from alexander@leidinger.net) Received: from redbull.bpaserver.net (redbullneu.bpaserver.net [213.198.78.217]) by mx1.freebsd.org (Postfix) with ESMTP id 9A1688FC19; Wed, 1 Apr 2009 05:52:56 +0000 (UTC) (envelope-from alexander@leidinger.net) Received: from outgoing.leidinger.net (pD9E2E2B1.dip.t-dialin.net [217.226.226.177]) by redbull.bpaserver.net (Postfix) with ESMTP id 81F5B2E111; Wed, 1 Apr 2009 07:52:48 +0200 (CEST) Received: from webmail.leidinger.net (webmail.leidinger.net [192.168.1.102]) by outgoing.leidinger.net (Postfix) with ESMTP id 953BB5E54D; Wed, 1 Apr 2009 07:52:44 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=Leidinger.net; s=outgoing-alex; t=1238565164; bh=tDSD9O5SzLyxxYBCUiUEFTCnjKkMVPOpQ JWWCpk1OV0=; h=Message-ID:Date:From:To:Cc:Subject:References: In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=ByLHYY55x33utJ8JDkInw87EX/fHszc1Y+tRh1sq+P+YvW8HhFwM4RChN/t8t3fJr q+4JnrhKAJ5rphfIlk/u45YiUsTlirqDHPxwJP3nWj//r2duZpntAsBub+Q1Zaz7Xts RD3MFf0cXvPOSJvFzH+TPME43S/DHfPonBlCoKvjDevWJuRh5bYoto8pLzjySGGWixy 6UwSTxpgFR5ySxIq/X3YD39XHcN/s2PQEAP77yXN/d5BLbYJPm4v2fuoxwuswqbX+AK g1u7MH/K0onDmnr4ky9HKt+W5veamtOx7Mn0w1cziiwvHE/e4Kb8/+f0F2i1hk8zXgZ Cpwfj0I8g== Received: (from www@localhost) by webmail.leidinger.net (8.14.3/8.13.8/Submit) id n315qiGO032769; Wed, 1 Apr 2009 07:52:44 +0200 (CEST) (envelope-from Alexander@Leidinger.net) Received: from pslux.cec.eu.int (pslux.cec.eu.int [158.169.9.14]) by webmail.leidinger.net (Horde Framework) with HTTP; Wed, 01 Apr 2009 07:52:43 +0200 Message-ID: <20090401075243.13336br8h73f2884@webmail.leidinger.net> X-Priority: 3 (Normal) Date: Wed, 01 Apr 2009 07:52:43 +0200 From: Alexander Leidinger To: Doug Barton References: <49D1B261.6010406@FreeBSD.org> <20090331101454.16983mt8x4ru2xog@webmail.leidinger.net> <49D278BA.6070705@FreeBSD.org> In-Reply-To: <49D278BA.6070705@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; DelSp="Yes"; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: 7bit User-Agent: Internet Messaging Program (IMP) H3 (4.3) / FreeBSD-8.0 X-BPAnet-MailScanner-Information: Please contact the ISP for more information X-MailScanner-ID: 81F5B2E111.DA276 X-BPAnet-MailScanner: Found to be clean X-BPAnet-MailScanner-SpamCheck: not spam, ORDB-RBL, SpamAssassin (not cached, score=-14.9, required 6, BAYES_00 -15.00, DKIM_SIGNED 0.00, DKIM_VERIFIED -0.00, RDNS_DYNAMIC 0.10) X-BPAnet-MailScanner-From: alexander@leidinger.net X-Spam-Status: No Cc: freebsd-current@FreeBSD.org Subject: Re: New rc.d/named features for testing: auto-forwarding and wait on boot 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, 01 Apr 2009 05:52:57 -0000 Quoting Doug Barton (from Tue, 31 Mar 2009 13:10:34 -0700): > Alexander Leidinger wrote: >> At which place in the startup would this wait? > > This would be answered by looking at the patch as well, but since I'm > a nice guy I'll tell you that it waits right after named is started. > On my system with essentially the default "local resolver" > configuration plus a few things added the delay waiting for the host > command to complete is almost unnoticeable. Thank you for the information. Bye, Alexander. -- DALLAS: The city that chose Astroturf to keep the cheerleaders from grazing. http://www.Leidinger.net Alexander @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137 From owner-freebsd-current@FreeBSD.ORG Wed Apr 1 06:14: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 3F1561065673; Wed, 1 Apr 2009 06:14:00 +0000 (UTC) (envelope-from mel.flynn+fbsd.current@mailing.thruhere.net) Received: from mailhub.rachie.is-a-geek.net (rachie.is-a-geek.net [66.230.99.27]) by mx1.freebsd.org (Postfix) with ESMTP id D85B38FC20; Wed, 1 Apr 2009 06:13:59 +0000 (UTC) (envelope-from mel.flynn+fbsd.current@mailing.thruhere.net) Received: from sarevok.dnr.servegame.org (gate.lan.rachie.is-a-geek.net [192.168.2.10]) by mailhub.rachie.is-a-geek.net (Postfix) with ESMTP id A87E27E818; Tue, 31 Mar 2009 22:13:58 -0800 (AKDT) From: Mel Flynn To: freebsd-current@freebsd.org Date: Wed, 1 Apr 2009 08:13:56 +0200 User-Agent: KMail/1.11.0 (FreeBSD/8.0-CURRENT; KDE/4.2.0; i386; ; ) References: <49D1B261.6010406@FreeBSD.org> <200903311025.22219.mel.flynn+fbsd.current@mailing.thruhere.net> <49D27B95.7030209@FreeBSD.org> In-Reply-To: <49D27B95.7030209@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200904010813.57167.mel.flynn+fbsd.current@mailing.thruhere.net> Cc: Doug Barton Subject: Re: New rc.d/named features for testing: auto-forwarding and wait on boot 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, 01 Apr 2009 06:14:00 -0000 On Tuesday 31 March 2009 22:22:45 Doug Barton wrote: > Mel Flynn wrote: > > Hi Doug, > > > > On Tuesday 31 March 2009 08:17:35 Doug Barton wrote: > >>> In addition to enabling auto_forward you can also enable > >>> auto_forward_only which changes from the default 'forward first' to > >>> (you guessed it) 'forward only'. > >> > >> And of course, the patch: > >> http://dougbarton.us/Downloads/rcd-named.diff > > > > Snippet: > > + if [ -z "$firstns" ]; then > > + if [ ! "$nsip" = '127.0.0.1' ]; then > > + echo 'nameserver 127.0.0.1' > > + echo " ${nsip};" >> /var/run/auto_forward.conf > > + fi > > > > I think the hardcoded 127.0.0.1 should be configurable especially > > considering prepend-domain-nameservers option for dhclient.conf(5). > > I'm not sure you understand the goal. The idea here is to use the > local resolver first, as a forwarder. If that usage would conflict > with something that you prepend in dhclient.conf, don't enable both > options. But the local resolver is assumed to be 127.0.0.1, not for example 192.168.1.10 or ::1. I agree prepending a nameserver and autoforward are not the best combo, but it can be handy in case you stop named (free up resources, you temporarily want) to still be able to resolve (though with a delay). Either way, you're writing 127.0.0.1 to resolv.conf, yet not setting a listen- on in named so the two can be out of sync, though documentation can fix this. On my home network, pppoe on the gateway updates /etc/resolv.conf and I later insert the named running on 192.168.2.51. Named doesn't listen on 127.0.0.1 (didn't see a need to do this). At the very least, it would be nice if a warning was added if listen-on.*127.0.0.1 could not be found in /etc/namedb/named.conf. > > Now you risk using > > yourself as forwarder if you expose the resolver to the internal network > > Sorry, I'm not parsing this. The 127.0.0.1 address is not added to the > forwarders list, if that's what you're concerned about. But a 192.168.1.10 would be. > Come to think > of it, the lines you pasted handle that address only if it's first. I > just updated the patch to handle 127.0.0.1 coming later in the file, > thanks! > > > (whether it be through dhclient or statically). > > Also, maybe the combo of autoforward and dhclient should be guarded > > against, since there's no telling which comes up first > > Ummmm.... that's completely false. rcorder determines that the network > will be up first, so not only is there no harm in using both, it's how > I've done all my testing. And what happens if the DHCP server cannot be reached within 5 tries, but will once it's in the background? Also, rcorder shows NETWORKING before named, yet dhclient after, though with the changes of (a)sync dhclient lately, I should probably familiarize myself again with what exactly is done. > There is really no point in using this > option if you are on a static network, you could just configure > forwarders in named.conf yourself. Since forwarders are picked up from /etc/resolv.conf I was ready to abuse the feature and not worry about changing named.conf, but yes you are right :). > > Lastly, 127.0.0.1 and ::1 aren't equal, yet they are the same thing ;) > > I have no idea what you're trying to say here. However, we currently > don't support (TMK anyway) IPv6-only configurations, although I'd like > to see us do so sometime soon ... Noted. -- Mel From owner-freebsd-current@FreeBSD.ORG Wed Apr 1 06:44: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 5A397106564A for ; Wed, 1 Apr 2009 06:44:27 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe04.swip.net [212.247.154.97]) by mx1.freebsd.org (Postfix) with ESMTP id E58208FC0A for ; Wed, 1 Apr 2009 06:44:26 +0000 (UTC) (envelope-from hselasky@c2i.net) X-Cloudmark-Score: 0.000000 [] X-Cloudmark-Analysis: v=1.0 c=1 a=XvHtPtpkKJ8A:10 a=u5uu7iVke1AA:10 a=MXw7gxVQKqGXY79tIT8aFQ==:17 a=QPbusHYMeZ8bnxd80gEA:9 a=e0qvDzEypWtRVoh3FDjp6J1f8BkA:4 a=LY0hPdMaydYA:10 Received: from [62.113.132.61] (account mc467741@c2i.net HELO laptop) by mailfe04.swip.net (CommuniGate Pro SMTP 5.2.6) with ESMTPA id 1218520719; Wed, 01 Apr 2009 08:44:24 +0200 From: Hans Petter Selasky To: freebsd-current@freebsd.org Date: Wed, 1 Apr 2009 08:46:55 +0200 User-Agent: KMail/1.9.7 References: <49BD117B.2080706@163.com> <20090331100328.H46640@rust.salford.ac.uk> <20090401044011.GA51164@plebeian.afflictions.org> In-Reply-To: <20090401044011.GA51164@plebeian.afflictions.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200904010846.55770.hselasky@c2i.net> Cc: Damian Gerow Subject: Re: ZFS checksum errors on USB attach (Was: ZFS data error without reasons) 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, 01 Apr 2009 06:44:27 -0000 On Wednesday 01 April 2009, Damian Gerow wrote: > Mark Powell wrote: > : > the problem can be solved - The weird thing is that it will give CRC > : > errros (and permenent errors) in blocks that has not been touched (or > : > at least I think so) > : > : Can you be a little clearer? Perhaps some zpool status output with the > : steps you've taken? > > I've run into this problem four times in the past week or so. I haven't > reliably been able to reproduce it (which isn't /that/ upsetting; I don't > much like data loss, even if I can predict it), but my current hunch is > that it has something to do with uptime: the longer the system is up, the > more likely the bug is to trigger. > > Here's what happened an hour ago: > > I walked over to my laptop (Lenovo X200), and plugged in a Cowon D2 to > charge up the battery. When I tried to do other things, I received a large > number of input/output errors, so I knew I'd triggered the bug. Two things > that I tried to do: If you unload "umass" and plug a memory stick, do you see the same behaviour then? Maybe it is not directly USB related. --HPS From owner-freebsd-current@FreeBSD.ORG Wed Apr 1 06:54: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 3A5911065672 for ; Wed, 1 Apr 2009 06:54:34 +0000 (UTC) (envelope-from peterjeremy@optushome.com.au) Received: from mail12.syd.optusnet.com.au (mail12.syd.optusnet.com.au [211.29.132.193]) by mx1.freebsd.org (Postfix) with ESMTP id B64118FC15 for ; Wed, 1 Apr 2009 06:54:33 +0000 (UTC) (envelope-from peterjeremy@optushome.com.au) Received: from server.vk2pj.dyndns.org (c122-106-216-167.belrs3.nsw.optusnet.com.au [122.106.216.167]) by mail12.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id n316sUvk030141 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 1 Apr 2009 17:54:31 +1100 X-Bogosity: Ham, spamicity=0.000000 Received: from server.vk2pj.dyndns.org (localhost.vk2pj.dyndns.org [127.0.0.1]) by server.vk2pj.dyndns.org (8.14.3/8.14.3) with ESMTP id n316sU4X012151; Wed, 1 Apr 2009 17:54:30 +1100 (EST) (envelope-from peter@server.vk2pj.dyndns.org) Received: (from peter@localhost) by server.vk2pj.dyndns.org (8.14.3/8.14.3/Submit) id n316sUxU012150; Wed, 1 Apr 2009 17:54:30 +1100 (EST) (envelope-from peter) Date: Wed, 1 Apr 2009 17:54:30 +1100 From: Peter Jeremy To: Barney Cordoba Message-ID: <20090401065430.GA12025@server.vk2pj.dyndns.org> References: <200903311055.48136.jhb@freebsd.org> <208477.83685.qm@web63906.mail.re1.yahoo.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="gBBFr7Ir9EOA20Yy" Content-Disposition: inline In-Reply-To: <208477.83685.qm@web63906.mail.re1.yahoo.com> X-PGP-Key: http://members.optusnet.com.au/peterjeremy/pubkey.asc User-Agent: Mutt/1.5.19 (2009-01-05) Cc: freebsd-current@freebsd.org Subject: Re: pci_alloc_resource is broken 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, 01 Apr 2009 06:54:34 -0000 --gBBFr7Ir9EOA20Yy Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 2009-Mar-31 10:55:26 -0700, Barney Cordoba wr= ote: >Its really you who is being condescending. You _really_ need to learn some manners. Despite your goading, John has remained polite and helpful. >in business for 20 years with 3000 active customers that Given your attitude, I'm surprised you have _any_ customers. I presume you have other minions who actually interact with them. > If you were Bill Gates >I'd accept that. But you're a programmer. More insults. BTW, I suspect Bill Gates considers himself a programmer - he used to be a fairly good one. >Now is a resource in use a "fatal" system error?=20 That depends on the resource but, possibly, yes. >Face it please. You replaced one bug with another. If you spent half the >effort doing it correctly as you are spending defending what you've done >we'd all be a lot happier. If you spent as much time helping the project by providing patches or constructive input as you do insulting the developers, we'd all be a lot happier. --=20 Peter Jeremy --gBBFr7Ir9EOA20Yy Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.10 (FreeBSD) iEYEARECAAYFAknTD6YACgkQ/opHv/APuIdSKwCgjCZHIc57ThDdX5n+mpJc4sTS 5P8AoLW8AKZ2FHLX8myP0CvqEcEocDkM =ktcf -----END PGP SIGNATURE----- --gBBFr7Ir9EOA20Yy-- From owner-freebsd-current@FreeBSD.ORG Wed Apr 1 07:20: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 3F6791065675; Wed, 1 Apr 2009 07:20:12 +0000 (UTC) (envelope-from lstewart@freebsd.org) Received: from lauren.room52.net (lauren.room52.net [210.50.193.198]) by mx1.freebsd.org (Postfix) with ESMTP id B13198FC1F; Wed, 1 Apr 2009 07:20:11 +0000 (UTC) (envelope-from lstewart@freebsd.org) Received: from lstewart.caia.swin.edu.au (lstewart.caia.swin.edu.au [136.186.229.95]) (authenticated bits=0) by lauren.room52.net (8.14.3/8.14.3) with ESMTP id n317K3po039257 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 1 Apr 2009 18:20:03 +1100 (EST) (envelope-from lstewart@freebsd.org) Message-ID: <49D3159E.5000901@freebsd.org> Date: Wed, 01 Apr 2009 18:19:58 +1100 From: Lawrence Stewart User-Agent: Thunderbird 2.0.0.21 (X11/20090325) MIME-Version: 1.0 To: freebsd-current@freebsd.org References: <49CF0754.9070907@room52.net> <49CF2B0C.7050301@FreeBSD.org> <49CF6551.4080301@room52.net> <49CF68C4.8020806@FreeBSD.org> <49D0150E.8050601@room52.net> In-Reply-To: <49D0150E.8050601@room52.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-2.0 required=5.0 tests=AWL,BAYES_00,SPF_SOFTFAIL autolearn=disabled version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on lauren.room52.net Cc: Alexander Motin Subject: Re: [SOLVED->UNSOLVED] Re: kernel panic with snd_hda "panic: Duplicate free of item 0xffffff00025f8c00 from zone 0xffffff00b697d400(1024)" (possibly an ACPI 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, 01 Apr 2009 07:20:12 -0000 Lawrence Stewart wrote: > Alexander Motin wrote: >> Lawrence Stewart wrote: >>> Alexander Motin wrote: >>>> I can't reproduce neither "Invalid corb size (0)" error, nor the >>>> crash in case of it. I have tried to simulate that error, but system >>>> handled it correctly. But I have INVARIANTS disabled on my system. >>>> >>>> Can you try to disable MSI? >>> >>> Setting hw.pci.enable_msix=0 and hw.pci.enable_msi=0 at the loader >>> prompt made no difference. >> >> It could also be done with hint.hdac.0.msi=0. >> >>>> Can you try to move hdac_irq_alloc() call after hdac_rirb_init() in >>>> hdac_attach()? May be interrupt shots while something is not yet >>>> initialized? >>> >>> Running with the following patch made no difference either. >>> >>> Any other ideas I could try? >> >> I have none. I haven't changed anything significant last time, except >> enabling MSI. You can try to investigate both problems: original >> "Invalid corb size (0)" and the consequent crash. As I have said, I >> can't reproduce none of them. Try to put some debug printfs inside >> hdac_get_capabilities(), may be it give some new clues. >> > > Seems to have been a red herring. I tried a couple of older kernel > revisions which made no difference. Booting into windows, the sound card > works fine. Then I booted into FreeBSD and it booted fine without the > panic, although the hda driver spewed out a heap of error messages like > this: > > Mar 30 09:50:12 lstewart-laptop kernel: hdac0: > hdac_command_send_internal: TIMEOUT numcmd=1, sent=1, received=0 > Mar 30 09:50:12 lstewart-laptop kernel: hdac0: > hdac_command_send_internal: TIMEOUT numcmd=1, sent=1, received=0 > Mar 30 09:50:12 lstewart-laptop kernel: hdac0: Codec #0 is not > responding! Probing aborted. > > repeated up to: > > Mar 30 09:50:12 lstewart-laptop kernel: hdac0: > hdac_command_send_internal: TIMEOUT numcmd=1, sent=0, received=0 > Mar 30 09:50:12 lstewart-laptop kernel: hdac0: > hdac_command_send_internal: TIMEOUT numcmd=1, sent=0, received=0 > Mar 30 09:50:12 lstewart-laptop kernel: hdac0: Codec #14 is not > responding! Probing aborted. > > Then I rebooted again and got the panic on every reboot. Weird. > > On a whim, I suspected fishy BIOS settings left over after a BIOS > upgrade so I reset all BIOS values to factory defaults and now it seems > to be working fine. There are no audio related options in the BIOS, so > not sure what was broken but something must not have been happy or must > have been left in an inconsistent state somehow. > > Sorry for not having thought of it sooner, but it looks like the case is > closed. > So... just got this panic again, for no discernible reason. Turn the laptop on and bam. Reboot and try again, same panic. So I try my previous trick and enter the BIOS screen, reset all to factory defaults, save and exit - everything is fine once again. I hadn't entered the BIOS since resetting everything to factory defaults last time which resolved the issue as noted in my previous email. So, either the BIOS is dodgy, or FreeBSD is tickling something in a bad way. I don't think I've found any evidence to implicate either theory yet. As a starting point, I poured over the kernel boot log and noticed this line: Apr 1 16:53:34 lstewart-laptop kernel: ACPI Warning (tbutils-0243): Incorrect checksum in table [ASF!] - C8, should be 5E [20070320] Could anyone enlighten me as to whether that is a cause for concern? Might make the "dodgy BIOS" theory more likely if the incorrect checksum is indeed bad. The full verbose boot log is available at: http://people.freebsd.org/~lstewart/misc/intel_debug/verbose_boot.txt Cheers, Lawrence From owner-freebsd-current@FreeBSD.ORG Wed Apr 1 07:38: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 A6B90106566B for ; Wed, 1 Apr 2009 07:38:30 +0000 (UTC) (envelope-from ccuiyyan@gmail.com) Received: from wa-out-1112.google.com (wa-out-1112.google.com [209.85.146.178]) by mx1.freebsd.org (Postfix) with ESMTP id 7E1C38FC08 for ; Wed, 1 Apr 2009 07:38:30 +0000 (UTC) (envelope-from ccuiyyan@gmail.com) Received: by wa-out-1112.google.com with SMTP id m38so2030159waf.27 for ; Wed, 01 Apr 2009 00:38:30 -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=kzSgK+UrIffAMPSUnhQMcTNO5BAU76aeLVxDINDlgcQ=; b=MkQGT+oi94BCw96BVkaZB1i9TKCszUbfW/ru2dRAkt1RpQGBO195G/IzaJAav7HeDo OzBBNpaALYTykSiUgpqMLge9bv0l5KWTvoKwg4YyYYHq1ajpG1Azz0D9FILfQuAxePWm j1PbhtWJ4rnCuwHegWWKsg1J+Ycln/Lt3H3I8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=slwFuoUicCfbKDl4BJmyFtnWmJaQuW015C+6MLGuyo8R2PRtdS1lxRfTRAOGAcoJrf /0u2gIFeilf5kqu74AsP/5NhXdI6soXk6/U1ybChxClHSTXYKtHIrdQ1qk/WFe3mnJu9 DAEcF06OdRgA6dv6kUGN1d2gg4FWtcSZxGmVQ= MIME-Version: 1.0 Received: by 10.115.89.1 with SMTP id r1mr5026725wal.84.1238571510057; Wed, 01 Apr 2009 00:38:30 -0700 (PDT) Date: Wed, 1 Apr 2009 15:38:29 +0800 Message-ID: <4451ccf20904010038p64ed2540mec3249f89bb7b8c2@mail.gmail.com> From: =?GB2312?B?tN7R0mNjdWl5eWFuQHNpbmEuY29t?= To: freebsd-current@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Performance Tools in FreeBSD 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, 01 Apr 2009 07:38:30 -0000 Dear all: I wonder to know which kind of performance tools FreeBSD hackers use to identify scalability or performance bottlenecks. I really have a hard time in that. To identify bottlenecks in our benchmarks, i try PMC and Dtrace. However, PMC seems not to be supported in AMD Opteron CPU because i get a "invalid arguments" error when i use the command pmcstat -S instructions -O . However, "instructions, cycles,..." are documented in pmc manual. By the way, I enable the options in configuration file options HWPMC_HOOKS and device hwpmc. So i give up PMC and turn to Dtrace in BSD. Dtrace in FreeBSD can work, but the information is meaningless. Profile provider cannot be used. (When i used, the kernel goes into kdb.) Tick provider can be used (It can only work on one CPU by definition). However, when i use aggregation like "dtrace -n 'tick-10ms /arg0!=0/{@ks[probefunc] = count();}'" There are no human readable results. Only tools i can use is the stack() command. However, the results are limited. I know Dtrace is a tool in FreeBSD under development. Are there any tools recommended to do kernel profiling or callgraph effectively? (which functions take the most time) Best Wishes! Yan From owner-freebsd-current@FreeBSD.ORG Wed Apr 1 08:22:40 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 0CFE5106566C for ; Wed, 1 Apr 2009 08:22:40 +0000 (UTC) (envelope-from army.of.root@googlemail.com) Received: from fk-out-0910.google.com (fk-out-0910.google.com [209.85.128.188]) by mx1.freebsd.org (Postfix) with ESMTP id 8AB598FC0C for ; Wed, 1 Apr 2009 08:22:38 +0000 (UTC) (envelope-from army.of.root@googlemail.com) Received: by fk-out-0910.google.com with SMTP id b27so1322438fka.11 for ; Wed, 01 Apr 2009 01:22:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=XSgHawUn08CTk2hR5cTM+Yan7gaM1+ZvXdYvlMmsIdU=; b=XuS+DflBLhGwqSbacYuPej5FW8880I+yRckcAnuYGeZwittMehlEfcFPru2bqA22cQ Mp+7DmREg2on2IXXsVcR2e7ryz79rY6WuWYEhKuM5OMygdpW9HdXhg2gDWyO6mpeBeEP B+vuBo90/OdO01AOXw9aa01/nyY1+N+38/jhM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=jan5cfwWHxGPT5kh0I1tYYqE1vXoS76ekaisHpSuFusOiBaE7O5LzgQTUQZ07wu8+p tYsH/laHiNxxD43Ksy0q0MBWtgCYkpBBLC7w2eUjGDEBH6bO++dsa1botNrmRf//n/lT nUS/Lw6NbdQVqC8C+WqToPLzyDzJLCMd3cxC8= Received: by 10.223.113.9 with SMTP id y9mr5914524fap.19.1238572195132; Wed, 01 Apr 2009 00:49:55 -0700 (PDT) Received: from ?192.168.2.24? (p5486CD5F.dip.t-dialin.net [84.134.205.95]) by mx.google.com with ESMTPS id 22sm3276348fkr.14.2009.04.01.00.49.54 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 01 Apr 2009 00:49:54 -0700 (PDT) Message-ID: <49D31CA1.9080201@googlemail.com> Date: Wed, 01 Apr 2009 09:49:53 +0200 From: "army.of.root" User-Agent: Thunderbird 2.0.0.17 (X11/20081028) MIME-Version: 1.0 To: Poul-Henning Kamp References: <973.1238529980@critter.freebsd.dk> In-Reply-To: <973.1238529980@critter.freebsd.dk> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: Garrett Wollman , current@freebsd.org Subject: Re: New rc.d/named features for testing: auto-forwarding and wait on boot 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, 01 Apr 2009 08:22:40 -0000 Poul-Henning Kamp wrote: > In message <200903312004.n2VK4G9s077941@hergotha.csail.mit.edu>, Garrett Wollma > n writes: > >> I'm not sure if this is fixed in more recent versions on ntpd. (I'm >> also dubious that you'd really want to wait 3*MINPOLL for ntpd to >> figure out what's going on before you finish booting, but that's more >> an argument to have with Dave Mills.) > > I'm pretty sure everybody else than Dave Mills runs ntpdate before > they start ntpd :-) > Hi, I use ntpd_sync_on_start="YES" in my rc.conf . From owner-freebsd-current@FreeBSD.ORG Wed Apr 1 08:49: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 BEA72106566B for ; Wed, 1 Apr 2009 08:49:00 +0000 (UTC) (envelope-from gary.jennejohn@freenet.de) Received: from mout2.freenet.de (mout2.freenet.de [IPv6:2001:748:100:40::2:4]) by mx1.freebsd.org (Postfix) with ESMTP id 566BB8FC1E for ; Wed, 1 Apr 2009 08:49:00 +0000 (UTC) (envelope-from gary.jennejohn@freenet.de) Received: from [195.4.92.12] (helo=2.mx.freenet.de) by mout2.freenet.de with esmtpa (ID gary.jennejohn@freenet.de) (port 25) (Exim 4.69 #79) id 1Low83-0001Md-7n; Wed, 01 Apr 2009 10:48:59 +0200 Received: from tf73b.t.pppool.de ([89.55.247.59]:55329 helo=ernst.jennejohn.org) by 2.mx.freenet.de with esmtpa (ID gary.jennejohn@freenet.de) (port 25) (Exim 4.69 #79) id 1Low81-0006Xv-6u; Wed, 01 Apr 2009 10:48:57 +0200 Date: Wed, 1 Apr 2009 10:48:56 +0200 From: Gary Jennejohn To: Marcel Moolenaar Message-ID: <20090401104856.1feb6a79@ernst.jennejohn.org> In-Reply-To: <60084D1E-9F64-463A-A8E9-7A237D5C7661@mac.com> References: <95891.1238477069@critter.freebsd.dk> <20090331133132.1e191836@ernst.jennejohn.org> <20090331155542.74d89d64@ernst.jennejohn.org> <60084D1E-9F64-463A-A8E9-7A237D5C7661@mac.com> X-Mailer: Claws Mail 3.7.1 (GTK+ 2.14.7; amd64-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: Removal of GEOM_BSD, GEOM_MBR, GEOM_PC98 and GEOM_SUNLABEL X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: gary.jennejohn@freenet.de List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Apr 2009 08:49:01 -0000 On Tue, 31 Mar 2009 09:00:55 -0700 Marcel Moolenaar wrote: > > On Mar 31, 2009, at 6:55 AM, Gary Jennejohn wrote: > >>> > >>> I have some disks which were partitioned before GEOM or gpart even > >>> existed. If this means that I can't use them any more I'll be very > >>> ticked off. > >> > >> No, the question is which GEOM class to use to parse the partition > >> table :) > >> > >> gpart is new, shiny, but with some rough edges (most of which have > >> been > >> polished by now), GEOM_xxx were the old classes. 8-CURRENT doesn't > >> use > >> the old classes but they are still there if anyone needs them. > >> > > > > Well, that would be OK then, as long as I can still _use_ the old > > classes > > after the removal of the various GEOM_XXX options. > > Why do you want to use the old classes when gpart can be used? > Because the disks were already labeled long ago and I do not want to risk blowing them away by relabeling them? I must admit that I'm not sure whether that would really be a problem since I haven't wanted to risk trying it with gpart. They may just still work. At the moment I see complaints about geometry and rawoffset. As long as the complaints remain complaints and everything still works then I won't care about the change. > BTW: it was my intention to remove the source files along with > the options. So you wouldn't be able to use the old classes. > Hmm. --- Gary Jennejohn From owner-freebsd-current@FreeBSD.ORG Wed Apr 1 08:50: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 12586106568E for ; Wed, 1 Apr 2009 08:50:46 +0000 (UTC) (envelope-from xkuipjiedeyt@gmail.com) Received: from mail-gx0-f176.google.com (mail-gx0-f176.google.com [209.85.217.176]) by mx1.freebsd.org (Postfix) with ESMTP id C1C8F8FC08 for ; Wed, 1 Apr 2009 08:50:45 +0000 (UTC) (envelope-from xkuipjiedeyt@gmail.com) Received: by gxk24 with SMTP id 24so738489gxk.19 for ; Wed, 01 Apr 2009 01:50:45 -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=aVPYB0j7YjyRr3uRaK+pTmtMlmNjWjQ80rmvTwIashI=; b=TQkhWUFwEVpU+9yXxRDFMrYB+InykTp17wCjEFBh1qy5py3jHvQ0Z7Lq1dZpb553JM HjEs1OY+ei1oAVZg+6ZwdYXNG2z1erHynqh/90ca1sC9kUhgJPvwXJB44IH9wqaf1ghN pYj41C2xOsABkJ5mXAe+Qxvkq5XpAxQM3s7cQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=eRR09PyhWCGYvESspHJ5T+Ju5cmHTnUi/YyAmygKCkGJanoqsufjqEPXGkvyW4Jl8s vOljLCe62LnqQyvYEr19t3mtUUWzLqN0SZ6IGMUMmOhse2PWBwmLruGLmp+q8MFMXr5p IucabjsUDqfUWlkukvqJuDPRYCJovDslYmJdw= MIME-Version: 1.0 Received: by 10.142.79.17 with SMTP id c17mr3035688wfb.171.1238575844674; Wed, 01 Apr 2009 01:50:44 -0700 (PDT) Date: Wed, 1 Apr 2009 16:50:44 +0800 Message-ID: <1128196a0904010150v572edbd4sb9ab080e2cd8bbb1@mail.gmail.com> From: XkuIPjIedEYT XkuIPjIedEYT To: freebsd-current@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: How can I change the MAC address of ath0? 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, 01 Apr 2009 08:50:46 -0000 I'm running the FreeBSD 8.0-CURRENT r190504. # dmesg | grep ^ath0 ath0: mem 0xf4000000-0xf400ffff irq 18 at device 11.0 on pci0 ath0: [ITHREAD] ath0: AR2413 mac 7.9 RF2413 phy 4.5 changing the MAC address directly on ath0 didn't work: # ifconfig ath0 link 00:aa:bb:cc:dd:ee ifconfig: ioctl (SIOCAIFADDR): Operation not supported by device # ifconfig ath0 ether 00:aa:bb:cc:dd:ee ifconfig: ioctl (SIOCAIFADDR): Operation not supported by device it worked when creating wlan0 with the wlanaddr option, but I can't associate to the AP if I try to change the MAC address of wlan0. Any help? From owner-freebsd-current@FreeBSD.ORG Wed Apr 1 08:56: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 4F0571065676 for ; Wed, 1 Apr 2009 08:56:10 +0000 (UTC) (envelope-from olivier@gid0.org) Received: from mail-fx0-f167.google.com (mail-fx0-f167.google.com [209.85.220.167]) by mx1.freebsd.org (Postfix) with ESMTP id B487C8FC14 for ; Wed, 1 Apr 2009 08:56:09 +0000 (UTC) (envelope-from olivier@gid0.org) Received: by fxm11 with SMTP id 11so2696649fxm.43 for ; Wed, 01 Apr 2009 01:56:08 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.113.9 with SMTP id y9mr5938037fap.61.1238576168884; Wed, 01 Apr 2009 01:56:08 -0700 (PDT) In-Reply-To: <20090401104856.1feb6a79@ernst.jennejohn.org> References: <95891.1238477069@critter.freebsd.dk> <20090331133132.1e191836@ernst.jennejohn.org> <20090331155542.74d89d64@ernst.jennejohn.org> <60084D1E-9F64-463A-A8E9-7A237D5C7661@mac.com> <20090401104856.1feb6a79@ernst.jennejohn.org> Date: Wed, 1 Apr 2009 10:56:08 +0200 Message-ID: <367b2c980904010156w48c401afo469dca8cb90926e2@mail.gmail.com> From: Olivier SMEDTS To: gary.jennejohn@freenet.de Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Marcel Moolenaar , freebsd-current@freebsd.org Subject: Re: Removal of GEOM_BSD, GEOM_MBR, GEOM_PC98 and GEOM_SUNLABEL 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, 01 Apr 2009 08:56:10 -0000 2009/4/1 Gary Jennejohn : > On Tue, 31 Mar 2009 09:00:55 -0700 > Marcel Moolenaar wrote: > >> >> On Mar 31, 2009, at 6:55 AM, Gary Jennejohn wrote: >> >>> >> >>> I have some disks which were partitioned before GEOM or gpart even >> >>> existed. =A0If this means that I can't use them any more I'll be ver= y >> >>> ticked off. >> >> >> >> No, the question is which GEOM class to use to parse the partition >> >> table :) >> >> >> >> gpart is new, shiny, but with some rough edges (most of which have >> >> been >> >> polished by now), GEOM_xxx were the old classes. 8-CURRENT doesn't >> >> use >> >> the old classes but they are still there if anyone needs them. >> >> >> > >> > Well, that would be OK then, as long as I can still _use_ the old >> > classes >> > after the removal of the various GEOM_XXX options. >> >> Why do you want to use the old classes when gpart can be used? >> > > Because the disks were already labeled long ago and I do not want > to risk blowing them away by relabeling them? You won't have to relabel them. > I must admit that I'm not sure whether that would really be a problem > since I haven't wanted to risk trying it with gpart. =A0They may just > still work. > > At the moment I see complaints about geometry and rawoffset. =A0As long > as the complaints remain complaints and everything still works then I > won't care about the change. > >> BTW: it was my intention to remove the source files along with >> the options. So you wouldn't be able to use the old classes. >> > > Hmm. > > --- > Gary Jennejohn > _______________________________________________ > 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= " > --=20 Olivier Smedts _ ASCII ribbon campaign ( ) e-mail: olivier@gid0.org - against HTML email & vCards X www: http://www.gid0.org - against proprietary attachments / \ "Il y a seulement 10 sortes de gens dans le monde : ceux qui comprennent le binaire, et ceux qui ne le comprennent pas." From owner-freebsd-current@FreeBSD.ORG Wed Apr 1 08:59: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 0C26E1065674 for ; Wed, 1 Apr 2009 08:59:16 +0000 (UTC) (envelope-from pluknet@gmail.com) Received: from mu-out-0910.google.com (mu-out-0910.google.com [209.85.134.185]) by mx1.freebsd.org (Postfix) with ESMTP id 8E7DB8FC08 for ; Wed, 1 Apr 2009 08:59:15 +0000 (UTC) (envelope-from pluknet@gmail.com) Received: by mu-out-0910.google.com with SMTP id w9so1127976mue.3 for ; Wed, 01 Apr 2009 01:59:14 -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=RgLxq+gd96BuWjiSGdpEaqJJdmj8hA+zwdV2tHfBPsw=; b=WF1s03gUk7x0TXIwRwhVc+li5cR4AvjjObywYrihalthnZagllP4yulN2DbnciZ7q6 X4FL9YS/i0l/Jikxcv0HdRtgInAnMXunNU1cA8z1Gu0cIfnfTaveAJ4Eifucm30+8eHt UnRB1Fr84OQ0Qc7eldCqAXCc32GXekr9JVdfI= 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=NYqU+z6bpbiE7YAqpcgldHYwidgtdkNypYB030ZmFGYtkDR5I7PzVQMLrUhKXDh0vm wzSwUJyg9f4uTr7zzJ0WlhqG1K6M7Z0UT/VXHCElrIH6YxMrKDI7kRD4+yEayR8w5SB4 awykZhjEYINBd3srvdeVxzMY/BWrXCM2osTto= MIME-Version: 1.0 Received: by 10.103.244.4 with SMTP id w4mr2713972mur.11.1238576354643; Wed, 01 Apr 2009 01:59:14 -0700 (PDT) In-Reply-To: <1128196a0904010150v572edbd4sb9ab080e2cd8bbb1@mail.gmail.com> References: <1128196a0904010150v572edbd4sb9ab080e2cd8bbb1@mail.gmail.com> Date: Wed, 1 Apr 2009 12:59:14 +0400 Message-ID: From: pluknet To: XkuIPjIedEYT XkuIPjIedEYT Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: How can I change the MAC address of ath0? 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, 01 Apr 2009 08:59:16 -0000 2009/4/1 XkuIPjIedEYT XkuIPjIedEYT : > I'm running the FreeBSD 8.0-CURRENT r190504. > > # dmesg | grep ^ath0 > ath0: mem 0xf4000000-0xf400ffff irq 18 at device 11.0 on pci0 > ath0: [ITHREAD] > ath0: AR2413 mac 7.9 RF2413 phy 4.5 > > changing the MAC address directly on ath0 didn't work: > > # ifconfig ath0 link 00:aa:bb:cc:dd:ee > ifconfig: ioctl (SIOCAIFADDR): Operation not supported by device > > # ifconfig ath0 ether 00:aa:bb:cc:dd:ee > ifconfig: ioctl (SIOCAIFADDR): Operation not supported by device It looks that something was changed in this area in r190508. -- wbr, pluknet From owner-freebsd-current@FreeBSD.ORG Wed Apr 1 11:32: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 E54DD106564A for ; Wed, 1 Apr 2009 11:32:36 +0000 (UTC) (envelope-from avatar@mmlab.cse.yzu.edu.tw) Received: from www.mmlab.cse.yzu.edu.tw (www.mmlab.cse.yzu.edu.tw [140.138.150.166]) by mx1.freebsd.org (Postfix) with ESMTP id A8C668FC1B for ; Wed, 1 Apr 2009 11:32:36 +0000 (UTC) (envelope-from avatar@mmlab.cse.yzu.edu.tw) Received: by www.mmlab.cse.yzu.edu.tw (qmail, from userid 1000) id D46D2E43405; Wed, 1 Apr 2009 19:16:34 +0800 (CST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=mmlab.cse.yzu.edu.tw; s=test; t=1238584594; bh=wo+Ol4b9XnZaMNkVHYpFYPd/bc9jrqSEw6e50FudxUU=; h=Date:From:To:cc:Subject:In-Reply-To:Message-ID:References: MIME-Version:Content-Type; b=iWOnZ63LC8dagsmHOu8PVgQwBLhGXI/U6VYHgVfYndEVSkFwgxl6rNpOdabJ73O/J VB4q+h8SSKL/EY509CVHdURuxkD97VSzgaxGrJ3+TKwaqw8wDGyoOl4+SRCF/aYA1q x/t/NgNJ2pbFwRmcZBPobH4Zv42gP9ejNHI0qHMM= Received: from localhost (localhost [127.0.0.1]) by www.mmlab.cse.yzu.edu.tw (qmail) with ESMTP id D2A95E43403; Wed, 1 Apr 2009 19:16:34 +0800 (CST) Date: Wed, 1 Apr 2009 19:16:34 +0800 (CST) From: Tai-hwa Liang To: Marcel Moolenaar In-Reply-To: <60084D1E-9F64-463A-A8E9-7A237D5C7661@mac.com> Message-ID: <0904011910169.29800@www.mmlab.cse.yzu.edu.tw> References: <95891.1238477069@critter.freebsd.dk> <20090331133132.1e191836@ernst.jennejohn.org> <20090331155542.74d89d64@ernst.jennejohn.org> <60084D1E-9F64-463A-A8E9-7A237D5C7661@mac.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-current@freebsd.org Subject: Re: Removal of GEOM_BSD, GEOM_MBR, GEOM_PC98 and GEOM_SUNLABEL 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, 01 Apr 2009 11:32:37 -0000 On Tue, 31 Mar 2009, Marcel Moolenaar wrote: > > On Mar 31, 2009, at 6:55 AM, Gary Jennejohn wrote: >>>> >>>> I have some disks which were partitioned before GEOM or gpart even >>>> existed. If this means that I can't use them any more I'll be very >>>> ticked off. >>> >>> No, the question is which GEOM class to use to parse the partition table >>> :) >>> >>> gpart is new, shiny, but with some rough edges (most of which have been >>> polished by now), GEOM_xxx were the old classes. 8-CURRENT doesn't use >>> the old classes but they are still there if anyone needs them. >>> >> >> Well, that would be OK then, as long as I can still _use_ the old classes >> after the removal of the various GEOM_XXX options. > > Why do you want to use the old classes when gpart can be used? > > BTW: it was my intention to remove the source files along with > the options. So you wouldn't be able to use the old classes. That's too bad. Since my /home is sitting on the extended partition, the OS won't boot unless the kernel is built with various GEOM_PART_ removed from i386/conf/DEFAULT plus GEOM_{BSD,MBR} added back to the kernel configuration file(ie: GENERIC kernel cvsup'ed today doesn't boot). # gpart show => 0 31250961 ad0s7c BSD (15G) 0 31250945 1 freebsd-ufs (15G) 31250945 16 - free - (8.0K) => 0 16783200 ad0s2c BSD (8.0G) 0 786432 1 freebsd-ufs (384M) 786432 4194304 2 freebsd-swap (2.0G) 4980736 393216 4 freebsd-ufs (192M) 5373952 11409248 5 freebsd-ufs (5.4G) -- Cheers, Tai-hwa Liang From owner-freebsd-current@FreeBSD.ORG Wed Apr 1 10:31: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 932B1106566C; Wed, 1 Apr 2009 10:31:41 +0000 (UTC) (envelope-from bjacke@sernet.de) Received: from mail.SerNet.de (mail1.SerNet.de [193.175.80.2]) by mx1.freebsd.org (Postfix) with ESMTP id 491EE8FC12; Wed, 1 Apr 2009 10:31:40 +0000 (UTC) (envelope-from bjacke@sernet.de) Received: from intern.SerNet.DE by mail.SerNet.DE with esmtp (Exim 4.63 #1) id 1LoxjP-0005TT-Kr; Wed, 01 Apr 2009 12:31:39 +0200 Received: by intern.SerNet.DE id 1LoxjP-005eZY-Ec; Wed, 01 Apr 2009 12:31:39 +0200 Received: by intern.SerNet.DE id 1LoxjP-005eZR-4Q; Wed, 01 Apr 2009 12:31:39 +0200 Received: from bjacke by pell.sernet.de with local (Exim 4.69) (envelope-from ) id 1Loxk4-0001eS-Pr; Wed, 01 Apr 2009 12:32:20 +0200 Date: Wed, 1 Apr 2009 12:32:20 +0200 From: =?iso-8859-1?Q?Bj=F6rn?= JACKE To: Doug Rabson References: <1238162602.24399.29.camel@phoenix.blechhirn.net> <20090401100438.GA5039@SerNet.DE> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="2oS5YaxWCcQjTEyO" Content-Disposition: inline In-Reply-To: <20090401100438.GA5039@SerNet.DE> X-Q: Sprechen und Hoeren ist Befruchten und Empfangen. (Novalis) Message-Id: Organization: SerNet GmbH, Goettingen, Germany X-Mailman-Approved-At: Wed, 01 Apr 2009 11:39:47 +0000 Cc: freebsd-xen@freebsd.org, freebsd-current@freebsd.org, Mister Olli Subject: Re: Compiling CURRENT with XEN config fails 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, 01 Apr 2009 10:31:42 -0000 --2oS5YaxWCcQjTEyO Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi, On 2009-04-01 at 12:04 +0200 Bj=F6rn JACKE sent off: > On 2009-03-27 at 15:03 +0100 Mister Olli sent off: > > /usr/src/sys/xen/evtchn/evtchn.c:516: error: conflicting types for 'bin= d_virq_to_irqhandler' > > /usr/src/sys/xen/xen_intr.h:61: error: previous declaration of 'bind_vi= rq_to_irqhandler' was here > > /usr/src/sys/xen/evtchn/evtchn.c: In function 'bind_virq_to_irqhandler': > > /usr/src/sys/xen/evtchn/evtchn.c:523: error: 'arg' undeclared (first us= e in this function) > > /usr/src/sys/xen/evtchn/evtchn.c:523: error: (Each undeclared identifie= r is reported only once > > /usr/src/sys/xen/evtchn/evtchn.c:523: error: for each function it appea= rs in.) > > *** Error code 1 >=20 > the attached patch should fix this one. Can someone review that please? there are a whole bunch of other compile bugs that had been introduced with r189699. Doug, can you please try to do a xen kernel compile with and witho= ut SMP support and take a look at the issues? Thanks... Bj=F6rn --2oS5YaxWCcQjTEyO Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.11 (GNU/Linux) iEYEARECAAYFAknTQrQACgkQdoo0s+hIejlkGACgmIv2fyceYr/2yGAMV2ZUnJYa 2QoAoOuVW8JOexoDU3i5mm1LWs6WGcQD =gvOr -----END PGP SIGNATURE----- --2oS5YaxWCcQjTEyO-- From owner-freebsd-current@FreeBSD.ORG Wed Apr 1 10:31: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 2F3181065670; Wed, 1 Apr 2009 10:31:42 +0000 (UTC) (envelope-from bjacke@sernet.de) Received: from mail.SerNet.de (mail1.SerNet.de [193.175.80.2]) by mx1.freebsd.org (Postfix) with ESMTP id DA7138FC16; Wed, 1 Apr 2009 10:31:41 +0000 (UTC) (envelope-from bjacke@sernet.de) Received: from intern.SerNet.DE by mail.SerNet.DE with esmtp (Exim 4.63 #1) id 1LoxIb-0008Ek-TQ; Wed, 01 Apr 2009 12:03:57 +0200 Received: by intern.SerNet.DE id 1LoxIb-005cL7-Ky; Wed, 01 Apr 2009 12:03:57 +0200 Received: by intern.SerNet.DE id 1LoxIb-005cL0-Bt; Wed, 01 Apr 2009 12:03:57 +0200 Received: from bjacke by pell.sernet.de with local (Exim 4.69) (envelope-from ) id 1LoxJH-0001N5-1w; Wed, 01 Apr 2009 12:04:39 +0200 Date: Wed, 1 Apr 2009 12:04:38 +0200 From: =?iso-8859-1?Q?Bj=F6rn?= JACKE To: Mister Olli References: <1238162602.24399.29.camel@phoenix.blechhirn.net> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="W/nzBZO5zC0uMSeA" Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <1238162602.24399.29.camel@phoenix.blechhirn.net> X-Q: Sprechen und Hoeren ist Befruchten und Empfangen. (Novalis) Message-Id: Organization: SerNet GmbH, Goettingen, Germany X-Mailman-Approved-At: Wed, 01 Apr 2009 11:40:39 +0000 Cc: freebsd-xen@freebsd.org, freebsd-current@freebsd.org Subject: Re: Compiling CURRENT with XEN config fails 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, 01 Apr 2009 10:31:42 -0000 --W/nzBZO5zC0uMSeA Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit On 2009-03-27 at 15:03 +0100 Mister Olli sent off: > /usr/src/sys/xen/evtchn/evtchn.c:516: error: conflicting types for 'bind_virq_to_irqhandler' > /usr/src/sys/xen/xen_intr.h:61: error: previous declaration of 'bind_virq_to_irqhandler' was here > /usr/src/sys/xen/evtchn/evtchn.c: In function 'bind_virq_to_irqhandler': > /usr/src/sys/xen/evtchn/evtchn.c:523: error: 'arg' undeclared (first use in this function) > /usr/src/sys/xen/evtchn/evtchn.c:523: error: (Each undeclared identifier is reported only once > /usr/src/sys/xen/evtchn/evtchn.c:523: error: for each function it appears in.) > *** Error code 1 the attached patch should fix this one. Can someone review that please? Thanks Björn --W/nzBZO5zC0uMSeA Content-Type: text/x-patch; charset=us-ascii Content-Disposition: attachment; filename="freebsd-head-evtchn-build-fix.patch" Index: xen/evtchn/evtchn.c =================================================================== --- xen/evtchn/evtchn.c (Revision 190598) +++ xen/evtchn/evtchn.c (Arbeitskopie) @@ -512,7 +512,7 @@ int bind_virq_to_irqhandler(unsigned int virq, unsigned int cpu, const char *devname, driver_filter_t filter, driver_intr_t handler, - unsigned long irqflags, unsigned int *irqp) + void *arg, unsigned long irqflags, unsigned int *irqp) { unsigned int irq; int error; --W/nzBZO5zC0uMSeA-- From owner-freebsd-current@FreeBSD.ORG Wed Apr 1 12:03: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 DD33B10657E5 for ; Wed, 1 Apr 2009 12:03:55 +0000 (UTC) (envelope-from vince@unsane.co.uk) Received: from unsane.co.uk (unsane-pt.tunnel.tserv5.lon1.ipv6.he.net [IPv6:2001:470:1f08:110::2]) by mx1.freebsd.org (Postfix) with ESMTP id 427088FC08 for ; Wed, 1 Apr 2009 12:03:55 +0000 (UTC) (envelope-from vince@unsane.co.uk) Received: from vhoffman.lon.namesco.net (150.117-84-212.staticip.namesco.net [212.84.117.150]) (authenticated bits=0) by unsane.co.uk (8.14.3/8.14.0) with ESMTP id n31C5u1r018059 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Wed, 1 Apr 2009 13:05:57 +0100 (BST) (envelope-from vince@unsane.co.uk) Message-ID: <49D35828.6060703@unsane.co.uk> Date: Wed, 01 Apr 2009 13:03:52 +0100 From: Vincent Hoffman User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-GB; rv:1.9.1b3pre) Gecko/20081204 Thunderbird/3.0b1 MIME-Version: 1.0 To: pluknet References: <1128196a0904010150v572edbd4sb9ab080e2cd8bbb1@mail.gmail.com> In-Reply-To: X-Enigmail-Version: 0.96a Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org, XkuIPjIedEYT XkuIPjIedEYT Subject: Re: How can I change the MAC address of ath0? 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, 01 Apr 2009 12:04:20 -0000 On 1/4/09 09:59, pluknet wrote: > 2009/4/1 XkuIPjIedEYT XkuIPjIedEYT : > >> I'm running the FreeBSD 8.0-CURRENT r190504. >> >> # dmesg | grep ^ath0 >> ath0: mem 0xf4000000-0xf400ffff irq 18 at device 11.0 on pci0 >> ath0: [ITHREAD] >> ath0: AR2413 mac 7.9 RF2413 phy 4.5 >> >> changing the MAC address directly on ath0 didn't work: >> >> # ifconfig ath0 link 00:aa:bb:cc:dd:ee >> ifconfig: ioctl (SIOCAIFADDR): Operation not supported by device >> >> # ifconfig ath0 ether 00:aa:bb:cc:dd:ee >> ifconfig: ioctl (SIOCAIFADDR): Operation not supported by device >> > > It looks that something was changed in this area in r190508. > > I dont have a current system handy so this is conjecture, since the ath device isnt used directly and instead you use cloned wlan devices, could you instead change the MAC address assigned to that instead? Vince From owner-freebsd-current@FreeBSD.ORG Wed Apr 1 12:17: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 EBB7B1065689 for ; Wed, 1 Apr 2009 12:17:21 +0000 (UTC) (envelope-from dgerow@afflictions.org) Received: from relay4-v.mail.gandi.net (relay4-v.mail.gandi.net [217.70.178.78]) by mx1.freebsd.org (Postfix) with ESMTP id AE7578FC0C for ; Wed, 1 Apr 2009 12:17:21 +0000 (UTC) (envelope-from dgerow@afflictions.org) Received: from plebeian.afflictions.org (CPE0021296fd1ec-CM0019475d4056.cpe.net.cable.rogers.com [99.241.164.229]) by relay4-v.mail.gandi.net (Postfix) with ESMTP id 6842DBA36 for ; Wed, 1 Apr 2009 14:17:20 +0200 (CEST) Received: by plebeian.afflictions.org (Postfix, from userid 1001) id C594B40BB; Wed, 1 Apr 2009 08:17:04 -0400 (EDT) Date: Wed, 1 Apr 2009 08:17:04 -0400 From: Damian Gerow To: freebsd-current@freebsd.org Message-ID: <20090401121704.GA92522@plebeian.afflictions.org> References: <49BD117B.2080706@163.com> <20090331100328.H46640@rust.salford.ac.uk> <20090401044011.GA51164@plebeian.afflictions.org> <200904010846.55770.hselasky@c2i.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200904010846.55770.hselasky@c2i.net> User-Agent: Mutt/1.5.19 (2009-01-05) Subject: Re: ZFS checksum errors on USB attach (Was: ZFS data error without reasons) 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, 01 Apr 2009 12:17:22 -0000 Hans Petter Selasky wrote: : > I walked over to my laptop (Lenovo X200), and plugged in a Cowon D2 to : > charge up the battery. When I tried to do other things, I received a large : > number of input/output errors, so I knew I'd triggered the bug. Two things : > that I tried to do: : : If you unload "umass" and plug a memory stick, do you see the same behaviour : then? : : Maybe it is not directly USB related. I had previously been unable to produce the same symptoms immediately following a reboot, with no USB-related modules loaded. I will give it another try later today to confirm. - Damian From owner-freebsd-current@FreeBSD.ORG Wed Apr 1 14:40: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 5D949106570B; Wed, 1 Apr 2009 14:40:24 +0000 (UTC) (envelope-from dfr@rabson.org) Received: from itchy.rabson.org (unknown [IPv6:2002:50b1:e8f2:1::143]) by mx1.freebsd.org (Postfix) with ESMTP id ED84D8FC20; Wed, 1 Apr 2009 14:40:23 +0000 (UTC) (envelope-from dfr@rabson.org) Received: from [IPv6:2001:470:909f:1:21b:63ff:feb8:5abc] (unknown [IPv6:2001:470:909f:1:21b:63ff:feb8:5abc]) by itchy.rabson.org (Postfix) with ESMTP id 1CA803FA8; Wed, 1 Apr 2009 15:40:21 +0100 (BST) Message-Id: From: Doug Rabson To: =?ISO-8859-1?Q?Bj=F6rn_JACKE?= In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v930.3) Date: Wed, 1 Apr 2009 15:40:21 +0100 References: <1238162602.24399.29.camel@phoenix.blechhirn.net> <20090401100438.GA5039@SerNet.DE> X-Mailer: Apple Mail (2.930.3) Cc: freebsd-xen@freebsd.org, Doug Rabson , freebsd-current@freebsd.org, Mister Olli Subject: Re: Compiling CURRENT with XEN config fails 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, 01 Apr 2009 14:40:25 -0000 On 1 Apr 2009, at 11:32, Bj=F6rn JACKE wrote: > Hi, > > On 2009-04-01 at 12:04 +0200 Bj=F6rn JACKE sent off: >> On 2009-03-27 at 15:03 +0100 Mister Olli sent off: >>> /usr/src/sys/xen/evtchn/evtchn.c:516: error: conflicting types for =20= >>> 'bind_virq_to_irqhandler' >>> /usr/src/sys/xen/xen_intr.h:61: error: previous declaration of =20 >>> 'bind_virq_to_irqhandler' was here >>> /usr/src/sys/xen/evtchn/evtchn.c: In function =20 >>> 'bind_virq_to_irqhandler': >>> /usr/src/sys/xen/evtchn/evtchn.c:523: error: 'arg' undeclared =20 >>> (first use in this function) >>> /usr/src/sys/xen/evtchn/evtchn.c:523: error: (Each undeclared =20 >>> identifier is reported only once >>> /usr/src/sys/xen/evtchn/evtchn.c:523: error: for each function it =20= >>> appears in.) >>> *** Error code 1 >> >> the attached patch should fix this one. Can someone review that =20 >> please? > > there are a whole bunch of other compile bugs that had been =20 > introduced with > r189699. Doug, can you please try to do a xen kernel compile with =20 > and without > SMP support and take a look at the issues? I'll sort it out as soon as possible. Sorry for the inconvenience. From owner-freebsd-current@FreeBSD.ORG Wed Apr 1 15:26: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 9C7431065706 for ; Wed, 1 Apr 2009 15:26:39 +0000 (UTC) (envelope-from xcllnt@mac.com) Received: from asmtpout018.mac.com (asmtpout018.mac.com [17.148.16.93]) by mx1.freebsd.org (Postfix) with ESMTP id 038B98FC23 for ; Wed, 1 Apr 2009 15:26:35 +0000 (UTC) (envelope-from xcllnt@mac.com) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=US-ASCII; format=flowed Received: from iphone-5.jnpr.net ([66.129.224.36]) by asmtp018.mac.com (Sun Java(tm) System Messaging Server 6.3-8.01 (built Dec 16 2008; 32bit)) with ESMTPSA id <0KHF00KOSHK9XX70@asmtp018.mac.com> for freebsd-current@freebsd.org; Wed, 01 Apr 2009 08:26:34 -0700 (PDT) Message-id: From: Marcel Moolenaar To: Tai-hwa Liang In-reply-to: <0904011910169.29800@www.mmlab.cse.yzu.edu.tw> Date: Wed, 01 Apr 2009 08:25:08 -0700 References: <95891.1238477069@critter.freebsd.dk> <20090331133132.1e191836@ernst.jennejohn.org> <20090331155542.74d89d64@ernst.jennejohn.org> <60084D1E-9F64-463A-A8E9-7A237D5C7661@mac.com> <0904011910169.29800@www.mmlab.cse.yzu.edu.tw> X-Mailer: Apple Mail (2.930.3) Cc: freebsd-current@freebsd.org Subject: Re: Removal of GEOM_BSD, GEOM_MBR, GEOM_PC98 and GEOM_SUNLABEL 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, 01 Apr 2009 15:26:53 -0000 On Apr 1, 2009, at 4:16 AM, Tai-hwa Liang wrote: > that's too bad. Since my /home is sitting on the extended partition, > the OS won't boot unless the kernel is built with various GEOM_PART_ > removed from i386/conf/DEFAULT plus GEOM_{BSD,MBR} added back to the > kernel configuration file(ie: GENERIC kernel cvsup'ed today doesn't > boot). That sounds like a bug, because logical partitions are supported. Can you enable GEOM_PART_BSD, GEOM_PART_EBR and GEOM_PART_MBR and tell me which GEOMs are available at the mount root prompt? -- Marcel Moolenaar xcllnt@mac.com From owner-freebsd-current@FreeBSD.ORG Wed Apr 1 16:08: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 49132106566C; Wed, 1 Apr 2009 16:08:23 +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 CA2B38FC1E; Wed, 1 Apr 2009 16:08:22 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from localhost (amavis.fra.cksoft.de [192.168.74.71]) by mail.cksoft.de (Postfix) with ESMTP id 5E80A41C712; Wed, 1 Apr 2009 17:50:06 +0200 (CEST) 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 m2dky0aNyzVG; Wed, 1 Apr 2009 17:50:05 +0200 (CEST) Received: by mail.cksoft.de (Postfix, from userid 66) id 8B8ED41C735; Wed, 1 Apr 2009 17:50:05 +0200 (CEST) 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 C0C244448EC; Wed, 1 Apr 2009 15:47:18 +0000 (UTC) Date: Wed, 1 Apr 2009 15:47:18 +0000 (UTC) From: "Bjoern A. Zeeb" X-X-Sender: bz@maildrop.int.zabbadoz.net To: =?iso-8859-1?Q?Bj=F6rn?= JACKE In-Reply-To: Message-ID: <20090401154457.K15361@maildrop.int.zabbadoz.net> References: <1238162602.24399.29.camel@phoenix.blechhirn.net> X-OpenPGP-Key: 0x14003F198FEFA3E77207EE8D2B58B8F83CCF1842 MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="0-2014893890-1238600777=:15361" Content-ID: <20090401154626.R15361@maildrop.int.zabbadoz.net> Cc: freebsd-xen@freebsd.org, Doug Rabson , freebsd-current@freebsd.org, Mister Olli Subject: Re: Compiling CURRENT with XEN config fails 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, 01 Apr 2009 16:08:23 -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. --0-2014893890-1238600777=:15361 Content-Type: TEXT/PLAIN; CHARSET=ISO-8859-1; FORMAT=flowed Content-Transfer-Encoding: QUOTED-PRINTABLE Content-ID: <20090401154626.O15361@maildrop.int.zabbadoz.net> On Wed, 1 Apr 2009, Bj=F6rn JACKE wrote: > On 2009-03-27 at 15:03 +0100 Mister Olli sent off: >> /usr/src/sys/xen/evtchn/evtchn.c:516: error: conflicting types for 'bind= _virq_to_irqhandler' >> /usr/src/sys/xen/xen_intr.h:61: error: previous declaration of 'bind_vir= q_to_irqhandler' was here >> /usr/src/sys/xen/evtchn/evtchn.c: In function 'bind_virq_to_irqhandler': >> /usr/src/sys/xen/evtchn/evtchn.c:523: error: 'arg' undeclared (first use= in this function) >> /usr/src/sys/xen/evtchn/evtchn.c:523: error: (Each undeclared identifier= is reported only once >> /usr/src/sys/xen/evtchn/evtchn.c:523: error: for each function it appear= s in.) >> *** Error code 1 > > the attached patch should fix this one. Can someone review that please? I had those since last weekend but there are even more ... Not entirely sure about the second hunk of the console.c patch though. I gave up as the universe I built worked for what I tested. Index: sys/dev/xen/console/console.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- sys/dev/xen/console/console.c (revision 190619) +++ sys/dev/xen/console/console.c (working copy) @@ -225,7 +225,6 @@ xc_attach(device_t dev) { int error; - struct xc_softc *sc =3D (struct xc_softc *)device_get_softc(dev); if (xen_start_info->flags & SIF_INITDOMAIN) { xc_consdev.cn_putc =3D xccnputc_dom0; @@ -248,6 +247,7 @@ "console", NULL, xencons_priv_interrupt, + NULL, INTR_TYPE_TTY, NULL); KASSERT(error >=3D 0, ("can't register con= sole interrupt")); Index: sys/xen/evtchn/evtchn.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- sys/xen/evtchn/evtchn.c (revision 190619) +++ sys/xen/evtchn/evtchn.c (working copy) @@ -512,7 +512,7 @@ int bind_virq_to_irqhandler(unsigned int virq, unsigned int cpu, const char *devname, driver_filter_t filter, driver_intr_t handler, - unsigned long irqflags, unsigned int *irqp) + void *arg, unsigned long irqflags, unsigned int *irqp) { unsigned int irq; int error; Index: sys/xen/reboot.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- sys/xen/reboot.c (revision 190619) +++ sys/xen/reboot.c (working copy) @@ -176,9 +176,9 @@ /* * Bind us to CPU 0 and stop any other VCPUs. */ - mtx_lock_spin(&sched_lock); + thread_lock(curthread); sched_bind(curthread, 0); - mtx_unlock_spin(&sched_lock); + thread_unlock(curthread); KASSERT(PCPU_GET(cpuid) =3D=3D 0, ("xen_suspend: not running on cp= u 0")); map =3D PCPU_GET(other_cpus) & ~stopped_cpus; --=20 Bjoern A. Zeeb The greatest risk is not taking one. --0-2014893890-1238600777=:15361-- From owner-freebsd-current@FreeBSD.ORG Wed Apr 1 16:49:53 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 C2BD21065675; Wed, 1 Apr 2009 16:49:53 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smarthost2.sentex.ca (smarthost2.sentex.ca [205.211.164.50]) by mx1.freebsd.org (Postfix) with ESMTP id 92E798FC18; Wed, 1 Apr 2009 16:49:53 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smtp1.sentex.ca (smtp1.sentex.ca [199.212.134.4]) by smarthost2.sentex.ca (8.14.3/8.14.3) with ESMTP id n31GnmIA006475; Wed, 1 Apr 2009 12:49:48 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp1.sentex.ca (8.14.3/8.14.3) with ESMTP id n31Gnlln054146; Wed, 1 Apr 2009 12:49:47 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 873CE7302F; Wed, 1 Apr 2009 11:49:47 -0500 (EST) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20090401164947.873CE7302F@freebsd-current.sentex.ca> Date: Wed, 1 Apr 2009 11:49:47 -0500 (EST) X-Virus-Scanned: ClamAV 0.94.1/8983/Thu Feb 12 07:48:01 2009 clamav-milter version 0.94.2 on clamscanner2 X-Virus-Status: Clean X-Scanned-By: MIMEDefang 2.64 on 205.211.164.50 Cc: Subject: [head tinderbox] failure on ia64/ia64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Apr 2009 16:49:55 -0000 TB --- 2009-04-01 14:36:51 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2009-04-01 14:36:51 - starting HEAD tinderbox run for ia64/ia64 TB --- 2009-04-01 14:36:51 - cleaning the object tree TB --- 2009-04-01 14:37:32 - cvsupping the source tree TB --- 2009-04-01 14:37:32 - /usr/bin/csup -z -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/ia64/ia64/supfile TB --- 2009-04-01 14:37:40 - building world TB --- 2009-04-01 14:37:40 - MAKEOBJDIRPREFIX=/obj TB --- 2009-04-01 14:37:40 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-04-01 14:37:40 - TARGET=ia64 TB --- 2009-04-01 14:37:40 - TARGET_ARCH=ia64 TB --- 2009-04-01 14:37:40 - TZ=UTC TB --- 2009-04-01 14:37:40 - __MAKE_CONF=/dev/null TB --- 2009-04-01 14:37:40 - cd /src TB --- 2009-04-01 14:37:40 - /usr/bin/make -B buildworld >>> World build started on Wed Apr 1 14:37:42 UTC 2009 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Wed Apr 1 16:27:40 UTC 2009 TB --- 2009-04-01 16:27:40 - generating LINT kernel config TB --- 2009-04-01 16:27:40 - cd /src/sys/ia64/conf TB --- 2009-04-01 16:27:40 - /usr/bin/make -B LINT TB --- 2009-04-01 16:27:40 - building LINT kernel TB --- 2009-04-01 16:27:40 - MAKEOBJDIRPREFIX=/obj TB --- 2009-04-01 16:27:40 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-04-01 16:27:40 - TARGET=ia64 TB --- 2009-04-01 16:27:40 - TARGET_ARCH=ia64 TB --- 2009-04-01 16:27:40 - TZ=UTC TB --- 2009-04-01 16:27:40 - __MAKE_CONF=/dev/null TB --- 2009-04-01 16:27:40 - cd /src TB --- 2009-04-01 16:27:40 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Wed Apr 1 16:27:40 UTC 2009 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/ia64/libuwx/src -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mconstant-gp -ffixed-r13 -mfixed-range=f32-f127 -fpic -ffreestanding -Werror vnode_if.c :> hack.c cc -shared -nostdlib hack.c -o hack.So rm -f hack.c MAKE=/usr/bin/make sh /src/sys/conf/newvers.sh LINT cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/ia64/libuwx/src -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mconstant-gp -ffixed-r13 -mfixed-range=f32-f127 -fpic -ffreestanding -Werror vers.c linking kernel freebsd32_sysent.o(.data.rel+0x19d0): undefined reference to `freebsd32_sysarch' *** Error code 1 Stop in /obj/ia64/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2009-04-01 16:49:45 - WARNING: /usr/bin/make returned exit code 1 TB --- 2009-04-01 16:49:45 - ERROR: failed to build lint kernel TB --- 2009-04-01 16:49:45 - 6522.28 user 458.22 system 7973.66 real http://tinderbox.des.no/tinderbox-head-HEAD-ia64-ia64.full From owner-freebsd-current@FreeBSD.ORG Wed Apr 1 16:58:51 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 68F28106566C for ; Wed, 1 Apr 2009 16:58:51 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.terabit.net.ua (mail.terabit.net.ua [195.137.202.147]) by mx1.freebsd.org (Postfix) with ESMTP id 031BA8FC18 for ; Wed, 1 Apr 2009 16:58:50 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from skuns.zoral.com.ua ([91.193.166.194] helo=mail.zoral.com.ua) by mail.terabit.net.ua with esmtps (TLSv1:AES256-SHA:256) (Exim 4.63 (FreeBSD)) (envelope-from ) id 1Lp3m5-000Ejh-7p; Wed, 01 Apr 2009 19:58:49 +0300 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 n31GwjPv056313 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 1 Apr 2009 19:58:46 +0300 (EEST) (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 n31Gwj9e083878; Wed, 1 Apr 2009 19:58:45 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.3/8.14.3/Submit) id n31GwjME083877; Wed, 1 Apr 2009 19:58:45 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Wed, 1 Apr 2009 19:58:45 +0300 From: Kostik Belousov To: current@freebsd.org, ia64@freebsd.org Message-ID: <20090401165845.GU31897@deviant.kiev.zoral.com.ua> References: <20090401164947.873CE7302F@freebsd-current.sentex.ca> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="OcTOUf3JcxRJhNXh" Content-Disposition: inline In-Reply-To: <20090401164947.873CE7302F@freebsd-current.sentex.ca> User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-4.4 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua X-Virus-Scanned: mail.terabit.net.ua 1Lp3m5-000Ejh-7p a54c1f8f973787b2c3a32b3bcd954149 X-Terabit: YES Cc: Subject: Re: [head tinderbox] failure on ia64/ia64 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, 01 Apr 2009 16:58:51 -0000 --OcTOUf3JcxRJhNXh Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Apr 01, 2009 at 11:49:47AM -0500, FreeBSD Tinderbox wrote: > TB --- 2009-04-01 14:36:51 - tinderbox 2.6 running on freebsd-current.sen= tex.ca > TB --- 2009-04-01 14:36:51 - starting HEAD tinderbox run for ia64/ia64 > TB --- 2009-04-01 14:36:51 - cleaning the object tree > TB --- 2009-04-01 14:37:32 - cvsupping the source tree > TB --- 2009-04-01 14:37:32 - /usr/bin/csup -z -r 3 -g -L 1 -h localhost -= s /tinderbox/HEAD/ia64/ia64/supfile > TB --- 2009-04-01 14:37:40 - building world > TB --- 2009-04-01 14:37:40 - MAKEOBJDIRPREFIX=3D/obj > TB --- 2009-04-01 14:37:40 - PATH=3D/usr/bin:/usr/sbin:/bin:/sbin > TB --- 2009-04-01 14:37:40 - TARGET=3Dia64 > TB --- 2009-04-01 14:37:40 - TARGET_ARCH=3Dia64 > TB --- 2009-04-01 14:37:40 - TZ=3DUTC > TB --- 2009-04-01 14:37:40 - __MAKE_CONF=3D/dev/null > TB --- 2009-04-01 14:37:40 - cd /src > TB --- 2009-04-01 14:37:40 - /usr/bin/make -B buildworld > >>> World build started on Wed Apr 1 14:37:42 UTC 2009 > >>> Rebuilding the temporary build tree > >>> stage 1.1: legacy release compatibility shims > >>> stage 1.2: bootstrap tools > >>> stage 2.1: cleaning up the object tree > >>> stage 2.2: rebuilding the object tree > >>> stage 2.3: build tools > >>> stage 3: cross tools > >>> stage 4.1: building includes > >>> stage 4.2: building libraries > >>> stage 4.3: make dependencies > >>> stage 4.4: building everything > >>> World build completed on Wed Apr 1 16:27:40 UTC 2009 > TB --- 2009-04-01 16:27:40 - generating LINT kernel config > TB --- 2009-04-01 16:27:40 - cd /src/sys/ia64/conf > TB --- 2009-04-01 16:27:40 - /usr/bin/make -B LINT > TB --- 2009-04-01 16:27:40 - building LINT kernel > TB --- 2009-04-01 16:27:40 - MAKEOBJDIRPREFIX=3D/obj > TB --- 2009-04-01 16:27:40 - PATH=3D/usr/bin:/usr/sbin:/bin:/sbin > TB --- 2009-04-01 16:27:40 - TARGET=3Dia64 > TB --- 2009-04-01 16:27:40 - TARGET_ARCH=3Dia64 > TB --- 2009-04-01 16:27:40 - TZ=3DUTC > TB --- 2009-04-01 16:27:40 - __MAKE_CONF=3D/dev/null > TB --- 2009-04-01 16:27:40 - cd /src > TB --- 2009-04-01 16:27:40 - /usr/bin/make -B buildkernel KERNCONF=3DLINT > >>> Kernel build for LINT started on Wed Apr 1 16:27:40 UTC 2009 > >>> stage 1: configuring the kernel > >>> stage 2.1: cleaning up the object tree > >>> stage 2.2: rebuilding the object tree > >>> stage 2.3: build tools > >>> stage 3.1: making dependencies > >>> stage 3.2: building everything > [...] > cc -c -O2 -pipe -fno-strict-aliasing -std=3Dc99 -Wall -Wredundant-decls= -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith= -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostd= inc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/ia64/libuwx= /src -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-comm= on -finline-limit=3D15000 --param inline-unit-growth=3D100 --param large-fu= nction-growth=3D1000 -fno-builtin -mconstant-gp -ffixed-r13 -mfixed-range= =3Df32-f127 -fpic -ffreestanding -Werror vnode_if.c > :> hack.c > cc -shared -nostdlib hack.c -o hack.So > rm -f hack.c > MAKE=3D/usr/bin/make sh /src/sys/conf/newvers.sh LINT > cc -c -O2 -pipe -fno-strict-aliasing -std=3Dc99 -Wall -Wredundant-decls= -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith= -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostd= inc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/ia64/libuwx= /src -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-comm= on -finline-limit=3D15000 --param inline-unit-growth=3D100 --param large-fu= nction-growth=3D1000 -fno-builtin -mconstant-gp -ffixed-r13 -mfixed-range= =3Df32-f127 -fpic -ffreestanding -Werror vers.c > linking kernel > freebsd32_sysent.o(.data.rel+0x19d0): undefined reference to `freebsd32_s= ysarch' > *** Error code 1 >=20 > Stop in /obj/ia64/src/sys/LINT. > *** Error code 1 >=20 > Stop in /src. > *** Error code 1 >=20 > Stop in /src. > TB --- 2009-04-01 16:49:45 - WARNING: /usr/bin/make returned exit code 1= =20 > TB --- 2009-04-01 16:49:45 - ERROR: failed to build lint kernel > TB --- 2009-04-01 16:49:45 - 6522.28 user 458.22 system 7973.66 real This is mine. I will fix it shortly. --OcTOUf3JcxRJhNXh Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (FreeBSD) iEYEARECAAYFAknTnUUACgkQC3+MBN1Mb4gCawCeKadJU4UTGqTarPjFpuERB+At Bw4AoKge1cQxU8VD33+rbKq8XwsLLDjO =jIzE -----END PGP SIGNATURE----- --OcTOUf3JcxRJhNXh-- From owner-freebsd-current@FreeBSD.ORG Wed Apr 1 19:20: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 67478106566C for ; Wed, 1 Apr 2009 19:20:57 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from mail2.fluidhosting.com (mx22.fluidhosting.com [204.14.89.5]) by mx1.freebsd.org (Postfix) with ESMTP id 0DF9F8FC16 for ; Wed, 1 Apr 2009 19:20:56 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: (qmail 19557 invoked by uid 399); 1 Apr 2009 19:20:54 -0000 Received: from localhost (HELO 192-168-15-100.nohostname) (dougb@dougbarton.us@127.0.0.1) by localhost with ESMTPAM; 1 Apr 2009 19:20:54 -0000 X-Originating-IP: 127.0.0.1 X-Sender: dougb@dougbarton.us Message-ID: <49D3BCF2.9000405@FreeBSD.org> Date: Wed, 01 Apr 2009 12:13:54 -0700 From: Doug Barton Organization: http://www.FreeBSD.org/ User-Agent: Thunderbird 2.0.0.21 (X11/20090321) MIME-Version: 1.0 To: Mel Flynn References: <49D1B261.6010406@FreeBSD.org> <200903311025.22219.mel.flynn+fbsd.current@mailing.thruhere.net> <49D27B95.7030209@FreeBSD.org> <200904010813.57167.mel.flynn+fbsd.current@mailing.thruhere.net> In-Reply-To: <200904010813.57167.mel.flynn+fbsd.current@mailing.thruhere.net> X-Enigmail-Version: 0.95.7 OpenPGP: id=D5B2F0FB Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: New rc.d/named features for testing: auto-forwarding and wait on boot 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, 01 Apr 2009 19:20:57 -0000 Mel Flynn wrote: > On Tuesday 31 March 2009 22:22:45 Doug Barton wrote: >> Mel Flynn wrote: >>> I think the hardcoded 127.0.0.1 should be configurable especially >>> considering prepend-domain-nameservers option for dhclient.conf(5). >> I'm not sure you understand the goal. The idea here is to use the >> local resolver first, as a forwarder. If that usage would conflict >> with something that you prepend in dhclient.conf, don't enable both >> options. > > But the local resolver is assumed to be 127.0.0.1, not for example > 192.168.1.10 or ::1. Yes. Not only is that considered "best practice," but the named.conf that comes with the system has: listen-on { 127.0.0.1; }; already. There is no good reason to disable that. Adding additional listen-on statements (or other devices) to have the name server listen on other addresses is fine of course. > I agree prepending a nameserver and autoforward are not > the best combo, I never said that, and I don't believe it. Prepending a _local_ name server with an address other than 127.0.0.1 _is_ a bad idea however. > but it can be handy in case you stop named (free up resources, > you temporarily want) to still be able to resolve (though with a delay). > Either way, you're writing 127.0.0.1 to resolv.conf, yet not setting a listen- > on in named so the two can be out of sync, It's already in the default named.conf, and should be there anyway. > And what happens if the DHCP server cannot be reached within 5 tries, but will > once it's in the background? This is actually a good argument for prepending 127.0.0.1 in dhclient.conf. > Also, rcorder shows NETWORKING before named, yet dhclient after, though with > the changes of (a)sync dhclient lately, I should probably familiarize myself > again with what exactly is done. You need to run 'rcorder -s nostart /etc/rc.d/*' to get a better idea of what's happening. The dhclient script is not run by rc, it's run by another script. hth, Doug -- This .signature sanitized for your protection From owner-freebsd-current@FreeBSD.ORG Wed Apr 1 19:33: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 020E51065670 for ; Wed, 1 Apr 2009 19:33:19 +0000 (UTC) (envelope-from yanefbsd@gmail.com) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.236]) by mx1.freebsd.org (Postfix) with ESMTP id C50BC8FC14 for ; Wed, 1 Apr 2009 19:33:18 +0000 (UTC) (envelope-from yanefbsd@gmail.com) Received: by rv-out-0506.google.com with SMTP id l9so171872rvb.43 for ; Wed, 01 Apr 2009 12:33:18 -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=Hsvy7hJQTCBkzCj8s7AuRf57r/Eep+JfAyTvyG7JToY=; b=k0voTLmtXmIl8nzXuQ/pHhC96bLnBOEWsYMvpuGJnfxKTvz3wM6ndNEM1htnUX9oVV XCfQbnnvKdnnP9C7OXY88hhURfMul4GsdI7619WQR6Qy4II3VwIog4D1nVSvOOllUhF+ smodbpFVXSAcNaAxXhvg0hav73pg+cnTaq4VA= 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=HjklE5QScjjkYljTnofTHICB82DzTV1n5aLYPKP9HoHS2UDVx8x86oGXIe8ChBMlaw WYAS1fx0NG00XkgNmzLlz0S5dMzOP29xOdoVdHoIptbWxIB9NnxP0KSGeujoPbLIRqQb Q44FV70KllE8vtStJZrzEqO/Nsn4i3jQqSISw= MIME-Version: 1.0 Received: by 10.141.36.10 with SMTP id o10mr4150897rvj.237.1238614397533; Wed, 01 Apr 2009 12:33:17 -0700 (PDT) In-Reply-To: References: <95891.1238477069@critter.freebsd.dk> <20090331133132.1e191836@ernst.jennejohn.org> <20090331155542.74d89d64@ernst.jennejohn.org> <60084D1E-9F64-463A-A8E9-7A237D5C7661@mac.com> <0904011910169.29800@www.mmlab.cse.yzu.edu.tw> Date: Wed, 1 Apr 2009 12:33:17 -0700 Message-ID: <7d6fde3d0904011233v758d337am5e4252adbe5cf58a@mail.gmail.com> From: Garrett Cooper To: Marcel Moolenaar Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Tai-hwa Liang , freebsd-current@freebsd.org Subject: Re: Removal of GEOM_BSD, GEOM_MBR, GEOM_PC98 and GEOM_SUNLABEL 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, 01 Apr 2009 19:33:19 -0000 On Wed, Apr 1, 2009 at 8:25 AM, Marcel Moolenaar wrote: > > On Apr 1, 2009, at 4:16 AM, Tai-hwa Liang wrote: > >> that's too bad. =A0Since my /home is sitting on the extended partition, >> the OS won't boot unless the kernel is built with various GEOM_PART_ >> removed from i386/conf/DEFAULT plus GEOM_{BSD,MBR} added back to the >> kernel configuration file(ie: GENERIC kernel cvsup'ed today doesn't >> boot). > > That sounds like a bug, because logical partitions are > supported. Can you enable GEOM_PART_BSD, GEOM_PART_EBR > and GEOM_PART_MBR and tell me which GEOMs are available > at the mount root prompt? Wait -- you're saying with the new change I'd have to shuffle around my data, redo my 3.5 TB RAID6 array, then shuffle it all back, etc? [gcooper@optimus ~]$ gpart show =3D> 63 312581745 ad4 MBR (149G) 63 134319402 1 freebsd [active] (64G) 134319465 178257240 2 freebsd (85G) 312576705 5103 - free - (2.5M) =3D> 0 134319402 ad4s1 BSD (64G) 0 16777216 2 freebsd-swap (8.0G) 16777216 16777216 1 freebsd-ufs (8.0G) 33554432 16777216 5 freebsd-ufs (8.0G) 50331648 33554432 6 freebsd-ufs (16G) 83886080 16777216 7 freebsd-ufs (8.0G) 100663296 16777216 8 freebsd-ufs (8.0G) 117440512 16878890 4 freebsd-ufs (8.0G) =3D> 0 178257240 ad4s2 BSD (85G) 0 16777216 4 freebsd-ufs (8.0G) 16777216 161480024 5 freebsd-ufs (77G) =3D> 63 4394465208 da0 MBR (2.0T) 63 4294961622 1 !131 [active] (2.0T) 4294961685 99503586 - free - (47G) Btw, what's the replacement for GEOM_* that's getting removed? Thanks, -Garrett From owner-freebsd-current@FreeBSD.ORG Wed Apr 1 19:35: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 83DD41065675 for ; Wed, 1 Apr 2009 19:35:50 +0000 (UTC) (envelope-from yanefbsd@gmail.com) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.236]) by mx1.freebsd.org (Postfix) with ESMTP id 525AC8FC15 for ; Wed, 1 Apr 2009 19:35:50 +0000 (UTC) (envelope-from yanefbsd@gmail.com) Received: by rv-out-0506.google.com with SMTP id l9so172979rvb.43 for ; Wed, 01 Apr 2009 12:35:50 -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=YQKKtvISyBGd+2Vup5VcJpjk1ygt1rC0SFn4ksp3fbs=; b=GVlSMi17Rluu2Y413GC0POFlhm5whd5ndMIy75m7CeLcl0q0IAy0L1zai3ijazfvd2 7/jmStozG/zBU9ovBJWqq94kU3VJTo6gobJYIQhoHKUq/D83ixE1hHld7KG3UsusU/2j snHAOiVUZR1B19uyI85LiOuBHnfPQJO4LKWQc= 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=ZiA3SVDgewc54/ghsdho+6AAVDYgOTKAJJ+JOPo8DCJnYRukEHI/ibdabkx78ptmVj 53QCTQor6YI6nWk5mdMvJB5Pii4I2UwQ1T900iM7fn3NPVCDVL1Ga664WPdCLPyhhfzs Hqs7vAGA7FWHHjzqBjbX5X8a0nmbyeZnlfyEA= MIME-Version: 1.0 Received: by 10.141.48.10 with SMTP id a10mr4149504rvk.250.1238614550057; Wed, 01 Apr 2009 12:35:50 -0700 (PDT) In-Reply-To: <7d6fde3d0904011233v758d337am5e4252adbe5cf58a@mail.gmail.com> References: <95891.1238477069@critter.freebsd.dk> <20090331133132.1e191836@ernst.jennejohn.org> <20090331155542.74d89d64@ernst.jennejohn.org> <60084D1E-9F64-463A-A8E9-7A237D5C7661@mac.com> <0904011910169.29800@www.mmlab.cse.yzu.edu.tw> <7d6fde3d0904011233v758d337am5e4252adbe5cf58a@mail.gmail.com> Date: Wed, 1 Apr 2009 12:35:50 -0700 Message-ID: <7d6fde3d0904011235x404fc7dbo1918d3dbe7ed645a@mail.gmail.com> From: Garrett Cooper To: Marcel Moolenaar Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Tai-hwa Liang , freebsd-current@freebsd.org Subject: Re: Removal of GEOM_BSD, GEOM_MBR, GEOM_PC98 and GEOM_SUNLABEL 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, 01 Apr 2009 19:35:50 -0000 On Wed, Apr 1, 2009 at 12:33 PM, Garrett Cooper wrote: > On Wed, Apr 1, 2009 at 8:25 AM, Marcel Moolenaar wrote: >> >> On Apr 1, 2009, at 4:16 AM, Tai-hwa Liang wrote: >> >>> that's too bad. =A0Since my /home is sitting on the extended partition, >>> the OS won't boot unless the kernel is built with various GEOM_PART_ >>> removed from i386/conf/DEFAULT plus GEOM_{BSD,MBR} added back to the >>> kernel configuration file(ie: GENERIC kernel cvsup'ed today doesn't >>> boot). >> >> That sounds like a bug, because logical partitions are >> supported. Can you enable GEOM_PART_BSD, GEOM_PART_EBR >> and GEOM_PART_MBR and tell me which GEOMs are available >> at the mount root prompt? > > Wait -- you're saying with the new change I'd have to shuffle around > my data, redo my 3.5 TB RAID6 array, then shuffle it all back, etc? > > [gcooper@optimus ~]$ gpart show > =3D> =A0 =A0 =A0 63 =A0312581745 =A0ad4 =A0MBR =A0(149G) > =A0 =A0 =A0 =A0 63 =A0134319402 =A0 =A01 =A0freebsd =A0[active] =A0(64G) > =A0134319465 =A0178257240 =A0 =A02 =A0freebsd =A0(85G) > =A0312576705 =A0 =A0 =A0 5103 =A0 =A0 =A0 - free - =A0(2.5M) > > =3D> =A0 =A0 =A0 =A00 =A0134319402 =A0ad4s1 =A0BSD =A0(64G) > =A0 =A0 =A0 =A0 =A00 =A0 16777216 =A0 =A0 =A02 =A0freebsd-swap =A0(8.0G) > =A0 16777216 =A0 16777216 =A0 =A0 =A01 =A0freebsd-ufs =A0(8.0G) > =A0 33554432 =A0 16777216 =A0 =A0 =A05 =A0freebsd-ufs =A0(8.0G) > =A0 50331648 =A0 33554432 =A0 =A0 =A06 =A0freebsd-ufs =A0(16G) > =A0 83886080 =A0 16777216 =A0 =A0 =A07 =A0freebsd-ufs =A0(8.0G) > =A0100663296 =A0 16777216 =A0 =A0 =A08 =A0freebsd-ufs =A0(8.0G) > =A0117440512 =A0 16878890 =A0 =A0 =A04 =A0freebsd-ufs =A0(8.0G) > > =3D> =A0 =A0 =A0 =A00 =A0178257240 =A0ad4s2 =A0BSD =A0(85G) > =A0 =A0 =A0 =A0 =A00 =A0 16777216 =A0 =A0 =A04 =A0freebsd-ufs =A0(8.0G) > =A0 16777216 =A0161480024 =A0 =A0 =A05 =A0freebsd-ufs =A0(77G) > > =3D> =A0 =A0 =A0 =A063 =A04394465208 =A0da0 =A0MBR =A0(2.0T) > =A0 =A0 =A0 =A0 =A063 =A04294961622 =A0 =A01 =A0!131 =A0[active] =A0(2.0T= ) > =A04294961685 =A0 =A099503586 =A0 =A0 =A0 - free - =A0(47G) > > Btw, what's the replacement for GEOM_* that's getting removed? Or to sum it up a bit better: 1. What's getting removed and why? 2. What's it being replaced with? 3. How do I migrate from the old system to the new one? I don't see that information in the initial warning email. Thanks, -Garrett From owner-freebsd-current@FreeBSD.ORG Wed Apr 1 19:44: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 A325C1065674 for ; Wed, 1 Apr 2009 19:44:37 +0000 (UTC) (envelope-from xcllnt@mac.com) Received: from asmtpout014.mac.com (asmtpout014.mac.com [17.148.16.89]) by mx1.freebsd.org (Postfix) with ESMTP id 883BD8FC13 for ; Wed, 1 Apr 2009 19:44:37 +0000 (UTC) (envelope-from xcllnt@mac.com) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=US-ASCII; format=flowed Received: from sivam-t43.jnpr.net (natint3.juniper.net [66.129.224.36]) by asmtp014.mac.com (Sun Java(tm) System Messaging Server 6.3-8.01 (built Dec 16 2008; 32bit)) with ESMTPSA id <0KHF00GJJTI46030@asmtp014.mac.com> for freebsd-current@freebsd.org; Wed, 01 Apr 2009 12:44:28 -0700 (PDT) Message-id: <94ABEC6B-4AC5-4350-B111-AD9795D4F2ED@mac.com> From: Marcel Moolenaar To: Garrett Cooper In-reply-to: <7d6fde3d0904011235x404fc7dbo1918d3dbe7ed645a@mail.gmail.com> Date: Wed, 01 Apr 2009 12:44:27 -0700 References: <95891.1238477069@critter.freebsd.dk> <20090331133132.1e191836@ernst.jennejohn.org> <20090331155542.74d89d64@ernst.jennejohn.org> <60084D1E-9F64-463A-A8E9-7A237D5C7661@mac.com> <0904011910169.29800@www.mmlab.cse.yzu.edu.tw> <7d6fde3d0904011233v758d337am5e4252adbe5cf58a@mail.gmail.com> <7d6fde3d0904011235x404fc7dbo1918d3dbe7ed645a@mail.gmail.com> X-Mailer: Apple Mail (2.930.3) Cc: Tai-hwa Liang , freebsd-current@freebsd.org Subject: Re: Removal of GEOM_BSD, GEOM_MBR, GEOM_PC98 and GEOM_SUNLABEL 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, 01 Apr 2009 19:44:38 -0000 On Apr 1, 2009, at 12:35 PM, Garrett Cooper wrote: >>> That sounds like a bug, because logical partitions are >>> supported. Can you enable GEOM_PART_BSD, GEOM_PART_EBR >>> and GEOM_PART_MBR and tell me which GEOMs are available >>> at the mount root prompt? >> >> Wait -- you're saying with the new change I'd have to shuffle around >> my data, redo my 3.5 TB RAID6 array, then shuffle it all back, etc? No! hint: GEOM_MBR is not GEOM_PART_MBR. >> > Or to sum it up a bit better: > 1. What's getting removed and why? GEOM_BSD, GEOM_MBR, GEOM_PC98 and GEOM_SUNLABEL They're so yesterday. > 2. What's it being replaced with? GEOM_PART_BSD, GEOM_PART_MBR, GEOM_PART_PC98 and GEOM_PART_VTOC8 > 3. How do I migrate from the old system to the new one? No migration is needed. You already use the new kernel options. All I'm doing is remove the old not-to-be-used options. FYI, -- Marcel Moolenaar xcllnt@mac.com From owner-freebsd-current@FreeBSD.ORG Wed Apr 1 21:33: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 B8379106566B for ; Wed, 1 Apr 2009 21:33:59 +0000 (UTC) (envelope-from juhasaarinen@gmail.com) Received: from ti-out-0910.google.com (ti-out-0910.google.com [209.85.142.190]) by mx1.freebsd.org (Postfix) with ESMTP id 551138FC25 for ; Wed, 1 Apr 2009 21:33:59 +0000 (UTC) (envelope-from juhasaarinen@gmail.com) Received: by ti-out-0910.google.com with SMTP id u5so203825tia.3 for ; Wed, 01 Apr 2009 14:33: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:content-type :content-transfer-encoding; bh=yMDC5sV1a442DUXxWfS5U8hYz8K1yuozlJRAYUcK88I=; b=hDGQhKsnF6Axucgg7kYdAZedr1/DIBO/QuK5LrrQpiqtPL1yaTZpWMXVhIJVT8e3Rb GlUNcwD1dUpWTTIeOg7kmFblIgcSnv+Ws2fLMJ1wq1M8v9cwz1ZOXTs222Jnhxh1xPcB uErW7bkYvL6klJgaP/dOTDyKWdwKOWDoIoLH4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; b=oQ/HChx51eSNXlLE8TsLvDHA55ExAhe7O/D5hF3u7nRMZq+mR/i1PxnGzHegNafcoa QJQGULxqF7lQAaU8+CZISAjjVy0eOt59WIaovw6cPYb80jk9WVK4AM+lkzCst6AJbxcG +f+OnXQByCcLqp2OCZeRQNNGwjiqrVsBTtLfw= MIME-Version: 1.0 Received: by 10.110.63.17 with SMTP id l17mr1514988tia.3.1238620063567; Wed, 01 Apr 2009 14:07:43 -0700 (PDT) In-Reply-To: References: <20081223013626.2833a911@baby-jane> <20081223010902.GB1072@in-addr.com> Date: Thu, 2 Apr 2009 10:07:43 +1300 Message-ID: From: Juha Saarinen To: FreeBSD Current Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: Kip Macy 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, 01 Apr 2009 21:34:00 -0000 Motion for dismissal of Kip Macy's indictment: http://www.scribd.com/doc/13481284/Kip-Macys-995-Absurd-Indictment -- Juha http://www.techsploder.com From owner-freebsd-current@FreeBSD.ORG Wed Apr 1 23:43: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 3E920106566C for ; Wed, 1 Apr 2009 23:43:34 +0000 (UTC) (envelope-from dgerow@afflictions.org) Received: from relay3-v.mail.gandi.net (relay3-v.mail.gandi.net [217.70.178.77]) by mx1.freebsd.org (Postfix) with ESMTP id CC8428FC14 for ; Wed, 1 Apr 2009 23:43:33 +0000 (UTC) (envelope-from dgerow@afflictions.org) Received: from plebeian.afflictions.org (CPE0021296fd1ec-CM0019475d4056.cpe.net.cable.rogers.com [99.241.164.229]) by relay3-v.mail.gandi.net (Postfix) with ESMTP id 9B122BA19 for ; Thu, 2 Apr 2009 01:43:32 +0200 (CEST) Received: by plebeian.afflictions.org (Postfix, from userid 1001) id F251A41E0; Wed, 1 Apr 2009 19:43:15 -0400 (EDT) Date: Wed, 1 Apr 2009 19:43:15 -0400 From: Damian Gerow To: freebsd-current@freebsd.org Message-ID: <20090401234315.GA11125@plebeian.afflictions.org> References: <49BD117B.2080706@163.com> <20090331100328.H46640@rust.salford.ac.uk> <20090401044011.GA51164@plebeian.afflictions.org> <200904010846.55770.hselasky@c2i.net> <20090401121704.GA92522@plebeian.afflictions.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20090401121704.GA92522@plebeian.afflictions.org> User-Agent: Mutt/1.5.19 (2009-01-05) Subject: Re: ZFS checksum errors on USB attach (Was: ZFS data error without reasons) 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, 01 Apr 2009 23:43:34 -0000 Damian Gerow wrote: : : > I walked over to my laptop (Lenovo X200), and plugged in a Cowon D2 to : : > charge up the battery. When I tried to do other things, I received a large : : > number of input/output errors, so I knew I'd triggered the bug. Two things : : > that I tried to do: : : : : If you unload "umass" and plug a memory stick, do you see the same behaviour : : then? : : : : Maybe it is not directly USB related. : : I had previously been unable to produce the same symptoms immediately : following a reboot, with no USB-related modules loaded. I will give it : another try later today to confirm. umass is compiled in to the kernel by default. It's not a module I can load and unload (that I'm aware of, anyhow). So I tried plugging the D2 in, and it didn't cause any troubles. But I wasn't running transmission -- so I started transmission up, plugged the D2 in again, and lo and behold, ZFS checksum errors: ----- Apr 1 19:37:24 plebeian kernel: da1 at umass-sim0 bus 0 target 0 lun 1 Apr 1 19:37:24 plebeian kernel: da1: Removable Direct Access SCSI-0 device Apr 1 19:37:24 plebeian kernel: da1: 40.000MB/s transfers Apr 1 19:37:24 plebeian kernel: da1: 15359MB (31456320 512 byte sectors: 255H 63S/T 1958C) Apr 1 19:37:24 plebeian kernel: GEOM_LABEL: Label for provider da0 is msdosfs/D2. Apr 1 19:37:24 plebeian kernel: GEOM: da1: partition 1 does not start on a track boundary. Apr 1 19:37:24 plebeian kernel: GEOM: da1: partition 1 does not end on a track boundary. Apr 1 19:37:29 plebeian root: ZFS: checksum mismatch, zpool=storage path=/dev/ad4s1d.eli offset=107774476288 size=131072 Apr 1 19:37:29 plebeian root: ZFS: checksum mismatch, zpool=storage path=/dev/ad4s1d.eli offset=107774476288 size=131072 Apr 1 19:37:29 plebeian root: ZFS: zpool I/O failure, zpool=storage error=86 ----- However, the errors are ocurring far less quickly than normal. Could just be coincidence, but I doubt it: closing firefox didn't result in a core dump, but in a proper shutdown procedure. So, this seems to be related to ZFS, and possibly the number of files it has open? Pure speculation on my part, but I only seem to be able to trigger this bug when transmission is open: the only torrent it has loaded is something like 200 files, and 30GB. - Damian From owner-freebsd-current@FreeBSD.ORG Thu Apr 2 00:27: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 644A8106566B for ; Thu, 2 Apr 2009 00:27:13 +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 ED0B58FC15 for ; Thu, 2 Apr 2009 00:27:12 +0000 (UTC) (envelope-from wblock@wonkity.com) Received: from wonkity.com (localhost [127.0.0.1]) by wonkity.com (8.14.3/8.14.3) with ESMTP id n320RCkE036431; Wed, 1 Apr 2009 18:27:12 -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 n320RB2m036428; Wed, 1 Apr 2009 18:27:11 -0600 (MDT) (envelope-from wblock@wonkity.com) Date: Wed, 1 Apr 2009 18:27:11 -0600 (MDT) From: User Wblock To: Andriy Gapon In-Reply-To: <49D1C3E6.3050207@icyb.net.ua> Message-ID: References: <4451ccf20903300123p4df9c1d7k4c4138ad25d2d4af@mail.gmail.com> <49D0E44C.60103@phat.za.net> <49D1001E.2050405@icyb.net.ua> <49D1C3E6.3050207@icyb.net.ua> 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.0.1 (wonkity.com [127.0.0.1]); Wed, 01 Apr 2009 18:27:12 -0600 (MDT) Cc: Aragon Gouveia , ccuiyyan@gmail.com, freebsd-current@freebsd.org Subject: Re: loader prompt doesn't work 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, 02 Apr 2009 00:27:13 -0000 On Tue, 31 Mar 2009, Andriy Gapon wrote: > on 31/03/2009 03:50 User Wblock said the following: >> On Mon, 30 Mar 2009, Andriy Gapon wrote: >>> There was a significant fix to boot code made recently by jhb. It is >>> now in head, stable/7 and stable/6. So you need to update to the >>> recent resources. What you also need (and what was not emphasized >>> enough, IMO) is to actually install new boot code (/boot/boot) to >>> your active slices after installworld completes. >>> >>> E.g.: >>> $ gpart bootcode -b /boot/boot adXsY >> >> The gpart manpage just makes me more confused about this. > > Your reply is quite confusing too - you put many different things into > the same heap. Okay, I'll try again. >> I don't know >> what a "protective" MBR is, or if I've got one. > > If you think that you have to know, then google is your friend. The question is "How can I tell if 'gpart bootcode -b /boot/boot adXsY'? is needed? The gpart man page is apparently not the place to start. >> Can you expand on this a little? > > On "this" what? On your statement above: >>> What you also need (and what was not emphasized enough, IMO) is to >>> actually install new boot code (/boot/boot) to your active slices >>> after installworld completes. Would it be more accurate if that sentence read: "What you also need *if you experience problems with the boot loader prompt* (and what was not emphasized enough, IMO)..." >> For instance: >> >> * When did it happen? > > "it" what? >>> There was a significant fix to boot code made recently by jhb. Hoping for something more specific than "recently". >> * Who needs to do this--everyone who has updated to a recent -CURRENT or >> -STABLE? > > If you don't have the problems described earlier in this thread than you > don't have to do anything. Does not having the problem mean the latest boot code is in place, or just that the particular system hasn't triggered the problem? Is there a way to tell if the installed boot code is up to date? >> Or just those using certain partitioning features? >> * There's no mention in /usr/src/UPDATING. Was it mentioned anywhere? -Warren Block * Rapid City, South Dakota USA From owner-freebsd-current@FreeBSD.ORG Thu Apr 2 01:44: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 B26FD106566C for ; Thu, 2 Apr 2009 01:44:58 +0000 (UTC) (envelope-from avatar@mmlab.cse.yzu.edu.tw) Received: from www.mmlab.cse.yzu.edu.tw (www.mmlab.cse.yzu.edu.tw [140.138.150.166]) by mx1.freebsd.org (Postfix) with ESMTP id A5A668FC12 for ; Thu, 2 Apr 2009 01:44:57 +0000 (UTC) (envelope-from avatar@mmlab.cse.yzu.edu.tw) Received: by www.mmlab.cse.yzu.edu.tw (qmail, from userid 1000) id 14EDAE43407; Thu, 2 Apr 2009 09:44:35 +0800 (CST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=mmlab.cse.yzu.edu.tw; s=test; t=1238636675; bh=u62N/jpDgEU5GYfu21q0wTZjTejg4DyxyfqW0bJY6Pg=; h=Date:From:To:cc:Subject:In-Reply-To:Message-ID:References: MIME-Version:Content-Type; b=sXroBf6rRRFaSuFeHDhLwd5IQIn1XGj+lXMqGENbpGDtoE9fKIM9aewmKDBh8E+GS E4b63/pwz4smZ+HsVsC7rhjFEa+DEyM8S280b8yOxshkO3/ERJLg8OhLEHGcd94pkL tCJjk5q5tZ0RSnPnkN6ZK20rMaEHiuCdqqoci1i0= Received: from localhost (localhost [127.0.0.1]) by www.mmlab.cse.yzu.edu.tw (qmail) with ESMTP id 14954E43406; Thu, 2 Apr 2009 09:44:35 +0800 (CST) Date: Thu, 2 Apr 2009 09:44:35 +0800 (CST) From: Tai-hwa Liang To: Marcel Moolenaar In-Reply-To: Message-ID: <0904020940371.36257@www.mmlab.cse.yzu.edu.tw> References: <95891.1238477069@critter.freebsd.dk> <20090331133132.1e191836@ernst.jennejohn.org> <20090331155542.74d89d64@ernst.jennejohn.org> <60084D1E-9F64-463A-A8E9-7A237D5C7661@mac.com> <0904011910169.29800@www.mmlab.cse.yzu.edu.tw> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-current@freebsd.org Subject: Re: Removal of GEOM_BSD, GEOM_MBR, GEOM_PC98 and GEOM_SUNLABEL 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, 02 Apr 2009 01:44:58 -0000 On Wed, 1 Apr 2009, Marcel Moolenaar wrote: > > On Apr 1, 2009, at 4:16 AM, Tai-hwa Liang wrote: > >> that's too bad. Since my /home is sitting on the extended partition, >> the OS won't boot unless the kernel is built with various GEOM_PART_ >> removed from i386/conf/DEFAULT plus GEOM_{BSD,MBR} added back to the >> kernel configuration file(ie: GENERIC kernel cvsup'ed today doesn't >> boot). > > That sounds like a bug, because logical partitions are > supported. Can you enable GEOM_PART_BSD, GEOM_PART_EBR > and GEOM_PART_MBR and tell me which GEOMs are available > at the mount root prompt? Following are what gpart sees with a GEOM_PART_{BSD,EBR,MBR} and GEOM_{BSD,MBR} enabled kernel: # gpart show => 63 228338775 ad0 MBR (109G) 63 18688257 1 !12 (8.9G) 18688320 16783200 2 freebsd [active] (8.0G) 35471520 192855600 3 !15 (92G) 228327120 11718 - free - (5.7M) => 0 16783200 ad0s2c BSD (8.0G) 0 786432 1 freebsd-ufs (384M) 786432 4194304 2 freebsd-swap (2.0G) 4980736 393216 4 freebsd-ufs (192M) 5373952 11409248 5 freebsd-ufs (5.4G) # gpart list Geom name: ad0 fwheads: 16 fwsectors: 63 last: 228338837 first: 63 entries: 4 scheme: MBR Providers: 1. Name: ad0s1 Mediasize: 9568387584 (8.9G) Sectorsize: 512 Mode: r0w0e0 rawtype: 12 length: 9568387584 offset: 32256 type: !12 index: 1 end: 18688319 start: 63 2. Name: ad0s2 Mediasize: 8592998400 (8.0G) Sectorsize: 512 Mode: r3w3e3 attrib: active rawtype: 165 length: 8592998400 offset: 9568419840 type: freebsd index: 2 end: 35471519 start: 18688320 3. Name: ad0s3 Mediasize: 98742067200 (92G) Sectorsize: 512 Mode: r0w0e0 rawtype: 15 length: 98742067200 offset: 18161418240 type: !15 index: 3 end: 228327119 start: 35471520 Consumers: 1. Name: ad0 Mediasize: 116909491200 (109G) Sectorsize: 512 Mode: r3w3e6 Geom name: ad0s2c fwheads: 16 fwsectors: 63 last: 16783199 first: 0 entries: 8 scheme: BSD Providers: 1. Name: ad0s2ca Mediasize: 402653184 (384M) Sectorsize: 512 Mode: r0w0e0 rawtype: 7 length: 402653184 offset: 0 type: freebsd-ufs index: 1 end: 786431 start: 0 2. Name: ad0s2cb Mediasize: 2147483648 (2.0G) Sectorsize: 512 Mode: r0w0e0 rawtype: 1 length: 2147483648 offset: 402653184 type: freebsd-swap index: 2 end: 4980735 start: 786432 3. Name: ad0s2cd Mediasize: 201326592 (192M) Sectorsize: 512 Mode: r0w0e0 rawtype: 7 length: 201326592 offset: 2550136832 type: freebsd-ufs index: 4 end: 5373951 start: 4980736 4. Name: ad0s2ce Mediasize: 5841534976 (5.4G) Sectorsize: 512 Mode: r0w0e0 rawtype: 7 length: 5841534976 offset: 2751463424 type: freebsd-ufs index: 5 end: 16783199 start: 5373952 Consumers: 1. Name: ad0s2c Mediasize: 8592998400 (8.0G) Sectorsize: 512 Mode: r0w0e0 Not sure if that's correct but I did not see something like "scheme: EBR" in gpart list. -- Thanks, Tai-hwa Liang From owner-freebsd-current@FreeBSD.ORG Thu Apr 2 02:11: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 E2FE2106564A for ; Thu, 2 Apr 2009 02:11:37 +0000 (UTC) (envelope-from xcllnt@mac.com) Received: from asmtpout021.mac.com (asmtpout021.mac.com [17.148.16.96]) by mx1.freebsd.org (Postfix) with ESMTP id CA1CF8FC08 for ; Thu, 2 Apr 2009 02:11:37 +0000 (UTC) (envelope-from xcllnt@mac.com) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Received: from MacBook-Pro.lan.xcllnt.net (mail.xcllnt.net [75.101.29.67]) by asmtp021.mac.com (Sun Java(tm) System Messaging Server 6.3-8.01 (built Dec 16 2008; 32bit)) with ESMTPSA id <0KHG002GDBF4P080@asmtp021.mac.com> for freebsd-current@freebsd.org; Wed, 01 Apr 2009 19:11:29 -0700 (PDT) Message-id: <4CCDEFD6-830E-4C8F-B7A2-B7878F8842BE@mac.com> From: Marcel Moolenaar To: Tai-hwa Liang In-reply-to: <0904020940371.36257@www.mmlab.cse.yzu.edu.tw> Date: Wed, 01 Apr 2009 19:11:26 -0700 References: <95891.1238477069@critter.freebsd.dk> <20090331133132.1e191836@ernst.jennejohn.org> <20090331155542.74d89d64@ernst.jennejohn.org> <60084D1E-9F64-463A-A8E9-7A237D5C7661@mac.com> <0904011910169.29800@www.mmlab.cse.yzu.edu.tw> <0904020940371.36257@www.mmlab.cse.yzu.edu.tw> X-Mailer: Apple Mail (2.930.3) Cc: freebsd-current@freebsd.org Subject: Re: Removal of GEOM_BSD, GEOM_MBR, GEOM_PC98 and GEOM_SUNLABEL 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, 02 Apr 2009 02:11:38 -0000 On Apr 1, 2009, at 6:44 PM, Tai-hwa Liang wrote: > On Wed, 1 Apr 2009, Marcel Moolenaar wrote: >> >> On Apr 1, 2009, at 4:16 AM, Tai-hwa Liang wrote: >> >>> that's too bad. Since my /home is sitting on the extended >>> partition, >>> the OS won't boot unless the kernel is built with various GEOM_PART_ >>> removed from i386/conf/DEFAULT plus GEOM_{BSD,MBR} added back to the >>> kernel configuration file(ie: GENERIC kernel cvsup'ed today doesn't >>> boot). >> >> That sounds like a bug, because logical partitions are >> supported. Can you enable GEOM_PART_BSD, GEOM_PART_EBR >> and GEOM_PART_MBR and tell me which GEOMs are available >> at the mount root prompt? > > Following are what gpart sees with a GEOM_PART_{BSD,EBR,MBR} and > GEOM_{BSD,MBR} enabled kernel: Please remove GEOM_{BSD,MBR} when enabling GEOM_PART_{BSD,EBR,MBR} (and vice versa) and let me know how things look then. Thanks, -- Marcel Moolenaar xcllnt@mac.com From owner-freebsd-current@FreeBSD.ORG Thu Apr 2 02:50: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 41F9E1065670 for ; Thu, 2 Apr 2009 02:50:40 +0000 (UTC) (envelope-from wilkinsa@stlux550.dsto.defence.gov.au) Received: from digger1.defence.gov.au (digger1.defence.gov.au [203.5.217.4]) by mx1.freebsd.org (Postfix) with ESMTP id 919028FC14 for ; Thu, 2 Apr 2009 02:50:39 +0000 (UTC) (envelope-from wilkinsa@stlux550.dsto.defence.gov.au) Received: from ednmsw520.dsto.defence.gov.au (ednmsw520.dsto.defence.gov.au [131.185.68.60]) by digger1.defence.gov.au (DSTO/DSTO) with ESMTP id n322jt4U020706 for ; Thu, 2 Apr 2009 12:15:55 +0930 (CST) Received: from ednex510.dsto.defence.gov.au (ednex510.dsto.defence.gov.au) by ednmsw520.dsto.defence.gov.au (Clearswift SMTPRS 5.3.1) with ESMTP id for ; Thu, 2 Apr 2009 13:20:37 +1030 Received: from stlex511.dsto.defence.gov.au ([203.6.60.49]) by ednex510.dsto.defence.gov.au with Microsoft SMTPSVC(6.0.3790.3959); Thu, 2 Apr 2009 13:20:37 +1030 Received: from stlux550.dsto.defence.gov.au ([203.6.60.61]) by stlex511.dsto.defence.gov.au with Microsoft SMTPSVC(6.0.3790.3959); Thu, 2 Apr 2009 10:50:27 +0800 Received: from stlux550.dsto.defence.gov.au (localhost [127.0.0.1]) by stlux550.dsto.defence.gov.au (8.14.3/8.14.3) with ESMTP id n322oLBf002788 for ; Thu, 2 Apr 2009 10:50:21 +0800 (WST) (envelope-from wilkinsa@stlux550.dsto.defence.gov.au) Received: (from wilkinsa@localhost) by stlux550.dsto.defence.gov.au (8.14.3/8.14.3/Submit) id n322oLZE002787 for freebsd-current@freebsd.org; Thu, 2 Apr 2009 10:50:21 +0800 (WST) (envelope-from wilkinsa) Date: Thu, 2 Apr 2009 10:50:21 +0800 From: "Wilkinson, Alex" To: freebsd-current@freebsd.org Message-ID: <20090402025021.GD2351@stlux503.dsto.defence.gov.au> Mail-Followup-To: freebsd-current@freebsd.org References: <95891.1238477069@critter.freebsd.dk> <20090331133132.1e191836@ernst.jennejohn.org> <20090331155542.74d89d64@ernst.jennejohn.org> <60084D1E-9F64-463A-A8E9-7A237D5C7661@mac.com> <0904011910169.29800@www.mmlab.cse.yzu.edu.tw> <7d6fde3d0904011233v758d337am5e4252adbe5cf58a@mail.gmail.com> <7d6fde3d0904011235x404fc7dbo1918d3dbe7ed645a@mail.gmail.com> <94ABEC6B-4AC5-4350-B111-AD9795D4F2ED@mac.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline In-Reply-To: <94ABEC6B-4AC5-4350-B111-AD9795D4F2ED@mac.com> Organisation: Defence Science Technology Organisation User-Agent: Mutt/1.5.18 (2008-05-17) X-OriginalArrivalTime: 02 Apr 2009 02:50:27.0205 (UTC) FILETIME=[C7222350:01C9B33D] X-TM-AS-Product-Ver: SMEX-7.0.0.1584-5.6.1016-16554.007 X-TM-AS-Result: No-0.570500-0.000000-31 X-TM-AS-User-Approved-Sender: No X-TM-AS-User-Blocked-Sender: No Content-Transfer-Encoding: 7bit Subject: Re: Removal of GEOM_BSD, GEOM_MBR, GEOM_PC98 and GEOM_SUNLABEL 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, 02 Apr 2009 02:50:40 -0000 0n Wed, Apr 01, 2009 at 12:44:27PM -0700, Marcel Moolenaar wrote: >> 2. What's it being replaced with? > >GEOM_PART_BSD, GEOM_PART_MBR, GEOM_PART_PC98 and >GEOM_PART_VTOC8 Why ? -aW IMPORTANT: This email remains the property of the Australian Defence Organisation and is subject to the jurisdiction of section 70 of the CRIMES ACT 1914. If you have received this email in error, you are requested to contact the sender and delete the email. From owner-freebsd-current@FreeBSD.ORG Thu Apr 2 05:17: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 54AFB1065672 for ; Thu, 2 Apr 2009 05:17:21 +0000 (UTC) (envelope-from avatar@mmlab.cse.yzu.edu.tw) Received: from www.mmlab.cse.yzu.edu.tw (www.mmlab.cse.yzu.edu.tw [140.138.150.166]) by mx1.freebsd.org (Postfix) with ESMTP id A90008FC13 for ; Thu, 2 Apr 2009 05:17:19 +0000 (UTC) (envelope-from avatar@mmlab.cse.yzu.edu.tw) Received: by www.mmlab.cse.yzu.edu.tw (qmail, from userid 1000) id 12CCCE43407; Thu, 2 Apr 2009 13:16:57 +0800 (CST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=mmlab.cse.yzu.edu.tw; s=test; t=1238649417; bh=foHr3uv1MRnTp81H2rJpIOELPhWplGpZpuRy0hIaabw=; h=Date:From:To:cc:Subject:In-Reply-To:Message-ID:References: MIME-Version:Content-Type; b=egcZl9Oe5vjddtWepiN6Tc2t1Yekiwm5znTK1IYK3JFQiBil5D9ofMfpJgUfNvR2b tK0ak7QZhykrkDc8VuiilEKk8uTfZPQnbO0484iliPuuh7+k9wkMBRMqk30Hprm2tD 35LWzck+2dsqXHH+nQ+qOBJrJlfOatjQOVVHkXxQ= Received: from localhost (localhost [127.0.0.1]) by www.mmlab.cse.yzu.edu.tw (qmail) with ESMTP id 1274CE43406; Thu, 2 Apr 2009 13:16:57 +0800 (CST) Date: Thu, 2 Apr 2009 13:16:57 +0800 (CST) From: Tai-hwa Liang To: Marcel Moolenaar In-Reply-To: <4CCDEFD6-830E-4C8F-B7A2-B7878F8842BE@mac.com> Message-ID: <0904021314574.37737@www.mmlab.cse.yzu.edu.tw> References: <95891.1238477069@critter.freebsd.dk> <20090331133132.1e191836@ernst.jennejohn.org> <20090331155542.74d89d64@ernst.jennejohn.org> <60084D1E-9F64-463A-A8E9-7A237D5C7661@mac.com> <0904011910169.29800@www.mmlab.cse.yzu.edu.tw> <0904020940371.36257@www.mmlab.cse.yzu.edu.tw> <4CCDEFD6-830E-4C8F-B7A2-B7878F8842BE@mac.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-current@freebsd.org Subject: Re: Removal of GEOM_BSD, GEOM_MBR, GEOM_PC98 and GEOM_SUNLABEL 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, 02 Apr 2009 05:17:22 -0000 On Wed, 1 Apr 2009, Marcel Moolenaar wrote: > On Apr 1, 2009, at 6:44 PM, Tai-hwa Liang wrote: >> On Wed, 1 Apr 2009, Marcel Moolenaar wrote: >>> On Apr 1, 2009, at 4:16 AM, Tai-hwa Liang wrote: >>>> >>>> that's too bad. Since my /home is sitting on the extended partition, >>>> the OS won't boot unless the kernel is built with various GEOM_PART_ >>>> removed from i386/conf/DEFAULT plus GEOM_{BSD,MBR} added back to the >>>> kernel configuration file(ie: GENERIC kernel cvsup'ed today doesn't >>>> boot). >>> >>> That sounds like a bug, because logical partitions are >>> supported. Can you enable GEOM_PART_BSD, GEOM_PART_EBR >>> and GEOM_PART_MBR and tell me which GEOMs are available >>> at the mount root prompt? >> >> Following are what gpart sees with a GEOM_PART_{BSD,EBR,MBR} and >> GEOM_{BSD,MBR} enabled kernel: > > Please remove GEOM_{BSD,MBR} when enabling GEOM_PART_{BSD,EBR,MBR} > (and vice versa) and let me know how things look then. GENERIC kernel as of today(read: with GEOM_PART_{BSD,EBR,MBR} in DEFAULT and no GEOM{BSD,MBR}): # geom show => 63 228338775 ad0 MBR (109G) 63 18688257 1 !12 (8.9G) 18688320 16783200 2 freebsd [active] (8.0G) 35471520 192855600 3 !15 (92G) 228327120 11718 - free - (5.7M) => 0 16783200 ad0s2c BSD (8.0G) 0 786432 1 freebsd-ufs (384M) 786432 4194304 2 freebsd-swap (2.0G) 4980736 393216 4 freebsd-ufs (192M) 5373952 11409248 5 freebsd-ufs (5.4G) # geom list Geom name: ad0 fwheads: 16 fwsectors: 63 last: 228338837 first: 63 entries: 4 scheme: MBR Providers: 1. Name: ad0s1 Mediasize: 9568387584 (8.9G) Sectorsize: 512 Mode: r0w0e0 rawtype: 12 length: 9568387584 offset: 32256 type: !12 index: 1 end: 18688319 start: 63 2. Name: ad0s2 Mediasize: 8592998400 (8.0G) Sectorsize: 512 Mode: r2w2e3 attrib: active rawtype: 165 length: 8592998400 offset: 9568419840 type: freebsd index: 2 end: 35471519 start: 18688320 3. Name: ad0s3 Mediasize: 98742067200 (92G) Sectorsize: 512 Mode: r0w0e0 rawtype: 15 length: 98742067200 offset: 18161418240 type: !15 index: 3 end: 228327119 start: 35471520 Consumers: 1. Name: ad0 Mediasize: 116909491200 (109G) Sectorsize: 512 Mode: r2w2e5 Geom name: ad0s2 fwheads: 16 fwsectors: 63 last: 16783199 first: 0 entries: 8 scheme: BSD Providers: 1. Name: ad0s2a Mediasize: 402653184 (384M) Sectorsize: 512 Mode: r1w1e1 rawtype: 7 length: 402653184 offset: 0 type: freebsd-ufs index: 1 end: 786431 start: 0 2. Name: ad0s2b Mediasize: 2147483648 (2.0G) Sectorsize: 512 Mode: r1w1e0 rawtype: 1 length: 2147483648 offset: 402653184 type: freebsd-swap index: 2 end: 4980735 start: 786432 3. Name: ad0s2d Mediasize: 201326592 (192M) Sectorsize: 512 Mode: r0w0e0 rawtype: 7 length: 201326592 offset: 2550136832 type: freebsd-ufs index: 4 end: 5373951 start: 4980736 4. Name: ad0s2e Mediasize: 5841534976 (5.4G) Sectorsize: 512 Mode: r0w0e0 rawtype: 7 length: 5841534976 offset: 2751463424 type: freebsd-ufs index: 5 end: 16783199 start: 5373952 Consumers: 1. Name: ad0s2 Mediasize: 8592998400 (8.0G) Sectorsize: 512 Mode: r2w2e3 From owner-freebsd-current@FreeBSD.ORG Thu Apr 2 05: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 0609D106566C for ; Thu, 2 Apr 2009 05:51:00 +0000 (UTC) (envelope-from akm@theinternet.com.au) Received: from fallbackmx08.syd.optusnet.com.au (fallbackmx08.syd.optusnet.com.au [211.29.132.10]) by mx1.freebsd.org (Postfix) with ESMTP id 762B58FC17 for ; Thu, 2 Apr 2009 05:50:59 +0000 (UTC) (envelope-from akm@theinternet.com.au) Received: from mail08.syd.optusnet.com.au (mail08.syd.optusnet.com.au [211.29.132.189]) by fallbackmx08.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id n31NeG3p017898 for ; Thu, 2 Apr 2009 10:40:16 +1100 Received: from camelot.theinternet.com.au (d122-105-150-189.bla11.nsw.optusnet.com.au [122.105.150.189]) by mail08.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id n31NeBJ8006114; Thu, 2 Apr 2009 10:40:14 +1100 Received: by camelot.theinternet.com.au (Postfix, from userid 1000) id 68D0017037; Thu, 2 Apr 2009 10:38:18 +1100 (EST) Date: Thu, 2 Apr 2009 10:38:18 +1100 From: Andrew Milton To: Juha Saarinen Message-ID: <20090401233818.GC1035@camelot.theinternet.com.au> Mail-Followup-To: Andrew Milton , Juha Saarinen , FreeBSD Current References: <20081223013626.2833a911@baby-jane> <20081223010902.GB1072@in-addr.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Cc: FreeBSD Current Subject: Re: Kip Macy 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, 02 Apr 2009 05:51:00 -0000 +-------[ Juha Saarinen ]---------------------- | Motion for dismissal of Kip Macy's indictment: | | http://www.scribd.com/doc/13481284/Kip-Macys-995-Absurd-Indictment | I hope he gets a discount based on quality of the motion.. My favourite is "... with intent to commit larceny and talking" well I guess if they're going to violate your constititional rights, they might as well arrest you for the intent to talk. -- Andrew Milton akm@theinternet.com.au From owner-freebsd-current@FreeBSD.ORG Thu Apr 2 07:00:58 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 04DBD106566B for ; Thu, 2 Apr 2009 07:00:58 +0000 (UTC) (envelope-from luigi@onelab2.iet.unipi.it) Received: from onelab2.iet.unipi.it (onelab2.iet.unipi.it [131.114.9.129]) by mx1.freebsd.org (Postfix) with ESMTP id C04F48FC14 for ; Thu, 2 Apr 2009 07:00:57 +0000 (UTC) (envelope-from luigi@onelab2.iet.unipi.it) Received: by onelab2.iet.unipi.it (Postfix, from userid 275) id EC25873098; Thu, 2 Apr 2009 09:06:05 +0200 (CEST) Date: Thu, 2 Apr 2009 09:06:05 +0200 From: Luigi Rizzo To: current@freebsd.org Message-ID: <20090402070605.GA96848@onelab2.iet.unipi.it> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.3i Cc: Subject: cmpxchg / atomic_cmpset_int emulation for userland (i386) ? 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, 02 Apr 2009 07:00:58 -0000 Hi, I have some list manipulation algorithm that I would like to use that relies rather centrally on atomic_cmpset_int(). This is an atomic instruction on 486+, but not available on 386 and maybe other platforms. i386/atomic.h has a replacement but it uses "pushfl; cli; ... popfl;" so it cannot run in userland. I was wondering if there is a good emulation for that instruction on the i386 that is suitable for userland (other architectures we support have a CPU instruction that does it, or in the case of ARM, a usable emulation for userland). cheers luigi From owner-freebsd-current@FreeBSD.ORG Thu Apr 2 07:40: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 9541B106566B for ; Thu, 2 Apr 2009 07:40:26 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id B46318FC19 for ; Thu, 2 Apr 2009 07:40:25 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from porto.topspin.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id KAA04378; Thu, 02 Apr 2009 10:39:54 +0300 (EEST) (envelope-from avg@icyb.net.ua) Received: from localhost.topspin.kiev.ua ([127.0.0.1] helo=edge.pp.kiev.ua) by porto.topspin.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1LpHWk-0005At-B0; Thu, 02 Apr 2009 10:39:54 +0300 Message-ID: <49D46BC7.5030307@icyb.net.ua> Date: Thu, 02 Apr 2009 10:39:51 +0300 From: Andriy Gapon User-Agent: Thunderbird 2.0.0.19 (X11/20090114) MIME-Version: 1.0 To: User Wblock References: <4451ccf20903300123p4df9c1d7k4c4138ad25d2d4af@mail.gmail.com> <49D0E44C.60103@phat.za.net> <49D1001E.2050405@icyb.net.ua> <49D1C3E6.3050207@icyb.net.ua> In-Reply-To: X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Aragon Gouveia , ccuiyyan@gmail.com, freebsd-current@freebsd.org Subject: Re: loader prompt doesn't work 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, 02 Apr 2009 07:40:26 -0000 on 02/04/2009 03:27 User Wblock said the following: > On Tue, 31 Mar 2009, Andriy Gapon wrote: >> on 31/03/2009 03:50 User Wblock said the following: >>> On Mon, 30 Mar 2009, Andriy Gapon wrote: >>>> There was a significant fix to boot code made recently by jhb. It is >>>> now in head, stable/7 and stable/6. So you need to update to the >>>> recent resources. What you also need (and what was not emphasized >>>> enough, IMO) is to actually install new boot code (/boot/boot) to >>>> your active slices after installworld completes. >>>> >>>> E.g.: >>>> $ gpart bootcode -b /boot/boot adXsY >>> >>> The gpart manpage just makes me more confused about this. >> >> Your reply is quite confusing too - you put many different things into >> the same heap. > > Okay, I'll try again. Thank you! >>> I don't know >>> what a "protective" MBR is, or if I've got one. >> >> If you think that you have to know, then google is your friend. > > The question is "How can I tell if 'gpart bootcode -b /boot/boot adXsY'? > is needed? The gpart man page is apparently not the place to start. Well, it is needed if you want to update your btx / boot2 code and not needed otherwise. The manual page can't know your intentions :) >>> Can you expand on this a little? >> >> On "this" what? > > On your statement above: > >>>> What you also need (and what was not emphasized enough, IMO) is to >>>> actually install new boot code (/boot/boot) to your active slices >>>> after installworld completes. > > Would it be more accurate if that sentence read: > > "What you also need *if you experience problems with the boot loader > prompt* (and what was not emphasized enough, IMO)..." Yes, this will definitely be more accurate. OTOH, I think it was clear enough from the context of this thread (e.g. see subject line). >>> For instance: >>> >>> * When did it happen? >> >> "it" what? > >>>> There was a significant fix to boot code made recently by jhb. > > Hoping for something more specific than "recently". http://svn.freebsd.org/viewvc/base/head/sys/boot/i386/btx/btx/ You can easily continue from here. >>> * Who needs to do this--everyone who has updated to a recent -CURRENT or >>> -STABLE? >> >> If you don't have the problems described earlier in this thread than you >> don't have to do anything. > > Does not having the problem mean the latest boot code is in place, or > just that the particular system hasn't triggered the problem? Is there > a way to tell if the installed boot code is up to date? It can mean either. The people who did/do have the problem experienced it very consistently. As for telling - I know of no easy way. You can dd first 8k of your boot slice, hexdump it and then compare with hexdump of /boot/boot installed by installworld. >>> Or just those using certain partitioning features? >>> * There's no mention in /usr/src/UPDATING. Was it mentioned anywhere? BTW, I think it was not mentioned in UPDATING because only a very small minority of users was affected or at least reported the problem. -- Andriy Gapon From owner-freebsd-current@FreeBSD.ORG Thu Apr 2 08:48:40 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 67E3F1065674 for ; Thu, 2 Apr 2009 08:48:40 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.terabit.net.ua (mail.terabit.net.ua [195.137.202.147]) by mx1.freebsd.org (Postfix) with ESMTP id 0B9C58FC19 for ; Thu, 2 Apr 2009 08:48:39 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from skuns.zoral.com.ua ([91.193.166.194] helo=mail.zoral.com.ua) by mail.terabit.net.ua with esmtps (TLSv1:AES256-SHA:256) (Exim 4.63 (FreeBSD)) (envelope-from ) id 1LpIbF-000Pnj-Il; Thu, 02 Apr 2009 11:48:37 +0300 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 n328mYVf011170 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 2 Apr 2009 11:48:34 +0300 (EEST) (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 n328mYSF090830; Thu, 2 Apr 2009 11:48:34 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.3/8.14.3/Submit) id n328mX8V090829; Thu, 2 Apr 2009 11:48:33 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Thu, 2 Apr 2009 11:48:33 +0300 From: Kostik Belousov To: Luigi Rizzo Message-ID: <20090402084833.GZ31897@deviant.kiev.zoral.com.ua> References: <20090402070605.GA96848@onelab2.iet.unipi.it> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="GNE9ETaGyP7vJxQo" Content-Disposition: inline In-Reply-To: <20090402070605.GA96848@onelab2.iet.unipi.it> User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-4.4 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua X-Virus-Scanned: mail.terabit.net.ua 1LpIbF-000Pnj-Il be94835d1d34e6e67bf4fc89afa2d219 X-Terabit: YES Cc: current@freebsd.org Subject: Re: cmpxchg / atomic_cmpset_int emulation for userland (i386) ? 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, 02 Apr 2009 08:48:41 -0000 --GNE9ETaGyP7vJxQo Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Apr 02, 2009 at 09:06:05AM +0200, Luigi Rizzo wrote: > Hi, > I have some list manipulation algorithm that I would like to use > that relies rather centrally on atomic_cmpset_int(). >=20 > This is an atomic instruction on 486+, but not available on 386 > and maybe other platforms. i386/atomic.h has a replacement > but it uses "pushfl; cli; ... popfl;" so it cannot run in userland. >=20 > I was wondering if there is a good emulation for that instruction > on the i386 that is suitable for userland (other architectures > we support have a CPU instruction that does it, or in the case of ARM, > a usable emulation for userland). FreeBSD cannot boot on anything < 486, i.e. cmpxchgl and xaddl may be considered always supported by the CPU. --GNE9ETaGyP7vJxQo Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (FreeBSD) iEYEARECAAYFAknUe+AACgkQC3+MBN1Mb4gWZwCgzqRxTpUB03rwi1Az4/wvB09p A/8AoO10q/FZ/xdf+gWajB8FqkAVMdHC =bhYi -----END PGP SIGNATURE----- --GNE9ETaGyP7vJxQo-- From owner-freebsd-current@FreeBSD.ORG Thu Apr 2 08:53:47 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 D7434106566B for ; Thu, 2 Apr 2009 08:53:46 +0000 (UTC) (envelope-from luigi@onelab2.iet.unipi.it) Received: from onelab2.iet.unipi.it (onelab2.iet.unipi.it [131.114.9.129]) by mx1.freebsd.org (Postfix) with ESMTP id 9B19D8FC28 for ; Thu, 2 Apr 2009 08:53:46 +0000 (UTC) (envelope-from luigi@onelab2.iet.unipi.it) Received: by onelab2.iet.unipi.it (Postfix, from userid 275) id E72B173098; Thu, 2 Apr 2009 10:58:54 +0200 (CEST) Date: Thu, 2 Apr 2009 10:58:54 +0200 From: Luigi Rizzo To: Kostik Belousov Message-ID: <20090402085854.GA2237@onelab2.iet.unipi.it> References: <20090402070605.GA96848@onelab2.iet.unipi.it> <20090402084833.GZ31897@deviant.kiev.zoral.com.ua> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20090402084833.GZ31897@deviant.kiev.zoral.com.ua> User-Agent: Mutt/1.4.2.3i Cc: current@freebsd.org Subject: Re: cmpxchg / atomic_cmpset_int emulation for userland (i386) ? 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, 02 Apr 2009 08:53:47 -0000 On Thu, Apr 02, 2009 at 11:48:33AM +0300, Kostik Belousov wrote: > On Thu, Apr 02, 2009 at 09:06:05AM +0200, Luigi Rizzo wrote: > > Hi, > > I have some list manipulation algorithm that I would like to use > > that relies rather centrally on atomic_cmpset_int(). > > > > This is an atomic instruction on 486+, but not available on 386 > > and maybe other platforms. i386/atomic.h has a replacement > > but it uses "pushfl; cli; ... popfl;" so it cannot run in userland. > > > > I was wondering if there is a good emulation for that instruction > > on the i386 that is suitable for userland (other architectures > > we support have a CPU instruction that does it, or in the case of ARM, > > a usable emulation for userland). > > FreeBSD cannot boot on anything < 486, i.e. cmpxchgl and xaddl may be > considered always supported by the CPU. It was a slightly more generic question -- this stuff is for userland so while we can assume it works on modern FreeBSD versions, I would like to see what constraints it has on older versions of FreeBSD. Of course I can emulate the critical section with a pthread lock, but that would be the worst case option. cheers luigi From owner-freebsd-current@FreeBSD.ORG Thu Apr 2 09:47: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 1BC831065672 for ; Thu, 2 Apr 2009 09:47:32 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.terabit.net.ua (mail.terabit.net.ua [195.137.202.147]) by mx1.freebsd.org (Postfix) with ESMTP id B2FF38FC12 for ; Thu, 2 Apr 2009 09:47:31 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from skuns.zoral.com.ua ([91.193.166.194] helo=mail.zoral.com.ua) by mail.terabit.net.ua with esmtps (TLSv1:AES256-SHA:256) (Exim 4.63 (FreeBSD)) (envelope-from ) id 1LpJWE-00060O-Bj; Thu, 02 Apr 2009 12:47:30 +0300 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 n329lRMm014472 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 2 Apr 2009 12:47:27 +0300 (EEST) (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 n329lRkG032014; Thu, 2 Apr 2009 12:47:27 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.3/8.14.3/Submit) id n329lR32032013; Thu, 2 Apr 2009 12:47:27 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Thu, 2 Apr 2009 12:47:27 +0300 From: Kostik Belousov To: Luigi Rizzo Message-ID: <20090402094727.GC31897@deviant.kiev.zoral.com.ua> References: <20090402070605.GA96848@onelab2.iet.unipi.it> <20090402084833.GZ31897@deviant.kiev.zoral.com.ua> <20090402085854.GA2237@onelab2.iet.unipi.it> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="j9j9RojA/SLAeXkU" Content-Disposition: inline In-Reply-To: <20090402085854.GA2237@onelab2.iet.unipi.it> User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-4.4 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua X-Virus-Scanned: mail.terabit.net.ua 1LpJWE-00060O-Bj 7790033e8dd309314ea97696bd01659a X-Terabit: YES Cc: current@freebsd.org Subject: Re: cmpxchg / atomic_cmpset_int emulation for userland (i386) ? 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, 02 Apr 2009 09:47:32 -0000 --j9j9RojA/SLAeXkU Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Apr 02, 2009 at 10:58:54AM +0200, Luigi Rizzo wrote: > On Thu, Apr 02, 2009 at 11:48:33AM +0300, Kostik Belousov wrote: > > On Thu, Apr 02, 2009 at 09:06:05AM +0200, Luigi Rizzo wrote: > > > Hi, > > > I have some list manipulation algorithm that I would like to use > > > that relies rather centrally on atomic_cmpset_int(). > > >=20 > > > This is an atomic instruction on 486+, but not available on 386 > > > and maybe other platforms. i386/atomic.h has a replacement > > > but it uses "pushfl; cli; ... popfl;" so it cannot run in userland. > > >=20 > > > I was wondering if there is a good emulation for that instruction > > > on the i386 that is suitable for userland (other architectures > > > we support have a CPU instruction that does it, or in the case of ARM, > > > a usable emulation for userland). > >=20 > > FreeBSD cannot boot on anything < 486, i.e. cmpxchgl and xaddl may be > > considered always supported by the CPU. >=20 > It was a slightly more generic question -- this stuff is for userland > so while we can assume it works on modern FreeBSD versions, I would > like to see what constraints it has on older versions of FreeBSD. > Of course I can emulate the critical section with a pthread lock, > but that would be the worst case option. Support for FPU-less operations was removed from HEAD in Jul 2003. The support for i386+387 seems to be removed in 2004, i.e. before 5.x. The kernel explicitely requires working read-only mappings of the pages for kernel mode, AKA WP bit in CR0. Also, kernel assumes that cmpxchgl is always present. Do you want to support 4.x ? --j9j9RojA/SLAeXkU Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (FreeBSD) iEYEARECAAYFAknUia4ACgkQC3+MBN1Mb4jb2wCgrRut4dpvGPNjneo1ztK1Y8lL p8gAn1wPPu5RY9r1jVP201S7j4CcJ3BL =E0sP -----END PGP SIGNATURE----- --j9j9RojA/SLAeXkU-- From owner-freebsd-current@FreeBSD.ORG Thu Apr 2 10:00:26 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 CA1AC1065675 for ; Thu, 2 Apr 2009 10:00:26 +0000 (UTC) (envelope-from sobomax@FreeBSD.org) Received: from sippysoft.com (gk1.360sip.com [72.236.70.240]) by mx1.freebsd.org (Postfix) with ESMTP id 761678FC14 for ; Thu, 2 Apr 2009 10:00:26 +0000 (UTC) (envelope-from sobomax@FreeBSD.org) Received: from [192.168.1.38] (S0106001372fd1e07.vs.shawcable.net [70.71.171.106]) (authenticated bits=0) by sippysoft.com (8.14.3/8.14.3) with ESMTP id n32A0OU5074325 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 2 Apr 2009 03:00:25 -0700 (PDT) (envelope-from sobomax@FreeBSD.org) Message-ID: <49D48CA7.9050102@FreeBSD.org> Date: Thu, 02 Apr 2009 03:00:07 -0700 From: Maxim Sobolev Organization: Sippy Software, Inc. User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Luigi Rizzo References: <20090402070605.GA96848@onelab2.iet.unipi.it> <20090402084833.GZ31897@deviant.kiev.zoral.com.ua> <20090402085854.GA2237@onelab2.iet.unipi.it> In-Reply-To: <20090402085854.GA2237@onelab2.iet.unipi.it> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Kostik Belousov , current@FreeBSD.org Subject: Re: cmpxchg / atomic_cmpset_int emulation for userland (i386) ? 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, 02 Apr 2009 10:00:28 -0000 Luigi Rizzo wrote: > On Thu, Apr 02, 2009 at 11:48:33AM +0300, Kostik Belousov wrote: >> On Thu, Apr 02, 2009 at 09:06:05AM +0200, Luigi Rizzo wrote: >>> Hi, >>> I have some list manipulation algorithm that I would like to use >>> that relies rather centrally on atomic_cmpset_int(). >>> >>> This is an atomic instruction on 486+, but not available on 386 >>> and maybe other platforms. i386/atomic.h has a replacement >>> but it uses "pushfl; cli; ... popfl;" so it cannot run in userland. >>> >>> I was wondering if there is a good emulation for that instruction >>> on the i386 that is suitable for userland (other architectures >>> we support have a CPU instruction that does it, or in the case of ARM, >>> a usable emulation for userland). >> FreeBSD cannot boot on anything < 486, i.e. cmpxchgl and xaddl may be >> considered always supported by the CPU. > > It was a slightly more generic question -- this stuff is for userland > so while we can assume it works on modern FreeBSD versions, I would > like to see what constraints it has on older versions of FreeBSD. > Of course I can emulate the critical section with a pthread lock, > but that would be the worst case option. On i386's you can use XCHG instruction to implement locks and test&set in userland. Check this: http://lists.canonical.org/pipermail/kragen-tol/1999-August/000457.html http://www.acm.uiuc.edu/sigops/roll_your_own/i386/atomic.html The simplest is the XCHG instruction, which can be used to atomically exchange two registers or a register and a memory location. This makes it possible to implement multiple exclusion; reserve a particular location in RAM as a mutex, and initially set it to 1. To acquire the mutex, set a register to 0, and XCHG it with the location in RAM. If what you get back is a 1, then you have successfully acquired the mutex; otherwise, someone else has it. You can return the mutex simply by setting the location to a nonzero value. Intel's doc says, "When a memory operand is used with the XCHG instruction, the processor's LOCK signal is automatically asserted. This instruction is thus useful for implementing semaphores or similar data structures for process synchronization." -Maxim From owner-freebsd-current@FreeBSD.ORG Thu Apr 2 10:19: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 1E875106566C for ; Thu, 2 Apr 2009 10:19:31 +0000 (UTC) (envelope-from ccuiyyan@gmail.com) Received: from wa-out-1112.google.com (wa-out-1112.google.com [209.85.146.178]) by mx1.freebsd.org (Postfix) with ESMTP id E28DC8FC0C for ; Thu, 2 Apr 2009 10:19:30 +0000 (UTC) (envelope-from ccuiyyan@gmail.com) Received: by wa-out-1112.google.com with SMTP id m38so312285waf.27 for ; Thu, 02 Apr 2009 03:19:30 -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=W4HQd2Dwlq6rp8pHQ27UqmKhN25fF636/5oQIWusMrM=; b=M5cqKjz2+7YNeOeTpO+/qhnrbJ+zE77Vg/2LRlIXkAkXoLIIUfOmIyTzhkS43s4dzN aEWP6c38rqrZwl4y7kqGmslwQ4/8edemywrat4WpbxA5Jq4Vn8pYvPJ+dIvGVsw7Vtr5 2eOIuNzXuW8AVZDgsVEnqbmc8Md5vnn8rEP9M= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=RwreyuCSj2Tn4kNkYz26RNLWxBgA2e/4oAv++kuM8TCoYYA9pyTbWKhvTK0qMtaMuQ XmwZl2fA8DfCZMezJbY1XEDyp6QUJWO6A+NTbBpaUGgec9dM4po5NAhrcyVUQqzj3n52 fDWhhgUr5MGWoaXUgBwwJr55rk8LHVwtN8lhA= MIME-Version: 1.0 Received: by 10.114.133.1 with SMTP id g1mr5813735wad.162.1238667570692; Thu, 02 Apr 2009 03:19:30 -0700 (PDT) Date: Thu, 2 Apr 2009 18:19:30 +0800 Message-ID: <4451ccf20904020319r6b66f390vebbb678b9e8eb2ab@mail.gmail.com> From: =?GB2312?B?tN7R0mNjdWl5eWFuQHNpbmEuY29t?= To: freebsd-current@freebsd.org Content-Type: multipart/mixed; boundary=0016e64dd4ce8bce0604668fc488 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: dup() scales badly on multicore platform 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, 02 Apr 2009 10:19:31 -0000 --0016e64dd4ce8bce0604668fc488 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Dear all; i benchchmark the dup() system call on 32 cores machine in FreeBSD-current8.0. The results are bad. The phenomenon is easy to come out. Each process(not thread) on the core dup() its private file, and close() in a tight loop. The time completing the parallel workload is considered as performance. At first, i think there are some locks. However, lock profiling in FreeBSD is strange and interesting. I attach the graph and lock profiling. Any ideas? --0016e64dd4ce8bce0604668fc488 Content-Type: application/octet-stream; name=TCCC Content-Disposition: attachment; filename=TCCC Content-Transfer-Encoding: base64 X-Attachment-Id: f_ft1anyhd1 IG11dGV4OnByb2Nlc3MgbG9jaykKICAgICAxNDkgICAgICAgNDA4ICAgIDEyMTgwODc2ICAgICAg MjEzNTA4ICAgICAgMTQ2NzY2ICAgICA4MiAgICAgIDEgIDAgICAxMzIyIC91c3Ivc3JjL3N5cy9r ZXJuL2tlcm5fY2xvY2suYzoyODYgKHNwaW4gbXV0ZXg6c2NoZWQgbG9jayAxKQogICAgMjc5MCAg ICAgIDIyNDAgICAgICA0NTM3NTAgICAgICAyMTc4NTIgICAgICAgICA3MTAgICAgNjM5ICAgIDMw NiAgMCAgICAzMzQgL3Vzci9zcmMvc3lzL2tlcm4va2Vybl9tdXRleC5jOjEzNyAoc2xlZXAgbXV0 ZXg6VVNCIGRldmljZSBtdXRleCkKICAgMzEyMjAgICAgIDIwMzMxICAgNDY2NTA2NTExICAgICAg MjIzMTY2ICAgICAxNjAwMDE3ICAgIDI5MSAgICAgIDAgIDAgICAgMzUzIC91c3Ivc3JjL3N5cy9r ZXJuL2tlcm5fZGVzY3JpcC5jOjcxMCAoc2xlZXAgbXV0ZXg6cHJvY2VzcyBsb2NrKQogICAgIDE1 MyAgICAgICA2MDEgICAgMTIxOTUyOTMgICAgICAyNTg2NTUgICAgICAxNDYyNzcgICAgIDgzICAg ICAgMSAgMCAgIDIwMzkgL3Vzci9zcmMvc3lzL2tlcm4va2Vybl9jbG9jay5jOjI4NiAoc3BpbiBt dXRleDpzY2hlZCBsb2NrIDIpCiAgICAgMTUxICAgICAgIDM5NSAgICAxMjIwODIwNyAgICAgIDI2 ODA4MCAgICAgIDE0Njc0NSAgICAgODMgICAgICAxICAwICAgMjE2NSAvdXNyL3NyYy9zeXMva2Vy bi9rZXJuX2Nsb2NrLmM6Mjg2IChzcGluIG11dGV4OnNjaGVkIGxvY2sgMykKICAgIDc5NzQgICAg IDUyNTc4ICAgICAgMjk4OTc3ICAgICAgMjc2Mjg0ICAgICAgICAxMjEyICAgIDI0NiAgICAyMjcg IDAgICAgMTc2IC91c3Ivc3JjL3N5cy92bS92bV9nbHVlLmM6Njg5IChzbGVlcCBtdXRleDpwcm9j ZXNzIGxvY2spCiAgICAyMzMyICAgICAxMzg5MiAgICAgIDE0NzIwMCAgICAgIDMwMjQ4MiAgICAg ICAgIDcxMCAgICAyMDcgICAgNDI2ICAwICAgIDEzNiAvdXNyL3NyYy9zeXMvZGV2L3VzYjIvY29y ZS91c2IyX3JlcXVlc3QuYzo0NzQgKHNsZWVwIG11dGV4OkdpYW50KQogICAgODczNyAgICAgMTUy NzEgICAgIDQyOTk4MDEgICAgICAzMzg4ODggICAgICAgMjUwMTYgICAgMTcxICAgICAxMyAgMCAg ICA3NjkgL3Vzci9zcmMvc3lzL3ZtL3VtYV9jb3JlLmM6MjUyNCAoc2xlZXAgbXV0ZXg6Z19iaW8p CiAgIDE1NDk4ICAgICAxMzM5NSAgICAgMzkzNDI0MSAgICAgIDM0Mzc3NiAgICAgICAyNTAxNiAg ICAxNTcgICAgIDEzICAwICAgIDc3OSAvdXNyL3NyYy9zeXMvdm0vdW1hX2NvcmUuYzoxOTkwIChz bGVlcCBtdXRleDpnX2JpbykKICAgICAxNjIgICAgICAgMzU2ICAgICAgNDE5NzMzICAgICAgMzU2 ODYyICAgICAgICA0NTc5ICAgICA5MSAgICAgNzcgIDAgICAzNTQ3IC91c3Ivc3JjL3N5cy9rZXJu L3NjaGVkX3VsZS5jOjIwNzQgKHNwaW4gbXV0ZXg6c2NoZWQgbG9jayAzKQogICAgMTE2NSAgICAg MTI3MDggICAgICA0NzAzNjUgICAgICAzODc0NzIgICAgICAgICA3MTMgICAgNjU5ICAgIDU0MyAg MCAgICAgNzYgL3Vzci9zcmMvc3lzL2tlcm4vc3Vicl90dXJuc3RpbGUuYzo1NDcgKHNwaW4gbXV0 ZXg6dHVybnN0aWxlIGNoYWluKQogICAgIDI1NCAgICAgICA5MTYgICAgICA4NDQ2MTYgICAgICAz ODg2MTYgICAgICAgIDgyNzkgICAgMTAyICAgICA0NiAgMCAgIDI4NjQgL3Vzci9zcmMvc3lzL2tl cm4va2Vybl9pbnRyLmM6ODAwIChzcGluIG11dGV4OnNjaGVkIGxvY2sgMSkKICAgIDY5NTYgICAg IDE4MTkxICAgICAxNTExNDQxICAgICAgNDAyMzgyICAgICAgICAzMTY5ICAgIDQ3NiAgICAxMjYg IDAgICAgMjI4IC91c3Ivc3JjL3N5cy92bS92bV9mYXVsdC5jOjEwMDcgKHNsZWVwIG11dGV4OnZt IG9iamVjdCkKICAgICAxMzYgICAgMTMwNTY1ICAgICAgIDI4Nzk1ICAgICAgNDMzOTE0ICAgICAg ICAgMzMyICAgICA4NiAgIDEzMDYgIDAgICAgMzAyIC91c3Ivc3JjL3N5cy9rZXJuL3NjaGVkX3Vs ZS5jOjI1NjkgKHNwaW4gbXV0ZXg6c2NoZWQgbG9jayAxKQogICAgIDE3NiAgICAgICA0NDYgICAg ICA0OTQ4NTQgICAgICA0NjQwMjkgICAgICAgIDUzNzUgICAgIDkyICAgICA4NiAgMCAgIDQ0ODcg L3Vzci9zcmMvc3lzL2tlcm4vc2NoZWRfdWxlLmM6MjA3NCAoc3BpbiBtdXRleDpzY2hlZCBsb2Nr IDIpCiAgIDM4NDE3ICAgICAgNzU2MiAgICAxMzE2NDE1NCAgICAgIDQ2OTMyNiAgICAgICAgNTc2 NiAgIDIyODMgICAgIDgxICAwICAgIDY4OSAvdXNyL3NyYy9zeXMva2Vybi9rZXJuX211dGV4LmM6 MTM3IChzbGVlcCBtdXRleDpHaWFudCkKICAgMzA2MDMgICAgICA5NjM5ICAgIDEyMzA0MDM5ICAg ICAgNTM4MTM4ICAgICAgIDEyNTA4ICAgIDk4MyAgICAgNDMgIDAgICAgNDE5IC91c3Ivc3JjL3N5 cy9kZXYvYXRhL2F0YS1xdWV1ZS5jOjE3NyAoc2xlZXAgbXV0ZXg6QVRBIHF1ZXVlIGxvY2spCiAg ICAgMTY0ICAgICAgIDQxOSAgICAgIDU4MTc5OSAgICAgIDU1Mzc0NyAgICAgICAgNjczMiAgICAg ODYgICAgIDgyICAwICAgNTY3MiAvdXNyL3NyYy9zeXMva2Vybi9zY2hlZF91bGUuYzoyMDc0IChz cGluIG11dGV4OnNjaGVkIGxvY2sgMSkKICAgICAxOTUgICAgICA5OTQxICAgICAyODI5OTcwICAg ICAgNjE2MTIxICAgICAgIDMyMTUwICAgICA4OCAgICAgMTkgIDAgICAzNDk0IC91c3Ivc3JjL3N5 cy9rZXJuL2tlcm5fdGltZW91dC5jOjQzNiAoc3BpbiBtdXRleDpjYWxsb3V0KQogICAgIDE4MiAg ICAgIDQ5ODMgICAgIDIyNDMwMjMgICAgICA2NzI4NDEgICAgICAgMjUzNzQgICAgIDg4ICAgICAy NiAgMCAgIDM1ODQgL3Vzci9zcmMvc3lzL2tlcm4va2Vybl90aW1lb3V0LmM6MzI1IChzcGluIG11 dGV4OmNhbGxvdXQpCiAgICA1OTYxICAgICAyMjQyMiAgICAgIDQ5MDMzNSAgICAgIDc4MDM0OSAg ICAgICAgMzExNiAgICAxNTcgICAgMjUwICAwICAgIDk0NSAvdXNyL3NyYy9zeXMva2Vybi9rZXJu X211dGV4LmM6MTM3IChzbGVlcCBtdXRleDpzbGVlcCBtdHhwb29sKQogICAgNjc2MyAgICAgODk3 OTkgICAgIDExMjM5OTggICAgICA4MDQ5MDEgICAgICAgIDM0ODIgICAgMzIyICAgIDIzMSAgMCAg ICAxMjIgL3Vzci9zcmMvc3lzL3ZtL3ZtX29iamVjdC5jOjQ0NyAoc2xlZXAgbXV0ZXg6dm0gb2Jq ZWN0KQogICAxNzA2OCAgICAgMTUwMjMgICAgMjQwNzQ1NDAgICAgICA5MTYyODIgICAgICAgOTg4 MTMgICAgMjQzICAgICAgOSAgMCAgIDE0MTQgL3Vzci9zcmMvc3lzL2dlb20vZ2VvbV9pby5jOjY4 IChzbGVlcCBtdXRleDpiaW8gcXVldWUpCiAgICA4MDE0ICAgICAxMzAxOSAgICAgIDc5MjIxNCAg ICAgMTE0NjM3MCAgICAgICAgMTExOSAgICA3MDcgICAxMDI0ICAwICAgIDY5OCAvdXNyL3NyYy9z eXMva2Vybi9rZXJuX211dGV4LmM6MTM3IChzbGVlcCBtdXRleDpvaGNpMCkKICAgIDUyMTAgICAg ICA4MDUyICAgICAgNzUzMDcwICAgICAxMTkxMTMxICAgICAgICAxMDY2ICAgIDcwNiAgIDExMTcg IDAgICAgNzEyIC91c3Ivc3JjL3N5cy9rZXJuL2tlcm5fbXV0ZXguYzoxMzcgKHNsZWVwIG11dGV4 OmVoY2kwKQogICAgODczMyAgICAgMTA3MTUgICAgIDMxMDk3MDUgICAgIDEyMjk2NzYgICAgICAg IDEzMzMgICAyMzMyICAgIDkyMiAgMCAgICAzNDIgL3Vzci9zcmMvc3lzL2Rldi91c2IyL2NvcmUv dXNiMl90cmFuc2Zlci5jOjE4MDkgKHNsZWVwIG11dGV4OlVTQiBkZXZpY2UgbXV0ZXgpCiAgICAg MjEyICAgICAgMTc1MCAgICAgNTk5NTEyMiAgICAgMTQ1MjMzOSAgICAgICA2OTc3NyAgICAgODUg ICAgIDIwICAwICAgODY1OCAvdXNyL3NyYy9zeXMva2Vybi9rZXJuX3RpbWVvdXQuYzoyNzIgKHNw aW4gbXV0ZXg6Y2FsbG91dCkKICAgIDQ0NTggICAgIDE3OTMzICAgIDI2ODAwNzAxICAgICAxNTIw ODI4ICAgICAgIDkzNzkwICAgIDI4NSAgICAgMTYgIDAgICAzMTQ5IC91c3Ivc3JjL3N5cy9rZXJu L3N1YnJfc2xlZXBxdWV1ZS5jOjIzNiAoc3BpbiBtdXRleDpzbGVlcHEgY2hhaW4pCiAgICAgMjUw ICAgICAgIDYwOCAgIDU2OTg2OTA4NSAgICAgMTcwNjY4NiAgICAgNDc3NDQ1MyAgICAxMTkgICAg ICAwICAwICAxMjM4OSAvdXNyL3NyYy9zeXMva2Vybi9rZXJuX3RpbWVvdXQuYzoyNDYgKHNwaW4g bXV0ZXg6Y2FsbG91dCkKICAgIDQ0NjMgICAgIDE2NzE4ICAgICAzMzE1MjQyICAgICAxNzI1ODQ2 ICAgICAgICA1MzM0ICAgIDYyMSAgICAzMjMgIDAgICAgNzcxIC91c3Ivc3JjL3N5cy9rZXJuL2tl cm5faW50ci5jOjExMzMgKHNsZWVwIG11dGV4OkdpYW50KQogICAgMTgwOSAgICAyMTk0NDkgICAg ICAxMjkwMzggICAgIDIyODY4NTcgICAgICAgICAyMTEgICAgNjExICAxMDgzOCAgMCAgICAyMDkg L3Vzci9zcmMvc3lzL3ZtL3ZtX2ZhdWx0LmM6Mzc1IChzbGVlcCBtdXRleDp2bSBvYmplY3QpCiAg ICAgOTI0ICAgIDE2NDI3NSAgICAgICAzNjk2MyAgICAgMjU1NDIwNCAgICAgICAgIDIwMCAgICAx ODQgIDEyNzcxICAwICAgIDE5OCAvdXNyL3NyYy9zeXMva2Vybi9rZXJuX211dGV4LmM6MTM3IChz bGVlcCBtdXRleDp2bSBvYmplY3QpCiAgICA5NTQ1ICAgIDM2NzkyMyAgICAgMTE4NzA3NSAgICAg MjgxNDk3NyAgICAgICAgMjE1NSAgICA1NTAgICAxMzA2ICAwICAgIDIzOCAvdXNyL3NyYy9zeXMv dm0vdm1fZmF1bHQuYzoyOTcgKHNsZWVwIG11dGV4OnZtIG9iamVjdCkKICAgIDE2NzggICAgIDE4 OTI2ICAgICAyMjYwNjQ5ICAgICAzMjA4Mzc4ICAgICAgICA3ODcyICAgIDI4NyAgICA0MDcgIDAg ICAgNzI1IC91c3Ivc3JjL3N5cy9rZXJuL2tlcm5fY29uZi5jOjQyMiAoc2xlZXAgbXV0ZXg6R2lh bnQpCiAgICAxNjgzICAgIDEwMTg4OSAgICAgMjI2NzM3MyAgICAgMzgyOTc0NyAgICAgICAgNzkz NyAgICAyODUgICAgNDgyICAwICAgIDc4NCAvdXNyL3NyYy9zeXMva2Vybi9rZXJuX2NvbmYuYzo0 NTQgKHNsZWVwIG11dGV4OkdpYW50KQo= --0016e64dd4ce8bce0604668fc488-- From owner-freebsd-current@FreeBSD.ORG Thu Apr 2 10:52: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 2E18C1065675 for ; Thu, 2 Apr 2009 10:52:37 +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 C717F8FC13 for ; Thu, 2 Apr 2009 10:52:36 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by cyrus.watson.org (Postfix) with ESMTPS id 528E746B51; Thu, 2 Apr 2009 06:52:36 -0400 (EDT) Date: Thu, 2 Apr 2009 11:52:36 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: =?ISO-2022-JP?Q?=1B$BVC4d=1B=28Jccuiyyan=40sina=2Ecom?= In-Reply-To: <4451ccf20904020319r6b66f390vebbb678b9e8eb2ab@mail.gmail.com> Message-ID: References: <4451ccf20904020319r6b66f390vebbb678b9e8eb2ab@mail.gmail.com> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="621616949-14832556-1238669556=:94891" Cc: freebsd-current@freebsd.org Subject: Re: dup() scales badly on multicore platform 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, 02 Apr 2009 10:52:39 -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. --621616949-14832556-1238669556=:94891 Content-Type: TEXT/PLAIN; charset=ISO-2022-JP; format=flowed On Thu, 2 Apr 2009, $BVC4d(Jccuiyyan@sina.com wrote: > i benchchmark the dup() system call on 32 cores machine in > FreeBSD-current8.0. > > The results are bad. The phenomenon is easy to come out. Each > process(not thread) on the core > > dup() its private file, and close() in a tight loop. The time > completing the parallel workload > > is considered as performance. At first, i think there are some locks. > However, lock profiling > > in FreeBSD is strange and interesting. I attach the graph and lock > profiling. Any ideas? Could you post your benchmark code? It sounds from the above as though you have 32 processes, ecah dup'ing and closing a descriptor originally created in that process (and not a shared descriptor with other processes)? Robert N M Watson Computer Laboratory University of Cambridge --621616949-14832556-1238669556=:94891-- From owner-freebsd-current@FreeBSD.ORG Thu Apr 2 10:14: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 56DFB106566C for ; Thu, 2 Apr 2009 10:14:38 +0000 (UTC) (envelope-from ccuiyyan@gmail.com) Received: from wa-out-1112.google.com (wa-out-1112.google.com [209.85.146.180]) by mx1.freebsd.org (Postfix) with ESMTP id 0352E8FC1E for ; Thu, 2 Apr 2009 10:14:37 +0000 (UTC) (envelope-from ccuiyyan@gmail.com) Received: by wa-out-1112.google.com with SMTP id m38so311183waf.27 for ; Thu, 02 Apr 2009 03:14:37 -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=QlNeLu9BZXk5J+PbNnqLLFOkDpAZI2CFVcne62lWucA=; b=fef8JYJkRDdzcZssD9ahwEqcuceYRnAJMESBmwSOB9lk8US0GCZE+NcFyLzDzrz30w mPVcP6jDgLewt6peiHAW5TbE3S7CYc8J0DrABvqCqGivwpZjUtLRbyKl3O7OHsWSVAIy +Gg5UVCkP/IW+Y+Dv7IZW23gMBTGvaKJpU1/A= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=oUS0dIPWjMnW0RCwLfZS/JPUQaoQ3SLu2qgrC30F0HxBeLZkL7u5Jwbsn+xoJi6JTK vpWydqYALu4zvXhTmsD4PkaKs+DXleqg1q9NoF6Lfqjb9nGEFvmOEINklgf1aBAimChG W+1jWumM74V/2c/NciItveROicGVqjzfWkfjk= MIME-Version: 1.0 Received: by 10.114.157.1 with SMTP id f1mr5806057wae.185.1238667277495; Thu, 02 Apr 2009 03:14:37 -0700 (PDT) Date: Thu, 2 Apr 2009 18:14:37 +0800 Message-ID: <4451ccf20904020314r7591a546l89573aa76a44143a@mail.gmail.com> From: =?GB2312?B?tN7R0mNjdWl5eWFuQHNpbmEuY29t?= To: freebsd-current@freebsd.org Content-Type: multipart/mixed; boundary=001636456fd611f42404668fb355 X-Mailman-Approved-At: Thu, 02 Apr 2009 11:20:07 +0000 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: dup() scales badly on multicore platform 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, 02 Apr 2009 10:14:41 -0000 --001636456fd611f42404668fb355 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Dear all; i benchchmark the dup() system call on 32 cores machine in FreeBSD-current8.0. The results are bad. The phenomenon is easy to come out. Each process(not thread) on the core dup() its private file, and close() in a tight loop. The time completing the parallel workload is considered as performance. At first, i think there are some locks. However, lock profiling in FreeBSD is strange and interesting. I attach the graph and lock profiling. Any ideas? Best Wishes! Yan --001636456fd611f42404668fb355 Content-Type: application/octet-stream; name=LOCK32 Content-Disposition: attachment; filename=LOCK32 Content-Transfer-Encoding: base64 X-Attachment-Id: f_ft1ag2r21 ZGVidWcubG9jay5wcm9mLnN0YXRzOiAKICAgICBtYXggIHdhaXRfbWF4ICAgICAgIHRvdGFsICB3 YWl0X3RvdGFsICAgICAgIGNvdW50ICAgIGF2ZyB3YWl0X2F2ZyBjbnRfaG9sZCBjbnRfbG9jayBu YW1lCiAgICAgNjM5ICAgICAgICAgMCAgICAgICAgNjQ0NyAgICAgICAgICAgMCAgICAgICAgICA0 NiAgICAxNDAgICAgICAwICAwICAgICAgMCAvdXNyL3NyYy9zeXMva2Vybi9rZXJuX2V4aXQuYzoz OTkgKHNsZWVwIG11dGV4OnByb2Nlc3MgbG9jaykKICAgIDg3NzcgICAgICAgICAwICAgICAgNTIx NTk3ICAgICAgICAgICAwICAgICAgICAgMTQzICAgMzY0NyAgICAgIDAgIDAgICAgICAwIC91c3Iv c3JjL3N5cy9rZXJuL2tlcm5fbXV0ZXguYzoxMzcgKHNsZWVwIG11dGV4OmVtMCkKICAgICAxNTYg ICAgICAgICAwICAgICAgICAgNjM4ICAgICAgICAgICAwICAgICAgICAgICA3ICAgICA5MSAgICAg IDAgIDAgICAgICAwIC91c3Ivc3JjL3N5cy92bS91bWFfY29yZS5jOjQxMCAoc2xlZXAgbXV0ZXg6 c29ja2V0KQogICAgMTc3OCAgICAgICAgIDAgICAgICAgMzE0OTYgICAgICAgICAgIDAgICAgICAg ICAgOTkgICAgMzE4ICAgICAgMCAgMCAgICAgIDAgL3Vzci9zcmMvc3lzL2tlcm4va2Vybl9kZXNj cmlwLmM6MTQ0NSAoc3g6ZmlsZWRlc2Mgc3RydWN0dXJlKQogICAgIDc1NiAgICAgICAgIDAgICAg ICAgIDE4ODkgICAgICAgICAgIDAgICAgICAgICAgIDcgICAgMjY5ICAgICAgMCAgMCAgICAgIDAg L3Vzci9zcmMvc3lzL3ZtL3VtYV9jb3JlLmM6NDEwIChzbGVlcCBtdXRleDo1MTIpCiAgICAgNzc5 ICAgICAgICAgMCAgICAgICAyNTA5NyAgICAgICAgICAgMCAgICAgICAgICA3NiAgICAzMzAgICAg ICAwICAwICAgICAgMCAvdXNyL3NyYy9zeXMva2Vybi92ZnNfbG9va3VwLmM6NzE2IChsb2NrbWdy OmNyb3NzbXApCiAgICAxMTkwICAgICAgICAgMCAgICAgICAgODMyMCAgICAgICAgICAgMCAgICAg ICAgICAzNSAgICAyMzcgICAgICAwICAwICAgICAgMCAvdXNyL3NyYy9zeXMvZGV2L3VzYjIvY29u dHJvbGxlci91c2IyX2NvbnRyb2xsZXIuYzoyMjYgKHNsZWVwIG11dGV4OmVoY2kwKQogICAgIDQ1 OCAgICAgICAgIDAgICAgICAgIDQ1NjggICAgICAgICAgIDAgICAgICAgICAgMzggICAgMTIwICAg ICAgMCAgMCAgICAgIDAgL3Vzci9zcmMvc3lzL2tlcm4vdmZzX3Zub3BzLmM6MTAzNyAoc2xlZXAg bXV0ZXg6c3RydWN0IG1vdW50IG10eCkKICAgIDU2NTQgICAgICAgICAwICAgICAgMTQ2Njk0ICAg ICAgICAgICAwICAgICAgICAgIDQ2ICAgMzE4OSAgICAgIDAgIDAgICAgICAwIC91c3Ivc3JjL3N5 cy9rZXJuL2tlcm5fZXhpdC5jOjQ1MyAoc2xlZXAgbXV0ZXg6cHJvY2VzcyBsb2NrKQogICAgIDk5 NiAgICAgICAgIDAgICAgICAgMTU2NDUgICAgICAgICAgIDAgICAgICAgICAgNDYgICAgMzQwICAg ICAgMCAgMCAgICAgIDAgL3Vzci9zcmMvc3lzL2tlcm4va2Vybl9kZXNjcmlwLmM6MTQ3NCAoc3g6 ZmlsZWRlc2Mgc3RydWN0dXJlKQogICAgIDk4NyAgICAgIDEwMjEgICAgICAgIDg1MzIgICAgICAg IDEyMzggICAgICAgICAgMjkgICAgMjk0ICAgICA0MiAgMCAgICAgIDIgL3Vzci9zcmMvc3lzL2tl cm4va2Vybl9tdXRleC5jOjEzNyAoc2xlZXAgbXV0ZXg6dm0gcGFnZSBxdWV1ZSBmcmVlIG11dGV4 KQogICAgMTI1NSAgICAgIDI5OTUgICAgICAyMDExNjAgICAgICAgNDEwNTYgICAgICAgIDE2MTUg ICAgMTI0ICAgICAyNSAgMCAgICAxOTQgL3Vzci9zcmMvc3lzL3ZtL3ZtX2ZhdWx0LmM6MzM2IChz bGVlcCBtdXRleDp2bSBwYWdlIHF1ZXVlIG11dGV4KQogICAgIDYyNiAgICAgICAgIDAgICAgICAg MjIxMzUgICAgICAgICAgIDAgICAgICAgICAxNjggICAgMTMxICAgICAgMCAgMCAgICAgIDAgL3Vz ci9zcmMvc3lzL2tlcm4vdmZzX21vdW50LmM6NDQzIChzbGVlcCBtdXRleDpzdHJ1Y3QgbW91bnQg bXR4KQogICAgMjk1NCAgICAgICAgIDAgICAgICA1NzI0OTUgICAgICAgICAgIDAgICAgICAgIDIx ODkgICAgMjYxICAgICAgMCAgMCAgICAgIDAgL3Vzci9zcmMvc3lzL3Vmcy9mZnMvZmZzX3Zmc29w cy5jOjEyOTQgKHNsZWVwIG11dGV4OnZub2RlIGludGVybG9jaykKICAgICA1NjcgICAgICAgICAw ICAgICAgICAxMzk5ICAgICAgICAgICAwICAgICAgICAgICA3ICAgIDE5OSAgICAgIDAgIDAgICAg ICAwIC91c3Ivc3JjL3N5cy92bS91bWFfY29yZS5jOjQxMCAoc2xlZXAgbXV0ZXg6aG9zdGNhY2hl KQogICAgIDY2OSAgICAgICAgIDAgICAgICAgIDI0ODYgICAgICAgICAgIDAgICAgICAgICAgNTAg ICAgIDQ5ICAgICAgMCAgMCAgICAgIDAgL3Vzci9zcmMvc3lzL3ZtL3VtYV9jb3JlLmM6MTk5MCAo c2xlZXAgbXV0ZXg6MTYpCiAgICAgOTUwICAgICAgIDYwNCAgICAgICAxOTQzMCAgICAgICAgIDYw NCAgICAgICAgIDE0NyAgICAxMzIgICAgICA0ICAwICAgICAgMSAvdXNyL3NyYy9zeXMva2Vybi92 ZnNfdm5vcHMuYzoxMDc0IChzbGVlcCBtdXRleDpzdHJ1Y3QgbW91bnQgbXR4KQogICAgNDQ2MSAg ICAgICAgIDAgICAgICAxMTQ4NzUgICAgICAgICAgIDAgICAgICAgICAgNDYgICAyNDk3ICAgICAg MCAgMCAgICAgIDAgL3Vzci9zcmMvc3lzL2tlcm4va2Vybl9leGl0LmM6NDk2IChzbGVlcCBtdXRl eDpwcm9jZXNzIGxvY2spCiAgICAgODg4ICAgICAgICAgMCAgICAgICAxMTE0NiAgICAgICAgICAg MCAgICAgICAgICAzMCAgICAzNzEgICAgICAwICAwICAgICAgMCAvdXNyL3NyYy9zeXMva2Vybi92 ZnNfc3Vici5jOjE2ODYgKHNsZWVwIG11dGV4OnZub2RlIGludGVybG9jaykKICAgIDI4MDQgICAg ICAgICAwICAgICAgIDE0ODU0ICAgICAgICAgICAwICAgICAgICAgIDIyICAgIDY3NSAgICAgIDAg IDAgICAgICAwIC91c3Ivc3JjL3N5cy9kZXYvZTEwMDAvaWZfZW0uYzoxMDMxIChzbGVlcCBtdXRl eDplbTApCiAgICAgNDQ5ICAgICAgICAgMCAgICAgICAgMzg1MSAgICAgICAgICAgMCAgICAgICAg ICAzOCAgICAxMDEgICAgICAwICAwICAgICAgMCAvdXNyL3NyYy9zeXMva2Vybi92ZnNfdm5vcHMu YzoxMDk2IChzbGVlcCBtdXRleDpzdHJ1Y3QgbW91bnQgbXR4KQogICAzMTIyMCAgICAgMjAzMzEg ICA0NjY1MDY1MTEgICAgICAyMjMxNjYgICAgIDE2MDAwMTcgICAgMjkxICAgICAgMCAgMCAgICAz NTMgL3Vzci9zcmMvc3lzL2tlcm4va2Vybl9kZXNjcmlwLmM6NzEwIChzbGVlcCBtdXRleDpwcm9j ZXNzIGxvY2spCiAgICAgNDc1ICAgICAgICAgMCAgICAgICAgMjk3MSAgICAgICAgICAgMCAgICAg ICAgICAyNiAgICAxMTQgICAgICAwICAwICAgICAgMCAvdXNyL3NyYy9zeXMva2Vybi9rZXJuX2V4 ZWMuYzoxMDAxIChzbGVlcCBtdXRleDpwcm9jZXNzX2V4ZWMpCiAgICAgNTUzICAgICAgICAgMCAg ICAgICAgMTQ4MiAgICAgICAgICAgMCAgICAgICAgICAxMyAgICAxMTQgICAgICAwICAwICAgICAg MCAvdXNyL3NyYy9zeXMva2Vybi9rZXJuX2Rlc2NyaXAuYzoxNTQ3IChzeDpmaWxlZGVzYyBzdHJ1 Y3R1cmUpCiAgICAgMTg2ICAgICAgICA4NyAgICAgICAgIDQ1OSAgICAgICAgICA4NyAgICAgICAg ICAgNyAgICAgNjUgICAgIDEyICAwICAgICAgMSAvdXNyL3NyYy9zeXMva2Vybi9rZXJuX3N5c2N0 bC5jOjE0MjEgKHNsZWVwIG11dGV4OkdpYW50KQogICAgODczNyAgICAgMTUyNzEgICAgIDQyOTk4 MDEgICAgICAzMzg4ODggICAgICAgMjUwMTYgICAgMTcxICAgICAxMyAgMCAgICA3NjkgL3Vzci9z cmMvc3lzL3ZtL3VtYV9jb3JlLmM6MjUyNCAoc2xlZXAgbXV0ZXg6Z19iaW8pCiAgICAgNzI0ICAg ICAgICAgMCAgICAgICAgMTI1NSAgICAgICAgICAgMCAgICAgICAgICAgNyAgICAxNzkgICAgICAw ICAwICAgICAgMCAvdXNyL3NyYy9zeXMvdm0vdW1hX2NvcmUuYzo0MTAgKHNsZWVwIG11dGV4OnR0 eW91dHEpCiAgICAgNDQ2ICAgICAgICAgMCAgICAgICAgMjY1NSAgICAgICAgICAgMCAgICAgICAg ICA0NiAgICAgNTcgICAgICAwICAwICAgICAgMCAvdXNyL3NyYy9zeXMva2Vybi9rZXJuX2Rlc2Ny aXAuYzoxNTc0IChzeDpmaWxlZGVzYyBzdHJ1Y3R1cmUpCiAgICAgNTgyICAgICAgICAgMCAgICAg ICAgMTM3NCAgICAgICAgICAgMCAgICAgICAgICAgNyAgICAxOTYgICAgICAwICAwICAgICAgMCAv dXNyL3NyYy9zeXMvdm0vdW1hX2NvcmUuYzo0MTAgKHNsZWVwIG11dGV4OktOT1RFKQogICAxNzA2 OCAgICAgMTUwMjMgICAgMjQwNzQ1NDAgICAgICA5MTYyODIgICAgICAgOTg4MTMgICAgMjQzICAg ICAgOSAgMCAgIDE0MTQgL3Vzci9zcmMvc3lzL2dlb20vZ2VvbV9pby5jOjY4IChzbGVlcCBtdXRl eDpiaW8gcXVldWUpCiAgICAgOTM5ICAgICAgICAyNSAgICAgICA1NDkzOCAgICAgICAgICAyNSAg ICAgICAgIDQ0NCAgICAxMjMgICAgICAwICAwICAgICAgMSAvdXNyL3NyYy9zeXMva2Vybi9rZXJu X3NpZy5jOjk4MSAoc2xlZXAgbXV0ZXg6cHJvY2VzcyBsb2NrKQogICAgIDQ0NiAgICAgICAgIDAg ICAgICAgIDM1NDQgICAgICAgICAgIDAgICAgICAgICAgNDYgICAgIDc3ICAgICAgMCAgMCAgICAg IDAgL3Vzci9zcmMvc3lzL2tlcm4va2Vybl9kZXNjcmlwLmM6MTU5OCAoc3g6ZmlsZWRlc2Mgc3Ry dWN0dXJlKQogICAgICA5NyAgICAgICAgIDAgICAgICAgICAgOTcgICAgICAgICAgIDAgICAgICAg ICAgIDEgICAgIDk3ICAgICAgMCAgMCAgICAgIDAgL3Vzci9zcmMvc3lzL3Vmcy9mZnMvZmZzX3Nv ZnRkZXAuYzo0MDcxIChzbGVlcCBtdXRleDpTb2Z0ZGVwIExvY2spCiAgICAgNDUxICAgICAgICAg MCAgICAgICAgMjg4OCAgICAgICAgICAgMCAgICAgICAgICA0NiAgICAgNjIgICAgICAwICAwICAg ICAgMCAvdXNyL3NyYy9zeXMva2Vybi9rZXJuX2Rlc2NyaXAuYzoxNjAzIChzeDpmaWxlZGVzYyBz dHJ1Y3R1cmUpCiAgICAgNzM1ICAgICAgICAgMCAgICAgICAgNTIzNyAgICAgICAgICAgMCAgICAg ICAgICAyNSAgICAyMDkgICAgICAwICAwICAgICAgMCAvdXNyL3NyYy9zeXMva2Vybi92ZnNfYmlv LmM6MzE4MyAoc2xlZXAgbXV0ZXg6dm0gb2JqZWN0KQogICAgIDEyOSAgICAgICAgIDAgICAgICAg ICA2NDcgICAgICAgICAgIDAgICAgICAgICAgIDcgICAgIDkyICAgICAgMCAgMCAgICAgIDAgL3Vz ci9zcmMvc3lzL3ZtL3VtYV9jb3JlLmM6NDEwIChzbGVlcCBtdXRleDpzY3RwX3N0cmVhbV9tc2df b3V0KQogICAgMzczNiAgICAgICAgIDAgICAgICAgNjQ1MzcgICAgICAgICAgIDAgICAgICAgICAg NjAgICAxMDc1ICAgICAgMCAgMCAgICAgIDAgL3Vzci9zcmMvc3lzL3ZtL3ZtX21hcC5jOjE2NzYg KHN4OnVzZXIgbWFwKQogICAzMDcwMCAgICAgICA5NDUgICAgIDQ5MjE5NDYgICAgICAgIDM0MjEg ICAgICAgMTU4NjQgICAgMzEwICAgICAgMCAgMCAgICAgIDcgL3Vzci9zcmMvc3lzL2tlcm4vdmZz X2Jpby5jOjI0MjkgKHNsZWVwIG11dGV4OmJ1Zm9iaiBpbnRlcmxvY2spCiAgICA2NTAzICAgICAg ICAgMCAgICAgICA2MzY2NSAgICAgICAgICAgMCAgICAgICAgIDM5OSAgICAxNTkgICAgICAwICAw ICAgICAgMCAvdXNyL3NyYy9zeXMvdm0vdW1hX2NvcmUuYzoyNjAyIChzbGVlcCBtdXRleDpnX2Jp bykKICAgICAgMzggICAgICAgICAwICAgICAgICAgIDc3ICAgICAgICAgICAwICAgICAgICAgICA0 ICAgICAxOSAgICAgIDAgIDAgICAgICAwIC91c3Ivc3JjL3N5cy9rZXJuL2tlcm5fcHJvYy5jOjMx OSAoc2xlZXAgbXV0ZXg6cHJvY2VzcyBncm91cCkKICAxNjUxNjkgICAgICAgICAwICAgICAgOTAy NDYzICAgICAgICAgICAwICAgICAgICAgIDE0ICA2NDQ2MSAgICAgIDAgIDAgICAgICAwIC91c3Iv c3JjL3N5cy92bS92bV9nbHVlLmM6Njg3IChzeDphbGxwcm9jKQogICAgMTEwNiAgICAgICAgIDAg ICAgICAgNDE2MzcgICAgICAgICAgIDAgICAgICAgICAxNDMgICAgMjkxICAgICAgMCAgMCAgICAg IDAgL3Vzci9zcmMvc3lzL2tlcm4vdmZzX2Jpby5jOjIwNzcgKHNsZWVwIG11dGV4OmJ1ZmZlciBk YWVtb24gbG9jaykKICAgIDU1NzYgICAgICAgICAwICAgICAgMTA0NDk4ICAgICAgICAgICAwICAg ICAgICAgIDY3ICAgMTU1OSAgICAgIDAgIDAgICAgICAwIC91c3Ivc3JjL3N5cy9rZXJuL2ltZ2Fj dF9lbGYuYzozMjMgKHN4OnVzZXIgbWFwKQogICAgIDc0MSAgICAgICA5MzYgICAgICAgIDM3NjEg ICAgICAgICA5MzYgICAgICAgICAgMTggICAgMjA4ICAgICA1MiAgMCAgICAgIDEgL3Vzci9zcmMv c3lzL3ZtL3VtYV9jb3JlLmM6MjY2MSAoc2xlZXAgbXV0ZXg6Z19iaW8pCiAgICAxMTcxICAgICAg ICAgMCAgICAgICAxMjYwMyAgICAgICAgICAgMCAgICAgICAgICAxOCAgICA3MDAgICAgICAwICAw ICAgICAgMCAvdXNyL3NyYy9zeXMva2Vybi92ZnNfc3Vici5jOjM0MjAgKHNsZWVwIG11dGV4OmJ1 Zm9iaiBpbnRlcmxvY2spCiAgICAyODM4ICAgICAgICAgMCAgICAgIDM5NjExNSAgICAgICAgICAg MCAgICAgICAgIDM2MCAgIDExMDAgICAgICAwICAwICAgICAgMCAvdXNyL3NyYy9zeXMvZGV2L3Vz YjIvY29yZS91c2IyX3RyYW5zZmVyLmM6MTUzNSAoc2xlZXAgbXV0ZXg6b2hjaTApCiAgICAgOTAy ICAgICAgICAgMCAgICAgICAgMjQ2NSAgICAgICAgICAgMCAgICAgICAgICAgNyAgICAzNTIgICAg ICAwICAwICAgICAgMCAvdXNyL3NyYy9zeXMvdm0vdW1hX2NvcmUuYzo0MTAgKHNsZWVwIG11dGV4 OjEyOCkKICAgICA2MzUgICAgICAgICAwICAgICAgICA4NjY2ICAgICAgICAgICAwICAgICAgICAg IDQ2ICAgIDE4OCAgICAgIDAgIDAgICAgICAwIC91c3Ivc3JjL3N5cy9rZXJuL2tlcm5fZGVzY3Jp cC5jOjE3MDIgKHN4OmZpbGVkZXNjIHN0cnVjdHVyZSkKICAgICA3NDAgICAgICAgICAwICAgICAg ICA3MDQ4ICAgICAgICAgICAwICAgICAgICAgIDQ2ICAgIDE1MyAgICAgIDAgIDAgICAgICAwIC91 c3Ivc3JjL3N5cy92bS91bWFfY29yZS5jOjI1MjQgKHNsZWVwIG11dGV4OlZNU1BBQ0UpCiAgICAz MTI5ICAgICAgICAgMCAgICAgICA4NjAxMyAgICAgICAgICAgMCAgICAgICAgIDE5NSAgICA0NDEg ICAgICAwICAwICAgICAgMCAvdXNyL3NyYy9zeXMvYW1kNjQvYW1kNjQvcG1hcC5jOjI0NzAgKHNs ZWVwIG11dGV4OnZtIHBhZ2UgcXVldWUgbXV0ZXgpCiAgICAgNDQ1ICAgICAgICAgMCAgICAgICAg IDc3NCAgICAgICAgICAgMCAgICAgICAgICAgNSAgICAxNTQgICAgICAwICAwICAgICAgMCAvdXNy L3NyYy9zeXMvdm0vdW1hX2NvcmUuYzo5MTQgKHNsZWVwIG11dGV4OlNMRUVQUVVFVUUpCiAgICAg OTQ5ICAgICAgICAgMCAgICAgICA1ODEwOSAgICAgICAgICAgMCAgICAgICAgIDMwNSAgICAxOTAg ICAgICAwICAwICAgICAgMCAvdXNyL3NyYy9zeXMva2Vybi9rZXJuX2Rlc2NyaXAuYzoxNzExIChz eDpmaWxlZGVzYyBzdHJ1Y3R1cmUpCiAgICAgIDM2ICAgICAgICAgMCAgICAgICAgICA1MiAgICAg ICAgICAgMCAgICAgICAgICAgMiAgICAgMjYgICAgICAwICAwICAgICAgMCAvdXNyL3NyYy9zeXMv a2Vybi9rZXJuX3Byb2MuYzozNzcgKHNsZWVwIG11dGV4OnByb2Nlc3MgZ3JvdXApCiAgICAxMTIz ICAgICAgICAgMCAgICAgICAyMTI4NiAgICAgICAgICAgMCAgICAgICAgICA0NiAgICA0NjIgICAg ICAwICAwICAgICAgMCAvdXNyL3NyYy9zeXMva2Vybi9rZXJuX2Rlc2NyaXAuYzoxNzE4IChzeDpm aWxlZGVzYyBzdHJ1Y3R1cmUpCiAgICAgNzE0ICAgICAgICAgMCAgICAgICAgMTY4MiAgICAgICAg ICAgMCAgICAgICAgICAxMyAgICAxMjkgICAgICAwICAwICAgICAgMCAvdXNyL3NyYy9zeXMva2Vy bi9rZXJuX2V4ZWMuYzozNTggKHNsZWVwIG11dGV4OnByb2Nlc3MgbG9jaykKICAgICA4OTcgICAg ICAgICAwICAgICAgICAxNDI3ICAgICAgICAgICAwICAgICAgICAgICAzICAgIDQ3NSAgICAgIDAg IDAgICAgICAwIC91c3Ivc3JjL3N5cy9mcy9kZXZmcy9kZXZmc192bm9wcy5jOjk2NCAobG9ja21n cjpkZXZmcykKICAgIDc0MDIgICAgICAxOTUwICAgICAxNDI1MjQ0ICAgICAgIDMyNTA2ICAgICAg ICAxMTkwICAgMTE5NyAgICAgMjcgIDAgICAgIDM1IC91c3Ivc3JjL3N5cy9rZXJuL2tlcm5fbXV0 ZXguYzoxMzcgKHNsZWVwIG11dGV4OnByb2Nlc3MgbG9jaykKICAgMTA1NTggICAgICAgICAwICAg ICAgNzcwMDQ2ICAgICAgICAgICAwICAgICAgICAgMzYwICAgMjEzOSAgICAgIDAgIDAgICAgICAw IC91c3Ivc3JjL3N5cy9kZXYvdXNiMi9jb3JlL3VzYjJfdHJhbnNmZXIuYzoxNTg5IChzbGVlcCBt dXRleDpvaGNpMCkKICAgIDgzMjYgICAgICAgICAwICAgICAgNDI5OTk3ICAgICAgICAgICAwICAg ICAgICAgMjU2ICAgMTY3OSAgICAgIDAgIDAgICAgICAwIC91c3Ivc3JjL3N5cy9rZXJuL3Zmc19s b29rdXAuYzo0NDIgKGxvY2ttZ3I6dWZzKQogICAgMTA1OCAgICAgIDgwNjUgICAgICAgMzA0Mjcg ICAgICAgOTk3MTAgICAgICAgICAzMjMgICAgIDk0ICAgIDMwOCAgMCAgICAgMzEgL3Vzci9zcmMv c3lzL3ZtL3VtYV9jb3JlLmM6MjUyNCAoc2xlZXAgbXV0ZXg6c2VsZmQpCiAgICAgODY2ICAgICAg ICAgMCAgICAgICA0OTcwMiAgICAgICAgICAgMCAgICAgICAgIDI4NCAgICAxNzUgICAgICAwICAw ICAgICAgMCAvdXNyL3NyYy9zeXMvbmV0aW5ldDYvZnJhZzYuYzo3MjMgKHNsZWVwIG11dGV4Omlw NnFsb2NrKQogICAgOTI2MSAgICAgICAgIDAgICAgICA0OTM2MTkgICAgICAgICAgIDAgICAgICAg IDMxMTYgICAgMTU4ICAgICAgMCAgMCAgICAgIDAgL3Vzci9zcmMvc3lzL2tlcm4vdmZzX2Jpby5j OjE5NjUgKHNsZWVwIG11dGV4OnN5c3RlbSBtYXApCiAgICAgOTU0ICAgICAgMzcwMyAgICAgIDIy NzcxNSAgICAgICAgNDk0NiAgICAgICAgMTkxNSAgICAxMTggICAgICAyICAwICAgICAgNiAvdXNy L3NyYy9zeXMvYW1kNjQvYW1kNjQvdHJhcC5jOjY0NyAoc2xlZXAgbXV0ZXg6cHJvY2VzcyBsb2Nr KQogICAgIDQ3NiAgICAgICAgIDAgICAgICAgIDE1MTkgICAgICAgICAgIDAgICAgICAgICAgMTgg ICAgIDg0ICAgICAgMCAgMCAgICAgIDAgL3Vzci9zcmMvc3lzL3ZtL3VtYV9jb3JlLmM6OTE0IChz bGVlcCBtdXRleDpNQVAgRU5UUlkpCiAgICAxNjc0ICAgICAgIDc5NyAgICAgIDIzMjM3OCAgICAg ICAgIDc5NyAgICAgICAgMTkxNSAgICAxMjEgICAgICAwICAwICAgICAgMSAvdXNyL3NyYy9zeXMv YW1kNjQvYW1kNjQvdHJhcC5jOjY1NiAoc2xlZXAgbXV0ZXg6cHJvY2VzcyBsb2NrKQogICAgIDQz MSAgICAgICAgIDAgICAgICAgICA3NzUgICAgICAgICAgIDAgICAgICAgICAgIDMgICAgMjU4ICAg ICAgMCAgMCAgICAgIDAgL3Vzci9zcmMvc3lzL2tlcm4va2Vybl9wcm9jLmM6NDQ5IChzbGVlcCBt dXRleDpwcm9jZXNzIGdyb3VwKQogICAgIDI1OCAgICAgICAgIDAgICAgICAgICA0MDEgICAgICAg ICAgIDAgICAgICAgICAgIDMgICAgMTMzICAgICAgMCAgMCAgICAgIDAgL3Vzci9zcmMvc3lzL2tl cm4va2Vybl9wcm9jLmM6NDUwIChzbGVlcCBtdXRleDpwcm9jZXNzIGdyb3VwKQogICA0NzcwOCAg ICAgICA1NDIgICAgIDE2OTcyMDUgICAgICAgICA1NDIgICAgICAgIDMxMTYgICAgNTQ0ICAgICAg MCAgMCAgICAgIDEgL3Vzci9zcmMvc3lzL2tlcm4vdmZzX2Jpby5jOjI1OTAgKHNsZWVwIG11dGV4 OmJ1Zm9iaiBpbnRlcmxvY2spCiAgICAxNjU1ICAgICAgICAgMCAgICAgICAxNTk0NiAgICAgICAg ICAgMCAgICAgICAgICAyNSAgICA2MzcgICAgICAwICAwICAgICAgMCAvdXNyL3NyYy9zeXMva2Vy bi92ZnNfYmlvLmM6MzM5NiAoc2xlZXAgbXV0ZXg6dm0gb2JqZWN0KQogICAgIDc1MiAgICAgICAg IDAgICAgICAgMjQwODQgICAgICAgICAgIDAgICAgICAgICAxNDMgICAgMTY4ICAgICAgMCAgMCAg ICAgIDAgL3Vzci9zcmMvc3lzL2Rldi9lMTAwMC9pZl9lbS5jOjEzMzIgKHNsZWVwIG11dGV4OmVt MCkKICAgICA4NDYgICAgICAgICAwICAgICAgIDEwMTQ1ICAgICAgICAgICAwICAgICAgICAgIDM2 ICAgIDI4MSAgICAgIDAgIDAgICAgICAwIC91c3Ivc3JjL3N5cy9kZXYvdXNiMi9jb250cm9sbGVy L29oY2kyLmM6MjgyNSAoc2xlZXAgbXV0ZXg6b2hjaTApCiAgICAgNjExICAgICAgICAgMCAgICAg ICAgMjA3MyAgICAgICAgICAgMCAgICAgICAgICAxNSAgICAxMzggICAgICAwICAwICAgICAgMCAv dXNyL3NyYy9zeXMva2Vybi9rZXJuX2Rlc2NyaXAuYzoxODMzIChzeDpmaWxlZGVzYyBzdHJ1Y3R1 cmUpCiAgICAxMjYzICAgICAgICAgMCAgICAgICAxMDA4NSAgICAgICAgICAgMCAgICAgICAgICAz NSAgICAyODggICAgICAwICAwICAgICAgMCAvdXNyL3NyYy9zeXMvZGV2L3VzYjIvY29udHJvbGxl ci9laGNpMi5jOjM5MjkgKHNsZWVwIG11dGV4OmVoY2kwKQogICAgIDM5MiAgICAgICAgIDAgICAg ICAgICA2OTMgICAgICAgICAgIDAgICAgICAgICAgIDIgICAgMzQ2ICAgICAgMCAgMCAgICAgIDAg L3Vzci9zcmMvc3lzL2tlcm4va2Vybl9wcm90LmM6MzkxIChzeDpwcm9jdHJlZSkKICAgICA0NTIg ICAgICAgICAwICAgICAgICAxNzU1ICAgICAgICAgICAwICAgICAgICAgIDEzICAgIDEzNSAgICAg IDAgIDAgICAgICAwIC91c3Ivc3JjL3N5cy9rZXJuL2tlcm5fZGVzY3JpcC5jOjE4NTcgKHN4OmZp bGVkZXNjIHN0cnVjdHVyZSkKICAgIDE2MTEgICAgICAxMTAwICAgICAgMTMzNDIzICAgICAgIDQ1 NDIwICAgICAgICAgNzIwICAgIDE4NSAgICAgNjMgIDAgICAgMTI1IC91c3Ivc3JjL3N5cy9kZXYv dXNiMi9jb3JlL3VzYjJfdHJhbnNmZXIuYzoxNzAzIChzbGVlcCBtdXRleDpvaGNpMCkKICAgICAg MjUgICAgICAgICAwICAgICAgICAgIDc5ICAgICAgICAgICAwICAgICAgICAgICA0ICAgICAxOSAg ICAgIDAgIDAgICAgICAwIC91c3Ivc3JjL3N5cy9rZXJuL2tlcm5fcHJvYy5jOjUyNyAoc2xlZXAg bXV0ZXg6cHJvY2VzcyBncm91cCkKICAgIDMwODMgICAgICAyODU3ICAgICAgIDgyMzY3ICAgICAg ICA3NDg4ICAgICAgICAgIDcxICAgMTE2MCAgICAxMDUgIDAgICAgICA5IC91c3Ivc3JjL3N5cy9k ZXYvdXNiMi9jb250cm9sbGVyL3VzYjJfY29udHJvbGxlci5jOjIxMSAoc2xlZXAgbXV0ZXg6R2lh bnQpCiAgICAgMTI3ICAgICAgICAgMCAgICAgICAgIDIwOCAgICAgICAgICAgMCAgICAgICAgICAx MCAgICAgMjAgICAgICAwICAwICAgICAgMCAvdXNyL3NyYy9zeXMva2Vybi9rZXJuX2Rlc2NyaXAu YzoxODgyIChzeDpmaWxlZGVzYyBzdHJ1Y3R1cmUpCiAgICA2Njc1ICAgICAgICAgMCAgICAgIDEz MDA2NyAgICAgICAgICAgMCAgICAgICAgICA3MCAgIDE4NTggICAgICAwICAwICAgICAgMCAvdXNy L3NyYy9zeXMva2Vybi92ZnNfdm5vcHMuYzoyOTMgKGxvY2ttZ3I6dWZzKQogICAgMTcyMyAgICAg ICAgIDAgICAgICAgNDE4NzkgICAgICAgICAgIDAgICAgICAgICAxMDYgICAgMzk1ICAgICAgMCAg MCAgICAgIDAgL3Vzci9zcmMvc3lzL2tlcm4vdmZzX2Jpby5jOjM0NjggKHNsZWVwIG11dGV4OnZt IG9iamVjdCkKICAgIDE5MjcgICAgICAgICAwICAgICAgMTU1OTA5ICAgICAgICAgICAwICAgICAg ICAgMjI3ICAgIDY4NiAgICAgIDAgIDAgICAgICAwIC91c3Ivc3JjL3N5cy9uZXQvYnBmLmM6MTY0 MSAoc2xlZXAgbXV0ZXg6YnBmIGludGVyZmFjZSBsb2NrKQogICAgMjg5NSAgICAgICAgIDAgICAg ICAzODc4MTggICAgICAgICAgIDAgICAgICAgICAzNTAgICAxMTA4ICAgICAgMCAgMCAgICAgIDAg L3Vzci9zcmMvc3lzL2Rldi91c2IyL2NvcmUvdXNiMl90cmFuc2Zlci5jOjE1MzUgKHNsZWVwIG11 dGV4OmVoY2kwKQogICAgIDcyMSAgICAgICAgIDAgICAgICAgIDk3MDMgICAgICAgICAgIDAgICAg ICAgICAgMzQgICAgMjg1ICAgICAgMCAgMCAgICAgIDAgL3Vzci9zcmMvc3lzL2tlcm4vdmZzX3N1 YnIuYzoyMDkwIChzbGVlcCBtdXRleDp2bm9kZSBpbnRlcmxvY2spCiAgICAgNjM3ICAgICAgICAg MCAgICAgICAgMTQ1OCAgICAgICAgICAgMCAgICAgICAgICAgNyAgICAyMDggICAgICAwICAwICAg ICAgMCAvdXNyL3NyYy9zeXMvdm0vdW1hX2NvcmUuYzo0MTAgKHNsZWVwIG11dGV4Om10X3pvbmUp CiAgICAxNTM1ICAgICAgICAgMCAgICAgICAxMDAxNCAgICAgICAgICAgMCAgICAgICAgICAxMyAg ICA3NzAgICAgICAwICAwICAgICAgMCAvdXNyL3NyYy9zeXMva2Vybi9rZXJuX2V4ZWMuYzo1NzIg KHNsZWVwIG11dGV4OnByb2Nlc3MgbG9jaykKICAgICA3MjkgICAgICAgICAwICAgICAgIDk5Njgx ICAgICAgICAgICAwICAgICAgICAgNjQ1ICAgIDE1NCAgICAgIDAgIDAgICAgICAwIC91c3Ivc3Jj L3N5cy9rZXJuL3Zmc19zdWJyLmM6MjEwMCAoc2xlZXAgbXV0ZXg6dm5vZGUgaW50ZXJsb2NrKQog ICAgIDg3MCAgICAgICA1NDMgICAgICAgNDAxNDIgICAgICAgIDQwNTQgICAgICAgICA0NTYgICAg IDg4ICAgICAgOCAgMCAgICAgMzEgL3Vzci9zcmMvc3lzL3ZtL3ZtX29iamVjdC5jOjEyMzggKHNs ZWVwIG11dGV4OnZtIG9iamVjdCkKICAgMTIyMzMgICAgICAgICAwICAgICAgIDU1MjY5ICAgICAg ICAgICAwICAgICAgICAgIDIwICAgMjc2MyAgICAgIDAgIDAgICAgICAwIC91c3Ivc3JjL3N5cy9r ZXJuL3VpcGNfc29ja2J1Zi5jOjE0OCAoc3g6c29fc25kX3N4KQogICAgIDE3OSAgICAgICAgIDAg ICAgICAgICA2NTcgICAgICAgICAgIDAgICAgICAgICAgIDcgICAgIDkzICAgICAgMCAgMCAgICAg IDAgL3Vzci9zcmMvc3lzL3ZtL3VtYV9jb3JlLmM6NDEwIChzbGVlcCBtdXRleDozMikKICAgICA1 ODYgICAgICAgICAwICAgICAgICAzNjk1ICAgICAgICAgICAwICAgICAgICAgIDI5ICAgIDEyNyAg ICAgIDAgIDAgICAgICAwIC91c3Ivc3JjL3N5cy92bS92bV9tYXAuYzozMjU3IChzbGVlcCBtdXRl eDpzeXN0ZW0gbWFwKQogICAgIDk4NiAgICAgICAyNzggICAgICAgNjA5MDggICAgICAgIDI0NTYg ICAgICAgICAyMTYgICAgMjgxICAgICAxMSAgMCAgICAgMzIgL3Vzci9zcmMvc3lzL2FtZDY0L2Ft ZDY0L3BtYXAuYzoyNzE3IChzbGVlcCBtdXRleDp2bSBwYWdlIHF1ZXVlIG11dGV4KQogICAgIDQ1 MiAgICAgICAgIDAgICAgICAgIDE2MzQgICAgICAgICAgIDAgICAgICAgICAgMTQgICAgMTE2ICAg ICAgMCAgMCAgICAgIDAgL3Vzci9zcmMvc3lzL3ZtL3VtYV9jb3JlLmM6OTE0IChzbGVlcCBtdXRl eDo1MTIpCiAgICAgNzE4ICAgICAgICAgMCAgICAgICAgNDI3OCAgICAgICAgICAgMCAgICAgICAg ICAxOCAgICAyMzcgICAgICAwICAwICAgICAgMCAvdXNyL3NyYy9zeXMvdWZzL2Zmcy9mZnNfdmZz b3BzLmM6MTI3NiAoc2xlZXAgbXV0ZXg6c3RydWN0IG1vdW50IG10eCkKICAgIDE1ODUgICAgICA3 NDE3ICAgICAgMjIxNTk1ICAgICAgIDI1OTEyICAgICAgICAxNjgwICAgIDEzMSAgICAgMTUgIDAg ICAgIDQ4IC91c3Ivc3JjL3N5cy9rZXJuL3Zmc19zdWJyLmM6MjEyNyAoc2xlZXAgbXV0ZXg6dm5v ZGUgaW50ZXJsb2NrKQogICAgIDkzNiAgICAgICAgIDAgICAgICAgIDQ2NDggICAgICAgICAgIDAg ICAgICAgICAgMTggICAgMjU4ICAgICAgMCAgMCAgICAgIDAgL3Vzci9zcmMvc3lzL3Vmcy9mZnMv ZmZzX3Zmc29wcy5jOjEyODUgKHNsZWVwIG11dGV4OnN0cnVjdCBtb3VudCBtdHgpCiAgICAxMDQx ICAgICAgICAgMCAgICAgIDE1OTU1MyAgICAgICAgICAgMCAgICAgICAgIDY4NyAgICAyMzIgICAg ICAwICAwICAgICAgMCAvdXNyL3NyYy9zeXMvZGV2L3VzYjIvY29yZS91c2IyX3RyYW5zZmVyLmM6 MTgxMCAoc2xlZXAgbXV0ZXg6b2hjaTApCiAgICAgMTg4ICAgICAgICAgMCAgICAgICAgIDQwNiAg ICAgICAgICAgMCAgICAgICAgICAgNCAgICAxMDEgICAgICAwICAwICAgICAgMCAvdXNyL3NyYy9z eXMva2Vybi90dHkuYzoxNTE1IChzbGVlcCBtdXRleDp0dHltdHgpCiAgICAgOTIwICAgICAgMTEx NiAgICAgICAzODcwNyAgICAgICAgNDc1NSAgICAgICAgIDQzMiAgICAgODkgICAgIDExICAwICAg ICAyMyAvdXNyL3NyYy9zeXMvdm0vdm1fb2JqZWN0LmM6MTI3MSAoc2xlZXAgbXV0ZXg6dm0gb2Jq ZWN0KQogICAgIDc2NiAgICAgICAgIDAgICAgICAgIDIwNjAgICAgICAgICAgIDAgICAgICAgICAg MTMgICAgMTU4ICAgICAgMCAgMCAgICAgIDAgL3Vzci9zcmMvc3lzL3ZtL3ZtX21hcC5jOjI4NzEg KHNsZWVwIG11dGV4OnByb2Nlc3MgbG9jaykKICAgIDc3NDMgICAgICAgICAwICAgICAgODE5MTcw ICAgICAgICAgICAwICAgICAgICAgMzUwICAgMjM0MCAgICAgIDAgIDAgICAgICAwIC91c3Ivc3Jj L3N5cy9kZXYvdXNiMi9jb3JlL3VzYjJfdHJhbnNmZXIuYzoxNTg5IChzbGVlcCBtdXRleDplaGNp MCkKICAgICAxMTMgICAgICAgICAwICAgICAgICAgNTcwICAgICAgICAgICAwICAgICAgICAgICA3 ICAgICA4MSAgICAgIDAgIDAgICAgICAwIC91c3Ivc3JjL3N5cy92bS91bWFfY29yZS5jOjQxMCAo c2xlZXAgbXV0ZXg6U1dBUE1FVEEpCiAgICAgOTY4ICAgICAgIDY1MiAgICAgIDIwODA5MyAgICAg ICAgNDc5MSAgICAgICAgMTM1NSAgICAxNTMgICAgICAzICAwICAgICAxNCAvdXNyL3NyYy9zeXMv a2Vybi92ZnNfc3Vici5jOjIxNjYgKHNsZWVwIG11dGV4OnZub2RlIGludGVybG9jaykKICAgICA2 MTkgICAgICAgICAwICAgICAgIDIyNTQ4ICAgICAgICAgICAwICAgICAgICAgMTgxICAgIDEyNCAg ICAgIDAgIDAgICAgICAwIC91c3Ivc3JjL3N5cy92bS91bWFfY29yZS5jOjI0NjQgKHNsZWVwIG11 dGV4OlVNQSBTbGFicykKICAgICA2NTMgICAgICAgICAwICAgICAgICAyODA2ICAgICAgICAgICAw ICAgICAgICAgIDUwICAgICA1NiAgICAgIDAgIDAgICAgICAwIC91c3Ivc3JjL3N5cy92bS91bWFf Y29yZS5jOjI1MjQgKHNsZWVwIG11dGV4OjE2KQogICAgIDYwNyAgICAgICAgIDAgICAgICAgIDI1 MTEgICAgICAgICAgIDAgICAgICAgICAgMjYgICAgIDk2ICAgICAgMCAgMCAgICAgIDAgL3Vzci9z cmMvc3lzL3ZtL3ZtX2dsdWUuYzoyNzAgKHNsZWVwIG11dGV4OnZtIHBhZ2UgcXVldWUgbXV0ZXgp CiAgICAgNDY4ICAgICAgICAgMCAgICAgICAgNDg3OSAgICAgICAgICAgMCAgICAgICAgICA0NSAg ICAxMDggICAgICAwICAwICAgICAgMCAvdXNyL3NyYy9zeXMva2Vybi9rZXJuX3NpZy5jOjY1NiAo c2xlZXAgbXV0ZXg6c2lnYWN0cykKICAgICA1MzMgICAgICAgICAwICAgICAgICAgOTg4ICAgICAg ICAgICAwICAgICAgICAgICAyICAgIDQ5NCAgICAgIDAgIDAgICAgICAwIC91c3Ivc3JjL3N5cy9u ZXRpbmV0Ni9pbjZfcm14LmM6Mzg0IChydzpyYWRpeCBub2RlIGhlYWQpCiAgICAgNDkwICAgICAg ICAgMCAgICAgICAgMzMyMyAgICAgICAgICAgMCAgICAgICAgICAyNSAgICAxMzIgICAgICAwICAw ICAgICAgMCAvdXNyL3NyYy9zeXMva2Vybi92ZnNfc3Vici5jOjIxOTggKHNsZWVwIG11dGV4OnZu b2RlIGludGVybG9jaykKICAgNTQ0ODkgICAgICAgICAwICAgICA1MzA3MTUyICAgICAgICAgICAw ICAgICAgICAzMTE1ICAgMTcwMyAgICAgIDAgIDAgICAgICAwIC91c3Ivc3JjL3N5cy9rZXJuL3Zm c19iaW8uYzozNjExIChzbGVlcCBtdXRleDp2bSBvYmplY3QpCiAgICAgNzIzICAgICAgICAgMCAg ICAgICAgMTcxMCAgICAgICAgICAgMCAgICAgICAgICAgNyAgICAyNDQgICAgICAwICAwICAgICAg MCAvdXNyL3NyYy9zeXMvdm0vdW1hX2NvcmUuYzo0MTAgKHNsZWVwIG11dGV4OjY0KQogICAgODM4 NyAgICAgICAgIDAgICAgIDI2MjQ0MTQgICAgICAgICAgIDAgICAgICAgIDkyODcgICAgMjgyICAg ICAgMCAgMCAgICAgIDAgL3Vzci9zcmMvc3lzL2tlcm4va2Vybl9kZXNjcmlwLmM6MjA1MiAoc3g6 ZmlsZWRlc2Mgc3RydWN0dXJlKQogICAgIDQ2MSAgICAgICAgIDAgICAgICAgIDM5MDIgICAgICAg ICAgIDAgICAgICAgICAgMjYgICAgMTUwICAgICAgMCAgMCAgICAgIDAgL3Vzci9zcmMvc3lzL3Zt L3ZtX2dsdWUuYzozMDYgKHNsZWVwIG11dGV4OnZtIHBhZ2UgcXVldWUgbXV0ZXgpCiAgICAgNjAz ICAgICAgICAgMCAgICAgICAgMTA3NCAgICAgICAgICAgMCAgICAgICAgICAgNyAgICAxNTMgICAg ICAwICAwICAgICAgMCAvdXNyL3NyYy9zeXMvdm0vdW1hX2NvcmUuYzo0MTAgKHNsZWVwIG11dGV4 OkZGUyBpbm9kZSkKICAgICA5ODMgICAgICAgICAwICAgICAgMjEyOTcwICAgICAgICAgICAwICAg ICAgICAxMDA0ICAgIDIxMiAgICAgIDAgIDAgICAgICAwIC91c3Ivc3JjL3N5cy9rZXJuL3Zmc19z dWJyLmM6MjIyNyAoc2xlZXAgbXV0ZXg6dm5vZGUgaW50ZXJsb2NrKQogICAgIDg3NCAgICAgICAg IDAgICAgICAgIDI0ODAgICAgICAgICAgIDAgICAgICAgICAgIDcgICAgMzU0ICAgICAgMCAgMCAg ICAgIDAgL3Vzci9zcmMvc3lzL3ZtL3VtYV9jb3JlLmM6NDEwIChzbGVlcCBtdXRleDptYnVmX2Ns dXN0ZXIpCiAgICAgNzUwICAgICAgICAgMCAgICAgICAgMTU4OCAgICAgICAgICAgMCAgICAgICAg ICAgNyAgICAyMjYgICAgICAwICAwICAgICAgMCAvdXNyL3NyYy9zeXMvdm0vdW1hX2NvcmUuYzo0 MTAgKHNsZWVwIG11dGV4OjE2IEJ1Y2tldCkKICAgICAxNTYgICAgICAgICAwICAgICAgICAgNjI3 ICAgICAgICAgICAwICAgICAgICAgICA3ICAgICA4OSAgICAgIDAgIDAgICAgICAwIC91c3Ivc3Jj L3N5cy92bS91bWFfY29yZS5jOjQxMCAoc2xlZXAgbXV0ZXg6YXRhX3JlcXVlc3QpCiAgICAgOTU3 ICAgICAgMjg0MSAgICAgIDIyNTQ0MiAgICAgICAzNzg4MiAgICAgICAgMTk0NCAgICAxMTUgICAg IDE5ICAwICAgIDE4NSAvdXNyL3NyYy9zeXMvdm0vdm1fZmF1bHQuYzo5MzUgKHNsZWVwIG11dGV4 OnZtIHBhZ2UgcXVldWUgbXV0ZXgpCiAgICAxNjI1ICAgICAgMTIyOCAgICAgIDEzNzQ0MCAgICAg ICA0ODcwNSAgICAgICAgIDcwMCAgICAxOTYgICAgIDY5ICAwICAgIDEyOSAvdXNyL3NyYy9zeXMv ZGV2L3VzYjIvY29yZS91c2IyX3RyYW5zZmVyLmM6MTcwMyAoc2xlZXAgbXV0ZXg6ZWhjaTApCiAg ICAgODE4ICAgICAgICAgMCAgICAgICA1MzY1NyAgICAgICAgICAgMCAgICAgICAgIDQwNSAgICAx MzIgICAgICAwICAwICAgICAgMCAvdXNyL3NyYy9zeXMva2Vybi92ZnNfc3Vici5jOjIyNTYgKHNs ZWVwIG11dGV4OnZub2RlIGludGVybG9jaykKICAgICAxMzEgICAgICAgICAwICAgICAgICAgNjAy ICAgICAgICAgICAwICAgICAgICAgICA3ICAgICA4NiAgICAgIDAgIDAgICAgICAwIC91c3Ivc3Jj L3N5cy92bS91bWFfY29yZS5jOjQxMCAoc2xlZXAgbXV0ZXg6Vk5PREUpCiAgICAxOTM5ICAgICAg MTczMSAgICAgIDMzNjIzNSAgICAgICAyODkzNyAgICAgICAgIDcyMCAgICA0NjYgICAgIDQwICAw ICAgICAzMyAvdXNyL3NyYy9zeXMvZGV2L3VzYjIvY29yZS91c2IyX3RyYW5zZmVyLmM6MTk0MiAo c2xlZXAgbXV0ZXg6b2hjaTApCiAgICAgNTkwICAgICAgICAgMCAgICAgICAgMTEyNyAgICAgICAg ICAgMCAgICAgICAgICAgNyAgICAxNjEgICAgICAwICAwICAgICAgMCAvdXNyL3NyYy9zeXMvdm0v dW1hX2NvcmUuYzo0MTAgKHNsZWVwIG11dGV4OmtzaWdpbmZvKQogICAgNjQwOSAgICAgICAgIDAg ICAgICA0NzQ2OTkgICAgICAgICAgIDAgICAgICAgIDMxMzIgICAgMTUxICAgICAgMCAgMCAgICAg IDAgL3Vzci9zcmMvc3lzL2tlcm4vdmZzX3N1YnIuYzoyMjc5IChzbGVlcCBtdXRleDp2bm9kZSBp bnRlcmxvY2spCiAgICA1Nzg4ICAgICAgICAgMCAgICAgIDE5MzgzNiAgICAgICAgICAgMCAgICAg ICAgICA5NiAgIDIwMTkgICAgICAwICAwICAgICAgMCAvdXNyL3NyYy9zeXMva2Vybi92ZnNfdm5v cHMuYzo1MzEgKGxvY2ttZ3I6dWZzKQogICAgNDA0OSAgICAgICAgIDAgICAgICAgMTA2MjYgICAg ICAgICAgIDAgICAgICAgICAgMTMgICAgODE3ICAgICAgMCAgMCAgICAgIDAgL3Vzci9zcmMvc3lz L3ZtL3ZtX2tlcm4uYzo0MzIgKHN4OnVzZXIgbWFwKQogICAgIDIwMSAgICAgICAgIDAgICAgICAg ICA4OTEgICAgICAgICAgIDAgICAgICAgICAgMzUgICAgIDI1ICAgICAgMCAgMCAgICAgIDAgL3Vz ci9zcmMvc3lzL2tlcm4vc3lzX3BpcGUuYzo1NzggKHNsZWVwIG11dGV4OnBpcGUgbXV0ZXgpCiAg ICAgNjMzICAgICAgICAgMCAgICAgICAgOTg5NyAgICAgICAgICAgMCAgICAgICAgICA2NiAgICAx NDkgICAgICAwICAwICAgICAgMCAvdXNyL3NyYy9zeXMvdm0vdW1hX2NvcmUuYzoxOTkwIChzbGVl cCBtdXRleDoyNTYpCiAgICAgNjA3ICAgICAgICAgMCAgICAgICAgNjI5MyAgICAgICAgICAgMCAg ICAgICAgICA0NSAgICAxMzkgICAgICAwICAwICAgICAgMCAvdXNyL3NyYy9zeXMva2Vybi92ZnNf c3Vici5jOjIzMDIgKHNsZWVwIG11dGV4OnZub2RlIGludGVybG9jaykKICAgMTA1OTAgICAgICAg ICAwICAgICAgIDk5OTU0ICAgICAgICAgICAwICAgICAgICAgIDM2ICAgMjc3NiAgICAgIDAgIDAg ICAgICAwIC91c3Ivc3JjL3N5cy9kZXYvdXNiMi9jb3JlL3VzYjJfaHViLmM6MTM1MSAoc2xlZXAg bXV0ZXg6b2hjaTApCiAgICA0ODQ0ICAgICAgICAgMCAgICAgICAzOTE0NyAgICAgICAgICAgMCAg ICAgICAgICAxMyAgIDMwMTEgICAgICAwICAwICAgICAgMCAvdXNyL3NyYy9zeXMvdm0vdm1fa2Vy bi5jOjQ2MyAoc3g6dXNlciBtYXApCiAgICAgODUwICAgICAgICAgMCAgICAgICAgMTMxNSAgICAg ICAgICAgMCAgICAgICAgICAgNyAgICAxODcgICAgICAwICAwICAgICAgMCAvdXNyL3NyYy9zeXMv dm0vdW1hX2NvcmUuYzo0MTAgKHNsZWVwIG11dGV4OnJ0ZW50cnkpCiAgICAgNTc5ICAgICAgICAg MCAgICAgICAyNDY0MSAgICAgICAgICAgMCAgICAgICAgIDEyMSAgICAyMDMgICAgICAwICAwICAg ICAgMCAvdXNyL3NyYy9zeXMva2Vybi92ZnNfaGFzaC5jOjcxIChzbGVlcCBtdXRleDp2ZnMgaGFz aCkKICAgNjk3MzIgICAgICAxNzkyICAgNDY3NzA2NTcwICAgICAgMTQ5ODI2ICAgICAxNjAwMTA5 ICAgIDI5MiAgICAgIDAgIDAgICAgMjc2IC91c3Ivc3JjL3N5cy9rZXJuL2tlcm5fZGVzY3JpcC5j OjEzNDIgKHNsZWVwIG11dGV4OnByb2Nlc3MgbG9jaykKICAgICA0NTAgICAgICAgICAwICAgICAg ICAgOTg5ICAgICAgICAgICAwICAgICAgICAgIDMzICAgICAyOSAgICAgIDAgIDAgICAgICAwIC91 c3Ivc3JjL3N5cy9rZXJuL3N5c19waXBlLmM6NjE1IChzbGVlcCBtdXRleDpwaXBlIG11dGV4KQog ICAgMjA1OCAgICAgICA3NzkgICAgICA3ODUzOTcgICAgICAgMTI3NzUgICAgICAgIDIwOTkgICAg Mzc0ICAgICAgNiAgMCAgICAgNzcgL3Vzci9zcmMvc3lzL3ZtL3ZtX2ZhdWx0LmM6MTAyOSAoc2xl ZXAgbXV0ZXg6dm0gcGFnZSBxdWV1ZSBtdXRleCkKICAgIDE4NDkgICAgICAgICAwICAgICAgMTU4 MDk4ICAgICAgICAgICAwICAgICAgICAgNDkxICAgIDMyMSAgICAgIDAgIDAgICAgICAwIC91c3Iv c3JjL3N5cy9rZXJuL3Zmc19zdWJyLmM6MjM1MSAoc2xlZXAgbXV0ZXg6dm5vZGUgaW50ZXJsb2Nr KQogICAgMTY5MyAgICAgICAgIDAgICAgICAxNDc2MzggICAgICAgICAgIDAgICAgICAgICA2NDYg ICAgMjI4ICAgICAgMCAgMCAgICAgIDAgL3Vzci9zcmMvc3lzL2Rldi91c2IyL2NvcmUvdXNiMl90 cmFuc2Zlci5jOjE4MTAgKHNsZWVwIG11dGV4OmVoY2kwKQogICAgMjMwNSAgICAgIDE2NjQgICAg ICA1ODUxNTMgICAgICAgMjYzMTEgICAgICAgIDE5NDQgICAgMzAxICAgICAxMyAgMCAgICAxNDEg L3Vzci9zcmMvc3lzL2FtZDY0L2FtZDY0L3BtYXAuYzoyOTY0IChzbGVlcCBtdXRleDp2bSBwYWdl IHF1ZXVlIG11dGV4KQogICAgICA5MyAgICAgICAgIDAgICAgICAgICAyOTUgICAgICAgICAgIDAg ICAgICAgICAgIDUgICAgIDU5ICAgICAgMCAgMCAgICAgIDAgL3Vzci9zcmMvc3lzL3ZtL3VtYV9j b3JlLmM6MTk5MCAoc2xlZXAgbXV0ZXg6cGlwZSkKICAgICA1MTkgICAgICAgICAwICAgICAgICAx MDE0ICAgICAgICAgICAwICAgICAgICAgICA3ICAgIDE0NCAgICAgIDAgIDAgICAgICAwIC91c3Iv c3JjL3N5cy92bS91bWFfY29yZS5jOjQxMCAoc2xlZXAgbXV0ZXg6c2N0cF9hc2NvbmYpCiAgICAg MTcwICAgICAgICAgMCAgICAgICAgIDczMyAgICAgICAgICAgMCAgICAgICAgICAgNyAgICAxMDQg ICAgICAwICAwICAgICAgMCAvdXNyL3NyYy9zeXMvdm0vdW1hX2NvcmUuYzo0MTAgKHNsZWVwIG11 dGV4OlRVUk5TVElMRSkKICAgICAgOTggICAgICAgICAwICAgICAgICAgNTY0ICAgICAgICAgICAw ICAgICAgICAgICA3ICAgICA4MCAgICAgIDAgIDAgICAgICAwIC91c3Ivc3JjL3N5cy92bS91bWFf Y29yZS5jOjQxMCAoc2xlZXAgbXV0ZXg6TUFQKQogICAgIDE0MyAgICAgICAgIDAgICAgICAgICA2 MDIgICAgICAgICAgIDAgICAgICAgICAgIDcgICAgIDg2ICAgICAgMCAgMCAgICAgIDAgL3Vzci9z cmMvc3lzL3ZtL3VtYV9jb3JlLmM6NDEwIChzbGVlcCBtdXRleDpOQU1FSSkKICAgICA0NzIgICAg ICAgICAwICAgICAgICAyNTM0ICAgICAgICAgICAwICAgICAgICAgIDQ2ICAgICA1NSAgICAgIDAg IDAgICAgICAwIC91c3Ivc3JjL3N5cy9rZXJuL2tlcm5fZXZlbnQuYzoxNzMxIChzbGVlcCBtdXRl eDpwcm9jZXNzIGxvY2spCiAgICAgNDU1ICAgICAgICAgMCAgICAgICAgMjc2MiAgICAgICAgICAg MCAgICAgICAgICAyNyAgICAxMDIgICAgICAwICAwICAgICAgMCAvdXNyL3NyYy9zeXMva2Vybi9r ZXJuX2V4ZWMuYzo5NTIgKHNsZWVwIG11dGV4OnZtIHBhZ2UgcXVldWUgbXV0ZXgpCiAgIDExMDM4 ICAgICAgICAgMCAgICAgICAzMDEyNSAgICAgICAgICAgMCAgICAgICAgICAxNyAgIDE3NzIgICAg ICAwICAwICAgICAgMCAvdXNyL3NyYy9zeXMva2Vybi91aXBjX3NvY2tidWYuYzoxNDggKHN4OnNv X3Jjdl9zeCkKICAgICA4ODkgICAgICAgICAwICAgICAgICAxOTMxICAgICAgICAgICAwICAgICAg ICAgIDIwICAgICA5NiAgICAgIDAgIDAgICAgICAwIC91c3Ivc3JjL3N5cy9rZXJuL3VpcGNfc29j a2V0LmM6MTE0MSAoc2xlZXAgbXV0ZXg6c29fc25kKQogICAgIDY4NSAgICAgICAgIDAgICAgICAg IDc4NDggICAgICAgICAgIDAgICAgICAgICAgMjAgICAgMzkyICAgICAgMCAgMCAgICAgIDAgL3Vz ci9zcmMvc3lzL2tlcm4vdmZzX3Zub3BzLmM6Njc2IChsb2NrbWdyOnVmcykKICAgICA2MDggICAg ICAgICAwICAgICAgICA2NDMzICAgICAgICAgICAwICAgICAgICAgIDQ2ICAgIDEzOSAgICAgIDAg IDAgICAgICAwIC91c3Ivc3JjL3N5cy9rZXJuL2tlcm5fZXhpdC5jOjQ5NyAoc2xlZXAgbXV0ZXg6 c2lnYWN0cykKICAgICA4NTQgICAgICAgICAwICAgICAgICA0MjY2ICAgICAgICAgICAwICAgICAg ICAgIDI3ICAgIDE1OCAgICAgIDAgIDAgICAgICAwIC91c3Ivc3JjL3N5cy9rZXJuL2tlcm5fZXhl Yy5jOjk3NCAoc2xlZXAgbXV0ZXg6dm0gcGFnZSBxdWV1ZSBtdXRleCkKICAgIDEwNDcgICAgICAg ICAwICAgICAgICA0ODcyICAgICAgICAgICAwICAgICAgICAgIDIyICAgIDIyMSAgICAgIDAgIDAg ICAgICAwIC91c3Ivc3JjL3N5cy9uZXQvcm91dGUuYzoyOTEgKHJ3OnJhZGl4IG5vZGUgaGVhZCkK ICAgICA1MzQgICAgICAgICAwICAgICAgICAgOTk1ICAgICAgICAgICAwICAgICAgICAgICA3ICAg IDE0MiAgICAgIDAgIDAgICAgICAwIC91c3Ivc3JjL3N5cy92bS91bWFfY29yZS5jOjQxMCAoc2xl ZXAgbXV0ZXg6Vk5PREVQT0xMKQogICAgIDM5NiAgICAgICAgIDAgICAgICAgIDEwNDAgICAgICAg ICAgIDAgICAgICAgICAgIDcgICAgMTQ4ICAgICAgMCAgMCAgICAgIDAgL3Vzci9zcmMvc3lzL3Zt L3VtYV9jb3JlLmM6NDEwIChzbGVlcCBtdXRleDpWTSBPQkpFQ1QpCiAgICAgNjEyICAgICAgICAg MCAgICAgICAgMzg3MiAgICAgICAgICAgMCAgICAgICAgICA0NiAgICAgODQgICAgICAwICAwICAg ICAgMCAvdXNyL3NyYy9zeXMvdm0vdW1hX2NvcmUuYzoxOTkwIChzbGVlcCBtdXRleDpQUk9DKQog ICAgIDU1NyAgICAgICAgIDAgICAgICAgIDIyNzUgICAgICAgICAgIDAgICAgICAgICAgMTMgICAg MTc1ICAgICAgMCAgMCAgICAgIDAgL3Vzci9zcmMvc3lzL2tlcm4va2Vybl9zaWcuYzo5MzkgKHNs ZWVwIG11dGV4OnNpZ2FjdHMpCiAgICAgODkzICAgICAgICAgMCAgICAgICAgNTk5MiAgICAgICAg ICAgMCAgICAgICAgICAzNiAgICAxNjYgICAgICAwICAwICAgICAgMCAvdXNyL3NyYy9zeXMvZGV2 L3VzYjIvY29yZS91c2IyX2h1Yi5jOjE1MTggKHNsZWVwIG11dGV4Om9oY2kwKQogICAgMTk3OCAg ICAgIDIwNzAgICAgICAzMjQyMTggICAgICAgNTQ3OTUgICAgICAgICA3MDAgICAgNDYzICAgICA3 OCAgMCAgICAgNTQgL3Vzci9zcmMvc3lzL2Rldi91c2IyL2NvcmUvdXNiMl90cmFuc2Zlci5jOjE5 NDIgKHNsZWVwIG11dGV4OmVoY2kwKQogICAgIDEyOCAgICAgICAgIDAgICAgICAgICA3MzkgICAg ICAgICAgIDAgICAgICAgICAgMTAgICAgIDczICAgICAgMCAgMCAgICAgIDAgL3Vzci9zcmMvc3lz L3ZtL3VtYV9jb3JlLmM6MjAzNCAoc2xlZXAgbXV0ZXg6UFJPQykKICAgICA2NTggICAgICAgICAw ICAgICAgICAzMDg0ICAgICAgICAgICAwICAgICAgICAgIDE2ICAgIDE5MiAgICAgIDAgIDAgICAg ICAwIC91c3Ivc3JjL3N5cy9rZXJuL2tlcm5fcmVzb3VyY2UuYzoxMTk4IChydzp1aWRpbmZvIGhh c2gpCiAgIDIxMDc1ICAgICAgIDI3NiAgICAgIDE4NjQyMyAgICAgICAgIDc4OSAgICAgICAgIDM0 MSAgICA1NDYgICAgICAyICAwICAgICAgNyAvdXNyL3NyYy9zeXMvdm0vdm1fb2JqZWN0LmM6MTY2 MiAoc2xlZXAgbXV0ZXg6dm0gb2JqZWN0KQogICAgIDU0MCAgICAgICAgIDAgICAgICAgIDE4MDcg ICAgICAgICAgIDAgICAgICAgICAgIDcgICAgMjU4ICAgICAgMCAgMCAgICAgIDAgL3Vzci9zcmMv c3lzL3ZtL3VtYV9jb3JlLmM6NDEwIChzbGVlcCBtdXRleDpzYWNraG9sZSkKICAgIDYyMzkgICAg ICAgICAwICAgICAgIDg4MTYzICAgICAgICAgICAwICAgICAgICAgIDM1ICAgMjUxOCAgICAgIDAg IDAgICAgICAwIC91c3Ivc3JjL3N5cy9kZXYvdXNiMi9jb3JlL3VzYjJfaHViLmM6MTM1MSAoc2xl ZXAgbXV0ZXg6ZWhjaTApCiAgICAgNTIwICAgICAgICAgMCAgICAgICAgMTM3NiAgICAgICAgICAg MCAgICAgICAgICAgNyAgICAxOTYgICAgICAwICAwICAgICAgMCAvdXNyL3NyYy9zeXMvdm0vdW1h X2NvcmUuYzo0MTAgKHNsZWVwIG11dGV4OkZGUzEgZGlub2RlKQogICAgIDQ2NSAgICAgICAgIDAg ICAgICAgMTM4OTIgICAgICAgICAgIDAgICAgICAgICAxMTUgICAgMTIwICAgICAgMCAgMCAgICAg IDAgL3Vzci9zcmMvc3lzL3ZtL3ZtX21tYXAuYzoxMzczIChzbGVlcCBtdXRleDpwcm9jZXNzIGxv Y2spCiAgICAgNDM2ICAgICAgICAgMCAgICAgICAgIDkxMiAgICAgICAgICAgMCAgICAgICAgICAg NyAgICAxMzAgICAgICAwICAwICAgICAgMCAvdXNyL3NyYy9zeXMvdm0vdW1hX2NvcmUuYzo0MTAg KHNsZWVwIG11dGV4OjMyIEJ1Y2tldCkKICAgICA5MjAgICAgICA2Njk0ICAgICAgIDEyODM4ICAg ICAgICA4NjEwICAgICAgICAgMTYwICAgICA4MCAgICAgNTMgIDAgICAgIDExIC91c3Ivc3JjL3N5 cy9rZXJuL2tlcm5fbXV0ZXguYzoxMzcgKHNsZWVwIG11dGV4OnNlbGxjaykKICAgICA3NTMgICAg ICAgICAwICAgICAgICAyMjY5ICAgICAgICAgICAwICAgICAgICAgICA3ICAgIDMyNCAgICAgIDAg IDAgICAgICAwIC91c3Ivc3JjL3N5cy92bS91bWFfY29yZS5jOjQxMCAoc2xlZXAgbXV0ZXg6dGNw Y2IpCiAgICAgIDk1ICAgICAgICAgMCAgICAgICAgIDE4OSAgICAgICAgICAgMCAgICAgICAgICAg MiAgICAgOTQgICAgICAwICAwICAgICAgMCAvdXNyL3NyYy9zeXMva2Vybi92ZnNfc3lzY2FsbHMu YzoxMTY5IChsb2NrbWdyOmRldmZzKQogICAgOTE4NiAgICAgICAgIDAgICAgICAgMTQxOTAgICAg ICAgICAgIDAgICAgICAgICAgIDMgICA0NzMwICAgICAgMCAgMCAgICAgIDAgL3Vzci9zcmMvc3lz L2tlcm4vdHR5LmM6MTE5MiAoc2xlZXAgbXV0ZXg6cHJvY2VzcyBncm91cCkKICAgIDg1NTUgICAg ICAgICAwICAgICAgIDEzMTE1ICAgICAgICAgICAwICAgICAgICAgICAzICAgNDM3MSAgICAgIDAg IDAgICAgICAwIC91c3Ivc3JjL3N5cy9rZXJuL2tlcm5fc2lnLmM6MTgwNSAoc2xlZXAgbXV0ZXg6 cHJvY2VzcyBsb2NrKQogICAgNTI3MiAgICAgICAgIDAgICAgICAxMTA0NjUgICAgICAgICAgIDAg ICAgICAgICAgNDkgICAyMjU0ICAgICAgMCAgMCAgICAgIDAgL3Vzci9zcmMvc3lzL3ZtL3ZtX21t YXAuYzo1NzYgKHN4OnVzZXIgbWFwKQogICAgIDcwNSAgICAgICAgIDAgICAgICAgIDE3MzMgICAg ICAgICAgIDAgICAgICAgICAgMTMgICAgMTMzICAgICAgMCAgMCAgICAgIDAgL3Vzci9zcmMvc3lz L3ZtL3ZtX29iamVjdC5jOjE3MzggKHNsZWVwIG11dGV4OnZtIG9iamVjdCkKICAgICAxMzEgICAg ICAgICAwICAgICAgICAgNTkzICAgICAgICAgICAwICAgICAgICAgICA3ICAgICA4NCAgICAgIDAg IDAgICAgICAwIC91c3Ivc3JjL3N5cy92bS91bWFfY29yZS5jOjQxMCAoc2xlZXAgbXV0ZXg6YXRh X2NvbXBvc2l0ZSkKICAgICA4NDQgICAgICAgICAwICAgICAgICA4MDM3ICAgICAgICAgICAwICAg ICAgICAgIDY1ICAgIDEyMyAgICAgIDAgIDAgICAgICAwIC91c3Ivc3JjL3N5cy91ZnMvZmZzL2Zm c19zb2Z0ZGVwLmM6NDkxOCAoc2xlZXAgbXV0ZXg6U29mdGRlcCBMb2NrKQogICAgNTk2MSAgICAg MjI0MjIgICAgICA0OTAzMzUgICAgICA3ODAzNDkgICAgICAgIDMxMTYgICAgMTU3ICAgIDI1MCAg MCAgICA5NDUgL3Vzci9zcmMvc3lzL2tlcm4va2Vybl9tdXRleC5jOjEzNyAoc2xlZXAgbXV0ZXg6 c2xlZXAgbXR4cG9vbCkKICAgIDE2NTYgICAgICAgICAwICAgICAyMjc4MTg5ICAgICAgICAgICAw ICAgICAgICA3OTc0ICAgIDI4NSAgICAgIDAgIDAgICAgICAwIC91c3Ivc3JjL3N5cy9rZXJuL3N5 c19nZW5lcmljLmM6NzgxIChzeDpmaWxlZGVzYyBzdHJ1Y3R1cmUpCiAgICAgNjQzICAgICAgICAg MCAgICAgICAgODY5NCAgICAgICAgICAgMCAgICAgICAgICA3NSAgICAxMTUgICAgICAwICAwICAg ICAgMCAvdXNyL3NyYy9zeXMvdm0vdm1fbWFwLmM6MTA3NSAoc2xlZXAgbXV0ZXg6dm0gb2JqZWN0 KQogICAgMTA1NCAgICAgICAgMzcgICAgICAgNTE4NzEgICAgICAgICAgMzcgICAgICAgICAyNDgg ICAgMjA5ICAgICAgMCAgMCAgICAgIDEgL3Vzci9zcmMvc3lzL3ZtL3VtYV9jb3JlLmM6MTk5MCAo c2xlZXAgbXV0ZXg6bWJ1ZikKICAgICAxOTcgICAgICAgICAwICAgICAgICAgOTIyICAgICAgICAg ICAwICAgICAgICAgIDMwICAgICAzMCAgICAgIDAgIDAgICAgICAwIC91c3Ivc3JjL3N5cy92bS92 bV9vYmplY3QuYzoxNzk5IChzbGVlcCBtdXRleDp2bSBvYmplY3QpCiAgICA3OTc0ICAgICA1MjU3 OCAgICAgIDI5ODk3NyAgICAgIDI3NjI4NCAgICAgICAgMTIxMiAgICAyNDYgICAgMjI3ICAwICAg IDE3NiAvdXNyL3NyYy9zeXMvdm0vdm1fZ2x1ZS5jOjY4OSAoc2xlZXAgbXV0ZXg6cHJvY2VzcyBs b2NrKQogICAyMDg2NyAgICAgICAgIDAgICAgICAzNjA3OTggICAgICAgICAgIDAgICAgICAgICAg NjEgICA1OTE0ICAgICAgMCAgMCAgICAgIDAgL3Vzci9zcmMvc3lzL3ZtL3ZtX21hcC5jOjI1NTYg KHN4OnVzZXIgbWFwKQogICAgIDkzMCAgICAgICAgIDAgICAgICAgIDY1OTIgICAgICAgICAgIDAg ICAgICAgICAgMzUgICAgMTg4ICAgICAgMCAgMCAgICAgIDAgL3Vzci9zcmMvc3lzL2Rldi91c2Iy L2NvcmUvdXNiMl9odWIuYzoxNTE4IChzbGVlcCBtdXRleDplaGNpMCkKICAgMzY4NjIgICAgICAg ICAwICAgIDEwNDUyMDU2ICAgICAgICAgICAwICAgICAgICA2MjU0ICAgMTY3MSAgICAgIDAgIDAg ICAgICAwIC91c3Ivc3JjL3N5cy9nZW9tL2dlb21fZGlzay5jOjE5OSAoc2xlZXAgbXV0ZXg6Z19k aXNrX2RvbmUpCiAgICAgNDU1ICAgICAgICAgMCAgICAgICAgMTg5MiAgICAgICAgICAgMCAgICAg ICAgICAzNCAgICAgNTUgICAgICAwICAwICAgICAgMCAvdXNyL3NyYy9zeXMva2Vybi9zeXNfcGlw ZS5jOjk4MiAoc2xlZXAgbXV0ZXg6cGlwZSBtdXRleCkKICAgIDE1NzUgICAgICAgICAwICAgICAg MTA1MzY5ICAgICAgICAgICAwICAgICAgICAgMjU2ICAgIDQxMSAgICAgIDAgIDAgICAgICAwIC91 c3Ivc3JjL3N5cy9rZXJuL3Zmc19sb29rdXAuYzoxODggKHN4OmZpbGVkZXNjIHN0cnVjdHVyZSkK ICAgICA1NzMgICAgICAgICAwICAgICAgICAxMDMyICAgICAgICAgICAwICAgICAgICAgICA3ICAg IDE0NyAgICAgIDAgIDAgICAgICAwIC91c3Ivc3JjL3N5cy92bS91bWFfY29yZS5jOjQxMCAoc2xl ZXAgbXV0ZXg6MTAyNCkKICAgICAxMzcgICAgICAgICAwICAgICAgICAgNjAyICAgICAgICAgICAw ICAgICAgICAgICA3ICAgICA4NiAgICAgIDAgIDAgICAgICAwIC91c3Ivc3JjL3N5cy92bS91bWFf Y29yZS5jOjQxMCAoc2xlZXAgbXV0ZXg6c2N0cF9hc2NvbmZfYWNrKQogICAgMTA2OCAgICAgICAg IDAgICAgICAgNzgwNTkgICAgICAgICAgIDAgICAgICAgICAzNjAgICAgMjE2ICAgICAgMCAgMCAg ICAgIDAgL3Vzci9zcmMvc3lzL2Rldi91c2IyL2NvcmUvdXNiMl90cmFuc2Zlci5jOjI0NTUgKHNs ZWVwIG11dGV4Om9oY2kwKQogICAgICA4OCAgICAgICAgIDAgICAgICAgICAgODggICAgICAgICAg IDAgICAgICAgICAgIDEgICAgIDg4ICAgICAgMCAgMCAgICAgIDAgL3Vzci9zcmMvc3lzL3Vmcy9m ZnMvZmZzX3NvZnRkZXAuYzo5OTMgKHNsZWVwIG11dGV4OlNvZnRkZXAgTG9jaykKICAgICAxNzQg ICAgICAgICAwICAgICAgICAgNzMzICAgICAgICAgICAwICAgICAgICAgICA3ICAgIDEwNCAgICAg IDAgIDAgICAgICAwIC91c3Ivc3JjL3N5cy92bS91bWFfY29yZS5jOjQxMCAoc2xlZXAgbXV0ZXg6 cmlwY2IpCiAgICAxNjQ0ICAgICAgICAgMCAgICAgICAyMTAxOSAgICAgICAgICAgMCAgICAgICAg ICA0NiAgICA0NTYgICAgICAwICAwICAgICAgMCAvdXNyL3NyYy9zeXMva2Vybi9rZXJuX2Zvcmsu YzozMjAgKHN4OmFsbHByb2MpCiAgICAgNTAyICAgICAgICAgMCAgICAgICAgNTY1MiAgICAgICAg ICAgMCAgICAgICAgICA0OSAgICAxMTUgICAgICAwICAwICAgICAgMCAvdXNyL3NyYy9zeXMvdm0v dm1fb2JqZWN0LmM6MTk1OCAoc2xlZXAgbXV0ZXg6dm0gb2JqZWN0KQogICAgIDUxNCAgICAgICAg IDAgICAgICAgIDcxNjAgICAgICAgICAgIDAgICAgICAgICAgNTkgICAgMTIxICAgICAgMCAgMCAg ICAgIDAgL3Vzci9zcmMvc3lzL3ZtL3VtYV9jb3JlLmM6MjUyNCAoc2xlZXAgbXV0ZXg6MjU2KQog ICAxMjA1MiAgICAgICAgIDAgICAgICAxMjA0MDkgICAgICAgICAgIDAgICAgICAgICAgOTQgICAx MjgwICAgICAgMCAgMCAgICAgIDAgL3Vzci9zcmMvc3lzL2tlcm4vc3lzX2dlbmVyaWMuYzo5NzQg KHN4OmZpbGVkZXNjIHN0cnVjdHVyZSkKICAgICA4NjkgICAgICAgICAwICAgICAgICAzNzk3ICAg ICAgICAgICAwICAgICAgICAgICA2ICAgIDYzMiAgICAgIDAgIDAgICAgICAwIC91c3Ivc3JjL3N5 cy9mcy9kZXZmcy9kZXZmc192bm9wcy5jOjM1MSAoc2xlZXAgbXV0ZXg6dm5vZGUgaW50ZXJsb2Nr KQogICA2NzA4OSAgICAgICAgIDAgICAgICA4MjI5ODQgICAgICAgICAgIDAgICAgICAgICAgNDMg IDE5MTM5ICAgICAgMCAgMCAgICAgIDAgL3Vzci9zcmMvc3lzL3ZtL3ZtX21hcC5jOjI3MzAgKHN4 OnVzZXIgbWFwKQogICAgIDExMCAgICAgICAgIDAgICAgICAgICA1NjAgICAgICAgICAgIDAgICAg ICAgICAgIDcgICAgIDgwICAgICAgMCAgMCAgICAgIDAgL3Vzci9zcmMvc3lzL3ZtL3VtYV9jb3Jl LmM6NDEwIChzbGVlcCBtdXRleDo2NCBCdWNrZXQpCiAgICA1NTg2ICAgICAgICAgMCAgICAgICAg NzE2OCAgICAgICAgICAgMCAgICAgICAgICAzNCAgICAyMTAgICAgICAwICAwICAgICAgMCAvdXNy L3NyYy9zeXMva2Vybi9zeXNfcGlwZS5jOjExMzggKHNsZWVwIG11dGV4OnBpcGUgbXV0ZXgpCiAg ICAgMzQxICAgICAgICAgMCAgICAgICAgMTIyNiAgICAgICAgICAgMCAgICAgICAgICAzMiAgICAg MzggICAgICAwICAwICAgICAgMCAvdXNyL3NyYy9zeXMvdm0vdW1hX2NvcmUuYzoxOTkwIChzbGVl cCBtdXRleDpjcHVzZXQpCiAgMTA1Njk4ICAgICAgICAgMCAgICAyOTI2MjY5NiAgICAgICAgICAg MCAgICAgICAgNzk3NCAgIDM2NjkgICAgICAwICAwICAgICAgMCAvdXNyL3NyYy9zeXMva2Vybi9z eXNfZ2VuZXJpYy5jOjEwMTYgKHN4OmZpbGVkZXNjIHN0cnVjdHVyZSkKICAgICA5MDkgICAgICAg ICAwICAgICAgIDEwMDI2ICAgICAgICAgICAwICAgICAgICAgIDQ4ICAgIDIwOCAgICAgIDAgIDAg ICAgICAwIC91c3Ivc3JjL3N5cy9rZXJuL3Zmc19zdWJyLmM6MTYzMyAoc2xlZXAgbXV0ZXg6U3lu Y2VyIG10eCkKICAgICAgOTIgICAgICAgICAwICAgICAgICAgNDYyICAgICAgICAgICAwICAgICAg ICAgICA2ICAgICA3NyAgICAgIDAgIDAgICAgICAwIC91c3Ivc3JjL3N5cy92bS91bWFfY29yZS5j OjkxNCAoc2xlZXAgbXV0ZXg6VFVSTlNUSUxFKQogICAgIDkzOCAgICAgICAgIDAgICAgICAgIDE3 MDUgICAgICAgICAgIDAgICAgICAgICAgIDMgICAgNTY4ICAgICAgMCAgMCAgICAgIDAgL3Vzci9z cmMvc3lzL3Vmcy9mZnMvZmZzX3Zub3BzLmM6ODM3IChzbGVlcCBtdXRleDp2bSBvYmplY3QpCiAg ICAgMTI0ICAgICAgICAgMCAgICAgICAgIDYyOSAgICAgICAgICAgMCAgICAgICAgICAgNyAgICAg ODkgICAgICAwICAwICAgICAgMCAvdXNyL3NyYy9zeXMvdm0vdW1hX2NvcmUuYzo0MTAgKHNsZWVw IG11dGV4OkZGUzIgZGlub2RlKQogICAgMzkzNCAgICAgICA3MjQgICAgICAyNTIxNzAgICAgICAg MTQ3NDQgICAgICAgICA2MzggICAgMzk1ICAgICAyMyAgMCAgICAxMjAgL3Vzci9zcmMvc3lzL2Ft ZDY0L2FtZDY0L3BtYXAuYzozNTIyIChzbGVlcCBtdXRleDp2bSBwYWdlIHF1ZXVlIG11dGV4KQog ICAgIDY1NyAgICAgICAgIDAgICAgICAgIDEzNzAgICAgICAgICAgIDAgICAgICAgICAgMTcgICAg IDgwICAgICAgMCAgMCAgICAgIDAgL3Vzci9zcmMvc3lzL2tlcm4vdWlwY19zb2NrZXQuYzoxNDIz IChzbGVlcCBtdXRleDpzb19yY3YpCiAgICAxNzA5ICAgICAgICAgMCAgICAgICAgNDQ4MiAgICAg ICAgICAgMCAgICAgICAgICAyMiAgICAyMDMgICAgICAwICAwICAgICAgMCAvdXNyL3NyYy9zeXMv bmV0L3JvdXRlLmM6Mjk5IChzbGVlcCBtdXRleDpydGVudHJ5KQogICAgIDYzOSAgICAgICAgIDAg ICAgICAgIDExNDAgICAgICAgICAgIDAgICAgICAgICAgMTkgICAgIDYwICAgICAgMCAgMCAgICAg IDAgL3Vzci9zcmMvc3lzL2tlcm4vdWlwY19zb2NrYnVmLmM6NTM2IChzbGVlcCBtdXRleDpzb19z bmQpCiAgICAgNjA1ICAgICAgICAgMCAgICAgICAxMjQ0NCAgICAgICAgICAgMCAgICAgICAgIDEw OCAgICAxMTUgICAgICAwICAwICAgICAgMCAvdXNyL3NyYy9zeXMvdm0vdW1hX2NvcmUuYzoxOTkw IChzbGVlcCBtdXRleDpTTEVFUFFVRVVFKQogICAgIDI5NSAgICAgICAgMTUgICAgICAgIDE3ODUg ICAgICAgICAgMTUgICAgICAgICAgMjcgICAgIDY2ICAgICAgMCAgMCAgICAgIDEgL3Vzci9zcmMv c3lzL3ZtL3VtYV9jb3JlLmM6OTE0IChzbGVlcCBtdXRleDpWTSBPQkpFQ1QpCiAgIDEwNTUyICAg ICAgICAgMCAgICAgICA0MDEwMSAgICAgICAgICAgMCAgICAgICAgICAzMCAgIDEzMzYgICAgICAw ICAwICAgICAgMCAvdXNyL3NyYy9zeXMva2Vybi92ZnNfc3Vici5jOjE3MTggKHNsZWVwIG11dGV4 OlN5bmNlciBtdHgpCiAgICAgNzMxICAgICAgICAgMCAgICAgICAgMTgwMSAgICAgICAgICAgMCAg ICAgICAgICAgNyAgICAyNTcgICAgICAwICAwICAgICAgMCAvdXNyL3NyYy9zeXMvdm0vdW1hX2Nv cmUuYzo0MTAgKHNsZWVwIG11dGV4OnVtdHggcGkpCiAgICAxMTA2ICAgICAgICAgMCAgICAgICAg NjE4NSAgICAgICAgICAgMCAgICAgICAgICAxMyAgICA0NzUgICAgICAwICAwICAgICAgMCAvdXNy L3NyYy9zeXMvdm0vdm1fbWFwLmM6Mjg3NSAoc3g6dXNlciBtYXApCiAgICAgNDUzICAgICAgICAg MCAgICAgICAgMTUxMiAgICAgICAgICAgMCAgICAgICAgICAgOCAgICAxODkgICAgICAwICAwICAg ICAgMCAvdXNyL3NyYy9zeXMvdm0vdW1hX2NvcmUuYzoyMDM0IChzbGVlcCBtdXRleDpTTEVFUFFV RVVFKQogICAgNTk4MiAgICAgICAgIDAgICAgICA1MzEyNzEgICAgICAgICAgIDAgICAgICAgIDMx NDAgICAgMTY5ICAgICAgMCAgMCAgICAgIDAgL3Vzci9zcmMvc3lzL2tlcm4vdmZzX2Jpby5jOjMy OSAoc2xlZXAgbXV0ZXg6cnVubmluZ2J1ZnNwYWNlIGxvY2spCiAgIDE0MjcxICAgICAgICAgMCAg ICAgIDI4ODc3NyAgICAgICAgICAgMCAgICAgICAgICAzMiAgIDkwMjQgICAgICAwICAwICAgICAg MCAvdXNyL3NyYy9zeXMva2Vybi9zeXNfZ2VuZXJpYy5jOjExNDAgKHN4OmZpbGVkZXNjIHN0cnVj dHVyZSkKICAgIDEwMjQgICAgICAgICAwICAgICAgIDY4NDE0ICAgICAgICAgICAwICAgICAgICAg MzUwICAgIDE5NSAgICAgIDAgIDAgICAgICAwIC91c3Ivc3JjL3N5cy9kZXYvdXNiMi9jb3JlL3Vz YjJfdHJhbnNmZXIuYzoyNDU1IChzbGVlcCBtdXRleDplaGNpMCkKICAgICA0MzYgICAgICAgICAw ICAgICAgICAgOTIzICAgICAgICAgICAwICAgICAgICAgICA3ICAgIDEzMSAgICAgIDAgIDAgICAg ICAwIC91c3Ivc3JjL3N5cy92bS91bWFfY29yZS5jOjQxMCAoc2xlZXAgbXV0ZXg6bWJ1Zl9qdW1i b19wYWdlKQogICAgIDk2MCAgICAgICAgIDAgICAgICAgOTUxNjEgICAgICAgICAgIDAgICAgICAg ICA5MjEgICAgMTAzICAgICAgMCAgMCAgICAgIDAgL3Vzci9zcmMvc3lzL3ZtL3VtYV9jb3JlLmM6 MTk5MCAoc2xlZXAgbXV0ZXg6TUFQIEVOVFJZKQogICAgIDkyMiAgICAgICAgIDAgICAgICAgMTk3 MzQgICAgICAgICAgIDAgICAgICAgICAxMjggICAgMTU0ICAgICAgMCAgMCAgICAgIDAgL3Vzci9z cmMvc3lzL3ZtL3ZtX2dsdWUuYzoxNzkgKHN4OnVzZXIgbWFwKQogICAgICA5MyAgICAgICAgIDAg ICAgICAgICA1ODMgICAgICAgICAgIDAgICAgICAgICAgIDcgICAgIDgzICAgICAgMCAgMCAgICAg IDAgL3Vzci9zcmMvc3lzL3ZtL3VtYV9jb3JlLmM6NDEwIChzbGVlcCBtdXRleDppdGltZXIpCiAg ICA3MDIzICAgICAgICAgMCAgICAgIDQ4NjQyMiAgICAgICAgICAgMCAgICAgICAgMzExMiAgICAx NTYgICAgICAwICAwICAgICAgMCAvdXNyL3NyYy9zeXMva2Vybi92ZnNfYmlvLmM6MzgxIChzbGVl cCBtdXRleDpydW5uaW5nYnVmc3BhY2UgbG9jaykKICAgICA0ODcgICAgICAgICAwICAgICAgICAy NDc3ICAgICAgICAgICAwICAgICAgICAgIDE5ICAgIDEzMCAgICAgIDAgIDAgICAgICAwIC91c3Iv c3JjL3N5cy92bS91bWFfY29yZS5jOjIwMzQgKHNsZWVwIG11dGV4Ok1BUCBFTlRSWSkKICAgICA4 OTggICAgICAgICAwICAgICAgICA4NTA4ICAgICAgICAgICAwICAgICAgICAgIDQ2ICAgIDE4NCAg ICAgIDAgIDAgICAgICAwIC91c3Ivc3JjL3N5cy9rZXJuL2tlcm5fZm9yay5jOjMxMSAoc3g6cHJv Y3RyZWUpCiAgICA4MDg4ICAgICAgIDE4NiAgICAgICAzMDc1NiAgICAgICAgIDMzMyAgICAgICAg IDEzMiAgICAyMzMgICAgICAyICAwICAgICAgNCAvdXNyL3NyYy9zeXMva2Vybi9zeXNfcGlwZS5j OjEzNTAgKHNsZWVwIG11dGV4OnBpcGUgbXV0ZXgpCiAgICAgNzExICAgICAgICAgMCAgICAgICAg MTE5NSAgICAgICAgICAgMCAgICAgICAgICAgNyAgICAxNzAgICAgICAwICAwICAgICAgMCAvdXNy L3NyYy9zeXMvdm0vdW1hX2NvcmUuYzo0MTAgKHNsZWVwIG11dGV4OmF1ZGl0X3JlY29yZCkKICAg IDI3OTAgICAgICAyMjQwICAgICAgNDUzNzUwICAgICAgMjE3ODUyICAgICAgICAgNzEwICAgIDYz OSAgICAzMDYgIDAgICAgMzM0IC91c3Ivc3JjL3N5cy9rZXJuL2tlcm5fbXV0ZXguYzoxMzcgKHNs ZWVwIG11dGV4OlVTQiBkZXZpY2UgbXV0ZXgpCiAgICAgNjc1ICAgICAgIDE4NyAgICAgICA1MjA5 MiAgICAgICAgIDI1NCAgICAgICAgIDU4OCAgICAgODggICAgICAwICAwICAgICAgMyAvdXNyL3Ny Yy9zeXMvdm0vdm1fb2JqZWN0LmM6MjM2IChzbGVlcCBtdXRleDp2bSBvYmplY3RfbGlzdCkKICAg IDMxNDEgICAgICAgICAwICAgICAgIDc2ODkzICAgICAgICAgICAwICAgICAgICAgIDc1ICAgMTAy NSAgICAgIDAgIDAgICAgICAwIC91c3Ivc3JjL3N5cy92bS92bV9tYXAuYzoxNTgzIChzbGVlcCBt dXRleDp2bSBvYmplY3QpCiAgICAgMTA2ICAgICAgICAgMCAgICAgICAgIDU1NyAgICAgICAgICAg MCAgICAgICAgICAgNyAgICAgNzkgICAgICAwICAwICAgICAgMCAvdXNyL3NyYy9zeXMvdm0vdW1h X2NvcmUuYzo0MTAgKHNsZWVwIG11dGV4OjEyOCBCdWNrZXQpCiAgICAxNzA5ICAgICAgICAgMCAg ICAgICAgNjIxOCAgICAgICAgICAgMCAgICAgICAgICAxNyAgICAzNjUgICAgICAwICAwICAgICAg MCAvdXNyL3NyYy9zeXMva2Vybi91aXBjX3NvY2tldC5jOjE2NjkgKHNsZWVwIG11dGV4OnNvX3Jj dikKICAgMTgwOTggICAgICAgICAwICAgICAzNTExMTg4ICAgICAgICAgICAwICAgICAgICAgNzEw ICAgNDk0NSAgICAgIDAgIDAgICAgICAwIC91c3Ivc3JjL3N5cy9kZXYvdXNiMi9jb3JlL3VzYjJf cmVxdWVzdC5jOjMxOSAoc2xlZXAgbXV0ZXg6VVNCIGRldmljZSBtdXRleCkKICAgIDc0NjkgICAg ICAgICAwICAgICAgNTMzNDEwICAgICAgICAgICAwICAgICAgICAzMTM4ICAgIDE2OSAgICAgIDAg IDAgICAgICAwIC91c3Ivc3JjL3N5cy9rZXJuL3Zmc19iaW8uYzozODE1IChzbGVlcCBtdXRleDpi dWZvYmogaW50ZXJsb2NrKQogICAgMTY0NCAgICAgICAgIDAgICAgICA1NjQxOTAgICAgICAgICAg IDAgICAgICAgIDIxODkgICAgMjU3ICAgICAgMCAgMCAgICAgIDAgL3Vzci9zcmMvc3lzL2tlcm4v dmZzX3N1YnIuYzozMTg4IChzbGVlcCBtdXRleDp2bm9kZSBpbnRlcmxvY2spCiAgICAxMDQ0ICAg ICAgICAgMCAgICAgICA1NjYyMSAgICAgICAgICAgMCAgICAgICAgIDI0OCAgICAyMjggICAgICAw ICAwICAgICAgMCAvdXNyL3NyYy9zeXMvdm0vdW1hX2NvcmUuYzoyNTI0IChzbGVlcCBtdXRleDpt YnVmKQogICAgMTcwMCAgICAgMjY2NzMgICAgICA1MjkxMzQgICAgICAxMTg5NTUgICAgICAgIDMx MzkgICAgMTY4ICAgICAzNyAgMCAgICAgMTMgL3Vzci9zcmMvc3lzL2tlcm4vdmZzX2Jpby5jOjM4 MjUgKHNsZWVwIG11dGV4OmJ1Zm9iaiBpbnRlcmxvY2spCiAgICAgNTE4ICAgICAgICAgMCAgICAg ICAgIDk2NiAgICAgICAgICAgMCAgICAgICAgICAgMiAgICA0ODMgICAgICAwICAwICAgICAgMCAv dXNyL3NyYy9zeXMvdm0vdm5vZGVfcGFnZXIuYzo5MzUgKHNsZWVwIG11dGV4OnZtIHBhZ2UgcXVl dWUgbXV0ZXgpCiAgICAgNzYwICAgICAgICAgMCAgICAgICAgMjIzNyAgICAgICAgICAgMCAgICAg ICAgICAgNyAgICAzMTkgICAgICAwICAwICAgICAgMCAvdXNyL3NyYy9zeXMvdm0vdW1hX2NvcmUu Yzo0MTAgKHNsZWVwIG11dGV4OjIwNDgpCiAgICAxMDU1ICAgICAgICAgMCAgICAgICAyNTY2NyAg ICAgICAgICAgMCAgICAgICAgIDE4NSAgICAxMzggICAgICAwICAwICAgICAgMCAvdXNyL3NyYy9z eXMvdm0vdW1hX2NvcmUuYzoxOTkwIChzbGVlcCBtdXRleDo1MTIpCiAgICAgNTIyICAgICAgICAg MCAgICAgICAgMTM0NyAgICAgICAgICAgMCAgICAgICAgICAgNyAgICAxOTIgICAgICAwICAwICAg ICAgMCAvdXNyL3NyYy9zeXMvdm0vdW1hX2NvcmUuYzo0MTAgKHNsZWVwIG11dGV4OnVucGNiKQog ICAgIDY5OCAgICAgICAgIDAgICAgICAgIDI1MDkgICAgICAgICAgIDAgICAgICAgICAgMTQgICAg MTc5ICAgICAgMCAgMCAgICAgIDAgL3Vzci9zcmMvc3lzL2tlcm4vdmZzX3N1YnIuYzoxOTY0IChz bGVlcCBtdXRleDpTeW5jZXIgbXR4KQogICAxNDkzOSAgICAgIDI3OTcgICAgICAyNTc0MTYgICAg ICAgIDI3OTcgICAgICAgICAgNTYgICA0NTk2ICAgICA0OSAgMCAgICAgIDEgL3Vzci9zcmMvc3lz L2FtZDY0L2FtZDY0L3BtYXAuYzozODIyIChzbGVlcCBtdXRleDp2bSBwYWdlIHF1ZXVlIG11dGV4 KQogICAgIDkwMyAgICAgICAgNTggICAgICAgMzUwNjYgICAgICAgICAgNTggICAgICAgICAyMDAg ICAgMTc1ICAgICAgMCAgMCAgICAgIDEgL3Vzci9zcmMvc3lzL3ZtL3ZtX3BhZ2UuYzo1NDYgKHNs ZWVwIG11dGV4OnZtIHBhZ2UgcXVldWUgbXV0ZXgpCiAgICAgIDk3ICAgICAgICAgMCAgICAgICAg IDQwMSAgICAgICAgICAgMCAgICAgICAgICAgNiAgICAgNjYgICAgICAwICAwICAgICAgMCAvdXNy L3NyYy9zeXMvdm0vdW1hX2NvcmUuYzoyMDM0IChzbGVlcCBtdXRleDo1MTIpCiAgIDE2NjUyICAg ICAgICAgMCAgICAgNTIzNzkwMiAgICAgICAgICAgMCAgICAgICAxMDIzOSAgICA1MTEgICAgICAw ICAwICAgICAgMCAvdXNyL3NyYy9zeXMvbmV0aW5ldC90Y3Bfc3Vici5jOjE1NDkgKHNsZWVwIG11 dGV4Omlzbl9tdHgpCiAgICA2NTkzICAgICAgMTY4MiAgICAgIDQ0MTc3NCAgICAgICAgODA3MCAg ICAgICAgIDQ2NSAgICA5NTAgICAgIDE3ICAwICAgICAxMiAvdXNyL3NyYy9zeXMvdm0vdm1fb2Jq ZWN0LmM6NjcxIChzbGVlcCBtdXRleDp2bSBwYWdlIHF1ZXVlIG11dGV4KQogIDIyNDIwOCAgICAg ICAgIDAgICAgIDE4MDU0NzEgICAgICAgICAgIDAgICAgICAgICAgMzYgIDUwMTUxICAgICAgMCAg MCAgICAgIDAgL3Vzci9zcmMvc3lzL2tlcm4vdmZzX21vdW50LmM6MjA1NSAoc2xlZXAgbXV0ZXg6 c3RydWN0IG1vdW50IG10eCkKICAgICA5ODAgICAgICAgICAwICAgICAgIDIzNTc5ICAgICAgICAg ICAwICAgICAgICAgMTM4ICAgIDE3MCAgICAgIDAgIDAgICAgICAwIC91c3Ivc3JjL3N5cy9rZXJu L2tlcm5fZXhpdC5jOjIzOCAoc2xlZXAgbXV0ZXg6cHJvY2Vzc19leGl0KQogICAgMTAzMiAgICAg ICAgIDAgICAgICAgIDkwMTUgICAgICAgICAgIDAgICAgICAgICAgMzYgICAgMjUwICAgICAgMCAg MCAgICAgIDAgL3Vzci9zcmMvc3lzL2tlcm4vdmZzX21vdW50LmM6MjA5MCAoc2xlZXAgbXV0ZXg6 c3RydWN0IG1vdW50IG10eCkKICAgIDM0NTkgICAgICAgICAwICAgICAgMjIwNzkzICAgICAgICAg ICAwICAgICAgICAgNTA0ICAgIDQzOCAgICAgIDAgIDAgICAgICAwIC91c3Ivc3JjL3N5cy9rZXJu L3Zmc19jYWNoZS5jOjQ4MCAoc2xlZXAgbXV0ZXg6dm5vZGUgaW50ZXJsb2NrKQogICAgIDEzMSAg ICAgICAgIDAgICAgICAgICA3ODkgICAgICAgICAgIDAgICAgICAgICAgMTcgICAgIDQ2ICAgICAg MCAgMCAgICAgIDAgL3Vzci9zcmMvc3lzL2tlcm4vdWlwY19zb2NrZXQuYzoxODI1IChzbGVlcCBt dXRleDpzb19yY3YpCiAgICAxODAxICAgICAgICAgMCAgICAgICAyNzQ3MCAgICAgICAgICAgMCAg ICAgICAgICA0NiAgICA1OTcgICAgICAwICAwICAgICAgMCAvdXNyL3NyYy9zeXMva2Vybi9rZXJu X2ZvcmsuYzo2MDAgKHN4OnByb2N0cmVlKQogICAgIDc1MyAgICAgICAgIDAgICAgICAgIDM2NjAg ICAgICAgICAgIDAgICAgICAgICAgMTkgICAgMTkyICAgICAgMCAgMCAgICAgIDAgL3Vzci9zcmMv c3lzL3ZtL3VtYV9jb3JlLmM6OTE0IChzbGVlcCBtdXRleDo2NCBCdWNrZXQpCiAgICAgNzMzICAg ICAgICAgMCAgICAgICAgMjM1MiAgICAgICAgICAgMCAgICAgICAgICAgNyAgICAzMzYgICAgICAw ICAwICAgICAgMCAvdXNyL3NyYy9zeXMvdm0vdW1hX2NvcmUuYzo0MTAgKHNsZWVwIG11dGV4OkZp bGVzKQogICAgIDg2MiAgICAgICAgIDAgICAgICAgIDE5MjUgICAgICAgICAgIDAgICAgICAgICAg IDMgICAgNjQxICAgICAgMCAgMCAgICAgIDAgL3Vzci9zcmMvc3lzL2ZzL2RldmZzL2RldmZzX3Zm c29wcy5jOjE1NyAoc3g6ZGV2ZnNtb3VudCkKICAzNjkxNjYgICAgICAgICAwICAgIDEyNTE2NDA0 ICAgICAgICAgICAwICAgICAgICAyMTU1ICAgNTgwOCAgICAgIDAgIDAgICAgICAwIC91c3Ivc3Jj L3N5cy92bS92bV9tYXAuYzozMjU3IChzeDp1c2VyIG1hcCkKICAgICAxMTkgICAgICAgICAwICAg ICAgICAgNTQxICAgICAgICAgICAwICAgICAgICAgICA2ICAgICA5MCAgICAgIDAgIDAgICAgICAw IC91c3Ivc3JjL3N5cy91ZnMvZmZzL2Zmc19zb2Z0ZGVwLmM6Mzc2NSAoc2xlZXAgbXV0ZXg6cHJv Y2VzcyBsb2NrKQogICAgIDE0OCAgICAgICAgIDAgICAgICAgICA2MzEgICAgICAgICAgIDAgICAg ICAgICAgIDcgICAgIDkwICAgICAgMCAgMCAgICAgIDAgL3Vzci9zcmMvc3lzL3ZtL3VtYV9jb3Jl LmM6NDEwIChzbGVlcCBtdXRleDppcHEpCiAgICAgNDUyICAgICAgICAgMCAgICAgICAgMzMyNiAg ICAgICAgICAgMCAgICAgICAgICAxOSAgICAxNzUgICAgICAwICAwICAgICAgMCAvdXNyL3NyYy9z eXMva2Vybi9rZXJuX3Byb3QuYzoxMjEwIChzbGVlcCBtdXRleDpwcm9jZXNzIGxvY2spCiAgICAg NzAwICAgICAgICAgMCAgICAgICAgMTQ3MyAgICAgICAgICAgMCAgICAgICAgICAgNiAgICAyNDUg ICAgICAwICAwICAgICAgMCAvdXNyL3NyYy9zeXMvZnMvZGV2ZnMvZGV2ZnNfdm5vcHMuYzozNTUg KHN4OmRldmZzbW91bnQpCiAgICAgNzYyICAgICAgICAgMCAgICAgICAxNjI2MSAgICAgICAgICAg MCAgICAgICAgIDE1NCAgICAxMDUgICAgICAwICAwICAgICAgMCAvdXNyL3NyYy9zeXMvdm0vdW1h X2NvcmUuYzoxOTkwIChzbGVlcCBtdXRleDoxMjgpCiAgICAgMTAwICAgICAgICAgMCAgICAgICAg IDU1NCAgICAgICAgICAgMCAgICAgICAgICAgNyAgICAgNzkgICAgICAwICAwICAgICAgMCAvdXNy L3NyYy9zeXMvdm0vdW1hX2NvcmUuYzo0MTAgKHNsZWVwIG11dGV4OnRjcHJlYXNzKQogICAgIDQ0 NCAgICAgICAgIDAgICAgICAgICA5MDkgICAgICAgICAgIDAgICAgICAgICAgIDYgICAgMTUxICAg ICAgMCAgMCAgICAgIDAgL3Vzci9zcmMvc3lzL3Vmcy9mZnMvZmZzX3NvZnRkZXAuYzozODM4IChz bGVlcCBtdXRleDpwcm9jZXNzIGxvY2spCiAgICAzOTkwICAgICAgICAgMCAgICAgICA2NjY5NCAg ICAgICAgICAgMCAgICAgICAgICAzNSAgIDE5MDUgICAgICAwICAwICAgICAgMCAvdXNyL3NyYy9z eXMva2Vybi9rZXJuX3RpbWUuYzo2NzQgKHNsZWVwIG11dGV4OnByb2Nlc3MgbG9jaykKICAgICA3 NDUgICAgICAgIDc3ICAgICAgIDY5NzE1ICAgICAgICAgIDc3ICAgICAgICAgNDY1ICAgIDE0OSAg ICAgIDAgIDAgICAgICAxIC91c3Ivc3JjL3N5cy92bS92bV9vYmplY3QuYzo2MDcgKHNsZWVwIG11 dGV4OnZtIG9iamVjdF9saXN0KQogICAgIDY2NiAgICAgICAgIDAgICAgICAgIDY2MTMgICAgICAg ICAgIDAgICAgICAgICAgMzYgICAgMTgzICAgICAgMCAgMCAgICAgIDAgL3Vzci9zcmMvc3lzL2tl cm4vdmZzX3N1YnIuYzozMjI2IChzbGVlcCBtdXRleDp2bm9kZV9mcmVlX2xpc3QpCiAgICA1NzQ1 ICAgICAgICAxNSAgICAgICAxNzE2OCAgICAgICAgICAxNSAgICAgICAgICAyMiAgICA3ODAgICAg ICAwICAwICAgICAgMSAvdXNyL3NyYy9zeXMva2Vybi90dHlfdHR5ZGlzYy5jOjQ2NyAoc2xlZXAg bXV0ZXg6dHR5bXR4KQogICAgIDcyNCAgICAgICAgIDAgICAgICAgIDE3NDUgICAgICAgICAgIDAg ICAgICAgICAgIDcgICAgMjQ5ICAgICAgMCAgMCAgICAgIDAgL3Vzci9zcmMvc3lzL3ZtL3VtYV9j b3JlLmM6NDEwIChzbGVlcCBtdXRleDptYnVmX2p1bWJvXzlrKQogICAgIDg5MiAgICAgIDE3NTgg ICAgICAgIDgwMjkgICAgICAgIDIzNzYgICAgICAgICAgMjggICAgMjg2ICAgICA4NCAgMCAgICAg IDIgL3Vzci9zcmMvc3lzL3ZtL3ZtX3BhZ2VvdXQuYzoxNDU0IChzbGVlcCBtdXRleDp2bSBwYWdl IHF1ZXVlIGZyZWUgbXV0ZXgpCiAgIDE2MTg3ICAgICAgICAgMCAgICAgIDEzMjE5NiAgICAgICAg ICAgMCAgICAgICAgICAxMyAgMTAxNjggICAgICAwICAwICAgICAgMCAvdXNyL3NyYy9zeXMva2Vy bi9pbWdhY3RfZWxmLmM6Njc1IChsb2NrbWdyOnVmcykKICAgICA5MjIgICAgICAgICAwICAgICAg IDEyNDg3ICAgICAgICAgICAwICAgICAgICAgIDg0ICAgIDE0OCAgICAgIDAgIDAgICAgICAwIC91 c3Ivc3JjL3N5cy9rZXJuL2tlcm5fc2lnLmM6MjAwNyAoc2xlZXAgbXV0ZXg6c2lnYWN0cykKICAg IDEwODggICAgICAgICAwICAgICAgIDM2NTQ1ICAgICAgICAgICAwICAgICAgICAgIDg3ICAgIDQy MCAgICAgIDAgIDAgICAgICAwIC91c3Ivc3JjL3N5cy9rZXJuL3Zmc19oYXNoLmM6NzkgKHNsZWVw IG11dGV4OnZub2RlIGludGVybG9jaykKICAgICAgMzEgICAgICAgICAwICAgICAgICAgIDMxICAg ICAgICAgICAwICAgICAgICAgICAxICAgICAzMSAgICAgIDAgIDAgICAgICAwIC91c3Ivc3JjL3N5 cy9saWJrZXJuL2FyYzRyYW5kb20uYzo2MSAoc2xlZXAgbXV0ZXg6YXJjNF9tdHgpCiAgICAgOTEx ICAgICAgIDk2NSAgICAgIDE0MjI3MSAgICAgICAgMjkyNSAgICAgICAgIDkyMSAgICAxNTQgICAg ICAzICAwICAgICAgNiAvdXNyL3NyYy9zeXMvdm0vdW1hX2NvcmUuYzoyNTI0IChzbGVlcCBtdXRl eDpNQVAgRU5UUlkpCiAgIDI1MDExICAgICAgODkxOSAgICAgMjQyMDA5OSAgICAgIDExMjA5NCAg ICAgICAxNTg5MSAgICAxNTIgICAgICA3ICAwICAgIDI3NSAvdXNyL3NyYy9zeXMvdm0vdm1fcGFn ZS5jOjEwNDkgKHNsZWVwIG11dGV4OnZtIHBhZ2UgcXVldWUgZnJlZSBtdXRleCkKICAgICA2NDcg ICAgICAgMzI2ICAgICAgICAxNjc0ICAgICAgICAgNTU0ICAgICAgICAgIDE5ICAgICA4OCAgICAg MjkgIDAgICAgICAzIC91c3Ivc3JjL3N5cy9rZXJuL3R0eV9wdHMuYzoxMTYgKHNsZWVwIG11dGV4 OnR0eW10eCkKICAgICA4OTcgICAgICAgICAwICAgICAgIDE0ODMyICAgICAgICAgICAwICAgICAg ICAgIDkzICAgIDE1OSAgICAgIDAgIDAgICAgICAwIC91c3Ivc3JjL3N5cy9rZXJuL2tlcm5fcHJv Yy5jOjI5MSAoc3g6YWxscHJvYykKICAgICA4MjggICAgICAgICAwICAgICAgICA0NzYwICAgICAg ICAgICAwICAgICAgICAgIDI0ICAgIDE5OCAgICAgIDAgIDAgICAgICAwIC91c3Ivc3JjL3N5cy9r ZXJuL3Zmc19iaW8uYzoyODMgKHNsZWVwIG11dGV4Om5lZWRzYnVmZmVyIGxvY2spCiAgIDI2NzAx ICAgICAgNjQ2OSAgICAgODkwOTUwOCAgICAgIDE4ODIwMyAgICAgICAgNjc0MCAgIDEzMjEgICAg IDI3ICAwICAgIDIzNiAvdXNyL3NyYy9zeXMvZGV2L2F0YS9hdGEtcXVldWUuYzoxOTQgKHNsZWVw IG11dGV4OkFUQSBzdGF0ZSBsb2NrKQogICAgIDQ5NiAgICAgICAgIDAgICAgICAgIDIyMDEgICAg ICAgICAgIDAgICAgICAgICAgMTMgICAgMTY5ICAgICAgMCAgMCAgICAgIDAgL3Vzci9zcmMvc3lz L2xpYmtlcm4vYXJjNHJhbmRvbS5jOjEzOCAoc2xlZXAgbXV0ZXg6YXJjNF9tdHgpCiAgICA5Mjcx ICAgICAgMTA0MCAgICAgMjQ1ODYyNiAgICAgICAgNjYxNiAgICAgICAxNTc1MCAgICAxNTYgICAg ICAwICAwICAgICAxMyAvdXNyL3NyYy9zeXMva2Vybi92ZnNfYmlvLmM6MzEwIChzbGVlcCBtdXRl eDpuZWVkc2J1ZmZlciBsb2NrKQogICAgMTIxMSAgICAgICAgIDAgICAgICAgIDQ4MjYgICAgICAg ICAgIDAgICAgICAgICAgMTQgICAgMzQ0ICAgICAgMCAgMCAgICAgIDAgL3Vzci9zcmMvc3lzL2tl cm4vdHR5X3B0cy5jOjE5NiAoc2xlZXAgbXV0ZXg6dHR5bXR4KQogICAxMTk0MiAgICAgMjEyMzkg ICAgIDI0NzcyMTQgICAgICAgOTQ3NDMgICAgICAgMTU4MjMgICAgMTU2ICAgICAgNSAgMCAgICAg MzggL3Vzci9zcmMvc3lzL2tlcm4vdmZzX2Jpby5jOjE0MzggKHNsZWVwIG11dGV4OmJ1ZiBxdWV1 ZSBsb2NrKQogICAgIDEyNSAgICAgICAgIDAgICAgICAgICA2MDcgICAgICAgICAgIDAgICAgICAg ICAgIDcgICAgIDg2ICAgICAgMCAgMCAgICAgIDAgL3Vzci9zcmMvc3lzL3ZtL3VtYV9jb3JlLmM6 NDEwIChzbGVlcCBtdXRleDo0MDk2KQogICAxMDQzOSAgICAgMTkwMzUgICAgIDI0NjY4NjcgICAg ICAxODM4NjYgICAgICAgMTU3MjQgICAgMTU2ICAgICAxMSAgMCAgICAgNzkgL3Vzci9zcmMvc3lz L2tlcm4vdmZzX2Jpby5jOjM1MiAoc2xlZXAgbXV0ZXg6bmVlZHNidWZmZXIgbG9jaykKICAgIDE2 MDIgICAgICAgICAwICAgICAgICA1NDgxICAgICAgICAgICAwICAgICAgICAgIDE4ICAgIDMwNCAg ICAgIDAgIDAgICAgICAwIC91c3Ivc3JjL3N5cy9rZXJuL3Zmc19zdWJyLmM6MzE4NiAoc2xlZXAg bXV0ZXg6c3RydWN0IG1vdW50IG10eCkKICAgIDIzODQgICAgICAgICAwICAgICAgICA3OTUwICAg ICAgICAgICAwICAgICAgICAgIDEzICAgIDYxMSAgICAgIDAgIDAgICAgICAwIC91c3Ivc3JjL3N5 cy9rZXJuL2ltZ2FjdF9lbGYuYzo4MjAgKGxvY2ttZ3I6dWZzKQogICAgMTY1MiAgICAgICAgIDAg ICAgICAyOTIzMDEgICAgICAgICAgIDAgICAgICAgICA5ODcgICAgMjk2ICAgICAgMCAgMCAgICAg IDAgL3Vzci9zcmMvc3lzL3ZtL3VtYV9jb3JlLmM6MTk5MCAoc2xlZXAgbXV0ZXg6MzIpCiAgICAg IDg4ICAgICAgICAgMCAgICAgICAgIDE3NiAgICAgICAgICAgMCAgICAgICAgICAgMiAgICAgODgg ICAgICAwICAwICAgICAgMCAvdXNyL3NyYy9zeXMvdm0vdm1fcGFnZXIuYzo0MTMgKHNsZWVwIG11 dGV4OnBidWYgbXV0ZXgpCiAgICAgNzIzICAgICAgICAgMCAgICAgICAgMTIyMyAgICAgICAgICAg MCAgICAgICAgICAgNyAgICAxNzQgICAgICAwICAwICAgICAgMCAvdXNyL3NyYy9zeXMvdm0vdW1h X2NvcmUuYzo0MTAgKHNsZWVwIG11dGV4OmdfYmlvKQogICAgMzg5OSAgICAgICAgIDAgICAgICAx MTAzODEgICAgICAgICAgIDAgICAgICAgICAxNDAgICAgNzg4ICAgICAgMCAgMCAgICAgIDAgL3Vz ci9zcmMvc3lzL2tlcm4va2Vybl9tdXRleC5jOjEzNyAoc2xlZXAgbXV0ZXg6U3luY2VyIG10eCkK ICAgIDEwMTcgICAgICAgICAwICAgICAgIDYxMDY5ICAgICAgICAgICAwICAgICAgICAgMjg2ICAg IDIxMyAgICAgIDAgIDAgICAgICAwIC91c3Ivc3JjL3N5cy9rZXJuL2tlcm5fa3RocmVhZC5jOjIw MSAoc2xlZXAgbXV0ZXg6cHJvY2VzcyBsb2NrKQogICAgIDc0NiAgICAgICAgIDAgICAgICAgIDYx MzkgICAgICAgICAgIDAgICAgICAgICAgMjUgICAgMjQ1ICAgICAgMCAgMCAgICAgIDAgL3Vzci9z cmMvc3lzL2tlcm4vdmZzX2Jpby5jOjM0MDcgKHNsZWVwIG11dGV4OnZtIHBhZ2UgcXVldWUgbXV0 ZXgpCiAgICAgNzUzICAgICAgICAgMCAgICAgICAgMTg3MCAgICAgICAgICAgMCAgICAgICAgICAg NyAgICAyNjcgICAgICAwICAwICAgICAgMCAvdXNyL3NyYy9zeXMvdm0vdW1hX2NvcmUuYzo0MTAg KHNsZWVwIG11dGV4OkRQIGZha2VwZykKICAgICA3NDIgICAgICAgIDg1ICAgICAgIDE1NTg5ICAg ICAgICAgIDg1ICAgICAgICAgIDk1ICAgIDE2NCAgICAgIDAgIDAgICAgICAxIC91c3Ivc3JjL3N5 cy92bS91bWFfY29yZS5jOjI1MjQgKHNsZWVwIG11dGV4OjUxMikKICAgIDEzMTUgICAgICAgICAw ICAgICAgICA2NTEyICAgICAgICAgICAwICAgICAgICAgIDI4ICAgIDIzMiAgICAgIDAgIDAgICAg ICAwIC91c3Ivc3JjL3N5cy92bS92bV9wYWdlb3V0LmM6MTQ4NiAoc2xlZXAgbXV0ZXg6dm0gcGFn ZSBxdWV1ZSBtdXRleCkKICAgOTAxMTggICAgICAgICAwICAgICAyMTk2NjMxICAgICAgICAgICAw ICAgICAgICAgNjM5ICAgMzQzNyAgICAgIDAgIDAgICAgICAwIC91c3Ivc3JjL3N5cy9rZXJuL3Zm c19zdWJyLmM6MjA5MiAobG9ja21ncjp1ZnMpCiAgICAgNzA4ICAgICAgICAgMCAgICAgICAgMTYy MiAgICAgICAgICAgMCAgICAgICAgICAgNyAgICAyMzEgICAgICAwICAwICAgICAgMCAvdXNyL3Ny Yy9zeXMvdm0vdW1hX2NvcmUuYzo0MTAgKHNsZWVwIG11dGV4OlRIUkVBRCkKICAgICA2NjcgICAg ICAgMTI1ICAgICAgICAxMTM1ICAgICAgICAgMzkzICAgICAgICAgIDEyICAgICA5NCAgICAgMzIg IDAgICAgICA3IC91c3Ivc3JjL3N5cy9rZXJuL3R0eV9wdHMuYzozMTcgKHNsZWVwIG11dGV4OnR0 eW10eCkKICAgIDc1MzYgICAgICAyNDAxICAgIDE4NTczMTYzICAgICAgIDQxMjUzICAgICAgIDY1 NTk4ICAgIDI4MyAgICAgIDAgIDAgICAgIDYxIC91c3Ivc3JjL3N5cy9rZXJuL2tlcm5fY29uZi5j OjcxIChzbGVlcCBtdXRleDpjZGV2KQogICAgIDY2MyAgICAgICA3NzQgICAgICAgMTA4NTggICAg ICAgIDQwMjggICAgICAgICAxMDYgICAgMTAyICAgICAzOCAgMCAgICAgMjEgL3Vzci9zcmMvc3lz L2tlcm4vdmZzX2Jpby5jOjM0NjkgKHNsZWVwIG11dGV4OnZtIHBhZ2UgcXVldWUgbXV0ZXgpCiAg ICAgOTAxICAgICAgICAgMCAgICAgICAxMjQzMiAgICAgICAgICAgMCAgICAgICAgICA0NiAgICAy NzAgICAgICAwICAwICAgICAgMCAvdXNyL3NyYy9zeXMva2Vybi9rZXJuX2ZvcmsuYzo0NDIgKHNs ZWVwIG11dGV4OnByb2Nlc3MgbG9jaykKICAgICA3MDkgICAgICAgICAwICAgICAgICA1OTA5ICAg ICAgICAgICAwICAgICAgICAgIDQ2ICAgIDEyOCAgICAgIDAgIDAgICAgICAwIC91c3Ivc3JjL3N5 cy9rZXJuL2tlcm5fZm9yay5jOjQ0MyAoc2xlZXAgbXV0ZXg6cHJvY2VzcyBsb2NrKQogICAgIDcx NyAgICAgICAgIDAgICAgICAgMTM4ODUgICAgICAgICAgIDAgICAgICAgICAxMDAgICAgMTM4ICAg ICAgMCAgMCAgICAgIDAgL3Vzci9zcmMvc3lzL3ZtL3VtYV9jb3JlLmM6MTk5MCAoc2xlZXAgbXV0 ZXg6NjQpCiAgICAxNDc1ICAgICAgICAgMCAgICAgIDE2MzQyOSAgICAgICAgICAgMCAgICAgICAg IDYwMyAgICAyNzEgICAgICAwICAwICAgICAgMCAvdXNyL3NyYy9zeXMva2Vybi92ZnNfY2FjaGUu YzozMzggKHJ3Ok5hbWUgQ2FjaGUpCiAgICAgNDcyICAgICAgICAgMCAgICAgICAgMjUwMCAgICAg ICAgICAgMCAgICAgICAgICAzNyAgICAgNjcgICAgICAwICAwICAgICAgMCAvdXNyL3NyYy9zeXMv a2Vybi9zdWJyX3VuaXQuYzo2MjMgKHNsZWVwIG11dGV4OlRJRCBsb2NrKQogICAxNjg0NyAgICAg ICA4NDcgICAgICA5NTQ1NjggICAgICAgMjA4MTEgICAgICAgIDYyNTQgICAgMTUyICAgICAgMyAg MCAgICAgNjUgL3Vzci9zcmMvc3lzL3ZtL3VtYV9jb3JlLmM6MTk5MCAoc2xlZXAgbXV0ZXg6YXRh X3JlcXVlc3QpCiAgICAxMDI0ICAgICAgICAgMCAgICAgICA0ODk0MiAgICAgICAgICAgMCAgICAg ICAgIDIyNyAgICAyMTUgICAgICAwICAwICAgICAgMCAvdXNyL3NyYy9zeXMvbmV0L2JwZi5jOjE2 NDUgKHNsZWVwIG11dGV4OmJwZikKICAgIDkzNjUgICAgICAgICAwICAgICAgIDE1Nzk1ICAgICAg ICAgICAwICAgICAgICAgICAzICAgNTI2NSAgICAgIDAgIDAgICAgICAwIC91c3Ivc3JjL3N5cy9r ZXJuL3R0eV9wdHMuYzozODUgKHNsZWVwIG11dGV4OnR0eW10eCkKICAgIDM5MDAgICAgICAxMjYy ICAgICAgIDE5NTk4ICAgICAgICA0ODc0ICAgICAgICAgIDk5ICAgIDE5NyAgICAgNDkgIDAgICAg IDE3IC91c3Ivc3JjL3N5cy9rZXJuL3R0eV9wdHMuYzo0MDAgKHNsZWVwIG11dGV4OnR0eW10eCkK ICAgICA4NjUgICAgICAgICAwICAgICAgICAyMTE1ICAgICAgICAgICAwICAgICAgICAgIDIyICAg ICA5NiAgICAgIDAgIDAgICAgICAwIC91c3Ivc3JjL3N5cy9uZXQvaWYuYzoyODg1IChzbGVlcCBt dXRleDplbTApCiAgICAxNjc4ICAgICAxODkyNiAgICAgMjI2MDY0OSAgICAgMzIwODM3OCAgICAg ICAgNzg3MiAgICAyODcgICAgNDA3ICAwICAgIDcyNSAvdXNyL3NyYy9zeXMva2Vybi9rZXJuX2Nv bmYuYzo0MjIgKHNsZWVwIG11dGV4OkdpYW50KQogICAgIDY1MCAgICAgICAgIDAgICAgICAgIDI3 MzMgICAgICAgICAgIDAgICAgICAgICAgMzcgICAgIDczICAgICAgMCAgMCAgICAgIDAgL3Vzci9z cmMvc3lzL3ZtL3VtYV9jb3JlLmM6MTk5MCAoc2xlZXAgbXV0ZXg6a3NpZ2luZm8pCiAgICA1MDI0 ICAgICAgICAgMCAgICAgICA2NzMxNSAgICAgICAgICAgMCAgICAgICAgICAyNSAgIDI2OTIgICAg ICAwICAwICAgICAgMCAvdXNyL3NyYy9zeXMva2Vybi92ZnNfc3Vici5jOjIxOTcgKGxvY2ttZ3I6 dWZzKQogICAgIDcwOCAgICAgICAgIDAgICAgICAgIDE2NTMgICAgICAgICAgIDAgICAgICAgICAg IDcgICAgMjM2ICAgICAgMCAgMCAgICAgIDAgL3Vzci9zcmMvc3lzL3ZtL3VtYV9jb3JlLmM6NDEw IChzbGVlcCBtdXRleDpWTVNQQUNFKQogICAgMTEyNyAgICAgICAgIDAgICAgICAgMTU1MDAgICAg ICAgICAgIDAgICAgICAgICAgNDYgICAgMzM2ICAgICAgMCAgMCAgICAgIDAgL3Vzci9zcmMvc3lz L2tlcm4va2Vybl9mb3JrLmM6NTEyIChzbGVlcCBtdXRleDpwcm9jZXNzIGxvY2spCiAgICAgOTE3 ICAgICAgICAgMCAgICAgICA0NjQ5NCAgICAgICAgICAgMCAgICAgICAgIDI4NCAgICAxNjMgICAg ICAwICAwICAgICAgMCAvdXNyL3NyYy9zeXMvbmV0aW5ldC90Y3BfdGltZXIuYzoxMzYgKHJ3OnRj cCkKICAgICA4NzAgICAgICAgICAwICAgICAgICA5Mjk3ICAgICAgICAgICAwICAgICAgICAgIDQ2 ICAgIDIwMiAgICAgIDAgIDAgICAgICAwIC91c3Ivc3JjL3N5cy9rZXJuL2tlcm5fZm9yay5jOjUx MyAoc2xlZXAgbXV0ZXg6cHJvY2VzcyBsb2NrKQogICAgMTY4MyAgICAxMDE4ODkgICAgIDIyNjcz NzMgICAgIDM4Mjk3NDcgICAgICAgIDc5MzcgICAgMjg1ICAgIDQ4MiAgMCAgICA3ODQgL3Vzci9z cmMvc3lzL2tlcm4va2Vybl9jb25mLmM6NDU0IChzbGVlcCBtdXRleDpHaWFudCkKICAgICAxODEg ICAgICAgICAwICAgICAgICAgNTM3ICAgICAgICAgICAwICAgICAgICAgICAzICAgIDE3OSAgICAg IDAgIDAgICAgICAwIC91c3Ivc3JjL3N5cy9uZXRpbmV0L3RjcF90aW1lci5jOjE2OCAocnc6dGNw KQogICAgIDQ3MyAgICAgICAgIDAgICAgICAgIDEzNzMgICAgICAgICAgIDAgICAgICAgICAgIDgg ICAgMTcxICAgICAgMCAgMCAgICAgIDAgL3Vzci9zcmMvc3lzL3ZtL3VtYV9jb3JlLmM6MjAzNCAo c2xlZXAgbXV0ZXg6a3NpZ2luZm8pCiAgICAxMDc5ICAgICAgICAgMCAgICAgICAzODY1NiAgICAg ICAgICAgMCAgICAgICAgIDE0MiAgICAyNzIgICAgICAwICAwICAgICAgMCAvdXNyL3NyYy9zeXMv a2Vybi9rZXJuX211dGV4LmM6MTM3IChzbGVlcCBtdXRleDpmZGMgbG9jaykKICAgICA0NDAgICAg ICAgICAwICAgICAgICAgOTM0ICAgICAgICAgICAwICAgICAgICAgICA3ICAgIDEzMyAgICAgIDAg IDAgICAgICAwIC91c3Ivc3JjL3N5cy92bS91bWFfY29yZS5jOjQxMCAoc2xlZXAgbXV0ZXg6c2Vs ZmQpCiAgICAgODcxICAgICAgICAgMCAgICAgICAgMjQzNiAgICAgICAgICAgMCAgICAgICAgICAg NyAgICAzNDggICAgICAwICAwICAgICAgMCAvdXNyL3NyYy9zeXMvdm0vdW1hX2NvcmUuYzo0MTAg KHNsZWVwIG11dGV4OlVNQSBab25lcykKICAgMjA5NzQgICAgICAgNTAxICAgICAxMDc5MzQ2ICAg ICAgICAgNzAxICAgICAgICAzMTE3ICAgIDM0NiAgICAgIDAgIDAgICAgICAzIC91c3Ivc3JjL3N5 cy9rZXJuL3Zmc19iaW8uYzoxNzA4IChzbGVlcCBtdXRleDpidWYgcXVldWUgbG9jaykKICAgIDEz MjEgICAgICA1MDQ1ICAgICAgMzEzMTI3ICAgICAgIDIyMzE3ICAgICAgICAyMTMxICAgIDE0NiAg ICAgMTAgIDAgICAgIDM0IC91c3Ivc3JjL3N5cy92bS92bV9wYWdlLmM6MTQxNiAoc2xlZXAgbXV0 ZXg6dm0gcGFnZSBxdWV1ZSBmcmVlIG11dGV4KQogICAgIDkwMyAgICAgICAgIDAgICAgICAgIDQ4 MTAgICAgICAgICAgIDAgICAgICAgICAgMTggICAgMjY3ICAgICAgMCAgMCAgICAgIDAgL3Vzci9z cmMvc3lzL2tlcm4vdmZzX3N1YnIuYzozNDM3IChzbGVlcCBtdXRleDpzdHJ1Y3QgbW91bnQgbXR4 KQogICAgIDE0MSAgICAgICAgIDAgICAgICAgICA2MDkgICAgICAgICAgIDAgICAgICAgICAgIDcg ICAgIDg3ICAgICAgMCAgMCAgICAgIDAgL3Vzci9zcmMvc3lzL3ZtL3VtYV9jb3JlLmM6NDEwIChz bGVlcCBtdXRleDptYnVmX2p1bWJvXzE2aykKICAgIDE1MDEgICAgICAgICAwICAgICAgIDI1NjQ1 ICAgICAgICAgICAwICAgICAgICAgIDQ2ICAgIDU1NyAgICAgIDAgIDAgICAgICAwIC91c3Ivc3Jj L3N5cy9rZXJuL2tlcm5fZm9yay5jOjYwMiAoc2xlZXAgbXV0ZXg6cHJvY2VzcyBsb2NrKQogICAg MTA5NCAgICAgICAgIDAgICAgICAgMTc2MDYgICAgICAgICAgIDAgICAgICAgICAgNDYgICAgMzgy ICAgICAgMCAgMCAgICAgIDAgL3Vzci9zcmMvc3lzL2tlcm4va2Vybl9mb3JrLmM6NjAzIChzbGVl cCBtdXRleDpwcm9jZXNzIGxvY2spCiAgICAgNzYyICAgICAgICAgMCAgICAgICAgMTgxNiAgICAg ICAgICAgMCAgICAgICAgICAgMyAgICA2MDUgICAgICAwICAwICAgICAgMCAvdXNyL3NyYy9zeXMv ZnMvZGV2ZnMvZGV2ZnNfdm5vcHMuYzo4NjkgKHN4OmRldmZzbW91bnQpCiAgICAgMTQzICAgICAg ICAgMCAgICAgICAgIDYzMSAgICAgICAgICAgMCAgICAgICAgICAgNyAgICAgOTAgICAgICAwICAw ICAgICAgMCAvdXNyL3NyYy9zeXMvdm0vdW1hX2NvcmUuYzo0MTAgKHNsZWVwIG11dGV4OnNjdHBf ZXApCiAgICAzNTg3ICAgICAgICAgMCAgICAgICA4NzEyNyAgICAgICAgICAgMCAgICAgICAgIDE5 NSAgICA0NDYgICAgICAwICAwICAgICAgMCAvdXNyL3NyYy9zeXMvYW1kNjQvYW1kNjQvcG1hcC5j OjI0NzEgKHNsZWVwIG11dGV4OnBtYXApCiAgIDEwMTIwICAgICAgICAgMCAgICAgICA4MjU5MyAg ICAgICAgICAgMCAgICAgICAgIDEyNiAgICA2NTUgICAgICAwICAwICAgICAgMCAvdXNyL3NyYy9z eXMva2Vybi91aXBjX3NvY2tldC5jOjI2NjYgKHNsZWVwIG11dGV4OnNvX3NuZCkKICAgIDY5Nzcg ICAgICAxNzE5ICAgICAgOTU5NzEyICAgICAgIDE3MzMzICAgICAgICA2MjU0ICAgIDE1MyAgICAg IDIgIDAgICAgIDQ0IC91c3Ivc3JjL3N5cy9kZXYvYXRhL2F0YS1xdWV1ZS5jOjg2IChzbGVlcCBt dXRleDpBVEEgcXVldWUgbG9jaykKICAgICA3MTAgICAgICAgICAwICAgICAgICA0MDc2ICAgICAg ICAgICAwICAgICAgICAgIDE4ICAgIDIyNiAgICAgIDAgIDAgICAgICAwIC91c3Ivc3JjL3N5cy91 ZnMvZmZzL2Zmc19zb2Z0ZGVwLmM6NjI4MiAoc2xlZXAgbXV0ZXg6U29mdGRlcCBMb2NrKQogICAg IDYwNyAgICAgICAgIDAgICAgICAgMTIzMzEgICAgICAgICAgIDAgICAgICAgICAxMDggICAgMTE0 ICAgICAgMCAgMCAgICAgIDAgL3Vzci9zcmMvc3lzL3ZtL3VtYV9jb3JlLmM6MTk5MCAoc2xlZXAg bXV0ZXg6VFVSTlNUSUxFKQogICAgOTU0NSAgICAzNjc5MjMgICAgIDExODcwNzUgICAgIDI4MTQ5 NzcgICAgICAgIDIxNTUgICAgNTUwICAgMTMwNiAgMCAgICAyMzggL3Vzci9zcmMvc3lzL3ZtL3Zt X2ZhdWx0LmM6Mjk3IChzbGVlcCBtdXRleDp2bSBvYmplY3QpCiAgICAgODE0ICAgICAgICAgMCAg ICAgICAzMzY3NiAgICAgICAgICAgMCAgICAgICAgIDI1NiAgICAxMzEgICAgICAwICAwICAgICAg MCAvdXNyL3NyYy9zeXMvdm0vdW1hX2NvcmUuYzoxOTkwIChzbGVlcCBtdXRleDpOQU1FSSkKICAg MzY0MjUgICAgICAgICAwICAgIDEwODI4OTcyICAgICAgICAgICAwICAgICAgICAgNzEwICAxNTI1 MiAgICAgIDAgIDAgICAgICAwIC91c3Ivc3JjL3N5cy9kZXYvdXNiMi9jb3JlL3VzYjJfcmVxdWVz dC5jOjMwNiAoc3g6MDEyMzQ1Njc4OUFCQ0RFRiAtIFVTQiBkZXZpY2UgU1ggbG9jaykKICAgIDM5 MTMgICAgICAgICAwICAgICAgMjAwNjI3ICAgICAgICAgICAwICAgICAgICAgOTA4ICAgIDIyMCAg ICAgIDAgIDAgICAgICAwIC91c3Ivc3JjL3N5cy92bS92bV9tYXAuYzoyNDM0IChzbGVlcCBtdXRl eDp2bSBvYmplY3QpCiAgICAgMTA4ICAgICAgICAgMCAgICAgICAgIDYwNiAgICAgICAgICAgMCAg ICAgICAgICAgOCAgICAgNzUgICAgICAwICAwICAgICAgMCAvdXNyL3NyYy9zeXMvdm0vdW1hX2Nv cmUuYzoyMDM0IChzbGVlcCBtdXRleDpUVVJOU1RJTEUpCiAgICA3MDY0ICAgICAgICAgMCAgICAg ICAxNzcyMyAgICAgICAgICAgMCAgICAgICAgICAgMyAgIDU5MDcgICAgICAwICAwICAgICAgMCAv dXNyL3NyYy9zeXMvbmV0aW5ldC90Y3BfdGltZXIuYzoxODMgKHJ3OnRjcGlucCkKICAgIDI5MTgg ICAgICAgNDcyICAgICAgIDUyNzkzICAgICAgICAxNzU4ICAgICAgICAgNTc4ICAgICA5MSAgICAg IDMgIDAgICAgIDE0IC91c3Ivc3JjL3N5cy92bS91bWFfY29yZS5jOjE5OTAgKHNsZWVwIG11dGV4 OlZNIE9CSkVDVCkKICAgNzUwMjEgICAgICAgICAwICAgICAgMTIyNDYyICAgICAgICAgICAwICAg ICAgICAgICAyICA2MTIzMSAgICAgIDAgIDAgICAgICAwIC91c3Ivc3JjL3N5cy92bS92bV9wYWdl ci5jOjMxMyAobG9ja21ncjpidWZ3YWl0KQogICAgMTgwOSAgICAyMTk0NDkgICAgICAxMjkwMzgg ICAgIDIyODY4NTcgICAgICAgICAyMTEgICAgNjExICAxMDgzOCAgMCAgICAyMDkgL3Vzci9zcmMv c3lzL3ZtL3ZtX2ZhdWx0LmM6Mzc1IChzbGVlcCBtdXRleDp2bSBvYmplY3QpCiAgIDMwNjAzICAg ICAgOTYzOSAgICAxMjMwNDAzOSAgICAgIDUzODEzOCAgICAgICAxMjUwOCAgICA5ODMgICAgIDQz ICAwICAgIDQxOSAvdXNyL3NyYy9zeXMvZGV2L2F0YS9hdGEtcXVldWUuYzoxNzcgKHNsZWVwIG11 dGV4OkFUQSBxdWV1ZSBsb2NrKQogICAgIDg0MyAgICAgICAgIDAgICAgICAgMTQ2ODkgICAgICAg ICAgIDAgICAgICAgICAgNDYgICAgMzE5ICAgICAgMCAgMCAgICAgIDAgL3Vzci9zcmMvc3lzL2tl cm4vc3Vicl9ldmVudGhhbmRsZXIuYzoyMTUgKHNsZWVwIG11dGV4OnByb2Nlc3NfZXhpdCkKICAg MTIzNjQgICAgICAgNDMzICAgICA0MTk2MTMyICAgICAgICAgODcyICAgICAgIDI1MDE2ICAgIDE2 NyAgICAgIDAgIDAgICAgICA0IC91c3Ivc3JjL3N5cy9rZXJuL3Zmc19iaW8uYzoyOTcyIChzbGVl cCBtdXRleDpzbGVlcCBtdHhwb29sKQogICAgIDQ2OSAgICAgICAgNjUgICAgICAgIDIxNjMgICAg ICAgICAgNjUgICAgICAgICAgMjggICAgIDc3ICAgICAgMiAgMCAgICAgIDEgL3Vzci9zcmMvc3lz L3ZtL3VtYV9jb3JlLmM6MjAzNCAoc2xlZXAgbXV0ZXg6Vk0gT0JKRUNUKQogICAgIDQ3MiAgICAg ICAgIDAgICAgICAgIDM0NzUgICAgICAgICAgIDAgICAgICAgICAgNDYgICAgIDc1ICAgICAgMCAg MCAgICAgIDAgL3Vzci9zcmMvc3lzL2tlcm4va2Vybl9mb3JrLmM6NzQwIChzbGVlcCBtdXRleDpw cm9jZXNzIGxvY2spCiAgICAgNjY4ICAgICAgIDQ5OSAgICAgICAgNDU0MSAgICAgICAgIDQ5OSAg ICAgICAgICA0NiAgICAgOTggICAgIDEwICAwICAgICAgMSAvdXNyL3NyYy9zeXMva2Vybi9rZXJu X2ZvcmsuYzo3NTUgKHNsZWVwIG11dGV4OnByb2Nlc3MgbG9jaykKICAgICAgOTEgICAgICAgICAw ICAgICAgICAgNDE3ICAgICAgICAgICAwICAgICAgICAgICA2ICAgICA2OSAgICAgIDAgIDAgICAg ICAwIC91c3Ivc3JjL3N5cy92bS92bV91bml4LmM6ODIgKHNsZWVwIG11dGV4OnByb2Nlc3MgbG9j aykKICAgICA4NjcgICAgICAgICAwICAgICAgIDQ3ODcyICAgICAgICAgICAwICAgICAgICAgMjg0 ICAgIDE2OCAgICAgIDAgIDAgICAgICAwIC91c3Ivc3JjL3N5cy9uZXRpbmV0L2lnbXAuYzo0NjUg KHNsZWVwIG11dGV4OmlnbXBfbXR4KQogICAgIDk1MCAgICAgICAgIDAgICAgICAgMjcwNTggICAg ICAgICAgIDAgICAgICAgICAgNjQgICAgNDIyICAgICAgMCAgMCAgICAgIDAgL3Vzci9zcmMvc3lz L3ZtL3ZtX29iamVjdC5jOjE1NzggKHNsZWVwIG11dGV4OnZtIHBhZ2UgcXVldWUgbXV0ZXgpCiAg ICAgOTIwICAgICAgICAgMCAgICAgICAgMjU1NSAgICAgICAgICAgMCAgICAgICAgICAyMiAgICAx MTYgICAgICAwICAwICAgICAgMCAvdXNyL3NyYy9zeXMvZGV2L2UxMDAwL2lmX2VtLmM6MTAwMyAo c2xlZXAgbXV0ZXg6ZW0wKQogICAgIDYyNSAgICAgICAgIDAgICAgICAgMTk0MzAgICAgICAgICAg IDAgICAgICAgICAxNjcgICAgMTE2ICAgICAgMCAgMCAgICAgIDAgL3Vzci9zcmMvc3lzL3ZtL3Vt YV9jb3JlLmM6OTE0IChzbGVlcCBtdXRleDo0MDk2KQogICAgIDgxNSAgICAgICAgIDAgICAgICAg IDE5MzAgICAgICAgICAgIDAgICAgICAgICAgIDcgICAgMjc1ICAgICAgMCAgMCAgICAgIDAgL3Vz ci9zcmMvc3lzL3ZtL3VtYV9jb3JlLmM6NDEwIChzbGVlcCBtdXRleDoxNikKICAgIDM0MzAgICAg ICAgICAwICAgICAgIDQyNTE5ICAgICAgICAgICAwICAgICAgICAgMTI2ICAgIDMzNyAgICAgIDAg IDAgICAgICAwIC91c3Ivc3JjL3N5cy9rZXJuL3VpcGNfc29ja2V0LmM6MjY2NyAoc2xlZXAgbXV0 ZXg6c29fcmN2KQogICAgMTM4MiAgICAgICAgIDAgICAgICAgNDkyNTkgICAgICAgICAgIDAgICAg ICAgICAzMTcgICAgMTU1ICAgICAgMCAgMCAgICAgIDAgL3Vzci9zcmMvc3lzL3ZtL3ZtX29iamVj dC5jOjE2MDUgKHNsZWVwIG11dGV4OnZtIHBhZ2UgcXVldWUgbXV0ZXgpCiAgICAgMjY4ICAgICAg ICAgMCAgICAgICAgIDc4NSAgICAgICAgICAgMCAgICAgICAgICAgNyAgICAxMTIgICAgICAwICAw ICAgICAgMCAvdXNyL3NyYy9zeXMvdm0vdW1hX2NvcmUuYzo0MTAgKHNsZWVwIG11dGV4OnNjdHBf YXNvYykKICAgIDExNzggICAgICAgICAwICAgICAgIDU2MDI0ICAgICAgICAgICAwICAgICAgICAg MjE2ICAgIDI1OSAgICAgIDAgIDAgICAgICAwIC91c3Ivc3JjL3N5cy9hbWQ2NC9hbWQ2NC9wbWFw LmM6MjcxOCAoc2xlZXAgbXV0ZXg6cG1hcCkKICAgICA5MzMgICAgICAgICAwICAgICAgIDEyMjk2 ICAgICAgICAgICAwICAgICAgICAgIDQ4ICAgIDI1NiAgICAgIDAgIDAgICAgICAwIC91c3Ivc3Jj L3N5cy92bS91bWFfY29yZS5jOjkxNCAoc2xlZXAgbXV0ZXg6Z19iaW8pCiAgICAgOTI0ICAgIDE2 NDI3NSAgICAgICAzNjk2MyAgICAgMjU1NDIwNCAgICAgICAgIDIwMCAgICAxODQgIDEyNzcxICAw ICAgIDE5OCAvdXNyL3NyYy9zeXMva2Vybi9rZXJuX211dGV4LmM6MTM3IChzbGVlcCBtdXRleDp2 bSBvYmplY3QpCiAgICA2Mzg3ICAgICAgICAgMCAgICAgICAxMzcxOCAgICAgICAgICAgMCAgICAg ICAgICAzNSAgICAzOTEgICAgICAwICAwICAgICAgMCAvdXNyL3NyYy9zeXMvZGV2L3JhbmRvbS95 YXJyb3cuYzoxOTEgKHNsZWVwIG11dGV4OnJhbmRvbSByZXNlZWQpCiAgICAgOTA3ICAgICAgIDYx NCAgICAgIDEzMjkxMSAgICAgICAgMzE0OSAgICAgICAgIDYzOCAgICAyMDggICAgICA0ICAwICAg ICAyMyAvdXNyL3NyYy9zeXMvdm0vdm1fbWFwLmM6MjY0NCAoc2xlZXAgbXV0ZXg6dm0gb2JqZWN0 KQogICAgIDcxNyAgICAgICAgIDAgICAgICAgIDEyNTQgICAgICAgICAgIDAgICAgICAgICAgIDcg ICAgMTc5ICAgICAgMCAgMCAgICAgIDAgL3Vzci9zcmMvc3lzL3ZtL3VtYV9jb3JlLmM6NDEwIChz bGVlcCBtdXRleDpVTUEgU2xhYnMpCiAgICAxNjMwICAgICAgICAgMCAgICAgIDI4NDgyMiAgICAg ICAgICAgMCAgICAgICAgIDk4NyAgICAyODggICAgICAwICAwICAgICAgMCAvdXNyL3NyYy9zeXMv dm0vdW1hX2NvcmUuYzoyNTI0IChzbGVlcCBtdXRleDozMikKICAgMzM4ODggICAgICAgICAwICAg ICAgMTQ5ODIxICAgICAgICAgICAwICAgICAgICAgIDEwICAxNDk4MiAgICAgIDAgIDAgICAgICAw IC91c3Ivc3JjL3N5cy9rZXJuL3Zmc19zdWJyLmM6MTcwMiAobG9ja21ncjpkZXZmcykKICAgICA2 NTUgICAgICAgICAwICAgICAgIDEyODQ5ICAgICAgICAgICAwICAgICAgICAgIDkzICAgIDEzOCAg ICAgIDAgIDAgICAgICAwIC91c3Ivc3JjL3N5cy91ZnMvdWZzL3Vmc192bm9wcy5jOjE3NSAoc2xl ZXAgbXV0ZXg6dm5vZGUgaW50ZXJsb2NrKQogICAgMTYzMiAgICAgICAgIDAgICAgICAgMTUzMTEg ICAgICAgICAgIDAgICAgICAgICAgMzAgICAgNTEwICAgICAgMCAgMCAgICAgIDAgL3Vzci9zcmMv c3lzL2tlcm4vdmZzX3N1YnIuYzoxNzA2IChzbGVlcCBtdXRleDpidWZvYmogaW50ZXJsb2NrKQog ICAgIDQ1MiAgICAgICAgIDAgICAgICAgIDMyODAgICAgICAgICAgIDAgICAgICAgICAgMzcgICAg IDg4ICAgICAgMCAgMCAgICAgIDAgL3Vzci9zcmMvc3lzL3ZtL3ZtX21hcC5jOjEyOTkgKHNsZWVw IG11dGV4OnN5c3RlbSBtYXApCiAgICAgNDUxICAgICAgICAgMCAgICAgICAgMjI0MCAgICAgICAg ICAgMCAgICAgICAgICAyNyAgICAgODIgICAgICAwICAwICAgICAgMCAvdXNyL3NyYy9zeXMvdm0v dW1hX2NvcmUuYzo5MTQgKHNsZWVwIG11dGV4OlRIUkVBRCkKICAgICA4NzYgICAgICAgICAwICAg ICAgIDE2NzEyICAgICAgICAgICAwICAgICAgICAgMTI3ICAgIDEzMSAgICAgIDAgIDAgICAgICAw IC91c3Ivc3JjL3N5cy9rZXJuL3Zmc19iaW8uYzo0MTggKHNsZWVwIG11dGV4OmJ1ZmZlciBkYWVt b24gbG9jaykKICAgICA2NjIgICAgICAgICAwICAgICAgICAxODg4ICAgICAgICAgICAwICAgICAg ICAgICA2ICAgIDMxNCAgICAgIDAgIDAgICAgICAwIC91c3Ivc3JjL3N5cy9mcy9kZXZmcy9kZXZm c192bm9wcy5jOjM0OCAoc2xlZXAgbXV0ZXg6ZGV2ZnMgaW50ZXJsb2NrKQogICAgMzE5NCAgICAg ICAgIDAgICAgICAgMjQ0OTkgICAgICAgICAgIDAgICAgICAgICAgMTMgICAxODg0ICAgICAgMCAg MCAgICAgIDAgL3Vzci9zcmMvc3lzL2tlcm4va2Vybl9leGVjLmM6NTYxIChsb2NrbWdyOnVmcykK ICAgICA1MTYgICAgICAgICAwICAgICAgICAgNTM5ICAgICAgICAgICAwICAgICAgICAgICAyICAg IDI2OSAgICAgIDAgIDAgICAgICAwIC91c3Ivc3JjL3N5cy9kZXYvcmFuZG9tL3lhcnJvdy5jOjI3 OCAoc2xlZXAgbXV0ZXg6cmFuZG9tIHJlc2VlZCkKICAgMTEyMTAgICAgICA4MjUwICAgICA3MDc0 Nzc5ICAgICAgMTI2NzQyICAgICAgIDEyODgwICAgIDU0OSAgICAgIDkgIDAgICAgIDQ5IC91c3Iv c3JjL3N5cy9kZXYvYXRhL2F0YS1hbGwuYzozMjggKHNsZWVwIG11dGV4OkFUQSBzdGF0ZSBsb2Nr KQogICA0NTYxNiAgICAgICAgIDAgICAgICAyMTY1NTUgICAgICAgICAgIDAgICAgICAgICAgIDcg IDMwOTM2ICAgICAgMCAgMCAgICAgIDAgL3Vzci9zcmMvc3lzL3ZtL3VtYV9jb3JlLmM6MTU2MyAo c2xlZXAgbXV0ZXg6VU1BIGxvY2spCiAgICAxMDEzICAgICAgICAgMCAgICAgICAxNTQ3MiAgICAg ICAgICAgMCAgICAgICAgICA5MyAgICAxNjYgICAgICAwICAwICAgICAgMCAvdXNyL3NyYy9zeXMv dm0vdW1hX2NvcmUuYzoyNTI0IChzbGVlcCBtdXRleDo2NCkKICAgICA2OTEgICAgICAgICAwICAg ICAgICAxNTQ5ICAgICAgICAgICAwICAgICAgICAgICA3ICAgIDIyMSAgICAgIDAgIDAgICAgICAw IC91c3Ivc3JjL3N5cy92bS91bWFfY29yZS5jOjQxMCAoc2xlZXAgbXV0ZXg6TkZTTk9ERSkKICAg MTA0OTYgICAgICAxMTM0ICAgICAxMDY1NjA3ICAgICAgIDI5MjgxICAgICAgICA2MjU0ICAgIDE3 MCAgICAgIDQgIDAgICAgIDkxIC91c3Ivc3JjL3N5cy92bS91bWFfY29yZS5jOjI1MjQgKHNsZWVw IG11dGV4OmF0YV9yZXF1ZXN0KQogICAgIDc2MyAgICAgICAgIDAgICAgICAgMTUwMDEgICAgICAg ICAgIDAgICAgICAgICAgODQgICAgMTc4ICAgICAgMCAgMCAgICAgIDAgL3Vzci9zcmMvc3lzL3Vm cy91ZnMvdWZzX3Zub3BzLmM6MjkzIChzbGVlcCBtdXRleDp2bm9kZSBpbnRlcmxvY2spCiAgICAg NDgzICAgICAgICAgMCAgICAgICAgMTAyMyAgICAgICAgICAgMCAgICAgICAgICAgOCAgICAxMjcg ICAgICAwICAwICAgICAgMCAvdXNyL3NyYy9zeXMvdm0vdW1hX2NvcmUuYzo5MTQgKHNsZWVwIG11 dGV4OlZNU1BBQ0UpCiAgICAgNzYyICAgICAgICAgMCAgICAgICAgNjQ3MiAgICAgICAgICAgMCAg ICAgICAgICAzNSAgICAxODQgICAgICAwICAwICAgICAgMCAvdXNyL3NyYy9zeXMvdm0vdm1fZmF1 bHQuYzo2ODggKHNsZWVwIG11dGV4OnZtIG9iamVjdCkKICAgIDQ3ODUgICAgICAgNzg3ICAgICAg NjgxMjU5ICAgICAgICA5NjcwICAgICAgICAgOTI0ICAgIDczNyAgICAgMTAgIDAgICAgIDQ5IC91 c3Ivc3JjL3N5cy92bS92bV9mYXVsdC5jOjcwNiAoc2xlZXAgbXV0ZXg6dm0gb2JqZWN0KQogICAg MTAxNCAgICAgICAgIDAgICAgICAgIDM5MzAgICAgICAgICAgIDAgICAgICAgICAgNDUgICAgIDg3 ICAgICAgMCAgMCAgICAgIDAgL3Vzci9zcmMvc3lzL2tlcm4vdHR5LmM6MzY0IChzbGVlcCBtdXRl eDpwcm9jZXNzIGxvY2spCiAgICAgNzIzICAgICAgICAgMCAgICAgICAgMjEwNyAgICAgICAgICAg MCAgICAgICAgICAgNyAgICAzMDEgICAgICAwICAwICAgICAgMCAvdXNyL3NyYy9zeXMvdm0vdW1h X2NvcmUuYzo0MTAgKHNsZWVwIG11dGV4Om1idWZfZXh0X3JlZmNudCkKICAgICA4NzUgICAgICAg ICAwICAgICAgIDIxNDc5ICAgICAgICAgICAwICAgICAgICAgMTUyICAgIDE0MSAgICAgIDAgIDAg ICAgICAwIC91c3Ivc3JjL3N5cy92bS91bWFfY29yZS5jOjI2MDIgKHNsZWVwIG11dGV4OmF0YV9y ZXF1ZXN0KQogICAgMTE1MiAgICAgICAgIDAgICAgICAgMjExODcgICAgICAgICAgIDAgICAgICAg ICAgOTMgICAgMjI3ICAgICAgMCAgMCAgICAgIDAgL3Vzci9zcmMvc3lzL2tlcm4va2Vybl9wcm9j LmM6Mjk4IChzbGVlcCBtdXRleDpwcm9jZXNzIGxvY2spCiAgICAyMzA4ICAgICAgICAgMCAgICAg IDU4MDU3MiAgICAgICAgICAgMCAgICAgICAgMTk0NCAgICAyOTggICAgICAwICAwICAgICAgMCAv dXNyL3NyYy9zeXMvYW1kNjQvYW1kNjQvcG1hcC5jOjI5NjUgKHNsZWVwIG11dGV4OnBtYXApCiAg ICAzNzM5ICAgICAgICAgMCAgICAgICA1NDA1NiAgICAgICAgICAgMCAgICAgICAgICA1MSAgIDEw NTkgICAgICAwICAwICAgICAgMCAvdXNyL3NyYy9zeXMvdm0vdm1fb2JqZWN0LmM6MTg3MiAoc2xl ZXAgbXV0ZXg6dm0gcGFnZSBxdWV1ZSBtdXRleCkKICAgIDEwNDAgICAgICAgICAwICAgICAgIDE1 NzEzICAgICAgICAgICAwICAgICAgICAgIDQ1ICAgIDM0OSAgICAgIDAgIDAgICAgICAwIC91c3Iv c3JjL3N5cy9rZXJuL3Zmc19zdWJyLmM6MTkzNiAoc2xlZXAgbXV0ZXg6YnVmb2JqIGludGVybG9j aykKICAgICA2NjkgICAgICAgICAwICAgICAgIDIyNTc0ICAgICAgICAgICAwICAgICAgICAgMTg1 ICAgIDEyMiAgICAgIDAgIDAgICAgICAwIC91c3Ivc3JjL3N5cy91ZnMvdWZzL3Vmc192bm9wcy5j OjQyMiAoc2xlZXAgbXV0ZXg6dm5vZGUgaW50ZXJsb2NrKQogICAgIDY2NiAgICAgICAgIDAgICAg ICAgIDM4NDQgICAgICAgICAgIDAgICAgICAgICAgMTcgICAgMjI2ICAgICAgMCAgMCAgICAgIDAg L3Vzci9zcmMvc3lzL3ZtL3VtYV9jb3JlLmM6MjY2MSAoc2xlZXAgbXV0ZXg6YXRhX3JlcXVlc3Qp CiAgICAxMDAyICAgICAgICAgMCAgICAgICA5NzUyMCAgICAgICAgICAgMCAgICAgICAgIDg4OSAg ICAxMDkgICAgICAwICAwICAgICAgMCAvdXNyL3NyYy9zeXMvdm0vdm1fZmF1bHQuYzo4MDkgKHNs ZWVwIG11dGV4OnZtIG9iamVjdCkKICAgICA1NDIgICAgICAgICAwICAgICAgICAxMDYxICAgICAg ICAgICAwICAgICAgICAgICA3ICAgIDE1MSAgICAgIDAgIDAgICAgICAwIC91c3Ivc3JjL3N5cy92 bS91bWFfY29yZS5jOjQxMCAoc2xlZXAgbXV0ZXg6c2N0cF9sYWRkcikKICAgICAgODYgICAgICAg ICAwICAgICAgICAgMTY5ICAgICAgICAgICAwICAgICAgICAgICAyICAgICA4NCAgICAgIDAgIDAg ICAgICAwIC91c3Ivc3JjL3N5cy92bS92bV9wYWdlci5jOjUwMCAoc2xlZXAgbXV0ZXg6YnVmb2Jq IGludGVybG9jaykKICAgICA4MzEgICAgICAgICAwICAgICAgIDM2NTYwICAgICAgICAgICAwICAg ICAgICAgMjU2ICAgIDE0MiAgICAgIDAgIDAgICAgICAwIC91c3Ivc3JjL3N5cy92bS91bWFfY29y ZS5jOjI1MjQgKHNsZWVwIG11dGV4Ok5BTUVJKQogICAgIDc1MiAgICAgICAgIDAgICAgICAgIDE3 MTUgICAgICAgICAgIDAgICAgICAgICAgIDcgICAgMjQ1ICAgICAgMCAgMCAgICAgIDAgL3Vzci9z cmMvc3lzL3ZtL3VtYV9jb3JlLmM6NDEwIChzbGVlcCBtdXRleDpVTUEgUkNudFNsYWJzKQogICAg IDkyNSAgICAgICAgIDAgICAgICAgMTA0OTEgICAgICAgICAgIDAgICAgICAgICAgMjYgICAgNDAz ICAgICAgMCAgMCAgICAgIDAgL3Vzci9zcmMvc3lzL3ZtL3ZtX2dsdWUuYzoyNTMgKHNsZWVwIG11 dGV4OnZtIG9iamVjdCkKICAgIDgwMTQgICAgIDEzMDE5ICAgICAgNzkyMjE0ICAgICAxMTQ2Mzcw ICAgICAgICAxMTE5ICAgIDcwNyAgIDEwMjQgIDAgICAgNjk4IC91c3Ivc3JjL3N5cy9rZXJuL2tl cm5fbXV0ZXguYzoxMzcgKHNsZWVwIG11dGV4Om9oY2kwKQogICAgMTE5OSAgICAgICAgIDAgICAg ICAgIDkzMjkgICAgICAgICAgIDAgICAgICAgICAgMTggICAgNTE4ICAgICAgMCAgMCAgICAgIDAg L3Vzci9zcmMvc3lzL2tlcm4vdmZzX3N1YnIuYzozNDI4IChzbGVlcCBtdXRleDptb3VudGxpc3Qp CiAgICAxMTQxICAgICAgICAgMCAgICAgICA4ODgwMyAgICAgICAgICAgMCAgICAgICAgIDUxNyAg ICAxNzEgICAgICAwICAwICAgICAgMCAvdXNyL3NyYy9zeXMvdm0vdW1hX2NvcmUuYzoyNTI0IChz bGVlcCBtdXRleDpWTSBPQkpFQ1QpCiAgICAxNzQ3ICAgICAgICAgMCAgICAgICAxMzYzNiAgICAg ICAgICAgMCAgICAgICAgICAxMyAgIDEwNDggICAgICAwICAwICAgICAgMCAvdXNyL3NyYy9zeXMv a2Vybi9rZXJuX2V4ZWMuYzo4MzkgKGxvY2ttZ3I6dWZzKQogICAgICA4NyAgICAgICAgIDAgICAg ICAgICAxMTkgICAgICAgICAgIDAgICAgICAgICAgIDMgICAgIDM5ICAgICAgMCAgMCAgICAgIDAg L3Vzci9zcmMvc3lzL2tlcm4va2Vybl9wcm9jLmM6NDUxIChzbGVlcCBtdXRleDpwcm9jZXNzIGxv Y2spCiAgICAgNDU2ICAgICAgICAgMCAgICAgICAgMTc1OCAgICAgICAgICAgMCAgICAgICAgICAx NyAgICAxMDMgICAgICAwICAwICAgICAgMCAvdXNyL3NyYy9zeXMvdm0vdm1fbW1hcC5jOjQwMCAo c3g6cG1jLXN4KQogICAgIDQ1MyAgICAgICAgIDAgICAgICAgICA5NzIgICAgICAgICAgIDAgICAg ICAgICAgIDcgICAgMTM4ICAgICAgMCAgMCAgICAgIDAgL3Vzci9zcmMvc3lzL3ZtL3VtYV9jb3Jl LmM6NDEwIChzbGVlcCBtdXRleDpESVJIQVNIKQogICAgNTY0NCAgICAgIDI5MjIgICAgICA3OTg0 NzUgICAgICAgMTQzMjUgICAgICAgIDE5NDQgICAgNDEwICAgICAgNyAgMCAgICAgMTMgL3Vzci9z cmMvc3lzL3ZtL3ZtX2ZhdWx0LmM6OTM0IChzbGVlcCBtdXRleDp2bSBvYmplY3QpCiAgICA1MjAy ICAgICAgICAgMCAgICAgICAyMTkwOCAgICAgICAgICAgMCAgICAgICAgICAgNiAgIDM2NTEgICAg ICAwICAwICAgICAgMCAvdXNyL3NyYy9zeXMva2Vybi92ZnNfc3Vici5jOjIwOTIgKGxvY2ttZ3I6 ZGV2ZnMpCiAgICAgIDkyICAgICAgICAgMCAgICAgICAgICA5MiAgICAgICAgICAgMCAgICAgICAg ICAgMSAgICAgOTIgICAgICAwICAwICAgICAgMCAvdXNyL3NyYy9zeXMvdWZzL2Zmcy9mZnNfdm5v cHMuYzo4NDEgKHNsZWVwIG11dGV4OnZtIHBhZ2UgcXVldWUgbXV0ZXgpCiAgICAgNjk4ICAgICAg ICAgMCAgICAgICAgNzQ2MCAgICAgICAgICAgMCAgICAgICAgICA1MiAgICAxNDMgICAgICAwICAw ICAgICAgMCAvdXNyL3NyYy9zeXMvdm0vdm1fb2JqZWN0LmM6MTc2MyAoc2xlZXAgbXV0ZXg6dm0g b2JqZWN0X2xpc3QpCiAgICAxNzgzICAgICAgICAgMCAgICAgICAyODE1NyAgICAgICAgICAgMCAg ICAgICAgICAzNyAgICA3NjEgICAgICAwICAwICAgICAgMCAvdXNyL3NyYy9zeXMvdm0vdm1fZ2x1 ZS5jOjM2NCAoc2xlZXAgbXV0ZXg6dm0gb2JqZWN0KQogICAgIDEyMCAgICAgICAgIDAgICAgICAg ICA1ODUgICAgICAgICAgIDAgICAgICAgICAgIDcgICAgIDgzICAgICAgMCAgMCAgICAgIDAgL3Vz ci9zcmMvc3lzL3ZtL3VtYV9jb3JlLmM6NDEwIChzbGVlcCBtdXRleDpORlNNT1VOVCkKICAgIDIx NjggICAgICAgICAwICAgICAgIDQwMDcwICAgICAgICAgICAwICAgICAgICAgIDYyICAgIDY0NiAg ICAgIDAgIDAgICAgICAwIC91c3Ivc3JjL3N5cy9hbWQ2NC9hbWQ2NC9wbWFwLmM6MzIwNyAoc2xl ZXAgbXV0ZXg6cG1hcCkKICAgICA0NzQgICAgICAgICAwICAgICAgICAyODA1ICAgICAgICAgICAw ICAgICAgICAgIDQ2ICAgICA2MCAgICAgIDAgIDAgICAgICAwIC91c3Ivc3JjL3N5cy9rZXJuL2tl cm5fc2lnLmM6MzE1OSAoc2xlZXAgbXV0ZXg6c2lnYWN0cykKICAgIDY5NTYgICAgIDE4MTkxICAg ICAxNTExNDQxICAgICAgNDAyMzgyICAgICAgICAzMTY5ICAgIDQ3NiAgICAxMjYgIDAgICAgMjI4 IC91c3Ivc3JjL3N5cy92bS92bV9mYXVsdC5jOjEwMDcgKHNsZWVwIG11dGV4OnZtIG9iamVjdCkK ICAgIDEzMjMgICAgICAgICAwICAgICAgICA1NzU2ICAgICAgICAgICAwICAgICAgICAgIDIyICAg IDI2MSAgICAgIDAgIDAgICAgICAwIC91c3Ivc3JjL3N5cy91ZnMvZmZzL2Zmc192ZnNvcHMuYzox ODEwIChzbGVlcCBtdXRleDpidWZvYmogaW50ZXJsb2NrKQogICAgMTU3MyAgICAgICA4NTkgICAg ICAxMjY1MjAgICAgICAgIDY5NjYgICAgICAgICA1NzUgICAgMjIwICAgICAxMiAgMCAgICAgMjMg L3Vzci9zcmMvc3lzL3ZtL3ZtX2ZhdWx0LmM6MTAxNCAoc2xlZXAgbXV0ZXg6dm0gb2JqZWN0KQog ICAgIDQ1OSAgICAgICAgIDAgICAgICAgIDE0MDggICAgICAgICAgIDAgICAgICAgICAgMTMgICAg MTA4ICAgICAgMCAgMCAgICAgIDAgL3Vzci9zcmMvc3lzL2tlcm4va2Vybl9zaWcuYzozMTY5IChz bGVlcCBtdXRleDpzaWdhY3RzKQogICAgIDQ1OCAgICAgICAgIDAgICAgICAgIDE4NzQgICAgICAg ICAgIDAgICAgICAgICAgMTMgICAgMTQ0ICAgICAgMCAgMCAgICAgIDAgL3Vzci9zcmMvc3lzL2tl cm4va2Vybl9kZXNjcmlwLmM6NDQzIChzeDpmaWxlZGVzYyBzdHJ1Y3R1cmUpCiAgICAgOTg3ICAg ICAgICAgMCAgICAgIDI3Mjc5MyAgICAgICAgICAgMCAgICAgICAgMjA5OSAgICAxMjkgICAgICAw ICAwICAgICAgMCAvdXNyL3NyYy9zeXMvYW1kNjQvYW1kNjQvcG1hcC5jOjMyMzYgKHNsZWVwIG11 dGV4OnBtYXApCiAgICAgNzM3ICAgICAgNzc1OCAgICAgICAyNTcwOSAgICAgIDEzMjAxMCAgICAg ICAgIDMyMyAgICAgNzkgICAgNDA4ICAwICAgICAzMyAvdXNyL3NyYy9zeXMva2Vybi9zeXNfZ2Vu ZXJpYy5jOjEzMTAgKHNsZWVwIG11dGV4OnNsZWVwIG10eHBvb2wpCiAgICAgNDkwICAgICAgICAg MCAgICAgICAgMzQyMiAgICAgICAgICAgMCAgICAgICAgICAyNiAgICAxMzEgICAgICAwICAwICAg ICAgMCAvdXNyL3NyYy9zeXMvdm0vdW1hX2NvcmUuYzo5MTQgKHNsZWVwIG11dGV4OlVNQSBTbGFi cykKICAgICA2MzEgICAgICAgICAwICAgICAgICA2NDcxICAgICAgICAgICAwICAgICAgICAgIDQ3 ICAgIDEzNyAgICAgIDAgIDAgICAgICAwIC91c3Ivc3JjL3N5cy91ZnMvdWZzL3Vmc192bm9wcy5j OjY2OCAoc2xlZXAgbXV0ZXg6dm5vZGUgaW50ZXJsb2NrKQogICAgIDc1NiAgICAgICAgIDAgICAg ICAgICA3NTYgICAgICAgICAgIDAgICAgICAgICAgIDEgICAgNzU2ICAgICAgMCAgMCAgICAgIDAg L3Vzci9zcmMvc3lzL3Vmcy9mZnMvZmZzX3Zmc29wcy5jOjE4NTQgKHNsZWVwIG11dGV4OmJ1Zm9i aiBpbnRlcmxvY2spCiAgICAgNjMxICAgICAgICAgMCAgICAgICAxMjcwNSAgICAgICAgICAgMCAg ICAgICAgIDEyNyAgICAxMDAgICAgICAwICAwICAgICAgMCAvdXNyL3NyYy9zeXMvdm0vdm5vZGVf cGFnZXIuYzoxMTAgKHNsZWVwIG11dGV4OnZtIG9iamVjdCkKICAgICAgIDUgICAgICAgICAwICAg ICAgICAgICA5ICAgICAgICAgICAwICAgICAgICAgICAyICAgICAgNCAgICAgIDAgIDAgICAgICAw IC91c3Ivc3JjL3N5cy9rZXJuL2tlcm5fcHJvYy5jOjYwNSAoc2xlZXAgbXV0ZXg6cHJvY2VzcyBs b2NrKQogICAgMjIwOSAgICAgICAgIDAgICAgICAgMTMyMDggICAgICAgICAgIDAgICAgICAgICAg MjcgICAgNDg5ICAgICAgMCAgMCAgICAgIDAgL3Vzci9zcmMvc3lzL2tlcm4va2Vybl9leGVjLmM6 OTEyIChzbGVlcCBtdXRleDp2bSBvYmplY3QpCiAgICAyNzk3ICAgICAgIDE2MiAgICAgICAzOTE1 MSAgICAgICAgIDE2MiAgICAgICAgIDEyNyAgICAzMDggICAgICAxICAwICAgICAgMSAvdXNyL3Ny Yy9zeXMva2Vybi9zeXNfZ2VuZXJpYy5jOjE0MTEgKHNsZWVwIG11dGV4OnNlbGxjaykKICAgICA5 NDUgICAgICAgICAwICAgICAgICAxOTU4ICAgICAgICAgICAwICAgICAgICAgICA3ICAgIDI3OSAg ICAgIDAgIDAgICAgICAwIC91c3Ivc3JjL3N5cy92bS91bWFfY29yZS5jOjQxMCAoc2xlZXAgbXV0 ZXg6dWRwY2IpCiAgICA4NzMzICAgICAxMDcxNSAgICAgMzEwOTcwNSAgICAgMTIyOTY3NiAgICAg ICAgMTMzMyAgIDIzMzIgICAgOTIyICAwICAgIDM0MiAvdXNyL3NyYy9zeXMvZGV2L3VzYjIvY29y ZS91c2IyX3RyYW5zZmVyLmM6MTgwOSAoc2xlZXAgbXV0ZXg6VVNCIGRldmljZSBtdXRleCkKICAg ICA5MzQgICAgICAgIDM5ICAgICAgIDMxNzU1ICAgICAgICAgIDM5ICAgICAgICAgMzIwICAgICA5 OSAgICAgIDAgIDAgICAgICAxIC91c3Ivc3JjL3N5cy9rZXJuL3N5c19nZW5lcmljLmM6MTM1NSAo c2xlZXAgbXV0ZXg6c2xlZXAgbXR4cG9vbCkKICAgIDUyMTAgICAgICA4MDUyICAgICAgNzUzMDcw ICAgICAxMTkxMTMxICAgICAgICAxMDY2ICAgIDcwNiAgIDExMTcgIDAgICAgNzEyIC91c3Ivc3Jj L3N5cy9rZXJuL2tlcm5fbXV0ZXguYzoxMzcgKHNsZWVwIG11dGV4OmVoY2kwKQogICAgMTc4MCAg ICAgICAgIDAgICAgICAgNDY2OTQgICAgICAgICAgIDAgICAgICAgICAxNTkgICAgMjkzICAgICAg MCAgMCAgICAgIDAgL3Vzci9zcmMvc3lzL2tlcm4vc3lzX2dlbmVyaWMuYzoxNDQ1IChzbGVlcCBt dXRleDpzZWxsY2spCiAgIDEwMjM3ICAgICAgICAgMCAgICAgICAxMDIzNyAgICAgICAgICAgMCAg ICAgICAgICAgMSAgMTAyMzcgICAgICAwICAwICAgICAgMCAvdXNyL3NyYy9zeXMva2Vybi92ZnNf ZGVmYXVsdC5jOjQ3OCAobG9ja21ncjpidWZ3YWl0KQogICAgNTU1OCAgICAgICAzNzEgICAgICAz NDc1NjAgICAgICAgICAzOTggICAgICAgIDEzNDIgICAgMjU4ICAgICAgMCAgMCAgICAgIDIgL3Vz ci9zcmMvc3lzL2tlcm4vc3lzX2dlbmVyaWMuYzoxNDAyIChzbGVlcCBtdXRleDpzbGVlcCBtdHhw b29sKQogICAgIDYyNiAgICAgICAgIDAgICAgICAgIDE0NDcgICAgICAgICAgIDAgICAgICAgICAg IDcgICAgMjA2ICAgICAgMCAgMCAgICAgIDAgL3Vzci9zcmMvc3lzL3ZtL3VtYV9jb3JlLmM6NDEw IChzbGVlcCBtdXRleDoyNTYpCiAgICAgNjI0ICAgICAgICAgMCAgICAgICAgNjIwMCAgICAgICAg ICAgMCAgICAgICAgICA0NiAgICAxMzQgICAgICAwICAwICAgICAgMCAvdXNyL3NyYy9zeXMva2Vy bi9rZXJuX2V4aXQuYzo0MDkgKHN4OmFsbHByb2MpCiAgICAgNjIwICAgICAgICAgMCAgICAgICAg NDQ1OSAgICAgICAgICAgMCAgICAgICAgICAzNCAgICAxMzEgICAgICAwICAwICAgICAgMCAvdXNy L3NyYy9zeXMvdm0vdm5vZGVfcGFnZXIuYzoyMDcgKHNsZWVwIG11dGV4OnZtIG9iamVjdCkKICAg ICAxMDkgICAgICAgICAwICAgICAgICAgNTk4ICAgICAgICAgICAwICAgICAgICAgICA3ICAgICA4 NSAgICAgIDAgIDAgICAgICAwIC91c3Ivc3JjL3N5cy92bS91bWFfY29yZS5jOjQxMCAoc2xlZXAg bXV0ZXg6c2N0cF9yYWRkcikKICAgMTM4NjUgICAgICAgICAwICAgICAyNzY4NjE3ICAgICAgICAg ICAwICAgICAgICAzMTE2ICAgIDg4OCAgICAgIDAgIDAgICAgICAwIC91c3Ivc3JjL3N5cy9rZXJu L3Zmc19iaW8uYzozNzYyIChzbGVlcCBtdXRleDpzbGVlcCBtdHhwb29sKQogICAgMTU3OCAgICAg ICA2NTIgICAgICA2NjkyNzQgICAgICAgICA5MzggICAgICAgIDMxMTYgICAgMjE0ICAgICAgMCAg MCAgICAgIDIgL3Vzci9zcmMvc3lzL2tlcm4vdmZzX2Jpby5jOjM3NzQgKHNsZWVwIG11dGV4OnNs ZWVwIG10eHBvb2wpCiAgICAyMzYzICAgICAgIDI2NSAgICAgICAxODQ0NSAgICAgICAgIDY4MyAg ICAgICAgICA4MSAgICAyMjcgICAgICA4ICAwICAgICAgNCAvdXNyL3NyYy9zeXMva2Vybi90dHku YzoxNTggKHNsZWVwIG11dGV4OnR0eW10eCkKICAgICA0OTAgICAgICAgICAwICAgICAgIDExNDMy ICAgICAgICAgICAwICAgICAgICAgIDk2ICAgIDExOSAgICAgIDAgIDAgICAgICAwIC91c3Ivc3Jj L3N5cy9rZXJuL3Zmc192bm9wcy5jOjUyMyAoc2xlZXAgbXV0ZXg6c2xlZXAgbXR4cG9vbCkKICAg ICA2OTIgICAgICAgICAwICAgICAgICAxMTgxICAgICAgICAgICAwICAgICAgICAgICA3ICAgIDE2 OCAgICAgIDAgIDAgICAgICAwIC91c3Ivc3JjL3N5cy92bS91bWFfY29yZS5jOjQxMCAoc2xlZXAg bXV0ZXg6cGlwZSkKICAgICA4NDkgICAgICAgICAwICAgICAgIDI2NjU1ICAgICAgICAgICAwICAg ICAgICAgMTI5ICAgIDIwNiAgICAgIDAgIDAgICAgICAwIC91c3Ivc3JjL3N5cy92bS91bWFfY29y ZS5jOjI0NjQgKHNsZWVwIG11dGV4OjY0IEJ1Y2tldCkKICAgICA0MzMgICAgICAgICAwICAgICAg ICAgOTA4ICAgICAgICAgICAwICAgICAgICAgICA3ICAgIDEyOSAgICAgIDAgIDAgICAgICAwIC91 c3Ivc3JjL3N5cy92bS91bWFfY29yZS5jOjQxMCAoc2xlZXAgbXV0ZXg6dGNwdHcpCiAgICAgNTA3 ICAgICAgICAgMCAgICAgICAxMzcyNCAgICAgICAgICAgMCAgICAgICAgICA5NiAgICAxNDIgICAg ICAwICAwICAgICAgMCAvdXNyL3NyYy9zeXMva2Vybi92ZnNfdm5vcHMuYzo1NDUgKHNsZWVwIG11 dGV4OnNsZWVwIG10eHBvb2wpCiAgICAyMTA2ICAgICAgICAgMCAgICAgICAgMjEwNiAgICAgICAg ICAgMCAgICAgICAgICAgMSAgIDIxMDYgICAgICAwICAwICAgICAgMCAvdXNyL3NyYy9zeXMvdm0v dm1fbWFwLmM6MTY0MCAoc2xlZXAgbXV0ZXg6dm0gcGFnZSBxdWV1ZSBtdXRleCkKICAgICAxNjEg ICAgICAgICAwICAgICAgICAgMjk4ICAgICAgICAgICAwICAgICAgICAgICA0ICAgICA3NCAgICAg IDAgIDAgICAgICAwIC91c3Ivc3JjL3N5cy9rZXJuL3R0eS5jOjE1MDYgKHN4OnByb2N0cmVlKQog ICAgMTc1NCAgICAgICAgIDAgICAgICAgMjAwNjkgICAgICAgICAgIDAgICAgICAgICAgOTUgICAg MjExICAgICAgMCAgMCAgICAgIDAgL3Vzci9zcmMvc3lzL2tlcm4vdmZzX3N1YnIuYzozNDYgKHNs ZWVwIG11dGV4OnN0cnVjdCBtb3VudCBtdHgpCiAgICAgNDc4ICAgICAgICAgMCAgICAgICAgOTI3 NyAgICAgICAgICAgMCAgICAgICAgICA5OSAgICAgOTMgICAgICAwICAwICAgICAgMCAvdXNyL3Ny Yy9zeXMvdm0vdW1hX2NvcmUuYzoxOTkwIChzbGVlcCBtdXRleDpGaWxlcykKICAgIDIzNDMgICAg ICAgICAwICAgICAgIDU0MTg2ICAgICAgICAgICAwICAgICAgICAgIDYxICAgIDg4OCAgICAgIDAg IDAgICAgICAwIC91c3Ivc3JjL3N5cy92bS92bV9tYXAuYzoxNjUwIChzbGVlcCBtdXRleDp2bSBw YWdlIHF1ZXVlIG11dGV4KQogICAgIDcyMSAgICAgICAgIDAgICAgICAgIDEyMDggICAgICAgICAg IDAgICAgICAgICAgIDcgICAgMTcyICAgICAgMCAgMCAgICAgIDAgL3Vzci9zcmMvc3lzL3ZtL3Vt YV9jb3JlLmM6NDEwIChzbGVlcCBtdXRleDpVTUEgSGFzaCkKICAgICA0NTYgICAgICAgICAwICAg ICAgICAgOTc0ICAgICAgICAgICAwICAgICAgICAgICA3ICAgIDEzOSAgICAgIDAgIDAgICAgICAw IC91c3Ivc3JjL3N5cy92bS91bWFfY29yZS5jOjQxMCAoc2xlZXAgbXV0ZXg6QUNMIFVNQSB6b25l KQogICAgIDY3MCAgICAgICAgIDAgICAgICAgMTU2NjMgICAgICAgICAgIDAgICAgICAgICAgOTUg ICAgMTY0ICAgICAgMCAgMCAgICAgIDAgL3Vzci9zcmMvc3lzL2tlcm4vdmZzX3N1YnIuYzozODIg KHNsZWVwIG11dGV4OnN0cnVjdCBtb3VudCBtdHgpCiAgICAgOTI4ICAgICAgICAgMCAgICAgICAg NDY3NSAgICAgICAgICAgMCAgICAgICAgICAxNyAgICAyNzUgICAgICAwICAwICAgICAgMCAvdXNy L3NyYy9zeXMvbmV0aW5ldC90Y3BfdXNycmVxLmM6NzIxIChydzp0Y3BpbnApCiAxMzcwODU4ICAg ICAgICAgMCAgMTQ0MjgwNTU5MSAgICAgICAgICAgMCAgICAgMTYwMDAxNyAgICA5MDEgICAgICAw ICAwICAgICAgMCAvdXNyL3NyYy9zeXMva2Vybi9rZXJuX2Rlc2NyaXAuYzo3MTYgKHN4OmZpbGVk ZXNjIHN0cnVjdHVyZSkKICAgICA1NDYgICAgICAgICAwICAgICAgICAxMDU3ICAgICAgICAgICAw ICAgICAgICAgICA3ICAgIDE1MSAgICAgIDAgIDAgICAgICAwIC91c3Ivc3JjL3N5cy92bS91bWFf Y29yZS5jOjQxMCAoc2xlZXAgbXV0ZXg6UFJPQykKICAgICAxMjYgICAgICAgICAwICAgICAgICAg NTY0ICAgICAgICAgICAwICAgICAgICAgICA3ICAgICA4MCAgICAgIDAgIDAgICAgICAwIC91c3Iv c3JjL3N5cy92bS91bWFfY29yZS5jOjQxMCAoc2xlZXAgbXV0ZXg6UyBWRlMgQ2FjaGUpCiAgICAg OTQwICAgICAgICAgMCAgICAgICAxMzYyMSAgICAgICAgICAgMCAgICAgICAgIDEwNiAgICAxMjgg ICAgICAwICAwICAgICAgMCAvdXNyL3NyYy9zeXMva2Vybi92ZnNfYmlvLmM6MjI5NSAoc2xlZXAg bXV0ZXg6dm0gb2JqZWN0KQogICAgIDgxNCAgICAgIDQ0ODIgICAgICAgIDc1ODMgICAgICAgIDQ0 ODIgICAgICAgICAgNDYgICAgMTY0ICAgICA5NyAgMCAgICAgIDEgL3Vzci9zcmMvc3lzL2tlcm4v a2Vybl9leGl0LmM6MzAxIChzeDpwcm9jdHJlZSkKICAgIDEwMDEgICAgICAgICAwICAgICAgICA0 MjU4ICAgICAgICAgICAwICAgICAgICAgICA2ICAgIDcwOSAgICAgIDAgIDAgICAgICAwIC91c3Iv c3JjL3N5cy92bS92bV91bml4LmM6OTAgKHN4OnVzZXIgbWFwKQogICAgMTk5MyAgICAgICAgIDAg ICAgICAgNzU2ODYgICAgICAgICAgIDAgICAgICAgICAyMDIgICAgMzc0ICAgICAgMCAgMCAgICAg IDAgL3Vzci9zcmMvc3lzL2FtZDY0L2FtZDY0L3BtYXAuYzozNTI0IChzbGVlcCBtdXRleDpwbWFw KQogICAgMTgyMCAgICAgICAgIDAgICAgICAgNTExMzcgICAgICAgICAgIDAgICAgICAgICAyMDIg ICAgMjUzICAgICAgMCAgMCAgICAgIDAgL3Vzci9zcmMvc3lzL2FtZDY0L2FtZDY0L3BtYXAuYzoz NTI1IChzbGVlcCBtdXRleDpwbWFwKQogICAgMzkyNSAgICAgICAgIDAgICAgICAxODc4MjcgICAg ICAgICAgIDAgICAgICAgICA0MzYgICAgNDMwICAgICAgMCAgMCAgICAgIDAgL3Vzci9zcmMvc3lz L2FtZDY0L2FtZDY0L3BtYXAuYzozNTI3IChzbGVlcCBtdXRleDpwbWFwKQogICAgIDExOSAgICAg ICAgIDAgICAgICAgICA2MTAgICAgICAgICAgIDAgICAgICAgICAgIDcgICAgIDg3ICAgICAgMCAg MCAgICAgIDAgL3Vzci9zcmMvc3lzL3ZtL3VtYV9jb3JlLmM6NDEwIChzbGVlcCBtdXRleDpNb3Vu dHBvaW50cykKICAgIDM5MjcgICAgICAgICAwICAgICAgMTg4Mzg2ICAgICAgICAgICAwICAgICAg ICAgNDM2ICAgIDQzMiAgICAgIDAgIDAgICAgICAwIC91c3Ivc3JjL3N5cy9hbWQ2NC9hbWQ2NC9w bWFwLmM6MzUyOCAoc2xlZXAgbXV0ZXg6cG1hcCkKICAgICA3MTMgICAgICAgICAwICAgICAgICA1 NzkwICAgICAgICAgICAwICAgICAgICAgIDM3ICAgIDE1NiAgICAgIDAgIDAgICAgICAwIC91c3Iv c3JjL3N5cy91ZnMvZmZzL2Zmc192bm9wcy5jOjYwOSAoc2xlZXAgbXV0ZXg6dm5vZGUgaW50ZXJs b2NrKQogICAxMDgwMiAgICAgICA4MTIgICAgICAgNDM0NTkgICAgICAgICA4MTIgICAgICAgICAg MTkgICAyMjg3ICAgICA0MiAgMCAgICAgIDEgL3Vzci9zcmMvc3lzL25ldGluZXQvdGNwX3VzcnJl cS5jOjc3MiAocnc6dGNwaW5wKQogICAgIDQ3NCAgICAgICAgIDAgICAgICAgIDI3MzMgICAgICAg ICAgIDAgICAgICAgICAgNDYgICAgIDU5ICAgICAgMCAgMCAgICAgIDAgL3Vzci9zcmMvc3lzL2tl cm4va2Vybl9mb3JrLmM6NjExIChzbGVlcCBtdXRleDpzZXNzaW9uKQogICAgIDc5MSAgICAgICAg IDAgICAgICAgNDQxOTEgICAgICAgICAgIDAgICAgICAgICAyODQgICAgMTU1ICAgICAgMCAgMCAg ICAgIDAgL3Vzci9zcmMvc3lzL25ldGluZXQvaXBfaW5wdXQuYzoxMTQ1IChzbGVlcCBtdXRleDpp cHFsb2NrKQogICAgIDg0OCAgICAgICAgIDAgICAgICAgIDI0MjIgICAgICAgICAgIDAgICAgICAg ICAgMjIgICAgMTEwICAgICAgMCAgMCAgICAgIDAgL3Vzci9zcmMvc3lzL25ldGluZXQvaW4uYzox MTY2IChydzpsbGUpCiAgICAgODg2ICAgICAgICAgMCAgICAgICAgNDA3MyAgICAgICAgICAgMCAg ICAgICAgICAxMCAgICA0MDcgICAgICAwICAwICAgICAgMCAvdXNyL3NyYy9zeXMva2Vybi92ZnNf ZGVmYXVsdC5jOjQ2MCAoc2xlZXAgbXV0ZXg6YnVmb2JqIGludGVybG9jaykKICAgIDExOTEgICAg ICAgICAwICAgICAgICA2MDgyICAgICAgICAgICAwICAgICAgICAgIDIwICAgIDMwNCAgICAgIDAg IDAgICAgICAwIC91c3Ivc3JjL3N5cy9rZXJuL3Zmc19kZWZhdWx0LmM6NDkyIChzbGVlcCBtdXRl eDpidWZvYmogaW50ZXJsb2NrKQogICAgMjc2MSAgICAgIDQ0MjcgICAgICAgNTU5NjcgICAgICAg IDQ0MjcgICAgICAgICAgNDYgICAxMjE2ICAgICA5NiAgMCAgICAgIDEgL3Vzci9zcmMvc3lzL2tl cm4va2Vybl9leGl0LmM6NDI4IChzeDpwcm9jdHJlZSkKICAgIDczOTUgICAgICAgICAwICAgICAg MTI5NjMzICAgICAgICAgICAwICAgICAgICAgMTQzICAgIDkwNiAgICAgIDAgIDAgICAgICAwIC91 c3Ivc3JjL3N5cy9rZXJuL3Zmc19zdWJyLmM6Nzc4IChzbGVlcCBtdXRleDp2bm9kZV9mcmVlX2xp c3QpCiAgICAgOTA3ICAgICAgICAgMCAgICAgICAgMzY3MyAgICAgICAgICAgMCAgICAgICAgICAx NCAgICAyNjIgICAgICAwICAwICAgICAgMCAvdXNyL3NyYy9zeXMvdm0vdW1hX2NvcmUuYzo0MTAg KHNsZWVwIG11dGV4Om1idWYpCiAgICAgNDc4ICAgICAgICAgMCAgICAgICAgNDg3MiAgICAgICAg ICAgMCAgICAgICAgICA0NiAgICAxMDUgICAgICAwICAwICAgICAgMCAvdXNyL3NyYy9zeXMva2Vy bi9rZXJuX2V4aXQuYzoyMjAgKHNsZWVwIG11dGV4OnBfcGVlcnMpCiAgICAgNjA3ICAgICAgICAg MCAgICAgICAgMTkxMiAgICAgICAgICAgMCAgICAgICAgICAgNyAgICAyNzMgICAgICAwICAwICAg ICAgMCAvdXNyL3NyYy9zeXMvdm0vdW1hX2NvcmUuYzo0MTAgKHNsZWVwIG11dGV4OnNjdHBfY2h1 bmspCiAgIDM4NDE3ICAgICAgNzU2MiAgICAxMzE2NDE1NCAgICAgIDQ2OTMyNiAgICAgICAgNTc2 NiAgIDIyODMgICAgIDgxICAwICAgIDY4OSAvdXNyL3NyYy9zeXMva2Vybi9rZXJuX211dGV4LmM6 MTM3IChzbGVlcCBtdXRleDpHaWFudCkKICAgICA0NjMgICAgICAgICAwICAgICAgICAyNjU0ICAg ICAgICAgICAwICAgICAgICAgIDQ2ICAgICA1NyAgICAgIDAgIDAgICAgICAwIC91c3Ivc3JjL3N5 cy9rZXJuL2tlcm5fZm9yay5jOjYyOSAoc2xlZXAgbXV0ZXg6a3RyYWNlKQogICAgICA5MiAgICAg ICAgIDAgICAgICAgIDIwODQgICAgICAgICAgIDAgICAgICAgICAgNDcgICAgIDQ0ICAgICAgMCAg MCAgICAgIDAgL3Vzci9zcmMvc3lzL3ZtL3VtYV9jb3JlLmM6MTk5MCAoc2xlZXAgbXV0ZXg6NDA5 NikKICAgICA3MjYgICAgICAgICAwICAgICAgICAxNzE1ICAgICAgICAgICAwICAgICAgICAgICA3 ICAgIDI0NSAgICAgIDAgIDAgICAgICAwIC91c3Ivc3JjL3N5cy92bS91bWFfY29yZS5jOjQxMCAo c2xlZXAgbXV0ZXg6VU1BIEtlZ3MpCiAgICAgNTQ0ICAgICAgICAgMCAgICAgICAgNTMyNCAgICAg ICAgICAgMCAgICAgICAgICA0NiAgICAxMTUgICAgICAwICAwICAgICAgMCAvdXNyL3NyYy9zeXMv a2Vybi9rZXJuX2V4aXQuYzoyODkgKHNsZWVwIG11dGV4OnBfcGVlcnMpCiAgICAgOTM4ICAgICAg ICAgMCAgICAgICAgMzg2MyAgICAgICAgICAgMCAgICAgICAgICAxOSAgICAyMDMgICAgICAwICAw ICAgICAgMCAvdXNyL3NyYy9zeXMva2Vybi90dHlfb3V0cS5jOjI1NSAoc2xlZXAgbXV0ZXg6dHR5 bXR4KQogICAgIDU3OCAgICAgICAgIDAgICAgICAgIDEwNjcgICAgICAgICAgIDAgICAgICAgICAg IDcgICAgMTUyICAgICAgMCAgMCAgICAgIDAgL3Vzci9zcmMvc3lzL3ZtL3VtYV9jb3JlLmM6NDEw IChzbGVlcCBtdXRleDppbnBjYikKICAgMTU0OTggICAgIDEzMzk1ICAgICAzOTM0MjQxICAgICAg MzQzNzc2ICAgICAgIDI1MDE2ICAgIDE1NyAgICAgMTMgIDAgICAgNzc5IC91c3Ivc3JjL3N5cy92 bS91bWFfY29yZS5jOjE5OTAgKHNsZWVwIG11dGV4OmdfYmlvKQogICAgIDQ5MiAgICAgICAgIDAg ICAgICAgIDEzNDcgICAgICAgICAgIDAgICAgICAgICAgMTAgICAgMTM0ICAgICAgMCAgMCAgICAg IDAgL3Vzci9zcmMvc3lzL3ZtL3VtYV9jb3JlLmM6MjAzNCAoc2xlZXAgbXV0ZXg6NDA5NikKICAg MTQ4ODYgICAgICAgICAwICAgICAgMjU3MTI1ICAgICAgICAgICAwICAgICAgICAgIDU2ICAgNDU5 MSAgICAgIDAgIDAgICAgICAwIC91c3Ivc3JjL3N5cy9hbWQ2NC9hbWQ2NC9wbWFwLmM6MzgyMyAo c2xlZXAgbXV0ZXg6cG1hcCkKICAgIDEwNDMgICAgICAgICAwICAgICAgICAxODk1ICAgICAgICAg ICAwICAgICAgICAgICAzICAgIDYzMSAgICAgIDAgIDAgICAgICAwIC91c3Ivc3JjL3N5cy92bS92 bm9kZV9wYWdlci5jOjY3MyAoc2xlZXAgbXV0ZXg6dm0gb2JqZWN0KQogICAxNjIyNCAgICAgICAg IDAgICAgIDIxNTIxMTEgICAgICAgICAgIDAgICAgICAgIDEzMzkgICAxNjA3ICAgICAgMCAgMCAg ICAgIDAgL3Vzci9zcmMvc3lzL2dlb20vZ2VvbV9ldmVudC5jOjE4NSAoc3g6R0VPTSB0b3BvbG9n eSkKICAgIDEwODAgICAgICAgMTMzICAgICAgIDU2NTU4ICAgICAgICAgNDI5ICAgICAgICAgNDI0 ICAgIDEzMyAgICAgIDEgIDAgICAgICA0IC91c3Ivc3JjL3N5cy92bS91bWFfY29yZS5jOjIwMzQg KHNsZWVwIG11dGV4OmdfYmlvKQogICAgMTUzMiAgICAgICAgIDAgICAgICAgNTU4NDMgICAgICAg ICAgIDAgICAgICAgICAxNjkgICAgMzMwICAgICAgMCAgMCAgICAgIDAgL3Vzci9zcmMvc3lzL3Zt L3ZtX29iamVjdC5jOjM2OSAoc2xlZXAgbXV0ZXg6dm0gb2JqZWN0KQogICA4MDMzMSAgICAgICAg IDAgICA0Njk2NDc1MzMgICAgICAgICAgIDAgICAgIDE2MDAwNzQgICAgMjkzICAgICAgMCAgMCAg ICAgIDAgL3Vzci9zcmMvc3lzL2tlcm4va2Vybl9kZXNjcmlwLmM6MTA3NiAoc3g6ZmlsZWRlc2Mg c3RydWN0dXJlKQogICAgIDQzOSAgICAgICAgIDAgICAgICAgIDI2NzUgICAgICAgICAgIDAgICAg ICAgICAgMzcgICAgIDcyICAgICAgMCAgMCAgICAgIDAgL3Vzci9zcmMvc3lzL3ZtL3VtYV9jb3Jl LmM6MTk5MCAoc2xlZXAgbXV0ZXg6VEhSRUFEKQogICAgIDYzMSAgICAgICAgIDAgICAgICAgIDEx MzggICAgICAgICAgIDAgICAgICAgICAgIDcgICAgMTYyICAgICAgMCAgMCAgICAgIDAgL3Vzci9z cmMvc3lzL3ZtL3VtYV9jb3JlLmM6NDEwIChzbGVlcCBtdXRleDpMIFZGUyBDYWNoZSkKICAgIDY2 NzEgICAgICAgICAwICAgICAgMzAxNDM0ICAgICAgICAgICAwICAgICAgICAxMzM5ICAgIDIyNSAg ICAgIDAgIDAgICAgICAwIC91c3Ivc3JjL3N5cy9nZW9tL2dlb21fZXZlbnQuYzoyMzMgKHN4OkdF T00gdG9wb2xvZ3kpCiAgICAgNzkwICAgICAgICAgMCAgICAgICAgMjgxNCAgICAgICAgICAgMCAg ICAgICAgICAyMiAgICAxMjcgICAgICAwICAwICAgICAgMCAvdXNyL3NyYy9zeXMvbmV0aW5ldC9p Zl9ldGhlci5jOjI3NCAocnc6aWZfYWZkYXRhKQogICAgNTY2MCAgICAgICAgIDAgICAgICAgMzQz NTIgICAgICAgICAgIDAgICAgICAgICAxNDMgICAgMjQwICAgICAgMCAgMCAgICAgIDAgL3Vzci9z cmMvc3lzL2tlcm4va2Vybl9tdXRleC5jOjEzNyAoc2xlZXAgbXV0ZXg6YnVmZmVyIGRhZW1vbiBs b2NrKQogICAgIDg0NiAgICAgICAgIDAgICAgICAgIDEzMDcgICAgICAgICAgIDAgICAgICAgICAg IDcgICAgMTg2ICAgICAgMCAgMCAgICAgIDAgL3Vzci9zcmMvc3lzL3ZtL3VtYV9jb3JlLmM6NDEw IChzbGVlcCBtdXRleDpjcHVzZXQpCiAgICAgNDM2ICAgICAgICAgMCAgICAgICAgMTM1MiAgICAg ICAgICAgMCAgICAgICAgICAxMCAgICAxMzUgICAgICAwICAwICAgICAgMCAvdXNyL3NyYy9zeXMv dm0vdW1hX2NvcmUuYzoyMDM0IChzbGVlcCBtdXRleDpUSFJFQUQpCiAgICAgOTQxICAgICAgICAg MCAgICAgICAgNjQzNCAgICAgICAgICAgMCAgICAgICAgICA1MSAgICAxMjYgICAgICAwICAwICAg ICAgMCAvdXNyL3NyYy9zeXMvbmV0aW5ldC90Y3Bfb3V0cHV0LmM6MjgyIChzbGVlcCBtdXRleDpz b19zbmQpCiAgICA4NjUyICAgICAgICAgMCAgICAgIDMxMDU5NCAgICAgICAgICAgMCAgICAgICAg MTMzOSAgICAyMzEgICAgICAwICAwICAgICAgMCAvdXNyL3NyYy9zeXMvZ2VvbS9nZW9tX2V2ZW50 LmM6MTg3IChzbGVlcCBtdXRleDpHRU9NIG9ycGhhbmFnZSkKICAgIDEzNTcgICAgICAgICAwICAg ICAgIDEzNzcwICAgICAgICAgICAwICAgICAgICAgIDQ2ICAgIDI5OSAgICAgIDAgIDAgICAgICAw IC91c3Ivc3JjL3N5cy9rZXJuL2tlcm5fZm9yay5jOjYwMSAoc2xlZXAgbXV0ZXg6cHJvY2VzcyBn cm91cCkKICAgICA5MzYgICAgICAgICAwICAgICAgICA3NTg3ICAgICAgICAgICAwICAgICAgICAg IDI5ICAgIDI2MSAgICAgIDAgIDAgICAgICAwIC91c3Ivc3JjL3N5cy9rZXJuL2tlcm5fcHJvYy5j OjEyNjMgKHNsZWVwIG11dGV4OnByb2Nlc3MgbG9jaykKICAgIDY3NjMgICAgIDg5Nzk5ICAgICAx MTIzOTk4ICAgICAgODA0OTAxICAgICAgICAzNDgyICAgIDMyMiAgICAyMzEgIDAgICAgMTIyIC91 c3Ivc3JjL3N5cy92bS92bV9vYmplY3QuYzo0NDcgKHNsZWVwIG11dGV4OnZtIG9iamVjdCkKICAg MTUxNzQgICAgICAgICAwICAgICAgODgzNzQzICAgICAgICAgICAwICAgICAgICAxMzM5ICAgIDY2 MCAgICAgIDAgIDAgICAgICAwIC91c3Ivc3JjL3N5cy9nZW9tL2dlb21fZXZlbnQuYzoyMDEgKHNs ZWVwIG11dGV4OkdFT00gb3JwaGFuYWdlKQogICAgMTY3MSAgICAgICAgIDAgICAgICAgMjQzNDQg ICAgICAgICAgIDAgICAgICAgICAgNDYgICAgNTI5ICAgICAgMCAgMCAgICAgIDAgL3Vzci9zcmMv c3lzL2tlcm4va2Vybl9leGl0LmM6MTQ0IChzbGVlcCBtdXRleDpwcm9jZXNzIGxvY2spCiAgICAg NTY1ICAgICAgICAgMCAgICAgICAgMzc2NCAgICAgICAgICAgMCAgICAgICAgICA0NiAgICAgODEg ICAgICAwICAwICAgICAgMCAvdXNyL3NyYy9zeXMvdm0vdW1hX2NvcmUuYzoxOTkwIChzbGVlcCBt dXRleDpWTVNQQUNFKQogICAxNTEwMiAgICAgICAgIDAgICAgMTE0MTkzNDEgICAgICAgICAgIDAg ICAgICAgMjA0NzggICAgNTU3ICAgICAgMCAgMCAgICAgIDAgL3Vzci9zcmMvc3lzL2Rldi9kY29u cy9kY29uc19vcy5jOjIzMiAoc2xlZXAgbXV0ZXg6dHR5bXR4KQogICAgIDY0MiAgICAgICAgIDAg ICAgICAgIDY5NDcgICAgICAgICAgIDAgICAgICAgICAgNDYgICAgMTUxICAgICAgMCAgMCAgICAg IDAgL3Vzci9zcmMvc3lzL2tlcm4va2Vybl9kZXNjcmlwLmM6MTUxNyAoc2xlZXAgbXV0ZXg6ZmRl c2MpCiAgICAyMzMyICAgICAxMzg5MiAgICAgIDE0NzIwMCAgICAgIDMwMjQ4MiAgICAgICAgIDcx MCAgICAyMDcgICAgNDI2ICAwICAgIDEzNiAvdXNyL3NyYy9zeXMvZGV2L3VzYjIvY29yZS91c2Iy X3JlcXVlc3QuYzo0NzQgKHNsZWVwIG11dGV4OkdpYW50KQogICAyMjE4NyAgICAgICAgIDAgICAg ICAyMTkzMzUgICAgICAgICAgIDAgICAgICAgICAgNTIgICA0MjE3ICAgICAgMCAgMCAgICAgIDAg L3Vzci9zcmMvc3lzL3ZtL3ZtX29iamVjdC5jOjUwNiAoc2xlZXAgbXV0ZXg6dm0gb2JqZWN0KQog ICAgIDcwMCAgICAgICAgIDAgICAgICAgIDE2MDEgICAgICAgICAgIDAgICAgICAgICAgIDcgICAg MjI4ICAgICAgMCAgMCAgICAgIDAgL3Vzci9zcmMvc3lzL3ZtL3VtYV9jb3JlLmM6NDEwIChzbGVl cCBtdXRleDpTTEVFUFFVRVVFKQogICAgIDgwOCAgICAgICAgIDAgICAgICAgNjEyMTEgICAgICAg ICAgIDAgICAgICAgICA0NzggICAgMTI4ICAgICAgMCAgMCAgICAgIDAgL3Vzci9zcmMvc3lzL2tl cm4vc3Vicl9ldmVudGhhbmRsZXIuYzoyMTIgKHNsZWVwIG11dGV4OmV2ZW50aGFuZGxlcikKICAg IDE2MDQgICAgICAgICAwICAgICAgODM4NTcyICAgICAgICAgICAwICAgICAgICA2ODkzICAgIDEy MSAgICAgIDAgIDAgICAgICAwIC91c3Ivc3JjL3N5cy9hbWQ2NC9hbWQ2NC9wbWFwLmM6Mzk5NCAo c2xlZXAgbXV0ZXg6cG1hcCkKICAgICA4NTggICAgICAgNTk5ICAgICAgIDE3NDUxICAgICAgICAg NTk5ICAgICAgICAgIDk5ICAgIDE3NiAgICAgIDYgIDAgICAgICAxIC91c3Ivc3JjL3N5cy92bS91 bWFfY29yZS5jOjI1MjQgKHNsZWVwIG11dGV4OkZpbGVzKQogICAgIDU1OCAgICAgICAgIDAgICAg ICAgIDI4MzUgICAgICAgICAgIDAgICAgICAgICAgMTMgICAgMjE4ICAgICAgMCAgMCAgICAgIDAg L3Vzci9zcmMvc3lzL2tlcm4vc3Vicl9ldmVudGhhbmRsZXIuYzoyMTUgKHNsZWVwIG11dGV4OnBy b2Nlc3NfZXhlYykKICAgICA3NDEgICAgICAgICAwICAgICAgIDI3OTExICAgICAgICAgICAwICAg ICAgICAgMzUxICAgICA3OSAgICAgIDAgIDAgICAgICAwIC91c3Ivc3JjL3N5cy92bS91bWFfY29y ZS5jOjE5OTAgKHNsZWVwIG11dGV4OnNlbGZkKQogICAgIDQ1MSAgICAgICAgIDAgICAgICAgIDEw MjkgICAgICAgICAgIDAgICAgICAgICAgIDggICAgMTI4ICAgICAgMCAgMCAgICAgIDAgL3Vzci9z cmMvc3lzL3ZtL3VtYV9jb3JlLmM6MjAzNCAoc2xlZXAgbXV0ZXg6Vk1TUEFDRSkKICAgICA3NzIg ICAgICAgICAwICAgICAgICA4MjE2ICAgICAgICAgICAwICAgICAgICAgIDQ2ICAgIDE3OCAgICAg IDAgIDAgICAgICAwIC91c3Ivc3JjL3N5cy9rZXJuL3N5c3Zfc2VtLmM6MTI3NiAoc2xlZXAgbXV0 ZXg6c2VtdSkKICAgICA0NDcgICAgICAgICAwICAgICAgICAyNzQ0ICAgICAgICAgICAwICAgICAg ICAgIDMwICAgICA5MSAgICAgIDAgIDAgICAgICAwIC91c3Ivc3JjL3N5cy92bS91bWFfY29yZS5j OjkxNCAoc2xlZXAgbXV0ZXg6UFJPQykKICAgICA1NDEgICAgICAgICAwICAgICAgICAxMzUwICAg ICAgICAgICAwICAgICAgICAgICA3ICAgIDE5MiAgICAgIDAgIDAgICAgICAwIC91c3Ivc3JjL3N5 cy92bS91bWFfY29yZS5jOjQxMCAoc2xlZXAgbXV0ZXg6c3luY2FjaGUpCiAgICA3NzY2ICAgICAg ICAgMCAgICAgICA4MjQzNiAgICAgICAgICAgMCAgICAgICAgICAzMCAgIDI3NDcgICAgICAwICAw ICAgICAgMCAvdXNyL3NyYy9zeXMvdm0vdm1fbWFwLmM6MTI3MCAoc3g6dXNlciBtYXApCiAgICAg NzE2ICAgICAgICAgMCAgICAgICAgODQ5NyAgICAgICAgICAgMCAgICAgICAgICAzNiAgICAyMzYg ICAgICAwICAwICAgICAgMCAvdXNyL3NyYy9zeXMvZGV2L3VzYjIvY29udHJvbGxlci91c2IyX2Nv bnRyb2xsZXIuYzoyMjYgKHNsZWVwIG11dGV4Om9oY2kwKQogICAgIDc1MiAgICAgICAgIDAgICAg ICAgIDEyNTggICAgICAgICAgIDAgICAgICAgICAgIDcgICAgMTc5ICAgICAgMCAgMCAgICAgIDAg L3Vzci9zcmMvc3lzL3ZtL3VtYV9jb3JlLmM6NDEwIChzbGVlcCBtdXRleDpLTUFQIEVOVFJZKQog ICAgMTcxMSAgICAgICAgIDAgICAgICAxNTEzNTggICAgICAgICAgIDAgICAgICAgICA3MTAgICAg MjEzICAgICAgMCAgMCAgICAgIDAgL3Vzci9zcmMvc3lzL2Rldi91c2IyL2NvcmUvdXNiMl90cmFu c2Zlci5jOjI1NTAgKHNsZWVwIG11dGV4OlVTQiBkZXZpY2UgbXV0ZXgpCiAgICAxOTMyICAgICAg ICAgMCAgICAgICA0ODI2MSAgICAgICAgICAgMCAgICAgICAgICA5MCAgICA1MzYgICAgICAwICAw ICAgICAgMCAvdXNyL3NyYy9zeXMvdm0vdm1fbWFwLmM6MTI5OSAoc3g6dXNlciBtYXApCiAgICAg NDUyICAgICAgICAgMCAgICAgICAgMTM3NSAgICAgICAgICAgMCAgICAgICAgICAxMyAgICAxMDUg ICAgICAwICAwICAgICAgMCAvdXNyL3NyYy9zeXMva2Vybi9pbWdhY3RfZWxmLmM6NzcxIChzbGVl cCBtdXRleDpwcm9jZXNzIGxvY2spCiAgICAgNjI1ICAgICAgIDg2NSAgICAgICAgNjM4OSAgICAg ICAgIDg2NSAgICAgICAgICA0NiAgICAxMzggICAgIDE4ICAwICAgICAgMSAvdXNyL3NyYy9zeXMv a2Vybi9rZXJuX2V4aXQuYzoyNDQgKHNsZWVwIG11dGV4OnByb2Nlc3MgbG9jaykKICAgICA3Mjcg ICAgICAgICAwICAgICAgICAxNjYyICAgICAgICAgICAwICAgICAgICAgIDIyICAgICA3NSAgICAg IDAgIDAgICAgICAwIC91c3Ivc3JjL3N5cy9uZXRpbmV0L2lwX291dHB1dC5jOjY0MCAoc2xlZXAg bXV0ZXg6cnRlbnRyeSkKICAgICA1OTQgICAgICAgICAwICAgICAgICAxNTQ3ICAgICAgICAgICAw ICAgICAgICAgICA3ICAgIDIyMSAgICAgIDAgIDAgICAgICAwIC91c3Ivc3JjL3N5cy92bS91bWFf Y29yZS5jOjQxMCAoc2xlZXAgbXV0ZXg6TUFQIEVOVFJZKQogICAgIDU0NSAgICAgICAgIDAgICAg ICAgIDE0NDQgICAgICAgICAgIDAgICAgICAgICAgIDcgICAgMjA2ICAgICAgMCAgMCAgICAgIDAg L3Vzci9zcmMvc3lzL3ZtL3VtYV9jb3JlLmM6NDEwIChzbGVlcCBtdXRleDpzY3RwX3JlYWRxKQog ICAgIDg2NSAgICAgICAgIDAgICAgICAgMTM3OTcgICAgICAgICAgIDAgICAgICAgICAgNDUgICAg MzA2ICAgICAgMCAgMCAgICAgIDAgL3Vzci9zcmMvc3lzL2tlcm4va2Vybl9zaWcuYzo2NTQgKHNs ZWVwIG11dGV4OnByb2Nlc3MgbG9jaykKICAgICA4NDggICAgICAgICAwICAgICAgIDU2MzM0ICAg ICAgICAgICAwICAgICAgICAgMzQ5ICAgIDE2MSAgICAgIDAgIDAgICAgICAwIC91c3Ivc3JjL3N5 cy92bS92bV9vYmplY3QuYzo1NzYgKHNsZWVwIG11dGV4OnZtIG9iamVjdCkKICAgICA5NDUgICAg ICAxMDA1ICAgICAgIDk3MTQ0ICAgICAgIDE3Njc5ICAgICAgICAgODg5ICAgIDEwOSAgICAgMTkg IDAgICAgMTE0IC91c3Ivc3JjL3N5cy92bS92bV9mYXVsdC5jOjE0MSAoc2xlZXAgbXV0ZXg6dm0g cGFnZSBxdWV1ZSBtdXRleCkKICAgICA2MDAgICAgICAgICAwICAgICAgIDEwNjM0ICAgICAgICAg ICAwICAgICAgICAgIDg1ICAgIDEyNSAgICAgIDAgIDAgICAgICAwIC91c3Ivc3JjL3N5cy92bS92 bV9tbWFwLmM6Mjg0IChzbGVlcCBtdXRleDpwcm9jZXNzIGxvY2spCiAgICAgNjQyICAgICAgICAg MCAgICAgICAgMTE1MyAgICAgICAgICAgMCAgICAgICAgICAgNiAgICAxOTIgICAgICAwICAwICAg ICAgMCAvdXNyL3NyYy9zeXMvdWZzL2Zmcy9mZnNfc29mdGRlcC5jOjM3NjcgKHNsZWVwIG11dGV4 OlNvZnRkZXAgTG9jaykKICAgICA3ODkgICAgICAgICAwICAgICAgICAxNDk5ICAgICAgICAgICAw ICAgICAgICAgICAyICAgIDc0OSAgICAgIDAgIDAgICAgICAwIC91c3Ivc3JjL3N5cy92bS92bm9k ZV9wYWdlci5jOjkzNCAoc2xlZXAgbXV0ZXg6dm0gb2JqZWN0KQogICA0ODE0MSAgICAgICAgIDAg ICAgMTkxMTQ1MzEgICAgICAgICAgIDAgICAgICAgMTI3NDYgICAxNDk5ICAgICAgMCAgMCAgICAg IDAgL3Vzci9zcmMvc3lzL2tlcm4vdmZzX2Jpby5jOjI0NDMgKGxvY2ttZ3I6YnVmd2FpdCkKICAg ICA3MzQgICAgICAgICAwICAgICAgICAyMjMxICAgICAgICAgICAwICAgICAgICAgICA3ICAgIDMx OCAgICAgIDAgIDAgICAgICAwIC91c3Ivc3JjL3N5cy92bS91bWFfY29yZS5jOjQxMCAoc2xlZXAg bXV0ZXg6dHR5aW5xKQogICAgIDg2MiAgICAgICAgIDAgICAgICAgIDcwOTggICAgICAgICAgIDAg ICAgICAgICAgNDYgICAgMTU0ICAgICAgMCAgMCAgICAgIDAgL3Vzci9zcmMvc3lzL2tlcm4va2Vy bl9kZXNjcmlwLmM6MTcyMSAoc2xlZXAgbXV0ZXg6ZmRlc2MpCiAgIDEwMjU0ICAgICAgICAgMCAg ICAgICA5Nzc5MSAgICAgICAgICAgMCAgICAgICAgIDEyMiAgICA4MDEgICAgICAwICAwICAgICAg MCAvdXNyL3NyYy9zeXMva2Vybi9rZXJuX3N5c2N0bC5jOjE1MTAgKHN4OnN5c2N0bCBsb2NrKQog ICAgIDg0NyAgICAgICAgIDAgICAgICAgMTg2MjcgICAgICAgICAgIDAgICAgICAgICAxNDcgICAg MTI2ICAgICAgMCAgMCAgICAgIDAgL3Vzci9zcmMvc3lzL2tlcm4vdmZzX3Zub3BzLmM6OTY5IChz bGVlcCBtdXRleDpzdHJ1Y3QgbW91bnQgbXR4KQogICAgIDIwMyAgICAgICAyODIgICAgICAgIDQ5 NTcgICAgICAgICA4NTkgICAgICAgICAgMjcgICAgMTgzICAgICAzMSAgMCAgICAgIDcgL3Vzci9z cmMvc3lzL2tlcm4vc2NoZWRfdWxlLmM6ODA0IChzcGluIG11dGV4OnNjaGVkIGxvY2sgOSkKICAg ICAgOTMgICAgICAgMTk4ICAgICAgICAgNTQ2ICAgICAgICAgMTk4ICAgICAgICAgICA2ICAgICA5 MSAgICAgMzMgIDAgICAgICAxIC91c3Ivc3JjL3N5cy9rZXJuL3NjaGVkX3VsZS5jOjgwNyAoc3Bp biBtdXRleDpzY2hlZCBsb2NrIDkpCiAgICAgMTQ3ICAgICAgIDIyNSAgICAgICAgIDk3MyAgICAg ICAgIDU1OCAgICAgICAgICAgOSAgICAxMDggICAgIDYyICAwICAgICAgMyAvdXNyL3NyYy9zeXMv a2Vybi9zY2hlZF91bGUuYzoxMTE4IChzcGluIG11dGV4OnNjaGVkIGxvY2sgMjcpCiAgICAgMTE1 ICAgICAgICAgMCAgICAgICAxMjYwOCAgICAgICAgICAgMCAgICAgICAgIDE1MiAgICAgODIgICAg ICAwICAwICAgICAgMCAvdXNyL3NyYy9zeXMva2Vybi9zY2hlZF91bGUuYzo3OTMgKHNwaW4gbXV0 ZXg6c2NoZWQgbG9jayAwKQogICAgIDcxOSAgICAgICAgIDAgICAgICAgMjgzNzkgICAgICAgICAg IDAgICAgICAgICAxMzEgICAgMjE2ICAgICAgMCAgMCAgICAgIDAgL3Vzci9zcmMvc3lzL2tlcm4v c2NoZWRfdWxlLmM6ODAzIChzcGluIG11dGV4OnNjaGVkIGxvY2sgMCkKICAgICA3NzYgICAgICAg NjcyICAgICAgIDUwMzE4ICAgICAgIDE3NDQ4ICAgICAgICAgMjIzICAgIDIyNSAgICAgNzggIDAg ICAgMTAzIC91c3Ivc3JjL3N5cy9rZXJuL3NjaGVkX3VsZS5jOjgwNiAoc3BpbiBtdXRleDpzY2hl ZCBsb2NrIDApCiAgICAgMTMwICAgICAgICAgMCAgICAgICAgIDUxNiAgICAgICAgICAgMCAgICAg ICAgICAgOCAgICAgNjQgICAgICAwICAwICAgICAgMCAvdXNyL3NyYy9zeXMva2Vybi9rZXJuX3Vt dHguYzozMzYwIChzcGluIG11dGV4OnNjaGVkIGxvY2sgMCkKICAgICAgODIgICAgICAgMTQ0ICAg ICAgICAgNzg5ICAgICAgICAgMzAzICAgICAgICAgIDI4ICAgICAyOCAgICAgMTAgIDAgICAgICAz IC91c3Ivc3JjL3N5cy9rZXJuL3NjaGVkX3VsZS5jOjExMTggKHNwaW4gbXV0ZXg6c2NoZWQgbG9j ayAxOCkKICAgICAxODkgICAgICAgICAwICAgICAgICAgMzc3ICAgICAgICAgICAwICAgICAgICAg ICAyICAgIDE4OCAgICAgIDAgIDAgICAgICAwIC91c3Ivc3JjL3N5cy9rZXJuL3NjaGVkX3VsZS5j OjgwNCAoc3BpbiBtdXRleDpzY2hlZCBsb2NrIDIzKQogICAgICA5MSAgICAgICAgIDAgICAgICAg ICAxODAgICAgICAgICAgIDAgICAgICAgICAgIDIgICAgIDkwICAgICAgMCAgMCAgICAgIDAgL3Vz ci9zcmMvc3lzL2tlcm4va2Vybl9zaWcuYzo1OTMgKHNwaW4gbXV0ZXg6c2NoZWQgbG9jayAwKQog ICAgIDE3NyAgICAgICAxNjkgICAgICAgMjIzODkgICAgICAgIDEzNTUgICAgICAgICAyMDYgICAg MTA4ICAgICAgNiAgMCAgICAgMTIgL3Vzci9zcmMvc3lzL2tlcm4vc2NoZWRfdWxlLmM6MTExOCAo c3BpbiBtdXRleDpzY2hlZCBsb2NrIDkpCiAgIDExMzg3ICAgICAgICAgMCAgICAgICA0NzMxNiAg ICAgICAgICAgMCAgICAgICAgICA3MiAgICA2NTcgICAgICAwICAwICAgICAgMCAvdXNyL3NyYy9z eXMvYW1kNjQvYW1kNjQvbXBfbWFjaGRlcC5jOjg1OCAoc3BpbiBtdXRleDpzbXAgcmVuZGV6dm91 cykKICAgICAgIDkgICAgICAgICAwICAgICAgICAgICA5ICAgICAgICAgICAwICAgICAgICAgICAx ICAgICAgOSAgICAgIDAgIDAgICAgICAwIC91c3Ivc3JjL3N5cy9rZXJuL3NjaGVkX3VsZS5jOjIw NjIgKHNwaW4gbXV0ZXg6c2NoZWQgbG9jayA4KQogICAgMTk2OCAgICAgIDEzMjUgICAgICAxMDMx NDEgICAgICAgIDEzOTcgICAgICAgICA1MDYgICAgMjAzICAgICAgMiAgMCAgICAgIDMgL3Vzci9z cmMvc3lzL2FtZDY0L2FtZDY0L21wX21hY2hkZXAuYzo4OTUgKHNwaW4gbXV0ZXg6c21wIHJlbmRl enZvdXMpCiAgICAgMTc1ICAgICAgIDEwMCAgICAgICAgIDE3NSAgICAgICAgIDEwMCAgICAgICAg ICAgMSAgICAxNzUgICAgMTAwICAwICAgICAgMSAvdXNyL3NyYy9zeXMva2Vybi9rZXJuX3NpZy5j OjIyNTEgKHNwaW4gbXV0ZXg6c2NoZWQgbG9jayAxMikKICAgICAxODkgICAgICAgMjQxICAgICAg ICAxMjYyICAgICAgICAgMjQxICAgICAgICAgICA3ICAgIDE4MCAgICAgMzQgIDAgICAgICAxIC91 c3Ivc3JjL3N5cy9rZXJuL3NjaGVkX3VsZS5jOjgwNCAoc3BpbiBtdXRleDpzY2hlZCBsb2NrIDE0 KQogICAgIDQ4NiAgICAgICAxODAgICAgICAgIDI5NzQgICAgICAgICA0MDMgICAgICAgICAgIDgg ICAgMzcxICAgICA1MCAgMCAgICAgIDMgL3Vzci9zcmMvc3lzL2tlcm4vc2NoZWRfdWxlLmM6ODA2 IChzcGluIG11dGV4OnNjaGVkIGxvY2sgMTQpCiAgICAgMTg0ICAgICAgIDU3MSAgICAgMTkzMzEw NCAgICAgICAzMDI3MyAgICAgICAyMTU4MiAgICAgODkgICAgICAxICAwICAgIDE5OCAvdXNyL3Ny Yy9zeXMva2Vybi9rZXJuX2ludHIuYzo4MDAgKHNwaW4gbXV0ZXg6c2NoZWQgbG9jayAwKQogICAg IDE5MCAgICAgICA3NTAgICAgICAzNTUzMjEgICAgICAgOTUwODggICAgICAgIDM3ODEgICAgIDkz ICAgICAyNSAgMCAgICA2NTMgL3Vzci9zcmMvc3lzL2tlcm4vc2NoZWRfdWxlLmM6MTExOCAoc3Bp biBtdXRleDpzY2hlZCBsb2NrIDApCiAgICAyMzYwICAgICAgICAgMCAgICAgIDgyODE3NiAgICAg ICAgICAgMCAgICAgICAgIDY3OCAgIDEyMjEgICAgICAwICAwICAgICAgMCAvdXNyL3NyYy9zeXMv a2Vybi9zdWJyX3R1cm5zdGlsZS5jOjU1NiAoc3BpbiBtdXRleDp0dXJuc3RpbGUgbG9jaykKICAg IDIzMDYgICAgICAgNDMzICAgICAgNjY0OTQxICAgICAgICAyOTM4ICAgICAgICAgNjA1ICAgMTA5 OSAgICAgIDQgIDAgICAgIDEyIC91c3Ivc3JjL3N5cy9rZXJuL3N1YnJfdHVybnN0aWxlLmM6NTk0 IChzcGluIG11dGV4OnR1cm5zdGlsZSBsb2NrKQogICAgIDE4MSAgICAgICAgIDAgICAgICAgICA1 MzUgICAgICAgICAgIDAgICAgICAgICAgIDMgICAgMTc4ICAgICAgMCAgMCAgICAgIDAgL3Vzci9z cmMvc3lzL2tlcm4va2Vybl9zaWcuYzoyMjUxIChzcGluIG11dGV4OnNjaGVkIGxvY2sgMykKICAg ICAyMjkgICAgICAgMTc4ICAgICAgICA2OTM4ICAgICAgICAgNTU1ICAgICAgICAgIDM3ICAgIDE4 NyAgICAgMTUgIDAgICAgICA1IC91c3Ivc3JjL3N5cy9rZXJuL3NjaGVkX3VsZS5jOjgwNCAoc3Bp biBtdXRleDpzY2hlZCBsb2NrIDUpCiAgICAgNjg2ICAgICAgIDI1NyAgICAgICAgMjY3MiAgICAg ICAgIDc3OCAgICAgICAgICAgNiAgICA0NDUgICAgMTI5ICAwICAgICAgNCAvdXNyL3NyYy9zeXMv a2Vybi9zY2hlZF91bGUuYzo4MDYgKHNwaW4gbXV0ZXg6c2NoZWQgbG9jayA1KQogICAgICA5NiAg ICAgICAgIDAgICAgICAgMTExNDkgICAgICAgICAgIDAgICAgICAgICAxMjYgICAgIDg4ICAgICAg MCAgMCAgICAgIDAgL3Vzci9zcmMvc3lzL2tlcm4vc3Vicl90dXJuc3RpbGUuYzo3MjcgKHNwaW4g bXV0ZXg6c2NoZWQgbG9jayAwKQogICAgMTA2NiAgICAgICAgIDAgICAgICAgMzM0ODYgICAgICAg ICAgIDAgICAgICAgICAgNDYgICAgNzI3ICAgICAgMCAgMCAgICAgIDAgL3Vzci9zcmMvc3lzL2tl cm4va2Vybl9leGl0LmM6NTQ4IChzcGluIG11dGV4OnByb2Nlc3Mgc2xvY2spCiAgICAgIDg5ICAg ICAgICAgMCAgICAgICAgIDI2NSAgICAgICAgICAgMCAgICAgICAgICAgMyAgICAgODggICAgICAw ICAwICAgICAgMCAvdXNyL3NyYy9zeXMva2Vybi9rZXJuX2ludHIuYzo4MDAgKHNwaW4gbXV0ZXg6 dHVybnN0aWxlIGxvY2spCiAgICAgMTU1ICAgICAgIDIyMSAgICAgICAgIDkxNiAgICAgICAgIDIy MSAgICAgICAgICAgOCAgICAxMTQgICAgIDI3ICAwICAgICAgMSAvdXNyL3NyYy9zeXMva2Vybi9z Y2hlZF91bGUuYzoxMTE4IChzcGluIG11dGV4OnNjaGVkIGxvY2sgMjMpCiAgIDE2MTkzICAgICAg ICAgMCAgICAgODg1MzQ1MiAgICAgICAgICAgMCAgICAgICAgMzE5NSAgIDI3NzEgICAgICAwICAw ICAgICAgMCAvdXNyL3NyYy9zeXMvZGV2L3N5c2NvbnMvc3lzY29ucy5jOjE3ODQgKHNwaW4gbXV0 ZXg6c3lzY29ucyB2aWRlbyBsb2NrKQogICAgNDQ1OCAgICAgMTc5MzMgICAgMjY4MDA3MDEgICAg IDE1MjA4MjggICAgICAgOTM3OTAgICAgMjg1ICAgICAxNiAgMCAgIDMxNDkgL3Vzci9zcmMvc3lz L2tlcm4vc3Vicl9zbGVlcHF1ZXVlLmM6MjM2IChzcGluIG11dGV4OnNsZWVwcSBjaGFpbikKICAg ICA1MTYgICAgICAgICAwICAgICAgIDQ5NjQwICAgICAgICAgICAwICAgICAgICAgMTg3ICAgIDI2 NSAgICAgIDAgIDAgICAgICAwIC91c3Ivc3JjL3N5cy9rZXJuL3N1YnJfdHVybnN0aWxlLmM6ODg5 IChzcGluIG11dGV4OnNjaGVkIGxvY2sgMCkKICAgICAxNzMgICAgICAgNDQxICAgICAgNTcxMDI1 ICAgICAgMTM0MjQxICAgICAgICA3ODA4ICAgICA3MyAgICAgMTcgIDAgICAxMjIzIC91c3Ivc3Jj L3N5cy9rZXJuL2tlcm5faW50ci5jOjgwMCAoc3BpbiBtdXRleDpzY2hlZCBsb2NrIDE0KQogICAg IDE1NyAgICAgICAyNjggICAgICAgMTA2NjIgICAgICAgIDM4NTMgICAgICAgICAgOTUgICAgMTEy ICAgICA0MCAgMCAgICAgMjQgL3Vzci9zcmMvc3lzL2tlcm4vc2NoZWRfdWxlLmM6MTExOCAoc3Bp biBtdXRleDpzY2hlZCBsb2NrIDE0KQogICAgIDIyNyAgICAgICAyNDYgICAgICAgMTQ4NTQgICAg ICAgIDQwNzQgICAgICAgICAgODQgICAgMTc2ICAgICA0OCAgMCAgICAgMjggL3Vzci9zcmMvc3lz L2tlcm4vc2NoZWRfdWxlLmM6ODA0IChzcGluIG11dGV4OnNjaGVkIGxvY2sgMTkpCiAgICAgMTg5 ICAgICAgIDQzMSAgICAgICA0MTI3OSAgICAgICAxNjEwNSAgICAgICAgIDQ0OSAgICAgOTEgICAg IDM1ICAwICAgIDEzOCAvdXNyL3NyYy9zeXMva2Vybi9rZXJuX2ludHIuYzo4MDAgKHNwaW4gbXV0 ZXg6c2NoZWQgbG9jayA1KQogICAgIDE5NSAgICAgICA0MjYgICAgICAgNDE4NzkgICAgICAgMTc0 NDcgICAgICAgICA0NDQgICAgIDk0ICAgICAzOSAgMCAgICAxMTYgL3Vzci9zcmMvc3lzL2tlcm4v c2NoZWRfdWxlLmM6MTExOCAoc3BpbiBtdXRleDpzY2hlZCBsb2NrIDUpCiAgICAgMTM0ICAgICAg MTA4MCAgICAgIDQ1NzIwMyAgICAgICAgNDE1OCAgICAgICAgNTE1OSAgICAgODggICAgICAwICAw ICAgICAxNCAvdXNyL3NyYy9zeXMva2Vybi9rZXJuX2ludHIuYzoxMjM5IChzcGluIG11dGV4OnNj aGVkIGxvY2sgMCkKICAgICAxMjAgICAgICAgNTMzICAgICAgICAxNzY2ICAgICAgICAgNzc0ICAg ICAgICAgIDE5ICAgICA5MiAgICAgNDAgIDAgICAgICAzIC91c3Ivc3JjL3N5cy9rZXJuL3N1YnJf dHVybnN0aWxlLmM6MjAzIChzcGluIG11dGV4OnNjaGVkIGxvY2sgMSkKICAgICAxODggICAgICAg Mjg4ICAgICAgICA0MDcwICAgICAgICAxNTU4ICAgICAgICAgIDIzICAgIDE3NiAgICAgNjcgIDAg ICAgICA4IC91c3Ivc3JjL3N5cy9rZXJuL3NjaGVkX3VsZS5jOjgwNCAoc3BpbiBtdXRleDpzY2hl ZCBsb2NrIDEwKQogICAgMjQ5MiAgICAgIDE3MTkgICAgICA4MTA0MTIgICAgICAgIDQ3MzggICAg ICAgICA2MDUgICAxMzM5ICAgICAgNyAgMCAgICAgIDUgL3Vzci9zcmMvc3lzL2tlcm4vc3Vicl90 dXJuc3RpbGUuYzo1MzcgKHNwaW4gbXV0ZXg6dHVybnN0aWxlIGNoYWluKQogICAgMTE2NSAgICAg MTI3MDggICAgICA0NzAzNjUgICAgICAzODc0NzIgICAgICAgICA3MTMgICAgNjU5ICAgIDU0MyAg MCAgICAgNzYgL3Vzci9zcmMvc3lzL2tlcm4vc3Vicl90dXJuc3RpbGUuYzo1NDcgKHNwaW4gbXV0 ZXg6dHVybnN0aWxlIGNoYWluKQogICAgIDE4OSAgICAgICAzNjcgICAgICAgIDI4MzAgICAgICAg ICA3NTcgICAgICAgICAgMjEgICAgMTM0ICAgICAzNiAgMCAgICAgIDQgL3Vzci9zcmMvc3lzL2tl cm4va2Vybl9pbnRyLmM6ODAwIChzcGluIG11dGV4OnNjaGVkIGxvY2sgMjgpCiAgICAgMTUyICAg ICAgIDI2NSAgICAgICAgMzgyMiAgICAgICAgMTQxOCAgICAgICAgICA0OCAgICAgNzkgICAgIDI5 ICAwICAgICAgOCAvdXNyL3NyYy9zeXMva2Vybi9zY2hlZF91bGUuYzoxMTE4IChzcGluIG11dGV4 OnNjaGVkIGxvY2sgMjgpCiAgICAgNTkwICAgICAgIDQ1OSAgICAgICAgNTg5MyAgICAgICAgIDQ1 OSAgICAgICAgICAxNiAgICAzNjggICAgIDI4ICAwICAgICAgMSAvdXNyL3NyYy9zeXMva2Vybi9z Y2hlZF91bGUuYzo4MDMgKHNwaW4gbXV0ZXg6c2NoZWQgbG9jayAxKQogICAgIDE4OSAgICAgICA1 MzQgICAgICAgIDk0NzYgICAgICAgIDE5OTQgICAgICAgICAgNTMgICAgMTc4ICAgICAzNyAgMCAg ICAgMTIgL3Vzci9zcmMvc3lzL2tlcm4vc2NoZWRfdWxlLmM6ODA0IChzcGluIG11dGV4OnNjaGVk IGxvY2sgMSkKICAgICA3MTAgICAgICAgNTMwICAgICAgICAxMjM3ICAgICAgICAgNzA0ICAgICAg ICAgICA0ICAgIDMwOSAgICAxNzYgIDAgICAgICAzIC91c3Ivc3JjL3N5cy9rZXJuL3NjaGVkX3Vs ZS5jOjgwNiAoc3BpbiBtdXRleDpzY2hlZCBsb2NrIDEpCiAgICAgMTg3ICAgICAgIDUxMCAgICAg ICAxMDI4MiAgICAgICAgMjA2MCAgICAgICAgICA3NSAgICAxMzcgICAgIDI3ICAwICAgICAxMSAv dXNyL3NyYy9zeXMva2Vybi9zY2hlZF91bGUuYzo4MDcgKHNwaW4gbXV0ZXg6c2NoZWQgbG9jayAx KQogICAgIDE3MiAgICAgICAxMTEgICAgICAgIDIzMzUgICAgICAgICA2MTAgICAgICAgICAgMjUg ICAgIDkzICAgICAyNCAgMCAgICAgIDYgL3Vzci9zcmMvc3lzL2tlcm4va2Vybl9pbnRyLmM6ODAw IChzcGluIG11dGV4OnNjaGVkIGxvY2sgMTkpCiAgICAgMTYxICAgICAgIDE1NiAgICAgICAgMTk3 NiAgICAgICAgIDQ4MiAgICAgICAgICAxOSAgICAxMDQgICAgIDI1ICAwICAgICAgNCAvdXNyL3Ny Yy9zeXMva2Vybi9zY2hlZF91bGUuYzoxMTE4IChzcGluIG11dGV4OnNjaGVkIGxvY2sgMTkpCiAg ICAgMjYzICAgICAgICA4NyAgICAgICAgIDYxNCAgICAgICAgICA4NyAgICAgICAgICAgMyAgICAy MDQgICAgIDI5ICAwICAgICAgMSAvdXNyL3NyYy9zeXMva2Vybi9zY2hlZF91bGUuYzo4MDMgKHNw aW4gbXV0ZXg6c2NoZWQgbG9jayAyNCkKICAgICAyMzkgICAgICAgNjA4ICAgICAgNDE2MjY5ICAg ICAgICAxMTMzICAgICAgICAyODI4ICAgIDE0NyAgICAgIDAgIDAgICAgICAzIC91c3Ivc3JjL3N5 cy9rZXJuL3NjaGVkX3VsZS5jOjE4MzUgKHNwaW4gbXV0ZXg6c2NoZWQgbG9jayAwKQogICAgIDU0 MyAgICAgICAgIDAgICAgIDE1NDQyNDEgICAgICAgICAgIDAgICAgICAgMTU4MjMgICAgIDk3ICAg ICAgMCAgMCAgICAgIDAgL3Vzci9zcmMvc3lzL2tlcm4vc2NoZWRfdWxlLmM6MTg3NiAoc3BpbiBt dXRleDpzY2hlZCBsb2NrIDApCiAgICAgIDY1ICAgICAgICA2NyAgICAgICAgIDMxNCAgICAgICAg ICA2NyAgICAgICAgICAgNyAgICAgNDQgICAgICA5ICAwICAgICAgMSAvdXNyL3NyYy9zeXMva2Vy bi9zY2hlZF91bGUuYzoxMTE4IChzcGluIG11dGV4OnNjaGVkIGxvY2sgMTApCiAgICAgMTM5ICAg ICAgIDQzMSAgICAgIDE5ODIxMCAgICAgICAgIDc5NyAgICAgICAgMjcwMiAgICAgNzMgICAgICAw ICAwICAgICAgMyAvdXNyL3NyYy9zeXMva2Vybi9zdWJyX3NsZWVwcXVldWUuYzozMzUgKHNwaW4g bXV0ZXg6c2NoZWQgbG9jayAwKQogICAgIDI0OSAgICAgIDE5NDAgICAgICAzNjE4ODQgICAgICAg ODU3MzQgICAgICAgIDMzMzYgICAgMTA4ICAgICAyNSAgMCAgICAxNjQgL3Vzci9zcmMvc3lzL2tl cm4vc3Vicl9zbGVlcHF1ZXVlLmM6ODMwIChzcGluIG11dGV4OnNsZWVwcSBjaGFpbikKICAgICAg OTEgICAgICAgICAwICAgICAgICAxNDIxICAgICAgICAgICAwICAgICAgICAgIDI5ICAgICA0OSAg ICAgIDAgIDAgICAgICAwIC91c3Ivc3JjL3N5cy9rZXJuL3N1YnJfc2xlZXBxdWV1ZS5jOjM5MyAo c3BpbiBtdXRleDpzY2hlZCBsb2NrIDApCiAgICAgMTg4ICAgICAgICA5OSAgICAgICAgMTI1MCAg ICAgICAgIDI3NCAgICAgICAgICAgNyAgICAxNzggICAgIDM5ICAwICAgICAgMyAvdXNyL3NyYy9z eXMva2Vybi9zY2hlZF91bGUuYzo4MDQgKHNwaW4gbXV0ZXg6c2NoZWQgbG9jayAxNSkKICAgICAx MTMgICAgICAgNDU0ICAgICAgICAyNjk0ICAgICAgICAzMDE4ICAgICAgICAgIDI5ICAgICA5MiAg ICAxMDQgIDAgICAgIDE0IC91c3Ivc3JjL3N5cy9rZXJuL3NjaGVkX3VsZS5jOjgwNyAoc3BpbiBt dXRleDpzY2hlZCBsb2NrIDE1KQogICAgIDI1NCAgICAgICA5MTYgICAgICA4NDQ2MTYgICAgICAz ODg2MTYgICAgICAgIDgyNzkgICAgMTAyICAgICA0NiAgMCAgIDI4NjQgL3Vzci9zcmMvc3lzL2tl cm4va2Vybl9pbnRyLmM6ODAwIChzcGluIG11dGV4OnNjaGVkIGxvY2sgMSkKICAgICAxOTggICAg ICAgNzcxICAgICAgNTQ3MjI4ICAgICAgMTg1MTg3ICAgICAgICA1NjE5ICAgICA5NyAgICAgMzIg IDAgICAxMTk1IC91c3Ivc3JjL3N5cy9rZXJuL3NjaGVkX3VsZS5jOjExMTggKHNwaW4gbXV0ZXg6 c2NoZWQgbG9jayAxKQogICAgIDEzOCAgICAgICAzMjYgICAgICAyMDY0MjkgICAgICAxMzY4OTcg ICAgICAgIDI3NzEgICAgIDc0ICAgICA0OSAgMCAgIDE3OTEgL3Vzci9zcmMvc3lzL2tlcm4vc2No ZWRfdWxlLmM6MjA3NCAoc3BpbiBtdXRleDpzY2hlZCBsb2NrIDApCiAgICAgMTg5ICAgICAgICAg MCAgICAgICAgIDU1MCAgICAgICAgICAgMCAgICAgICAgICAgMyAgICAxODMgICAgICAwICAwICAg ICAgMCAvdXNyL3NyYy9zeXMva2Vybi9zY2hlZF91bGUuYzo4MDMgKHNwaW4gbXV0ZXg6c2NoZWQg bG9jayA2KQogICAgIDIwMiAgICAgICAyNDcgICAgICAgIDQ1NDQgICAgICAgICA5MjEgICAgICAg ICAgMjUgICAgMTgxICAgICAzNiAgMCAgICAgIDcgL3Vzci9zcmMvc3lzL2tlcm4vc2NoZWRfdWxl LmM6ODA0IChzcGluIG11dGV4OnNjaGVkIGxvY2sgNikKICAgICAxMDAgICAgICAgNDk1ICAgICAg ICAxMzgxICAgICAgICAyMzQ3ICAgICAgICAgIDE1ICAgICA5MiAgICAxNTYgIDAgICAgIDEwIC91 c3Ivc3JjL3N5cy9rZXJuL3NjaGVkX3VsZS5jOjgwNyAoc3BpbiBtdXRleDpzY2hlZCBsb2NrIDYp CiAgICAgMTE5ICAgICAxNzE1OSAgICAgICAyODk3NyAgICAgICAxNzE1OSAgICAgICAgIDM2NCAg ICAgNzkgICAgIDQ3ICAwICAgICAgMSAvdXNyL3NyYy9zeXMva2Vybi9zY2hlZF91bGUuYzoyMTEx IChzcGluIG11dGV4OnNjaGVkIGxvY2sgMCkKICAgICAyMDUgICAgICAgMzU4ICAgICAgIDE2NjM3 ICAgICAgICA2MzQxICAgICAgICAgMTM4ICAgIDEyMCAgICAgNDUgIDAgICAgIDQwIC91c3Ivc3Jj L3N5cy9rZXJuL2tlcm5faW50ci5jOjgwMCAoc3BpbiBtdXRleDpzY2hlZCBsb2NrIDI0KQogICAg IDEyNCAgICAgICAgIDAgICAgICAgNTE2NDggICAgICAgICAgIDAgICAgICAgICA2MDcgICAgIDg1 ICAgICAgMCAgMCAgICAgIDAgL3Vzci9zcmMvc3lzL2tlcm4vc3Vicl9zbGVlcHF1ZXVlLmM6NTgz IChzcGluIG11dGV4OnNjaGVkIGxvY2sgMCkKICAgICAyNjYgICAgICAgICAwICAgICAgICA0Mjc3 ICAgICAgICAgICAwICAgICAgICAgIDMxICAgIDEzNyAgICAgIDAgIDAgICAgICAwIC91c3Ivc3Jj L3N5cy9rZXJuL2tlcm5fc2lnLmM6MjI1MSAoc3BpbiBtdXRleDpzbGVlcHEgY2hhaW4pCiAgICAg MTY3ICAgICAgIDQwOCAgICAgICAxMzcxNyAgICAgICAgNzk5OSAgICAgICAgIDExNiAgICAxMTgg ICAgIDY4ICAwICAgICAzOCAvdXNyL3NyYy9zeXMva2Vybi9zY2hlZF91bGUuYzoxMTE4IChzcGlu IG11dGV4OnNjaGVkIGxvY2sgMjQpCiAgICAgMTMxICAgICAgICAgMCAgICAgIDE0NTA0OCAgICAg ICAgICAgMCAgICAgICAgMjA2NiAgICAgNzAgICAgICAwICAwICAgICAgMCAvdXNyL3NyYy9zeXMv a2Vybi9zdWJyX3NsZWVwcXVldWUuYzo2MTggKHNwaW4gbXV0ZXg6c2NoZWQgbG9jayAwKQogICAg IDE3NSAgICAgICAyMzUgICAgICAgNzI0OTQgICAgICAgICA0MzggICAgICAgICA2MDUgICAgMTE5 ICAgICAgMCAgMCAgICAgIDMgL3Vzci9zcmMvc3lzL2tlcm4vc3Vicl90dXJuc3RpbGUuYzo3MDkg KHNwaW4gbXV0ZXg6dGRfY29udGVzdGVkKQogICAgIDE4MCAgICAgICAyMzYgICAgICAyNzY0MTEg ICAgICAgIDExODYgICAgICAgIDMzNDQgICAgIDgyICAgICAgMCAgMCAgICAgIDggL3Vzci9zcmMv c3lzL2tlcm4va2Vybl9pbnRyLmM6ODAwIChzcGluIG11dGV4OnNjaGVkIGxvY2sgMTUpCiAgICAg MjUwICAgICAgIDYwOCAgIDU2OTg2OTA4NSAgICAgMTcwNjY4NiAgICAgNDc3NDQ1MyAgICAxMTkg ICAgICAwICAwICAxMjM4OSAvdXNyL3NyYy9zeXMva2Vybi9rZXJuX3RpbWVvdXQuYzoyNDYgKHNw aW4gbXV0ZXg6Y2FsbG91dCkKICAgICAxNDggICAgICAgMTE5ICAgICAgIDY2Mjc1ICAgICAgICAg NjkxICAgICAgICAgNTEyICAgIDEyOSAgICAgIDEgIDAgICAgICA3IC91c3Ivc3JjL3N5cy9rZXJu L3NjaGVkX3VsZS5jOjExMTggKHNwaW4gbXV0ZXg6c2NoZWQgbG9jayAxNSkKICAgICAyMTIgICAg ICAxNzUwICAgICA1OTk1MTIyICAgICAxNDUyMzM5ICAgICAgIDY5Nzc3ICAgICA4NSAgICAgMjAg IDAgICA4NjU4IC91c3Ivc3JjL3N5cy9rZXJuL2tlcm5fdGltZW91dC5jOjI3MiAoc3BpbiBtdXRl eDpjYWxsb3V0KQogICAgIDIxNCAgICAgICA3MjYgICAgICAgIDE1MjggICAgICAgIDIyNTEgICAg ICAgICAgIDggICAgMTkxICAgIDI4MSAgMCAgICAgIDUgL3Vzci9zcmMvc3lzL2tlcm4vc2NoZWRf dWxlLmM6ODAzIChzcGluIG11dGV4OnNjaGVkIGxvY2sgMjApCiAgICAgMTgyICAgICAgNDk4MyAg ICAgMjI0MzAyMyAgICAgIDY3Mjg0MSAgICAgICAyNTM3NCAgICAgODggICAgIDI2ICAwICAgMzU4 NCAvdXNyL3NyYy9zeXMva2Vybi9rZXJuX3RpbWVvdXQuYzozMjUgKHNwaW4gbXV0ZXg6Y2FsbG91 dCkKICAgICAxNjUgICAgICAgMTQ4ICAgICAgIDcxMzQyICAgICAgICAgNTk2ICAgICAgICAgNjA1 ICAgIDExNyAgICAgIDAgIDAgICAgICA1IC91c3Ivc3JjL3N5cy9rZXJuL3N1YnJfdHVybnN0aWxl LmM6ODMwIChzcGluIG11dGV4OnRkX2NvbnRlc3RlZCkKICAgICAxNjggICAgICAgMTUyICAgICAg IDc5Mjg0ICAgICAgICAgMTUyICAgICAgICAgNjQ0ICAgIDEyMyAgICAgIDAgIDAgICAgICAxIC91 c3Ivc3JjL3N5cy9rZXJuL3NjaGVkX3VsZS5jOjExMTggKHNwaW4gbXV0ZXg6c2NoZWQgbG9jayA2 KQogICAgIDE2MSAgICAgICAyNDYgICAgICAgNzEwNjUgICAgICAgICA4MTkgICAgICAgICA2MDUg ICAgMTE3ICAgICAgMSAgMCAgICAgIDUgL3Vzci9zcmMvc3lzL2tlcm4vc3Vicl90dXJuc3RpbGUu Yzo4OTAgKHNwaW4gbXV0ZXg6dGRfY29udGVzdGVkKQogICAgIDE0NyAgICAgICAzNDkgICAgMTE3 Njc5NzAgICAgICAgNzgxODAgICAgICAxNDM1MDIgICAgIDgyICAgICAgMCAgMCAgICA0NjEgL3Vz ci9zcmMvc3lzL2tlcm4va2Vybl9jbG9jay5jOjI4NiAoc3BpbiBtdXRleDpzY2hlZCBsb2NrIDAp CiAgICAgMTk1ICAgICAgOTk0MSAgICAgMjgyOTk3MCAgICAgIDYxNjEyMSAgICAgICAzMjE1MCAg ICAgODggICAgIDE5ICAwICAgMzQ5NCAvdXNyL3NyYy9zeXMva2Vybi9rZXJuX3RpbWVvdXQuYzo0 MzYgKHNwaW4gbXV0ZXg6Y2FsbG91dCkKICAgICAxMzIgICAgICAgNDQ2ICAgICAgICAyNjY5ICAg ICAgICAgOTY0ICAgICAgICAgIDI5ICAgICA5MiAgICAgMzMgIDAgICAgICA0IC91c3Ivc3JjL3N5 cy9rZXJuL3N1YnJfdHVybnN0aWxlLmM6MjAzIChzcGluIG11dGV4OnNjaGVkIGxvY2sgMikKICAg ICAxOTAgICAgICAgMjczICAgICAgICAzODg4ICAgICAgICAgNzk4ICAgICAgICAgIDIyICAgIDE3 NiAgICAgMzYgIDAgICAgICA0IC91c3Ivc3JjL3N5cy9rZXJuL3NjaGVkX3VsZS5jOjgwNCAoc3Bp biBtdXRleDpzY2hlZCBsb2NrIDExKQogICAgIDE1OSAgICAgICAyNTggICAgICAgIDE0MjMgICAg ICAgICA4NzUgICAgICAgICAgMTMgICAgMTA5ICAgICA2NyAgMCAgICAgIDYgL3Vzci9zcmMvc3lz L2tlcm4vc2NoZWRfdWxlLmM6MTExOCAoc3BpbiBtdXRleDpzY2hlZCBsb2NrIDI5KQogICAgIDE3 MSAgICAgICA5ODEgICAgICA0MTkyMTcgICAgICAgOTAzNzQgICAgICAgIDQ3NzQgICAgIDg3ICAg ICAxOCAgMCAgICA2MTQgL3Vzci9zcmMvc3lzL2tlcm4va2Vybl90aW1lb3V0LmM6NTA2IChzcGlu IG11dGV4OmNhbGxvdXQpCiAgICAgNTMwICAgICAgICAgMCAgICAgICAgODkwMiAgICAgICAgICAg MCAgICAgICAgICA0MSAgICAyMTcgICAgICAwICAwICAgICAgMCAvdXNyL3NyYy9zeXMva2Vybi9r ZXJuX3NpZy5jOjIyNTAgKHNwaW4gbXV0ZXg6cHJvY2VzcyBzbG9jaykKICAgICAgNTMgICAgICAg ICAwICAgICAgICAgNjQzICAgICAgICAgICAwICAgICAgICAgIDMyICAgICAyMCAgICAgIDAgIDAg ICAgICAwIC91c3Ivc3JjL3N5cy9rZXJuL2tlcm5fY3B1c2V0LmM6NTYyIChzcGluIG11dGV4OnNs ZWVwcSBjaGFpbikKICAgICAgNTAgICAgICAgICAwICAgICAgICAgNjQ1ICAgICAgICAgICAwICAg ICAgICAgIDMyICAgICAyMCAgICAgIDAgIDAgICAgICAwIC91c3Ivc3JjL3N5cy9rZXJuL2tlcm5f Y3B1c2V0LmM6MjY2IChzcGluIG11dGV4OmNwdXNldCkKICAgICAgODUgICAgICAyOTgyICAgICAg ICAgNDk1ICAgICAgICA0MjQ4ICAgICAgICAgIDE3ICAgICAyOSAgICAyNDkgIDAgICAgIDEyIC91 c3Ivc3JjL3N5cy9rZXJuL3NjaGVkX3VsZS5jOjI1NjkgKHNwaW4gbXV0ZXg6c2NoZWQgbG9jayAw KQogICAgIDEyOCAgICAgICAgIDAgICAgICAgIDIwNTkgICAgICAgICAgIDAgICAgICAgICAgMzIg ICAgIDY0ICAgICAgMCAgMCAgICAgIDAgL3Vzci9zcmMvc3lzL2tlcm4va2Vybl9jcHVzZXQuYzo1 OTIgKHNwaW4gbXV0ZXg6c2xlZXBxIGNoYWluKQogICAgIDgyNCAgICAgICAyNTEgICAgICAgIDU4 MzkgICAgICAgICA0MzEgICAgICAgICAgMTQgICAgNDE3ICAgICAzMCAgMCAgICAgIDIgL3Vzci9z cmMvc3lzL2tlcm4vc2NoZWRfdWxlLmM6ODAzIChzcGluIG11dGV4OnNjaGVkIGxvY2sgMikKICAg ICAxODMgICAgICAgICAwICAgICAgICAgMzY0ICAgICAgICAgICAwICAgICAgICAgICAyICAgIDE4 MiAgICAgIDAgIDAgICAgICAwIC91c3Ivc3JjL3N5cy9rZXJuL2tlcm5fc2lnLmM6MjI1MSAoc3Bp biBtdXRleDpzY2hlZCBsb2NrIDApCiAgICAgMTk0ICAgICAgIDQ0NyAgICAgICAgNzMzNiAgICAg ICAgMTQ2NyAgICAgICAgICA0MSAgICAxNzggICAgIDM1ICAwICAgICAxMCAvdXNyL3NyYy9zeXMv a2Vybi9zY2hlZF91bGUuYzo4MDQgKHNwaW4gbXV0ZXg6c2NoZWQgbG9jayAyKQogICAgIDIxNiAg ICAgICA0NTMgICAgICAgIDk3NDEgICAgICAgICA0NTMgICAgICAgICAgNjUgICAgMTQ5ICAgICAg NiAgMCAgICAgIDEgL3Vzci9zcmMvc3lzL2tlcm4vc2NoZWRfdWxlLmM6ODA3IChzcGluIG11dGV4 OnNjaGVkIGxvY2sgMikKICAgICAxNDggICAgICAxMjIzICAgICAgNTM4OTY5ICAgICAgIDExNjYw ICAgICAgICA2MDUzICAgICA4OSAgICAgIDEgIDAgICAgIDI3IC91c3Ivc3JjL3N5cy9rZXJuL2tl cm5fc3dpdGNoLmM6MTg4IChzcGluIG11dGV4OnNjaGVkIGxvY2sgMCkKICAgICAxMjkgICAgICAg ICAwICAgICAgICAgNDU4ICAgICAgICAgICAwICAgICAgICAgICA2ICAgICA3NiAgICAgIDAgIDAg ICAgICAwIC91c3Ivc3JjL3N5cy9rZXJuL3NjaGVkX3VsZS5jOjI2MjcgKHNwaW4gbXV0ZXg6c2No ZWQgbG9jayAwKQogICAgIDI2MiAgICAgIDEwNDEgICAgICAgNzMzMzggICAgICAgMjU3ODAgICAg ICAgICA1OTYgICAgMTIzICAgICA0MyAgMCAgICAxNzIgL3Vzci9zcmMvc3lzL2tlcm4va2Vybl9p bnRyLmM6ODAwIChzcGluIG11dGV4OnNjaGVkIGxvY2sgMjApCiAgICAgMTg1ICAgICAgIDcxOCAg ICAgICA3NTU4MyAgICAgICAzMzQ0OSAgICAgICAgIDk2MCAgICAgNzggICAgIDM0ICAwICAgIDIw OCAvdXNyL3NyYy9zeXMva2Vybi9zY2hlZF91bGUuYzoxMTE4IChzcGluIG11dGV4OnNjaGVkIGxv Y2sgMjApCiAgICAgMTQ0ICAgICAgIDMyMyAgICAgMTU4NTA2OSAgICAgICAgOTgxOCAgICAgICAx OTA4NiAgICAgODMgICAgICAwICAwICAgICA3MCAvdXNyL3NyYy9zeXMva2Vybi9rZXJuX2Nsb2Nr LmM6NTAzIChzcGluIG11dGV4OnNjaGVkIGxvY2sgMCkKICAgICAxMzAgICAgICAzNjI2ICAgICAg IDY4NDcwICAgICAgICAzNjI2ICAgICAgICAgODA2ICAgICA4NCAgICAgIDQgIDAgICAgICAxIC91 c3Ivc3JjL3N5cy9rZXJuL3N1YnJfdHJhcC5jOjE2NyAoc3BpbiBtdXRleDpzY2hlZCBsb2NrIDAp CiAgICAgMTMxICAgICAgMzcyOSAgICAgICA3MDE3MyAgICAgICAgMzcyOSAgICAgICAgIDgwNSAg ICAgODcgICAgICA0ICAwICAgICAgMSAvdXNyL3NyYy9zeXMva2Vybi9zdWJyX3RyYXAuYzoyMTMg KHNwaW4gbXV0ZXg6c2NoZWQgbG9jayAwKQogICAgIDE3NiAgICAgICAgODggICAgICAgICAxNzYg ICAgICAgICAgODggICAgICAgICAgIDEgICAgMTc2ICAgICA4OCAgMCAgICAgIDEgL3Vzci9zcmMv c3lzL2tlcm4vc2NoZWRfdWxlLmM6ODA0IChzcGluIG11dGV4OnNjaGVkIGxvY2sgMjUpCiAgICAg IDEyICAgICAgICAgMCAgICAgICAgICAxMiAgICAgICAgICAgMCAgICAgICAgICAgMSAgICAgMTIg ICAgICAwICAwICAgICAgMCAvdXNyL3NyYy9zeXMva2Vybi9zY2hlZF91bGUuYzoxMTE4IChzcGlu IG11dGV4OnNjaGVkIGxvY2sgMTEpCiAgICAgNDAxICAgICAgICAgMCAgICAgICAxNTUzNCAgICAg ICAgICAgMCAgICAgICAgICA1OSAgICAyNjMgICAgICAwICAwICAgICAgMCAvdXNyL3NyYy9zeXMv a2Vybi9rZXJuX3VtdHguYzozMzU0IChzcGluIG11dGV4OnVtdHggbG9jaykKICAgICA0NTQgICAg ICAgNDYyICAgICAgIDI5MjMwICAgICAgIDEwMjA0ICAgICAgICAgMTMyICAgIDIyMSAgICAgNzcg IDAgICAgIDU1IC91c3Ivc3JjL3N5cy9rZXJuL3NjaGVkX3VsZS5jOjgwMyAoc3BpbiBtdXRleDpz Y2hlZCBsb2NrIDE2KQogICAgIDUyOSAgICAgICAyNzYgICAgICAgMjIyMzkgICAgICAgIDI0ODQg ICAgICAgICAgNjYgICAgMzM2ICAgICAzNyAgMCAgICAgMTYgL3Vzci9zcmMvc3lzL2tlcm4vc2No ZWRfdWxlLmM6ODA2IChzcGluIG11dGV4OnNjaGVkIGxvY2sgMTYpCiAgICAgMTU1ICAgICAgIDE1 MiAgICAgICA5ODk4MiAgICAgICAgIDE1MiAgICAgICAgMTE0NCAgICAgODYgICAgICAwICAwICAg ICAgMSAvdXNyL3NyYy9zeXMva2Vybi9rZXJuX3Jlc291cmNlLmM6NjI2IChzcGluIG11dGV4OnNs ZWVwcSBjaGFpbikKICAgICAxOTYgICAgICAgODk3ICAgICAgNzcwMDk1ICAgICAgMTcwOTMwICAg ICAgICA3ODk0ICAgICA5NyAgICAgMjEgIDAgICAxMDg5IC91c3Ivc3JjL3N5cy9rZXJuL2tlcm5f aW50ci5jOjgwMCAoc3BpbiBtdXRleDpzY2hlZCBsb2NrIDIpCiAgICAgMTg4ICAgICAgIDgxMCAg ICAgIDQ3MTg0OSAgICAgIDE5ODQ3MCAgICAgICAgNDU0OCAgICAxMDMgICAgIDQzICAwICAgMTMy NCAvdXNyL3NyYy9zeXMva2Vybi9zY2hlZF91bGUuYzoxMTE4IChzcGluIG11dGV4OnNjaGVkIGxv Y2sgMikKICAgICAyMDggICAgICAgMjAxICAgICAgICA1NzI5ICAgICAgICAgNzAyICAgICAgICAg IDMxICAgIDE4NCAgICAgMjIgIDAgICAgICA1IC91c3Ivc3JjL3N5cy9rZXJuL3NjaGVkX3VsZS5j OjgwNCAoc3BpbiBtdXRleDpzY2hlZCBsb2NrIDcpCiAgICAgMTE3ICAgICAgIDEzOCAgICAgICAg IDQzOCAgICAgICAgIDIwMyAgICAgICAgICAgNSAgICAgODcgICAgIDQwICAwICAgICAgMiAvdXNy L3NyYy9zeXMva2Vybi9zY2hlZF91bGUuYzoxMTE4IChzcGluIG11dGV4OnNjaGVkIGxvY2sgMjUp CiAgICAgMTk4ICAgICAgIDYxMCAgICAgICAyMzE0NiAgICAgICAxMTc2MiAgICAgICAgIDIwNiAg ICAxMTIgICAgIDU3ICAwICAgICA1NiAvdXNyL3NyYy9zeXMva2Vybi9rZXJuX2ludHIuYzo4MDAg KHNwaW4gbXV0ZXg6c2NoZWQgbG9jayAxNikKICAgICAxNjYgICAgICAgNTMxICAgICAgIDM5MzU4 ICAgICAgIDE1MjgxICAgICAgICAgNjk5ICAgICA1NiAgICAgMjEgIDAgICAgIDk3IC91c3Ivc3Jj L3N5cy9rZXJuL3NjaGVkX3VsZS5jOjExMTggKHNwaW4gbXV0ZXg6c2NoZWQgbG9jayAxNikKICAg ICAyMDEgICAgICAgICAwICAgICAgICAgNzU3ICAgICAgICAgICAwICAgICAgICAgICA0ICAgIDE4 OSAgICAgIDAgIDAgICAgICAwIC91c3Ivc3JjL3N5cy9rZXJuL3NjaGVkX3VsZS5jOjgwNCAoc3Bp biBtdXRleDpzY2hlZCBsb2NrIDIxKQogICAgIDU4MiAgICAgICAgIDAgICAgICAyOTY4MDcgICAg ICAgICAgIDAgICAgICAgIDExNDQgICAgMjU5ICAgICAgMCAgMCAgICAgIDAgL3Vzci9zcmMvc3lz L2tlcm4va2Vybl9yZXNvdXJjZS5jOjYyNCAoc3BpbiBtdXRleDpwcm9jZXNzIHNsb2NrKQogICAg IDE1NSAgICAgICAxODkgICAgICAgMzA4NzAgICAgICAgIDIwMjUgICAgICAgIDExMDMgICAgIDI3 ICAgICAgMSAgMCAgICAgMzAgL3Vzci9zcmMvc3lzL2tlcm4va2Vybl9pbnRyLmM6ODAwIChzcGlu IG11dGV4OnNjaGVkIGxvY2sgNykKICAgICAxODMgICAgICAgMjUzICAgICAgIDU1Mjk2ICAgICAg IDE1NjY1ICAgICAgICAgODA1ICAgICA2OCAgICAgMTkgIDAgICAgMTMyIC91c3Ivc3JjL3N5cy9r ZXJuL3NjaGVkX3VsZS5jOjExMTggKHNwaW4gbXV0ZXg6c2NoZWQgbG9jayA3KQogICAgICA4OCAg ICAgICAgIDAgICAgICAgIDEwMjUgICAgICAgICAgIDAgICAgICAgICAgMzMgICAgIDMxICAgICAg MCAgMCAgICAgIDAgL3Vzci9zcmMvc3lzL2tlcm4va2Vybl9mb3JrLmM6NDM1IChzcGluIG11dGV4 OnNjaGVkIGxvY2sgMCkKICAgICAxMzMgICAgICAgNjc3ICAgICAgICAxNjQwICAgICAgICAgNjc3 ICAgICAgICAgIDE3ICAgICA5NiAgICAgMzkgIDAgICAgICAxIC91c3Ivc3JjL3N5cy9rZXJuL3N1 YnJfdHVybnN0aWxlLmM6MjAzIChzcGluIG11dGV4OnNjaGVkIGxvY2sgMykKICAgICA0MzEgICAg ICAgMjQ4ICAgICAgICA0NTkxICAgICAgICAxOTkyICAgICAgICAgIDIxICAgIDIxOCAgICAgOTQg IDAgICAgIDExIC91c3Ivc3JjL3N5cy9rZXJuL3NjaGVkX3VsZS5jOjgwMyAoc3BpbiBtdXRleDpz Y2hlZCBsb2NrIDEyKQogICAgIDcyNiAgICAgICAxODYgICAgICAgIDM5MjkgICAgICAgICA2MDIg ICAgICAgICAgMTEgICAgMzU3ICAgICA1NCAgMCAgICAgIDUgL3Vzci9zcmMvc3lzL2tlcm4vc2No ZWRfdWxlLmM6ODA2IChzcGluIG11dGV4OnNjaGVkIGxvY2sgMTIpCiAgICAgMTM3ICAgICAgIDI1 OSAgICAgICAgNTY4MiAgICAgICAgMTkwMSAgICAgICAgICA2MSAgICAgOTMgICAgIDMxICAwICAg ICAxNCAvdXNyL3NyYy9zeXMva2Vybi9rZXJuX2ludHIuYzo4MDAgKHNwaW4gbXV0ZXg6c2NoZWQg bG9jayAzMCkKICAgICAxNjYgICAgICAgMjg0ICAgICAgICAzMDEzICAgICAgICAxMDgyICAgICAg ICAgIDI0ICAgIDEyNSAgICAgNDUgIDAgICAgICA1IC91c3Ivc3JjL3N5cy9rZXJuL3NjaGVkX3Vs ZS5jOjExMTggKHNwaW4gbXV0ZXg6c2NoZWQgbG9jayAzMCkKICAgICAyMTcgICAgICAgMjkxICAg ICAgICA4MDE2ICAgICAgICAxNTIxICAgICAgICAgIDQ1ICAgIDE3OCAgICAgMzMgIDAgICAgIDEz IC91c3Ivc3JjL3N5cy9rZXJuL3NjaGVkX3VsZS5jOjgwNCAoc3BpbiBtdXRleDpzY2hlZCBsb2Nr IDMpCiAgICAgMjM2ICAgICAgIDI3NiAgICAgICAxMjI1NiAgICAgICAgIDM2NyAgICAgICAgICA4 NCAgICAxNDUgICAgICA0ICAwICAgICAgMiAvdXNyL3NyYy9zeXMva2Vybi9zY2hlZF91bGUuYzo4 MDcgKHNwaW4gbXV0ZXg6c2NoZWQgbG9jayAzKQogICAgICA4OSAgICAgICAgIDAgICAgICAgICAg ODkgICAgICAgICAgIDAgICAgICAgICAgIDEgICAgIDg5ICAgICAgMCAgMCAgICAgIDAgL3Vzci9z cmMvc3lzL2tlcm4va2Vybl9zaWcuYzo1OTMgKHNwaW4gbXV0ZXg6c2NoZWQgbG9jayAxMikKICAg ICAxODEgICAgICAgNDc0ICAgICAgIDIyNzk2ICAgICAgIDEwMjE3ICAgICAgICAgMjA2ICAgIDEx MCAgICAgNDkgIDAgICAgIDU2IC91c3Ivc3JjL3N5cy9rZXJuL2tlcm5faW50ci5jOjgwMCAoc3Bp biBtdXRleDpzY2hlZCBsb2NrIDIxKQogICAgIDE4MyAgICAgICA0NDEgICAgICAgMjkxNzAgICAg ICAgMTA2NjMgICAgICAgICAyNTkgICAgMTEyICAgICA0MSAgMCAgICAgNjcgL3Vzci9zcmMvc3lz L2tlcm4vc2NoZWRfdWxlLmM6MTExOCAoc3BpbiBtdXRleDpzY2hlZCBsb2NrIDIxKQogICAgICA5 NyAgICAgICAgIDAgICAgICAgIDE4ODIgICAgICAgICAgIDAgICAgICAgICAgNDYgICAgIDQwICAg ICAgMCAgMCAgICAgIDAgL3Vzci9zcmMvc3lzL2tlcm4va2Vybl9mb3JrLmM6NzIyIChzcGluIG11 dGV4OnByb2Nlc3Mgc2xvY2spCiAgICAgMTc0ICAgICAgICAgMCAgICAgICAgIDE3NCAgICAgICAg ICAgMCAgICAgICAgICAgMSAgICAxNzQgICAgICAwICAwICAgICAgMCAvdXNyL3NyYy9zeXMva2Vy bi9zY2hlZF91bGUuYzo4MDQgKHNwaW4gbXV0ZXg6c2NoZWQgbG9jayAyNikKICAgICAgOTEgICAg ICAgIDk5ICAgICAgICAgMjY5ICAgICAgICAgIDk5ICAgICAgICAgICAzICAgICA4OSAgICAgMzMg IDAgICAgICAxIC91c3Ivc3JjL3N5cy9rZXJuL2tlcm5fc2lnLmM6NTkzIChzcGluIG11dGV4OnNj aGVkIGxvY2sgMykKICAgICAxMjcgICAgICAgICAwICAgICAgICAxMzEwICAgICAgICAgICAwICAg ICAgICAgIDMzICAgICAzOSAgICAgIDAgIDAgICAgICAwIC91c3Ivc3JjL3N5cy9rZXJuL2tlcm5f Zm9yay5jOjczMSAoc3BpbiBtdXRleDpzY2hlZCBsb2NrIDApCiAgICAgMjA4ICAgICAgIDY2NiAg ICAgICA3OTgyMSAgICAgICAyNzY1MCAgICAgICAgIDcwMSAgICAxMTMgICAgIDM5ICAwICAgIDE1 OCAvdXNyL3NyYy9zeXMva2Vybi9rZXJuX2ludHIuYzo4MDAgKHNwaW4gbXV0ZXg6c2NoZWQgbG9j ayAxMikKICAgICAxOTIgICAgICAgNzU3ICAgICAgMTc2MDI5ICAgICAgIDYxNTMyICAgICAgICAy MjAzICAgICA3OSAgICAgMjcgIDAgICAgMzg4IC91c3Ivc3JjL3N5cy9rZXJuL3NjaGVkX3VsZS5j OjExMTggKHNwaW4gbXV0ZXg6c2NoZWQgbG9jayAxMikKICAgICAyMDAgICAgICAgMTUzICAgICAg IDEwNjcwICAgICAgICAgODMwICAgICAgICAgIDY2ICAgIDE2MSAgICAgMTIgIDAgICAgICA2IC91 c3Ivc3JjL3N5cy9rZXJuL3N1YnJfdHVybnN0aWxlLmM6MjAzIChzcGluIG11dGV4OnNjaGVkIGxv Y2sgOCkKICAgICA0MzIgICAgICAgMjcwICAgICAgIDIxMDU5ICAgICAgICA3NDA3ICAgICAgICAg IDk0ICAgIDIyNCAgICAgNzggIDAgICAgIDM2IC91c3Ivc3JjL3N5cy9rZXJuL3NjaGVkX3VsZS5j OjgwMyAoc3BpbiBtdXRleDpzY2hlZCBsb2NrIDE3KQogICAgIDI1OSAgICAgICAyNzYgICAgICAg MTAyODMgICAgICAgIDI5NjIgICAgICAgICAgNTcgICAgMTgwICAgICA1MSAgMCAgICAgMjEgL3Vz ci9zcmMvc3lzL2tlcm4vc2NoZWRfdWxlLmM6ODA0IChzcGluIG11dGV4OnNjaGVkIGxvY2sgMTcp CiAgICAgMTU4ICAgICAgIDI2NiAgICAgICAgNjE1MSAgICAgICAgNDM5NSAgICAgICAgICA2NiAg ICAgOTMgICAgIDY2ICAwICAgICAzMiAvdXNyL3NyYy9zeXMva2Vybi9zY2hlZF91bGUuYzo4MDcg KHNwaW4gbXV0ZXg6c2NoZWQgbG9jayAxNykKICAgICAyMTcgICAgICAgOTYxICAgICAgNjkwMzIy ICAgICAgMTU0NjYwICAgICAgICA3MzI3ICAgICA5NCAgICAgMjEgIDAgICAxMDE0IC91c3Ivc3Jj L3N5cy9rZXJuL2tlcm5faW50ci5jOjgwMCAoc3BpbiBtdXRleDpzY2hlZCBsb2NrIDMpCiAgICAg MjAyICAgICAgIDg4NiAgICAgIDM3NDU2OCAgICAgIDE1Mzg2MiAgICAgICAgMzcwOCAgICAxMDEg ICAgIDQxICAwICAgMTA0NyAvdXNyL3NyYy9zeXMva2Vybi9zY2hlZF91bGUuYzoxMTE4IChzcGlu IG11dGV4OnNjaGVkIGxvY2sgMykKICAgICAxNjMgICAgICAgNDc3ICAgICAgICAzNjQ4ICAgICAg ICAzMTc2ICAgICAgICAgIDM4ICAgICA5NiAgICAgODMgIDAgICAgIDE1IC91c3Ivc3JjL3N5cy9r ZXJuL3NjaGVkX3VsZS5jOjIwNjIgKHNwaW4gbXV0ZXg6c2NoZWQgbG9jayAyKQogICAgIDQ2MiAg ICAgICA2MTcgICAgICAgMTM3NTMgICAgICAgIDY1NTIgICAgICAgICAgNjQgICAgMjE0ICAgIDEw MiAgMCAgICAgMjkgL3Vzci9zcmMvc3lzL2tlcm4vc2NoZWRfdWxlLmM6ODAzIChzcGluIG11dGV4 OnNjaGVkIGxvY2sgOCkKICAgICA0NzYgICAgICAgMjY1ICAgICAgICAyMDg3ICAgICAgICAgNzM2 ICAgICAgICAgICA3ICAgIDI5OCAgICAxMDUgIDAgICAgICA0IC91c3Ivc3JjL3N5cy9rZXJuL3Nj aGVkX3VsZS5jOjgwNiAoc3BpbiBtdXRleDpzY2hlZCBsb2NrIDgpCiAgICAgIDg4ICAgICAgIDE0 MiAgICAgICAgIDYxNyAgICAgICAgIDE0MiAgICAgICAgICAgOCAgICAgNzcgICAgIDE3ICAwICAg ICAgMSAvdXNyL3NyYy9zeXMva2Vybi9rZXJuX2ludHIuYzo4MDAgKHNwaW4gbXV0ZXg6c2NoZWQg bG9jayAyNikKICAgICAxNjIgICAgICAgMjQ2ICAgICAgICAyODk3ICAgICAgICAxNTc1ICAgICAg ICAgIDI1ICAgIDExNSAgICAgNjMgIDAgICAgIDEwIC91c3Ivc3JjL3N5cy9rZXJuL3NjaGVkX3Vs ZS5jOjExMTggKHNwaW4gbXV0ZXg6c2NoZWQgbG9jayAyNikKICAgICAxMDYgICAgICAgMTY4ICAg ICAgICAxNTYyICAgICAgICAgNzAxICAgICAgICAgIDE5ICAgICA4MiAgICAgMzYgIDAgICAgICA3 IC91c3Ivc3JjL3N5cy9rZXJuL2tlcm5faW50ci5jOjgwMCAoc3BpbiBtdXRleDpzY2hlZCBsb2Nr IDE3KQogICAgIDE2NSAgICAgICAzODAgICAgICAgIDExODMgICAgICAgICA5NDMgICAgICAgICAg MTQgICAgIDg0ICAgICA2NyAgMCAgICAgIDUgL3Vzci9zcmMvc3lzL2tlcm4vc2NoZWRfdWxlLmM6 MTExOCAoc3BpbiBtdXRleDpzY2hlZCBsb2NrIDE3KQogICAgIDE5MCAgICAgICAgIDAgICAgICAg ICAzODAgICAgICAgICAgIDAgICAgICAgICAgIDIgICAgMTkwICAgICAgMCAgMCAgICAgIDAgL3Vz ci9zcmMvc3lzL2tlcm4vc2NoZWRfdWxlLmM6ODA0IChzcGluIG11dGV4OnNjaGVkIGxvY2sgMjIp CiAgICAgMjA2ICAgICAgIDY2NSAgICAgIDEyMTY5NSAgICAgICA1MzczMSAgICAgICAgMTA2MCAg ICAxMTQgICAgIDUwICAwICAgIDI3OCAvdXNyL3NyYy9zeXMva2Vybi9rZXJuX2ludHIuYzo4MDAg KHNwaW4gbXV0ZXg6c2NoZWQgbG9jayA4KQogICAgIDE4NCAgICAgICA0NzMgICAgICAxNDgwMzIg ICAgICAgNjc3ODQgICAgICAgIDE0OTIgICAgIDk5ICAgICA0NSAgMCAgICAzOTUgL3Vzci9zcmMv c3lzL2tlcm4vc2NoZWRfdWxlLmM6MTExOCAoc3BpbiBtdXRleDpzY2hlZCBsb2NrIDgpCiAgICAg MTE0ICAgICAgICAgMCAgICAgICAgIDEzNSAgICAgICAgICAgMCAgICAgICAgICAgMiAgICAgNjcg ICAgICAwICAwICAgICAgMCAvdXNyL3NyYy9zeXMva2Vybi9rZXJuX3RocmVhZC5jOjQxMCAoc3Bp biBtdXRleDpzY2hlZCBsb2NrIDApCiAgICAgMjIzICAgICAgIDU5MyAgICAgICAxNDIyOCAgICAg ICAgMTM2NiAgICAgICAgIDEwNyAgICAxMzIgICAgIDEyICAwICAgICAgNiAvdXNyL3NyYy9zeXMv a2Vybi9zdWJyX3R1cm5zdGlsZS5jOjIwMyAoc3BpbiBtdXRleDpzY2hlZCBsb2NrIDQpCiAgICAg MTkxICAgICAgIDE1MCAgICAgICAgMTI3OSAgICAgICAgIDI4NSAgICAgICAgICAgNyAgICAxODIg ICAgIDQwICAwICAgICAgMiAvdXNyL3NyYy9zeXMva2Vybi9zY2hlZF91bGUuYzo4MDQgKHNwaW4g bXV0ZXg6c2NoZWQgbG9jayAxMykKICAgICA3MzQgICAgICAgMjA3ICAgICAgICA0MDgxICAgICAg ICAgODE1ICAgICAgICAgIDEwICAgIDQwOCAgICAgODEgIDAgICAgICA1IC91c3Ivc3JjL3N5cy9r ZXJuL3NjaGVkX3VsZS5jOjgwNiAoc3BpbiBtdXRleDpzY2hlZCBsb2NrIDEzKQogICAgIDEyOSAg ICAgICAyNTcgICAgICAgIDEzNzEgICAgICAgICA4NzggICAgICAgICAgMTUgICAgIDkxICAgICA1 OCAgMCAgICAgIDYgL3Vzci9zcmMvc3lzL2tlcm4va2Vybl9pbnRyLmM6ODAwIChzcGluIG11dGV4 OnNjaGVkIGxvY2sgMzEpCiAgICAgMTU5ICAgICAgIDM3OSAgICAgICAgMTgxOSAgICAgICAgIDg2 MCAgICAgICAgICAxNSAgICAxMjEgICAgIDU3ICAwICAgICAgMyAvdXNyL3NyYy9zeXMva2Vybi9z Y2hlZF91bGUuYzoxMTE4IChzcGluIG11dGV4OnNjaGVkIGxvY2sgMzEpCiAgICAgNDIwICAgICAg IDI0OCAgICAgICAxODc3MyAgICAgICAgNjE1NyAgICAgICAgICA5MCAgICAyMDggICAgIDY4ICAw ICAgICAzNiAvdXNyL3NyYy9zeXMva2Vybi9zY2hlZF91bGUuYzo4MDMgKHNwaW4gbXV0ZXg6c2No ZWQgbG9jayA0KQogICAgIDc2NSAgICAgICAyMTcgICAgICAgIDQyODYgICAgICAgICA2OTMgICAg ICAgICAgMTEgICAgMzg5ICAgICA2MyAgMCAgICAgIDUgL3Vzci9zcmMvc3lzL2tlcm4vc2NoZWRf dWxlLmM6ODA2IChzcGluIG11dGV4OnNjaGVkIGxvY2sgNCkKICAgICAxNzAgICAgICAgMzQxICAg ICAgIDE0OTcyICAgICAgICA1NDE1ICAgICAgICAgMTQzICAgIDEwNCAgICAgMzcgIDAgICAgIDMz IC91c3Ivc3JjL3N5cy9rZXJuL3NjaGVkX3VsZS5jOjExMTggKHNwaW4gbXV0ZXg6c2NoZWQgbG9j ayAyMikKICAgICAxNzUgICAgICAgICAwICAgICAgICAgMTc1ICAgICAgICAgICAwICAgICAgICAg ICAxICAgIDE3NSAgICAgIDAgIDAgICAgICAwIC91c3Ivc3JjL3N5cy9rZXJuL3NjaGVkX3VsZS5j OjgwNCAoc3BpbiBtdXRleDpzY2hlZCBsb2NrIDI3KQogICAgIDE3MyAgICAgICA1NDYgICAgICAg MTI5NTIgICAgICAgIDY4OTAgICAgICAgICAxMTggICAgMTA5ICAgICA1OCAgMCAgICAgNDEgL3Vz ci9zcmMvc3lzL2tlcm4vc2NoZWRfdWxlLmM6MTExOCAoc3BpbiBtdXRleDpzY2hlZCBsb2NrIDEz KQogICAgIDEzNCAgICAgICA1ODAgICAgICAgIDI1MTkgICAgICAgICA1ODAgICAgICAgICAgMzEg ICAgIDgxICAgICAxOCAgMCAgICAgIDEgL3Vzci9zcmMvc3lzL2tlcm4va2Vybl9zaWcuYzo1OTMg KHNwaW4gbXV0ZXg6c2xlZXBxIGNoYWluKQogICAgIDI4NSAgICAgIDE4OTQgICAgIDE0NDczOTcg ICAgICAgNTYwMDcgICAgICAgMTE3NzQgICAgMTIyICAgICAgNCAgMCAgICAxOTkgL3Vzci9zcmMv c3lzL2FtZDY0L2FtZDY0L2lvX2FwaWMuYzoyMTIgKHNwaW4gbXV0ZXg6aWN1KQogICAgIDE3NCAg ICAgICA3NjAgICAgICAxNDI1MTkgICAgICAgIDQxMzEgICAgICAgIDEzNTQgICAgMTA1ICAgICAg MyAgMCAgICAgMjAgL3Vzci9zcmMvc3lzL2Rldi9yYW5kb20vcmFuZG9tZGV2X3NvZnQuYzoyNTAg KHNwaW4gbXV0ZXg6ZW50cm9weSBoYXJ2ZXN0IG11dGV4KQogICAgIDE2MiAgICAgICA3MzEgICAg ICAxNDAxMDcgICAgICAgIDQwNTIgICAgICAgIDEzNTMgICAgMTAzICAgICAgMiAgMCAgICAgMTUg L3Vzci9zcmMvc3lzL2Rldi9yYW5kb20vcmFuZG9tZGV2X3NvZnQuYzoyNzAgKHNwaW4gbXV0ZXg6 ZW50cm9weSBoYXJ2ZXN0IG11dGV4KQogICAgICA5NiAgICAgICAgODkgICAgICAgICAgOTYgICAg ICAgICAgODkgICAgICAgICAgIDEgICAgIDk2ICAgICA4OSAgMCAgICAgIDEgL3Vzci9zcmMvc3lz L2tlcm4vc3Vicl90dXJuc3RpbGUuYzoyMDMgKHNwaW4gbXV0ZXg6c2NoZWQgbG9jayA5KQogICAg IDIzMiAgICAgICAyNjUgICAgICAgMTUyMTggICAgICAgIDI5MDIgICAgICAgICAgODUgICAgMTc5 ICAgICAzNCAgMCAgICAgMTkgL3Vzci9zcmMvc3lzL2tlcm4vc2NoZWRfdWxlLmM6ODA0IChzcGlu IG11dGV4OnNjaGVkIGxvY2sgMTgpCiAgICAgMjEwICAgICAgIDY1MSAgICAgIDE0NTc2MyAgICAg ICA1MTM2MCAgICAgICAgMTM5NSAgICAxMDQgICAgIDM2ICAwICAgIDI4OSAvdXNyL3NyYy9zeXMv a2Vybi9rZXJuX2ludHIuYzo4MDAgKHNwaW4gbXV0ZXg6c2NoZWQgbG9jayA0KQogICAgIDI2MSAg ICAgICA2NjcgICAgICAyODc3MDIgICAgICAxMjYzMjAgICAgICAgIDI3MzEgICAgMTA1ICAgICA0 NiAgMCAgICA3NDIgL3Vzci9zcmMvc3lzL2tlcm4vc2NoZWRfdWxlLmM6MTExOCAoc3BpbiBtdXRl eDpzY2hlZCBsb2NrIDQpCiAgICAgMTk3ICAgICAgIDM1MyAgICAgICAyNDQzNCAgICAgICAgNjMy MiAgICAgICAgIDIyMCAgICAxMTEgICAgIDI4ICAwICAgICA0MCAvdXNyL3NyYy9zeXMva2Vybi9z dWJyX3R1cm5zdGlsZS5jOjIwMyAoc3BpbiBtdXRleDpzY2hlZCBsb2NrIDApCiAgICAgNDU1ICAg ICAgIDIzNyAgICAgICAgMjQxMCAgICAgICAgIDY1OCAgICAgICAgICAgOCAgICAzMDEgICAgIDgy ICAwICAgICAgMyAvdXNyL3NyYy9zeXMva2Vybi9zY2hlZF91bGUuYzo4MDMgKHNwaW4gbXV0ZXg6 c2NoZWQgbG9jayA5KQogICAgMTAyNSAgICAgICAgIDAgICAgICAgMzEwNzYgICAgICAgICAgIDAg ICAgICAgICAxMDEgICAgMzA3ICAgICAgMCAgMCAgICAgIDAgL3Vzci9zcmMvc3lzL25ldGluZXQv aWZfZXRoZXIuYzo1ODcgKHJ3OmlmX2FmZGF0YSkKICAgICAgOTEgICAgICAgICAwICAgICAgICAg MjUzICAgICAgICAgICAwICAgICAgICAgICAzICAgICA4NCAgICAgIDAgIDAgICAgICAwIC91c3Iv c3JjL3N5cy92bS91bWFfY29yZS5jOjIzNTUgKHNsZWVwIG11dGV4OlRIUkVBRCkKICAgICAxMjQg ICAgICAgICAwICAgICAgICAgNDY1ICAgICAgICAgICAwICAgICAgICAgICA1ICAgICA5MyAgICAg IDAgIDAgICAgICAwIC91c3Ivc3JjL3N5cy9rZXJuL3Zmc19zeXNjYWxscy5jOjQxNzYgKHN4OmZp bGVkZXNjIHN0cnVjdHVyZSkKICAgICA0NzIgICAgICAgICAwICAgICAgICA1Mjk2ICAgICAgICAg ICAwICAgICAgICAgIDQ3ICAgIDExMiAgICAgIDAgIDAgICAgICAwIC91c3Ivc3JjL3N5cy92bS91 bWFfY29yZS5jOjI1MjQgKHNsZWVwIG11dGV4OjQwOTYpCiAgICAgIDkyICAgICAgICAgMCAgICAg ICAgIDI3MyAgICAgICAgICAgMCAgICAgICAgICAgMyAgICAgOTEgICAgICAwICAwICAgICAgMCAv dXNyL3NyYy9zeXMvdm0vdW1hX2NvcmUuYzoyMzU1IChzbGVlcCBtdXRleDpWTVNQQUNFKQogICAg IDExOSAgICAgICAgIDAgICAgICAgICA1NTAgICAgICAgICAgIDAgICAgICAgICAgIDcgICAgIDc4 ICAgICAgMCAgMCAgICAgIDAgL3Vzci9zcmMvc3lzL3ZtL3VtYV9jb3JlLmM6MjM1NSAoc2xlZXAg bXV0ZXg6c2VsZmQpCiAgICAgIDkxICAgICAgICAgMCAgICAgICAgIDUzMSAgICAgICAgICAgMCAg ICAgICAgICAgNiAgICAgODggICAgICAwICAwICAgICAgMCAvdXNyL3NyYy9zeXMvdm0vdW1hX2Nv cmUuYzoyNjAyIChzbGVlcCBtdXRleDo0MDk2KQogICAgIDQ1MiAgICAgICAgIDAgICAgICAgICA2 MTcgICAgICAgICAgIDAgICAgICAgICAgIDMgICAgMjA1ICAgICAgMCAgMCAgICAgIDAgL3Vzci9z cmMvc3lzL3ZtL3VtYV9jb3JlLmM6MjY2MSAoc2xlZXAgbXV0ZXg6NDA5NikKICAgICAgOTUgICAg ICAgICAwICAgICAgICAgMjc2ICAgICAgICAgICAwICAgICAgICAgICAzICAgICA5MiAgICAgIDAg IDAgICAgICAwIC91c3Ivc3JjL3N5cy9mcy9kZXZmcy9kZXZmc192bm9wcy5jOjQ4MSAoc3g6cHJv Y3RyZWUpCiAgICAgNDU1ICAgICAgICAgMCAgICAgICAgIDQ1NSAgICAgICAgICAgMCAgICAgICAg ICAgMSAgICA0NTUgICAgICAwICAwICAgICAgMCAvdXNyL3NyYy9zeXMva2Vybi9rZXJuX3Byb2Mu YzozNjMgKHNsZWVwIG11dGV4OnByb2Nlc3MgZ3JvdXApCiAgICAgNTQxICAgICAgICAgMCAgICAg ICAgIDU0MSAgICAgICAgICAgMCAgICAgICAgICAgMSAgICA1NDEgICAgICAwICAwICAgICAgMCAv dXNyL3NyYy9zeXMva2Vybi91aXBjX3VzcnJlcS5jOjExNTMgKHNsZWVwIG11dGV4OnVucF9tdHgp CiAgICA0MDMyICAgICAxMDg4OSAgICAgIDM1ODM4MCAgICAgIDIwOTM1NiAgICAgICAgIDkwOSAg ICAzOTQgICAgMjMwICAwICAgIDM3MyAvdXNyL3NyYy9zeXMva2Vybi9rZXJuX2V4aXQuYzo3MTQg KHNsZWVwIG11dGV4OnByb2Nlc3MgbG9jaykKICAgICA0ODAgICAgICAgICAwICAgICAgICA1ODc3 ICAgICAgICAgICAwICAgICAgICAgIDQ2ICAgIDEyNyAgICAgIDAgIDAgICAgICAwIC91c3Ivc3Jj L3N5cy9rZXJuL2tlcm5fZXhpdC5jOjc2MiAoc2xlZXAgbXV0ZXg6cHJvY2VzcyBsb2NrKQogICAg MTY5MyAgICAgICAgIDAgICAgICAgIDE2OTMgICAgICAgICAgIDAgICAgICAgICAgIDEgICAxNjkz ICAgICAgMCAgMCAgICAgIDAgL3Vzci9zcmMvc3lzL2tlcm4va2Vybl9wcm90LmM6MzMyIChzeDpw cm9jdHJlZSkKICAgICA5MjMgICAgICAgICAwICAgICAgICA4OTkyICAgICAgICAgICAwICAgICAg ICAgIDU0ICAgIDE2NiAgICAgIDAgIDAgICAgICAwIC91c3Ivc3JjL3N5cy92bS91bWFfY29yZS5j OjI2MDIgKHNsZWVwIG11dGV4OlZNU1BBQ0UpCiAgICA1MTQ4ICAgICAgICAgMCAgICAgICAgOTMx MCAgICAgICAgICAgMCAgICAgICAgICAgNiAgIDE1NTEgICAgICAwICAwICAgICAgMCAvdXNyL3Ny Yy9zeXMvdWZzL2Zmcy9mZnNfc29mdGRlcC5jOjQyNjggKHNsZWVwIG11dGV4OlNvZnRkZXAgTG9j aykKICAgICA3NzMgICAgICAgICAwICAgICAgIDE1NzYwICAgICAgICAgICAwICAgICAgICAgIDQ2 ICAgIDM0MiAgICAgIDAgIDAgICAgICAwIC91c3Ivc3JjL3N5cy9rZXJuL2tlcm5fcHJvYy5jOjQ3 MyAoc2xlZXAgbXV0ZXg6cHJvY2VzcyBncm91cCkKICAgICA1MzAgICAgICAgICAwICAgICAgICA2 NTI1ICAgICAgICAgICAwICAgICAgICAgIDQ2ICAgIDE0MSAgICAgIDAgIDAgICAgICAwIC91c3Iv c3JjL3N5cy9rZXJuL2tlcm5fZXhpdC5jOjgwMCAoc2xlZXAgbXV0ZXg6cHJvY2VzcyBsb2NrKQog ICAgIDUwNCAgICAgICAgIDAgICAgICAgIDQ5MzMgICAgICAgICAgIDAgICAgICAgICAgNDYgICAg MTA3ICAgICAgMCAgMCAgICAgIDAgL3Vzci9zcmMvc3lzL2tlcm4va2Vybl9leGl0LmM6ODAzIChz bGVlcCBtdXRleDpwcm9jZXNzIGxvY2spCiAgICAgIDc5ICAgICAgODAyOCAgICAgICAgMjM4MCAg ICAgICAyODM0NSAgICAgICAgICA1NCAgICAgNDQgICAgNTI0ICAwICAgICAzOSAvdXNyL3NyYy9z eXMvdm0vdW1hX2NvcmUuYzoyNjAyIChzbGVlcCBtdXRleDpzZWxmZCkKICAgIDE5NzggICAgICAg ICAwICAgICAgICAxOTc4ICAgICAgICAgICAwICAgICAgICAgICAxICAgMTk3OCAgICAgIDAgIDAg ICAgICAwIC91c3Ivc3JjL3N5cy9rZXJuL3VpcGNfdXNycmVxLmM6MTI2OSAoc2xlZXAgbXV0ZXg6 dW5wX210eCkKICAgIDE0MzEgICAgICAgICAwICAgICAgICAxNDMxICAgICAgICAgICAwICAgICAg ICAgICAxICAgMTQzMSAgICAgIDAgIDAgICAgICAwIC91c3Ivc3JjL3N5cy9rZXJuL3VpcGNfdXNy cmVxLmM6MTI3MCAoc2xlZXAgbXV0ZXg6dW5wX210eCkKICAgICA2NzUgICAgICAgICAwICAgICAg ICA0NDM2ICAgICAgICAgICAwICAgICAgICAgIDI2ICAgIDE3MCAgICAgIDAgIDAgICAgICAwIC91 c3Ivc3JjL3N5cy92bS91bWFfY29yZS5jOjI2NjEgKHNsZWVwIG11dGV4OlZNU1BBQ0UpCiAgICAg MTA1ICAgICAgICAgMCAgICAgICAgIDEwNSAgICAgICAgICAgMCAgICAgICAgICAgMSAgICAxMDUg ICAgICAwICAwICAgICAgMCAvdXNyL3NyYy9zeXMva2Vybi91aXBjX3VzcnJlcS5jOjEyODggKHNs ZWVwIG11dGV4OnVucF9tdHgpCiAgICAgIDgyICAgICAgMTE0NyAgICAgICAgMTIzNiAgICAgICAg NzUzMyAgICAgICAgICAyNiAgICAgNDcgICAgMjg5ICAwICAgICAyMSAvdXNyL3NyYy9zeXMvdm0v dW1hX2NvcmUuYzoyNjYxIChzbGVlcCBtdXRleDpzZWxmZCkKICAgIDEwMzEgICAgICAgICAwICAg ICAgIDEzMDgxICAgICAgICAgICAwICAgICAgICAgIDQxICAgIDMxOSAgICAgIDAgIDAgICAgICAw IC91c3Ivc3JjL3N5cy9rZXJuL2tlcm5fZXhpdC5jOjg4OSAoc2xlZXAgbXV0ZXg6cHJvY2VzcyBs b2NrKQogICAgIDExOCAgICAgICAgIDAgICAgICAgICAyMDYgICAgICAgICAgIDAgICAgICAgICAg IDIgICAgMTAzICAgICAgMCAgMCAgICAgIDAgL3Vzci9zcmMvc3lzL3ZtL3VtYV9jb3JlLmM6OTE0 IChzbGVlcCBtdXRleDpzb2NrZXQpCiAgICAgNzI2ICAgICAgICAgMCAgICAgICAgMjcyMSAgICAg ICAgICAgMCAgICAgICAgICAxMSAgICAyNDcgICAgICAwICAwICAgICAgMCAvdXNyL3NyYy9zeXMv YW1kNjQvYW1kNjQvbWFjaGRlcC5jOjM2MyAoc2xlZXAgbXV0ZXg6c2lnYWN0cykKICAxNTQwMzQg ICAgICAgICAwICAgICAgNTEwNzE1ICAgICAgICAgICAwICAgICAgICAgIDE0ICAzNjQ3OSAgICAg IDAgIDAgICAgICAwIC91c3Ivc3JjL3N5cy91ZnMvZmZzL2Zmc192ZnNvcHMuYzoxMzE4IChzbGVl cCBtdXRleDpzdHJ1Y3QgbW91bnQgbXR4KQogICAgIDg1MSAgICAgICAgIDAgICAgICAgIDI1Njcg ICAgICAgICAgIDAgICAgICAgICAgIDQgICAgNjQxICAgICAgMCAgMCAgICAgIDAgL3Vzci9zcmMv c3lzL3ZtL3ZtX29iamVjdC5jOjEzMjYgKHNsZWVwIG11dGV4OnZtIG9iamVjdCkKICAgICA2NzQg ICAgICAgICAwICAgICAgICAxODIzICAgICAgICAgICAwICAgICAgICAgICA0ICAgIDQ1NSAgICAg IDAgIDAgICAgICAwIC91c3Ivc3JjL3N5cy92bS92bV9vYmplY3QuYzoxMzI3IChzbGVlcCBtdXRl eDp2bSBvYmplY3QpCiAgICAgIDg3ICAgICAgICAgMCAgICAgICAgICA4NyAgICAgICAgICAgMCAg ICAgICAgICAgMSAgICAgODcgICAgICAwICAwICAgICAgMCAvdXNyL3NyYy9zeXMva2Vybi91aXBj X3NvY2tldC5jOjY5MSAoc2xlZXAgbXV0ZXg6c29fcmN2KQogICAgIDc5MSAgICAgICAgIDAgICAg ICAgIDEyNTMgICAgICAgICAgIDAgICAgICAgICAgIDIgICAgNjI2ICAgICAgMCAgMCAgICAgIDAg L3Vzci9zcmMvc3lzL2tlcm4vdmZzX2NhY2hlLmM6NzcxIChzeDpmaWxlZGVzYyBzdHJ1Y3R1cmUp CiAgICAgNzUwICAgICAgICAgMCAgICAgICA3NTcwMCAgICAgICAgICAgMCAgICAgICAgIDUxMiAg ICAxNDcgICAgICAwICAwICAgICAgMCAvdXNyL3NyYy9zeXMvbmV0aW5ldC90Y3BfaG9zdGNhY2hl LmM6NjQ4IChzbGVlcCBtdXRleDp0Y3BfaGNfZW50cnkpCiAgICAgMTIxICAgICAgICAgMCAgICAg ICAgIDQwNSAgICAgICAgICAgMCAgICAgICAgICAgNCAgICAxMDEgICAgICAwICAwICAgICAgMCAv dXNyL3NyYy9zeXMvdm0vdm1fb2JqZWN0LmM6MTQwNSAoc2xlZXAgbXV0ZXg6dm0gb2JqZWN0KQog ICAgICA4OSAgICAgICAgIDAgICAgICAgICAxNzYgICAgICAgICAgIDAgICAgICAgICAgIDIgICAg IDg4ICAgICAgMCAgMCAgICAgIDAgL3Vzci9zcmMvc3lzL2tlcm4va2Vybl9wcm90LmM6MTE2IChz bGVlcCBtdXRleDpwcm9jZXNzIGxvY2spCiAgICA4NDgwICAgICAgICAgMCAgICAgICA0OTcxNiAg ICAgICAgICAgMCAgICAgICAgICAgNiAgIDgyODYgICAgICAwICAwICAgICAgMCAvdXNyL3NyYy9z eXMva2Vybi92ZnNfbG9va3VwLmM6ODY2IChsb2NrbWdyOnVmcykKICAgICAgOTggICAgICAgICAw ICAgICAgICAgOTI1ICAgICAgICAgICAwICAgICAgICAgIDEwICAgICA5MiAgICAgIDAgIDAgICAg ICAwIC91c3Ivc3JjL3N5cy9rZXJuL2tlcm5fcHJvdC5jOjEzNSAoc2xlZXAgbXV0ZXg6cHJvY2Vz cyBsb2NrKQogICAgMTYyMyAgICAgICA1MzkgICAgICAgNDU1NzUgICAgICAgICA1MzkgICAgICAg ICAxODYgICAgMjQ1ICAgICAgMiAgMCAgICAgIDEgL3Vzci9zcmMvc3lzL2Rldi9lMTAwMC9pZl9l bS5jOjE3MDUgKHNsZWVwIG11dGV4OmVtMCkKICAgICAzMjMgICAgICAgICAwICAgICAgICAxNjEw ICAgICAgICAgICAwICAgICAgICAgIDM0ICAgICA0NyAgICAgIDAgIDAgICAgICAwIC91c3Ivc3Jj L3N5cy9rZXJuL3Zmc19oYXNoLmM6MTE0IChzbGVlcCBtdXRleDp2ZnMgaGFzaCkKICAgICAgOTUg ICAgICAgICAwICAgICAgICAgMzU5ICAgICAgICAgICAwICAgICAgICAgICA0ICAgICA4OSAgICAg IDAgIDAgICAgICAwIC91c3Ivc3JjL3N5cy92bS91bWFfY29yZS5jOjIwMzQgKHNsZWVwIG11dGV4 OnBpcGUpCiAgICAgIDg5ICAgICAgICAgMCAgICAgICAgICA4OSAgICAgICAgICAgMCAgICAgICAg ICAgMSAgICAgODkgICAgICAwICAwICAgICAgMCAvdXNyL3NyYy9zeXMva2Vybi92ZnNfc3lzY2Fs bHMuYzo4NDEgKHN4OmZpbGVkZXNjIHN0cnVjdHVyZSkKICAgICA2MjQgICAgICAgICAwICAgICAg ICAzODQ0ICAgICAgICAgICAwICAgICAgICAgIDI1ICAgIDE1MyAgICAgIDAgIDAgICAgICAwIC91 c3Ivc3JjL3N5cy91ZnMvZmZzL2Zmc19zb2Z0ZGVwLmM6NjQ1IChzbGVlcCBtdXRleDpTb2Z0ZGVw IExvY2spCiAgICAgNDQ3ICAgICAgICAgMCAgICAgICAgMzIzOSAgICAgICAgICAgMCAgICAgICAg ICA0NCAgICAgNzMgICAgICAwICAwICAgICAgMCAvdXNyL3NyYy9zeXMvdm0vdW1hX2NvcmUuYzox OTkwIChzbGVlcCBtdXRleDpTIFZGUyBDYWNoZSkKICAgIDEwNzggICAgICAgICAwICAgICAgICAx MDc4ICAgICAgICAgICAwICAgICAgICAgICAxICAgMTA3OCAgICAgIDAgIDAgICAgICAwIC91c3Iv c3JjL3N5cy91ZnMvdWZzL3Vmc19kaXJoYXNoLmM6MjI1IChzeDpkaXJoYXNoKQogICAgICA4NyAg ICAgICAgIDAgICAgICAgICAxNzMgICAgICAgICAgIDAgICAgICAgICAgIDIgICAgIDg2ICAgICAg MCAgMCAgICAgIDAgL3Vzci9zcmMvc3lzL2tlcm4vdWlwY19zb2NrYnVmLmM6Mjk2IChzbGVlcCBt dXRleDpwcm9jZXNzIGxvY2spCiAgICAgOTM3ICAgICAgICAgMCAgICAgICA3OTQ5NiAgICAgICAg ICAgMCAgICAgICAgIDQwOSAgICAxOTQgICAgICAwICAwICAgICAgMCAvdXNyL3NyYy9zeXMvdm0v dW1hX2NvcmUuYzoyNDY0IChzbGVlcCBtdXRleDpVTUEgUkNudFNsYWJzKQogICAgICA5MSAgICAg ICAgIDAgICAgICAgICAgOTEgICAgICAgICAgIDAgICAgICAgICAgIDEgICAgIDkxICAgICAgMCAg MCAgICAgIDAgL3Vzci9zcmMvc3lzL2tlcm4vdWlwY191c3JyZXEuYzozNzIgKHJ3OnVucF9nbG9i YWxfcndsb2NrKQogICAgICA5MSAgICAgICAgIDAgICAgICAgICA2NTAgICAgICAgICAgIDAgICAg ICAgICAgMTAgICAgIDY1ICAgICAgMCAgMCAgICAgIDAgL3Vzci9zcmMvc3lzL3ZtL3VtYV9jb3Jl LmM6MjAzNCAoc2xlZXAgbXV0ZXg6UyBWRlMgQ2FjaGUpCiAgICAgNDcwICAgICAgICAgMCAgICAg ICAgIDQ3MCAgICAgICAgICAgMCAgICAgICAgICAgMSAgICA0NzAgICAgICAwICAwICAgICAgMCAv dXNyL3NyYy9zeXMva2Vybi9rZXJuX3Jlc291cmNlLmM6MTIwMyAocnc6dWlkaW5mbyBoYXNoKQog ICAgICA5MyAgICAgICAgIDAgICAgICAgIDEzMDcgICAgICAgICAgIDAgICAgICAgICAgMzQgICAg IDM4ICAgICAgMCAgMCAgICAgIDAgL3Vzci9zcmMvc3lzL3Vmcy9mZnMvZmZzX3NvZnRkZXAuYzo0 ODc2IChzbGVlcCBtdXRleDpTb2Z0ZGVwIExvY2spCiAgICAgMTc5ICAgICAgICAgMCAgICAgICAg IDE3OSAgICAgICAgICAgMCAgICAgICAgICAgMSAgICAxNzkgICAgICAwICAwICAgICAgMCAvdXNy L3NyYy9zeXMva2Vybi91aXBjX3VzcnJlcS5jOjUwNiAocnc6dW5wX2dsb2JhbF9yd2xvY2spCiAg ICAgOTYwICAgICAgICAgMCAgICAgICAgIDk2MCAgICAgICAgICAgMCAgICAgICAgICAgMSAgICA5 NjAgICAgICAwICAwICAgICAgMCAvdXNyL3NyYy9zeXMva2Vybi91aXBjX3NvY2tidWYuYzoyMzUg KHNsZWVwIG11dGV4OnNvX3NuZCkKICAgICA3NzkgICAgICAgICAwICAgICAgICAgNzc5ICAgICAg ICAgICAwICAgICAgICAgICAxICAgIDc3OSAgICAgIDAgIDAgICAgICAwIC91c3Ivc3JjL3N5cy9r ZXJuL3VpcGNfdXNycmVxLmM6NTIwIChydzp1bnBfZ2xvYmFsX3J3bG9jaykKICAgICAxNzUgICAg ICAgICAwICAgICAgICAgMTc1ICAgICAgICAgICAwICAgICAgICAgICAxICAgIDE3NSAgICAgIDAg IDAgICAgICAwIC91c3Ivc3JjL3N5cy9rZXJuL3VpcGNfdXNycmVxLmM6NTYzIChydzp1bnBfZ2xv YmFsX3J3bG9jaykKICAgICA2MzcgICAgICAgICAwICAgICAgICAxOTQyICAgICAgICAgICAwICAg ICAgICAgIDExICAgIDE3NiAgICAgIDAgIDAgICAgICAwIC91c3Ivc3JjL3N5cy92bS91bWFfY29y ZS5jOjIwMzQgKHNsZWVwIG11dGV4Om1idWYpCiAgICA1MDQ5ICAgICAgICAgMCAgICAgICAyNjMy NSAgICAgICAgICAgMCAgICAgICAgICAgNiAgIDQzODcgICAgICAwICAwICAgICAgMCAvdXNyL3Ny Yy9zeXMvdWZzL3Vmcy91ZnNfdm5vcHMuYzoxMDc5IChsb2NrbWdyOnVmcykKICAgICAgOTEgICAg ICAgICAwICAgICAgICAgIDkxICAgICAgICAgICAwICAgICAgICAgICAxICAgICA5MSAgICAgIDAg IDAgICAgICAwIC91c3Ivc3JjL3N5cy9rZXJuL2tlcm5fcHJvdC5jOjQ4OCAoc2xlZXAgbXV0ZXg6 cHJvY2VzcyBsb2NrKQogICAgIDQzMyAgICAgICAgIDAgICAgICAgIDEyNTggICAgICAgICAgIDAg ICAgICAgICAgMTAgICAgMTI1ICAgICAgMCAgMCAgICAgIDAgL3Vzci9zcmMvc3lzL3ZtL3VtYV9j b3JlLmM6OTE0IChzbGVlcCBtdXRleDpGRlMgaW5vZGUpCiAgICAgOTM2ICAgICAgICAgMCAgICAg ICA3ODY3MiAgICAgICAgICAgMCAgICAgICAgIDQwOSAgICAxOTIgICAgICAwICAwICAgICAgMCAv dXNyL3NyYy9zeXMvdm0vdW1hX2NvcmUuYzo5MTQgKHNsZWVwIG11dGV4Om1idWZfY2x1c3RlcikK ICAgICA5NjggICAgICAgNDQ4ICAgICAgIDEzNTUwICAgICAgICAgNDQ4ICAgICAgICAgIDY4ICAg IDE5OSAgICAgIDYgIDAgICAgICAxIC91c3Ivc3JjL3N5cy92bS91bWFfY29yZS5jOjkxNCAoc2xl ZXAgbXV0ZXg6YXRhX3JlcXVlc3QpCiAgICAgIDkzICAgICAgICAgMCAgICAgICAgICA5MyAgICAg ICAgICAgMCAgICAgICAgICAgMSAgICAgOTMgICAgICAwICAwICAgICAgMCAvdXNyL3NyYy9zeXMv dm0vdW1hX2NvcmUuYzoyMzU1IChzbGVlcCBtdXRleDpwaXBlKQogICAgIDk2OCAgICAgICAgIDAg ICAgICAgICA5NjggICAgICAgICAgIDAgICAgICAgICAgIDEgICAgOTY4ICAgICAgMCAgMCAgICAg IDAgL3Vzci9zcmMvc3lzL2tlcm4vdWlwY191c3JyZXEuYzo2MjggKHJ3OnVucF9nbG9iYWxfcnds b2NrKQogICAgIDQ2NyAgICAgICAgIDAgICAgICAgIDI5NTQgICAgICAgICAgIDAgICAgICAgICAg MjYgICAgMTEzICAgICAgMCAgMCAgICAgIDAgL3Vzci9zcmMvc3lzL3ZtL3VtYV9jb3JlLmM6OTE0 IChzbGVlcCBtdXRleDpWTk9ERSkKICAgICAzNTAgICAgICAgICAwICAgICAgICAgMzUwICAgICAg ICAgICAwICAgICAgICAgICAxICAgIDM1MCAgICAgIDAgIDAgICAgICAwIC91c3Ivc3JjL3N5cy91 ZnMvZmZzL2Zmc192bm9wcy5jOjIzNCAobG9ja21ncjpidWZ3YWl0KQogICAgIDYxMCAgICAgICAg IDAgICAgICAgICA2MTAgICAgICAgICAgIDAgICAgICAgICAgIDEgICAgNjEwICAgICAgMCAgMCAg ICAgIDAgL3Vzci9zcmMvc3lzL2tlcm4vdWlwY19zb2NrZXQuYzo2OTAgKHNsZWVwIG11dGV4OmFj Y2VwdCkKICAgICAgODUgICAgICAgICAwICAgICAgICAgMTY2ICAgICAgICAgICAwICAgICAgICAg ICAyICAgICA4MyAgICAgIDAgIDAgICAgICAwIC91c3Ivc3JjL3N5cy9rZXJuL2tlcm5fcHJvdC5j OjYwMCAoc2xlZXAgbXV0ZXg6cHJvY2VzcyBsb2NrKQogICAgIDQ5NSAgICAgICAgIDAgICAgICAg ICA3MDkgICAgICAgICAgIDAgICAgICAgICAgIDMgICAgMjM2ICAgICAgMCAgMCAgICAgIDAgL3Vz ci9zcmMvc3lzL3ZtL3VtYV9jb3JlLmM6MjM1NSAoc2xlZXAgbXV0ZXg6UFJPQykKICAgICAgOTIg ICAgICAgICAwICAgICAgICAgMzAzICAgICAgICAgICAwICAgICAgICAgICA0ICAgICA3NSAgICAg IDAgIDAgICAgICAwIC91c3Ivc3JjL3N5cy92bS91bWFfY29yZS5jOjIzNTUgKHNsZWVwIG11dGV4 OlMgVkZTIENhY2hlKQogICAgIDQzOCAgICAgICAgIDAgICAgICAgICA0MzggICAgICAgICAgIDAg ICAgICAgICAgIDEgICAgNDM4ICAgICAgMCAgMCAgICAgIDAgL3Vzci9zcmMvc3lzL2tlcm4vdWlw Y19zb2NrYnVmLmM6MjM2IChzbGVlcCBtdXRleDpzb19yY3YpCiAgICAgIDg5ICAgICAgICAgMCAg ICAgICAgICA4OSAgICAgICAgICAgMCAgICAgICAgICAgMSAgICAgODkgICAgICAwICAwICAgICAg MCAvdXNyL3NyYy9zeXMva2Vybi9rZXJuX3Byb3QuYzo2NTMgKHNsZWVwIG11dGV4OnByb2Nlc3Mg bG9jaykKICAgIDIwNTMgICAgICAgICAwICAgICAgICAyMDUzICAgICAgICAgICAwICAgICAgICAg ICAxICAgMjA1MyAgICAgIDAgIDAgICAgICAwIC91c3Ivc3JjL3N5cy9rZXJuL3VpcGNfdXNycmVx LmM6NzczIChydzp1bnBfZ2xvYmFsX3J3bG9jaykKICAgIDMyMjUgICAgICAgICAwICAgICAgICA4 MjIwICAgICAgICAgICAwICAgICAgICAgICAzICAgMjc0MCAgICAgIDAgIDAgICAgICAwIC91c3Iv c3JjL3N5cy9rZXJuL3Zmc192bm9wcy5jOjI5MyAobG9ja21ncjpkZXZmcykKICAgICAgODYgICAg ICAgICAwICAgICAgICAgMTY3ICAgICAgICAgICAwICAgICAgICAgICAyICAgICA4MyAgICAgIDAg IDAgICAgICAwIC91c3Ivc3JjL3N5cy9rZXJuL2tlcm5fcHJvdC5jOjc1MiAoc2xlZXAgbXV0ZXg6 cHJvY2VzcyBsb2NrKQogICAgIDYyMCAgICAgICAgIDAgICAgICAgIDExNDUgICAgICAgICAgIDAg ICAgICAgICAgIDMgICAgMzgxICAgICAgMCAgMCAgICAgIDAgL3Vzci9zcmMvc3lzL2ZzL2RldmZz L2RldmZzX3Zub3BzLmM6NTA3IChzbGVlcCBtdXRleDp2bm9kZSBpbnRlcmxvY2spCiAgICAgNjM0 ICAgICAgICAgMCAgICAgICAgMjc3MyAgICAgICAgICAgMCAgICAgICAgICAxNSAgICAxODQgICAg ICAwICAwICAgICAgMCAvdXNyL3NyYy9zeXMva2Vybi9zeXNfcGlwZS5jOjEyNzUgKHNsZWVwIG11 dGV4OnBpcGUgbXV0ZXgpCiAgICAgNjcxICAgICAgICAgMCAgICAgICAgNjk2NSAgICAgICAgICAg MCAgICAgICAgICA0NiAgICAxNTEgICAgICAwICAwICAgICAgMCAvdXNyL3NyYy9zeXMvdm0vdW1h X2NvcmUuYzoyNTI0IChzbGVlcCBtdXRleDpQUk9DKQogICAgIDYzMCAgICAgICAgIDAgICAgICAg IDI5MTAgICAgICAgICAgIDAgICAgICAgICAgMTUgICAgMTk0ICAgICAgMCAgMCAgICAgIDAgL3Vz ci9zcmMvc3lzL3ZtL3VtYV9jb3JlLmM6MjUyNCAoc2xlZXAgbXV0ZXg6UyBWRlMgQ2FjaGUpCiAg ICAgIDg1ICAgICAgICAgMCAgICAgICAgICA4NSAgICAgICAgICAgMCAgICAgICAgICAgMSAgICAg ODUgICAgICAwICAwICAgICAgMCAvdXNyL3NyYy9zeXMva2Vybi9rZXJuX3Byb3QuYzo4MTQgKHNs ZWVwIG11dGV4OnByb2Nlc3MgbG9jaykKICAgICAxNDAgICAgICAgICAwICAgICAgICAgNDE0ICAg ICAgICAgICAwICAgICAgICAgICA0ICAgIDEwMyAgICAgIDAgIDAgICAgICAwIC91c3Ivc3JjL3N5 cy92bS91bWFfY29yZS5jOjkxNCAoc2xlZXAgbXV0ZXg6MzIgQnVja2V0KQogICAgIDYyOCAgICAg ICAgIDAgICAgICAgIDMxMDAgICAgICAgICAgIDAgICAgICAgICAgMTYgICAgMTkzICAgICAgMCAg MCAgICAgIDAgL3Vzci9zcmMvc3lzL3Vmcy9mZnMvZmZzX3Zub3BzLmM6MjE2IChzbGVlcCBtdXRl eDpidWZvYmogaW50ZXJsb2NrKQogICAgIDYxNCAgICAgICAgIDAgICAgICAgIDE0MDMgICAgICAg ICAgIDAgICAgICAgICAgIDYgICAgMjMzICAgICAgMCAgMCAgICAgIDAgL3Vzci9zcmMvc3lzL3Zt L3VtYV9jb3JlLmM6MjYwMiAoc2xlZXAgbXV0ZXg6UFJPQykKICAgICAgOTUgICAgICAgICAwICAg ICAgICAgNTM1ICAgICAgICAgICAwICAgICAgICAgICA2ICAgICA4OSAgICAgIDAgIDAgICAgICAw IC91c3Ivc3JjL3N5cy92bS91bWFfY29yZS5jOjI2MDIgKHNsZWVwIG11dGV4OlMgVkZTIENhY2hl KQogICAgIDU2MCAgICAgICAgIDAgICAgICAgICA5ODAgICAgICAgICAgIDAgICAgICAgICAgIDUg ICAgMTk2ICAgICAgMCAgMCAgICAgIDAgL3Vzci9zcmMvc3lzL3ZtL3VtYV9jb3JlLmM6MjQyNCAo c2xlZXAgbXV0ZXg6bWJ1ZikKICAgICA2MTIgICAgICAgICAwICAgICAgICAgNzAwICAgICAgICAg ICAwICAgICAgICAgICAyICAgIDM1MCAgICAgIDAgIDAgICAgICAwIC91c3Ivc3JjL3N5cy91ZnMv ZmZzL2Zmc192bm9wcy5jOjI0MiAoc2xlZXAgbXV0ZXg6YnVmb2JqIGludGVybG9jaykKICAgICA0 NjIgICAgICAgICAwICAgICAgICAxNjY4ICAgICAgICAgICAwICAgICAgICAgICA4ICAgIDIwOCAg ICAgIDAgIDAgICAgICAwIC91c3Ivc3JjL3N5cy91ZnMvZmZzL2Zmc19zb2Z0ZGVwLmM6MTMwMiAo c2xlZXAgbXV0ZXg6U29mdGRlcCBMb2NrKQogICAgICA5MyAgICAgICAgIDAgICAgICAgICAyNjcg ICAgICAgICAgIDAgICAgICAgICAgIDMgICAgIDg5ICAgICAgMCAgMCAgICAgIDAgL3Vzci9zcmMv c3lzL3ZtL3VtYV9jb3JlLmM6MjY2MSAoc2xlZXAgbXV0ZXg6UFJPQykKICAgICAgOTMgICAgICAg ICAwICAgICAgICAgMjU4ICAgICAgICAgICAwICAgICAgICAgICAzICAgICA4NiAgICAgIDAgIDAg ICAgICAwIC91c3Ivc3JjL3N5cy92bS91bWFfY29yZS5jOjI2NjEgKHNsZWVwIG11dGV4OlMgVkZT IENhY2hlKQogICAgIDQ3NyAgICAgICAgIDAgICAgICAgICA3NjcgICAgICAgICAgIDAgICAgICAg ICAgIDQgICAgMTkxICAgICAgMCAgMCAgICAgIDAgL3Vzci9zcmMvc3lzL3Vmcy9mZnMvZmZzX3Zu b3BzLmM6MjkxIChzbGVlcCBtdXRleDpidWZvYmogaW50ZXJsb2NrKQogICAgMTg3NSAgICAgICAg IDAgICAgICAgIDgxOTkgICAgICAgICAgIDAgICAgICAgICAgMTEgICAgNzQ1ICAgICAgMCAgMCAg ICAgIDAgL3Vzci9zcmMvc3lzL2tlcm4vc3Vicl90cmFwLmM6MjIzIChzbGVlcCBtdXRleDpwcm9j ZXNzIGxvY2spCiAgICAgIDg3ICAgICAgICAgMCAgICAgICAgICA4NyAgICAgICAgICAgMCAgICAg ICAgICAgMSAgICAgODcgICAgICAwICAwICAgICAgMCAvdXNyL3NyYy9zeXMvdm0vdW1hX2NvcmUu YzoxOTkwIChzbGVlcCBtdXRleDpzb2NrZXQpCiAgICAgIDk1ICAgICAgICAgMCAgICAgICAgICA5 NSAgICAgICAgICAgMCAgICAgICAgICAgMSAgICAgOTUgICAgICAwICAwICAgICAgMCAvdXNyL3Ny Yy9zeXMva2Vybi92ZnNfYmlvLmM6Mjg5NCAoc2xlZXAgbXV0ZXg6dm0gcGFnZSBxdWV1ZSBtdXRl eCkKICAgICA0OTEgICAgICAgICAwICAgICAgICAgNTc4ICAgICAgICAgICAwICAgICAgICAgICAy ICAgIDI4OSAgICAgIDAgIDAgICAgICAwIC91c3Ivc3JjL3N5cy92bS91bWFfY29yZS5jOjIwMzQg KHNsZWVwIG11dGV4OnNvY2tldCkKICAgICA2NDggICAgICAgICAwICAgICAgICAyODg0ICAgICAg ICAgICAwICAgICAgICAgIDEyICAgIDI0MCAgICAgIDAgIDAgICAgICAwIC91c3Ivc3JjL3N5cy92 bS91bWFfY29yZS5jOjI2MDIgKHNsZWVwIG11dGV4Om1idWYpCiAgICAgNDMzICAgICAgICAgMCAg ICAgICAgIDQzMyAgICAgICAgICAgMCAgICAgICAgICAgMSAgICA0MzMgICAgICAwICAwICAgICAg MCAvdXNyL3NyYy9zeXMva2Vybi91aXBjX3N5c2NhbGxzLmM6NTY3IChzbGVlcCBtdXRleDpzb19y Y3YpCiAgNDU3NzQwICAgICAgICAgMCAgICAgMjYwMTU3MyAgICAgICAgICAgMCAgICAgICAgICAx OCAxNDQ1MzEgICAgICAwICAwICAgICAgMCAvdXNyL3NyYy9zeXMva2Vybi92ZnNfc3Vici5jOjE3 MDIgKGxvY2ttZ3I6c3luY2VyKQogICAgICA5MiAgICAgICAgIDAgICAgICAgICAgOTIgICAgICAg ICAgIDAgICAgICAgICAgIDEgICAgIDkyICAgICAgMCAgMCAgICAgIDAgL3Vzci9zcmMvc3lzL3Vm cy91ZnMvdWZzX2Rpcmhhc2guYzo1NTMgKHNsZWVwIG11dGV4OmRpcmhhc2ggbGlzdCkKICAgICAy NzYgICAgICAgICAwICAgICAgICAgMjc2ICAgICAgICAgICAwICAgICAgICAgICAxICAgIDI3NiAg ICAgIDAgIDAgICAgICAwIC91c3Ivc3JjL3N5cy9rZXJuL2tlcm5fcmVzb3VyY2UuYzoxODggKHNs ZWVwIG11dGV4OnByb2Nlc3MgbG9jaykKICAgICAgOTggICAgICAgICAwICAgICAgICAgMjcyICAg ICAgICAgICAwICAgICAgICAgICAzICAgICA5MCAgICAgIDAgIDAgICAgICAwIC91c3Ivc3JjL3N5 cy92bS91bWFfY29yZS5jOjIzNTUgKHNsZWVwIG11dGV4OlNMRUVQUVVFVUUpCiAgICAgNzAwICAg ICAgICAgMCAgICAgICAgMTE4NyAgICAgICAgICAgMCAgICAgICAgICAgNiAgICAxOTcgICAgICAw ICAwICAgICAgMCAvdXNyL3NyYy9zeXMvdm0vdW1hX2NvcmUuYzoyNjYxIChzbGVlcCBtdXRleDpt YnVmKQogICAgMjczMSAgICAgICAgIDAgICAgICAgIDI3MzEgICAgICAgICAgIDAgICAgICAgICAg IDEgICAyNzMxICAgICAgMCAgMCAgICAgIDAgL3Vzci9zcmMvc3lzL2tlcm4vdWlwY191c3JyZXEu YzoxMTk3IChydzp1bnBfZ2xvYmFsX3J3bG9jaykKICAgICA0MzYgICAgICAgICAwICAgICAgICAx MjM2ICAgICAgICAgICAwICAgICAgICAgIDEwICAgIDEyMyAgICAgIDAgIDAgICAgICAwIC91c3Iv c3JjL3N5cy92bS91bWFfY29yZS5jOjkxNCAoc2xlZXAgbXV0ZXg6RkZTMiBkaW5vZGUpCiAgICAg Mjg0ICAgICAgICAgMCAgICAgICAgIDI4NCAgICAgICAgICAgMCAgICAgICAgICAgMSAgICAyODQg ICAgICAwICAwICAgICAgMCAvdXNyL3NyYy9zeXMva2Vybi91aXBjX3VzcnJlcS5jOjEyODcgKHJ3 OnVucF9nbG9iYWxfcndsb2NrKQogICAgIDQ3MSAgICAgICAgIDAgICAgICAgIDI0NDYgICAgICAg ICAgIDAgICAgICAgICAgMzkgICAgIDYyICAgICAgMCAgMCAgICAgIDAgL3Vzci9zcmMvc3lzL3Vm cy9mZnMvZmZzX3NvZnRkZXAuYzo1NzQ3IChzbGVlcCBtdXRleDpTb2Z0ZGVwIExvY2spCiAgIDY0 MzA3ICAgICAgICAgMCAgICAgIDE0NTYwNSAgICAgICAgICAgMCAgICAgICAgICAzNCAgIDQyODIg ICAgICAwICAwICAgICAgMCAvdXNyL3NyYy9zeXMvdWZzL2Zmcy9mZnNfdmZzb3BzLmM6MTQ2MiAo bG9ja21ncjp1ZnMpCiAgICAgNjIwICAgICAgICAgMCAgICAgICAgMTI4OCAgICAgICAgICAgMCAg ICAgICAgICAgNSAgICAyNTcgICAgICAwICAwICAgICAgMCAvdXNyL3NyYy9zeXMva2Vybi92ZnNf c3Vici5jOjMyNTUgKHNsZWVwIG11dGV4OnZub2RlX2ZyZWVfbGlzdCkKICAgICA2MTEgICAgICAg NDg5ICAgICAgICA2MDY0ICAgICAgICAgOTU3ICAgICAgICAgIDY2ICAgICA5MSAgICAgMTQgIDAg ICAgICA1IC91c3Ivc3JjL3N5cy9rZXJuL3Zmc19iaW8uYzoxMzIzIChzbGVlcCBtdXRleDpidWYg cXVldWUgbG9jaykKICAgICAgOTEgICAgICAgICAwICAgICAgICAgIDkxICAgICAgICAgICAwICAg ICAgICAgICAxICAgICA5MSAgICAgIDAgIDAgICAgICAwIC91c3Ivc3JjL3N5cy92bS91bWFfY29y ZS5jOjIzNTUgKHNsZWVwIG11dGV4OnNvY2tldCkKICAgICA2NDAgICAgICAgICAwICAgICAgICA1 MDU5ICAgICAgICAgICAwICAgICAgICAgIDM3ICAgIDEzNiAgICAgIDAgIDAgICAgICAwIC91c3Iv c3JjL3N5cy92bS91bWFfY29yZS5jOjkxNCAoc2xlZXAgbXV0ZXg6MTI4IEJ1Y2tldCkKICAgICA2 MzUgICAgICAgICAwICAgICAgICAyNTAxICAgICAgICAgICAwICAgICAgICAgIDEwICAgIDI1MCAg ICAgIDAgIDAgICAgICAwIC91c3Ivc3JjL3N5cy9rZXJuL2tlcm5fZm9yay5jOjMzNyAoc2xlZXAg bXV0ZXg6cHJvY2VzcyBsb2NrKQogICAgICA4OSAgICAgICAgIDAgICAgICAgICAgODkgICAgICAg ICAgIDAgICAgICAgICAgIDEgICAgIDg5ICAgICAgMCAgMCAgICAgIDAgL3Vzci9zcmMvc3lzL2tl cm4vdWlwY19zb2NrZXQuYzoyODQgKHNsZWVwIG11dGV4OnNvX2dsYWJlbCkKICAgICAgOTEgICAg ICAgICAwICAgICAgICAgIDkxICAgICAgICAgICAwICAgICAgICAgICAxICAgICA5MSAgICAgIDAg IDAgICAgICAwIC91c3Ivc3JjL3N5cy92bS91bWFfY29yZS5jOjkxNCAoc2xlZXAgbXV0ZXg6dW5w Y2IpCiAgICAgIDg4ICAgICAgICAgMCAgICAgICAgICA4OCAgICAgICAgICAgMCAgICAgICAgICAg MSAgICAgODggICAgICAwICAwICAgICAgMCAvdXNyL3NyYy9zeXMvdWZzL3Vmcy91ZnNfZGlyaGFz aC5jOjIxMiAoc2xlZXAgbXV0ZXg6dm5vZGUgaW50ZXJsb2NrKQogICAgIDQ0MyAgICAgICAgIDAg ICAgICAgICA0NDMgICAgICAgICAgIDAgICAgICAgICAgIDEgICAgNDQzICAgICAgMCAgMCAgICAg IDAgL3Vzci9zcmMvc3lzL2tlcm4vdWlwY19zb2NrZXQuYzozMDMgKHNsZWVwIG11dGV4OnNvX2ds YWJlbCkKICAgICAgODcgICAgICAgICAwICAgICAgICAgIDg3ICAgICAgICAgICAwICAgICAgICAg ICAxICAgICA4NyAgICAgIDAgIDAgICAgICAwIC91c3Ivc3JjL3N5cy92bS91bWFfY29yZS5jOjI1 MjQgKHNsZWVwIG11dGV4OnNvY2tldCkKICAgICAgNzggICAgICAgICAwICAgICAgICAgIDc4ICAg ICAgICAgICAwICAgICAgICAgICAxICAgICA3OCAgICAgIDAgIDAgICAgICAwIC91c3Ivc3JjL3N5 cy91ZnMvdWZzL3Vmc19kaXJoYXNoLmM6MjI4IChzbGVlcCBtdXRleDp2bm9kZSBpbnRlcmxvY2sp CiAgICAgNDM5ICAgICAgICAgMCAgICAgICAgIDYxNCAgICAgICAgICAgMCAgICAgICAgICAgMyAg ICAyMDQgICAgICAwICAwICAgICAgMCAvdXNyL3NyYy9zeXMvdWZzL2Zmcy9mZnNfc29mdGRlcC5j OjYwNjggKHNsZWVwIG11dGV4OlNvZnRkZXAgTG9jaykKICAgICA0NDQgICAgICAgICAwICAgICAg ICAxNDE3ICAgICAgICAgICAwICAgICAgICAgIDEyICAgIDExOCAgICAgIDAgIDAgICAgICAwIC91 c3Ivc3JjL3N5cy9rZXJuL2tlcm5fcmVzb3VyY2UuYzo2NzEgKHNsZWVwIG11dGV4OnByb2Nlc3Mg bG9jaykKICAgICAgODkgICAgICAgICAwICAgICAgICAgMTc1ICAgICAgICAgICAwICAgICAgICAg ICAyICAgICA4NyAgICAgIDAgIDAgICAgICAwIC91c3Ivc3JjL3N5cy92bS91bWFfY29yZS5jOjI2 MDIgKHNsZWVwIG11dGV4OnNvY2tldCkKICAgICAgOTMgICAgICAgICAwICAgICAgICAxMzEzICAg ICAgICAgICAwICAgICAgICAgIDM0ICAgICAzOCAgICAgIDAgIDAgICAgICAwIC91c3Ivc3JjL3N5 cy92bS91bWFfY29yZS5jOjE5OTAgKHNsZWVwIG11dGV4OkZGUyBpbm9kZSkKICAgICA5MDYgICAg ICAgICAwICAgICAgMTIyNzQ2ICAgICAgICAgICAwICAgICAgICAgNjQwICAgIDE5MSAgICAgIDAg IDAgICAgICAwIC91c3Ivc3JjL3N5cy92bS91bWFfY29yZS5jOjE5OTAgKHNsZWVwIG11dGV4Om1i dWZfY2x1c3RlcikKICAgICA0NTEgICAgICAgICAwICAgICAgICAxOTMyICAgICAgICAgICAwICAg ICAgICAgIDM0ICAgICA1NiAgICAgIDAgIDAgICAgICAwIC91c3Ivc3JjL3N5cy92bS91bWFfY29y ZS5jOjE5OTAgKHNsZWVwIG11dGV4OlZOT0RFKQogICAgIDQ5MyAgICAgICAgIDAgICAgICAgIDIx ODggICAgICAgICAgIDAgICAgICAgICAgMTAgICAgMjE4ICAgICAgMCAgMCAgICAgIDAgL3Vzci9z cmMvc3lzL3ZtL3VtYV9jb3JlLmM6MjAzNCAoc2xlZXAgbXV0ZXg6RkZTIGlub2RlKQogICAgIDg1 NyAgICAgICAgIDAgICAgICAgIDYyOTkgICAgICAgICAgIDAgICAgICAgICAgMjggICAgMjI0ICAg ICAgMCAgMCAgICAgIDAgL3Vzci9zcmMvc3lzL3ZtL3VtYV9jb3JlLmM6MjAzNCAoc2xlZXAgbXV0 ZXg6bWJ1Zl9jbHVzdGVyKQogICAgICA4NSAgICAgICAgIDAgICAgICAgICAgODUgICAgICAgICAg IDAgICAgICAgICAgIDEgICAgIDg1ICAgICAgMCAgMCAgICAgIDAgL3Vzci9zcmMvc3lzL3ZtL3Vt YV9jb3JlLmM6MjY2MSAoc2xlZXAgbXV0ZXg6c29ja2V0KQogICAgIDkyNyAgICAgICAgIDAgICAg ICAgMjYyNDAgICAgICAgICAgIDAgICAgICAgICAxNzcgICAgMTQ4ICAgICAgMCAgMCAgICAgIDAg L3Vzci9zcmMvc3lzL3ZtL3VtYV9jb3JlLmM6MjAzNCAoc2xlZXAgbXV0ZXg6YXRhX3JlcXVlc3Qp CiAgICAgNDk2ICAgICAgICAgMCAgICAgICAgMTY4NSAgICAgICAgICAgMCAgICAgICAgICAxMiAg ICAxNDAgICAgICAwICAwICAgICAgMCAvdXNyL3NyYy9zeXMvdm0vdW1hX2NvcmUuYzoyMDM0IChz bGVlcCBtdXRleDpWTk9ERSkKICAgICA2MTUgICAgICAgICAwICAgICAgICAyODM5ICAgICAgICAg ICAwICAgICAgICAgIDEyICAgIDIzNiAgICAgIDAgIDAgICAgICAwIC91c3Ivc3JjL3N5cy9rZXJu L2tlcm5fcmVzb3VyY2UuYzo3ODggKHNsZWVwIG11dGV4OnByb2Nlc3MgbG9jaykKICAgICA5OTgg ICAgICAgICAwICAgICAgICAyNTk2ICAgICAgICAgICAwICAgICAgICAgIDExICAgIDIzNiAgICAg IDAgIDAgICAgICAwIC91c3Ivc3JjL3N5cy9rZXJuL3N1YnJfdHJhcC5jOjIyNCAoc2xlZXAgbXV0 ZXg6c2lnYWN0cykKICAgICA5ODggICAgICAgICAwICAgICAgIDE2MjIzICAgICAgICAgICAwICAg ICAgICAgIDY2ICAgIDI0NSAgICAgIDAgIDAgICAgICAwIC91c3Ivc3JjL3N5cy9uZXRpbmV0L3Vk cF91c3JyZXEuYzozOTYgKHJ3OnVkcCkKICAgICA0NTcgICAgICAgICAwICAgICAgICA2MDU2ICAg ICAgICAgICAwICAgICAgICAgIDY1ICAgICA5MyAgICAgIDAgIDAgICAgICAwIC91c3Ivc3JjL3N5 cy9rZXJuL3Zmc19iaW8uYzoxMjUwIChzbGVlcCBtdXRleDp2bSBvYmplY3QpCiAgICAgNzQyICAg ICAgICAgMCAgICAgICAgNDg4MSAgICAgICAgICAgMCAgICAgICAgICAxOCAgICAyNzEgICAgICAw ICAwICAgICAgMCAvdXNyL3NyYy9zeXMva2Vybi92ZnNfc3Vici5jOjM0NDMgKHNsZWVwIG11dGV4 OnN0cnVjdCBtb3VudCBtdHgpCiAgICAgMTMwICAgICAgICAgMCAgICAgICAgIDM4OCAgICAgICAg ICAgMCAgICAgICAgICAgNCAgICAgOTcgICAgICAwICAwICAgICAgMCAvdXNyL3NyYy9zeXMvdm0v dm1fb2JqZWN0LmM6MTM1OCAoc2xlZXAgbXV0ZXg6dm0gcGFnZSBxdWV1ZSBtdXRleCkKICAgICA0 NzkgICAgICAgICAwICAgICAgICAxNjI1ICAgICAgICAgICAwICAgICAgICAgIDE1ICAgIDEwOCAg ICAgIDAgIDAgICAgICAwIC91c3Ivc3JjL3N5cy92bS91bWFfY29yZS5jOjI1MjQgKHNsZWVwIG11 dGV4OjEyOCkKICAgIDEzNzAgICAgICAgICAwICAgICAgICA0NDg0ICAgICAgICAgICAwICAgICAg ICAgIDQ0ICAgIDEwMSAgICAgIDAgIDAgICAgICAwIC91c3Ivc3JjL3N5cy9rZXJuL3Zmc19jYWNo ZS5jOjU2OSAocnc6TmFtZSBDYWNoZSkKICAgICA0MzkgICAgICAgICAwICAgICAgICAxMTM0ICAg ICAgICAgICAwICAgICAgICAgICA3ICAgIDE2MiAgICAgIDAgIDAgICAgICAwIC91c3Ivc3JjL3N5 cy9rZXJuL2tlcm5fcHJvdC5jOjE5MDkgKHNsZWVwIG11dGV4OnByb2Nlc3MgbG9jaykKICAgICAx MTkgICAgICAgICAwICAgICAgICAgMzI3ICAgICAgICAgICAwICAgICAgICAgICA0ICAgICA4MSAg ICAgIDAgIDAgICAgICAwIC91c3Ivc3JjL3N5cy92bS91bWFfY29yZS5jOjIzNTUgKHNsZWVwIG11 dGV4OkZGUyBpbm9kZSkKICAgICA0NDUgICAgICAgICAwICAgICAgICAxMTYyICAgICAgICAgICAw ICAgICAgICAgICA1ICAgIDIzMiAgICAgIDAgIDAgICAgICAwIC91c3Ivc3JjL3N5cy92bS91bWFf Y29yZS5jOjIzNTUgKHNsZWVwIG11dGV4Om1idWZfY2x1c3RlcikKICAgICA2NTggICAgICAgICAw ICAgICAgICAgNjU4ICAgICAgICAgICAwICAgICAgICAgICAxICAgIDY1OCAgICAgIDAgIDAgICAg ICAwIC91c3Ivc3JjL3N5cy9rZXJuL2tlcm5fcHJvdC5jOjE5NjcgKHNsZWVwIG11dGV4OnByb2Nl c3MgbG9jaykKICAgICAgOTEgICAgICAgICAwICAgICAgICAgMjk2ICAgICAgICAgICAwICAgICAg ICAgICA0ICAgICA3NCAgICAgIDAgIDAgICAgICAwIC91c3Ivc3JjL3N5cy92bS91bWFfY29yZS5j OjIzNTUgKHNsZWVwIG11dGV4OlZOT0RFKQogICAgICA5OCAgICAgICAgIDAgICAgICAgICAyNzYg ICAgICAgICAgIDAgICAgICAgICAgIDMgICAgIDkyICAgICAgMCAgMCAgICAgIDAgL3Vzci9zcmMv c3lzL3ZtL3VtYV9jb3JlLmM6MjM1NSAoc2xlZXAgbXV0ZXg6a3NpZ2luZm8pCiAgICAgNjY5ICAg ICAgICAgMCAgICAgICAgNDMxNCAgICAgICAgICAgMCAgICAgICAgICAxOCAgICAyMzkgICAgICAw ICAwICAgICAgMCAvdXNyL3NyYy9zeXMvdWZzL2Zmcy9mZnNfdmZzb3BzLmM6MTMzOCAoc2xlZXAg bXV0ZXg6YnVmb2JqIGludGVybG9jaykKICAgICA0MTAgICAgICAgICAwICAgICAgICAgNzczICAg ICAgICAgICAwICAgICAgICAgICA1ICAgIDE1NCAgICAgIDAgIDAgICAgICAwIC91c3Ivc3JjL3N5 cy92bS91bWFfY29yZS5jOjI0NjQgKHNsZWVwIG11dGV4OjE2IEJ1Y2tldCkKICAgICAgOTUgICAg ICAgICAwICAgICAgICAgMTg5ICAgICAgICAgICAwICAgICAgICAgICAyICAgICA5NCAgICAgIDAg IDAgICAgICAwIC91c3Ivc3JjL3N5cy92bS91bWFfY29yZS5jOjE5OTAgKHNsZWVwIG11dGV4OjEw MjQpCiAgICAgIDk1ICAgICAgICAgMCAgICAgICAgIDI2NyAgICAgICAgICAgMCAgICAgICAgICAg MyAgICAgODkgICAgICAwICAwICAgICAgMCAvdXNyL3NyYy9zeXMvdm0vdW1hX2NvcmUuYzoyMzU1 IChzbGVlcCBtdXRleDpUVVJOU1RJTEUpCiAgICAgIDg4ICAgICAgICAgMCAgICAgICAgICA4OCAg ICAgICAgICAgMCAgICAgICAgICAgMSAgICAgODggICAgICAwICAwICAgICAgMCAvdXNyL3NyYy9z eXMva2Vybi91aXBjX3NvY2tldC5jOjMwNjIgKHNsZWVwIG11dGV4OnNvX3NuZCkKICAgICAgOTQg ICAgICAgICAwICAgICAgICAgIDk0ICAgICAgICAgICAwICAgICAgICAgICAxICAgICA5NCAgICAg IDAgIDAgICAgICAwIC91c3Ivc3JjL3N5cy92bS91bWFfY29yZS5jOjIwMzQgKHNsZWVwIG11dGV4 OjEwMjQpCiAgICAxMzMzICAgICAgICAgMCAgICAgICAgMTMzMyAgICAgICAgICAgMCAgICAgICAg ICAgMSAgIDEzMzMgICAgICAwICAwICAgICAgMCAvdXNyL3NyYy9zeXMva2Vybi91aXBjX3VzcnJl cS5jOjgxMiAoc2xlZXAgbXV0ZXg6c29fcmN2KQogICAgICA5NSAgICAgICAgIDAgICAgICAgICAx ODcgICAgICAgICAgIDAgICAgICAgICAgIDIgICAgIDkzICAgICAgMCAgMCAgICAgIDAgL3Vzci9z cmMvc3lzL2tlcm4vdmZzX2NhY2hlLmM6OTI1IChydzpOYW1lIENhY2hlKQogICAgIDQ3NCAgICAg ICAgIDAgICAgICAgIDE0NTcgICAgICAgICAgIDAgICAgICAgICAgIDggICAgMTgyICAgICAgMCAg MCAgICAgIDAgL3Vzci9zcmMvc3lzL3ZtL3VtYV9jb3JlLmM6OTE0IChzbGVlcCBtdXRleDpzZWxm ZCkKICAgICA0NTIgICAgICAgICAwICAgICAgICAxMDg0ICAgICAgICAgICAwICAgICAgICAgIDEx ICAgICA5OCAgICAgIDAgIDAgICAgICAwIC91c3Ivc3JjL3N5cy9rZXJuL2tlcm5fZGVzY3JpcC5j OjgzMyAoc2xlZXAgbXV0ZXg6c2lnaW8gbG9jaykKICAgICAgOTIgICAgICAgICAwICAgICAgICAx MjIyICAgICAgICAgICAwICAgICAgICAgIDM0ICAgICAzNSAgICAgIDAgIDAgICAgICAwIC91c3Iv c3JjL3N5cy92bS91bWFfY29yZS5jOjE5OTAgKHNsZWVwIG11dGV4OkZGUzIgZGlub2RlKQogICAg ICA4OSAgICAgICAgIDAgICAgICAgICAgODkgICAgICAgICAgIDAgICAgICAgICAgIDEgICAgIDg5 ICAgICAgMCAgMCAgICAgIDAgL3Vzci9zcmMvc3lzL2tlcm4va2Vybl9wcm9jLmM6MzYwIChzbGVl cCBtdXRleDpwcm9jZXNzIGxvY2spCiAgICAgMTE2ICAgICAgICAgMCAgICAgICAgIDYyNSAgICAg ICAgICAgMCAgICAgICAgICAgOCAgICAgNzggICAgICAwICAwICAgICAgMCAvdXNyL3NyYy9zeXMv dm0vdW1hX2NvcmUuYzoyMDM0IChzbGVlcCBtdXRleDpGRlMyIGRpbm9kZSkKICAgICAgOTMgICAg ICAgICAwICAgICAgICAgIDkzICAgICAgICAgICAwICAgICAgICAgICAxICAgICA5MyAgICAgIDAg IDAgICAgICAwIC91c3Ivc3JjL3N5cy9rZXJuL3VpcGNfc29ja2V0LmM6MzAzMCAoc2xlZXAgbXV0 ZXg6c29fcmN2KQogICAgICA4OSAgICAgICAgIDAgICAgICAgICAgODkgICAgICAgICAgIDAgICAg ICAgICAgIDEgICAgIDg5ICAgICAgMCAgMCAgICAgIDAgL3Vzci9zcmMvc3lzL2tlcm4vdWlwY19z b2NrZXQuYzozMDYxIChzbGVlcCBtdXRleDpzb19yY3YpCiAgICAgNjQ4ICAgICAgICAgMCAgICAg ICAgOTcxOCAgICAgICAgICAgMCAgICAgICAgICA1NiAgICAxNzMgICAgICAwICAwICAgICAgMCAv dXNyL3NyYy9zeXMvdm0vdW1hX2NvcmUuYzoyNDY0IChzbGVlcCBtdXRleDozMiBCdWNrZXQpCiAg ICAgNTk1ICAgICAgICAgMCAgICAgICAgNTQwMSAgICAgICAgICAgMCAgICAgICAgICA0NiAgICAx MTcgICAgICAwICAwICAgICAgMCAvdXNyL3NyYy9zeXMva2Vybi9rZXJuX3Byb2MuYzo0NzQgKHNs ZWVwIG11dGV4OnByb2Nlc3MgbG9jaykKICAgICA5MjYgICAgICAgICAwICAgICAgIDEyNzY1ICAg ICAgICAgICAwICAgICAgICAgIDc3ICAgIDE2NSAgICAgIDAgIDAgICAgICAwIC91c3Ivc3JjL3N5 cy92bS91bWFfY29yZS5jOjI2MDIgKHNsZWVwIG11dGV4OlZNIE9CSkVDVCkKICAgICA2NTEgICAg ICAgMjcyICAgICAgICA1MDg0ICAgICAgICAgMjcyICAgICAgICAgIDIzICAgIDIyMSAgICAgMTEg IDAgICAgICAxIC91c3Ivc3JjL3N5cy92bS91bWFfY29yZS5jOjI2NjEgKHNsZWVwIG11dGV4OlZN IE9CSkVDVCkKICAgICA0NTUgICAgICAgICAwICAgICAgICA0MzUzICAgICAgICAgICAwICAgICAg ICAgIDMxICAgIDE0MCAgICAgIDAgIDAgICAgICAwIC91c3Ivc3JjL3N5cy92bS91bWFfY29yZS5j OjI3MDMgKHNsZWVwIG11dGV4OlZNIE9CSkVDVCkKICAgICAgODkgICAgICAgICAwICAgICAgICAg IDg5ICAgICAgICAgICAwICAgICAgICAgICAxICAgICA4OSAgICAgIDAgIDAgICAgICAwIC91c3Iv c3JjL3N5cy92bS91bWFfY29yZS5jOjE5OTAgKHNsZWVwIG11dGV4OnVucGNiKQogICAgIDQ4OCAg ICAgICAgIDAgICAgICAgIDEwNTkgICAgICAgICAgIDAgICAgICAgICAgIDcgICAgMTUxICAgICAg MCAgMCAgICAgIDAgL3Vzci9zcmMvc3lzL3Vmcy9mZnMvZmZzX3NvZnRkZXAuYzozMDI3IChzbGVl cCBtdXRleDpTb2Z0ZGVwIExvY2spCiAgICAgNDUyICAgICAgICAgMCAgICAgICAgIDU0MiAgICAg ICAgICAgMCAgICAgICAgICAgMiAgICAyNzEgICAgICAwICAwICAgICAgMCAvdXNyL3NyYy9zeXMv dm0vdW1hX2NvcmUuYzoyMDM0IChzbGVlcCBtdXRleDp1bnBjYikKICAgICA0MjcgICAgICAgICAw ICAgICAgICAgNTE0ICAgICAgICAgICAwICAgICAgICAgICAyICAgIDI1NyAgICAgIDAgIDAgICAg ICAwIC91c3Ivc3JjL3N5cy92bS91bWFfY29yZS5jOjI1MjQgKHNsZWVwIG11dGV4OjEwMjQpCiAg ICAgNDYzICAgICAgICAgMCAgICAgICAgMTAyOSAgICAgICAgICAgMCAgICAgICAgICAgNCAgICAy NTcgICAgICAwICAwICAgICAgMCAvdXNyL3NyYy9zeXMvdm0vdW1hX2NvcmUuYzoyMzU1IChzbGVl cCBtdXRleDpGRlMyIGRpbm9kZSkKICAgICAgODkgICAgICAgICAwICAgICAgICAgIDg5ICAgICAg ICAgICAwICAgICAgICAgICAxICAgICA4OSAgICAgIDAgIDAgICAgICAwIC91c3Ivc3JjL3N5cy9r ZXJuL3VpcGNfdXNycmVxLmM6MTM1MSAoc2xlZXAgbXV0ZXg6c29fcmN2KQogICAgICA4OCAgICAg ICAgIDAgICAgICAgICAxNzYgICAgICAgICAgIDAgICAgICAgICAgIDIgICAgIDg4ICAgICAgMCAg MCAgICAgIDAgL3Vzci9zcmMvc3lzL3ZtL3VtYV9jb3JlLmM6MjYwMiAoc2xlZXAgbXV0ZXg6MTAy NCkKICAgODExMTcgICAgICAgICAwICAgICAgMTAzNTc0ICAgICAgICAgICAwICAgICAgICAgICA0 ICAyNTg5MyAgICAgIDAgIDAgICAgICAwIC91c3Ivc3JjL3N5cy9rZXJuL3Zmc19iaW8uYzoxNzgz IChsb2NrbWdyOmJ1ZndhaXQpCiAgICAgIDg3ICAgICAgICAgMCAgICAgICAgICA4NyAgICAgICAg ICAgMCAgICAgICAgICAgMSAgICAgODcgICAgICAwICAwICAgICAgMCAvdXNyL3NyYy9zeXMvdm0v dW1hX2NvcmUuYzoyNjYxIChzbGVlcCBtdXRleDoxMDI0KQogICAgIDcyNiAgICAgICAgIDAgICAg ICAgIDk3MzIgICAgICAgICAgIDAgICAgICAgICAgNTkgICAgMTY0ICAgICAgMCAgMCAgICAgIDAg L3Vzci9zcmMvc3lzL3ZtL3VtYV9jb3JlLmM6OTE0IChzbGVlcCBtdXRleDpVTUEgUkNudFNsYWJz KQogIDI2MzA1OCAgICAgICAgIDAgICAgICA5NTQwNjcgICAgICAgICAgIDAgICAgICAgICAxODYg ICA1MTI5ICAgICAgMCAgMCAgICAgIDAgL3Vzci9zcmMvc3lzL2Rldi9lMTAwMC9pZl9lbS5jOjQz ODYgKHNsZWVwIG11dGV4OmVtMCkKICAgICA0NDMgICAgICAgICAwICAgICAgICAgNTI5ICAgICAg ICAgICAwICAgICAgICAgICAyICAgIDI2NCAgICAgIDAgIDAgICAgICAwIC91c3Ivc3JjL3N5cy9r ZXJuL3Zmc19iaW8uYzoxNjIwIChzbGVlcCBtdXRleDpidWZvYmogaW50ZXJsb2NrKQogICAgICA5 NCAgICAgICAgIDAgICAgICAgICA2MzggICAgICAgICAgIDAgICAgICAgICAgIDcgICAgIDkxICAg ICAgMCAgMCAgICAgIDAgL3Vzci9zcmMvc3lzL3Vmcy9mZnMvZmZzX3NvZnRkZXAuYzozMzExIChz bGVlcCBtdXRleDpTb2Z0ZGVwIExvY2spCiAgICAgNDU3ICAgICAgICAgMCAgICAgICAgMTM0NSAg ICAgICAgICAgMCAgICAgICAgICAgNyAgICAxOTIgICAgICAwICAwICAgICAgMCAvdXNyL3NyYy9z eXMvdWZzL2Zmcy9mZnNfc29mdGRlcC5jOjMzMjMgKHNsZWVwIG11dGV4OlNvZnRkZXAgTG9jaykK ICAgICAzMDUgICAgICAgICAwICAgICAgICAgMzA1ICAgICAgICAgICAwICAgICAgICAgICAxICAg IDMwNSAgICAgIDAgIDAgICAgICAwIC91c3Ivc3JjL3N5cy9rZXJuL3VpcGNfc29ja2V0LmM6MzAy OSAoc2xlZXAgbXV0ZXg6YWNjZXB0KQogICAgICA4OSAgICAgICAgIDAgICAgICAgICAgODkgICAg ICAgICAgIDAgICAgICAgICAgIDEgICAgIDg5ICAgICAgMCAgMCAgICAgIDAgL3Vzci9zcmMvc3lz L3ZtL3VtYV9jb3JlLmM6MjM1NSAoc2xlZXAgbXV0ZXg6dW5wY2IpCiAgICA0NDYzICAgICAxNjcx OCAgICAgMzMxNTI0MiAgICAgMTcyNTg0NiAgICAgICAgNTMzNCAgICA2MjEgICAgMzIzICAwICAg IDc3MSAvdXNyL3NyYy9zeXMva2Vybi9rZXJuX2ludHIuYzoxMTMzIChzbGVlcCBtdXRleDpHaWFu dCkKICAgIDE5NDggICAgICAgICAwICAgICAgIDcxNzI1ICAgICAgICAgICAwICAgICAgICAgMjA1 ICAgIDM0OSAgICAgIDAgIDAgICAgICAwIC91c3Ivc3JjL3N5cy9kZXYvZTEwMDAvaWZfZW0uYzo0 NTQxIChzbGVlcCBtdXRleDplbTApCiAgICAgOTU3ICAgICAgIDQyOCAgICAgICAyMjUwOSAgICAg ICAgMTM0NCAgICAgICAgIDE1NCAgICAxNDYgICAgICA4ICAwICAgICAgOSAvdXNyL3NyYy9zeXMv dm0vdW1hX2NvcmUuYzoyNDY0IChzbGVlcCBtdXRleDoxMjggQnVja2V0KQogICAgIDQ2OSAgICAg ICAgIDAgICAgICAgIDU5OTMgICAgICAgICAgIDAgICAgICAgICAgNDYgICAgMTMwICAgICAgMCAg MCAgICAgIDAgL3Vzci9zcmMvc3lzL2tlcm4va2Vybl9leGl0LmM6Nzg4IChzeDphbGxwcm9jKQog ICAgIDQ3NyAgICAgICAgIDAgICAgICAgIDUxNzEgICAgICAgICAgIDAgICAgICAgICAgNDYgICAg MTEyICAgICAgMCAgMCAgICAgIDAgL3Vzci9zcmMvc3lzL2tlcm4va2Vybl9leGl0LmM6ODQwIChz eDphbGxwcm9jKQogICAgICA5MyAgICAgICAgIDAgICAgICAgICAgOTMgICAgICAgICAgIDAgICAg ICAgICAgIDEgICAgIDkzICAgICAgMCAgMCAgICAgIDAgL3Vzci9zcmMvc3lzL2tlcm4va2Vybl9w cm90LmM6MTk2OCAoc2xlZXAgbXV0ZXg6c2Vzc2lvbikKICAgICAyNzkgICAgICAgICAwICAgICAg ICAxNTQzICAgICAgICAgICAwICAgICAgICAgIDM0ICAgICA0NSAgICAgIDAgIDAgICAgICAwIC91 c3Ivc3JjL3N5cy9rZXJuL3Zmc19zdWJyLmM6OTM4IChzbGVlcCBtdXRleDp2bm9kZV9mcmVlX2xp c3QpCiAgICAgMTIwICAgICAgICAgMCAgICAgICAgMTMxMSAgICAgICAgICAgMCAgICAgICAgICAx NCAgICAgOTMgICAgICAwICAwICAgICAgMCAvdXNyL3NyYy9zeXMvdWZzL2Zmcy9mZnNfc29mdGRl cC5jOjM1MTIgKHNsZWVwIG11dGV4OlNvZnRkZXAgTG9jaykKICAgICAgOTUgICAgICAgICAwICAg ICAgICAgIDk1ICAgICAgICAgICAwICAgICAgICAgICAxICAgICA5NSAgICAgIDAgIDAgICAgICAw IC91c3Ivc3JjL3N5cy92bS91bWFfY29yZS5jOjI1MjQgKHNsZWVwIG11dGV4OnVucGNiKQogICAg IDYwNiAgICAgICAgIDAgICAgICAgICA2MDYgICAgICAgICAgIDAgICAgICAgICAgIDEgICAgNjA2 ICAgICAgMCAgMCAgICAgIDAgL3Vzci9zcmMvc3lzL2tlcm4vdWlwY191c3JyZXEuYzo1MjEgKHNs ZWVwIG11dGV4OnVucF9tdHgpCiAgIDM1ODY5ICAgICAgICAgMCAgICAgIDczNzgxMSAgICAgICAg ICAgMCAgICAgICAgICA5MSAgIDgxMDcgICAgICAwICAwICAgICAgMCAvdXNyL3NyYy9zeXMva2Vy bi9rZXJuX2V4aXQuYzo3MTIgKHN4OnByb2N0cmVlKQogICAgICA5MiAgICAgICAgIDAgICAgICAg ICAxODIgICAgICAgICAgIDAgICAgICAgICAgIDIgICAgIDkxICAgICAgMCAgMCAgICAgIDAgL3Vz ci9zcmMvc3lzL3ZtL3VtYV9jb3JlLmM6MjYwMiAoc2xlZXAgbXV0ZXg6dW5wY2IpCiAgICAgIDg5 ICAgICAgICAgMCAgICAgICAgIDQzNSAgICAgICAgICAgMCAgICAgICAgICAgNSAgICAgODcgICAg ICAwICAwICAgICAgMCAvdXNyL3NyYy9zeXMvdm0vdW1hX2NvcmUuYzo5MTQgKHNsZWVwIG11dGV4 OnBpcGUpCiAgICAgIDkxICAgICAgICAgMCAgICAgICAgICA5MSAgICAgICAgICAgMCAgICAgICAg ICAgMSAgICAgOTEgICAgICAwICAwICAgICAgMCAvdXNyL3NyYy9zeXMvdm0vdW1hX2NvcmUuYzoy NjYxIChzbGVlcCBtdXRleDp1bnBjYikKICAgICA3OTUgICAgICAgICAwICAgICAgICAgNzk1ICAg ICAgICAgICAwICAgICAgICAgICAxICAgIDc5NSAgICAgIDAgIDAgICAgICAwIC91c3Ivc3JjL3N5 cy9rZXJuL3VpcGNfdXNycmVxLmM6NjI5IChzbGVlcCBtdXRleDp1bnBfbXR4KQogICAgIDYyMSAg ICAgICAgIDAgICAgICAgICA2MjEgICAgICAgICAgIDAgICAgICAgICAgIDEgICAgNjIxICAgICAg MCAgMCAgICAgIDAgL3Vzci9zcmMvc3lzL2tlcm4vdWlwY191c3JyZXEuYzo2MzIgKHNsZWVwIG11 dGV4OnVucF9tdHgpCiAgICAgNDM4ICAgICAgICAgMCAgICAgICAgIDkxOCAgICAgICAgICAgMCAg ICAgICAgICAgOCAgICAxMTQgICAgICAwICAwICAgICAgMCAvdXNyL3NyYy9zeXMvdm0vdW1hX2Nv cmUuYzo5MTQgKHNsZWVwIG11dGV4OlMgVkZTIENhY2hlKQogICAgMTE2OCAgICAgICAgIDAgICAg ICAgIDYxODAgICAgICAgICAgIDAgICAgICAgICAgMTEgICAgNTYxICAgICAgMCAgMCAgICAgIDAg L3Vzci9zcmMvc3lzL2FtZDY0L2FtZDY0L21hY2hkZXAuYzozNjIgKHNsZWVwIG11dGV4OnByb2Nl c3MgbG9jaykKICAgICA2MTIgICAgICAgICAwICAgICAgICAxNTk5ICAgICAgICAgICAwICAgICAg ICAgIDE0ICAgIDExNCAgICAgIDAgIDAgICAgICAwIC91c3Ivc3JjL3N5cy92bS91bWFfY29yZS5j OjIwMzQgKHNsZWVwIG11dGV4OnNlbGZkKQogICAgIDc5NCAgICAgICAgIDAgICAgICAgIDEwNTUg ICAgICAgICAgIDAgICAgICAgICAgIDIgICAgNTI3ICAgICAgMCAgMCAgICAgIDAgL3Vzci9zcmMv c3lzL2tlcm4vdmZzX2Jpby5jOjI4NDYgKHNsZWVwIG11dGV4OnZtIG9iamVjdCkKICAgICA2NzAg ICAgICAgICAwICAgICAgICAyMDk0ICAgICAgICAgICAwICAgICAgICAgIDExICAgIDE5MCAgICAg IDAgIDAgICAgICAwIC91c3Ivc3JjL3N5cy9hbWQ2NC9hbWQ2NC9tYWNoZGVwLmM6NDM4IChzbGVl cCBtdXRleDpwcm9jZXNzIGxvY2spCiAgICAgIDk3ICAgICAgICAgMCAgICAgICAgIDI3OCAgICAg ICAgICAgMCAgICAgICAgICAgMyAgICAgOTIgICAgICAwICAwICAgICAgMCAvdXNyL3NyYy9zeXMv dm0vdW1hX2NvcmUuYzoyMzU1IChzbGVlcCBtdXRleDo0MDk2KQogICAgMTg4MyAgICAgICAgIDAg ICAgICAgIDE4ODMgICAgICAgICAgIDAgICAgICAgICAgIDEgICAxODgzICAgICAgMCAgMCAgICAg IDAgL3Vzci9zcmMvc3lzL2tlcm4vdWlwY191c3JyZXEuYzo4MDYgKHNsZWVwIG11dGV4OnVucF9t dHgpCiAgICAgIDkxICAgICAgICAgMCAgICAgICAgMTMwNiAgICAgICAgICAgMCAgICAgICAgICAz NCAgICAgMzggICAgICAwICAwICAgICAgMCAvdXNyL3NyYy9zeXMva2Vybi92ZnNfc3Vici5jOjEw NzYgKHNsZWVwIG11dGV4OnN0cnVjdCBtb3VudCBtdHgpCiAgICAgIDg4ICAgICAgICAgMCAgICAg ICAgIDI2MSAgICAgICAgICAgMCAgICAgICAgICAgMyAgICAgODcgICAgICAwICAwICAgICAgMCAv dXNyL3NyYy9zeXMva2Vybi91aXBjX3N5c2NhbGxzLmM6MTI3IChzeDpmaWxlZGVzYyBzdHJ1Y3R1 cmUpCiAgICAgNjg1ICAgICAgICAgMCAgICAgICAgNzkxNyAgICAgICAgICAgMCAgICAgICAgICA0 MyAgICAxODQgICAgICAwICAwICAgICAgMCAvdXNyL3NyYy9zeXMvdm0vdW1hX2NvcmUuYzo5MTQg KHNsZWVwIG11dGV4Om1idWYpCiAgICAgMTgyICAgICAgICAgMCAgICAgICAgIDg4OSAgICAgICAg ICAgMCAgICAgICAgICAgNSAgICAxNzcgICAgICAwICAwICAgICAgMCAvdXNyL3NyYy9zeXMva2Vy bi9rZXJuX3RocmVhZC5jOjQxMCAoc3BpbiBtdXRleDpzY2hlZCBsb2NrIDEpCiAgICAgMTEwICAg ICAgICAgMCAgICAgICAgIDQ3OCAgICAgICAgICAgMCAgICAgICAgICAgNSAgICAgOTUgICAgICAw ICAwICAgICAgMCAvdXNyL3NyYy9zeXMva2Vybi9rZXJuX3RocmVhZC5jOjQzNyAoc3BpbiBtdXRl eDpzY2hlZCBsb2NrIDEpCiAgICAgMTI1ICAgICAgIDExMSAgICAgICA3MzI2NiAgICAgICAgIDIx NSAgICAgICAgIDkwOSAgICAgODAgICAgICAwICAwICAgICAgNCAvdXNyL3NyYy9zeXMva2Vybi9r ZXJuX2V4aXQuYzo3NDAgKHNwaW4gbXV0ZXg6cHJvY2VzcyBzbG9jaykKICAgICAgOTMgICAgICAg ICAwICAgICAgICAgODAyICAgICAgICAgICAwICAgICAgICAgICA5ICAgICA4OSAgICAgIDAgIDAg ICAgICAwIC91c3Ivc3JjL3N5cy9rZXJuL2tlcm5fdW10eC5jOjMzNjAgKHNwaW4gbXV0ZXg6c2No ZWQgbG9jayAxKQogICAgICA5NSAgICAgICAgIDAgICAgICAgIDExNTcgICAgICAgICAgIDAgICAg ICAgICAgMTMgICAgIDg5ICAgICAgMCAgMCAgICAgIDAgL3Vzci9zcmMvc3lzL2tlcm4vc3Vicl90 dXJuc3RpbGUuYzo3MjcgKHNwaW4gbXV0ZXg6c2NoZWQgbG9jayAxKQogICAgIDMwMCAgICAgICAx MzQgICAgICAgIDM1OTAgICAgICAgICAxMzQgICAgICAgICAgMTMgICAgMjc2ICAgICAxMCAgMCAg ICAgIDEgL3Vzci9zcmMvc3lzL2tlcm4vc3Vicl90dXJuc3RpbGUuYzo4ODkgKHNwaW4gbXV0ZXg6 c2NoZWQgbG9jayAxKQogICAgIDE2OSAgICAgICA2MjMgICAgICAzNTI3NTkgICAgICAgIDc1MzMg ICAgICAgIDM4ODUgICAgIDkwICAgICAgMSAgMCAgICAgNDUgL3Vzci9zcmMvc3lzL2tlcm4va2Vy bl9pbnRyLmM6MTIzOSAoc3BpbiBtdXRleDpzY2hlZCBsb2NrIDEpCiAgICAgMjMzICAgICAgIDI4 MCAgICAgIDU1MTEyOSAgICAgICAgNTUxMiAgICAgICAgMzY0MiAgICAxNTEgICAgICAxICAwICAg ICAyNyAvdXNyL3NyYy9zeXMva2Vybi9zY2hlZF91bGUuYzoxODM1IChzcGluIG11dGV4OnNjaGVk IGxvY2sgMSkKICAgICA2MDYgICAgICAgICAwICAgICAxNTc3NDExICAgICAgICAgICAwICAgICAg IDE0NjkzICAgIDEwNyAgICAgIDAgIDAgICAgICAwIC91c3Ivc3JjL3N5cy9rZXJuL3NjaGVkX3Vs ZS5jOjE4NzYgKHNwaW4gbXV0ZXg6c2NoZWQgbG9jayAxKQogICAgIDE0NSAgICAgICAyMTkgICAg ICAyNzQ3NTMgICAgICAgIDY5ODMgICAgICAgIDM2MzQgICAgIDc1ICAgICAgMSAgMCAgICAgNTMg L3Vzci9zcmMvc3lzL2tlcm4vc3Vicl9zbGVlcHF1ZXVlLmM6MzM1IChzcGluIG11dGV4OnNjaGVk IGxvY2sgMSkKICAgICAgODcgICAgICAgICAwICAgICAgICAgIDg3ICAgICAgICAgICAwICAgICAg ICAgICAxICAgICA4NyAgICAgIDAgIDAgICAgICAwIC91c3Ivc3JjL3N5cy9rZXJuL3NjaGVkX3Vs ZS5jOjE5MDMgKHNwaW4gbXV0ZXg6c2NoZWQgbG9jayAxKQogICAgIDEyMSAgICAgICAgIDAgICAg ICAgICA0ODkgICAgICAgICAgIDAgICAgICAgICAgIDUgICAgIDk3ICAgICAgMCAgMCAgICAgIDAg L3Vzci9zcmMvc3lzL2tlcm4vc3Vicl9zbGVlcHF1ZXVlLmM6MzkzIChzcGluIG11dGV4OnNjaGVk IGxvY2sgMSkKICAgICAgODkgICAgICAgICAwICAgICAgICAgIDg5ICAgICAgICAgICAwICAgICAg ICAgICAxICAgICA4OSAgICAgIDAgIDAgICAgICAwIC91c3Ivc3JjL3N5cy9rZXJuL3NjaGVkX3Vs ZS5jOjIwNjIgKHNwaW4gbXV0ZXg6c2NoZWQgbG9jayAxKQogICAgIDE2NCAgICAgICA0MTkgICAg ICA1ODE3OTkgICAgICA1NTM3NDcgICAgICAgIDY3MzIgICAgIDg2ICAgICA4MiAgMCAgIDU2NzIg L3Vzci9zcmMvc3lzL2tlcm4vc2NoZWRfdWxlLmM6MjA3NCAoc3BpbiBtdXRleDpzY2hlZCBsb2Nr IDEpCiAgICAgIDk5ICAgICAgIDgwMSAgICAgICAxNTk4MiAgICAgICAgIDgwMSAgICAgICAgIDE4 NSAgICAgODYgICAgICA0ICAwICAgICAgMSAvdXNyL3NyYy9zeXMva2Vybi9zY2hlZF91bGUuYzoy MTExIChzcGluIG11dGV4OnNjaGVkIGxvY2sgMSkKICAgICAxODMgICAgICAgIDk4ICAgICAgIDkw NzMzICAgICAgICAgIDk4ICAgICAgICAxMDExICAgICA4OSAgICAgIDAgIDAgICAgICAxIC91c3Iv c3JjL3N5cy9rZXJuL3N1YnJfc2xlZXBxdWV1ZS5jOjU4MyAoc3BpbiBtdXRleDpzY2hlZCBsb2Nr IDEpCiAgICAgMTI5ICAgICAgIDI5MCAgICAgIDE4NDgwOCAgICAgICAgNTkwNSAgICAgICAgMjYx OCAgICAgNzAgICAgICAyICAwICAgICA0MiAvdXNyL3NyYy9zeXMva2Vybi9zdWJyX3NsZWVwcXVl dWUuYzo2MTggKHNwaW4gbXV0ZXg6c2NoZWQgbG9jayAxKQogICAgIDE0OSAgICAgICA0MDggICAg MTIxODA4NzYgICAgICAyMTM1MDggICAgICAxNDY3NjYgICAgIDgyICAgICAgMSAgMCAgIDEzMjIg L3Vzci9zcmMvc3lzL2tlcm4va2Vybl9jbG9jay5jOjI4NiAoc3BpbiBtdXRleDpzY2hlZCBsb2Nr IDEpCiAgICAxNjEyICAgICAgIDQ2MiAgICAgIDE3OTMwOSAgICAgICAgIDkwMCAgICAgICAgIDM3 MiAgICA0ODIgICAgICAyICAwICAgICAgMyAvdXNyL3NyYy9zeXMva2Vybi9zdWJyX3Rhc2txdWV1 ZS5jOjczIChzcGluIG11dGV4OmZhc3RfdGFza3F1ZXVlKQogICAgIDEzNiAgICAxMzA1NjUgICAg ICAgMjg3OTUgICAgICA0MzM5MTQgICAgICAgICAzMzIgICAgIDg2ICAgMTMwNiAgMCAgICAzMDIg L3Vzci9zcmMvc3lzL2tlcm4vc2NoZWRfdWxlLmM6MjU2OSAoc3BpbiBtdXRleDpzY2hlZCBsb2Nr IDEpCiAgICAgMTIzICAgICAgIDE3MiAgICAgICAxNDEzMCAgICAgICAgIDQ4MCAgICAgICAgIDE1 OCAgICAgODkgICAgICAzICAwICAgICAgMyAvdXNyL3NyYy9zeXMva2Vybi9rZXJuX3N3aXRjaC5j OjE4OCAoc3BpbiBtdXRleDpzY2hlZCBsb2NrIDEpCiAgICAgIDkxICAgICAgICAgMCAgICAgICAg IDQ0MiAgICAgICAgICAgMCAgICAgICAgICAgNSAgICAgODggICAgICAwICAwICAgICAgMCAvdXNy L3NyYy9zeXMva2Vybi9zY2hlZF91bGUuYzoyNjI3IChzcGluIG11dGV4OnNjaGVkIGxvY2sgMSkK ICAgICAxNDMgICAgICAgNTE5ICAgICAxNjI2MTQ4ICAgICAgIDU1NjM0ICAgICAgIDE5NTIwICAg ICA4MyAgICAgIDIgIDAgICAgNDU1IC91c3Ivc3JjL3N5cy9rZXJuL2tlcm5fY2xvY2suYzo1MDMg KHNwaW4gbXV0ZXg6c2NoZWQgbG9jayAxKQogICAgIDExOSAgICAgICAgIDAgICAgICAgNTYwMjQg ICAgICAgICAgIDAgICAgICAgICA2MzMgICAgIDg4ICAgICAgMCAgMCAgICAgIDAgL3Vzci9zcmMv c3lzL2tlcm4vc3Vicl90cmFwLmM6MTY3IChzcGluIG11dGV4OnNjaGVkIGxvY2sgMSkKICAgICAx MTYgICAgICAgICAwICAgICAgIDU1ODA4ICAgICAgICAgICAwICAgICAgICAgNjMyICAgICA4OCAg ICAgIDAgIDAgICAgICAwIC91c3Ivc3JjL3N5cy9rZXJuL3N1YnJfdHJhcC5jOjIxMyAoc3BpbiBt dXRleDpzY2hlZCBsb2NrIDEpCiAgICAgMTgwICAgICAgIDUyMyAgICAgICAgIDkxMyAgICAgICAg MTkzNSAgICAgICAgICAgOSAgICAxMDEgICAgMjE1ICAwICAgICAgNyAvdXNyL3NyYy9zeXMva2Vy bi9zY2hlZF91bGUuYzo4MDQgKHNwaW4gbXV0ZXg6c2NoZWQgbG9jayA4KQogICAgIDE1NyAgICAg ICAgIDAgICAgICAgMTc5MjYgICAgICAgICAgIDAgICAgICAgICAxODYgICAgIDk2ICAgICAgMCAg MCAgICAgIDAgL3Vzci9zcmMvc3lzL2tlcm4va2Vybl9zeW5jaC5jOjMyMSAoc3BpbiBtdXRleDpm YXN0X3Rhc2txdWV1ZSkKICAgICAxMjggICAgICAgICAwICAgICAgICAgMjE4ICAgICAgICAgICAw ICAgICAgICAgICAyICAgIDEwOSAgICAgIDAgIDAgICAgICAwIC91c3Ivc3JjL3N5cy9rZXJuL2tl cm5fZm9yay5jOjQzNSAoc3BpbiBtdXRleDpzY2hlZCBsb2NrIDEpCiAgICAgMTc5ICAgICAgIDY1 OCAgICAgICAgMjc4MSAgICAgICAgMzg2NiAgICAgICAgICAyOCAgICAgOTkgICAgMTM4ICAwICAg ICAxNyAvdXNyL3NyYy9zeXMva2Vybi9zY2hlZF91bGUuYzo4MDQgKHNwaW4gbXV0ZXg6c2NoZWQg bG9jayA0KQogICAgICA5OSAgICAgICAgIDAgICAgICAgICAxOTQgICAgICAgICAgIDAgICAgICAg ICAgIDIgICAgIDk3ICAgICAgMCAgMCAgICAgIDAgL3Vzci9zcmMvc3lzL2tlcm4va2Vybl9mb3Jr LmM6NzMxIChzcGluIG11dGV4OnNjaGVkIGxvY2sgMSkKICAgICAxODQgICAgICAgODAwICAgICAg ODAxNDA5ICAgICAgICA3OTA0ICAgICAgICA3NjI5ICAgIDEwNSAgICAgIDEgIDAgICAgIDQ2IC91 c3Ivc3JjL3N5cy9kZXYvcmFuZG9tL3JhbmRvbWRldl9zb2Z0LmM6MzE2IChzcGluIG11dGV4OmVu dHJvcHkgaGFydmVzdCBtdXRleCkKICAgICA0MzYgICAgICAgICAwICAgICAgICAgOTAzICAgICAg ICAgICAwICAgICAgICAgICA0ICAgIDIyNSAgICAgIDAgIDAgICAgICAwIC91c3Ivc3JjL3N5cy92 bS91bWFfY29yZS5jOjIwMzQgKHNsZWVwIG11dGV4OjE2KQogICAgICA4OSAgICAgICAgIDAgICAg ICAgICAxMDEgICAgICAgICAgIDAgICAgICAgICAgIDMgICAgIDMzICAgICAgMCAgMCAgICAgIDAg L3Vzci9zcmMvc3lzL2tlcm4va2Vybl9wcm9jLmM6NTA0IChzbGVlcCBtdXRleDpwcm9jZXNzIGdy b3VwKQogICAgICA5OCAgICAgICAgIDAgICAgICAgICAxOTQgICAgICAgICAgIDAgICAgICAgICAg IDIgICAgIDk3ICAgICAgMCAgMCAgICAgIDAgL3Vzci9zcmMvc3lzL3ZtL3VtYV9jb3JlLmM6MjM1 NSAoc2xlZXAgbXV0ZXg6MTYpCiAgICAgIDkyICAgICAgICAgMCAgICAgICAgIDM2MCAgICAgICAg ICAgMCAgICAgICAgICAgNCAgICAgOTAgICAgICAwICAwICAgICAgMCAvdXNyL3NyYy9zeXMvdm0v dW1hX2NvcmUuYzoyNjAyIChzbGVlcCBtdXRleDoxNikKICAgICAgOTEgICAgICAgICAwICAgICAg ICAgMTgxICAgICAgICAgICAwICAgICAgICAgICAyICAgICA5MCAgICAgIDAgIDAgICAgICAwIC91 c3Ivc3JjL3N5cy92bS91bWFfY29yZS5jOjI2NjEgKHNsZWVwIG11dGV4OjE2KQogICAgICA4NiAg ICAgICAgIDAgICAgICAgICAxNzIgICAgICAgICAgIDAgICAgICAgICAgIDIgICAgIDg2ICAgICAg MCAgMCAgICAgIDAgL3Vzci9zcmMvc3lzL3ZtL3VtYV9jb3JlLmM6MjAzNCAoc2xlZXAgbXV0ZXg6 MjU2KQogICAxMjE4MyAgICAgICAgIDAgICAgICAgMTU1NjkgICAgICAgICAgIDAgICAgICAgICAg IDIgICA3Nzg0ICAgICAgMCAgMCAgICAgIDAgL3Vzci9zcmMvc3lzL2tlcm4vdmZzX3Zub3BzLmM6 NTk0IChsb2NrbWdyOnVmcykKICAgICA0MzIgICAgICAgICAwICAgICAgICAxNDcyICAgICAgICAg ICAwICAgICAgICAgICA5ICAgIDE2MyAgICAgIDAgIDAgICAgICAwIC91c3Ivc3JjL3N5cy92bS91 bWFfY29yZS5jOjkxNCAoc2xlZXAgbXV0ZXg6MTI4KQogICAgICA4MCAgICAgICAgIDAgICAgICAg ICAgODAgICAgICAgICAgIDAgICAgICAgICAgIDEgICAgIDgwICAgICAgMCAgMCAgICAgIDAgL3Vz ci9zcmMvc3lzL2tlcm4va2Vybl9yZXNvdXJjZS5jOjEyNjIgKHJ3OnVpZGluZm8gaGFzaCkKICAg ICAgODggICAgICAgICAwICAgICAgICAgIDg4ICAgICAgICAgICAwICAgICAgICAgICAxICAgICA4 OCAgICAgIDAgIDAgICAgICAwIC91c3Ivc3JjL3N5cy9rZXJuL2tlcm5fZXhpdC5jOjMwNyAoc2xl ZXAgbXV0ZXg6c2Vzc2lvbikKICAgICAgOTEgICAgICAgICAwICAgICAgICAgIDkxICAgICAgICAg ICAwICAgICAgICAgICAxICAgICA5MSAgICAgIDAgIDAgICAgICAwIC91c3Ivc3JjL3N5cy9rZXJu L2tlcm5fZXhpdC5jOjM0NiAoc2xlZXAgbXV0ZXg6c2Vzc2lvbikKICAgICA0NDUgICAgICAgICAw ICAgICAgICAgNDQ1ICAgICAgICAgICAwICAgICAgICAgICAxICAgIDQ0NSAgICAgIDAgIDAgICAg ICAwIC91c3Ivc3JjL3N5cy92bS91bWFfY29yZS5jOjIzNTUgKHNsZWVwIG11dGV4OjI1NikKICAg ICAgOTIgICAgICAgICAwICAgICAgICAgMTgzICAgICAgICAgICAwICAgICAgICAgICAyICAgICA5 MSAgICAgIDAgIDAgICAgICAwIC91c3Ivc3JjL3N5cy92bS91bWFfY29yZS5jOjkxNCAoc2xlZXAg bXV0ZXg6NjQpCiAgICAgNTk4ICAgICAgICAgMCAgICAgICAgMjYxMiAgICAgICAgICAgMCAgICAg ICAgICAxNCAgICAxODYgICAgICAwICAwICAgICAgMCAvdXNyL3NyYy9zeXMvdm0vdW1hX2NvcmUu Yzo5MTQgKHNsZWVwIG11dGV4Ok5BTUVJKQogICAgIDYxOSAgICAgICAgIDAgICAgICAgICA4ODcg ICAgICAgICAgIDAgICAgICAgICAgIDQgICAgMjIxICAgICAgMCAgMCAgICAgIDAgL3Vzci9zcmMv c3lzL3ZtL3VtYV9jb3JlLmM6MjYwMiAoc2xlZXAgbXV0ZXg6MjU2KQogICAgICA4OSAgICAgICAg IDAgICAgICAgICAzNDYgICAgICAgICAgIDAgICAgICAgICAgIDUgICAgIDY5ICAgICAgMCAgMCAg ICAgIDAgL3Vzci9zcmMvc3lzL3ZtL3VtYV9jb3JlLmM6MjUyNCAoc2xlZXAgbXV0ZXg6cGlwZSkK ICAgICAgODkgICAgICAgICAwICAgICAgICAgMTc2ICAgICAgICAgICAwICAgICAgICAgICAyICAg ICA4OCAgICAgIDAgIDAgICAgICAwIC91c3Ivc3JjL3N5cy92bS91bWFfY29yZS5jOjI2NjEgKHNs ZWVwIG11dGV4OjI1NikKICAgICAgODkgICAgICAgICAwICAgICAgICAgMzUyICAgICAgICAgICAw ICAgICAgICAgICA0ICAgICA4OCAgICAgIDAgIDAgICAgICAwIC91c3Ivc3JjL3N5cy92bS91bWFf Y29yZS5jOjI2MDIgKHNsZWVwIG11dGV4OnBpcGUpCiAgICAgNDQ3ICAgICAgICAgMCAgICAgICAg IDQ0NyAgICAgICAgICAgMCAgICAgICAgICAgMSAgICA0NDcgICAgICAwICAwICAgICAgMCAvdXNy L3NyYy9zeXMvdWZzL2Zmcy9mZnNfc29mdGRlcC5jOjEyMjIgKHNsZWVwIG11dGV4OlNvZnRkZXAg TG9jaykKICAgICA0NTMgICAgICAgICAwICAgICAgICAgODI5ICAgICAgICAgICAwICAgICAgICAg ICA0ICAgIDIwNyAgICAgIDAgIDAgICAgICAwIC91c3Ivc3JjL3N5cy92bS91bWFfY29yZS5jOjIz NTUgKHNsZWVwIG11dGV4Om1idWYpCiAgICAgIDg3ICAgICAgICAgMCAgICAgICAgIDE3MSAgICAg ICAgICAgMCAgICAgICAgICAgMiAgICAgODUgICAgICAwICAwICAgICAgMCAvdXNyL3NyYy9zeXMv dm0vdW1hX2NvcmUuYzoyNjYxIChzbGVlcCBtdXRleDpwaXBlKQogICAgIDI4NiAgICAgICAgIDAg ICAgICAgIDE1MTQgICAgICAgICAgIDAgICAgICAgICAgMzQgICAgIDQ0ICAgICAgMCAgMCAgICAg IDAgL3Vzci9zcmMvc3lzL3ZtL3Zub2RlX3BhZ2VyLmM6MjI2IChzbGVlcCBtdXRleDp2bm9kZSBp bnRlcmxvY2spCiAgICAgODAyICAgICAgICAgMCAgICAgICAgMjM1OCAgICAgICAgICAgMCAgICAg ICAgICAxMCAgICAyMzUgICAgICAwICAwICAgICAgMCAvdXNyL3NyYy9zeXMva2Vybi9zeXNfcGlw ZS5jOjE0ODcgKHNsZWVwIG11dGV4OnBpcGUgbXV0ZXgpCiAgICAgIDk2ICAgICAgICAgMCAgICAg ICAgIDY1OSAgICAgICAgICAgMCAgICAgICAgICAxMCAgICAgNjUgICAgICAwICAwICAgICAgMCAv dXNyL3NyYy9zeXMva2Vybi9zeXNfcGlwZS5jOjE1MjcgKHNsZWVwIG11dGV4OnBpcGUgbXV0ZXgp CiAgICAgIDkyICAgICAgICAgMCAgICAgICAgIDEwNSAgICAgICAgICAgMCAgICAgICAgICAgMiAg ICAgNTIgICAgICAwICAwICAgICAgMCAvdXNyL3NyYy9zeXMva2Vybi92ZnNfdm5vcHMuYzo2NzYg KGxvY2ttZ3I6ZGV2ZnMpCiAgIDEwMzE2ICAgICAgICAgMCAgICAgICAxMzc4OCAgICAgICAgICAg MCAgICAgICAgICAgMiAgIDY4OTQgICAgICAwICAwICAgICAgMCAvdXNyL3NyYy9zeXMva2Vybi92 ZnNfc3Vici5jOjE3MDIgKGxvY2ttZ3I6dWZzKQogICAgIDMxNyAgICAgICAgIDAgICAgICAgICA0 MDggICAgICAgICAgIDAgICAgICAgICAgIDIgICAgMjA0ICAgICAgMCAgMCAgICAgIDAgL3Vzci9z cmMvc3lzL3ZtL3VtYV9jb3JlLmM6MjM1NSAoc2xlZXAgbXV0ZXg6TUFQIEVOVFJZKQogICAgIDM2 OSAgICAgICAgIDAgICAgICAgIDMxNDcgICAgICAgICAgIDAgICAgICAgICAgMzIgICAgIDk4ICAg ICAgMCAgMCAgICAgIDAgL3Vzci9zcmMvc3lzL3ZtL3VtYV9jb3JlLmM6MjUyNCAoc2xlZXAgbXV0 ZXg6Y3B1c2V0KQogICAgIDI2NCAgICAgICAgIDAgICAgICAgICAyNjQgICAgICAgICAgIDAgICAg ICAgICAgIDEgICAgMjY0ICAgICAgMCAgMCAgICAgIDAgL3Vzci9zcmMvc3lzL2tlcm4vdWlwY19z b2NrZXQuYzoxODg5IChzbGVlcCBtdXRleDpzb19yY3YpCiAgICAxOTkwICAgICAgICAgMCAgICAg ICAgNDUyMyAgICAgICAgICAgMCAgICAgICAgICAgOSAgICA1MDIgICAgICAwICAwICAgICAgMCAv dXNyL3NyYy9zeXMva2Vybi9rZXJuX3RpbWUuYzo2MjggKHNsZWVwIG11dGV4OnByb2Nlc3MgbG9j aykKICAgICA0MzEgICAgICAgICAwICAgICAgICAgNjkwICAgICAgICAgICAwICAgICAgICAgICA0 ICAgIDE3MiAgICAgIDAgIDAgICAgICAwIC91c3Ivc3JjL3N5cy92bS91bWFfY29yZS5jOjI2MDIg KHNsZWVwIG11dGV4OmNwdXNldCkKICAgICAgOTQgICAgICAgICAwICAgICAgICAgMzU5ICAgICAg ICAgICAwICAgICAgICAgICA0ICAgICA4OSAgICAgIDAgIDAgICAgICAwIC91c3Ivc3JjL3N5cy92 bS91bWFfY29yZS5jOjIwMzQgKHNsZWVwIG11dGV4OjEyOCkKICAgICAgODUgICAgICAgICAwICAg ICAgICAgMTcxICAgICAgICAgICAwICAgICAgICAgICAyICAgICA4NSAgICAgIDAgIDAgICAgICAw IC91c3Ivc3JjL3N5cy92bS91bWFfY29yZS5jOjI2NjEgKHNsZWVwIG11dGV4OmNwdXNldCkKICAg ICAgOTEgICAgICAgICAwICAgICAgICAgIDkxICAgICAgICAgICAwICAgICAgICAgICAxICAgICA5 MSAgICAgIDAgIDAgICAgICAwIC91c3Ivc3JjL3N5cy92bS91bWFfY29yZS5jOjIzNTUgKHNsZWVw IG11dGV4OjUxMikKICAgICA5MDEgICAgICAgICAwICAgICAgICAgOTkzICAgICAgICAgICAwICAg ICAgICAgICAyICAgIDQ5NiAgICAgIDAgIDAgICAgICAwIC91c3Ivc3JjL3N5cy92bS92bV9wYWdl ci5jOjMzNiAoc2xlZXAgbXV0ZXg6cGJ1ZiBtdXRleCkKICAgICA2MDAgICAgICAgICAwICAgICAg ICA2MzQ0ICAgICAgICAgICAwICAgICAgICAgIDQyICAgIDE1MSAgICAgIDAgIDAgICAgICAwIC91 c3Ivc3JjL3N5cy92bS91bWFfY29yZS5jOjI2MDIgKHNsZWVwIG11dGV4Ok1BUCBFTlRSWSkKICAg ICAgOTEgICAgICAgICAwICAgICAgICAgMTgwICAgICAgICAgICAwICAgICAgICAgICAyICAgICA5 MCAgICAgIDAgIDAgICAgICAwIC91c3Ivc3JjL3N5cy92bS91bWFfY29yZS5jOjIzNTUgKHNsZWVw IG11dGV4OjEyOCkKICAgICA2NTcgICAgICAgICAwICAgICAgICA3MzkwICAgICAgICAgICAwICAg ICAgICAgIDQ2ICAgIDE2MCAgICAgIDAgIDAgICAgICAwIC91c3Ivc3JjL3N5cy92bS91bWFfY29y ZS5jOjI2MDIgKHNsZWVwIG11dGV4OjUxMikKICAgICAgODYgICAgICAgICAwICAgICAgICAgMTcy ICAgICAgICAgICAwICAgICAgICAgICAyICAgICA4NiAgICAgIDAgIDAgICAgICAwIC91c3Ivc3Jj L3N5cy92bS91bWFfY29yZS5jOjIwMzQgKHNsZWVwIG11dGV4OjY0KQogICAgIDQ1NCAgICAgICAg IDAgICAgICAgICA2MzEgICAgICAgICAgIDAgICAgICAgICAgIDMgICAgMjEwICAgICAgMCAgMCAg ICAgIDAgL3Vzci9zcmMvc3lzL3ZtL3VtYV9jb3JlLmM6OTE0IChzbGVlcCBtdXRleDpGaWxlcykK ICAgIDEwMTIgICAgICAgICAwICAgICAgICA0MzkyICAgICAgICAgICAwICAgICAgICAgIDIzICAg IDE5MCAgICAgIDAgIDAgICAgICAwIC91c3Ivc3JjL3N5cy92bS91bWFfY29yZS5jOjI2NjEgKHNs ZWVwIG11dGV4OjUxMikKICAgICA0MzMgICAgICAgICAwICAgICAgICAgOTc5ICAgICAgICAgICAw ICAgICAgICAgICA2ICAgIDE2MyAgICAgIDAgIDAgICAgICAwIC91c3Ivc3JjL3N5cy92bS91bWFf Y29yZS5jOjIwMzQgKHNsZWVwIG11dGV4Ok5BTUVJKQogICAgICA5MyAgICAgICAgIDAgICAgICAg ICAzNjEgICAgICAgICAgIDAgICAgICAgICAgIDQgICAgIDkwICAgICAgMCAgMCAgICAgIDAgL3Vz ci9zcmMvc3lzL3ZtL3VtYV9jb3JlLmM6MjYwMiAoc2xlZXAgbXV0ZXg6MTI4KQogICAgICA4OSAg ICAgICAgIDAgICAgICAgICAxNzUgICAgICAgICAgIDAgICAgICAgICAgIDIgICAgIDg3ICAgICAg MCAgMCAgICAgIDAgL3Vzci9zcmMvc3lzL3ZtL3VtYV9jb3JlLmM6MjY2MSAoc2xlZXAgbXV0ZXg6 MTI4KQogICAgIDQzMiAgICAgICAgIDAgICAgICAgICA0MzIgICAgICAgICAgIDAgICAgICAgICAg IDEgICAgNDMyICAgICAgMCAgMCAgICAgIDAgL3Vzci9zcmMvc3lzL3ZtL3VtYV9jb3JlLmM6MjM1 NSAoc2xlZXAgbXV0ZXg6NjQpCiAgICAgNjUzICAgICAgICAgMCAgICAgICAgMTQwMiAgICAgICAg ICAgMCAgICAgICAgICAgNyAgICAyMDAgICAgICAwICAwICAgICAgMCAvdXNyL3NyYy9zeXMvdm0v dW1hX2NvcmUuYzoyMzU1IChzbGVlcCBtdXRleDphdGFfcmVxdWVzdCkKICAgICAxMzIgICAgICAg ICAwICAgICAgICAgMzQ3ICAgICAgICAgICAwICAgICAgICAgICAzICAgIDExNSAgICAgIDAgIDAg ICAgICAwIC91c3Ivc3JjL3N5cy92bS91bWFfY29yZS5jOjIzNTUgKHNsZWVwIG11dGV4Ok5BTUVJ KQogICAgIDQ1NSAgICAgICAgIDAgICAgICAgIDIxMzkgICAgICAgICAgIDAgICAgICAgICAgMTIg ICAgMTc4ICAgICAgMCAgMCAgICAgIDAgL3Vzci9zcmMvc3lzL3ZtL3VtYV9jb3JlLmM6MjM1NSAo c2xlZXAgbXV0ZXg6Vk0gT0JKRUNUKQogICAgICA5MyAgICAgICAgIDAgICAgICAgICAzNTggICAg ICAgICAgIDAgICAgICAgICAgIDQgICAgIDg5ICAgICAgMCAgMCAgICAgIDAgL3Vzci9zcmMvc3lz L3ZtL3VtYV9jb3JlLmM6MjYwMiAoc2xlZXAgbXV0ZXg6NjQpCiAgICAgNDU1ICAgICAgICAgMCAg ICAgICAgIDkwMyAgICAgICAgICAgMCAgICAgICAgICAgMiAgICA0NTEgICAgICAwICAwICAgICAg MCAvdXNyL3NyYy9zeXMvdm0vdW1hX2NvcmUuYzoyNjYxIChzbGVlcCBtdXRleDo2NCkKICAgICAg OTQgICAgICAgICAwICAgICAgICAgMTg2ICAgICAgICAgICAwICAgICAgICAgICAyICAgICA5MyAg ICAgIDAgIDAgICAgICAwIC91c3Ivc3JjL3N5cy91ZnMvZmZzL2Zmc192bm9wcy5jOjY4NyAoc2xl ZXAgbXV0ZXg6cHJvY2VzcyBsb2NrKQogICAgIDg4MyAgICAgICAgIDAgICAgICAgIDEzOTUgICAg ICAgICAgIDAgICAgICAgICAgIDYgICAgMjMyICAgICAgMCAgMCAgICAgIDAgL3Vzci9zcmMvc3lz L3ZtL3VtYV9jb3JlLmM6MjYwMiAoc2xlZXAgbXV0ZXg6TkFNRUkpCiAgICAgMTA3ICAgICAgICAg MCAgICAgICAgIDI4MiAgICAgICAgICAgMCAgICAgICAgICAgMyAgICAgOTQgICAgICAwICAwICAg ICAgMCAvdXNyL3NyYy9zeXMvdm0vdW1hX2NvcmUuYzoyNjYxIChzbGVlcCBtdXRleDpOQU1FSSkK ICAgICAgOTMgICAgICAgICAwICAgICAgICAgIDkzICAgICAgICAgICAwICAgICAgICAgICAxICAg ICA5MyAgICAgIDAgIDAgICAgICAwIC91c3Ivc3JjL3N5cy9rZXJuL2tlcm5fZGVzY3JpcC5jOjQ1 NiAoc3g6ZmlsZWRlc2Mgc3RydWN0dXJlKQogICAgIDQ1MyAgICAgICAgIDAgICAgICAgIDIwNDQg ICAgICAgICAgIDAgICAgICAgICAgMzQgICAgIDYwICAgICAgMCAgMCAgICAgIDAgL3Vzci9zcmMv c3lzL3ZtL3Zub2RlX3BhZ2VyLmM6MTM2IChzbGVlcCBtdXRleDp2bSBvYmplY3QpCiAgICAgIDkz ICAgICAgICAgMCAgICAgICAgIDM1OCAgICAgICAgICAgMCAgICAgICAgICAgNCAgICAgODkgICAg ICAwICAwICAgICAgMCAvdXNyL3NyYy9zeXMvdm0vdW1hX2NvcmUuYzoyMDM0IChzbGVlcCBtdXRl eDpGaWxlcykKICAgICAgOTQgICAgICAgICAwICAgICAgICAgMTg2ICAgICAgICAgICAwICAgICAg ICAgICAyICAgICA5MyAgICAgIDAgIDAgICAgICAwIC91c3Ivc3JjL3N5cy92bS92bm9kZV9wYWdl ci5jOjM2OSAoc2xlZXAgbXV0ZXg6dm0gb2JqZWN0KQogICAgICA4OCAgICAgICAgIDAgICAgICAg ICAxNzUgICAgICAgICAgIDAgICAgICAgICAgIDIgICAgIDg3ICAgICAgMCAgMCAgICAgIDAgL3Vz ci9zcmMvc3lzL3ZtL3VtYV9jb3JlLmM6MjM1NSAoc2xlZXAgbXV0ZXg6RmlsZXMpCiAgICAgNDM2 ICAgICAgICAgMCAgICAgICAgIDcwMyAgICAgICAgICAgMCAgICAgICAgICAgNCAgICAxNzUgICAg ICAwICAwICAgICAgMCAvdXNyL3NyYy9zeXMvdm0vdW1hX2NvcmUuYzo5MTQgKHNsZWVwIG11dGV4 OjI1NikKICAgICAxMjYgICAgICAgICAwICAgICAgICAgMjIzICAgICAgICAgICAwICAgICAgICAg ICAyICAgIDExMSAgICAgIDAgIDAgICAgICAwIC91c3Ivc3JjL3N5cy92bS92bm9kZV9wYWdlci5j Ojc2OCAoc2xlZXAgbXV0ZXg6dm0gb2JqZWN0KQogICAgIDY0OCAgICAgICAgIDAgICAgICAgIDcw MjYgICAgICAgICAgIDAgICAgICAgICAgNDIgICAgMTY3ICAgICAgMCAgMCAgICAgIDAgL3Vzci9z cmMvc3lzL3ZtL3VtYV9jb3JlLmM6MjYwMiAoc2xlZXAgbXV0ZXg6RmlsZXMpCiAgICAgIDkxICAg ICAgICAgMCAgICAgICAgIDI2NyAgICAgICAgICAgMCAgICAgICAgICAgMyAgICAgODkgICAgICAw ICAwICAgICAgMCAvdXNyL3NyYy9zeXMva2Vybi9rZXJuX211dGV4LmM6MTM3IChzbGVlcCBtdXRl eDpwaXBlIG11dGV4KQogICAgIDU5MiAgICAgICAgIDAgICAgICAgIDM3OTAgICAgICAgICAgIDAg ICAgICAgICAgMjEgICAgMTgwICAgICAgMCAgMCAgICAgIDAgL3Vzci9zcmMvc3lzL3ZtL3VtYV9j b3JlLmM6MjY2MSAoc2xlZXAgbXV0ZXg6RmlsZXMpCiAgICAgIDcxICAgICAgIDIwMyAgICAgICAg ICA3MSAgICAgICAgIDIwMyAgICAgICAgICAgMSAgICAgNzEgICAgMjAzICAwICAgICAgMSAvdXNy L3NyYy9zeXMva2Vybi9rZXJuX3RocmVhZC5jOjQzNyAoc3BpbiBtdXRleDpzY2hlZCBsb2NrIDI4 KQogICAgICA4NCAgICAgICAgIDAgICAgICAgICAgODQgICAgICAgICAgIDAgICAgICAgICAgIDEg ICAgIDg0ICAgICAgMCAgMCAgICAgIDAgL3Vzci9zcmMvc3lzL2tlcm4va2Vybl90aHJlYWQuYzo0 MzcgKHNwaW4gbXV0ZXg6c2NoZWQgbG9jayAxOSkKICAgICAgODcgICAgICAgNDkwICAgICAgICAg IDg3ICAgICAgICAgNDkwICAgICAgICAgICAxICAgICA4NyAgICA0OTAgIDAgICAgICAxIC91c3Iv c3JjL3N5cy9rZXJuL2tlcm5fdGhyZWFkLmM6NDM3IChzcGluIG11dGV4OnNjaGVkIGxvY2sgMTAp CiAgICAgMTI0ICAgICAgICAgMCAgICAgICAgIDU4NiAgICAgICAgICAgMCAgICAgICAgICAgNiAg ICAgOTcgICAgICAwICAwICAgICAgMCAvdXNyL3NyYy9zeXMva2Vybi9rZXJuX2ZvcmsuYzo0MzUg KHNwaW4gbXV0ZXg6c2NoZWQgbG9jayAyKQogICAgICA0MyAgICAgICAgIDAgICAgICAgICAgNDMg ICAgICAgICAgIDAgICAgICAgICAgIDEgICAgIDQzICAgICAgMCAgMCAgICAgIDAgL3Vzci9zcmMv c3lzL2tlcm4va2Vybl90aHJlYWQuYzo0MzcgKHNwaW4gbXV0ZXg6c2NoZWQgbG9jayAyNCkKICAg ICAxMDMgICAgICAgIDY5ICAgICAgICAgMTAzICAgICAgICAgIDY5ICAgICAgICAgICAxICAgIDEw MyAgICAgNjkgIDAgICAgICAxIC91c3Ivc3JjL3N5cy9rZXJuL2tlcm5fdGhyZWFkLmM6NDM3IChz cGluIG11dGV4OnNjaGVkIGxvY2sgMTUpCiAgICAgMTMyICAgICAgICAgMCAgICAgICAgIDYyNiAg ICAgICAgICAgMCAgICAgICAgICAgNiAgICAxMDQgICAgICAwICAwICAgICAgMCAvdXNyL3NyYy9z eXMva2Vybi9rZXJuX2ZvcmsuYzo3MzEgKHNwaW4gbXV0ZXg6c2NoZWQgbG9jayAyKQogICAgICA4 NiAgICAgICA2NTggICAgICAgICAgODYgICAgICAgICA2NTggICAgICAgICAgIDEgICAgIDg2ICAg IDY1OCAgMCAgICAgIDEgL3Vzci9zcmMvc3lzL2tlcm4va2Vybl90aHJlYWQuYzo0MzcgKHNwaW4g bXV0ZXg6c2NoZWQgbG9jayA2KQogICAgICA2MCAgICAgICAgIDAgICAgICAgICAgNjAgICAgICAg ICAgIDAgICAgICAgICAgIDEgICAgIDYwICAgICAgMCAgMCAgICAgIDAgL3Vzci9zcmMvc3lzL2tl cm4va2Vybl90aHJlYWQuYzo0MzcgKHNwaW4gbXV0ZXg6c2NoZWQgbG9jayAyOSkKICAgICAgNzcg ICAgICAgMjEyICAgICAgICAgIDc3ICAgICAgICAgMjEyICAgICAgICAgICAxICAgICA3NyAgICAy MTIgIDAgICAgICAxIC91c3Ivc3JjL3N5cy9rZXJuL2tlcm5fdGhyZWFkLmM6NDM3IChzcGluIG11 dGV4OnNjaGVkIGxvY2sgMjApCiAgICAgIDkyICAgICAgIDEzNCAgICAgICAgICA5MiAgICAgICAg IDEzNCAgICAgICAgICAgMSAgICAgOTIgICAgMTM0ICAwICAgICAgMSAvdXNyL3NyYy9zeXMva2Vy bi9rZXJuX3NpZy5jOjU5MyAoc3BpbiBtdXRleDpzY2hlZCBsb2NrIDEpCiAgICAgIDg1ICAgICAg IDM3MCAgICAgICAgICA4NSAgICAgICAgIDM3MCAgICAgICAgICAgMSAgICAgODUgICAgMzcwICAw ICAgICAgMSAvdXNyL3NyYy9zeXMva2Vybi9rZXJuX3RocmVhZC5jOjQzNyAoc3BpbiBtdXRleDpz Y2hlZCBsb2NrIDExKQogICAgIDE4MCAgICAgICAgIDAgICAgICAgICA5MjYgICAgICAgICAgIDAg ICAgICAgICAgIDYgICAgMTU0ICAgICAgMCAgMCAgICAgIDAgL3Vzci9zcmMvc3lzL2tlcm4va2Vy bl90aHJlYWQuYzo0MTAgKHNwaW4gbXV0ZXg6c2NoZWQgbG9jayAyKQogICAgICA5NSAgICAgICA0 MjcgICAgICAgICA0NTUgICAgICAgICA1ODUgICAgICAgICAgIDYgICAgIDc1ICAgICA5NyAgMCAg ICAgIDIgL3Vzci9zcmMvc3lzL2tlcm4vc3Vicl90dXJuc3RpbGUuYzoyMDMgKHNwaW4gbXV0ZXg6 c2NoZWQgbG9jayA2KQogICAgICA5NCAgICAgICAgIDAgICAgICAgICA0NTQgICAgICAgICAgIDAg ICAgICAgICAgIDYgICAgIDc1ICAgICAgMCAgMCAgICAgIDAgL3Vzci9zcmMvc3lzL2tlcm4va2Vy bl90aHJlYWQuYzo0MzcgKHNwaW4gbXV0ZXg6c2NoZWQgbG9jayAyKQogICAgICA3MiAgICAgICAg IDAgICAgICAgICAgNzIgICAgICAgICAgIDAgICAgICAgICAgIDEgICAgIDcyICAgICAgMCAgMCAg ICAgIDAgL3Vzci9zcmMvc3lzL2tlcm4va2Vybl90aHJlYWQuYzo0MzcgKHNwaW4gbXV0ZXg6c2No ZWQgbG9jayAyNSkKICAgICAgMTAgICAgICAgICAwICAgICAgICAgIDEwICAgICAgICAgICAwICAg ICAgICAgICAxICAgICAxMCAgICAgIDAgIDAgICAgICAwIC91c3Ivc3JjL3N5cy9rZXJuL2tlcm5f dGhyZWFkLmM6NDM3IChzcGluIG11dGV4OnNjaGVkIGxvY2sgMTYpCiAgICAgMTAxICAgICAgICAg MCAgICAgICAgMjI0NSAgICAgICAgICAgMCAgICAgICAgICAzMiAgICAgNzAgICAgICAwICAwICAg ICAgMCAvdXNyL3NyYy9zeXMva2Vybi9rZXJuX2NwdXNldC5jOjE2NiAoc3BpbiBtdXRleDpjcHVz ZXQpCiAgICAgIDU4ICAgICAgICAgMCAgICAgICAgICA1OCAgICAgICAgICAgMCAgICAgICAgICAg MSAgICAgNTggICAgICAwICAwICAgICAgMCAvdXNyL3NyYy9zeXMva2Vybi9rZXJuX3RocmVhZC5j OjQzNyAoc3BpbiBtdXRleDpzY2hlZCBsb2NrIDMwKQogICAgICA5MyAgICAgICAgIDAgICAgICAg ICA1MzkgICAgICAgICAgIDAgICAgICAgICAgIDcgICAgIDc3ICAgICAgMCAgMCAgICAgIDAgL3Vz ci9zcmMvc3lzL2tlcm4va2Vybl91bXR4LmM6MzM2MCAoc3BpbiBtdXRleDpzY2hlZCBsb2NrIDIp CiAgICAgIDkwICAgICAgICAgMCAgICAgICAgICA5MCAgICAgICAgICAgMCAgICAgICAgICAgMSAg ICAgOTAgICAgICAwICAwICAgICAgMCAvdXNyL3NyYy9zeXMva2Vybi9rZXJuX3RocmVhZC5jOjQz NyAoc3BpbiBtdXRleDpzY2hlZCBsb2NrIDIxKQogICAgICA4OSAgICAgICAgIDAgICAgICAgICAg ODkgICAgICAgICAgIDAgICAgICAgICAgIDEgICAgIDg5ICAgICAgMCAgMCAgICAgIDAgL3Vzci9z cmMvc3lzL2tlcm4va2Vybl90aHJlYWQuYzo0MzcgKHNwaW4gbXV0ZXg6c2NoZWQgbG9jayAxMikK ICAgICAgOTMgICAgICAgICAwICAgICAgICAgNDM4ICAgICAgICAgICAwICAgICAgICAgICA1ICAg ICA4NyAgICAgIDAgIDAgICAgICAwIC91c3Ivc3JjL3N5cy9rZXJuL2tlcm5fdGhyZWFkLmM6NDM3 IChzcGluIG11dGV4OnNjaGVkIGxvY2sgMykKICAgICAgOTUgICAgICAgIDg4ICAgICAgICAyNjU4 ICAgICAgICAgIDg4ICAgICAgICAgIDMwICAgICA4OCAgICAgIDIgIDAgICAgICAxIC91c3Ivc3Jj L3N5cy9rZXJuL3N1YnJfdHVybnN0aWxlLmM6NzI3IChzcGluIG11dGV4OnNjaGVkIGxvY2sgMikK ICAgICAgODIgICAgICAgICAwICAgICAgICAgIDgyICAgICAgICAgICAwICAgICAgICAgICAxICAg ICA4MiAgICAgIDAgIDAgICAgICAwIC91c3Ivc3JjL3N5cy9rZXJuL2tlcm5fdGhyZWFkLmM6NDM3 IChzcGluIG11dGV4OnNjaGVkIGxvY2sgMjYpCiAgICAgIDIwICAgICAgICAgMCAgICAgICAgICAy MCAgICAgICAgICAgMCAgICAgICAgICAgMSAgICAgMjAgICAgICAwICAwICAgICAgMCAvdXNyL3Ny Yy9zeXMva2Vybi9rZXJuX3RocmVhZC5jOjQzNyAoc3BpbiBtdXRleDpzY2hlZCBsb2NrIDE3KQog ICAgIDI4MiAgICAgICAgOTMgICAgICAgIDQ0OTIgICAgICAgICAxNzkgICAgICAgICAgMTcgICAg MjY0ICAgICAxMCAgMCAgICAgIDIgL3Vzci9zcmMvc3lzL2tlcm4vc3Vicl90dXJuc3RpbGUuYzo4 ODkgKHNwaW4gbXV0ZXg6c2NoZWQgbG9jayAyKQogICAgICAyMyAgICAgICAgIDAgICAgICAgICAg MjMgICAgICAgICAgIDAgICAgICAgICAgIDEgICAgIDIzICAgICAgMCAgMCAgICAgIDAgL3Vzci9z cmMvc3lzL2tlcm4va2Vybl90aHJlYWQuYzo0MzcgKHNwaW4gbXV0ZXg6c2NoZWQgbG9jayA4KQog ICAgIDEzOCAgICAgICA2MTIgICAgICAyNzE2MDIgICAgICAgMTAxMjQgICAgICAgIDI5ODEgICAg IDkxICAgICAgMyAgMCAgICAgMzYgL3Vzci9zcmMvc3lzL2tlcm4va2Vybl9pbnRyLmM6MTIzOSAo c3BpbiBtdXRleDpzY2hlZCBsb2NrIDIpCiAgICAgIDU0ICAgICAgICAgMCAgICAgICAgICA1NCAg ICAgICAgICAgMCAgICAgICAgICAgMSAgICAgNTQgICAgICAwICAwICAgICAgMCAvdXNyL3NyYy9z eXMva2Vybi9rZXJuX3RocmVhZC5jOjQzNyAoc3BpbiBtdXRleDpzY2hlZCBsb2NrIDMxKQogICAg IDE3NiAgICAgICAgIDAgICAgICAgICAxNzYgICAgICAgICAgIDAgICAgICAgICAgIDEgICAgMTc2 ICAgICAgMCAgMCAgICAgIDAgL3Vzci9zcmMvc3lzL2tlcm4va2Vybl9zaWcuYzoyMjUxIChzcGlu IG11dGV4OnNjaGVkIGxvY2sgMSkKICAgICAgODggICAgICAgICAwICAgICAgICAgIDg4ICAgICAg ICAgICAwICAgICAgICAgICAxICAgICA4OCAgICAgIDAgIDAgICAgICAwIC91c3Ivc3JjL3N5cy9r ZXJuL2tlcm5fdGhyZWFkLmM6NDM3IChzcGluIG11dGV4OnNjaGVkIGxvY2sgMjIpCiAgICAgMjUz ICAgICAgIDI2MCAgICAgIDUzNDM3MyAgICAgICAgMjkzNSAgICAgICAgMzAyNSAgICAxNzYgICAg ICAwICAwICAgICAxNSAvdXNyL3NyYy9zeXMva2Vybi9zY2hlZF91bGUuYzoxODM1IChzcGluIG11 dGV4OnNjaGVkIGxvY2sgMikKICAgICAgODMgICAgICAgICAwICAgICAgICAgIDgzICAgICAgICAg ICAwICAgICAgICAgICAxICAgICA4MyAgICAgIDAgIDAgICAgICAwIC91c3Ivc3JjL3N5cy9rZXJu L2tlcm5fdGhyZWFkLmM6NDM3IChzcGluIG11dGV4OnNjaGVkIGxvY2sgMTMpCiAgICAgNTQwICAg ICAgICAgMCAgICAgMTM5Njg1NiAgICAgICAgICAgMCAgICAgICAxMTc0NyAgICAxMTggICAgICAw ICAwICAgICAgMCAvdXNyL3NyYy9zeXMva2Vybi9zY2hlZF91bGUuYzoxODc2IChzcGluIG11dGV4 OnNjaGVkIGxvY2sgMikKICAgICAxMzYgICAgICAgMjUyICAgICAgMjY1MjkxICAgICAgICA0ODM4 ICAgICAgICAyOTk2ICAgICA4OCAgICAgIDEgIDAgICAgIDMzIC91c3Ivc3JjL3N5cy9rZXJuL3N1 YnJfc2xlZXBxdWV1ZS5jOjMzNSAoc3BpbiBtdXRleDpzY2hlZCBsb2NrIDIpCiAgICAgMTEyICAg ICAgICAgMCAgICAgICAgMzY4OSAgICAgICAgICAgMCAgICAgICAgICA0NyAgICAgNzggICAgICAw ICAwICAgICAgMCAvdXNyL3NyYy9zeXMva2Vybi9zdWJyX3NsZWVwcXVldWUuYzozOTMgKHNwaW4g bXV0ZXg6c2NoZWQgbG9jayAyKQogICAgICA3MyAgICAgICAgIDAgICAgICAgICAgNzMgICAgICAg ICAgIDAgICAgICAgICAgIDEgICAgIDczICAgICAgMCAgMCAgICAgIDAgL3Vzci9zcmMvc3lzL2tl cm4va2Vybl90aHJlYWQuYzo0MzcgKHNwaW4gbXV0ZXg6c2NoZWQgbG9jayA0KQogICAgIDE3NiAg ICAgICA0NDYgICAgICA0OTQ4NTQgICAgICA0NjQwMjkgICAgICAgIDUzNzUgICAgIDkyICAgICA4 NiAgMCAgIDQ0ODcgL3Vzci9zcmMvc3lzL2tlcm4vc2NoZWRfdWxlLmM6MjA3NCAoc3BpbiBtdXRl eDpzY2hlZCBsb2NrIDIpCiAgICAgIDUzICAgICAgICAgMCAgICAgICAgICA1MyAgICAgICAgICAg MCAgICAgICAgICAgMSAgICAgNTMgICAgICAwICAwICAgICAgMCAvdXNyL3NyYy9zeXMva2Vybi9r ZXJuX3RocmVhZC5jOjQzNyAoc3BpbiBtdXRleDpzY2hlZCBsb2NrIDI3KQogICAgIDEwNSAgICAg ICAgIDAgICAgICAgMTQwMjggICAgICAgICAgIDAgICAgICAgICAxNjcgICAgIDg0ICAgICAgMCAg MCAgICAgIDAgL3Vzci9zcmMvc3lzL2tlcm4vc2NoZWRfdWxlLmM6MjExMSAoc3BpbiBtdXRleDpz Y2hlZCBsb2NrIDIpCiAgICAgMTcyICAgICAgIDIzOCAgICAgICA3MzkzNCAgICAgICAgIDM0NyAg ICAgICAgIDg0MyAgICAgODcgICAgICAwICAwICAgICAgMiAvdXNyL3NyYy9zeXMva2Vybi9zdWJy X3NsZWVwcXVldWUuYzo1ODMgKHNwaW4gbXV0ZXg6c2NoZWQgbG9jayAyKQogICAgIDEzMiAgICAg ICAyMTIgICAgICAxODcyODQgICAgICAgIDIzODcgICAgICAgIDIxMDYgICAgIDg4ICAgICAgMSAg MCAgICAgMjAgL3Vzci9zcmMvc3lzL2tlcm4vc3Vicl9zbGVlcHF1ZXVlLmM6NjE4IChzcGluIG11 dGV4OnNjaGVkIGxvY2sgMikKICAgICAgOTEgICAgICAgMzM2ICAgICAgICAgIDkxICAgICAgICAg MzM2ICAgICAgICAgICAxICAgICA5MSAgICAzMzYgIDAgICAgICAxIC91c3Ivc3JjL3N5cy9rZXJu L2tlcm5fdGhyZWFkLmM6NDM3IChzcGluIG11dGV4OnNjaGVkIGxvY2sgMTgpCiAgICAgIDc1ICAg ICAgIDEwOCAgICAgICAgICA3NSAgICAgICAgIDEwOCAgICAgICAgICAgMSAgICAgNzUgICAgMTA4 ICAwICAgICAgMSAvdXNyL3NyYy9zeXMva2Vybi9rZXJuX3RocmVhZC5jOjQzNyAoc3BpbiBtdXRl eDpzY2hlZCBsb2NrIDkpCiAgICAgMTUzICAgICAgIDYwMSAgICAxMjE5NTI5MyAgICAgIDI1ODY1 NSAgICAgIDE0NjI3NyAgICAgODMgICAgICAxICAwICAgMjAzOSAvdXNyL3NyYy9zeXMva2Vybi9r ZXJuX2Nsb2NrLmM6Mjg2IChzcGluIG11dGV4OnNjaGVkIGxvY2sgMikKICAgICAgNTMgICAgICAg ICAwICAgICAgICAgIDYxICAgICAgICAgICAwICAgICAgICAgICAyICAgICAzMCAgICAgIDAgIDAg ICAgICAwIC91c3Ivc3JjL3N5cy9rZXJuL2tlcm5fdGhyZWFkLmM6NDM3IChzcGluIG11dGV4OnNj aGVkIGxvY2sgMCkKICAgICAxMjggICAgIDE1ODE3ICAgICAgIDIzMDY5ICAgICAgMTgxOTM5ICAg ICAgICAgMjU3ICAgICA4OSAgICA3MDcgIDAgICAgMjE4IC91c3Ivc3JjL3N5cy9rZXJuL3NjaGVk X3VsZS5jOjI1NjkgKHNwaW4gbXV0ZXg6c2NoZWQgbG9jayAyKQogICAgIDEwNSAgICAgICA0ODMg ICAgICAgICAxMDUgICAgICAgICA0ODMgICAgICAgICAgIDEgICAgMTA1ICAgIDQ4MyAgMCAgICAg IDEgL3Vzci9zcmMvc3lzL2tlcm4va2Vybl90aHJlYWQuYzo0MzcgKHNwaW4gbXV0ZXg6c2NoZWQg bG9jayAyMykKICAgICAxMjcgICAgICAgICAwICAgICAgIDEyNTUyICAgICAgICAgICAwICAgICAg ICAgMTM5ICAgICA5MCAgICAgIDAgIDAgICAgICAwIC91c3Ivc3JjL3N5cy9rZXJuL2tlcm5fc3dp dGNoLmM6MTg4IChzcGluIG11dGV4OnNjaGVkIGxvY2sgMikKICAgICAgOTIgICAgICAgICAwICAg ICAgICAgMTgzICAgICAgICAgICAwICAgICAgICAgICAyICAgICA5MSAgICAgIDAgIDAgICAgICAw IC91c3Ivc3JjL3N5cy9rZXJuL3NjaGVkX3VsZS5jOjI2MjcgKHNwaW4gbXV0ZXg6c2NoZWQgbG9j ayAyKQogICAgIDE0MyAgICAgICAzNzcgICAgIDE2MjQ1MDAgICAgICAgNTE5MTMgICAgICAgMTk0 NTUgICAgIDgzICAgICAgMiAgMCAgICA0MjIgL3Vzci9zcmMvc3lzL2tlcm4va2Vybl9jbG9jay5j OjUwMyAoc3BpbiBtdXRleDpzY2hlZCBsb2NrIDIpCiAgICAgMTE0ICAgICAgICAgMCAgICAgICA1 NDY4MSAgICAgICAgICAgMCAgICAgICAgIDYyMSAgICAgODggICAgICAwICAwICAgICAgMCAvdXNy L3NyYy9zeXMva2Vybi9zdWJyX3RyYXAuYzoxNjcgKHNwaW4gbXV0ZXg6c2NoZWQgbG9jayAyKQog ICAgIDEyOSAgICAgICAgIDAgICAgICAgNTQ3MDIgICAgICAgICAgIDAgICAgICAgICA2MTkgICAg IDg4ICAgICAgMCAgMCAgICAgIDAgL3Vzci9zcmMvc3lzL2tlcm4vc3Vicl90cmFwLmM6MjEzIChz cGluIG11dGV4OnNjaGVkIGxvY2sgMikKICAgICAgODIgICAgICAgNDc4ICAgICAgICAgIDgyICAg ICAgICAgNDc4ICAgICAgICAgICAxICAgICA4MiAgICA0NzggIDAgICAgICAxIC91c3Ivc3JjL3N5 cy9rZXJuL2tlcm5fdGhyZWFkLmM6NDM3IChzcGluIG11dGV4OnNjaGVkIGxvY2sgMTQpCiAgICAg MTczICAgICAgIDYyNiAgICAgICAyMTAyMiAgICAgICAxNzE4NCAgICAgICAgIDIyNSAgICAgOTMg ICAgIDc2ICAwICAgIDEwMiAvdXNyL3NyYy9zeXMva2Vybi9rZXJuX2ludHIuYzo4MDAgKHNwaW4g bXV0ZXg6c2NoZWQgbG9jayAxMykKICAgICAgMTEgICAgICAgICAwICAgICAgICAgIDExICAgICAg ICAgICAwICAgICAgICAgICAxICAgICAxMSAgICAgIDAgIDAgICAgICAwIC91c3Ivc3JjL3N5cy9r ZXJuL3NjaGVkX3VsZS5jOjIwNjIgKHNwaW4gbXV0ZXg6c2NoZWQgbG9jayAxMikKICAgICAxMTAg ICAgICAgICAwICAgICAgICAgMTEwICAgICAgICAgICAwICAgICAgICAgICAxICAgIDExMCAgICAg IDAgIDAgICAgICAwIC91c3Ivc3JjL3N5cy9rZXJuL2tlcm5fdGhyZWFkLmM6NDM3IChzcGluIG11 dGV4OnNjaGVkIGxvY2sgNSkKICAgICAgODcgICAgICAgICAwICAgICAgICAgIDg3ICAgICAgICAg ICAwICAgICAgICAgICAxICAgICA4NyAgICAgIDAgIDAgICAgICAwIC91c3Ivc3JjL3N5cy9rZXJu L3Zmc19tb3VudC5jOjQ1MyAoc2xlZXAgbXV0ZXg6c3RydWN0IG1vdW50IG10eCkKICAgICAxMzkg ICAgICAgICAwICAgICAgICAgMTM5ICAgICAgICAgICAwICAgICAgICAgICAxICAgIDEzOSAgICAg IDAgIDAgICAgICAwIC91c3Ivc3JjL3N5cy9rZXJuL3Zmc19iaW8uYzozNTQ5IChzbGVlcCBtdXRl eDp2bSBvYmplY3QpCiAgIDE3NTAxICAgICAgMjE4MCAgICAgICAxNzUwMSAgICAgICAgMjE4MCAg ICAgICAgICAgMSAgMTc1MDEgICAyMTgwICAwICAgICAgMSAvdXNyL3NyYy9zeXMva2Vybi92ZnNf YmlvLmM6MzY1MCAoc2xlZXAgbXV0ZXg6dm0gb2JqZWN0KQogICAgIDY2MiAgICAgICAgIDAgICAg ICAgIDExMzUgICAgICAgICAgIDAgICAgICAgICAgIDYgICAgMTg5ICAgICAgMCAgMCAgICAgIDAg L3Vzci9zcmMvc3lzL3ZtL3VtYV9jb3JlLmM6OTE0IChzbGVlcCBtdXRleDozMikKICAgICAgODgg ICAgICAgICAwICAgICAgICAgIDg4ICAgICAgICAgICAwICAgICAgICAgICAxICAgICA4OCAgICAg IDAgIDAgICAgICAwIC91c3Ivc3JjL3N5cy91ZnMvZmZzL2Zmc19hbGxvYy5jOjk0MiAoc2xlZXAg bXV0ZXg6RkZTKQogICAgICA5MiAgICAgICAgIDAgICAgICAgICAgOTIgICAgICAgICAgIDAgICAg ICAgICAgIDEgICAgIDkyICAgICAgMCAgMCAgICAgIDAgL3Vzci9zcmMvc3lzL3Vmcy9mZnMvZmZz X3NvZnRkZXAuYzoxMzc5IChzbGVlcCBtdXRleDpTb2Z0ZGVwIExvY2spCiAgICAgIDgzICAgICAg ICAgMCAgICAgICAgICA4MyAgICAgICAgICAgMCAgICAgICAgICAgMSAgICAgODMgICAgICAwICAw ICAgICAgMCAvdXNyL3NyYy9zeXMvdWZzL2Zmcy9mZnNfc29mdGRlcC5jOjE1NDQgKHNsZWVwIG11 dGV4OlNvZnRkZXAgTG9jaykKICAgICAgOTQgICAgICAgICAwICAgICAgICAgIDk0ICAgICAgICAg ICAwICAgICAgICAgICAxICAgICA5NCAgICAgIDAgIDAgICAgICAwIC91c3Ivc3JjL3N5cy91ZnMv ZmZzL2Zmc19zb2Z0ZGVwLmM6MTU3NiAoc2xlZXAgbXV0ZXg6U29mdGRlcCBMb2NrKQogICAgICA3 OSAgICAgICAgIDAgICAgICAgICAgNzkgICAgICAgICAgIDAgICAgICAgICAgIDEgICAgIDc5ICAg ICAgMCAgMCAgICAgIDAgL3Vzci9zcmMvc3lzL3Vmcy9mZnMvZmZzX3NvZnRkZXAuYzoxNjExIChz bGVlcCBtdXRleDpTb2Z0ZGVwIExvY2spCiAgICAgNjQ3ICAgICAgICAgMCAgICAgICAgIDY0NyAg ICAgICAgICAgMCAgICAgICAgICAgMSAgICA2NDcgICAgICAwICAwICAgICAgMCAvdXNyL3NyYy9z eXMvdWZzL2Zmcy9mZnNfc29mdGRlcC5jOjE2NzkgKHNsZWVwIG11dGV4OlNvZnRkZXAgTG9jaykK ICAgICAgOTggICAgICAgICAwICAgICAgICAgIDk4ICAgICAgICAgICAwICAgICAgICAgICAxICAg ICA5OCAgICAgIDAgIDAgICAgICAwIC91c3Ivc3JjL3N5cy91ZnMvZmZzL2Zmc19hbGxvYy5jOjE0 OTQgKHNsZWVwIG11dGV4OkZGUykKICAgICA3MjEgICAgICAgICAwICAgICAgICAxNjI5ICAgICAg ICAgICAwICAgICAgICAgIDEwICAgIDE2MiAgICAgIDAgIDAgICAgICAwIC91c3Ivc3JjL3N5cy92 bS91bWFfY29yZS5jOjIwMzQgKHNsZWVwIG11dGV4OjMyKQogICAgICA3NSAgICAgICAgIDAgICAg ICAgICAgNzUgICAgICAgICAgIDAgICAgICAgICAgIDEgICAgIDc1ICAgICAgMCAgMCAgICAgIDAg L3Vzci9zcmMvc3lzL3Vmcy9mZnMvZmZzX2FsbG9jLmM6MTc5MyAoc2xlZXAgbXV0ZXg6RkZTKQog ICAgIDYwNCAgICAgICAgIDAgICAgICAgIDE0MTIgICAgICAgICAgIDAgICAgICAgICAgIDQgICAg MzUzICAgICAgMCAgMCAgICAgIDAgL3Vzci9zcmMvc3lzL2tlcm4vdmZzX2Jpby5jOjM2NjIgKHNs ZWVwIG11dGV4OnZtIHBhZ2UgcXVldWUgbXV0ZXgpCiAgICAgMTU3ICAgICAgICAgMCAgICAgICAg IDU1MiAgICAgICAgICAgMCAgICAgICAgICAgNSAgICAxMTAgICAgICAwICAwICAgICAgMCAvdXNy L3NyYy9zeXMvdm0vdW1hX2NvcmUuYzoyMzU1IChzbGVlcCBtdXRleDozMikKICAgICAgODggICAg ICAgICAwICAgICAgICAgIDg4ICAgICAgICAgICAwICAgICAgICAgICAxICAgICA4OCAgICAgIDAg IDAgICAgICAwIC91c3Ivc3JjL3N5cy9rZXJuL3Zmc19zdWJyLmM6MTYwNCAoc2xlZXAgbXV0ZXg6 YnVmb2JqIGludGVybG9jaykKICAgICA3MDYgICAgICAgICAwICAgICAgICAyMDExICAgICAgICAg ICAwICAgICAgICAgIDEwICAgIDIwMSAgICAgIDAgIDAgICAgICAwIC91c3Ivc3JjL3N5cy92bS91 bWFfY29yZS5jOjI2MDIgKHNsZWVwIG11dGV4OjMyKQogICAgIDYxMiAgICAgICAgIDAgICAgICAg IDEwMTYgICAgICAgICAgIDAgICAgICAgICAgIDUgICAgMjAzICAgICAgMCAgMCAgICAgIDAgL3Vz ci9zcmMvc3lzL3ZtL3VtYV9jb3JlLmM6MjY2MSAoc2xlZXAgbXV0ZXg6MzIpCiAgICAgNDM2ICAg ICAgICAgMCAgICAgICAgMTIzNSAgICAgICAgICAgMCAgICAgICAgICAxMCAgICAxMjMgICAgICAw ICAwICAgICAgMCAvdXNyL3NyYy9zeXMvdm0vdW1hX2NvcmUuYzoyNDY0IChzbGVlcCBtdXRleDpW TSBPQkpFQ1QpCiAgICAgIDk0ICAgICAgICAgMCAgICAgICAgICA5NCAgICAgICAgICAgMCAgICAg ICAgICAgMSAgICAgOTQgICAgICAwICAwICAgICAgMCAvdXNyL3NyYy9zeXMvdWZzL2Zmcy9mZnNf dmZzb3BzLmM6MTczNyAoc2xlZXAgbXV0ZXg6YnVmb2JqIGludGVybG9jaykKICAgICAgODcgICAg ICAgICAwICAgICAgICAgIDg3ICAgICAgICAgICAwICAgICAgICAgICAxICAgICA4NyAgICAgIDAg IDAgICAgICAwIC91c3Ivc3JjL3N5cy91ZnMvZmZzL2Zmc192ZnNvcHMuYzoxNzU5IChzbGVlcCBt dXRleDpidWZvYmogaW50ZXJsb2NrKQogICAgICA5MSAgICAgICAgIDAgICAgICAgICAgOTEgICAg ICAgICAgIDAgICAgICAgICAgIDEgICAgIDkxICAgICAgMCAgMCAgICAgIDAgL3Vzci9zcmMvc3lz L3ZtL3VtYV9jb3JlLmM6OTE0IChzbGVlcCBtdXRleDoxNikKICAgICAgOTIgICAgICAgICAwICAg ICAgICAgIDkyICAgICAgICAgICAwICAgICAgICAgICAxICAgICA5MiAgICAgIDAgIDAgICAgICAw IC91c3Ivc3JjL3N5cy91ZnMvZmZzL2Zmc192ZnNvcHMuYzoxMjE3IChzbGVlcCBtdXRleDpGRlMp CiAgICAgIDk2ICAgICAgICAgMCAgICAgICAgICA5NiAgICAgICAgICAgMCAgICAgICAgICAgMSAg ICAgOTYgICAgICAwICAwICAgICAgMCAvdXNyL3NyYy9zeXMvdWZzL2Zmcy9mZnNfYmFsbG9jLmM6 NzA4IChzbGVlcCBtdXRleDpGRlMpCiAgICAxMDUwICAgICAgICAgMCAgICAgICAgMTA1MCAgICAg ICAgICAgMCAgICAgICAgICAgMSAgIDEwNTAgICAgICAwICAwICAgICAgMCAvdXNyL3NyYy9zeXMv ZnMvZGV2ZnMvZGV2ZnNfdm5vcHMuYzo1MjUgKGxvY2ttZ3I6ZGV2ZnMpCiAgICAgMTAzICAgICAg ICAgMCAgICAgICAxNTQxOSAgICAgICAgICAgMCAgICAgICAgIDE3OCAgICAgODYgICAgICAwICAw ICAgICAgMCAvdXNyL3NyYy9zeXMva2Vybi9zY2hlZF91bGUuYzoyMTExIChzcGluIG11dGV4OnNj aGVkIGxvY2sgMykKICAgICAxMjEgICAgICAgIDk1ICAgICAgIDU5NzAwICAgICAgICAgIDk1ICAg ICAgICAgNjc5ICAgICA4NyAgICAgIDAgIDAgICAgICAxIC91c3Ivc3JjL3N5cy9rZXJuL3N1YnJf c2xlZXBxdWV1ZS5jOjU4MyAoc3BpbiBtdXRleDpzY2hlZCBsb2NrIDMpCiAgICAgMTM1ICAgICAg IDIzMiAgICAgIDE3MzI4OCAgICAgICAgMTAxMyAgICAgICAgMTkzMiAgICAgODkgICAgICAwICAw ICAgICAgOSAvdXNyL3NyYy9zeXMva2Vybi9zdWJyX3NsZWVwcXVldWUuYzo2MTggKHNwaW4gbXV0 ZXg6c2NoZWQgbG9jayAzKQogICAgIDE1MSAgICAgICAzOTUgICAgMTIyMDgyMDcgICAgICAyNjgw ODAgICAgICAxNDY3NDUgICAgIDgzICAgICAgMSAgMCAgIDIxNjUgL3Vzci9zcmMvc3lzL2tlcm4v a2Vybl9jbG9jay5jOjI4NiAoc3BpbiBtdXRleDpzY2hlZCBsb2NrIDMpCiAgICAgMTMzICAgICAy NTA4MyAgICAgICAyMTM2OCAgICAgIDE2MjEwMCAgICAgICAgIDIzMyAgICAgOTEgICAgNjk1ICAw ICAgIDIwNyAvdXNyL3NyYy9zeXMva2Vybi9zY2hlZF91bGUuYzoyNTY5IChzcGluIG11dGV4OnNj aGVkIGxvY2sgMykKICAgICAxNTMgICAgICAgICAwICAgICAgIDEwNTUxICAgICAgICAgICAwICAg ICAgICAgMTE2ICAgICA5MCAgICAgIDAgIDAgICAgICAwIC91c3Ivc3JjL3N5cy9rZXJuL2tlcm5f c3dpdGNoLmM6MTg4IChzcGluIG11dGV4OnNjaGVkIGxvY2sgMykKICAgICAgOTEgICAgICAgICAw ICAgICAgICAgMjY2ICAgICAgICAgICAwICAgICAgICAgICAzICAgICA4OCAgICAgIDAgIDAgICAg ICAwIC91c3Ivc3JjL3N5cy9rZXJuL3NjaGVkX3VsZS5jOjI2MjcgKHNwaW4gbXV0ZXg6c2NoZWQg bG9jayAzKQogICAgIDEzOSAgICAgICAyNjcgICAgIDE2MzAwMTIgICAgICAgMzYyNTAgICAgICAg MTk1MTcgICAgIDgzICAgICAgMSAgMCAgICAzMTYgL3Vzci9zcmMvc3lzL2tlcm4va2Vybl9jbG9j ay5jOjUwMyAoc3BpbiBtdXRleDpzY2hlZCBsb2NrIDMpCiAgICAgMTEzICAgICAgICAgMCAgICAg ICA1NDM3OSAgICAgICAgICAgMCAgICAgICAgIDYxNiAgICAgODggICAgICAwICAwICAgICAgMCAv dXNyL3NyYy9zeXMva2Vybi9zdWJyX3RyYXAuYzoxNjcgKHNwaW4gbXV0ZXg6c2NoZWQgbG9jayAz KQogICAgIDEyNyAgICAgICAgIDAgICAgICAgNTQ1MjMgICAgICAgICAgIDAgICAgICAgICA2MTYg ICAgIDg4ICAgICAgMCAgMCAgICAgIDAgL3Vzci9zcmMvc3lzL2tlcm4vc3Vicl90cmFwLmM6MjEz IChzcGluIG11dGV4OnNjaGVkIGxvY2sgMykKICAgICAgODggICAgICAgICAwICAgICAgICAgMjYw ICAgICAgICAgICAwICAgICAgICAgICAzICAgICA4NiAgICAgIDAgIDAgICAgICAwIC91c3Ivc3Jj L3N5cy9rZXJuL2tlcm5fZm9yay5jOjQzNSAoc3BpbiBtdXRleDpzY2hlZCBsb2NrIDMpCiAgICAg MTAxICAgICAgICAgMCAgICAgICAgIDI4MyAgICAgICAgICAgMCAgICAgICAgICAgMyAgICAgOTQg ICAgICAwICAwICAgICAgMCAvdXNyL3NyYy9zeXMva2Vybi9rZXJuX2ZvcmsuYzo3MzEgKHNwaW4g bXV0ZXg6c2NoZWQgbG9jayAzKQogICAgICA4OCAgICAgICAyMDMgICAgICAgICAgODggICAgICAg ICAyMDMgICAgICAgICAgIDEgICAgIDg4ICAgIDIwMyAgMCAgICAgIDEgL3Vzci9zcmMvc3lzL2tl cm4va2Vybl90aHJlYWQuYzo0MzcgKHNwaW4gbXV0ZXg6c2NoZWQgbG9jayA3KQogICAgIDE3OSAg ICAgICAyMTggICAgICAgICA1MzMgICAgICAgICAyMTggICAgICAgICAgIDMgICAgMTc3ICAgICA3 MiAgMCAgICAgIDEgL3Vzci9zcmMvc3lzL2tlcm4vc2NoZWRfdWxlLmM6ODA2IChzcGluIG11dGV4 OnNjaGVkIGxvY2sgMikKICAgICAyMDUgICAgICAgICAwICAgICAgICAgOTAzICAgICAgICAgICAw ICAgICAgICAgICA1ICAgIDE4MCAgICAgIDAgIDAgICAgICAwIC91c3Ivc3JjL3N5cy9rZXJuL2tl cm5fdGhyZWFkLmM6NDEwIChzcGluIG11dGV4OnNjaGVkIGxvY2sgMykKICAgICA2NjYgICAgICAg ICAwICAgICAgICA2MDQ0ICAgICAgICAgICAwICAgICAgICAgIDE1ICAgIDQwMiAgICAgIDAgIDAg ICAgICAwIC91c3Ivc3JjL3N5cy9rZXJuL3NjaGVkX3VsZS5jOjgwMyAoc3BpbiBtdXRleDpzY2hl ZCBsb2NrIDMpCiAgICAgIDkyICAgICAgICAgMCAgICAgICAgIDYxNyAgICAgICAgICAgMCAgICAg ICAgICAgNyAgICAgODggICAgICAwICAwICAgICAgMCAvdXNyL3NyYy9zeXMva2Vybi9rZXJuX3Vt dHguYzozMzYwIChzcGluIG11dGV4OnNjaGVkIGxvY2sgMykKICAgICAgOTUgICAgICAgICAwICAg ICAgICAyMTMwICAgICAgICAgICAwICAgICAgICAgIDI0ICAgICA4OCAgICAgIDAgIDAgICAgICAw IC91c3Ivc3JjL3N5cy9rZXJuL3N1YnJfdHVybnN0aWxlLmM6NzI3IChzcGluIG11dGV4OnNjaGVk IGxvY2sgMykKICAgICAyNzYgICAgICAgICAwICAgICAgICAyOTQyICAgICAgICAgICAwICAgICAg ICAgIDExICAgIDI2NyAgICAgIDAgIDAgICAgICAwIC91c3Ivc3JjL3N5cy9rZXJuL3N1YnJfdHVy bnN0aWxlLmM6ODg5IChzcGluIG11dGV4OnNjaGVkIGxvY2sgMykKICAgICAxMzcgICAgICAgNTY5 ICAgICAgMjI0ODk3ICAgICAgICAzNTkyICAgICAgICAyNDk1ICAgICA5MCAgICAgIDEgIDAgICAg IDE2IC91c3Ivc3JjL3N5cy9rZXJuL2tlcm5faW50ci5jOjEyMzkgKHNwaW4gbXV0ZXg6c2NoZWQg bG9jayAzKQogICAgIDI0NyAgICAgICAyNjIgICAgICA0NzE1OTMgICAgICAgIDE5ODYgICAgICAg IDI2NDQgICAgMTc4ICAgICAgMCAgMCAgICAgMTAgL3Vzci9zcmMvc3lzL2tlcm4vc2NoZWRfdWxl LmM6MTgzNSAoc3BpbiBtdXRleDpzY2hlZCBsb2NrIDMpCiAgICAgNjM0ICAgICAgICAgMCAgICAg MTIzMDQ4OSAgICAgICAgICAgMCAgICAgICAxMDA1NSAgICAxMjIgICAgICAwICAwICAgICAgMCAv dXNyL3NyYy9zeXMva2Vybi9zY2hlZF91bGUuYzoxODc2IChzcGluIG11dGV4OnNjaGVkIGxvY2sg MykKICAgICAxMzQgICAgICAgMjE2ICAgICAgMjMzODY1ICAgICAgICAzMDQwICAgICAgICAyNjIw ICAgICA4OSAgICAgIDEgIDAgICAgIDI1IC91c3Ivc3JjL3N5cy9rZXJuL3N1YnJfc2xlZXBxdWV1 ZS5jOjMzNSAoc3BpbiBtdXRleDpzY2hlZCBsb2NrIDMpCiAgICAgIDk5ICAgICAgICAgMCAgICAg ICAgIDgwMiAgICAgICAgICAgMCAgICAgICAgICAgOSAgICAgODkgICAgICAwICAwICAgICAgMCAv dXNyL3NyYy9zeXMva2Vybi9zdWJyX3NsZWVwcXVldWUuYzozOTMgKHNwaW4gbXV0ZXg6c2NoZWQg bG9jayAzKQogICAgIDEyNSAgICAgICAgIDAgICAgICAgICA0NjkgICAgICAgICAgIDAgICAgICAg ICAgIDUgICAgIDkzICAgICAgMCAgMCAgICAgIDAgL3Vzci9zcmMvc3lzL2tlcm4vc2NoZWRfdWxl LmM6MjA2MiAoc3BpbiBtdXRleDpzY2hlZCBsb2NrIDMpCiAgICAgMTYyICAgICAgIDM1NiAgICAg IDQxOTczMyAgICAgIDM1Njg2MiAgICAgICAgNDU3OSAgICAgOTEgICAgIDc3ICAwICAgMzU0NyAv dXNyL3NyYy9zeXMva2Vybi9zY2hlZF91bGUuYzoyMDc0IChzcGluIG11dGV4OnNjaGVkIGxvY2sg MykKICAgIDE1NzMgICAgICAgICAwICAgICAgIDMwMTczICAgICAgICAgICAwICAgICAgICAgIDMy ICAgIDk0MiAgICAgIDAgIDAgICAgICAwIC91c3Ivc3JjL3N5cy9rZXJuL3Zmc19zeXNjYWxscy5j OjExNjkgKGxvY2ttZ3I6dWZzKQogICAgMTI5MyAgICAgIDgyNTIgICAgICAgIDQyNjkgICAgICAg IDg2MDcgICAgICAgICAgMTkgICAgMjI0ICAgIDQ1MyAgMCAgICAgIDQgL3Vzci9zcmMvc3lzL2tl cm4va2Vybl9tdXRleC5jOjEzNyAoc2xlZXAgbXV0ZXg6dHR5bXR4KQogICAgMTYzNyAgICAgICAg IDAgICAgICAyODUyMzQgICAgICAgICAgIDAgICAgICAgICA5ODQgICAgMjg5ICAgICAgMCAgMCAg ICAgIDAgL3Vzci9zcmMvc3lzL2Rldi9zeXNjb25zL3N5c21vdXNlLmM6MTkxIChzbGVlcCBtdXRl eDp0dHltdHgpCiAgICAgNzU0ICAgICAgICAgMCAgICAgICAxMjMyOCAgICAgICAgICAgMCAgICAg ICAgICAzMiAgICAzODUgICAgICAwICAwICAgICAgMCAvdXNyL3NyYy9zeXMva2Vybi9zeXNfZ2Vu ZXJpYy5jOjExODAgKHN4OmZpbGVkZXNjIHN0cnVjdHVyZSkKICAgIDI4ODcgICAgIDE0NDAwICAg ICAxNDQxODMyICAgICAgIDkzNTEzICAgICAgICAgOTg0ICAgMTQ2NSAgICAgOTUgIDAgICAgIDY1 IC91c3Ivc3JjL3N5cy9rZXJuL3R0eS5jOjE1OCAoc2xlZXAgbXV0ZXg6R2lhbnQpCiAgICAxNjQ5 ICAgICAgICAgMCAgICAgICAgMzg5OSAgICAgICAgICAgMCAgICAgICAgICAxNCAgICAyNzggICAg ICAwICAwICAgICAgMCAvdXNyL3NyYy9zeXMva2Vybi90dHlfaW5xLmM6MjMzIChzbGVlcCBtdXRl eDp0dHltdHgpCiAgICAgMTQwICAgICAgIDEzOSAgICAgICAyMDM4OCAgICAgICAgIDQwMyAgICAg ICAgIDE1NSAgICAxMzEgICAgICAyICAwICAgICAgMyAvdXNyL3NyYy9zeXMva2Vybi9zdWJyX3R1 cm5zdGlsZS5jOjcyNyAoc3BpbiBtdXRleDpzY2hlZCBsb2NrIDQpCiAgICAgNTcyICAgICAgIDE0 MSAgICAgICA1MTcyOSAgICAgICAgIDQwOSAgICAgICAgIDEzMSAgICAzOTQgICAgICAzICAwICAg ICAgMyAvdXNyL3NyYy9zeXMva2Vybi9zdWJyX3R1cm5zdGlsZS5jOjg4OSAoc3BpbiBtdXRleDpz Y2hlZCBsb2NrIDQpCiAgICAgMTU0ICAgICAgIDE3MiAgICAgICA2OTg5OSAgICAgICAgIDUxNyAg ICAgICAgIDYwMCAgICAxMTYgICAgICAwICAwICAgICAgNCAvdXNyL3NyYy9zeXMva2Vybi9rZXJu X2ludHIuYzoxMjM5IChzcGluIG11dGV4OnNjaGVkIGxvY2sgNCkKICAgIDE1MTcgICAgICAgODMw ICAgICAgIDEwNDYwICAgICAgICA0Mzc1ICAgICAgICAgIDM1ICAgIDI5OCAgICAxMjUgIDAgICAg IDE1IC91c3Ivc3JjL3N5cy9rZXJuL3N1YnJfdHVybnN0aWxlLmM6NTUwIChzcGluIG11dGV4OnR1 cm5zdGlsZSBsb2NrKQogICAgIDMxMiAgICAgICAyMjkgICAgICA1NTk4NzQgICAgICAgICA3NTQg ICAgICAgIDI0MDMgICAgMjMyICAgICAgMCAgMCAgICAgIDQgL3Vzci9zcmMvc3lzL2tlcm4vc2No ZWRfdWxlLmM6MTgzNSAoc3BpbiBtdXRleDpzY2hlZCBsb2NrIDQpCiAgICAgMTMzICAgICAgICAg MCAgICAgICAgIDEzMyAgICAgICAgICAgMCAgICAgICAgICAgMSAgICAxMzMgICAgICAwICAwICAg ICAgMCAvdXNyL3NyYy9zeXMva2Vybi9zdWJyX3NsZWVwcXVldWUuYzo4MzAgKHNwaW4gbXV0ZXg6 c2NoZWQgbG9jayA4KQogICAgIDY5MCAgICAgICAgIDAgICAgICA5MDM1NDQgICAgICAgICAgIDAg ICAgICAgIDU3ODAgICAgMTU2ICAgICAgMCAgMCAgICAgIDAgL3Vzci9zcmMvc3lzL2tlcm4vc2No ZWRfdWxlLmM6MTg3NiAoc3BpbiBtdXRleDpzY2hlZCBsb2NrIDQpCiAgICAgMTgxICAgICAgIDE1 OCAgICAgIDI1OTc5NyAgICAgICAgIDY5OCAgICAgICAgMjI0OCAgICAxMTUgICAgICAwICAwICAg ICAgNSAvdXNyL3NyYy9zeXMva2Vybi9zdWJyX3NsZWVwcXVldWUuYzozMzUgKHNwaW4gbXV0ZXg6 c2NoZWQgbG9jayA0KQogICAgIDEzOCAgICAgICAgIDAgICAgICAgIDIwMzAgICAgICAgICAgIDAg ICAgICAgICAgMzMgICAgIDYxICAgICAgMCAgMCAgICAgIDAgL3Vzci9zcmMvc3lzL2tlcm4vc3Vi cl9zbGVlcHF1ZXVlLmM6MzkzIChzcGluIG11dGV4OnNjaGVkIGxvY2sgNCkKICAgICAyMzEgICAg ICAgMzk2ICAgICAgMjYxOTk4ICAgICAgMTY5OTcyICAgICAgICAyMjc0ICAgIDExNSAgICAgNzQg IDAgICAxNTQ1IC91c3Ivc3JjL3N5cy9rZXJuL3NjaGVkX3VsZS5jOjIwNzQgKHNwaW4gbXV0ZXg6 c2NoZWQgbG9jayA0KQogICAgIDE1OCAgICAgIDc1MDcgICAgICAgMjM5NjQgICAgICAgMTM4NTkg ICAgICAgICAyMDcgICAgMTE1ICAgICA2NiAgMCAgICAgIDIgL3Vzci9zcmMvc3lzL2tlcm4vc2No ZWRfdWxlLmM6MjExMSAoc3BpbiBtdXRleDpzY2hlZCBsb2NrIDQpCiAgICAgMTYzICAgICAgICAg MCAgICAgICA3OTc5MSAgICAgICAgICAgMCAgICAgICAgIDY0MiAgICAxMjQgICAgICAwICAwICAg ICAgMCAvdXNyL3NyYy9zeXMva2Vybi9zdWJyX3NsZWVwcXVldWUuYzo1ODMgKHNwaW4gbXV0ZXg6 c2NoZWQgbG9jayA0KQogICAgIDE2NiAgICAgICAgIDAgICAgICAxNzkzMzcgICAgICAgICAgIDAg ICAgICAgIDE1NzMgICAgMTE0ICAgICAgMCAgMCAgICAgIDAgL3Vzci9zcmMvc3lzL2tlcm4vc3Vi cl9zbGVlcHF1ZXVlLmM6NjE4IChzcGluIG11dGV4OnNjaGVkIGxvY2sgNCkKICAgICAxNzkgICAg ICAgNTUzICAgIDE2OTY0ODkyICAgICAgIDc4MjQ5ICAgICAgMTQ1OTQ4ICAgIDExNiAgICAgIDAg IDAgICAgNDM5IC91c3Ivc3JjL3N5cy9rZXJuL2tlcm5fY2xvY2suYzoyODYgKHNwaW4gbXV0ZXg6 c2NoZWQgbG9jayA0KQogICAgICA1OSAgICAgICAgNTYgICAgICAgICA2NDkgICAgICAgICA1ODgg ICAgICAgICAgMjkgICAgIDIyICAgICAyMCAgMCAgICAgMjcgL3Vzci9zcmMvc3lzL2tlcm4vc2No ZWRfdWxlLmM6MjU2OSAoc3BpbiBtdXRleDpzY2hlZCBsb2NrIDQpCiAgICAgMTcxICAgICAgMTg3 NSAgICAgIDE3Mzc4MiAgICAgICAgMzcyNyAgICAgICAgMTMxNiAgICAxMzIgICAgICAyICAwICAg ICAxMCAvdXNyL3NyYy9zeXMva2Vybi9rZXJuX3N3aXRjaC5jOjE4OCAoc3BpbiBtdXRleDpzY2hl ZCBsb2NrIDQpCiAgICAgMTI2ICAgICAgICAgMCAgICAgICAgIDU4MCAgICAgICAgICAgMCAgICAg ICAgICAxNiAgICAgMzYgICAgICAwICAwICAgICAgMCAvdXNyL3NyYy9zeXMva2Vybi9zY2hlZF91 bGUuYzoyNjI3IChzcGluIG11dGV4OnNjaGVkIGxvY2sgNCkKICAgICAxODMgICAgICAgMjUwICAg ICAyMjcwNTk2ICAgICAgIDEwMjg1ICAgICAgIDE5NDExICAgIDExNiAgICAgIDAgIDAgICAgIDcz IC91c3Ivc3JjL3N5cy9rZXJuL2tlcm5fY2xvY2suYzo1MDMgKHNwaW4gbXV0ZXg6c2NoZWQgbG9j ayA0KQogICAgIDE1OCAgICAgICAgIDAgICAgICAxMjUzMjkgICAgICAgICAgIDAgICAgICAgIDEw MzkgICAgMTIwICAgICAgMCAgMCAgICAgIDAgL3Vzci9zcmMvc3lzL2tlcm4vc3Vicl90cmFwLmM6 MTY3IChzcGluIG11dGV4OnNjaGVkIGxvY2sgNCkKICAgICAxMzkgICAgICAgNDg4ICAgICAgICA0 NDU0ICAgICAgICAgNjIxICAgICAgICAgIDMzICAgIDEzNCAgICAgMTggIDAgICAgICAyIC91c3Iv c3JjL3N5cy9rZXJuL3N1YnJfdHVybnN0aWxlLmM6MjAzIChzcGluIG11dGV4OnNjaGVkIGxvY2sg MjApCiAgICAgMTY4ICAgICAyMDg2NCAgICAgIDEyNzMyMiAgICAgICAzNjg0MyAgICAgICAgMTAz NyAgICAxMjIgICAgIDM1ICAwICAgICAgNSAvdXNyL3NyYy9zeXMva2Vybi9zdWJyX3RyYXAuYzoy MTMgKHNwaW4gbXV0ZXg6c2NoZWQgbG9jayA0KQogICAgIDE5OCAgICAgICA1OTAgICAgICAgIDM2 MTMgICAgICAgICA1OTAgICAgICAgICAgMjIgICAgMTY0ICAgICAyNiAgMCAgICAgIDEgL3Vzci9z cmMvc3lzL2tlcm4vc3Vicl90dXJuc3RpbGUuYzoyMDMgKHNwaW4gbXV0ZXg6c2NoZWQgbG9jayAx NikKICAgICAxNDcgICAgICAgICAwICAgICAgICAgMTQ3ICAgICAgICAgICAwICAgICAgICAgICAx ICAgIDE0NyAgICAgIDAgIDAgICAgICAwIC91c3Ivc3JjL3N5cy9rZXJuL2tlcm5fdGhyZWFkLmM6 NDEwIChzcGluIG11dGV4OnNjaGVkIGxvY2sgNCkKICAgICAgNDUgICAgICAgICAwICAgICAgICAg IDQ1ICAgICAgICAgICAwICAgICAgICAgICAxICAgICA0NSAgICAgIDAgIDAgICAgICAwIC91c3Iv c3JjL3N5cy9rZXJuL2tlcm5fdW10eC5jOjMzNjAgKHNwaW4gbXV0ZXg6c2NoZWQgbG9jayA0KQog ICAgIDE5MyAgICAgICAxMzQgICAgICAgMTI3MTcgICAgICAgIDE1MTggICAgICAgICAxNTUgICAg IDgyICAgICAgOSAgMCAgICAgMTYgL3Vzci9zcmMvc3lzL2tlcm4va2Vybl9pbnRyLmM6ODAwIChz cGluIG11dGV4OnNjaGVkIGxvY2sgOSkKICAgICAyNjcgICAgICAgICAwICAgICAgICAgMzkxICAg ICAgICAgICAwICAgICAgICAgICAyICAgIDE5NSAgICAgIDAgIDAgICAgICAwIC91c3Ivc3JjL3N5 cy9rZXJuL3NjaGVkX3VsZS5jOjgwNyAoc3BpbiBtdXRleDpzY2hlZCBsb2NrIDUpCiAgICAgMTMx ICAgICAgICAgMCAgICAgICAgIDEzMSAgICAgICAgICAgMCAgICAgICAgICAgMSAgICAxMzEgICAg ICAwICAwICAgICAgMCAvdXNyL3NyYy9zeXMva2Vybi9rZXJuX3VtdHguYzozMzYwIChzcGluIG11 dGV4OnNjaGVkIGxvY2sgNSkKICAgICAxMzQgICAgICAgICAwICAgICAgICAgMTM0ICAgICAgICAg ICAwICAgICAgICAgICAxICAgIDEzNCAgICAgIDAgIDAgICAgICAwIC91c3Ivc3JjL3N5cy9rZXJu L3N1YnJfdHVybnN0aWxlLmM6NzI3IChzcGluIG11dGV4OnNjaGVkIGxvY2sgNSkKICAgICAxNTEg ICAgICAgICAwICAgICAgIDEyNDQ3ICAgICAgICAgICAwICAgICAgICAgMTExICAgIDExMiAgICAg IDAgIDAgICAgICAwIC91c3Ivc3JjL3N5cy9rZXJuL2tlcm5faW50ci5jOjEyMzkgKHNwaW4gbXV0 ZXg6c2NoZWQgbG9jayA1KQogICAgIDMwMiAgICAgICAxNzMgICAgICAgNzg2OTggICAgICAgICAx NzMgICAgICAgICA0MjUgICAgMTg1ICAgICAgMCAgMCAgICAgIDEgL3Vzci9zcmMvc3lzL2tlcm4v c2NoZWRfdWxlLmM6MTgzNSAoc3BpbiBtdXRleDpzY2hlZCBsb2NrIDUpCiAgICAgNTU2ICAgICAg ICAgMCAgICAgIDE0OTMzNCAgICAgICAgICAgMCAgICAgICAgMTA2MyAgICAxNDAgICAgICAwICAw ICAgICAgMCAvdXNyL3NyYy9zeXMva2Vybi9zY2hlZF91bGUuYzoxODc2IChzcGluIG11dGV4OnNj aGVkIGxvY2sgNSkKICAgICAxNjEgICAgICAgICAwICAgICAgIDM5NzQ2ICAgICAgICAgICAwICAg ICAgICAgNDI0ICAgICA5MyAgICAgIDAgIDAgICAgICAwIC91c3Ivc3JjL3N5cy9rZXJuL3N1YnJf c2xlZXBxdWV1ZS5jOjMzNSAoc3BpbiBtdXRleDpzY2hlZCBsb2NrIDUpCiAgICAgMTc0ICAgICAg IDMyMiAgICAgICA1Nzg2NCAgICAgICA0MTI0MSAgICAgICAgIDU0MSAgICAxMDYgICAgIDc2ICAw ICAgIDM5MSAvdXNyL3NyYy9zeXMva2Vybi9zY2hlZF91bGUuYzoyMDc0IChzcGluIG11dGV4OnNj aGVkIGxvY2sgNSkKICAgICAxNjQgICAgICAgICAwICAgICAgIDQ1ODI3ICAgICAgICAgICAwICAg ICAgICAgMzY0ICAgIDEyNSAgICAgIDAgIDAgICAgICAwIC91c3Ivc3JjL3N5cy9rZXJuL3NjaGVk X3VsZS5jOjIxMTEgKHNwaW4gbXV0ZXg6c2NoZWQgbG9jayA1KQogICAgIDEzMSAgICAgICAgIDAg ICAgICAgIDQ5MTAgICAgICAgICAgIDAgICAgICAgICAgNDggICAgMTAyICAgICAgMCAgMCAgICAg IDAgL3Vzci9zcmMvc3lzL2tlcm4vc3Vicl9zbGVlcHF1ZXVlLmM6NTgzIChzcGluIG11dGV4OnNj aGVkIGxvY2sgNSkKICAgICAxNTMgICAgICAgICAwICAgICAgIDM0NTkzICAgICAgICAgICAwICAg ICAgICAgMzc2ICAgICA5MiAgICAgIDAgIDAgICAgICAwIC91c3Ivc3JjL3N5cy9rZXJuL3N1YnJf c2xlZXBxdWV1ZS5jOjYxOCAoc3BpbiBtdXRleDpzY2hlZCBsb2NrIDUpCiAgICAgMjE5ICAgICAg IDUyMiAgICAxNzYzNzkzOSAgICAgICAxMTkzMiAgICAgIDE0OTkyNyAgICAxMTcgICAgICAwICAw ICAgICA3NiAvdXNyL3NyYy9zeXMva2Vybi9rZXJuX2Nsb2NrLmM6Mjg2IChzcGluIG11dGV4OnNj aGVkIGxvY2sgNSkKICAgICAxMzMgICAgIDEyNzYwICAgICAgICAyMDk1ICAgICAgIDI2OTMzICAg ICAgICAgIDIwICAgIDEwNCAgIDEzNDYgIDAgICAgIDE5IC91c3Ivc3JjL3N5cy9rZXJuL3NjaGVk X3VsZS5jOjI1NjkgKHNwaW4gbXV0ZXg6c2NoZWQgbG9jayA1KQogICAgIDEzMyAgICAgICAgIDAg ICAgICAgICAzOTggICAgICAgICAgIDAgICAgICAgICAgIDMgICAgMTMyICAgICAgMCAgMCAgICAg IDAgL3Vzci9zcmMvc3lzL2tlcm4va2Vybl9zd2l0Y2guYzoxODggKHNwaW4gbXV0ZXg6c2NoZWQg bG9jayA1KQogICAgIDE3MCAgICAgICAxODcgICAgIDIzNjA5NTIgICAgICAgIDIxNjYgICAgICAg MTk5NDAgICAgMTE4ICAgICAgMCAgMCAgICAgMTggL3Vzci9zcmMvc3lzL2tlcm4va2Vybl9jbG9j ay5jOjUwMyAoc3BpbiBtdXRleDpzY2hlZCBsb2NrIDUpCiAgICAgMTY1ICAgICAgICAgMCAgICAg IDE1NjEwNSAgICAgICAgICAgMCAgICAgICAgMTIwNSAgICAxMjkgICAgICAwICAwICAgICAgMCAv dXNyL3NyYy9zeXMva2Vybi9zdWJyX3RyYXAuYzoxNjcgKHNwaW4gbXV0ZXg6c2NoZWQgbG9jayA1 KQogICAgIDE3NyAgICAgICA5ODkgICAgICAxNTY2MzggICAgICAgIDExNzQgICAgICAgIDEyMDUg ICAgMTI5ICAgICAgMCAgMCAgICAgIDIgL3Vzci9zcmMvc3lzL2tlcm4vc3Vicl90cmFwLmM6MjEz IChzcGluIG11dGV4OnNjaGVkIGxvY2sgNSkKICAgICAyNjUgICAgICAgICAwICAgICAgICAgMjY1 ICAgICAgICAgICAwICAgICAgICAgICAxICAgIDI2NSAgICAgIDAgIDAgICAgICAwIC91c3Ivc3Jj L3N5cy9rZXJuL2tlcm5fdGhyZWFkLmM6NDEwIChzcGluIG11dGV4OnNjaGVkIGxvY2sgNSkKICAg ICA2NjQgICAgICAgICAwICAgICAgICAzNTI1ICAgICAgICAgICAwICAgICAgICAgIDIwICAgIDE3 NiAgICAgIDAgIDAgICAgICAwIC91c3Ivc3JjL3N5cy92bS91bWFfY29yZS5jOjI2NjEgKHNsZWVw IG11dGV4Ok1BUCBFTlRSWSkKICAgICAyMTcgICAgICAgICAwICAgICAgICAgMjE3ICAgICAgICAg ICAwICAgICAgICAgICAxICAgIDIxNyAgICAgIDAgIDAgICAgICAwIC91c3Ivc3JjL3N5cy9rZXJu L2tlcm5fdGhyZWFkLmM6NDEwIChzcGluIG11dGV4OnNjaGVkIGxvY2sgNikKICAgICAgODYgICAg ICAgICAwICAgICAgICAgIDg2ICAgICAgICAgICAwICAgICAgICAgICAxICAgICA4NiAgICAgIDAg IDAgICAgICAwIC91c3Ivc3JjL3N5cy9rZXJuL2tlcm5fdW10eC5jOjMzNjAgKHNwaW4gbXV0ZXg6 c2NoZWQgbG9jayA2KQogICAgIDIyMCAgICAgICAgIDAgICAgICA1NDAyNDIgICAgICAgICAgIDAg ICAgICAgIDQ0MDUgICAgMTIyICAgICAgMCAgMCAgICAgIDAgL3Vzci9zcmMvc3lzL2tlcm4va2Vy bl9pbnRyLmM6ODAwIChzcGluIG11dGV4OnNjaGVkIGxvY2sgNikKICAgICAxMzEgICAgICAgICAw ICAgICAgICAgMTMxICAgICAgICAgICAwICAgICAgICAgICAxICAgIDEzMSAgICAgIDAgIDAgICAg ICAwIC91c3Ivc3JjL3N5cy9rZXJuL3N1YnJfdHVybnN0aWxlLmM6NzI3IChzcGluIG11dGV4OnNj aGVkIGxvY2sgNikKICAgICAzOTAgICAgICAgICAwICAgICAgICAxNjE0ICAgICAgICAgICAwICAg ICAgICAgICA1ICAgIDMyMiAgICAgIDAgIDAgICAgICAwIC91c3Ivc3JjL3N5cy9rZXJuL3N1YnJf dHVybnN0aWxlLmM6ODg5IChzcGluIG11dGV4OnNjaGVkIGxvY2sgNikKICAgICAxODYgICAgICAg MTI5ICAgICAgNDg5NDY2ICAgICAgICAgMTI5ICAgICAgICA0MDIyICAgIDEyMSAgICAgIDAgIDAg ICAgICAxIC91c3Ivc3JjL3N5cy9rZXJuL2tlcm5faW50ci5jOjEyMzkgKHNwaW4gbXV0ZXg6c2No ZWQgbG9jayA2KQogICAgIDI2NSAgICAgICAgIDAgICAgICAgICA1NDMgICAgICAgICAgIDAgICAg ICAgICAgIDQgICAgMTM1ICAgICAgMCAgMCAgICAgIDAgL3Vzci9zcmMvc3lzL2tlcm4vc2NoZWRf dWxlLmM6MTgzNSAoc3BpbiBtdXRleDpzY2hlZCBsb2NrIDYpCiAgICAgMTgwICAgICAgICAgMCAg ICAgIDk2NjE0OCAgICAgICAgICAgMCAgICAgICAgODA1MSAgICAxMjAgICAgICAwICAwICAgICAg MCAvdXNyL3NyYy9zeXMva2Vybi9zY2hlZF91bGUuYzoxODc2IChzcGluIG11dGV4OnNjaGVkIGxv Y2sgNikKICAgICAgNTYgICAgICAgICAwICAgICAgICAgMTU0ICAgICAgICAgICAwICAgICAgICAg ICAzICAgICA1MSAgICAgIDAgIDAgICAgICAwIC91c3Ivc3JjL3N5cy9rZXJuL3N1YnJfc2xlZXBx dWV1ZS5jOjMzNSAoc3BpbiBtdXRleDpzY2hlZCBsb2NrIDYpCiAgICAgMTM4ICAgICAgIDIwMyAg ICAgICAgMzQ0NCAgICAgICAgMzI5MSAgICAgICAgICAyOSAgICAxMTggICAgMTEzICAwICAgICAy NSAvdXNyL3NyYy9zeXMva2Vybi9zY2hlZF91bGUuYzoyMDc0IChzcGluIG11dGV4OnNjaGVkIGxv Y2sgNikKICAgICAxNDMgICAgICAgICAwICAgICAgIDIzODMxICAgICAgICAgICAwICAgICAgICAg MTkwICAgIDEyNSAgICAgIDAgIDAgICAgICAwIC91c3Ivc3JjL3N5cy9rZXJuL3NjaGVkX3VsZS5j OjIxMTEgKHNwaW4gbXV0ZXg6c2NoZWQgbG9jayA2KQogICAgICA0MSAgICAgICAgIDAgICAgICAg ICAxMTMgICAgICAgICAgIDAgICAgICAgICAgIDMgICAgIDM3ICAgICAgMCAgMCAgICAgIDAgL3Vz ci9zcmMvc3lzL2tlcm4vc3Vicl9zbGVlcHF1ZXVlLmM6NTgzIChzcGluIG11dGV4OnNjaGVkIGxv Y2sgNikKICAgICAyMTcgICAgICAgMzk0ICAgIDE3MzcxMDgxICAgICAgICAyNTc5ICAgICAgMTQ3 ODc1ICAgIDExNyAgICAgIDAgIDAgICAgIDEyIC91c3Ivc3JjL3N5cy9rZXJuL2tlcm5fY2xvY2su YzoyODYgKHNwaW4gbXV0ZXg6c2NoZWQgbG9jayA2KQogICAgIDE3NCAgICAgICAgIDAgICAgICA0 ODc0MjUgICAgICAgICAgIDAgICAgICAgIDQwMjIgICAgMTIxICAgICAgMCAgMCAgICAgIDAgL3Vz ci9zcmMvc3lzL2tlcm4va2Vybl9zd2l0Y2guYzoxODggKHNwaW4gbXV0ZXg6c2NoZWQgbG9jayA2 KQogICAgIDE4NSAgICAgICAxMjkgICAgIDIzMTcyNDEgICAgICAgICAxMjkgICAgICAgMTk2Njcg ICAgMTE3ICAgICAgMCAgMCAgICAgIDEgL3Vzci9zcmMvc3lzL2tlcm4va2Vybl9jbG9jay5jOjUw MyAoc3BpbiBtdXRleDpzY2hlZCBsb2NrIDYpCiAgICAgMTYzICAgICAgICAgMCAgICAgIDE0NjU1 MSAgICAgICAgICAgMCAgICAgICAgMTE1NSAgICAxMjYgICAgICAwICAwICAgICAgMCAvdXNyL3Ny Yy9zeXMva2Vybi9zdWJyX3RyYXAuYzoxNjcgKHNwaW4gbXV0ZXg6c2NoZWQgbG9jayA2KQogICAg IDE4OSAgICAgICAgIDAgICAgICAxNDgwODkgICAgICAgICAgIDAgICAgICAgIDExNTUgICAgMTI4 ICAgICAgMCAgMCAgICAgIDAgL3Vzci9zcmMvc3lzL2tlcm4vc3Vicl90cmFwLmM6MjEzIChzcGlu IG11dGV4OnNjaGVkIGxvY2sgNikKICAgICAyNjAgICAgICAgMzI2ICAgICAxNjg5NTk3ICAgICAg IDMxMzkzICAgICAgIDExODExICAgIDE0MyAgICAgIDIgIDAgICAgMTk2IC91c3Ivc3JjL3N5cy9h bWQ2NC9hbWQ2NC9pb19hcGljLmM6MjI5IChzcGluIG11dGV4OmljdSkKICAgICAgODkgICAgICAg ICAwICAgICAgICAgIDg5ICAgICAgICAgICAwICAgICAgICAgICAxICAgICA4OSAgICAgIDAgIDAg ICAgICAwIC91c3Ivc3JjL3N5cy9rZXJuL3NjaGVkX3VsZS5jOjI2MjcgKHNwaW4gbXV0ZXg6c2No ZWQgbG9jayA3KQogICAgIDIyMiAgICAgICAyMjYgICAgIDIzNDY1NDkgICAgICAgIDIxNzcgICAg ICAgMTk5NTEgICAgMTE3ICAgICAgMCAgMCAgICAgMjIgL3Vzci9zcmMvc3lzL2tlcm4va2Vybl9j bG9jay5jOjUwMyAoc3BpbiBtdXRleDpzY2hlZCBsb2NrIDcpCiAgICAgMTYwICAgICAgICAgMCAg ICAgIDE1NTgyMSAgICAgICAgICAgMCAgICAgICAgMTIwNiAgICAxMjkgICAgICAwICAwICAgICAg MCAvdXNyL3NyYy9zeXMva2Vybi9zdWJyX3RyYXAuYzoxNjcgKHNwaW4gbXV0ZXg6c2NoZWQgbG9j ayA3KQogICAgIDE3NSAgICAgICAgIDAgICAgICAxNTY1ODEgICAgICAgICAgIDAgICAgICAgIDEy MDYgICAgMTI5ICAgICAgMCAgMCAgICAgIDAgL3Vzci9zcmMvc3lzL2tlcm4vc3Vicl90cmFwLmM6 MjEzIChzcGluIG11dGV4OnNjaGVkIGxvY2sgNykKICAgICAyNjggICAgICAgICAwICAgICAgICAg MjY4ICAgICAgICAgICAwICAgICAgICAgICAxICAgIDI2OCAgICAgIDAgIDAgICAgICAwIC91c3Iv c3JjL3N5cy9rZXJuL2tlcm5fdGhyZWFkLmM6NDEwIChzcGluIG11dGV4OnNjaGVkIGxvY2sgNykK ICAgICAxMjAgICAgICAgICAwICAgICAgICAgMTIwICAgICAgICAgICAwICAgICAgICAgICAxICAg IDEyMCAgICAgIDAgIDAgICAgICAwIC91c3Ivc3JjL3N5cy9rZXJuL2tlcm5fdW10eC5jOjMzNjAg KHNwaW4gbXV0ZXg6c2NoZWQgbG9jayA3KQogICAgIDEzNiAgICAgICAgIDAgICAgICAgMjEzOTgg ICAgICAgICAgIDAgICAgICAgIDEwNDggICAgIDIwICAgICAgMCAgMCAgICAgIDAgL3Vzci9zcmMv c3lzL2tlcm4va2Vybl9pbnRyLmM6MTIzOSAoc3BpbiBtdXRleDpzY2hlZCBsb2NrIDcpCiAgICAg MzE0ICAgICAgICAgMCAgICAgIDExNTU0OSAgICAgICAgICAgMCAgICAgICAgIDc5NyAgICAxNDQg ICAgICAwICAwICAgICAgMCAvdXNyL3NyYy9zeXMva2Vybi9zY2hlZF91bGUuYzoxODM1IChzcGlu IG11dGV4OnNjaGVkIGxvY2sgNykKICAgICAyODYgICAgICAgICAwICAgICAgMTU3MjA2ICAgICAg ICAgICAwICAgICAgICAzNjg2ICAgICA0MiAgICAgIDAgIDAgICAgICAwIC91c3Ivc3JjL3N5cy9r ZXJuL3NjaGVkX3VsZS5jOjE4NzYgKHNwaW4gbXV0ZXg6c2NoZWQgbG9jayA3KQogICAgIDE1OCAg ICAgICAgIDAgICAgICAgNTY4NzUgICAgICAgICAgIDAgICAgICAgICA3OTcgICAgIDcxICAgICAg MCAgMCAgICAgIDAgL3Vzci9zcmMvc3lzL2tlcm4vc3Vicl9zbGVlcHF1ZXVlLmM6MzM1IChzcGlu IG11dGV4OnNjaGVkIGxvY2sgNykKICAgICAxNzkgICAgICAgMjUxICAgICAgIDg3MTkyICAgICAg IDY5NTQzICAgICAgICAxNzk2ICAgICA0OCAgICAgMzggIDAgICAxNjEwIC91c3Ivc3JjL3N5cy9r ZXJuL3NjaGVkX3VsZS5jOjIwNzQgKHNwaW4gbXV0ZXg6c2NoZWQgbG9jayA3KQogICAgIDE1MyAg ICAgICAgIDAgICAgICAgNTkzNDkgICAgICAgICAgIDAgICAgICAgICA0NjUgICAgMTI3ICAgICAg MCAgMCAgICAgIDAgL3Vzci9zcmMvc3lzL2tlcm4vc2NoZWRfdWxlLmM6MjExMSAoc3BpbiBtdXRl eDpzY2hlZCBsb2NrIDcpCiAgICAgMTY2ICAgICAgICAgMCAgICAgICA1Njc2NiAgICAgICAgICAg MCAgICAgICAgIDc4NCAgICAgNzIgICAgICAwICAwICAgICAgMCAvdXNyL3NyYy9zeXMva2Vybi9z dWJyX3NsZWVwcXVldWUuYzo1ODMgKHNwaW4gbXV0ZXg6c2NoZWQgbG9jayA3KQogICAgIDEzNCAg ICAgICAgIDAgICAgICAgIDEyOTkgICAgICAgICAgIDAgICAgICAgICAgMTMgICAgIDk5ICAgICAg MCAgMCAgICAgIDAgL3Vzci9zcmMvc3lzL2tlcm4vc3Vicl9zbGVlcHF1ZXVlLmM6NjE4IChzcGlu IG11dGV4OnNjaGVkIGxvY2sgNykKICAgICAyMTkgICAgICAgMjgwICAgIDE3NDk1NDgzICAgICAg ICA4MDkyICAgICAgMTUwMDEwICAgIDExNiAgICAgIDAgIDAgICAgIDY4IC91c3Ivc3JjL3N5cy9r ZXJuL2tlcm5fY2xvY2suYzoyODYgKHNwaW4gbXV0ZXg6c2NoZWQgbG9jayA3KQogICAgIDE0OCAg ICAgMjg0MzQgICAgICAgIDQ5NjMgICAgICAxNzczNzYgICAgICAgICAgOTAgICAgIDU1ICAgMTk3 MCAgMCAgICAgNzkgL3Vzci9zcmMvc3lzL2tlcm4vc2NoZWRfdWxlLmM6MjU2OSAoc3BpbiBtdXRl eDpzY2hlZCBsb2NrIDcpCiAgICAgIDkwICAgICAgICAgMCAgICAgICAgIDEyNCAgICAgICAgICAg MCAgICAgICAgICAgMiAgICAgNjIgICAgICAwICAwICAgICAgMCAvdXNyL3NyYy9zeXMva2Vybi9r ZXJuX3NpZy5jOjE0NTAgKHNsZWVwIG11dGV4OnByb2Nlc3MgbG9jaykKICAgIDEwMzMgICAgICAg ODA5ICAgICAgICAzMTQwICAgICAgICAxMTQ0ICAgICAgICAgIDIwICAgIDE1NyAgICAgNTcgIDAg ICAgICA1IC91c3Ivc3JjL3N5cy9rZXJuL3R0eV9pbnEuYzoyNTEgKHNsZWVwIG11dGV4OnR0eW10 eCkKICAgICAgIDYgICAgICAgICAwICAgICAgICAgIDEyICAgICAgICAgICAwICAgICAgICAgICAy ICAgICAgNiAgICAgIDAgIDAgICAgICAwIC91c3Ivc3JjL3N5cy9rZXJuL2tlcm5fcHJvYy5jOjUx MiAoc2xlZXAgbXV0ZXg6dHR5bXR4KQogICAgIDMyMiAgICAgICAyOTMgICAgICAyOTcyMzcgICAg ICAgIDIwNjcgICAgICAgIDEzMjQgICAgMjI0ICAgICAgMSAgMCAgICAgMTEgL3Vzci9zcmMvc3lz L2tlcm4vc2NoZWRfdWxlLmM6MTgzNSAoc3BpbiBtdXRleDpzY2hlZCBsb2NrIDgpCiAgICAgODA2 ICAgICAgICAgMCAgICAgIDUwMDA3MyAgICAgICAgICAgMCAgICAgICAgMzI3OSAgICAxNTIgICAg ICAwICAwICAgICAgMCAvdXNyL3NyYy9zeXMva2Vybi9zY2hlZF91bGUuYzoxODc2IChzcGluIG11 dGV4OnNjaGVkIGxvY2sgOCkKICAgICAxNjUgICAgICAgMjY3ICAgICAgMTM4NTAzICAgICAgICAg NzMxICAgICAgICAxMjU0ICAgIDExMCAgICAgIDAgIDAgICAgICA0IC91c3Ivc3JjL3N5cy9rZXJu L3N1YnJfc2xlZXBxdWV1ZS5jOjMzNSAoc3BpbiBtdXRleDpzY2hlZCBsb2NrIDgpCiAgICAgMTQ5 ICAgICAgICAgMCAgICAgICAgMTczMSAgICAgICAgICAgMCAgICAgICAgICAyNSAgICAgNjkgICAg ICAwICAwICAgICAgMCAvdXNyL3NyYy9zeXMva2Vybi9zdWJyX3NsZWVwcXVldWUuYzozOTMgKHNw aW4gbXV0ZXg6c2NoZWQgbG9jayA4KQogICAgIDE4OSAgICAgICAzODMgICAgICAxNDk5MjkgICAg ICAgODAxNjkgICAgICAgIDEyNDggICAgMTIwICAgICA2NCAgMCAgICA3OTEgL3Vzci9zcmMvc3lz L2tlcm4vc2NoZWRfdWxlLmM6MjA3NCAoc3BpbiBtdXRleDpzY2hlZCBsb2NrIDgpCiAgICAgMTU3 ICAgICAgODY4OSAgICAgICA0MzE5MCAgICAgICAgODY4OSAgICAgICAgIDMzNyAgICAxMjggICAg IDI1ICAwICAgICAgMSAvdXNyL3NyYy9zeXMva2Vybi9zY2hlZF91bGUuYzoyMTExIChzcGluIG11 dGV4OnNjaGVkIGxvY2sgOCkKICAgICAxNjggICAgICAgICAwICAgICAgIDQyMjY1ICAgICAgICAg ICAwICAgICAgICAgMzExICAgIDEzNSAgICAgIDAgIDAgICAgICAwIC91c3Ivc3JjL3N5cy9rZXJu L3N1YnJfc2xlZXBxdWV1ZS5jOjU4MyAoc3BpbiBtdXRleDpzY2hlZCBsb2NrIDgpCiAgICAgMTY3 ICAgICAgICAgMCAgICAgICA5NDkzMCAgICAgICAgICAgMCAgICAgICAgIDkxOCAgICAxMDMgICAg ICAwICAwICAgICAgMCAvdXNyL3NyYy9zeXMva2Vybi9zdWJyX3NsZWVwcXVldWUuYzo2MTggKHNw aW4gbXV0ZXg6c2NoZWQgbG9jayA4KQogICAgIDIzOCAgICAgICA0NTggICAgMTgyNDc3MTkgICAg ICAgNDY3MTAgICAgICAxNDc1MjQgICAgMTIzICAgICAgMCAgMCAgICAyNTIgL3Vzci9zcmMvc3lz L2tlcm4va2Vybl9jbG9jay5jOjI4NiAoc3BpbiBtdXRleDpzY2hlZCBsb2NrIDgpCiAgICAgMTAx ICAgICAzNDMwOCAgICAgICAgIDU5MCAgICAgICAzNDgxMCAgICAgICAgICAxNSAgICAgMzkgICAy MzIwICAwICAgICAxNSAvdXNyL3NyYy9zeXMva2Vybi9zY2hlZF91bGUuYzoyNTY5IChzcGluIG11 dGV4OnNjaGVkIGxvY2sgOCkKICAgICAxODcgICAgICAgOTU3ICAgICAgMTA1NzAxICAgICAgICAz MDU5ICAgICAgICAgNzAzICAgIDE1MCAgICAgIDQgIDAgICAgIDEwIC91c3Ivc3JjL3N5cy9rZXJu L2tlcm5fc3dpdGNoLmM6MTg4IChzcGluIG11dGV4OnNjaGVkIGxvY2sgOCkKICAgICAgNTEgICAg ICAgICAwICAgICAgICAgMzkwICAgICAgICAgICAwICAgICAgICAgIDEyICAgICAzMiAgICAgIDAg IDAgICAgICAwIC91c3Ivc3JjL3N5cy9rZXJuL3NjaGVkX3VsZS5jOjI2MjcgKHNwaW4gbXV0ZXg6 c2NoZWQgbG9jayA4KQogICAgIDE3OCAgICAgICAzNzkgICAgIDI0MzUwNDAgICAgICAgIDQ2MTEg ICAgICAgMTk2MjEgICAgMTI0ICAgICAgMCAgMCAgICAgMjkgL3Vzci9zcmMvc3lzL2tlcm4va2Vy bl9jbG9jay5jOjUwMyAoc3BpbiBtdXRleDpzY2hlZCBsb2NrIDgpCiAgICAgMTYwICAgICA0NDUy NiAgICAgIDE1NTczOSAgICAgICA0NDUyNiAgICAgICAgMTIyMSAgICAxMjcgICAgIDM2ICAwICAg ICAgMSAvdXNyL3NyYy9zeXMva2Vybi9zdWJyX3RyYXAuYzoxNjcgKHNwaW4gbXV0ZXg6c2NoZWQg bG9jayA4KQogICAgIDE3NSAgICAgICAgIDAgICAgICAxNjI2NjQgICAgICAgICAgIDAgICAgICAg IDEyMTYgICAgMTMzICAgICAgMCAgMCAgICAgIDAgL3Vzci9zcmMvc3lzL2tlcm4vc3Vicl90cmFw LmM6MjEzIChzcGluIG11dGV4OnNjaGVkIGxvY2sgOCkKICAgICAxNTAgICAgICAgICAwICAgICAg ICAgMTUwICAgICAgICAgICAwICAgICAgICAgICAxICAgIDE1MCAgICAgIDAgIDAgICAgICAwIC91 c3Ivc3JjL3N5cy9rZXJuL3N1YnJfc2xlZXBxdWV1ZS5jOjgzMCAoc3BpbiBtdXRleDpzY2hlZCBs b2NrIDQpCiAgICAgIDI5ICAgICAgICAgMCAgICAgICAgICAyOSAgICAgICAgICAgMCAgICAgICAg ICAgMSAgICAgMjkgICAgICAwICAwICAgICAgMCAvdXNyL3NyYy9zeXMva2Vybi9rZXJuX2Zvcmsu Yzo0MzUgKHNwaW4gbXV0ZXg6c2NoZWQgbG9jayA4KQogICAgICA0MSAgICAgICAgIDAgICAgICAg ICAgNDEgICAgICAgICAgIDAgICAgICAgICAgIDEgICAgIDQxICAgICAgMCAgMCAgICAgIDAgL3Vz ci9zcmMvc3lzL2tlcm4va2Vybl9mb3JrLmM6NzMxIChzcGluIG11dGV4OnNjaGVkIGxvY2sgOCkK ICAgICAgNjUgICAgICAgICAwICAgICAgICAgIDY1ICAgICAgICAgICAwICAgICAgICAgICAxICAg ICA2NSAgICAgIDAgIDAgICAgICAwIC91c3Ivc3JjL3N5cy9rZXJuL2tlcm5fdGhyZWFkLmM6NDEw IChzcGluIG11dGV4OnNjaGVkIGxvY2sgOCkKICAgICAgNDQgICAgICAgICAwICAgICAgICAgIDQ0 ICAgICAgICAgICAwICAgICAgICAgICAxICAgICA0NCAgICAgIDAgIDAgICAgICAwIC91c3Ivc3Jj L3N5cy9rZXJuL2tlcm5fdW10eC5jOjMzNjAgKHNwaW4gbXV0ZXg6c2NoZWQgbG9jayA4KQogICAg IDE1MSAgICAgICAxNDYgICAgICAgIDk5MjEgICAgICAgICAxNDYgICAgICAgICAgNzAgICAgMTQx ICAgICAgMiAgMCAgICAgIDEgL3Vzci9zcmMvc3lzL2tlcm4vc3Vicl90dXJuc3RpbGUuYzo3Mjcg KHNwaW4gbXV0ZXg6c2NoZWQgbG9jayA4KQogICAgIDUxOSAgICAgICAxNTggICAgICAgMzg3Mzkg ICAgICAgICAzMTMgICAgICAgICAgOTAgICAgNDMwICAgICAgMyAgMCAgICAgIDIgL3Vzci9zcmMv c3lzL2tlcm4vc3Vicl90dXJuc3RpbGUuYzo4ODkgKHNwaW4gbXV0ZXg6c2NoZWQgbG9jayA4KQog ICAgIDE4MiAgICAgICAgIDAgICAgICAgNDc1ODMgICAgICAgICAgIDAgICAgICAgICAzMjIgICAg MTQ3ICAgICAgMCAgMCAgICAgIDAgL3Vzci9zcmMvc3lzL2tlcm4va2Vybl9pbnRyLmM6MTIzOSAo c3BpbiBtdXRleDpzY2hlZCBsb2NrIDgpCiAgICAgMTQ4ICAgICAgICAgMCAgICAgICAgIDU4MyAg ICAgICAgICAgMCAgICAgICAgICAgNyAgICAgODMgICAgICAwICAwICAgICAgMCAvdXNyL3NyYy9z eXMvbmV0aW5ldC90Y3BfaW5wdXQuYzoxMzY2IChzbGVlcCBtdXRleDpzb19zbmQpCiAgICAzOTY1 ICAgICAgICAgMCAgICAgICAyMTY0MyAgICAgICAgICAgMCAgICAgICAgICAxNyAgIDEyNzMgICAg ICAwICAwICAgICAgMCAvdXNyL3NyYy9zeXMvbmV0aW5ldC90Y3BfaW5wdXQuYzoxNDY3IChzbGVl cCBtdXRleDpzb19yY3YpCiAgICAxODg2ICAgICAgICAgMCAgICAgICAgNDUxMCAgICAgICAgICAg MCAgICAgICAgICAgNyAgICA2NDQgICAgICAwICAwICAgICAgMCAvdXNyL3NyYy9zeXMva2Vybi91 aXBjX3NvY2tidWYuYzo5MDggKHNsZWVwIG11dGV4OnNvX3NuZCkKICAgICAzMjAgICAgICAgICAw ICAgICAgICAxMjUyICAgICAgICAgICAwICAgICAgICAgIDEyICAgIDEwNCAgICAgIDAgIDAgICAg ICAwIC91c3Ivc3JjL3N5cy9uZXRpbmV0L3RjcF9pbnB1dC5jOjIzNTkgKHNsZWVwIG11dGV4OnNv X3NuZCkKICAgIDIyMTkgICAgICAgICAwICAgICAgIDIyNDc3ICAgICAgICAgICAwICAgICAgICAg IDM2ICAgIDYyNCAgICAgIDAgIDAgICAgICAwIC91c3Ivc3JjL3N5cy9uZXRpbmV0L3RjcF9pbnB1 dC5jOjUwNCAocnc6dGNwKQogICAgNzAxNyAgICAgICAgIDAgICAgICAgNjY0ODEgICAgICAgICAg IDAgICAgICAgICAgMzYgICAxODQ2ICAgICAgMCAgMCAgICAgIDAgL3Vzci9zcmMvc3lzL25ldGlu ZXQvdGNwX2lucHV0LmM6NTk2IChydzp0Y3BpbnApCiAgICAyMDc5ICAgICAgICAgMCAgICAgICAg MzIzMiAgICAgICAgICAgMCAgICAgICAgICAgMiAgIDE2MTYgICAgICAwICAwICAgICAgMCAvdXNy L3NyYy9zeXMvbmV0aW5ldC9pbi5jOjExNjQgKHJ3OmxsZSkKICAgICAgOTQgICAgICAgICAwICAg ICAgICAgIDk0ICAgICAgICAgICAwICAgICAgICAgICAxICAgICA5NCAgICAgIDAgIDAgICAgICAw IC91c3Ivc3JjL3N5cy9rZXJuL2tlcm5fdW10eC5jOjMzNjAgKHNwaW4gbXV0ZXg6c2NoZWQgbG9j ayA5KQogICAgIDE0NCAgICAgICAgIDAgICAgICAgICAyMDEgICAgICAgICAgIDAgICAgICAgICAg IDIgICAgMTAwICAgICAgMCAgMCAgICAgIDAgL3Vzci9zcmMvc3lzL2tlcm4vc3Vicl90dXJuc3Rp bGUuYzo3MjcgKHNwaW4gbXV0ZXg6c2NoZWQgbG9jayA5KQogICAgIDE2NSAgICAgICAgIDAgICAg ICAgMTA1ODQgICAgICAgICAgIDAgICAgICAgICAxMzUgICAgIDc4ICAgICAgMCAgMCAgICAgIDAg L3Vzci9zcmMvc3lzL2tlcm4va2Vybl9pbnRyLmM6MTIzOSAoc3BpbiBtdXRleDpzY2hlZCBsb2Nr IDkpCiAgICAgMzE5ICAgICAgICAgMCAgICAgICAzNjk1NiAgICAgICAgICAgMCAgICAgICAgIDE5 NiAgICAxODggICAgICAwICAwICAgICAgMCAvdXNyL3NyYy9zeXMva2Vybi9zY2hlZF91bGUuYzox ODM1IChzcGluIG11dGV4OnNjaGVkIGxvY2sgOSkKICAgICA0NTIgICAgICAgICAwICAgICAgIDcz OTAyICAgICAgICAgICAwICAgICAgICAgNzIzICAgIDEwMiAgICAgIDAgIDAgICAgICAwIC91c3Iv c3JjL3N5cy9rZXJuL3NjaGVkX3VsZS5jOjE4NzYgKHNwaW4gbXV0ZXg6c2NoZWQgbG9jayA5KQog ICAgIDE1NyAgICAgICAgIDAgICAgICAgMTk0ODUgICAgICAgICAgIDAgICAgICAgICAyMTYgICAg IDkwICAgICAgMCAgMCAgICAgIDAgL3Vzci9zcmMvc3lzL2tlcm4vc3Vicl9zbGVlcHF1ZXVlLmM6 MzM1IChzcGluIG11dGV4OnNjaGVkIGxvY2sgOSkKICAgICAxNTcgICAgICAgMTk4ICAgICAgIDE3 NTM5ICAgICAgIDEzNDA0ICAgICAgICAgMjA5ICAgICA4MyAgICAgNjQgIDAgICAgMTY2IC91c3Iv c3JjL3N5cy9rZXJuL3NjaGVkX3VsZS5jOjIwNzQgKHNwaW4gbXV0ZXg6c2NoZWQgbG9jayA5KQog ICAgIDE2NiAgICAgICAgIDAgICAgICAgMzcwMDcgICAgICAgICAgIDAgICAgICAgICAyNzUgICAg MTM0ICAgICAgMCAgMCAgICAgIDAgL3Vzci9zcmMvc3lzL2tlcm4vc2NoZWRfdWxlLmM6MjExMSAo c3BpbiBtdXRleDpzY2hlZCBsb2NrIDkpCiAgICAgMzAwICAgICAgICAgMCAgICAgICAxNDk0MCAg ICAgICAgICAgMCAgICAgICAgIDE0NyAgICAxMDEgICAgICAwICAwICAgICAgMCAvdXNyL3NyYy9z eXMva2Vybi9zdWJyX3NsZWVwcXVldWUuYzo1ODMgKHNwaW4gbXV0ZXg6c2NoZWQgbG9jayA5KQog ICAgIDE1MSAgICAgICAgIDAgICAgICAgIDU3MDEgICAgICAgICAgIDAgICAgICAgICAgNjkgICAg IDgyICAgICAgMCAgMCAgICAgIDAgL3Vzci9zcmMvc3lzL2tlcm4vc3Vicl9zbGVlcHF1ZXVlLmM6 NjE4IChzcGluIG11dGV4OnNjaGVkIGxvY2sgOSkKICAgICAxNDggICAgICAgICAwICAgICAgICAx MjYzICAgICAgICAgICAwICAgICAgICAgIDIyICAgICA1NyAgICAgIDAgIDAgICAgICAwIC91c3Iv c3JjL3N5cy9rZXJuL3N1YnJfc2xlZXBxdWV1ZS5jOjc3MiAoc3BpbiBtdXRleDpzY2hlZCBsb2Nr IDkpCiAgICAgMTE0ICAgICAgICAgMCAgICAgICAgIDgxNiAgICAgICAgICAgMCAgICAgICAgICAx MSAgICAgNzQgICAgICAwICAwICAgICAgMCAvdXNyL3NyYy9zeXMva2Vybi9zdWJyX3R1cm5zdGls ZS5jOjcxNyAoc3BpbiBtdXRleDp0ZF9jb250ZXN0ZWQpCiAgICAgMjQxICAgICAgIDYxNyAgICAx ODU3MzE3NCAgICAgICAgNDU3OSAgICAgIDE0OTk5NCAgICAxMjMgICAgICAwICAwICAgICAyNiAv dXNyL3NyYy9zeXMva2Vybi9rZXJuX2Nsb2NrLmM6Mjg2IChzcGluIG11dGV4OnNjaGVkIGxvY2sg OSkKICAgICAxMzkgICAgIDExNjY4ICAgICAgICAxMzM3ICAgICAgIDE1MTU3ICAgICAgICAgIDE1 ICAgICA4OSAgIDEwMTAgIDAgICAgIDE0IC91c3Ivc3JjL3N5cy9rZXJuL3NjaGVkX3VsZS5jOjI1 NjkgKHNwaW4gbXV0ZXg6c2NoZWQgbG9jayA5KQogICAgIDE2MyAgICAgICAgIDAgICAgICAgMTYy OTcgICAgICAgICAgIDAgICAgICAgICAxMzcgICAgMTE4ICAgICAgMCAgMCAgICAgIDAgL3Vzci9z cmMvc3lzL2tlcm4va2Vybl9zd2l0Y2guYzoxODggKHNwaW4gbXV0ZXg6c2NoZWQgbG9jayA5KQog ICAgIDE3NiAgICAgICAxNjUgICAgIDI0ODgyNjAgICAgICAgICA1NDkgICAgICAgMTk5NTAgICAg MTI0ICAgICAgMCAgMCAgICAgIDQgL3Vzci9zcmMvc3lzL2tlcm4va2Vybl9jbG9jay5jOjUwMyAo c3BpbiBtdXRleDpzY2hlZCBsb2NrIDkpCiAgICAgMTYzICAgICAgICAgMCAgICAgIDE4MDIyMiAg ICAgICAgICAgMCAgICAgICAgMTM0OCAgICAxMzMgICAgICAwICAwICAgICAgMCAvdXNyL3NyYy9z eXMva2Vybi9zdWJyX3RyYXAuYzoxNjcgKHNwaW4gbXV0ZXg6c2NoZWQgbG9jayA5KQogICAgIDE3 NiAgICAgICAgIDAgICAgICAxODc3MTAgICAgICAgICAgIDAgICAgICAgIDEzNDggICAgMTM5ICAg ICAgMCAgMCAgICAgIDAgL3Vzci9zcmMvc3lzL2tlcm4vc3Vicl90cmFwLmM6MjEzIChzcGluIG11 dGV4OnNjaGVkIGxvY2sgOSkKICAgICAxNDQgICAgICAgMTQwICAgICAgICAgNjQyICAgICAgICAg MTQwICAgICAgICAgICA1ICAgIDEyOCAgICAgMjggIDAgICAgICAxIC91c3Ivc3JjL3N5cy9rZXJu L3N1YnJfc2xlZXBxdWV1ZS5jOjc3MiAoc3BpbiBtdXRleDpzY2hlZCBsb2NrIDEpCiAgICAgMTAw ICAgICAgIDEwNyAgICAgICAgIDEwMCAgICAgICAgIDEwNyAgICAgICAgICAgMSAgICAxMDAgICAg MTA3ICAwICAgICAgMSAvdXNyL3NyYy9zeXMva2Vybi9zdWJyX3NsZWVwcXVldWUuYzo3NzIgKHNw aW4gbXV0ZXg6c2NoZWQgbG9jayAyMCkKICAgICAxNjEgICAgICAgICAwICAgICAgICAgMTYxICAg ICAgICAgICAwICAgICAgICAgICAxICAgIDE2MSAgICAgIDAgIDAgICAgICAwIC91c3Ivc3JjL3N5 cy9rZXJuL2tlcm5fdGhyZWFkLmM6NDEwIChzcGluIG11dGV4OnNjaGVkIGxvY2sgOSkKICAgICAx MzggICAgICAgICAwICAgICAgICAgMTM4ICAgICAgICAgICAwICAgICAgICAgICAxICAgIDEzOCAg ICAgIDAgIDAgICAgICAwIC91c3Ivc3JjL3N5cy9rZXJuL3N1YnJfc2xlZXBxdWV1ZS5jOjc3MiAo c3BpbiBtdXRleDpzY2hlZCBsb2NrIDIpCiAgICAgIDg3ICAgICAgICAgMCAgICAgICAgIDUzMCAg ICAgICAgICAgMCAgICAgICAgICAgOCAgICAgNjYgICAgICAwICAwICAgICAgMCAvdXNyL3NyYy9z eXMva2Vybi9zdWJyX3R1cm5zdGlsZS5jOjIwMyAoc3BpbiBtdXRleDp0dXJuc3RpbGUgbG9jaykK ICAgICAxNjkgICAgICAgICAwICAgICAgICAgMTY5ICAgICAgICAgICAwICAgICAgICAgICAxICAg IDE2OSAgICAgIDAgIDAgICAgICAwIC91c3Ivc3JjL3N5cy9rZXJuL2tlcm5fdGhyZWFkLmM6NDEw IChzcGluIG11dGV4OnNjaGVkIGxvY2sgMTApCiAgICAgIDUzICAgICAgICAgMCAgICAgICAgICA1 MyAgICAgICAgICAgMCAgICAgICAgICAgMSAgICAgNTMgICAgICAwICAwICAgICAgMCAvdXNyL3Ny Yy9zeXMva2Vybi9rZXJuX3VtdHguYzozMzYwIChzcGluIG11dGV4OnNjaGVkIGxvY2sgMTApCiAg ICAgIDc4ICAgICAgICAgMCAgICAgICAgICA3OCAgICAgICAgICAgMCAgICAgICAgICAgMSAgICAg NzggICAgICAwICAwICAgICAgMCAvdXNyL3NyYy9zeXMva2Vybi9zdWJyX3R1cm5zdGlsZS5jOjcy NyAoc3BpbiBtdXRleDpzY2hlZCBsb2NrIDEwKQogICAgIDExNyAgICAgICAgIDAgICAgICAgICA1 ODQgICAgICAgICAgIDAgICAgICAgICAgIDYgICAgIDk3ICAgICAgMCAgMCAgICAgIDAgL3Vzci9z cmMvc3lzL2tlcm4vc2NoZWRfdWxlLmM6MTgzNSAoc3BpbiBtdXRleDpzY2hlZCBsb2NrIDEwKQog ICAgIDEwOSAgICAgICAgIDAgICAgICAgICA3NTkgICAgICAgICAgIDAgICAgICAgICAgMTQgICAg IDU0ICAgICAgMCAgMCAgICAgIDAgL3Vzci9zcmMvc3lzL2tlcm4vc2NoZWRfdWxlLmM6MTg3NiAo c3BpbiBtdXRleDpzY2hlZCBsb2NrIDEwKQogICAgICA1NyAgICAgICAgIDAgICAgICAgICAyNDMg ICAgICAgICAgIDAgICAgICAgICAgIDUgICAgIDQ4ICAgICAgMCAgMCAgICAgIDAgL3Vzci9zcmMv c3lzL2tlcm4vc3Vicl9zbGVlcHF1ZXVlLmM6MzM1IChzcGluIG11dGV4OnNjaGVkIGxvY2sgMTAp CiAgICAgMTQ4ICAgICAgIDE4OSAgICAgICAgMzQzMiAgICAgICAgMjUxOSAgICAgICAgICAyOSAg ICAxMTggICAgIDg2ICAwICAgICAyMCAvdXNyL3NyYy9zeXMva2Vybi9zY2hlZF91bGUuYzoyMDc0 IChzcGluIG11dGV4OnNjaGVkIGxvY2sgMTApCiAgICAgMTU5ICAgICAgICAgMCAgICAgICA0NDc1 NyAgICAgICAgICAgMCAgICAgICAgIDM0MCAgICAxMzEgICAgICAwICAwICAgICAgMCAvdXNyL3Ny Yy9zeXMva2Vybi9zY2hlZF91bGUuYzoyMTExIChzcGluIG11dGV4OnNjaGVkIGxvY2sgMTApCiAg ICAgIDU3ICAgICAgICAgMCAgICAgICAgIDI1MSAgICAgICAgICAgMCAgICAgICAgICAgNSAgICAg NTAgICAgICAwICAwICAgICAgMCAvdXNyL3NyYy9zeXMva2Vybi9zdWJyX3NsZWVwcXVldWUuYzo1 ODMgKHNwaW4gbXV0ZXg6c2NoZWQgbG9jayAxMCkKICAgICAyNTAgICAgICAgMjU5ICAgIDE4NjY2 MTcxICAgICAgICAgNDc2ICAgICAgMTUwNDkyICAgIDEyNCAgICAgIDAgIDAgICAgICAyIC91c3Iv c3JjL3N5cy9rZXJuL2tlcm5fY2xvY2suYzoyODYgKHNwaW4gbXV0ZXg6c2NoZWQgbG9jayAxMCkK ICAgICAyMzkgICAgICAgICAwICAgICAyNDg3ODI0ICAgICAgICAgICAwICAgICAgIDIwMDE2ICAg IDEyNCAgICAgIDAgIDAgICAgICAwIC91c3Ivc3JjL3N5cy9rZXJuL2tlcm5fY2xvY2suYzo1MDMg KHNwaW4gbXV0ZXg6c2NoZWQgbG9jayAxMCkKICAgICAxNzAgICAgICAgICAwICAgICAgMTgxMDI5 ICAgICAgICAgICAwICAgICAgICAxMzQ1ICAgIDEzNCAgICAgIDAgIDAgICAgICAwIC91c3Ivc3Jj L3N5cy9rZXJuL3N1YnJfdHJhcC5jOjE2NyAoc3BpbiBtdXRleDpzY2hlZCBsb2NrIDEwKQogICAg IDE4OCAgICAgICAgIDAgICAgICAxODk0NDkgICAgICAgICAgIDAgICAgICAgIDEzNDUgICAgMTQw ICAgICAgMCAgMCAgICAgIDAgL3Vzci9zcmMvc3lzL2tlcm4vc3Vicl90cmFwLmM6MjEzIChzcGlu IG11dGV4OnNjaGVkIGxvY2sgMTApCiAgICAgMjEzICAgICAgICAgMCAgICAgICAgIDIxMyAgICAg ICAgICAgMCAgICAgICAgICAgMSAgICAyMTMgICAgICAwICAwICAgICAgMCAvdXNyL3NyYy9zeXMv a2Vybi9rZXJuX3RocmVhZC5jOjQxMCAoc3BpbiBtdXRleDpzY2hlZCBsb2NrIDExKQogICAgICA5 OCAgICAgICAgIDAgICAgICAgICAgOTggICAgICAgICAgIDAgICAgICAgICAgIDEgICAgIDk4ICAg ICAgMCAgMCAgICAgIDAgL3Vzci9zcmMvc3lzL2tlcm4va2Vybl91bXR4LmM6MzM2MCAoc3BpbiBt dXRleDpzY2hlZCBsb2NrIDExKQogICAgIDEyNCAgICAgICAgIDAgICAgICAgICAxNzcgICAgICAg ICAgIDAgICAgICAgICAgIDIgICAgIDg4ICAgICAgMCAgMCAgICAgIDAgL3Vzci9zcmMvc3lzL2tl cm4vc2NoZWRfdWxlLmM6MTg3NiAoc3BpbiBtdXRleDpzY2hlZCBsb2NrIDExKQogICAgIDE1NCAg ICAgICAxNzkgICAgICAgIDMxMTcgICAgICAgIDI1MjUgICAgICAgICAgMjMgICAgMTM1ICAgIDEw OSAgMCAgICAgMTcgL3Vzci9zcmMvc3lzL2tlcm4vc2NoZWRfdWxlLmM6MjA3NCAoc3BpbiBtdXRl eDpzY2hlZCBsb2NrIDExKQogICAgIDE1NyAgICAgICAgIDAgICAgICAgMjQxNjUgICAgICAgICAg IDAgICAgICAgICAxODYgICAgMTI5ICAgICAgMCAgMCAgICAgIDAgL3Vzci9zcmMvc3lzL2tlcm4v c2NoZWRfdWxlLmM6MjExMSAoc3BpbiBtdXRleDpzY2hlZCBsb2NrIDExKQogICAgIDI0NyAgICAg ICAyNDYgICAgMTg3NDU1NzYgICAgICAgICA0ODYgICAgICAxNTA0OTEgICAgMTI0ICAgICAgMCAg MCAgICAgIDIgL3Vzci9zcmMvc3lzL2tlcm4va2Vybl9jbG9jay5jOjI4NiAoc3BpbiBtdXRleDpz Y2hlZCBsb2NrIDExKQogICAgIDE5MSAgICAgICAgIDAgICAgIDI1MDIwNzUgICAgICAgICAgIDAg ICAgICAgMjAwMTYgICAgMTI1ICAgICAgMCAgMCAgICAgIDAgL3Vzci9zcmMvc3lzL2tlcm4va2Vy bl9jbG9jay5jOjUwMyAoc3BpbiBtdXRleDpzY2hlZCBsb2NrIDExKQogICAgIDE2MCAgICAgICAg IDAgICAgICAxODA3MzIgICAgICAgICAgIDAgICAgICAgIDEzNDYgICAgMTM0ICAgICAgMCAgMCAg ICAgIDAgL3Vzci9zcmMvc3lzL2tlcm4vc3Vicl90cmFwLmM6MTY3IChzcGluIG11dGV4OnNjaGVk IGxvY2sgMTEpCiAgICAgMTgxICAgICAgICAgMCAgICAgIDE5MDUyMiAgICAgICAgICAgMCAgICAg ICAgMTM0NiAgICAxNDEgICAgICAwICAwICAgICAgMCAvdXNyL3NyYy9zeXMva2Vybi9zdWJyX3Ry YXAuYzoyMTMgKHNwaW4gbXV0ZXg6c2NoZWQgbG9jayAxMSkKICAgICAxOTcgICAgICAgNTIwICAg IDE3NzU3Nzc4ICAgICAgIDMzNjg1ICAgICAgMTQ4MzY5ICAgIDExOSAgICAgIDAgIDAgICAgMjA1 IC91c3Ivc3JjL3N5cy9rZXJuL2tlcm5fY2xvY2suYzoyODYgKHNwaW4gbXV0ZXg6c2NoZWQgbG9j ayAxMikKICAgICAxNTEgICAgIDM0MzYyICAgICAgICA3MTI0ICAgICAgMTQ4OTUzICAgICAgICAg MTAxICAgICA3MCAgIDE0NzQgIDAgICAgIDgxIC91c3Ivc3JjL3N5cy9rZXJuL3NjaGVkX3VsZS5j OjI1NjkgKHNwaW4gbXV0ZXg6c2NoZWQgbG9jayAxMikKICAgICAxNjQgICAgICAgNzg0ICAgICAg IDc3MDEwICAgICAgICAxMTg3ICAgICAgICAgNTgxICAgIDEzMiAgICAgIDIgIDAgICAgICA0IC91 c3Ivc3JjL3N5cy9rZXJuL2tlcm5fc3dpdGNoLmM6MTg4IChzcGluIG11dGV4OnNjaGVkIGxvY2sg MTIpCiAgICAgIDkxICAgICAgICAgMCAgICAgICAgIDI2MiAgICAgICAgICAgMCAgICAgICAgICAg NCAgICAgNjUgICAgICAwICAwICAgICAgMCAvdXNyL3NyYy9zeXMva2Vybi9zY2hlZF91bGUuYzoy NjI3IChzcGluIG11dGV4OnNjaGVkIGxvY2sgMTIpCiAgICAgMTgyICAgICAgIDY0OCAgICAgMjM2 NDQ5MCAgICAgICAgNjcwMyAgICAgICAxOTczMyAgICAxMTkgICAgICAwICAwICAgICA0MyAvdXNy L3NyYy9zeXMva2Vybi9rZXJuX2Nsb2NrLmM6NTAzIChzcGluIG11dGV4OnNjaGVkIGxvY2sgMTIp CiAgICAgMTU4ICAgICAgICAgMCAgICAgIDE1NTAzOCAgICAgICAgICAgMCAgICAgICAgMTIwNiAg ICAxMjggICAgICAwICAwICAgICAgMCAvdXNyL3NyYy9zeXMva2Vybi9zdWJyX3RyYXAuYzoxNjcg KHNwaW4gbXV0ZXg6c2NoZWQgbG9jayAxMikKICAgICAxODUgICAgICAgICAwICAgICAgMTU2Mzky ICAgICAgICAgICAwICAgICAgICAxMjA0ICAgIDEyOSAgICAgIDAgIDAgICAgICAwIC91c3Ivc3Jj L3N5cy9rZXJuL3N1YnJfdHJhcC5jOjIxMyAoc3BpbiBtdXRleDpzY2hlZCBsb2NrIDEyKQogICAg ICAxMiAgICAgICAgIDAgICAgICAgICAgMTIgICAgICAgICAgIDAgICAgICAgICAgIDEgICAgIDEy ICAgICAgMCAgMCAgICAgIDAgL3Vzci9zcmMvc3lzL2tlcm4va2Vybl9mb3JrLmM6NDM1IChzcGlu IG11dGV4OnNjaGVkIGxvY2sgMTIpCiAgICAgIDQwICAgICAgICAgMCAgICAgICAgICA0MCAgICAg ICAgICAgMCAgICAgICAgICAgMSAgICAgNDAgICAgICAwICAwICAgICAgMCAvdXNyL3NyYy9zeXMv a2Vybi9rZXJuX2ZvcmsuYzo3MzEgKHNwaW4gbXV0ZXg6c2NoZWQgbG9jayAxMikKICAgICAyMTQg ICAgICAgICAwICAgICAgICAgMjE0ICAgICAgICAgICAwICAgICAgICAgICAxICAgIDIxNCAgICAg IDAgIDAgICAgICAwIC91c3Ivc3JjL3N5cy9rZXJuL2tlcm5fdGhyZWFkLmM6NDEwIChzcGluIG11 dGV4OnNjaGVkIGxvY2sgMTIpCiAgICAgMTU3ICAgICAgIDEzNiAgICAgICAxMDU5MiAgICAgICAg IDI2OSAgICAgICAgICA3OSAgICAxMzQgICAgICAzICAwICAgICAgMiAvdXNyL3NyYy9zeXMva2Vy bi9zdWJyX3R1cm5zdGlsZS5jOjIwMyAoc3BpbiBtdXRleDpzY2hlZCBsb2NrIDEyKQogICAgIDEy OSAgICAgICAgIDAgICAgICAgICAxMjkgICAgICAgICAgIDAgICAgICAgICAgIDEgICAgMTI5ICAg ICAgMCAgMCAgICAgIDAgL3Vzci9zcmMvc3lzL2tlcm4va2Vybl91bXR4LmM6MzM2MCAoc3BpbiBt dXRleDpzY2hlZCBsb2NrIDEyKQogICAgIDEzNyAgICAgICAxNTcgICAgICAgMTA4MTggICAgICAg ICA0MjYgICAgICAgICAgODMgICAgMTMwICAgICAgNSAgMCAgICAgIDMgL3Vzci9zcmMvc3lzL2tl cm4vc3Vicl90dXJuc3RpbGUuYzo3MjcgKHNwaW4gbXV0ZXg6c2NoZWQgbG9jayAxMikKICAgICA1 MzUgICAgICAgICAwICAgICAgIDMzMzY1ICAgICAgICAgICAwICAgICAgICAgIDg0ICAgIDM5NyAg ICAgIDAgIDAgICAgICAwIC91c3Ivc3JjL3N5cy9rZXJuL3N1YnJfdHVybnN0aWxlLmM6ODg5IChz cGluIG11dGV4OnNjaGVkIGxvY2sgMTIpCiAgICAgMTM4ICAgICAgIDE1NSAgICAgICAzNzk3OSAg ICAgICAgIDE1NSAgICAgICAgIDI5MyAgICAxMjkgICAgICAwICAwICAgICAgMSAvdXNyL3NyYy9z eXMva2Vybi9rZXJuX2ludHIuYzoxMjM5IChzcGluIG11dGV4OnNjaGVkIGxvY2sgMTIpCiAgICAg MzAwICAgICAgIDI2MSAgICAgIDMyMTU4OCAgICAgICAgMTM0NCAgICAgICAgMjA1NSAgICAxNTYg ICAgICAwICAwICAgICAgOCAvdXNyL3NyYy9zeXMva2Vybi9zY2hlZF91bGUuYzoxODM1IChzcGlu IG11dGV4OnNjaGVkIGxvY2sgMTIpCiAgICAgNzIwICAgICAgICAgMCAgICAgIDUzNjkxNCAgICAg ICAgICAgMCAgICAgICAgNDYyOCAgICAxMTYgICAgICAwICAwICAgICAgMCAvdXNyL3NyYy9zeXMv a2Vybi9zY2hlZF91bGUuYzoxODc2IChzcGluIG11dGV4OnNjaGVkIGxvY2sgMTIpCiAgICAgMTY4 ICAgICAgIDE2NCAgICAgIDE1MDE0OSAgICAgICAgIDQxMSAgICAgICAgMTk3MiAgICAgNzYgICAg ICAwICAwICAgICAgMyAvdXNyL3NyYy9zeXMva2Vybi9zdWJyX3NsZWVwcXVldWUuYzozMzUgKHNw aW4gbXV0ZXg6c2NoZWQgbG9jayAxMikKICAgICAxMzMgICAgICAgICAwICAgICAgICAxMDg3ICAg ICAgICAgICAwICAgICAgICAgIDIwICAgICA1NCAgICAgIDAgIDAgICAgICAwIC91c3Ivc3JjL3N5 cy9rZXJuL3N1YnJfc2xlZXBxdWV1ZS5jOjM5MyAoc3BpbiBtdXRleDpzY2hlZCBsb2NrIDEyKQog ICAgIDE3MiAgICAgICAzNjcgICAgICAxNTk2MjUgICAgICAxMTEzNTMgICAgICAgIDE5MjcgICAg IDgyICAgICA1NyAgMCAgIDE1MDkgL3Vzci9zcmMvc3lzL2tlcm4vc2NoZWRfdWxlLmM6MjA3NCAo c3BpbiBtdXRleDpzY2hlZCBsb2NrIDEyKQogICAgIDE2OSAgICAgICAxMDAgICAgICAgNTU1MjYg ICAgICAgICAxMDAgICAgICAgICA0MzEgICAgMTI4ICAgICAgMCAgMCAgICAgIDEgL3Vzci9zcmMv c3lzL2tlcm4vc2NoZWRfdWxlLmM6MjExMSAoc3BpbiBtdXRleDpzY2hlZCBsb2NrIDEyKQogICAg IDE1NSAgICAgICAgIDAgICAgICAgNDU2NzMgICAgICAgICAgIDAgICAgICAgICAzNjIgICAgMTI2 ICAgICAgMCAgMCAgICAgIDAgL3Vzci9zcmMvc3lzL2tlcm4vc3Vicl9zbGVlcHF1ZXVlLmM6NTgz IChzcGluIG11dGV4OnNjaGVkIGxvY2sgMTIpCiAgICAgMTQ3ICAgICAgICAgMCAgICAgIDEwMjYz MyAgICAgICAgICAgMCAgICAgICAgMTU5MCAgICAgNjQgICAgICAwICAwICAgICAgMCAvdXNyL3Ny Yy9zeXMva2Vybi9zdWJyX3NsZWVwcXVldWUuYzo2MTggKHNwaW4gbXV0ZXg6c2NoZWQgbG9jayAx MikKICAgICAxNzIgICAgICAgICAwICAgICAgIDE1MDQwICAgICAgICAgICAwICAgICAgICAgMTI0 ICAgIDEyMSAgICAgIDAgIDAgICAgICAwIC91c3Ivc3JjL3N5cy9rZXJuL2tlcm5faW50ci5jOjEy MzkgKHNwaW4gbXV0ZXg6c2NoZWQgbG9jayAxMykKICAgICAyOTggICAgICAgICAwICAgICAgIDI0 MzI5ICAgICAgICAgICAwICAgICAgICAgMTAzICAgIDIzNiAgICAgIDAgIDAgICAgICAwIC91c3Iv c3JjL3N5cy9rZXJuL3NjaGVkX3VsZS5jOjE4MzUgKHNwaW4gbXV0ZXg6c2NoZWQgbG9jayAxMykK ICAgICA1MTggICAgICAgICAwICAgICAgIDcwMzIwICAgICAgICAgICAwICAgICAgICAgNDUxICAg IDE1NSAgICAgIDAgIDAgICAgICAwIC91c3Ivc3JjL3N5cy9rZXJuL3NjaGVkX3VsZS5jOjE4NzYg KHNwaW4gbXV0ZXg6c2NoZWQgbG9jayAxMykKICAgICAxNjUgICAgICAgICAwICAgICAgIDEyMTU4 ICAgICAgICAgICAwICAgICAgICAgMTAyICAgIDExOSAgICAgIDAgIDAgICAgICAwIC91c3Ivc3Jj L3N5cy9rZXJuL3N1YnJfc2xlZXBxdWV1ZS5jOjMzNSAoc3BpbiBtdXRleDpzY2hlZCBsb2NrIDEz KQogICAgIDE2NiAgICAgICAzNDYgICAgICAgMjgwNzYgICAgICAgMTY3OTUgICAgICAgICAyMzAg ICAgMTIyICAgICA3MyAgMCAgICAxMzMgL3Vzci9zcmMvc3lzL2tlcm4vc2NoZWRfdWxlLmM6MjA3 NCAoc3BpbiBtdXRleDpzY2hlZCBsb2NrIDEzKQogICAgIDE2MCAgICAgICAgIDAgICAgICAgNDgw NzggICAgICAgICAgIDAgICAgICAgICAzNzMgICAgMTI4ICAgICAgMCAgMCAgICAgIDAgL3Vzci9z cmMvc3lzL2tlcm4vc2NoZWRfdWxlLmM6MjExMSAoc3BpbiBtdXRleDpzY2hlZCBsb2NrIDEzKQog ICAgIDE1MSAgICAgICAgIDAgICAgICAgIDIzMDcgICAgICAgICAgIDAgICAgICAgICAgMjAgICAg MTE1ICAgICAgMCAgMCAgICAgIDAgL3Vzci9zcmMvc3lzL2tlcm4vc3Vicl9zbGVlcHF1ZXVlLmM6 NTgzIChzcGluIG11dGV4OnNjaGVkIGxvY2sgMTMpCiAgICAgMTQ1ICAgICAgICAgMCAgICAgICAg OTY1NSAgICAgICAgICAgMCAgICAgICAgICA4MiAgICAxMTcgICAgICAwICAwICAgICAgMCAvdXNy L3NyYy9zeXMva2Vybi9zdWJyX3NsZWVwcXVldWUuYzo2MTggKHNwaW4gbXV0ZXg6c2NoZWQgbG9j ayAxMykKICAgICAxOTcgICAgICAgMzcyICAgIDE3OTM5MjY5ICAgICAgICA2MDU5ICAgICAgMTUw Mjk4ICAgIDExOSAgICAgIDAgIDAgICAgIDM5IC91c3Ivc3JjL3N5cy9rZXJuL2tlcm5fY2xvY2su YzoyODYgKHNwaW4gbXV0ZXg6c2NoZWQgbG9jayAxMykKICAgICAxMjMgICAgIDE1NDQ3ICAgICAg ICAxMDQzICAgICAgIDE2MzQzICAgICAgICAgICA5ICAgIDExNSAgIDE4MTUgIDAgICAgICA4IC91 c3Ivc3JjL3N5cy9rZXJuL3NjaGVkX3VsZS5jOjI1NjkgKHNwaW4gbXV0ZXg6c2NoZWQgbG9jayAx MykKICAgICAxOTUgICAgICAgMjEwICAgICAyMzkzOTIzICAgICAgICAxNTU4ICAgICAgIDE5OTg5 ICAgIDExOSAgICAgIDAgIDAgICAgIDExIC91c3Ivc3JjL3N5cy9rZXJuL2tlcm5fY2xvY2suYzo1 MDMgKHNwaW4gbXV0ZXg6c2NoZWQgbG9jayAxMykKICAgICAxNTcgICAgICAgICAwICAgICAgMTU5 MDgxICAgICAgICAgICAwICAgICAgICAxMjIzICAgIDEzMCAgICAgIDAgIDAgICAgICAwIC91c3Iv c3JjL3N5cy9rZXJuL3N1YnJfdHJhcC5jOjE2NyAoc3BpbiBtdXRleDpzY2hlZCBsb2NrIDEzKQog ICAgIDE4MyAgICAgICAgIDAgICAgICAxNjAyNDggICAgICAgICAgIDAgICAgICAgIDEyMjMgICAg MTMxICAgICAgMCAgMCAgICAgIDAgL3Vzci9zcmMvc3lzL2tlcm4vc3Vicl90cmFwLmM6MjEzIChz cGluIG11dGV4OnNjaGVkIGxvY2sgMTMpCiAgICAgMjY1ICAgICAgICAgMCAgICAgICAgIDI2NSAg ICAgICAgICAgMCAgICAgICAgICAgMSAgICAyNjUgICAgICAwICAwICAgICAgMCAvdXNyL3NyYy9z eXMva2Vybi9rZXJuX3RocmVhZC5jOjQxMCAoc3BpbiBtdXRleDpzY2hlZCBsb2NrIDEzKQogICAg IDEzMyAgICAgICAgIDAgICAgICAgICAxMzMgICAgICAgICAgIDAgICAgICAgICAgIDEgICAgMTMz ICAgICAgMCAgMCAgICAgIDAgL3Vzci9zcmMvc3lzL2tlcm4va2Vybl91bXR4LmM6MzM2MCAoc3Bp biBtdXRleDpzY2hlZCBsb2NrIDEzKQogICAgICA2NSAgICAgICAgIDAgICAgICAgICAgNjUgICAg ICAgICAgIDAgICAgICAgICAgIDEgICAgIDY1ICAgICAgMCAgMCAgICAgIDAgL3Vzci9zcmMvc3lz L2tlcm4vc3Vicl90dXJuc3RpbGUuYzo3MjcgKHNwaW4gbXV0ZXg6c2NoZWQgbG9jayAxMykKICAg ICAyMDggICAgICAgMTE3ICAgICAgICAgNTQyICAgICAgICAgMTE3ICAgICAgICAgICAzICAgIDE4 MCAgICAgMzkgIDAgICAgICAxIC91c3Ivc3JjL3N5cy9rZXJuL2tlcm5fc2lnLmM6MjI1MSAoc3Bp biBtdXRleDpzY2hlZCBsb2NrIDcpCiAgICAgMTI5ICAgICAgICAgMCAgICAgICAgIDEyOSAgICAg ICAgICAgMCAgICAgICAgICAgMSAgICAxMjkgICAgICAwICAwICAgICAgMCAvdXNyL3NyYy9zeXMv a2Vybi9rZXJuX3VtdHguYzozMzYwIChzcGluIG11dGV4OnNjaGVkIGxvY2sgMTQpCiAgICAgIDc5 ICAgICAgICAgMCAgICAgICAgIDE1MiAgICAgICAgICAgMCAgICAgICAgICAgMiAgICAgNzYgICAg ICAwICAwICAgICAgMCAvdXNyL3NyYy9zeXMva2Vybi9zdWJyX3R1cm5zdGlsZS5jOjcyNyAoc3Bp biBtdXRleDpzY2hlZCBsb2NrIDE0KQogICAgIDE4OSAgICAgICAxMjcgICAgICAxNTg0MDIgICAg ICAgICAxMjcgICAgICAgIDIwMTYgICAgIDc4ICAgICAgMCAgMCAgICAgIDEgL3Vzci9zcmMvc3lz L2tlcm4va2Vybl9pbnRyLmM6MTIzOSAoc3BpbiBtdXRleDpzY2hlZCBsb2NrIDE0KQogICAgIDI5 MyAgICAgICAgIDAgICAgICAgMTk4NTMgICAgICAgICAgIDAgICAgICAgICAgODcgICAgMjI4ICAg ICAgMCAgMCAgICAgIDAgL3Vzci9zcmMvc3lzL2tlcm4vc2NoZWRfdWxlLmM6MTgzNSAoc3BpbiBt dXRleDpzY2hlZCBsb2NrIDE0KQogICAgIDU5NCAgICAgICAgIDAgICAgICAzMjc5NDUgICAgICAg ICAgIDAgICAgICAgIDQxOTAgICAgIDc4ICAgICAgMCAgMCAgICAgIDAgL3Vzci9zcmMvc3lzL2tl cm4vc2NoZWRfdWxlLmM6MTg3NiAoc3BpbiBtdXRleDpzY2hlZCBsb2NrIDE0KQogICAgIDE3MSAg ICAgICAgIDAgICAgICAgMTAzNTAgICAgICAgICAgIDAgICAgICAgICAgODUgICAgMTIxICAgICAg MCAgMCAgICAgIDAgL3Vzci9zcmMvc3lzL2tlcm4vc3Vicl9zbGVlcHF1ZXVlLmM6MzM1IChzcGlu IG11dGV4OnNjaGVkIGxvY2sgMTQpCiAgICAgMTg1ICAgICAgIDI2MiAgICAgIDE1Nzk0NCAgICAg IDExMDMyNSAgICAgICAgMTk4MyAgICAgNzkgICAgIDU1ICAwICAgMTYzMSAvdXNyL3NyYy9zeXMv a2Vybi9zY2hlZF91bGUuYzoyMDc0IChzcGluIG11dGV4OnNjaGVkIGxvY2sgMTQpCiAgICAgMTU0 ICAgICAgICAgMCAgICAgICA2NTgxNiAgICAgICAgICAgMCAgICAgICAgIDUwNyAgICAxMjkgICAg ICAwICAwICAgICAgMCAvdXNyL3NyYy9zeXMva2Vybi9zY2hlZF91bGUuYzoyMTExIChzcGluIG11 dGV4OnNjaGVkIGxvY2sgMTQpCiAgICAgMTEyICAgICAgICAgMCAgICAgICAgMTE3MiAgICAgICAg ICAgMCAgICAgICAgICAxMyAgICAgOTAgICAgICAwICAwICAgICAgMCAvdXNyL3NyYy9zeXMva2Vy bi9zdWJyX3NsZWVwcXVldWUuYzo1ODMgKHNwaW4gbXV0ZXg6c2NoZWQgbG9jayAxNCkKICAgICAx NjIgICAgICAgICAwICAgICAgICA4NzE0ICAgICAgICAgICAwICAgICAgICAgIDcyICAgIDEyMSAg ICAgIDAgIDAgICAgICAwIC91c3Ivc3JjL3N5cy9rZXJuL3N1YnJfc2xlZXBxdWV1ZS5jOjYxOCAo c3BpbiBtdXRleDpzY2hlZCBsb2NrIDE0KQogICAgIDIxNiAgICAgICAzMzEgICAgMTc3OTgxMDIg ICAgICAgMzE2MDAgICAgICAxNDgxNTkgICAgMTIwICAgICAgMCAgMCAgICAyNTggL3Vzci9zcmMv c3lzL2tlcm4va2Vybl9jbG9jay5jOjI4NiAoc3BpbiBtdXRleDpzY2hlZCBsb2NrIDE0KQogICAg IDE5MyAgICAgMjM1MDIgICAgICAgMTQ5OTYgICAgICAxNTQyOTcgICAgICAgICAxNDcgICAgMTAy ICAgMTA0OSAgMCAgICAxMDkgL3Vzci9zcmMvc3lzL2tlcm4vc2NoZWRfdWxlLmM6MjU2OSAoc3Bp biBtdXRleDpzY2hlZCBsb2NrIDE0KQogICAgIDEwMCAgICAgICAgIDAgICAgICAgICAxMDAgICAg ICAgICAgIDAgICAgICAgICAgIDEgICAgMTAwICAgICAgMCAgMCAgICAgIDAgL3Vzci9zcmMvc3lz L2tlcm4va2Vybl9zd2l0Y2guYzoxODggKHNwaW4gbXV0ZXg6c2NoZWQgbG9jayAxNCkKICAgICAx ODIgICAgICAgMjE2ICAgICAyMzYyNTMwICAgICAgIDE1Njc0ICAgICAgIDE5NzA1ICAgIDExOSAg ICAgIDAgIDAgICAgMTI5IC91c3Ivc3JjL3N5cy9rZXJuL2tlcm5fY2xvY2suYzo1MDMgKHNwaW4g bXV0ZXg6c2NoZWQgbG9jayAxNCkKICAgICAxNjkgICAgICAgICAwICAgICAgMTU5NzQ2ICAgICAg ICAgICAwICAgICAgICAxMjI3ICAgIDEzMCAgICAgIDAgIDAgICAgICAwIC91c3Ivc3JjL3N5cy9r ZXJuL3N1YnJfdHJhcC5jOjE2NyAoc3BpbiBtdXRleDpzY2hlZCBsb2NrIDE0KQogICAgIDE3MyAg ICAgICAgIDAgICAgICAxNjE0MTYgICAgICAgICAgIDAgICAgICAgIDEyMjcgICAgMTMxICAgICAg MCAgMCAgICAgIDAgL3Vzci9zcmMvc3lzL2tlcm4vc3Vicl90cmFwLmM6MjEzIChzcGluIG11dGV4 OnNjaGVkIGxvY2sgMTQpCiAgICAgMTQyICAgICAgIDU3NCAgICAgICAgIDMyNiAgICAgICAgIDU3 NCAgICAgICAgICAgMyAgICAxMDggICAgMTkxICAwICAgICAgMSAvdXNyL3NyYy9zeXMva2Vybi9r ZXJuX3NpZy5jOjU5MyAoc3BpbiBtdXRleDpzY2hlZCBsb2NrIDcpCiAgICAgMjE5ICAgICAgICAg MCAgICAgICAgIDIxOSAgICAgICAgICAgMCAgICAgICAgICAgMSAgICAyMTkgICAgICAwICAwICAg ICAgMCAvdXNyL3NyYy9zeXMva2Vybi9rZXJuX3RocmVhZC5jOjQxMCAoc3BpbiBtdXRleDpzY2hl ZCBsb2NrIDE0KQogICAgIDU5OSAgICAgICAgIDAgICAgICAgIDExMDIgICAgICAgICAgIDAgICAg ICAgICAgIDUgICAgMjIwICAgICAgMCAgMCAgICAgIDAgL3Vzci9zcmMvc3lzL3ZtL3VtYV9jb3Jl LmM6MjM1NSAoc2xlZXAgbXV0ZXg6Z19iaW8pCiAgICAgMjU3ICAgICAgICAgMCAgICAgICAgIDI1 NyAgICAgICAgICAgMCAgICAgICAgICAgMSAgICAyNTcgICAgICAwICAwICAgICAgMCAvdXNyL3Ny Yy9zeXMva2Vybi9rZXJuX3RocmVhZC5jOjQxMCAoc3BpbiBtdXRleDpzY2hlZCBsb2NrIDE1KQog ICAgICA5NCAgICAgICAgIDAgICAgICAgICAgOTQgICAgICAgICAgIDAgICAgICAgICAgIDEgICAg IDk0ICAgICAgMCAgMCAgICAgIDAgL3Vzci9zcmMvc3lzL2tlcm4va2Vybl91bXR4LmM6MzM2MCAo c3BpbiBtdXRleDpzY2hlZCBsb2NrIDE1KQogICAgIDEzNyAgICAgICAgIDAgICAgICAgIDQ2NzAg ICAgICAgICAgIDAgICAgICAgICAgMzYgICAgMTI5ICAgICAgMCAgMCAgICAgIDAgL3Vzci9zcmMv c3lzL2tlcm4vc3Vicl90dXJuc3RpbGUuYzo3MjcgKHNwaW4gbXV0ZXg6c2NoZWQgbG9jayAxNSkK ICAgICAxNzYgICAgICAgMjYyICAgICAgICAgNTMxICAgICAgICAgMzkzICAgICAgICAgICA0ICAg IDEzMiAgICAgOTggIDAgICAgICAyIC91c3Ivc3JjL3N5cy9rZXJuL2tlcm5faW50ci5jOjgwMCAo c3BpbiBtdXRleDpzY2hlZCBsb2NrIDI5KQogICAgIDE3MyAgICAgICAxNzQgICAgICAyODA2NjQg ICAgICAgICAyOTYgICAgICAgIDMyODkgICAgIDg1ICAgICAgMCAgMCAgICAgIDIgL3Vzci9zcmMv c3lzL2tlcm4va2Vybl9pbnRyLmM6MTIzOSAoc3BpbiBtdXRleDpzY2hlZCBsb2NrIDE1KQogICAg IDI3NSAgICAgICAgIDAgICAgICAgMTEzOTcgICAgICAgICAgIDAgICAgICAgICAgNDcgICAgMjQy ICAgICAgMCAgMCAgICAgIDAgL3Vzci9zcmMvc3lzL2tlcm4vc2NoZWRfdWxlLmM6MTgzNSAoc3Bp biBtdXRleDpzY2hlZCBsb2NrIDE1KQogICAgIDMyNiAgICAgICAgIDAgICAgICA1NTQ1OTUgICAg ICAgICAgIDAgICAgICAgIDY2NzAgICAgIDgzICAgICAgMCAgMCAgICAgIDAgL3Vzci9zcmMvc3lz L2tlcm4vc2NoZWRfdWxlLmM6MTg3NiAoc3BpbiBtdXRleDpzY2hlZCBsb2NrIDE1KQogICAgIDEx OCAgICAgICAgIDAgICAgICAgICA5OTAgICAgICAgICAgIDAgICAgICAgICAgMTEgICAgIDkwICAg ICAgMCAgMCAgICAgIDAgL3Vzci9zcmMvc3lzL2tlcm4vc3Vicl9zbGVlcHF1ZXVlLmM6MzM1IChz cGluIG11dGV4OnNjaGVkIGxvY2sgMTUpCiAgICAgMTM0ICAgICAgIDE2NSAgICAgICAgMzE2MSAg ICAgICAgMjI3MCAgICAgICAgICAyOCAgICAxMTIgICAgIDgxICAwICAgICAyMCAvdXNyL3NyYy9z eXMva2Vybi9zY2hlZF91bGUuYzoyMDc0IChzcGluIG11dGV4OnNjaGVkIGxvY2sgMTUpCiAgICAg MTYyICAgICAgICAgMCAgICAgICA0MzE5MCAgICAgICAgICAgMCAgICAgICAgIDM0MCAgICAxMjcg ICAgICAwICAwICAgICAgMCAvdXNyL3NyYy9zeXMva2Vybi9zY2hlZF91bGUuYzoyMTExIChzcGlu IG11dGV4OnNjaGVkIGxvY2sgMTUpCiAgICAgMTIxICAgICAgICAgMCAgICAgICAgIDkxMyAgICAg ICAgICAgMCAgICAgICAgICAxMCAgICAgOTEgICAgICAwICAwICAgICAgMCAvdXNyL3NyYy9zeXMv a2Vybi9zdWJyX3NsZWVwcXVldWUuYzo1ODMgKHNwaW4gbXV0ZXg6c2NoZWQgbG9jayAxNSkKICAg ICAgNzcgICAgICAgICAwICAgICAgICAgIDc3ICAgICAgICAgICAwICAgICAgICAgICAxICAgICA3 NyAgICAgIDAgIDAgICAgICAwIC91c3Ivc3JjL3N5cy9rZXJuL3N1YnJfc2xlZXBxdWV1ZS5jOjYx OCAoc3BpbiBtdXRleDpzY2hlZCBsb2NrIDE1KQogICAgIDIyMSAgICAgICAyMzUgICAgMTc0ODMy NDcgICAgICAgIDIzNjcgICAgICAxNDcwOTcgICAgMTE4ICAgICAgMCAgMCAgICAgMTUgL3Vzci9z cmMvc3lzL2tlcm4va2Vybl9jbG9jay5jOjI4NiAoc3BpbiBtdXRleDpzY2hlZCBsb2NrIDE1KQog ICAgIDExNSAgICAgICAxMTUgICAgICAgICAxMTUgICAgICAgICAxMTUgICAgICAgICAgIDEgICAg MTE1ICAgIDExNSAgMCAgICAgIDEgL3Vzci9zcmMvc3lzL2tlcm4vc2NoZWRfdWxlLmM6MjU2OSAo c3BpbiBtdXRleDpzY2hlZCBsb2NrIDE1KQogICAgIDE3MyAgICAgICAgIDAgICAgICAyNzUzNDgg ICAgICAgICAgIDAgICAgICAgIDMzMTMgICAgIDgzICAgICAgMCAgMCAgICAgIDAgL3Vzci9zcmMv c3lzL2tlcm4va2Vybl9zd2l0Y2guYzoxODggKHNwaW4gbXV0ZXg6c2NoZWQgbG9jayAxNSkKICAg ICAxMTUgICAgICAgICAwICAgICAgICAgMTE1ICAgICAgICAgICAwICAgICAgICAgICAxICAgIDEx NSAgICAgIDAgIDAgICAgICAwIC91c3Ivc3JjL3N5cy9rZXJuL3NjaGVkX3VsZS5jOjI2MjcgKHNw aW4gbXV0ZXg6c2NoZWQgbG9jayAxNSkKICAgICAxOTAgICAgICAgMTMzICAgICAyMzMxOTYwICAg ICAgICAgMjY0ICAgICAgIDE5NTY0ICAgIDExOSAgICAgIDAgIDAgICAgICAyIC91c3Ivc3JjL3N5 cy9rZXJuL2tlcm5fY2xvY2suYzo1MDMgKHNwaW4gbXV0ZXg6c2NoZWQgbG9jayAxNSkKICAgICAx ODcgICAgICAgICAwICAgICAgMTUzNTMxICAgICAgICAgICAwICAgICAgICAxMjAyICAgIDEyNyAg ICAgIDAgIDAgICAgICAwIC91c3Ivc3JjL3N5cy9rZXJuL3N1YnJfdHJhcC5jOjE2NyAoc3BpbiBt dXRleDpzY2hlZCBsb2NrIDE1KQogICAgIDE3NyAgICAgICAgIDAgICAgICAxNTU3NjQgICAgICAg ICAgIDAgICAgICAgIDEyMDIgICAgMTI5ICAgICAgMCAgMCAgICAgIDAgL3Vzci9zcmMvc3lzL2tl cm4vc3Vicl90cmFwLmM6MjEzIChzcGluIG11dGV4OnNjaGVkIGxvY2sgMTUpCiAgICAgMTQ3ICAg ICAgICAgMCAgICAgICAgIDM4NiAgICAgICAgICAgMCAgICAgICAgICAgMyAgICAxMjggICAgICAw ICAwICAgICAgMCAvdXNyL3NyYy9zeXMva2Vybi9rZXJuX2ludHIuYzo4MDAgKHNwaW4gbXV0ZXg6 c2NoZWQgbG9jayAyMikKICAgICAgMzQgICAgICAgICAwICAgICAgICAgIDM0ICAgICAgICAgICAw ICAgICAgICAgICAxICAgICAzNCAgICAgIDAgIDAgICAgICAwIC91c3Ivc3JjL3N5cy9rZXJuL2tl cm5fdGhyZWFkLmM6NDEwIChzcGluIG11dGV4OnNjaGVkIGxvY2sgMTYpCiAgICAgIDEyICAgICAg ICAgMCAgICAgICAgICAxMiAgICAgICAgICAgMCAgICAgICAgICAgMSAgICAgMTIgICAgICAwICAw ICAgICAgMCAvdXNyL3NyYy9zeXMva2Vybi9rZXJuX3VtdHguYzozMzYwIChzcGluIG11dGV4OnNj aGVkIGxvY2sgMTYpCiAgICAgMTUwICAgICAgICAgMCAgICAgICAgMjc4MyAgICAgICAgICAgMCAg ICAgICAgICAyMCAgICAxMzkgICAgICAwICAwICAgICAgMCAvdXNyL3NyYy9zeXMva2Vybi9zdWJy X3R1cm5zdGlsZS5jOjcyNyAoc3BpbiBtdXRleDpzY2hlZCBsb2NrIDE2KQogICAgIDQ0MSAgICAg ICAgIDAgICAgICAgMTEwNDkgICAgICAgICAgIDAgICAgICAgICAgMjYgICAgNDI0ICAgICAgMCAg MCAgICAgIDAgL3Vzci9zcmMvc3lzL2tlcm4vc3Vicl90dXJuc3RpbGUuYzo4ODkgKHNwaW4gbXV0 ZXg6c2NoZWQgbG9jayAxNikKICAgICAxNzggICAgICAgICAwICAgICAgICA5NzM4ICAgICAgICAg ICAwICAgICAgICAgIDY3ICAgIDE0NSAgICAgIDAgIDAgICAgICAwIC91c3Ivc3JjL3N5cy9rZXJu L2tlcm5faW50ci5jOjEyMzkgKHNwaW4gbXV0ZXg6c2NoZWQgbG9jayAxNikKICAgICAzMDcgICAg ICAgICAwICAgICAgIDcyMTIwICAgICAgICAgICAwICAgICAgICAgNjU4ICAgIDEwOSAgICAgIDAg IDAgICAgICAwIC91c3Ivc3JjL3N5cy9rZXJuL3NjaGVkX3VsZS5jOjE4MzUgKHNwaW4gbXV0ZXg6 c2NoZWQgbG9jayAxNikKICAgICA3NTEgICAgICAgICAwICAgICAgMjA1NTgwICAgICAgICAgICAw ICAgICAgICAxOTk0ICAgIDEwMyAgICAgIDAgIDAgICAgICAwIC91c3Ivc3JjL3N5cy9rZXJuL3Nj aGVkX3VsZS5jOjE4NzYgKHNwaW4gbXV0ZXg6c2NoZWQgbG9jayAxNikKICAgICAxNTkgICAgICAg ICAwICAgICAgIDMzNDUzICAgICAgICAgICAwICAgICAgICAgNjM4ICAgICA1MiAgICAgIDAgIDAg ICAgICAwIC91c3Ivc3JjL3N5cy9rZXJuL3N1YnJfc2xlZXBxdWV1ZS5jOjMzNSAoc3BpbiBtdXRl eDpzY2hlZCBsb2NrIDE2KQogICAgIDE0MiAgICAgICAgIDAgICAgICAgICA2ODcgICAgICAgICAg IDAgICAgICAgICAgMjkgICAgIDIzICAgICAgMCAgMCAgICAgIDAgL3Vzci9zcmMvc3lzL2tlcm4v c3Vicl9zbGVlcHF1ZXVlLmM6MzkzIChzcGluIG11dGV4OnNjaGVkIGxvY2sgMTYpCiAgICAgMTkx ICAgICAgIDMxNCAgICAgICA0ODI4MSAgICAgICAzMTgxNyAgICAgICAgIDcwNSAgICAgNjggICAg IDQ1ICAwICAgIDU3NiAvdXNyL3NyYy9zeXMva2Vybi9zY2hlZF91bGUuYzoyMDc0IChzcGluIG11 dGV4OnNjaGVkIGxvY2sgMTYpCiAgICAgMTc1ICAgICAgMTE3NiAgICAgICA1NDc4MCAgICAgICAg MTE3NiAgICAgICAgIDQzOCAgICAxMjUgICAgICAyICAwICAgICAgMSAvdXNyL3NyYy9zeXMva2Vy bi9zY2hlZF91bGUuYzoyMTExIChzcGluIG11dGV4OnNjaGVkIGxvY2sgMTYpCiAgICAgMTU2ICAg ICAgICAgMCAgICAgICAgNzQ2MyAgICAgICAgICAgMCAgICAgICAgICA3MiAgICAxMDMgICAgICAw ICAwICAgICAgMCAvdXNyL3NyYy9zeXMva2Vybi9zdWJyX3NsZWVwcXVldWUuYzo1ODMgKHNwaW4g bXV0ZXg6c2NoZWQgbG9jayAxNikKICAgICAxNjUgICAgICAgIDQzICAgICAgIDI1ODUxICAgICAg ICAgIDQzICAgICAgICAgNTM3ICAgICA0OCAgICAgIDAgIDAgICAgICAxIC91c3Ivc3JjL3N5cy9r ZXJuL3N1YnJfc2xlZXBxdWV1ZS5jOjYxOCAoc3BpbiBtdXRleDpzY2hlZCBsb2NrIDE2KQogICAg IDE5NSAgICAgICA0NDcgICAgMTkxNjg1NzAgICAgICAgMjc3OTEgICAgICAxNDk4MzIgICAgMTI3 ICAgICAgMCAgMCAgICAxNDMgL3Vzci9zcmMvc3lzL2tlcm4va2Vybl9jbG9jay5jOjI4NiAoc3Bp biBtdXRleDpzY2hlZCBsb2NrIDE2KQogICAgICA5NSAgICAgIDQ2NzUgICAgICAgICA3ODcgICAg ICAgIDg5MTUgICAgICAgICAgMjAgICAgIDM5ICAgIDQ0NSAgMCAgICAgIDggL3Vzci9zcmMvc3lz L2tlcm4vc2NoZWRfdWxlLmM6MjU2OSAoc3BpbiBtdXRleDpzY2hlZCBsb2NrIDE2KQogICAgIDE4 MSAgICAgICAxNTAgICAgICAgMjEyODIgICAgICAgICAxNTAgICAgICAgICAxNDEgICAgMTUwICAg ICAgMSAgMCAgICAgIDEgL3Vzci9zcmMvc3lzL2tlcm4va2Vybl9zd2l0Y2guYzoxODggKHNwaW4g bXV0ZXg6c2NoZWQgbG9jayAxNikKICAgICAgMTQgICAgICAgICAwICAgICAgICAgIDE0ICAgICAg ICAgICAwICAgICAgICAgICAxICAgICAxNCAgICAgIDAgIDAgICAgICAwIC91c3Ivc3JjL3N5cy9r ZXJuL3NjaGVkX3VsZS5jOjI2MjcgKHNwaW4gbXV0ZXg6c2NoZWQgbG9jayAxNikKICAgICAxODUg ICAgICAgMjk2ICAgICAyNTMyMTA5ICAgICAgICAzOTg2ICAgICAgIDE5OTI3ICAgIDEyNyAgICAg IDAgIDAgICAgIDI1IC91c3Ivc3JjL3N5cy9rZXJuL2tlcm5fY2xvY2suYzo1MDMgKHNwaW4gbXV0 ZXg6c2NoZWQgbG9jayAxNikKICAgICAxNjUgICAgICA3MDcxICAgICAgMTg0NTg2ICAgICAgICA3 MDcxICAgICAgICAxNDEwICAgIDEzMCAgICAgIDUgIDAgICAgICAxIC91c3Ivc3JjL3N5cy9rZXJu L3N1YnJfdHJhcC5jOjE2NyAoc3BpbiBtdXRleDpzY2hlZCBsb2NrIDE2KQogICAgIDE3NSAgICAg ICA0NzEgICAgICAxOTE3ODAgICAgICAgICA0NzEgICAgICAgIDE0MDkgICAgMTM2ICAgICAgMCAg MCAgICAgIDEgL3Vzci9zcmMvc3lzL2tlcm4vc3Vicl90cmFwLmM6MjEzIChzcGluIG11dGV4OnNj aGVkIGxvY2sgMTYpCiAgICAgMjg0ICAgICAgICAgMCAgICAgICAgMTg1OSAgICAgICAgICAgMCAg ICAgICAgICAxMSAgICAxNjkgICAgICAwICAwICAgICAgMCAvdXNyL3NyYy9zeXMva2Vybi9zY2hl ZF91bGUuYzoxODM1IChzcGluIG11dGV4OnNjaGVkIGxvY2sgMTcpCiAgICAgNDIyICAgICAgICAg MCAgICAgICA5NTYyMyAgICAgICAgICAgMCAgICAgICAgIDcwOSAgICAxMzQgICAgICAwICAwICAg ICAgMCAvdXNyL3NyYy9zeXMva2Vybi9zY2hlZF91bGUuYzoxODc2IChzcGluIG11dGV4OnNjaGVk IGxvY2sgMTcpCiAgICAgMTQ1ICAgICAgICAgMCAgICAgICAgIDg0MyAgICAgICAgICAgMCAgICAg ICAgICAgOSAgICAgOTMgICAgICAwICAwICAgICAgMCAvdXNyL3NyYy9zeXMva2Vybi9zdWJyX3Ns ZWVwcXVldWUuYzozMzUgKHNwaW4gbXV0ZXg6c2NoZWQgbG9jayAxNykKICAgICAxODMgICAgICAg MjEzICAgICAgICA4ODE5ICAgICAgICA3MDMyICAgICAgICAgIDY5ICAgIDEyNyAgICAxMDEgIDAg ICAgIDUxIC91c3Ivc3JjL3N5cy9rZXJuL3NjaGVkX3VsZS5jOjIwNzQgKHNwaW4gbXV0ZXg6c2No ZWQgbG9jayAxNykKICAgICAxNzggICAgICAgICAwICAgICAgIDU1NTY5ICAgICAgICAgICAwICAg ICAgICAgNDE1ICAgIDEzMyAgICAgIDAgIDAgICAgICAwIC91c3Ivc3JjL3N5cy9rZXJuL3NjaGVk X3VsZS5jOjIxMTEgKHNwaW4gbXV0ZXg6c2NoZWQgbG9jayAxNykKICAgICAxNDQgICAgICAgICAw ICAgICAgICAgNjQwICAgICAgICAgICAwICAgICAgICAgICA3ICAgICA5MSAgICAgIDAgIDAgICAg ICAwIC91c3Ivc3JjL3N5cy9rZXJuL3N1YnJfc2xlZXBxdWV1ZS5jOjU4MyAoc3BpbiBtdXRleDpz Y2hlZCBsb2NrIDE3KQogICAgIDE0MiAgICAgICAgIDAgICAgICAgICAxNzQgICAgICAgICAgIDAg ICAgICAgICAgIDIgICAgIDg3ICAgICAgMCAgMCAgICAgIDAgL3Vzci9zcmMvc3lzL2tlcm4vc3Vi cl9zbGVlcHF1ZXVlLmM6NjE4IChzcGluIG11dGV4OnNjaGVkIGxvY2sgMTcpCiAgICAgMjQyICAg ICAgIDQyMSAgICAxOTExMDI0NiAgICAgICAxMjkxMyAgICAgIDE1MDM1OCAgICAxMjcgICAgICAw ICAwICAgICA1NyAvdXNyL3NyYy9zeXMva2Vybi9rZXJuX2Nsb2NrLmM6Mjg2IChzcGluIG11dGV4 OnNjaGVkIGxvY2sgMTcpCiAgICAgMTYzICAgICAgICAgMCAgICAgICAgIDYwMCAgICAgICAgICAg MCAgICAgICAgICAgNCAgICAxNTAgICAgICAwICAwICAgICAgMCAvdXNyL3NyYy9zeXMva2Vybi9r ZXJuX3N3aXRjaC5jOjE4OCAoc3BpbiBtdXRleDpzY2hlZCBsb2NrIDE3KQogICAgIDExMyAgICAg ICAgIDAgICAgICAgICAxMTMgICAgICAgICAgIDAgICAgICAgICAgIDEgICAgMTEzICAgICAgMCAg MCAgICAgIDAgL3Vzci9zcmMvc3lzL2tlcm4vc2NoZWRfdWxlLmM6MjYyNyAoc3BpbiBtdXRleDpz Y2hlZCBsb2NrIDE3KQogICAgIDE3NCAgICAgICAyNzEgICAgIDI1Mzc3NDUgICAgICAgIDExNDQg ICAgICAgMTk5OTggICAgMTI2ICAgICAgMCAgMCAgICAgIDUgL3Vzci9zcmMvc3lzL2tlcm4va2Vy bl9jbG9jay5jOjUwMyAoc3BpbiBtdXRleDpzY2hlZCBsb2NrIDE3KQogICAgIDE2NSAgICAgIDEw MDkgICAgICAxOTAwMDAgICAgICAgIDEwMDkgICAgICAgIDE0NDcgICAgMTMxICAgICAgMCAgMCAg ICAgIDEgL3Vzci9zcmMvc3lzL2tlcm4vc3Vicl90cmFwLmM6MTY3IChzcGluIG11dGV4OnNjaGVk IGxvY2sgMTcpCiAgICAgMTgwICAgICAgICAgMCAgICAgIDE5ODEzOSAgICAgICAgICAgMCAgICAg ICAgMTQ0NyAgICAxMzYgICAgICAwICAwICAgICAgMCAvdXNyL3NyYy9zeXMva2Vybi9zdWJyX3Ry YXAuYzoyMTMgKHNwaW4gbXV0ZXg6c2NoZWQgbG9jayAxNykKICAgICAgNjYgICAgICAgICAwICAg ICAgICAgIDY2ICAgICAgICAgICAwICAgICAgICAgICAxICAgICA2NiAgICAgIDAgIDAgICAgICAw IC91c3Ivc3JjL3N5cy9rZXJuL2tlcm5fdGhyZWFkLmM6NDEwIChzcGluIG11dGV4OnNjaGVkIGxv Y2sgMTcpCiAgICAgIDMzICAgICAgICAgMCAgICAgICAgICAzMyAgICAgICAgICAgMCAgICAgICAg ICAgMSAgICAgMzMgICAgICAwICAwICAgICAgMCAvdXNyL3NyYy9zeXMva2Vybi9rZXJuX3VtdHgu YzozMzYwIChzcGluIG11dGV4OnNjaGVkIGxvY2sgMTcpCiAgICAgIDgwICAgICAgICAgMCAgICAg ICAgIDEyOSAgICAgICAgICAgMCAgICAgICAgICAgMiAgICAgNjQgICAgICAwICAwICAgICAgMCAv dXNyL3NyYy9zeXMva2Vybi9zdWJyX3R1cm5zdGlsZS5jOjcyNyAoc3BpbiBtdXRleDpzY2hlZCBs b2NrIDE3KQogICAgIDExNCAgICAgICAgIDAgICAgICAgICA0ODkgICAgICAgICAgIDAgICAgICAg ICAgIDUgICAgIDk3ICAgICAgMCAgMCAgICAgIDAgL3Vzci9zcmMvc3lzL2tlcm4va2Vybl9pbnRy LmM6MTIzOSAoc3BpbiBtdXRleDpzY2hlZCBsb2NrIDE3KQogICAgICAzNyAgICAgICAyMzEgICAg ICAgICAgNzIgICAgICAgICAzMTggICAgICAgICAgIDIgICAgIDM2ICAgIDE1OSAgMCAgICAgIDIg L3Vzci9zcmMvc3lzL3ZtL3VtYV9jb3JlLmM6MjcwMyAoc2xlZXAgbXV0ZXg6c2VsZmQpCiAgICAg IDYwICAgICAgICAgMCAgICAgICAgICA2MCAgICAgICAgICAgMCAgICAgICAgICAgMSAgICAgNjAg ICAgICAwICAwICAgICAgMCAvdXNyL3NyYy9zeXMva2Vybi9zdWJyX3R1cm5zdGlsZS5jOjcyNyAo c3BpbiBtdXRleDpzY2hlZCBsb2NrIDE4KQogICAgIDE2OCAgICAgICAgIDAgICAgICAgIDE1ODIg ICAgICAgICAgIDAgICAgICAgICAgMjggICAgIDU2ICAgICAgMCAgMCAgICAgIDAgL3Vzci9zcmMv c3lzL2tlcm4vc2NoZWRfdWxlLmM6MTgzNSAoc3BpbiBtdXRleDpzY2hlZCBsb2NrIDE4KQogICAg IDEwOCAgICAgICAgIDAgICAgICAgIDE5MjYgICAgICAgICAgIDAgICAgICAgICAgNTggICAgIDMz ICAgICAgMCAgMCAgICAgIDAgL3Vzci9zcmMvc3lzL2tlcm4vc2NoZWRfdWxlLmM6MTg3NiAoc3Bp biBtdXRleDpzY2hlZCBsb2NrIDE4KQogICAgIDEwMyAgICAgICAgIDAgICAgICAgICA4MjEgICAg ICAgICAgIDAgICAgICAgICAgMjcgICAgIDMwICAgICAgMCAgMCAgICAgIDAgL3Vzci9zcmMvc3lz L2tlcm4vc3Vicl9zbGVlcHF1ZXVlLmM6MzM1IChzcGluIG11dGV4OnNjaGVkIGxvY2sgMTgpCiAg ICAgIDQxICAgICAgICAgMCAgICAgICAgIDQxNyAgICAgICAgICAgMCAgICAgICAgICAyMiAgICAg MTggICAgICAwICAwICAgICAgMCAvdXNyL3NyYy9zeXMva2Vybi9zdWJyX3NsZWVwcXVldWUuYzoz OTMgKHNwaW4gbXV0ZXg6c2NoZWQgbG9jayAxOCkKICAgICAxNjYgICAgICAgMjA0ICAgICAgIDEy MjMxICAgICAgICA5Nzc4ICAgICAgICAgMTA5ICAgIDExMiAgICAgODkgIDAgICAgIDgwIC91c3Iv c3JjL3N5cy9rZXJuL3NjaGVkX3VsZS5jOjIwNzQgKHNwaW4gbXV0ZXg6c2NoZWQgbG9jayAxOCkK ICAgICAxNjAgICAgICAgICAwICAgICAgIDU4MTM4ICAgICAgICAgICAwICAgICAgICAgNDcxICAg IDEyMyAgICAgIDAgIDAgICAgICAwIC91c3Ivc3JjL3N5cy9rZXJuL3NjaGVkX3VsZS5jOjIxMTEg KHNwaW4gbXV0ZXg6c2NoZWQgbG9jayAxOCkKICAgICAgOTIgICAgICAgICAwICAgICAgICAgMzAz ICAgICAgICAgICAwICAgICAgICAgICA0ICAgICA3NSAgICAgIDAgIDAgICAgICAwIC91c3Ivc3Jj L3N5cy9rZXJuL3N1YnJfc2xlZXBxdWV1ZS5jOjU4MyAoc3BpbiBtdXRleDpzY2hlZCBsb2NrIDE4 KQogICAgICA4MCAgICAgICAgIDAgICAgICAgICAgODAgICAgICAgICAgIDAgICAgICAgICAgIDEg ICAgIDgwICAgICAgMCAgMCAgICAgIDAgL3Vzci9zcmMvc3lzL2tlcm4vc3Vicl9zbGVlcHF1ZXVl LmM6NjE4IChzcGluIG11dGV4OnNjaGVkIGxvY2sgMTgpCiAgICAgMjMyICAgICAgIDI2OSAgICAx OTEyMTQ3OSAgICAgICAgMzI3NCAgICAgIDE1MDQ3NyAgICAxMjcgICAgICAwICAwICAgICAxNiAv dXNyL3NyYy9zeXMva2Vybi9rZXJuX2Nsb2NrLmM6Mjg2IChzcGluIG11dGV4OnNjaGVkIGxvY2sg MTgpCiAgICAgIDQxICAgICAgICAzMCAgICAgICAgIDExNyAgICAgICAgICA5NiAgICAgICAgICAg NCAgICAgMjkgICAgIDI0ICAwICAgICAgNCAvdXNyL3NyYy9zeXMva2Vybi9zY2hlZF91bGUuYzoy NTY5IChzcGluIG11dGV4OnNjaGVkIGxvY2sgMTgpCiAgICAgMTg4ICAgICAgIDE0OCAgICAgMjU1 NTI0NyAgICAgICAgIDMzOCAgICAgICAyMDAxNCAgICAxMjcgICAgICAwICAwICAgICAgMyAvdXNy L3NyYy9zeXMva2Vybi9rZXJuX2Nsb2NrLmM6NTAzIChzcGluIG11dGV4OnNjaGVkIGxvY2sgMTgp CiAgICAgMTc0ICAgICAgICAgMCAgICAgIDE4OTM4NiAgICAgICAgICAgMCAgICAgICAgMTQxMiAg ICAxMzQgICAgICAwICAwICAgICAgMCAvdXNyL3NyYy9zeXMva2Vybi9zdWJyX3RyYXAuYzoxNjcg KHNwaW4gbXV0ZXg6c2NoZWQgbG9jayAxOCkKICAgICAxNzkgICAgICAgICAwICAgICAgMTk5MzM0 ICAgICAgICAgICAwICAgICAgICAxNDEyICAgIDE0MSAgICAgIDAgIDAgICAgICAwIC91c3Ivc3Jj L3N5cy9rZXJuL3N1YnJfdHJhcC5jOjIxMyAoc3BpbiBtdXRleDpzY2hlZCBsb2NrIDE4KQogICAg IDIzMSAgICAgICAgIDAgICAgICAgICAyMzEgICAgICAgICAgIDAgICAgICAgICAgIDEgICAgMjMx ICAgICAgMCAgMCAgICAgIDAgL3Vzci9zcmMvc3lzL2tlcm4va2Vybl90aHJlYWQuYzo0MTAgKHNw aW4gbXV0ZXg6c2NoZWQgbG9jayAxOCkKICAgICAgODQgICAgICAgICAwICAgICAgICAgIDg0ICAg ICAgICAgICAwICAgICAgICAgICAxICAgICA4NCAgICAgIDAgIDAgICAgICAwIC91c3Ivc3JjL3N5 cy9rZXJuL2tlcm5fdW10eC5jOjMzNjAgKHNwaW4gbXV0ZXg6c2NoZWQgbG9jayAxOCkKICAgICAy MDAgICAgICAgICAwICAgICAgICAgMjAwICAgICAgICAgICAwICAgICAgICAgICAxICAgIDIwMCAg ICAgIDAgIDAgICAgICAwIC91c3Ivc3JjL3N5cy9rZXJuL2tlcm5fdGhyZWFkLmM6NDEwIChzcGlu IG11dGV4OnNjaGVkIGxvY2sgMTkpCiAgICAgMTA2ICAgICAgICAgMCAgICAgICAgIDEwNiAgICAg ICAgICAgMCAgICAgICAgICAgMSAgICAxMDYgICAgICAwICAwICAgICAgMCAvdXNyL3NyYy9zeXMv a2Vybi9rZXJuX3VtdHguYzozMzYwIChzcGluIG11dGV4OnNjaGVkIGxvY2sgMTkpCiAgICAgMTQ1 ICAgICAgICAgMCAgICAgICAgIDYyOCAgICAgICAgICAgMCAgICAgICAgICAgNSAgICAxMjUgICAg ICAwICAwICAgICAgMCAvdXNyL3NyYy9zeXMva2Vybi9rZXJuX2ludHIuYzoxMjM5IChzcGluIG11 dGV4OnNjaGVkIGxvY2sgMTkpCiAgICAgMjQzICAgICAgICAgMCAgICAgICAgMjkyOCAgICAgICAg ICAgMCAgICAgICAgICAxNSAgICAxOTUgICAgICAwICAwICAgICAgMCAvdXNyL3NyYy9zeXMva2Vy bi9zY2hlZF91bGUuYzoxODM1IChzcGluIG11dGV4OnNjaGVkIGxvY2sgMTkpCiAgICAgMTQ4ICAg ICAgICAgMCAgICAgICAgNDA5NiAgICAgICAgICAgMCAgICAgICAgICAzOSAgICAxMDUgICAgICAw ICAwICAgICAgMCAvdXNyL3NyYy9zeXMva2Vybi9zY2hlZF91bGUuYzoxODc2IChzcGluIG11dGV4 OnNjaGVkIGxvY2sgMTkpCiAgICAgMTIzICAgICAgICAgMCAgICAgICAgMTQ5OSAgICAgICAgICAg MCAgICAgICAgICAxNSAgICAgOTkgICAgICAwICAwICAgICAgMCAvdXNyL3NyYy9zeXMva2Vybi9z dWJyX3NsZWVwcXVldWUuYzozMzUgKHNwaW4gbXV0ZXg6c2NoZWQgbG9jayAxOSkKICAgICAxNTEg ICAgICAgMTkyICAgICAgIDEzMDI2ICAgICAgIDEwMjk2ICAgICAgICAgMTAxICAgIDEyOCAgICAx MDEgIDAgICAgIDcyIC91c3Ivc3JjL3N5cy9rZXJuL3NjaGVkX3VsZS5jOjIwNzQgKHNwaW4gbXV0 ZXg6c2NoZWQgbG9jayAxOSkKICAgICAxNTUgICAgICAgICAwICAgICAgIDM2NjM5ICAgICAgICAg ICAwICAgICAgICAgMjYzICAgIDEzOSAgICAgIDAgIDAgICAgICAwIC91c3Ivc3JjL3N5cy9rZXJu L3NjaGVkX3VsZS5jOjIxMTEgKHNwaW4gbXV0ZXg6c2NoZWQgbG9jayAxOSkKICAgICAxMTkgICAg ICAgICAwICAgICAgICAxMjQyICAgICAgICAgICAwICAgICAgICAgIDEzICAgICA5NSAgICAgIDAg IDAgICAgICAwIC91c3Ivc3JjL3N5cy9rZXJuL3N1YnJfc2xlZXBxdWV1ZS5jOjU4MyAoc3BpbiBt dXRleDpzY2hlZCBsb2NrIDE5KQogICAgIDExNyAgICAgICAgIDAgICAgICAgICAyMzQgICAgICAg ICAgIDAgICAgICAgICAgIDIgICAgMTE3ICAgICAgMCAgMCAgICAgIDAgL3Vzci9zcmMvc3lzL2tl cm4vc3Vicl9zbGVlcHF1ZXVlLmM6NjE4IChzcGluIG11dGV4OnNjaGVkIGxvY2sgMTkpCiAgICAg MjQyICAgICAgIDI1NiAgICAxOTE5MDAxOCAgICAgICAgMjA3OSAgICAgIDE1MDQ0NiAgICAxMjcg ICAgICAwICAwICAgICAxMSAvdXNyL3NyYy9zeXMva2Vybi9rZXJuX2Nsb2NrLmM6Mjg2IChzcGlu IG11dGV4OnNjaGVkIGxvY2sgMTkpCiAgICAgIDk2ICAgICAxOTY4NiAgICAgICAgICA5NiAgICAg ICAxOTY4NiAgICAgICAgICAgMSAgICAgOTYgIDE5Njg2ICAwICAgICAgMSAvdXNyL3NyYy9zeXMv a2Vybi9zY2hlZF91bGUuYzoyNTY5IChzcGluIG11dGV4OnNjaGVkIGxvY2sgMTkpCiAgICAgMTQ4 ICAgICAgICAgMCAgICAgICAgIDI3MiAgICAgICAgICAgMCAgICAgICAgICAgMiAgICAxMzYgICAg ICAwICAwICAgICAgMCAvdXNyL3NyYy9zeXMva2Vybi9rZXJuX3N3aXRjaC5jOjE4OCAoc3BpbiBt dXRleDpzY2hlZCBsb2NrIDE5KQogICAgIDExNiAgICAgICAgIDAgICAgICAgICAxMTYgICAgICAg ICAgIDAgICAgICAgICAgIDEgICAgMTE2ICAgICAgMCAgMCAgICAgIDAgL3Vzci9zcmMvc3lzL2tl cm4vc2NoZWRfdWxlLmM6MjYyNyAoc3BpbiBtdXRleDpzY2hlZCBsb2NrIDE5KQogICAgIDE4NCAg ICAgICAyNDggICAgIDI1NTA2MTYgICAgICAgICA3NzggICAgICAgMjAwMTAgICAgMTI3ICAgICAg MCAgMCAgICAgIDQgL3Vzci9zcmMvc3lzL2tlcm4va2Vybl9jbG9jay5jOjUwMyAoc3BpbiBtdXRl eDpzY2hlZCBsb2NrIDE5KQogICAgIDE2NiAgICAgIDExMzggICAgICAxODY5NzAgICAgICAgIDEx MzggICAgICAgIDEzODQgICAgMTM1ICAgICAgMCAgMCAgICAgIDEgL3Vzci9zcmMvc3lzL2tlcm4v c3Vicl90cmFwLmM6MTY3IChzcGluIG11dGV4OnNjaGVkIGxvY2sgMTkpCiAgICAgMTg0ICAgICAg ICAgMCAgICAgIDE5ODA3OCAgICAgICAgICAgMCAgICAgICAgMTM4NCAgICAxNDMgICAgICAwICAw ICAgICAgMCAvdXNyL3NyYy9zeXMva2Vybi9zdWJyX3RyYXAuYzoyMTMgKHNwaW4gbXV0ZXg6c2No ZWQgbG9jayAxOSkKICAgICAyMzIgICAgICAgICAwICAgICAgICAgMjMyICAgICAgICAgICAwICAg ICAgICAgICAxICAgIDIzMiAgICAgIDAgIDAgICAgICAwIC91c3Ivc3JjL3N5cy9rZXJuL2tlcm5f dGhyZWFkLmM6NDEwIChzcGluIG11dGV4OnNjaGVkIGxvY2sgMjApCiAgICAgMjc2ICAgICAgICAg MCAgICAgICAgMTA1OSAgICAgICAgICAgMCAgICAgICAgICAgNCAgICAyNjQgICAgICAwICAwICAg ICAgMCAvdXNyL3NyYy9zeXMva2Vybi9zY2hlZF91bGUuYzo4MDcgKHNwaW4gbXV0ZXg6c2NoZWQg bG9jayAyMCkKICAgICAxMzggICAgICAgICAwICAgICAgICAgMTM4ICAgICAgICAgICAwICAgICAg ICAgICAxICAgIDEzOCAgICAgIDAgIDAgICAgICAwIC91c3Ivc3JjL3N5cy9rZXJuL2tlcm5fdW10 eC5jOjMzNjAgKHNwaW4gbXV0ZXg6c2NoZWQgbG9jayAyMCkKICAgICAxMzcgICAgICAgICAwICAg ICAgICA0NDgxICAgICAgICAgICAwICAgICAgICAgIDM0ICAgIDEzMSAgICAgIDAgIDAgICAgICAw IC91c3Ivc3JjL3N5cy9rZXJuL3N1YnJfdHVybnN0aWxlLmM6NzI3IChzcGluIG11dGV4OnNjaGVk IGxvY2sgMjApCiAgICAgNDA2ICAgICAgICAgMCAgICAgICAxMTg2NiAgICAgICAgICAgMCAgICAg ICAgICAzMCAgICAzOTUgICAgICAwICAwICAgICAgMCAvdXNyL3NyYy9zeXMva2Vybi9zdWJyX3R1 cm5zdGlsZS5jOjg4OSAoc3BpbiBtdXRleDpzY2hlZCBsb2NrIDIwKQogICAgIDIxNyAgICAgICAg IDAgICAgICAgNTQ4MzAgICAgICAgICAgIDAgICAgICAgICA0MzAgICAgMTI3ICAgICAgMCAgMCAg ICAgIDAgL3Vzci9zcmMvc3lzL2tlcm4va2Vybl9pbnRyLmM6MTIzOSAoc3BpbiBtdXRleDpzY2hl ZCBsb2NrIDIwKQogICAgIDMzMiAgICAgICAyODIgICAgICAxMzI1MDUgICAgICAgICAyODIgICAg ICAgICA4MjUgICAgMTYwICAgICAgMCAgMCAgICAgIDEgL3Vzci9zcmMvc3lzL2tlcm4vc2NoZWRf dWxlLmM6MTgzNSAoc3BpbiBtdXRleDpzY2hlZCBsb2NrIDIwKQogICAgIDc2OCAgICAgICAgIDAg ICAgICAyNTkxNzAgICAgICAgICAgIDAgICAgICAgIDI1MTMgICAgMTAzICAgICAgMCAgMCAgICAg IDAgL3Vzci9zcmMvc3lzL2tlcm4vc2NoZWRfdWxlLmM6MTg3NiAoc3BpbiBtdXRleDpzY2hlZCBs b2NrIDIwKQogICAgIDE3OCAgICAgICAxMzMgICAgICAgNjA4NTYgICAgICAgICAxMzMgICAgICAg ICA3OTIgICAgIDc2ICAgICAgMCAgMCAgICAgIDEgL3Vzci9zcmMvc3lzL2tlcm4vc3Vicl9zbGVl cHF1ZXVlLmM6MzM1IChzcGluIG11dGV4OnNjaGVkIGxvY2sgMjApCiAgICAgMTMxICAgICAgICAg MCAgICAgICAgIDM2MSAgICAgICAgICAgMCAgICAgICAgICAgNSAgICAgNzIgICAgICAwICAwICAg ICAgMCAvdXNyL3NyYy9zeXMva2Vybi9zdWJyX3NsZWVwcXVldWUuYzozOTMgKHNwaW4gbXV0ZXg6 c2NoZWQgbG9jayAyMCkKICAgICAxOTIgICAgICAgMzQ2ICAgICAgIDk5Njg5ICAgICAgIDY1MzU1 ICAgICAgICAxMDc5ICAgICA5MiAgICAgNjAgIDAgICAgNzkzIC91c3Ivc3JjL3N5cy9rZXJuL3Nj aGVkX3VsZS5jOjIwNzQgKHNwaW4gbXV0ZXg6c2NoZWQgbG9jayAyMCkKICAgICAxODAgICAgICA2 NjIwICAgICAgIDUzNzE4ICAgICAgICA2NjIwICAgICAgICAgNDE0ICAgIDEyOSAgICAgMTUgIDAg ICAgICAxIC91c3Ivc3JjL3N5cy9rZXJuL3NjaGVkX3VsZS5jOjIxMTEgKHNwaW4gbXV0ZXg6c2No ZWQgbG9jayAyMCkKICAgICAyNDMgICAgICAgICAwICAgICAgIDI4ODU1ICAgICAgICAgICAwICAg ICAgICAgNTA3ICAgICA1NiAgICAgIDAgIDAgICAgICAwIC91c3Ivc3JjL3N5cy9rZXJuL3N1YnJf c2xlZXBxdWV1ZS5jOjU4MyAoc3BpbiBtdXRleDpzY2hlZCBsb2NrIDIwKQogICAgIDE3MyAgICAg ICAxNzAgICAgICAgMzMzMzcgICAgICAgICAyNzAgICAgICAgICAyODAgICAgMTE5ICAgICAgMCAg MCAgICAgIDIgL3Vzci9zcmMvc3lzL2tlcm4vc3Vicl9zbGVlcHF1ZXVlLmM6NjE4IChzcGluIG11 dGV4OnNjaGVkIGxvY2sgMjApCiAgICAgMjM0ICAgICAgIDU0OCAgICAxODIyNzE1NyAgICAgICAy Nzg3NCAgICAgIDE0OTQ3OSAgICAxMjEgICAgICAwICAwICAgIDE2NyAvdXNyL3NyYy9zeXMva2Vy bi9rZXJuX2Nsb2NrLmM6Mjg2IChzcGluIG11dGV4OnNjaGVkIGxvY2sgMjApCiAgICAgMTgxICAg ICAxMjAxMyAgICAgICAgNDY5NiAgICAgICA3MTE3NiAgICAgICAgICA1NSAgICAgODUgICAxMjk0 ICAwICAgICA0MyAvdXNyL3NyYy9zeXMva2Vybi9zY2hlZF91bGUuYzoyNTY5IChzcGluIG11dGV4 OnNjaGVkIGxvY2sgMjApCiAgICAgMTUyICAgICAgIDc4MSAgICAgICAzNDUzNCAgICAgICAgMTA4 NSAgICAgICAgIDI2MSAgICAxMzIgICAgICA0ICAwICAgICAgMyAvdXNyL3NyYy9zeXMva2Vybi9r ZXJuX3N3aXRjaC5jOjE4OCAoc3BpbiBtdXRleDpzY2hlZCBsb2NrIDIwKQogICAgIDEyNiAgICAg ICAgIDAgICAgICAgICAxMjYgICAgICAgICAgIDAgICAgICAgICAgIDEgICAgMTI2ICAgICAgMCAg MCAgICAgIDAgL3Vzci9zcmMvc3lzL2tlcm4vc2NoZWRfdWxlLmM6MjYyNyAoc3BpbiBtdXRleDpz Y2hlZCBsb2NrIDIwKQogICAgIDIwMCAgICAgICAyMzAgICAgIDI0MjkxNTggICAgICAgIDQ2MDgg ICAgICAgMTk4ODAgICAgMTIyICAgICAgMCAgMCAgICAgMzUgL3Vzci9zcmMvc3lzL2tlcm4va2Vy bl9jbG9jay5jOjUwMyAoc3BpbiBtdXRleDpzY2hlZCBsb2NrIDIwKQogICAgIDE4OCAgICAgICAg IDAgICAgICAxNjIyMjIgICAgICAgICAgIDAgICAgICAgIDEyNDMgICAgMTMwICAgICAgMCAgMCAg ICAgIDAgL3Vzci9zcmMvc3lzL2tlcm4vc3Vicl90cmFwLmM6MTY3IChzcGluIG11dGV4OnNjaGVk IGxvY2sgMjApCiAgICAgMTg3ICAgICAgICAgMCAgICAgIDE2MzYzNCAgICAgICAgICAgMCAgICAg ICAgMTI0MyAgICAxMzEgICAgICAwICAwICAgICAgMCAvdXNyL3NyYy9zeXMva2Vybi9zdWJyX3Ry YXAuYzoyMTMgKHNwaW4gbXV0ZXg6c2NoZWQgbG9jayAyMCkKICAgICAyMTggICAgICAgMzAzICAg IDE4MzYwMTkyICAgICAgIDEwODg0ICAgICAgMTUwMTAzICAgIDEyMiAgICAgIDAgIDAgICAgIDY2 IC91c3Ivc3JjL3N5cy9rZXJuL2tlcm5fY2xvY2suYzoyODYgKHNwaW4gbXV0ZXg6c2NoZWQgbG9j ayAyMSkKICAgICAxNTAgICAgIDE3ODI2ICAgICAgICAyODEyICAgICAgIDI4Mjk5ICAgICAgICAg IDI2ICAgIDEwOCAgIDEwODggIDAgICAgIDI0IC91c3Ivc3JjL3N5cy9rZXJuL3NjaGVkX3VsZS5j OjI1NjkgKHNwaW4gbXV0ZXg6c2NoZWQgbG9jayAyMSkKICAgICAxNzIgICAgICAgICAwICAgICAg ICAxNjU4ICAgICAgICAgICAwICAgICAgICAgIDEzICAgIDEyNyAgICAgIDAgIDAgICAgICAwIC91 c3Ivc3JjL3N5cy9rZXJuL2tlcm5fc3dpdGNoLmM6MTg4IChzcGluIG11dGV4OnNjaGVkIGxvY2sg MjEpCiAgICAgMTIyICAgICAgICAgMCAgICAgICAgIDEyMiAgICAgICAgICAgMCAgICAgICAgICAg MSAgICAxMjIgICAgICAwICAwICAgICAgMCAvdXNyL3NyYy9zeXMva2Vybi9zY2hlZF91bGUuYzoy NjI3IChzcGluIG11dGV4OnNjaGVkIGxvY2sgMjEpCiAgICAgMjAwICAgICAgIDIxMCAgICAgMjQz OTg0NyAgICAgICAgMjIyOCAgICAgICAxOTk2NCAgICAxMjIgICAgICAwICAwICAgICAxNiAvdXNy L3NyYy9zeXMva2Vybi9rZXJuX2Nsb2NrLmM6NTAzIChzcGluIG11dGV4OnNjaGVkIGxvY2sgMjEp CiAgICAgMTY2ICAgICAgICAgMCAgICAgIDE2MzY4MCAgICAgICAgICAgMCAgICAgICAgMTI0OCAg ICAxMzEgICAgICAwICAwICAgICAgMCAvdXNyL3NyYy9zeXMva2Vybi9zdWJyX3RyYXAuYzoxNjcg KHNwaW4gbXV0ZXg6c2NoZWQgbG9jayAyMSkKICAgICAxOTggICAgICAgICAwICAgICAgMTY0ODk0 ICAgICAgICAgICAwICAgICAgICAxMjQ4ICAgIDEzMiAgICAgIDAgIDAgICAgICAwIC91c3Ivc3Jj L3N5cy9rZXJuL3N1YnJfdHJhcC5jOjIxMyAoc3BpbiBtdXRleDpzY2hlZCBsb2NrIDIxKQogICAg IDIzOSAgICAgICAgIDAgICAgICAgICAyMzkgICAgICAgICAgIDAgICAgICAgICAgIDEgICAgMjM5 ICAgICAgMCAgMCAgICAgIDAgL3Vzci9zcmMvc3lzL2tlcm4va2Vybl90aHJlYWQuYzo0MTAgKHNw aW4gbXV0ZXg6c2NoZWQgbG9jayAyMSkKICAgICAxMzEgICAgICAgICAwICAgICAgICAgMTMxICAg ICAgICAgICAwICAgICAgICAgICAxICAgIDEzMSAgICAgIDAgIDAgICAgICAwIC91c3Ivc3JjL3N5 cy9rZXJuL2tlcm5fdW10eC5jOjMzNjAgKHNwaW4gbXV0ZXg6c2NoZWQgbG9jayAyMSkKICAgICA0 MDAgICAgICAgICAwICAgICAgICAgNDAwICAgICAgICAgICAwICAgICAgICAgICAxICAgIDQwMCAg ICAgIDAgIDAgICAgICAwIC91c3Ivc3JjL3N5cy9rZXJuL3N1YnJfdHVybnN0aWxlLmM6ODg5IChz cGluIG11dGV4OnNjaGVkIGxvY2sgMjEpCiAgICAgMjA4ICAgICAgIDEyOSAgICAgICAxNjI0NSAg ICAgICAgIDEyOSAgICAgICAgIDE0NSAgICAxMTIgICAgICAwICAwICAgICAgMSAvdXNyL3NyYy9z eXMva2Vybi9rZXJuX2ludHIuYzoxMjM5IChzcGluIG11dGV4OnNjaGVkIGxvY2sgMjEpCiAgICAg MzE2ICAgICAgICAgMCAgICAgICA1MTc0NyAgICAgICAgICAgMCAgICAgICAgIDIyMSAgICAyMzQg ICAgICAwICAwICAgICAgMCAvdXNyL3NyYy9zeXMva2Vybi9zY2hlZF91bGUuYzoxODM1IChzcGlu IG11dGV4OnNjaGVkIGxvY2sgMjEpCiAgICAgNjcxICAgICAgICAgMCAgICAgIDEyMzAzMCAgICAg ICAgICAgMCAgICAgICAgIDcyNyAgICAxNjkgICAgICAwICAwICAgICAgMCAvdXNyL3NyYy9zeXMv a2Vybi9zY2hlZF91bGUuYzoxODc2IChzcGluIG11dGV4OnNjaGVkIGxvY2sgMjEpCiAgICAgMTcw ICAgICAgIDEwMiAgICAgICAyNTc5NCAgICAgICAgIDEwMiAgICAgICAgIDIyMSAgICAxMTYgICAg ICAwICAwICAgICAgMSAvdXNyL3NyYy9zeXMva2Vybi9zdWJyX3NsZWVwcXVldWUuYzozMzUgKHNw aW4gbXV0ZXg6c2NoZWQgbG9jayAyMSkKICAgICAxMDYgICAgICAgICAwICAgICAgICAgMTA2ICAg ICAgICAgICAwICAgICAgICAgICAxICAgIDEwNiAgICAgIDAgIDAgICAgICAwIC91c3Ivc3JjL3N5 cy9rZXJuL3N1YnJfc2xlZXBxdWV1ZS5jOjM5MyAoc3BpbiBtdXRleDpzY2hlZCBsb2NrIDIxKQog ICAgIDIxNyAgICAgICAzOTUgICAgICAgMzk0NDggICAgICAgMjQ0OTggICAgICAgICAzMjggICAg MTIwICAgICA3NCAgMCAgICAyMTEgL3Vzci9zcmMvc3lzL2tlcm4vc2NoZWRfdWxlLmM6MjA3NCAo c3BpbiBtdXRleDpzY2hlZCBsb2NrIDIxKQogICAgIDE2MiAgICAgICAgIDAgICAgICAgNTM4NTgg ICAgICAgICAgIDAgICAgICAgICA0MTAgICAgMTMxICAgICAgMCAgMCAgICAgIDAgL3Vzci9zcmMv c3lzL2tlcm4vc2NoZWRfdWxlLmM6MjExMSAoc3BpbiBtdXRleDpzY2hlZCBsb2NrIDIxKQogICAg IDE3NCAgICAgICAgIDAgICAgICAgIDQ0NDQgICAgICAgICAgIDAgICAgICAgICAgNDMgICAgMTAz ICAgICAgMCAgMCAgICAgIDAgL3Vzci9zcmMvc3lzL2tlcm4vc3Vicl9zbGVlcHF1ZXVlLmM6NTgz IChzcGluIG11dGV4OnNjaGVkIGxvY2sgMjEpCiAgICAgMTg4ICAgICAgIDExNiAgICAgICAyMTQy MSAgICAgICAgIDExNiAgICAgICAgIDE3NyAgICAxMjEgICAgICAwICAwICAgICAgMSAvdXNyL3Ny Yy9zeXMva2Vybi9zdWJyX3NsZWVwcXVldWUuYzo2MTggKHNwaW4gbXV0ZXg6c2NoZWQgbG9jayAy MSkKICAgICAxMzMgICAgICAgICAwICAgICAgICAgMzY5ICAgICAgICAgICAwICAgICAgICAgICAz ICAgIDEyMyAgICAgIDAgIDAgICAgICAwIC91c3Ivc3JjL3N5cy9rZXJuL2tlcm5faW50ci5jOjEy MzkgKHNwaW4gbXV0ZXg6c2NoZWQgbG9jayAyMikKICAgICAzMjkgICAgICAgICAwICAgICAgIDMz MTM0ICAgICAgICAgICAwICAgICAgICAgMTQxICAgIDIzNCAgICAgIDAgIDAgICAgICAwIC91c3Iv c3JjL3N5cy9rZXJuL3NjaGVkX3VsZS5jOjE4MzUgKHNwaW4gbXV0ZXg6c2NoZWQgbG9jayAyMikK ICAgICA2MDQgICAgICAgICAwICAgICAgIDUyNjgwICAgICAgICAgICAwICAgICAgICAgMjg2ICAg IDE4NCAgICAgIDAgIDAgICAgICAwIC91c3Ivc3JjL3N5cy9rZXJuL3NjaGVkX3VsZS5jOjE4NzYg KHNwaW4gbXV0ZXg6c2NoZWQgbG9jayAyMikKICAgICAxNjcgICAgICAgICAwICAgICAgIDE2MTc4 ICAgICAgICAgICAwICAgICAgICAgMTQwICAgIDExNSAgICAgIDAgIDAgICAgICAwIC91c3Ivc3Jj L3N5cy9rZXJuL3N1YnJfc2xlZXBxdWV1ZS5jOjMzNSAoc3BpbiBtdXRleDpzY2hlZCBsb2NrIDIy KQogICAgIDE5NyAgICAgICAxODEgICAgICAgMTY5ODIgICAgICAgIDk5NTIgICAgICAgICAxMzUg ICAgMTI1ICAgICA3MyAgMCAgICAgODYgL3Vzci9zcmMvc3lzL2tlcm4vc2NoZWRfdWxlLmM6MjA3 NCAoc3BpbiBtdXRleDpzY2hlZCBsb2NrIDIyKQogICAgIDE2NiAgICAgICAgIDAgICAgICAgNDkw NjQgICAgICAgICAgIDAgICAgICAgICAzNzQgICAgMTMxICAgICAgMCAgMCAgICAgIDAgL3Vzci9z cmMvc3lzL2tlcm4vc2NoZWRfdWxlLmM6MjExMSAoc3BpbiBtdXRleDpzY2hlZCBsb2NrIDIyKQog ICAgIDIwMCAgICAgICAgIDAgICAgICAgIDY4MTggICAgICAgICAgIDAgICAgICAgICAgNjIgICAg MTA5ICAgICAgMCAgMCAgICAgIDAgL3Vzci9zcmMvc3lzL2tlcm4vc3Vicl9zbGVlcHF1ZXVlLmM6 NTgzIChzcGluIG11dGV4OnNjaGVkIGxvY2sgMjIpCiAgICAgMTk4ICAgICAgICAgMCAgICAgICAg OTk0MyAgICAgICAgICAgMCAgICAgICAgICA3OCAgICAxMjcgICAgICAwICAwICAgICAgMCAvdXNy L3NyYy9zeXMva2Vybi9zdWJyX3NsZWVwcXVldWUuYzo2MTggKHNwaW4gbXV0ZXg6c2NoZWQgbG9j ayAyMikKICAgICAyMzUgICAgICAgMjM1ICAgIDE4MzEzMDYxICAgICAgICA0NzU2ICAgICAgMTUw Mjg4ICAgIDEyMSAgICAgIDAgIDAgICAgIDI4IC91c3Ivc3JjL3N5cy9rZXJuL2tlcm5fY2xvY2su YzoyODYgKHNwaW4gbXV0ZXg6c2NoZWQgbG9jayAyMikKICAgICAxNzggICAgIDE5NDUwICAgICAg ICAxMTk1ICAgICAgIDM2NjAyICAgICAgICAgICA5ICAgIDEzMiAgIDQwNjYgIDAgICAgICA4IC91 c3Ivc3JjL3N5cy9rZXJuL3NjaGVkX3VsZS5jOjI1NjkgKHNwaW4gbXV0ZXg6c2NoZWQgbG9jayAy MikKICAgICAxNDcgICAgICAgICAwICAgICAgICAgMjgyICAgICAgICAgICAwICAgICAgICAgICAy ICAgIDE0MSAgICAgIDAgIDAgICAgICAwIC91c3Ivc3JjL3N5cy9rZXJuL2tlcm5fc3dpdGNoLmM6 MTg4IChzcGluIG11dGV4OnNjaGVkIGxvY2sgMjIpCiAgICAgMTMzICAgICAgICAgMCAgICAgICAg IDEzMyAgICAgICAgICAgMCAgICAgICAgICAgMSAgICAxMzMgICAgICAwICAwICAgICAgMCAvdXNy L3NyYy9zeXMva2Vybi9zY2hlZF91bGUuYzoyNjI3IChzcGluIG11dGV4OnNjaGVkIGxvY2sgMjIp CiAgICAgMTkxICAgICAgIDEzMCAgICAgMjQzNTQyOCAgICAgICAgIDEzMCAgICAgICAxOTk4OCAg ICAxMjEgICAgICAwICAwICAgICAgMSAvdXNyL3NyYy9zeXMva2Vybi9rZXJuX2Nsb2NrLmM6NTAz IChzcGluIG11dGV4OnNjaGVkIGxvY2sgMjIpCiAgICAgMTcwICAgICAgICAgMCAgICAgIDE2MzAx MiAgICAgICAgICAgMCAgICAgICAgMTI0NyAgICAxMzAgICAgICAwICAwICAgICAgMCAvdXNyL3Ny Yy9zeXMva2Vybi9zdWJyX3RyYXAuYzoxNjcgKHNwaW4gbXV0ZXg6c2NoZWQgbG9jayAyMikKICAg ICAxOTUgICAgICAgICAwICAgICAgMTY0NTYxICAgICAgICAgICAwICAgICAgICAxMjQ3ICAgIDEz MSAgICAgIDAgIDAgICAgICAwIC91c3Ivc3JjL3N5cy9rZXJuL3N1YnJfdHJhcC5jOjIxMyAoc3Bp biBtdXRleDpzY2hlZCBsb2NrIDIyKQogICAgIDEyNyAgICAgICAgIDAgICAgICAgICAxMjcgICAg ICAgICAgIDAgICAgICAgICAgIDEgICAgMTI3ICAgICAgMCAgMCAgICAgIDAgL3Vzci9zcmMvc3lz L2tlcm4vc3Vicl90dXJuc3RpbGUuYzoyMDMgKHNwaW4gbXV0ZXg6c2NoZWQgbG9jayAyMSkKICAg ICAyNzEgICAgICAgICAwICAgICAgICAgMjcxICAgICAgICAgICAwICAgICAgICAgICAxICAgIDI3 MSAgICAgIDAgIDAgICAgICAwIC91c3Ivc3JjL3N5cy9rZXJuL2tlcm5fdGhyZWFkLmM6NDEwIChz cGluIG11dGV4OnNjaGVkIGxvY2sgMjIpCiAgICAgMjQ3ICAgICAgICAgMCAgICAgICAgIDI0NyAg ICAgICAgICAgMCAgICAgICAgICAgMSAgICAyNDcgICAgICAwICAwICAgICAgMCAvdXNyL3NyYy9z eXMva2Vybi9zY2hlZF91bGUuYzo4MDcgKHNwaW4gbXV0ZXg6c2NoZWQgbG9jayAyMikKICAgICAx MjIgICAgICAgICAwICAgICAgICAgMTIyICAgICAgICAgICAwICAgICAgICAgICAxICAgIDEyMiAg ICAgIDAgIDAgICAgICAwIC91c3Ivc3JjL3N5cy9rZXJuL2tlcm5fdW10eC5jOjMzNjAgKHNwaW4g bXV0ZXg6c2NoZWQgbG9jayAyMikKICAgICAxNDggICAgICAgICAwICAgICAgICAgMTQ4ICAgICAg ICAgICAwICAgICAgICAgICAxICAgIDE0OCAgICAgIDAgIDAgICAgICAwIC91c3Ivc3JjL3N5cy9r ZXJuL3N1YnJfdHVybnN0aWxlLmM6NzI3IChzcGluIG11dGV4OnNjaGVkIGxvY2sgMjIpCiAgICAg NDA1ICAgICAgICAgMCAgICAgICAgIDQwNSAgICAgICAgICAgMCAgICAgICAgICAgMSAgICA0MDUg ICAgICAwICAwICAgICAgMCAvdXNyL3NyYy9zeXMva2Vybi9zdWJyX3R1cm5zdGlsZS5jOjg4OSAo c3BpbiBtdXRleDpzY2hlZCBsb2NrIDIyKQogICAgIDI1MCAgICAgICAgIDAgICAgICAgICAyNTAg ICAgICAgICAgIDAgICAgICAgICAgIDEgICAgMjUwICAgICAgMCAgMCAgICAgIDAgL3Vzci9zcmMv c3lzL2tlcm4vc2NoZWRfdWxlLmM6ODA3IChzcGluIG11dGV4OnNjaGVkIGxvY2sgMjMpCiAgICAg MTI2ICAgICAgICAgMCAgICAgICAgIDEyNiAgICAgICAgICAgMCAgICAgICAgICAgMSAgICAxMjYg ICAgICAwICAwICAgICAgMCAvdXNyL3NyYy9zeXMva2Vybi9rZXJuX3VtdHguYzozMzYwIChzcGlu IG11dGV4OnNjaGVkIGxvY2sgMjMpCiAgICAgMjkxICAgICAgICAgMCAgICAgICAgMjA0NSAgICAg ICAgICAgMCAgICAgICAgICAgOCAgICAyNTUgICAgICAwICAwICAgICAgMCAvdXNyL3NyYy9zeXMv a2Vybi9zY2hlZF91bGUuYzoxODM1IChzcGluIG11dGV4OnNjaGVkIGxvY2sgMjMpCiAgICAgMTYx ICAgICAgICAgMCAgICAgICAgMjAyMiAgICAgICAgICAgMCAgICAgICAgICAxNyAgICAxMTggICAg ICAwICAwICAgICAgMCAvdXNyL3NyYy9zeXMva2Vybi9zY2hlZF91bGUuYzoxODc2IChzcGluIG11 dGV4OnNjaGVkIGxvY2sgMjMpCiAgICAgMTM0ICAgICAgICAgMCAgICAgICAgIDkzNiAgICAgICAg ICAgMCAgICAgICAgICAgOCAgICAxMTcgICAgICAwICAwICAgICAgMCAvdXNyL3NyYy9zeXMva2Vy bi9zdWJyX3NsZWVwcXVldWUuYzozMzUgKHNwaW4gbXV0ZXg6c2NoZWQgbG9jayAyMykKICAgICAx MjggICAgICAgICAwICAgICAgICAgMTI4ICAgICAgICAgICAwICAgICAgICAgICAxICAgIDEyOCAg ICAgIDAgIDAgICAgICAwIC91c3Ivc3JjL3N5cy9rZXJuL3N1YnJfc2xlZXBxdWV1ZS5jOjM5MyAo c3BpbiBtdXRleDpzY2hlZCBsb2NrIDIzKQogICAgIDEzOCAgICAgICAxMzQgICAgICAgICA5MDAg ICAgICAgICA2MTAgICAgICAgICAgIDggICAgMTEyICAgICA3NiAgMCAgICAgIDYgL3Vzci9zcmMv c3lzL2tlcm4vc2NoZWRfdWxlLmM6MjA3NCAoc3BpbiBtdXRleDpzY2hlZCBsb2NrIDIzKQogICAg IDE4MiAgICAgICAgIDAgICAgICAgNjU2NjUgICAgICAgICAgIDAgICAgICAgICA1MDMgICAgMTMw ICAgICAgMCAgMCAgICAgIDAgL3Vzci9zcmMvc3lzL2tlcm4vc2NoZWRfdWxlLmM6MjExMSAoc3Bp biBtdXRleDpzY2hlZCBsb2NrIDIzKQogICAgIDEzOSAgICAgICAgIDAgICAgICAgICA4NzMgICAg ICAgICAgIDAgICAgICAgICAgIDcgICAgMTI0ICAgICAgMCAgMCAgICAgIDAgL3Vzci9zcmMvc3lz L2tlcm4vc3Vicl9zbGVlcHF1ZXVlLmM6NTgzIChzcGluIG11dGV4OnNjaGVkIGxvY2sgMjMpCiAg ICAgMjIxICAgICAgIDIzOSAgICAxODM2MDgzNyAgICAgICAgIDQwMCAgICAgIDE1MDQ4NiAgICAx MjIgICAgICAwICAwICAgICAgMiAvdXNyL3NyYy9zeXMva2Vybi9rZXJuX2Nsb2NrLmM6Mjg2IChz cGluIG11dGV4OnNjaGVkIGxvY2sgMjMpCiAgICAgMjAwICAgICAgICAgMCAgICAgMjQzMjYxNCAg ICAgICAgICAgMCAgICAgICAyMDAxNCAgICAxMjEgICAgICAwICAwICAgICAgMCAvdXNyL3NyYy9z eXMva2Vybi9rZXJuX2Nsb2NrLmM6NTAzIChzcGluIG11dGV4OnNjaGVkIGxvY2sgMjMpCiAgICAg MTY0ICAgICAgICAgMCAgICAgIDE2MzMyMSAgICAgICAgICAgMCAgICAgICAgMTI1MCAgICAxMzAg ICAgICAwICAwICAgICAgMCAvdXNyL3NyYy9zeXMva2Vybi9zdWJyX3RyYXAuYzoxNjcgKHNwaW4g bXV0ZXg6c2NoZWQgbG9jayAyMykKICAgICAxNzggICAgICAgICAwICAgICAgMTY0NzYxICAgICAg ICAgICAwICAgICAgICAxMjUwICAgIDEzMSAgICAgIDAgIDAgICAgICAwIC91c3Ivc3JjL3N5cy9r ZXJuL3N1YnJfdHJhcC5jOjIxMyAoc3BpbiBtdXRleDpzY2hlZCBsb2NrIDIzKQogICAgIDI3NyAg ICAgICAgIDAgICAgICAgICAyNzcgICAgICAgICAgIDAgICAgICAgICAgIDEgICAgMjc3ICAgICAg MCAgMCAgICAgIDAgL3Vzci9zcmMvc3lzL2tlcm4va2Vybl90aHJlYWQuYzo0MTAgKHNwaW4gbXV0 ZXg6c2NoZWQgbG9jayAyMykKICAgICAxNTYgICAgICAgICAwICAgICAgICAgMTU2ICAgICAgICAg ICAwICAgICAgICAgICAxICAgIDE1NiAgICAgIDAgIDAgICAgICAwIC91c3Ivc3JjL3N5cy9rZXJu L2tlcm5fdGhyZWFkLmM6NDEwIChzcGluIG11dGV4OnNjaGVkIGxvY2sgMjQpCiAgICAgMTk3ICAg ICAgICAgMCAgICAgICAgMTI4MCAgICAgICAgICAgMCAgICAgICAgICAgNyAgICAxODIgICAgICAw ICAwICAgICAgMCAvdXNyL3NyYy9zeXMva2Vybi9zdWJyX3R1cm5zdGlsZS5jOjIwMyAoc3BpbiBt dXRleDpzY2hlZCBsb2NrIDI0KQogICAgICA2NyAgICAgICAgIDAgICAgICAgICAgNjcgICAgICAg ICAgIDAgICAgICAgICAgIDEgICAgIDY3ICAgICAgMCAgMCAgICAgIDAgL3Vzci9zcmMvc3lzL2tl cm4va2Vybl91bXR4LmM6MzM2MCAoc3BpbiBtdXRleDpzY2hlZCBsb2NrIDI0KQogICAgIDE1MCAg ICAgICAgIDAgICAgICAgIDExMTIgICAgICAgICAgIDAgICAgICAgICAgIDggICAgMTM5ICAgICAg MCAgMCAgICAgIDAgL3Vzci9zcmMvc3lzL2tlcm4vc3Vicl90dXJuc3RpbGUuYzo3MjcgKHNwaW4g bXV0ZXg6c2NoZWQgbG9jayAyNCkKICAgICA0NDEgICAgICAgICAwICAgICAgICAzMDMzICAgICAg ICAgICAwICAgICAgICAgICA3ICAgIDQzMyAgICAgIDAgIDAgICAgICAwIC91c3Ivc3JjL3N5cy9r ZXJuL3N1YnJfdHVybnN0aWxlLmM6ODg5IChzcGluIG11dGV4OnNjaGVkIGxvY2sgMjQpCiAgICAg MTcwICAgICAgICAgMCAgICAgICAgNjM4MCAgICAgICAgICAgMCAgICAgICAgICA0MyAgICAxNDgg ICAgICAwICAwICAgICAgMCAvdXNyL3NyYy9zeXMva2Vybi9rZXJuX2ludHIuYzoxMjM5IChzcGlu IG11dGV4OnNjaGVkIGxvY2sgMjQpCiAgICAgMzE3ICAgICAgICAgMCAgICAgICAyNjE1MyAgICAg ICAgICAgMCAgICAgICAgICA5NyAgICAyNjkgICAgICAwICAwICAgICAgMCAvdXNyL3NyYy9zeXMv a2Vybi9zY2hlZF91bGUuYzoxODM1IChzcGluIG11dGV4OnNjaGVkIGxvY2sgMjQpCiAgICAgNTkz ICAgICAgICAgMCAgICAgICA0MTM1OCAgICAgICAgICAgMCAgICAgICAgIDI3OSAgICAxNDggICAg ICAwICAwICAgICAgMCAvdXNyL3NyYy9zeXMva2Vybi9zY2hlZF91bGUuYzoxODc2IChzcGluIG11 dGV4OnNjaGVkIGxvY2sgMjQpCiAgICAgMTU2ICAgICAgICAgMCAgICAgICAxMTk3NiAgICAgICAg ICAgMCAgICAgICAgICA4OSAgICAxMzQgICAgICAwICAwICAgICAgMCAvdXNyL3NyYy9zeXMva2Vy bi9zdWJyX3NsZWVwcXVldWUuYzozMzUgKHNwaW4gbXV0ZXg6c2NoZWQgbG9jayAyNCkKICAgICAx NDggICAgICAgICAwICAgICAgICAgMjc1ICAgICAgICAgICAwICAgICAgICAgICAyICAgIDEzNyAg ICAgIDAgIDAgICAgICAwIC91c3Ivc3JjL3N5cy9rZXJuL3N1YnJfc2xlZXBxdWV1ZS5jOjM5MyAo c3BpbiBtdXRleDpzY2hlZCBsb2NrIDI0KQogICAgIDE4MiAgICAgICAyMDYgICAgICAgMTM4MTUg ICAgICAgIDgwOTAgICAgICAgICAgOTYgICAgMTQzICAgICA4NCAgMCAgICAgNjAgL3Vzci9zcmMv c3lzL2tlcm4vc2NoZWRfdWxlLmM6MjA3NCAoc3BpbiBtdXRleDpzY2hlZCBsb2NrIDI0KQogICAg IDE2MSAgICAgICAgIDAgICAgICAgMzEzNzIgICAgICAgICAgIDAgICAgICAgICAyMjYgICAgMTM4 ICAgICAgMCAgMCAgICAgIDAgL3Vzci9zcmMvc3lzL2tlcm4vc2NoZWRfdWxlLmM6MjExMSAoc3Bp biBtdXRleDpzY2hlZCBsb2NrIDI0KQogICAgIDE1OCAgICAgICAgIDAgICAgICAgIDU1MjYgICAg ICAgICAgIDAgICAgICAgICAgNDAgICAgMTM4ICAgICAgMCAgMCAgICAgIDAgL3Vzci9zcmMvc3lz L2tlcm4vc3Vicl9zbGVlcHF1ZXVlLmM6NTgzIChzcGluIG11dGV4OnNjaGVkIGxvY2sgMjQpCiAg ICAgMTUzICAgICAgICAgMCAgICAgICAgNjE2MyAgICAgICAgICAgMCAgICAgICAgICA0NyAgICAx MzEgICAgICAwICAwICAgICAgMCAvdXNyL3NyYy9zeXMva2Vybi9zdWJyX3NsZWVwcXVldWUuYzo2 MTggKHNwaW4gbXV0ZXg6c2NoZWQgbG9jayAyNCkKICAgICAyMjIgICAgICAgMzY3ICAgIDE5NDQ0 NTk2ICAgICAgICA1ODcyICAgICAgMTUwMjIyICAgIDEyOSAgICAgIDAgIDAgICAgIDMyIC91c3Iv c3JjL3N5cy9rZXJuL2tlcm5fY2xvY2suYzoyODYgKHNwaW4gbXV0ZXg6c2NoZWQgbG9jayAyNCkK ICAgICAxNTcgICAgICAgMTM5ICAgICAgICAgMjMzICAgICAgICAgMTM5ICAgICAgICAgICAyICAg IDExNiAgICAgNjkgIDAgICAgICAxIC91c3Ivc3JjL3N5cy9rZXJuL3NjaGVkX3VsZS5jOjI1Njkg KHNwaW4gbXV0ZXg6c2NoZWQgbG9jayAyNCkKICAgICAxNzQgICAgICAgICAwICAgICAgICA5Nzkx ICAgICAgICAgICAwICAgICAgICAgIDY1ICAgIDE1MCAgICAgIDAgIDAgICAgICAwIC91c3Ivc3Jj L3N5cy9rZXJuL2tlcm5fc3dpdGNoLmM6MTg4IChzcGluIG11dGV4OnNjaGVkIGxvY2sgMjQpCiAg ICAgMTk2ICAgICAgIDIwNyAgICAgMjU3ODIzNCAgICAgICAgIDk1OCAgICAgICAxOTk4MCAgICAx MjkgICAgICAwICAwICAgICAgNiAvdXNyL3NyYy9zeXMva2Vybi9rZXJuX2Nsb2NrLmM6NTAzIChz cGluIG11dGV4OnNjaGVkIGxvY2sgMjQpCiAgICAgMTcxICAgICAgICAgMCAgICAgIDE4OTQ2NyAg ICAgICAgICAgMCAgICAgICAgMTQwMyAgICAxMzUgICAgICAwICAwICAgICAgMCAvdXNyL3NyYy9z eXMva2Vybi9zdWJyX3RyYXAuYzoxNjcgKHNwaW4gbXV0ZXg6c2NoZWQgbG9jayAyNCkKICAgICAx ODcgICAgICAgICAwICAgICAgMTk1ODg4ICAgICAgICAgICAwICAgICAgICAxNDAzICAgIDEzOSAg ICAgIDAgIDAgICAgICAwIC91c3Ivc3JjL3N5cy9rZXJuL3N1YnJfdHJhcC5jOjIxMyAoc3BpbiBt dXRleDpzY2hlZCBsb2NrIDI0KQogICAgIDE5NSAgICAgICAgIDAgICAgICAgICAxOTUgICAgICAg ICAgIDAgICAgICAgICAgIDEgICAgMTk1ICAgICAgMCAgMCAgICAgIDAgL3Vzci9zcmMvc3lzL2tl cm4va2Vybl90aHJlYWQuYzo0MTAgKHNwaW4gbXV0ZXg6c2NoZWQgbG9jayAyNSkKICAgICAxMjMg ICAgICAgICAwICAgICAgICAgMTIzICAgICAgICAgICAwICAgICAgICAgICAxICAgIDEyMyAgICAg IDAgIDAgICAgICAwIC91c3Ivc3JjL3N5cy9rZXJuL2tlcm5fdW10eC5jOjMzNjAgKHNwaW4gbXV0 ZXg6c2NoZWQgbG9jayAyNSkKICAgICAyNjUgICAgICAgICAwICAgICAgICAgOTI5ICAgICAgICAg ICAwICAgICAgICAgICA0ICAgIDIzMiAgICAgIDAgIDAgICAgICAwIC91c3Ivc3JjL3N5cy9rZXJu L3NjaGVkX3VsZS5jOjE4MzUgKHNwaW4gbXV0ZXg6c2NoZWQgbG9jayAyNSkKICAgICAzNTIgICAg ICAgICAwICAgICAgICAxMTI5ICAgICAgICAgICAwICAgICAgICAgICA5ICAgIDEyNSAgICAgIDAg IDAgICAgICAwIC91c3Ivc3JjL3N5cy9rZXJuL3NjaGVkX3VsZS5jOjE4NzYgKHNwaW4gbXV0ZXg6 c2NoZWQgbG9jayAyNSkKICAgICAxMDEgICAgICAgICAwICAgICAgICAgMzcwICAgICAgICAgICAw ICAgICAgICAgICA0ICAgICA5MiAgICAgIDAgIDAgICAgICAwIC91c3Ivc3JjL3N5cy9rZXJuL3N1 YnJfc2xlZXBxdWV1ZS5jOjMzNSAoc3BpbiBtdXRleDpzY2hlZCBsb2NrIDI1KQogICAgIDE0MyAg ICAgICAxMjEgICAgICAgICA1MzcgICAgICAgICAyMTUgICAgICAgICAgIDUgICAgMTA3ICAgICA0 MyAgMCAgICAgIDIgL3Vzci9zcmMvc3lzL2tlcm4vc2NoZWRfdWxlLmM6MjA3NCAoc3BpbiBtdXRl eDpzY2hlZCBsb2NrIDI1KQogICAgIDE1NiAgICAgICAgIDAgICAgICAgMzQzNTkgICAgICAgICAg IDAgICAgICAgICAyNTEgICAgMTM2ICAgICAgMCAgMCAgICAgIDAgL3Vzci9zcmMvc3lzL2tlcm4v c2NoZWRfdWxlLmM6MjExMSAoc3BpbiBtdXRleDpzY2hlZCBsb2NrIDI1KQogICAgIDEwMiAgICAg ICAgIDAgICAgICAgICAzMDEgICAgICAgICAgIDAgICAgICAgICAgIDMgICAgMTAwICAgICAgMCAg MCAgICAgIDAgL3Vzci9zcmMvc3lzL2tlcm4vc3Vicl9zbGVlcHF1ZXVlLmM6NTgzIChzcGluIG11 dGV4OnNjaGVkIGxvY2sgMjUpCiAgICAgMTAzICAgICAgICAgMCAgICAgICAgIDEwMyAgICAgICAg ICAgMCAgICAgICAgICAgMSAgICAxMDMgICAgICAwICAwICAgICAgMCAvdXNyL3NyYy9zeXMva2Vy bi9zdWJyX3NsZWVwcXVldWUuYzo2MTggKHNwaW4gbXV0ZXg6c2NoZWQgbG9jayAyNSkKICAgICAy MzUgICAgICAgMTAzICAgIDE5MzQzNTIwICAgICAgICAgMTAzICAgICAgMTUwNDg2ICAgIDEyOCAg ICAgIDAgIDAgICAgICAxIC91c3Ivc3JjL3N5cy9rZXJuL2tlcm5fY2xvY2suYzoyODYgKHNwaW4g bXV0ZXg6c2NoZWQgbG9jayAyNSkKICAgICAxODMgICAgICAgICAwICAgICAyNTg1NjM3ICAgICAg ICAgICAwICAgICAgIDIwMDE1ICAgIDEyOSAgICAgIDAgIDAgICAgICAwIC91c3Ivc3JjL3N5cy9r ZXJuL2tlcm5fY2xvY2suYzo1MDMgKHNwaW4gbXV0ZXg6c2NoZWQgbG9jayAyNSkKICAgICAxNjkg ICAgICAgICAwICAgICAgMTkwOTQ5ICAgICAgICAgICAwICAgICAgICAxNDA3ICAgIDEzNSAgICAg IDAgIDAgICAgICAwIC91c3Ivc3JjL3N5cy9rZXJuL3N1YnJfdHJhcC5jOjE2NyAoc3BpbiBtdXRl eDpzY2hlZCBsb2NrIDI1KQogICAgIDIwMSAgICAgICAgIDAgICAgICAyMDAyNjUgICAgICAgICAg IDAgICAgICAgIDE0MDcgICAgMTQyICAgICAgMCAgMCAgICAgIDAgL3Vzci9zcmMvc3lzL2tlcm4v c3Vicl90cmFwLmM6MjEzIChzcGluIG11dGV4OnNjaGVkIGxvY2sgMjUpCiAgICAgMTY1ICAgICAg IDE0MCAgICAgICAgMjMzOCAgICAgICAgMTMwMCAgICAgICAgICAyMCAgICAxMTYgICAgIDY1ICAw ICAgICAxMiAvdXNyL3NyYy9zeXMva2Vybi9zY2hlZF91bGUuYzoyMDc0IChzcGluIG11dGV4OnNj aGVkIGxvY2sgMjYpCiAgICAgMTU5ICAgICAgICAgMCAgICAgICAzMjQ0MSAgICAgICAgICAgMCAg ICAgICAgIDI1MCAgICAxMjkgICAgICAwICAwICAgICAgMCAvdXNyL3NyYy9zeXMva2Vybi9zY2hl ZF91bGUuYzoyMTExIChzcGluIG11dGV4OnNjaGVkIGxvY2sgMjYpCiAgICAgMTQ0ICAgICAgICAg MCAgICAgICAgMTM1MiAgICAgICAgICAgMCAgICAgICAgICAxMiAgICAxMTIgICAgICAwICAwICAg ICAgMCAvdXNyL3NyYy9zeXMva2Vybi9zdWJyX3NsZWVwcXVldWUuYzo1ODMgKHNwaW4gbXV0ZXg6 c2NoZWQgbG9jayAyNikKICAgICAxNDcgICAgICAgICAwICAgICAgICAxMDgyICAgICAgICAgICAw ICAgICAgICAgICA4ICAgIDEzNSAgICAgIDAgIDAgICAgICAwIC91c3Ivc3JjL3N5cy9rZXJuL3N1 YnJfc2xlZXBxdWV1ZS5jOjYxOCAoc3BpbiBtdXRleDpzY2hlZCBsb2NrIDI2KQogICAgIDIzNiAg ICAgICAyNzYgICAgMTk1NjUxMzEgICAgICAgIDE1NTEgICAgICAxNTA0NjIgICAgMTMwICAgICAg MCAgMCAgICAgIDggL3Vzci9zcmMvc3lzL2tlcm4va2Vybl9jbG9jay5jOjI4NiAoc3BpbiBtdXRl eDpzY2hlZCBsb2NrIDI2KQogICAgIDE2NiAgICAgOTQ4MDYgICAgICAgICAyNDYgICAgICAgOTQ5 NDkgICAgICAgICAgIDIgICAgMTIzICA0NzQ3NCAgMCAgICAgIDIgL3Vzci9zcmMvc3lzL2tlcm4v c2NoZWRfdWxlLmM6MjU2OSAoc3BpbiBtdXRleDpzY2hlZCBsb2NrIDI2KQogICAgIDEzMCAgICAg ICAgIDAgICAgICAgICAxMzAgICAgICAgICAgIDAgICAgICAgICAgIDEgICAgMTMwICAgICAgMCAg MCAgICAgIDAgL3Vzci9zcmMvc3lzL2tlcm4va2Vybl9zd2l0Y2guYzoxODggKHNwaW4gbXV0ZXg6 c2NoZWQgbG9jayAyNikKICAgICAxOTMgICAgICAgICAwICAgICAyNjA1Njg3ICAgICAgICAgICAw ICAgICAgIDIwMDEyICAgIDEzMCAgICAgIDAgIDAgICAgICAwIC91c3Ivc3JjL3N5cy9rZXJuL2tl cm5fY2xvY2suYzo1MDMgKHNwaW4gbXV0ZXg6c2NoZWQgbG9jayAyNikKICAgICAxNzIgICAgICAg ICAwICAgICAgMTkxMzM4ICAgICAgICAgICAwICAgICAgICAxNDA1ICAgIDEzNiAgICAgIDAgIDAg ICAgICAwIC91c3Ivc3JjL3N5cy9rZXJuL3N1YnJfdHJhcC5jOjE2NyAoc3BpbiBtdXRleDpzY2hl ZCBsb2NrIDI2KQogICAgIDE5NCAgICAgICAgIDAgICAgICAyMDIxNzIgICAgICAgICAgIDAgICAg ICAgIDE0MDUgICAgMTQzICAgICAgMCAgMCAgICAgIDAgL3Vzci9zcmMvc3lzL2tlcm4vc3Vicl90 cmFwLmM6MjEzIChzcGluIG11dGV4OnNjaGVkIGxvY2sgMjYpCiAgICAgMTgwICAgICAgICAgMCAg ICAgICAgIDE4MCAgICAgICAgICAgMCAgICAgICAgICAgMSAgICAxODAgICAgICAwICAwICAgICAg MCAvdXNyL3NyYy9zeXMva2Vybi9rZXJuX3RocmVhZC5jOjQxMCAoc3BpbiBtdXRleDpzY2hlZCBs b2NrIDI2KQogICAgIDI4NiAgICAgICAgIDAgICAgICAgICAyODYgICAgICAgICAgIDAgICAgICAg ICAgIDEgICAgMjg2ICAgICAgMCAgMCAgICAgIDAgL3Vzci9zcmMvc3lzL2tlcm4vc2NoZWRfdWxl LmM6ODA3IChzcGluIG11dGV4OnNjaGVkIGxvY2sgMjYpCiAgICAgIDk4ICAgICAgICAgMCAgICAg ICAgICA5OCAgICAgICAgICAgMCAgICAgICAgICAgMSAgICAgOTggICAgICAwICAwICAgICAgMCAv dXNyL3NyYy9zeXMva2Vybi9rZXJuX3VtdHguYzozMzYwIChzcGluIG11dGV4OnNjaGVkIGxvY2sg MjYpCiAgICAgMTM0ICAgICAgICAgMCAgICAgICAgIDEzNCAgICAgICAgICAgMCAgICAgICAgICAg MSAgICAxMzQgICAgICAwICAwICAgICAgMCAvdXNyL3NyYy9zeXMva2Vybi9zdWJyX3R1cm5zdGls ZS5jOjIwMyAoc3BpbiBtdXRleDpzY2hlZCBsb2NrIDIyKQogICAgIDE0NCAgICAgICAgIDAgICAg ICAgICAxOTkgICAgICAgICAgIDAgICAgICAgICAgIDIgICAgIDk5ICAgICAgMCAgMCAgICAgIDAg L3Vzci9zcmMvc3lzL2tlcm4vc3Vicl90dXJuc3RpbGUuYzo3MjcgKHNwaW4gbXV0ZXg6c2NoZWQg bG9jayAyNikKICAgICAxNTMgICAgICAgICAwICAgICAgICAgMzU5ICAgICAgICAgICAwICAgICAg ICAgICA0ICAgICA4OSAgICAgIDAgIDAgICAgICAwIC91c3Ivc3JjL3N5cy9rZXJuL2tlcm5faW50 ci5jOjEyMzkgKHNwaW4gbXV0ZXg6c2NoZWQgbG9jayAyNikKICAgICAyODYgICAgICAgICAwICAg ICAgICA1MjM3ICAgICAgICAgICAwICAgICAgICAgIDIyICAgIDIzOCAgICAgIDAgIDAgICAgICAw IC91c3Ivc3JjL3N5cy9rZXJuL3NjaGVkX3VsZS5jOjE4MzUgKHNwaW4gbXV0ZXg6c2NoZWQgbG9j ayAyNikKICAgICA0MTEgICAgICAgICAwICAgICAgICA3MDUyICAgICAgICAgICAwICAgICAgICAg IDQ5ICAgIDE0MyAgICAgIDAgIDAgICAgICAwIC91c3Ivc3JjL3N5cy9rZXJuL3NjaGVkX3VsZS5j OjE4NzYgKHNwaW4gbXV0ZXg6c2NoZWQgbG9jayAyNikKICAgICAxNTMgICAgICAgICAwICAgICAg ICAyNDE5ICAgICAgICAgICAwICAgICAgICAgIDIwICAgIDEyMCAgICAgIDAgIDAgICAgICAwIC91 c3Ivc3JjL3N5cy9rZXJuL3N1YnJfc2xlZXBxdWV1ZS5jOjMzNSAoc3BpbiBtdXRleDpzY2hlZCBs b2NrIDI2KQogICAgIDE1NiAgICAgICAgIDAgICAgICAgICAxNTYgICAgICAgICAgIDAgICAgICAg ICAgIDEgICAgMTU2ICAgICAgMCAgMCAgICAgIDAgL3Vzci9zcmMvc3lzL2tlcm4vc3Vicl90dXJu c3RpbGUuYzo3MjcgKHNwaW4gbXV0ZXg6c2NoZWQgbG9jayAyNykKICAgICAyODkgICAgICAgICAw ICAgICAgICAxODQ4ICAgICAgICAgICAwICAgICAgICAgICA4ICAgIDIzMSAgICAgIDAgIDAgICAg ICAwIC91c3Ivc3JjL3N5cy9rZXJuL3NjaGVkX3VsZS5jOjE4MzUgKHNwaW4gbXV0ZXg6c2NoZWQg bG9jayAyNykKICAgICAxNTcgICAgICAgICAwICAgICAgICAyMDI3ICAgICAgICAgICAwICAgICAg ICAgIDE4ICAgIDExMiAgICAgIDAgIDAgICAgICAwIC91c3Ivc3JjL3N5cy9rZXJuL3NjaGVkX3Vs ZS5jOjE4NzYgKHNwaW4gbXV0ZXg6c2NoZWQgbG9jayAyNykKICAgICAxNDcgICAgICAgICAwICAg ICAgICAgODY3ICAgICAgICAgICAwICAgICAgICAgICA3ICAgIDEyMyAgICAgIDAgIDAgICAgICAw IC91c3Ivc3JjL3N5cy9rZXJuL3N1YnJfc2xlZXBxdWV1ZS5jOjMzNSAoc3BpbiBtdXRleDpzY2hl ZCBsb2NrIDI3KQogICAgIDE2OCAgICAgICAxMjcgICAgICAgIDExNjggICAgICAgICA2ODUgICAg ICAgICAgMTAgICAgMTE2ICAgICA2OCAgMCAgICAgIDcgL3Vzci9zcmMvc3lzL2tlcm4vc2NoZWRf dWxlLmM6MjA3NCAoc3BpbiBtdXRleDpzY2hlZCBsb2NrIDI3KQogICAgIDE2MSAgICAgICAgIDAg ICAgICAgNDIyMzYgICAgICAgICAgIDAgICAgICAgICAzMjIgICAgMTMxICAgICAgMCAgMCAgICAg IDAgL3Vzci9zcmMvc3lzL2tlcm4vc2NoZWRfdWxlLmM6MjExMSAoc3BpbiBtdXRleDpzY2hlZCBs b2NrIDI3KQogICAgIDEyMiAgICAgICAgIDAgICAgICAgICA3ODcgICAgICAgICAgIDAgICAgICAg ICAgIDcgICAgMTEyICAgICAgMCAgMCAgICAgIDAgL3Vzci9zcmMvc3lzL2tlcm4vc3Vicl9zbGVl cHF1ZXVlLmM6NTgzIChzcGluIG11dGV4OnNjaGVkIGxvY2sgMjcpCiAgICAgMjM1ICAgICAgIDIw OSAgICAxOTU2NTE1MSAgICAgICAgIDIwOSAgICAgIDE1MDQ4MSAgICAxMzAgICAgICAwICAwICAg ICAgMSAvdXNyL3NyYy9zeXMva2Vybi9rZXJuX2Nsb2NrLmM6Mjg2IChzcGluIG11dGV4OnNjaGVk IGxvY2sgMjcpCiAgICAgMTkxICAgICAgICA5NyAgICAgMjYwMTA1OSAgICAgICAgICA5NyAgICAg ICAyMDAxNCAgICAxMjkgICAgICAwICAwICAgICAgMSAvdXNyL3NyYy9zeXMva2Vybi9rZXJuX2Ns b2NrLmM6NTAzIChzcGluIG11dGV4OnNjaGVkIGxvY2sgMjcpCiAgICAgMTc5ICAgICAgICAgMCAg ICAgIDE5MTU1MyAgICAgICAgICAgMCAgICAgICAgMTQwOSAgICAxMzUgICAgICAwICAwICAgICAg MCAvdXNyL3NyYy9zeXMva2Vybi9zdWJyX3RyYXAuYzoxNjcgKHNwaW4gbXV0ZXg6c2NoZWQgbG9j ayAyNykKICAgICAyMDQgICAgICAgICAwICAgICAgMjAyODAzICAgICAgICAgICAwICAgICAgICAx NDA5ICAgIDE0MyAgICAgIDAgIDAgICAgICAwIC91c3Ivc3JjL3N5cy9rZXJuL3N1YnJfdHJhcC5j OjIxMyAoc3BpbiBtdXRleDpzY2hlZCBsb2NrIDI3KQogICAgIDIxOSAgICAgICAgIDAgICAgICAg ICAyMTkgICAgICAgICAgIDAgICAgICAgICAgIDEgICAgMjE5ICAgICAgMCAgMCAgICAgIDAgL3Vz ci9zcmMvc3lzL2tlcm4va2Vybl90aHJlYWQuYzo0MTAgKHNwaW4gbXV0ZXg6c2NoZWQgbG9jayAy NykKICAgICAxMTYgICAgICAgICAwICAgICAgICAgMTE2ICAgICAgICAgICAwICAgICAgICAgICAx ICAgIDExNiAgICAgIDAgIDAgICAgICAwIC91c3Ivc3JjL3N5cy9rZXJuL2tlcm5fdW10eC5jOjMz NjAgKHNwaW4gbXV0ZXg6c2NoZWQgbG9jayAyNykKICAgICAgNTYgICAgICAgICAwICAgICAgICAg IDU2ICAgICAgICAgICAwICAgICAgICAgICAxICAgICA1NiAgICAgIDAgIDAgICAgICAwIC91c3Iv c3JjL3N5cy9rZXJuL2tlcm5fdW10eC5jOjMzNjAgKHNwaW4gbXV0ZXg6c2NoZWQgbG9jayAyOCkK ICAgICA0NjAgICAgICAgICAwICAgICAgICAgOTE5ICAgICAgICAgICAwICAgICAgICAgICAyICAg IDQ1OSAgICAgIDAgIDAgICAgICAwIC91c3Ivc3JjL3N5cy9rZXJuL3N1YnJfdHVybnN0aWxlLmM6 ODg5IChzcGluIG11dGV4OnNjaGVkIGxvY2sgMjgpCiAgICAgMTY3ICAgICAgICAgMCAgICAgICAg MTE5MCAgICAgICAgICAgMCAgICAgICAgICAgOCAgICAxNDggICAgICAwICAwICAgICAgMCAvdXNy L3NyYy9zeXMva2Vybi9rZXJuX2ludHIuYzoxMjM5IChzcGluIG11dGV4OnNjaGVkIGxvY2sgMjgp CiAgICAgMjk5ICAgICAgICAgMCAgICAgICAgNjk5MSAgICAgICAgICAgMCAgICAgICAgICA0MyAg ICAxNjIgICAgICAwICAwICAgICAgMCAvdXNyL3NyYy9zeXMva2Vybi9zY2hlZF91bGUuYzoxODM1 IChzcGluIG11dGV4OnNjaGVkIGxvY2sgMjgpCiAgICAgNDg2ICAgICAgICAgMCAgICAgICAgOTQ3 NCAgICAgICAgICAgMCAgICAgICAgIDEwMSAgICAgOTMgICAgICAwICAwICAgICAgMCAvdXNyL3Ny Yy9zeXMva2Vybi9zY2hlZF91bGUuYzoxODc2IChzcGluIG11dGV4OnNjaGVkIGxvY2sgMjgpCiAg ICAgMTU0ICAgICAgICAgMCAgICAgICAgMzU2MyAgICAgICAgICAgMCAgICAgICAgICA0MyAgICAg ODIgICAgICAwICAwICAgICAgMCAvdXNyL3NyYy9zeXMva2Vybi9zdWJyX3NsZWVwcXVldWUuYzoz MzUgKHNwaW4gbXV0ZXg6c2NoZWQgbG9jayAyOCkKICAgICAxNzkgICAgICAgMTU4ICAgICAgICAz ODkyICAgICAgICAyMzIyICAgICAgICAgIDQ0ICAgICA4OCAgICAgNTIgIDAgICAgIDMzIC91c3Iv c3JjL3N5cy9rZXJuL3NjaGVkX3VsZS5jOjIwNzQgKHNwaW4gbXV0ZXg6c2NoZWQgbG9jayAyOCkK ICAgICAxODAgICAgICAgICAwICAgICAgIDYwMDg2ICAgICAgICAgICAwICAgICAgICAgNDU0ICAg IDEzMiAgICAgIDAgIDAgICAgICAwIC91c3Ivc3JjL3N5cy9rZXJuL3NjaGVkX3VsZS5jOjIxMTEg KHNwaW4gbXV0ZXg6c2NoZWQgbG9jayAyOCkKICAgICAyNDMgICAgICAgICAwICAgICAgICAyOTU5 ICAgICAgICAgICAwICAgICAgICAgIDM3ICAgICA3OSAgICAgIDAgIDAgICAgICAwIC91c3Ivc3Jj L3N5cy9rZXJuL3N1YnJfc2xlZXBxdWV1ZS5jOjU4MyAoc3BpbiBtdXRleDpzY2hlZCBsb2NrIDI4 KQogICAgIDE0OSAgICAgICAgIDAgICAgICAgICA4NTIgICAgICAgICAgIDAgICAgICAgICAgIDYg ICAgMTQyICAgICAgMCAgMCAgICAgIDAgL3Vzci9zcmMvc3lzL2tlcm4vc3Vicl9zbGVlcHF1ZXVl LmM6NjE4IChzcGluIG11dGV4OnNjaGVkIGxvY2sgMjgpCiAgICAgMjA0ICAgICAgIDI1NyAgICAx OTQ0MTE0MiAgICAgICAgIDY1NiAgICAgIDE1MDQ0OCAgICAxMjkgICAgICAwICAwICAgICAgNCAv dXNyL3NyYy9zeXMva2Vybi9rZXJuX2Nsb2NrLmM6Mjg2IChzcGluIG11dGV4OnNjaGVkIGxvY2sg MjgpCiAgICAgIDQzICAgICAgICA0MCAgICAgICAgICA3NiAgICAgICAgICA0MCAgICAgICAgICAg MiAgICAgMzggICAgIDIwICAwICAgICAgMSAvdXNyL3NyYy9zeXMva2Vybi9zY2hlZF91bGUuYzoy NTY5IChzcGluIG11dGV4OnNjaGVkIGxvY2sgMjgpCiAgICAgMTc1ICAgICAgICAgMCAgICAgICAg MjA1MSAgICAgICAgICAgMCAgICAgICAgICAxMyAgICAxNTcgICAgICAwICAwICAgICAgMCAvdXNy L3NyYy9zeXMva2Vybi9rZXJuX3N3aXRjaC5jOjE4OCAoc3BpbiBtdXRleDpzY2hlZCBsb2NrIDI4 KQogICAgIDE0MSAgICAgICAgIDAgICAgICAgICAxNDEgICAgICAgICAgIDAgICAgICAgICAgIDEg ICAgMTQxICAgICAgMCAgMCAgICAgIDAgL3Vzci9zcmMvc3lzL2tlcm4vc2NoZWRfdWxlLmM6MjYy NyAoc3BpbiBtdXRleDpzY2hlZCBsb2NrIDI4KQogICAgIDIwMSAgICAgICAgIDAgICAgIDI2MTM3 MTQgICAgICAgICAgIDAgICAgICAgMjAwMTAgICAgMTMwICAgICAgMCAgMCAgICAgIDAgL3Vzci9z cmMvc3lzL2tlcm4va2Vybl9jbG9jay5jOjUwMyAoc3BpbiBtdXRleDpzY2hlZCBsb2NrIDI4KQog ICAgIDE2MyAgICAgICAgIDAgICAgICAxOTEyMzggICAgICAgICAgIDAgICAgICAgIDE0MTQgICAg MTM1ICAgICAgMCAgMCAgICAgIDAgL3Vzci9zcmMvc3lzL2tlcm4vc3Vicl90cmFwLmM6MTY3IChz cGluIG11dGV4OnNjaGVkIGxvY2sgMjgpCiAgICAgMTk1ICAgICAgICAgMCAgICAgIDE5ODg0NyAg ICAgICAgICAgMCAgICAgICAgMTQxNCAgICAxNDAgICAgICAwICAwICAgICAgMCAvdXNyL3NyYy9z eXMva2Vybi9zdWJyX3RyYXAuYzoyMTMgKHNwaW4gbXV0ZXg6c2NoZWQgbG9jayAyOCkKICAgICAy MjAgICAgICAgICAwICAgICAgICAgMjIwICAgICAgICAgICAwICAgICAgICAgICAxICAgIDIyMCAg ICAgIDAgIDAgICAgICAwIC91c3Ivc3JjL3N5cy9rZXJuL2tlcm5fdGhyZWFkLmM6NDEwIChzcGlu IG11dGV4OnNjaGVkIGxvY2sgMjgpCiAgICAgMjA4ICAgICAgICAgMCAgICAgICAgIDIwOCAgICAg ICAgICAgMCAgICAgICAgICAgMSAgICAyMDggICAgICAwICAwICAgICAgMCAvdXNyL3NyYy9zeXMv a2Vybi9rZXJuX3RocmVhZC5jOjQxMCAoc3BpbiBtdXRleDpzY2hlZCBsb2NrIDI5KQogICAgIDEw OCAgICAgICAgIDAgICAgICAgICAxMDggICAgICAgICAgIDAgICAgICAgICAgIDEgICAgMTA4ICAg ICAgMCAgMCAgICAgIDAgL3Vzci9zcmMvc3lzL2tlcm4va2Vybl91bXR4LmM6MzM2MCAoc3BpbiBt dXRleDpzY2hlZCBsb2NrIDI5KQogICAgICA2NiAgICAgICAgIDAgICAgICAgICAgNjYgICAgICAg ICAgIDAgICAgICAgICAgIDEgICAgIDY2ICAgICAgMCAgMCAgICAgIDAgL3Vzci9zcmMvc3lzL2tl cm4vc3Vicl90dXJuc3RpbGUuYzo3MjcgKHNwaW4gbXV0ZXg6c2NoZWQgbG9jayAyOSkKICAgICAx NDEgICAgICAgICAwICAgICAgICAgMzc2ICAgICAgICAgICAwICAgICAgICAgICAzICAgIDEyNSAg ICAgIDAgIDAgICAgICAwIC91c3Ivc3JjL3N5cy9rZXJuL2tlcm5faW50ci5jOjEyMzkgKHNwaW4g bXV0ZXg6c2NoZWQgbG9jayAyOSkKICAgICAyODcgICAgICAgICAwICAgICAgICAyMTc5ICAgICAg ICAgICAwICAgICAgICAgIDEwICAgIDIxNyAgICAgIDAgIDAgICAgICAwIC91c3Ivc3JjL3N5cy9r ZXJuL3NjaGVkX3VsZS5jOjE4MzUgKHNwaW4gbXV0ZXg6c2NoZWQgbG9jayAyOSkKICAgICAzMTAg ICAgICAgICAwICAgICAgICAzMjA5ICAgICAgICAgICAwICAgICAgICAgIDI2ICAgIDEyMyAgICAg IDAgIDAgICAgICAwIC91c3Ivc3JjL3N5cy9rZXJuL3NjaGVkX3VsZS5jOjE4NzYgKHNwaW4gbXV0 ZXg6c2NoZWQgbG9jayAyOSkKICAgICAxMzEgICAgICAgICAwICAgICAgICAgOTgwICAgICAgICAg ICAwICAgICAgICAgICA5ICAgIDEwOCAgICAgIDAgIDAgICAgICAwIC91c3Ivc3JjL3N5cy9rZXJu L3N1YnJfc2xlZXBxdWV1ZS5jOjMzNSAoc3BpbiBtdXRleDpzY2hlZCBsb2NrIDI5KQogICAgIDE1 MyAgICAgICAxNDggICAgICAgIDE1MTEgICAgICAgICA4MzYgICAgICAgICAgMTMgICAgMTE2ICAg ICA2NCAgMCAgICAgIDggL3Vzci9zcmMvc3lzL2tlcm4vc2NoZWRfdWxlLmM6MjA3NCAoc3BpbiBt dXRleDpzY2hlZCBsb2NrIDI5KQogICAgIDE4MSAgICAgICAgIDAgICAgICAgNTMyMDQgICAgICAg ICAgIDAgICAgICAgICAzODYgICAgMTM3ICAgICAgMCAgMCAgICAgIDAgL3Vzci9zcmMvc3lzL2tl cm4vc2NoZWRfdWxlLmM6MjExMSAoc3BpbiBtdXRleDpzY2hlZCBsb2NrIDI5KQogICAgIDEzMSAg ICAgICAgIDAgICAgICAgICA4ODggICAgICAgICAgIDAgICAgICAgICAgIDggICAgMTExICAgICAg MCAgMCAgICAgIDAgL3Vzci9zcmMvc3lzL2tlcm4vc3Vicl9zbGVlcHF1ZXVlLmM6NTgzIChzcGlu IG11dGV4OnNjaGVkIGxvY2sgMjkpCiAgICAgMTIyICAgICAgICAgMCAgICAgICAgIDEyMiAgICAg ICAgICAgMCAgICAgICAgICAgMSAgICAxMjIgICAgICAwICAwICAgICAgMCAvdXNyL3NyYy9zeXMv a2Vybi9zdWJyX3NsZWVwcXVldWUuYzo2MTggKHNwaW4gbXV0ZXg6c2NoZWQgbG9jayAyOSkKICAg ICAyMzEgICAgICAgMjI4ICAgIDE5MzgwMTgxICAgICAgICAgODA5ICAgICAgMTUwNDgwICAgIDEy OCAgICAgIDAgIDAgICAgICA1IC91c3Ivc3JjL3N5cy9rZXJuL2tlcm5fY2xvY2suYzoyODYgKHNw aW4gbXV0ZXg6c2NoZWQgbG9jayAyOSkKICAgICAxMjUgICAgICAgICAwICAgICAgICAgMTI1ICAg ICAgICAgICAwICAgICAgICAgICAxICAgIDEyNSAgICAgIDAgIDAgICAgICAwIC91c3Ivc3JjL3N5 cy9rZXJuL3NjaGVkX3VsZS5jOjI2MjcgKHNwaW4gbXV0ZXg6c2NoZWQgbG9jayAyOSkKICAgICAx OTMgICAgICAgICAwICAgICAyNTk2ODM5ICAgICAgICAgICAwICAgICAgIDIwMDEzICAgIDEyOSAg ICAgIDAgIDAgICAgICAwIC91c3Ivc3JjL3N5cy9rZXJuL2tlcm5fY2xvY2suYzo1MDMgKHNwaW4g bXV0ZXg6c2NoZWQgbG9jayAyOSkKICAgICAxNjkgICAgICAgICAwICAgICAgMTkyMDM3ICAgICAg ICAgICAwICAgICAgICAxNDEzICAgIDEzNSAgICAgIDAgIDAgICAgICAwIC91c3Ivc3JjL3N5cy9r ZXJuL3N1YnJfdHJhcC5jOjE2NyAoc3BpbiBtdXRleDpzY2hlZCBsb2NrIDI5KQogICAgIDE4NiAg ICAgICAgIDAgICAgICAyMDE4NTMgICAgICAgICAgIDAgICAgICAgIDE0MTMgICAgMTQyICAgICAg MCAgMCAgICAgIDAgL3Vzci9zcmMvc3lzL2tlcm4vc3Vicl90cmFwLmM6MjEzIChzcGluIG11dGV4 OnNjaGVkIGxvY2sgMjkpCiAgICAgMjAxICAgICAgIDE2NyAgICAgMjU5OTg4NSAgICAgICAgIDgx NiAgICAgICAyMDAxMCAgICAxMjkgICAgICAwICAwICAgICAgNiAvdXNyL3NyYy9zeXMva2Vybi9r ZXJuX2Nsb2NrLmM6NTAzIChzcGluIG11dGV4OnNjaGVkIGxvY2sgMzApCiAgICAgMTc2ICAgICAg ICAgMCAgICAgIDE5MTc3NCAgICAgICAgICAgMCAgICAgICAgMTQxMSAgICAxMzUgICAgICAwICAw ICAgICAgMCAvdXNyL3NyYy9zeXMva2Vybi9zdWJyX3RyYXAuYzoxNjcgKHNwaW4gbXV0ZXg6c2No ZWQgbG9jayAzMCkKICAgICAxOTcgICAgICAgICAwICAgICAgMjAzODU5ICAgICAgICAgICAwICAg ICAgICAxNDExICAgIDE0NCAgICAgIDAgIDAgICAgICAwIC91c3Ivc3JjL3N5cy9rZXJuL3N1YnJf dHJhcC5jOjIxMyAoc3BpbiBtdXRleDpzY2hlZCBsb2NrIDMwKQogICAgIDE5NSAgICAgICAgIDAg ICAgICAgICAxOTUgICAgICAgICAgIDAgICAgICAgICAgIDEgICAgMTk1ICAgICAgMCAgMCAgICAg IDAgL3Vzci9zcmMvc3lzL2tlcm4va2Vybl90aHJlYWQuYzo0MTAgKHNwaW4gbXV0ZXg6c2NoZWQg bG9jayAzMCkKICAgICAgNTggICAgICAgICAwICAgICAgICAgIDU4ICAgICAgICAgICAwICAgICAg ICAgICAxICAgICA1OCAgICAgIDAgIDAgICAgICAwIC91c3Ivc3JjL3N5cy9rZXJuL2tlcm5fdW10 eC5jOjMzNjAgKHNwaW4gbXV0ZXg6c2NoZWQgbG9jayAzMCkKICAgICAxNjUgICAgICAgICAwICAg ICAgICAgODIzICAgICAgICAgICAwICAgICAgICAgICA2ICAgIDEzNyAgICAgIDAgIDAgICAgICAw IC91c3Ivc3JjL3N5cy9rZXJuL2tlcm5faW50ci5jOjEyMzkgKHNwaW4gbXV0ZXg6c2NoZWQgbG9j ayAzMCkKICAgICAyOTcgICAgICAgICAwICAgICAgICA0NTk4ICAgICAgICAgICAwICAgICAgICAg IDE4ICAgIDI1NSAgICAgIDAgIDAgICAgICAwIC91c3Ivc3JjL3N5cy9rZXJuL3NjaGVkX3VsZS5j OjE4MzUgKHNwaW4gbXV0ZXg6c2NoZWQgbG9jayAzMCkKICAgICA2NTcgICAgICAgICAwICAgICAg ICA3MTM4ICAgICAgICAgICAwICAgICAgICAgIDQ0ICAgIDE2MiAgICAgIDAgIDAgICAgICAwIC91 c3Ivc3JjL3N5cy9rZXJuL3NjaGVkX3VsZS5jOjE4NzYgKHNwaW4gbXV0ZXg6c2NoZWQgbG9jayAz MCkKICAgICAxNTMgICAgICAgMTM0ICAgICAgICAyMzQ4ICAgICAgICAgMTM0ICAgICAgICAgIDE4 ICAgIDEzMCAgICAgIDcgIDAgICAgICAxIC91c3Ivc3JjL3N5cy9rZXJuL3N1YnJfc2xlZXBxdWV1 ZS5jOjMzNSAoc3BpbiBtdXRleDpzY2hlZCBsb2NrIDMwKQogICAgIDE3OCAgICAgICAzMzkgICAg ICAgIDI1NzYgICAgICAgIDE3OTkgICAgICAgICAgMTkgICAgMTM1ICAgICA5NCAgMCAgICAgMTMg L3Vzci9zcmMvc3lzL2tlcm4vc2NoZWRfdWxlLmM6MjA3NCAoc3BpbiBtdXRleDpzY2hlZCBsb2Nr IDMwKQogICAgIDE3NyAgICAgICAgIDAgICAgICAgNTQ3NTggICAgICAgICAgIDAgICAgICAgICAz OTggICAgMTM3ICAgICAgMCAgMCAgICAgIDAgL3Vzci9zcmMvc3lzL2tlcm4vc2NoZWRfdWxlLmM6 MjExMSAoc3BpbiBtdXRleDpzY2hlZCBsb2NrIDMwKQogICAgIDE1OSAgICAgICAgIDAgICAgICAg IDE2NjMgICAgICAgICAgIDAgICAgICAgICAgMTMgICAgMTI3ICAgICAgMCAgMCAgICAgIDAgL3Vz ci9zcmMvc3lzL2tlcm4vc3Vicl9zbGVlcHF1ZXVlLmM6NTgzIChzcGluIG11dGV4OnNjaGVkIGxv Y2sgMzApCiAgICAgMTQyICAgICAgICAgMCAgICAgICAgIDY4MCAgICAgICAgICAgMCAgICAgICAg ICAgNSAgICAxMzYgICAgICAwICAwICAgICAgMCAvdXNyL3NyYy9zeXMva2Vybi9zdWJyX3NsZWVw cXVldWUuYzo2MTggKHNwaW4gbXV0ZXg6c2NoZWQgbG9jayAzMCkKICAgICAyMjcgICAgICAgMjYy ICAgIDE5NDkxNTY4ICAgICAgICAxNDA2ICAgICAgMTUwNDU0ICAgIDEyOSAgICAgIDAgIDAgICAg ICA4IC91c3Ivc3JjL3N5cy9rZXJuL2tlcm5fY2xvY2suYzoyODYgKHNwaW4gbXV0ZXg6c2NoZWQg bG9jayAzMCkKICAgICAyOTAgICAgICAgICAwICAgICAgICAyOTg2ICAgICAgICAgICAwICAgICAg ICAgIDEyICAgIDI0OCAgICAgIDAgIDAgICAgICAwIC91c3Ivc3JjL3N5cy9rZXJuL3NjaGVkX3Vs ZS5jOjE4MzUgKHNwaW4gbXV0ZXg6c2NoZWQgbG9jayAzMSkKICAgICAxNjMgICAgICAgICAwICAg ICAgICAzNzI5ICAgICAgICAgICAwICAgICAgICAgIDMwICAgIDEyNCAgICAgIDAgIDAgICAgICAw IC91c3Ivc3JjL3N5cy9rZXJuL3NjaGVkX3VsZS5jOjE4NzYgKHNwaW4gbXV0ZXg6c2NoZWQgbG9j ayAzMSkKICAgICAxMzcgICAgICAgICAwICAgICAgICAxMzY1ICAgICAgICAgICAwICAgICAgICAg IDExICAgIDEyNCAgICAgIDAgIDAgICAgICAwIC91c3Ivc3JjL3N5cy9rZXJuL3N1YnJfc2xlZXBx dWV1ZS5jOjMzNSAoc3BpbiBtdXRleDpzY2hlZCBsb2NrIDMxKQogICAgIDE2MyAgICAgICAxNDcg ICAgICAgIDE3NjcgICAgICAgIDExNjMgICAgICAgICAgMTQgICAgMTI2ICAgICA4MyAgMCAgICAg MTAgL3Vzci9zcmMvc3lzL2tlcm4vc2NoZWRfdWxlLmM6MjA3NCAoc3BpbiBtdXRleDpzY2hlZCBs b2NrIDMxKQogICAgIDE3MyAgICAgICAgIDAgICAgICAgNDIwNjYgICAgICAgICAgIDAgICAgICAg ICAzMDYgICAgMTM3ICAgICAgMCAgMCAgICAgIDAgL3Vzci9zcmMvc3lzL2tlcm4vc2NoZWRfdWxl LmM6MjExMSAoc3BpbiBtdXRleDpzY2hlZCBsb2NrIDMxKQogICAgIDE1NyAgICAgICAgIDAgICAg ICAgIDE0MTggICAgICAgICAgIDAgICAgICAgICAgMTEgICAgMTI4ICAgICAgMCAgMCAgICAgIDAg L3Vzci9zcmMvc3lzL2tlcm4vc3Vicl9zbGVlcHF1ZXVlLmM6NTgzIChzcGluIG11dGV4OnNjaGVk IGxvY2sgMzEpCiAgICAgMjQwICAgICAgIDI3MCAgICAxOTUwNjI2NSAgICAgICAgIDk5MyAgICAg IDE1MDQ3OSAgICAxMjkgICAgICAwICAwICAgICAgNSAvdXNyL3NyYy9zeXMva2Vybi9rZXJuX2Ns b2NrLmM6Mjg2IChzcGluIG11dGV4OnNjaGVkIGxvY2sgMzEpCiAgICAgMTg4ICAgICAgIDE3MSAg ICAgMjU5NzYxMyAgICAgICAgIDE3MSAgICAgICAyMDAxNCAgICAxMjkgICAgICAwICAwICAgICAg MSAvdXNyL3NyYy9zeXMva2Vybi9rZXJuX2Nsb2NrLmM6NTAzIChzcGluIG11dGV4OnNjaGVkIGxv Y2sgMzEpCiAgICAgMTY4ICAgICAgICAgMCAgICAgIDE5MTQ0MyAgICAgICAgICAgMCAgICAgICAg MTQwOSAgICAxMzUgICAgICAwICAwICAgICAgMCAvdXNyL3NyYy9zeXMva2Vybi9zdWJyX3RyYXAu YzoxNjcgKHNwaW4gbXV0ZXg6c2NoZWQgbG9jayAzMSkKICAgICAxOTkgICAgICAgICAwICAgICAg MjAxMjUxICAgICAgICAgICAwICAgICAgICAxNDA5ICAgIDE0MiAgICAgIDAgIDAgICAgICAwIC91 c3Ivc3JjL3N5cy9rZXJuL3N1YnJfdHJhcC5jOjIxMyAoc3BpbiBtdXRleDpzY2hlZCBsb2NrIDMx KQogICAgIDI1MSAgICAgICAgIDAgICAgICAgICAyNTEgICAgICAgICAgIDAgICAgICAgICAgIDEg ICAgMjUxICAgICAgMCAgMCAgICAgIDAgL3Vzci9zcmMvc3lzL2tlcm4va2Vybl90aHJlYWQuYzo0 MTAgKHNwaW4gbXV0ZXg6c2NoZWQgbG9jayAzMSkKICAgICAxMDkgICAgICAgICAwICAgICAgICAg MTA5ICAgICAgICAgICAwICAgICAgICAgICAxICAgIDEwOSAgICAgIDAgIDAgICAgICAwIC91c3Iv c3JjL3N5cy9rZXJuL2tlcm5fdW10eC5jOjMzNjAgKHNwaW4gbXV0ZXg6c2NoZWQgbG9jayAzMSkK ICAgICAxNDkgICAgICAgICAwICAgICAgICAgMTQ5ICAgICAgICAgICAwICAgICAgICAgICAxICAg IDE0OSAgICAgIDAgIDAgICAgICAwIC91c3Ivc3JjL3N5cy9rZXJuL3N1YnJfdHVybnN0aWxlLmM6 NzI3IChzcGluIG11dGV4OnNjaGVkIGxvY2sgMzEpCiAgICAgMTQ4ICAgICAgICAgMCAgICAgICAg IDQyMyAgICAgICAgICAgMCAgICAgICAgICAgMyAgICAxNDEgICAgICAwICAwICAgICAgMCAvdXNy L3NyYy9zeXMva2Vybi9rZXJuX2ludHIuYzoxMjM5IChzcGluIG11dGV4OnNjaGVkIGxvY2sgMzEp Cgo= --001636456fd611f42404668fb355-- From owner-freebsd-current@FreeBSD.ORG Thu Apr 2 13:39: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 9708D106566B; Thu, 2 Apr 2009 13:39:34 +0000 (UTC) (envelope-from bsam@ipt.ru) Received: from services.ipt.ru (services.ipt.ru [194.62.233.110]) by mx1.freebsd.org (Postfix) with ESMTP id 548A88FC0C; Thu, 2 Apr 2009 13:39:34 +0000 (UTC) (envelope-from bsam@ipt.ru) Received: from bb.ipt.ru ([194.62.233.89]) by services.ipt.ru with esmtp (Exim 4.54 (FreeBSD)) id 1LpN8m-0006Hw-BJ; Thu, 02 Apr 2009 17:39:32 +0400 To: "O. Hartmann" References: <49D4BD74.30608@web.de> From: Boris Samorodov Date: Thu, 02 Apr 2009 17:39:33 +0400 In-Reply-To: <49D4BD74.30608@web.de> (O. Hartmann's message of "Thu\, 02 Apr 2009 13\:28\:20 +0000") Message-ID: <14512074@bb.ipt.ru> User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.3 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: freebsd-current@FreeBSD.org, freebsd-questions@freebsd.org Subject: Re: FreeBSD 8.0-CUR: /usr/ports/x11/linux-f8-xorg-libs won't install although emulators/linux_base-f8 is already installed 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, 02 Apr 2009 13:39:35 -0000 On Thu, 02 Apr 2009 13:28:20 +0000 O. Hartmann wrote: > Before filing a PR I will ask for hints for a problem I revealed when > I wanted installing usr/ports/x11/linux-f8-xorg-libs on a FreeBSD > 8.0-CURRENT/amd64 box (most recent build_world, ports tree up to > date). > I receive this error: > ===> linux-f8-xorg-libs-7.3 the port should be used with > linux_base-f8, please read /usr/ports/UPDATING. There was an error at /usr/ports/UPDATING, I committed a fix two hours ago. You should define at /etc/make.conf variables: OVERRIDE_LINUX_BASE_PORT=f8 OVERRIDE_LINUX_NONBASE_PORTS=f8 > *** Error code 1 > Stop in /usr/ports/x11/linux-f8-xorg-libs. > Package /usr/ports/emulators/linux_base-f8 is already installed, up to > date and Linux kernel module is also running and showing up when doing > kldstat adjacent with linprocfs and linsysfs. > What's wrong? HTH & WBR -- Boris Samorodov (bsam) Research Engineer, http://www.ipt.ru Telephone & Internet SP FreeBSD Committer, http://www.FreeBSD.org The Power To Serve From owner-freebsd-current@FreeBSD.ORG Thu Apr 2 13:29: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 5316A1065670; Thu, 2 Apr 2009 13:29:51 +0000 (UTC) (envelope-from ohartman@web.de) Received: from fmmailgate03.web.de (fmmailgate03.web.de [217.72.192.234]) by mx1.freebsd.org (Postfix) with ESMTP id 0F4C58FC18; Thu, 2 Apr 2009 13:29:50 +0000 (UTC) (envelope-from ohartman@web.de) Received: from smtp08.web.de (fmsmtp08.dlan.cinetic.de [172.20.5.216]) by fmmailgate03.web.de (Postfix) with ESMTP id A58E7F9E45CA; Thu, 2 Apr 2009 15:29:49 +0200 (CEST) Received: from [130.133.86.198] (helo=telesto.geoinf.fu-berlin.de) by smtp08.web.de with asmtp (TLSv1:AES256-SHA:256) (WEB.DE 4.110 #277) id 1LpMzN-0004wu-00; Thu, 02 Apr 2009 15:29:49 +0200 Message-ID: <49D4BD74.30608@web.de> Date: Thu, 02 Apr 2009 13:28:20 +0000 From: "O. Hartmann" User-Agent: Thunderbird 2.0.0.21 (X11/20090323) MIME-Version: 1.0 To: freebsd-current@FreeBSD.org, freebsd-questions@freebsd.org Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit Sender: ohartman@web.de X-Sender: ohartman@web.de X-Provags-ID: V01U2FsdGVkX1+dTPcyiycl2KChmct24Q8XP+fn+ZQlG+sMefsd FQ8L+oTQrkQs20UVPhyGmd5AF9s9hKNDiGMwHtdxbDXyMA1oo/ LDj+cpizs= X-Mailman-Approved-At: Thu, 02 Apr 2009 13:53:02 +0000 Cc: Subject: FreeBSD 8.0-CUR: /usr/ports/x11/linux-f8-xorg-libs won't install although emulators/linux_base-f8 is already installed 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, 02 Apr 2009 13:29:52 -0000 Before filing a PR I will ask for hints for a problem I revealed when I wanted installing usr/ports/x11/linux-f8-xorg-libs on a FreeBSD 8.0-CURRENT/amd64 box (most recent build_world, ports tree up to date). I receive this error: ===> linux-f8-xorg-libs-7.3 the port should be used with linux_base-f8, please read /usr/ports/UPDATING. *** Error code 1 Stop in /usr/ports/x11/linux-f8-xorg-libs. Package /usr/ports/emulators/linux_base-f8 is already installed, up to date and Linux kernel module is also running and showing up when doing kldstat adjacent with linprocfs and linsysfs. What's wrong? Oliver From owner-freebsd-current@FreeBSD.ORG Thu Apr 2 14:16: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 61C951065674; Thu, 2 Apr 2009 14:16:10 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.208.78.105]) by mx1.freebsd.org (Postfix) with ESMTP id 426D78FC16; Thu, 2 Apr 2009 14:16:10 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (localhost.apl.washington.edu [127.0.0.1]) by troutmask.apl.washington.edu (8.14.3/8.14.3) with ESMTP id n32EGAJ8055749; Thu, 2 Apr 2009 07:16:10 -0700 (PDT) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.14.3/8.14.3/Submit) id n32EGAcX055748; Thu, 2 Apr 2009 07:16:10 -0700 (PDT) (envelope-from sgk) Date: Thu, 2 Apr 2009 07:16:10 -0700 From: Steve Kargl To: "O. Hartmann" Message-ID: <20090402141610.GA55696@troutmask.apl.washington.edu> References: <49D4BD74.30608@web.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <49D4BD74.30608@web.de> User-Agent: Mutt/1.4.2.3i Cc: freebsd-current@freebsd.org, freebsd-questions@freebsd.org Subject: Re: FreeBSD 8.0-CUR: /usr/ports/x11/linux-f8-xorg-libs won't install although emulators/linux_base-f8 is already installed 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, 02 Apr 2009 14:16:10 -0000 On Thu, Apr 02, 2009 at 01:28:20PM +0000, O. Hartmann wrote: > Before filing a PR I will ask for hints for a problem I revealed when I > wanted installing usr/ports/x11/linux-f8-xorg-libs on a FreeBSD > 8.0-CURRENT/amd64 box (most recent build_world, ports tree up to date). > I receive this error: > > ===> linux-f8-xorg-libs-7.3 the port should be used with linux_base-f8, > please read /usr/ports/UPDATING. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > *** Error code 1 > > Stop in /usr/ports/x11/linux-f8-xorg-libs. > > > Package /usr/ports/emulators/linux_base-f8 is already installed, up to > date and Linux kernel module is also running and showing up when doing > kldstat adjacent with linprocfs and linsysfs. > > What's wrong? > See above? -- Steve From owner-freebsd-current@FreeBSD.ORG Thu Apr 2 14:47: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 99C1F106564A; Thu, 2 Apr 2009 14:47:09 +0000 (UTC) (envelope-from ohartman@zedat.fu-berlin.de) Received: from outpost1.zedat.fu-berlin.de (outpost1.zedat.fu-berlin.de [130.133.4.66]) by mx1.freebsd.org (Postfix) with ESMTP id 529008FC13; Thu, 2 Apr 2009 14:47:09 +0000 (UTC) (envelope-from ohartman@zedat.fu-berlin.de) Received: from inpost2.zedat.fu-berlin.de ([130.133.4.69]) by outpost1.zedat.fu-berlin.de (Exim 4.69) with esmtp (envelope-from ) id <1LpOCC-0001Jg-4d>; Thu, 02 Apr 2009 16:47:08 +0200 Received: from telesto.geoinf.fu-berlin.de ([130.133.86.198]) by inpost2.zedat.fu-berlin.de (Exim 4.69) with esmtpsa (envelope-from ) id <1LpOCC-0003FL-3K>; Thu, 02 Apr 2009 16:47:08 +0200 Message-ID: <49D4CF93.8000906@zedat.fu-berlin.de> Date: Thu, 02 Apr 2009 14:45:39 +0000 From: "O. Hartmann" Organization: Freie =?ISO-8859-15?Q?Universit=E4t_Berlin?= User-Agent: Thunderbird 2.0.0.21 (X11/20090323) MIME-Version: 1.0 To: Boris Samorodov References: <49D4BD74.30608@web.de> <14512074@bb.ipt.ru> In-Reply-To: <14512074@bb.ipt.ru> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: 130.133.86.198 Cc: freebsd-current@FreeBSD.org, freebsd-questions@freebsd.org, "O. Hartmann" Subject: Re: FreeBSD 8.0-CUR: /usr/ports/x11/linux-f8-xorg-libs won't install although emulators/linux_base-f8 is already installed 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, 02 Apr 2009 14:47:10 -0000 Boris Samorodov wrote: > On Thu, 02 Apr 2009 13:28:20 +0000 O. Hartmann wrote: > >> Before filing a PR I will ask for hints for a problem I revealed when >> I wanted installing usr/ports/x11/linux-f8-xorg-libs on a FreeBSD >> 8.0-CURRENT/amd64 box (most recent build_world, ports tree up to >> date). >> I receive this error: > >> ===> linux-f8-xorg-libs-7.3 the port should be used with >> linux_base-f8, please read /usr/ports/UPDATING. > > There was an error at /usr/ports/UPDATING, I committed a fix two > hours ago. You should define at /etc/make.conf variables: > OVERRIDE_LINUX_BASE_PORT=f8 > OVERRIDE_LINUX_NONBASE_PORTS=f8 > >> *** Error code 1 > >> Stop in /usr/ports/x11/linux-f8-xorg-libs. > > >> Package /usr/ports/emulators/linux_base-f8 is already installed, up to >> date and Linux kernel module is also running and showing up when doing >> kldstat adjacent with linprocfs and linsysfs. > >> What's wrong? > > HTH & WBR After adding both lines as recommended everything worked well! Thanks. From owner-freebsd-current@FreeBSD.ORG Thu Apr 2 16:45: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 35D7010656C2 for ; Thu, 2 Apr 2009 16:45:16 +0000 (UTC) (envelope-from xcllnt@mac.com) Received: from asmtpout015.mac.com (asmtpout015.mac.com [17.148.16.90]) by mx1.freebsd.org (Postfix) with ESMTP id 185018FC20 for ; Thu, 2 Apr 2009 16:45:16 +0000 (UTC) (envelope-from xcllnt@mac.com) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Received: from jflores-gxdt755.jnpr.net ([66.129.224.36]) by asmtp015.mac.com (Sun Java(tm) System Messaging Server 6.3-8.01 (built Dec 16 2008; 32bit)) with ESMTPSA id <0KHH00GA4FV4S130@asmtp015.mac.com> for freebsd-current@freebsd.org; Thu, 02 Apr 2009 09:45:05 -0700 (PDT) Message-id: From: Marcel Moolenaar To: Tai-hwa Liang In-reply-to: <0904021314574.37737@www.mmlab.cse.yzu.edu.tw> Date: Thu, 02 Apr 2009 09:43:43 -0700 References: <95891.1238477069@critter.freebsd.dk> <20090331133132.1e191836@ernst.jennejohn.org> <20090331155542.74d89d64@ernst.jennejohn.org> <60084D1E-9F64-463A-A8E9-7A237D5C7661@mac.com> <0904011910169.29800@www.mmlab.cse.yzu.edu.tw> <0904020940371.36257@www.mmlab.cse.yzu.edu.tw> <4CCDEFD6-830E-4C8F-B7A2-B7878F8842BE@mac.com> <0904021314574.37737@www.mmlab.cse.yzu.edu.tw> X-Mailer: Apple Mail (2.930.3) Cc: freebsd-current@freebsd.org Subject: Re: Removal of GEOM_BSD, GEOM_MBR, GEOM_PC98 and GEOM_SUNLABEL 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, 02 Apr 2009 16:45:19 -0000 On Apr 1, 2009, at 10:16 PM, Tai-hwa Liang wrote: > GENERIC kernel as of today(read: with GEOM_PART_{BSD,EBR,MBR} in > DEFAULT > and no GEOM{BSD,MBR}): > > # geom show > => 63 228338775 ad0 MBR (109G) > 63 18688257 1 !12 (8.9G) > 18688320 16783200 2 freebsd [active] (8.0G) > 35471520 192855600 3 !15 (92G) > 228327120 11718 - free - (5.7M) Can you dump the first 2 sectors of slice 3 and send it to me: dd if=/dev/ad0s3 of=/tmp/dump.dd count=2 bs=512 I suspect the EBR has some data where it shouldn't and as such is rejected by the EBR scheme. Could you also send me the confxml output: sysctl -b kern.geom.confxml > geom.xml Thanks! -- Marcel Moolenaar xcllnt@mac.com From owner-freebsd-current@FreeBSD.ORG Thu Apr 2 17:00: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 B217B10656C9 for ; Thu, 2 Apr 2009 17:00:09 +0000 (UTC) (envelope-from xcllnt@mac.com) Received: from asmtpout016.mac.com (asmtpout016.mac.com [17.148.16.91]) by mx1.freebsd.org (Postfix) with ESMTP id D7EDB8FC15 for ; Thu, 2 Apr 2009 17:00:03 +0000 (UTC) (envelope-from xcllnt@mac.com) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=US-ASCII; format=flowed Received: from dpham-t61.jnpr.net ([66.129.224.36]) by asmtp016.mac.com (Sun Java(tm) System Messaging Server 6.3-8.01 (built Dec 16 2008; 32bit)) with ESMTPSA id <0KHH002PWGJPNF40@asmtp016.mac.com> for freebsd-current@freebsd.org; Thu, 02 Apr 2009 09:59:50 -0700 (PDT) Message-id: <41AA874E-3A8D-4059-9B60-BCE91051BB0C@mac.com> From: Marcel Moolenaar To: "Wilkinson, Alex" In-reply-to: <20090402025021.GD2351@stlux503.dsto.defence.gov.au> Date: Thu, 02 Apr 2009 09:58:28 -0700 References: <95891.1238477069@critter.freebsd.dk> <20090331133132.1e191836@ernst.jennejohn.org> <20090331155542.74d89d64@ernst.jennejohn.org> <60084D1E-9F64-463A-A8E9-7A237D5C7661@mac.com> <0904011910169.29800@www.mmlab.cse.yzu.edu.tw> <7d6fde3d0904011233v758d337am5e4252adbe5cf58a@mail.gmail.com> <7d6fde3d0904011235x404fc7dbo1918d3dbe7ed645a@mail.gmail.com> <94ABEC6B-4AC5-4350-B111-AD9795D4F2ED@mac.com> <20090402025021.GD2351@stlux503.dsto.defence.gov.au> X-Mailer: Apple Mail (2.930.3) Cc: freebsd-current@freebsd.org Subject: Re: Removal of GEOM_BSD, GEOM_MBR, GEOM_PC98 and GEOM_SUNLABEL 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, 02 Apr 2009 17:00:13 -0000 On Apr 1, 2009, at 7:50 PM, Wilkinson, Alex wrote: > > 0n Wed, Apr 01, 2009 at 12:44:27PM -0700, Marcel Moolenaar wrote: > >>> 2. What's it being replaced with? >> >> GEOM_PART_BSD, GEOM_PART_MBR, GEOM_PART_PC98 and >> GEOM_PART_VTOC8 > > Why ? It's a better basis for further growth. It has a uniform interface which allows us to improve sysinstall and add GPT on i386 or even APM on PowerPC (you'd expect we have that already, but we don't). We can even modify logical partitions then, something we cannot do now. We can have a tool like parted... It allows us to add "advanced" features like moving a partition that's mounted or resizing a partition that has been formatted without reformatting. Or even the ability to migrate a MBR+BSD partitioning scheme into a GPT one while the system is running from the disk. -- Marcel Moolenaar xcllnt@mac.com From owner-freebsd-current@FreeBSD.ORG Thu Apr 2 18:48: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 A6BAA106566C; Thu, 2 Apr 2009 18:48:27 +0000 (UTC) (envelope-from babkin@verizon.net) Received: from vms173017pub.verizon.net (vms173017pub.verizon.net [206.46.173.17]) by mx1.freebsd.org (Postfix) with ESMTP id 82A2A8FC13; Thu, 2 Apr 2009 18:48:27 +0000 (UTC) (envelope-from babkin@verizon.net) Received: from vms062.mailsrvcs.net ([172.18.12.134]) by vms173017.mailsrvcs.net (Sun Java(tm) System Messaging Server 6.3-7.04 (built Sep 26 2008; 32bit)) with ESMTPA id <0KHH00ED7LK4DA5R@vms173017.mailsrvcs.net>; Thu, 02 Apr 2009 13:48:04 -0500 (CDT) Received: from 65.242.108.162 ([65.242.108.162]) by vms062.mailsrvcs.net (Verizon Webmail) with HTTP; Thu, 02 Apr 2009 13:48:04 -0500 (CDT) Date: Thu, 02 Apr 2009 13:48:04 -0500 (CDT) From: Sergey Babkin To: peterjeremy@optushome.com.au Message-id: <6547642.196222.1238698084570.JavaMail.root@vms062.mailsrvcs.net> Content-transfer-encoding: quoted-printable X-Originating-IP: [65.242.108.162] X-Mailman-Approved-At: Thu, 02 Apr 2009 19:07:57 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: sobomax@FreeBSD.org, prashant.vaibhav@gmail.com, freebsd-current@FreeBSD.org, davidxu@FreeBSD.org, freebsd-hackers@FreeBSD.org Subject: Re: Re: Improving the kernel/i386 timecounter performance (GSoC proposal) 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, 02 Apr 2009 18:48:28 -0000 Apr 2, 2009 01:03:48 AM, [1]peterjeremy@optushome.com.au wrot= e: >On 2009-Mar-30 18:45:30 -0700, Maxim Sobolev <[2]sobomax@freebsd.org> wrote: >>You don't really need to = do it on every execve() unconditionally. It >>could be done on de= mand in libc, so that only when thread pass certain >>threshold, = the "common page optimization code" kicks in and does its >>open/= mmap/etc magic. Otherwise, "normal" syscall is performed. > >Th= is "optimisation" is premature. First step is to implement an >appro= ach that always maps (or whatever) the data and then gather some >inf= ormation about its overheads in the real world. If they are deemed >= excessive, only then do we start looking at how to improve things. >A= nd IMO, the first step would be to lazily map the page - so it's not >= ;mapped by default but mapped the first time any of the information in &= gt;it is used. Does it make sense to even bother with lazy mapping? = After all, this is a very minor activity compared to mapping and linking= the dynamic libc. I think the overhead won't be even noticeable. If you= already map 200 pages, adding one more should not make much difference.= -SB References 1. 3D"mailto:peterjeremy@optushome.com.au" 2. file://localhost/tmp/3D"m= From owner-freebsd-current@FreeBSD.ORG Thu Apr 2 19:18: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 54E1B106567C for ; Thu, 2 Apr 2009 19:18:38 +0000 (UTC) (envelope-from julian@elischer.org) Received: from outF.internet-mail-service.net (outf.internet-mail-service.net [216.240.47.229]) by mx1.freebsd.org (Postfix) with ESMTP id E7D2B8FC23 for ; Thu, 2 Apr 2009 19:18:37 +0000 (UTC) (envelope-from julian@elischer.org) Received: from idiom.com (mx0.idiom.com [216.240.32.160]) by out.internet-mail-service.net (Postfix) with ESMTP id 1871E1F673; Thu, 2 Apr 2009 12:18:38 -0700 (PDT) X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e Received: from julian-mac.elischer.org (home.elischer.org [216.240.48.38]) by idiom.com (Postfix) with ESMTP id 0679F2D6116; Thu, 2 Apr 2009 12:18:33 -0700 (PDT) Message-ID: <49D50FA6.1020202@elischer.org> Date: Thu, 02 Apr 2009 12:19:02 -0700 From: Julian Elischer User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: Sergey Babkin References: <6547642.196222.1238698084570.JavaMail.root@vms062.mailsrvcs.net> In-Reply-To: <6547642.196222.1238698084570.JavaMail.root@vms062.mailsrvcs.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: sobomax@FreeBSD.org, peterjeremy@optushome.com.au, freebsd-current@FreeBSD.org, davidxu@FreeBSD.org, freebsd-hackers@FreeBSD.org, prashant.vaibhav@gmail.com Subject: Re: Improving the kernel/i386 timecounter performance (GSoC proposal) 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, 02 Apr 2009 19:18:38 -0000 Hey Sergey, whatever you are using for a mail client SUCKS real bad at the moment.. it's really messing up your outgoing mails.. note the mail below.... Sergey Babkin wrote: > Apr 2, 2009 01:03:48 AM, [1]peterjeremy@optushome.com.au wrot= : > >On 2009-Mar-30 18:45:30 -0700, Maxim Sobolev <[2]sobomax@freebsd.org> > wrote: > >>You don't really need to =o it on every execve() unconditionally. > It > >>could be done on de=and in libc, so that only when thread pass > certain > >>threshold, =he "common page optimization code" kicks in and does > its > >>open/=map/etc magic. Otherwise, "normal" syscall is performed. > > > >Th=s "optimisation" is premature. First step is to implement an > >appro=ch that always maps (or whatever) the data and then gather > some > >inf=rmation about its overheads in the real world. If they are > deemed > >=xcessive, only then do we start looking at how to improve things. > >A=d IMO, the first step would be to lazily map the page - so it's > not > >=mapped by default but mapped the first time any of the information > in > &=t;it is used. > Does it make sense to even bother with lazy mapping? =fter all, this > is a very minor > activity compared to mapping and linking=he dynamic libc. I think > the overhead > won't be even noticeable. If you=lready map 200 pages, adding one > more should not > make much difference. -SB > > References > > 1. 3D"mailto:peterjeremy@optushome.com.au" > 2. file://localhost/tmp/3D"m_______________________________________________ > 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 Apr 2 19:35: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 F1035106566B; Thu, 2 Apr 2009 19:35:05 +0000 (UTC) (envelope-from mister.olli@googlemail.com) Received: from mail-bw0-f164.google.com (mail-bw0-f164.google.com [209.85.218.164]) by mx1.freebsd.org (Postfix) with ESMTP id DFA768FC19; Thu, 2 Apr 2009 19:35:04 +0000 (UTC) (envelope-from mister.olli@googlemail.com) Received: by bwz8 with SMTP id 8so656154bwz.43 for ; Thu, 02 Apr 2009 12:35:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:received:received:subject:from:reply-to:to:cc :in-reply-to:references:content-type:date:message-id:mime-version :x-mailer:content-transfer-encoding; bh=xTm6XZUNGB+tMyn9ufRERMWmZM+ZmSKHEiLEDLjzO68=; b=lBBFZmKcdFqprg0/ikHcRwiDwJkP/H46TgDZlLrZjI/vhb7YpvAtfptyP8Q0y9DOWv iH51la/kougBfjNu1yvK8SK2GS5O4+AIIgJ4942TF2GS9SAhek4lTNPfF1k5zUHR1/rk 0VqLfBNJHTIB2Kwq5h4byYU/dJOAWKdy4NVK4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=subject:from:reply-to:to:cc:in-reply-to:references:content-type :date:message-id:mime-version:x-mailer:content-transfer-encoding; b=To+an0yl24UsLxlQI+DtdLYhlwoT9CQo2Tpg1Y6mtO3p2CHHf2O9AnbN8diP/k/vgn BMbf7oiCg/chWQBOTf6j2hHFPx+vv6njenaJP+D3NsBY0iNwRzBzUVC2Cy2BPMQ7mvm5 EJgOXMBsajSrvma9zvOqntZpPyhdHs6JM6AgA= Received: by 10.103.225.11 with SMTP id c11mr186415mur.24.1238700903845; Thu, 02 Apr 2009 12:35:03 -0700 (PDT) Received: from ?10.30.1.139? (vpn-or.studi-planet.com [78.47.172.52]) by mx.google.com with ESMTPS id 23sm507801mum.37.2009.04.02.12.35.01 (version=SSLv3 cipher=RC4-MD5); Thu, 02 Apr 2009 12:35:02 -0700 (PDT) From: Mister Olli To: =?ISO-8859-1?Q?Bj=F6rn?= JACKE In-Reply-To: References: <1238162602.24399.29.camel@phoenix.blechhirn.net> Content-Type: text/plain; charset="ISO-8859-15" Date: Thu, 02 Apr 2009 21:34:54 +0200 Message-Id: <1238700894.14361.615.camel@phoenix.blechhirn.net> Mime-Version: 1.0 X-Mailer: Evolution 2.24.5 Content-Transfer-Encoding: 8bit Cc: freebsd-xen@freebsd.org, dfr@freebsd.org, freebsd-current@freebsd.org, bzeeb-lists@lists.zabbadoz.net Subject: Re: Compiling CURRENT with XEN config fails X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: mister.olli@googlemail.com List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Apr 2009 19:35:06 -0000 Hi, the attached patch fixed the compile problem, but new ones are coming up (on r190464) ;-)) cc -c -O -pipe -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/usr/src/sys -I/usr/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -fstack-protector -Werror /usr/src/sys/xen/reboot.c /usr/src/sys/xen/reboot.c: In function 'xen_suspend': /usr/src/sys/xen/reboot.c:179: error: 'sched_lock' undeclared (first use in this function) /usr/src/sys/xen/reboot.c:179: error: (Each undeclared identifier is reported only once /usr/src/sys/xen/reboot.c:179: error: for each function it appears in.) cc1: warnings being treated as errors /usr/src/sys/xen/reboot.c:216: warning: implicit declaration of function 'pmap_suspend' /usr/src/sys/xen/reboot.c:216: warning: nested extern declaration of 'pmap_suspend' /usr/src/sys/xen/reboot.c:218: warning: implicit declaration of function 'pmap_resume' /usr/src/sys/xen/reboot.c:218: warning: nested extern declaration of 'pmap_resume' /usr/src/sys/xen/reboot.c:224: error: 'xen_pfn_to_mfn_frame_list_list' undeclared (first use in this function) /usr/src/sys/xen/reboot.c:231: error: 'xen_pfn_to_mfn_frame_list' undeclared (first use in this function) *** Error code 1 Stop in /usr/obj/usr/src/sys/XEN. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. template-8_CURRENT# with a current revision (190640) 'make depend' fails with these errors: ===> sbin/ifconfig (depend) rm -f .depend mkdep -f .depend -a ifconfig.c af_link.c af_inet.c af_inet6.c af_atalk.c ifclone.c ifmac.c ifmedia.c ifvlan.c ifgre.c ifieee80211.c regdomain.c ifcarp.c ifgroup.c ifpfsync.c ifbridge.c iflagg.c af_ipx.c ifieee80211.c:82:39: error: net80211/ieee80211_superg.h: No such file or directory mkdep: compile failed *** Error code 1 Stop in /usr/src/sbin/ifconfig. *** Error code 1 Regards, Olli On Mi, 2009-04-01 at 12:04 +0200, Björn JACKE wrote: > On 2009-03-27 at 15:03 +0100 Mister Olli sent off: > > /usr/src/sys/xen/evtchn/evtchn.c:516: error: conflicting types for 'bind_virq_to_irqhandler' > > /usr/src/sys/xen/xen_intr.h:61: error: previous declaration of 'bind_virq_to_irqhandler' was here > > /usr/src/sys/xen/evtchn/evtchn.c: In function 'bind_virq_to_irqhandler': > > /usr/src/sys/xen/evtchn/evtchn.c:523: error: 'arg' undeclared (first use in this function) > > /usr/src/sys/xen/evtchn/evtchn.c:523: error: (Each undeclared identifier is reported only once > > /usr/src/sys/xen/evtchn/evtchn.c:523: error: for each function it appears in.) > > *** Error code 1 > > the attached patch should fix this one. Can someone review that please? > > Thanks > Björn From owner-freebsd-current@FreeBSD.ORG Thu Apr 2 20:25: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 55D931065673 for ; Thu, 2 Apr 2009 20:25:35 +0000 (UTC) (envelope-from freebsd-current@m.gmane.org) Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by mx1.freebsd.org (Postfix) with ESMTP id C6CC28FC1A for ; Thu, 2 Apr 2009 20:25:34 +0000 (UTC) (envelope-from freebsd-current@m.gmane.org) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1LpTTh-0006bU-60 for freebsd-current@freebsd.org; Thu, 02 Apr 2009 20:25:33 +0000 Received: from 93-138-88-151.adsl.net.t-com.hr ([93.138.88.151]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 02 Apr 2009 20:25:32 +0000 Received: from ivoras by 93-138-88-151.adsl.net.t-com.hr with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 02 Apr 2009 20:25:32 +0000 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-current@freebsd.org From: Ivan Voras Date: Thu, 02 Apr 2009 22:25:09 +0200 Lines: 47 Message-ID: References: <367b2c980903311133v37833cabla4934f8b1a9b5e15@mail.gmail.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig0AF00B832FA1D7C0D6D217CF" X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: 93-138-88-151.adsl.net.t-com.hr User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) In-Reply-To: <367b2c980903311133v37833cabla4934f8b1a9b5e15@mail.gmail.com> X-Enigmail-Version: 0.95.7 Sender: news Subject: Re: strange UFS labels behaviour 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, 02 Apr 2009 20:25:35 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig0AF00B832FA1D7C0D6D217CF Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Olivier SMEDTS wrote: > Hi, >=20 > Since UFS labels were introduced, I've got strange behaviour when > fsck-ing or mounting my UFS partitions. Here is the console output at > boot : > Is this expected ? I didn't read your message in detail but if are you asking if the "label =2E.. removed" are valid when the device is opened from an "alternative" entry point (e.g. ad0s1e instead of ufsid/4867d45fd3972203) then yes, this is by design. The label is read from the file system metadata and anything that opens that file system for its own use can change this metadata - so the labels are removed. (note that this is nothing special as far as GEOM_LABEL is concerned - this is present in all types and forms of labels). If you're complaining about the verbosity of the whole process then I think you can set the kern.geom.label.debug sysctl to -1 to avoid these messages. The "modern" way would be to use the labels as device nodes for mounting instead of raw devices - in this case they would "stay" when opened. --------------enig0AF00B832FA1D7C0D6D217CF Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAknVHyUACgkQldnAQVacBchuxACgg2GuKaEpeb+2Lrr10lKWbgQU eoMAn2n+UWZ/H1UPvf01zuXlRWraGd// =J3jT -----END PGP SIGNATURE----- --------------enig0AF00B832FA1D7C0D6D217CF-- From owner-freebsd-current@FreeBSD.ORG Fri Apr 3 01:35: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 EEB84106564A for ; Fri, 3 Apr 2009 01:35:25 +0000 (UTC) (envelope-from avatar@mmlab.cse.yzu.edu.tw) Received: from www.mmlab.cse.yzu.edu.tw (www.mmlab.cse.yzu.edu.tw [140.138.150.166]) by mx1.freebsd.org (Postfix) with ESMTP id E0DA08FC08 for ; Fri, 3 Apr 2009 01:35:24 +0000 (UTC) (envelope-from avatar@mmlab.cse.yzu.edu.tw) Received: by www.mmlab.cse.yzu.edu.tw (qmail, from userid 1000) id 37B95E43407; Fri, 3 Apr 2009 09:35:02 +0800 (CST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=mmlab.cse.yzu.edu.tw; s=test; t=1238722502; bh=xShDZzo3K5VcZgB9sCS26QUmYCIj9gJA2Q2lDHRtP0c=; h=Date:From:To:cc:Subject:In-Reply-To:Message-ID:References: MIME-Version:Content-Type; b=xfbzzEajw02eYUB9jJ35vFiTkJ+4W5v6FMBGSag/LzYqde8tmzOHOpQ7rBoVdIvg+ RU8DOP9ScyUHkep9P5+3gNRp/+NHTW4gpkBvWn3QIgN2lzUvp3UHn+vAks5F/e+RgF q9w0Hpyk/zK9/8hCZYEBRo0U0FWI0WG33zq6Uioc= Received: from localhost (localhost [127.0.0.1]) by www.mmlab.cse.yzu.edu.tw (qmail) with ESMTP id 35755E43406; Fri, 3 Apr 2009 09:35:02 +0800 (CST) Date: Fri, 3 Apr 2009 09:35:02 +0800 (CST) From: Tai-hwa Liang To: Marcel Moolenaar In-Reply-To: Message-ID: <09040309313414.76643@www.mmlab.cse.yzu.edu.tw> References: <95891.1238477069@critter.freebsd.dk> <20090331133132.1e191836@ernst.jennejohn.org> <20090331155542.74d89d64@ernst.jennejohn.org> <60084D1E-9F64-463A-A8E9-7A237D5C7661@mac.com> <0904011910169.29800@www.mmlab.cse.yzu.edu.tw> <0904020940371.36257@www.mmlab.cse.yzu.edu.tw> <4CCDEFD6-830E-4C8F-B7A2-B7878F8842BE@mac.com> <0904021314574.37737@www.mmlab.cse.yzu.edu.tw> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-current@freebsd.org Subject: Re: Removal of GEOM_BSD, GEOM_MBR, GEOM_PC98 and GEOM_SUNLABEL 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, 03 Apr 2009 01:35:26 -0000 On Thu, 2 Apr 2009, Marcel Moolenaar wrote: > Can you dump the first 2 sectors of slice 3 and > send it to me: > dd if=/dev/ad0s3 of=/tmp/dump.dd count=2 bs=512 00000000 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 00000010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 00000020 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 00000030 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 00000040 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 00000050 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 00000060 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 00000070 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 00000080 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 00000090 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 000000a0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 000000b0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 000000c0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 000000d0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 000000e0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 000000f0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 00000100 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 00000110 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 00000120 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 00000130 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 00000140 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 00000150 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 00000160 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 00000170 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 00000180 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 00000190 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 000001a0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 000001b0 00 00 00 00 00 f2 0e 00 00 00 00 00 00 00 00 01 |................| 000001c0 c1 ff 83 ef ff ff 3f 00 00 00 21 17 00 01 00 00 |......?...!.....| 000001d0 c1 ff 05 ef ff ff 60 17 00 01 b0 a8 fe 02 00 00 |......`.........| 000001e0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 000001f0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 55 aa |..............U.| 00000200 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 00000210 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 00000220 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 00000230 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 00000240 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 00000250 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 00000260 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 00000270 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 00000280 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 00000290 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 000002a0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 000002b0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 000002c0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 000002d0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 000002e0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 000002f0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 00000300 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 00000310 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 00000320 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 00000330 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 00000340 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 00000350 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 00000360 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 00000370 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 00000380 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 00000390 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 000003a0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 000003b0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 000003c0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 000003d0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 000003e0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 000003f0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 00000400 > I suspect the EBR has some data where it shouldn't and > as such is rejected by the EBR scheme. > > Could you also send me the confxml output: > sysctl -b kern.geom.confxml > geom.xml A working(w/ GEOM_{MBR,BSD}, w/o GEOM_PART_{MBR,EBR,BSD}) kernel: MD md0 1 r1w1e1 md0 536870912 512 0 512 0 0 536870912 swap ACD acd0 1 r0w0e0 acd0 8796093020160 2048 BSD ad0s7 4 512 18161418240 18161418240 r1w1e2 r0w0e0 ad0s7c 16000492032 512 2 16000492032 31250961 0 0 0 r1w1e1 ad0s7a 16000483840 512 0 16000483840 31250945 0 0 7 ad0s2 3 512 9568419840 9568419840 r4w4e4 r1w1e1 ad0s2e 5841534976 512 4 5841534976 11409248 2751463424 5373952 7 r1w1e1 ad0s2d 201326592 512 3 201326592 393216 2550136832 4980736 7 r0w0e0 ad0s2c 8592998400 512 2 8592998400 16783200 0 0 0 r1w1e0 ad0s2b 2147483648 512 1 2147483648 4194304 402653184 786432 1 r1w1e1 ad0s2a 402653184 512 0 402653184 786432 0 0 7 PART VFS ffs.md0 2 r1w1e1 msdosfs.ad0s6 4 r1w1e1 msdosfs.ad0s1 3 r1w1e1 ffs.ad0s7a 5 r1w1e1 ffs.ad0s2e 4 r1w1e1 ffs.ad0s2d 4 r1w1e1 ffs.ad0s2a 4 r1w1e1 DISK cd0 1 r0w0e0 cd0 0 2048 0 0 ad0 1 r7w7e10 ad0 116909491200 512 16 63 MBR ad0 2 r7w7e10 r2w2e4 ad0s3 98742067200 512 2 98742067200 192855600 18161418240 35471520 15 r4w4e4 ad0s2 8592998400 512 1 8592998400 16783200 9568419840 18688320 165 r1w1e1 ad0s1 9568387584 512 0 9568387584 18688257 32256 63 12 MBREXT ad0s3 3 r2w2e4 r0w0e0 ad0s8 48423707136 512 3 48423707136 94577553 50318360064 98278047 165 r1w1e2 ad0s7 16000492032 512 2 16000492032 31250961 34317835776 67027023 165 r1w1e1 ad0s6 25724772864 512 1 25724772864 50243697 8593030656 16783263 11 r0w0e0 ad0s5 8592966144 512 0 8592966144 16783137 32256 63 131 SWAP swap 4 r1w1e0 DEV md0 2 r0w0e0 cd0 2 r0w0e0 acd0 2 r0w0e0 ad0s7c 5 r0w0e0 ad0s7a 5 r0w0e0 ad0s8 4 r0w0e0 ad0s7 4 r0w0e0 ad0s6 4 r0w0e0 ad0s5 4 r0w0e0 ad0s2e 4 r0w0e0 ad0s2d 4 r0w0e0 ad0s2c 4 r0w0e0 ad0s2b 4 r0w0e0 ad0s2a 4 r0w0e0 ad0s3 3 r0w0e0 ad0s2 3 r0w0e0 ad0s1 3 r0w0e0 ad0 2 r0w0e0 A non-working kernel(GENERIC): ACD acd0 1 r0w0e0 acd0 8796093020160 2048 FD SWAP swap 4 r1w1e0 DEV ufsid/46387cd73d66d2ca 5 r0w0e0 acd0 2 r0w0e0 ad0s2e 4 r0w0e0 ad0s2d 4 r0w0e0 ad0s2b 4 r0w0e0 ad0s2a 4 r0w0e0 msdosfs/IBM_PRELOAD 4 r0w0e0 ad0s3 3 r0w0e0 ad0s2 3 r0w0e0 ad0s1 3 r0w0e0 ad0 2 r0w0e0 MD PART ad0s2 3 BSD 8 0 16783199 63 16 r3w3e5 r1w1e1 ad0s2e 5841534976 512 5373952 16783199 5 freebsd-ufs 2751463424 5841534976 7 r0w0e0 ad0s2d 201326592 512 4980736 5373951 4 freebsd-ufs 2550136832 201326592 7 r1w1e0 ad0s2b 2147483648 512 786432 4980735 2 freebsd-swap 402653184 2147483648 1 r1w1e1 ad0s2a 402653184 512 0 786431 1 freebsd-ufs 0 402653184 7 ad0 2 MBR 4 63 228338837 63 16 r3w3e8 r0w0e0 ad0s3 98742067200 512 35471520 228327119 3 !15 18161418240 98742067200 15 r3w3e5 ad0s2 8592998400 512 18688320 35471519 2 freebsd 9568419840 8592998400 165 active r0w0e0 ad0s1 9568387584 512 63 18688319 1 !12 32256 9568387584 12 DISK ad0 1 r3w3e8 ad0 116909491200 512 16 63 LABEL ad0s2d 4 r0w0e0 r0w0e0 ufsid/46387cd73d66d2ca 201326592 512 0 201326592 393216 0 0 ad0s1 3 r0w0e0 r0w0e0 msdosfs/IBM_PRELOAD 9568387584 512 0 9568387584 18688257 0 0 VFS ffs.ad0s2e 4 r1w1e1 ffs.ad0s2a 4 r1w1e1 -- Thanks, Tai-hwa Liang From owner-freebsd-current@FreeBSD.ORG Fri Apr 3 02:43: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 718D0106564A for ; Fri, 3 Apr 2009 02:43:07 +0000 (UTC) (envelope-from joseph.koshy@gmail.com) Received: from wf-out-1314.google.com (wf-out-1314.google.com [209.85.200.168]) by mx1.freebsd.org (Postfix) with ESMTP id 4679D8FC15 for ; Fri, 3 Apr 2009 02:43:07 +0000 (UTC) (envelope-from joseph.koshy@gmail.com) Received: by wf-out-1314.google.com with SMTP id 24so863013wfg.7 for ; Thu, 02 Apr 2009 19:43:06 -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=eN2BD4wOWTnvXkGb3+/dqwiHU1zItB0UJvOpdSRrkTc=; b=BPSqhoOlMDw9ft9qrEXdz9q45i5DjNsoYzQlmA3fNgCI9iNrmvAlzXnXtrbSFx12z0 Q/SB1k10wr7k+zY/FYLoHky8yEECrgvtsHIyIOygvbtJ5lh56rLMnCsD4zHj1YMRGKcL UVgLYugW0bGS6LcIIhwv8RcQDxnjChOmfsQFU= 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=c4qjQSHsBOGB2RYElh5QbzhklMjHr/3n1MZQucCm2iu4gwBeUSNQ/+1+szvctL0hJl fBtO+HArzg6D+K35JCDyFDIh4vIjVjSkfGU8k4qEWWIrcW/Xxb5KpPJSeyhfQzJ1szTH CxSHu+sBenZZ9sy51g5z/k8ckrMQi2ufVEt6k= MIME-Version: 1.0 Received: by 10.142.11.20 with SMTP id 20mr163323wfk.197.1238724789796; Thu, 02 Apr 2009 19:13:09 -0700 (PDT) In-Reply-To: <4451ccf20904010038p64ed2540mec3249f89bb7b8c2@mail.gmail.com> References: <4451ccf20904010038p64ed2540mec3249f89bb7b8c2@mail.gmail.com> Date: Fri, 3 Apr 2009 07:43:09 +0530 Message-ID: <84dead720904021913t1f1c27dasd942c50213e2a83a@mail.gmail.com> From: Joseph Koshy To: =?ISO-2022-JP?B?GyRCVkM0ZBsoQmNjdWl5eWFuQHNpbmEuY29t?= Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: Performance Tools in FreeBSD 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, 03 Apr 2009 02:43:07 -0000 > However, PMC seems not to be supported in AMD Opteron CPU because i > get a "invalid arguments" error when > > i use the command pmcstat -S instructions -O . However, > "instructions, cycles,..." are documented in > > pmc manual. By the way, I enable the options in configuration file > options HWPMC_HOOKS and device hwpmc. What kind of CPU do you have? Are there any messages from hwpmc(4) when it initializes? Koshy From owner-freebsd-current@FreeBSD.ORG Fri Apr 3 02:44: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 2CF45106566B for ; Fri, 3 Apr 2009 02:44:19 +0000 (UTC) (envelope-from lists.br@gmail.com) Received: from mail-gx0-f176.google.com (mail-gx0-f176.google.com [209.85.217.176]) by mx1.freebsd.org (Postfix) with ESMTP id D69368FC1A for ; Fri, 3 Apr 2009 02:44:18 +0000 (UTC) (envelope-from lists.br@gmail.com) Received: by gxk24 with SMTP id 24so2534375gxk.19 for ; Thu, 02 Apr 2009 19:44:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:from:to:references :subject:date:mime-version:content-type:content-transfer-encoding :x-priority:x-msmail-priority:x-mailer:x-mimeole; bh=POUUBiZcV/deoq9DpuhokZ8HgbpWREf8lXpWNHQF7hM=; b=gY0zHkmKzwhpT96HU27kFnj4QReqm4G+5kvhY/51hT0OygEzT56RnXWy0B5aYoCxua oRlptluOs3C/Lm5hJ3AU0Y7GVgbfWsPIPHRDfJEPqyuAJy//6XMTLtbxo0CYbbCF10oY 2yvFpTVWMDYWLZu3PREonJv9MFTYx1uE4Bq4Q= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:from:to:references:subject:date:mime-version :content-type:content-transfer-encoding:x-priority:x-msmail-priority :x-mailer:x-mimeole; b=PVMh4w9hKCxXqHujqOy7yiQdv7VZVq8Ligqk1kGqqbdTaZFQ5o9h29eY3Jc9VN4G9n 2U8MI1xsERYa4noK7UWnGfgEYAraqGDfUwgS2yasWtW5ESJvZkfzKooCmAiYdkfh1TN8 RRwJrSuME39RgRL0Z2Z2DAPUq8kFTVCQgQb5I= Received: by 10.90.117.17 with SMTP id p17mr416991agc.5.1238725350979; Thu, 02 Apr 2009 19:22:30 -0700 (PDT) Received: from adnote989 (201-42-156-231.dsl.telesp.net.br [201.42.156.231]) by mx.google.com with ESMTPS id 7sm2531663agd.1.2009.04.02.19.22.28 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 02 Apr 2009 19:22:30 -0700 (PDT) Message-ID: From: "Luiz Otavio O Souza" To: "Thomas Wahyudi" , References: <3FD46C21A487490FB15B89E890790121@adnote989><49D4C9A0.9000804@freebsdbrasil.com.br> <49D56212.1000702@sanbe-farma.com> Date: Thu, 2 Apr 2009 23:22:05 -0300 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5512 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 X-Mailman-Approved-At: Fri, 03 Apr 2009 03:10:20 +0000 Cc: Subject: Re: Setting the mss for socket 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, 03 Apr 2009 02:44:19 -0000 > Patrick Tracanelli wrote: >> Luiz Otavio O Souza escreveu: >>> Hello hackers, >>> >>> Is there a way to set the mss for a socket ? Like you can do in linux >>> with setsockopt(TCP_MAXSEG) ? >>> >>> So i can set the maximum size of packets (or sort of) from a simple >>> userland program. >>> > you mean sysctl -w net.inet.tcp.mssdflt=512 ? Not really... I don't want this to be a system wide option, i need this to be able to generate some traffic under a certain pattern of packet sizes. I really should read the code for more than 30 minutes... it's simple than i first think, i already have a simple patch for this, but it is too ugly for anything more than get iperf running... This is the patch (just for reference - may work for someone else): http://pastebin.com/m706da25b And the iperf patch: http://pastebin.com/m2f8f1100 Luiz From owner-freebsd-current@FreeBSD.ORG Fri Apr 3 04:44: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 68A281065673 for ; Fri, 3 Apr 2009 04:44:09 +0000 (UTC) (envelope-from xcllnt@mac.com) Received: from asmtpout020.mac.com (asmtpout020.mac.com [17.148.16.95]) by mx1.freebsd.org (Postfix) with ESMTP id 47F728FC17 for ; Fri, 3 Apr 2009 04:44:09 +0000 (UTC) (envelope-from xcllnt@mac.com) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Received: from MacBook-Pro.lan.xcllnt.net (mail.xcllnt.net [75.101.29.67]) by asmtp020.mac.com (Sun Java(tm) System Messaging Server 6.3-8.01 (built Dec 16 2008; 32bit)) with ESMTPSA id <0KHI000QJD5F5610@asmtp020.mac.com> for freebsd-current@freebsd.org; Thu, 02 Apr 2009 21:44:04 -0700 (PDT) Message-id: From: Marcel Moolenaar To: Tai-hwa Liang In-reply-to: <09040309313414.76643@www.mmlab.cse.yzu.edu.tw> Date: Thu, 02 Apr 2009 21:44:02 -0700 References: <95891.1238477069@critter.freebsd.dk> <20090331133132.1e191836@ernst.jennejohn.org> <20090331155542.74d89d64@ernst.jennejohn.org> <60084D1E-9F64-463A-A8E9-7A237D5C7661@mac.com> <0904011910169.29800@www.mmlab.cse.yzu.edu.tw> <0904020940371.36257@www.mmlab.cse.yzu.edu.tw> <4CCDEFD6-830E-4C8F-B7A2-B7878F8842BE@mac.com> <0904021314574.37737@www.mmlab.cse.yzu.edu.tw> <09040309313414.76643@www.mmlab.cse.yzu.edu.tw> X-Mailer: Apple Mail (2.930.3) Cc: freebsd-current@freebsd.org Subject: Re: Removal of GEOM_BSD, GEOM_MBR, GEOM_PC98 and GEOM_SUNLABEL 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, 03 Apr 2009 04:44:10 -0000 On Apr 2, 2009, at 6:35 PM, Tai-hwa Liang wrote: > On Thu, 2 Apr 2009, Marcel Moolenaar wrote: >> Can you dump the first 2 sectors of slice 3 and >> send it to me: >> dd if=/dev/ad0s3 of=/tmp/dump.dd count=2 bs=512 *snip* > 000001b0 00 00 00 00 00 f2 0e 00 00 00 00 00 00 00 00 01 > |................| > 000001c0 c1 ff 83 ef ff ff 3f 00 00 00 21 17 00 01 00 00 > |......?...!.....| > 000001d0 c1 ff 05 ef ff ff 60 17 00 01 b0 a8 fe 02 00 00 > |......`.........| > 000001e0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > |................| > 000001f0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 55 aa > |..............U.| *snip* It looks like you have a boot menu entry at 0x1b6. Can you try the following patch: Index: g_part_ebr.c =================================================================== --- g_part_ebr.c (revision 190655) +++ g_part_ebr.c (working copy) @@ -403,9 +403,13 @@ if (magic != DOSMAGIC) goto out; - /* The sector is all zeroes, except for the partition entries. */ + /* + * The sector is all zeroes, except for the partition entries + * and a possible IBM Boot Manager menu entry. The menu entry + * is 9 bytes in length and preceeds the partition entries. + */ sum = 0; - for (index = 0; index < DOSPARTOFF; index++) + for (index = 0; index < DOSPARTOFF - 9; index++) sum += buf[index]; if (sum != 0) goto out; The real fix will be a bit more involved, because we should avoid wiping out the boot menu entry on a write. But at least with the patch you should be able to read the EBR. Thanks, -- Marcel Moolenaar xcllnt@mac.com From owner-freebsd-current@FreeBSD.ORG Fri Apr 3 05:29: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 62BFC106566C for ; Fri, 3 Apr 2009 05:29:56 +0000 (UTC) (envelope-from avatar@mmlab.cse.yzu.edu.tw) Received: from www.mmlab.cse.yzu.edu.tw (www.mmlab.cse.yzu.edu.tw [140.138.150.166]) by mx1.freebsd.org (Postfix) with ESMTP id 0331E8FC12 for ; Fri, 3 Apr 2009 05:29:55 +0000 (UTC) (envelope-from avatar@mmlab.cse.yzu.edu.tw) Received: by www.mmlab.cse.yzu.edu.tw (qmail, from userid 1000) id 7C561E43407; Fri, 3 Apr 2009 13:29:33 +0800 (CST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=mmlab.cse.yzu.edu.tw; s=test; t=1238736573; bh=xkEwjNWv9NwEVosWiIzFGWv72xwgTkxNGaPmnVJVgNc=; h=Date:From:To:cc:Subject:In-Reply-To:Message-ID:References: MIME-Version:Content-Type; b=s1UYl+eNTUfHs+WMX2jefw5bcZ/nsB71xOwN/p1IgqIUphoH5VrzUBcCApiM1y5ap ERHJPiz4k8wU/7bSPizbFDVKuOphQBcTg9/drT67I6nd0JhvA9FKmEW5djbkIBt+zK q/+IuWTJAsYl2tO0RJ4f0vxUlMywX26lLb5OY/04= Received: from localhost (localhost [127.0.0.1]) by www.mmlab.cse.yzu.edu.tw (qmail) with ESMTP id 7A8F6E43406; Fri, 3 Apr 2009 13:29:33 +0800 (CST) Date: Fri, 3 Apr 2009 13:29:33 +0800 (CST) From: Tai-hwa Liang To: Marcel Moolenaar In-Reply-To: Message-ID: <0904031327195.78401@www.mmlab.cse.yzu.edu.tw> References: <95891.1238477069@critter.freebsd.dk> <20090331133132.1e191836@ernst.jennejohn.org> <20090331155542.74d89d64@ernst.jennejohn.org> <60084D1E-9F64-463A-A8E9-7A237D5C7661@mac.com> <0904011910169.29800@www.mmlab.cse.yzu.edu.tw> <0904020940371.36257@www.mmlab.cse.yzu.edu.tw> <4CCDEFD6-830E-4C8F-B7A2-B7878F8842BE@mac.com> <0904021314574.37737@www.mmlab.cse.yzu.edu.tw> <09040309313414.76643@www.mmlab.cse.yzu.edu.tw> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-current@freebsd.org Subject: Re: Removal of GEOM_BSD, GEOM_MBR, GEOM_PC98 and GEOM_SUNLABEL 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, 03 Apr 2009 05:29:56 -0000 On Thu, 2 Apr 2009, Marcel Moolenaar wrote: [...] > It looks like you have a boot menu entry at 0x1b6. Can you > try the following patch: > > Index: g_part_ebr.c > =================================================================== > --- g_part_ebr.c (revision 190655) > +++ g_part_ebr.c (working copy) > @@ -403,9 +403,13 @@ > if (magic != DOSMAGIC) > goto out; > > - /* The sector is all zeroes, except for the partition entries. */ > + /* > + * The sector is all zeroes, except for the partition entries > + * and a possible IBM Boot Manager menu entry. The menu entry > + * is 9 bytes in length and preceeds the partition entries. > + */ > sum = 0; > - for (index = 0; index < DOSPARTOFF; index++) > + for (index = 0; index < DOSPARTOFF - 9; index++) > sum += buf[index]; > if (sum != 0) > goto out; > > > The real fix will be a bit more involved, because we should > avoid wiping out the boot menu entry on a write. But at least > with the patch you should be able to read the EBR. Much better. I can see extended partition nodes after booting with the patched kernel: # ls -la /dev/ad* crw-r----- 1 root operator 0, 73 4 3 21:12 /dev/ad0 crw-r----- 1 root operator 0, 79 4 3 21:12 /dev/ad0s1 crw-r----- 1 root operator 0, 80 4 3 21:12 /dev/ad0s2 crw-r----- 1 root operator 0, 82 4 3 21:12 /dev/ad0s2a crw-r----- 1 root operator 0, 83 4 3 21:12 /dev/ad0s2b crw-r----- 1 root operator 0, 84 4 3 21:12 /dev/ad0s2d crw-r----- 1 root operator 0, 85 4 3 21:12 /dev/ad0s2e crw-r----- 1 root operator 0, 81 4 3 21:12 /dev/ad0s3 crw-r----- 1 root operator 0, 86 4 3 21:12 /dev/ad0s3+00000001 crw-r----- 1 root operator 0, 88 4 3 21:12 /dev/ad0s3+000410a1 crw-r----- 1 root operator 0, 90 4 3 21:12 /dev/ad0s3+00103bf1 crw-r----- 1 root operator 0, 92 4 3 21:12 /dev/ad0s3+0017cda1 lrwxr-xr-x 1 root wheel 14 4 3 21:12 /dev/ad0s5 -> ad0s3+00000001 lrwxr-xr-x 1 root wheel 14 4 3 21:12 /dev/ad0s6 -> ad0s3+000410a1 lrwxr-xr-x 1 root wheel 14 4 3 21:12 /dev/ad0s7 -> ad0s3+00103bf1 lrwxr-xr-x 1 root wheel 14 4 3 21:12 /dev/ad0s8 -> ad0s3+0017cda1 # gpart show => 63 228338775 ad0 MBR (109G) 63 18688257 1 !12 (8.9G) 18688320 16783200 2 freebsd [active] (8.0G) 35471520 192855600 3 !15 (92G) 228327120 11718 - free - (5.7M) => 0 16783200 ad0s2 BSD (8.0G) 0 786432 1 freebsd-ufs (384M) 786432 4194304 2 freebsd-swap (2.0G) 4980736 393216 4 freebsd-ufs (192M) 5373952 11409248 5 freebsd-ufs (5.4G) => 0 192855600 ad0s3 EBR (92G) 0 16783200 1 !131 (8.0G) 16783200 50243760 266401 !11 (24G) 67026960 31251024 1063921 freebsd (15G) 98277984 94577616 1559969 freebsd (45G) The only downside is that I'll have to update /etc/fstab to boot correctly as /dev/ad0s7a is still missing. -- Thanks, Tai-hwa Liang From owner-freebsd-current@FreeBSD.ORG Fri Apr 3 06:00: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 8A052106566B for ; Fri, 3 Apr 2009 06:00:03 +0000 (UTC) (envelope-from xcllnt@mac.com) Received: from asmtpout013.mac.com (asmtpout013.mac.com [17.148.16.88]) by mx1.freebsd.org (Postfix) with ESMTP id 65F408FC26 for ; Fri, 3 Apr 2009 06:00:03 +0000 (UTC) (envelope-from xcllnt@mac.com) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Received: from MacBook-Pro.lan.xcllnt.net (mail.xcllnt.net [75.101.29.67]) by asmtp013.mac.com (Sun Java(tm) System Messaging Server 6.3-8.01 (built Dec 16 2008; 32bit)) with ESMTPSA id <0KHI00456GN36C30@asmtp013.mac.com> for freebsd-current@freebsd.org; Thu, 02 Apr 2009 22:59:28 -0700 (PDT) Message-id: <8583A3BA-2871-4DF4-9792-1031044A4A22@mac.com> From: Marcel Moolenaar To: Tai-hwa Liang In-reply-to: <0904031327195.78401@www.mmlab.cse.yzu.edu.tw> Date: Thu, 02 Apr 2009 22:59:26 -0700 References: <95891.1238477069@critter.freebsd.dk> <20090331133132.1e191836@ernst.jennejohn.org> <20090331155542.74d89d64@ernst.jennejohn.org> <60084D1E-9F64-463A-A8E9-7A237D5C7661@mac.com> <0904011910169.29800@www.mmlab.cse.yzu.edu.tw> <0904020940371.36257@www.mmlab.cse.yzu.edu.tw> <4CCDEFD6-830E-4C8F-B7A2-B7878F8842BE@mac.com> <0904021314574.37737@www.mmlab.cse.yzu.edu.tw> <09040309313414.76643@www.mmlab.cse.yzu.edu.tw> <0904031327195.78401@www.mmlab.cse.yzu.edu.tw> X-Mailer: Apple Mail (2.930.3) Cc: freebsd-current@freebsd.org Subject: Re: Removal of GEOM_BSD, GEOM_MBR, GEOM_PC98 and GEOM_SUNLABEL 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, 03 Apr 2009 06:00:03 -0000 On Apr 2, 2009, at 10:29 PM, Tai-hwa Liang wrote: >> The real fix will be a bit more involved, because we should >> avoid wiping out the boot menu entry on a write. But at least >> with the patch you should be able to read the EBR. > > Much better. I can see extended partition nodes after booting with > the > patched kernel: I dug a bit deeper and it's not a boot manager menu entry, but some signature particular to some tool. I'm not going to worry about preserving that. Patch committed. *snip* > => 0 192855600 ad0s3 EBR (92G) > 0 16783200 1 !131 (8.0G) > 16783200 50243760 266401 !11 (24G) > 67026960 31251024 1063921 freebsd (15G) > 98277984 94577616 1559969 freebsd (45G) > > The only downside is that I'll have to update /etc/fstab to boot > correctly > as /dev/ad0s7a is still missing. Ok, let's look at those sectors as well. Can you send the output of: dd if=/dev/ad0s7 of=dump.dd count=2 bs=512 BTW: Thanks for testing! -- Marcel Moolenaar xcllnt@mac.com From owner-freebsd-current@FreeBSD.ORG Fri Apr 3 07:18: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 7D6931065675 for ; Fri, 3 Apr 2009 07:18:59 +0000 (UTC) (envelope-from avatar@mmlab.cse.yzu.edu.tw) Received: from www.mmlab.cse.yzu.edu.tw (www.mmlab.cse.yzu.edu.tw [140.138.150.166]) by mx1.freebsd.org (Postfix) with ESMTP id 396AA8FC1B for ; Fri, 3 Apr 2009 07:18:59 +0000 (UTC) (envelope-from avatar@mmlab.cse.yzu.edu.tw) Received: by www.mmlab.cse.yzu.edu.tw (qmail, from userid 1000) id 8FD22E43407; Fri, 3 Apr 2009 15:18:36 +0800 (CST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=mmlab.cse.yzu.edu.tw; s=test; t=1238743116; bh=r73zju83p8MLkCr/DI28mYyPfSnXt3eRrlYZVHGzSk8=; h=Date:From:To:cc:Subject:In-Reply-To:Message-ID:References: MIME-Version:Content-Type; b=uXI4POXeaMWdrrD1UdSBTvtQoO+q+LN3EtQDdxm+gsv98A5Up3JRSa2sbK+23tuac i49l3vQs5KqTH0g9oJ+b788xDanECQuiMkPGd2LcrsIVFM85cMpVRAFCj9IE7Im2mU UwTH9hjoeDSGbINw9bSD5CcmzD0d86V6d/9O+JCs= Received: from localhost (localhost [127.0.0.1]) by www.mmlab.cse.yzu.edu.tw (qmail) with ESMTP id 8E1A0E43406; Fri, 3 Apr 2009 15:18:36 +0800 (CST) Date: Fri, 3 Apr 2009 15:18:36 +0800 (CST) From: Tai-hwa Liang To: Marcel Moolenaar In-Reply-To: <8583A3BA-2871-4DF4-9792-1031044A4A22@mac.com> Message-ID: <09040315161311.79260@www.mmlab.cse.yzu.edu.tw> References: <95891.1238477069@critter.freebsd.dk> <20090331133132.1e191836@ernst.jennejohn.org> <20090331155542.74d89d64@ernst.jennejohn.org> <60084D1E-9F64-463A-A8E9-7A237D5C7661@mac.com> <0904011910169.29800@www.mmlab.cse.yzu.edu.tw> <0904020940371.36257@www.mmlab.cse.yzu.edu.tw> <4CCDEFD6-830E-4C8F-B7A2-B7878F8842BE@mac.com> <0904021314574.37737@www.mmlab.cse.yzu.edu.tw> <09040309313414.76643@www.mmlab.cse.yzu.edu.tw> <0904031327195.78401@www.mmlab.cse.yzu.edu.tw> <8583A3BA-2871-4DF4-9792-1031044A4A22@mac.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-current@freebsd.org Subject: Re: Removal of GEOM_BSD, GEOM_MBR, GEOM_PC98 and GEOM_SUNLABEL 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, 03 Apr 2009 07:18:59 -0000 On Thu, 2 Apr 2009, Marcel Moolenaar wrote: > > On Apr 2, 2009, at 10:29 PM, Tai-hwa Liang wrote: > >>> The real fix will be a bit more involved, because we should >>> avoid wiping out the boot menu entry on a write. But at least >>> with the patch you should be able to read the EBR. >> >> Much better. I can see extended partition nodes after booting with the >> patched kernel: > > I dug a bit deeper and it's not a boot manager menu entry, > but some signature particular to some tool. I'm not going > to worry about preserving that. > > Patch committed. Thanks! > *snip* >> => 0 192855600 ad0s3 EBR (92G) >> 0 16783200 1 !131 (8.0G) >> 16783200 50243760 266401 !11 (24G) >> 67026960 31251024 1063921 freebsd (15G) >> 98277984 94577616 1559969 freebsd (45G) >> >> The only downside is that I'll have to update /etc/fstab to boot correctly >> as /dev/ad0s7a is still missing. > > Ok, let's look at those sectors as well. Can you send the > output of: > dd if=/dev/ad0s7 of=dump.dd count=2 bs=512 00000000 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| * 00000200 57 45 56 82 00 00 00 00 61 6d 6e 65 73 69 61 63 |WEV.....amnesiac| 00000210 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 00000220 00 00 00 00 00 00 00 00 00 02 00 00 3f 00 00 00 |............?...| 00000230 10 00 00 00 1a 79 00 00 f0 03 00 00 11 da dc 01 |.....y..........| 00000240 00 00 00 00 00 00 00 00 10 0e 01 00 00 00 00 00 |................| 00000250 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| * 00000280 00 00 00 00 57 45 56 82 93 e0 08 00 00 20 00 00 |....WEV...... ..| 00000290 00 00 00 00 01 da dc 01 a0 40 1d 02 00 08 00 00 |.........@......| 000002a0 07 08 88 6f 00 00 00 00 00 00 00 00 00 00 00 00 |...o............| 000002b0 00 00 00 00 11 da dc 01 a0 40 1d 02 00 00 00 00 |.........@......| 000002c0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| * 00000400 > BTW: Thanks for testing! Thanks for fixing! :) -- Cheers, Tai-hwa Liang From owner-freebsd-current@FreeBSD.ORG Fri Apr 3 07:28:55 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 C1B84106564A for ; Fri, 3 Apr 2009 07:28:55 +0000 (UTC) (envelope-from randy@psg.com) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by mx1.freebsd.org (Postfix) with ESMTP id A013E8FC18 for ; Fri, 3 Apr 2009 07:28:55 +0000 (UTC) (envelope-from randy@psg.com) Received: from localhost ([127.0.0.1] helo=rmac.psg.om) by ran.psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Lpdpe-00028S-OO for current@freebsd.org; Fri, 03 Apr 2009 07:28:55 +0000 Received: from rmac.local.psg.com (localhost [127.0.0.1]) by rmac.psg.om (Postfix) with ESMTP id 38E4077516D for ; Fri, 3 Apr 2009 16:28:54 +0900 (JST) Date: Fri, 03 Apr 2009 16:28:54 +0900 Message-ID: From: Randy Bush To: current References: User-Agent: Wanderlust/2.15.5 (Almost Unreal) SEMI/1.14.6 (Maruoka) FLIM/1.14.9 (=?ISO-8859-4?Q?Goj=F2?=) APEL/10.7 Emacs/22.3 (i386-apple-darwin9.6.0) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: Subject: zfs chflags 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, 03 Apr 2009 07:28:56 -0000 very up to date 7 i386 system :/usr/src# time make installworld 2>&1 > installworld.log install: /usr/lib/libkse.so.3: chflags: Operation not supported install: /usr/lib/librt.so.1: chflags: Operation not supported chflags: /usr/bin/chpass: Operation not supported install: /usr/bin/login: chflags: Operation not supported install: /usr/bin/opieinfo: chflags: Operation not supported install: /usr/bin/opiepasswd: chflags: Operation not supported chflags: /usr/bin/passwd: Operation not supported install: /usr/bin/rlogin: chflags: Operation not supported install: /usr/bin/rsh: chflags: Operation not supported install: /usr/bin/su: chflags: Operation not supported install: /usr/bin/crontab: chflags: Operation not supported install: /usr/sbin/sliplogin: chflags: Operation not supported shown as "done" on http://wiki.freebsd.org/ZFS, but i think that is only for 8-current, and it does work on my 8-current systems. in the archives, there is a message which says "For the record, defining NO_FSCHG= would work around this." but it does not say what goes to the right of the "=" and may i assume this is to make installworld? so choices seem to be o move to 8-current o dig up some patch to zfs 13 and rebuild o get clue from mailing list randy From owner-freebsd-current@FreeBSD.ORG Fri Apr 3 09:22:24 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 EBE11106566C for ; Fri, 3 Apr 2009 09:22:23 +0000 (UTC) (envelope-from dzentoo@gmail.com) Received: from mail-fx0-f167.google.com (mail-fx0-f167.google.com [209.85.220.167]) by mx1.freebsd.org (Postfix) with ESMTP id 4EFCA8FC18 for ; Fri, 3 Apr 2009 09:22:22 +0000 (UTC) (envelope-from dzentoo@gmail.com) Received: by fxm11 with SMTP id 11so856457fxm.43 for ; Fri, 03 Apr 2009 02:22:22 -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=rohxz34gYR+H19Yirjr9lybLFvR6jc30SYoWs0LDpgM=; b=WVSJHSiD3UCYKDOLy/N6QFnZOIv3AnFA+6tRViLuqyfqFU/dXBroOdzLF9LoK9CfXt VHum/RL55jJYYOz59g5fN5+R4FK3rNDSla/pnZexg0fMPrqxkfBYgxH18h7w8CTI3PLo +f1laTKTo4MOHUxyMrWy1LP/mW1FWizAHi0l4= 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=v9oV/bPuxBUdkBmsYrrj2obTFfppAbGnUeHeJlAPdksLQEDR/k4LV7+5SXdWAQuBYV CTaYshT6+U3pUdC4ENvfhV9xsbuaN7S3Oqc2dr307SkuMcBzwXClD6YOpbOTsvM2KBuV ookJ2S9gIUYGGqDBputgexKEAWc5kBOyDEWVI= MIME-Version: 1.0 Sender: dzentoo@gmail.com Received: by 10.103.241.15 with SMTP id t15mr460464mur.85.1238749015806; Fri, 03 Apr 2009 01:56:55 -0700 (PDT) In-Reply-To: References: Date: Fri, 3 Apr 2009 10:56:55 +0200 X-Google-Sender-Auth: e97f693a47e35864 Message-ID: <3481d8e60904030156n7b77b223p429313b9621f6d95@mail.gmail.com> From: Benoit Calvez To: Randy Bush Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: current Subject: Re: zfs chflags 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, 03 Apr 2009 09:22:24 -0000 On Fri, Apr 3, 2009 at 9:28 AM, Randy Bush wrote: > very up to date 7 i386 system > > :/usr/src# time make installworld 2>&1 > installworld.log > install: /usr/lib/libkse.so.3: chflags: Operation not supported > install: /usr/lib/librt.so.1: chflags: Operation not supported > chflags: /usr/bin/chpass: Operation not supported > install: /usr/bin/login: chflags: Operation not supported > install: /usr/bin/opieinfo: chflags: Operation not supported > install: /usr/bin/opiepasswd: chflags: Operation not supported > chflags: /usr/bin/passwd: Operation not supported > install: /usr/bin/rlogin: chflags: Operation not supported > install: /usr/bin/rsh: chflags: Operation not supported > install: /usr/bin/su: chflags: Operation not supported > install: /usr/bin/crontab: chflags: Operation not supported > install: /usr/sbin/sliplogin: chflags: Operation not supported > > shown as "done" on http://wiki.freebsd.org/ZFS, but i think that > is only for 8-current, and it does work on my 8-current systems. > > in the archives, there is a message which says "For the record, defining > NO_FSCHG= would work around this." but it does not say what goes to the > right of the "=" and may i assume this is to make installworld? > > so choices seem to be > o move to 8-current > o dig up some patch to zfs 13 and rebuild > o get clue from mailing list > > randy > _______________________________________________ > 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" > Yes, it just defines the variables, but the var is empty. -- Benoit C From owner-freebsd-current@FreeBSD.ORG Fri Apr 3 15:45: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 F34171065672 for ; Fri, 3 Apr 2009 15:45:07 +0000 (UTC) (envelope-from xcllnt@mac.com) Received: from asmtpout014.mac.com (asmtpout014.mac.com [17.148.16.89]) by mx1.freebsd.org (Postfix) with ESMTP id D38D38FC21 for ; Fri, 3 Apr 2009 15:45:07 +0000 (UTC) (envelope-from xcllnt@mac.com) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Received: from hsheth-mbp.jnpr.net (natint3.juniper.net [66.129.224.36]) by asmtp014.mac.com (Sun Java(tm) System Messaging Server 6.3-8.01 (built Dec 16 2008; 32bit)) with ESMTPSA id <0KHJ00EFT7QGCO60@asmtp014.mac.com> for freebsd-current@freebsd.org; Fri, 03 Apr 2009 08:44:41 -0700 (PDT) Message-id: <1DDB4728-7742-4265-999F-F1A0FC69F9E4@mac.com> From: Marcel Moolenaar To: Tai-hwa Liang In-reply-to: <09040315161311.79260@www.mmlab.cse.yzu.edu.tw> Date: Fri, 03 Apr 2009 08:44:40 -0700 References: <95891.1238477069@critter.freebsd.dk> <20090331133132.1e191836@ernst.jennejohn.org> <20090331155542.74d89d64@ernst.jennejohn.org> <60084D1E-9F64-463A-A8E9-7A237D5C7661@mac.com> <0904011910169.29800@www.mmlab.cse.yzu.edu.tw> <0904020940371.36257@www.mmlab.cse.yzu.edu.tw> <4CCDEFD6-830E-4C8F-B7A2-B7878F8842BE@mac.com> <0904021314574.37737@www.mmlab.cse.yzu.edu.tw> <09040309313414.76643@www.mmlab.cse.yzu.edu.tw> <0904031327195.78401@www.mmlab.cse.yzu.edu.tw> <8583A3BA-2871-4DF4-9792-1031044A4A22@mac.com> <09040315161311.79260@www.mmlab.cse.yzu.edu.tw> X-Mailer: Apple Mail (2.930.3) Cc: freebsd-current@freebsd.org Subject: Re: Removal of GEOM_BSD, GEOM_MBR, GEOM_PC98 and GEOM_SUNLABEL 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, 03 Apr 2009 15:45:08 -0000 On Apr 3, 2009, at 12:18 AM, Tai-hwa Liang wrote: >> Ok, let's look at those sectors as well. Can you send the >> output of: >> dd if=/dev/ad0s7 of=dump.dd count=2 bs=512 > > 00000000 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > |................| > * > 00000200 57 45 56 82 00 00 00 00 61 6d 6e 65 73 69 61 63 | > WEV.....amnesiac| > 00000210 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > |................| > 00000220 00 00 00 00 00 00 00 00 00 02 00 00 3f 00 00 00 > |............?...| > 00000230 10 00 00 00 1a 79 00 00 f0 03 00 00 11 da dc 01 > |.....y..........| > 00000240 00 00 00 00 00 00 00 00 10 0e 01 00 00 00 00 00 > |................| > 00000250 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > |................| > * > 00000280 00 00 00 00 57 45 56 82 93 e0 08 00 00 20 00 00 > |....WEV...... ..| > 00000290 00 00 00 00 01 da dc 01 a0 40 1d 02 00 08 00 00 > |.........@......| > 000002a0 07 08 88 6f 00 00 00 00 00 00 00 00 00 00 00 00 > |...o............| > 000002b0 00 00 00 00 11 da dc 01 a0 40 1d 02 00 00 00 00 > |.........@......| > 000002c0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > |................| > * > 00000400 Hmmmm... I don't think there's anything wrong with the label nor the code. If the label is rejected, the dmesg should show that. Is there anything in the dmesg like? GEOM: ad0s3+00103bf1: invalid disklabel. Also, could you trigger a re-taste by writing all zeroes to the first sector: dd if=/dev/zero of=/dev/ad0s7 count=1 bs=512 Thanks, -- Marcel Moolenaar xcllnt@mac.com From owner-freebsd-current@FreeBSD.ORG Sat Apr 4 01:08: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 2A16A106566C for ; Sat, 4 Apr 2009 01:08:24 +0000 (UTC) (envelope-from avatar@mmlab.cse.yzu.edu.tw) Received: from www.mmlab.cse.yzu.edu.tw (www.mmlab.cse.yzu.edu.tw [140.138.150.166]) by mx1.freebsd.org (Postfix) with ESMTP id D88828FC0A for ; Sat, 4 Apr 2009 01:08:23 +0000 (UTC) (envelope-from avatar@mmlab.cse.yzu.edu.tw) Received: by www.mmlab.cse.yzu.edu.tw (qmail, from userid 1000) id 93593E43407; Sat, 4 Apr 2009 09:08:00 +0800 (CST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=mmlab.cse.yzu.edu.tw; s=test; t=1238807280; bh=rFgpPEYGk/L/9dYpfnmhrqEBCff3sJjZx/0DzVy/pxA=; h=Date:From:To:cc:Subject:In-Reply-To:Message-ID:References: MIME-Version:Content-Type; b=GDAeanpPV4Auff1/9LVBlRV4j2A61I3faLmbQeZDy8UXn6my67GOqcuI7ZwicjSZV UJXlxo0R4vTa+wnzxGu5OMDaXfHQs1bP7uB6sD4wAAWohmpRqm7y4dYmSqT/QDYFef 2HB6nbLhr2x9y+QdF4U6QLyLqoRCsHFWVv9Si6EU= Received: from localhost (localhost [127.0.0.1]) by www.mmlab.cse.yzu.edu.tw (qmail) with ESMTP id 91857E43406; Sat, 4 Apr 2009 09:08:00 +0800 (CST) Date: Sat, 4 Apr 2009 09:08:00 +0800 (CST) From: Tai-hwa Liang To: Marcel Moolenaar In-Reply-To: <1DDB4728-7742-4265-999F-F1A0FC69F9E4@mac.com> Message-ID: <0904040858433.86299@www.mmlab.cse.yzu.edu.tw> References: <95891.1238477069@critter.freebsd.dk> <20090331133132.1e191836@ernst.jennejohn.org> <20090331155542.74d89d64@ernst.jennejohn.org> <60084D1E-9F64-463A-A8E9-7A237D5C7661@mac.com> <0904011910169.29800@www.mmlab.cse.yzu.edu.tw> <0904020940371.36257@www.mmlab.cse.yzu.edu.tw> <4CCDEFD6-830E-4C8F-B7A2-B7878F8842BE@mac.com> <0904021314574.37737@www.mmlab.cse.yzu.edu.tw> <09040309313414.76643@www.mmlab.cse.yzu.edu.tw> <0904031327195.78401@www.mmlab.cse.yzu.edu.tw> <8583A3BA-2871-4DF4-9792-1031044A4A22@mac.com> <09040315161311.79260@www.mmlab.cse.yzu.edu.tw> <1DDB4728-7742-4265-999F-F1A0FC69F9E4@mac.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-current@freebsd.org Subject: Re: Removal of GEOM_BSD, GEOM_MBR, GEOM_PC98 and GEOM_SUNLABEL 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, 04 Apr 2009 01:08:24 -0000 On Fri, 3 Apr 2009, Marcel Moolenaar wrote: [...] > Hmmmm... I don't think there's anything wrong with the label > nor the code. If the label is rejected, the dmesg should show > that. Is there anything in the dmesg like? > GEOM: ad0s3+00103bf1: invalid disklabel. # dmesg | grep GEOM GEOM: new disk cd0 GEOM_LABEL: Label ufsid/46387cd616292ca8 removed. GEOM_LABEL: Label for provider ad0s2a is ufsid/46387cd616292ca8. GEOM_LABEL: Label ufsid/46387cd73d66d2ca removed. GEOM_LABEL: Label for provider ad0s2d is ufsid/46387cd73d66d2ca. GEOM_LABEL: Label ufsid/46387cd6c10fa381 removed. GEOM_LABEL: Label for provider ad0s2e is ufsid/46387cd6c10fa381. GEOM_LABEL: Label ufsid/46389322544a8c64 removed. GEOM_LABEL: Label for provider ad0s3+00103bf1a is ufsid/46389322544a8c64. GEOM_LABEL: Label ufsid/46387cd616292ca8 removed. GEOM_LABEL: Label ufsid/46387cd73d66d2ca removed. GEOM_LABEL: Label ufsid/46387cd6c10fa381 removed. GEOM_LABEL: Label ufsid/46389322544a8c64 removed. GEOM_LABEL: Label for provider md0 is ufsid/49d71e25191c321d. GEOM_LABEL: Label ufsid/49d71e25191c321d removed. > Also, could you trigger a re-taste by writing all zeroes to > the first sector: > dd if=/dev/zero of=/dev/ad0s7 count=1 bs=512 # dd if=/dev/zero of=/dev/ad0s7 bs=512 count=1 dd: /dev/ad0s7: Operation not permitted # sysctl kern.geom.debugflags=16 kern.geom.debugflags: 0 -> 16 # dd if=/dev/zero of=/dev/ad0s7 bs=512 count=1 dd: /dev/ad0s7: Operation not permitted # I can see ad0s3 falls in 'scheme: EBR' but not 'BSD scheme' now: Geom name: ad0 fwheads: 16 fwsectors: 63 last: 228338837 first: 63 entries: 4 scheme: MBR Providers: 1. Name: ad0s1 Mediasize: 9568387584 (8.9G) Sectorsize: 512 Mode: r0w0e0 rawtype: 12 length: 9568387584 offset: 32256 type: !12 index: 1 end: 18688319 start: 63 2. Name: ad0s2 Mediasize: 8592998400 (8.0G) Sectorsize: 512 Mode: r4w4e7 attrib: active rawtype: 165 length: 8592998400 offset: 9568419840 type: freebsd index: 2 end: 35471519 start: 18688320 3. Name: ad0s3 Mediasize: 98742067200 (92G) Sectorsize: 512 Mode: r1w1e2 rawtype: 15 length: 98742067200 offset: 18161418240 type: !15 index: 3 end: 228327119 start: 35471520 Consumers: 1. Name: ad0 Mediasize: 116909491200 (109G) Sectorsize: 512 Mode: r5w5e14 Geom name: ad0s2 fwheads: 16 fwsectors: 63 last: 16783199 first: 0 entries: 8 scheme: BSD Providers: 1. Name: ad0s2a Mediasize: 402653184 (384M) Sectorsize: 512 Mode: r1w1e1 rawtype: 7 length: 402653184 offset: 0 type: freebsd-ufs index: 1 end: 786431 start: 0 2. Name: ad0s2b Mediasize: 2147483648 (2.0G) Sectorsize: 512 Mode: r1w1e0 rawtype: 1 length: 2147483648 offset: 402653184 type: freebsd-swap index: 2 end: 4980735 start: 786432 3. Name: ad0s2d Mediasize: 201326592 (192M) Sectorsize: 512 Mode: r1w1e1 rawtype: 7 length: 201326592 offset: 2550136832 type: freebsd-ufs index: 4 end: 5373951 start: 4980736 4. Name: ad0s2e Mediasize: 5841534976 (5.4G) Sectorsize: 512 Mode: r1w1e1 rawtype: 7 length: 5841534976 offset: 2751463424 type: freebsd-ufs index: 5 end: 16783199 start: 5373952 Consumers: 1. Name: ad0s2 Mediasize: 8592998400 (8.0G) Sectorsize: 512 Mode: r4w4e7 Geom name: ad0s3 fwheads: 16 fwsectors: 63 last: 192855599 first: 0 entries: 3061200 scheme: EBR Providers: 1. Name: ad0s3+00000001 Mediasize: 8592966144 (8.0G) Sectorsize: 512 Mode: r0w0e0 rawtype: 131 length: 8592966144 offset: 32256 type: !131 index: 1 end: 16783199 start: 0 2. Name: ad0s3+000410a1 Mediasize: 25724772864 (24G) Sectorsize: 512 Mode: r0w0e0 rawtype: 11 length: 25724772864 offset: 8593030656 type: !11 index: 266401 end: 67026959 start: 16783200 3. Name: ad0s3+00103bf1 Mediasize: 16000492032 (15G) Sectorsize: 512 Mode: r1w1e1 rawtype: 165 length: 16000492032 offset: 34317835776 type: freebsd index: 1063921 end: 98277983 start: 67026960 4. Name: ad0s3+0017cda1 Mediasize: 48423707136 (45G) Sectorsize: 512 Mode: r0w0e0 rawtype: 165 length: 48423707136 offset: 50318360064 type: freebsd index: 1559969 end: 192855599 start: 98277984 Consumers: 1. Name: ad0s3 Mediasize: 98742067200 (92G) Sectorsize: 512 Mode: r1w1e2 -- Cheers, Tai-hwa Liang From owner-freebsd-current@FreeBSD.ORG Sat Apr 4 01:23: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 E36BD106566C for ; Sat, 4 Apr 2009 01:23:38 +0000 (UTC) (envelope-from xcllnt@mac.com) Received: from asmtpout016.mac.com (asmtpout016.mac.com [17.148.16.91]) by mx1.freebsd.org (Postfix) with ESMTP id C272B8FC15 for ; Sat, 4 Apr 2009 01:23:38 +0000 (UTC) (envelope-from xcllnt@mac.com) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Received: from mohana-t43.jnpr.net ([66.129.224.36]) by asmtp016.mac.com (Sun Java(tm) System Messaging Server 6.3-8.01 (built Dec 16 2008; 32bit)) with ESMTPSA id <0KHJ0072VYJ5LS90@asmtp016.mac.com> for freebsd-current@freebsd.org; Fri, 03 Apr 2009 18:23:31 -0700 (PDT) Message-id: <7AD352A2-BEDD-4DFD-896D-104E6376D887@mac.com> From: Marcel Moolenaar To: Tai-hwa Liang In-reply-to: <0904040858433.86299@www.mmlab.cse.yzu.edu.tw> Date: Fri, 03 Apr 2009 18:22:07 -0700 References: <95891.1238477069@critter.freebsd.dk> <20090331133132.1e191836@ernst.jennejohn.org> <20090331155542.74d89d64@ernst.jennejohn.org> <60084D1E-9F64-463A-A8E9-7A237D5C7661@mac.com> <0904011910169.29800@www.mmlab.cse.yzu.edu.tw> <0904020940371.36257@www.mmlab.cse.yzu.edu.tw> <4CCDEFD6-830E-4C8F-B7A2-B7878F8842BE@mac.com> <0904021314574.37737@www.mmlab.cse.yzu.edu.tw> <09040309313414.76643@www.mmlab.cse.yzu.edu.tw> <0904031327195.78401@www.mmlab.cse.yzu.edu.tw> <8583A3BA-2871-4DF4-9792-1031044A4A22@mac.com> <09040315161311.79260@www.mmlab.cse.yzu.edu.tw> <1DDB4728-7742-4265-999F-F1A0FC69F9E4@mac.com> <0904040858433.86299@www.mmlab.cse.yzu.edu.tw> X-Mailer: Apple Mail (2.930.3) Cc: freebsd-current@freebsd.org Subject: Re: Removal of GEOM_BSD, GEOM_MBR, GEOM_PC98 and GEOM_SUNLABEL 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, 04 Apr 2009 01:23:39 -0000 On Apr 3, 2009, at 6:08 PM, Tai-hwa Liang wrote: > # dmesg | grep GEOM > GEOM: new disk cd0 > GEOM_LABEL: Label ufsid/46387cd616292ca8 removed. > GEOM_LABEL: Label for provider ad0s2a is ufsid/46387cd616292ca8. > GEOM_LABEL: Label ufsid/46387cd73d66d2ca removed. > GEOM_LABEL: Label for provider ad0s2d is ufsid/46387cd73d66d2ca. > GEOM_LABEL: Label ufsid/46387cd6c10fa381 removed. > GEOM_LABEL: Label for provider ad0s2e is ufsid/46387cd6c10fa381. > GEOM_LABEL: Label ufsid/46389322544a8c64 removed. > GEOM_LABEL: Label for provider ad0s3+00103bf1a is ufsid/ > 46389322544a8c64. Hmm... the BSD scheme does probe and read. You have partition 'a' under ad0s3+00103bf1 here. It looks like the partition gets spoiled shortly after. Can you enable tracing and check if that's the case? > I can see ad0s3 falls in 'scheme: EBR' but not 'BSD scheme' now: That's correct. ad0s3 is an extended partition. -- Marcel Moolenaar xcllnt@mac.com From owner-freebsd-current@FreeBSD.ORG Sat Apr 4 03:15: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 36421106566B for ; Sat, 4 Apr 2009 03:15:27 +0000 (UTC) (envelope-from avatar@mmlab.cse.yzu.edu.tw) Received: from www.mmlab.cse.yzu.edu.tw (www.mmlab.cse.yzu.edu.tw [140.138.150.166]) by mx1.freebsd.org (Postfix) with ESMTP id 840ED8FC17 for ; Sat, 4 Apr 2009 03:15:26 +0000 (UTC) (envelope-from avatar@mmlab.cse.yzu.edu.tw) Received: by www.mmlab.cse.yzu.edu.tw (qmail, from userid 1000) id B96FBE43407; Sat, 4 Apr 2009 11:15:03 +0800 (CST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=mmlab.cse.yzu.edu.tw; s=test; t=1238814903; bh=kmm1JPixQhThx4iEYMgVRooUQVAqF1Zo5YBz9K5UBwk=; h=Date:From:To:cc:Subject:In-Reply-To:Message-ID:References: MIME-Version:Content-Type; b=HIXd/Xsyqc7dInxvepu2mE1o+rnz61MUZT2gw0JHLVcFTH3rapBdqWEIr4rKXngMH nXf1Gw7FQvEyJMDV74QxiXf4tENnzJxVDawMnJiIQ1nqJIO4jou3KtLRCCZesih0cV lcWXKNJPbZAcsblAOn5vu4hm943dVCy6TMMV6Pwg= Received: from localhost (localhost [127.0.0.1]) by www.mmlab.cse.yzu.edu.tw (qmail) with ESMTP id B8B95E43406; Sat, 4 Apr 2009 11:15:03 +0800 (CST) Date: Sat, 4 Apr 2009 11:15:03 +0800 (CST) From: Tai-hwa Liang To: Marcel Moolenaar In-Reply-To: <7AD352A2-BEDD-4DFD-896D-104E6376D887@mac.com> Message-ID: <09040411131618.87313@www.mmlab.cse.yzu.edu.tw> References: <95891.1238477069@critter.freebsd.dk> <20090331133132.1e191836@ernst.jennejohn.org> <20090331155542.74d89d64@ernst.jennejohn.org> <60084D1E-9F64-463A-A8E9-7A237D5C7661@mac.com> <0904011910169.29800@www.mmlab.cse.yzu.edu.tw> <0904020940371.36257@www.mmlab.cse.yzu.edu.tw> <4CCDEFD6-830E-4C8F-B7A2-B7878F8842BE@mac.com> <0904021314574.37737@www.mmlab.cse.yzu.edu.tw> <09040309313414.76643@www.mmlab.cse.yzu.edu.tw> <0904031327195.78401@www.mmlab.cse.yzu.edu.tw> <8583A3BA-2871-4DF4-9792-1031044A4A22@mac.com> <09040315161311.79260@www.mmlab.cse.yzu.edu.tw> <1DDB4728-7742-4265-999F-F1A0FC69F9E4@mac.com> <0904040858433.86299@www.mmlab.cse.yzu.edu.tw> <7AD352A2-BEDD-4DFD-896D-104E6376D887@mac.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-current@freebsd.org Subject: Re: Removal of GEOM_BSD, GEOM_MBR, GEOM_PC98 and GEOM_SUNLABEL 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, 04 Apr 2009 03:15:27 -0000 On Fri, 3 Apr 2009, Marcel Moolenaar wrote: [...] > Hmm... the BSD scheme does probe and read. You have > partition 'a' under ad0s3+00103bf1 here. It looks > like the partition gets spoiled shortly after. > > Can you enable tracing and check if that's the case? boot with kern.geom.debugflags=1: Copyright (c) 1992-2009 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 8.0-CURRENT #46: Sat Apr 4 08:25:53 CST 2009 [...] pnpbios: Event flag at 4b4 Other BIOS signatures found: g_ignition g_modevent(DISK, LOAD) g_post_event_x(0xc04cd490, 0xc38060a0, 2, 0) g_modevent(PART, LOAD) g_post_event_x(0xc04cd490, 0xc3806090, 2, 0) g_modevent(DEV, LOAD) g_post_event_x(0xc04cd490, 0xc3806080, 2, 0) wlan: <802.11 Link Layer> snd_unit_init() u=0x00ff8000 [512] d=0x00007c00 [32] c=0x000003ff [1024] feeder_register: snd_unit=-1 snd_maxautovchans=16 latency=5 feeder_buffersize=16384 feeder_rate_min=1 feeder_rate_max=2016000 feeder_rate_round=25 g_modevent(VFS, LOAD) g_post_event_x(0xc04cd490, 0xc3806040, 2, 0) g_modevent(SWAP, LOAD) g_post_event_x(0xc04cd490, 0xc3806030, 2, 0) g_modevent(LABEL, LOAD) g_post_event_x(0xc04cd490, 0xc3806020, 2, 0) random: g_modevent(ACD, LOAD) g_post_event_x(0xc04cd490, 0xc3806590, 2, 0) io: mem: Pentium Pro MTRR support enabled null: crypto: g_post_event_x(0xc04cd2c0, 0xc38e5a00, 2, 0) g_post_event_x(0xc04cd2c0, 0xc38e59f0, 2, 0) g_post_event_x(0xc04cd2c0, 0xc38e5820, 2, 0) g_post_event_x(0xc04cd2c0, 0xc38e5700, 2, 0) ACPI: RSDP @ 0x0xf6d70/0x0024 (v 2 IBM ) [...] ata0: Identifying devices: 00000001 ata0: New devices: 00000001 g_load_class(DISK) g_load_class(PART) g_load_class(DEV) g_load_class(VFS) g_load_class(SWAP) g_load_class(LABEL) g_load_class(ACD) g_retaste(PART) g_retaste(PART)usbus0: 12Mbps Full Speed USB v1.0 usbus1: 12Mbps Full Speed USB v1.0 usbus2: 12Mbps Full Speed USB v1.0 usbus3: 480Mbps High Speed USB v2.0 ata0-master: pio=PIO4 wdma=WDMA2 udma=UDMA100 cable=80 wire g_retaste(PART) g_retaste(PART)ad0: setting PIO4 on ICH4 chip battery0: battery initiaad0: setting UDMA100 on ICH4 chip lization start acpi_acadad0: 111493MB at ata0-master UDMA100 ad0: 228338850 sectors [226526C/16H/63S] 16 sectors/interrupt 1 depth queue g_post_event_x(0xc04c78b0, 0xc39e4c00, 2, 0) ref 0xc39e4c00 g_post_event_x(0xc04cb510, 0xc384ca00, 2, 0) ref 0xc384ca00 ref 0xc384c980 GEOM: new disk ad0 g_label_taste(LABEL, ad0) 0: acline initialization start ata1: Identifying devices: 00030000 ata1: New devices: 00030000 ata1-master: pio=PIO4 wdma=WDMA2 udma=UDMA33 cable=40 wire battery0: battery initialization done, tried 1 times acpi_acad0: On Line acpi_acad0: acline initialization done, tried 1 times ugen0.1: at usbus0 uhub0: on usbus0 ugen1.1: at usbus1 uhub1: on usbus1 ugen2.1: at usbus2 uhub2: on usbus2 ugen3.1: at usbus3 uhub3: on usbus3 g_detach(0xc3adcdc0) g_destroy_consumer(0xc3adcdc0) g_destroy_geom(0xc388a280(label:taste)) dev_taste(DEV,ad0) g_part_taste(PART,ad0) g_post_event_x(0xc04cb510, 0xc39a8a80, 2, 0) ref 0xc39a8a80 ref 0xc3ae0000 g_post_event_x(0xc04cb510, 0xc3ae0500, 2, 0) ref 0xc3ae0500 ref 0xc3ae0000 g_post_event_x(0xc04cb510, 0xc39a8d80, 2, 0) ref 0xc39a8d80 ref 0xc3ae0000 g_label_taste(LABEL, ad0s1) g_slice_config(ad0s1, 0, 1) g_post_event_x(0xc04cb510, 0xc388a280, 2, 0) ref 0xc388a280 ref 0xc384cb00 GEOM_LABEL: Label for provider ad0s1 is msdosfs/IBM_PRELOAD. g_detach(0xc3addc80) g_destroy_consumer(0xc3addc80) g_destroy_geom(0xc384ca80(label:taste)) dev_taste(DEV,ad0s1) g_part_taste(PART,ad0s1) g_wither_geom(0xc3ae4700(ad0s1)) g_label_taste(LABEL, ad0s2) g_detach(0xc3addb00) g_destroy_consumer(0xc3addb00) g_destroy_geom(0xc3ae4600(label:taste)) dev_taste(DEV,ad0s2) g_part_taste(PART,ad0s2) g_post_event_x(0xc04cb510, 0xc3ae4400, 2, 0) ref 0xc3ae4400 ref 0xc3ae4500 g_post_event_x(0xc04cb510, 0xc3ae4300, 2, 0) ref 0xc3ae4300 ref 0xc3ae4500 g_post_event_x(0xc04cb510, 0xc3ae4200, 2, 0) ref 0xc3ae4200 ref 0xc3ae4500 g_post_event_x(0xc04cb510, 0xc3ae4100, 2, 0) ref 0xc3ae4100 ref 0xc3ae4500 g_label_taste(LABEL, ad0s3) g_detach(0xc3add880) g_destroy_consumer(0xc3add880) g_destroy_geom(0xc3ae4000(label:taste)) dev_taste(DEV,ad0s3) g_part_taste(PART,ad0s3) g_post_event_x(0xc04cb510, 0xc3ae0d00, 2, 0) ref 0xc3ae0d00 ref 0xc3ae0e00 g_post_event_x(0xc04cb510, 0xc3ae0c00, 2, 0) ref 0xc3ae0c00 ref 0xc3ae0e00 g_post_event_x(0xc04cb510, 0xc3ae0b00, 2, 0) ref 0xc3ae0b00 ref 0xc3ae0e00 g_post_event_x(0xc04cb510, 0xc3ae0a00, 2, 0) ref 0xc3ae0a00 ref 0xc3ae0e00 g_label_taste(LABEL, msdosfs/IBM_PRELOAD) dev_taste(DEV,msdosfs/IBM_PRELOAD) g_part_taste(PART,msdosfs/IBM_PRELOAD) g_wither_geom(0xc3ae0800(msdosfs/IBM_PRELOAD)) g_label_taste(LABEL, ad0s2a) g_slice_config(ad0s2a, 0, 1) g_post_event_x(0xc04cb510, 0xc3ae0700, 2, 0) ref 0xc3ae0700 ref 0xc3ae0780 GEOM_LABEL: Label for provider ad0s2a is ufsid/46387cd616292ca8. g_detach(0xc3add580) g_destroy_consumer(0xc3add580) g_destroy_geom(0xc3ae4800(label:taste)) dev_taste(DEV,ad0s2a) g_part_taste(PART,ad0s2a) g_wither_geom(0xc39a8700(ad0s2a)) g_label_taste(LABEL, ad0s2b) g_detach(0xc3add440) g_destroy_consumer(0xc3add440) g_destroy_geom(0xc3ae4600(label:taste)) dev_taste(DEV,ad0s2b) g_part_taste(PART,ad0s2b) g_wither_geom(0xc3ae4680(ad0s2b)) g_label_taste(LABEL, ad0s2d) g_slice_config(ad0s2d, 0, 1) g_post_event_x(0xc04cb510, 0xc3ae4600, 2, 0) ref 0xc3ae4600 ref 0xc3ae4280 GEOM_LABEL: Label for provider ad0s2d is ufsid/46387cd73d66d2ca. g_detach(0xc3add340) g_destroy_consumer(0xc3add340) g_destroy_geom(0xc384ca80(label:taste)) dev_taste(DEV,ad0s2d) g_part_taste(PART,ad0s2d) g_wither_geom(0xc384ca80(ad0s2d)) g_label_taste(LABEL, ad0s2e) g_slice_config(ad0s2e, 0, 1) g_post_event_x(0xc04cb510, 0xc3af3880, 2, 0) ref 0xc3af3880 ref 0xc3af3900 GEOM_LABEL: Label for provider ad0s2e is ufsid/46387cd6c10fa381. g_detach(0xc3add200) g_destroy_consumer(0xc3add200) g_destroy_geom(0xc3ae4180(label:taste)) dev_taste(DEV,ad0s2e) g_part_taste(PART,ad0s2e) g_wither_geom(0xc3af3700(ad0s2e)) g_label_taste(LABEL, ad0s3+00000001) g_detach(0xc3add0c0) g_destroy_consumer(0xc3add0c0) g_destroy_geom(0xc3af3680(label:taste)) dev_taste(DEV,ad0s3+00000001) g_part_taste(PART,ad0s3+00000001) g_wither_geom(0xc3af3580(ad0s3+00000001)) g_label_taste(LABEL, ad0s3+000410a1) g_slice_config(ad0s3+000410a1, 0, 1) g_post_event_x(0xc04cb510, 0xc3af3380, 2, 0) ref 0xc3af3380 ref 0xc3af3400 GEOM_LABEL: Label for provider ad0s3+000410a1 is msdosfs/ . g_detach(0xc3add440) g_destroy_consumer(0xc3add440) g_destroy_geom(0xc3af3480(label:taste)) dev_taste(DEV,ad0s3+000410a1) g_part_taste(PART,ad0s3+000410a1) g_wither_geom(0xc3af3200(ad0s3+000410a1)) g_label_taste(LABEL, ad0s3+00103bf1) g_detach(0xc3addc80) g_destroy_consumer(0xc3addc80) g_destroy_geom(0xc3af3100(label:taste)) dev_taste(DEV,ad0s3+00103bf1) g_part_taste(PART,ad0s3+00103bf1) g_post_event_x(0xc04cb510, 0xc3ae4e00, 2, 0) ref 0xc3ae4e00 ref 0xc3af3000 g_label_taste(LABEL, ad0s3+0017cda1) g_detach(0xc3af6280) g_destroy_consumer(0xc3af6280) g_destroy_geom(0xc3ae4d00(label:taste)) dev_taste(DEV,ad0s3+0017cda1) g_part_taste(PART,ad0s3+0017cda1) g_wither_geom(0xc3ae4c00(ad0s3+0017cda1)) g_label_taste(LABEL, ufsid/46387cd616292ca8) dev_taste(DEV,ufsid/46387cd616292ca8) g_part_taste(PART,ufsid/46387cd616292ca8) g_wither_geom(0xc3ae4a00(ufsid/46387cd616292ca8)) g_label_taste(LABEL, ufsid/46387cd73d66d2ca) dev_taste(DEV,ufsid/46387cd73d66d2ca) g_part_taste(PART,ufsid/46387cd73d66d2ca) g_wither_geom(0xc3ae4880(ufsid/46387cd73d66d2ca)) g_label_taste(LABEL, ufsid/46387cd6c10fa381) dev_taste(DEV,ufsid/46387cd6c10fa381) g_part_taste(PART,ufsid/46387cd6c10fa381) g_wither_geom(0xc3ae0980(ufsid/46387cd6c10fa381)) g_label_taste(LABEL, msdosfs/ ) dev_taste(DEV,msdosfs/ ) g_part_taste(PART,msdosfs/ ) g_wither_geom(0xc3ae4d00(msdosfs/ )) g_label_taste(LABEL, ad0s3+00103bf1a) g_slice_config(ad0s3+00103bf1a, 0, 1) g_post_event_x(0xc04cb510, 0xc3af3180, 2, 0) ref 0xc3af3180 ref 0xc3ae0b80 GEOM_LABEL: Label for provider ad0s3+00103bf1a is ufsid/46389322544a8c64. g_detach(0xc3ae2d40) g_destroy_consumer(0xc3ae2d40) g_destroy_geom(0xc3af3100(label:taste)) dev_taste(DEV,ad0s3+00103bf1a) g_part_taste(PART,ad0s3+00103bf1a) g_wither_geom(0xc3af3500(ad0s3+00103bf1a)) g_label_taste(LABEL, ufsid/46389322544a8c64) dev_taste(DEV,ufsid/46389322544a8c64) g_part_taste(PART,ufsid/46389322544a8c64) g_wither_geom(0xc3ae4180(ufsid/46389322544a8c64)) g_detach(0xc3ae2bc0) g_destroy_consumer(0xc3ae2bc0) g_destroy_geom(0xc3ae4180(ufsid/46389322544a8c64)) g_detach(0xc3ae2c40) g_destroy_consumer(0xc3ae2c40) g_destroy_geom(0xc3af3500(ad0s3+00103bf1a)) g_detach(0xc3ae2dc0) g_destroy_consumer(0xc3ae2dc0) g_destroy_geom(0xc3ae4d00(msdosfs/ )) g_detach(0xc3ae2e80) g_destroy_consumer(0xc3ae2e80) g_destroy_geom(0xc3ae0980(ufsid/46387cd6c10fa381)) g_detach(0xc3af6040) g_destroy_consumer(0xc3af6040) g_destroy_geom(0xc3ae4880(ufsid/46387cd73d66d2ca)) g_detach(0xc3af60c0) g_destroy_consumer(0xc3af60c0) g_destroy_geom(0xc3ae4a00(ufsid/46387cd616292ca8)) g_detach(0xc3af6180) g_destroy_consumer(0xc3af6180) g_destroy_geom(0xc3ae4c00(ad0s3+0017cda1)) g_detach(0xc3addb00) g_destroy_consumer(0xc3addb00) g_destroy_geom(0xc3af3200(ad0s3+000410a1)) g_detach(0xc3add200) g_destroy_consumer(0xc3add200) g_destroy_geom(0xc3af3580(ad0s3+00000001)) g_detach(0xc3add100) g_destroy_consumer(0xc3add100) g_destroy_geom(0xc3af3700(ad0s2e)) g_detach(0xc3add240) g_destroy_consumer(0xc3add240) g_destroy_geom(0xc384ca80(ad0s2d)) g_detach(0xc3add380) g_destroy_consumer(0xc3add380) g_destroy_geom(0xc3ae4680(ad0s2b)) g_detach(0xc3add480) g_destroy_consumer(0xc3add480) g_destroy_geom(0xc39a8700(ad0s2a)) g_detach(0xc3add600) g_destroy_consumer(0xc3add600) g_destroy_geom(0xc3ae0800(msdosfs/IBM_PRELOAD)) g_detach(0xc3addb80) g_destroy_consumer(0xc3addb80) g_destroy_geom(0xc3ae4700(ad0s1)) uhub0: 2 ports with 2 removable, self powered uhub1: 2 ports with 2 removable, self powered uhub2: 2 ports with 2 removable, self powered ata1: reiniting channel .. ata1: reset tp1 mask=03 ostat0=50 ostat1=00 ata1: stat0=0x00 err=0x01 lsb=0x14 msb=0xeb ata1: stat1=0x00 err=0x01 lsb=0x14 msb=0xeb ata1: reset tp2 stat0=00 stat1=00 devices=0x30000 ata1: reinit done .. unknown: FAILURE - ATAPI_IDENTIFY timed out LBA=0 ata1: reiniting channel .. ata1: reset tp1 mask=03 ostat0=00 ostat1=00 ata1: stat0=0x00 err=0x01 lsb=0x14 msb=0xeb ata1: stat1=0x00 err=0x01 lsb=0x14 msb=0xeb ata1: reset tp2 stat0=00 stat1=00 devices=0x30000 ata1: reinit done .. unknown: FAILURE - ATAPI_IDENTIFY timed out LBA=0 acd0: setting PIO4 on ICH4 chip acd0: setting UDMA33 on ICH4 chip g_post_event_x(0xc04863d0, 0xc3ae0680, 2, 0) acd0: CDRW drive at ata1 as master acd0: read 4134KB/s (4134KB/s) write 2755KB/s (2755KB/s), 2048KB buffer, UDMA33 acd0: Reads: CDR, CDRW, CDDA stream, DVDROM, DVDR, DVDRAM, packet acd0: Writes: CDR, CDRW, test write, burnproof acd0: Audio: play, 256 volume levels acd0: Mechanism: ejectable tray, unlocked acd0: Medium: no/blank disc g_post_event_x(0xc04cb510, 0xc384ca80, 2, 0) ref 0xc384ca80 ref 0xc3ae4680 g_label_taste(LABEL, acd0) acd0: FAILURE - INQUIRY ILLEGAL REQUEST asc=0x24 ascq=0x00 sks=0x40 0x00 0x01 (probe0:ata1:0:0:0): error 22 (probe0:ata1:0:0:0): Unretryable Error (probe0:ata1:0:0:0): Down reving Protocol Version from 2 to 0? (probe0:ata1:0:0:0): TEST UNIT READY. CDB: 0 0 0 0 0 0 (probe0:ata1:0:0:0): CAM Status: SCSI Status Error (probe0:ata1:0:0:0): SCSI Status: Check Condition (probe0:ata1:0:0:0): NOT READY asc:3a,1 (probe0:ata1:0:0:0): Medium not present - tray closed (probe0:ata1:0:0:0): (probe0:ata1:0:0:0): TEST UNIT READY. CDB: 0 0 0 0 0 0 (probe0:ata1:0:0:0): NOT READY asc:3a,1 (probe0:ata1:0:0:0): Medium not present - tray closed Unretryable error (probe0:ata1:0:0:0): error 6 (probe0:ata1:0:0:0): Unretryable Error pcm0: measured ac97 link rate at 3996 Hz (probe0:ata1:0:0:0): error 6 (probe0:ata1:0:0:0): Unretryable Error g_detach(0xc3ae25c0) g_destroy_consumer(0xc3ae25c0) g_destroy_geom(0xc3af3580(label:taste)) dev_taste(DEV,acd0) g_part_taste(PART,acd0) acd0: FAILURE - INQUIRY ILLEGAL REQUEST asc=0x24 ascq=0x00 sks=0x40 0x00 0x01 (probe0:ata1:0:0:0): error 22 (probe0:ata1:0:0:0): Unretryable Error pass0 at ata1 bus 0 target 0 lun 0 pass0: Removable CD-ROM SCSI-0 device pass0: 33.000MB/s transfers g_post_event_x(0xc04c78b0, 0xc3af9400, 2, 0) ref 0xc3af9400 (cd0:ata1:0:0:0): error 6 (cd0:ata1:0:0:0): Unretryable Error cd0 at ata1 bus 0 target 0 lun 0 cd0: Removable CD-ROM SCSI-0 device cd0: 33.000MB/s transfers cd0: Attempt to query device size failed: NOT READY, Medium not present - tray closed g_wither_geom(0xc3ae4c00(acd0)) g_post_event_x(0xc04cb510, 0xc3af3480, 2, 0) ref 0xc3af3480 ref 0xc3ae4180 GEOM: new disk cd0 g_label_taste(LABEL, cd0) (cd0:ata1:0:0:0): error 6 (cd0:ata1:0:0:0): Unretryable Error g_detach(0xc3add100) g_destroy_consumer(0xc3add100) g_destroy_geom(0xc3af3100(label:taste)) dev_taste(DEV,cd0) scsi_cd.c::ioctl cmd=4400648b error=25 g_part_taste(PART,cd0) (cd0:ata1:0:0:0): error 6 (cd0:ata1:0:0:0): Unretryable Error g_wither_geom(0xc3ae0a80(cd0)) g_detach(0xc3ae2e80) g_destroy_consumer(0xc3ae2e80) g_destroy_geom(0xc3ae0a80(cd0)) g_detach(0xc39b5280) g_destroy_consumer(0xc39b5280) g_destroy_geom(0xc3ae4c00(acd0)) Root mount waiting for: usbus3 uhub3: 6 ports with 6 removable, self powered Trying to mount root from ufs:/dev/ad0s2a ct_to_ts([2009-04-04 11:06:51]) = 1238843211.000000000 start_init: trying /sbin/init g_disk_kernedump(ad0, 9971073024, 2147483648) Entropy harvesting: interrupts ethernet point_to_point g_post_event_x(0xc04c7590, 0xc3ae3960, 2, 262144) g_post_event_x(0xc04c7590, 0xc3ae3940, 2, 262144) g_post_event_x(0xc04c8a00, 0xc3ae3980, 2, 262144) g_post_event_x(0xc04c8a00, 0xc3ae39c0, 2, 262144) g_post_event_x(0xc04c8880, 0xc3ae3a20, 2, 262144) g_post_event_x(0xc04c8880, 0xc3ae3a40, 2, 262144) g_post_event_x(0xc04c8840, 0xc3ae3a60, 2, 262144) g_post_event_x(0xc04c8840, 0xc3ae3a80, 2, 262144) kickstart . g_post_event_x(0xc0665230, 0xdf0d3c64, 2, 262144) g_post_event_x(0xc04cb710, 0xc384ca00, 2, 0) ref 0xc384ca00 g_post_event_x(0xc04cb710, 0xc3ae0500, 2, 0) ref 0xc3ae0500 g_post_event_x(0xc04cb710, 0xc3ae4300, 2, 0) ref 0xc3ae4300 g_post_event_x(0xc04cb710, 0xc3ae4400, 2, 0) ref 0xc3ae4400 GEOM_LABEL: Label ufsid/46387cd616292ca8 removed. g_slice_spoiled(0xc3add540/ad0s2a) g_wither_geom(0xc3ae0780(ad0s2a)) g_orphan_provider(0xc3ae0700(ufsid/46387cd616292ca8), 6) g_orphan_register(ufsid/46387cd616292ca8) g_dev_orphan(0xc3af6100(ufsid/46387cd616292ca8)) g_detach(0xc3af6100) g_destroy_consumer(0xc3af6100) g_destroy_geom(0xc3ae4b00(ufsid/46387cd616292ca8)) g_detach(0xc3add540) g_destroy_consumer(0xc3add540) g_destroy_geom(0xc3ae0780(ad0s2a)) /dev/ad0s2a: FILE SYSTEM CLEAN; SKIPPING CHECKS /dev/ad0s2a: clean, 37241 free (1089 frags, 4519 blocks, 0.6% fragmentation) g_post_event_x(0xc04cb510, 0xc3ae4400, 2, 0) ref 0xc3ae4400 g_label_taste(LABEL, ad0s2a) g_slice_config(ad0s2a, 0, 1) g_post_event_x(0xc04cb510, 0xc3b26080, 2, 0) ref 0xc3b26080 ref 0xc3b26000 GEOM_LABEL: Label for provider ad0s2a is ufsid/46387cd616292ca8. g_detach(0xc3af69c0) g_destroy_consumer(0xc3af69c0) g_destroy_geom(0xc3b6d680(label:taste)) g_part_taste(PART,ad0s2a) g_wither_geom(0xc3b25e00(ad0s2a)) g_label_taste(LABEL, ufsid/46387cd616292ca8) dev_taste(DEV,ufsid/46387cd616292ca8) g_part_taste(PART,ufsid/46387cd616292ca8) g_wither_geom(0xc3b26400(ufsid/46387cd616292ca8)) g_detach(0xc3af68c0) g_destroy_consumer(0xc3af68c0) g_destroy_geom(0xc3b26400(ufsid/46387cd616292ca8)) g_detach(0xc3af6940) g_destroy_consumer(0xc3af6940) g_destroy_geom(0xc3b25e00(ad0s2a)) g_post_event_x(0xc04cb710, 0xc3ae4200, 2, 0) ref 0xc3ae4200 GEOM_LABEL: Label ufsid/46387cd73d66d2ca removed. g_slice_spoiled(0xc3add300/ad0s2d) g_wither_geom(0xc3ae4280(ad0s2d)) g_orphan_provider(0xc3ae4600(ufsid/46387cd73d66d2ca), 6) g_orphan_register(ufsid/46387cd73d66d2ca) g_dev_orphan(0xc3af6080(ufsid/46387cd73d66d2ca)) g_detach(0xc3af6080) g_destroy_consumer(0xc3af6080) g_destroy_geom(0xc3ae4980(ufsid/46387cd73d66d2ca)) g_detach(0xc3add300) g_destroy_consumer(0xc3add300) g_destroy_geom(0xc3ae4280(ad0s2d)) /dev/ad0s2d: FILE SYSTEM CLEAN; SKIPPING CHECKS /dev/ad0s2d: clean, 65381 free (5149 frags, 7529 blocks, 5.4% fragmentation) g_post_event_x(0xc04cb510, 0xc3ae4200, 2, 0) ref 0xc3ae4200 g_label_taste(LABEL, ad0s2d) g_slice_config(ad0s2d, 0, 1) g_post_event_x(0xc04cb510, 0xc3b25e00, 2, 0) ref 0xc3b25e00 ref 0xc3b26900 GEOM_LABEL: Label for provider ad0s2d is ufsid/46387cd73d66d2ca. g_detach(0xc3af66c0) g_destroy_consumer(0xc3af66c0) g_destroy_geom(0xc3b26200(label:taste)) g_part_taste(PART,ad0s2d) g_wither_geom(0xc3b25d80(ad0s2d)) g_label_taste(LABEL, ufsid/46387cd73d66d2ca) dev_taste(DEV,ufsid/46387cd73d66d2ca) g_part_taste(PART,ufsid/46387cd73d66d2ca) g_wither_geom(0xc3b6d480(ufsid/46387cd73d66d2ca)) g_detach(0xc3af65c0) g_destroy_consumer(0xc3af65c0) g_destroy_geom(0xc3b6d480(ufsid/46387cd73d66d2ca)) g_detach(0xc3af6640) g_destroy_consumer(0xc3af6640) g_destroy_geom(0xc3b25d80(ad0s2d)) g_post_event_x(0xc04cb710, 0xc3ae4100, 2, 0) ref 0xc3ae4100 GEOM_LABEL: Label ufsid/46387cd6c10fa381 removed. g_slice_spoiled(0xc3add1c0/ad0s2e) g_wither_geom(0xc3af3900(ad0s2e)) g_orphan_provider(0xc3af3880(ufsid/46387cd6c10fa381), 6) g_orphan_register(ufsid/46387cd6c10fa381) g_dev_orphan(0xc3af6000(ufsid/46387cd6c10fa381)) g_detach(0xc3af6000) g_destroy_consumer(0xc3af6000) g_destroy_geom(0xc3ae4380(ufsid/46387cd6c10fa381)) g_detach(0xc3add1c0) g_destroy_consumer(0xc3add1c0) g_destroy_geom(0xc3af3900(ad0s2e)) /dev/ad0s2e: FILE SYSTEM CLEAN; SKIPPING CHECKS /dev/ad0s2e: clean, 689500 free (141532 frags, 68496 blocks, 5.1% fragmentation) g_post_event_x(0xc04cb510, 0xc3ae4100, 2, 0) ref 0xc3ae4100 g_label_taste(LABEL, ad0s2e) g_slice_config(ad0s2e, 0, 1) g_post_event_x(0xc04cb510, 0xc3af3880, 2, 0) ref 0xc3af3880 ref 0xc3af3900 GEOM_LABEL: Label for provider ad0s2e is ufsid/46387cd6c10fa381. g_detach(0xc3af6480) g_destroy_consumer(0xc3af6480) g_destroy_geom(0xc3ae4b00(label:taste)) g_part_taste(PART,ad0s2e) g_wither_geom(0xc3ae0780(ad0s2e)) g_label_taste(LABEL, ufsid/46387cd6c10fa381) dev_taste(DEV,ufsid/46387cd6c10fa381) g_part_taste(PART,ufsid/46387cd6c10fa381) g_wither_geom(0xc3b6d480(ufsid/46387cd6c10fa381)) g_detach(0xc3af6380) g_destroy_consumer(0xc3af6380) g_destroy_geom(0xc3b6d480(ufsid/46387cd6c10fa381)) g_detach(0xc3af6400) g_destroy_consumer(0xc3af6400) g_destroy_geom(0xc3ae0780(ad0s2e)) g_post_event_x(0xc04cb710, 0xc39a8d80, 2, 0) ref 0xc39a8d80 g_post_event_x(0xc04cb710, 0xc3ae0b00, 2, 0) ref 0xc3ae0b00 g_part_spoiled(ad0s3+00103bf1) g_wither_geom(0xc3af3000(ad0s3+00103bf1)) g_orphan_provider(0xc3ae4e00(ad0s3+00103bf1a), 6) g_orphan_register(ad0s3+00103bf1a) g_dev_orphan(0xc3ae2cc0(ad0s3+00103bf1a)) g_detach(0xc3ae2cc0) g_destroy_consumer(0xc3ae2cc0) g_destroy_geom(0xc3ae0c80(ad0s3+00103bf1a)) GEOM_LABEL: Label ufsid/46389322544a8c64 removed. g_slice_orphan(0xc3ae2d00/ad0s3+00103bf1a) g_wither_geom(0xc3ae0b80(ad0s3+00103bf1a)) g_orphan_provider(0xc3af3180(ufsid/46389322544a8c64), 6) g_orphan_register(ufsid/46389322544a8c64) g_dev_orphan(0xc3ae2c00(ufsid/46389322544a8c64)) g_detach(0xc3ae2c00) g_destroy_consumer(0xc3ae2c00) g_destroy_geom(0xc3af3680(ufsid/46389322544a8c64)) g_detach(0xc3ae2d00) g_destroy_consumer(0xc3ae2d00) g_destroy_geom(0xc3ae0b80(ad0s3+00103bf1a)) g_detach(0xc3addb40) g_destroy_consumer(0xc3addb40) g_destroy_geom(0xc3af3000(ad0s3+00103bf1)) /dev/ad0s7: FILE SYSTEM CLEAN; SKIPPING CHECKS /dev/ad0s7: clean, 4999758 free (51910 frags, 618481 blocks, 0.7% fragmentation) g_post_event_x(0xc04cb510, 0xc39a8d80, 2, 0) ref 0xc39a8d80 g_post_event_x(0xc04cb510, 0xc3ae0b00, 2, 0) ref 0xc3ae0b00 g_label_taste(LABEL, ad0s3) g_detach(0xc3ae2c00) g_destroy_consumer(0xc3ae2c00) g_destroy_geom(0xc3ae0b80(label:taste)) g_label_taste(LABEL, ad0s3+00103bf1) g_detach(0xc3ae2cc0) g_destroy_consumer(0xc3ae2cc0) g_destroy_geom(0xc3af3180(label:taste)) g_part_taste(PART,ad0s3+00103bf1) g_post_event_x(0xc04cb510, 0xc3b26200, 2, 0) ref 0xc3b26200 ref 0xc3af3680 g_label_taste(LABEL, ad0s3+00103bf1a) g_slice_config(ad0s3+00103bf1a, 0, 1) g_post_event_x(0xc04cb510, 0xc3ae0780, 2, 0) ref 0xc3ae0780 ref 0xc3b26800 GEOM_LABEL: Label for provider ad0s3+00103bf1a is ufsid/46389322544a8c64. g_detach(0xc3af6380) g_destroy_consumer(0xc3af6380) g_destroy_geom(0xc3ae4980(label:taste)) dev_taste(DEV,ad0s3+00103bf1a) g_part_taste(PART,ad0s3+00103bf1a) g_wither_geom(0xc3b6d580(ad0s3+00103bf1a)) g_label_taste(LABEL, ufsid/46389322544a8c64) dev_taste(DEV,ufsid/46389322544a8c64) g_part_taste(PART,ufsid/46389322544a8c64) g_wither_geom(0xc3ae4980(ufsid/46389322544a8c64)) g_detach(0xc3af6000) g_destroy_consumer(0xc3af6000) g_destroy_geom(0xc3ae4980(ufsid/46389322544a8c64)) g_detach(0xc3af6540) g_destroy_consumer(0xc3af6540) g_destroy_geom(0xc3b6d580(ad0s3+00103bf1a)) g_post_event_x(0xc04cb710, 0xc3ae4400, 2, 0) ref 0xc3ae4400 GEOM_LABEL: Label ufsid/46387cd616292ca8 removed. g_slice_spoiled(0xc3af6980/ad0s2a) g_wither_geom(0xc3b26000(ad0s2a)) g_orphan_provider(0xc3b26080(ufsid/46387cd616292ca8), 6) g_orphan_register(ufsid/46387cd616292ca8) g_dev_orphan(0xc3af6900(ufsid/46387cd616292ca8)) g_detach(0xc3af6900) g_destroy_consumer(0xc3af6900) g_destroy_geom(0xc3b25c80(ufsid/46387cd616292ca8)) g_detach(0xc3af6980) g_destroy_consumer(0xc3af6980) g_destroy_geom(0xc3b26000(ad0s2a)) g_post_event_x(0xc04cb710, 0xc3ae4200, 2, 0) ref 0xc3ae4200 GEOM_LABEL: Label ufsid/46387cd73d66d2ca removed. g_slice_spoiled(0xc3af6680/ad0s2d) g_wither_geom(0xc3b26900(ad0s2d)) g_orphan_provider(0xc3b25e00(ufsid/46387cd73d66d2ca), 6) g_orphan_register(ufsid/46387cd73d66d2ca) g_dev_orphan(0xc3af6600(ufsid/46387cd73d66d2ca)) g_detach(0xc3af6600) g_destroy_consumer(0xc3af6600) g_destroy_geom(0xc3b6d600(ufsid/46387cd73d66d2ca)) g_detach(0xc3af6680) g_destroy_consumer(0xc3af6680) g_destroy_geom(0xc3b26900(ad0s2d)) g_post_event_x(0xc04cb710, 0xc3ae4100, 2, 0) ref 0xc3ae4100 GEOM_LABEL: Label ufsid/46387cd6c10fa381 removed. g_slice_spoiled(0xc3af6440/ad0s2e) g_wither_geom(0xc3af3900(ad0s2e)) g_orphan_provider(0xc3af3880(ufsid/46387cd6c10fa381), 6) g_orphan_register(ufsid/46387cd6c10fa381) g_dev_orphan(0xc3af63c0(ufsid/46387cd6c10fa381)) g_detach(0xc3af63c0) g_destroy_consumer(0xc3af63c0) g_destroy_geom(0xc3b26880(ufsid/46387cd6c10fa381)) g_detach(0xc3af6440) g_destroy_consumer(0xc3af6440) g_destroy_geom(0xc3af3900(ad0s2e)) g_post_event_x(0xc04cb710, 0xc39a8d80, 2, 0) ref 0xc39a8d80 g_post_event_x(0xc04cb710, 0xc3ae0b00, 2, 0) ref 0xc3ae0b00 g_part_spoiled(ad0s3+00103bf1) g_wither_geom(0xc3af3680(ad0s3+00103bf1)) g_orphan_provider(0xc3b26200(ad0s3+00103bf1a), 6) g_orphan_register(ad0s3+00103bf1a) g_dev_orphan(0xc3af64c0(ad0s3+00103bf1a)) g_detach(0xc3af64c0) g_destroy_consumer(0xc3af64c0) g_destroy_geom(0xc3ae4380(ad0s3+00103bf1a)) GEOM_LABEL: Label ufsid/46389322544a8c64 removed. g_slice_orphan(0xc3af6480/ad0s3+00103bf1a) g_wither_geom(0xc3b26800(ad0s3+00103bf1a)) g_orphan_provider(0xc3ae0780(ufsid/46389322544a8c64), 6) g_orphan_register(ufsid/46389322544a8c64) g_dev_orphan(0xc3add1c0(ufsid/46389322544a8c64)) g_detach(0xc3add1c0) g_destroy_consumer(0xc3add1c0) g_destroy_geom(0xc3ae4b00(ufsid/46389322544a8c64)) g_detach(0xc3af6480) g_destroy_consumer(0xc3af6480) g_destroy_geom(0xc3b26800(ad0s3+00103bf1a)) g_detach(0xc3add340) g_destroy_consumer(0xc3add340) g_destroy_geom(0xc3af3680(ad0s3+00103bf1)) g_modevent(MD, LOAD) g_post_event_x(0xc04cd490, 0xc3ae19f0, 2, 262144) g_load_class(MD) g_post_event_x(0xc04cb510, 0xc3b25e00, 2, 0) ref 0xc3b25e00 ref 0xc3b26900 g_label_taste(LABEL, md0) g_slice_config(md0, 0, 1) g_post_event_x(0xc04cb510, 0xc3b26d80, 2, 0) ref 0xc3b26d80 ref 0xc3ae4280 GEOM_LABEL: Label for provider md0 is ufsid/49d71e25191c321d. g_detach(0xc3af6c40) g_destroy_consumer(0xc3af6c40) g_destroy_geom(0xc3b26080(label:taste)) dev_taste(DEV,md0) g_part_taste(PART,md0) g_wither_geom(0xc3b26700(md0)) g_label_taste(LABEL, ufsid/49d71e25191c321d) dev_taste(DEV,ufsid/49d71e25191c321d) g_part_taste(PART,ufsid/49d71e25191c321d) g_wither_geom(0xc3b26200(ufsid/49d71e25191c321d)) g_detach(0xc3af6dc0) g_destroy_consumer(0xc3af6dc0) g_destroy_geom(0xc3b26200(ufsid/49d71e25191c321d)) g_detach(0xc3af6d00) g_destroy_consumer(0xc3af6d00) g_destroy_geom(0xc3b26700(md0)) g_post_event_x(0xc04cb710, 0xc3b25e00, 2, 0) ref 0xc3b25e00 GEOM_LABEL: Label ufsid/49d71e25191c321d removed. g_slice_spoiled(0xc3af6c80/md0) g_wither_geom(0xc3ae4280(md0)) g_orphan_provider(0xc3b26d80(ufsid/49d71e25191c321d), 6) g_orphan_register(ufsid/49d71e25191c321d) g_dev_orphan(0xc3af6d80(ufsid/49d71e25191c321d)) g_detach(0xc3af6d80) g_destroy_consumer(0xc3af6d80) g_destroy_geom(0xc3ae4980(ufsid/49d71e25191c321d)) g_detach(0xc3af6c80) g_destroy_consumer(0xc3af6c80) g_destroy_geom(0xc3ae4280(md0)) g_post_event_x(0xc04cb510, 0xc3b25e00, 2, 0) ref 0xc3b25e00 g_label_taste(LABEL, md0) g_slice_config(md0, 0, 1) g_post_event_x(0xc04cb510, 0xc3b26d80, 2, 0) ref 0xc3b26d80 ref 0xc3ae4280 GEOM_LABEL: Label for provider md0 is ufsid/49d73f4d44e77d1b. g_detach(0xc3b6f100) g_destroy_consumer(0xc3b6f100) g_destroy_geom(0xc3ae4b00(label:taste)) g_part_taste(PART,md0) g_wither_geom(0xc3ae4380(md0)) g_label_taste(LABEL, ufsid/49d73f4d44e77d1b) dev_taste(DEV,ufsid/49d73f4d44e77d1b) g_part_taste(PART,ufsid/49d73f4d44e77d1b) g_wither_geom(0xc3b26800(ufsid/49d73f4d44e77d1b)) g_detach(0xc3b6f1c0) g_destroy_consumer(0xc3b6f1c0) g_destroy_geom(0xc3b26800(ufsid/49d73f4d44e77d1b)) g_detach(0xc3b6f180) g_destroy_consumer(0xc3b6f180) g_destroy_geom(0xc3ae4380(md0)) g_post_event_x(0xc04cb710, 0xc3b25e00, 2, 0) ref 0xc3b25e00 GEOM_LABEL: Label ufsid/49d73f4d44e77d1b removed. g_slice_spoiled(0xc3b6f0c0/md0) g_wither_geom(0xc3ae4280(md0)) g_orphan_provider(0xc3b26d80(ufsid/49d73f4d44e77d1b), 6) g_orphan_register(ufsid/49d73f4d44e77d1b) g_dev_orphan(0xc3b6f200(ufsid/49d73f4d44e77d1b)) g_detach(0xc3b6f200) g_destroy_consumer(0xc3b6f200) g_destroy_geom(0xc3b26200(ufsid/49d73f4d44e77d1b)) g_detach(0xc3b6f0c0) g_destroy_consumer(0xc3b6f0c0) g_destroy_geom(0xc3ae4280(md0)) procfs registered linprocfs registered -- Thanks, Tai-hwa Liang From owner-freebsd-current@FreeBSD.ORG Sat Apr 4 05:37: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 44E261065686 for ; Sat, 4 Apr 2009 05:37:11 +0000 (UTC) (envelope-from wilkinsa@stlux550.dsto.defence.gov.au) Received: from digger1.defence.gov.au (digger1.defence.gov.au [203.5.217.4]) by mx1.freebsd.org (Postfix) with ESMTP id C3EC68FC0A for ; Sat, 4 Apr 2009 05:37:09 +0000 (UTC) (envelope-from wilkinsa@stlux550.dsto.defence.gov.au) Received: from ednmsw520.dsto.defence.gov.au (ednmsw520.dsto.defence.gov.au [131.185.68.60]) by digger1.defence.gov.au (DSTO/DSTO) with ESMTP id n345WO9L015939 for ; Sat, 4 Apr 2009 15:02:24 +0930 (CST) Received: from ednex510.dsto.defence.gov.au (ednex510.dsto.defence.gov.au) by ednmsw520.dsto.defence.gov.au (Clearswift SMTPRS 5.3.1) with ESMTP id for ; Sat, 4 Apr 2009 16:07:09 +1030 Received: from stlex511.dsto.defence.gov.au ([203.6.60.49]) by ednex510.dsto.defence.gov.au with Microsoft SMTPSVC(6.0.3790.3959); Sat, 4 Apr 2009 16:07:08 +1030 Received: from stlux550.dsto.defence.gov.au ([203.6.60.61]) by stlex511.dsto.defence.gov.au with Microsoft SMTPSVC(6.0.3790.3959); Sat, 4 Apr 2009 13:37:07 +0800 Received: from stlux550.dsto.defence.gov.au (localhost [127.0.0.1]) by stlux550.dsto.defence.gov.au (8.14.3/8.14.3) with ESMTP id n345at9V014491 for ; Sat, 4 Apr 2009 13:36:55 +0800 (WST) (envelope-from wilkinsa@stlux550.dsto.defence.gov.au) Received: (from wilkinsa@localhost) by stlux550.dsto.defence.gov.au (8.14.3/8.14.3/Submit) id n345atXf014490 for freebsd-current@freebsd.org; Sat, 4 Apr 2009 13:36:55 +0800 (WST) (envelope-from wilkinsa) Date: Sat, 4 Apr 2009 13:36:55 +0800 From: "Wilkinson, Alex" To: freebsd-current@freebsd.org Message-ID: <20090404053655.GH3597@stlux503.dsto.defence.gov.au> Mail-Followup-To: freebsd-current@freebsd.org References: <20090331155542.74d89d64@ernst.jennejohn.org> <60084D1E-9F64-463A-A8E9-7A237D5C7661@mac.com> <0904011910169.29800@www.mmlab.cse.yzu.edu.tw> <0904020940371.36257@www.mmlab.cse.yzu.edu.tw> <4CCDEFD6-830E-4C8F-B7A2-B7878F8842BE@mac.com> <0904021314574.37737@www.mmlab.cse.yzu.edu.tw> <09040309313414.76643@www.mmlab.cse.yzu.edu.tw> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline In-Reply-To: Organisation: Defence Science Technology Organisation User-Agent: Mutt/1.5.18 (2008-05-17) X-OriginalArrivalTime: 04 Apr 2009 05:37:07.0924 (UTC) FILETIME=[64DA4140:01C9B4E7] X-TM-AS-Product-Ver: SMEX-8.0.0.1285-5.600.1016-16560.004 X-TM-AS-Result: No--2.494300-8.000000-31 X-TM-AS-User-Approved-Sender: No X-TM-AS-User-Blocked-Sender: No Content-Transfer-Encoding: 7bit Subject: Re: Removal of GEOM_BSD, GEOM_MBR, GEOM_PC98 and GEOM_SUNLABEL 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, 04 Apr 2009 05:37:11 -0000 0n Thu, Apr 02, 2009 at 09:44:02PM -0700, Marcel Moolenaar wrote: >*snip* >> 000001b0 00 00 00 00 00 f2 0e 00 00 00 00 00 00 00 00 01 >> |................| >> 000001c0 c1 ff 83 ef ff ff 3f 00 00 00 21 17 00 01 00 00 >> |......?...!.....| >> 000001d0 c1 ff 05 ef ff ff 60 17 00 01 b0 a8 fe 02 00 00 >> |......`.........| >> 000001e0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 >> |................| >> 000001f0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 55 aa >> |..............U.| >*snip* > >It looks like you have a boot menu entry at 0x1b6. Can you >try the following patch: OK, excuse my lack of skill here, but Marcel how in the hell did you decifer that ? -aW IMPORTANT: This email remains the property of the Australian Defence Organisation and is subject to the jurisdiction of section 70 of the CRIMES ACT 1914. If you have received this email in error, you are requested to contact the sender and delete the email. From owner-freebsd-current@FreeBSD.ORG Sat Apr 4 05:55:54 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 4D1261065672 for ; Sat, 4 Apr 2009 05:55:54 +0000 (UTC) (envelope-from xcllnt@mac.com) Received: from asmtpout011.mac.com (asmtpout011.mac.com [17.148.16.86]) by mx1.freebsd.org (Postfix) with ESMTP id 2A6808FC13 for ; Sat, 4 Apr 2009 05:55:53 +0000 (UTC) (envelope-from xcllnt@mac.com) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Received: from MacBook-Pro.lan.xcllnt.net (mail.xcllnt.net [75.101.29.67]) by asmtp011.mac.com (Sun Java(tm) System Messaging Server 6.3-8.01 (built Dec 16 2008; 32bit)) with ESMTPSA id <0KHK00CWMB53P740@asmtp011.mac.com> for freebsd-current@freebsd.org; Fri, 03 Apr 2009 22:55:52 -0700 (PDT) Message-id: From: Marcel Moolenaar To: Tai-hwa Liang In-reply-to: <09040411131618.87313@www.mmlab.cse.yzu.edu.tw> Date: Fri, 03 Apr 2009 22:55:50 -0700 References: <95891.1238477069@critter.freebsd.dk> <20090331133132.1e191836@ernst.jennejohn.org> <20090331155542.74d89d64@ernst.jennejohn.org> <60084D1E-9F64-463A-A8E9-7A237D5C7661@mac.com> <0904011910169.29800@www.mmlab.cse.yzu.edu.tw> <0904020940371.36257@www.mmlab.cse.yzu.edu.tw> <4CCDEFD6-830E-4C8F-B7A2-B7878F8842BE@mac.com> <0904021314574.37737@www.mmlab.cse.yzu.edu.tw> <09040309313414.76643@www.mmlab.cse.yzu.edu.tw> <0904031327195.78401@www.mmlab.cse.yzu.edu.tw> <8583A3BA-2871-4DF4-9792-1031044A4A22@mac.com> <09040315161311.79260@www.mmlab.cse.yzu.edu.tw> <1DDB4728-7742-4265-999F-F1A0FC69F9E4@mac.com> <0904040858433.86299@www.mmlab.cse.yzu.edu.tw> <7AD352A2-BEDD-4DFD-896D-104E6376D887@mac.com> <09040411131618.87313@www.mmlab.cse.yzu.edu.tw> X-Mailer: Apple Mail (2.930.3) Cc: freebsd-current@freebsd.org Subject: Re: Removal of GEOM_BSD, GEOM_MBR, GEOM_PC98 and GEOM_SUNLABEL 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, 04 Apr 2009 05:55:54 -0000 On Apr 3, 2009, at 8:15 PM, Tai-hwa Liang wrote: > g_part_taste(PART,ad0) > g_part_taste(PART,ad0s1) > g_part_taste(PART,ad0s2) > g_part_taste(PART,ad0s3) > g_part_taste(PART,msdosfs/IBM_PRELOAD) > g_part_taste(PART,ad0s2a) > g_part_taste(PART,ad0s2b) > g_part_taste(PART,ad0s2d) > g_part_taste(PART,ad0s2e) > g_part_taste(PART,ad0s3+00000001) > g_part_taste(PART,ad0s3+000410a1) > g_part_taste(PART,ad0s3+00103bf1) > g_part_taste(PART,ad0s3+0017cda1) > g_part_taste(PART,ufsid/46387cd616292ca8) > g_part_taste(PART,ufsid/46387cd73d66d2ca) > g_part_taste(PART,ufsid/46387cd6c10fa381) > g_part_taste(PART,msdosfs/ ) > g_part_taste(PART,ad0s3+00103bf1a) > g_part_taste(PART,ufsid/46389322544a8c64) > g_part_taste(PART,acd0) > g_part_taste(PART,cd0) > g_part_taste(PART,ad0s2a) > g_part_taste(PART,ufsid/46387cd616292ca8) > g_part_taste(PART,ad0s2d) > g_part_taste(PART,ufsid/46387cd73d66d2ca) > g_part_taste(PART,ad0s2e) > g_part_taste(PART,ufsid/46387cd6c10fa381) > g_part_spoiled(ad0s3+00103bf1) > /dev/ad0s7: FILE SYSTEM CLEAN; SKIPPING CHECKS > /dev/ad0s7: clean, 4999758 free (51910 frags, 618481 blocks, 0.7% > fragmentation) > g_part_taste(PART,ad0s3+00103bf1) > g_part_taste(PART,ad0s3+00103bf1a) > g_part_taste(PART,ufsid/46389322544a8c64) > g_part_spoiled(ad0s3+00103bf1) > g_part_taste(PART,md0) > g_part_taste(PART,ufsid/49d71e25191c321d) > g_part_taste(PART,md0) > g_part_taste(PART,ufsid/49d73f4d44e77d1b) I think your /etc/fstab is wrong. fsck is run on /dev/ad0s7 and not on /dev/ad0s7a. That's why the geom is spoiled and gpart show doesn't list the partition. FYI, -- Marcel Moolenaar xcllnt@mac.com From owner-freebsd-current@FreeBSD.ORG Sat Apr 4 08:50: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 9B302106564A for ; Sat, 4 Apr 2009 08:50:45 +0000 (UTC) (envelope-from thierry.herbelot@free.fr) Received: from smtp2-g21.free.fr (smtp2-g21.free.fr [212.27.42.2]) by mx1.freebsd.org (Postfix) with ESMTP id 15A3A8FC13 for ; Sat, 4 Apr 2009 08:50:43 +0000 (UTC) (envelope-from thierry.herbelot@free.fr) Received: from smtp2-g21.free.fr (localhost [127.0.0.1]) by smtp2-g21.free.fr (Postfix) with ESMTP id B0CEA4B0078 for ; Sat, 4 Apr 2009 10:50:39 +0200 (CEST) Received: from mail.herbelot.nom (bne75-4-82-227-159-103.fbx.proxad.net [82.227.159.103]) by smtp2-g21.free.fr (Postfix) with ESMTP id B2F3E4B0160 for ; Sat, 4 Apr 2009 10:50:36 +0200 (CEST) Received: from tulipe.herbelot.nom (tulipe.herbelot.nom [192.168.2.5]) by mail.herbelot.nom (8.14.1/8.14.1) with ESMTP id n348oYMn005548 for ; Sat, 4 Apr 2009 10:50:35 +0200 (CEST) From: Thierry Herbelot To: freebsd-current@freebsd.org Date: Sat, 4 Apr 2009 10:50:28 +0200 User-Agent: KMail/1.9.10 X-Warning: Windows can lose your files X-Op-Sys: Le FriBi de la mort qui tue X-Org: TfH&Co X-MailScanner: Found to be clean MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200904041050.28932.thierry.herbelot@free.fr> Subject: Stuck kernel while cleaning up the object tree 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, 04 Apr 2009 08:50:45 -0000 Hello, On recent -current machines, I have seen a common pattern, with the machine being frozen (still responsive to pings, though) in the initial phases of the buildworld procedure : example freeze : -------------------------------------------------------------- >>> stage 2.1: cleaning up the object tree -------------------------------------------------------------- cd /usr/src; MAKEOBJDIRPREFIX=/usr/obj MACHINE_ARCH=i386 MACHINE=i386 CPUTYPE= GROFF_BIN_PATH=/usr/obj/usr/src/tmp/legacy/usr/bin GROFF_FONT_PATH=/usr/obj/usr/src/tmp/legacy/usr/share/groff_font GROFF_TMAC_PATH=/usr/obj/usr/src/tmp/legacy/usr/share/tmac _SHLIBDIRPREFIX=/usr/obj/usr/src/tmp VERSION="FreeBSD 8.0-CURRENT i386 800074" INSTALL="sh /usr/src/tools/install.sh" PATH=/usr/obj/usr/src/tmp/legacy/usr/sbin:/usr/obj/usr/src/tmp/legacy/usr/bin:/usr/obj/usr/src/tmp/legacy/usr/games:/usr/obj/usr/src/tmp/usr/sbin:/usr/obj/usr/src/tmp/usr/bin:/usr/obj/usr/src/tmp/usr/games:/sbin:/bin:/usr/sbin:/usr/bin NO_CTF=1 make -f Makefile.inc1 DESTDIR=/usr/obj/usr/src/tmp par-cleandir ===> share/info (cleandir) ===> lib (cleandir) ===> lib/csu/i386-elf (cleandir) [type ^T in the console] load: 0.00 cmd: sh 24587 [*Name Cache] 0.01u 0.00s 0% 1584k The other machines also froze while "cleaning up the object tree". The machines are configured with serial consoles : I have no kernel stack backtrace to aid in pinpointing the cause of this freeze. Cheers TfH From owner-freebsd-current@FreeBSD.ORG Sat Apr 4 09:51: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 3AC491065673 for ; Sat, 4 Apr 2009 09:51:34 +0000 (UTC) (envelope-from thierry.herbelot@free.fr) Received: from smtp4-g21.free.fr (smtp4-g21.free.fr [212.27.42.4]) by mx1.freebsd.org (Postfix) with ESMTP id 730E28FC12 for ; Sat, 4 Apr 2009 09:51:31 +0000 (UTC) (envelope-from thierry.herbelot@free.fr) Received: from smtp4-g21.free.fr (localhost [127.0.0.1]) by smtp4-g21.free.fr (Postfix) with ESMTP id 7EED74C80D7 for ; Sat, 4 Apr 2009 11:51:27 +0200 (CEST) Received: from mail.herbelot.nom (bne75-4-82-227-159-103.fbx.proxad.net [82.227.159.103]) by smtp4-g21.free.fr (Postfix) with ESMTP id 71FF34C8118 for ; Sat, 4 Apr 2009 11:51:25 +0200 (CEST) Received: from tulipe.herbelot.nom (tulipe.herbelot.nom [192.168.2.5]) by mail.herbelot.nom (8.14.1/8.14.1) with ESMTP id n349pNie010426 for ; Sat, 4 Apr 2009 11:51:24 +0200 (CEST) From: Thierry Herbelot To: freebsd-current@freebsd.org Date: Sat, 4 Apr 2009 11:51:17 +0200 User-Agent: KMail/1.9.10 References: <200904041050.28932.thierry.herbelot@free.fr> In-Reply-To: <200904041050.28932.thierry.herbelot@free.fr> X-Warning: Windows can lose your files X-Op-Sys: Le FriBi de la mort qui tue X-Org: TfH&Co X-MailScanner: Found to be clean MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit Content-Disposition: inline Message-Id: <200904041151.18209.thierry.herbelot@free.fr> Subject: Re: Stuck kernel while cleaning up the object tree 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, 04 Apr 2009 09:51:34 -0000 Le Saturday 04 April 2009, Thierry Herbelot a écrit : > Hello, > > On recent -current machines, I have seen a common pattern, with the machine > being frozen (still responsive to pings, though) in the initial phases of > the buildworld procedure : > > example freeze : > -------------------------------------------------------------- > > >>> stage 2.1: cleaning up the object tree > > -------------------------------------------------------------- > cd /usr/src; MAKEOBJDIRPREFIX=/usr/obj MACHINE_ARCH=i386 MACHINE=i386 > CPUTYPE= GROFF_BIN_PATH=/usr/obj/usr/src/tmp/legacy/usr/bin > GROFF_FONT_PATH=/usr/obj/usr/src/tmp/legacy/usr/share/groff_font > GROFF_TMAC_PATH=/usr/obj/usr/src/tmp/legacy/usr/share/tmac > _SHLIBDIRPREFIX=/usr/obj/usr/src/tmp VERSION="FreeBSD 8.0-CURRENT i386 > 800074" INSTALL="sh /usr/src/tools/install.sh" > PATH=/usr/obj/usr/src/tmp/legacy/usr/sbin:/usr/obj/usr/src/tmp/legacy/usr/b >in:/usr/obj/usr/src/tmp/legacy/usr/games:/usr/obj/usr/src/tmp/usr/sbin:/usr/ >obj/usr/src/tmp/usr/bin:/usr/obj/usr/src/tmp/usr/games:/sbin:/bin:/usr/sbin: >/usr/bin NO_CTF=1 make -f Makefile.inc1 DESTDIR=/usr/obj/usr/src/tmp > par-cleandir ===> share/info (cleandir) > ===> lib (cleandir) > ===> lib/csu/i386-elf (cleandir) > [type ^T in the console] > load: 0.00 cmd: sh 24587 [*Name Cache] 0.01u 0.00s 0% 1584k > > The other machines also froze while "cleaning up the object tree". > > The machines are configured with serial consoles : I have no kernel stack > backtrace to aid in pinpointing the cause of this freeze. > > Cheers > > TfH With a bit more investigation : on a separate ssh session, top is still live and shows processes stuck as : 24523 root 1 76 0 1888K 764K *Name 1 0:00 0.00% make on still another machine, running Witnesses (all other machines run with a lean GENERIC, with most of the debuging features commented out) : System call __getcwd returning with the following locks held: shared rw Name Cache (Name Cache) r = 0 (0xc0ee7e1c) locked @ /usr/src/sys/kerne/vfs_cache.c:974 panic: witness_warn cpuid = 0 KDB: enter: panic TfH > _______________________________________________ > 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 Sat Apr 4 10:11: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 0D335106566B for ; Sat, 4 Apr 2009 10:11:59 +0000 (UTC) (envelope-from bsam@ipt.ru) Received: from services.ipt.ru (services.ipt.ru [194.62.233.110]) by mx1.freebsd.org (Postfix) with ESMTP id BEFDF8FC0A for ; Sat, 4 Apr 2009 10:11:58 +0000 (UTC) (envelope-from bsam@ipt.ru) Received: from bb.ipt.ru ([194.62.233.89]) by services.ipt.ru with esmtp (Exim 4.54 (FreeBSD)) id 1Lq2qz-000DEs-Gv; Sat, 04 Apr 2009 14:11:57 +0400 To: Thierry Herbelot References: <200904041050.28932.thierry.herbelot@free.fr> <200904041151.18209.thierry.herbelot@free.fr> From: Boris Samorodov Date: Sat, 04 Apr 2009 14:11:56 +0400 In-Reply-To: <200904041151.18209.thierry.herbelot@free.fr> (Thierry Herbelot's message of "Sat\, 4 Apr 2009 11\:51\:17 +0200") Message-ID: <10969763@bb.ipt.ru> User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.3 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Cc: freebsd-current@freebsd.org, peter@FreeBSD.org Subject: Re: Stuck kernel while cleaning up the object tree 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, 04 Apr 2009 10:11:59 -0000 On Sat, 4 Apr 2009 11:51:17 +0200 Thierry Herbelot wrote: > Le Saturday 04 April 2009, Thierry Herbelot a écrit : > > Hello, > > > > On recent -current machines, I have seen a common pattern, with the machine > > being frozen (still responsive to pings, though) in the initial phases of > > the buildworld procedure : > > > > example freeze : > > -------------------------------------------------------------- > > > > >>> stage 2.1: cleaning up the object tree > > > > -------------------------------------------------------------- > > cd /usr/src; MAKEOBJDIRPREFIX=/usr/obj MACHINE_ARCH=i386 MACHINE=i386 > > CPUTYPE= GROFF_BIN_PATH=/usr/obj/usr/src/tmp/legacy/usr/bin > > GROFF_FONT_PATH=/usr/obj/usr/src/tmp/legacy/usr/share/groff_font > > GROFF_TMAC_PATH=/usr/obj/usr/src/tmp/legacy/usr/share/tmac > > _SHLIBDIRPREFIX=/usr/obj/usr/src/tmp VERSION="FreeBSD 8.0-CURRENT i386 > > 800074" INSTALL="sh /usr/src/tools/install.sh" > > PATH=/usr/obj/usr/src/tmp/legacy/usr/sbin:/usr/obj/usr/src/tmp/legacy/usr/b > >in:/usr/obj/usr/src/tmp/legacy/usr/games:/usr/obj/usr/src/tmp/usr/sbin:/usr/ > >obj/usr/src/tmp/usr/bin:/usr/obj/usr/src/tmp/usr/games:/sbin:/bin:/usr/sbin: > >/usr/bin NO_CTF=1 make -f Makefile.inc1 DESTDIR=/usr/obj/usr/src/tmp > > par-cleandir ===> share/info (cleandir) > > ===> lib (cleandir) > > ===> lib/csu/i386-elf (cleandir) > > [type ^T in the console] > > load: 0.00 cmd: sh 24587 [*Name Cache] 0.01u 0.00s 0% 1584k > > > > The other machines also froze while "cleaning up the object tree". > > > > The machines are configured with serial consoles : I have no kernel stack > > backtrace to aid in pinpointing the cause of this freeze. > > > > Cheers > > > > TfH > With a bit more investigation : > on a separate ssh session, top is still live and shows processes stuck as : > 24523 root 1 76 0 1888K 764K *Name 1 0:00 0.00% make > on still another machine, running Witnesses (all other machines run with a > lean GENERIC, with most of the debuging features commented out) : > System call __getcwd returning with the following locks held: > shared rw Name Cache (Name Cache) r = 0 (0xc0ee7e1c) locked > @ /usr/src/sys/kerne/vfs_cache.c:974 This is definitely related to: SVN rev 190655 on 2009-04-02 21:16:20Z by peter (peter@ CCed) > panic: witness_warn > cpuid = 0 > KDB: enter: panic WBR -- Boris Samorodov (bsam) Research Engineer, http://www.ipt.ru Telephone & Internet SP FreeBSD Committer, http://www.FreeBSD.org The Power To Serve From owner-freebsd-current@FreeBSD.ORG Sat Apr 4 11:55: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 3B4871065677 for ; Sat, 4 Apr 2009 11:55:50 +0000 (UTC) (envelope-from M.S.Powell@salford.ac.uk) Received: from airy.salford.ac.uk (airy.salford.ac.uk [146.87.0.11]) by mx1.freebsd.org (Postfix) with SMTP id 8F4288FC1A for ; Sat, 4 Apr 2009 11:55:49 +0000 (UTC) (envelope-from M.S.Powell@salford.ac.uk) Received: (qmail 19479 invoked by uid 98); 4 Apr 2009 12:55:47 +0100 Received: from 146.87.255.121 by airy.salford.ac.uk (envelope-from , uid 401) with qmail-scanner-2.01 (clamdscan: 0.94.2/9204. spamassassin: 3.2.4. Clear:RC:1(146.87.255.121):. Processed in 0.03569 secs); 04 Apr 2009 11:55:47 -0000 Received: from rust.salford.ac.uk (HELO rust.salford.ac.uk) (146.87.255.121) by airy.salford.ac.uk (qpsmtpd/0.3x.614) with SMTP; Sat, 04 Apr 2009 12:55:47 +0100 Received: (qmail 41721 invoked by uid 1002); 4 Apr 2009 11:55:45 -0000 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 4 Apr 2009 11:55:45 -0000 Date: Sat, 4 Apr 2009 12:55:45 +0100 (BST) From: "Mark Powell" To: freebsd-current@freebsd.org Message-ID: <20090404124909.C24261@rust.salford.ac.uk> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Subject: panic: vput: negative ref cnt 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, 04 Apr 2009 11:55:50 -0000 Hi, Getting a reproducable panic during backups: panic: vput: negative ref cnt cpuid = 0 KDB: enter: panic [thread pid 3521 tid 100374 ] Stopped at kdb_enter+0x3d: movq $0,0x654104(%rip) db> bt Tracing pid 3521 tid 100374 0xffffff008c79e380 kdb_enter() at kdb_enter+0x3d panic() at panic+0x176 vput() at vput+0x10c dounmount() at dounmount0x421 unmount() at unmount+0x24b syscall() at syscall+0x1bf Xfast_syscall() at Xfast_syscall+0xab --- syscall (22, FreeBSD ELF64, unmount), rip = 0x800695d7c, rsp = 0x7fffffffe218, rbp = 0 --- My script takes a zfs snapshot, mounts the snapshot, backs it up using star, then umounts the snapshot. The panic seems to occur on the umount. Cheers. -- Mark Powell - UNIX System Administrator - The University of Salford Information & Learning Services, Clifford Whitworth Building, Salford University, Manchester, M5 4WT, UK. Tel: +44 161 295 6843 Fax: +44 161 295 5888 www.pgp.com for PGP key From owner-freebsd-current@FreeBSD.ORG Sat Apr 4 12:30: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 54143106564A for ; Sat, 4 Apr 2009 12:30:13 +0000 (UTC) (envelope-from michael.copeland@gmail.com) Received: from yx-out-2324.google.com (yx-out-2324.google.com [74.125.44.29]) by mx1.freebsd.org (Postfix) with ESMTP id 0B6EC8FC19 for ; Sat, 4 Apr 2009 12:30:12 +0000 (UTC) (envelope-from michael.copeland@gmail.com) Received: by yx-out-2324.google.com with SMTP id 8so925709yxm.13 for ; Sat, 04 Apr 2009 05:30:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:subject:content-type :content-transfer-encoding; bh=4seFlgjXnIweFmpcGkZCSFTknqVKsn7yKSDbwxPzPVE=; b=sTN6GO2W031IqSvT8l5UajujMDzX10b5+qe4D/4d3tHIPLFkpp/aHEhgdXNIuCUP9T L2kABEfiASxMszb0A5gghW3PlAuSv1t0LQpvLdgCPVo+eJXn9iWVLAvCBkP1B9zpKvE/ T/vpcMc9sNpxZCxWK05hXyLHqfelRRVGvZuGc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding; b=LQCZ1Mt/9ygGXm9y12bcGHs9VWH5LKiNpTDjgt2xmMLe2vaPUVWu0+Lh1SNffacYck rHcNSJNtaEoGpL/Q2BxEl0kti/udTopeF+iskcvC1pwOWa4u9NJNA3iCSbw7ILAVbEu/ s9l6wqL89JP/0vGPVDIGEbGGAy1xZ+sFbrEqc= Received: by 10.90.120.14 with SMTP id s14mr1416655agc.121.1238848212537; Sat, 04 Apr 2009 05:30:12 -0700 (PDT) Received: from ?10.10.10.2? (adsl-074-245-053-043.sip.jax.bellsouth.net [74.245.53.43]) by mx.google.com with ESMTPS id 39sm4000705aga.35.2009.04.04.05.30.11 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sat, 04 Apr 2009 05:30:12 -0700 (PDT) Message-ID: <49D752D2.4090902@gmail.com> Date: Sat, 04 Apr 2009 08:30:10 -0400 From: michael User-Agent: Thunderbird 2.0.0.21 (X11/20090318) MIME-Version: 1.0 To: freebsd-current@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: rt2870 wireless chipset 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, 04 Apr 2009 12:30:14 -0000 is this chip or will this chip be covered under the rum module? if it has not already been started on, i've noticed from looking at the ralink opensource driver that it seems be structured nearly identical to the rt73 driver. eg: its used in the version 3 of the linksys WUSB54GC compact wireless adapter. version 1 was the rt73 which already works with the rum module. what i'm asking is, since the two linux drivers seem nearly identical; would it be very difficult for me to copy the rum driver source to another directory and make the changes evident in the linux driver(mainly dealing with loading the rt2870 firmware file) in the copied rum driver? thank you for your insight, michael From owner-freebsd-current@FreeBSD.ORG Sat Apr 4 12:54: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 565B9106564A for ; Sat, 4 Apr 2009 12:54:42 +0000 (UTC) (envelope-from christoph.mallon@gmx.de) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by mx1.freebsd.org (Postfix) with SMTP id A7B138FC08 for ; Sat, 4 Apr 2009 12:54:41 +0000 (UTC) (envelope-from christoph.mallon@gmx.de) Received: (qmail invoked by alias); 04 Apr 2009 12:27:58 -0000 Received: from p54A3D407.dip.t-dialin.net (EHLO tron.homeunix.org) [84.163.212.7] by mail.gmx.net (mp052) with SMTP; 04 Apr 2009 14:27:58 +0200 X-Authenticated: #1673122 X-Provags-ID: V01U2FsdGVkX1/ILFghBaHILIC9P12+xyYROJt2yd7qjtxF7U+FUn mlmllDfTxabFc2 Message-ID: <49D7524D.1090508@gmx.de> Date: Sat, 04 Apr 2009 14:27:57 +0200 From: Christoph Mallon User-Agent: Thunderbird 2.0.0.19 (X11/20090103) MIME-Version: 1.0 To: freebsd-current@freebsd.org References: <20090331155542.74d89d64@ernst.jennejohn.org> <60084D1E-9F64-463A-A8E9-7A237D5C7661@mac.com> <0904011910169.29800@www.mmlab.cse.yzu.edu.tw> <0904020940371.36257@www.mmlab.cse.yzu.edu.tw> <4CCDEFD6-830E-4C8F-B7A2-B7878F8842BE@mac.com> <0904021314574.37737@www.mmlab.cse.yzu.edu.tw> <09040309313414.76643@www.mmlab.cse.yzu.edu.tw> <20090404053655.GH3597@stlux503.dsto.defence.gov.au> In-Reply-To: <20090404053655.GH3597@stlux503.dsto.defence.gov.au> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-FuHaFi: 0.55 Subject: Re: Removal of GEOM_BSD, GEOM_MBR, GEOM_PC98 and GEOM_SUNLABEL 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, 04 Apr 2009 12:54:42 -0000 Wilkinson, Alex schrieb: > 0n Thu, Apr 02, 2009 at 09:44:02PM -0700, Marcel Moolenaar wrote: > > >*snip* > >> 000001b0 00 00 00 00 00 f2 0e 00 00 00 00 00 00 00 00 01 > >> |................| > >> 000001c0 c1 ff 83 ef ff ff 3f 00 00 00 21 17 00 01 00 00 > >> |......?...!.....| > >> 000001d0 c1 ff 05 ef ff ff 60 17 00 01 b0 a8 fe 02 00 00 > >> |......`.........| > >> 000001e0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > >> |................| > >> 000001f0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 55 aa > >> |..............U.| > >*snip* > > > >It looks like you have a boot menu entry at 0x1b6. Can you > >try the following patch: > > OK, excuse my lack of skill here, but Marcel how in the hell did you decifer that ? Read from the back: The last two bytes (55 AA) are a magic marker. Before that are four times 16 bytes, which describe the four possible partitions (start, size, type etc.). For MBRs (Master Boot Record) all four can be used, for EBRs (Extended Boot Record) the 3rd and 4th are always zero (i.e. unused). Before that (0x01B5 till 0x01BD) are are the nine non-zero bytes, which caused the trouble. More info about the layout of the partition entries etc.: http://en.wikipedia.org/wiki/Extended_Boot_Record Christoph From owner-freebsd-current@FreeBSD.ORG Sat Apr 4 13:38: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 AAC4E106564A for ; Sat, 4 Apr 2009 13:38:22 +0000 (UTC) (envelope-from onemda@gmail.com) Received: from mail-ew0-f171.google.com (mail-ew0-f171.google.com [209.85.219.171]) by mx1.freebsd.org (Postfix) with ESMTP id 3E5618FC15 for ; Sat, 4 Apr 2009 13:38:21 +0000 (UTC) (envelope-from onemda@gmail.com) Received: by ewy19 with SMTP id 19so1253911ewy.43 for ; Sat, 04 Apr 2009 06:38:20 -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=SZDqU74MkI6k43ro4hqxpxtva4w3PjLfpK9Ei6QBP4M=; b=xh53ROyTracTGRthdYxfhivAvwl6D5Nh7gWxjsH/6vypEMGCRegcWe2CsupwfjkSU/ W/6rKtf2Z7kdTywqCqnSgrT3i6PGpL0aq8733OyWh2ncbjAbxq59NpWHos5tUVpTwJW4 yQqaED6hWlUhWSbnfESf+ZWNbFeUqtZUufqXI= 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=Sd6VlFfrzEP3BVUXClaDRWnUL1tgtVXQgV9YvV6dUp2+13LMjaH0lKO2lXDsLzL9NK IORviOWijs0fU1px0oJopPWVRDVMWrWuFgjDcY0C5CGeZdxIK6H7MmkqoaUbJ9Baf/DY h9yT0cMnuSHb1XTaS4KKVYRzcUJHzVkp/MaKk= MIME-Version: 1.0 Received: by 10.210.38.5 with SMTP id l5mr1353961ebl.73.1238852300678; Sat, 04 Apr 2009 06:38:20 -0700 (PDT) In-Reply-To: <49D752D2.4090902@gmail.com> References: <49D752D2.4090902@gmail.com> Date: Sat, 4 Apr 2009 15:38:20 +0200 Message-ID: <3a142e750904040638p5714282cwab08835d00ea4dde@mail.gmail.com> From: "Paul B. Mahol" To: michael Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: rt2870 wireless chipset 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, 04 Apr 2009 13:38:23 -0000 On 4/4/09, michael wrote: > is this chip or will this chip be covered under the rum module? if it > has not already been started on, i've noticed from looking at the ralink > opensource driver that it seems be structured nearly identical to the > rt73 driver. eg: its used in the version 3 of the linksys WUSB54GC > compact wireless adapter. version 1 was the rt73 which already works > with the rum module. what i'm asking is, since the two linux drivers > seem nearly identical; would it be very difficult for me to copy the rum > driver source to another directory and make the changes evident in the > linux driver(mainly dealing with loading the rt2870 firmware file) in > the copied rum driver? What about non evident things :-), Just go ahead, but note that if you make some terrible mistake that you can say goodbye to chip. -- Paul From owner-freebsd-current@FreeBSD.ORG Sat Apr 4 15:16: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 A168D106564A for ; Sat, 4 Apr 2009 15:16:51 +0000 (UTC) (envelope-from avatar@mmlab.cse.yzu.edu.tw) Received: from www.mmlab.cse.yzu.edu.tw (www.mmlab.cse.yzu.edu.tw [140.138.150.166]) by mx1.freebsd.org (Postfix) with ESMTP id 035088FC0A for ; Sat, 4 Apr 2009 15:16:50 +0000 (UTC) (envelope-from avatar@mmlab.cse.yzu.edu.tw) Received: by www.mmlab.cse.yzu.edu.tw (qmail, from userid 1000) id 44176E43407; Sat, 4 Apr 2009 23:16:28 +0800 (CST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=mmlab.cse.yzu.edu.tw; s=test; t=1238858188; bh=DJ77M1oWJSnuNCfPzurDtFBtLRVOH1JUmRWUMQ1Ajlo=; h=Date:From:To:cc:Subject:In-Reply-To:Message-ID:References: MIME-Version:Content-Type; b=hEWenoB06Gy6r6rlDqRtJBzakJqNgCsnrVYyiFB8HVIs3D4EvSbVGaJ6JKHL9Q0Po xfkE7gPmVgK8tgs30u2sjSAFQx7dcXBIXq7oZjSj8Z8Q7P/FXMP7AeWH/WD7h2rQwe /gTGdZDOGBvamTTmR/oBDHDQUAft3KoiZV7pF+5w= Received: from localhost (localhost [127.0.0.1]) by www.mmlab.cse.yzu.edu.tw (qmail) with ESMTP id 421E2E43406; Sat, 4 Apr 2009 23:16:28 +0800 (CST) Date: Sat, 4 Apr 2009 23:16:28 +0800 (CST) From: Tai-hwa Liang To: Marcel Moolenaar In-Reply-To: Message-ID: <09040423143118.91304@www.mmlab.cse.yzu.edu.tw> References: <20090331155542.74d89d64@ernst.jennejohn.org> <60084D1E-9F64-463A-A8E9-7A237D5C7661@mac.com> <0904011910169.29800@www.mmlab.cse.yzu.edu.tw> <0904020940371.36257@www.mmlab.cse.yzu.edu.tw> <4CCDEFD6-830E-4C8F-B7A2-B7878F8842BE@mac.com> <0904021314574.37737@www.mmlab.cse.yzu.edu.tw> <09040309313414.76643@www.mmlab.cse.yzu.edu.tw> <0904031327195.78401@www.mmlab.cse.yzu.edu.tw> <8583A3BA-2871-4DF4-9792-1031044A4A22@mac.com> <09040315161311.79260@www.mmlab.cse.yzu.edu.tw> <1DDB4728-7742-4265-999F-F1A0FC69F9E4@mac.com> <0904040858433.86299@www.mmlab.cse.yzu.edu.tw> <7AD352A2-BEDD-4DFD-896D-104E6376D887@mac.com> <09040411131618.87313@www.mmlab.cse.yzu.edu.tw> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-current@freebsd.org Subject: Re: Removal of GEOM_BSD, GEOM_MBR, GEOM_PC98 and GEOM_SUNLABEL 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, 04 Apr 2009 15:16:52 -0000 On Fri, 3 Apr 2009, Marcel Moolenaar wrote: > On Apr 3, 2009, at 8:15 PM, Tai-hwa Liang wrote: [...] >> g_part_spoiled(ad0s3+00103bf1) >> /dev/ad0s7: FILE SYSTEM CLEAN; SKIPPING CHECKS >> /dev/ad0s7: clean, 4999758 free (51910 frags, 618481 blocks, 0.7% >> fragmentation) >> g_part_taste(PART,ad0s3+00103bf1) >> g_part_taste(PART,ad0s3+00103bf1a) >> g_part_taste(PART,ufsid/46389322544a8c64) >> g_part_spoiled(ad0s3+00103bf1) >> g_part_taste(PART,md0) >> g_part_taste(PART,ufsid/49d71e25191c321d) >> g_part_taste(PART,md0) >> g_part_taste(PART,ufsid/49d73f4d44e77d1b) > > I think your /etc/fstab is wrong. fsck is run on /dev/ad0s7 > and not on /dev/ad0s7a. That's why the geom is spoiled and > gpart show doesn't list the partition. I have to use ad0s7 after moving to GEOM_PART_{BSD,EBR,MBR}; otherwise, booting with with /dev/ad0s7a looks like: g_ignition g_modevent(DISK, LOAD) g_post_event_x(0xc04cd490, 0xc38060a0, 2, 0) g_modevent(PART, LOAD) g_post_event_x(0xc04cd490, 0xc3806090, 2, 0) g_modevent(DEV, LOAD) g_post_event_x(0xc04cd490, 0xc3806080, 2, 0) g_modevent(VFS, LOAD) g_post_event_x(0xc04cd490, 0xc3806040, 2, 0) g_modevent(SWAP, LOAD) g_post_event_x(0xc04cd490, 0xc3806030, 2, 0) g_modevent(LABEL, LOAD) g_post_event_x(0xc04cd490, 0xc3806020, 2, 0) random: g_modevent(ACD, LOAD) g_post_event_x(0xc04cd490, 0xc3806590, 2, 0) g_post_event_x(0xc04cd2c0, 0xc38e5a00, 2, 0) g_post_event_x(0xc04cd2c0, 0xc38e59f0, 2, 0) g_post_event_x(0xc04cd2c0, 0xc38e5820, 2, 0) g_post_event_x(0xc04cd2c0, 0xc38e5700, 2, 0) ata0: Identifying devices: 00000001 ata0: New devices: 00000001 g_load_class(DISK) g_load_class(PART) g_load_class(DEV) g_load_class(VFS) g_load_class(SWAP) g_load_class(LABEL) g_load_usbus0: 12Mbps Full Speed USB v1.0 class(ACD) g_retaste(PART)ad0: setting PIO4 on ICH4 chip g_retaste(PART) g_retaste(PART)ad0: setting UDMA100 on ICH4 chip g_retaste(PART) ad0: 228338850 sectors [226526C/16H/63S] 16 sectors/interrupt 1 depth queue g_post_event_x(0xc04c78b0, 0xc39e4c00, 2, 0) ref 0xc39e4c00 g_post_event_x(0xc04cb510, 0xc384cb00, 2, 0) ref 0xc384cb00 ref 0xc384ca80 GEOM: new disk ad0 g_label_taste(LABEL, ad0) g_detach(0xc39e2c80) g_destroy_consumer(0xc39e2c80) g_destroy_geom(0xc388a280(label:taste)) dev_taste(DEV,ad0) g_part_taste(PART,ad0) g_post_event_x(0xc04cb510, 0xc3ade400, 2, 0) ref 0xc3ade400 ref 0xc39a8a80 g_post_event_x(0xc04cb510, 0xc39a8d80, 2, 0) ref 0xc39a8d80 ref 0xc39a8a80 g_post_event_x(0xc04cb510, 0xc3ade680, 2, 0) ref 0xc3ade680 ref 0xc39a8a80 g_label_taste(LABEL, ad0s1) g_slice_config(ad0s1, 0, 1) g_post_event_x(0xc04cb510, 0xc388a280, 2, 0) ref 0xc388a280 ref 0xc3ade380 GEOM_LABEL: Label for provider ad0s1 is msdosfs/IBM_PRELOAD. g_detach(0xc3ae0c80) g_destroy_consumer(0xc3ae0c80) g_destroy_geom(0xc384cd80(label:taste)) dev_taste(DEV,ad0s1) g_part_taste(PART,ad0s1) g_wither_geom(0xc3ae2700(ad0s1)) g_label_taste(LABEL, ad0s2) g_detach(0xc3ae0b00) g_destroy_consumer(0xc3ae0b00) g_destroy_geom(0xc3ae2600(label:taste)) dev_taste(DEV,ad0s2) g_part_taste(PART,ad0s2) g_post_event_x(0xc04cb510, 0xc3ae2400, 2, 0) ref 0xc3ae2400 ref 0xc3ae2500 g_post_event_x(0xc04cb510, 0xc3ae2300, 2, 0) ref 0xc3ae2300 ref 0xc3ae2500 g_post_event_x(0xc04cb510, 0xc3ae2200, 2, 0) ref 0xc3ae2200 ref 0xc3ae2500 g_post_event_x(0xc04cb510, 0xc3ae2100, 2, 0) ref 0xc3ae2100 ref 0xc3ae2500 g_label_taste(LABEL, ad0s3) g_detach(0xc3ae0880) g_destroy_consumer(0xc3ae0880) g_destroy_geom(0xc3ae2000(label:taste)) dev_taste(DEV,ad0s3) g_part_taste(PART,ad0s3) g_post_event_x(0xc04cb510, 0xc3aded00, 2, 0) ref 0xc3aded00 ref 0xc3adee00 g_post_event_x(0xc04cb510, 0xc3adec00, 2, 0) ref 0xc3adec00 ref 0xc3adee00 g_post_event_x(0xc04cb510, 0xc3adeb00, 2, 0) ref 0xc3adeb00 ref 0xc3adee00 g_post_event_x(0xc04cb510, 0xc3adea00, 2, 0) ref 0xc3adea00 ref 0xc3adee00 g_label_taste(LABEL, msdosfs/IBM_PRELOAD) dev_taste(DEV,msdosfs/IBM_PRELOAD) g_part_taste(PART,msdosfs/IBM_PRELOAD) g_wither_geom(0xc3ade800(msdosfs/IBM_PRELOAD)) g_label_taste(LABEL, ad0s2a) g_slice_config(ad0s2a, 0, 1) g_post_event_x(0xc04cb510, 0xc3ade700, 2, 0) ref 0xc3ade700 ref 0xc3ade780 GEOM_LABEL: Label for provider ad0s2a is ufsid/46387cd616292ca8. g_detach(0xc3ae0580) g_destroy_consumer(0xc3ae0580) g_destroy_geom(0xc3ae2800(label:taste)) dev_taste(DEV,ad0s2a) g_part_taste(PART,ad0s2a) g_wither_geom(0xc3ade600(ad0s2a)) g_label_taste(LABEL, ad0s2b) g_detach(0xc3ae0440) g_destroy_consumer(0xc3ae0440) g_destroy_geom(0xc3ae2600(label:taste)) dev_taste(DEV,ad0s2b) g_part_taste(PART,ad0s2b) g_wither_geom(0xc3ae2680(ad0s2b)) g_label_taste(LABEL, ad0s2d) g_slice_config(ad0s2d, 0, 1) g_post_event_x(0xc04cb510, 0xc3ae2600, 2, 0) ref 0xc3ae2600 ref 0xc3ae2280 GEOM_LABEL: Label for provider ad0s2d is ufsid/46387cd73d66d2ca. g_detach(0xc3ae0340) g_destroy_consumer(0xc3ae0340) g_destroy_geom(0xc384cd80(label:taste)) dev_taste(DEV,ad0s2d) g_part_taste(PART,ad0s2d) g_wither_geom(0xc384cd80(ad0s2d)) g_label_taste(LABEL, ad0s2e) g_slice_config(ad0s2e, 0, 1) g_post_event_x(0xc04cb510, 0xc3aef880, 2, 0) ref 0xc3aef880 ref 0xc3aef900 GEOM_LABEL: Label for provider ad0s2e is ufsid/46387cd6c10fa381. g_detach(0xc3ae0200) g_destroy_consumer(0xc3ae0200) g_destroy_geom(0xc3ae2180(label:taste)) dev_taste(DEV,ad0s2e) g_part_taste(PART,ad0s2e) g_wither_geom(0xc3aef700(ad0s2e)) g_label_taste(LABEL, ad0s3+00000001) g_detach(0xc3ae00c0) g_destroy_consumer(0xc3ae00c0) g_destroy_geom(0xc3aef680(label:taste)) dev_taste(DEV,ad0s3+00000001) g_part_taste(PART,ad0s3+00000001) g_wither_geom(0xc3aef580(ad0s3+00000001)) g_label_taste(LABEL, ad0s3+000410a1) g_slice_config(ad0s3+000410a1, 0, 1) g_post_event_x(0xc04cb510, 0xc3aef380, 2, 0) ref 0xc3aef380 ref 0xc3aef400 GEOM_LABEL: Label for provider ad0s3+000410a1 is msdosfs/ . g_detach(0xc3ae0440) g_destroy_consumer(0xc3ae0440) g_destroy_geom(0xc3aef480(label:taste)) dev_taste(DEV,ad0s3+000410a1) g_part_taste(PART,ad0s3+000410a1) g_wither_geom(0xc3aef200(ad0s3+000410a1)) g_label_taste(LABEL, ad0s3+00103bf1) g_detach(0xc3ae0c80) g_destroy_consumer(0xc3ae0c80) g_destroy_geom(0xc3aef100(label:taste)) dev_taste(DEV,ad0s3+00103bf1) g_part_taste(PART,ad0s3+00103bf1) g_post_event_x(0xc04cb510, 0xc3ae2e00, 2, 0) ref 0xc3ae2e00 ref 0xc3aef000 g_label_taste(LABEL, ad0s3+0017cda1) g_detach(0xc3af6280) g_destroy_consumer(0xc3af6280) g_destroy_geom(0xc3ae2d00(label:taste)) dev_taste(DEV,ad0s3+0017cda1) g_part_taste(PART,ad0s3+0017cda1) g_wither_geom(0xc3ae2c00(ad0s3+0017cda1)) g_label_taste(LABEL, ufsid/46387cd616292ca8) dev_taste(DEV,ufsid/46387cd616292ca8) g_part_taste(PART,ufsid/46387cd616292ca8) g_wither_geom(0xc3ae2a00(ufsid/46387cd616292ca8)) g_label_taste(LABEL, ufsid/46387cd73d66d2ca) dev_taste(DEV,ufsid/46387cd73d66d2ca) g_part_taste(PART,ufsid/46387cd73d66d2ca) g_wither_geom(0xc3ae2880(ufsid/46387cd73d66d2ca)) g_label_taste(LABEL, ufsid/46387cd6c10fa381) dev_taste(DEV,ufsid/46387cd6c10fa381) g_part_taste(PART,ufsid/46387cd6c10fa381) g_wither_geom(0xc3ade980(ufsid/46387cd6c10fa381)) g_label_taste(LABEL, msdosfs/ ) dev_taste(DEV,msdosfs/ ) g_part_taste(PART,msdosfs/ ) g_wither_geom(0xc3ae2d00(msdosfs/ )) g_label_taste(LABEL, ad0s3+00103bf1a) g_slice_config(ad0s3+00103bf1a, 0, 1) g_post_event_x(0xc04cb510, 0xc3aef180, 2, 0) ref 0xc3aef180 ref 0xc3adeb80 GEOM_LABEL: Label for provider ad0s3+00103bf1a is ufsid/46389322544a8c64. g_detach(0xc3ae4d40) g_destroy_consumer(0xc3ae4d40) g_destroy_geom(0xc3aef100(label:taste)) dev_taste(DEV,ad0s3+00103bf1a) g_part_taste(PART,ad0s3+00103bf1a) g_wither_geom(0xc3aef500(ad0s3+00103bf1a)) g_label_taste(LABEL, ufsid/46389322544a8c64) dev_taste(DEV,ufsid/46389322544a8c64) g_part_taste(PART,ufsid/46389322544a8c64) g_wither_geom(0xc3ae2180(ufsid/46389322544a8c64)) g_detach(0xc3ae4bc0) g_destroy_consumer(0xc3ae4bc0) g_destroy_geom(0xc3ae2180(ufsid/46389322544a8c64)) g_detach(0xc3ae4c40) g_destroy_consumer(0xc3ae4c40) g_destroy_geom(0xc3aef500(ad0s3+00103bf1a)) g_detach(0xc3ae4dc0) g_destroy_consumer(0xc3ae4dc0) g_destroy_geom(0xc3ae2d00(msdosfs/ )) g_detach(0xc3ae4e80) g_destroy_consumer(0xc3ae4e80) g_destroy_geom(0xc3ade980(ufsid/46387cd6c10fa381)) g_detach(0xc3af6040) g_destroy_consumer(0xc3af6040) g_destroy_geom(0xc3ae2880(ufsid/46387cd73d66d2ca)) g_detach(0xc3af60c0) g_destroy_consumer(0xc3af60c0) g_destroy_geom(0xc3ae2a00(ufsid/46387cd616292ca8)) g_detach(0xc3af6180) g_destroy_consumer(0xc3af6180) g_destroy_geom(0xc3ae2c00(ad0s3+0017cda1)) g_detach(0xc3ae0b00) g_destroy_consumer(0xc3ae0b00) g_destroy_geom(0xc3aef200(ad0s3+000410a1)) g_detach(0xc3ae0200) g_destroy_consumer(0xc3ae0200) g_destroy_geom(0xc3aef580(ad0s3+00000001)) g_detach(0xc3ae0100) g_destroy_consumer(0xc3ae0100) g_destroy_geom(0xc3aef700(ad0s2e)) g_detach(0xc3ae0240) g_destroy_consumer(0xc3ae0240) g_destroy_geom(0xc384cd80(ad0s2d)) g_detach(0xc3ae0380) g_destroy_consumer(0xc3ae0380) g_destroy_geom(0xc3ae2680(ad0s2b)) g_detach(0xc3ae0480) g_destroy_consumer(0xc3ae0480) g_destroy_geom(0xc3ade600(ad0s2a)) g_detach(0xc3ae0600) g_destroy_consumer(0xc3ae0600) g_destroy_geom(0xc3ade800(msdosfs/IBM_PRELOAD)) g_detach(0xc3ae0b80) g_destroy_consumer(0xc3ae0b80) g_destroy_geom(0xc3ae2700(ad0s1)) g_post_event_x(0xc04863d0, 0xc3ade580, 2, 0) g_post_event_x(0xc04cb510, 0xc384cd80, 2, 0) ref 0xc384cd80 ref 0xc3ae2680 g_label_taste(LABEL, acd0) g_detach(0xc3ae45c0) g_destroy_consumer(0xc3ae45c0) g_destroy_geom(0xc3aef580(label:taste)) dev_taste(DEV,acd0) g_part_taste(PART,acd0) g_post_event_x(0xc04c78b0, 0xc3af9400, 2, 0) ref 0xc3af9400 g_wither_geom(0xc3ae2c00(acd0)) g_post_event_x(0xc04cb510, 0xc3aef480, 2, 0) ref 0xc3aef480 ref 0xc3ae2180 GEOM: new disk cd0 g_label_taste(LABEL, cd0) g_detach(0xc3ae0100) g_destroy_consumer(0xc3ae0100) g_destroy_geom(0xc3aef100(label:taste)) dev_taste(DEV,cd0) scsi_cd.c::ioctl cmd=4400648b error=25 g_part_taste(PART,cd0) (cd0:ata1:0:0:0): error 6 (cd0:ata1:0:0:0): Unretryable Error g_wither_geom(0xc3adea80(cd0)) g_detach(0xc3ae4e80) g_destroy_consumer(0xc3ae4e80) g_destroy_geom(0xc3adea80(cd0)) g_detach(0xc39b5280) g_destroy_consumer(0xc39b5280) g_destroy_geom(0xc3ae2c00(acd0)) Root mount waiting for: usbus3 uhub3: 6 ports with 6 removable, self powered Root mount waiting for: usbus3 ugen3.2: at usbus3 Trying to mount root from ufs:/dev/ad0s2a ct_to_ts([2009-04-04 18:48:32]) = 1238870912.000000000 start_init: trying /sbin/init g_disk_kernedump(ad0, 9971073024, 2147483648) Entropy harvesting: interrupts ethernet point_to_point g_post_event_x(0xc04c7590, 0xc3ae5b00, 2, 262144) g_post_event_x(0xc04c7590, 0xc3ae5b20, 2, 262144) g_post_event_x(0xc04c8a00, 0xc3ae5b40, 2, 262144) g_post_event_x(0xc04c8a00, 0xc3ae5b80, 2, 262144) g_post_event_x(0xc04c8880, 0xc3ae5bc0, 2, 262144) g_post_event_x(0xc04c8880, 0xc3ae5be0, 2, 262144) g_post_event_x(0xc04c8840, 0xc3ae5c60, 2, 262144) g_post_event_x(0xc04c8840, 0xc3ae5c40, 2, 262144) kickstart . g_post_event_x(0xc0665230, 0xdf0d7c64, 2, 262144) g_post_event_x(0xc04cb710, 0xc384cb00, 2, 0) ref 0xc384cb00 g_post_event_x(0xc04cb710, 0xc39a8d80, 2, 0) ref 0xc39a8d80 g_post_event_x(0xc04cb710, 0xc3ae2300, 2, 0) ref 0xc3ae2300 g_post_event_x(0xc04cb710, 0xc3ae2400, 2, 0) ref 0xc3ae2400 GEOM_LABEL: Label ufsid/46387cd616292ca8 removed. g_slice_spoiled(0xc3ae0540/ad0s2a) g_wither_geom(0xc3ade780(ad0s2a)) g_orphan_provider(0xc3ade700(ufsid/46387cd616292ca8), 6) g_orphan_register(ufsid/46387cd616292ca8) g_dev_orphan(0xc3af6100(ufsid/46387cd616292ca8)) g_detach(0xc3af6100) g_destroy_consumer(0xc3af6100) g_destroy_geom(0xc3ae2b00(ufsid/46387cd616292ca8)) g_detach(0xc3ae0540) g_destroy_consumer(0xc3ae0540) g_destroy_geom(0xc3ade780(ad0s2a)) /dev/ad0s2a: FILE SYSTEM CLEAN; SKIPPING CHECKS /dev/ad0s2a: clean, 45406 free (1094 frags, 5539 blocks, 0.6% fragmentation) g_post_event_x(0xc04cb510, 0xc3ae2400, 2, 0) ref 0xc3ae2400 g_label_taste(LABEL, ad0s2a) g_slice_config(ad0s2a, 0, 1) g_post_event_x(0xc04cb510, 0xc3b39900, 2, 0) ref 0xc3b39900 ref 0xc3b31800 GEOM_LABEL: Label for provider ad0s2a is ufsid/46387cd616292ca8. g_detach(0xc3af6480) g_destroy_consumer(0xc3af6480) g_destroy_geom(0xc3b31780(label:taste)) g_part_taste(PART,ad0s2a) g_wither_geom(0xc3b39880(ad0s2a)) g_label_taste(LABEL, ufsid/46387cd616292ca8) dev_taste(DEV,ufsid/46387cd616292ca8) g_part_taste(PART,ufsid/46387cd616292ca8) g_wither_geom(0xc3ade700(ufsid/46387cd616292ca8)) g_detach(0xc3af6580) g_destroy_consumer(0xc3af6580) g_destroy_geom(0xc3ade700(ufsid/46387cd616292ca8)) g_detach(0xc3af6500) g_destroy_consumer(0xc3af6500) g_destroy_geom(0xc3b39880(ad0s2a)) Can't stat /dev/ad0s7a: No such file or directory g_post_event_x(0xc04cb710, 0xc3ae2200, 2, 0) ref 0xc3ae2200 GEOM_LABEL: Label ufsid/46387cd73d66d2ca removed. g_slice_spoiled(0xc3ae0300/ad0s2d) g_wither_geom(0xc3ae2280(ad0s2d)) g_orphan_provider(0xc3ae2600(ufsid/46387cd73d66d2ca), 6) g_orphan_register(ufsid/46387cd73d66d2ca) g_dev_orphan(0xc3af6080(ufsid/46387cd73d66d2ca)) g_detach(0xc3af6080) g_destroy_consumer(0xc3af6080) g_destroy_geom(0xc3ae2980(ufsid/46387cd73d66d2ca)) g_detach(0xc3ae0300) g_destroy_consumer(0xc3ae0300) g_destroy_geom(0xc3ae2280(ad0s2d)) /dev/ad0s2d: FILE SYSTEM CLEAN; SKIPPING CHECKS /dev/ad0s2d: clean, 65349 free (5189 frags, 7520 blocks, 5.5% fragmentation) g_post_event_x(0xc04cb510, 0xc3ae2200, 2, 0) ref 0xc3ae2200 g_label_taste(LABEL, ad0s2d) g_slice_config(ad0s2d, 0, 1) g_post_event_x(0xc04cb510, 0xc3b39880, 2, 0) ref 0xc3b39880 ref 0xc3ae2980 GEOM_LABEL: Label for provider ad0s2d is ufsid/46387cd73d66d2ca. g_detach(0xc3af67c0) g_destroy_consumer(0xc3af67c0) g_destroy_geom(0xc3ae2600(label:taste)) g_part_taste(PART,ad0s2d) g_wither_geom(0xc3ae2600(ad0s2d)) g_label_taste(LABEL, ufsid/46387cd73d66d2ca) dev_taste(DEV,ufsid/46387cd73d66d2ca) g_part_taste(PART,ufsid/46387cd73d66d2ca) g_wither_geom(0xc3b74000(ufsid/46387cd73d66d2ca)) g_detach(0xc3af6900) g_destroy_consumer(0xc3af6900) g_destroy_geom(0xc3b74000(ufsid/46387cd73d66d2ca)) g_detach(0xc3af6840) g_destroy_consumer(0xc3af6840) g_destroy_geom(0xc3ae2600(ad0s2d)) g_post_event_x(0xc04cb710, 0xc3ae2100, 2, 0) ref 0xc3ae2100 GEOM_LABEL: Label ufsid/46387cd6c10fa381 removed. g_slice_spoiled(0xc3ae01c0/ad0s2e) g_wither_geom(0xc3aef900(ad0s2e)) g_orphan_provider(0xc3aef880(ufsid/46387cd6c10fa381), 6) g_orphan_register(ufsid/46387cd6c10fa381) g_dev_orphan(0xc3af6000(ufsid/46387cd6c10fa381)) g_detach(0xc3af6000) g_destroy_consumer(0xc3af6000) g_destroy_geom(0xc3ae2380(ufsid/46387cd6c10fa381)) g_detach(0xc3ae01c0) g_destroy_consumer(0xc3ae01c0) g_destroy_geom(0xc3aef900(ad0s2e)) /dev/ad0s2e: FILE SYSTEM CLEAN; SKIPPING CHECKS /dev/ad0s2e: clean, 689500 free (141532 frags, 68496 blocks, 5.1% fragmentation) g_post_event_x(0xc04cb510, 0xc3ae2100, 2, 0) ref 0xc3ae2100 g_label_taste(LABEL, ad0s2e) g_slice_config(ad0s2e, 0, 1) g_post_event_x(0xc04cb510, 0xc3b73a80, 2, 0) ref 0xc3b73a80 ref 0xc3b73b00 GEOM_LABEL: Label for provider ad0s2e is ufsid/46387cd6c10fa381. g_detach(0xc3af6a40) g_destroy_consumer(0xc3af6a40) g_destroy_geom(0xc3b73b80(label:taste)) g_part_taste(PART,ad0s2e) g_wither_geom(0xc3b73980(ad0s2e)) g_label_taste(LABEL, ufsid/46387cd6c10fa381) dev_taste(DEV,ufsid/46387cd6c10fa381) g_part_taste(PART,ufsid/46387cd6c10fa381) g_wither_geom(0xc3b73800(ufsid/46387cd6c10fa381)) g_detach(0xc3af6b40) g_destroy_consumer(0xc3af6b40) g_destroy_geom(0xc3b73800(ufsid/46387cd6c10fa381)) g_detach(0xc3af6ac0) g_destroy_consumer(0xc3af6ac0) g_destroy_geom(0xc3b73980(ad0s2e)) Can't stat /dev/ad0s7a: No such file or directory THE FOLLOWING FILE SYSTEM HAD AN UNEXPECTED INCONSISTENCY: ufs: /dev/ad0s7a (/home) Unknown error; help! ERROR: ABORTING BOOT (sending SIGTERM to parent)! Apr 5 02:48:33 init: /bin/sh on /etc/rc terminated abnormally, going to single user mode Enter root password, or ^D to go multi-user Password: From owner-freebsd-current@FreeBSD.ORG Sat Apr 4 16:09: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 E9226106564A for ; Sat, 4 Apr 2009 16:09:58 +0000 (UTC) (envelope-from xcllnt@mac.com) Received: from asmtpout017.mac.com (asmtpout017.mac.com [17.148.16.92]) by mx1.freebsd.org (Postfix) with ESMTP id C643E8FC12 for ; Sat, 4 Apr 2009 16:09:58 +0000 (UTC) (envelope-from xcllnt@mac.com) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Received: from MacBook-Pro.lan.xcllnt.net (mail.xcllnt.net [75.101.29.67]) by asmtp017.mac.com (Sun Java(tm) System Messaging Server 6.3-8.01 (built Dec 16 2008; 32bit)) with ESMTPSA id <0KHL00DXD3KKWP40@asmtp017.mac.com> for freebsd-current@freebsd.org; Sat, 04 Apr 2009 09:09:56 -0700 (PDT) Message-id: <42E3BB6C-16C7-4211-A4FD-A362383418E9@mac.com> From: Marcel Moolenaar To: Tai-hwa Liang In-reply-to: <09040423143118.91304@www.mmlab.cse.yzu.edu.tw> Date: Sat, 04 Apr 2009 09:09:55 -0700 References: <20090331155542.74d89d64@ernst.jennejohn.org> <60084D1E-9F64-463A-A8E9-7A237D5C7661@mac.com> <0904011910169.29800@www.mmlab.cse.yzu.edu.tw> <0904020940371.36257@www.mmlab.cse.yzu.edu.tw> <4CCDEFD6-830E-4C8F-B7A2-B7878F8842BE@mac.com> <0904021314574.37737@www.mmlab.cse.yzu.edu.tw> <09040309313414.76643@www.mmlab.cse.yzu.edu.tw> <0904031327195.78401@www.mmlab.cse.yzu.edu.tw> <8583A3BA-2871-4DF4-9792-1031044A4A22@mac.com> <09040315161311.79260@www.mmlab.cse.yzu.edu.tw> <1DDB4728-7742-4265-999F-F1A0FC69F9E4@mac.com> <0904040858433.86299@www.mmlab.cse.yzu.edu.tw> <7AD352A2-BEDD-4DFD-896D-104E6376D887@mac.com> <09040411131618.87313@www.mmlab.cse.yzu.edu.tw> <09040423143118.91304@www.mmlab.cse.yzu.edu.tw> X-Mailer: Apple Mail (2.930.3) Cc: freebsd-current@freebsd.org Subject: Re: Removal of GEOM_BSD, GEOM_MBR, GEOM_PC98 and GEOM_SUNLABEL 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, 04 Apr 2009 16:09:59 -0000 On Apr 4, 2009, at 8:16 AM, Tai-hwa Liang wrote: > I have to use ad0s7 after moving to GEOM_PART_{BSD,EBR,MBR}; > otherwise, > booting with with /dev/ad0s7a looks like: > Can't stat /dev/ad0s7a: No such file or directory It just hit me (doh!). The problem is that /dev/ad0s7 is a compatibility symlink, which exists outside of the GEOM graph. That is, it's a symlink that geom_dev creates and it provides an alternate name to the same "entry point". In your case another GEOM (gpart for the BSD scheme) is stacked onto the gpart GEOM for the EBR scheme) -- with possibly other GEOMs in between. The provider for the 'a' partition is named based on the underlying consumer, which is based on the true name of the GEOM: "ad0s3+00103bf1a". There's no alias for the device node that corresponds to this GEOM and based on some alias that was created by some other geom_dev. This is simply not possible to without messing things up pretty easily. In short: the solution of using a compatibility symlink is flawed at best and useless in the worst case. There's no software fix for it. I think we're left with a simple choice: 1) have EBR create the "old" names and tell the user to reboot every time they make a change in FreeBSD and when booting into FreeBSD after the EBR changed, boot into single user mode to change /etc/fstab and *then* go into multi-user mode, or 2) stick with the new names and tell the user to make this one-time adjustment during upgrades and that's it. If we choose 2, we can argue whether to keep the symlinks or not. I'm sure there's a small group of people for which it works, but I fear the majority of people still have problems. Any thoughts? -- Marcel Moolenaar xcllnt@mac.com