From owner-freebsd-sparc64@FreeBSD.ORG Sun Dec 16 21:32:47 2012 Return-Path: Delivered-To: freebsd-sparc64@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 7CED0DAD for ; Sun, 16 Dec 2012 21:32:47 +0000 (UTC) (envelope-from marius@alchemy.franken.de) Received: from alchemy.franken.de (alchemy.franken.de [194.94.249.214]) by mx1.freebsd.org (Postfix) with ESMTP id 1E7FF8FC0A for ; Sun, 16 Dec 2012 21:32:46 +0000 (UTC) Received: from alchemy.franken.de (localhost [127.0.0.1]) by alchemy.franken.de (8.14.5/8.14.5/ALCHEMY.FRANKEN.DE) with ESMTP id qBGLWksK049971; Sun, 16 Dec 2012 22:32:46 +0100 (CET) (envelope-from marius@alchemy.franken.de) Received: (from marius@localhost) by alchemy.franken.de (8.14.5/8.14.5/Submit) id qBGLWj7O049970; Sun, 16 Dec 2012 22:32:45 +0100 (CET) (envelope-from marius) Date: Sun, 16 Dec 2012 22:32:45 +0100 From: Marius Strobl To: KOT MATPOCKuH Subject: Re: zfs booting feedback Message-ID: <20121216213245.GB49699@alchemy.franken.de> References: <20120708025435.GA12487@pix.net> <20120709140019.GA67276@alchemy.franken.de> <20120710165433.GA98707@pix.net> <20120712172208.GA47484@pix.net> <20120713195807.GU63893@alchemy.franken.de> <20120714004335.GD92944@pix.net> <20120727182558.GH58433@alchemy.franken.de> <20120730113015.GA14735@alchemy.franken.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-sparc64@freebsd.org X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Dec 2012 21:32:47 -0000 On Thu, Dec 13, 2012 at 01:05:16PM +0300, KOT MATPOCKuH wrote: > Good morning! > > I builded world/kernel from stable/9 r244121, installed zfsboot and > zfsloader to disk on Sun Fire V240 with OpenBoot 4.30.4.a. > But boot fails with: > Rebooting with command: boot disk > Boot device: /pci@1c,600000/scsi@2/disk@0,0 File and args: > > >> FreeBSD/sparc64 ZFS boot block > Boot path: /pci@1c,600000/scsi@2/disk@0,0:a > Consoles: Open Firmware console > ERROR: Last Trap: Division by Zero Please use debug versions of the loaders and report the output of `ctrace` on the boot monitor prompt. Building debug versions is most easily done via `make DEBUG_FLAGS=-g` in path/to/src/boot when building natively. You can also add the same when cross- compiling but then you'll end up with debug versions of everything. In both cases, make sure to not have any old object files in place. > > Also I tried zfsloader builded from sources @ may 2012: > (same zfsboot, but used zfsloader.old) > Boot device: disk File and args: > > >> FreeBSD/sparc64 ZFS boot block > Boot path: /pci@1c,600000/scsi@2/disk@0,0:a > Consoles: Open Firmware console > ofwd_open: Could not open disk1: > ofwd_open: Could not open disk2: > ofwd_open: Could not open disk3: > > FreeBSD/sparc64 ZFS enabled bootstrap loader, Revision 1.0 > (root@sunspot, Fri Nov 2 08:59:22 MSK 2012) > bootpath="/pci@1c,600000/scsi@2/disk@0,0:a" > ZFS: i/o error - all block copies unavailable > ZFS: i/o error - all block copies unavailable > ZFS: i/o error - all block copies unavailable > ZFS: i/o error - all block copies unavailable > ZFS: i/o error - all block copies unavailable > ZFS: i/o error - all block copies unavailable > > ZFS: i/o error - all block copies unavailable > ZFS: i/o error - all block copies unavailable > ZFS: i/o error - all block copies unavailable > ZFS: i/o error - all block copies unavailable > ZFS: i/o error - all block copies unavailable > ZFS: i/o error - all block copies unavailable > ZFS: i/o error - all block copies unavailable > ZFS: i/o error - all block copies unavailable > ZFS: i/o error - all block copies unavailable > ZFS: i/o error - all block copies unavailable > ZFS: i/o error - all block copies unavailable > ZFS: i/o error - all block copies unavailable > can't load 'kernel' > > What's wrong? No idea; looks like either an older ZFS loader can't deal with current ZFS or something is fundamentally wrong with your ZFS setup. I don't know enough about ZFS for telling what's the problem here. You're probably off asking ZFS people about this. > Could it a result of crosscompiling? Unlikely; the last time I encountered a bug causing cross- and native- builds to differ was in GCC 3 times. > > PS. When writing both zfsloader I got "Invalid argument" message: > # dd if=/boot/zfsloader.old of=/dev/da0a bs=512 oseek=1024 > dd: /dev/da0a: Invalid argument > 470+1 records in > 470+0 records out > 240640 bytes transferred in 1.915555 secs (125624 bytes/sec) > Is it okey? > Apparently, this is a cosmetic bug (at least I haven't hit any problems arising from it so far) introduced some time ago. But yes, I also see this and also in other occasions and on other architectures as well. Marius From owner-freebsd-sparc64@FreeBSD.ORG Sun Dec 16 21:16:26 2012 Return-Path: Delivered-To: sparc64@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id D0B98C95; Sun, 16 Dec 2012 21:16:26 +0000 (UTC) (envelope-from marius@alchemy.franken.de) Received: from alchemy.franken.de (alchemy.franken.de [194.94.249.214]) by mx1.freebsd.org (Postfix) with ESMTP id 464568FC19; Sun, 16 Dec 2012 21:16:26 +0000 (UTC) Received: from alchemy.franken.de (localhost [127.0.0.1]) by alchemy.franken.de (8.14.5/8.14.5/ALCHEMY.FRANKEN.DE) with ESMTP id qBGLGNN0049914; Sun, 16 Dec 2012 22:16:24 +0100 (CET) (envelope-from marius@alchemy.franken.de) Received: (from marius@localhost) by alchemy.franken.de (8.14.5/8.14.5/Submit) id qBGLGNXu049913; Sun, 16 Dec 2012 22:16:23 +0100 (CET) (envelope-from marius) Date: Sun, 16 Dec 2012 22:16:23 +0100 From: Marius Strobl To: Jeff Roberson Subject: Re: Call for testing and review, busdma changes Message-ID: <20121216211623.GA49699@alchemy.franken.de> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-Mailman-Approved-At: Sun, 16 Dec 2012 23:04:54 +0000 Cc: powerpc@freebsd.org, marcel@freebsd.org, mips@freebsd.org, mav@freebsd.org, scottl@freebsd.org, attilio@freebsd.org, kib@freebsd.org, sparc64@freebsd.org, arm@freebsd.org X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Dec 2012 21:16:26 -0000 On Sat, Dec 08, 2012 at 08:51:12AM -1000, Jeff Roberson wrote: > Hello, > > http://people.freebsd.org/~jeff/physbio.diff > > I have a relative large patch that reforms the busdma API so that new > types may be added without modifying every architecture's > busdma_machdep.c. It does this by unifying the bus_dmamap_load_buffer() > routines so that they may be called from MI code. The MD busdma is then > given a chance to do any final processing in the complete() callback. > This patch also contains cam changes to unify the bus_dmamap_load* > handling in cam drivers. > > The arm and mips implementations saw the largest changes since they have > to track virtual addresses for sync(). Previously this was done in a type > specific way. Now it is done in a generic way by recording the list of > virtuals in the map. > > I have verified that this patch passes make universe which includes > several kernel builds from each architecture. I suspect that if I broke > anything your machine simply won't boot or will throw I/O errors. There > is little subtlety, it is mostly refactoring. > > The next step is to allow for dma loading of physical addresses. This > will permit unmapped I/O. Which is a significant performance optimization > targeted for 10.0. > > Many thanks for your assistance. Any review feedback is also appreciated. > Survives a buildworld on sparc64; tested with mpt(4) and sym(4). Marius From owner-freebsd-sparc64@FreeBSD.ORG Mon Dec 17 11:06:51 2012 Return-Path: Delivered-To: freebsd-sparc64@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 32E5E9F4 for ; Mon, 17 Dec 2012 11:06:51 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by mx1.freebsd.org (Postfix) with ESMTP id 1721F8FC12 for ; Mon, 17 Dec 2012 11:06:51 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.5/8.14.5) with ESMTP id qBHB6oQX023596 for ; Mon, 17 Dec 2012 11:06:50 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id qBHB6op0023594 for freebsd-sparc64@FreeBSD.org; Mon, 17 Dec 2012 11:06:50 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 17 Dec 2012 11:06:50 GMT Message-Id: <201212171106.qBHB6op0023594@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: gnats set sender to owner-bugmaster@FreeBSD.org using -f From: FreeBSD bugmaster To: freebsd-sparc64@FreeBSD.org Subject: Current problem reports assigned to freebsd-sparc64@FreeBSD.org X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Dec 2012 11:06:51 -0000 Note: to view an individual PR, use: http://www.freebsd.org/cgi/query-pr.cgi?pr=(number). The following is a listing of current problems submitted by FreeBSD users. These represent problem reports covering all versions including experimental development code and obsolete releases. S Tracker Resp. Description -------------------------------------------------------------------------------- o sparc/170663 sparc64 panics with VIA 6421 SATA150 controller on Blade 1500 o sparc/169669 sparc64 Something seems broken in sparc64 TLS or lang/lua o sparc/164227 sparc64 [boot] Can't boot 9.0-RELEASE/sparc64 on Blade 1500 s sparc/164226 sparc64 [cd] Data corruption on 9.0-RELEASE when reading from o sparc/162513 sparc64 mpt(4), mptutil(8) reports variable, erroneous drive i o sparc/141918 sparc64 [ehci] ehci_interrupt: unrecoverable error, controller s sparc/139134 sparc64 kernel output corruption s sparc/107087 sparc64 [hang] system is hung during boot from CD o sparc/105048 sparc64 [trm] trm(4) panics on sparc64 o sparc/104428 sparc64 [nullfs] nullfs panics on E4500 (but not E420) o sparc/71729 sparc64 printf in kernel thread causes panic on SPARC 11 problems total. From owner-freebsd-sparc64@FreeBSD.ORG Wed Dec 19 23:03:36 2012 Return-Path: Delivered-To: sparc64@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 1F1A244E; Wed, 19 Dec 2012 23:03:36 +0000 (UTC) (envelope-from freebsd@damnhippie.dyndns.org) Received: from duck.symmetricom.us (duck.symmetricom.us [206.168.13.214]) by mx1.freebsd.org (Postfix) with ESMTP id 97ABF8FC16; Wed, 19 Dec 2012 23:03:29 +0000 (UTC) Received: from damnhippie.dyndns.org (daffy.symmetricom.us [206.168.13.218]) by duck.symmetricom.us (8.14.5/8.14.5) with ESMTP id qBJN3Smn050166; Wed, 19 Dec 2012 16:03:28 -0700 (MST) (envelope-from freebsd@damnhippie.dyndns.org) Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by damnhippie.dyndns.org (8.14.3/8.14.3) with ESMTP id qBJN3NsO065767; Wed, 19 Dec 2012 16:03:23 -0700 (MST) (envelope-from freebsd@damnhippie.dyndns.org) Subject: Re: Call for testing and review, busdma changes From: Ian Lepore To: Jeff Roberson In-Reply-To: References: Content-Type: text/plain; charset="us-ascii" Date: Wed, 19 Dec 2012 16:03:23 -0700 Message-ID: <1355958203.1198.235.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Thu, 20 Dec 2012 00:09:17 +0000 Cc: powerpc@freebsd.org, marcel@freebsd.org, mips@freebsd.org, mav@freebsd.org, scottl@freebsd.org, attilio@freebsd.org, kib@freebsd.org, sparc64@freebsd.org, arm@freebsd.org X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Dec 2012 23:03:36 -0000 On Sat, 2012-12-08 at 08:51 -1000, Jeff Roberson wrote: > Hello, > > http://people.freebsd.org/~jeff/physbio.diff > > I have a relative large patch that reforms the busdma API so that new > types may be added without modifying every architecture's > busdma_machdep.c. It does this by unifying the bus_dmamap_load_buffer() > routines so that they may be called from MI code. The MD busdma is then > given a chance to do any final processing in the complete() callback. > This patch also contains cam changes to unify the bus_dmamap_load* > handling in cam drivers. > > The arm and mips implementations saw the largest changes since they have > to track virtual addresses for sync(). Previously this was done in a type > specific way. Now it is done in a generic way by recording the list of > virtuals in the map. > > I have verified that this patch passes make universe which includes > several kernel builds from each architecture. I suspect that if I broke > anything your machine simply won't boot or will throw I/O errors. There > is little subtlety, it is mostly refactoring. > > The next step is to allow for dma loading of physical addresses. This > will permit unmapped I/O. Which is a significant performance optimization > targeted for 10.0. > > Many thanks for your assistance. Any review feedback is also appreciated. > > Jeff More test results... Today I updated to r244435 and then applied your patches (and my little fix, but not my big set of busdma changes) over that, and built everything fresh for my DreamPlug. I plugged an SSD drive into the eSata port for some testing and right away noticed extreme slowness; 'camcontrol identify' shows the drive running in PIO mode with the patches, but it's fine without them (output below). I'm no ata or cam wizard, but I can easily toggle back and forth between kernels with/without the patches; let me know if I can do anything to generate useful info to track this down. -- Ian -------------------------------- With unpatched -current @ r244435 ada0 at mvsch0 bus 0 scbus0 target 0 lun 0 ada0: ATA-9 SATA 2.x device ada0: 300.000MB/s transfers (SATA 2.x, UDMA5, PIO 8192bytes) ada0: 122104MB (250069680 512 byte sectors: 16H 63S/T 16383C) root@dpcur:/root # camcontrol identify ada0 pass0: ATA-9 SATA 2.x device pass0: 300.000MB/s transfers (SATA 2.x, UDMA5, PIO 8192bytes) protocol ATA/ATAPI-9 SATA 2.x device model M4-CT128M4SSD2 firmware revision 000F serial number 0000000012290910F745 WWN 500a07510910f745 cylinders 16383 heads 16 sectors/track 63 sector size logical 512, physical 512, offset 0 LBA supported 250069680 sectors LBA48 supported 250069680 sectors PIO supported PIO4 DMA supported WDMA2 UDMA5 media RPM non-rotating Feature Support Enabled Value Vendor read ahead yes yes write cache yes yes flush cache yes yes overlap no Tagged Command Queuing (TCQ) no no Native Command Queuing (NCQ) no SMART yes yes microcode download yes yes security yes no power management yes yes advanced power management yes yes 254/0xFE automatic acoustic management no no media status notification no no power-up in Standby no no write-read-verify yes no 0/0x0 unload yes yes free-fall no no data set management (TRIM) yes -------------------------------- With physbio patches applied to r244435... ada0 at mvsch0 bus 0 scbus0 target 0 lun 0 ada0: ATA-9 SATA 2.x device ada0: 300.000MB/s transfers (SATA 2.x, UDMA5, PIO 8192bytes) ada0: 122104MB (250069680 512 byte sectors: 16H 63S/T 16383C) root@dpcur:/root # camcontrol identify ada0 pass0: < > ATA-0 device pass0: 300.000MB/s transfers (SATA 2.x, UDMA5, PIO 8192bytes) protocol ATA/ATAPI-0 device model firmware revision serial number cylinders 0 heads 0 sectors/track 0 sector size logical 512, physical 512, offset 0 LBA not supported LBA48 not supported PIO supported PIO0 w/o IORDY DMA not supported Feature Support Enabled Value Vendor read ahead no no write cache no no flush cache no no overlap no Tagged Command Queuing (TCQ) no no Native Command Queuing (NCQ) no SMART no no microcode download no no security no no power management no no advanced power management no no automatic acoustic management no no media status notification no no power-up in Standby no no write-read-verify no no unload no no free-fall no no data set management (TRIM) no -- Ian From owner-freebsd-sparc64@FreeBSD.ORG Sat Dec 22 14:22:45 2012 Return-Path: Delivered-To: sparc64@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 90748EB9; Sat, 22 Dec 2012 14:22:45 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) by mx1.freebsd.org (Postfix) with ESMTP id 287A28FC0A; Sat, 22 Dec 2012 14:22:44 +0000 (UTC) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.5/8.14.5) with ESMTP id qBMEMUNE073377; Sat, 22 Dec 2012 16:22:30 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.7.3 kib.kiev.ua qBMEMUNE073377 Received: (from kostik@localhost) by tom.home (8.14.5/8.14.5/Submit) id qBMEMUZ7073376; Sat, 22 Dec 2012 16:22:30 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Sat, 22 Dec 2012 16:22:30 +0200 From: Konstantin Belousov To: Jeff Roberson Subject: Re: Call for testing and review, busdma changes Message-ID: <20121222142230.GU53644@kib.kiev.ua> References: MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="pzbqGaOtRNiVr7w4" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on tom.home X-Mailman-Approved-At: Sat, 22 Dec 2012 14:46:32 +0000 Cc: powerpc@freebsd.org, marcel@freebsd.org, mips@freebsd.org, mav@freebsd.org, scottl@freebsd.org, attilio@freebsd.org, sparc64@freebsd.org, arm@freebsd.org X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Dec 2012 14:22:45 -0000 --pzbqGaOtRNiVr7w4 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Dec 08, 2012 at 08:51:12AM -1000, Jeff Roberson wrote: > Hello, >=20 > http://people.freebsd.org/~jeff/physbio.diff >=20 > I have a relative large patch that reforms the busdma API so that new=20 > types may be added without modifying every architecture's=20 > busdma_machdep.c. It does this by unifying the bus_dmamap_load_buffer()= =20 > routines so that they may be called from MI code. The MD busdma is then= =20 > given a chance to do any final processing in the complete() callback.=20 > This patch also contains cam changes to unify the bus_dmamap_load*=20 > handling in cam drivers. >=20 > The arm and mips implementations saw the largest changes since they have= =20 > to track virtual addresses for sync(). Previously this was done in a typ= e=20 > specific way. Now it is done in a generic way by recording the list of= =20 > virtuals in the map. >=20 > I have verified that this patch passes make universe which includes=20 > several kernel builds from each architecture. I suspect that if I broke= =20 > anything your machine simply won't boot or will throw I/O errors. There= =20 > is little subtlety, it is mostly refactoring. >=20 > The next step is to allow for dma loading of physical addresses. This=20 > will permit unmapped I/O. Which is a significant performance optimizatio= n=20 > targeted for 10.0. >=20 > Many thanks for your assistance. Any review feedback is also appreciated. I re-read the patch with the scars from the unmapped buffers work somewhat healed up, and I noted something I do not quite understand. As an example, please look at the sys/cam/ata/ata_da.c:adastart(). The code there takes bp and converts in into ccb with ataio union member used. Should this code path be converted, together with e.g. ahci_begin_transaction(), to operate on ccb instead of loading from the buffer ? The same question for ata. Was the change missed, or do you have some other plans for the drivers ? --pzbqGaOtRNiVr7w4 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iQIcBAEBAgAGBQJQ1cIlAAoJEJDCuSvBvK1BFQAP/iuogDJUm1Ic80g20ZLhSz3M 9Pmb6NXMB0pFCRXy+gWMnMy/Rccf1fJlVtC8cxRxQZLJxOyur/RdrN4PTzdr4HtA gEBk2wnKtyXLTLHgKZcGhMoI62lwxgTJMXz8yK4S3DpmmA2URsLRrqgmWRw1MMdK +fKrhthaedPDFgvcJU0BwJjNoyiMod7LabqmuJr32PC2wtvAQH/sXBILk9qp1lXl xNgAhduvUF7n6d61qRELx1DVQkU3xWjVf8NiA3VqTDbCRrSrFBGdwJZKMSIyqDy/ Q2gUYegpd7QkEKzHt4u8O3sn2Um1XpC86/YfBMNMI28wDZjtijsOgx+RiykJHEiM tvTcQCS7dXo696nXEEKkw9607GU0KAKamtyIGSMz3qUE9PKTFcfR3BVoj7ikrJDq LFiODjF+wCpJ9MtIWJPjWfpVOicl7mkedu6U2HZ7ABIUltusqHZTYW2yEtJSle/e QjDPcfgGdPKtjaKSfd4bCfNqe0mLHtAThJmV/dX1Nx+43aGBmCJ8qWjDkmBJG5Uw su+KSsQ/q+T0QEvUSwDrVUaTJ7PSRctc6MnLMJcUt5VRwHJ8NArIxe6YapMNOlS6 D0MIMcsIt1B0qgvXyGYiTiF564lM0bgqAzRWcragvxYOd6cixWqNBV7qmjkdySch Ysf8ToRRocS2b92/i/8N =GTYI -----END PGP SIGNATURE----- --pzbqGaOtRNiVr7w4--