From owner-freebsd-stable@FreeBSD.ORG Sun Jul 16 02:30:16 2006 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3B38916A4DF for ; Sun, 16 Jul 2006 02:30:16 +0000 (UTC) (envelope-from javier@skyhawk.kjsl.com) Received: from skyhawk.kjsl.com (skyhawk.kjsl.com [69.36.241.138]) by mx1.FreeBSD.org (Postfix) with ESMTP id DA24D43D46 for ; Sun, 16 Jul 2006 02:30:15 +0000 (GMT) (envelope-from javier@skyhawk.kjsl.com) Received: by skyhawk.kjsl.com (Postfix, from userid 1001) id 38A87B818A; Sat, 15 Jul 2006 22:30:15 -0400 (EDT) Date: Sat, 15 Jul 2006 22:30:15 -0400 From: Javier Henderson To: Matthew Seaman Message-ID: <20060716023014.GE86544@skyhawk.kjsl.com> References: <20060714165735.L15214@bunning.skiltech.com> <44B8094C.3040007@rogers.com> <20060715011112.GB32358@skyhawk.kjsl.com> <44B88B51.10607@infracaninophile.co.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <44B88B51.10607@infracaninophile.co.uk> User-Agent: Mutt/1.4.2.1i Cc: Mike Jakubik , freebsd-stable@freebsd.org Subject: Re: Intel ICH7R RAID controller working on 6.1/STABLE? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Jul 2006 02:30:16 -0000 * Matthew Seaman [060715 02:30]: > Javier Henderson wrote: > > * Mike Jakubik [060714 17:15]: > > >> The chipset is supported, but i wouldn't recommend onboard raid for any > >> production server. Get a real raid controller, or use gmirror if you > >> plan to mirror. I use several of these board sin production with gmirror. > > > Why do you recommend against on-board RAID controllers? > > Think about what happens if one of your disks dies. Sure, the machine will > carry on running. With an on-board controller there are two problems: > > i) How do you get notified that a disk has died > ii) How do you replace the drive > > (i) you'ld likely only find out about at reboot time, or by noticing a > change in the pattern of blinken-lights on the machine. (Don't laugh -- > it happens) Good point. The Intel motherboard I have with on-board RAID controller doesn't have a notification features as I've seen on stand-alone controllers. > (ii) is not just about having to power off the machine and swap out the > hardware: it's not uncommon for on-board RAID-1 setups to be unable to > rebuild a mirror by duplicating the good disk onto the replacement one. That > means blowing everything away and recovering from backup. By which time > you've had so much downtime that you might as well not have bothered with > RAID in the first place. Well, in my case, I mentioned I have the Intel D945PVS motherboard. Before storing valuable data, I did take out a drive (out of four in a RAID 5 configuration) while reading and writing to/from the array, and it just kept on going. Then I put the disk back, and things got slow while parity was rebuilt, but in the end the array was back to healthy status. > The advantage of a good RAID controller -- like one of the 3ware cards > -- or of gmirror is that combined with hot-swap disk (and pretty much all > SATA drives nowadays have hot-swap capability; you just need to find a > chassis with the right sort of drive bays) then you can take out the dead > disk, replace it with a good one and rebuild the array *without taking the > machine down*. > > gmirror will alert you to failures in the nightly e-mail if you enable > the 406.status-gmirror periodic script. Similarly a good hardware RAID > controller will have a system level control application to let you interface > with the card from the OS level, and it will have some mechanism for alerting > the admin to problems. Yes, there are indeed good advantages to stand-alone controllers, and in some cases they justify the expense. Thanks for taking the time to post a reply. -jav From owner-freebsd-stable@FreeBSD.ORG Sun Jul 16 05:07:18 2006 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 37FE216A4DE for ; Sun, 16 Jul 2006 05:07:18 +0000 (UTC) (envelope-from zkolic@sbb.co.yu) Received: from smtp2.sbb.co.yu (smtp2.sbb.co.yu [82.117.194.22]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8C31B43D45 for ; Sun, 16 Jul 2006 05:07:16 +0000 (GMT) (envelope-from zkolic@sbb.co.yu) Received: from faust.net (dhcp-87-116-189-214.ataman-bg.customer.sbb.co.yu [87.116.189.214]) by smtp2.sbb.co.yu (8.13.6/8.13.6) with ESMTP id k6G57DOL003116 for ; Sun, 16 Jul 2006 07:07:13 +0200 Received: by faust.net (Postfix, from userid 1001) id 980331704B; Sun, 16 Jul 2006 07:07:47 +0200 (CEST) Date: Sun, 16 Jul 2006 07:07:47 +0200 From: Zoran Kolic To: freebsd-stable@freebsd.org Message-ID: <20060716050747.GA808@faust.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-SMTP-Vilter-Version: 1.3.2 X-SBB-Virus-Status: clean X-SBB-Spam-Score: 1.3 X-SBB-Spam-Level: XXX Subject: asus wl 530-g router X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Jul 2006 05:07:18 -0000 Hi all! I'd like to know if someone has experience with this router. The signal comes from cable modem, to wan port. It has 4 lan ethernets and wireless G. The chip is (probably) Marwell, os linux embeded. Internet provider offers dhcp dynamic address. I would use static IPs in lan. Has nat and some kind of firewall. Question? Should I take this? Does it pass through telnet, ssh, ping (from inside out)? How nice works wi-fi component? Best regards Zoran From owner-freebsd-stable@FreeBSD.ORG Sun Jul 16 08:32:59 2006 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 16CE916A4E1 for ; Sun, 16 Jul 2006 08:32:59 +0000 (UTC) (envelope-from markk@knigma.org) Received: from mail.ncipher.com (mail.ncipher.com [82.108.130.24]) by mx1.FreeBSD.org (Postfix) with ESMTP id EC22E43D46 for ; Sun, 16 Jul 2006 08:32:57 +0000 (GMT) (envelope-from markk@knigma.org) Received: from cromer.ncipher.com ([172.23.135.200]) by mail.ncipher.com with esmtp (TLSv1:DES-CBC3-SHA:168) (Exim 3.34 #1) id 1G223b-00039J-00 for freebsd-stable@freebsd.org; Sun, 16 Jul 2006 09:32:55 +0100 Received: from lap.knigma.org (mourn.ncipher.com [172.19.133.171]) by cromer.ncipher.com (8.13.6/8.13.6) with ESMTP id k6G8WpbL032318 for ; Sun, 16 Jul 2006 09:32:52 +0100 (BST) (envelope-from markk@knigma.org) Message-ID: Date: Sun, 16 Jul 2006 09:32:47 +0100 To: freebsd-stable@freebsd.org From: Mark Knight MIME-Version: 1.0 Content-Type: text/plain;charset=us-ascii User-Agent: Turnpike/6.05-U () Subject: 6.1 panic after approx. 49 days uptime X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Jul 2006 08:32:59 -0000 Just awoke to fine my home server (6.1-RELEASE) had panicked during its daily update of /usr/ports with an uptime of 49 days. Stack trace is here: Looks file system related to me. Any advice appreciated. Cheers, -- Mark A. R. Knight finger: markk@knigma.org Tel: +44 7880 556751 http://www.knigma.org/ From owner-freebsd-stable@FreeBSD.ORG Sun Jul 16 08:46:56 2006 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3DF1D16A4DD for ; Sun, 16 Jul 2006 08:46:56 +0000 (UTC) (envelope-from markk@knigma.org) Received: from mail.ncipher.com (mail.ncipher.com [82.108.130.24]) by mx1.FreeBSD.org (Postfix) with ESMTP id C693243D45 for ; Sun, 16 Jul 2006 08:46:55 +0000 (GMT) (envelope-from markk@knigma.org) Received: from cromer.ncipher.com ([172.23.135.200]) by mail.ncipher.com with esmtp (TLSv1:DES-CBC3-SHA:168) (Exim 3.34 #1) id 1G22H8-0003OR-00 for freebsd-stable@freebsd.org; Sun, 16 Jul 2006 09:46:54 +0100 Received: from lap.knigma.org (mourn.ncipher.com [172.19.133.171]) by cromer.ncipher.com (8.13.6/8.13.6) with ESMTP id k6G8krri032552 for ; Sun, 16 Jul 2006 09:46:54 +0100 (BST) (envelope-from markk@knigma.org) Message-ID: Date: Sun, 16 Jul 2006 09:46:49 +0100 To: freebsd-stable@freebsd.org From: Mark Knight References: <20060716084210.GL32624@deviant.kiev.zoral.com.ua> In-Reply-To: <20060716084210.GL32624@deviant.kiev.zoral.com.ua> MIME-Version: 1.0 Content-Type: text/plain;charset=us-ascii;format=flowed User-Agent: Turnpike/6.05-U () Subject: Re: 6.1 panic after approx. 49 days uptime X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Jul 2006 08:46:56 -0000 In message <20060716084210.GL32624@deviant.kiev.zoral.com.ua>, Kostik Belousov writes >On Sun, Jul 16, 2006 at 09:32:47AM +0100, Mark Knight wrote: >> Just awoke to fine my home server (6.1-RELEASE) had panicked during its >> daily update of /usr/ports with an uptime of 49 days. >> >> Stack trace is here: >> >> >> >> Looks file system related to me. Any advice appreciated. > >If you still have the core dump at hands, go to frame #7 and post the >output of the commands "p *vp" and "p *(vp->v_mount)". Appended to log file (in case of mail formatting) and reproduced here: (kgdb) p *(vp) $3 = {v_type = VBAD, v_tag = 0xc0791704 "none", v_op = 0xc07d89e0, v_data = 0x0, v_mount = 0x0, v_nmntvnodes = {tqe_next = 0x0, tqe_prev = 0xc3250014}, v_un = {vu_mount = 0x0, vu_socket = 0x0, vu_cdev = 0x0, vu_fifoinfo = 0x0}, v_hashlist = {le_next = 0x0, le_prev = 0xc295f570}, v_hash = 3269747, v_cache_src = {lh_first = 0x0}, v_cache_dst = {tqh_first = 0x0, tqh_last = 0xc335cbe0}, v_dd = 0x0, v_cstart = 0, v_lasta = 0, v_lastw = 0, v_clen = 0, v_lock = {lk_interlock = 0xc08073dc, lk_flags = 64, lk_sharecount = 0, lk_waitcount = 0, lk_exclusivecount = 0, lk_prio = 80, lk_wmesg = 0xc07a24ed "ufs", lk_timo = 51, lk_lockholder = 0xffffffff, lk_newlock = 0x0}, v_interlock = {mtx_object = {lo_class = 0xc07e0644, lo_name = 0xc07a3a55 "vnode interlock", lo_type = 0xc07a3a55 "vnode interlock", lo_flags = 196608, lo_list = {tqe_next = 0x0, tqe_prev = 0x0}, lo_witness = 0x0}, mtx_lock = 4, mtx_recurse = 0}, v_vnlock = 0xc335cc08, v_holdcnt = 1, v_usecount = 0, v_iflag = 128, v_vflag = 0, v_writecount = 0, v_freelist = { tqe_next = 0xc3248990, tqe_prev = 0xc080d22c}, v_bufobj = {bo_mtx = 0xc335cc2c, bo_clean = {bv_hd = { tqh_first = 0x0, tqh_last = 0xc335cc74}, bv_root = 0x0, bv_cnt = 0}, bo_dirty = {bv_hd = { tqh_first = 0x0, tqh_last = 0xc335cc84}, bv_root = 0x0, bv_cnt = 0}, bo_numoutput = 0, bo_flag = 0, bo_ops = 0xc07e6564, bo_bsize = 8192, bo_object = 0x0, bo_synclist = {le_next = 0x0, le_prev = 0x0}, bo_private = 0xc335cbb0, __bo_vnode = 0xc335cbb0}, v_pollinfo = 0x0, v_label = 0x0} (kgdb) p *(vp->v_mount) Cannot access memory at address 0x0 (kgdb) Thanks, -- Mark A. R. Knight finger: markk@knigma.org Tel: +44 7880 556751 http://www.knigma.org/ From owner-freebsd-stable@FreeBSD.ORG Sun Jul 16 08:58:09 2006 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DC83016A4E1 for ; Sun, 16 Jul 2006 08:58:09 +0000 (UTC) (envelope-from markk@knigma.org) Received: from mail.ncipher.com (mail.ncipher.com [82.108.130.24]) by mx1.FreeBSD.org (Postfix) with ESMTP id 77EBC43D45 for ; Sun, 16 Jul 2006 08:58:09 +0000 (GMT) (envelope-from markk@knigma.org) Received: from cromer.ncipher.com ([172.23.135.200]) by mail.ncipher.com with esmtp (TLSv1:DES-CBC3-SHA:168) (Exim 3.34 #1) id 1G22S0-0003X5-00 for freebsd-stable@freebsd.org; Sun, 16 Jul 2006 09:58:08 +0100 Received: from lap.knigma.org (mourn.ncipher.com [172.19.133.171]) by cromer.ncipher.com (8.13.6/8.13.6) with ESMTP id k6G8w5uU032711 for ; Sun, 16 Jul 2006 09:58:06 +0100 (BST) (envelope-from markk@knigma.org) Message-ID: Date: Sun, 16 Jul 2006 09:57:56 +0100 To: freebsd-stable@freebsd.org From: Mark Knight References: <20060711112745.U24728@nietykalni.org> In-Reply-To: <20060711112745.U24728@nietykalni.org> MIME-Version: 1.0 Content-Type: text/plain;charset=us-ascii;format=flowed User-Agent: Turnpike/6.05-U () Subject: Re: FreeBSD 6.0 sudden kernel panic X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Jul 2006 08:58:09 -0000 In message <20060711112745.U24728@nietykalni.org>, Lukasz Jaroszewski writes >I did nothing special when suddenly my freebsd rebooted: [snip] > Version String: FreeBSD 6.0-RELEASE #1: Tue Mar 14 10:40:21 CET 2006 > vandal@revival:/usr/obj/usr/src/sys/GENERIC-NIETYKALNI [snip] >#7 0xc05fec64 in closef (fp=0xc1826120, td=0xc28f4780) > at /usr/src/sys/kern/kern_descrip.c:1876 >1876 vfslocked = VFS_LOCK_GIANT(vp->v_mount); >Current language: auto; currently c >(kgdb) p vp >$2 = (struct vnode *) 0xc1e1fbb0 >(kgdb) p vp-v_mount >No symbol "v_mount" in current context. >(kgdb) p vp->v_mount >$3 = (struct mount *) 0x0 Looks similar to a panic I just reported on 6.1 Cheers, -- Mark A. R. Knight finger: markk@knigma.org Tel: +44 7880 556751 http://www.knigma.org/ From owner-freebsd-stable@FreeBSD.ORG Sun Jul 16 09:49:36 2006 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5341E16A4DA for ; Sun, 16 Jul 2006 09:49:36 +0000 (UTC) (envelope-from markk@knigma.org) Received: from mail.ncipher.com (mail.ncipher.com [82.108.130.24]) by mx1.FreeBSD.org (Postfix) with ESMTP id E026043D45 for ; Sun, 16 Jul 2006 09:49:35 +0000 (GMT) (envelope-from markk@knigma.org) Received: from cromer.ncipher.com ([172.23.135.200]) by mail.ncipher.com with esmtp (TLSv1:DES-CBC3-SHA:168) (Exim 3.34 #1) id 1G23Fk-0004OA-00 for freebsd-stable@freebsd.org; Sun, 16 Jul 2006 10:49:33 +0100 Received: from lap.knigma.org (mourn.ncipher.com [172.19.133.171]) by cromer.ncipher.com (8.13.6/8.13.6) with ESMTP id k6G9nTsE033479 for ; Sun, 16 Jul 2006 10:49:30 +0100 (BST) (envelope-from markk@knigma.org) Message-ID: Date: Sun, 16 Jul 2006 10:47:58 +0100 To: freebsd-stable@freebsd.org From: Mark Knight References: <20060716084210.GL32624@deviant.kiev.zoral.com.ua> <20060716091925.GM32624@deviant.kiev.zoral.com.ua> In-Reply-To: <20060716091925.GM32624@deviant.kiev.zoral.com.ua> MIME-Version: 1.0 Content-Type: text/plain;charset=us-ascii;format=flowed User-Agent: Turnpike/6.05-U () Subject: Re: 6.1 panic after approx. 49 days uptime X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Jul 2006 09:49:36 -0000 In message <20060716091925.GM32624@deviant.kiev.zoral.com.ua>, Kostik Belousov writes >Thank you for the data. As I see, the problem could be worked around by >the following patch: [snip] I'll try loading this on my box later today. Thank you!! >What seems to be quite untrivial is testing. Quite! > Did you had unmount >some filesystem before that panic happen ? No; I was fast asleep! I think the panic happened while executing a cron job that does a "cvs update" in /usr/ports. The same job ran successfully every morning for the preceding 48 days. Cheers, -- Mark A. R. Knight finger: markk@knigma.org Tel: +44 7880 556751 http://www.knigma.org/ From owner-freebsd-stable@FreeBSD.ORG Sun Jul 16 15:36:40 2006 Return-Path: X-Original-To: stable@freebsd.org Delivered-To: freebsd-stable@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5A6D616A4DE for ; Sun, 16 Jul 2006 15:36:40 +0000 (UTC) (envelope-from david@catwhisker.org) Received: from bunrab.catwhisker.org (adsl-63-193-123-122.dsl.snfc21.pacbell.net [63.193.123.122]) by mx1.FreeBSD.org (Postfix) with ESMTP id E2A9043D49 for ; Sun, 16 Jul 2006 15:36:39 +0000 (GMT) (envelope-from david@catwhisker.org) Received: from bunrab.catwhisker.org (localhost [127.0.0.1]) by bunrab.catwhisker.org (8.13.3/8.13.3) with ESMTP id k6GFadIb053398 for ; Sun, 16 Jul 2006 08:36:39 -0700 (PDT) (envelope-from david@bunrab.catwhisker.org) Received: (from david@localhost) by bunrab.catwhisker.org (8.13.3/8.13.1/Submit) id k6GFadYB053397 for stable@freebsd.org; Sun, 16 Jul 2006 08:36:39 -0700 (PDT) (envelope-from david) Date: Sun, 16 Jul 2006 08:36:39 -0700 From: David Wolfskill To: stable@freebsd.org Message-ID: <20060716153639.GU41150@bunrab.catwhisker.org> Mail-Followup-To: David Wolfskill , stable@freebsd.org Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="WTbgq2twYBxfsYA6" Content-Disposition: inline User-Agent: Mutt/1.4.2.1i Cc: Subject: Looks like new 802.11 devices need to be pruned from PAE configs X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Jul 2006 15:36:40 -0000 --WTbgq2twYBxfsYA6 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Looks as if some recent wireless changes are in some conflict with PAE. Trying to build a kernel but slightly tweaked (added SMP & IPFIREWALL) from PAE, I see (with sources updated as of Sun Jul 16 03:37:02 PDT 2006): =2E.. >>> stage 4.4: building everything =2E.. touch hack.c cc -shared -nostdlib hack.c -o hack.So rm -f hack.c MAKE=3D/usr/obj/usr/src/make.i386/make sh /usr/src/sys/conf/newvers.sh PAE-= GENERIC cc -c -O -pipe -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototype= s -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-ext ensions -std=3Dc99 -g -nostdinc -I- -I. -I/usr/src/sys -I/usr/src/sys/cont= rib/altq -I/usr/src/sys/contrib/ipfilter -I/usr/src/sys/contrib/pf -I/usr/sr c/sys/contrib/dev/ath -I/usr/src/sys/contrib/dev/ath/freebsd -I/usr/src/sys= /contrib/ngatm -I/usr/src/sys/dev/twa -D_KERNEL -DHAVE_KERNEL_OPTION_HEADE RS -include opt_global.h -fno-common -finline-limit=3D8000 --param inline-u= nit-growth=3D100 --param large-function-growth=3D1000 -mno-align-long-stri= ngs - mpreferred-stack-boundary=3D2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -ffre= estanding -Werror vers.c linking kernel.debug sample.o(.text+0x15cf): In function `ath_rate_newstate': /usr/src/sys/dev/ath/ath_rate/sample/sample.c:765: undefined reference to `= ieee80211_iterate_nodes' if_ath.o(.text+0x4f5): In function `ath_attach': /usr/src/sys/dev/ath/if_ath.c:429: undefined reference to `ieee80211_wme_ac= names' if_ath.o(.text+0x9b3):/usr/src/sys/dev/ath/if_ath.c:593: undefined referenc= e to `ieee80211_ifattach' if_ath.o(.text+0xa5c):/usr/src/sys/dev/ath/if_ath.c:611: undefined referenc= e to `ieee80211_media_status' if_ath.o(.text+0xa67):/usr/src/sys/dev/ath/if_ath.c:611: undefined referenc= e to `ieee80211_media_init' if_ath.o(.text+0xa87):/usr/src/sys/dev/ath/if_ath.c:621: undefined referenc= e to `ieee80211_announce' if_ath.o(.text+0xb02): In function `ath_detach': /usr/src/sys/dev/ath/if_ath.c:658: undefined reference to `ieee80211_ifdeta= ch' if_ath.o(.text+0xeab): In function `ath_bmiss_proc': /usr/src/sys/dev/ath/if_ath.c:871: undefined reference to `ieee80211_beacon= _miss' =2E.. /usr/src/sys/net80211/ieee80211_crypto_wep.c:444: undefined reference to `i= eee80211_note' ieee80211_crypto_wep.o(.text+0x889): In function `wep_modevent': /usr/src/sys/net80211/ieee80211_crypto_wep.c:487: undefined reference to `i= eee80211_crypto_register' ieee80211_crypto_wep.o(.text+0x8bf):/usr/src/sys/net80211/ieee80211_crypto_= wep.c:497: undefined reference to `ieee80211_crypto_unregister' *** Error code 1 Stop in /usr/obj/usr/src/sys/SMP_PAE. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. I've resolved it locally by the "big hammer" approach of adding the following to my kernel config: nodevice wlan # 802.11 support nodevice wlan_wep # 802.11 WEP support nodevice wlan_ccmp # 802.11 CCMP support nodevice wlan_tkip # 802.11 TKIP support nodevice an # Aironet 4500/4800 802.11 wireless NICs. nodevice ath # Atheros pci/cardbus NIC's nodevice ath_hal # Atheros HAL (Hardware Access Layer) nodevice ath_rate_sample # SampleRate tx rate control for ath nodevice awi # BayStack 660 and others nodevice ral # Ralink Technology RT2500 wireless NICs. nodevice wi # WaveLAN/Intersil/Symbol 802.11 wireless N= ICs. But perhaps the PAE kernel config, which currently has: nodevice wlan nodevice an nodevice awi nodevice ral nodevice wi could use some of what I had added? At a guess: nodevice wlan_wep nodevice wlan_ccmp nodevice wlan_tkip nodevice ath nodevice ath_hal nodevice ath_rate_sample Peace, david --=20 David H. Wolfskill david@catwhisker.org Doing business with spammers only encourages them. Please boycott spammers. See http://www.catwhisker.org/~david/publickey.gpg for my public key. --WTbgq2twYBxfsYA6 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (FreeBSD) iEYEARECAAYFAkS6XQUACgkQmprOCmdXAD0KJwCfWUMb2ZqoXlHeaDTHAv7zDWGC Yd0An2vmEa96ywA+/Ic9EtIHjcB+OL6m =kejh -----END PGP SIGNATURE----- --WTbgq2twYBxfsYA6-- From owner-freebsd-stable@FreeBSD.ORG Sun Jul 16 22:20:36 2006 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 49B8416A4DF for ; Sun, 16 Jul 2006 22:20:36 +0000 (UTC) (envelope-from pawel.worach@gmail.com) Received: from ug-out-1314.google.com (ug-out-1314.google.com [66.249.92.168]) by mx1.FreeBSD.org (Postfix) with ESMTP id AE67343D45 for ; Sun, 16 Jul 2006 22:20:34 +0000 (GMT) (envelope-from pawel.worach@gmail.com) Received: by ug-out-1314.google.com with SMTP id m2so597433uge for ; Sun, 16 Jul 2006 15:20:33 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:user-agent:mime-version:to:subject:content-type:content-transfer-encoding; b=NGP8c4TkezLd9XmdvTdrM1I0v5WVWpm0Yb3O7pe7VSzqLC+d4Yj0qjCpSg7DsPj0VzrijRHwrOLQdaAGw1m0cyO19mdwPdOJmw2LtMxQWcWNoMV1XhaOKGV1LEE9wuK+FrvPmVhdUQCJYnmTEApIKvKcehc/pUSjZlFmkZ/i4pQ= Received: by 10.78.140.17 with SMTP id n17mr586143hud; Sun, 16 Jul 2006 15:20:33 -0700 (PDT) Received: from ?192.168.1.200? ( [80.217.194.157]) by mx.gmail.com with ESMTP id 3sm1449682huc.2006.07.16.15.20.32; Sun, 16 Jul 2006 15:20:33 -0700 (PDT) Message-ID: <44BABBAD.5060606@gmail.com> Date: Mon, 17 Jul 2006 00:20:29 +0200 From: Pawel Worach User-Agent: Thunderbird 1.5.0.4 (X11/20060715) MIME-Version: 1.0 To: freebsd-stable@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: panic: page fault in kern_kevent X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Jul 2006 22:20:36 -0000 Under moderate kqueue load I caught the following: Fatal trap 12: page fault while in kernel mode fault virtual address = 0x0 fault code = supervisor read, page not present instruction pointer = 0x20:0x0 stack pointer = 0x28:0xe745db78 frame pointer = 0x28:0xe745dbb8 code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 582 (squid) trap number = 12 panic: page fault KDB: stack backtrace: kdb_backtrace(c065b33b,c06a4780,c065344e,e745da80,100) at kdb_backtrace+0x2e panic(c065344e,c066df69,c49c0dd0,1,1) at panic+0xb7 trap_fatal(e745db38,0,1,0,c05239e2) at trap_fatal+0x33e trap_pfault(e745db38,0,0,e745db38,0) at trap_pfault+0x242 trap(c05e0008,c7310028,28,0,4) at trap+0x350 calltrap() at calltrap+0x5 --- trap 0xc, eip = 0, esp = 0xe745db78, ebp = 0xe745dbb8 --- MAXCPU(c4b20500,e745dbe8,c65c3300,1,c0c38000) at 0 kern_kevent(c65c3300,3,5,80,e745dcbc) at kern_kevent+0xf8 kevent(c65c3300,e745dd04,18,16,c65c3300) at kevent+0x7a syscall(821003b,3b,822003b,48106cf0,bfbfeec8) at syscall+0x380 Xint0x80_syscall() at Xint0x80_syscall+0x1f --- syscall (363, FreeBSD ELF32, kevent), eip = 0x4821ccfb, esp = 0xbfbfedfc, ebp = 0xbfbfee48 --- Uptime: 3d15h16m7s Dumping 1023 MB (2 chunks) chunk 0: 1MB (159 pages) ... ok chunk 1: 1023MB (261884 pages) 1008 992 976 960 944 928 912 896 880 864 848 832 816 800 784 768 752 736 720 704 688 672 656 640 624 608 592 576 560 544 528 512 496 480 464 448 432 416 400 384 368 352 336 320 304 288 272 256 240 224 208 192 176 160 144 128 112 96 80 64 48 32 16 (kgdb) bt #0 doadump () at pcpu.h:165 #1 0xc04c261c in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:409 #2 0xc04c299d in panic (fmt=0xc065344e "%s") at /usr/src/sys/kern/kern_shutdown.c:565 #3 0xc0637f7e in trap_fatal (frame=0xe745db38, eva=0) at /usr/src/sys/i386/i386/trap.c:836 #4 0xc0637c12 in trap_pfault (frame=0xe745db38, usermode=0, eva=0) at /usr/src/sys/i386/i386/trap.c:744 #5 0xc0637780 in trap (frame= {tf_fs = -1067581432, tf_es = -953090008, tf_ds = 40, tf_edi = 0, tf_esi = 4, tf_ebp = -414852168, tf_isp = -414852252, tf_ebx = 4, tf_edx = -953052640, tf_ecx = -1066925280, tf_eax = -1066924800, tf_trapno = 12, tf_err = 0, tf_eip = 0, tf_cs = 32, tf_eflags = 66118, tf_esp = -1068903001, tf_ss = -953052640}) at /usr/src/sys/i386/i386/trap.c:434 #6 0xc062498a in calltrap () at /usr/src/sys/i386/i386/exception.s:139 #7 0x00000000 in ?? () Previous frame inner to this frame (corrupt stack?) (kgdb) l *kern_kevent+0xf8 0xc049c6d8 is in kern_kevent (/usr/src/sys/kern/kern_event.c:637). 632 goto done; 633 changes = keva; 634 for (i = 0; i < n; i++) { 635 kevp = &changes[i]; 636 kevp->flags &= ~EV_SYSFLAGS; 637 error = kqueue_register(kq, kevp, td, 1); 638 if (error) { 639 if (nevents != 0) { 640 kevp->flags = EV_ERROR; 641 kevp->data = error; System is i386 UP running FreeBSD 6.1-STABLE #0: Sun Jul 9 01:11:16 CEST 2006 -- Pawel From owner-freebsd-stable@FreeBSD.ORG Sun Jul 16 22:53:09 2006 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 21F3616A4DD for ; Sun, 16 Jul 2006 22:53:09 +0000 (UTC) (envelope-from mike@sentex.net) Received: from smarthost2.sentex.ca (smarthost2.sentex.ca [205.211.164.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id AB51D43D6D for ; Sun, 16 Jul 2006 22:53:08 +0000 (GMT) (envelope-from mike@sentex.net) Received: from lava.sentex.ca (pyroxene.sentex.ca [199.212.134.18]) by smarthost2.sentex.ca (8.13.6/8.13.4) with ESMTP id k6GMr7I1082206; Sun, 16 Jul 2006 18:53:07 -0400 (EDT) (envelope-from mike@sentex.net) Received: from simian.sentex.net (simeon.sentex.ca [192.168.43.27]) by lava.sentex.ca (8.13.3P/8.13.3) with ESMTP id k6GMr6LN000581 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 16 Jul 2006 18:53:07 -0400 (EDT) (envelope-from mike@sentex.net) Message-Id: <6.2.3.4.0.20060716185019.12a29240@64.7.153.2> X-Mailer: QUALCOMM Windows Eudora Version 6.2.3.4 Date: Sun, 16 Jul 2006 18:53:42 -0400 To: Miroslav Lachman <000.fbsd@quip.cz>, freebsd-stable@freebsd.org From: Mike Tancsa In-Reply-To: <44B7EA39.4060509@quip.cz> References: <8D08DDB6-6AC1-45B6-B2CE-08782F54968A@stromnet.org> <884C01BC-3E97-46EC-AA8B-E70C3931F3A4@stromnet.org> <36895211-2796-4213-B336-6279AB3AC3CB@stromnet.org> <20060713132357.Y61840@fledge.watson.org> <44B7EA39.4060509@quip.cz> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: Subject: Re: ATA problems again ... X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Jul 2006 22:53:09 -0000 At 03:02 PM 14/07/2006, Miroslav Lachman wrote: >After reboot (command reboot), system boot up with both disks >attached and start autosynchronization. I do not know, if this is hw >or sw error, I got Install the smartmontools from /usr/ports/sysutils/smartmontools/ and post the output of smartctl -a /dev/ad8 ---Mike From owner-freebsd-stable@FreeBSD.ORG Mon Jul 17 09:02:54 2006 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E24E416A4DD; Mon, 17 Jul 2006 09:02:54 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from fw.zoral.com.ua (fw.zoral.com.ua [213.186.206.134]) by mx1.FreeBSD.org (Postfix) with ESMTP id EBA2143D45; Mon, 17 Jul 2006 09:02:53 +0000 (GMT) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (root@deviant.kiev.zoral.com.ua [10.1.1.148]) by fw.zoral.com.ua (8.13.4/8.13.4) with ESMTP id k6G9ptFk008974 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 16 Jul 2006 12:51:55 +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.13.6/8.13.6) with ESMTP id k6G9ptoP074984; Sun, 16 Jul 2006 12:51:55 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.13.6/8.13.6/Submit) id k6G9ptZp074974; Sun, 16 Jul 2006 12:51:55 +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: Sun, 16 Jul 2006 12:51:55 +0300 From: Kostik Belousov To: Mark Knight Message-ID: <20060716095155.GN32624@deviant.kiev.zoral.com.ua> References: <20060716084210.GL32624@deviant.kiev.zoral.com.ua> <20060716091925.GM32624@deviant.kiev.zoral.com.ua> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="ai3I8gwHc37+ASRI" Content-Disposition: inline In-Reply-To: <20060716091925.GM32624@deviant.kiev.zoral.com.ua> User-Agent: Mutt/1.4.2.1i X-Virus-Scanned: ClamAV version 0.88.2, clamav-milter version 0.88.2 on fw.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=0.4 required=5.0 tests=ALL_TRUSTED, DNS_FROM_RFC_ABUSE,SPF_NEUTRAL autolearn=no version=3.1.3 X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on fw.zoral.com.ua Cc: freebsd-fs@freebsd.org, freebsd-stable@freebsd.org Subject: Re: 6.1 panic after approx. 49 days uptime X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Jul 2006 09:02:55 -0000 --ai3I8gwHc37+ASRI Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Jul 16, 2006 at 12:19:25PM +0300, Kostik Belousov wrote: > On Sun, Jul 16, 2006 at 09:46:49AM +0100, Mark Knight wrote: >=20 > Index: mount.h > =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 > RCS file: /usr/local/arch/ncvs/src/sys/sys/mount.h,v > retrieving revision 1.210 > diff -u -r1.210 mount.h > --- mount.h 5 May 2006 19:32:35 -0000 1.210 > +++ mount.h 16 Jul 2006 09:15:32 -0000 > @@ -578,7 +578,7 @@ > int _locked; \ > struct mount *_MP; \ > _MP =3D (MP); \ > - if (VFS_NEEDSGIANT(_MP)) { \ > + if (_MP !=3D NULL && VFS_NEEDSGIANT(_MP)) { \ > mtx_lock(&Giant); \ > _locked =3D 1; \ > } else \ This is not needed, since the problem was fixed on HEAD and RELENG_6 by tegge, see rev. 1.210 of sys/sys/mount.h. Fix was committed after release of 6.1. --ai3I8gwHc37+ASRI Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.4 (FreeBSD) iD8DBQFEugw6C3+MBN1Mb4gRAkDHAJ0RpVAee7yMKXDo8KbN+he6JrALSgCguSMo eSDqDb4/q0lK7qiX5zvRsd4= =yT0z -----END PGP SIGNATURE----- --ai3I8gwHc37+ASRI-- From owner-freebsd-stable@FreeBSD.ORG Mon Jul 17 09:02:56 2006 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4614B16A4E0; Mon, 17 Jul 2006 09:02:56 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from fw.zoral.com.ua (fw.zoral.com.ua [213.186.206.134]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8717B43D45; Mon, 17 Jul 2006 09:02:55 +0000 (GMT) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (root@deviant.kiev.zoral.com.ua [10.1.1.148]) by fw.zoral.com.ua (8.13.4/8.13.4) with ESMTP id k6G9JQFP008185 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 16 Jul 2006 12:19:26 +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.13.6/8.13.6) with ESMTP id k6G9JQeH027191; Sun, 16 Jul 2006 12:19:26 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.13.6/8.13.6/Submit) id k6G9JPlR027182; Sun, 16 Jul 2006 12:19:25 +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: Sun, 16 Jul 2006 12:19:25 +0300 From: Kostik Belousov To: Mark Knight Message-ID: <20060716091925.GM32624@deviant.kiev.zoral.com.ua> References: <20060716084210.GL32624@deviant.kiev.zoral.com.ua> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="tBhgiDt8dP1efIIJ" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.1i X-Virus-Scanned: ClamAV version 0.88.2, clamav-milter version 0.88.2 on fw.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=0.4 required=5.0 tests=ALL_TRUSTED, DNS_FROM_RFC_ABUSE,SPF_NEUTRAL autolearn=no version=3.1.3 X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on fw.zoral.com.ua Cc: freebsd-fs@freebsd.org, freebsd-stable@freebsd.org Subject: Re: 6.1 panic after approx. 49 days uptime X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Jul 2006 09:02:56 -0000 --tBhgiDt8dP1efIIJ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Jul 16, 2006 at 09:46:49AM +0100, Mark Knight wrote: > In message <20060716084210.GL32624@deviant.kiev.zoral.com.ua>, Kostik=20 > Belousov writes > >On Sun, Jul 16, 2006 at 09:32:47AM +0100, Mark Knight wrote: > >>Just awoke to fine my home server (6.1-RELEASE) had panicked during its > >>daily update of /usr/ports with an uptime of 49 days. > >> > >>Stack trace is here: > >> > >> > >> > >>Looks file system related to me. Any advice appreciated. > > > >If you still have the core dump at hands, go to frame #7 and post the > >output of the commands "p *vp" and "p *(vp->v_mount)". >=20 > Appended to log file (in case of mail formatting) and reproduced here: >=20 > (kgdb) p *(vp) > $3 =3D {v_type =3D VBAD, v_tag =3D 0xc0791704 "none", v_op =3D 0xc07d89e0= , v_data =3D=20 > 0x0, v_mount =3D 0x0, > v_nmntvnodes =3D {tqe_next =3D 0x0, tqe_prev =3D 0xc3250014}, v_un =3D = {vu_mount=20 > =3D 0x0, vu_socket =3D 0x0, > vu_cdev =3D 0x0, vu_fifoinfo =3D 0x0}, v_hashlist =3D {le_next =3D 0x= 0, le_prev=20 > =3D 0xc295f570}, > v_hash =3D 3269747, v_cache_src =3D {lh_first =3D 0x0}, v_cache_dst =3D= =20 > {tqh_first =3D 0x0, tqh_last =3D 0xc335cbe0}, > v_dd =3D 0x0, v_cstart =3D 0, v_lasta =3D 0, v_lastw =3D 0, v_clen =3D = 0, v_lock =3D=20 > {lk_interlock =3D 0xc08073dc, > lk_flags =3D 64, lk_sharecount =3D 0, lk_waitcount =3D 0, lk_exclusiv= ecount =3D=20 > 0, lk_prio =3D 80, > lk_wmesg =3D 0xc07a24ed "ufs", lk_timo =3D 51, lk_lockholder =3D 0xff= ffffff,=20 > lk_newlock =3D 0x0}, > v_interlock =3D {mtx_object =3D {lo_class =3D 0xc07e0644, lo_name =3D 0= xc07a3a55=20 > "vnode interlock", > lo_type =3D 0xc07a3a55 "vnode interlock", lo_flags =3D 196608, lo_l= ist =3D=20 > {tqe_next =3D 0x0, > tqe_prev =3D 0x0}, lo_witness =3D 0x0}, mtx_lock =3D 4, mtx_recur= se =3D 0},=20 > v_vnlock =3D 0xc335cc08, > v_holdcnt =3D 1, v_usecount =3D 0, v_iflag =3D 128, v_vflag =3D 0, v_wr= itecount =3D=20 > 0, v_freelist =3D { > tqe_next =3D 0xc3248990, tqe_prev =3D 0xc080d22c}, v_bufobj =3D {bo_m= tx =3D=20 > 0xc335cc2c, bo_clean =3D {bv_hd =3D { > tqh_first =3D 0x0, tqh_last =3D 0xc335cc74}, bv_root =3D 0x0, bv_= cnt =3D=20 > 0}, bo_dirty =3D {bv_hd =3D { > tqh_first =3D 0x0, tqh_last =3D 0xc335cc84}, bv_root =3D 0x0, bv_= cnt =3D=20 > 0}, bo_numoutput =3D 0, bo_flag =3D 0, > bo_ops =3D 0xc07e6564, bo_bsize =3D 8192, bo_object =3D 0x0, bo_syncl= ist =3D=20 > {le_next =3D 0x0, le_prev =3D 0x0}, > bo_private =3D 0xc335cbb0, __bo_vnode =3D 0xc335cbb0}, v_pollinfo =3D= 0x0,=20 > v_label =3D 0x0} > (kgdb) p *(vp->v_mount) > Cannot access memory at address 0x0 > (kgdb) >=20 > Thanks, Thank you for the data. As I see, the problem could be worked around by the following patch: Index: mount.h =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 RCS file: /usr/local/arch/ncvs/src/sys/sys/mount.h,v retrieving revision 1.210 diff -u -r1.210 mount.h --- mount.h 5 May 2006 19:32:35 -0000 1.210 +++ mount.h 16 Jul 2006 09:15:32 -0000 @@ -578,7 +578,7 @@ int _locked; \ struct mount *_MP; \ _MP =3D (MP); \ - if (VFS_NEEDSGIANT(_MP)) { \ + if (_MP !=3D NULL && VFS_NEEDSGIANT(_MP)) { \ mtx_lock(&Giant); \ _locked =3D 1; \ } else \ What seems to be quite untrivial is testing. Did you had unmount some filesystem before that panic happen ? To reproduce the situation, the following cojunction of the events is neede= d: 1. you have free vnode pressure 2. some very active fs in unmounted 3. some further file activity is going on --tBhgiDt8dP1efIIJ Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.4 (FreeBSD) iD8DBQFEugSdC3+MBN1Mb4gRAnilAJ92qyB84eq3du4WDmulhov11ZwAnQCg7JX0 nrlrB9Ie0YmEedmgZAzmplM= =+sfK -----END PGP SIGNATURE----- --tBhgiDt8dP1efIIJ-- From owner-freebsd-stable@FreeBSD.ORG Mon Jul 17 09:02:58 2006 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 18F4A16A56A for ; Mon, 17 Jul 2006 09:02:58 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from fw.zoral.com.ua (fw.zoral.com.ua [213.186.206.134]) by mx1.FreeBSD.org (Postfix) with ESMTP id DCB9943D45 for ; Mon, 17 Jul 2006 09:02:56 +0000 (GMT) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (root@deviant.kiev.zoral.com.ua [10.1.1.148]) by fw.zoral.com.ua (8.13.4/8.13.4) with ESMTP id k6G8gBHv007375 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 16 Jul 2006 11:42:11 +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.13.6/8.13.6) with ESMTP id k6G8gAFf026641; Sun, 16 Jul 2006 11:42:10 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.13.6/8.13.6/Submit) id k6G8gADN026636; Sun, 16 Jul 2006 11:42:10 +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: Sun, 16 Jul 2006 11:42:10 +0300 From: Kostik Belousov To: Mark Knight Message-ID: <20060716084210.GL32624@deviant.kiev.zoral.com.ua> References: Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="enLffk0M6cffIOOh" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.1i X-Virus-Scanned: ClamAV version 0.88.2, clamav-milter version 0.88.2 on fw.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=0.4 required=5.0 tests=ALL_TRUSTED, DNS_FROM_RFC_ABUSE,SPF_NEUTRAL autolearn=no version=3.1.3 X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on fw.zoral.com.ua Cc: freebsd-stable@freebsd.org Subject: Re: 6.1 panic after approx. 49 days uptime X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Jul 2006 09:02:58 -0000 --enLffk0M6cffIOOh Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Jul 16, 2006 at 09:32:47AM +0100, Mark Knight wrote: > Just awoke to fine my home server (6.1-RELEASE) had panicked during its > daily update of /usr/ports with an uptime of 49 days. >=20 > Stack trace is here: >=20 > >=20 > Looks file system related to me. Any advice appreciated. If you still have the core dump at hands, go to frame #7 and post the output of the commands "p *vp" and "p *(vp->v_mount)". --enLffk0M6cffIOOh Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.4 (FreeBSD) iD8DBQFEufviC3+MBN1Mb4gRArnMAKC47CfDp24kjtG/Vnzti/F16MGLrwCgsX5p lImPjSfW97Lgl7tl3HnoJvg= =/Iz2 -----END PGP SIGNATURE----- --enLffk0M6cffIOOh-- From owner-freebsd-stable@FreeBSD.ORG Mon Jul 17 09:59:22 2006 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 48FF116A4E1 for ; Mon, 17 Jul 2006 09:59:22 +0000 (UTC) (envelope-from johan@stromnet.org) Received: from pne-smtpout1-sn2.hy.skanova.net (pne-smtpout1-sn2.hy.skanova.net [81.228.8.83]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4F74943D62 for ; Mon, 17 Jul 2006 09:59:20 +0000 (GMT) (envelope-from johan@stromnet.org) Received: from elfi.stromnet.org (213.67.205.103) by pne-smtpout1-sn2.hy.skanova.net (7.2.075) id 44A2E86F003910E5; Mon, 17 Jul 2006 11:59:19 +0200 Received: from localhost (localhost [127.0.0.1]) by elfi.stromnet.org (Postfix) with ESMTP id B9A8F61D64; Mon, 17 Jul 2006 11:59:17 +0200 (CEST) X-Virus-Scanned: amavisd-new at stromnet.org Received: from elfi.stromnet.org ([127.0.0.1]) by localhost (elfi.stromnet.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sUgn8HvJsfgp; Mon, 17 Jul 2006 11:59:16 +0200 (CEST) Received: from [IPv6:2001:16d8:ff20:2:211:24ff:fea2:8e01] (unknown [IPv6:2001:16d8:ff20:2:211:24ff:fea2:8e01]) by elfi.stromnet.org (Postfix) with ESMTP id 6D7BB61D72; Mon, 17 Jul 2006 11:59:16 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v750) In-Reply-To: <6.2.3.4.0.20060716185019.12a29240@64.7.153.2> References: <8D08DDB6-6AC1-45B6-B2CE-08782F54968A@stromnet.org> <884C01BC-3E97-46EC-AA8B-E70C3931F3A4@stromnet.org> <36895211-2796-4213-B336-6279AB3AC3CB@stromnet.org> <20060713132357.Y61840@fledge.watson.org> <44B7EA39.4060509@quip.cz> <6.2.3.4.0.20060716185019.12a29240@64.7.153.2> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <4AD53F0E-4CDA-4D20-82A4-A248FC541184@stromnet.org> Content-Transfer-Encoding: 7bit From: =?ISO-8859-1?Q?Johan_Str=F6m?= Date: Mon, 17 Jul 2006 11:59:41 +0200 To: freebsd-stable@freebsd.org, Mike Tancsa X-Mailer: Apple Mail (2.750) Cc: Subject: Re: ATA problems again ... X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Jul 2006 09:59:22 -0000 On 17 jul 2006, at 00.53, Mike Tancsa wrote: > At 03:02 PM 14/07/2006, Miroslav Lachman wrote: > > >> After reboot (command reboot), system boot up with both disks >> attached and start autosynchronization. I do not know, if this is >> hw or sw error, I got > > Install the smartmontools from > > /usr/ports/sysutils/smartmontools/ > > and post the output of > smartctl -a /dev/ad8 I tried this on my SATA disk ad6: === START OF INFORMATION SECTION === Model Family: Maxtor MaXLine III family Device Model: Maxtor 7L300S0 Serial Number: L60CJKPH Firmware Version: BANC1G10 User Capacity: 300,090,728,448 bytes Device is: In smartctl database [for details use: -P show] ATA Version is: 7 ATA Standard is: ATA/ATAPI-7 T13 1532D revision 0 Local Time is: Mon Jul 17 11:54:35 2006 CEST SMART support is: Available - device has SMART capability. SMART support is: Enabled .... SMART Error Log Version: 1 No Errors Logged Any other output from smartctl that can help? Both my ad4 and ad6 are the same. Now I had yet another crash.. They are very much more intense now the latest days... Two crashes ago I changed the SATA cable to ad4, i wonder if that had anything to do with it... On the other hand, now it was ad6 that got lost, so why would ad4's cable make any difference.. i'll change ad6 now too when i've taken the box down.. Jul 16 03:27:25 elfi kernel: ad6: FAILURE - device detached Jul 16 03:27:25 elfi kernel: subdisk6: detached Jul 16 03:27:25 elfi kernel: ad6: detached Jul 16 03:27:25 elfi kernel: GEOM_MIRROR: Device gm0s1: provider ad6s1 disconnected. Jul 16 03:27:25 elfi kernel: g_vfs_done():mirror/gm0s1f[READ (offset=27210082304, length=2048)]error = 6 Jul 16 03:27:25 elfi kernel: g_vfs_done():mirror/gm0s1f[READ (offset=35153985536, length=32768)]error = 6 Jul 16 03:27:25 elfi kernel: ufs_access(): Error retrieving ACL on object (6). Jul 16 03:27:25 labdator kernel: nfs: server 192.168.1.2 not responding, still trying Jul 16 03:27:25 labdator kernel: nfs: server 192.168.1.2 OK Those last 3 messages seems to be very related to the gmirror going to degraded mode? Some ACL reading and a mounted NFS system (192.168.1.2 is the failing box). Is there some way to enable more debug info output or something?? Johan From owner-freebsd-stable@FreeBSD.ORG Mon Jul 17 10:18:14 2006 Return-Path: X-Original-To: stable@FreeBSD.org Delivered-To: freebsd-stable@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4660616A4DD; Mon, 17 Jul 2006 10:18:14 +0000 (UTC) (envelope-from ume@mahoroba.org) Received: from ameno.mahoroba.org (gw4.mahoroba.org [218.45.22.175]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2879A43D45; Mon, 17 Jul 2006 10:18:12 +0000 (GMT) (envelope-from ume@mahoroba.org) Received: from kasuga.mahoroba.org (IDENT:TurIrSWiWTHbSlDSMqKA+ZQpvaET+jacF2VEicg6OIBhtZhP/qipbefed9AFpWsJ@kasuga-iwi.mahoroba.org [IPv6:2001:2f0:104:8010:212:f0ff:fe52:6ac]) (user=ume mech=CRAM-MD5 bits=0) by ameno.mahoroba.org (8.13.6/8.13.6) with ESMTP/inet6 id k6HAI4PG069980 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 17 Jul 2006 19:18:05 +0900 (JST) (envelope-from ume@mahoroba.org) Date: Mon, 17 Jul 2006 19:18:04 +0900 Message-ID: From: Hajimu UMEMOTO To: stable@FreeBSD.org, ports@FreeBSD.org, gnome@FreeBSD.org References: <200607171009.k6HA9xHu070992@repoman.freebsd.org> User-Agent: Wanderlust/2.14.0 (Africa) SEMI/1.14.6 (Maruoka) FLIM/1.14.8 (=?ISO-8859-4?Q?Shij=F2?=) APEL/10.6 Emacs/22.0.50 (i386-pc-freebsd) MULE/5.0 (SAKAKI) X-Operating-System: FreeBSD 6.1-STABLE 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: multipart/mixed; boundary="Multipart_Mon_Jul_17_19:18:03_2006-1" X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.1.5 (ameno.mahoroba.org [IPv6:2001:2f0:104:8010::1]); Mon, 17 Jul 2006 19:18:05 +0900 (JST) X-Virus-Scanned: by amavisd-new X-Virus-Status: Clean X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.3 X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on ameno.mahoroba.org Cc: Subject: HEADS UP: BIND9's resolver and reentrant version of netdb functions are MFC'ed X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Jul 2006 10:18:14 -0000 --Multipart_Mon_Jul_17_19:18:03_2006-1 Content-Type: text/plain; charset=US-ASCII Hi, I've just MFC'ed the BIND9's resolver stuff and reentrant version of netdb functions. It is known that some ports are confused by existence of reentrant functions. So, I've bumped __FreeBSD_version to 601103. --Multipart_Mon_Jul_17_19:18:03_2006-1 Content-Type: message/rfc822 X-Sieve: CMU Sieve 2.3 Delivered-To: ume@freebsd.org X-Original-To: src-committers@FreeBSD.org Delivered-To: src-committers@FreeBSD.org Message-Id: <200607171009.k6HA9xHu070992@repoman.freebsd.org> From: Hajimu UMEMOTO Date: Mon, 17 Jul 2006 10:09:59 +0000 (UTC) To: src-committers@FreeBSD.org, cvs-src@FreeBSD.org, cvs-all@FreeBSD.org Subject: cvs commit: src/sys/sys param.h src/include Makefile netdb.h res_update.h resolv.h src/include/arpa inet.h nameser.h nameser_compat.h src/lib/libc Makefile src/lib/libc/include port_after.h port_before.h resolv_mt.h src/lib/libc/include/isc ... X-FreeBSD-CVS-Branch: RELENG_6 Sender: owner-src-committers@FreeBSD.org Precedence: bulk X-Loop: FreeBSD.ORG X-Greylist: Sender is SPF-compliant, not delayed by milter-greylist-2.1.5 (ameno.mahoroba.org [218.45.22.175]); Mon, 17 Jul 2006 19:10:11 +0900 (JST) X-Virus-Scanned: by amavisd-new X-Virus-Status: Clean X-Spam-Status: No, score=-4.3 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00, SPF_PASS autolearn=ham version=3.1.3 X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on ameno.mahoroba.org ume 2006-07-17 10:09:59 UTC FreeBSD src repository Modified files: (Branch: RELENG_6) sys/sys param.h include Makefile netdb.h resolv.h include/arpa inet.h nameser.h nameser_compat.h lib/libc Makefile lib/libc/net Makefile.inc getaddrinfo.c gethostbydns.c gethostbyht.c gethostbyname.3 gethostbynis.c gethostnamadr.c getnameinfo.c getnetbydns.c getnetbyht.c getnetbynis.c getnetnamadr.c getproto.c getprotoent.c getprotoname.c getservbyname.c getservbyport.c getservent.c name6.c netdb_private.h res_config.h res_mkupdate.c res_update.c Added files: (Branch: RELENG_6) include res_update.h lib/libc/include port_after.h port_before.h resolv_mt.h lib/libc/include/isc eventlib.h lib/libc/inet Makefile.inc inet_addr.c inet_cidr_ntop.c inet_cidr_pton.c inet_lnaof.c inet_makeaddr.c inet_net_ntop.c inet_net_pton.c inet_neta.c inet_netof.c inet_network.c inet_ntoa.c inet_ntop.c inet_pton.c nsap_addr.c lib/libc/isc Makefile.inc ev_streams.c ev_timers.c eventlib_p.h lib/libc/nameser Makefile.inc ns_name.c ns_netint.c ns_parse.c ns_print.c ns_samedomain.c ns_ttl.c lib/libc/resolv Makefile.inc h_errno.c herror.c mtctxres.c res_comp.c res_data.c res_debug.c res_debug.h res_init.c res_mkquery.c res_private.h res_query.c res_send.c res_state.c Removed files: (Branch: RELENG_6) lib/libc/net herror.c inet_addr.c inet_lnaof.c inet_makeaddr.c inet_net_ntop.c inet_net_pton.c inet_neta.c inet_netof.c inet_network.c inet_ntoa.c inet_ntop.c inet_pton.c ns_name.c ns_netint.c ns_parse.c ns_print.c ns_ttl.c nsap_addr.c res_comp.c res_data.c res_debug.c res_init.c res_mkquery.c res_query.c res_send.c res_send_private.h Log: MFC: - Update the resolver in libc to BIND9's one. - make reentrant version of netdb functions glibc style API, and expose them to outside of libc. - make netdb functions NSS friendly. include/Makefile 1.261 include/arpa/inet.h 1.26 include/arpa/nameser.h 1.18 include/arpa/nameser_compat.h 1.5 include/netdb.h 1.40-1.42 include/res_update.h 1.1 include/resolv.h 1.29-1.30 lib/libc/Makefile 1.64 lib/libc/include/isc/eventlib.h 1.1.1.1 lib/libc/include/port_after.h 1.1-1.2 lib/libc/include/port_before.h 1.1 lib/libc/include/resolv_mt.h 1.1.1.1 lib/libc/inet/Makefile.inc 1.1 lib/libc/inet/inet_addr.c 1.1.1.1, 1.2 lib/libc/inet/inet_cidr_ntop.c 1.1.1.1 lib/libc/inet/inet_cidr_pton.c 1.1.1.1, 1.2 lib/libc/inet/inet_lnaof.c 1.1.1.1, 1.2 lib/libc/inet/inet_makeaddr.c 1.1.1.1, 1.2 lib/libc/inet/inet_net_ntop.c 1.1.1.1, 1.2 lib/libc/inet/inet_net_pton.c 1.1.1.1, 1.2 lib/libc/inet/inet_neta.c 1.1.1.1, 1.2 lib/libc/inet/inet_netof.c 1.1.1.1, 1.2 lib/libc/inet/inet_network.c 1.1.1.1, 1.2 lib/libc/inet/inet_ntoa.c 1.1.1.1, 1.2 lib/libc/inet/inet_ntop.c 1.1.1.1, 1.2 lib/libc/inet/inet_pton.c 1.1.1.1, 1.2 lib/libc/inet/nsap_addr.c 1.1.1.1, 1.2 lib/libc/isc/Makefile.inc 1.1 lib/libc/isc/ev_streams.c 1.1.1.1, 1.2 lib/libc/isc/ev_timers.c 1.1.1.1, 1.2 lib/libc/isc/eventlib_p.h 1.1.1.1, 1.2 lib/libc/nameser/Makefile.inc 1.1 lib/libc/nameser/ns_name.c 1.1.1.1 lib/libc/nameser/ns_netint.c 1.1.1.1 lib/libc/nameser/ns_parse.c 1.1.1.1 lib/libc/nameser/ns_print.c 1.1.1.1, 1.2 lib/libc/nameser/ns_samedomain.c 1.1.1.1, 1.2 lib/libc/nameser/ns_ttl.c 1.1.1.1 lib/libc/net/Makefile.inc 1.58 lib/libc/net/getaddrinfo.c 1.74, 1.77-1.78 lib/libc/net/gethostbydns.c 1.55-1.57 lib/libc/net/gethostbyht.c 1.24-1.26 lib/libc/net/gethostbyname.3 1.35 lib/libc/net/gethostbynis.c 1.26-1.28 lib/libc/net/gethostnamadr.c 1.29-1.30, 1.32 lib/libc/net/getnameinfo.c 1.18 lib/libc/net/getnetbydns.c 1.32-1.33 lib/libc/net/getnetbyht.c 1.17-1.18 lib/libc/net/getnetbynis.c 1.20-1.21 lib/libc/net/getnetnamadr.c 1.22 lib/libc/net/getproto.c 1.5 lib/libc/net/getprotoent.c 1.7 lib/libc/net/getprotoname.c 1.5 lib/libc/net/getservbyname.c 1.8 lib/libc/net/getservbyport.c 1.8 lib/libc/net/getservent.c 1.21 lib/libc/net/name6.c 1.56-1.57 lib/libc/net/netdb_private.h 1.10-1.11, 1.13 lib/libc/net/res_config.h 1.9 lib/libc/net/res_mkupdate.c 1.7-1.8 lib/libc/net/res_update.c 1.8-1.9 lib/libc/resolv/Makefile.inc 1.1 lib/libc/resolv/h_errno.c 1.1 lib/libc/resolv/herror.c 1.1.1.1, 1.2 lib/libc/resolv/mtctxres.c 1.1.1.1, 1.2 lib/libc/resolv/res_comp.c 1.1.1.1, 1.2 lib/libc/resolv/res_data.c 1.1.1.1, 1.2-1.3 lib/libc/resolv/res_debug.c 1.1.1.1, 1.2 lib/libc/resolv/res_debug.h 1.1.1.1 lib/libc/resolv/res_init.c 1.1.1.1, 1.2 lib/libc/resolv/res_mkquery.c 1.1.1.1, 1.2 lib/libc/resolv/res_private.h 1.1.1.1 lib/libc/resolv/res_query.c 1.1.1.1, 1.2-1.3 lib/libc/resolv/res_send.c 1.1.1.1, 1.2 lib/libc/resolv/res_state.c 1.1-1.2 Tested by: nork Revision Changes Path 1.244.2.4 +1 -1 src/include/Makefile 1.25.14.1 +33 -23 src/include/arpa/inet.h 1.16.14.1 +205 -73 src/include/arpa/nameser.h 1.4.14.1 +8 -1 src/include/arpa/nameser_compat.h 1.38.2.2 +29 -3 src/include/netdb.h 1.2.2.1 +79 -0 src/include/res_update.h (new) 1.26.2.2 +315 -148 src/include/resolv.h 1.56.2.1 +4 -0 src/lib/libc/Makefile 1.1.1.1.2.1 +203 -0 src/lib/libc/include/isc/eventlib.h (new) 1.2.2.1 +11 -0 src/lib/libc/include/port_after.h (new) 1.1.2.1 +22 -0 src/lib/libc/include/port_before.h (new) 1.1.1.1.2.1 +49 -0 src/lib/libc/include/resolv_mt.h (new) 1.2.2.1 +9 -0 src/lib/libc/inet/Makefile.inc (new) 1.2.2.1 +217 -0 src/lib/libc/inet/inet_addr.c (new) 1.1.1.1.2.1 +263 -0 src/lib/libc/inet/inet_cidr_ntop.c (new) 1.2.2.1 +277 -0 src/lib/libc/inet/inet_cidr_pton.c (new) 1.2.2.1 +72 -0 src/lib/libc/inet/inet_lnaof.c (new) 1.2.2.1 +75 -0 src/lib/libc/inet/inet_makeaddr.c (new) 1.2.2.1 +286 -0 src/lib/libc/inet/inet_net_ntop.c (new) 1.2.2.1 +414 -0 src/lib/libc/inet/inet_net_pton.c (new) 1.2.2.1 +96 -0 src/lib/libc/inet/inet_neta.c (new) 1.2.2.1 +71 -0 src/lib/libc/inet/inet_netof.c (new) 1.2.2.1 +113 -0 src/lib/libc/inet/inet_network.c (new) 1.2.2.1 +71 -0 src/lib/libc/inet/inet_ntoa.c (new) 1.2.2.1 +201 -0 src/lib/libc/inet/inet_ntop.c (new) 1.2.2.1 +223 -0 src/lib/libc/inet/inet_pton.c (new) 1.2.2.1 +120 -0 src/lib/libc/inet/nsap_addr.c (new) 1.1.2.1 +6 -0 src/lib/libc/isc/Makefile.inc (new) 1.2.2.1 +316 -0 src/lib/libc/isc/ev_streams.c (new) 1.2.2.1 +513 -0 src/lib/libc/isc/ev_timers.c (new) 1.2.2.1 +285 -0 src/lib/libc/isc/eventlib_p.h (new) 1.2.2.1 +6 -0 src/lib/libc/nameser/Makefile.inc (new) 1.1.1.1.2.1 +965 -0 src/lib/libc/nameser/ns_name.c (new) 1.1.1.1.2.1 +58 -0 src/lib/libc/nameser/ns_netint.c (new) 1.1.1.1.2.1 +211 -0 src/lib/libc/nameser/ns_parse.c (new) 1.2.2.1 +909 -0 src/lib/libc/nameser/ns_print.c (new) 1.3.2.1 +210 -0 src/lib/libc/nameser/ns_samedomain.c (new) 1.1.1.1.2.1 +162 -0 src/lib/libc/nameser/ns_ttl.c (new) 1.54.2.1 +10 -9 src/lib/libc/net/Makefile.inc 1.69.2.6 +134 -176 src/lib/libc/net/getaddrinfo.c 1.54.2.1 +187 -120 src/lib/libc/net/gethostbydns.c 1.23.2.1 +123 -49 src/lib/libc/net/gethostbyht.c 1.34.2.1 +2 -2 src/lib/libc/net/gethostbyname.3 1.25.2.1 +118 -58 src/lib/libc/net/gethostbynis.c 1.28.2.1 +227 -184 src/lib/libc/net/gethostnamadr.c 1.17.2.1 +7 -20 src/lib/libc/net/getnameinfo.c 1.31.2.1 +124 -56 src/lib/libc/net/getnetbydns.c 1.16.2.1 +100 -28 src/lib/libc/net/getnetbyht.c 1.19.2.1 +67 -22 src/lib/libc/net/getnetbynis.c 1.21.2.1 +90 -70 src/lib/libc/net/getnetnamadr.c 1.4.2.1 +20 -8 src/lib/libc/net/getproto.c 1.5.2.1 +82 -40 src/lib/libc/net/getprotoent.c 1.4.2.1 +22 -10 src/lib/libc/net/getprotoname.c 1.7.2.1 +23 -11 src/lib/libc/net/getservbyname.c 1.7.2.1 +22 -10 src/lib/libc/net/getservbyport.c 1.19.2.1 +92 -43 src/lib/libc/net/getservent.c 1.12.8.1 +0 -113 src/lib/libc/net/herror.c (dead) 1.16.14.1 +0 -200 src/lib/libc/net/inet_addr.c (dead) 1.5.14.1 +0 -68 src/lib/libc/net/inet_lnaof.c (dead) 1.4.14.1 +0 -71 src/lib/libc/net/inet_makeaddr.c (dead) 1.7.14.2 +0 -281 src/lib/libc/net/inet_net_ntop.c (dead) 1.9.10.2 +0 -410 src/lib/libc/net/inet_net_pton.c (dead) 1.9.12.1 +0 -92 src/lib/libc/net/inet_neta.c (dead) 1.5.14.1 +0 -67 src/lib/libc/net/inet_netof.c (dead) 1.9.14.1 +0 -100 src/lib/libc/net/inet_network.c (dead) 1.6.14.1 +0 -67 src/lib/libc/net/inet_ntoa.c (dead) 1.12.14.1 +0 -188 src/lib/libc/net/inet_ntop.c (dead) 1.11.14.2 +0 -219 src/lib/libc/net/inet_pton.c (dead) 1.54.2.2 +70 -67 src/lib/libc/net/name6.c 1.9.4.1 +56 -53 src/lib/libc/net/netdb_private.h 1.5.12.1 +0 -592 src/lib/libc/net/ns_name.c (dead) 1.3.14.1 +0 -53 src/lib/libc/net/ns_netint.c (dead) 1.4.14.1 +0 -189 src/lib/libc/net/ns_parse.c (dead) 1.3.14.1 +0 -742 src/lib/libc/net/ns_print.c (dead) 1.4.12.1 +0 -150 src/lib/libc/net/ns_ttl.c (dead) 1.9.14.1 +0 -113 src/lib/libc/net/nsap_addr.c (dead) 1.18.2.1 +0 -268 src/lib/libc/net/res_comp.c (dead) 1.8.14.1 +0 -4 src/lib/libc/net/res_config.h 1.8.14.1 +0 -82 src/lib/libc/net/res_data.c (dead) 1.21.12.1 +0 -992 src/lib/libc/net/res_debug.c (dead) 1.33.2.1 +0 -715 src/lib/libc/net/res_init.c (dead) 1.19.14.1 +0 -246 src/lib/libc/net/res_mkquery.c (dead) 1.6.2.1 +5 -9 src/lib/libc/net/res_mkupdate.c 1.30.2.4 +0 -491 src/lib/libc/net/res_query.c (dead) 1.50.2.1 +0 -941 src/lib/libc/net/res_send.c (dead) 1.1.8.1 +0 -82 src/lib/libc/net/res_send_private.h (dead) 1.7.14.1 +22 -20 src/lib/libc/net/res_update.c 1.3.2.1 +7 -0 src/lib/libc/resolv/Makefile.inc (new) 1.2.2.1 +49 -0 src/lib/libc/resolv/h_errno.c (new) 1.2.2.1 +128 -0 src/lib/libc/resolv/herror.c (new) 1.2.2.1 +140 -0 src/lib/libc/resolv/mtctxres.c (new) 1.2.2.1 +274 -0 src/lib/libc/resolv/res_comp.c (new) 1.3.2.1 +324 -0 src/lib/libc/resolv/res_data.c (new) 1.2.2.1 +1184 -0 src/lib/libc/resolv/res_debug.c (new) 1.1.1.1.2.1 +36 -0 src/lib/libc/resolv/res_debug.h (new) 1.2.2.1 +870 -0 src/lib/libc/resolv/res_init.c (new) 1.2.2.1 +260 -0 src/lib/libc/resolv/res_mkquery.c (new) 1.1.1.1.2.1 +22 -0 src/lib/libc/resolv/res_private.h (new) 1.3.2.1 +485 -0 src/lib/libc/resolv/res_query.c (new) 1.2.2.1 +1162 -0 src/lib/libc/resolv/res_send.c (new) 1.3.2.1 +96 -0 src/lib/libc/resolv/res_state.c (new) 1.244.2.14 +1 -1 src/sys/sys/param.h --Multipart_Mon_Jul_17_19:18:03_2006-1 Content-Type: text/plain; charset=US-ASCII -- Hajimu UMEMOTO @ Internet Mutual Aid Society Yokohama, Japan ume@mahoroba.org ume@{,jp.}FreeBSD.org http://www.imasy.org/~ume/ --Multipart_Mon_Jul_17_19:18:03_2006-1-- From owner-freebsd-stable@FreeBSD.ORG Mon Jul 17 13:11:01 2006 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 387B516A4E2 for ; Mon, 17 Jul 2006 13:11:01 +0000 (UTC) (envelope-from dom@helenmarks.co.uk) Received: from mail.goodforbusiness.co.uk (mail.goodforbusiness.co.uk [81.19.179.90]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5B87243D45 for ; Mon, 17 Jul 2006 13:11:00 +0000 (GMT) (envelope-from dom@helenmarks.co.uk) Received: from localhost (localhost [127.0.0.1]) by mail.goodforbusiness.co.uk (Postfix) with ESMTP id 4D73411462 for ; Mon, 17 Jul 2006 14:10:59 +0100 (BST) X-Virus-Scanned: mail.goodforbusiness.co.uk Received: from mail.goodforbusiness.co.uk ([127.0.0.1]) by localhost (mail.goodforbusiness.co.uk [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5MTj6SsQRzM6 for ; Mon, 17 Jul 2006 14:10:57 +0100 (BST) Received: from mail.helenmarks.co.uk (unknown [192.168.100.1]) by mail.goodforbusiness.co.uk (Postfix) with ESMTP id 610191141E for ; Mon, 17 Jul 2006 14:10:57 +0100 (BST) Received: from localhost (localhost [127.0.0.1]) by mail.helenmarks.co.uk (Postfix) with ESMTP id DF95F170E9; Mon, 17 Jul 2006 14:10:56 +0100 (BST) X-Virus-Scanned: amavisd-new at helenmarks.co.uk Received: from mail.helenmarks.co.uk ([127.0.0.1]) by localhost (mail.helenmarks.co.uk [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9DeEP9VrALig; Mon, 17 Jul 2006 14:10:53 +0100 (BST) Received: by mail.helenmarks.co.uk (Postfix, from userid 80) id 10B5C1704B; Mon, 17 Jul 2006 14:10:53 +0100 (BST) Received: from mailhost.graphdata.co.uk ([195.12.22.194]) (SquirrelMail authenticated user dom) by mail.helenmarks.co.uk with HTTP; Mon, 17 Jul 2006 14:10:53 +0100 (BST) Message-ID: <1968.195.12.22.194.1153141853.squirrel@mail.helenmarks.co.uk> Date: Mon, 17 Jul 2006 14:10:53 +0100 (BST) From: "Dominic Marks" To: freebsd-stable@freebsd.org User-Agent: SquirrelMail/1.4.6 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-15 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Subject: Two panics on recent 6.1-STABLE X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Jul 2006 13:11:01 -0000 Two panics, I've just had: I had just installed a fresh world+kernel, booted and then received the first panic. Then reset, booted again and shortly received the second (although they look identical to me). At the moment everything seems fine, sending this message from the machine in question. Rough description of the PC's life: Gnome Desktop connected using nsswitch/winbind to Active Directory. Low load. I can make the dumps available, but at a guess I'd say they don't look very helpful. I'll recompile with debugging options enabled and see if I can get some other info. If I do, I'll follow-up with it here. Thanks, Dominic FreeBSD gdc083.internal.graphdata.co.uk 6.1-STABLE FreeBSD 6.1-STABLE #0: Mon Jul 17 12:43:52 BST 2006 dominicm@gdc083.internal.graphdata.co.uk:/usr/obj/usr/src/sys/GDC083 i386 panic #1: Fatal trap 12: page fault while in kernel mode fault virtual address = 0xfefefe14 fault code = supervisor read, page not present instruction pointer = 0x20:0xc06a031b stack pointer = 0x28:0xe7383c88 frame pointer = 0x28:0xe7383ca0 code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 827 (csh) trap number = 12 panic: page fault Uptime: 3m47s Dumping 1022 MB (2 chunks) chunk 0: 1MB (160 pages) ... ok chunk 1: 1022MB (261516 pages) 1006 990 974 958 942 926 (CTRL-C to abort) 910 894 878 (CTRL-C to abort) 862 846 830 814 798 782 766 750 734 718 702 686 670 654 638 622 606 590 574 558 542 526 510 494 478 462 446 430 414 398 382 366 350 334 318 302 286 270 254 238 222 206 190 174 158 142 126 110 94 78 62 46 30 14 #0 doadump () at pcpu.h:165 165 pcpu.h: No such file or directory. in pcpu.h (kgdb) bt #0 doadump () at pcpu.h:165 #1 0xc06a8f7a in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:409 #2 0xc06a9284 in panic (fmt=0xc0925487 "%s") at /usr/src/sys/kern/kern_shutdown.c:565 #3 0xc08d142d in trap_fatal (frame=0xe7383c48, eva=0) at /usr/src/sys/i386/i386/trap.c:836 #4 0xc08d114d in trap_pfault (frame=0xe7383c48, usermode=0, eva=4278124052) at /usr/src/sys/i386/i386/trap.c:744 #5 0xc08d0d37 in trap (frame= {tf_fs = 8, tf_es = -1056702424, tf_ds = -1056702424, tf_edi = -415744764, tf_esi = -986172392, tf_ebp = -415744864, tf_isp = -415744908, tf_ebx = -16843264, tf_edx = 827, tf_ecx = 827, tf_eax = 4, tf_trapno = 12, tf_err = 0, tf_eip = -1066794213, tf_cs = 32, tf_eflags = 66182, tf_esp = 64, tf_ss = 2}) at /usr/src/sys/i386/i386/trap.c:434 #6 0xc08bee9a in calltrap () at /usr/src/sys/i386/i386/exception.s:139 #7 0xc06a031b in pgfind (pgid=827) at /usr/src/sys/kern/kern_proc.c:257 #8 0xc06a3567 in setpgid (td=0xc520cd80, uap=0xe7383d04) at /usr/src/sys/kern/kern_prot.c:436 #9 0xc08d17e3 in syscall (frame= {tf_fs = 59, tf_es = 59, tf_ds = -1078001605, tf_edi = 2, tf_esi = 827, tf_ebp = -1077995432, tf_isp = -415744668, tf_ebx = 783, tf_edx = -1077995488, tf_ecx = 2, tf_eax = 82, tf_trapno = 22, tf_err = 2, tf_eip = 672532403, tf_cs = 51, tf_eflags = 518, tf_esp = -1077995460, tf_ss = 59}) at /usr/src/sys/i386/i386/trap.c:981 #10 0xc08beeef in Xint0x80_syscall () at /usr/src/sys/i386/i386/exception.s:200 #11 0x00000033 in ?? () Previous frame inner to this frame (corrupt stack?) panic #2 Fatal trap 12: page fault while in kernel mode fault virtual address = 0xfefefe14 fault code = supervisor read, page not present instruction pointer = 0x20:0xc06a031b stack pointer = 0x28:0xe739ec88 frame pointer = 0x28:0xe739eca0 code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 827 (csh) trap number = 12 panic: page fault Uptime: 5m56s Dumping 1022 MB (2 chunks) chunk 0: 1MB (160 pages) ... ok chunk 1: 1022MB (261516 pages) 1006 990 974 958 (CTRL-C to abort) 942 926 910 894 878 862 846 830 814 798 782 766 750 734 718 702 686 670 654 638 622 606 590 574 558 542 526 510 494 478 462 446 430 414 398 382 366 350 334 318 302 286 270 254 238 222 206 190 174 158 142 126 110 94 78 62 46 30 14 #0 doadump () at pcpu.h:165 165 pcpu.h: No such file or directory. in pcpu.h (kgdb) bt #0 doadump () at pcpu.h:165 #1 0xc06a8f7a in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:409 #2 0xc06a9284 in panic (fmt=0xc0925487 "%s") at /usr/src/sys/kern/kern_shutdown.c:565 #3 0xc08d142d in trap_fatal (frame=0xe739ec48, eva=0) at /usr/src/sys/i386/i386/trap.c:836 #4 0xc08d114d in trap_pfault (frame=0xe739ec48, usermode=0, eva=4278124052) at /usr/src/sys/i386/i386/trap.c:744 #5 0xc08d0d37 in trap (frame= {tf_fs = 8, tf_es = -1056702424, tf_ds = -1056702424, tf_edi = -415634172, tf_esi = -981162460, tf_ebp = -415634272, tf_isp = -415634316, tf_ebx = -16843264, tf_edx = 827, tf_ecx = 827, tf_eax = 4, tf_trapno = 12, tf_err = 0, tf_eip = -1066794213, tf_cs = 32, tf_eflags = 66182, tf_esp = 64, tf_ss = 2}) at /usr/src/sys/i386/i386/trap.c:434 #6 0xc08bee9a in calltrap () at /usr/src/sys/i386/i386/exception.s:139 #7 0xc06a031b in pgfind (pgid=827) at /usr/src/sys/kern/kern_proc.c:257 #8 0xc06a3567 in setpgid (td=0xc52ebc00, uap=0xe739ed04) at /usr/src/sys/kern/kern_prot.c:436 #9 0xc08d17e3 in syscall (frame= {tf_fs = 59, tf_es = 59, tf_ds = 59, tf_edi = 2, tf_esi = 827, tf_ebp = -1077995432, tf_isp = -415634076, tf_ebx = 773, tf_edx = -1077995488, tf_ecx = 2, tf_eax = 82, tf_trapno = 22, tf_err = 2, tf_eip = 672532403, tf_cs = 51, tf_eflags = 518, tf_esp = -1077995460, tf_ss = 59}) at /usr/src/sys/i386/i386/trap.c:981 #10 0xc08beeef in Xint0x80_syscall () at /usr/src/sys/i386/i386/exception.s:200 #11 0x00000033 in ?? () Previous frame inner to this frame (corrupt stack?) dmesg: Copyright (c) 1992-2006 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 6.1-STABLE #0: Mon Jul 17 12:43:52 BST 2006 dominicm@gdc083.internal.graphdata.co.uk:/usr/obj/usr/src/sys/GDC083 Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: Intel(R) Xeon(TM) CPU 3.00GHz (2992.52-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0xf4a Stepping = 10 Features=0xbfebfbff Features2=0x641d> AMD Features=0x20100000 AMD Features2=0x1 Logical CPUs per core: 2 real memory = 1072218112 (1022 MB) avail memory = 1040334848 (992 MB) MPTable: ioapic0: Changing APIC ID to 8 ioapic0: Assuming intbase of 0 ioapic1: Changing APIC ID to 9 ioapic1: Assuming intbase of 24 ioapic2: Changing APIC ID to 10 ioapic2: Assuming intbase of 48 ioapic0 irqs 0-23 on motherboard ioapic1 irqs 24-47 on motherboard ioapic2 irqs 48-71 on motherboard kbd1 at kbdmux0 ath_hal: 0.9.17.2 (AR5210, AR5211, AR5212, RF5111, RF5112, RF2413, RF5413) cpu0 on motherboard pcib0: pcibus 0 on motherboard pci0: on pcib0 pcib0: unable to route slot 2 INTA pcib0: unable to route slot 3 INTA pcib0: unable to route slot 4 INTA pci0: at device 0.1 (no driver attached) pcib1: irq 11 at device 2.0 on pci0 pci1: on pcib1 pcib2: at device 0.0 on pci1 pci2: on pcib2 pci2: at device 12.0 (no driver attached) pcib3: at device 0.2 on pci1 pci3: on pcib3 twe0: <3ware Storage Controller. Driver version 1.50.01.002> port 0xccb0-0xccbf mem 0xdd800000-0xddffffff irq 49 at device 13.0 on pci3 twe0: [GIANT-LOCKED] twe0: 2 ports, Firmware FE8S 1.05.00.068, BIOS BE7X 1.08.00.048 em0: port 0xccc0-0xccff mem 0xdd6e0000-0xdd6fffff irq 48 at device 14.0 on pci3 em0: Ethernet address: 00:13:72:8b:3c:a9 pcib4: irq 11 at device 3.0 on pci0 pci4: on pcib4 pcib5: irq 11 at device 4.0 on pci0 pci5: on pcib5 uhci0: port 0xff80-0xff9f irq 16 at device 29.0 on pci0 uhci0: [GIANT-LOCKED] usb0: on uhci0 usb0: USB revision 1.0 uhub0: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub0: 2 ports with 2 removable, self powered uhci1: port 0xff60-0xff7f irq 19 at device 29.1 on pci0 uhci1: [GIANT-LOCKED] usb1: on uhci1 usb1: USB revision 1.0 uhub1: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub1: 2 ports with 2 removable, self powered uhci2: port 0xff40-0xff5f irq 18 at device 29.2 on pci0 uhci2: [GIANT-LOCKED] usb2: on uhci2 usb2: USB revision 1.0 uhub2: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub2: 2 ports with 2 removable, self powered uhci3: port 0xff20-0xff3f irq 16 at device 29.3 on pci0 uhci3: [GIANT-LOCKED] usb3: on uhci3 usb3: USB revision 1.0 uhub3: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub3: 2 ports with 2 removable, self powered ehci0: mem 0xffa80800-0xffa80bff irq 23 at device 29.7 on pci0 ehci0: [GIANT-LOCKED] usb4: waiting for BIOS to give up control usb4: EHCI version 1.0 usb4: companion controllers, 2 ports each: usb0 usb1 usb2 usb3 usb4: on ehci0 usb4: USB revision 2.0 uhub4: Intel EHCI root hub, class 9/0, rev 2.00/1.00, addr 1 uhub4: 8 ports with 8 removable, self powered umass0: FREECOM. ATAPI-6 Bridge Controller, rev 2.00/0.00, addr 2 umass1: Freecom Classic Mobile 2.5' Hard Disk, rev 2.00/0.33, addr 3 pcib6: at device 30.0 on pci0 pci6: on pcib6 isab0: at device 31.0 on pci0 isa0: on isab0 atapci0: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xffa0-0xffaf mem 0xdffffc00-0xdfffffff irq 18 at device 31.1 on pci0 ata0: on atapci0 ata1: on atapci0 atapci1: port 0xfe00-0xfe07,0xfe10-0xfe13,0xfe20-0xfe27,0xfe30-0xfe33,0xfea0-0xfeaf irq 18 at device 31.2 on pci0 ata2: on atapci1 ata3: on atapci1 pci0: at device 31.3 (no driver attached) pmtimer0 on isa0 orm0: at iomem 0xc0000-0xc7fff,0xc8000-0xc87ff,0xc8800-0xc9fff,0xca000-0xcbfff on isa0 atkbdc0: at port 0x60,0x64 on isa0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] psm0: irq 12 on atkbdc0 psm0: [GIANT-LOCKED] psm0: model Generic PS/2 mouse, device ID 0 ppc0: at port 0x378-0x37f irq 7 on isa0 ppc0: SMC-like chipset (ECP/EPP/PS2/NIBBLE) in COMPATIBLE mode ppc0: FIFO with 16/16/8 bytes threshold ppbus0: on ppc0 plip0: on ppbus0 lpt0: on ppbus0 lpt0: Interrupt-driven port ppi0: on ppbus0 sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> sio0: configured irq 4 not in bitmap of probed irqs 0 sio0: port may not be enabled sio0 at port 0x3f8-0x3ff irq 4 flags 0x10 on isa0 sio0: type 16550A sio1: configured irq 3 not in bitmap of probed irqs 0 sio1: port may not be enabled sio1 at port 0x2f8-0x2ff irq 3 on isa0 sio1: type 16550A vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 unknown: can't assign resources (memory) unknown: can't assign resources (port) unknown: can't assign resources (port) unknown: can't assign resources (port) unknown: can't assign resources (port) ukbd0: Dell Dell USB Keyboard, rev 1.10/2.00, addr 2, iclass 3/1 kbd2 at ukbd0 ums0: Microsoft Microsoft 5-Button Mouse with IntelliEye(TM), rev 1.10/3.00, addr 3, iclass 3/1 ums0: 5 buttons and Z dir. Timecounter "TSC" frequency 2992517370 Hz quality 800 Timecounters tick every 1.000 msec acd0: CDROM at ata1-master UDMA33 ad4: 76293MB at ata2-master SATA150 da1 at umass-sim1 bus 1 target 0 lun 0 da1: Fixed Direct Access SCSI-0 device da1: 40.000MB/s transfers da1: 28615MB (58605120 512 byte sectors: 255H 63S/T 3648C) da0 at umass-sim0 bus 0 target 0 lun 0 da0: Fixed Direct Access SCSI-0 device da0: 40.000MB/s transfers da0: 38154MB (78140160 512 byte sectors: 255H 63S/T 4864C) Trying to mount root from ufs:/dev/ad4s1a WARNING: / was not properly dismounted WARNING: /usr was not properly dismounted /usr: mount pending error: blocks 24 files 1 WARNING: /var was not properly dismounted From owner-freebsd-stable@FreeBSD.ORG Mon Jul 17 13:30:52 2006 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id AC16016A4E2; Mon, 17 Jul 2006 13:30:52 +0000 (UTC) (envelope-from GMcCaughan@synaptics-uk.com) Received: from mx2.synaptics-uk.com (mx2.synaptics-uk.com [194.203.111.209]) by mx1.FreeBSD.org (Postfix) with ESMTP id CDB9143D5C; Mon, 17 Jul 2006 13:30:51 +0000 (GMT) (envelope-from GMcCaughan@synaptics-uk.com) Received: from firewall.synaptics-uk.com ([194.203.111.212] helo=ukexchange2k.synaptics-inc.local) by mx2.synaptics-uk.com with esmtp (Exim 4.20) id 1G2Te0-0006Sh-PG; Mon, 17 Jul 2006 15:00:20 +0100 Received: from lists.synaptics-uk.com ([172.20.11.6]) by ukexchange2k.synaptics-inc.local with Microsoft SMTPSVC(5.0.2195.6713); Mon, 17 Jul 2006 14:30:28 +0100 Received: from [172.20.11.5] (unknown [172.20.11.5]) by lists.synaptics-uk.com (Postfix) with ESMTP id 0100B17030; Mon, 17 Jul 2006 14:10:56 +0100 (BST) From: Gareth McCaughan To: freebsd-questions@freebsd.org, freebsd-stable@freebsd.org Date: Mon, 17 Jul 2006 14:30:27 +0100 User-Agent: KMail/1.9.1 References: <200607132002.43637.gmccaughan@synaptics-uk.com> In-Reply-To: <200607132002.43637.gmccaughan@synaptics-uk.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200607171430.27752.gmccaughan@synaptics-uk.com> X-OriginalArrivalTime: 17 Jul 2006 13:30:28.0527 (UTC) FILETIME=[2B265BF0:01C6A9A5] Cc: Subject: Re: "swiN: clock sio" process taking 75% CPU X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Jul 2006 13:30:52 -0000 I wrote: > About 6 minutes after booting (on two occasions; I don't > guarantee that this doesn't vary), a process that appears > in the output of "ps" as "[swi4: clock sio]" begins to > use about 3/4 of the machine's CPU. I think it does so > more or less instantaneously. It continues to do so > indefinitely, so far as I can tell. [etc] No ideas? I'm willing to help track this down, and the machine in question is sufficiently little used that I can do so without gross inconvenience; but I don't have enough FreeBSD kernel expertise to feel like diving in blind. * A little more information, in case it's useful to anyone: | $ echo; sysctl debug | egrep to_ | debug.to_avg_mpcalls: 2890 | debug.to_avg_mtxcalls: 0 | debug.to_avg_gcalls: 768 | debug.to_avg_depth: 3815 That's with HZ = 100. Here are some numbers from a message in freebsd-ia64, from Marcel Moolenaar, in 2004-07, to someone seeing symptoms like mine. They're meant to be typical healthy numbers. Mine above look somewhat worse, but not insanely so; surely not enough to explain the difference between using 0.3% cpu and using 75%. Marcel also had HZ=100. | % sysctl debug | grep to_avg | debug.to_avg_depth: 2500 | debug.to_avg_gcalls: 1003 | debug.to_avg_mpcalls: 1255 * It would be a shame if the only conclusion to be drawn from this were "sometimes a machine running FreeBSD is just 4x slower than it should be, and no one knows why". -- g From owner-freebsd-stable@FreeBSD.ORG Mon Jul 17 14:51:47 2006 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id ADB1416A4E6 for ; Mon, 17 Jul 2006 14:51:47 +0000 (UTC) (envelope-from mike@sentex.net) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.FreeBSD.org (Postfix) with ESMTP id 44DDB43D5A for ; Mon, 17 Jul 2006 14:51:27 +0000 (GMT) (envelope-from mike@sentex.net) Received: from lava.sentex.ca (pyroxene.sentex.ca [199.212.134.18]) by smarthost1.sentex.ca (8.13.6/8.13.6) with ESMTP id k6HEp88L071450; Mon, 17 Jul 2006 10:51:08 -0400 (EDT) (envelope-from mike@sentex.net) Received: from simian.sentex.net (simeon.sentex.ca [192.168.43.27]) by lava.sentex.ca (8.13.3P/8.13.3) with ESMTP id k6HEpK0D005696 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 17 Jul 2006 10:51:20 -0400 (EDT) (envelope-from mike@sentex.net) Message-Id: <6.2.3.4.0.20060717104757.051cc068@64.7.153.2> X-Mailer: QUALCOMM Windows Eudora Version 6.2.3.4 Date: Mon, 17 Jul 2006 10:51:50 -0400 To: Johan =?iso-8859-1?Q?Str=F6m?= , freebsd-stable@freebsd.org From: Mike Tancsa In-Reply-To: <4AD53F0E-4CDA-4D20-82A4-A248FC541184@stromnet.org> References: <8D08DDB6-6AC1-45B6-B2CE-08782F54968A@stromnet.org> <884C01BC-3E97-46EC-AA8B-E70C3931F3A4@stromnet.org> <36895211-2796-4213-B336-6279AB3AC3CB@stromnet.org> <20060713132357.Y61840@fledge.watson.org> <44B7EA39.4060509@quip.cz> <6.2.3.4.0.20060716185019.12a29240@64.7.153.2> <4AD53F0E-4CDA-4D20-82A4-A248FC541184@stromnet.org> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: quoted-printable X-Virus-Scanned: ClamAV version 0.88.3, clamav-milter version 0.88.3 on clamscanner1 X-Virus-Status: Clean Cc: Subject: Re: ATA problems again ... X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Jul 2006 14:51:47 -0000 At 05:59 AM 17/07/2006, Johan Str=F6m wrote: >On 17 jul 2006, at 00.53, Mike Tancsa wrote: > >>At 03:02 PM 14/07/2006, Miroslav Lachman wrote: >> >> >>>After reboot (command reboot), system boot up with both disks >>>attached and start autosynchronization. I do not know, if this is >>>hw or sw error, I got >> >>Install the smartmontools from >> >>/usr/ports/sysutils/smartmontools/ >> >>and post the output of >>smartctl -a /dev/ad8 > >I tried this on my SATA disk ad6: >=3D=3D=3D START OF INFORMATION SECTION =3D=3D=3D >Model Family: Maxtor MaXLine III family >Device Model: Maxtor 7L300S0 >Serial Number: L60CJKPH >Firmware Version: BANC1G10 >User Capacity: 300,090,728,448 bytes >Device is: In smartctl database [for details use: -P show] >ATA Version is: 7 >ATA Standard is: ATA/ATAPI-7 T13 1532D revision 0 >Local Time is: Mon Jul 17 11:54:35 2006 CEST >SMART support is: Available - device has SMART capability. >SMART support is: Enabled >.... >SMART Error Log Version: 1 >No Errors Logged > >Any other output from smartctl that can help? Both my ad4 and ad6 are >the same. This at least rules out the disks being bad for=20 the most part. It still could be bad cables, but=20 if you changed those out than its=20 doubtful. Perhaps try updating to RELENG_6 ? If=20 its a gmirror issue, I think there have been a number of fixes. ---Mike=20 From owner-freebsd-stable@FreeBSD.ORG Mon Jul 17 15:02:01 2006 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8719D16A5AD for ; Mon, 17 Jul 2006 15:02:01 +0000 (UTC) (envelope-from johan@stromnet.org) Received: from pne-smtpout2-sn1.fre.skanova.net (pne-smtpout2-sn1.fre.skanova.net [81.228.11.159]) by mx1.FreeBSD.org (Postfix) with ESMTP id DC61743D73 for ; Mon, 17 Jul 2006 15:01:51 +0000 (GMT) (envelope-from johan@stromnet.org) Received: from elfi.stromnet.org (213.67.205.103) by pne-smtpout2-sn1.fre.skanova.net (7.2.075) id 44A135F100400C71; Mon, 17 Jul 2006 17:01:50 +0200 Received: from localhost (localhost [127.0.0.1]) by elfi.stromnet.org (Postfix) with ESMTP id DA63F61D72; Mon, 17 Jul 2006 17:01:49 +0200 (CEST) X-Virus-Scanned: amavisd-new at stromnet.org Received: from elfi.stromnet.org ([127.0.0.1]) by localhost (elfi.stromnet.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ldHi5zzDaG35; Mon, 17 Jul 2006 17:01:48 +0200 (CEST) Received: from [IPv6:2001:16d8:ff20:2:211:24ff:fea2:8e01] (unknown [IPv6:2001:16d8:ff20:2:211:24ff:fea2:8e01]) by elfi.stromnet.org (Postfix) with ESMTP id A9B8261D74; Mon, 17 Jul 2006 17:01:48 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v750) In-Reply-To: <6.2.3.4.0.20060717104757.051cc068@64.7.153.2> References: <8D08DDB6-6AC1-45B6-B2CE-08782F54968A@stromnet.org> <884C01BC-3E97-46EC-AA8B-E70C3931F3A4@stromnet.org> <36895211-2796-4213-B336-6279AB3AC3CB@stromnet.org> <20060713132357.Y61840@fledge.watson.org> <44B7EA39.4060509@quip.cz> <6.2.3.4.0.20060716185019.12a29240@64.7.153.2> <4AD53F0E-4CDA-4D20-82A4-A248FC541184@stromnet.org> <6.2.3.4.0.20060717104757.051cc068@64.7.153.2> Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed Message-Id: <898F22AA-A745-4798-9D8C-7472C5CDB012@stromnet.org> Content-Transfer-Encoding: quoted-printable From: =?ISO-8859-1?Q?Johan_Str=F6m?= Date: Mon, 17 Jul 2006 17:02:14 +0200 To: Mike Tancsa , freebsd-stable@freebsd.org X-Mailer: Apple Mail (2.750) Cc: Subject: Re: ATA problems again ... X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Jul 2006 15:02:01 -0000 On 17 jul 2006, at 16.51, Mike Tancsa wrote: > At 05:59 AM 17/07/2006, Johan Str=F6m wrote: > >> On 17 jul 2006, at 00.53, Mike Tancsa wrote: >> >>> At 03:02 PM 14/07/2006, Miroslav Lachman wrote: >>> >>> >>>> After reboot (command reboot), system boot up with both disks >>>> attached and start autosynchronization. I do not know, if this is >>>> hw or sw error, I got >>> >>> Install the smartmontools from >>> >>> /usr/ports/sysutils/smartmontools/ >>> >>> and post the output of >>> smartctl -a /dev/ad8 >> >> I tried this on my SATA disk ad6: >> =3D=3D=3D START OF INFORMATION SECTION =3D=3D=3D >> Model Family: Maxtor MaXLine III family >> Device Model: Maxtor 7L300S0 >> Serial Number: L60CJKPH >> Firmware Version: BANC1G10 >> User Capacity: 300,090,728,448 bytes >> Device is: In smartctl database [for details use: -P show] >> ATA Version is: 7 >> ATA Standard is: ATA/ATAPI-7 T13 1532D revision 0 >> Local Time is: Mon Jul 17 11:54:35 2006 CEST >> SMART support is: Available - device has SMART capability. >> SMART support is: Enabled >> .... >> SMART Error Log Version: 1 >> No Errors Logged >> >> Any other output from smartctl that can help? Both my ad4 and ad6 are >> the same. > > This at least rules out the disks being bad for the most part. It =20 > still could be bad cables, but if you changed those out than its =20 > doubtful. Perhaps try updating to RELENG_6 ? If its a gmirror =20 > issue, I think there have been a number of fixes. Just ran PowerMax (maxtors own testing software) full length test on =20 ad6, not a single problem.. Same result as on ad4 a couple of days =20 ago.. So no, i doubt it's the disks. I've changed the other SATA =20 cable too now (the one one ad6), this was a fresh one never used =20 before. I'll change ad4 too when i take it down for reboot. I'm currently running RELENG_6_1, however from may 9th. Have there =20 been any ata/gmirror changes merged to 6_1 since then? If I run RELENG_6 instead, how big is the change any other problems =20 might arise? ;) I've never used anything other than "stable".. Thanks Johan= From owner-freebsd-stable@FreeBSD.ORG Mon Jul 17 15:12:58 2006 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E95CD16A4DA; Mon, 17 Jul 2006 15:12:58 +0000 (UTC) (envelope-from mike@sentex.net) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4AE1343D45; Mon, 17 Jul 2006 15:12:58 +0000 (GMT) (envelope-from mike@sentex.net) Received: from lava.sentex.ca (pyroxene.sentex.ca [199.212.134.18]) by smarthost1.sentex.ca (8.13.6/8.13.6) with ESMTP id k6HFCiWP074650; Mon, 17 Jul 2006 11:12:44 -0400 (EDT) (envelope-from mike@sentex.net) Received: from simian.sentex.net (simeon.sentex.ca [192.168.43.27]) by lava.sentex.ca (8.13.3P/8.13.3) with ESMTP id k6HFCv8D005786 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 17 Jul 2006 11:12:57 -0400 (EDT) (envelope-from mike@sentex.net) Message-Id: <6.2.3.4.0.20060717110923.05336e10@64.7.153.2> X-Mailer: QUALCOMM Windows Eudora Version 6.2.3.4 Date: Mon, 17 Jul 2006 11:13:27 -0400 To: Johan =?iso-8859-1?Q?Str=F6m?= , freebsd-stable@freebsd.org From: Mike Tancsa In-Reply-To: <898F22AA-A745-4798-9D8C-7472C5CDB012@stromnet.org> References: <8D08DDB6-6AC1-45B6-B2CE-08782F54968A@stromnet.org> <884C01BC-3E97-46EC-AA8B-E70C3931F3A4@stromnet.org> <36895211-2796-4213-B336-6279AB3AC3CB@stromnet.org> <20060713132357.Y61840@fledge.watson.org> <44B7EA39.4060509@quip.cz> <6.2.3.4.0.20060716185019.12a29240@64.7.153.2> <4AD53F0E-4CDA-4D20-82A4-A248FC541184@stromnet.org> <6.2.3.4.0.20060717104757.051cc068@64.7.153.2> <898F22AA-A745-4798-9D8C-7472C5CDB012@stromnet.org> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: quoted-printable X-Virus-Scanned: ClamAV version 0.88.3, clamav-milter version 0.88.3 on clamscanner3 X-Virus-Status: Clean Cc: Subject: Re: ATA problems again ... X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Jul 2006 15:12:59 -0000 At 11:02 AM 17/07/2006, Johan Str=F6m wrote: >On 17 jul 2006, at 16.51, Mike Tancsa wrote: >> >>This at least rules out the disks being bad for the most part. It >>still could be bad cables, but if you changed those out than its >>doubtful. Perhaps try updating to RELENG_6 ? If its a gmirror >>issue, I think there have been a number of fixes. > >Just ran PowerMax (maxtors own testing software) full length test on >ad6, not a single problem.. Same result as on ad4 a couple of days >ago.. So no, i doubt it's the disks. I've changed the other SATA >cable too now (the one one ad6), this was a fresh one never used >before. I'll change ad4 too when i take it down for reboot. > >I'm currently running RELENG_6_1, however from may 9th. Have there >been any ata/gmirror changes merged to 6_1 since then? >If I run RELENG_6 instead, how big is the change any other problems >might arise? ;) I've never used anything other than "stable".. RELENG_6 is pretty stable for me. I see a few=20 commits and bug fixes to the tree specifically=20 for gmirror=20 (http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/geom/mirror/).=20 No idea if it will fix your problem or not. It=20 might be its a result of some other bug. But I=20 would try there unless someone has a better suggestion. ---Mike=20 From owner-freebsd-stable@FreeBSD.ORG Mon Jul 17 15:40:20 2006 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5A2B216A4E1 for ; Mon, 17 Jul 2006 15:40:20 +0000 (UTC) (envelope-from 000.fbsd@quip.cz) Received: from retezat.tovarna.cz (retezat.tovarna.cz [88.86.106.27]) by mx1.FreeBSD.org (Postfix) with ESMTP id C5A2443D4C for ; Mon, 17 Jul 2006 15:40:19 +0000 (GMT) (envelope-from 000.fbsd@quip.cz) Received: from localhost (localhost.tovarna.cz [127.0.0.1]) by retezat.tovarna.cz (Postfix) with ESMTP id 9D3E7F1F40; Mon, 17 Jul 2006 17:38:17 +0200 (CEST) Received: from [192.168.1.2] (unknown [85.132.172.19]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by retezat.tovarna.cz (Postfix) with ESMTP id A205AF1ED6; Mon, 17 Jul 2006 17:38:14 +0200 (CEST) Message-ID: <44BBAF52.9080007@quip.cz> Date: Mon, 17 Jul 2006 17:40:02 +0200 From: Miroslav Lachman <000.fbsd@quip.cz> User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: cs, cz, en, en-us MIME-Version: 1.0 To: freebsd-stable@freebsd.org References: <8D08DDB6-6AC1-45B6-B2CE-08782F54968A@stromnet.org> <884C01BC-3E97-46EC-AA8B-E70C3931F3A4@stromnet.org> <36895211-2796-4213-B336-6279AB3AC3CB@stromnet.org> <20060713132357.Y61840@fledge.watson.org> <44B7EA39.4060509@quip.cz> <6.2.3.4.0.20060716185019.12a29240@64.7.153.2> In-Reply-To: <6.2.3.4.0.20060716185019.12a29240@64.7.153.2> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: Subject: Re: ATA problems again ... X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Jul 2006 15:40:20 -0000 Mike Tancsa wrote: [..] > Install the smartmontools from > > /usr/ports/sysutils/smartmontools/ > > and post the output of > smartctl -a /dev/ad8 smartmontools was previously installed and running as daemon without any bad reports. I can not run "smartctl -a /dev/ad8" now, because my server housing provider replaced HDD with the new one and after an hour of synchronization "ad8: FAILURE - device detached". So provider replaced whole server, only ad4 is original piece of HW. On new server synchronization was much faster then in previous server (1:30 hour compared to 5 hours in previous server) - so I think it was HW problem. Now I am running stresstest with copying /usr/ports to another partition in infinite loop. I will post results later. (On bad server, test failed after about 30 minutes. On another server the test is running fine second day, so I think if disk will not fail after 1 day, problem is solved) At last - now I think this was not GEOM/gmirror related. I tried remove ad8 provider from gmirror (gm0), boot up system from gm0 with one provider (ad4) and test ad8 mounted separately - ad8 failed again. Miroslav Lachman From owner-freebsd-stable@FreeBSD.ORG Mon Jul 17 18:17:27 2006 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 17F8516A4DE for ; Mon, 17 Jul 2006 18:17:27 +0000 (UTC) (envelope-from vsemionov@gmail.com) Received: from ug-out-1314.google.com (ug-out-1314.google.com [66.249.92.175]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6A4BF43D46 for ; Mon, 17 Jul 2006 18:17:26 +0000 (GMT) (envelope-from vsemionov@gmail.com) Received: by ug-out-1314.google.com with SMTP id m2so989499uge for ; Mon, 17 Jul 2006 11:17:25 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:from:to:subject:date:user-agent:mime-version:content-type:content-transfer-encoding:content-disposition:message-id; b=G+CdeFEyODD0fr/tjVOhNe0OZSy/WOTn5ygSPef3QINtxGZf+rSCbNniciHdGvunXBYA/M59stnvngm5t/dwanIMKhexrUBKePci1dl3tlO4EgdNHhlBAk5cuSlGkVZFwXAReUWILvqDGHNACUGlT2AEuovtGQzjj+qEwOG2C0U= Received: by 10.66.221.19 with SMTP id t19mr2771666ugg; Mon, 17 Jul 2006 11:10:11 -0700 (PDT) Received: from neon.devian.bg ( [83.148.125.201]) by mx.gmail.com with ESMTP id w40sm537760ugc.2006.07.17.11.10.11; Mon, 17 Jul 2006 11:10:11 -0700 (PDT) From: Victor Semionov To: freebsd-stable@freebsd.org Date: Mon, 17 Jul 2006 21:11:08 +0300 User-Agent: KMail/1.9.3 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200607172111.08919.vsemionov@gmail.com> Subject: ath driver transmits frames only after a low watermark is filled X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Jul 2006 18:17:27 -0000 Hello list, I have a wireless card with an Atheros 5212 chipset and I'm experiencing the following behavior under FreeBSD 6.1: TCP connections that consist of small short bursts of one-way (transmission) traffic often stall until traffic is received over another TCP connection. For example, if I try to load a small web page, located on the FreeBSD box, over the wireless link, it doesn't load completely, unless I hit return in a concurrent terminal session, or until I request some other file hosted on the FreeBSD box, or until I wait 20 seconds or so. The signal is not low, the two wireless boxes are in the same room. Higher-bandwidth connections rarely stall. This makes me think there is some kind of low watermark functionality in the hardware/driver that doesn't send frames until a certain number of them have been queued for transmission, or until a frame has been received. Also, I guess this is the reason that the ath module caused the system to freeze at shutdown or when the module is unloaded, unless I do an "ifconfig ath0 down" before unloading - the unloading code is probably waiting for all queued frames to be transmitted, but that never happens. Sorry for the weak conclusion that is based on assumptions. I'm not familiar with the OS/driver internals and don't know how to investigate further. Is there a sysctl or other setting that controls this behavior, or some other workaround? Any help would be greatly appreciated. Best regards, Victor Semionov From owner-freebsd-stable@FreeBSD.ORG Mon Jul 17 22:22:40 2006 Return-Path: X-Original-To: stable@FreeBSD.org Delivered-To: freebsd-stable@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2DA2716A4E5 for ; Mon, 17 Jul 2006 22:22:40 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from mail2.fluidhosting.com (mx21.fluidhosting.com [204.14.89.4]) by mx1.FreeBSD.org (Postfix) with SMTP id A909B43D62 for ; Mon, 17 Jul 2006 22:22:37 +0000 (GMT) (envelope-from dougb@FreeBSD.org) Received: (qmail 18660 invoked by uid 399); 17 Jul 2006 22:22:36 -0000 Received: from localhost (HELO ?192.168.0.7?) (dougb@dougbarton.us@127.0.0.1) by localhost with SMTP; 17 Jul 2006 22:22:36 -0000 Message-ID: <44BC0DB0.4030300@FreeBSD.org> Date: Mon, 17 Jul 2006 15:22:40 -0700 From: Doug Barton Organization: http://www.FreeBSD.org/ User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: Hajimu UMEMOTO References: <200607171009.k6HA9xHu070992@repoman.freebsd.org> In-Reply-To: X-Enigmail-Version: 0.94.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: ports@FreeBSD.org, stable@FreeBSD.org Subject: Re: HEADS UP: BIND9's resolver and reentrant version of netdb functions are MFC'ed X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Jul 2006 22:22:40 -0000 Hajimu UMEMOTO wrote: > Hi, > > I've just MFC'ed the BIND9's resolver stuff and reentrant version of > netdb functions. > It is known that some ports are confused by existence of reentrant > functions. So, I've bumped __FreeBSD_version to 601103. This is very exciting stuff! Thanks for your hard work on this. Doug -- This .signature sanitized for your protection From owner-freebsd-stable@FreeBSD.ORG Tue Jul 18 06:42:13 2006 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B573216A4E6 for ; Tue, 18 Jul 2006 06:42:13 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from nz-out-0102.google.com (nz-out-0102.google.com [64.233.162.203]) by mx1.FreeBSD.org (Postfix) with ESMTP id 708A143D4C for ; Tue, 18 Jul 2006 06:42:12 +0000 (GMT) (envelope-from pyunyh@gmail.com) Received: by nz-out-0102.google.com with SMTP id f1so547881nzc for ; Mon, 17 Jul 2006 23:42:11 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:date:from:to:cc:subject:message-id:reply-to:references:mime-version:content-type:content-disposition:in-reply-to:user-agent; b=Gxd9iryd+hxZNS/3xDr2ymjay3zrpr/qUNo3AlrWVs3A8RMYyZxcZMAQ0IgMCQM4A0BCNz7zDDpqQuwoobs6RHnN20plODLF0A3XDBRzuWt8k9MYu1o6jlVUlzB2Qofp0ooUKTpvjZk8yS82+z8H2XbDs35ei2uug97ZvnwQ54U= Received: by 10.36.133.19 with SMTP id g19mr3629176nzd; Mon, 17 Jul 2006 23:42:11 -0700 (PDT) Received: from michelle.cdnetworks.co.kr ( [211.53.35.84]) by mx.gmail.com with ESMTP id 18sm295455nzo.2006.07.17.23.42.08; Mon, 17 Jul 2006 23:42:11 -0700 (PDT) Received: from michelle.cdnetworks.co.kr (localhost.cdnetworks.co.kr [127.0.0.1]) by michelle.cdnetworks.co.kr (8.13.5/8.13.5) with ESMTP id k6I6hoPX034792 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 18 Jul 2006 15:43:50 +0900 (KST) (envelope-from pyunyh@gmail.com) Received: (from yongari@localhost) by michelle.cdnetworks.co.kr (8.13.5/8.13.5/Submit) id k6I6hgQV034790; Tue, 18 Jul 2006 15:43:42 +0900 (KST) (envelope-from pyunyh@gmail.com) Date: Tue, 18 Jul 2006 15:43:41 +0900 From: Pyun YongHyeon To: Atanas Message-ID: <20060718064341.GC33301@cdnetworks.co.kr> References: <44AD7297.7080605@asd.aplus.net> <20060707010341.GD82406@cdnetworks.co.kr> <44ADC2ED.4070904@asd.aplus.net> <20060707040838.GE82406@cdnetworks.co.kr> <20060707151640.D51390@fledge.watson.org> <44AEB0CB.5060102@asd.aplus.net> <20060707181750.O1171@ganymede.hub.org> <20060707223609.N60542@fledge.watson.org> <20060708033254.GB87930@cdnetworks.co.kr> <44B2BCDB.7050403@asd.aplus.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <44B2BCDB.7050403@asd.aplus.net> User-Agent: Mutt/1.4.2.1i Cc: Peter Jeremy , Robert Watson , Michael Vince , freebsd-stable@freebsd.org, User Freebsd Subject: Re: em device hangs on ifconfig alias ... X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: pyunyh@gmail.com List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jul 2006 06:42:13 -0000 On Mon, Jul 10, 2006 at 01:47:23PM -0700, Atanas wrote: > Pyun YongHyeon said the following on 7/7/06 8:32 PM: > >On Fri, Jul 07, 2006 at 10:38:01PM +0100, Robert Watson wrote: > > > > > > Yes -- basically, there are two problems: > > > > > > (1) A little problem, in which an arp announcement is sent before the > > link > has > > > settled after reset. > > > > > > (2) A big problem, in which the interface is gratuitously recent > > requiring > > > long settling times. > > > > > > I'd really like to see a fix to the second of these problems (not > > resetting > when an IP is added or removed, resulting in link > > renegotiation); the first > one I'm less concerned about, although it > > would make some amount of sense > to do an arp announcement when the link > > goes up. > > > > > > >Ah, I see. Thanks for the insight. > >How about the attached patch? > > > This patch seems to fix both of the issues, or at least this is what I > see now: > - the card no longer gets reset when adding an alias; > - the arp packet gets delivered; > - adding 250 aliases takes less than a second; > > I haven't fully tested whether all 250 IP aliases were accessible (I > used non-routable IP addresses), but I suppose so. Also I couldn't > stress the patched driver enough to see whether it performs as expected. > > But in overall it looks good. I guess some more testing might be needed > in order to merge the patch into the source tree. > I haven't received any reports execept this one. If there is no objection I'll commit these changes within two days. -- Regards, Pyun YongHyeon From owner-freebsd-stable@FreeBSD.ORG Tue Jul 18 10:19:01 2006 Return-Path: X-Original-To: stable@freebsd.org Delivered-To: freebsd-stable@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9149D16A4DF for ; Tue, 18 Jul 2006 10:19:01 +0000 (UTC) (envelope-from nike_d@cytexbg.com) Received: from mail.interbgc.com (mx04.cablebg.net [217.9.224.232]) by mx1.FreeBSD.org (Postfix) with SMTP id D190243D4C for ; Tue, 18 Jul 2006 10:18:59 +0000 (GMT) (envelope-from nike_d@cytexbg.com) Received: (qmail 7554 invoked from network); 18 Jul 2006 10:18:57 -0000 Received: from nike_d@cytexbg.com by keeper.interbgc.com by uid 1002 with qmail-scanner-1.14 (uvscan: v4.2.40/v4374. spamassassin: 2.63. Clear:SA:0(0.1/8.0):. Processed in 1.39104 secs); 18 Jul 2006 10:18:57 -0000 X-Spam-Status: No, hits=0.1 required=8.0 Received: from niked.ddns.cablebg.net (HELO tormentor.totalterror.net) (85.130.14.211) by mx04.interbgc.com with SMTP; 18 Jul 2006 10:18:56 -0000 Received: (qmail 4215 invoked from network); 18 Jul 2006 10:18:55 -0000 Received: from unknown (HELO ?10.0.0.3?) (10.0.0.3) by tormentor.totalterror.net with SMTP; 18 Jul 2006 10:18:55 -0000 Message-ID: <44BCB58E.8010707@cytexbg.com> Date: Tue, 18 Jul 2006 13:18:54 +0300 From: Niki Denev User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: stable@freebsd.org, net@freebsd.org X-Enigmail-Version: 0.94.0.0 OpenPGP: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Subject: ural(4) deassociates if no activity (possible wpa_supplicant problem) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jul 2006 10:19:01 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hello, I've noticed something very interesing while using a ural(4) usb wifi device. When i plug the usb device, and there is absolutely no network activity, exactly after five minutes the device deassociates from the access point. I've put some debug printf's in ural_newstate and when i plug the device, i get several IEEE80211_S_SCAN state changes, then i gets from IEEE80211_S_AUTH to ASSOC and then RUN. Nothing wrong here, but exactly after five minutes of no activity (measured with stopwatch) i get a state transition from IEEE80211_S_RUN to IEEE80211_S_AUTH and it stays that way, until i remove/insert the device again or send HUP to wpa_supplicant and restart dhclient. This looks maybe like wpa_supplicant problem, and i think i've had similar problems with ath(4) mini-pci card and card bus ral(3), but as far as i remember the period of inactivity was much greater with them (i'll try to test this on these cards too when i have access to them again) Regards, - --niki -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFEvLWOHNAJ/fLbfrkRAkSbAJ90SYFCkdtjEw3hckrQ/B2O0geWHgCgoj5j gF7/O+dMKdNUrvFydNODQrE= =piip -----END PGP SIGNATURE----- From owner-freebsd-stable@FreeBSD.ORG Tue Jul 18 10:26:37 2006 Return-Path: X-Original-To: stable@freebsd.org Delivered-To: freebsd-stable@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 48C1916A4E0 for ; Tue, 18 Jul 2006 10:26:37 +0000 (UTC) (envelope-from nike_d@cytexbg.com) Received: from mail.interbgc.com (mx02.interbgc.com [217.9.224.227]) by mx1.FreeBSD.org (Postfix) with SMTP id 37FC643D7D for ; Tue, 18 Jul 2006 10:26:27 +0000 (GMT) (envelope-from nike_d@cytexbg.com) Received: (qmail 12942 invoked from network); 18 Jul 2006 10:26:26 -0000 Received: from nike_d@cytexbg.com by keeper.interbgc.com by uid 1002 with qmail-scanner-1.14 (uvscan: v4.2.40/v4374. spamassassin: 2.63. Clear:SA:0(0.1/8.0):. Processed in 2.295829 secs); 18 Jul 2006 10:26:26 -0000 X-Spam-Status: No, hits=0.1 required=8.0 Received: from niked.ddns.cablebg.net (HELO tormentor.totalterror.net) (85.130.14.211) by mx02.interbgc.com with SMTP; 18 Jul 2006 10:26:23 -0000 Received: (qmail 5136 invoked from network); 18 Jul 2006 10:26:23 -0000 Received: from unknown (HELO ?10.0.0.3?) (10.0.0.3) by tormentor.totalterror.net with SMTP; 18 Jul 2006 10:26:23 -0000 Message-ID: <44BCB74E.5020307@cytexbg.com> Date: Tue, 18 Jul 2006 13:26:22 +0300 From: Niki Denev User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: stable@freebsd.org References: <44BCB58E.8010707@cytexbg.com> In-Reply-To: <44BCB58E.8010707@cytexbg.com> X-Enigmail-Version: 0.94.0.0 OpenPGP: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: net@freebsd.org Subject: Re: ural(4) deassociates if no activity (possible wpa_supplicant problem) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jul 2006 10:26:37 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Niki Denev wrote: > Hello, > > I've noticed something very interesing while using a ural(4) usb wifi device. > > When i plug the usb device, and there is absolutely no network activity, exactly > after five minutes the device deassociates from the access point. > > I've put some debug printf's in ural_newstate and when i plug the device, > i get several IEEE80211_S_SCAN state changes, > then i gets from IEEE80211_S_AUTH to ASSOC and then RUN. > Nothing wrong here, but exactly after five minutes of no activity (measured > with stopwatch) i get a state transition from IEEE80211_S_RUN to IEEE80211_S_AUTH > and it stays that way, until i remove/insert the device again or send HUP to > wpa_supplicant and restart dhclient. > > This looks maybe like wpa_supplicant problem, and i think i've had similar problems with > ath(4) mini-pci card and card bus ral(3), but as far as i remember the period of > inactivity was much greater with them (i'll try to test this on these cards too when > i have access to them again) > > > Regards, > --niki Well, after a few more moments investigating the problem it seems that dhclient is to blame. If i don't start it i don't get disconnected, and also i noticed that the five minute interval matches the dhclient renewal period of 300 seconds. So the logical question is, why dhclient makes my ural(4) adapter deassociate, and what i can do to prevent this :) Thanks! - --niki -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFEvLdOHNAJ/fLbfrkRAnt+AKCnpfDdSucSccRTm4Qmg4ONVWQqzwCgygJp EE+HPPMAbzIhMOsHO6Q+f6o= =NXMO -----END PGP SIGNATURE----- From owner-freebsd-stable@FreeBSD.ORG Tue Jul 18 13:31:55 2006 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6F59516A4DD for ; Tue, 18 Jul 2006 13:31:55 +0000 (UTC) (envelope-from mb@imp.ch) Received: from pop.imp.ch (mx2.imp.ch [157.161.9.17]) by mx1.FreeBSD.org (Postfix) with ESMTP id E046543D55 for ; Tue, 18 Jul 2006 13:31:54 +0000 (GMT) (envelope-from mb@imp.ch) Received: from godot.imp.ch (godot.imp.ch [157.161.4.8]) by pop.imp.ch (8.13.7/8.13.7/Submit_imp) with ESMTP id k6IDVoAa026116 for ; Tue, 18 Jul 2006 15:31:52 +0200 (CEST) (envelope-from mb@imp.ch) Date: Tue, 18 Jul 2006 15:31:49 +0200 (CEST) From: Martin Blapp To: freebsd-stable@freebsd.org Message-ID: <20060718152306.X36995@godot.imp.ch> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Scanned-By: MIMEDefang 2.57 on 157.161.9.65 Subject: Please confirm: top(1) cpu time broken on FreeBSD 6.1 (RELEASE/STABLE) SMP ? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jul 2006 13:31:55 -0000 Hi all, I'm currently seeing strang things going on on all our upgraded SMP 2 CPU boxes. 4 Boxes are upgraded from 5.5 to 6 STABLE, one box is running 6.1 RELEASE. All of them have SMP kernels, just using the provided GENERIC and SMP kernel config files. Mergemaster has been done on all boxes. If a box is full loaded top(1) shows: CPU states: 41.7% user, 0.0% nice, 7.7% system, 0.6% interrupt, 50.0% idle I can buildworld -j 100, do verything what I want. The sum of idle time never goes below 50.0% idle ! And the sum of total CPU time never goes over 50.0%. So I wonder if just top is broken (in 6.1 RELEASE too), or if this is a SCHED4BSD bug. Can someone confirm this issue ? We see it on IBL X-Series 346 Boxes, as on IBM 306M Dual Core SMP systems. Martin Martin Blapp, ------------------------------------------------------------------ ImproWare AG, UNIXSP & ISP, Zurlindenstrasse 29, 4133 Pratteln, CH Phone: +41 61 826 93 00 Fax: +41 61 826 93 01 PGP: PGP Fingerprint: B434 53FC C87C FE7B 0A18 B84C 8686 EF22 D300 551E ------------------------------------------------------------------ From owner-freebsd-stable@FreeBSD.ORG Tue Jul 18 13:59:03 2006 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5BA8F16A4E2 for ; Tue, 18 Jul 2006 13:59:03 +0000 (UTC) (envelope-from mb@imp.ch) Received: from pop.imp.ch (mx2.imp.ch [157.161.9.17]) by mx1.FreeBSD.org (Postfix) with ESMTP id C328143D62 for ; Tue, 18 Jul 2006 13:59:02 +0000 (GMT) (envelope-from mb@imp.ch) Received: from godot.imp.ch (godot.imp.ch [157.161.4.8]) by pop.imp.ch (8.13.7/8.13.7/Submit_imp) with ESMTP id k6IDwwaj072252 for ; Tue, 18 Jul 2006 15:59:01 +0200 (CEST) (envelope-from mb@imp.ch) Date: Tue, 18 Jul 2006 15:58:58 +0200 (CEST) From: Martin Blapp To: freebsd-stable@freebsd.org In-Reply-To: <20060718152306.X36995@godot.imp.ch> Message-ID: <20060718155642.H36995@godot.imp.ch> References: <20060718152306.X36995@godot.imp.ch> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Scanned-By: MIMEDefang 2.57 on 157.161.9.65 Subject: Re: Please confirm: top(1) cpu time broken on FreeBSD 6.1 (RELEASE/STABLE) SMP ? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jul 2006 13:59:03 -0000 #include main() { while(1) {} } cc -o test.c test ./test & ./test & ./test & ./test & ./test & ./test & ./test & ./test & CPU states: 50.0% user, 0.0% nice, 0.0% system, 0.0% interrupt, 50.0% idle Mem: 1160M Active, 988M Inact, 254M Wired, 34M Cache, 112M Buf, 573M Free Swap: 8192M Total, 8192M Free PID USERNAME THR PRI NICE SIZE RES STATE C TIME WCPU COMMAND 21651 root 1 104 0 1216K 420K RUN 2 0:03 28.85% test 21653 root 1 103 0 1216K 420K CPU0 0 0:02 28.26% test 21649 root 1 104 0 1216K 420K RUN 2 0:03 26.12% test 21647 root 1 103 0 1216K 420K RUN 2 0:02 25.04% test 21650 root 1 103 0 1216K 420K RUN 0 0:02 24.50% test 21645 root 1 103 0 1216K 420K RUN 0 0:03 23.31% test 21646 root 1 104 0 1216K 420K RUN 2 0:03 22.81% test 21638 root 1 103 0 1216K 420K RUN 2 0:03 21.79% test Martin Blapp, ------------------------------------------------------------------ ImproWare AG, UNIXSP & ISP, Zurlindenstrasse 29, 4133 Pratteln, CH Phone: +41 61 826 93 00 Fax: +41 61 826 93 01 PGP: PGP Fingerprint: B434 53FC C87C FE7B 0A18 B84C 8686 EF22 D300 551E ------------------------------------------------------------------ From owner-freebsd-stable@FreeBSD.ORG Tue Jul 18 14:00:10 2006 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5A8B116A4DA for ; Tue, 18 Jul 2006 14:00:10 +0000 (UTC) (envelope-from killing@multiplay.co.uk) Received: from multiplay.co.uk (core6.multiplay.co.uk [85.236.96.23]) by mx1.FreeBSD.org (Postfix) with ESMTP id 809A943D8E for ; Tue, 18 Jul 2006 13:59:57 +0000 (GMT) (envelope-from killing@multiplay.co.uk) Received: from vader ([212.135.219.179]) by multiplay.co.uk (multiplay.co.uk [85.236.96.23]) (MDaemon PRO v9.0.1) with ESMTP id md50002789215.msg for ; Tue, 18 Jul 2006 14:58:23 +0100 Message-ID: <00a001c6aa72$509985b0$b3db87d4@multiplay.co.uk> From: "Steven Hartland" To: "Martin Blapp" , References: <20060718152306.X36995@godot.imp.ch> Date: Tue, 18 Jul 2006 14:58:51 +0100 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.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 X-Spam-Processed: multiplay.co.uk, Tue, 18 Jul 2006 14:58:24 +0100 (not processed: message from valid local sender) X-MDRemoteIP: 212.135.219.179 X-Return-Path: killing@multiplay.co.uk X-MDaemon-Deliver-To: freebsd-stable@freebsd.org X-MDAV-Processed: multiplay.co.uk, Tue, 18 Jul 2006 14:58:24 +0100 Cc: Subject: Re: Please confirm: top(1) cpu time broken on FreeBSD 6.1 (RELEASE/STABLE) SMP ? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jul 2006 14:00:10 -0000 What does dmesg say looks like you may be running a P4 there with HT disabled hence the results. Martin Blapp wrote: > > If a box is full loaded top(1) shows: > > CPU states: 41.7% user, 0.0% nice, 7.7% system, 0.6% interrupt, > 50.0% idle > > I can buildworld -j 100, do verything what I want. The > sum of idle time never goes below 50.0% idle ! And the sum > of total CPU time never goes over 50.0%. ================================================ This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. In the event of misdirection, illegible or incomplete transmission please telephone +44 845 868 1337 or return the E.mail to postmaster@multiplay.co.uk. From owner-freebsd-stable@FreeBSD.ORG Tue Jul 18 14:02:51 2006 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 479A016A4DD for ; Tue, 18 Jul 2006 14:02:51 +0000 (UTC) (envelope-from mb@imp.ch) Received: from pop.imp.ch (mx2.imp.ch [157.161.9.17]) by mx1.FreeBSD.org (Postfix) with ESMTP id 942DE43D76 for ; Tue, 18 Jul 2006 14:02:47 +0000 (GMT) (envelope-from mb@imp.ch) Received: from godot.imp.ch (godot.imp.ch [157.161.4.8]) by pop.imp.ch (8.13.7/8.13.7/Submit_imp) with ESMTP id k6IE2hmF079075; Tue, 18 Jul 2006 16:02:46 +0200 (CEST) (envelope-from mb@imp.ch) Date: Tue, 18 Jul 2006 16:02:43 +0200 (CEST) From: Martin Blapp To: Steven Hartland In-Reply-To: <00a001c6aa72$509985b0$b3db87d4@multiplay.co.uk> Message-ID: <20060718160133.M36995@godot.imp.ch> References: <20060718152306.X36995@godot.imp.ch> <00a001c6aa72$509985b0$b3db87d4@multiplay.co.uk> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Scanned-By: MIMEDefang 2.57 on 157.161.9.65 Cc: freebsd-stable@freebsd.org Subject: Re: Please confirm: top(1) cpu time broken on FreeBSD 6.1 (RELEASE/STABLE) SMP ? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jul 2006 14:02:51 -0000 Hi, Yes HTT is disabled (by default as I tought also by freebsd). But shouldn't top show then the correct results ? Martin From owner-freebsd-stable@FreeBSD.ORG Tue Jul 18 14:10:50 2006 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DAAF916A4DF for ; Tue, 18 Jul 2006 14:10:50 +0000 (UTC) (envelope-from matthieu.michaud@epita.info) Received: from marge.cload.net (marge.cload.net [213.41.172.209]) by mx1.FreeBSD.org (Postfix) with SMTP id DE17B43D5C for ; Tue, 18 Jul 2006 14:10:47 +0000 (GMT) (envelope-from matthieu.michaud@epita.info) Received: (qmail 11139 invoked by uid 80); 18 Jul 2006 16:12:28 +0200 Received: from 163.5.255.60 (SquirrelMail authenticated user ohmer@epita.info) by webmail.epita.info with HTTP; Tue, 18 Jul 2006 16:12:28 +0200 (CEST) Message-ID: <64643.163.5.255.60.1153231948.squirrel@webmail.epita.info> In-Reply-To: <20060718152306.X36995@godot.imp.ch> References: <20060718152306.X36995@godot.imp.ch> Date: Tue, 18 Jul 2006 16:12:28 +0200 (CEST) From: "Matthieu Michaud" To: "Martin Blapp" User-Agent: SquirrelMail/1.4.6 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Cc: freebsd-stable@freebsd.org Subject: Re: Please confirm: top(1) cpu time broken on FreeBSD 6.1 (RELEASE/STABLE) SMP ? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: matthieu.michaud@epita.info List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jul 2006 14:10:50 -0000 Le Mar 18 juillet 2006 15:31, Martin Blapp a écrit : > > Hi all, hi, > I'm currently seeing strang things going on on all our > upgraded SMP 2 CPU boxes. 4 Boxes are upgraded from 5.5 to > 6 STABLE, one box is running 6.1 RELEASE. i'm running 6.1 RELEASE upgraded from 6.0 RELEASE. > All of them have SMP kernels, just using the provided GENERIC and SMP > kernel config files. Mergemaster has been done on all > boxes. > > If a box is full loaded top(1) shows: > > CPU states: 41.7% user, 0.0% nice, 7.7% system, 0.6% interrupt, 50.0% > idle > > I can buildworld -j 100, do verything what I want. The > sum of idle time never goes below 50.0% idle ! And the sum > of total CPU time never goes over 50.0%. i ran make buildworld -j8 and i confirm. afair it was ok on 6.0-RELEASE. > So I wonder if just top is broken (in 6.1 RELEASE too), or if this > is a SCHED4BSD bug. > > Can someone confirm this issue ? We see it on IBL X-Series 346 Boxes, > as on IBM 306M Dual Core SMP systems. i have a DELL 1600SC (bi-xeons) with a SMP kernel and machdep.hyperthreading_allowed=0. setting it to 1 made idle % to 0. -- Matthieu Michaud EPITA SRS 2007 From owner-freebsd-stable@FreeBSD.ORG Tue Jul 18 14:12:40 2006 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8A0D016A4DD for ; Tue, 18 Jul 2006 14:12:40 +0000 (UTC) (envelope-from cswiger@mac.com) Received: from pi.codefab.com (pi.codefab.com [199.103.21.227]) by mx1.FreeBSD.org (Postfix) with ESMTP id E89F043D58 for ; Tue, 18 Jul 2006 14:12:31 +0000 (GMT) (envelope-from cswiger@mac.com) Received: from localhost (localhost [127.0.0.1]) by pi.codefab.com (Postfix) with ESMTP id 53D4E5DB3; Tue, 18 Jul 2006 10:12:31 -0400 (EDT) X-Virus-Scanned: amavisd-new at codefab.com Received: from pi.codefab.com ([127.0.0.1]) by localhost (pi.codefab.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hRW5c2aX0gTF; Tue, 18 Jul 2006 10:12:29 -0400 (EDT) Received: from [192.168.1.251] (pool-68-161-117-245.ny325.east.verizon.net [68.161.117.245]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by pi.codefab.com (Postfix) with ESMTP id 26DEA5C31; Tue, 18 Jul 2006 10:12:29 -0400 (EDT) Message-ID: <44BCEC46.1050303@mac.com> Date: Tue, 18 Jul 2006 10:12:22 -0400 From: Chuck Swiger User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: Martin Blapp References: <20060718152306.X36995@godot.imp.ch> <20060718155642.H36995@godot.imp.ch> In-Reply-To: <20060718155642.H36995@godot.imp.ch> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org Subject: Re: Please confirm: top(1) cpu time broken on FreeBSD 6.1 (RELEASE/STABLE) SMP ? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jul 2006 14:12:40 -0000 Hi, Martin-- Martin Blapp wrote: [ ...test program to create load... ] > CPU states: 50.0% user, 0.0% nice, 0.0% system, 0.0% interrupt, 50.0% > idle You've probably got HTT disabled by sysctl rather than in the BIOS. In that case, top "sees" that your system claims to have 4 CPUs, but you're only going to schedule tasks on 2 of them. Turning HTT off in the BIOS rather than via the sysctl would probably make top's view of your system more sensible... -- -Chuck From owner-freebsd-stable@FreeBSD.ORG Tue Jul 18 14:21:33 2006 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6C0B916A4E1 for ; Tue, 18 Jul 2006 14:21:33 +0000 (UTC) (envelope-from mb@imp.ch) Received: from pop.imp.ch (mx2.imp.ch [157.161.9.17]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3392943D9D for ; Tue, 18 Jul 2006 14:20:16 +0000 (GMT) (envelope-from mb@imp.ch) Received: from godot.imp.ch (godot.imp.ch [157.161.4.8]) by pop.imp.ch (8.13.7/8.13.7/Submit_imp) with ESMTP id k6IEK20Y009703; Tue, 18 Jul 2006 16:20:05 +0200 (CEST) (envelope-from mb@imp.ch) Date: Tue, 18 Jul 2006 16:20:02 +0200 (CEST) From: Martin Blapp To: David Wolfskill In-Reply-To: <20060718140707.GG66891@bunrab.catwhisker.org> Message-ID: <20060718161104.X36995@godot.imp.ch> References: <20060718152306.X36995@godot.imp.ch> <20060718155642.H36995@godot.imp.ch> <20060718140707.GG66891@bunrab.catwhisker.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Scanned-By: MIMEDefang 2.57 on 157.161.9.65 Cc: freebsd-stable@freebsd.org Subject: Re: Please confirm: top(1) cpu time broken on FreeBSD 6.1 (RELEASE/STABLE) SMP ? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jul 2006 14:21:33 -0000 Hi, Ok, seems to be a HTT issue on a untuned system. On two boxes I get with 'sysctl -a | grep smp | grep kern.smp.cpus' kern.smp.cpus: 4 Here I see CPU-IDs 0 and 2 in top. No other CPUs seem to be used. Here I get the broken CPU usage. And yes, seeting hyperthreading_allowed=1 corrects the top usage. On two other boxes where it works I get 'sysctl -a | grep smp | grep kern.smp.cpus' kern.smp.cpus: 2 Here I see CPU-ID's 0 and 1 in top. Here everything works as it should. Martin Martin Blapp, ------------------------------------------------------------------ ImproWare AG, UNIXSP & ISP, Zurlindenstrasse 29, 4133 Pratteln, CH Phone: +41 61 826 93 00 Fax: +41 61 826 93 01 PGP: PGP Fingerprint: B434 53FC C87C FE7B 0A18 B84C 8686 EF22 D300 551E ------------------------------------------------------------------ From owner-freebsd-stable@FreeBSD.ORG Tue Jul 18 14:33:14 2006 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4FECC16A4DE for ; Tue, 18 Jul 2006 14:33:14 +0000 (UTC) (envelope-from me@hawei.net2.nerim.net) Received: from hawei.net2.nerim.net (hawei.net2.nerim.net [213.41.129.28]) by mx1.FreeBSD.org (Postfix) with ESMTP id C545343E7E for ; Tue, 18 Jul 2006 14:26:54 +0000 (GMT) (envelope-from me@hawei.net2.nerim.net) Received: by hawei.net2.nerim.net (Postfix, from userid 1001) id 21384450C0; Tue, 18 Jul 2006 16:30:13 +0200 (CEST) Date: Tue, 18 Jul 2006 16:30:12 +0200 From: Harald Weis To: freebsd-stable@freebsd.org Message-ID: <20060718143012.GA92325@hawei.net2.nerim.net> Mail-Followup-To: freebsd-stable@freebsd.org References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.1i Subject: Re: Canon PIXMA support X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jul 2006 14:33:14 -0000 On Tue, Jun 27, 2006 at 07:27:50PM +0300, Ivan Asmer wrote: > Hello everyone. > > I'm interesting how to run my canon pixma iP 1500 under my honest freebsd. > As I found in internet this is impossible. Who can say more? I got my iP 5000 working with cups and gimp-print (WITH_CUPS). I haven't tried apsfilter yet which I would prefer because cups disallows a2ps. Bye Harald Weis -- FreeBSD 6.1-RELEASE #0: Sun May 7 04:42:56 UTC 2006 From owner-freebsd-stable@FreeBSD.ORG Tue Jul 18 17:07:45 2006 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8229216A4DD for ; Tue, 18 Jul 2006 17:07:45 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [209.31.154.42]) by mx1.FreeBSD.org (Postfix) with ESMTP id D836643D49 for ; Tue, 18 Jul 2006 17:07:44 +0000 (GMT) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [209.31.154.41]) by cyrus.watson.org (Postfix) with ESMTP id 54B5B46C1C; Tue, 18 Jul 2006 13:07:44 -0400 (EDT) Date: Tue, 18 Jul 2006 18:07:44 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Dominic Marks In-Reply-To: <1968.195.12.22.194.1153141853.squirrel@mail.helenmarks.co.uk> Message-ID: <20060718180701.N11473@fledge.watson.org> References: <1968.195.12.22.194.1153141853.squirrel@mail.helenmarks.co.uk> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-stable@freebsd.org Subject: Re: Two panics on recent 6.1-STABLE X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jul 2006 17:07:45 -0000 On Mon, 17 Jul 2006, Dominic Marks wrote: > Two panics, I've just had: > > I had just installed a fresh world+kernel, booted and then received the > first panic. Then reset, booted again and shortly received the second > (although they look identical to me). At the moment everything seems fine, > sending this message from the machine in question. Dominic, I've bounced a copy of your report to John Baldwin (jhb@FreeBSD.org) who has been involved in the process locking work, which seems relevant to this bug report. He's not on -stable, but will hopefully get in touch with you shortly. Robert N M Watson Computer Laboratory University of Cambridge > > Rough description of the PC's life: Gnome Desktop connected using > nsswitch/winbind to Active Directory. Low load. > > I can make the dumps available, but at a guess I'd say they don't look > very helpful. I'll recompile with debugging options enabled and see if > I can get some other info. If I do, I'll follow-up with it here. > > Thanks, > Dominic > > FreeBSD gdc083.internal.graphdata.co.uk 6.1-STABLE FreeBSD 6.1-STABLE > #0: Mon Jul 17 12:43:52 BST 2006 > dominicm@gdc083.internal.graphdata.co.uk:/usr/obj/usr/src/sys/GDC083 > i386 > > panic #1: > > Fatal trap 12: page fault while in kernel mode > fault virtual address = 0xfefefe14 > fault code = supervisor read, page not present > instruction pointer = 0x20:0xc06a031b > stack pointer = 0x28:0xe7383c88 > frame pointer = 0x28:0xe7383ca0 > code segment = base 0x0, limit 0xfffff, type 0x1b > = DPL 0, pres 1, def32 1, gran 1 > processor eflags = interrupt enabled, resume, IOPL = 0 > current process = 827 (csh) > trap number = 12 > panic: page fault > Uptime: 3m47s > Dumping 1022 MB (2 chunks) > chunk 0: 1MB (160 pages) ... ok > chunk 1: 1022MB (261516 pages) 1006 990 974 958 942 926 (CTRL-C to > abort) 910 894 878 (CTRL-C to abort) 862 846 830 814 798 782 766 > 750 734 718 702 686 670 654 638 622 606 590 574 558 542 526 510 494 > 478 462 446 430 414 398 382 366 350 334 318 302 286 270 254 238 222 > 206 190 174 158 142 126 110 94 78 62 46 30 14 > > #0 doadump () at pcpu.h:165 > 165 pcpu.h: No such file or directory. > in pcpu.h > (kgdb) bt > #0 doadump () at pcpu.h:165 > #1 0xc06a8f7a in boot (howto=260) at > /usr/src/sys/kern/kern_shutdown.c:409 > #2 0xc06a9284 in panic (fmt=0xc0925487 "%s") > at /usr/src/sys/kern/kern_shutdown.c:565 > #3 0xc08d142d in trap_fatal (frame=0xe7383c48, eva=0) > at /usr/src/sys/i386/i386/trap.c:836 > #4 0xc08d114d in trap_pfault (frame=0xe7383c48, usermode=0, > eva=4278124052) > at /usr/src/sys/i386/i386/trap.c:744 > #5 0xc08d0d37 in trap (frame= > {tf_fs = 8, tf_es = -1056702424, tf_ds = -1056702424, tf_edi = > -415744764, tf_esi = -986172392, tf_ebp = -415744864, tf_isp = > -415744908, tf_ebx = -16843264, tf_edx = 827, tf_ecx = 827, > tf_eax = 4, tf_trapno = 12, tf_err = 0, tf_eip = -1066794213, > tf_cs = 32, tf_eflags = 66182, tf_esp = 64, tf_ss = 2}) > at /usr/src/sys/i386/i386/trap.c:434 > #6 0xc08bee9a in calltrap () at /usr/src/sys/i386/i386/exception.s:139 > #7 0xc06a031b in pgfind (pgid=827) at /usr/src/sys/kern/kern_proc.c:257 > #8 0xc06a3567 in setpgid (td=0xc520cd80, uap=0xe7383d04) > at /usr/src/sys/kern/kern_prot.c:436 > #9 0xc08d17e3 in syscall (frame= > {tf_fs = 59, tf_es = 59, tf_ds = -1078001605, tf_edi = 2, tf_esi > = 827, tf_ebp = -1077995432, tf_isp = -415744668, tf_ebx = 783, > tf_edx = -1077995488, tf_ecx = 2, tf_eax = 82, tf_trapno = 22, > tf_err = 2, tf_eip = 672532403, tf_cs = 51, tf_eflags = 518, > tf_esp = -1077995460, tf_ss = 59}) > at /usr/src/sys/i386/i386/trap.c:981 > #10 0xc08beeef in Xint0x80_syscall () at > /usr/src/sys/i386/i386/exception.s:200 > #11 0x00000033 in ?? () > Previous frame inner to this frame (corrupt stack?) > > panic #2 > > Fatal trap 12: page fault while in kernel mode > fault virtual address = 0xfefefe14 > fault code = supervisor read, page not present > instruction pointer = 0x20:0xc06a031b > stack pointer = 0x28:0xe739ec88 > frame pointer = 0x28:0xe739eca0 > code segment = base 0x0, limit 0xfffff, type 0x1b > = DPL 0, pres 1, def32 1, gran 1 > processor eflags = interrupt enabled, resume, IOPL = 0 > current process = 827 (csh) > trap number = 12 > panic: page fault > Uptime: 5m56s > Dumping 1022 MB (2 chunks) > chunk 0: 1MB (160 pages) ... ok > chunk 1: 1022MB (261516 pages) 1006 990 974 958 (CTRL-C to abort) > 942 926 910 894 878 862 846 830 814 798 782 766 750 734 718 702 686 > 670 654 638 622 606 590 574 558 542 526 510 494 478 462 446 430 414 > 398 382 366 350 334 318 302 286 270 254 238 222 206 190 174 158 142 > 126 110 94 78 62 46 30 14 > > #0 doadump () at pcpu.h:165 > 165 pcpu.h: No such file or directory. > in pcpu.h > (kgdb) bt > #0 doadump () at pcpu.h:165 > #1 0xc06a8f7a in boot (howto=260) at > /usr/src/sys/kern/kern_shutdown.c:409 > #2 0xc06a9284 in panic (fmt=0xc0925487 "%s") at > /usr/src/sys/kern/kern_shutdown.c:565 > #3 0xc08d142d in trap_fatal (frame=0xe739ec48, eva=0) at > /usr/src/sys/i386/i386/trap.c:836 > #4 0xc08d114d in trap_pfault (frame=0xe739ec48, usermode=0, > eva=4278124052) at /usr/src/sys/i386/i386/trap.c:744 > #5 0xc08d0d37 in trap (frame= > {tf_fs = 8, tf_es = -1056702424, tf_ds = -1056702424, tf_edi = > -415634172, tf_esi = -981162460, tf_ebp = -415634272, tf_isp = > -415634316, tf_ebx = -16843264, tf_edx = 827, tf_ecx = 827, > tf_eax = 4, tf_trapno = 12, tf_err = 0, tf_eip = -1066794213, > tf_cs = 32, tf_eflags = 66182, tf_esp = 64, tf_ss = 2}) at > /usr/src/sys/i386/i386/trap.c:434 > #6 0xc08bee9a in calltrap () at /usr/src/sys/i386/i386/exception.s:139 > #7 0xc06a031b in pgfind (pgid=827) at /usr/src/sys/kern/kern_proc.c:257 > #8 0xc06a3567 in setpgid (td=0xc52ebc00, uap=0xe739ed04) at > /usr/src/sys/kern/kern_prot.c:436 > #9 0xc08d17e3 in syscall (frame= > {tf_fs = 59, tf_es = 59, tf_ds = 59, tf_edi = 2, tf_esi = 827, > tf_ebp = -1077995432, tf_isp = -415634076, tf_ebx = 773, tf_edx > = -1077995488, tf_ecx = 2, tf_eax = 82, tf_trapno = 22, tf_err = > 2, tf_eip = 672532403, tf_cs = 51, tf_eflags = 518, tf_esp = > -1077995460, tf_ss = 59}) at /usr/src/sys/i386/i386/trap.c:981 > #10 0xc08beeef in Xint0x80_syscall () at > /usr/src/sys/i386/i386/exception.s:200 > #11 0x00000033 in ?? () > Previous frame inner to this frame (corrupt stack?) > > dmesg: > > Copyright (c) 1992-2006 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 6.1-STABLE #0: Mon Jul 17 12:43:52 BST 2006 > dominicm@gdc083.internal.graphdata.co.uk:/usr/obj/usr/src/sys/GDC083 > Timecounter "i8254" frequency 1193182 Hz quality 0 > CPU: Intel(R) Xeon(TM) CPU 3.00GHz (2992.52-MHz 686-class CPU) > Origin = "GenuineIntel" Id = 0xf4a Stepping = 10 > Features=0xbfebfbff > Features2=0x641d> > AMD Features=0x20100000 > AMD Features2=0x1 > Logical CPUs per core: 2 > real memory = 1072218112 (1022 MB) > avail memory = 1040334848 (992 MB) > MPTable: > ioapic0: Changing APIC ID to 8 > ioapic0: Assuming intbase of 0 > ioapic1: Changing APIC ID to 9 > ioapic1: Assuming intbase of 24 > ioapic2: Changing APIC ID to 10 > ioapic2: Assuming intbase of 48 > ioapic0 irqs 0-23 on motherboard > ioapic1 irqs 24-47 on motherboard > ioapic2 irqs 48-71 on motherboard > kbd1 at kbdmux0 > ath_hal: 0.9.17.2 (AR5210, AR5211, AR5212, RF5111, RF5112, RF2413, > RF5413) > cpu0 on motherboard > pcib0: pcibus 0 on motherboard > pci0: on pcib0 > pcib0: unable to route slot 2 INTA > pcib0: unable to route slot 3 INTA > pcib0: unable to route slot 4 INTA > pci0: at device 0.1 (no driver attached) > pcib1: irq 11 at device 2.0 on pci0 > pci1: on pcib1 > pcib2: at device 0.0 on pci1 > pci2: on pcib2 > pci2: at device 12.0 (no driver attached) > pcib3: at device 0.2 on pci1 > pci3: on pcib3 > twe0: <3ware Storage Controller. Driver version 1.50.01.002> port > 0xccb0-0xccbf mem 0xdd800000-0xddffffff irq 49 at device 13.0 on pci3 > twe0: [GIANT-LOCKED] > twe0: 2 ports, Firmware FE8S 1.05.00.068, BIOS BE7X 1.08.00.048 > em0: port > 0xccc0-0xccff mem 0xdd6e0000-0xdd6fffff irq 48 at device 14.0 on pci3 > em0: Ethernet address: 00:13:72:8b:3c:a9 > pcib4: irq 11 at device 3.0 on pci0 > pci4: on pcib4 > pcib5: irq 11 at device 4.0 on pci0 > pci5: on pcib5 > uhci0: port 0xff80-0xff9f > irq 16 at device 29.0 on pci0 > uhci0: [GIANT-LOCKED] > usb0: on uhci0 > usb0: USB revision 1.0 > uhub0: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 > uhub0: 2 ports with 2 removable, self powered > uhci1: port 0xff60-0xff7f > irq 19 at device 29.1 on pci0 > uhci1: [GIANT-LOCKED] > usb1: on uhci1 > usb1: USB revision 1.0 > uhub1: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 > uhub1: 2 ports with 2 removable, self powered > uhci2: port 0xff40-0xff5f > irq 18 at device 29.2 on pci0 > uhci2: [GIANT-LOCKED] > usb2: on uhci2 > usb2: USB revision 1.0 > uhub2: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 > uhub2: 2 ports with 2 removable, self powered > uhci3: port 0xff20-0xff3f > irq 16 at device 29.3 on pci0 > uhci3: [GIANT-LOCKED] > usb3: on uhci3 > usb3: USB revision 1.0 > uhub3: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 > uhub3: 2 ports with 2 removable, self powered > ehci0: mem > 0xffa80800-0xffa80bff irq 23 at device 29.7 on pci0 > ehci0: [GIANT-LOCKED] > usb4: waiting for BIOS to give up control > usb4: EHCI version 1.0 > usb4: companion controllers, 2 ports each: usb0 usb1 usb2 usb3 > usb4: on ehci0 > usb4: USB revision 2.0 > uhub4: Intel EHCI root hub, class 9/0, rev 2.00/1.00, addr 1 > uhub4: 8 ports with 8 removable, self powered > umass0: FREECOM. ATAPI-6 Bridge Controller, rev 2.00/0.00, addr 2 > umass1: Freecom Classic Mobile 2.5' Hard Disk, rev 2.00/0.33, addr 3 > pcib6: at device 30.0 on pci0 > pci6: on pcib6 > isab0: at device 31.0 on pci0 > isa0: on isab0 > atapci0: port > 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xffa0-0xffaf mem > 0xdffffc00-0xdfffffff irq 18 at device 31.1 on pci0 > ata0: on atapci0 > ata1: on atapci0 > atapci1: port > 0xfe00-0xfe07,0xfe10-0xfe13,0xfe20-0xfe27,0xfe30-0xfe33,0xfea0-0xfeaf > irq 18 at device 31.2 on pci0 > ata2: on atapci1 > ata3: on atapci1 > pci0: at device 31.3 (no driver attached) > pmtimer0 on isa0 > orm0: at iomem > 0xc0000-0xc7fff,0xc8000-0xc87ff,0xc8800-0xc9fff,0xca000-0xcbfff on > isa0 > atkbdc0: at port 0x60,0x64 on isa0 > atkbd0: irq 1 on atkbdc0 > kbd0 at atkbd0 > atkbd0: [GIANT-LOCKED] > psm0: irq 12 on atkbdc0 > psm0: [GIANT-LOCKED] > psm0: model Generic PS/2 mouse, device ID 0 > ppc0: at port 0x378-0x37f irq 7 on isa0 > ppc0: SMC-like chipset (ECP/EPP/PS2/NIBBLE) in COMPATIBLE mode > ppc0: FIFO with 16/16/8 bytes threshold > ppbus0: on ppc0 > plip0: on ppbus0 > lpt0: on ppbus0 > lpt0: Interrupt-driven port > ppi0: on ppbus0 > sc0: at flags 0x100 on isa0 > sc0: VGA <16 virtual consoles, flags=0x300> > sio0: configured irq 4 not in bitmap of probed irqs 0 > sio0: port may not be enabled > sio0 at port 0x3f8-0x3ff irq 4 flags 0x10 on isa0 > sio0: type 16550A > sio1: configured irq 3 not in bitmap of probed irqs 0 > sio1: port may not be enabled > sio1 at port 0x2f8-0x2ff irq 3 on isa0 > sio1: type 16550A > vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 > unknown: can't assign resources (memory) > unknown: can't assign resources (port) > unknown: can't assign resources (port) > unknown: can't assign resources (port) > unknown: can't assign resources (port) > ukbd0: Dell Dell USB Keyboard, rev 1.10/2.00, addr 2, iclass 3/1 > kbd2 at ukbd0 > ums0: Microsoft Microsoft 5-Button Mouse with IntelliEye(TM), rev > 1.10/3.00, addr 3, iclass 3/1 > ums0: 5 buttons and Z dir. > Timecounter "TSC" frequency 2992517370 Hz quality 800 > Timecounters tick every 1.000 msec > acd0: CDROM at ata1-master UDMA33 > ad4: 76293MB at ata2-master SATA150 > da1 at umass-sim1 bus 1 target 0 lun 0 > da1: Fixed Direct Access SCSI-0 device > da1: 40.000MB/s transfers > da1: 28615MB (58605120 512 byte sectors: 255H 63S/T 3648C) > da0 at umass-sim0 bus 0 target 0 lun 0 > da0: Fixed Direct Access SCSI-0 device > da0: 40.000MB/s transfers > da0: 38154MB (78140160 512 byte sectors: 255H 63S/T 4864C) > Trying to mount root from ufs:/dev/ad4s1a > WARNING: / was not properly dismounted > WARNING: /usr was not properly dismounted > /usr: mount pending error: blocks 24 files 1 > WARNING: /var was not properly dismounted > > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" > From owner-freebsd-stable@FreeBSD.ORG Tue Jul 18 17:07:51 2006 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2C0DA16A584; Tue, 18 Jul 2006 17:07:51 +0000 (UTC) (envelope-from freebsd@hub.org) Received: from hub.org (hub.org [200.46.204.220]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2C4A243D49; Tue, 18 Jul 2006 17:07:48 +0000 (GMT) (envelope-from freebsd@hub.org) Received: from localhost (wm.hub.org [200.46.204.128]) by hub.org (Postfix) with ESMTP id 3018D291988; Tue, 18 Jul 2006 14:07:45 -0300 (ADT) Received: from hub.org ([200.46.204.220]) by localhost (mx1.hub.org [200.46.204.128]) (amavisd-new, port 10024) with ESMTP id 12944-05-2; Tue, 18 Jul 2006 17:07:43 +0000 (UTC) Received: from ganymede.hub.org (blk-224-179-167.eastlink.ca [24.224.179.167]) by hub.org (Postfix) with ESMTP id 77B17292931; Tue, 18 Jul 2006 07:51:47 -0300 (ADT) Received: by ganymede.hub.org (Postfix, from userid 1027) id 9827037B1D; Tue, 18 Jul 2006 07:51:52 -0300 (ADT) Received: from localhost (localhost [127.0.0.1]) by ganymede.hub.org (Postfix) with ESMTP id 8F6D7344AB; Tue, 18 Jul 2006 07:51:52 -0300 (ADT) Date: Tue, 18 Jul 2006 07:51:52 -0300 (ADT) From: User Freebsd To: Kostik Belousov In-Reply-To: <20060715035308.GJ32624@deviant.kiev.zoral.com.ua> Message-ID: <20060718074804.W1799@ganymede.hub.org> References: <20060705100403.Y80381@fledge.watson.org> <20060705234514.I70011@fledge.watson.org> <20060715000351.U1799@ganymede.hub.org> <20060715035308.GJ32624@deviant.kiev.zoral.com.ua> MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="0-391559352-1153219912=:1799" Cc: freebsd-stable@freebsd.org, Robert Watson Subject: file system deadlock - the whole story? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jul 2006 17:07:51 -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-391559352-1153219912=:1799 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed 'k, had a bunch of fun tonight, but one of the results is that I was able to achieve file system deadlock, or so it appears ... Using the following from DDB: set $lines=0 show pcpu show allpcpu ps trace alltrace show locks show alllocks show uma show malloc show lockedvnods call doadump I've been able to produce the attached output, as well as have a core dump that can hopefully be used to gather any that I may have missed this time *cross fingers* ---- Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email . scrappy@hub.org MSN . scrappy@hub.org Yahoo . yscrappy Skype: hub.org ICQ . 7615664 --0-391559352-1153219912=:1799 Content-Type: APPLICATION/octet-stream; name=crash_analysis_july_18_2006.gz Content-Transfer-Encoding: BASE64 Content-ID: <20060718075152.B1799@ganymede.hub.org> Content-Description: Content-Disposition: attachment; filename=crash_analysis_july_18_2006.gz H4sICLa3vEQAA2NyYXNoX2FuYWx5c2lzX2p1bHlfMThfMjAwNgDsXVuPI7l1 fg30F/JS2MSwjWBavF8GcBBn7QCOHcCB7afFJmCxWN21o9uqpO5t//oc8pTq ptK0SrWPGWDOaqXip8PDcyep+Ys/VodTVp/c8RSKbL/L/noO2X+eNxk1GdGf ifwMLxghavUaduf6n7JT2OzCKTvV8V2++uvxvdo9x9dPQj0xIp7M09PT6tv9 bhd8hDzt4dmnl3P+tD8+P61+X3t3CJl/cUcHnx+zqs5++T/f//JptTofXfqG 83Z/3p2y9et2Tddv28vY9bk+rg/746lebfau+JyZJyuyzG/hZTNEC8po9l1e 7Y/F9xl5IuQcqakz8otMGPOl/Y6iXP1HtQn1e30K2yyjf/yUb/b+S53FP3+r ge8s++2rqzbZt+7gfHV6z7L/it+RhLRaF+F1XThSUxcHMMmVNvGVFFYywNNG cJY+Er+I/1mvYESJ8N0fOn5B4mtCcAiM6H1RkZ5jSpOEmzFK4xdRIaTAN3DU aXvojQrwFidCwgJGNhXnKr7ghoj4XZltRoFse6PK4XfBCxlnZ6whaZaM46hX 1x/1DNPXmgoJGiOUZtookimurLBplDHNqO0DwoCvWu/cNhRJLIfj3o8BxPjF cPxImSLCI2yMYB5nRtD19n1Tn/a7J7/fLuFnhPQwS8yqtX8uq6UMDXEWsbPd n17C8cvPwFAfaRFLh7ra716rIux/Bq5GYIsYOx3P9QlGl6GOqG5T/wwM3gB9 mFHO7Nq/b48uPD8dzwuYGwE9zpBm6+pUftpVz+FYuYW+YQrtYdYEJ+t6vwHt iKr7BFF3AWcTYI8zZuT6hzrsnqtdWMrWGOpxpixf+/2uPm9O2/ci5KeF2j+N 9zB7krI1pE6h9vu3kC/kbQLsccaUWbNqKUMdyOOMaLN22/fdab9U18dIi1gC gABp3/FwrOqw0D1M4z3OntHrv+93IWbvS0U2hnqcKQvZ4MmF13B8fwNXEzYb v1S7bkEuYJKv65djeFsqtgHOw+woYtb5uSzdZl+BWrz4pCELpfYV0McZhSiS hxPg+Jfgl+ZlU2iPs6bp+lRBgRDqL1DLPS/lbQpuAXNsnVenYv/DfqELGSM9 zpJR4CTd36F6z+HvfqElTMI9zpwV67pwlCxdxQHOAnb0+vRyPB/c+2KGhkgP s6QJXf/Al9ayfZQFrEAq/ubqeu8rdwpQIbhFLF2jPc4alWtX+2rnntwS7R7i LGDHrMut22zC0hp7jPQ4S4ysy7wu1NNLtXFV2CxlbBJvAXuxoPJ7mKg/Va9h oW5NoC1gTawxY3peWgVdQS1gSq8riPObTfXi3r4sdQ8TaAtYM+vKucOn8Op2 z2ETK76FqzkJ+DiDXKyPoBXHwm3Cp4M7LhbfNOACBsE1nvPKP7tjsdyFTKA9 zpoga785559gpkv5GkM9zpSMSNWP5/AWa62FbF2DPc6YkuuXPUh9qYINcB5n R4t1+WOISXi9lKMx1ONMQUUKA6vXT/V+cz5V+93SfuYtxAUs2vVL9em0X+jH +jCRmcsmlS/S5+t/+Mfv/kjXqxVuvf1rVoddkeXH4L6s/vi7f/+cpcLuc/Yn cID4dtzHi72r/SasYhGzP8ctvv3hELfq/OFcr76DJDS4IjtURUa5oiw7xVeE GGuy71d/iQ+HInMnZPlLkf9v+pZ/IT+x/HO22x/S+6sij+ycsn+O3rf+DcE3 XvZv2QG+ZwV/q+Iy/99kdOXPx+ab0xvkJ18wyZwhn3usfPODe3XfxGcPPm8H k5+Cd8wXlqzKQw/nA5Sq2IT2K9OzRvJSt8/S7Jv4yOcoF/rN6rd//sO32R9+ d/lSFbk4wtQ3xakZL8mqBkFmuF/4EjbF51X4CTxWDa4+Sx9tz6fwU1ZX++wY h2S/gm8lKs8VI79O40C0/5Y23db10a/r9zrtosGA+PfJf6bc9kQJaV6S5rfI Svbtn//2GWQ5li6ZkK4lUljSzFVaAbN9OZ0OxZR087KYku4OMpMbUmyRo7hb KZIrKZIlUtweMhhahL+/7s/1QKBKO3dToBWHijSRw9YdQKbS2CuR/b9CzlHI pJGHepUlRoGCy0tsJZke0puH5yO4hnLjnuF9SGiBybdtqOP/ZW/+xe3Sjv1K S5BJ5oOSXNC4O8xYFt8jDSXwB7xR9t1f/vTn/wYPExP2LDHtSu3E9/H977O6 fkEoCVCutH0oZhs6E0pk3pjgEMqAr6bcsIbeB5UMLGFxcOFMFzDqQ6z8zVWn RnECI/4Ki8EUpc8djyJXJKNCS9VQgBKA9gFfFdgBYlHgKzclYjXiog2dKS6S eWeZ9MJcQptUsltEMTVFz5zMvRlBwVL5UFqD0opQ3OreIk5CBS9BYn4MZTLv LRtOkDR03gSZjlwZ1k4wvqeyTNtW7heondvVmwNCKSZMy9UmhMMKxwHDPDf8 MkNttZjE6uaXHr8gvSSYqO2lpsgSzg60FenM2YmkCWYAZRs6Eyoqu1McdBcV FMINVQ29T0EP+wNHLIZG+HMoO6g0+IZQokH3NRSVfVKtjMtpsGQ8RVD2qO04 RYCilCrbqdW0hhaMEjdWdmrRnFuoDFRGdoKfhnKuEMVY8DAvH/KcdiZIofDs 1GEaSuRS27HdUJ0myFFB73RY8LhS3IwdFo3KnjuFbC1bQ5r8ezAoLVRTIhs6 T01p0nhPBlC2oTOheNTSPKC0Gijd0JlQLPk+i74vGo8lQjZ0KKxbXqY1HhoV HtQXFX6Z4EEmYNSawBddfDJTrJPWDZ/s9LVukaimyvoWikouWUNRWh/6h+O+ bLQLJAyMybINFlRRZTrZTzJWEG+u4w6RyX44OpsIxaUknXJNO4hchE7pWyiB Dj5BRT8NCyt1Q0dQN+ZYQtqWvDzhuIwor6gSjIOPRTpcxpjAlckUrQEbIWON IKBdBVcEFfU+qFAWVItrKJLCoey8/MdQRamsvYIiNvktWs6BCtbx4mqCxCZt ULL1NbehnPfhgH6LceXzMMaClMM7CLodFrcQL5DexHI5z6W7wtIYe+5Yw4/M mjQuIvFF47iME2kbOk+3SHIRpcqji3gQK9+fdz5EMILJll/AmN8EtzsfEhpJ oV9EXX0Q7XSsXiu3+XQMb8fqBDwKm3QNao0FPLrda7VJWCylvClZexALHNlP 7+BjExxNLpZGn/EgXL1NXlFYjSUVQVd2Z/wOhbadV2ziN2DJ5Mso6u6dWGCD 8qp4EdFywA7sPL4cJcUEXyrmhnmpOvEronhDZ9kBYEVlCzx5swexLnYgYm8F jMqZWclTFL5tHVo7SUFSeljcU4X20kPTSw9brFQ55o7OEr7nhEwsZIwkEJFY F0m41LKhQ6xzWWNIstTbC1NbV5/CEZCMTWl5wdoUP5OS64bedLMlt8ayYZYi dCz3AIt0y0gNJGdI56mEjvkhBDiV1D6FcIgutKF3Wnflv0RnJlR0FZYURQR7 UL+ibUcoaVOLgy5Q+9bLAhrHRGWB4l97WZW0FtxPhypJDJ2JzlsHyK0w/enc 4mys1jRVbHjEmN4FldnTvbh/lYp4F/IFa9pz/4oxDMVfgfsoLb64f2mwryO6 /gJX0dITnWOdUlNMqBJStIKMCUYaOm8lpU5a0SRnj2G1KymVwd5Ha57zwToz kCkuqRybfY+hXZuBVGlJjV6A2tMQqVJcMWSB/C4aIgx2s2Qbo6D8EqqhN2OB 9YHrcYwSChsrHBPlGFeEirEg0VmdUsGh3koVSpefzbb2xlHyaOvBM9/Z+myo TkN4bJBBcdjz4LPRrjWEY/5t5QLndvFHPIVkyK1a9aAkBgukMwMWS3lyaTqD oICiGjoEa2syE8rctSnMxeyZBdtyROoukN6E+siFMIuOjd3B1ocuhBmDwl8Q pXrmyaJJmUKHLjA/pLrRDFgK8qBtXV1GhbnQG+KPhToXV+KX2BUsejnRPVC6 ax90EpMQ8gxkYZ263sT6cCmlRKw7pvjxUspmU2SOvKx32ourSVKuMX1vBMbj ZVJ+ocPm/M11LE+HT3U4vqYgmrZ/ImLDXcJiehLx4M51wCWA58Ul7z75JDTc hHCh7PMGs0U6p9OYBkQLp13j2caWRws13Tiz1ncRoIEiCQrC+h0VYq+BA2nF uN6BpB533cSsege4yq9qFA5JXsqoXNuEy7SCWIV0nkPkRtLU3Ci6REjGbBLp zGjCTZSYNbTseks3i54PWrNcN736fqESN5iQzpwmN0krwFeTh2V2sSTOOQYR 2e64aM6izqZPcJasAXsOp3zzBcAKr20Z2mof73OvcGDcQ7Vto1dzCuEAPxmC tUaUnuet/KMNpUGppO5a2bgPlD65008nxeeUW6yoW22ligrR0FmZD2BhZ4p0 GdlNrJ4RGVuYkRExyOVTUeeSqNIiWgNCQjpPI1jK7pwUpEu0rQArRToXjKPT 6RX7FDKDhoqpwsQUlF0XJowYLINtZ4+Wxavtic5ji4KGokp0WafScbqJzgrd 1AiNu3BdKHoYS1LM0m23ZRnbDxl+coe4UE9prA9i2sQ7qzbgrBs6U1ip/wy+ O+/yzNk5GKboxMjUWhS6S5nuyk2g+CNjJCy1aJee35cAKHGFRJJNh1n5kqU5 IWMkoZCnO7KlbovEg6e9RpKI1Onn7FypgVLpsA2oZ2fOhkSoROepAkkFbtx8 a3fMMm6jo0l05lYeOHC0wrLrWmQCf0yDYx35ceJVgesvKogX4PUx+tuZnVNX XFW4hKe+Ivh5Muv8juOyJKO2NWGq6Zx250hITPeVVcyMksGLTQdQSnkBOuzr U6o4CFYJUMC0kUxZAzF/CqqdID7eO0ZCmDCYJ7WZIMBAzFExpbjBUQFJWmuD h3DcyCfzZAAMT1mAW25d1uO7u8hGKkNblUCmpljrZpgev+INZZNUoo8Gkvq6 vNLjU2hEo9jahYxc0YaO6oRem9/qrjU/xBO4mgM80dAby9B39rvwVr/Xm/1z AkPtz3trqhRv6A0wsD07xVn8/nhUgrVrqqw0bJKzVvnx8U7P8JvT+70Jxk7l FE99GHh8CNPUer1VlIZ8XSfw8SEMpoF5z3iktpPL14cZGA9qTsq+WxcYYb6u U83jfZgoztisKruklMaDEkiHvu9QweIUqJy8yNlFOv64361QpAmqc6N3QnlP xlAEoTr/fh9U6ILhBUpbhOodTroPitrxBLVJUKGrXO+BEmALY66Eij0bnxe9 1RMietD4yaSZWKsDzQc6IJTC3cOeYgsI2fjJDRTIU6UZoshkHs32XMYSisjw k7t5ie0e42TRM3whouHHT27yMkZJqQu4g7bYyrgC/4T0toiD4Hws4pS7uKLX Z7gDqlCCCm/GUJggiHlcQel+ZSRRJLHPTLvM+g4o44CvMVc8ncKEwq0x3bhu nIqGTkrcBeW78JkkHp/1ORdugEInUS5+pHl8CEOxf9KqIgV/IBp6U0ReX1ss sRzP2jWn2kCfjUrZRfxkmCkOzIz2MuGwK7au2qxgaMz14wHhrmDTXPKGzko8 Ix829ZRVp+UmRXJzM4ka2kovvKUhsbOjOyeAE50Aa4864uM90ach4Nr7xVoG k23obUVnARL+gegNit73T9KoeNoE6TxZ6eQR4vZMdxzh5vZMV9AUEA7EMA+G Albh8arm3OuCnR6laXK9oKlddTS7Tm7nSNK5UKVk7xwTj79rl+h9YD9un48J SuAxnAVQF76UjlsMpihjcfjwHnELFtP9eIvgDukP2qzFeCEVHm7IWdET/kPn EQAqnvqKx70XTLGBUpQkKDNngvFMoSfjCSqCF0F6Ze7sdi12YUCpbFIuEzos SrVq6J2LeNknAjjd3FHpmjE34V536XZQ7IrKXEICM2RNGmHx6GSb6y2otqSO OVrckiFt33C20C7aKnU89g3a2rWJHlgB7/xLiGAEz1rwhcuZoFD8oRP/41DN FaGfA4rjAYRur+JxKIY+ZzlUUtW43do7k8I1a+hMhRBYAXC/uDGqJG8uZ4me 5Dlkh0jnMSasbGS/QO1xEx6w4gU0cGFigUqMjwkoYVRzhaLzsfN3qi/T1RbP c3rUD/C5SsRjQUhHQbxrZtFyum8BeALPYeKU78SDuB+6ezVDvHRIXWKleDd/ sIq3+MO9Nj8LL6gguutkQ7x4001yj4nsDP66awIDPIP5WY7qdy+e4xLUbBJP 44FKPCNxJ55jLr+FJ7Fyn8Wf14TcwhPogGfJD0ovd0NfDB5htLP02eS56baM h3h4IJXMmq/Jtbo1X4IN33n24eyt+epm52smf47csA+NlxFn2oeDUKWn+cOC v4nV9+ofDbo7/jzEw+4jnTXfeK3thr3ppC/Cz+LPM0pvrK9ODX2h5+FZnd9a D4qJ00x9Me7WfAk2YGb5g2gf3Zn7AZ5KcdzoeeuhCnljvgoLCDlzvq64Yb8K 9XmmvhSM3rC32JeDgj+f569yUGc3Jb84KuVnrb3FP3Qa71Yw7+PFWi52/Lru o4D0v6HDvsPX8BIUxwKga60/CiU5po6m1w3BWc6GonHfwPg8dGWh4fFUf6I3 ysJ4FlGM615BY18zpmek3cj7GCqUhXGjQxaK4zJC8r/4zABgkeaWR1eOCyJl Q+fld1zGq5pB2V5BLkRsHiU6Eyz1SWNTq3dg/tYse80jI50Z1aqcc4ZXSHuT jLEH6Uy+eKziHGO9kwMf81V47a0f85UaUZaosnfRbHBYfg5fVDXB744iZ9Bs c2O+mGAce1qtrirGod5Heqsb4jX4g5GuAhQe2TDtAb07oEDtczVWe0gqGUbP 9rD3HVDWmnhhdATFrUouopjDFUxQXHPFLfpodwdXX35seiqwTsIWE2xxjG8z haWu2mwAxfCqc3vj6h4oWzg5MUOCJz/bLu59XMmrLm4akLx876c6kmtuoTrX fOsy6gUrXb+OmwQLLi1ejIfquHkRf3Ghs0SmBW/oTDAWy9KgqFpwQeQCls7k xVMzpHM3LN76RzoLTIIr1XjqqZvm7NM8LRj2oGAxewef5l55u4AZTI1d0W1m w3tKZPgJGZyxnDyCEE9Y4pDknEfH1vCTO0NjPLkGqUK8S2lL2/2mRXwPKR1x dDq9V7vEk6I5fEWfpzQonc5vd4xkipT4CfJ0AWpzOHz8wtF5JZvgCsVm499Z gpEN2JCf7ih3fH54lBtHec+laiwnIsVbOUjvSwMbIaXLPFHe3TZ9OsrdQk0e 5XYyF6MfLpAM4xfoUuux7jqFSjkdeSyJJ80gdeicX2Z5/BeKEv2Kx+ITUE20 7w6Y3wMFBaq/gmpu7Zk5UM5QSGSHUMI2d8mV7HVHH8sAI1Y6acF57x7mo1g6 7rRajT3IhVgyzVH2KgKqLIgQP7nDI2zf6x83EUgldyx5k82YCAEmHLuvCcgT yLZ+hT+HFopfZziyWMHDzW+kpTXNCWha9qUO8dfFUl3JS+na2F7HfxOgff9S bw5BSsZSxt0DKaH6M9NNk7YJOObE+hHIfE7C/7H3r72S5MqBIPj9/IoE9sNo 0EeC8+VONrALaNU9u4NujAT0jHYWi9mCP+vm3qrMVGZWqe/8+qU9SPdw0iPI CNc9kackXZz0YtCM7qSZ0Wi0h9Vwd3WBxPSQQyhF4ttNFokdx2aPZPsmB0u8 e5O+m7vLiYWvnzNvAqYBkUfSLUN/iWTQss99DrTnP2fu227av4kZm+ybmFEd Teywm5N+HnubQQLtw+GbJHMCs517EzsuR0hsiiQ7J9B+OCc2oROQSDk6sbY7 JLYdxcJrtwef4/JIRq12DNj7ac0hgfYDJH2HYuDyc1RuiaH9eIl3E+uXMksn 0H6AZBnBjrp7kza3xNCeX2IvT5y2yepkRYFvPxAFnndEQic6R7HQfkCxozZ7 oWRsn5Ns/bim1EiXeM87vR10igRMikdIbKv7hE6GPkUCF0FRyUqFkkveRM+Z z5nkEq3HyeqYJkGi2sznzH1zgMTPVWZOstIe2g+XOHmTeZxyogDaD0TBMo4p A9rM6oCFNFogd0i8cNSpZMuZMf3EHu2A/nP6hOyznwPtB5/jSTn9nPyc9EdI /BJLlazOlNu8fPt8sHn1FLl7iSS/Zfj2oy3DdinFZrdRYIejN7FdyjsuK9l8 +4Fk86uTUqyLZD98/PyvXz+AY4mX0sOQX+FRzenitHnrfn/ExK2YE1ob2gz/ Aa1FE3z6JuniaJmjerfe+yRkkpFJIiNOxqWdDyTB2DuRrnCT2zGg/XDHkOnn TBk5PRgtj0SsJ6CU6uecJPCrc4TEi5MpmZM5J6c9HR+IE9gA+3SJxxQJZIXS B9JxGfdLPNIHZpa4P1ideVDLbk68ptlllniaOntEsZ7Y9nQyj7kNEPIsxfyG 6RKn0rHJzImfqUOyt7pL5fTRLno0Jx7JuJ/Y7C4KxHaExM9Jqjx2GYqdhFIH cwLCXu2RmBwSP7HjEZJlnJLPGVRmYkcpmoMlBopNPmfIL7E/6R5qFu2ULHFu FwVniAMGnGSixvo3yQklO7jxkOxHl5yZBplV2ZYjvQ8oNhXULvM5U6+mA4qF id0tsT+55t7ESTEfv0l6BNzsXZdeOgfSHohNp1ycl2xTvNpP3yRV7XNIQLId bl56r/fB9XCOAefWHi2x389TOsnpfXDzfPA5vVFLIpR6mZUnqj3mnTYjT7J7 sV+0g9UZtXMJkgN7w5GiZKdxf8qHtK4rnXz8mV8FbvflmMcC35Msj5Vb3X5F hCYsEb+JbFh4q8k3T5YvU6Jda2MgW/kHuwdT259etCUfxH5qyTz2ofkAbeID /XJg516aWY8Xdm4CQsfnaLCDDHsto8vbubn7aucmELibG6N1GtoEIzuwc2P/ 6BP0nV9IUAaxkHETMFlr+G+FnZsAwDOm39m5I6p8EuK2b3YpS7RXYjtywihw wr5xbaKNQttmp9eLTKGVpwT6e3QnqnzrzjwNqCQtX/R1KEA1L1Ozv3wENwtF pvx4f1yGSu3dJrxSgCkzWtM87OughZUUVuT4Ks0TqLDCfaBfmur0OgTt5a/Q bIcHjJ3r+G8NhSEAfugavYwpoCOqfFIcaaZdYnftFxAisaDCQcwmfbdrvkaj N8xaH+XDQ9jQ0d+r+SeEDQA2iJ8amrOw8RKc8KWK7kIgy/sJq6C6Fl1YhlEy 7aoP0Cb4bz3tEhw65/FdMGL0ZJzDuN4nQv/oi4hylqBAcqjNuxkn+G8FFxAA GMtXLvhgZGtWVAc1CWy7enAGVFjLY9TdegnYCef47+F9onXzTggBKkl+zWsc 2+2bu2mRbTsmqCj8qd9IWdMpyX+vuHiYJkUFPgtqcCsq2Znw94prjUs/UKCj sFjTaInGoMCFv2UrGHHhPXU/bXIyFjm6ucxrYV5ByPoV9xHhlQn+e4xqlMm8 a4xy72cVUX1oJcSA4t9jVF1KDZq8tJdudQqUkICc/h6jmva3yx4VJH+GpLBr phBMVE1/r8zV3qXJo2Ltq10/UHRC8t9jGoXLj0tUEI1Fbkgr5/jDQct/jy+q u/1NvNdO0BXGb7kFTnzXt2/VNuSVJuU6WcY/89/jydJ7rcKjElQoZliv4gtQ OTHLDCrKCbEpsHQblZ2XsUsmq0Eu9PO+cs5tVJBJqNu/FZynUcmcIiohgMnp 7xE1jJ3ce/ABKkXeTDWo/LTPmbcSdKW/Sf16iOqGmJGNpnycXSzd4PUl8IzB v01FHjvARalfxRm4IDHboLRba848gAsyfKjexNoNj+CiXAEqpk1/ABeRhBtr 9Xu5kzWyo090HOJDu7TTmv8eEWqr1H4/lOBiStQV/ax8mzYf6JcChxHQZggE ZcOuWBP9UiiyQAWRXmXpSDasO0UJQ/tz6451vGiFWGd/0jAPV9QBXB3FVq7k fjeuBk4HEBm+ktX9uECbh/CTldzvxYWeQsjSazaK1gG54y9HVgTo340bciAg PPlv0uOARyH9UkEOAEDzrjfpH61oP9Avl+90BZXHBLoiOLjZ9Wzh28QH+uXA ZjMtnbu02RAQ5jXZOFm1rWN0BzYb6r7abDyI49PJFo0TH+iXo/eRS2t37wNA 4Jq4+m/C+wR0+ffh7hfv0zrKDhctP9Cm+eOOVh/6dxe+kgSFIZdbTEbw34qz DX0HTlI0bAESx194aNjy/S8NWwSFr8taFWLS4W/dS3Fy2XFn2Irfd5CL1za7 InA0NprbVvIOqHQSzbC9Det2xRPBcZqmqinIbnqhCc27XcGjEsQqS4Fb6XWd A7JMkv7iHsg/ibk+AIC2Bg69vQsVWwEJBIXXRrCAJbgGGac39SAcqGQ2c6+t 47+VE4Z76eCa9Vx5iOvi4Ozsfh0Npk2CS6Goc9xGBcd5m5CEQUId7FiDylqj 9sdKQMVxAzUfCGfBDCrJ2V+i9SkuIh2VmtUecxQbgUl8PAAlkmnlLgKOfqmS D/AZGEyXkFb4wNt2p/CFGsJ9HVwZxvONctLx3zrK0h1paXKDyyAuk+DakMMw pZSlMTmgl6ZRtYqf2JamEo3cE+KdTLKK8EvZfFEqRXg1rIUA0VNVPvHL1O9j izyqlq5V1jwm0Kb5b5XskhiWCj51scRgNaoouyRmePSzvyZp4wkrRxZnHw+Y nh1dzb7Rex3MJewowC0ezl41SbEhzK/Z6+6tAB7qbSMrUQ0qg4pyPsqNvLmN qlXSpKg6rquZCAn4pUreCIyj9ppKsobwS5W8gc/AutDpW+m9FLwlI7CaM0T5 ES9uGHstyV3M2I21ZG9IXqyx+9SPNxkb/DqIulZNwvitiv/WcKMHcBQkvmoS 1agCNyII7rKrOkhfWYEsTBnm/cN9dhftl8sIeJ3CDGZS8R8577ch/KWGwijV FGTnXwsgBFRdLVV4EKKKUHAPph0ufvxfItexsepmbMmkxvHSOcKjNDn/eGzP u7Z7/msvHYs8c8s546mP7XlPfdsvvXj8Tay7hqQoLMTPyc5NA197dRhZPSzG ftQHHha2n3a+K/AqK9ldeljAQro2eFjQSuKeyduvXUmFcz1lPCyo++phAWjY UWPVN4vufKZ9cjlA5eWGm0ddg8rLf7G/pIdPIPkvNnW4br+V68BFP0FF8r+p QdWDTTLzVmQj6Qo+8Ib897hIT1kD7o4rjW0i4rsmUc5xcMwEs9/h4msVb0um 7ej4Me13EvyldicxkI/M7ySbzLSMDX6plNhG0b2IWvXNgtps0zTrfZFUYbRj o/rmFglq+tHfo1PWoFSfUD3ebYHW09AFcxu/URcbYcbfvxGqhuwdm/vXwy+8 sZAaOAhK1a/aZsFsOansWpk84lJc7TDZ4DQZ4sr3Si0F0ep6YVPwWuAxty/c CtZmYsdtYQR+LVHl4AIALd51Bt0ctkrV4V+yyRWFYfrv2rkUu8VtIijXDQrb 87ESsCvodFc42OUOQskAiTrjTa59TtFWOfqja+ZzxtxW6c9/B1vlKPudYzJg uYgI3WyVsJDGNHGr1A3dA8xreZ1AKE1Tq1Updutpk31XJebbyFbUfbvvKs4h WcTrm6rDXbuvwwG4NIWUF+C6yK6SbrwKUh2ACNpscbdfy/bbrF0rLkn2pwJc l5laki1Ocb3VOmkGruGrA1rEZSQdIxLNv973icZHbMnmG96sfPNVgs+EiUCD X8pwff32l0+jxyWtonu0ZOuVSdrtmxu5dpBKAc4l7EuoPkAb3H7ZWFtApnvv 7Np1N/nyl+9/gj0AAfHV+NpChVfLITtagIisozfreft9DBnae2QXihzhZ8It iLaUHCX/mWKZNjnSIjK8CIHE+WL/mSmym29m6KbPXbxZh7lRusM3G3SjNtnW VmSUr1xH77r4Zimym28myaegT5Hd8ZmQcx7mLNLZI28GBjdPgc1qCtTgpk1/ y7RPsmNovB2FI34T7RjVqIIdQztOAT3tBVAFsrAdaazLBeeIBJk1TZVu5qmB xE+XolKlJnDSpzRaV7zo71NUiXVlrV4/+YPCOMwB1e+f0B/Uo8PcvCAYV9Uf s6OJkCPtyLKYHJYoLS9Umtl4kt9GNXa9yaBiR631ZFmEyu2z5glO7uu1gRpU ztk+uTGgvL6wigVzdWNDohyokHN4v4lEXMWbG7pJoNSPzhgRl2krlTDdsb5u 0xcTpS+27m7GoCuTWWtwQFvLf6sEhTFsIngAVRQUAIK5kPbnrgpkccqgLCVS azJlXLCyXFBo1Df9fK05xKqroe6zeQNWYie9ZsavxhpKyXpsfKWkmc/BAUwL h3+7mhOdujT0jWrI5n+B9oN4LECS2vlyOSywPX8YAySX56g73sQfxnZpSi6R lBk/BztM6eesSDYnunHpDk50YIdNT3RmaxG+NH5qpQMiv4aGQ572Wjf+UrVV aUyi5QVJIpe0MrVySQuy34fjk12RJV5Ua5gMdt8cDrVuyPGwX09ORT6MXWKe 8qg60qg228ERqlsiXDeYumzrMVH0Wtomu5RuKDPlWInKJVZZjfUxQTlYTUpF qIZ0R1d8j5ZuK6r4Hi3iQkuqX9saEyP4hOw98T0qVsyW1SO8ANXSq3Te8VgI 6k+imN1xLFTkEdfbIZ7koK3hv0114A/BoUfUFqM/fOYwRj807L9zjkModE+I B0Pf1nX8t0ZEIABunevFIwb+RFRZ57HRtGaXSNADGNrk7Hq36tsa/lujangA 8uaQq9NENaqgaiAIbr77u9UKZEEKqpZLIRt2JtwgazYel//wT//bB/F/fPj/ 9b/3HgiLKoKhbC/S8ZcyyvwyfwJMLevlKaZ2T+PXNR0McoSiZhlUSRjTDSIy 7Ks77T15go97xT6jDEnicLW7fa+mVJmONiyl+UDaJ9h0vTatJCa49JsXJdZH upTS8d8qEpe4Nzem3XBLLapI4lLRya9ZT35KgEaIf6t2Qo9LYdU+XYDr4kC6 D6wBVJLuyFbTZgGqsWsTrxmPioPu1r3+NirwMGr2aoNH1ZCz0rqp3kYFu5dO UUlHIn1/iqlYxEj4wlDi9WSHxl+qeFtAvmH4xITq4Zcq3haSzUN7tw38pZK3 YYLRbJ7IHFFsBQ5z3zi6UezXnKedazv4SydITJq2PQV9+pYcgWzi6wABVznX Dd+ez+w09Z3eHYEgMj13BIL24yPQlCBZ827t3iSfAAw8Ucbkc2xdWlBAkr5J LhUZth++CToS7JDkLvqg/dCxphPpmxysjjtYHY9EJW+SS8aJ7flsc26Bwh4J koMlPkgU538aL1cHfJtzxIbtB5+j9vlP7kEi9bBbHdktKrc60H6wOopKBW/e pLdzV3ne9kh2h3aPxB6clIHZNydl1YDPLxy09g4d+Evl3i5tRwfTcTVv+baW /9bs7R6AxO/GUbcaVdjbEQQDG/d7TAWyIIBl57h2+X7K8JeaPUZ2IQItea/O 1umPMrgG9queUBBR73fkbr8jy45XcVj1hLLg/ER78aj4YrAGlR2XJMcLoCLr gqpJGYA6VeYDyblqDdw8RnVjC0UIvFzfqwkRV/F2LMEzD/I2zZss6y0Er+Pf yvfCEjTSbmLqD3FdxNQn7veyQ03IH2k2KelvorKtEfsoao9KkrmJT33tZraq NSHZWjoyzXtjBf5SK7sw5wbw4kbgGP9S9LdKdhnJFwYxTVI9qii7jOQb7OQr y5HFKdOGkA37czz+UiW7sEI9sPZG4CiIm8S/dcSqNRev3Ou0+EuVHNSSXmuM gbgRlay113oQTZJwNUMefuNF4askcIvqEsGZcL3CK0KlE3sf1yWCZPxNFarO JkIV/e0ghL3mrZyzXtylqOgssWzkc8lbNcnpUmpBdsOQ7ErC6jUWUbnSY8m4 S08HLthDJvU0tueTq8LZJvFtbze5YkvvQ9IDUnegPXcH1Qr6pU8PA92B9twd HZDsLuM6fHsuMz+2Hx4G1F6P72Qu9TS25z8HkKSrM2U/x7cfZI02k9gf1Xzn zJUXet8fZI32SC4/Z1QYjJC7Nxvbg8z8HklyDViLBI4l6WFgzlAsth9QrN8U xj2SXlWHL+xPWb1XC7Z0sj1ReD5dUzsSo6IsX+P7IZneyrwlRv/fvsxff//4 bUZ8JAySE0oG35ePHo6uMv32q6NfN3zZl6+fx+8fv/9COBsSxsmemuI82ga/ /f5t7GEjVI7NaokGGARfuQYoWDNNDyrwS61K04B0BzeI9QpANmClw79VKk3D 0n1YrbbVqKJK0wgK+5r2VroKZGGPFq5l+oCPbDFygLHhTx6bvblbjHKcdgYb OLXfeoldmtih3+XTB0bN2Z+w/cDqI4dd3nc0CWQkI7YfCHo1usyb5OQRtOfl kRuaXTphFCX5z+kPyo34vWIX2AWdc97q2J5/E49kVx4AXjsX2IXtB+LVT2wq XnObH7Yfmo5c8jlz1svCtx/5e2BCjj2SIRPshu35YDf4nHROcjY5bM9vw6Nx U7LEc84mh+0HxAYnp+RNcnZKbD9YHTNnjFg5OyW2H67OmH5OrqIMth/toMMu jT2OeMDFB7bbEfaK1LB3sDoHOt+4WHFpFPfvleUdbD82MepHkfSQMSURBQcM 2B8woN9udzZ+0Co2GeiLZKyUNuGdSR8EesCu0JmQjtvvB+AW1ENURzw4HeZk vLFTe1z+aOh0uzk5FeV3HPaVRQEVXVoN60m6AJVXuuT+EOZRccaYKlTL1O8z KQIqdt5Yz3O3UcFtYXLKFA4MSJ6IkvQg+EuN1UE4OEa7xSaqA/5SYynAzwC9 rd8rlvEDi/U2YWkJXbO/vcdf6qwOWIIUrwv3RppQnLRGCRToUgIZHNZLcoFZ oEQmS9JVJRAB0Jc/mbFyVPErDbsaNXu1GX+pIgrT0SXGErPJ+zZPDvBXFDtz eqGtExfKMXsvBO35PQg0yZ3kvwPJSAeQS3l7sC/3B/syCO1rn1MWnrfYJpG3 fZ915nRebTrwK/U7WaKP9k1zILX9Qk5BssHqtuzztRFEt5N46iX1BRTGUNTr dgMoyQc6zYmkJadw/6qrabAIVTsk4hGdwkEQVWUpdWJK7lsEuoS7xmwC4Ypy p04ikf/GEFMld1P4S5WkxdBsL5+XvQ8t/lIpHY1kF48YixuRyX1t440iYDdp 9v70QvOB65fIsjBT5dIfnclhq2R7JblRmDo3irFLvaZlzl4J7Qe6qxrH9IyT s81h+8FFfdvpRAHumzq5MbT7KndD1425hB7Ynj/jgBjcyVJrTQ4Jth8g8YfH 9LY/a1aD9vzEggDbiUHfOWdqRCQH5z5phHh0TuC0lc5JznKK7fmtYTTTmMrj XBFQbD8846SHgilXhRfbD844vTPpyWJFUrZJjY1JKfYimv3yUDBs7JWCvdat 29sC8ZdabUvalmR5DHeENsN/C62fW5dnhMMoHxYuhFFkMa4uz9A/rBu7PCMU SvTVeRoud/lvlUSXHAc+7V2eA6q8y7Prxl2tAw9gyBjYr/eu/k/Hf6v0UwAA R6PES7kCVdxnMMcYOKAkG0RtjjGvHjt0BzX76038pWrihSZtXiRbKfxSuZU2 jtShtXxSQNa4UlfCSPqNQ0L12uGa4945dBNwx24Co5293rPTPRrH5DWv1mbf JvhvDU0gAPrP7tm7AlWYsMYpSplJZSsMbPQBmSo0NcMlXOpMl6uJi+3HG31i S5mzuwC0H1uJd/dnslturniKJLWcZ9ORQPuhkWp/uwmdcxeT0H5o/dun//Kd c/sRth9cTHokKnmTXGIUbD+c2L5NkeQuJn27PLQS993++DZkzarQfjyxaXxi JRLQoDIbfd7oPR18DuzRiZV4knVX6YAkfZOjmnPApxtXx8Y1dKCZ9wYH/KVG oDcWS/2o7fbHqGxlSr/G8jkyifvAX+oEOogfSkG+32jwl1qB3raUoAXdMFgK Y9Jv/FslhTHrN1iOkgkrRxW/ssV6Ahfn5cOKPxfpTZPsbw0WtIMiXKt/YgGq RaYhER5VS9tfQR2ii0ypzf4U71GRytfVoILaQUn+Vo+KolrW2kEFqCBzwJB8 oLFkpkgUZfylin8MXHNDfEzCiqari8/Fz8BpT0g+fGDxOb7BqlSgXK1pbBoo CUV/71DeEQ6L7MUkL9DWZTFG5R3768t4RYQCf85uPQY0EBJPf6umDCPpQbNd F5KU94Aqr7wPwxRrm0ZU6P3qDxt7dRR/qZReWhii1YTA4Jda6SUkC9bVCdO3 tfy3SnoBAB5R9qawClTxKxv2rsYkQhf+CvhTkRIJZtnkfnHKqSnYfmAFwBIF +2OzzN9D9/LQRmMSTbTP2a2w/cC8InubIjnwV+gP/BXgzjXRMHpbrWG0qSnh 4Aq5P7hCHtoldQTpD66Q+6Mr5N7pDJKDOTlS3QyE3SRI8tfq/cG1OngJpEgO XA36A1cDqKGcushlnR6g/dCW16ZXGpVIwE0nVayzLinQnp/YwbZ2SpFUXq6Y xaTpNo6yFoLI2KqzTQgWSKRlk2Qbv7EdN4p39k3cwdHJ/dYe2mB4r+pNVDgK rACYjCBRzrDsF6CqMShAEoh93UNAxQmnNlUwS1BNSa5BjwouM/xOuVZvuI3K 63nCJRpVI8liknj74S8VezqNjSrjTqNa36pUDfIQlkKOTayxFXHZ0gyIvN15 EHDtB5vczsZEv9Rt6h+chdQBvZTtuo63S2dgDumdku1RgZLtGs5sjfmEfJvi vxX6AQGg0Tf5xnJUccIwbZhrN7mtC6Jt0I9e7z+xQ16EGLfb8URbUu32MQeA SmCo/b6EAP1SIW08AHh/AgPtNHb6pYrq4TMwri9B1VZTPSYEgcnaHcTpl0qq bzVL1GS64JdaqteWPrNfU185yMpFf6tIFdN8QVjYbteoQRW/ErP0gF17J7/o lyqiUFSyxHQJCylXFQnpAWC2IGPTWrnwdsVjiLTZC2hABTLCimWzAx2hukVf CmYejnabfaPktdq9GwOgUmTTrvzCce97AKhY1m9i+26islDdJZ0s8IgDatjZ eFZU5cyoMP29DFkKN8yodGUUlweBCAKo3ZRICfillhllQ4VN9Zrdzre1/LeK GWXDl4XJjJWjil/ZwL7Rx+weG2TwSxUzNnj15T8xRdVVSugGXbMgHQ6pgxaQ yBb/6nLXLAmK2/7qXGXOMdh+cI7xp4c01OdA8R+PfdF3Dqj3vIkcl/HK55Sd HuS49wCH185mTu+aw8zpqu9Sf7XDM4hfyPXu3K8hsGmvQkWCDZs29WwKZIFm 3ViPJiLjetupYw93Xx17PlisngrEu+pPhMZy9dSx2ZlXMMPUxazMXgu7PN71 kAgxY1/B9rx9ZfFq6uXU3oHEn+52mfovkazZcUfT6pgdN83r6AqRgBmgPUCi r83JBom289GbeHJLDt+jPEpW4VdxrWnjFzDIy72+gb9UCnKrHWnHbbxk/gDl bflvjSBHAKxwvNdeKlAFPrCYYx8OAKvSYZVQ/Pf4jKP3eYMBlaSdbz0A3EYF noX7+GVAxbbxVVEoequkbjagami2Vk3oENUNRcFCUQVMC7dye8FrjR7RXhWy ytBr6b2agL/UbKBWgUEFziUJPai63FH0GXhVst+L4wcWa1VWWiJTvbPW0y91 4tpK9ERpzN55hH6pZUYBebfBr39V+BTcBdHf5qJ+NhdAd66bo2mbi2d7RHCM g/la4//vRQS6f9durCD3IYIqanjejQ5O0Cb4b5WcAQCkq72VpwJVXMBG8JE+ WUD4pYreG7hl7KXs1gNJ57Tmv8dc2O7DTgAV0/sq/Q5R3aJ30BdQZlW+ltxf FAMqEn9r8coCVHDk2qdT+YCp6Ub/gU3NW80uTdfqAUDnB8PAfgnxlxo502Gh DPAc3+XNoF/qZIMH0VjqTa3v1UGJiugQXRUDDvhYcHHGUIUO1q7GwRpKBHWJ 4p7TxrA9r40Ntp10ogO1deH1oANlkGSOENieP0LAmzSp3p67AYT2w8+xyQXE mPXsAS3t8ARhL98EXjvn0Ibt+SszqAo7JkhysdPYnr8yA6fzSw3VLU7l3Jqx /QCJn5NLrf0OJHDbdYkEiCqXfQTbD68RdXrUXJ38Sh3xdeqIf+G5vq2MBckV 12sz5DE0pa0K92N83HZkvl+tjw/iM7TvnIXPkLuG2e+vGXxrrolB9X235HNN 0Ptg0One4prBeSPXBO0QuGfvtcG4dxRrg50FgyRsHnt9F3+pVOC6Fs2b/jPX 80FntOG/R7uaXly/N292bcs+zuvBrLrSAylMCIDaRDL55ajirtaCfwoockAd W88N+qkpzDQx70SutSab3wHaj+I33NQnSLJeCtB+7HQxJUiyXgrQfiDohl6m e1kuMAbaDwJjBrUsiQ1qmCqDQFS/20EQSX5DHI4CY/zqZN7koIrGwefAnKRI smFL0H7g6iD7fQoP6JxbYmg/WGIz7ekETIS5JYb2A0cUTye7DVF3Mre/Y/vx XrbbmuuRQETrpRkLtuCcugLtB+oKIEmqVqpKR2RQV5oUyYEjMoiMjRmrM3BB BU6nezMW/lJz8OoMWOphQy2Qurf2A9Px/U1ymIBfqg4TRvPF4P76M75W+TZl IAG6HYdpb2PGXyoPJtqx/0DyjfBL7Z6nMJ+El/3RxRDaFP+t2qhUiNJPZqwc VfxKrOKBWvn+K9MqHjcIDAO9oGh3oiRUxox5gHBZsDlCC+f475Uj9JCceyWo QWCboQ8sQwVFuxM3kE6GgKrVGHkbFWSOdXsbgUfFxFXzgb0VZu9kBKgEmTU3 VpAjVLcYSEJ5GOc3NvxCh/QplcW/pb4IXz5/+/7z1/nbC4GOdljIbBTQdfej 64gqUOVGdIHA7kMnSUFel9OgccVcNa5Yty+X4FFBmk0g/VW2anBGoL9HlDEu Sb16WjRYzn0A4Lqc5fJQoBGXL0Eo2LztgODwb5mk2FdX+4BJ4lFkcGzoPVj7 T79//AVwdZaWFD7qTlz+BPXf//Jr/wXQtexDT8y+2QDW6MniDQBducFqnchZ duWu2QBa5/j8WeOOBtS2z9wDqPD8pEY2ccGkOb8n0d+avQQBkOH31FaBKkxY i2mA4AppU6fKgg8Z/q2SRC2GTwJh7Ce/5fDJ4n2ppeKtzTTuD8L4S82+hN8B Tj4pKlvrRNZaSEkNGsHeioq/1NGqP1Gz4N5v4/hLLa12QPlww/IAhzOBAQBK xr0CW4EqfmWLQdsyJOXaIGuTlNRHyD5+mr/DN7aw1fm9qU2WslVVMdseAHxz Qe1MvrGt9M31AKwXENk7rMzmOv7bFFmAuGoxIGN+JJHzKLKGfIZOQYZ+nfNI 91wPI7N0RjplzgTrGOe8WUvEf86cGcqMQ+rKY8gABE1wJPediCTLyDYkGy2+ 1D1BZSmTwsYJ+bCk4C2ZSMddL8bqyhNOJvEc8KgM6T5VRROXqdnXcgRUvN+u GnZJ/cVe72tGAypF814wWRcfmCiKCICokh0yoCrfiwzs3JhbYOdDib9U7kUU Gqnkvig5/VK7F6mOJ3+jw4KvCv2t2ovQxQVQJcpOOar4legpCpI6RZZ4it7Y P6QjNd2tt7x+41D8t46DZAg33xDYEa71YOkGl3g0e1QNnZw3zHgTFQTCJB5B rbSOvrAGlX+rcR/pA6gootsWTNZFlHJyedCij4udumV/hdOuPi6F+zaM7XXM dkloXibF5G4uoWLnxr0VC3+pZEZ0lunTSGz6pZYZGzquDW49X0lnwt/mwtFl DQf25GiaPlx6sa9L27QkoO3mFNO0iv9WMXbTkj9z4ttQgSrMmEFHCVB+99qc cZXO0QYdJUCZqLIwLL0XnTta9aha4usmmrEOUd0gMI+LrGvTykIlrzWB5p2g 0oRq3Rpvo3JQSirzhYpQrTKi6K3a3GQJ0rv2W6NxxSoJMTaOjRpJiqr2FtVD kKVuE0BhDDi449/4WlDMttlACT6M7cUB/lInDrx+1ZDivd+18JdKcWBaCJUE qbd+kAT5TH/riLKFWEmwFa43ub5N8N8acYAAcOAf9jKvAlWcMdMSAQwbCs8s WtE3YnpSMB8kosUks39DtGAuC6CK/d5l0mQdN0jcoFm1CZlgNgRmVK07F04K xnAmBGaKjWZhunTLOdoS3oNfaolVaTbnrcE4vk3z3yoCUxhP7RWHve2gAlWc MQXqMgSObeQe2PTp74Hcmwa/TSTSWEGiUvjEVfm7jcqNTiQezkZBNhKgrw3Z H6G6tY4Kk/D419rIvdtfOHZwl5ygYtfDmi8E1/IknM3IjihVJJQqu7qrVcyI gvtNInDglypmpNscT/MpKl15qjNYxBlw7X248ZdKxhaWGTuRXSK5ib7NjA3u 0FB5OpKXxjS4+PfK2aJPSKJBKdFMI6fRhFcC3ZL+VvE1qqTAins9sgJVnLCm YRegla8PP/HWSsL7IK0mkw+/1NCqdtYRqv034i81tIrfgaj2YjB+YTGtaoem Xa+Y7GkVf6mjVU0W/65NmEi76txmHzTWOAX74lr5WkOFUfpbQ2AIgF+ZvFg5 qviVXcPvlawk/FJFFC2YA4Edk5VsE3PgDaJoO+Khca+Y4C/0UrcWMhBFi6zt le+EKNq2mihaSciGZLpaWa1NaMPZ4DaWSuna8PdAgPVu6JM9TWvHR4z1IKzB xYT+VtEX+qzA9rjf0ypQxQnTcD/u5LSJCDu81L61kljSEo4+e1UOf6miVR30 pYTAtKg73Gms7QaL2Oyui/GXSvrCtAQwXcl7hekql4YKp95PV4pLVfse6QZk q7Vdy5nlAE9jDP+tIjAAwBdLBFg5qjBjyjn2XNkjw19qiEI5MNG7ttsEyiiH t+vuyu36Mg1J+hLlwE8O7ln2pIq/1NCXokAZP+9EX3AyVpDKBv4iSRRFtEN1 tUv/TtfMIpeqH9sPUvVbscvM5dG6XGYubD9A4vn30kn0zjfpriAp8qr0S70r LeqsbNYgkG1Eu+jlQUQ7fE+XYtmG+W99M4GB1oh2RepP24n9Bb5aFbxS6aEo 95FuQ/oQuyLTwbK6j2jn7oHm/vRC1I78uVcUIx8UCyEvtRQJ2r1SgL+Ufd+X r58XwmYNqxh7kYa/VIo0hQqLtaN8MAZUYVogP5HzugXci4gkkCiIAT30TYi4 aObHU3ChSjDxbdxjuPDsILe3l7IFfz78W6URKKzIDv4XBe91feItV1db1Sff Jvlvze6GAOjIkWxI5agiR2M6Xb/rJmnW8JdLgs9+IG9txtFReZ8Al36p2o8M qih+qlijg/3I4H5kKvYjf3yZL6Wmn7JFZ8InsP0gWcUyDtOjSBYI52qOkZRu JbvSMbgJZGIssT0fYwmbmk52krWK48V+NC1H+5EVu8KjiMUe7Ed+IdeShcQ3 yJ0rRwVC6ar3I9Oy8r/a7ArcFZepcYlCZVoyx2+umw5R3ZIaZEH34rrOi1JA 9dY9KgjgAyHbNBWo/Bfq9Ashbg9mfrVmFaHqkws1ZEfUPleVMSzisR5A3bd6 gJGsxO4PgvGNyvUADTk4vKqUxBvgL7U7t9INvVmiVSj+wAoZK3HTbbomUXdk 8e02OwQqiYHonkyTF5PdHteN04hscR8ZZSKyZVvnWKCkYlVgn2oQf6lkamHJ Lpac3vCX2pVsWoqs0OuxUjXG8d+ylfz+yzfaehsUEl59gje4Exnv4g0ydjMl t2wVqOKUNaqh99pccR7ZeW4wknRBRdxPP/5SQ2ES867CeXdPYdJVuq7gd+DF 615UxC8sFhXoBYIksT8SBf+QCmqVGHQMDLmXO/KOoGPPw4ZMYyuB+TbFf2sI DAHw2juZsXJU8Ss7wTvauncIyJFCf+sIjMy4XlKv/iaH+vlFvuEkokW2HRtU 9kyEv1TRasusnUS1Sw6sLqdV+AzUSpqdDTd+YDmtkne07tResuIvlbRq8GTU hOP7GpqEv5R946f+1xlezLSW5iuhe/illu61JEWuWxPCSiiCTX+r6B4AkLyS 2S9HFWcMU4ACP+63W5mmAL1BYCroTAmtKl0pDJVmXXVzwj3yaLnQL9uEgxQE vwF9rZqcVCh2JAVylaWzNG7ZHSx0J3Pl4bH90G5n0gIBmySSm7J749yuNq5d opJdGpl73sSrjGlc9qbywuo02E1j3x6a7cbkTXKJNbH94MTm50Rcmdiys6P/ nBSJzh/7pDs69nksacS7Pjz2dWpjhpQKr1aaIC42ckzJWg1RUv5bfyxZLQSM jIk2e/zA7pvjBzILOMjsCw6sbFQupyUeZXRmt5XFR5lVHArBqdxXbwHfpvhv lTgEAESVvFg5qjjxTbBiradRL2Yt/z0QPKObdOL9KDmJXDuv5+3bqPxp1I6J DGssWwFW5aQAlet0kqxNYj46+MCNbnKE6hZJQFZW/MICXBcOrGJ/dJeN5qNa sohNUnPgxjZERwX/Vsk2BL9UbUMNXu3L1IMxfmA5/zQNv9Y+tgN/qZMPwoEu B9NF37jqOfhLlZ4jHDjkAa79R+IvlYwtLDE2MRAxtm9T/LeGsREApddeNalA FWess2yiWGlVdELy3yq6F3iGAb/DPYXhLzXEKjp03fVq4f4Aib/UECt+B6JK 30qUXlbHL2wk7T97YsVfKom1xctq/2J73sZfagnMSLpI2TjzHx7U2J4PNa5H t/9GgwcPr0avJoVDRKv08que5IcURvChtuCdVodP1Ui9F/WQ6JXeao2z8m3h bxX/aEtK9Lg/J1SgiouoUY3275UsIvxStohs4hOapmua0hdLqsbd4B/dkHEi KRSAv1Txj+IwpGTfwF/q+IcSQjfBCWXDP6qrVQaFalua+kRGwC9lyOIFsIcx dOFXYOi4yj9Kkn1vSOerXiEUmIHCjsO8uoX7tpb/VtE9ACCqZL7KUcXJF6AC wA13QqsiUQGy08WE2uBNuX+pvTUBfymYdqbShueJrHECqlgEPN1e58riWb7O 3/40/tL/isgUbf2ETGxeisg0yY4HgFNy+yfT279ckQZszxdpmK126T1kLZK+ 3VVGuESy5rv3bD41qj9CcnnSn6EG2fZUuzkFwuQZ0wREgny8vBDZnwLxl0rG b4SmtV6tIGU7VHL551GRLrWsh5ECVMs0JOcaqKBJAqTgra4KEMxmDe+0nrVu Ixqtm8YEEZjOzbzUbL/+47ok/T4CoBU+kR1N4i1wYxP4gDFrMFF7AfmhPGYt CsgPFuLPoHjgRoBYgdYBEZKSBpNArEuL/WNdWihLS0D4iZvXMuAQj7+UiUcS Rn6mSdJuN/JW02Lu32lDCtPSXLwRgKBs3Cv6+Au90d7awd0Zj5+jj58AE2YT GZMKi/TL5Qt9//6Xj58QVavHUYRX+nn2PyAqS7JxL/jxl2NUfl9NUYFQ6Jfk 5vYDm8sPUOkmg6ql7Wiv7+AvVz4w91aGUGXmylxDlXsrLmyZmSt9BdWQQ6Vo rvYMiL8co+pzKygJVeYD5bW3SlFhvgjgmYRCTWV6vg+mIy9gZj9QdAKqbq8I bPi4A5e9wH3zp+nXHhJ3fcDsE/Br+mLlIbYbdKgcenTJlJnKCKoP6EEBsw/f eZF6F38qE3+/ffn+8dd5BHSC0TGJiRVben6P1mvbq0V1YTW//uufPsOraTSL 2oy80cVm0a/f/vIJ3kt3rB8mvP0h4aLNcvr+USx/9O3Tx++ADGxE8JHpizWl d8Bfv4zDx0/wmegJD/7mJCtWI9GH8sABNhJ9UHDqhilL5A78UruXYcwfTELC 5GnM3xG2af4dFVESPd3lJhv+Ah7pN25C9bdwAQBVQqYmvtP4p3kav/yGmBRh unipPCYvF4Zf/uzReX2kcaOIWb/9KWuavyy//IYb2weUQB7lxXrmUQ4fP2Nu 8mns3DK3kdc9mYEyCM4hhOuCNfO4fv/l62//+p0FBwAwst8/+R8QF1HGZR2R PK4v336Z5y9h/qeYeGj4bZn6+VeUaR/gKAj4LqjjEt8Y8P38f85fPxO+wfmX CyfU/ucZfkF0ltBd8NTt1xtczCD84fdfN28HEtf0qoBELtGJqdm83QZhSwiv U8r//P/6+//5f/Ur+K8fm//44dtH+jJDkNcJgiE/fv0X8R8/9N//7BUsBNYE fJ0CVmBj/uOH+VeBoIo05OsLvgHVAEqjSgK9srYXoNKDfvz4lWAFwV5fyBXW +c8dv3wkWFbqr6/aOsntf/zwvf/25w//8tv82wwIPjhCUMDPf4u8Ypxd41Dg PX4ChBJxWcJVwMjXcOFafEBy1Or6hN7EhZP0oSVcBZwScelov/wzzhVO278A NuEIW+mUy//4Yex/HYi0hSXgUqbwxPkf8BMMwdVMbRungw/u6yfw5BbxCFEN voVgli6QiH9L4gHOm+Et/tJ//fr5X/FrmEdLF9fj8cf1IKB//mn6/K8oYj4o wlO6sIRHRzy/fUEsyLtqrviqxXVjxDL/Pn/6jtNjCFGREPDT6uXWp5kgNUEW iQAPqf6jl90IqAjwCjGOW0AvdkY43QdRK/jbr9Cjh/+H/tOHr7998tJn+mX2 GL78hnyFpgkPfIUos8DE4AycoUGyu8uo3URFlbpHQ/lHmruGiLlg+f78/Ws/ znzqaNQQUFH7C4Hg+vb2EFmzmc/+yxevdxghwEFo6rttzDsovR+Cgosa+f/5 +dfh//M//y9//w//6//8z/95VWmn4f/2gV7gf/V/P376+cOXjxPYoP3ifIen prHOfviOlrdJGulf7uXP0/CTJ7v569/49xWi18v/6DfBD7H5PzT/XQ4vfpU/ fvr+VfwNHrpt07zClj14ZfcVH4XX84ZX084IHHr/B7D8BNgIuu0C2MULPP00 //d5/O37/NOf+k9+fb9++xtYJqP75nUeewn5k14VPy7Wj2mGXnUKkXn4f/j8 6ZPXXD9+/gR0+W2ePgx/+bB8/jp//PnThz99/vb97148d/327f/y4fv8i2eW D9+/wV2w8lP1F5gp//x3uv07v8R/Z//u7/7uhfF5PN8/+75/96ffhr/7/PXn v3v5z9/G/sv8YfxT7+fYz8+Hj98+/A//3//jf/i7lz/grKfwHvUsXn7pv3wc ue0nfA1lECb5AV5lfvnfsfnjN/+p2G39b/+7Ui9/+7d/C8PNX7/6M+rrh/nj lw//V+Q+7cw8O9/yjVroTafRtwzblsV+8Dhefv76+bcvv86/Dn7i5asW8/QK U6lpdja/+mHFy2/Lt5/Aiv3t298glt76GegXcB0daU78mYoe+kH7ydGz8hyM uFZYQNUOL//8j//009//wz/85//23376+3/6Z1h2NXrSeA2YEeqyk4d0w8vv HtPY+5PTT798/vzn377QuwxCH73LoBp8F38+kIh1j8HjtQJf6L/+4z/+l//t nzIv5NHHF1o7AWD3sn2NsWlwBgNhv46DNpPpaELjcLqdX+Bw+3GF0uNrO0yj XwEB9x6vfutAGOwGq+76lz/PXz/99O17//1vIn4rJdQ4eeX3HDt6z9gTIM3L JQz29KfQV/mqpkm4V+laYgcCEJ7T/uLZ+pdf/kYNr/Q/K3sIjwzjUXfqBCRr hpf/3ROkn4/mpwBLlLtrBfQL0i83fPgb4cnow//0dZ7/7//tP334z//1f1Ly Fd/kf1wJW1q/AczzsBL2sDSib8SGsKllIMIG0e+Rk/SPgmj8/OuvntXQSIRS qTNeLrFUEqI1LJXmFu+DXvB8/pPf3b+Pf/qb0OqnWtDnb36Fz+q6l18/ht7i leYotsAsdR4lnPD+JeJkqwLh2/4EQkuE3rBP//Tt48+x/6vULQi8VgwtELdZ ZufEq1zGLaYABi83vYy/Z/DQg/8o7alicW7wbQvUGm8UvdQGCtBYx0SIdpF1 TvSrbTrnNFL/hgKxGxD8sLzsYXBAIEPz6l+deXOF0DsiHBa/wg2QIo4URzyT FJ1KKRFf6IIWlZbukhaHZdTmghaHZdY90eJ18jOB/JTrAvlROpc9+VHruyW/ SWk9cNu09GXkx3NCxGDbIvJjGBzwTvLzOkQY8Q3IT9l5VDvyU3JPfqo7ID+8 IYz0pwP9SbURf7AoqfjDpXqv9DcuI4q/qS8UfAgoZk8I1nZ9oeRDIByLSK/x pNeWkt7wOv71yU30fSLt5sHuyW2Yi8hNxTNAo5jcoIJqn5Abt55Kbl4BAhtC Mblx/1dBJ42mWZbuVS09qJPD4Nr+mNx+xdYVBT6Iyb4KYxGXkHYOb4194ZXb /oWujwhQDECXrfIb8ohjjl6HhbcJpEadkcpevvnD3Th//H1mWC+iGoYexkic sRcMN/nhPn/+CWxYnjgn185iAzJOrVak8ITVYBQEAsOKl+nz8tEfdBBFWDPP WAm2hf8PUaxAoEIbYi34z9+3SCKsbby66ujLVxbD/qDfti+XwyMcsJcCyc66 bXhjc8RcG/Qn8VfKXvASe+bq270q4fbM5QXTAXNh/ovIXOGALZquCbLcjBB8 tJfl1PoGshxuVKcjQewfxAAXL34Jp9kOXp30kn6L8QIc3nQGwX4VKQhpQqoZ 7apbJOic3Il5niiBdDLJYw2jdy97IByNxLy+qmF4OtBIg/EhUmXX2Nc30DG0 P27tdYxJNDu6nORSouKKeMJqRLD7DNalKi63vl8VY/QHVGzTTujJlSgaYU5q TlgBBgdc9Yw/6AmrCSqHbh2TH9RjFYnKwa2nkt8oezOMtpj8uP8jKkdAQQ9O F6sc2L8DsjHiUuXQ1/UNBJRkhALQIn0DSg2PvV1BoHCZa0jf4KW4oW+EBfOc mmAr1jdWJBGWiMsra/qKthHgEIq0DecF+JG24XkJeWvLZ/pc0V6gb3jGSvSN WXd3MZZ0Qa7bRjNjLVJCSfAdY3HrqYzlp93rueW6PPd/hLECCnwYl3JdHvtP YOPopKlhLAS0qMgjaBlj9dqNywZk9FqIaYmxeCluMFZYMGCsPbZixlqRRFgy TPTXGSvAIdTKWLJMjX8DnlJ20TtdaVa62B5zwVM2bFZtJ5mnoKB6ylPc+n51 pbYfUVea28k081iiK4U5Yc1FlehKAQYHvFdXUnHEZzEH7lX1WZkj8kOfs0B/ XZDpnQjK0txbCGzZHyGp9WT6Q5fl2iMkAqFgnyc7qhGlMmnYwZrc3DhEBhEf kPmvMiOS8iD9vC+92El33RDpfeo/fQ7bA88IvcQ4hgeg4YufmC8u4T3Sfng5 Qke3dU20ZmzB9JJe1zUkaqf+VIL0X51QZHyTS7uGUF2zl4lTQpTTIVH+KVJk vJ+D2NtwQTJCZozkggRbT9YyFERRVmgZ2J+1DLN02vlF89vnOC9WjkNTomUQ CnpwNlLivKisloF0xIoGT0HYo+GSY1agQcitIGRdox26F3jUKyD2B2LTeClC xIZ9YLA+JTSy/YLhZuEr8pNorUsoDV/jkspUN4k9lfXTnsr6EiuFjBdxbavW i7gh3Xm59d3uvJPq6CIOtE8jbOFF3LDuvNYUXsQNpOf5Ae+9iDNxxB9w592S X7iHa1wkv2mwQ3oPx63vlvxGTxhIfosY3DwV3QOHOakhvwCDA5YofuEEH/59 P4T45fMXtVLiekVnwy3CZGaX3iJw6xPeIjjZjXCJMOj5tEsEwqkZa8UdQpgm ukMYwMJ2+w4hAOFoRJ1tgXCEOwTzNjcGaklMtkMvdjQ4jE3JTZaUq1eCXW+y MjZbbn1CGlxvssbu3+Qmy6Otu8nCiaq9yWIbpx+NqNCWUeE7uLeS8d5K6eia 1TubcY2h1lOJ0PaDmF35yYP7P2LfDCjowZ86Su2b2F9Zr8kJ1dbYNwFwmi3a NwG00FHBjn6UFcTPv1kEbkRhKW7YN8OCta8ptmL75ookwhZdHAQ4hCL75nDl 4uDt7Ztn3hnEy7hOBjV37J1I7Uvceu5pfpKi6csv47j/Q3cGjIIeuvLLOOxv QPSCyajmzgAA2SMcQMt4Sndy7jcgcBlnNPEUL8UNngoLBjy1x1bMUyuSCFt0 ZxDgEIp4yv5R7gxEvIfzJ7GN20/GckGt5/JU3096Kj86cv+HeIpR0EPflPMU 9O8gPmRadBVPAaAckacAtIynpJtBDYog49xJyzzFS3Frn+IFA57aYyvfpyKS CFvEUwEOoW7fwx0ej39w7go3ckKbcMtt53ZOdyxuPZe79GA6V3HLTf0f4i5G QQ9txS039NdgQJRurOIuD9gudMsNoIW33EurUedkkHF2o6X5D0txg7vCguEt 9w5bMXetSCJsEXcFOIQi7urf84514QYuuqgGqqgGmsVk1EBqPZWpnLJtq8rV QO7/CFMFFPTQlKuB0N/MqNiYrtINHGEda4IeumzX8rK+b+0KMkJoOLtl8Wrc 0gR5zWCH3mMr1wQjkghb6AYeIBGOOEv/kdzARbwx1TLog3bCSnv7HYtan9h4 5s8y5t/AeIZoK4xnYaKqjGcBCEcrcQN/T8YzscY1Crsaz6BSY2o868b3fJ0q pKDr1N45NZTFNfKc8J1SkSNTgMEB771OVXHEJ7nF8nO/1zB0Cfmt16kuXqfK Yc5cYlHruyW/sdcWyW/swKmwyI8uzElNWG2AwQHv9KN7wrDaOTFzqhLyi3eo jY5bsIWw+mQLptZ3S37D3PdIfq5dlonzYNwgvzAnNSEvAQYH/CGTCjxIfhd3 +DHVjrBCxN3Xn7Uyuy+2PpcbJ9Beb5fp1asR4b3udd30B7Td6SrrukmzME/W CnbdhAdND5O6IMBrPpsbPJxhpdhn0zaLUW37qs4kvnKXTS3GxGVzGPbOdIUX +CLenUqz2qSnjADk1ic+g4yzOM+LZHOBD2irLvBpoiov8AkIR6tyI3kHZ5DG RSVQBCKc+nZOvUi49WTX4b6rMt1S/8cClAgFPdSYbqG/Rt+mqeoCHwDZdIug RSYm5zWBabQrCJqYaBcKS3HDxBQWzCssCbZiE9OKJMIWmW4DHEKtF/jv1nTL 5XsiW8UbERnjuee2dZkYEWp9Qtk+9y1Yl5pGnibZEaVmpDVynSeJ5PoMBlt6 EAXinWFxUBLvskbrVcv8FkJejFOaUkYnfvutKBHy8SrBnx437qqptZNbz80o 04y2Jryb+z+UUYZR0ENFeDf2x/Duoa3yKEFADu8G0LL7Oaht3GxAvC6iZ779 5qW4JeR5weB+bo+tXMhHJBG2TMgzHEKRkO/es5C/4KlovNVts8bC6ExORGo9 1/Nx0HPN9Rz3f8jzkVHQQ8X1HPTH6zl/RKyK7EZAuptD0EIvLaMabVeQcVhc 37FHCS3FLY8SXjD00tphK/coiUgibJlHCcMh1B/gzhsrcUSm0msgo9oEMmZs MtT6hGqTsMo6DBJszjsRI07NWGsUJ56mjmNdJStOYx8e5E39iVHg2KQ/qbLj MQ0gbBzyDSyGRiRH5XlILIbT0aXxhcWwUavBplsNNjJzX0et53pkOGtluHUv 8cig/ijyZdu9xpcCs5/VWhV4ZDAKj6RFWS9d3+ucrP9l8cTzHZL7bwZu1xjb NdgWHPxGvuFbodDELQCNF4eIhjoa/7qub9C9g5QraOVZWHvDWzSKkm8n8HNr BPotQQsQMP3kcCPy3KU22bcjOjFS9u3/9M//9R//4b/ss10TagTb9QJzJ5vq l/HT919WWuheXfz67aEFu6GVdHrZgcQ3Rr2KTaShv85loA70dhKPyYTHcPRL a5Q0rut2LNYkV5KiyCjfrPnvV6cnP/GpVsWt55qjlkl0upzFuP/KYuGlylks oKhjsThwnsWcLWQx6JiyGLSWsViABxcmcmb3LcRi8NMjLEaoy1gsTDuxGH39 DRYLIPGN/zgs1sT0JTGbMVQITi2+3HquMWBp17vDEmMA9V9ZLLxUOYsFFHUs FgfOstjUDmMRi2HHhMWwtYjFIvzcLlItDIsshj89wGKMuozFwrQji/HX32Cx ABLfeOtj+J5ZrHGr9beN+VjsrDPRJtR67i7mejVVKIrcf6Mo8ktV7GKMonIX CwPnWayZljIWg44pi0FrGYsF+GHSFu6CsYVYDH56hMUIdaGiyNNOLEZff0tR ZJD4xgquLv8QLLaatJ1bveN1uotx67lnMQmxrHP5WYz6R/Ob8OT0KvT8am/z VoBFYwB4HZHdDXId9WOOxaCE0JfvYv3yebQKT+7hEYv9GL8DTR2CMwSMqyXD Z8DVxlGDOgFEs6Uu6cx4GdkUGfpUglOpxwa90eXp3x+f5LKjOJFUgTjMsHVB cV28KVcuXOn1jcnk/ODWcymuH9Rg+nKKo/73URzD1lNc+PJ5VHYOFAePZRSX gG81hgOKo/+9LZXZE6msWxMqRJ/wQeecgqj1j+6VxrMwT2KYySsNHzQ9lHul bfGQV5op90qDKPTBvJ1X2vCQV9rWBN9s3SLjvdYyLpl7LWp9RhO8sa7Hc0d7 ngkecWrGWmOC52l6xATPKHDscheGJzHBqzlTG6fcBD98/u3TOEfyjE6TrZGr 9UKnCWe49TnJ0xpI3dzoM8nTGiRPwFpBnmGaAnk2gSpteGhukWdAgWPX3xAN i41DvgF5apEhzzEhT3dAnuMvc//pt5AcuGnW5NSRPgfbTunRn1ufkz5bT59j a/oz6bM1lLPa9DX0GaZJSCaSJdBl1wT6uUWgAQcOvhLorZpikUBnG4d8CwK1 GQIdEgK1BwT6/evH3z/2v/zt1/lfv378HgXpagaWKu7zttUZRZNan5FQB9jm 4TbkRN9z2uURac0uz5Mkmge2ecaBg8dgWPGjbPNpbsOabb7/9PvHX4g4tVsN qCLWo4GSqNmKi+45d/mBiisv9jziRJSakVa5z9IkuQdok1Hg2PUi9K1pc3yI Nr98/fzf//Jr/yWSZ7yl1jFyp5eyTx1BuPXdhi6OWhouSIt4A0leC10McxKo UQUiHMKDuhXJGFDg+OuBqIAa17HeggxzVUITA/g0Hrmf/hojDDwNihi4I80a uDNlorep9QlFpICrMvAe9v93nqIJODVjrUlBzNMk2vsVzYADBy85CUUzubRQ cfmikO0TqJ4mJzfLVc9NPiO/e2yKyK8hMf4EnNvTh9OLVEydqwlC4P6PpbUk FPRQEYSA/TEIYelNZT4jhOU4BIAu85k2XgotG5DRLp2aKZ8RrwajOPSZ5jWD HB57bOU+0xFJhC3MZxQgEY5uDsz1fEYQYXPJcD9kVqNLFltjEtzGfdpkHFSp 9VQW61tjaipHc/9HWCygwIeaytHYHypHT1o0lSyGsFQ5GqHLWKwFzrQryDi7 QXTMYrQat1iM1wzrfe2wVYQlBCQRtpTFGBLhiMXkO08ZdsFcbWQuKfWqcGWU fm49l7n8nNfsX9w/x1xeYVddgVNPQEEPFfsX9sf9a5SilrkAlvcvgC4tyz6Q hzeDjLPXmOYYLN3fZq6wZlSW/RJbTbA0I4mwhcwVIBGuKB/fO9m/NnePnsXW u8e1vtTST33m7hFbn/FMo52evJB044nGc8SpGWvV3SNN00N3j4QCx/7hwn8e NEpu7x49eUaTOabuo4xV/dKnR25ufU7ybJUXM5NbziTPVlG9FY+1JmUkT9MD d48BBY5dntPqWe4e0xLuNXePF/qJjjfjVrUbp+PM+ZpaTz9fuxqnY+r/6Pka 3ZRRFx7LS7Fgf6iDPjW7TC5l52trLHsYFyZzmYQbpbUriF+CbtKs/NNq3FL+ ec082yXYypX/iCTClir/DIlwf9jztV43ACniBjCZTMpCaj25ioStrCJhH68i YUMVCVtZRcKGKhLdUMtiABsKSXjosnxJstP9YleQcWq1csRivBo3WCysGSRi 3GMrT3UfkUTYQhYLkAhHLCb+SOdrFZV/HbMh22kcU+WfW09lrtErETXGK+7/ CHMFFPhQY7zC/mi8knKqZC6EZeMVQBcx17jMVix2BfE8KgbJdSRoNW4xF68Z JNndYytnrogkwpYyF0Mi3O39C4wklPyJLw1/QOb6tf/2ff4auCsGVguhVo8K KTKZNaj15NwFToxuvSZ+pQvoqemgVGIJ1604INDLP8IiDoJi1MSs9+wG69lu Ehlsxu+sPyVwVERnbcJpnXvpx3/57ePXGZIITMsgPMX5Qwr6h6/Tg1Dc0YN1 7QtEhP3689d1ONVosb5tAEVA7gsTqsTLsnz7KWQt8AO2dgM6KthGodnCB+jF 9S3NWICi0SG+LJurABEiwLYLcFf38vunn0LSBhqJxg0fedGMKBjAQ/fjy+8/ z98PQKmz/x1WUvpxPk/zT1/6n+evYcBeQKGn1/SBlmb2p0oe8RIUpkz6N//1 p6X/7RcsUtx6ievPslZ1M2X/bHbvwX1hdT3o96/9l5++EDTOzwSZkQi+dXZ9 IOhNd/iYGeE3SUDVph+emYcXYHLsRUdh/i//o0ExAP8BDHhxFmytp+N9Hp2p 2ed7k7dTy2rr1tSydlOWU2crC+jTM5UsXvFysngv5f73xSoxbH2sUvhyf6Sh uq3hsSxWKQHHanpXYpW8RNd81c8PTxEjp/1HPRK9tDXgdnKT9nIb+JwJHqHW J7SQzcKAc34z2/PSXgJKzUirnEppkh4x3zIKHPvHM9/qx7I3fRz/HFzzdRfr XYhO6zV0xKau+dz6hMQ5TZhIr+vOs94iSs1I6wJHrFuNty4Qpw3EaW8SZ0CB Y9cTpw3Ead+GONMs3HOXEOehfg7efEya7epQKmJmMdfMmahPbn1C0oRbALB6 NPZEZz7EGbBWEGeYJiZOf0bkBxN8+aZbxBlQ4NglxCkh6xlv8Crnyzfa+BJv QK6mzdw1uESWtiVxTro1saCuinFO86CWzFUttT4hxY6q7THg97zyaYhSM9Kq PI00SY9EOQUcOPiPF+Xkzo9y8mQaUzYa4TYJRTOZeKj1CclUmg4T0M7jaWSK KDUjrUwn6h6NcmIcOHj03f9Ropx085BDwfa01OpNCF6UoaPKhdpT6xMS5zC0 kHNBT+d5uyBKzUhriJMn6ZHTEqPAsX+8QHv10GnpwtmlVetR3rjVhGQzGzy1 PiVxNpBITKjzJCei1Iy0hjh5kh5wdQkocOyqWqnP4Oqi2gxxlru6bMNDWxVj n5R1m1RMaXUVbn1C2tRSQ4y9cuflgECUmpFW0GaYpAfCQwMKHPvHCw/NlFq5 Pzy0le2aw0lsRGcmtJ5a32146CRkVxseGubkgfDQgALHXyXl04eHDqeFh7ZS rnlyoiu11V3mvpdan1BEDl2HaXLm8wxKiFIz0ipLPE2SMA+czxkHDk5UOdTs 328cCpqTkeXn8wtvBGPX4GXdbWJp0vwO3Prv3gjojeD3yUtvhDg99d4IDHrd GwEGzHgjQPN93giEsM4bIXzkHd4I24+85o0wO/+KWBVy/1DrjTAvSw+ekijP YY3kq929xzVvBD8/0RtBeYbS68M1b4Roabbgi3ZZtNnYwVgo2qxNY8/wVBCN P2nuRIGb954K7qj86NYGYjqx5vGNkkAamSlNR61PuE+5pZGetHt1XqFERKkZ aU0SA56kB2wgAQWO/Ye2gZhu9ffu1pCKts240VDrMxLnPHcQFg/hzmcRJ6DU jLQuR1Y7PhbuE1Dg2D9cqsEHbSCXV3CmjRa6tt1mak1ToHPrU1LnAOZjuJo8 jzoHMh8D0so8reLRKzjGgYNX5SV6BhVfTRnyfPQKzmzi5pvoi9i2XUaIUusT kqnshACZs5xX0g9RakZaVwoZJ+mhKzjGgYNHKXrlCs42OrjDX/o0vPVu/6B/ 2KXhzqzx553ZSNQpY7ij1vdruGvNUm244zl5xHDHKHD8Hyevm1wyZHif4c60 0XW7a0w0Hncq57qNrU8oLp3fwPwaWqdO3NVH1DkRadW9G02S0A/s6owDB68y Jz/Drp6tgHpfDjdtY3WKTtnVhValMebcem6MnhtnFeawJEaP+j8Uo8co6EGV x5hjfwF+O+1cm2AKYOVIMeYAXZgDx/ZmtiuIJ1szc4IpXg1GcRSjF9YMc+Ds sBXH6K1IIqxtelMQoxcgEW5fb+goAPZHjc67YKtV5ivRbuLK0/tsbn1ivUMN zb16hwBj6ZGq8eUzxGWG75/HyXLUjRwikUAfoKjBHYVJe23iTEKRjUtIBV7i MsLGzlO/vzrpEy11OKp7tnEUV6aJ5tJYvLMfepX6M3LrE2oHw9BOfgFNe6rL GOZHQqQ1ng88SQ+4iQcUOHaJRco2Nn+WemP/cN1n9IR7/cNVdNERultTUTa5 bDTU+oSEqsYFMnnJ5Tw1FlFqRlrleEuT9Jh/eMM5XPzgRKnmx1Fj/02MU0rG mDDdmtU/PFPUj1ufkExF00LBUK1OTDgHKDUjrfMPx0l60D+cigDC4D9eFYzH LFJbN0e11rrqrF1NAXPGwE+tT0icpsVavtad54KLKDUjrTMF4CQ9UgWDUeDY 9ZaAt6bNnCXgzmhatSYUkbH+wGwmkbGVUusTEqcQrW0hRcaJDuKEUzPWGvLk aXognjagwLHrkyG+dTxtpk5gRTzt1q1ErgWEulZvEmBkQmuo9VTqtPMy9BXJ ELn/K9cM92eKBQ1G1osk91pehj3gqSvDHkc/KMM+9sGqfqMMu+/owEtrGDtI XMJl2H1rNwbwq2XYCT6MSA9cht23TFSGfRIdLVRVGXZEjWDZMuwLe4ExLcSR 5cYCtYSRepGzQZ1qVxBKpAXVYfwLjpGLk2pfUH1q7wpGk87EmIroMOzG2aWW BW59QnkuxwZy9snpxGtaQKkZaU0AOk/SA45YAQWO/cM5YmWvHe50xJKbYkdK RH/hLmNN4NZnJM5hAF1jVCcSJ6DUjLSq1BFN0gOOWAEFjl1PnG/siGVyp7Ry R6yd34C0q7ZhN5llTPZazLwNef6V/AY6Mdb6DYQ5ecBvIKDA8avCz96L34CM V7NeRsb0qdbTY5o+lVqfUETO8+w1TjeemEEGUWpGWpOanifpkYCfgAMHJ6ps f+hqcI95Elyom2v+mGaNTzNjzrWaWs9Npb1MQunyAxr3pwPaOE3jnQe0gKfu gBZHzx7Q4HWKDmjYEQ5ovZv8UUfTAQ1biw5oAT6MSA94QMOWBw5ojPr2AY1p IY785Ae0WZnpgQPapRJs7HpXsanulol659azWaaTNQUeqD/bNLRu7meZTlbb NOLoeZuGf50ymwZ0BJYZGtPajlkGW8tsGgwfRqQHsmlAyyM2DUJ9m2WYFuLI EitLyadlmTbDMrpYNb/cZNo1h0lMsNOKJVdyFFufUCcS/tXAoNufaKIGlJqR Vrme0yQ9kmCHUeDY6x30D2LTOLOalDRrXIR2m1y5GXFOrU9JnLrDmjDuROLU HReocbW5cttHg8sIBY79wwWXPVhLakec8XavabtVPe/SAH1uPTdAf+y7sUI9 5/5BPV/EnbpGwFOna8TRD9TzRRSq575jomtga6F6TvBhRHpg9dy3PKSeI+oS 9RxpIY4ssUTse9U1vi3fv/ztt/nr7zGxhVDRQd7vFsw3/ryVMVRz67u1BI52 mtESODkDdRlKLIFhTsyrbfTSeJ7Cf03wfj82AAZIHLbKMUOEMf76ItsL7cSg 0o9iT3/jEf19H6OqK5RaCS9eePtNOeMrRK0nHw57L2HLqydxf47MMEtv3PSq bf/a3BbSAZYebJDVgGQYcrKaqObjz99++/Zl/jStMyBRxG5JK3YCsaZeckDz JEaUbWLrW7EFVCqlMiuUg5tEWFBp53OjFXQq7NYXuoxaMKLTO4kn7V5JkPYo dce3b38KBmchuzXLWUyOMKgl4wBEre9W1E2ib1jUdUqasmBJnhMHiVlc3zX0 r70t6gIkDlseIxktyawOa6Xf4gRlUxOySkzIuimgv2YTKBlV1GGYc6mdsfVU +pucG2ti0bj/I7FoAQU9VMSiYX+MRVNOXsSiBd32IBANAEMgGoAWBaLZSQ2c 35lA/LlqsnR+DUvBKA6LnfKCmdcUW3mx04gkwhK5zfZVrzyWljplOISKYWi2 sA5jnNG/WiSa56lFJzy1j0TzXFYQidasTNWsidkG69JrGW49V41wU9/W2Jip P5/7xsHea2NmPJU25jB6/tznX6fs3Acd8dxnezV7puzVK39O4cGPEYQh6YEO ftDyyMGPUN88+AViiCPL17ng4Be5xopRGa/Twb/jOP71j4JCz8lRsJ/30U+D nG4zkXJWr67Rds140mecT6n17J1pqKlkyv0f3JkQBT7UVDLF/ljJtPEqWF2U NMJyJVOALouSXoTxQn0F8UvQGMOVuGk1bm1OvGYQJb3HVr45RSQRtrQSN0Mi HEfA9lfCpCOPXeqAP2DI9Db+QFkbD7ytjkw2dibjQECtz2g+N3oB9cScmASc cGrGWlU+gabpkfgDRoFj12eof+v4g8fqeV0EwCprostqG0t6jbLP+FNz6xPS p2qndhr8rt6O58UWMlLNaCsoNExUzxS6NOEw67pbpBlgcdBImu4qafoT+aUT 1hziGh2nsH37EFin9gTaH/lfbSrEKhsV/Qb9Ssjd34pMbCG3PiF5CmdGkJ+j WLrz5Cch1Yy2xuWfJ0ogjUxS762LWSd/BsLRiC5tmchs7XLuWbOMCnWbegFO zV5MToea8sUu3onotdrFsuSjX4uUDLn1GcmwWUZIaOFOTGhBODVjrZGRPE0P 7OIBBY7941XlzCQArtjFt9fgSsU89aLtoo9Gt2QS83DrM5KnVwjBSaM7scwh 4dSMtUbJ5Gl6xEuDUeDYJS5EFz7UOa/qHzop8G+/eor9Hgh2rdrVqTZqneOU noq49UyCncbOwSw+Ulgh4vCgXoAMehqpsELbaM0F2Tf9/8O2sMLF+B7UhsIK Eqpy7s0QF4UV2nkepH0VXly2VFkhzg+CZSsrxPE89Qkp1xcOwGS8i7UVtJ5f fp6/D79A0C10Ffq1NarrcBn0avGgTrAKcnkZ4CD96QYEdQI7gSCAkv5oTMRq D799mfrv81o8wWvpXVRe1g4AIC1CfPvLpxFrIaxAMvaOP8ILDXMEgJAIJTQW RYgTvLZdwOPLQR4vAAt9caGA5+FzpA0+I9h7aNMNSTFjj6fedak2ZWz/Dhds 3QyL2xs75szdfnd0mgxX+0o2KupIMZWS1y6HtBIft55rTvSM0qjyi1buf9fV foClh9bWX+2HGai62g9AXuGhdMhiu6PcvtofBxWu9p18u6v9rt/7/0nX7K/2 3WGWuXi1qoRbb4Gs3ATn5HJ7YOu7vdr3Ykfz1X5vW76OuXW1z3OCNVfcwFf7 Q8nVPkPisJy/43oCD/+ZQ7Durnf7pn2Lu/2cA6pONG9zRIDbKxShYniYFiG7 jJ0Wl1Igtz6h4i2HQUKyNdVCraSzAr6hnJC4pm9zokyeFhyfrwmivSvkyez3 4iwqxiLM5jkUVJQnU01Nmiez20uwuTNFBBQVYbEWx2j1kDm5UevJF9nWxZuk oots7M8X2Ut//0U24am9yObR8xfZ/nXKLrKhI1xk20UpM3MCGGwtu8dm+DAi PdA9NrQ8co9NqG/eYwdaiCNLcPKruceeB3BXhX/FcKqNuOweWw02TQmTyTUr Cqxz0iv2gYmM1ps7toweQK1PKIUF5d2YTHdiAFVIvIFYK+/YHs3xxShw7B8u x5ccunZPnhXWuQvyXNNmNzqmze5NzgOVW5+RPFs5gpDV7rycB4RTM9aadMg8 TQ+QZ0CBY5fkPJCH+ZDfmFRN85AheVvwVOo1HXInNoUTbHrPwa3n5qObhHy0 4GnAAfu7f6wqeHoxfq+a4oKnU9c1btJQ8JTNcnF6js1ycTjVNHJ92wCaMcqt BU9hwF6iMxSDYsFTbNb2joKnjDBqHgcFT8NINO72TS9KnP7y+bOXf/Sao9Sv nuFfN5OCHluT7fkToa+Hm+TLp/7X+eMKJqnbxkaCHeBI4PqX6fNP83+fR/Cx CogJcgjx7/QfCBg7A20aPglfAZ+NYwHBD6s8iXg6/ZLFQMeYJjq7RwAl091O 62EcxGyxIqo4N+LCpKcZepdLCSLUOCUSxCTnmSMT4MVm19ioiykXr6KGJldG jVqfcLMbFdSinJQ6r9ofotSMtC6heveotxOjwLHrY9l/7HvSTe4pYY1e7YXR WtMvfWqh5tYnpM1ZND0Y3vrzaBNRakZak3uKJ2ki+uj66OfU3STKAIuDFvo5 cSCk5AAJv6BvoW5lvO/ahB7ttSIpkR51DE3TsY6f9dgyudCo9QnpUZhJQ6oa fwo/8doecGrGWkORPE2ifSAbGuPAweudQ98691mGPCtyn623KxCCuVaZjIFr vesygWvU+u9nATwLCDFcngXi9NSfBRj0+lnAD5g7C0DzfWcBQlh3Fti+af4s 4LFuzgJhUm6eBRis+CwQEBNkPAvQf9w+C2TAZ2MXKvfJD9fPAhcYys8Cl0YF PdO1nD03/KHsRCCnLj0R6CQfnD6SItsTgdAyVqdv5BoA2wyZMCNqfcJdbugn qF2juum8WmCAUjPSuhMBTtJjJ4KBYnP82LTFNT/QieCx+Ie1TB0EvsV83SI4 EEx9O6fpg7j1CUlTjo3wavQwyzOTyVPiNUBala+bJumBMnUBBY59R26rt61N 12bSBlTUpltJ059PY9o1o5o1i6bMpa3A1rOzaJq25mKY+nMWTTXdWxkk4KnO okmj57No+tcpy6IJHTHCWbRuEpY1B2gty6LJ8GFEeqAsmtDySBZNQn37Yphp IY5MWTSfNvHs0mcyWyXeh2UMI9c8G9Hw2Nshk0STWk9PBddWpoJrQyq4CXJQ 3Z8Krr0rFVx7mAoOXqeMYaBjyjDQWsYwDB9GpAdiGGh5hGEI9W2GYVqIIxdk ak6znv/4zBN1dK1WPza/JBk/Nmw92Q1JDE1VPg3sz8wjlrt3G8ZT64bEo+eZ x79OGfNAx5R5oLWMeRg+jEgPxDzQ8gjzEOqbzBNoIY5club8/bCNbtfr8lDv Z17GXAYNaj3X5X3s2po0NNyf2aaV96Y6D3jq2CaOnmcb/zplbAMdU7aB1jK2 YfgwIj0Q20DLI2xDqG/vOUwLcWRKP/pHUNK0WRlGrqeabPrH8fT0jyfdeEwT lNtWvTjvwgNQakZaV8e4EY8duAMKHLveT++ND9ymzSSTLj9wbw2Vno3b9TpO rLlJRTY3qXhO4uxnhfvxtJxGnIhSM9Iq4qRJeshQSShw7B/PdeExQ+WXr5+X eFncmDbaKm0XDEKTmTOhJtz6hNQ591gkwp+4znNe6LlIBCCtsVXyJAkORXIh JkncToYRYHHQwmQY0or58tColpBz7K9KlmLMeNRANPAlWbZHrvcfv/S/TR85 krvRzepT46Kd0kwyc0tMre83Bm9usaYgPTgbSPF6DB7NiSbi64fDXCwX4XcE hAPxlm2mlZ2u5RawjcmkFgAJ73+BRHhvQJDdlG7ibb8nyLkgnqpRek23prrV gTlTEIJbzzVk9P1Uk22X+z+S0zCgoIeKbLvYH7PtdmauzGkIsCHhLkAX5TQc pVCqtyvIOLuunSmnIa8GozjKaRjWTL+m2IpzGq5IImxhTsMAiXB0s2+6KzkN 30M2wwvukmtpN6E24a4qG+6qzs5l3SuzNLbc3kH9L7lLurEmYyijwId50uUZ Q6H/0DCgGTHAdfSEsKLKcdg3CvT3PaYZc4v0Siy6aTbs9S2E+FvkrX/9+hEy YgzWLGLYAIxzJ3s6o4TFiMyFMP8B3Z2IURhJWDT9muLLsFdA49cS+QX/+/cL NPFt4nes7EXd4VOGlz0ozhYntW4ih60QTc42ok61jcjUNkLjX7KXM6Nedgl5 k9q4/SiPlPzP377HCs2NjEq+8BwWi221bcpg3Hquz91sTWMeyosTcQDZwSPY B4p97jbjN9NU7nM3Ln7T9HsfXqgZ9roLE4RwB153PKAk1zl+3wBK1sTV664z G687HNLpLSgF5PrmobnD644RRuvhkdcdj0Tjho+8aEYUFz54v/88fz8CxYEH iUs9jUtLuYsAAlZXvoy9p6yf2IsPytYYdC8EqLELD2z13PYFNtX9y+/+2y9Q 0Hhe/kVc4R0WnDZwHudP2IF6jP4UR3Pzj//lf/unzAR6vJsJDJ1oCrfjj2C4 nlspR42kus7jMIxGhaXnUXU7B3fEFXiyCi4Ox1l3MyTNgADBdtWctt6JKO76 cZy/fVsZd+0fJmDa1g+n7h6B31T2oNQbDcdreqEIIPYKSNDyoWJ5GPVULSRV Q+hlLjMNtVbZJNNQ4prsP/LAjPynICTXmsydXSu6DHMuxAhbT3aNcaaV5UdO 7h8TDXXaK5pyaZj+hmYvE3NeMYSCHizo+COdWheV1UJofyU1n6dg6w/j1T+L xLPZjEkYt0P3Ao96BcT+QGx648aKfWCw/qgCJqZWWpZTc+R36Y4M73G5Iatu EokPVuK7Ohz6rs5ffzF/Z//OBmrTdk3grdcTpc6GxOrzQ2JHazFk8hE3eMKB mqB/hKCIcjf4dfxm6XW5G3y7WNeNlyGx+nZILA3Huyq/bQDdb8iXbvAw4KS3 oBKOh9C83LMhM8KbGzKPJENILH7kRfPhhpwFxYH7tnhDHq2zmqBGER6kLd+Q AWAQ+jXi4ncY1GMbMuO9uSHjC0cA2pAvJmMw+nBDvgQewSSnnVAGPsfI1qve zI3Jhvzte/99ZVorLOftJZTdpvYO9ARIv7FewGBP2ofX0gbcWQy5FGyugZMf j3XqccWzY2Jr829yeZNr7Ly3tE1LYvr1OnDJjYQ/IcVafk0bE/4NS8Z7mlqf 8EZCzc6rU3173nUZYNSMs+Y+gqeIgylViFwD297N+wiGxUFDPrbr6Sw8NYI2 cGkLtnJsJjG9za1ExgiskqTx+jAI/WLbbr0Ui/cSXduurjm5murUerKSaHur avynsX9OSVzaXnbJLp1TEgkFPThbpSTyFAghW9wzez3iPnBdQ2Qo7E8aorum IfpFTjKogL5mIZUljPzX1hVlo1NdcUyIbjy6eUiITrarrthsbh9S8w23nkx0 /hWqiA77Z4kOzxklREco6KGO6MIU+KXvFNrUTQHRBSjsT0RnrxGdX2XK2xMf Nndhs26I9rpTbYf3016SdeMw8W5Ce0230p7bZBJMkxtw67m0N7lOTxWnYur/ 0M0Xo6CHvim/+YL+ZLoaRE2dSQSUbLDyoEXXXpPuBzFsQPzJ2lNXKOWFS3Hj 2issmHpNsVWU8gpIIqwVfQdHs6tlJtuQdNgDkUW+Lb/yCiN4jdc25lRjQMHd l2xNWnLSJu5h9uju69P8r364Xz7/HHlsVSps5LFRmwyPUeu/h8SjLcCIpjfN NiQ+TM9VW0A+JJ5Ar9sCYMDeJiHx0ExHxFpbACG8bQu4CInfvGk+JN5jHSkG 3gk9udfNzASZdHnw3cTFMyw+DP24IoHdW6rNLF87/obhiBEWOv8C6mvn3wCE Pen8u8TSs+n5N/icJL4nTayu8Vc/CgtpkqPwbJOj8FS+/a6OJ6vzqJ+n9DDM rSeLhtk8LhoIR0M3M5WiYTN+7yVsuWho+kszYZyeq6KBhgu2PnrbAHpDNPgB py0oiwbffJ+ZkBDeFg00koyiobPN60XzsZkwB4oDV5kJyR7qochMCA9VZkIP EM2EgIvf4WEzIeG9bSaEF24uTeFhMiR/ftZCyHDs8yeHFrcAuOZr7KudzS35 CANYJc2om/DNN8VjXCESj92rFNfNg6vKpIRr/OzyiE9iJNwfTKblqHAa39O1 rm1X19AmJBMdjZvS0zC3nustBGljRIW3EPU/OA0X3dMFFPSAiayKT8NhCjYJ zTs3FdzTBUDsTwdiWXFP5+D825xbDuT+e7oxuae7cR0MZBZ33mZN4uF1pzSF PreeTmajriMzcDrIWvqGIktfQEEPQxWZhSnYkNlkxgIyC4DYn8hMVJCZRTIT y3OQWeJ1MBRIs+ia1bTx7Gf8RpAqeNR6rn3FS6Aq2x71z5IZmocL7CuMgh4q Dco8BVsyg1ix214HDIj97yaz+Qcms7WmUWs3ZJYpCGLOl2aw1FXOLdT/4N6i zLmFUdBDpXOLSaXZPBeSGUszKtSGhWcqN00xPQeZ3bNpRk/uptObyPUpE7ZD raeS2di7tlclx1IiM+6fJzNXJM0CCnrAxKU112M4Bdtw9U6UkBkDYv96aTY8 lQ9VErk4NkdFAb9+/sSEZmzcNvXGWa+RGZMptZ58JaamQZZrZ9w/Eto8YOrJ 5bVkv2RYfBhhv9RMYf7UmaOwLx+/zHxJMBvTqhb93me6JLBLw85kYWIQQYSB A6efkYtrAp5A85riK78miEgirMXibTejYwIkwu3zXh7dFPj/dRAb2Yrm3LNu SWiMWtLrgXYfGjO3fQmZi5XMN0kuc2GQ1Ho6mY9jzc0v9r+bzAEWHyBwsIbM W9dAvXlPItOcI/OQQfYWmcMEApnv8VWROSGJsBVkTjJdTnMFmbfvgszXPFHW bsg8Y+Wm1rPJfK7KE0X97yXzmezR/kF01WTeTBZJZMiReVcozTsbyfwCXxWZ d0GaE2wFmZMR08MRmYsSMjfvgcy7tayn3RQxkZlDGLWeTubCVSkt0P9uMgdY fIDywDVkPrkR0iUAidgcmbeF0rxlab7HV0XmbZTmtpLMW5bmtoLM9bsg8zWc t1uVlrHN6ebYei6Z60FWSXPqfx+ZMyw+VEtzI3oJJKJlRprjxBSQOU0gSvMd vgoyD0gibDGZEyTCVSgt6kcl82jp0G3wi2vWIuG2X3S26I8+m8id62YxPHYx H3B4UHiUsuJi/mJ8sJqUXswPS2MxM0m8mI/Tc+ViPgxHPjvhbQPo1Yt5HNAE nx1EBGHz2Nzd47PDCG9dzIeR2Fdo86ZZnx3AChY32Xavm0kJoQMZT50AAQs2 9POMoBEQf+7Z93l7Ce1H//xl/vTT+HWeViT4MPoHgdXeF7M4GyLftxAoxpaA 5ABexXfawv8HjHRAOYKw6zfapps62wKDvHpiXuUNgw3tyyUEjhZ3Va7uFMbI mL00xqeK/uQyeIm4gVfYBacOSu/dgaYkanByt8VNdAEXsllvIzMR/Nx6srhx 8tEI/oADxY1/rIngvxi/U+V+QOOkLEfws7iJ03NV3NBwkmUGvW0AvSpucMDo QoSgdB/gm++L3yeEt8UNjUTjho+8aE6FD/kB5UFx4OL4fcCBchWgKH4fHqri 92E88LsOuMI7PBq/T3g3E3gQvw8vDCH4dlaG4/fXeRRyuRq/H4Bn140KPLBA ho4cj+8K4vfDUGv/MAE34/cvliyWbWe/yYL4fbOOeqo6Vhi/P2Ti91OPyaNL gY2IXEtbtGp1lXRZL2r37xpZdJXU46VGFqenXiNj0KsiEgdMNTJsvksjY4R1 Gtn2TQ+8qPW40cjCpFzRyALEpUYWAPHn2xpZQIIPFxoZ5Dm6rZFl4Qs1sviN xRrZxcfFA+AfQiMz0cphYuLU2WqXcdyh1tM1ssfFDeFgPaFS3GzG74QtFze2 GS81sjg9NzQyGG5Vq0jcEOh1cQMDXmhkJG6g+S6NjBGWaGQwUkiLRB950XxN I0tBceAKjSzIVQ+FGhk+1GhkOB5pZFtcLrzKg4oZo7+pmOGgqJj1ZvK0/dps p/OGYhaB51EYPgAswlYoZmGoS8UM8BYkVtqsXMzI/wdRzDYWYR0LWjTOqjWb by4/P7WebBGetapxcqT+d1qECRYfMHq07uJjmDABryRvDWd1Q9dAYWJuW4R5 Avni4wJfuUU4IomwpRZhhkS4P4JF+ILM4wlEdu0mzWLmBEKt57qMt9oTW4XL OPW/i8wDLD60qvJ+zw7OYeivnhMyp4m5TeY8gUjmO3zlZB6RRNhSMmdIhKsg c/kuyDwE4DSyDanLhnbJpC7j1nOluTWiyveO+t8nzRkWH2p971o6V8+jmdSe zHlibpJ5mEC839vhKybzFUmELSTzAIlwFWQu3gWZq1gZQ8U4M7/4KZlz67mh t70XrRXSnPvfReYBFh+qpbnrjbGv4L0+7smcJ+YmmYcJJKXlEl8xma9IImwh mQdIhKsg8+ZHJfNoxVAyqizCbNO7ZDzvqPVUIu/ndnw0DWXAAdnA4bEmDeXF +EpX3Cst/WA9g22sGGF6rlgxwnB0rg9vG0Cv3yvBgN24BYWwa2wGP6s78kIj wltWjDASmyL4Iy+aj6wYB6B+L5G4vjvzBVgP/tR/+9NPFJxuldB0KbW08+sG Ab654wJkWyB48wmn7Pc8igvI0A9XFmv5rYmc+6H3LziCFaYdR4Ibw3T3aPXS s0fuENMKC18/0Iz/w9//w//zP/+ng4TSiD/O/L4rmE2GbILrfsBA+fBejKsk UH4w1xJcI97bF2QwC2z/WJez0X3ftcPxzRhDQSLDCSKcaDxKlzIMk+3DT9cT ivB41nNqa5rw7dcD5rcUE/Nas3H6Wj5N2L7EHMY6U7aXJRGxQ5pEpE/yCw1H pZRW6S6ipr6GD/RGTakKw62nSvdB6b4m6o/7Z1Nam6YocVxAQQ91UX9hCjZR f7qVBeFYARD714djQdBYM4+nlki6PxwrMfANy21dWYk1vFS3m7vXzGXIeP5l yDx2dQ781P++IyHD4kOty+fkWocO90Y3qCtPVqpg+RjXu4yrlg+eQNKVL/GV Wz4ikghbavkYg03bw/0RjoRQGOfX/uMvTOqNi3khlFzLeaolU5yZWs/2bhZV pE797/VuFsG7WVSTug01vAfybvYtognezTgxt0k9TmCKr8K7OSCJsFbIMu9m gkS42zkKY6odT3NNLiPZaJX5KxO/XIa0TJfZJxAYzVECgU0l29a2xkR1ot1U wXPZmgXuOSvZCiHGDtK82vm8OsuIUzPWiuzcYZoeqGUbUODYP1wtW9M8Vsv2 Ml2ebaWL+QeMjrmhpimNsOLWf/cBQ3NGt0yX6fLi9Fx1yqDh5KUPGINeN2fA gNMWlLxHofmudHmM8LZTBo1E44aPvGg+dsrIgeLAxenycI4GS1CYLg8fatLl AQBbAQgXv8Oj6fIY720rALxwsALECbxpBWAoFJlq5A9PrAD+p6tWgDCel1pO qPjtV60AFytFVgCjrqQVjZu2uNzD/a7eab2MYfC/ullAtl5g7moCeomfOGSo G2YBu8nSImxwXXNyytTb5NZzpaScuposLdw/YxbooXx5SWqzgIIe6rK0hCnY mAWauSswCwRA7H9Hlhb44pE58q9qFliaoTsjS4sntOj308aA51GCMp9sx9R6 skOEnNu2/KzE/e90iCBYfPCrXXNWco1oPNeChGoWigQdhJv4Co0m5vYVGk+g eU3xlV+hRSQRtvQKjSERriLguUezwCDO1T5LzALaJSejuUtSq3VFJ6ONUUB3 Zo3sz7hEcOsznoyaqaH0PNN5JyPEqRlrxckoTNMDJ6OAAsemk9HN4kVJCfs3 Ph8p9dD5aK2y3XYXDuub+Jicdxq1nlzJQ00x73CJ4Yr6v3KEh5yh+rFXFu08 SkfnIa1VgRGL8XhMLQYQSgcKQEYi/7J4OvpO54Q4ervu+5s0bf51QhLCFQrG tQLQeNkYQl18RwcHDNUKSoLOXzPy1evaG96iUXgTmcCHEekBaJlaJpySbhKd iFeRKzoxorr/9//pn7NBM4g66vubXnDqcS8LzwTTQhzZq88u3qItYahebErj 6PFSdd5UAvOC3h9K4V8xnKtCq7SwNr7dBUPprpVqr9z0CUMdXq1tGUquKQBs ZKhJ5grGcusbCP1UNnO+cjJQoIbinPCCrznmJS+wr8h4+xreeNMPmcG9fPns lzB+/jz2piflYGzjBgN9QJUYXM6U2u6qKwlPPJ3fn06VxrJxCfHAa13Sjp2n fqcxaDfuaEcPR4rxVmPoRCQeIVW8RugdlLXZS2NqfUaNwRgLGoNo3HkaA+LU jLVGY+BpekRjYBQ4NmkM8sexpT6oK/zLrz9/ZeL0GkL0Cuvk6hWWMRBw6xMS p2r7oUOnH6vPq8JJSDWjrSFPnqiZSMT0TahTY27TZYCFQYkuu9WRJU+XaFy/ kJyzCAOKU3feUvIcU/LUCXm2R9arC+nZrI4tTgbDwqQgNi3Zeqn1SQlUTX5R B3HeVRQj1Yy2plIsTxRXim2WSKBNd4tAAywOypVibxEo/S8SZXNunc4HZGaT VOoUh1XdN0TZdnY9YLVmPWCp7AFLnX3AOocoPfFgOq9FnkaSiFIz0hqJyZP0 yIbOKHDsH+5yVM1p7eL7Dv9tZ+LFKFYb5LOKHjICk1rPPfy7qZ9qDv/Unw7/ o5unew//jKfy8B9Gzx7+4XWKDv/YMTn8Y2vR4T/AhxHpAQ//2PLA4Z9R3zz8 B1qII8tXIdurp3+7DGk15h/92P/t1+9RykfVQ2ix+n81JpuS2zyn6tHpETSP SYn+NDFPODVjrTP14jSxZkyxHPTYFNh4CRYGJQGvo4vWVQHvz+k0SLe8heJh 2oxs39sSZldCkI1dzVAbXdilITzc+pwEqcH/ox/FmQTpcWrGWqcJ4zTdQ5AR FgaNlw7vnyC3ykYrmng6a4KIHHtnUsMot5577bu0bqxwkeX+QdlohjuVjYCn TtmIox8oG81QqGz4jhllw7cWKhsEH0akB1Y2fMtDygaivqlsBFqII8tXa67q GlHBeHfKRmSlJlriVKzbZWe5pKzErU8o3HU3wkl/ku14mnAnnJqxVgj3ME09 C9suCvd2uSXcAywOSsLdFQj39e5CjjzU/CYiXqTGjjbxeLCH9xdfP//3v/za B73DuNVIvNamads+4/NArU98/SWXK8Fl16+/gAYb0Q396vd7cBm2swfTnDjO 9aSa4PcVHlSWHIflZY8Cx49Wt6ZA11jHeguzRsbnG7bcnRvjWCAeTbeKR7cp A5ajQWo9kwan0QyGErLd7e8dcbCn9gSFKoxLXc7+w9bTeztyv0yzp0KkPtFI MeU8vYfLwTa9se8QRgBX6c/T/NOX/uf5608/z5/mrx9HCK6Ghm8gAa2hGzLl JbAltzBMWD7LWHXhGgo/SOenGny6I1ZENqDfG6PnAYYZ9CjjulHTom3BYNH8 Jggaxf/jP/+v//T3/4///N/2Lg6ENioe226keVy+6fqRUl5+5Gvuw+Jr9Obl 919/WvrffsGo86mHvF/SekUSHee4bEkfEmGEvh7SeTL9/rX/8tMXgsYRwXVP rPDxgaA33YGaZoTfxi53dhLgttc5I8cIghvr8AKMigAkovi//I8GWRn+A1jo Ig/c0C/LtONX6zXM3bZx6Cj39fMSOdZYHWvgyNVI3rs2Ez5HrU+o0AxuEXhJ 3J5nJAeUmpHW3XrjJAm+2nPxjq95vWk8YVgclPYPr7deM49bSKiwU2rUEjyo /6rbiBin9MCqk+jl9kjL3l7dmG6tzCR1F+OG3JLaULj1CalysiNcd3theRpV IkrNSCuoMkzSA1c3AQWOHe+8f5irG/mQL8Y3DNwJxCmiF33nTLy7MTJVcrj1 CYmztRbOgGN/osWZcGrGWmPg42laKnXvrZ2PUeDYRJ62TPemAaR9UxU8cxKs VMEDcTaxMIkSarOfZ65DqPUZiXNYOjBQNMt5nu+EUzPWyh0dq0Kz/NLRQNGN JTs6XYc0C7u8qzI/jNX6fK7JrJAgdZ+Rl0mOhkMd84IgNxazmJe9FRmLGbc+ I0GOU+81TH9sGM4jSMSpGWuV5xpN010EybA4aHTA+IMRpF49ffWa/Fpkqn5S 6zMS5CRbcFWbtT2PIBGnZqw1BMnTdBdBMiwO+keVkDFYTYpVQrZdLucjtj4j QUIoATjEzt2JEhJwasZaJSFpmu6TkASLgxYSpG12QRHviDZlvFRoonmohYSR KW1i61PSZmsxc/7UnEibLYVFINYq2qRpuo82CRYH/QPt3he2ofWOoXEqBENM faczpRep9QlJUrRGA0mO8sTYXsSpGWvN8Zun6QHrUECBY0e/rx/FOtQ9aB1a b8CMXi2XRnbRQaCdM3WIqfUJqVNZN7dwq96b8wIhEKdmrFUOAjRNwUFgDdTp bpJlgMVBOYCsrY/UiX4C3ZtE6pgMebYJedqSSB2jVDz9NHbrC5bGOXLrE9Kn aCRc+Ix2USdmRpB044NYa2zrPE2P2NYZBY79w0nPB23r/affQzJP7cx6FNqo m2BDyxyF3HNSp1ETpdVezruOJJwBa91RCKeJBdgUqHMM1DkWRDsSChz7DtN6 oM7xbagzZ1pPqHM6os7vXz/+/rH/5W+/zv/69eP3OdCpijqojb5WkxyWXPgO tj4hnYpZQE6ivjsvtAxRakZadQFEkyTU/WQacODgvNe76vwyb02t+iFq3W71 2q416nWsUW+ncUzP7tz6jEQq20aB/ibPsysRTs1Ya1RRnqYHtvqAAseO5qU/ yFa/Sw+ru9Vl1Zg1dmtscrFb2HpuYIJYOj2Vu6xyf85H1zbNsnSvaukpZ6Zr +y2mg5gERkEPUI7SWHI0lDab+PAbeQpSf6waq4ZmbND7fxg78B0M3j7RaXB4 +fb56zzOH3+fGVCO5MI3YGb54IkUe8FYkx/r82fOgGcnbcBjKYL4A/6kFCfG p6VgFJ9DAjwtdrnCacGm1xRbRa7wgCTC9lgt1n/2ymiZROEEhkCcKFzGY18m U7joEzeqMA7kQLVmPJPZSvKEtyaTJD/1pjqqBZFyWkzQ0MQagdZ/W1oQgltP zpLfz7OryZKP/R/htICCHqDMfCGnYX/I1jjM01zDaQA4zZgEF0GLOG3WA1oA I8iW03gpbnBaWLDpNcVWzGkrkgjrOaC/xWkBDIGI01x7hdPAFRe5q9ll5A+D DVJ3zTtgNxnPB3JTq1Bn/Bep9dyNzZ+jqzY26v/QxsYo6KFmY4P+sLGNTvVV GxsA0saGoEXs5qTfDPUGZMtuvBQ32C0sWP+aYqupjchIIqznAHOL3QIYAhG7 qWsbm9VpPF4YZxCTeg8bW6h01MioQjorMkn/uPXcja2d9STLc2dz/4c2NkaB D+Niyzc26D/B6Vw2Y9XGBoBWI6cBaBGnTU0zTaNdQbacxktxg9PCgvmNLcFW zGkrkghbsrEFMAQiTjPDtY1t4fT0jclvbH6jbN/DxhZDyXX0VXGLa1I9kltP 39haVVFSnfo/urEBCnpodNXGZmagIKWG2o0N4kYCaBm7LQ2ceVaQC3ajpbjF brxgfnYSbOXsFpFE2JKNLYAhUMHGJq0gPuutTPiNtzc3vYPtbc1hptQmPMtm w7Ps6Rn7e2X6tkKRpP4P8RujoAdVoUhC/wYsJMKrhTX85gHdQBYSAC07t7Xz JKcNyIWFhJbiloWEF2x6TbGVW0gikghbZCFhMATi7e0Gv7XIXm6xCb9ZOrjB ld2Pz29rGmCrV37LxPZw67n1t2U/1PAb93+E3wIKeqjgN+yP/NZ0bQ2/AWDg NwAt4rdh0pYjKQhkx29SlPAbLpifnQRbDb8xkghbsr8FMATi/W25ZpFc9qna 0w2u0e172ODiFYC2as0YoDM3/tR6KsONXdPUMBz3f4ThAgp6qGA47I8MJ+cq SwkABoYD0FJLiUIVMIBcXgHgUty8AqAFI0vJJbaKK4CAJMIWMRyDIRAxnL62 wVFBsfaI1cy72Nv0Goml1kisOXPbRq2nsprtp77mDoD7P8JqAQU9VNwBYH+s 2DS7robVAJDvABC0kNXE2KoNyAWr0VLcYjVesOk1xVbOahFJhC0xlQQwBGJd UhSZSvSBqWTq+/ews0VfNiM2uXCabC6c5mxV0g6DLct5w+xG/R9iN0aBD2Iq t0xi/wEdMgZRxW4A2Gra2Txo2dFtXJqusSvIbmdrClRJXjA4uu2x1exsjCTC ll1uExgCEbt18xV2iye2jGUynNzce2A3ESOVXPQlWXK1Dbn1ZHbr2hpFkvs/ xm6Egh4qFEnsj4pk62wdu3VtUCQBtPCGu7f9YleQC3Zb1mqKV9iNF6x/TbGV s1tEEmGLFEkGQyD2JWmundzCrpbZ3cK57V0ok01kN9VulMlMFDW1nnvv1rsq ZZL7P3TvxijoocahBPqzMlm1uwHgqkwW7m7jYqZh2oDslcm2SJls6dyWYKtS JglJhC1iNwZDIDaUjPcaJsPhTbwDflvjypTpNnldMiWgqPXk7a1vajxKuP9j 2xuhoIcKjxLsj66SzVKpTXpAdpUE0DJ+G8a2mzcgO8MkLMVtwyQuGPDbHluN YZKRRNhCwySCIRDxm7ymTd6yk4h3oEl27eqVLDdeyZmYd2o9eWvre9XVbG3Y /7GtjVDQg6rZ2nx/iCKZVD/VbW19L0dLXsketFCTFBiPGkH2Xsm3nbfCgqEm ucNW5ZXMzlsBtswkSWAIVLC1QWIJfahEvguL5JouWLrIaXbOGf+p9dzbNjF3 rqIwAfd/6LaNUeCDHcs5Dfv3wGnNWMVpCGiI0wC00P9fDaOwK8gFp9FS3OI0 XrD+NcVWzmkRSYQt4jQGQyA+s/VX/f/HYzfJ93Fc69YCjS4WpenbMeU0bj3Z /38wNX5b3P8x/39CQQ8VflvQn/y2hjrbPwKy39ZQavufW0O5rQPIltN4KW5w Wlgw9CPZYSvmtBVJhC0xRgYwBOJrNn2N05Q4jrSZ+uE9cNpq9tfNqj2K3IX2 KE6/0JZCVF1oU/+HLrQZBT3UXGhD/4Zi2qockgEw2CEBtFB77JQe7Qqy0x5F yYU2LRhqjztsNdqjCHsawxZqj4KT4A/skKyuHdT6+Yrrf9O+B9eRbs1NZjZV sZdsVezlbJPI6LqhxiTC/R/iNEZBDxUmEeyPQTbLWBU9ioAcZAOgZb7IrhdC bkAuTZC4FDdNkLRg4Pq/x1ZhggxIImzRBRuDIRDHtHXX9jRpD/e0Qbb6Pexp Ys143sR0F3rIZTzH1pMtIrav0h6p/2MWEUJBDzXao+9P2qOrjB4FQNYeXWn0 6NQvLalfLo0e5aW4pT3ygoHX/x5bufYYkUTYkj0tgCFQSTgbX2HbzFU2O/0v 5j2wW7xbk93G1p8zi1Dr6Z4jw1jObtz/Uc8RQEEPrpzdsH+HJ/1+qfUcoTJP BFqmQko3z8auIDtbf4lZhBcMDmt7bDW2fkYSYQud/oNZpF/4sHbdUYuCtD2F Hzr9vwtFsl1zNproGDnqPs3ZyK0nx5BOpkaR5P6PxZASCnqoUCSxP96tmbbK BxkB+W4NQIt9kIlDGOSC32gpbvEbLxj7IF9gK+e3iCTCFh3ZGAyB+G7tmsH/ arR2Y6Z3sLO1a21sF8JrJjUOqdcIt559tTbV+ERy/wev1hAFPtT4RGL/AXOp LXWcBoDkE4mgZYqk7oex3YBcKJK0FLcUSV4wUCT32MoVyYgkwhYpkgyGQOwT eeNqLbupsRI5voeMP5vsb25jh2xz7sfYei6rTVJUOWhR/4dYjVHQQ42DFvQH B61JC1fFah6QHbQQtDhytNF2BdnZIdsS92NaMI4cvcBWY4dsg/sxwxbm1mrJ /dgDsRJp72A1MvnPi30Pu1rMBtrFEkejV7ZTVuPWs12PXdPXnNew/4Oux4iC Hrqa85rvbzDT8VTreszpfgm0iNXAl8XT3gpyke2HluIGq4UF86yWYCvP9hOR RNgSVgtgCFQQNNqD2fL4cu0dWEZauylHsnodyyZzUqPWZ0xpKiaJJTzOSw+N KBtGWlmMhCapiex0vfxIz+VHOBG07tcPyNWnzZxoNDoQzmZ5g1T6nh7TBKZ9 Qo+DuUKPgRTFWkZMtxvfpcztE7U+ISnKzkn0rZnOS6RPODVjrSFGnibRvDpl beN0CU0yEI5Wnjr/iamx2VNjb0uocU2cv2bS7Z3KCEZqfVJqRLft/jzJSDg1 Y60r+4nTZIkYe1tCjAyDg8X6TH84YjRrdnxnNs5mLk0Sxq1PSIzdJMCrqRtP I0XAqBlnVXUmmiIgxKYTKBVJPo43yDFA4pCca/w6PUbXfjtNu4p2r9aNs170 j0eZf/oeyzNp0aqYB9maNQ+yTg2Q3HruUW1eBq0rciBQfzyqzcO8LFAU2h+Z 7DxK5x+8pNBaFZzXGA8UCcODmnR9r3MHtV8WT0vff/k8/nkzehuPOusDvk6o lr1CwbhWABp/mEE01BHsMsPcTS1aJvlrxm4M4Nwb3qJRL78t31L4MCI9AD1T y4RT4rmro4XaAMPbjC///I//9NPf/6d//q//+A//5ae//6d/BtZUY5zSka1U u14e1LPSwjPBtBBHBm07HMSWMFIvjgS7FZ5g/bEX/hXnVuATSiRMhG90mbl/ sFJ1ex5KMvcPooSHdLsWP2k/rMVPUl2DW8+1LC6Tjfc+JZZF6k88NPaduZOH Ap46HoqjZ3kIXqeIh7BjwkPYWsRDAT6MSA/IQ9jyAA8x6ps8FGghjvxH46FN mUC1MWRIFVWkrHV++jewzp+jImmnZlCSJnVemUDCqRlrjZrE03RPmcAAi4OS ojSU1VV9P5UBld/f1sqAmxIRfZpJm1ufkCRnT0SwjIM4jSIRpWakNcWCeJIe KRbEKHDsH68uoHqsWNCWOE0TXXSaTq8uOioTk0utT0icYyeglJWezztTIkrN SGusGzxJDxBnQIFjE3GWlFt7H8S53cu99hj04XbNPDTqNpNXj1pPvmm3pkof pv6kD09GDvfqw4ynUh8Oo2f1YXidIn0YO4I+7E/93ehYH8bWIn04wIcR6QH1 YWx5QB9m1Df14UALcWT5CvE87aE+HFKeb5ViL0b++oqwXPpUEZ5UUqXw0FS4 lexKxVI5TtjVWDilebu49Qklu/BMg+bCqTnvTg9xasZaZzDEaXqonDuhwLFJ trd/SNmummjKVrFuWi9ln5qyufXc/PtemrmxXLZzf7Z1aNHeKdsDnjrZHkfP 2zr865TZOqBjItuxtczWwfBhRHogWwe0PGLrINQ3ZXughTiyfO2vyvbIPz++ QBdtSKHfCLWWnbWZvKfc+owCXeiue52HxdoTnTQAp2asVWVnaZoeKjtLKHDs P7KyLtpNyhmxcdtIrRzcerKyrqa+QqBzf1bWm/lu4zXjqVXWefS8su5fp0xZ h46psg6tZco6w4cR6YGUdWh5RFkn1LeVdaaFOLJ8te9YoG+ue6SW0bVEdM0a Zu9ymT6x9WwVqBUVV6bcn1Wgxfb3q0CIp1oFotHzKpB/nTIVCDoix0xw1d2w CgStZSoQw4cR6YFUIGh5RAUi1Lc5hmkhjizBsevafU881Eqr3c5fHFL4mMb/ 25rmXEt7GUNpvymndz868UHoihhqPfE2Idxw9DOcnim49ez706Gtuz+F/sxQ rmvuvz9FPNX3pzR6nqH865QxFHRMGQpayxiK4cOI9EAMBS2PMBShvslQgRbi yJ6hxFWGkrbXzFD9Po/gu2IoIdeUS2qTsDPj/EitpzKUc9aIijSC3J91OjWo Oxkq4KljqDh6Xqfzr1Om00HHhKGwtUynY/gwIj2QTgctj+h0hPr2DsW0EEcm A+wxP/U9OcWFf98nNykX3XtcvGqbBkiDkromYOvZ+p6u2Z64P29P4/iAvqfr t6c4en578q9Ttj1Bx3R7gtay7Ynhw4j0QNsTtDyyPRHqm9wUaCGO7Lcnc52d RsncM/8Q7LQknj6yiJ3W4MAu3G94nbhJ7ze49eSQd+2mis2J+3NwoFm8ute8 6gkiTd04qGW8zUkBxYoLgwM9LmHHHEP9+V9+m3+bf/JL9GmFhhAp1zcjJYmG x4GdjzfdcYU7spb9ef59/vR9nUWBZ++IZTWQUUcANeJlD4XdgXzbV7HG2kUQ s608wKeU9Ljyb0K6qk2NZfRel7SrZj0st73UdBHtrrksTbtJjJI5+lPr2SeV dqo4+nP/cLPdivtPKoin+qRCox/cbLei8Gbbd0wVK2gtvNkm+DAiPfDNtm95 6GYbUZfcbNNWEEb2W4F9V5rVvVvB6vTZrAUYW5dLWImt57KTm3pTc/Cn/sGS toz3shPjqWSnMPqBJW0ZCy1pvmPGkuZbCy1pBB9GpAe2pPmWhyxpiLrAkka0 EEf27NTdOPir4ah68PtiqNVlVbuN51UmUR61nr0/mbFuf4L+YX8S7v79CfFU 7080+sH+BClAivYn3zGzP/nWwv2J4MOI9MD7k295aH9C1CX7E+W5DCN7hppq QhHeFxNpt4YOqzV0WGZDh+X5ocOt1PZWTq7kbh2BQgqTllODAAtNS9fduKsP fBSwwAllROBB+vlWs9txkm7oiPGp//Q5HnJoKuapsdYfecODpodJXUQLR0Cg w+HlCA/RYrumQN3C6eW2umSbETM80upPp97V+1lIKDO+3yV1Gts1ScBmegQp CUuQognuJELJtRqTFhmliVqf0Z2kbdrBr7GY5XnuJIhTM9Ya32+epkd8vxkF js2RxVfdSdbMvW2qmLy5e8nk5uGcQAW/a8VU2a0M5p7Btl3qX8KtT0iuwyIg VZGXjqdRK6LUjLSCWMMkPUCsAQWOTcTa/WF8ny6IU7qYs8brGZuowzSKhluf kDgXjQfASZ8X4oUoNSOtjDl8MIomoMCxy1OGPAtxZuIP7yTOxqp4mNN6k8Im k5qBW5+QOKGOHSZUGobzNnoZEyp5rHUpbHCaHtnoGQWOXUKef5CN3jirol5q lF6dDkQm6otan5Bc/V+8/waF7iRqRZSakVZppTRJD2mlhALHJmIdfyBZOp9H nF2zJqczzSYdWIY4qfUJiVOY1krMpXVecjrCqRlrZTqwR8mTUeDYf7SgqvHb n4g27aZAnmo2+7zM7vPy9BRMk5Dggw7WHzG00WzUdPa1LDf8iqN5xUdYy0GQ AVfMF2Qfctm2ayqm7fhQLc9QFl7RWZuYcDv30o//8tvHrzN4wXdL7zt7VgDr JVUcoelBKO7owbr2BSyGv/78dR3On9bl+rYBlOy11Bdpb35Zlm8/Bbd7PyDl CWbQUaGdyzeP8AF6cX1LMxagaHQwvmad7RFhtM9ujLO2e/n900+cbIlHonG3 b8pdwIg2+k/87AUeveaIdkDt5nawr5uZgSXp7TLxdwKAB57ky6f+1/njFpaJ QZIZsJ/nV9l2bIPzXT2Ucj2LhO/995U2pRWjXxcusOvRdZuUvtAVQM3LJRD2 JGvf8ioFCzbqLIbUIzp9WAc+1frsaTARBv61LkSBgOnZ7VTwMpeiQNrDcJxv f5qCLGj1Gl7ZbsIr01gxbn2DfSrdTvxWtJIMEMzsnHiV15xj/B5zLesNRgpC lC9UllTab3hhZ9qise5yUwpzYr263bneb0X473CQqXJYXvaQOCztRfLmuTNH hSj1/Ru/xY5k0x1JDfsdSTe3diRldLTZmSba7NpFptoSt567I3k68qtQTIXc ny8/tD+X2R5JadYdkSNsLLevEQMe0IocZYLX1uSuEb9//8sWBsaNL5GCht4A LDwslxRnyHk0ftMYxtg55DG3y8uX799CpSovZS46M7/1gbS5K4wxvfz8sf/0 /adDUPEaWhF07U3Q0/y7373gv39aPGfYefaia4UfZ2sHzhnPy49otmAeUSsv 8sYHQhEY9rZDGa5dCc+VxPEbLBHYU/XUAq+LlceT1PEBEKG4SsP1Ig0hWg3R D/pc17XbmeLF2O0zxfuv7C652beMR5vKb5GZm5jhM1Y6t7az6X0Rt56sXnZz TYkh7r/6W2rnt/bF/4dbXPQYu87HjIIesBgD3WbOi8oWY0CSYU2Wp8CrXOZ1 dv6/R4uZ+VbaYhW2HboXeNQrEPYH4tJ4kCEtBvvAQH1KXX6ZTevf1W9Temrk qdUIuoTG8E0uiKyZm0kk+dLGpBzBfEBk3zd7xpqQyog15qRpMqcYaj3X9WRU TuuKSlbUP5JZb9z0qv2+UUBfAZYebPA6ASTDcEhfHs233759mT9N6wzIpMxA 7AQ6vXrJAc2THNChXGxNj1tApUo0ZitaJxo6Q0u7nHqGVjr12lhf8VLQGdHp bq8970sQeOF9U3v2NBhdy42KruWyt+ldI7e+X+25HSRpz7114Yx5Q3sOc+JI a1asPevb2nOAxGHXvHxX6mA0XSZ104+rO2+IUNtuPcKF/bZvTJ/64HHrqUTo ZZCuqQ3N/R8pfhRQ0ENFbWjoT7WhlVflKoofISDXhlZBq2WIq8UzO2dXEN8i vSKKiiwvBaM4Kn4UFsy8ptiKddgVSYQlcpvt1epHAQ6hSIWdvAbRXlVhI3fF Gf2rabCep9JaR8rueUodmUVWnzwjN1lKhI4VoG2bK95HrSd7igslqjzFsX/w FFf3e4oTnlpPcR79wFNclXqKK/IUt4tSwKbsKa6KPcVV8BRXwVNcBU9x9aCn uCrzFGdaiCNLyPJz1VG8U4fqklfAKN328EOm297wk5/IGNPaxbpho/GzlGpK 1Hq6o7iqS7kA/ZmfrOwecBRX96RcoNHz/ORfp4yfoCPw09j6g+kS+Alay/iJ 4cOI9ED8BC2P8BOhvslPgRbiyPL1esYFKwLz7LlJConc5P99B9y0SYrYbaz2 GZWPWk/mpl51NTm0qH9IithMd3MT4anlJh79ICliMxUmRfQdU26C1sKkiAQf RqQHToroWx5Kioiob3JToIU48r9zE3KTbFcH92bj4J5JbU6t5x6grLC2IoiJ +3MQk1cO7uSmgKeOm+Lo+SAm/zplQUzQMeEmbC0LYmL4MCI9UBATtDwSxESo b+t6TAtx5FvlVN4vN635HbVzzq7Z6tQmW13m5EStT+j5pLpGUbq483ycCadm rFU1Ymma7imsEmBxUDKUif5qZZWQ5ByKm1yS6Y9dauWSRldPZ2dX11GTJoDj 1iekUW20wuIPzXk0Sjg1Y61zHsVpuotGGRYHZRoVBdV/3iFhdiYq9lKFWDvX dhm3UW59QsKUg5wHL3GEW86rIos4NWOtIMwwTfcQZoDFQZkw2z8OYf76l2// 8gsTpll39aaLiWjMmCuxQq3/7jMKPqPjNOFkbHxGw/QgVJ3PKIGSenzgM4oD msRnFJu7e3xGGWFUh8t8RjdvmvUZBazDCC4TRvppxAUNM+Pfse+7duDvTHxG GRZ/3vqG+oE+f5k//TR+nad1BHyA+HBQg8ZZawHp4lR4tQjhkXiW5JYDcBWF Gfcj+YUSBMHiN9jGWFIb2gaS72xEDcMN7cslCI5E1ywqXrOEQfpckt6mz0T4 jO3ixxRnihuTSBt4rUtZ0zSL3gdPDCY5QfTXZE3YBc3qlOpUvHxZhkwBA249 17zVqsVMlbsgA61uRHC9KPr21d7Y/KJxixH4B6MafyIPTh7dqNVBSoRv809f vdzvv83rTMxTT+JCwHGUr8Q3PdEIsGYysFomF+NWwwm1OfkCz2ayp62vdUFN Rs3GbKjJv6RawDM6EBM2jLqKlgRaTZGWFilV6ibEreduXEPfTLLCG436P3I7 HlDggz/2Fd+OY/8JlP92VjW34whoNVpwALTodnxehDGzXUHGaejnjtw8eSlu 3I6HBRPuNUVXfD2+wRKBBwcB683V6/EAh0Akt5sr1+M5RhvkMAIKHu6vfF8O qVou7ss90+lZbmU2tphKmW3aGFS0uDHjjket/y6z40zMkz9qlMvsQEVyFdfu mcR1b7vpQlxjQ724jslmrHa56jDYejIZmV6YajJCoEfIiBDkyWjuW3GLjngq 5smKgehIxOIox3TUW0qb2ncd649MUYPTePA91wf9AYrygsjqeboUTVYvRwbp I5oyNqiTdvSrlDqkU+u79dIcFgjhwLZm6sY5mFGueWmGOTGc1EruXYhzDpoB CEck08nGEpQzO2f1UGlO10PLbCd+b8zYThJH9e7IP/NYqK0J3ro5c8FIrSe7 qtthELVCjYAeEGqM4H6hxlPhhVpv4+Z4U6hl9Swvz/STybPB7OXZYKrlWRvr +83dMmTyBVLrueQ0aNlX75EE9AA5MYL7yYmnYp66aXyQnKyT85OR09zuyWlu 7yCnNR2AV0gz0glbz5ZOZlT10gmAHpJOiOAB6URTgeW0y8npWOVSZnoymmpF t6Mp31JPU3Kjxg9ZNX44XY3v57EfammKgB6gKUbwiBo/sBqv3Ek0ZZ+MprTd 05S2d8ipdiOncloUtp4tp+y41MspAHpITiGCh+QUa1F6Lqep/Y7nKUk+GSV1 bk9JnbuDkvRKSTZLSfbfgpLqFSgCeoySHlOgeCo8JbUVCtSekrrRPBsl9f2e kvr+jn2u21BSZp+j1rPNVdZ29eYqAHrIXIUIHqIk3uc68xAlNU9GSdOwp6Rp uIOS7MbwmbGf2/OL/OI+4+7Z3dyju5t70PBJBnTbLGdoTN3SPJkW3jXjjqZ8 yx00Fe4+Zz+1mXt0aj1ZC/fn7WqaIqBHtHBCcD9N8VTMk56bk2hqeTKaUtOe ptR0B01tbJkqU/GFWk/f8VS1tYCAHtvx1GPWApoK2PGGM2jKOvlke59Xvvc0 5ZY7aEpvrAUZfZxaT7cW1FugCOgxa8FjFiieCrAWVMiprEHTq1LmycipnZfm kpx8y1HNxGNyioaCZVwyvqrUerqIaqsNBQT0mIhqHzIU8FTMU9tPj5OTejJy mpq9dJqa+utj164eZC4NFuHW88949Z4tCPTgGe/Qs6WAnMJUzFPn9BkuCZ6m 2ueiKduIHU35ljt2PLG5wsto5tR6+mlPV9vHCeix055+yD7OU+FpajzlzqWT ZnoymlJyT1NK1tOUsOtpz2RrBZvTPV17KKVSngeK+z/k6coo6MGV54HC/lh4 wTRdlacrAEouuOhByzxddd/1rV1Btp6uvBSM4sjTNSyY6V9TdMWerhssEXjo hvaWp2uAQ6A7PV0718FVFA93KsPd4+lq272nK7RUerp62d1srCoZmy+1nspn k9Cihs+4/yN8FlDQQwWfYX/kM72YGj5DQOYzAC3ks2GU1q4gOz6DpbjNZ7hg kFM5QVfDZwFLBB66voTPKNsNABGfiSt8dm1fQ/s6j/n2zObMntl8SzWzCbfm YdMZXydqPVdR0n1VMmHu/wizBRT4IKby8A3sP2B+ASFrmA0BW03J1jxoGbNJ N7dqA3LBbLQUt5iNFwy+L0FXzmwrlgjsdxt5k9kYDoFub2pXma1HZsMx357Z xnbPbL6lntn0xk81V7QIW08O8pVLCBot0iCp/0MaJKPABwtRnqUaJPTvLTqn DlUaJABysRIALdzZOjWLDcgFs9FS3GI2XjDTvaboypltxRKBh87eZjaGQ6AH mY3USPsczLZ0e2bzLbXMZly3mpVMepHCreeqkXPf1DAb939IjWQU+FDDbNgf ma0TVYGJCMjMBqBlzGamQSu7guwCE83ttL1hwUz7mqKrCUwMWCLw0LVzQWCi ocsmD3Tvcc33Rz7D4d6cz5ynkEs+g5b6TS1cgk/DmDmucevpl+D1gYkE9Ngl +HFgYoGpLUzFPE7yUW/5Tj6bx1c/728DfEutla2x1q6W24zY5tbT7yqnat9B AnrsrnJ6MPgiiKS+wrM5S07t3D1ZbKIze6dm33KH0Vatd5VjLtUFtp4tnaam Lzcmcf+HzreMgh66cmMS9jd4Qal11fkWABsyJgFokRYwjXoalw3IhcpNS3FL 5eYFM+o1RVeucq9YIvDQNdNNlZvhEOghlbvBxEU85turArbfqwK+pVoVaOSa 9q/Jpv1rzr7JhaNfVS4Q6v/o+ZZygfiHqlwg0B9zgai+7oYEADkXCICWVsrQ ChV8BrlgNlqKW8zGC2bka4qunNlWLBF4aJfblluGQ6BHmK2dMbKQx3x7ZhuG PbMNwx3nW7dRlLJRquZ0y21rbL2iRECPuU08rChxlOpQEa5zhaAG92TOp27e O8n7lju0pW1YYa4qiz7fbcKfqu5QvvsHaYoRPOQoSJqAlfpB5dtAUbhnIqel aXe+zNByBzmJ1QQn00qV3Ho6Oc3VeRkI6DFymh/JyxCmwiuWw1Lu2ZUnJ6h+ /EzkNA/9Ps+Mb7nDUdBurk+yrvHz+aaB3t4R9IxAj5HTY0HPPBVeOrlHTQMG stM8FzlN+zQfvqWanOQm0sJ2uds4bD2dnOqzxhDQY+T0YNYYmgpPTuPDlia1 PFkw2CD2Lqe+pX6za9yGnDL6OLWeTk6uPsgCgR4jJ/dY4A5NBZDTo3ZwYyDL 41ORk957m/qWO8hpawfPeMFR65nkNI228SfR8ZGE4BEHp/Ke4EbcuEvaSlKB b0ful2luXjU+N1LPMrGodO5luBxs0xv7RitK9zL8tlz23bwhuDyLYcay4p2U Pdl+GALtKQj+9eP3efthDAiJuT2gmQYm+NAXpt9oTB+egGPH7S8wjJXY+bcv U++7jr7fAlnRvAqo17Rwaw+wkWiHIN/+8mn8/dPn6QJqU3UHXhMzrJtp6p2K iCIc4Boo1fkCjX9DMFgPLKKkNqr+s5hOry+EMPC9EjOd/0//7f/9v/zDvvIP 4UOQiz4ezA0vNGokZ+we9V/LdX/CKOJ6ajvI/IqqCtuIThIHLk3VjW+0M/N4 oXZ5H+YPdZdmHmipNfOo1WdoVHMuxhhbTzbzTH2Vgx71f+gCg1HgQ5WDHvQf sLhKX3eBAYDkoIegpT5DkoygDHLpDYtLccumygumyWfoEl2FN2zEEoEh1d1t b1iCQ6BHbKpaz+jLQGO+uU11bPY+Q9BSb1ONAf2tmDMXGNR6+gXG7Ooc9Hz/ Ry8wZscOerOpc9Cbwe1mnO1ce4ExzegzhKDFIR7tuAG5YDZailvMxgum3WuK rpzZViwReGhld5PZGA6B7vQZatsZvc5puDfns75bdnwGLdV8tjp5eHmUseRQ 68lnJf8GquZWHvs/ditPKOihqbmVdwZqdYOUFnW38h7QcYiHBy27le+F6Jxd Qfab2m3fvLBgGuJZ9uiqNjXGEoH9McSUbGpk7fJAd/KZWWb0gaXh3p7PxLTn M99SXTRANKsBPhPdwa2n8tm4tHONDyz3f4TPAgp8qPGBxf7kA9v0NXyGgMEH 1oOW7mf+ELgB2fnAFkR3hAXT+jVFV+MDG7BE4MG4Eh9YzfeoTf9IKFVLnjY8 5psz22z3cYvQUu/9EhzOx96J1J7Mredng6pOi0FAD2aDeiQtRpiKeayyJ185 jQz6yfIY+NPV3htW19+gGus2N6jZIAZ5tqI0GC1rYmG5/yMCPKCgh4pYWOzf 0bWpqxHgCMixsABaJMCtnZRzG5CdAJe3FaWwYNq8puhqBHjAEoEHMwwFAlw2 fMvsSIDLAgF+wWqmE6go0XBvLrtHtQ9igJb6g79cL2+G1FOBW0+3stXwGfd/ 1MqGfIYPFXyG/ZHP7FQVmYeAzGcAWnYgcYs1/QbkMjIPl+LWgYQXTIOb8B5d RWRexBKBvdLibkfmERwCPWJlM0aPpCi5p2A2t3cThpZaZtPGbHzyMwURqPVk Rcn2dT752P+x0z+hoIcqn3zfn3zyzVh3+oegad7UPGipm7AahV1B9j75U5FP PiyYJjfhS3RVPvmMJQIPxt5mNoZDoIeYrZMamc0+B7O1bs9svqXe1KY32dWy JgB3tgmgb73cuhmetzIb93+E2QIKevDCvpTZsH+Hd5x9U8NsCCj5GtmDFjFb L5zgMzuB7DRIV2QCwAXT4jVFV6NBBiwR2DPATZN2gEOgB3c2uj/qnsKuPcm9 vQ1a6tXITbRZzq5NrWfbtfsaexv3f9CujSjwocbehv3R3tZ2U6Vduw/2NgAt 3NlcPym7gux2thK7Ni+YnF5TdDU7W8ASgQc16IKdje3aHqjc3nbJZ7JHDZKG e3s+M/Oez3xLrV27W9M7DmrJHNeo9dzcDhOkxyh3iuD+D+V2YBT4UOMUgf3R KUL0bVVuBwBkpwgALU0R5g95G5DLQDNcilt8xgumm9cUXUWgWcQSgQfQBm4G mhEcAt3e1LyCyLzV0r+z19LDpiZxU8Mx35zZvAq91yDHOwLNunZzWZtxbKXW s49rU+cqPJCo/4PHNURBD22FBxL0x6sUPVQxGwBCdumGQYsTqZDKxyD7y9qC FGG8YGp5TdFVXdYylgjsCb/ospY0SA9UboPMaJCQKbIJY749s/nNesdsvqVe g9yGTGWPa/JsZrNDW+eBRP0f8kBiFPRQ44EE/UkJG+s8kDwgeyAhaBGzjZ0Y xt6uIHuDf9FxDRdMza8puiqDP2OJwF61u8lsAQ6BHjquyZ5sI/IpmG2yezck aKm3jYg13LXLuPtR6+nJL6uOa9T/0eSXdFzzD1XHNehP7hFzFbMhYHCPmEuZ bdRwcbOCXCa/xKW4tbPxgoFnfoKuIvllxBKBB9PczlfAcAh073FNtGTwb54i VYE/pO/5zLfUb2rNhs+y1Wq7s1OEwQVvDZ9x/0dvsZHP4KGGz7A/8dlSZRZB wMBnS6FZxK+h72pXkD2fFWR05gXzFJuiq+IzxhKBBw3urrf5jGNFlql8U7t0 GLET8hkN9+Z8Nku590DyLfX72faklqtQgK0nZ05Xquakxv0fy5xOKOih4qSG /emk1lfxGQDGk1pfan4UtnHNBmR/UiupUEALpsD8uEdXdVJjLBHYbzRNyUmt DSM+FCtisQo7j/nmzDYtYr+p+ZZ6ZlObXCkZGyS1nm0WGSvNIuPjZpExmEXG SrPISMxmZVWyKwAMzAag5YFZywZkt6mVuIzwgqn+NUVXs6kFLBF40FPJphZc RmT3iG+t1jMyG4355sw2G7Xf2cBZstoG6daLtSmjQVLruY7sUjQ1Bn/u/5Aj O6PAhxqDP/ZHg3/bVTEbArLBH0DLmK0dl2HagOwu1qYCDZIXTEFg1h5dzcVa wBKBBz3edGQPcAj00M4mDKmR41M4si/d3mUEWmpv19qYZwdu+1M1kltPj86q vMU2j99im3CLbSpvsQ0f11zlzuYBw3HNlTLbuDRusivI3mXkthoZFgxD0fbo qlxGGEsEHnRf4nTM5cQ90L3Htb6hTa1/CqfjedjX3oGWeg3SrHzWpn6Q3Hru puYJp8bpmPs/tKkxCnqocDrG/uh03OkqP0gEZKdjAC0uB9IQY+jED5KX4jaf 4YIpLgdyga6GzwKWCOyPUDfLgQQ4BLrT/Oj3MzTz6+eoBLL0e39jaKlXHkNg 1iRz5a+59eQ7NTdWld2h/o/dqREKfKgquwP9YT8b3VwVBYmAtJ8haJlz/9KM TtsVZMtnvBQ3+CwsmGpfU3TFfLbBEoEHfdsFMsAhUIG3iFaRz+ZFM5+pkfjs ObwfF70Poln0HUE0nV3Tf7uMXz+1nmx+XKoKpHL/x8yPhIIeqgo3LlwgVeul zvy4xAKpAFp4SNOjGDYgu/TfrsCvnxdMqdcUXU3674AlAg9a3k5Vw3AI9JBF pMVSKTzm2zOb2KeqgZZ65XET2i+zVdPl2XfXU6+mGkcR7v8QszEKeqhwFMH+ 7ChSVbgRAFdHkdLCjf5URZdgDLJ3FLl9dx0WTJnXFF2VowhjicCD1jeZLcAh 0CNeWZ7ZaGfTT8Fs87wv3Agt9cwmNxaRbCJrd7at30kx1+xs3P8RZgso6KFi Z8P+dFJzVflqEDCc1FxhvhowznfzBmRvEblt6w8LhllM9+iqLCKMJQJ71a4o iEaxRUTceVKTw0gWEfUMGuQi1O4CG1vqNciNRaTLWkS60yND21lX5YWi/o+F YRMKeqjJC+X7U16orq06qSEg54UC0DJHEaM1R5e1uXw1XZFFBBfMU1GKrobP ApYIPOjbF9gBDoHu5DPld0Tks+e4u/YHgb3yON3j0q83d9dZx8fhdMfH3k59 Wx4Uyv0fdekHFPSgyoNCsX8z4mVsHZ95QMe5hQG0zFGklVZau4Ls766LHB9x wZR4TdFV3V0zlgg8qKXo7lpzLZQCi8ix8uiZDZVHGvOtmc2/1M6lH1uqma3d 5PDJeBlz6+kR2DUnNe7/aAQ2ntTwoeKkhv3pUsnY2gjscFID0DIv42W2ZMdg kP2mVnRSI/9gzDi3Q1e1qTGWCOwZwJZsauxlbGyB+bHtOecamx6XRkUNkiJD ccy3ZzY17ZlN1UdgSx1d+kedKx9Lree6Gs+trXI1pv4PuRozCnyocjWG/pRx eqlK5IOAfHcNoGW2/lYNlOGKQS5dIHVB1e+wYHJ5TdFVuEBGLBF4UNPtyFCG Q6BHbJCQ3gyZbXqGyNDFc8r+uNbUu0A2jd7UqEgv1rj15Iu1ztWokdz/sYs1 QkEPFWok9kc1shuqdjYADGokgBYa/I3oW7uCXDAbLcUtZuMFk/Nriq6c2VYs EXhQ482dLcAh0L3HNYVZFXi4t+czp/d85qozizZOBT7rjSfdhM+49eQ4NdVW 1YCg/o/FqREKfKiqAQH9wftx1ENVDh8EJO9HBC07rnnBh4wRQLZ8xktxg8/C gkER4QRdMZ9tsETgQfU3zSIBDoGIz/Q1DVIOQXN0uwe/q/XIbf0zGEf8ay17 FdJVR4U2Xbsx9reprzG3nm0ccXXJ6bH/g8YRx8np/UNVcnrr2Aipq3KuImAw QurCnKu9GCz7K+pcztX2tq9xWDA5vKboqtyyGEsE9ttNSQh2y9FqmnOuTle4 LWxokCEbNEnrBNr5aaS3Z7Gp2bPYdEdAaNutpzSXKb1Ireey2GjvKL1IQA+k ymYE99fK46mYJ6M3qbKpMNZxqmw30ik//BsLHVgtlueqXb2I0UzLpZI0gkWo jqZEG+KxLES4JTTFrWfS1DxJIcebNBXJKfSP5NQbN70q0782N+V1hM1Qkl/W jLxGceTRROpc50D6HcO8rrXlkq4gwBovvLPQ+CokybpIijvodsjr6WKJYg3P w76hXdrxVGLUab227dvtqdGrjhfUuLRze0mN/hWri8vqTdrNNpu4vT09E6An DHFTidhLOAJ6QMIxghxd2tfO/3hDwoWp8BukEjeKAUhRJuGAtqx4HhHn1dBF XRAVtNgDovr2p0BQYM3kM6AItwhT32Yi4Lj1ZH+vrhl1hXMl9V9pSTswuTWR Nm5rpQEFPQxga8EqmzB/Wa0URVdw+aIpCCrdK2TumEbrDzdbORclVPcCj3oF xP5AgQAhG6JA7AOD9TsdjWludh5gFFyq8iRq6xJaw9e4oDKhuklcKGf+Zewl lUHLkXI2BjLzWrmKcsvFFAKtFJlkb9R6KpktzaxHUW4/5/5MZv68M1k4+LT9 NGgivFb06jatBTxAZI6OUdqaHJF9//6XLQyMG18iBQ29AVh4WD4HMKQ/53BG HO4czgB2efny/Rsbzt2gLju/UlHePmzZ3BXPSy8/f+w/ff/pEFS8hlYEXXsT 9DT/vnzD//5pgQNX03LROk7DM8u+MZar7uHy02FpAwb8JHeV94hQBBhF9ijL TYkrlgjsqXpq+z5Q4FHpPQJEKNJVxqirZE9dgDZsJPTQ0FCDPldXvn3sEmO3 O3bBF3eXnO1bxqP947fI2GH/ECreQttZZmyI3HqyVcPrTaomqBP75/aPfmqL 9o+Agh6crdk/whQMC8YTy9YV7B0BCPvT3uGK9g6/zKadpddTGj018lQVuGT7 aOYm3T6g2vPl9tHOB0T2fbN/iDaqKZHMpsH2qQcft56rpgx29NpCuZpC/S9P YdqWnMIiLD30Omq7vRmunsK+/fbty/xpWmdAZs5f3MmD9uolBzSPXpKTjuwp s4lHrxVQqZTUrGidaCyqK9Iu51qRtMidtviFLsWaEZ3uLilO2mlHcdI1R2Lt 25+mSHFRMbYxinaSw5JRjKn1VIqDKvVdX34Jyf1fpW55H2+J9GbnhJdw4zHh jb9n8NADpO/3FNF3doA228965qoLGyhAYx3ToT+sjN/XOXFe+NCVJv6rL+kR O6MVd3nZQ+KwQIjmVaoo71YQvdtal8szWkOqs1b6TFp06d5Kb3RBhkrZedwL PjXsBZ8uIEOkPb41sLH6n5nG1MuLW08+8PeNqhB83P8x12VCQQ+qImkC9Ie6 MGM31RW18YBypCBTAC27o+tnZcQGZJy9BFSkxPJS3Lg1CAtmXlNsxfrriiTC ErnN9uqlQYBDKFJfXcGlAXNXnNG/msbqeWqvsUKa3j1PqeGAp758HP/82xfm KiykyR4mJoaUtiJXUINa30C478xol5IZHpxusfC3gUOpF/w3zGleYl9F6YkB UWpG2kdBnyBz8lLah0nq2F4hWfraPjzIrNjv3cseBY5NYn9Z9Y+81LdNeyn0 aSxh4+hvIftVKvu7eU+n7ohO//T9+xcW/kZtrL0iVjRr2y5Hpth6bnyY8uwx lgt/7o/Cfx6XyfqNHISw3wylQ2XEal1gNQl4GlZ9W+lAD86I/l8WT0zff/k8 /nkzerua5zZ2Ov8640AoVijUXASg8dIR0VBHcDIeJ09BnUYdmlq7MYBzb3iL Rr38tnxL4cOI9AAETS0TTkk3iY4WagMMbzO+/PM//tNPf/+f/vm//uM//Jef /v6f/hm4VI1xSkd2ud71An3evSw0E4EW4shyc6G3hJF6karxnWep3jTnmiOE SvV3fItL1V1bqXaq+zwk8n3oi/hGrkaJNholdIZvuPVcpWmZmklXKE3Un/hm kp28k28Cnjq+iaNn+QZep4hvsGPCN9haxDcBPoxID8g32PIA3zDqm3wTaCGO LOHs8Ufim9VKL3QsV2tbk8m0Qa1n843SdXwD/cN+o9r7+QbxVPMNjX6w36i2 cL/xHTP7jW8t3G8IPoxID7zf+JaH9htEfXu/YVqII0v4/xK+aX9cvvn2a+Qb 6ZxYfUQi37R6EJnbLWx9wuOEdGqZYA3dctp5gnBqxlp1oKBp6kmT7+BSih8L ThIEi4PSSUIMqxdJ/iixPUUIyWfoTpxKmIUHCCPTA0SbHCDskffSt+X7l7/9 Nn/9ff5K5Ck8oUd1SMZ4Coo3ThIoUSKP92rKnMQ0oilz7p0/7BaZMsOcGLhH WRrd0L/mtikzQOKwRIndLUsm/U+EMf769OcpMKG/fjR7+hunm8ZLv9W5YLzU Uq0BBnNqvOTWd0t4o7YtEt7UK1toQw9zUm9DD5A4LNvQrxJetywk+5bw8M4M 6aJz0eQnNiY/PWR8g6n13BtEaaaa6vDc/6HEVoyCHiqqw2N/gxtoX1WUCQEb VmD7wqJMEAU29xuQse9m1QRvEFyKG4b0sGDmNcVW4QgSkETYIkN6gEOo6Ady zZAOe/wlj/2A5vSvn5eoAAvZxMvSJrp32XFs0ohNbn1CBVjN7nUeFmNPU38B o2acFcpvmKKZCXBhEQy3YreU3wgLg5LkH6+a0a1Yk4dG/1aoYjM35xJlmcQX 4+TmYU+Xicuh7kroshGQwpA1X9VsDIE57yRsfVa6nKTtzqZLxFlDlzxFd9Fl gIVBi+iyGZkWxc75WigzD+YdEGfn4u2OitFKvZOZ4iPU+rTE2djhdOIEnDUW A56ie4gzwsKgbDGQ90hNMTfvgjBt2M2lDfYCNzQ2tRdw67MS5ii9cnYyYSLO CsIMU3QPYUZYGJQJs72HMFut3wVhbs5w7eYMl5GY1Pq0hLkM5xMm4Ky0sd4t MQMsDMqEqe/ez4Ue3Y9Oncp1JrrqORfrQagx56NMrU9Lnf18+n6OOCuoM0zR PdQZYWFQNn/ZG2JTpp5E8Sy0yOlHJM/9TYDqWiXXzErtSqJTurNz6/s1yA6y DzcBrvAmIMxJ/U1AgMRhiSKHH/QmoEluAo6CTGP8BhBevCGVa6HF3rWZzLDU enKY0CRsVWZY7H9X/EaApQdn6+M3wgxUxW8EIH+GWTTFb6ia+A3lxncUv+Ep TkbfSXRrIcd5cG5IRB23vl9R59oJRZ1HN/TzXCLqwpzU3z0FSBx2c5g+lnUW Djnozmvf4dWT6kx0D2m0kDGGYzEZUqTWszM/tXWFL7H/g5mfWi58adu6wpe+ PxYKs6aqzAMCcqEwAC28elqkWOwKMs62EybEcOBS3Lh6CguGV087bBUxHAFJ hC2M4SA4hKKrp/nK1dMhn/1410+r16JnLxntqEZFL/lhFJl0odR6Lns56+Ya r0Xqz96+ahzu9VpkPJVei2H0vLevf50yb1/oiKm4rf+AxrK3L7SWefsyfBiR HsjbV2FOjfu9fQk1gl31WmRaiCNLyAV602sxMo35cX0XL7knHgm95Fg1c53x XaTWc/0iFtm2FTEm3J+5pxnu9ZUPeOq4J46e5x7/OmXcAx3R57e1U7c0zD3Q WsY9DB9GpAfiHmh5hHsI9W3uYVqII9+KMbEi2FP2BhYpJByh4V8xvAE3+U0m 5aY+cbgcjhJ0XXCTiKcOLXTMFre4lJu49WwP+tbUqHrUP0SeKHe/Bz3iqfag p9EPIk/8kbQs8kQ54ibljzlN4CZoLYw8IfgwIj1w5IlveSjyBFHf5KZAC3Fk CYf3a9zk1T5kHv53w02LIm5alBjfgJu0P3mfx03x4GSiX/0oxznV7Lj1bG4a XF08CvTneJTOL8fd3IR4qrmJRs/Ho/jXKYtHgY5YDrPr2shN2FoWj8LwYUR6 oHgUaHkkHoVQ3+SmQAtx5B9JszOjXk7S7ER0fhKr238rRc7jFVvfrwVsxsun 16kvsX2F2RAKjsqWgk9u+vozEI5FZq/mVvw6/e/fhNwKb5j6Pr1hypDbUYam C3JrVncmZ9aDhMoeJNS/gerjKoW1i8J6apy+X1i7u4S1OxbW8DqFBwnf0WGR nm5q2xB0C62FBwmCDyPSAx8kfMtDBwlEXXKQUHyQoJHLggc397NzjwqP//fH Pz408TBu1so3Q5Opvs2tZ/MQVLKu4SHoH44Pk7mfhxBPNQ/R6AfHh8kUHh98 R1R4hHK9jYHrvrXw+EDwYUR64OODb3no+ICoC0xZDZfW5pGLEz6YV/NjKzna rqkeRLPuOjbrRGtPr6qxTF2V8Zf6M8cItdzPMd0dxt8wep5j/OuUcQx0ROOv cu2660BrGccwfBiRHohjoOURjiHUJbuOHZvNyGUcszlmm4aO2aZpmx9819F2 zeHqmnXX6TPJman1bB6alK3iIegfLlDMA0arifK1VfIQjX5wgWIKjVbQ0WHG rcaA7OMLFFNqtGL4MCI98AWKecxoRahLdp2eQjp45FvHbOnPOcg9nnz1pdnq jfah2UwnXaPoNhy2GxXzNHrFNFN6hltPP/2IOsMv9GdTldd7Hjj9iHsMvzR6 3lTlX6fMVAUdkYcm2QrFPIStZaYqhg8j0gOZqqDlEVMVob7JQ4EW4sgFpqrE QXVo6QA0tD/8AUhv0omb9S5fN5kMRNR69m2kVRVsxP2DOjfduxUFPNW3kTT6 gTo3FW5F0BHZSMyqGcJdPrQWqnMTb0U0Ij2wOjc9thUR6oKtiGghjlxp8RXv 4i6/NWt8jFlzHIy6Tx3NuPVU7umtX+IKRY77M/cYc68nTMBTxz1x9Dz3+Ncp 4x7oSEXpRQNFC4l7oLWMexg+jEgPxD3Q8gj3EOrb3MO0EEf+43DPmsVLtdqt HsPSbkwJWR91+zbZam5m8WpFL/FY25yXxQtxasZaF5OL03RXFi+GxUHZjbi/ msUrjd15Jxm9tiK+WXN5iTVovBVzLtUctp59ztCVKRr1mqJxtvemBA54qs8Z +kqKRv86ZecM6EjnjEk1KqRohNaycwbDhxHpgc4Z0PLIOYNQ3xbxTAtx5OIU je7HFe4XfCNUDM5sNnXu5mydu/l0O7HXrWWVkzD2Z74Z5vudhAlPrZMwj57n G/86ZXwDHVO+gdYyvmH4MCI9EN9AyyN8Q6hv8k2ghThyMd9059a/fQuOWWNF 15A9M+ZC9qj1VI6x8zJ2FYcJ7s8cM43TnRwT8NRxTBw9zzH+dco4BjqmHAOt ZRzD8GFEeiCOmfD/7+cYQn17p2FaiCOD5vjHSaINfNOsh3C3OYRnNDRqPbdo w9h3XcVOw/3jIfzuog2Mp7JoQxj96BBepqFhx4RvsLX0EG7DIdyGQ7gNh/CH NDRGXXQIJz8YHrkiiXb7Q3OMlGuorhBqdVTMGX2p9Vyj79hJUcEx3D+caZZ7 704Cnkqjbxj94EyzFN6dQEd0mp8niFMPZ5ql9O6E4cOI9MBnmuWxuxNCXXCm IVqII1d6jr1p8vnTPGA892wsAtFnzEwyk92bWs+2CMw1+w33D9xjHrh5nOv3 mzj6AfeYUu4xWe4xxdxjAveYwD0mcI95kHtMGfcwLcSRb4WcvFPuETaecuKF I0SEpr4v3Pp+neQHv67FTvJhNjzxg5N8q0uc5AMQjkVG3ZulPf/NIzMKXeXd 1LUFCs+Rq/zHX/tIdI2OcU1YPzsYozJHBG59wpsGYeUyQLKwwZ2Xyo6RakZb ky+MJ0ogtUzymB63icIYCEfjS4braWn3UtCE4t1/VWLU7ZDcKEzN/kZhkkc1 Gi6JMXou2XijMPrtJ5soR79NopzbxKj02EHOGSVOJEZEqhltBTGGiaoixgCE o1UQI5Kh+uHJUK21QmysFTL0MpWJ3PqUZMgy0ajp30ImAtoKMgwTVUWGAQhH YzK8njwxSsP3JhlVzINsTJSMqrepXYJbn5IklXZYFPvEBPKMVDPaGsnIE1Un GRkIR+N8nv0fSDKaeMBv1yt/7TLu+dT6nGRoBGzQi1NnkiEg1Yy2LvcxTlQV GQYgHK0oG/eBZPwhSXJ7at56obiNq1SXsdhS6+mFQmWdtzv0D2668oFYX8RT XyhUXnHTlYWxvtAxLbALrYVuupJjfWlEemA3XflYrC+hvm1zYlqIIxffcbyL ZFuekleNoo2ifGgXlfINt55709EqVZMeiPuzrdbcface8FTedITR87ZaU3qn bvhOfWg7O/fhTt0U36mbcKduwp26CXfq5sE7dVN2px5oIY58T5RIT3mB/L8/ ZJRIyCUtW7tWd29MyAo0DTZTBYJbz3VM8cJrdHo1v5IBdmo6OCWNBcy14vCg 8AhLOghiKDHrPUOBTtGuDirb8SExr6E0raKzNmGpzr3047/89vHr7Al5XLTr xlev67QNmP7X6UEo7ujBuvYF1u/Xn7+uw/kdTK5vG0CJf6gvqj7zy+LpnzkH Bpy2oKMaX6l5gZfWi+tbmrEARaMDM+T4hRBGftkwi+1efv/0Ezvj8Eg0bvjI i2ZEwQDAauPL7z/P349AceCeLO3TuLQdgXsIWFv5Mvaerjyuz3/+jRdowiOX hxqF5gdJTLft66GV7l9+999+gQIBBg8ZcfE7DAqnDdyn+RN2oB6jV3Vpbv7x v/xv/5SZQI93M4GhE03hdvyR0v9GGg+TIfnz44C6nV8+9b/OH1c4vp6QQzsC oY6Qpda+2pmCPLEzfLsLyc+/999XZoVc5H0Tv3nsNilwoSdAmpdLGOxJktGu ZwvqLIZUnxggEbYb0Bu9b01/qj4uPCMmCrl/l11xB23V5SWWV3D6S3nYt0Le yi/tBaJeC480duPbmik8Qq3v+A5rnkOq82npuqKbLJ4TiynOh45SnQ+24DqL IXFYOhCa60mfPObkPMghEaZ9iyznWqYJoHSyK5vboQnSOBGjzxrbbBxGM9Fn 1Hqy45sTNW483D86jN7riBDw1Dq+8ehHDqOFjgjQMecwWuqIwPBhRHoIDqOP OSIQ6gJHhJHrBfDIxQ6jb5Q04LHj4GrZ83PaxOOglsFVtDdqSi173PqMlj0v MRfIXK+7E++BCalmtDV3HjxRwbLXFt15MBCOxgbm61dvQAicy0Lscll0jX0b +14aZTaJfbWeSS5FhNlFjSLWzfW73ZjxiqHWJyVMCYQ5eMl2JmFKIkxAW+eg MFYTZgDC0Zgwr9fZo2I+744iG7t6KTSxuJ40MlUuuPVJKdLC9t6LE6+HCalm tDUUyRNVR5EMhKMxRV6/BPGq1BCU3ndCjGuB3M7FvNSLFW3qMkOtT0qMsgdv k345Vzz25DLj0dZcDPNEVRFjAMLR+AB2vXCzdK1ITmA/KEkGk6honWyjdNTR JCqHnAWAWs+9V1CtCOeNonsF6n9Xeb0ASw9DOHVVlNcLM1BVXi8AebFnJiqv 52rK643KhPJ6Tp5Ka4+W13N7gpPu6LQfbU6e4sQqAq1Z9+NM0SVufb82p76x teX1wpyQzanvubzeUGBzYkgclkWeuKURphkxfvDSepEK13OKbjeO1GnWPW59 v1Q4imHgtllx5Y/blk+cE4i87URLRR5FW1DkMUDisESF2pS5wuQfZjc34eFN SLJJ7aBJ4dHZHVl11q24iyWWmzYKxtGAeS4t9oitJ2ew69woajLYYf9XSuK4 LGODZkQgSrhdLNiPGYFHYRxeRDbamtxG/P37X7YweAEZRk9BQ28AFh6WKh4G yHnslg6LPHLnUO3QLi9fvn+jzm5242Vn5ro+EDh3hTGml58/9p++/3QIKl5D K4KuvQl6muEuDv77p8W/p+vaxm3gx1lrSfInrDui2YJ5RK3cVZckChEwV3uU wVxMeK6Wl4xYIrAn56mFfUesnJ6pL0mACEX1Jbtomk3rSxIrT4Gnp3Wjmdrh XNedghKTXkvcl5j0X9xdsrRvGY92md8iR8eclJ4+N8p1etrj1nOd3QzcFFY4 u1H/qFx32hONhPv2sbe27xP3goyfG6OgByhhbUbapxaVLd+K5EOuDWEKNMB4 JUXPo8X02iudsU9DO3Qv8KhXIOwPhKbhGpfjwrAPDNSnijXotO0ssRD71Mjx TBrrEhrDN7kgsmZuJpGk9hr3+0Z7FBW27hutW71aYiL7aRi7jCpDrefuG3Jp bc2+Qf2ZyvQwTLYn3WNxtmb7YDxV2wfA4PYRXqJ4+2DIeZxaeWv7mL1GJC46 F28fGVC/fXBryfYh2lEJu8J76d8KcqELy1+wfQRCwe1jj7J4+9hgicBF20cA RCjaPuyV7WPjqyYzh5Ufeg9p1xLgJhpoBgvEmDh+Uuup3D0q0+mQ+rCAu7l/ Zg/xayr9jnCbsQMKegDTYPkeEqZACwUnm1b2BXtIAML+f6Q95PtmE2ljEJ3t YmCxmV2as4tbz91EerNU2QGp/312QIalh7vsgDwDdXZABprHgUqui1dTYwf0 giDYAe3yVHbA5LQr3RUDzBQpTkcXBrfxaNcZwUat79cCY6YGLTCzVkYN8erj mgUmzIkj+59iO2CBBSZA4rBsgRmu5lK44nv2Q5oBL+ResyrPYqM8Z6zR1Hqu 3PObYt9VKM/U/z65x7D0APd41XKPZ6BO7jGQ1+XMQnLP3pR7u5vfdyj9zLrf tm5jGsgk8qDW9yv9em1Q+k1ees1TkfQLc1Iv/QIkDsvSr7uVSebd3YKsZBhP F23MJzOoZUltztx6rvhzoDmXkyH3Z/Hnj+3L0r2qpSdDgmv7AinIKOgBzqHG UhSMtNnTxbeBzVPQvwPLlOnGsUH3Vi/aJNAwC6QhxNwML98+f53H+ePvMwPK kWLHPCge6hki9MKjvB/r82e2A0zT7Ky0K4hv0Y6qaoelYBSfgzFAi4szfFgw 85piKz7Cr0giLJHbbF830RXJCT7AIRSd4Gd/XmqPDcBb7ooz+lc7r3ue2p/X /UcmzrlqKOApHe9xrJVrYrA+E2VGrefy1NR1k6w4SlH/h3iKUeDDuNhynoL+ E+4Bs63iKQDEiqsEWsRTgzWL6u0KMo7+v+koG5biBk+FBfM8lWArN4tFJBG2 iKcCHEIRT03vmafWEBHPVDJ6cTqnV6bKXI5y6+m5keeK+GfuH7Lwq+aB3Mhz dfxzHP0gC79qCrPw+44QImIXpWKBImwtzMJP8GFEeuAs/L7loSz8iBrBrmbh Z1qII0tMvHElRsSKI2cDK+aB64UPP2Qg9AU/xRz9TRczJw/tIlM/fW594vOH Gq4cf6+fP0QTrcPpkePLZziKhu/3qkzvSOwK42mI5C70ASE9uPQ6Qtpu508v X+WZdCMbl9ANvNAl2UzN1O89VDJkc+S79y+//vyVqca4Nedpu2YM9uIgF6jX na3anOO+7AbTtWCOWPrTvJcJp2asNemEeJpYBbALHyxtF+pdLTeTCzEKHHuT XOiaPa9N7Hk02Gzj8G9wrjUuPdd2ybnW2QNC/fJx/PNvXyKprjGlrdmQaib3 FbU+IakK1SqFC3tiBjbEqRlrJanCNHXsbScDqfbh4XZpNkaBYxcFJVm/4+Lm yyR7Sa9W2PgOb0GvTYZeE8HqjvTbX/tv3+dVtK6O+MqtyVRNeh3CrU9Ir05K IFen3XmSFVCiAwFgrcukirPUOiKRIUjUPsjYYHi/mljV0FWJH5zodRivilZQ sfOytW9tHP8NaFWnOdzmXu1pdTyyGW51R6NXUnVmc1ecMXBQ6x9Wdwzf788f bUO6o7ymOkrbDKw6avukquPgilOXX1LNmmvE2jVNr0pv2rj17ALdrauoCsb9 Qwaztru/QDfiqS7QTaMfZDBru8IMZr4jnOCnblrsEqpNQGthBjOCDyPSA2cw 8y0PZTBD1DdP8IEW4si3Mv9dYSErXE8neNc/zwk+w09HXmGX/LTWpYzhAr2T bRq5x60n16W0nkArnIupf+AndS8/BTy1dSl59AN+UqX8pLL8pIr5SQV+UoGf VOAn9SA/qTJ+YlqII99KmvLH4adoEXPRtgFZwjLO+tR6bnJAa5Qcy/mJ+zM/ jfO91fcCnsqqlWH0PD+Nc2F9ZOiY8hO0lvETw4cR6YH4CVoe4SdCfdvCzLQQ R76VYfOPw0+ra4GMOfDNkjvQUuvZmZ6nGn7i/sxPVt9dN5nxVGd6nq7wk3+d Mn6Cjik/QWsZPzF8GJEeiJ+g5RF+ItQ3+SnQQhxZQrj8H5Sfxq+fPwV2iqUu Gyc3iZUyGb+49eRDdyu1veVVkBhzEGj1VrTL9CqECe91aBcKzBQQrDEAg/Qz Pbed2/GTbsj686n/9Dn6ebecmmsY+3Ecw4Omh0ldOItFQKDG4eUID1FkH8/w WzC9ZNOFLvPkx1TDqad33STkF1/l0mdRtl2zN/yMSXzyVOAsZoReYwQ2d/BD JkaAWp/Y7vOozyLazg+tP0nBO205WN7ZubTeHUUL9MFSLtz1YjpoJe92ErDp 1NQ2YeA3sDvmfBV1l5BfW6BRaOtWDX0jAl3GB4Ran9BErmasfNedZyEHjA3j rMsqx1NUmE7OsSNFx5ZwsTr0FdS7a14XLfUbUKAWmVuacZ+6xh+HSyiwi5Zv FXPJOa/4pzZMbn2/ElBilq7Cmp9hNsSINT+7vkQGBiAcqyi3Ztx2RZj1vyal iT5DaRWFPi8pzax7rd34u2XiUqj1ZOveMNVYy7l/9Hdzd1v3CE+tdY9HP/J3 c6X+bo5SIrt2VnqM/m6u2N/NBX83F/zdXPB3cw/6u7lSfzdiGR5Zvkpz9fgU BfSF2iBNhwcn/+/zHJwqXN0urtZ1q9ZYm25zX5nhJWp9Qr1BNgPSkTnPEwRR BqQ1mgNPkpB0vBnHIg2CoXC4VZq7WxoESPPm9S3CbDqdEeeJO9J0pDj44X75 /HMU6HKNCnBqI9AziRap9f2qDgMHfNWUWuA5geLxpm2Oc3xenqEmLrIQQr2k uBXqFRyO1nv3GFjwV9Ul1JLxLUr8NYrOTTJ6bTauMRvXomydZnP2uWlepn6q q7kH/VmXcHq53xKLeKotsTR6Xpfwr1OmS0DH1HceWst0CYYPI9ID6RLQ8ogu QahvW2KZFuLI8lWogvoK78dhfuP5LNt48nPRPc8fipeMDkGtT6hD2HnuJdxU Nc1pSgTh1Iy1zv6ACJb7PZ8DChy7SMAHA1liKHtv7s+yjefH1rk1vkNlAnup 9QnpVRhjwJ/UDPY892fEqRlrBb2GaXrA/TmgwLHZiDaVGTTem7uzXLO/2Oie D5lJUm8Lbn1C+hycQPKczqsSgihFw1jryBNn6RF354ADByf6nG5lhmmvuOe/ H5dnuSYtx8i5mJs3TdfBraeSaw8JUCqcGbg/q9Ddcm/Z6oCnToWOo+dVaP86 ZSo0dExVaGgtU6EZPoxID6RCQ8sjKjShLnBmIFqII0swmtxQof0+8o4DT4WL gdzGBMP2qHqbBg9w67lu4BArV1Hrj/sHTrL3clLAU+kGHkY/4CRbykk2y0m2 mJNs4CQbOMkGTrIPcpIt4ySmhTiyxPCLasP2U7LSnR52Yr0P1zGG209UxgOc W89mpUHVsRL0D6x0t4ddwFPNSjT6ASuVeth17GG3Y6ViD7sueNh1wcOuCx52 3YMedl2hhx3TQhxZ4qm5xMXuHbPSWpRGRhNp70TGREqt57JSq6SpYSXqH5xV h+leVmI8lawURj9wVh2mQmdV3zFlJWgtdFYl+DAiPbCzqm95yFkVUd9mJaaF OLLflbof30R6n4eq6Fb3LGFWE+mcdc+azzc5PZOHat+KHRPlPVRndqqaHHuo woOmhxoP1RXP/R6qp+avfhMPVS/FYtKHtdZn346ZGB5qfceXrL2CS1Z66Eqr OuGcVDmqMgyOwzbNbi4r6JRY4eU78VQVenXWt9sqyNnbovE5b4vYU7Vvz/dU 9Tgr6x/TFJUWPmY/E6/nxhwjfwBP1QsDu5Drbrwm9B9sn4kXodYnJEHZCQG3 e5M6z+kJUGpGWkOEPElLlc8TA+FoLBz7Ap+nDS3+8I5PzXq0ckausrBP4wC5 9R3vyU5UOz7xnFQ5PjEMDsgi8HqO68Tr6Qd3f1o9N4xrVoNzjBoBc2JaHotb n1AQWmntBBabbj7PcwNxasZak1mJpyn4f97juhFw4OBEop29SqJZe+47c9sw 1sVdu12zgJlFZUy61PqExCqsadEQJM9LsEg4NWOtIVaepgfcNgIKHDvE4v0h 3TY8fa6budsebDIhoNT6hPTpiQDDQvrzvOAQpWgYa+XZBmbpEbeNgAMHZ/o0 1zOApvv8e/LcWI2Sxq4xy65rNsegTK46av3DGyV5GuDM0pJREh/ozNSWGyW3 eMgoqf6IRknTrRUc2zam2rZtl+7p3Pp+D0Ct7MgoCQ9lRskwJ7rCKBlgcByS iE3Bhv1+wuYvNu1uvZjpbDQFST1kQo+o9Qk3bSt6iERYzrNGAkbNOGt2bJ6i OkMQA+FovEUXBr/9kCagX//y7V9+iQKwW29ldLOGvo0ZUyS1nlxjz5rRVdIf A611bMEOK/r21RbuwQEBPFishM7V9rpRq6Ot+Nv801e/GP23eZ0Kr9VJrhfq CV8QxWx6oujNbKFehvSYKPFM6lE2JZ/Nu1yas/VszCZ5rD8w6GUrwrDh8Nhx REFr9M0wtrncfNh6cnXaTs5dLQUR0AMUxAjupyCeCq+3qDlSkKuioMHDn1s7 +wEKGha76PnyQgRadB0NNa4Nu6Dtlz514ebWf5dC61R4GnLjnVKoeSYp5F9o vpBC2FAvhbr1LOkyNTup9f0q8iN5F4QPLbrJ4DkxbAwru8pgIBwxavK6QG+y Cqocv8nthWmmjPaeXOTqSrnlqW6TCcal9xfceibVzWM/6lEUU13of1mhWJmS CsURNiOt1NUKxVECrnMg/c5nMnWKY1ePQjXDSx4aX4Xy9a9e5jvodsgTHWy5 sC9Ny7nGC6VNrlBxfKW92PMMf7l1TrPabZ3TfJSL6JAEpY1b52RSdxZuPXvr tK611VsnAD20dSKCHDHa186o21snTYXfOm1/Q/2Sew9R3jo7UL9OTWX1mP7l lnm5JCJoObraClXWTWfW2g9abKLns9cGy9nXBn4FVa8qSqJS/5V2tPMrtzSR Fm6KsoiCHjCWmSyxfv6yJVFRPrEQ4inYprBaeih3KrfCLIqh7gUe9QqI/YHi 0LefrwGwDwzWH5hbnR8A7rnOpLYuoTV8jd1dfzeJ/W5pE1uDnW473nlCE6sP str4IGcdQOezD4qQxnmsS3UC/UPatOmBVCfTeE+qExr9IG3aVJjqBDqCH/+o pqFvYpnQqTTVCcOHEemB06ZNj6U6IdQIdjVtGtNCHPlWEvdVSMtFUaa0RYnx DRz4ddeeFQXjuSe6yqjowe/GOVMzj1vPjoIRU10UDPRn7pHu7hI9jKc6CoZG z3OPf50y7oGOKfdAaxn3MHwYkR6Ie6DlEe4h1De5J9BCHPlWiZ53yj169biV et17pqySM52t5Myu06qm4AH1D3vPMN+dspPw1Kbs5NEP9p5hLtx7fMfM3uNb C/cegg8j0gPvPcP82N6DqEv2nomVNhr5D7r36I1nURs83+S4ZNw0qfXcDBvK 00bF3sP9QzCzvDvDBuOpzLARRj8IZpaleQGkznAPtBYGM8uQF0CGvAAy5AWQ D+YFkGV5AZgW4sjkZfLH455udbLf+OX12djL/m3SfZWapv+NS3Ly98PN/UIm PnWtJGckmLcowOnlyVkFOD2NrCnhrNrkMEr1E249Vz+ZuqaqIBP1jzmM+nv1 E8ZTqZ+E0Y9yGPWlOYx6KsjkxZo2OuYw6otzGPUhh1Efchj1IYdR/2AOo740 h5G2m5Hla9eXiVj3apve+CX76wtXoWczJcI1zcXflzCOkmtUcYwgWWyTqWRG rU/oP0XRnM6a06M5AWeNQ36cohLHqdAbh1lDma5Hc+48mt8uoHOcHwrovAik M223Fqjs1MaVORNUTK1PvMc/ev3sP7G4/BJPRlUEHcPgSEx2za3U4e8leO7C edSo6EBvdLd6L2cyH3LrEwo/KSeII271cF4cMaDEiA/AWpOok2ep7R5I1Mk4 cHB2J22Gqx7OoLjkw+feONZDOTfvNdz7snR6Wl0LfdhogZPDknN0xtZz7dfT rIfx1j31xn5N/fmasW2aZele1dKDSjcMru0LTNeMgh7AU8ygjtsIabPXjN8G vmOE/h06OnQDbEkwpj9Do74dpdbAd4x6ePn2+es8zh9/nxlWkiYL0MMYJWrs BcNNfrjPn3/6OveTV6ilmzuzARm9VikHXIKwGoyCQGBY8TJ9Xj7+MhOKsGae CxNsQTdHFCuQR2IN8R/85+9bJBEWlVRHX74yHvaHs2D7cjk8wtHBsRPx5Bhe 2eQ8uCPmsy7xE86C4XfFqPq+3fGV16F2fDUehv1t+UqvOTttvL4fjZtypXyx 9dzS2AM6ERbzFfcPJ8e774UCnsrS2GH0g5Nj6b1Qx/dCfdu23RJtc8X3Ql24 F+rCvVAX7oW6B++FurJ7oUALceRiy3b3lgfHXEK08oPj+Pu3yDarM0In5Sap YKqwc+v7Vdjt2FLgFzxwQOQNvT3MieZAm65EcQ9AOFCIhV09+ErzCti3CLoR WqWqUBqpfRhzeCGy16v8NqrtYCzPJBKg1vdLe52cyitVhtkQqqJSZQDCsYjq 7FKWIaD9txB1pfUq+5Te7qtXafR6+d2pVUVYTOb6jlpPpTcnle1cuYcf939E 9Q4o6AE8TQtVb+yvURaaqVL1Bth20ZQoFSpElKjedlLD2NsVZJzmxRpSvXk1 bqjeYc08ZyXYilXvFUmELVS9AyTCkertzLtVvTfpC7SKKoSNt+JQ1y4TckKt f/j0BTwNEDY5cU5VeND0UJ6+YIuHrz1upS8YUXcYM/k03jSVgWrEtBfzFakM LsS8FOtViFnpccgGowxni/m5t05P5WoF939EzAcU9NA3xWIe+3dIf01TKeYR Vo7ky+Shyywsi57UsgHxYr4bHFtYaDVuWVh4zeBz99jKLSwRSYQttbAwJMKR mJ/6dyvmNylCtFjdN+wmR+KYMVxS6/vV1odBll/t8GS0lKmjKU1YzFVhvWRH Xf16rqRruUHOJbrS7EgyVdtrcoNsQ7u0aNfoQrNG1ne5/EjYeq7evjgphsrr HQa6P7QrIIAgVqdtcxkVreY2o2bsAus7Sm3kJ5kiu1QkoVtB0cOimJC06txb hkYb48y4MXW5fpaLtZsEDdAw6loy0psIwdS3iFtPD65v7gmubx4NrgcEeTIq Cq6nqYAIQb1GCMoiOgL/GrDHvmWChj0FeRE56mm5EEW+ZVbVoqjZ0FDqw8it fwBR5ApIiLwZJyvKRZHrowziQ8pGKL1pvoY9SfkXGi6EEjZUCqVGua1QSvc2 bn2/WtXkKF8Df2iJchXmZGI/haFEuwpAOGJdvgatpjfK19CKMWN4N3uNyut7 tWJsdbNddM7NFlvPzddgVVuVr4H635evgWEzwqs4X0OYg/vyNQRofJU78jV4 OSh6zNfQLGZp3y5fgxd7rb3cSRczt5c7qX/FoxKbR4LPRG1slL1Lo6C59eRY msEZc+u+freTMtD9O2lAkCPGonwNYSrmsR31Pfka/NZp3zRfQ6qO1eVruHD8 02vefBuDgSEVdub2mlqf0PFv7iXIBnFe1nzAqBlnZRpyDFCRNWkjAxQOx26o pixtpHijvJFz5kqxonRIyBii1mxtsgspZ5zumkwoOrWeexgY/HpXZAzh/pmM ISyNCu4TGQU91GUMCVOw8TMSaijIGBIAsT9lDDEVGUPc+KrGxp1JZ2UZQ5Zm 2Pvo2DHJGFJyca26NTVNuxrA7JCJ2qbWUwltVF2rult75Upo3P+RG42Agh6A aAtvNLC/gJvfcTaVNxoAK0eLNxoAXXaj4dGvA+KNRi9HcskLq3HrRoPXDG40 9tjKbzQikghbeqPBkAhH+mnrooL6Q9xo9Pt4FS/Sivgqxg10jdxEG+Z8RqfT fUbnSU01uUS4f4w2FHdHGxKe2mhDHv0o2lCURhuKbLShKI42FCHaUIRoQxGi DcWD0YaiNNqwaTYjy9duDc+96jSqofz1ZPSTBR1m4r1kEf+o1YGvXX2ul1QB 4tZzfa77bqi5aef+j+xLAQU9VNy0Y3+8ae/GvnJfQli+aQfo4n1pUnYF8fvS pHXDDlW4Gjf2pbBmvC9dYKtwqApIImyxQxVBIhzHMvR/kH0pRlG2MUsPVCNL Paq49dybqrFrRUUUPPcP+1J7b4a4gKcyx1UY/WBfagszxEHHzL7UlmaIY/gw Ij3wvtQ+liGOUN/el5gW4sh+X2qv7ktAtgcllt7bTrX6KG7Ki8C35qLuzo8O cqM/w5bvVNT/oZ2KUdBDVx51h/0pbK2t9QlD2Iaj7tpSn7DJ9YO1K8g4OdfP TYy6a277hPGawU61x1YVddewTxjDVkTdkULo4WinArPGO92pvnz9vGw4y6wR /y5w1tAuOjXBcusTmmA7qTu/emZaTrPBIkrNSGtCr3mSxBp5fdsGG4BwNLLB 6v5qRNHOYUzG0f769lh/ZsvYY8Vd0dVKt6uTYjiR9EOvUksZtz4hNVIaFNOK 09OgAM4KWlynqIQIQ28chohw6mqIsHkd3oD6cgFGY+KpOB55yH799pdPY6A+ salnv7HT9lk7bf821PdXy37SVWU/0WvVjeH43mmX/oTNliPXz5sKfGT9/4zf 151s3FvIus5kZF2q0x7lEf92kW1HWrVmc5VrpEOfLVrWn21/eSp662dTXbae 56Qq6Q7D4IBEdcqUkd0bJdrRmdwlFYl2vvzl+59CqJd2NsYAdF1MtKOWJfVW 49ZzDROza2siKLn/Q8lLGAU9VERQYn+MoDR2HhYA0k4oA9eX1zOXeEAIn0TA UY38oOleCh/zJyo+m4y/w/Bh+i3D7B3jqB9yRfdyFWicmmm2nHZnA4ZQv377 eQVDIDr+yFh/i3t5EJN6mW/Dz0Soei7EqWwi09tafqcLPpH9ODd7PmmS+1px eCq65JNVDV0jFvo2l+SHWt+vYB79SRrbyIpQJJh5Tijnk4EswvgAyS7pQRdE 0HC0ux+f5XSBj+caQePJ8Y08PaXn6n1qNCP2+VSNONIRLimxWyX2GrUlATo1 fGHr+6XEXuhqSuQ5YUo0nP7MGE6IZvRykxIZBY7/DihR6z0l6iNfvUtKbPXq qyc2lJgpe0Ot5+oOYvE7a8WlBvV/SHdgFPRgyp1YsD/etvWNqdIdPKDfrAmQ dAd4YN0BHwt0hzD9AU+R7pAFGic3GKuu6A4BDIGic/Q13cGC1yfwhVGZIPZ3 pUWYaE6wa74STwuZ63Vqfb+y2+mGcjPBQ2dLZHeYkwe0iIACh2Xf1quy+5A4 n02K361PGLueAPXG4zrn8oGtp9LkoBtVc5HG/R+R4gEFPVRcpGF/vEizUHqj XIojYPP/b+/fmiTJjTRR8PVs/IoQ4YoctnQ0B1cDwIcjyy6yp3malxLedmZF dlPsWhXDzIxgRGSSnF+/uCguZgYPB9wsyz08K6eHZQEHFObwDwpAofopNHRa 3DyAFrePBVrcD7+ENkVaPNuo75q2e/UE6JvZRiFfwfET4HVqbRHpcFBy1Zwx ArvS69XabaOc1jYPZVrbj8mWsx+IsN2WaO0YHnMtWpqEnYPZnMM1mERsvdeG 0uvFoD6h1Z76/JhsOPV5EbZ/uJG9jp3Dyec/IuNuNjhbTxJlnNpc6fViUklZ i0k/Jhsw6UXY/t+0XqzA4N8+fPfkEYhjvFa4LlOI87UTGJReoHNAIwZD3GHT D+/lHuBkMpBa4SDghwnC76XPDiB9vgCRB2XiNeBF2L6BDLcvoyUF7lkZ+vzh 0UnpGp2jWMUSqoMa8r7/66fHgM+wc2wav3NUZFBr4joovUB89lJoePZoorvB 04pkILQGnTBIkMRC+UOGbP0DOYpOEGH7BnS2FeiUWIY+z4FOmkHniqz5IPtb Gmut0RnutCRSif0242zgSi8QnaQnrbU17hdsbUViBFIr4OlHqVGnJ1nxMmzn Dp/9+Ko7gkT8IlOskEwaqooUK5GPlsmEVjz4ABrf+AyzhCv92vlo/TCMvRDS 8dHaB+YeivloZ3JcAAI7xkc715dn5aAljUCrTGjlHLSRK5NJGh0BeRPv/zMr OZRe71mns6n34KHQBgRjwuooM2Gl7nwSPlSwUF8QZSaVaw1YQZn5/Pnj8/j0 efQQxCzGkNGoBUU2hkzsHkPWMtR3Y/l1q6sfDPWYCXmH2Tin1jlwzwptLewM dJ2F3rBStH3OQt/2/fj4guM31wqLW5dl/0gt/vseDc6TEFqYfhmB9pnm9vJS kqSJaYFeXXx1WWsJEvXbI74r8Oha9bm3mgOvU4RMS5/U1dLbHQJe4n/PhIpM FaJJPKAzOZ5d6b6oayipyd8L9SFyUS94p0YugpzKyEXfez5yUb9OWeSiqWjd DPQpgzAfuWhKyyIXob3v0T24yEVTsiVy0Ym2zV6LXPRYCD2ThNYqH7iIRhe4 IlGfC1zEYl9qoQ2JmU4LWdRTKZJT0JAdp1UZqlEo3TsIuOV1QcCmPkwlOanT g4CtnOogYNd7firp1ymbSqbieiqZ0rKpBO19j+7BTSVTsmUqOdFHp5LHQujZ JTTbNpXoW59KMU4Co7gdHzOmC1e691RSrayaSqY+TKVulKdPJQXfpW4qud7z U0m/TtlUMhXXU8mUlk0laO97dA9uKpmSLVPJiT6+KgEWQs97rErkrU+lGO7b yISKLBNI70r35bxTslUVUwnq+w3e0J84lbycuqkUej+wwRv6wg2erpjZ4OnS wg2ea+97dA+wwRv6bRs8K7pkg9chlPS8x6q0K4fpOaYSjkaiJEhEZVclddXu nZ27EKel1iG7QMmK7Ie+ke0qmocO28lLAHiOcL4Wra1EGQAWHdZFjFIiMgKw z1op+8u8b3TB8l2rdg+WNzJrrnPCEJUEy/vathvwxahibED77iS2oK88WH52 oSh4EiRHA/wEy+QNdKUXCD/ccYO/nrS74c+KZCC0CoBukOrom30r2x3ccE8F 9M0BiOcicWZrJNaQOKeB9EwkWTikX4pbxNU6rhlKr3cppi2qDaT3Y1ITSO/b 2A5BAYpXV+TUYj5fkM8UWU+njHdFeWR94pnGY1QFD2mFumbK0NZA6QWqQt41 ZNS/J++63XShk8lAah2Nkh2m6XTPNC/C9g0IVUd8K4S/S8yEpp3bU63bz1ON xxgHxVlydMlk5HOlF4hXfUpz54H94GpFMhBat3e0g7TBU82LsH0XeapJEw9l 0dpk0HpuzzWyn+ca50mqmSZqV7KOgYfSC0Qrm0aritr9KOqsSOyl1ilXO0pb PNe8DNs50DexV7Wr3pF0/vb8UpzWhr2c1pgMt30KJR5DU+4wZEuv2GmtEbmU gssk6jAMWuFNDJKomwfmHsqTqKdyTnda25W67odzWnt5uv98377/t6fx70/3 L955iMXECJyoRGOu0QilF6gxsRoHo16U2O9obkQyEFqpMM0ggb4c/Pre+/W9 P7q+exG2b9iN0iO70dfW996v7/151vfc8X21vg+H1vf+/dh+DNtRFvMQSBUC eyY5rjloofQS4crZZCInqF7mdsOrlclAak3oBAxTsCX5hb33S313PLIHZNjO gfimK0Rs7vzU+fNTf57zU2atzxicDuatS5IfMtbE/JskyWhOM5Z3V7pzQid9 mD6af3MBLmh0evJDL8BcBjJiiBTSNMKkHzJr/iKjOXUm84E0FWmEOwAVU8s0 wmr/ZK5VqRA7xHlCOyBZixdphHVBX5BGeA4omgBqrQGhdPfc5qw2LzU02pbb 3AjIA6ogt7kfCoMoWp7bXI7uZtD/N6gpfRwl6qy5zheI2pLrfI4plGAqx2bc 726UvEwlNRZAyhkNBzyUKymvnCyIgr4apktST/rF2pl6sgX16gknrEGZYARX er33K/rIZu9X4IuW3K/4MfFZzlXJBYtvZHssyXJ+UK3pZYieK+t5U3THIkS1 QiOJ71qGC9OV7pv1vNdKpCbruat/WtZzaJtRY7Q067kfg9OynvvW9lXKs54f BGFLsD42X0IW9A5phTBbY0/Ogp5AEgkR11iZyYIOpXvv2xhl9fs202jTvs0K yIGzKAu6HwqNrbYvz4L+ioJTw3jerOirjVtdVvQk9pTxEIIlJE3iRtZnSyi9 3rVWIYg9NQ+FrJEwJjWxp76N7edrjD2dXbcxGgDIaCAfIySTvRBKL9AaRwTG xnI1sP2IIoxIBkJrsvDAINX5dflWtjuwF/cFfl1v16Pre4+/mIVHqMD/0CO2 dk6A0n3XVCL6kNStJNrH1Y/LqT4Kar2HwvJ4dLcXRLgHm6SihwBomqUotbBx +zQ/BElcgmK0lzbaJWIs7NTEjXlksaGtbwBmIQYnXVvHdNYeuDNTxnVX8l0X 3DXZp32NhdOWGPASZXJ1XyanAv9phqLXVsiG0vOhz6YP73dPHz4Noq0AGtT3 aVoHemr6cJBTmT7c934gTetAC9O06oomFqYfjCNVSNOqS8tiYaC979E9QJpW XbIpTasVbZsdSR/eI5T0fCysLMwcG3jQj/ythzYzFClyKYsauslMHFd6xVvU xuZJG9qizSmMBuYVoS++ke0r0D6WUJgFvH2BHMA/fLgLQ/GsjWU8GGVSoUDp 3uqayYrQRajvA+oNqfGp6trKqVbXrvcDAfUDKQyo1xXX6tqUFgbUu/a+R/cA AfW6ZFNAvRV9XF0DFkLPx0IX19Pnjcf8MhQOdA1TcZ8zrC8XoXTviaMoq5o4 pr6fOAidPnGsnOqJ43o/MHEQKpw4umJm4ujSwonj2vse3QNMHF2yaeJY0SX7 nMHdrkLPxFyFVU2cM+ae33P6RNfOcEwwjDcZ105Xuvf06WqIXKB+4ETCp0+f rp7IJfR+iBMJl3Ii4cz0MaWlnEjYcyJhz4mEPScS3siJhEs5kSAwz/Wc+qV+ RdOHShljTUQSa5JxbXGlF2hOhChlSfaPUpakNtJEFKf09rVtN+DCh68+SnmG PhH4TiTC8dDAsrcpbO/blFFJRWsODa6+3/uM4lTlDXIqlbfv/cDeZxSFex9d 0SjvtmkaMSG/99GlhXsf19736B5g76NLNu19rOiSQwNTKOmZmP8H8+ZV5d1c mNbu5IoIsi2ZNwkDrgzZHqleynKpyfv9Nz0trTts2/qecgtNJ296nJzaTQ/0 foByC02FlFu64nremNJCyi3X3vfoHoByS5dsotyyoo9vegALoWd3ZiiYN5e2 26mYN3MuAiJDMINgJFlxMhn2XOn1GkflaBgw7sqc5GAwakgIfBvbUyS/eCVE 4XroB56nl8d/s4zRcHFPm0hIJVBgIZCNWDsjQen1Iq/BLkPT0NJJMVYCQD8m RhOxCTHk/suPw9C3tN2GFNGvoxCu6n0fPzz+tJ5a4a/NnPEOuSy99P7GXgMP Rct8uA8ifYafE0r39TRvZVghS4AH9eeOmUyWOGaGtu6hQ8H3reXdq46Zz5+e H8ePQxwBknHJhEpmSaU3uUYmdkpFt/TgjRkbUppL/0VVj1z0FZH7RlpTtl5i 4wvNNR7Hgi3WWbK6uyfqeIIG2shIYBFUnb3+XftdutLrVXUdI57wp2vHsUTV +TFR1mWtpc51rWUFPHzQ0nYLK26BqksMCs43jZ7DQynnJUdXHkqsBH8i4g/j aNQas9R74+4BgLzhDS1Powz1t6RR9iLcAypPo2zq89Gx8HKzvvisicfSKNuG ytMO877rg75cJk5+fnh496R3gDaXhGonGZvoEqXXcpfN3v0UIMI1Md3im+Fh un8/ehHuB+N3a2n+VGdFxEZaiOQ+fbM+UqVCQlsHt1GC90esbbR2czPv3LZy bvfyjkifidm9Lz80u9i+G9n1rDJvsJxTE1vNqdXZiR6y1UUSLdrwyPJNEkPx kKEmdqUXaChmg1SGRKvr9osCdzIZSK0zFtth2kCi5UXYvsH55HWal4tK78j4 bqRZGp/RlCx4sufI8P260gvE54RVY35Muh8NkRXJQGgNOmGQtpBmgQjbd2Rh fZU0i18waVYuGelppFkarShyaoQdCummTCYfV3qBaGVKGQqYtmn2U6ZGpEv3 qKVWpXt0o7Qt3aOTYTsH0qzXLQX61ORprDHOIPbMBFpUbCLQ+l/t59bjFUft qgKZNeHEaNe/Dt278aMGt/lBMW6Z24CFYvNtTQDjg/5iT/invWxYI91et+sa Yjd/pqHk3R1vIKsZ1DaAHH3b0DStYqTjG/P0bvzH2H96Gd99r99eb/2edX1O OWvtT0pMwoA7Co+TtQt0LRXu3iHbXose8c37Vi80UPbOvgblzt6//MC8ynjz P2zx/bP+qu73DH87A4D5Je/NuDx9enyJv5feeCs+jir+Xu5N0xO4f3f7e333 9PDp8cP4odMDT+4YHgdrswBfruRTAyB3F9H34/PzT62UVuoRaKdemGgGW9IT 6R7aziZPHynGPF5F2LZGVNO5q4hvvvnVH/+4vIlwkuNNRKj0ryai/eazltS3 WoO9e//woBdv9y6WEiD/Lp3NFcdG4ZeNpQSzucf2hX7z+9//15+/zbyQ5zmY VzINxU36Gj3wi3tg3+lTNB846I3QHWvGm4/th/E+tmL9XdMNvf4FsA0L0ucI 28ZWM7+68qaml9bllbXyJSFwp+0kieTsYWqalvo0MWtja8LdzTBgFYOOXAPc ZSxMRJ9bUOhv1zscQ1mwVEX6TeampYaM4zyoF7cIz4N6dcmhpfNxBCI/ymXM PotYpE7ja8sSlF6vZalBjbMsuQN7kREdxqSFWDfu6aaGAjM6tLUdg22p46/G vB1IyMghIOsMVnXeZqLg1lb1Q/FJkVKS8iaeh1FyHp6y5+Fp//PwJVFKFuVB 9sNgqCCxp5TEnlISV1FKBjlfcR5kyuMhAodYdEUGuQ65gNLrVYZoGF0sunko i0X3Y9JUxKL7NrYfUIKvZ7pZqD9yJXHolGMZXfd4PBHg3AnWll7gCRYzpbWX 3lHvZ2+xIhkIrTrAukGqzC8CrWx3YGKR159f5PHpYQrecJTH0LNGxgvuVq2p 1KD0AqFoiFnM3qrHu0HRimQgtAKKfpBwNKUcR6JvZHsDzdgUODPr/wvOeL67 Hx6QuF+7W4wdLjaVzJzMKIsJb4RsEt2Y4fZzpde7MLeIFDuZ+cGocTLzbWxP J67Ib9C/LLmZIzSqvxjvzSe2diyD0gtUfwxhYU4Eku6Xas7JZCC1RgHCMInT b+a8CNu3Py0fufuQawvy5eS3YaJZOuGeelVHIoURDRGvhs96fXSG0gsELEbU uh6Qab/bDyeTgdRKQnG0LcONF2H7hp0kfrsZbkiXwWv5ZV0SbKHhyqL/ZJLg JkP5BqXXu5rrX7qcT8OPBqaWT6NhJeu5b2T7ii5sh2FIJJNwB8cWGtSFaoru jAwbaljj8DSGDY3DYHFkMVSTmiuSjIdDt/eJe2goERVBP1Afgn7aiZ0Y9OPl 1AX9hN7zQT/6dcqCfkxFG+mM9JB0EoJ+TGlZ0A+09z26Bxf0Y0q2BP040fGq 7XDQT0dR0vMxQqQzTajSaCDes2mX2Gc9oUikhw15SbuWricUlO47oXrR8Arm DagPE4rz8dQJBXIqJ5TvPT+h9OuUTShTcT2hTGnZhIL2vkf34CaUKdkyoZzo oxPKYyH0/OOEChMqhDjxpkkiTdYTCkp3nVCtxE0NNyTUhwnVTO2JE8rLqZtQ off8hNKvUzahTMX1hDKlZRMK2vse3YObUKZky4Ryoo9OKI+F0LML5z7GxXG1 kyi6OITjhjEn5HgvbenunAishvfS1fecCGTYwInA6nkvfe8HOBHIUMiJoCuu J5EpLeREcO19j+4BOBF0ySZOBCv6+CQCLISejxHaXPWqNLuqJCRSFuM0P0pm WXKlF2hvakQnzI+L94tcsCIxAql19lE7Sg073dnWy7Cdg7Pt67TuqQvR5fna kmZ90D8pWS3FMdKmCccSM1xZez7d357/5jyL/DAYLHXOs8g+uIRAXbFn0UzO klPvmGeRQeUw9md0LCIEL1WmHoQlT8Yh37bEsQhTEbcg4UaJ6t9ifaHuSq/X 4ikodY5F5qEwyQWMiU1yIQuTXEAb20+J2XPpx3HXXobSG4a1G0eRQxEmEXTh 8NjRaVpfmkPpBa7SkNiCi/0cikJiCyO0JisyDFKdQ5FvZbuLnC0XnNiiEeuF t8KVKD164ZjboiE8oeLN0NG50guEoCNDlFop7E2GaGRW7RL9EBX5D0Ft200M Frx0MsTs/U45GeLHZ489FFlaSBOTFkuVS1psS/c1Ruvlp5lqc5W5RhtylYGA vlekPS3HrBsKrd064phXpkO5ypKEoJ1hyTDg8f8dRzhaYGzpCM6WYxZ3ZJ6q TL8ZHWaOaLbkkDrLAqqJDrqtYDlmV1u6O6Dqkxa7RtsAZZMWnwwoGAoNKApp sGUBoHxOdYulKWKJXhaW9Nq+wJIpqcESRoQF5dTTXG5PW7q/cqKnKCe6VTnR TcrJDYVJgD2VYykhhjKpoS8JQCb15rCI29MldQAKRm09Pk2GEcqVXvCJknav UJG9fqLEKCT+Wh8iHx/07xi+v0YNa0NqV+k2N6aKrk07ldhxiTjgOKh/wNYA aFd7GEFqBSDzWvNAO4qHdoYcPDXtPI2rKVF1yOEJcrKqp/kSqkedonrUVtWj NqqeBlQPG2IOV3JE9byKJf1tLksZET0cZAYpU3LI2HAAUslqJjKhm650f0ip UyCltkJKbYOUcBdMA0f7QAqxYbosSNFJLiBlSmoghSSXCaRyWUhs6f6QOuX0 prae3tS205sbCgMpuhukxsuCFJvUAlKmpApSlk8zQCrj7ulKd4dUy0+AlG60 DVJGwCZIUdBSzW6QGi4LUnxqF5AyJXWQQiFgfFJozZEGpftD6hSTQLvVJNBu MQn4oRh7ysRukOovC1LN1C0gZUqqIMUVizQYfeZg50r3pVqVklebLaHR6ZDy AjZYmdxQjH3XTgFS+Jhl4Aik6N5HvS2Qkkh0U2oItwVVdvAGJalNuix3dPcj oBygYCiMSzQse30Igj0ZUOiyAMXxZNimIqB0Qc8qAMUUDcHYrMuc9lzp3gnr J1p92nONNix6ICAPqM6fFV4BFAzF2KuhK79YSbxhmD4mXtQSJyYzTdIlzpSI Go3EOIkaSWUA5Eov2Ha5NZq/I84bxj70Jd4wfkyMr6CchtG6CJoHAQ9DPph6 TmuvHBjbDmL8k6vt13wStI6gcm8tVsg1JvAiwt98VzYDoCk5FDKdvxpGSeCf ymb7UnsbF4wKoax2SXSNNiyJICCjwai01CbHl0TljAut48bGSZjOQoORTMor o8Hs7Qu+HBWmpnGaqzBTcghBzzNSEkRCtFvDvIlKn2vo+vAHpderxtjQFZOS +MGoISXxbWxPTmFNxQpL98F8X2fwaKH92qdPrZhwCohJiBSBIszyXYf4yrUj M5ReojsVpYMhDeYN28+hyspkILXCpcoP0wZiEi/C9l3E82BDRGjO5f56OEk0 VqP3KVHB9U9NGZdnV3qBWNVfY7AuxJ3cj5PEymQgtcr9zw3TBk4SL8L2Dc6o 8qvlJEm9pTVeA+kTk6luXeMVSi8Qr9JHcne7wdWKxF5qpWo1o7QlpsnLsJ07 vI6v69bE3JID7LXENBGhwlZAUL/57FvFM+rVlV5xTFMjVObssoxpgmEYezk1 ENNkHph7KI9pSuW4mCZ+LKbpAG+3C2/qdnUmOkN4k+GFidS1CT0jyVkEben1 noRaLMCgox/Kwpv8mNSEN/k2tp+vJbwpCS0hQsQY5MhR25tT3koButLdo/pF ZVS/CFH9Si9np0f1i5Oi+sXhqH79OmVR/aaiieofhGha5DO2m9KyqH5o73t0 Dy6q35Rsiep3om2zV6P6AQuh52NcM8GQ4GL4GX67Mfzz6RNNCSzJYZzJtgCl +06faehquM+gPkwfgcmp0wfkVE4f33t++ujXKZs+puJ6+pjSsukD7X2P7sFN H1OyZfo40cenD2Ah9FzGLHOF00fE1QfF1Sfjfg+lu04f2U8Y9eXTB+r71UdM J04fL6du+oTeD6w+YipcfXTFzOojptLVx7X3PboHWH3MzeWW1ceKLll9IBQB ek75EA5MH2ncxNdkMtczkyK1O0WRnIOvb1GgdH8Szop9HNT37EwN2kLCWb2P C70fYGdqUCE7k664nkmmtJCdybX3PboHYGfSJZvYmazo4zMJsBB6LphJ17kQ BepvgWRCbpaLsJ/YVXMpS5uQt5BL2Y9GFZeyb2T7cqfu1/Pvmjtnn8+0/eHU +A/OpUxETJ0lQnC0oZ5enyeg9ALN547pgY/j7kwPRmYN1UgYoiKKEahtu/lq mB5m6GOBUR4xjz4pe7S2hkPpBWvBLxsN67//2I3tEKJhYeHMRMOGdZPsC5Ki qFfaNwSvEi6vbvg6WoSRwALHkb+Q7mQj1vQNULrvRnMy974VG01X33Pp4u7U jSbIqdxo+t4PcOnirpBLV1e0NKAN1mce5rl0dWkhl65r73t0D8Clq0s2cela 0Uc3mh4LoWeSBKu8utGU+itrqNn/4u4M+0zaDut9Zmb24JLZExnsOMXJ7Fkf 06B0X4NHw7GooHaH+n72EHyqwQPkVBo8fO8HZg/BhbNHV8zMHl1aOHtce9+j e4DZo0s2zR4rumj2uGMa9OzshV/D7Jl5l4jIxSdp4KCerG1neUxzpRe4PWaj yc+k2v2I0IxEBjJrPKFgiOqY+Hwr2x1sk8k1M/HN3JVJI2N+WZxAMBOrCqUX vEfeaClQqi12V/aDUeOu7NvYnuB2nn59/so88oTLYJwyngvZtJ3kQhlIG9Zy 42dB0H4UpFYmA6l1SY1JykF6isOyl2E7Bz3IXk3wKQ2F38JmcG3+ypwE9chJ Eze4Q3aDO5xHPR5Pvy3cfo8PO+bfNjIZSK0xYsEwbfBX9iJs3wBVWub/mX+4 Jo9lTpI76FS7ZvgoXekFIrbtOLaaaL+kn1YkRiC1UrnaNA796R7LXobt3GdP fl27BoBer7eyTa8IUI2kFoTjDAeBK71ib+WiDAx+GIx/J3beyvbBeZbiYm/l mZxlFptrz8CQGrAYixelIk0hn/VRPtMJ/DKuCPz3Hw1Tj7siwEeuCCTu54vt W7wtSDzaGQuxvZLQxF6T8e9ypReMlq2H5a5zHu3moTBhB4xJVcIOaGP7+Vo8 2mcbOkaiilIqsdBkfDlc6QVu6HBLrZVQif1OIEYkA6F1ZkI7SNVmQuR8PHR3 8cxxvWbC2SpJWHQL99QsLadDJoOvK93bLdxoi2K9B/Xhmoc1J0dVgJxqt3DX e/6aR79O2TWPqWiuebqhHwbscyWa0rJrHmjve3QP7prHlGy55nGij17zeCyE noklNzp8zSPF+sgjNZTtjY/+7+Xc+HRqtX/oiyZS8DYQwZzUtwpn4zPx3h4p GpqM1sVXmPrerbU7NXOvl1M9kVzvB9xau8LMvabieiKZ0kK31g4y97oe3QO4 tXbbMvc60UcnksdC6JnYDfvrF6arzfeVzaRkK66SQL/1JQKU7j2ThKwItYD6 IdBvQ6SSlVM9k1zvhwL9CiOVTMX1TDKlpYF+xAf6ER/oR3yg37ZIJSf6+EwC LISej/nt6MniJ89Vz6aQUb4RMXXv0OdoWWzprrNJKSn7inUJ6vu4v6E5cTZ5 OXWzKfR+IO5vaArj/nTF9WwypYVxf66979E9QNyfLtkU92dFH59NgIXQM7nj 4tXpRKShDc8zoV7XhIr0uo1MeI5y2eXVlwikNVlEapYnm3UEfv1uw4kJoVNO TK73AxOqKzwxmYqZCdWVnpigve/RPcCE6radmJzoggmlfCBtx6Nd/ivb5wVK TsKwX5cwCrYvk3Qnm0Km2T+FjCDdUM2kbxttYdJ3AvS2Xyqk59EpWYkghQyF bI2qgFSYSAzscz61XpJjD9Ez59hDrEshZTPqzYKSbAmrg1RMkSbV2qMDSi/Y hv+lU6S572+yfnJ34zO8liLNKiHkl3XkoSPa5jzJ0ci4uPhBE18kRzMlR5Oj zTETc8TILps0tvsSSWPFKTlixNYcMYJvUkNuKDR8XABamRqSJDEC4qh/8EXp H5NWb65/bEml/glBae3Urpc0KN0fS6ckhxFbk8OIbgOW/FDoJU2pmiWNZPj+ AqTOnGhvCSmTVm/uUWtKjmb9nEOKJUtaxqHWle6+S+rrs6LZRtt2Sf20TT0p ZwrqW4CU2Aip8yfaW0LKpNWbQ8qUVEKKxo13hsUcSneH1FC/4tlG2yA1bFvx euAjH4gK6WG2QurMifaWkDJp9eaQMiU1kEIs2Xj3NHuWo1/iLDfUL3y20UZI bVn4/FBoSGHmIMW3Q+rMifaWkDJp9eaQMiVVkCLCL3yjSZ29ghSU7g6pEZ8A Kd1oG6SMgJMh5Ydi1E8AqXE7pM6caG8JKZNWbw4pU1IFKc5UAqn1wgel+yaB oV3f1KaxgkYbksCAgE2QcgvfyHFVor3XIHXmRHtzSNm8eimibEHlskcSQK1t B1D6I6DiUGhAMbAd4MJMe68h6syZ9paI4ngiy0x7zbFMeymiZMj3YjITZhOl 7Z5pT/+k41hrFIdGGxAFAvKIGkZJj22kYCjGvvXWqLYgvaxsEo52EZF05qR7 y+XOEFXO88qakqN5ZedYwkm0WDYEh1y1R3tLLFGc/6IHTOOr2LB+Y9I9EGH7 fzNJ95olS9eJSfdmAGRJ0r1cYmNXurcyU5jKamVmGm1SZlZARpkVJ93ziY0J O5Ir+1KT7i1VmEmxN1dhrybd+/Q4Pn2+fx49jlDksSAiiZLIhuag8yiyo6QC vNFqzIQYDJ1kO5EKWJnYk/kdiJBwF35+ZOwbuAu/6LDtL/xausYTcPLtzBhY dMuHxn4d3pWhqzy0U38a2+Hx6aF/uX95H8GEI20ljd47QwZMrnRfpdRTzvpj SinRR65+0EdjZ5gb2DTXR3mPHd/WPjRGqTEXlarHsMk57jzeP5oZ3Q5GC+EW Oz+Zduq73ggZpYso9wPjoOPbGPzoERkepvv3oxMSB3AtzzsBWSGxkZYiuVuI zZ+fUyGhrXMxkRP8LrG2eYfmZt65bbWMaYSuGM+wHmoFOpJW/+hq3+PECu/m JRbRr0qMq7gevnKuOXSr/fxZ9xUisFHkZyUJTzAfsjTbwzXni9ILckm+KBgG wzDt80U1Pl9UU5EvKpVTmS9qfbYl5iODR76r/i0PycaZkGzjMLcINjtECpC6 TlIVLXDh6qknrcz4IrvSC1zJHWdwo/YjXPGcwUZmTbRjGKKiKEeobbuJnMHy 2Gkk4QyeGGFnOJEwxItYq8tY0XDkT28USvzhM2mkXOn1HovFMJWzosFgVLGi QRvbE0R4j18fKxqKIRg08Pa0WgWueXug9ALVHpZjS/QvSfeM87YyGUitSTUK w7QlizOIsH0DNqcjmXEFrMjXnsoZJSEOzJsOFeJs7XUEpZcIWP1izd2oZ+1+ 9KVOJgOpFYD1w7SBGs2LsH0DYJsCvowrJEJDONBMNjwe4ofsIX7Y/RC/Dz47 iYxBSCK1GzytSEuEZqRWZRp3o7QldbOXYTt3+OxJGXXflfGgBRM4Vk00gTch +JL0Q+YQ7koveLP5ZSMS/PfX55MJO3sNfS0i4bXrYI6a8UxxCcPCYsn7bhGX YEqOxiXMkRN4WbqWZHhZXOnuN8ENPeEmWDfadhNsBJiHvjGGoErfAj8U+jDI ULlLXcJBr/Fz1uvfdlo60I39IhjBlBwNRpgDKLgSkG7MUTHb0t0BVB2MAI22 AcgHI5wEID8UY9+yLt6+bQxGaC8LUg0alg50uuSov9MMUlzFC1211klQur9O qvZ3co026iS1BVIwFBpSndwNUurCIEXGJaTIYYvcAUj5u13VIbHeIEHp3pBq 6QnLnGm0CVJWwMmQ8kMx9qTBu0FKXhik2LSElC6phJSPwutp22QMvK50d0ih E7SUabQNUmiLlvJDMfaC9rtBSlwYpARaQkqXVEKKRUiJDE+nK9194etPWfj6 rQtfvxFSwjn6igbtBqnmwiCl8BJSuqQSUjTZnufYqW3p/pCqDeyERhshNW3c noOnLyO7Qeq8Dr9rSHVkCSldUgkpkmzP1wsflO4Oqa42ZAoabYNUhzduzxvY no+7QYpdGKT0t1xASpfUQQqnLrwZI4Ir3R9S4hRIia2QEtsg1TsjQof5bpA6 L0nPGlITW0XhsTpIiUYlC1+GcMWV7g6ptjb8HBptg1TLNy58bi/V+sBOvB1S 5LIgJTBfQMqUVEIqYeTL3bK40v0hdYqps91q6my3mDr9UBhCuv32Uuel8llD ijZLSOmSSkjRJHgqp6Vs6e6QUqec+NTWE5/aZOqEoTABT2o3SJ2XymcNKb6k 8jElVZBqZLiQ4aNaO79C6f6QOuXEp7ae+NSmEx8Mhd5L7XUhc3YqnzWkxJLK x5TUQYrSZHu+XvigdHdIyVPCheXWcGE5bNyeu4WvIwL2Ul0BpvSvogBKy4fz c/msMaWWXD6mpApTXKb78ww9lCvdX02d4nigtjoeqC03Mn4ozP7cY4oVex7o 36a7EAKfNY66JYGPKanCERPBz954Fa1t5q50f/+DU855m4g1vYDTN+UwFGOv BAUclax3rfQ5DDT6Zg/nJ/BZQ2pYEviYkrrlDiUJ7fHajx5Kd4WUnt/1N3vQ 6HRIeQGnQwqGwqTZI7sR+JyXbmUBKcuuMifw0QVVgCIooVvJsWu60h8BFYfC WMxhS47FdgKf81JCrRAl5ILARxccJfCZ2Q0Cx1hrvt461MeV7u58cMpNcbv1 prh95aZYyPEIovxQjD2bJoeopoDAZ8Z5cWGXeCey9swNT8FjvFUss8a50gv2 GN8YnihHZll74ItaUceiFGFM+OmsPV6E7f/tsPYsoxVPZO2Zn/+8+1RLiFyv iVC6twbrBa/kDYBGmzSYFZDRYGWsPX4oxp4O7dtk7VmpsDrWniTOHyseYqx5 4J7omilDMQ2l16vEeC9cMm3zUJZM248JNrHWUjasJNbaN7IdlWfT1v/HWKeP BoM8RypjrJZsY/nY/kML5xx1LC6d3ktPSZy5WYbSvRNzdT1DxaiD+pCYS2+f T0/MZeVUJ+ZyvecTc+nXKUvMZSqaxFwDpqqVDBJzmdKyxFzQ3vfoHlxiLlOy JTGXE22bvZaYy2Mh9EySq/UDibkWE0efqLj+4facPmXpuDDj63RcmelDiqYP jcQYTUKMkbtFH3a/TBgVpqQmgbGr7/PajeOp0wfkVE4f3/uBvHbjWJjXTldc Tx9TWpjXzrX3PboHyGs3jtvy2lnRR6ePx0LomdzJr3P6hKzFAkdemYlmsha7 0r1Xn5bWpYU09X3+byxPX31aCPSqW31c7wfyf2NZmP9bV1xPH1NamP/btfc9 ugfI/61LNuX/tqILpo/DQuiZJPfbX9X0ibZ9lUbtZLKqutKdTbEavhVJv6G+ X30oOnH6eDl10yf0fmD1oahw9dEVM6uPLi1cfVx736N7gNVHl2xafazo49MH sBB6/oo2b/3Tw0c/e6gIl62BsKdFvF0TokDp9ZI9jo0oIHv0wzD2tBsd2aN9 YO6hmOxxJiem9X2V7DE1GKJh7PXjnuir4HYkGW7Hrl8Rjk6HmPWevw/6m4TT AyU++ET1o1jrbyi9XpMPkcSZfMxDmcnHj4khvBPSGpGPWnx8G9tPucUnXLrh u/aHN/jkuHWGYcVTdvCmJN0zSBXNjNHFhPSZGDoovUAaKKATndj+dKITq6MT 9UNURifaQyReM8EtCRHB4l1EJ7orofgWc6NYLbklLGRYRoOJCMFRHZ2mtcEE Si8QfiM28OMK7wY/I5GBzAr4+SHCBCjn+xIY+la2O4BhzB77qtkbo3MYvGkj 1gjs1vqviMxWb+ijza7xp6ZONpnIFyi93lW3aWgxma0fjBoyW9/G9gTLbf/V kdniJmo9FrgQWolohszWlV6g1uuR8zYZ+G5qz4pkILSGyhYGaQuVLYiwfZ/A DPq2mWtna3LDE++FcIlBWpUjXLSll4hO/TWMmtmRuNaKtMygTR1xrR+lTcyg IMN27vDZvY5Pnw7hyohBE4sNl8nmUUU/r0x+Wyi9YotN3ud0mZ4DhmHsZT9B eg7zwNxDeXqOVM7JFpv+bVpsPvzz+W/v/e6Ri3hlxWgM0cjQfEPp/vlLqyMS XaON+UttRKLSG84OzZ1VCbzPqxEajoa7VxQi8UmB87NXZgwcnqlxeD2jwzOT 3czdqxUjnTk824JDDs+HYNQoFs0wQybSx5V+BTA6lrPUj4ReE8cYlXEURvpX 8fiBRTEB1FljMpaAknSZApe+kgL3IKCESPRSxq7nSnd3oj+Fz6HdyufQOj6H HKDKQseYs8gp0h1xQU0Qpbvo/F4LcHTWcLEljkxmbj7MEwXokvHQrdjhFS45 rGZWOCi9XvsIGwfrTQ9ftMRM4seE+5R7JXYS38j2WOI/v0Igp7trsrL9PWcy cxQly92VOGQmOYQ9jniMVkSZ3ZUr3RN7WgvIsT9KxxYw4+vHzT1Xwx3lrf8d XvFiCG0zustY+tfODA49998FfRjHwMSI8dUVRFJVi6Cou8m3tq/isgckoJu3 brpD0NOra2u4urWGmZqp2XWPTxlfQzB5saUS5GKuBKdmnGeCNK+IK4FIaQJE vKbthtJ9l1ONieGoY+dyOXWNNiynICAHyaKIDj8UGlGtKo/oyCyn4qxxHev1 9PS4Dt7EnKJIJS7CGR5cV7qvjyOb9JmrwsfR1Q8uwvxUH0eQU+nj6Hs/5CLM S12EuXXS6sehHbAMLsK82EWYexdh7l2EuXcR5htdhHmpi7BCSc/kbihw0gqW P+eq1bK366o1m0RcRcsfj47CLKOOXenejsLDWONn7+p7R2FKT3cUtnKqHYVd 7wcchSktdBTWFdeTyJQWOgq79r5H9wCOwrpkk6OwFV0wiRwWQs9lno5XO4lk NBGghPIxk0nYle49iZquwl0Y6vuVSLWnTyIrp3oSud4PrESqLVyJdMXMSqRL C1ci19736B5gJdIlm1YiK7pgEjkshJ6JJRr4aieRiP5zieE2kyIKSveO+BpE XcTXIMJK1EzD6RFfgzgl4sv1np9E+nXKJpGpuJ5EprRsEkF736N7cJPIlGyZ RE708UkEWAg9p/ntv8JJ1PhJhEmSK5evY92hdNdJpGEz4Iq4L6jvJlE3nTyJ vJy6SRR6z04i8zpFk8hWXE0iW1o0iXx736N7sJPIlmyYRCD66CTyWAg9f3Ur URI8wGPsZMO9107btTTDmuRKr9dMzwUFvgj9UBY84MekJnjAt7H9fC3BAzNX MU6DBw4OvrMKDdP6HA6lF+gqRrhs9G+IxH6uYlYkA6FVKc7dINU5cPtWtrsk juCYV20E4tt04/7eozDGTTWSJAfZXNi4Ld37rlsyLItVH9SPdnmml1EyRTv7 8Z2DF+EeZPQFGyc6HrwsgmseGIL09NqiXrKQXjpUthc94sY8stjQ1jcwMzdE BDt1Z+uYztpDDrJE3pEB7WrDFyuY2ddYuG2zbugWKGuGJcqaQ95es30qRjFU QCVAyxDLudILVHcuWEq0ze7BUkZmjVtsGKKiYCmobbsBJceuPlgqcsqxxp+R MCJ+f6fX7UyWVyjd94zUSU5qeeqh0ek3kF6A0XOdVu71PKswFGM/NODQ0xdQ Qes9YPCdHiefRoN0580f1RHOU02m34wNswAUW3KcszdiCQmRZLnrM4kTXenu vOLDKbziw1Ze8YFvwRIMhSEJgvSuJSkPVIujHz6KWDpv4qgllvSb8TmWbEkV lmRwwleNYBnbjSu94HMnfW3z9fq501DMHwyce3wwbg3++5s038g52JgEB9Kt S6aOrk47lagh8FSF/xqHFV+Ax739uwhSK/yYl5qTpFI8tDPg4Klpm6VXTauq gBOMfl0zZYx+ULorcDoh+rE2LyI0Ol0JeQEnKyE/FGPfIFrORO+Dgfx/L4iH fqGJLO18ukGyBTX7Iw2nJFcGy+bKYLt70EvJq+EEjTasaSDgZDj5oTCRGJBz ZShweD4MJ72wnTfX2GphI3ow5q5apuQ4i3i6SWIJm5bIRJe50v0BVZ0YyjXa CKgtG24/FCZheeMAJTcB6uyZxlaAopNcAMqU1AEKscSHNOvMjHc3U5mftjq3 tGu0EVB4C6BgKIwPab8ToM6bZmwFKDapBaBMSRWgJPYU4QPhOJMN0ZX+uIOK Q6EBNfXlUWN66ysuNvPKag8luknOM690U38080oCqIaSCCiy3kNB6e4aaqgO GnONtmmoodsGKNJAxlbYkrcFGuoIoM6bwm6lo/jULnSUKalb9ARO3N1znrq2 dP9kPiekQjSNNibzoVsWPRgKvYsaIHBCbIfUeVPYrSDVTN0CUqakClIcpSe9 DD9J/0XyQw34BOulabQJUlZAHlINBmy8ftJzlnDFmoqsiPqHi+ZLEcF03lxR KzCZzFBzEhFTImrAxJSMHCI8AyZXesHmy41uMwqNPlcUH4pzRXHnNrMlVxQH YKLxzeSKEnjs6R65ohIAYkaiNsuYQaF0b23WYXrMeWGtzUyjTdrMCshos8LI QhgKDRo+HklpfqG5olYqzEQQ0uKYwucZiSFDceeuaPRMyDhiQen1qjHRdcUk hn4wakgMfRvbE7j9tV8JieHz9PL4b8/j0+fgAkhk3I2Fu2STSGt9lwyl14s8 3lnS6r7Tp+1BlLFowphwo5ImxJD7Ly9LVuauo3kH1NUs2DFeZ231fZxh3ZR0 sW52+hi5dng+pPVe+uD1R2RkrqY04SVZL5xQujNlkp7CR0+WKVuSrT/nhmCy hBsitHUPyXLZ8u5VbojnT8+P48chjgDJsEJAJd20pTe5RialrIo0XeBGlTak NEUZXt4JUdUjxzlI5L6cg5St3ezjm81VH8eCLVQfkUtHQKIOEQ8mvvZaWPS1 T/wAp8zVkCu9Xp0nekeJ0+vTu57IpYuuGRNlfO1VS5H7LytbeuF2qQdeHFKg 8xIfQKteGD2HuzOVK9U30pW7MyvBn4gOzzzJDUrW+IPSndlIhOEiKFd9rj6o vgahaRJ3dGpNgFDXqaYt0IAgwj7IXp82uI2YQnouZh2enzvwdjb1W2lWybY3 C43psxfEgBe+QQeuzqy7eX54Gvvx/vMIDbm0jq2madcHxRlqmb4G3dfDg97i t4Np1FC9JYxN9LSgnUuN538KEOGamG7xzfAw3b8fnQj/g/G7tTTvsm1FxEZa iORuipk/P6dCQlsHt9FnKI21jfpubuad21bOQ2m40zs828S/Lz8YT7XzDchq Vpk3WM6pia3mlFzOKXrIfSTh5CaRUqKhIplT69tZKL1A3+6JKuKI/IfdvLud TAZSa7IRwDBNp7NyexG2b6fv6VC2yb0EVm6u1hr/VFZuEgPNaUhPpSa9pqxD rVzpBeKzlyb2gKJxP1JuLdFyclNrvCwGpx+jRp3Oye1l2M4dOkf8KjolYnmv hEsg5mbdGq2nEXNjEXUpaZL9ccYXz5VeMTF3USo1PwxmY4sdMbd9cDtsXE7M ncpxIdGkmJjbmX50n+fLpdYItIRgv4rVGgq2yLgJEGQhkXmrSLOmWYPS6z2i cTJCOLR+KAyHhjER9mgmx6JwaGhj+3HqsJc18dAE+d4u5HTGVoFaZWHRmMX8 LsF11GQ5XOs/KL3AtRoLgs3S1pHdFmsrkoHQmvwuMEhTTVS0b2R7AzM9r4mK Pk9QtGBrHJ6c2wqpyJNHm+R2O+Ny6kqvVwvKqbeGKi1umIQovd1mlSmufBvb IZio+lc3hYmPzmJXSM5yt43plDm2rDaCJeklkYpG+iamaOFTDoCudGePQr3y VXDMQX1P1MjZicw+Xk4ds0/o/QBRI2eFRI26omX2aZhKiBp1aSFRo2vve3QP QNSoSzYRNVrRttkRokY/iVzPjtnH7SRyzD5EotZNGf8QJhE/J72PJHTFcLEy T3XtUfMUUonJtwluIqSVOZ45W3qBW4pRIke71u5HteJkMpBal5XLDtOGpHFe hO07pjN8M0njMgf+E81TGp8xaRynkQdxyLgxudILxCfDrcsm0+0GTysSe6l1 qYTtKG1LGudk2M7hREZfxWeyF2kuz0JFhk0WquB0hxTFgUwD00CmIdXaXQpK 9yXTaBvMq8k0XKMNZBogQO8z9FHdxOBUk2m4odAHsBZciHmBB3Hi/TQJdlFu w+M40QWDhik5ynqQAAjJwLZnCCLWTEBQuj+DxgnplcZtkTIg4HQAwVCMfYe7 cgAZAg2UUrFEThaNqOvgZJkhKtiM9ICp9f0OlF7wUf3L8mj47z/2bd8Cj4Z4 nUdDrlKhSj1M7EIoNNDEFxQapuQohUaKGcFFgpkMJ5Qr3XcZI3qLrGqXMddo wzIGArZoIUil2zonImwtNDXRVXiaPxg9hC9KDxkSlkV0lSk5Gl2VYqoJCU31 kLVZbqh2b39e++vWZqKERhsxNW3DVOuccbVCAkypAkwZMgqLoIl6SJEIqetg 0kghxVEKqUycuivdHVLVAXvQaBukXMDeBki5OPV2gLBiPBYxHwxA6urwRK+N SCPFk417CXjKnN5c6f54qt18Q6ONeNq4+W4pqCgfAFqy7MkmCQBl10aiMd93 p8opw3ngSncHE6llZYFG28BE8EYwAefBACQapKlQTtG8xK+N8mC2g6IyQVTW NtDubhugXadqd+XQaFMubytgE6IELHcTqKcCYrt4npPyOpnt5hqKJXhauzJB 6Y94ikOh8eSTwxNawPOTtRVcCcHP3GCgEk67DNuBK92dOqN6sYNG26gzDi92 DSfNESj5oTCcdhAHN9bZva+FLmMOIJmwFWSy17rSC7ZSbqXL4J2LfHNftMih CMaEb6DLABG2/6+OLmO2uUrJf3J8La50Z4eiVlFWTVFmG22hKHMCMhqsnC4D OFYa9lXSZcToBKRQzJQVXMM72Yi1+QBKv/boBD8MY99g4qIT7ANzD8XRCTM5 zq2LfY3RCUiqoMX0JPAO4oTIDHeBK73eZZSOjYtOMA+F0QkwJszFC5Qla4M2 tp+wbpYHJ0iTW6tBvsczeL/sGKGAZJL7mfMkQiuzjLrSC3TX0grMpjIa0H6J 24xIBkLrchnZQapL3OZb2e7Af3B6A4nb9oxRcNTFcDvEkjwQZG0ug9Lr1YXc urCWUVf5wagJTvBtbE8AOFUWT/02YxESD2rrNu1DEVD0UJ2yHqrTZXqoDkPT GFIHQcRuOs/JZCC1zkXVDtMmD2onwvYdNeBb8aBmQo3L3IKnelA3kYCCSW+b a7uWZPaErvQC8an/v8mlytm0GzytSOtBbaTWRA3CKG3xoPYybOdFMa3+Zusi HaipWuO1woE6jexqkIyX8CH176RQjo/Clu6ds72nFZFdUB8iuyhrT8/ZbuVU 52x3vecju/TrlEV2mYo2sqsbCel9ZJcpLYvsgva+R/fgIrtMyZbILifaNns1 ZztgIfRMrKvUsZzt1Gdrx805w7lGPqySeZZna59Pn0DnYokMnbbndFz7REHp vtNnMikLKqaPqw/Th0l06vQBOZXTx/eenz76dcqmj6m4nj6mtGz6QHvfo3tw 08eUbJk+TvTR6eOxEHr+aqdP5DsO2d462cisDVfu7gLWiw7JqtXH1Ifp09CT pw/IqV59XO/56aNfp2z6mIrr6WNKy6YPtPc9ugc3fUzJlunjRB+dPh4LoeeU Huermj6ROzc4vXXNxLIEkmzvzds4DfqXLp8+UB+mDx/lidPHy6mbPqH3/PTR r1M2fUzF9fQxpWXTB9r7Ht2Dmz6mZMv0caKPTx/AQuj5q50+LHhBkJTVIsf/ a0t3nT5Kybar2LxBfc9q0dATp4+XUzd9Qu8HWC00CMtYLXTF9fQxpYWsFq69 79E9AKuFLtnEamFFH50+HguhZ2KzOn0V0ye5f+cyHH14kzCt0vXRB0qv+P49 78i4vH+HYTBU/9zdv9sHl3OAl9+/p3JOv3/vz3T/ThEeltar0+7fueCRHRDF +/ccQZsrvd47J4aVu383D8X373ZMKu/fIWJA9/Mm798ZWRtPK+7f0w0EZ/H6 PWRu7Umr1ioQSi/Q1k9Hc/vedPuRpRiJCGTWMfnAEBVdukNt2w0QtPEQulLE C0jOcBHatmv09Sv09YfCCVaJexDHMYouhBUY0sT1vTuUXq8OpB13rrxd14ux 6Prdj0l94h7f0nbrACiP3cETSRa0ZleRxEe/frz0JCQxg2cWYle6Kwj17ktj /9heMIIH6p+UxMe3dQ8SnZDEB0agLokPNDIWYxU4V44n8QHH32vL3aMRF08f WMRrdro+u0Pp9ao9LpBTe1Lvgsei3D1+TOpz9/iWtlvI5XCELF/4nd9c9V1H Fh/EEkpHGu4w6DRlHN9c6b6hDHr3Q1C57oP6m7L4gAj7gAdZnsXH1O8sZCWv yuJjGjbMWVp106IsPq3qhn5KmvS9UpBH2v8UIOJgFh/4wfjdWlp5Fp8gJLQt y+ID7Wwrx4/UX3MWn5kbFeMopgUUiZtfjijVll7g0YowZWyjAu93trIiGQit dPKzuxVZ5dkMrWx3cMhSVZ7NzV1zBu0uxvUp62TPZoaDlUnQ4GTfKp5Jg+JK r3erIaepPCkvDEYt7brb5uqeYlLeC/ZsZhlfvNM8m/XqGYM5WLiOGjJklFB6 gSqvHwQxafrEuF++CSeTgdSqcA43TD6c4yTXZpBhO4f97uvnfO8yuvIaPTdP dL8fTzQm0XEn6kTSZiLfoPQCsSqoMlDVf+3n5WxEOp7otsrL2Y9S02/hiW4h Nk53DsqTHU0mfZEezmTciSIaiaBURbil7Cf7pZdAdaW7U2VUk4xBo21UGY5k TJHxFNYVPxSjPjFhZ22SdVQZo2rPS5VBF4S+/YQXhL6m5Dih7wxATWQqYJk7 Hle6N4Ba/QtWA6i1P/sGAFkBpwMIhmI0AhyAVC2AxGUBaJjIAkCmpBJAPKG6 yGzrXOn+AKolqYdGGwE0bAMQd9suxaUD0FQAIGNjBm7xcZo/GEidmbZ+CalT aesTSDUYJ7uvDKRc6e6QaqqpxFyjbZBq1BZIwVCY7RFcobAqSE1omj8YSJGL gpRhHJ9DypbUaamY+EXva7OMUBeeaPPL8tb7769Vk1DAW09f460nkXE82WID fX1jGXnOQV9PFvT1eGoW9PWm5Dh9/Qw6JIFO5izoSnfXRvKUBU5uXeDkxgWu cYc1JYB6dahjr19hSWujM1ONL7XRqVTjM0ilZBKZuCBXujukFD0BUrrRNkgZ ASdDyg/F2HPVAvcqLsCUt1VdDsX4EkenUozPcISi6Z6tcQSl++PolI3SNs5V EHC6aoKhGHs5QH6fElLojnuFxBYPF8AzvkTUqTzjCaIoYwnjUmaf5Er3R1Rt Xg1otBFR0xZEwVAYV0fhENVtXezOTjS+hNSpROOpkmIyQmrIQmr4EpBqa/Nq QKNtkGr5NkgNACl/miPbIdVfFqSaqVtAypRUQUqfjaI/ZkZLQeneXON9V220 dI02cY1bASdDyg/F2LN2CPSqR7nrj0DqzIzjdMk43i7I63XBcfL6FFAiYRxv Mu44rvRHQMWh0DqKgo7CrIC8/giizpwOYYkojhcc9rqgP8phP0OUTHiyMnEL rnT3dAjVSe+g0bZ0COjg1ryl43hMRcFQGCIrQFT7xjjsl2vcqRz2MwA1CXfI mvsUSi/YYrnRLathLvAFvugB8+WcdxLGZAOHvRdh+387HPZkJw77GQBZQh+Q uRl2pftqMK1C6jnsXaMNGgwEZDRYIYc9DMXYSza+UQ77pQo7mcMescBAgcLR TxpelNU+HUq/9hh6PwxjN7bMxtC7B+YeimPoZ3LeXgz9Rg77NIgZ0YTHgUVP +2GdKRZKr3gdHSyJ/dCWrKB+NLCJn5dStEUOztDI9gUe9Uc99DCbHwIsj0g7 0C/BI1Iax4zWDnqZ2NGSKHpEgy8pD37PXTNl/OuhdGcWq5bKCgpSqO9ZrKZT KUi9nFoWK+j9AIvVVEhBaipaGp5GnyNwYLGaSilIob3v0T0Ai9W0jYLUibbN jrBYQagA9ExsdMphGh6iZ4udPuHhB5lQpcQ8ktCdeK0QjbRwvEmYebJU/HTv o/U4DWqso4Uz9f2E6vHptHBWTjUtnOv9wITqceGE0hUzE0qXFk4o19736B5g QumSTRPKii6ZUBRsC65nYi9pfpxQ5qov0pQm7gh0bU6H0r0n1ICrVihbP0wo dvqEsnKqJ5Tr/dCEYqUTimUnFCueUMxPKOYnFPMTim2cUKx0QimU9EySo+5X PqFCzDxB/jpBMYHXZw4o3Zv3F6sa2mxXHyYUZqdOKC+nmvfX9Z6fUPp1yiaU qbieUKa0bEJBe9+je3ATypRsmVBO9NEJ5bEQej5GXHrVEyrhoECER4dw772r kKBrPycovd4zPCKtI8IzD2VEeH5MaojwfBvbz5skwtuYiC7qc6VUPMGz9ASf pQLd3RK+Jw8en/DuPHhGZkUoaByiEooGX9t284Z48HL2o3IevCQYWSlJ4nGX JwbMXDSMLb1A9OGBtMYoOPLd4GdFMhBaRxUypFHzxVQhA0TXjHAZSNjXlQRR KRaQSKk3vKhJZkhroPR6l2GKh2KmED8YNUwhvo3tCfD2uiV97UwTHt5mVsRk BZY4Ii84/Cm9Gq9t6FC674Gq0T9CTSIVV98dqLppaE49UIGcygOV7z17oDKv U3SgshXNgUpvf0bKenegsqVFByrf3vfoHuyBypZsOFCB6OMHKsBC6Jk4pU0O nqjClJntZQkXhjLV/Bd3ZzhK0S5zlGrH5Uzq8DEWHr0VDycpTP1JSvY9Xpv6 oPQCNxM9pu5HFWo/Eh7sTkhOasV2wg/ThvSiXoTtG3R9dyR94yEHyotg4mGi WaL1NCYejVcab+9lsuXIKH5XeoF4lZMw6UYp2S8DuBVpiXiM1Aq4+lHakm7U y7CdAxGPpTE7DNisXr0IJp5mjdWTco0qoaLRlwSoNoJljL6udO9bFFSZrQrF bFW47U6/RUEnZatCr2Sr0q9TaPTVFZ3RF4+9Yt7oq0sLjb6uve/RPYDRV5ds Mvpa0cf3KICF0LPLlXh4i5KwXmtcmm2J/u95tiXt0LPp9G1JOnkSJ5k0U6JY Tx4o3fvGRNC6TImmvs+UiPrTb0ysnOobE9f7gUyJqC/MlKgrriePKS2bPNDe 9+geIFOiLtmUKdGKPn4FCVgIPZMklPcNTp5OrSZPf8zNVs+dkCKDBoIK1Y9q TVABpV+7l60fBj1bB+oyVdkH5h6KvWxncpYuJce8bPVRDA1aWZ7PyZYQvAJg vwLgdOx+Tgms4nU3S6671xZqKL1euyDm1F3PmYfC6zkYE3s9Jwuv56CN7eeE 6zl8117GZnsY1sboAoNgE6/k2Cy8Lpsfg5wnP0bhlRzfj0o4XMnxKiLhOEQl VyG+tu0mmivkYdO0nlydP/3ZK7mJEXaG0x5DfH3ay7gkHLoNSS0TTZIfEqvk UjjL4cPP45NwlMFfYGyvVtl+DP5GJAOhldfCZpDqruV8K9sd0FfTY9dyZGU+ O9PlXCPWcDz1cq5hSZwLTa6JM1xArvR6F+Fm6Mtp/GEwqmj8oY3tCQxgY3Fo qO6E+c7OcSvXrxdhhYsX4XiXwGRcgxVKtn0ZryxXeoEasGt63lqPu3Y3Fehk MpBaY5yFYdIa9OTLBC/Ddu6w2TRvktCfq70I/TVUWVysk2D6IROD5UovEar6 LGZUDt9vsbYiHZ8/r1utYZQadfo1gpdhOwctysdTfRwu4TKBdZto/aNJh6Ek 87PHa6tIk0k46Uqv2KTTCHXcpOOHQW8EiYTk4+aBuYdik46W883Dx4/6p73X P0b//uF5HG67f95OD0/j/Xcfb79/eH752c3n8eOn55/cvozvP44vty/Pt0Rj UP+e/zQ/p37+GWt+RhD7mfzZz352A/K0nJcHXfdn33/qfvbw9N3Pbn6l0fU4 3vbftxoIRlfdP9/+n/+//+//+bM0HbUyR626tFa+1dgzJGJOl6O+amdMaLXR S80lalUopm1hyO+BW8Tl+hYBSvfN00q7VtLyWwSoH9kq9DZKb32NRZ5yjpoZ aUX+AsGLcA8mOQtMnXGi2VyFFjV/t+kK/RAkVwe0aXvJAkV0qKwbN524MY8s NrT1Db7YnQhq29YxnbUHiAWU2fXTfY//YoUy+xqLja8Y8BJkq+yses91AGT/ q/3cWphJFWGGlIfZaNiyV/ZOKN0bZl1bm3QFGp3OjOIFGNYvZpGWcjtRmlHR KS+KH4hx6MQYKDILqMKwT9/T0PmDPUGdkyoMte2SKqxdUoW1B6nCcnDCjPgc PhPJLfZQ+iOc/ECMg6DAZai3osfxREeF42EnQdJ0WUgyBNAzJOmCKiQh5kMF 9C4gY5OE0rt+7Ohkz5wlgPK1S3DV84b13Vi8GkL9kLkXM6FRwca7gmXQt7UH G2NJcil7zTLY9rllsO378fEFx3HQmwtk40v8I7XA1huuQdjm0ML0ywi0zzSn NgaWJE1MCxQP2w2ki8Yhf8vgChpKbP4W/V+yb8AUXV8Julebr4+4JyS9DxxH xfSOfJa/RZdwVLE+csIjc1gmnhxK72ze7XIYQu0yGBpy56YChrb+iTB0beth 6Mdh7CXxMLSPZTBcNT8KQ7ODM6jjwL1jHbKcLuxtlgXb6SXA0NgnKWfzbdpA ZRUMEY4wZOttGpTehYEsgyHULoKh8Q2q0Yau/mkwhLYnwZANwF4nAwyZLIfh vDk1vmxwMVgHQ85bcxNu/ttcBAwNkYqcuefYkkPuOQe0YSAgo63IxO+50p2Z YFum5kfJ49s7aLSFCdYJyGzvCnkUYSjGXvBIVn2URzFc7a3v+Mwubzwrs+Jy m1fLrJje90mFIqxEkiQt4/UFpVd839fbYDwjbpiEKLv2c2NSd+3XgruX7hAc H17Plbw2U5u2bzgmL9z+SZYExWMSr1RkhjTIlV7glYoammE0vwntd7tTcTIZ SK27U5EbI4m8CNs3XKmookiibETRuW8AaeY+5bQbQKlPMsE0HIwsLafDejMI pRcIVzwqc1fNxH531VZkD0JrXMZgkPh4+gWgl2E7d2gd+iNo5ZcZRTRsuviL jo2SiiSKqEmiiDJOFa5070hn1tZFOpv6PoqoO5Xc0MupjnR2vR+IIuoKyQ1N RRMI0Y1iaJoQRdSVkhtCe9+je4Aoom4buaETbZsdiyKiKOm5LIoobo7x2EI4 RHs5Ic4V4RCzKRTJAqI7ej/KtW8wlO4biKdM9H1FIJ6rD1OIdPLUQDyQUxmI 53vPTyH9OmVTyFRcTyFTWjaFoL3v0T24KWRKtkwhJ/r4FAIshJ5JknHrq5tC IaSIsSZepLdrphco3XsVoqSGwNDVhylE2+n0VcjKqV6FXO/5KaRfp2wKmYrr KWRKy6YQtPc9ugc3hUzJlinkRB+dQh4LoeevehVCYQoFpg2z481MIVd6wfaZ L5tx3H9/fQ5ovNk4cmtlMo4vYEP2pXgryi9OB7TIL55HyliAlCaGzwkR/ahR hlbLle4d+9yyCvplqO+3/ORkZQtyqmOfXe8HtvykUNmaipktPylVttDe9+ge YMtPtilbJ/r4fgWwEHr+2vYrwV1WUh51LUnygY6ZZHuu9Kt3l4Vh0CrXeMv2 /oG5h3J32VTOMkvFgQjow1wwNudQt6su/8FyDoVwaEljxiEW9HkrUYatGEov eOXfeDPD+t6FQ5uHsnBoPyY1bMW+je3n62YrlhTTGDsQuBLJoDLR+K70Ai3d LjQaTfsxZvnQaCOzJiQrDFGJ572vbbuJN4SvhEav2IrPFRqNyzJeFYRGSyKT uxaWLMcZBehKLxCBEBrN9DZl99BoI7TursUOUmUUCLSy3QEWh6uOAkndIwgL WpAyGokDx/X1NJRe7yJMkazhKraDUclVPLpbZ90TIA0dy/rn/u9tekHcf2j9 aotViCyl4V5ZTQpl7utc6a44U0qMuGMRMw41AxLGMeXYkcTFAXkZlupXjISw uw67gzwe2RJ45odswiFk1r8JX+LgriikXB3lhbpp+799un8ajbWSylZX1rrV RHGYvv3w2FZQUTcTzY05On747il2p+uR+La+qTu3u7oWb+PNpM/d3jyqO2yt Sxs0NccmV9ybL8Am1TZuxHwr17s5hGeNolZgOKcnh3Qpbj5/fAfHdOgJ+k3e FKqYM1Wvv+LDXz89utfs4Uhohv8uGRkzyGhs/Pc0DXTjgegD2Yfxft7W+EHd NR2xjVSMk7FVjTlNQSzY80v7ErGppwanLVietTTBkrmva5qW/GbextYEa+8U FxhXG3c57jXaUObcBPpxXxIEbMImlhpAv8p8s8P5OC6Md/1qs9P3h0LB0vkf aWAY9zQwLSFtxvTgSn+c/3b+M9zP538Ynvr5D01fn/+mw8z8N8WnzX8nsG7+ p2+an/9a6nL++5Gx839o+4PzP2lbOf99F2Zqcunmv5H22vz3bWxNmP9UH3bI gfl/0O7TTyP0vO/J53RdMC6tkP10KFXLTBeEqH1CVfTdIWsfMyj9SnTBBUTU z0MX9fKzLXTRCOhb/TXNlcUsdPEAA2Xq2264CoBAjbLo2+7mzWuxsOQQ67tE bDASd7Xi17i2444sXNubqevJbBaZkkM76o/Pbg4JFZ13mEhzba3nEJTuO4cm RXtaaTuARqcjygs4GVF+KAwPrgqIwsejq19F1Fmjq5eI0sdRPKUGUVtwSCvn 8MSDM5hxk84y/8i9g6vfKp5gKIwfeePwVBJdfQRP9LLwJLpFjLUu6A/EWGf1 k+LRtplJSAGlu+KpE6Lvhko8QaPT8eQFHMCTXvePrXgwFHqr2IqAp3w015Dl SmYDv6z1TUz9MLcYmRJRs76pZH1ja2cPKL1euyQflA3bgi9aYp70Y2Kyl8hp GG2wgXkQ8DDkY2QSa6UXYfsPd4WF3I1U7q3DyiyWROCFxdJ8VzbDnyk5FAqT x1+S652twwahdF+yEa1AOlFLNuIabdixg4CM/iqLRvVDoTHjsj+WRaPO9Bc5 a+zpWoFVxp5+ehyfPt8/jwCj6LPGqIhmL5m54nOlF3jFJ3ulf349rwbRSbZT YiYrE/ussweu98DvEUbGvoHzexzDOdC7Pbb0AI+W8Tr74f0e0Tiu/R4r7olX OArmUxpYi5XEQyZ3hSu9QBzRkXNi/PDGbjccOZllOPIjY98A/GfVVwekYHuz ntc+YiHDyQalFwgk1YHbPt0NR1ZkoTqCcbEvADBC1w6jp7EdHp8e+pf7l/ce SjxZ2xJv0kzCbSjd94hH21ZMxwg7ktOdqx92R2NncpyyqYQpxre1D5bwgwF9 pAZQzhX78f7R7C/awVgxuxFP0nrt6x+/NxyUg2FXs1cWbmAccnwbAx89IsPD dP9+BCFhANfyvFu3FRIbmfsV7k4F5s/PqZDQ1vmOyAl+l1jbvENzM+/ctnKA Z010kYHOGC/wXO3MD6D2NW6swG9eaOGz2k9s5THDVx7U6pAO/az7+uhRLwPq Qz4L40O0Xomh9Hp9qDGVhT7UbtllioAPtXlg7qHKhzrIcfdotDnmRO0j4Q8Q YQ9Kn2t3VcbljtSYb3Kkjq6sQrHoXMN5jORVmeyvrvQCF3Xnykr6/TgbvCur kVnjyhqGqMiVFWrbboBEmnwVrqypH6GQMXMAk8He27UkQyntSq/YXkfbYj9C Pxg1foS+je0J2GvEMT/CtQLcxafwAq6swzUoiTEkLJPfzJVeL+zYZGNI/Bct Qh+MCT/dTOxF2P6/OjNxg2MCChpc+BVpMmrPle57bcoErSYthEYbrk1BgH04 hbTQD4VWYM4jCtu8UF+TnTgEZQoe00MRGUx7HZJ4bdpzpdd7oCgLyvTDoLdc jYC0tOaBuYfytLSpnBgZXJaW9s0HYibnBy5UtC6TxLqcYQJypde7iuJxNKvo 0Jasn340NPIlklK0RWEg0Mj2ldBjHovC1P/HWNcrpXrdW8v1RvuHXzlxW3Zo OOTAFsJ/NejiiSFcaZiVIWNIcaXXCzq9ZLrwX/NQGP4LY1IV/gttbD9wcPhK w38FZ0nqMJ7AL2O9dqUXazPhpNs/M7KWWRN6GYaoKOQSattuQAO24QalyGay 6w3KFtW3Al9/yNcyCf3Ve+TgXoJCXm6pDx3rTR+UXiD6sBL8buwmgvejWTUi GQitwJ8fpLrQX9/Kdhdtd19H6K9gKvI/chEPHmJ9doXS612AtdDy0F8YjKrQ X2hjewKNhwtCf/c11p2PBl3YewnPdSCTy+KMoc6VXqDCE1x/eWPpEmI3jedk MpBaySzdb6NB9yJs30U06PPj79UkPtbwjGQwHCVcRBm3GFd6kfCU1i1g3G89 tiJt4mMjtQadMEoN28B7DjJs58B7Pr4Kz+Sk0mRue68k7bGwdkIwGca0x4TI bDC1/JHHLQyD/gFG5EyG9oG5h3IfhFSOMxkedUFwVx0554M3bD2MdhwSmfhp yBmv+lFkGGRc6RVvIxVzdhzzUGbH8WMCdpyxaDcJbWw/W2ncxrdtxyEscWhl UReqNfygdF8W+2nQB/4KFntXH1hhGTo1EYSXU8li73vPs8Lq1yljhTUVDSts K/uuQxJYYU1pGSsstPc9ugfHCmtKtrDCOtG22asU3ICF0LOj4HaK/DArbLDB 60H/Ajb4MkJYzDKEsBkbPCmZPSxSMchIxUAzNgBXunNOZYKGitkD9T2nshxO nD1eTt3sCb0f4FSWQyGnsq64nj2mtJBT2bX3PboH4FTWJZs4la3oo7PHYyH0 /LXOnnhqZN6CJjVE1qdGKN119ugjP1IVjORQ382ebmrRibPHy6mbPaH37Owx r1M0e2zF1eyxpUWzx7f3PboHO3tsyYbZA6KPzh6PhdDz1zp7ov25QYnXQYYS 0JXuu/ZIzHHF7IH6fu3RmvfEtQfkVK49vvcDa8/QF649umJm7dGlhWuPa+97 dA+w9uiSTWuPFX187QEshJ6/1tkTUg8REXz+yZAJ5IPS6z12I+f5WuizA6OB qfHZsYb8ghM3NLJ9uRN3lcvOlwHdD+Oy8/jw/PLd0/gMuKPRVwyhJNYko7Vd 6fXijvQMPK7bqR3LLg9hTNytzVDoMQaNbI8l9h5J8Sr+rjnHBSLnfIW9gSyx N+hjRBn2ZPSa8NiTskdrlzEovVrsdXrz6HJ5O7kl2PNjAthr4CZmaMRxCPq2 tuPgOvaKp0Qegr6/t4/EyMcQVl9jU8rewFxo8ghMBeXmKmMa93PgsTIZSK25 MIRhcveFQ3fYoTG9IYRGtjdwq0ioVQth6ahMhYSe5YWgsx/L0ZluDGni1pPm pMxQzrjSndO6ShX4aUsM4q5+yEl56rHKy6lN6wq9H8pJWXisMhXtsQpz0sqY k7L0WAXtfY/uweek3HascqKPG8QBC6HnsjRp5jaJMGYTpOn/nilB2siH5amq HVfh/SWTh8TJQ5LdrcjubsXek0f2Ex4qJg/U9zmR5ak5kb2cSoue7/1ATmRZ mhNZupzIqhMjdxeg0Lxs8kB736N7gJzIcmNOZFmaE1lQlPRM7vDrGV2JPg6u FiJ8YZaJTq7mUHt8DmEV83Q2It4psYxDgCu9wL2R86zH3bC7Z72RWcNGEIao iI0AattuYEPErt6z/uXp/vN9+/7fnsa/P92/AD0RTrJrIRL3QRkXeyi9QBhi MmCzJDf74dCKZCC0ZoMOg+Rd7PXhCXztW/9Aju7XQYbtHBzuh1fdoA9TCfXB 1789iwfLesOuz8YrD5ZDkG0/fr5/74Eas7KyhJKtzVKytZfpe9pzZI+S/X6+ p1YkA6F1QLWD5PF5IlBb4HjrwfWUj3cEF+vRi4Ao2QTRx6eHf/zzQ/sIKBUy WjxwYvHIoNSVXq3trWeorbW9+TEJoKQei51/oEfDN0GGfQEHylYeA6VEC6r5 2O85IJlZ6M2ZZQHJQ6msU5d9nFDrhqOa4QjLOP650gtUm4Spwfyectove6YR yUBoZfZMM0iY1GbPBD86CXZhwgtC6OKZR0+pMwBxz0A6TAKDB2XhKnaSY4Z+ zZVer2qkiFTl0GxOyKHZQA5NAvcQ4zXn0IwH60ap6OrcyGSjmD3RtHufaIyt lNS4Orv6wbKrNlh2Sb2rs+/9kGVXlVp2lTNOqWakrA+WXVVs2VXesqu8ZVd5 y67aaNlVpZZdOHS5nolLcPyacYrhQ/lpCBfO2MvFmYy9GUNVhbE3hKTq6RQJ SHDCXzxl+Yuny7zDa8Q42qC/dj/eTCeTgdS6LYQVMGwKSZ2Aa7iFPS4hr/s6 IOmDWjIxVmcOUaX9XiGqGq7BnkVCRiXjDJfhCXOllwhXjlrruaf2Q6sRiRFI rbGswig16vQQVS/Ddg4hqq9TcR42aJ05OpWMm6JT030Kx9FFLIkIlNmIQHnd EYEdqXBNhNHArIZODBrZvgCCryJQ74qU45SQlM1VpnNWpPztOiuGIOlG0YhC QRODVYZfzJVecZB0PpXhOkhaAcE6YkDUbh6cyYvVBElHOW7DyU7gVez3RN8Z IqMbhYPJFPNAq4gEzjgTuNLr1YMI9S4y2jwURkbDmNQw3Pk2tp+tkdFvm+Gu kSoSy/IkvmbMRAi40gvcMEJWALSffTRkBUBV5tE4REX38FDbdgPHmOHq7+HT 44qUMU8KTczzQ9Y8P1ymeR4TYY4rTOzIcGdEMhBaSfdk94ZVDHe+le0OcDh9 LQx3jWTREykkkVWIs8yR2ZVe7QLcTf1QbpiHwagyzEMb2xMY5uU1G+ajIVEk 9z+B205NCmVg5kovUNXxweSH0yNC+W66zslkILVmsYVh2mBI9CJs38lF0Rvh ttvRcChIzA6FZeLTnM0OJS4zO1QnlN0Iyv1CVaxIjEBqXYIoO0qbDIcgw3YO 8OxUmeXwIsntNpoP7z+OL7BqNzzEVuFwzanQkDu3uNKrXbXNs/M04j1RXVe2 eLsxaUCPybLVe4Dziu4xnpsLFm/vz4TPsYSzzBLerD3c2FFjYROjmlHAnIl5 zDC5uNIrNhYWMSr6YTAehdwaC90Dcw/FxsKZHGcs5F9PEpZoLGxIcO5AMsQ2 txPLINCVXq3W06uazcHiHsqMhX5MRIWx0Lex/fg0BF0pwezitpm8YaPh4z9f vg+aMImA4z6/raEvz1zeudJL04RNoxxPnYHjMAmxTR0OXdcWXJ74wdAbOi4h KZV5cNAeG707g03r8axUURC465SkpdIwQAtfHWzSRMICzff19y1XkWSgaxXJ +iU4+cHA+xk4k5vlJNGtXN/pQemVg5OOJfnSYCjMDTEHaHYc8qV15Uv1TI5D ptY6xxIw48xh5WrhGSJ5qEpC7zPwhNIf4RmHQi9hYgJubvPA3EP5tXMqx8Gz LdlKSsKuHpg4kjZhmpiAMkdqV/ojMONQGH/lAfSmeXAE30ON3oxyHDC74Rgw 9at23k/sSjEZLgiJJHGjKTPeEa70R0zGoTA5S1uf+7T1uU/bqtynQY7DpJh+ VJYOmAm3U5JdQ63t5VD6IzDjUBgqpg5WcfPgqKC6KuexIMcBU+IfN5kpPONt I1bJWs6yazn7cS33azBza7AEeNoHRxJTDs+ZHICnKtGbBofXDkwe721EvLeZ MrkEXOmPwIxDYW5eYJNpH9ztT8UmM5UDC3qJ1+1XsKBzJWKgF0sCvTKMeK50 X6JxzhBBx4CZEI27+uFexzD63JHJxCASOoW4/ZxpPXCMgwj3oHHgcTlOdMxF TlpwGVlxCNK8MC3uHaldRKKprBs3nbgxjyw2tPUNAs3/I9gB0NYxnbUZAjlA 3K5QEyug2VeYg0yrcLzysljREcjjxHENl3HTSGmMAZ8yZnNXerXXNz0ljafH MPq06NIaxgQ3NZEv0Mj26O5vWA0pNyJvN85lBr3o561E4uWYCzOwpXtnwOIE oWLoQX2fhWQ4NQuJl1OdAcv1fiALyVCahWSALCRN04gJ+SwkQ3EWksFnIRl8 FpLBZyEZNmYhGYqykHgshJ7TVIYFeRS+zOz5ofMo6NkTExMjljhvZkyjrnTv 2YN4RRYSqO9JFdipGbC8nOrZ43o/QKrACjNgmYqr2WNLC0kVGGTAcj26ByBV YNsyYDnRx2cPYCH0XJmF5GpmT+RQQKnr85pDAUp3piRpGamZPa5+mD0nZ18E ObWUJND7odlTmH3RVMzNntLsi9De9+ge/OzZln3RiS6aPcDbzvDS6etrmj0x fxwWCYVZhlPPle6+c6thm4b6PnepOpVt2sup37m9wjatX6cwd6mSmdljSstm D7T3PboHyF2qtrFNO9FHZ4/HQuj52M7NTBrwWmtzAf/XMp0EjtOJJ3aeDD+W K73AQAcX8MrUfnEOPuDVyKwk88HFAa++tu0GmH3pVxXwyiPrCaMkCXjNXBu6 0gtEX4Ox+Qmbbj96HuzYpo3MynDX5qRwV3d5qLsDFLZfTbgrx9E7Uiap0DO8 O1B6xTbIkULgTLzIOU7Ra8ekJurVt7EdAk/06+w7WvaBq+q3HgarsRzPgio5 C+ZoUG3pBSpANk2OyJzutwA7mQykVobBmmGatoXBgjsF9TEOhZFdlxAGK7rd wmCpSPJBiASeuRsaW3qB8OwlmArYfjT7RiRGILUSnVZfNhvCYEGG7dzBcyrk z7vIKNhm2BQFGwMSKYprOZdJGE4m0sGVXpozxQ8dkOiHwcTNeA8f7j18eIWH TyrndPayNxqQmBynSSQcpYrGaAa19ueB0gveTtLX3CZe305q3UgO8qY8Phhf bf/99eR3+b9ochtgqujatFPr7F/6oVvsAvc9BxOkVsgxLzRXWwMyRB2LU4ha cSqPJaBJziAkOYP02TNIv7evjeqUqriMhvr+QmA8laPcy6kzaYbeD1wIjKUc 5aPjKG+papomZJ8ciznKR89RPnqO8tFzlI8bOcrHMo5ywELo2V2nFeTPW88g SfQJy1GU6y3CpVCUZ6bToSwns+kUIsoI8xzlqhEksw1wpXvfEAyyzrfD1Ifp hCU7/YZgkKf4drje89NJv07ZdDIV19PJlJZNJ2jve3QPbjqZki3TyYk+fr8G WAg9H0vm+rVMJxnj4AKHuokbzKxOrnTv1amXFdfVUN+vTpKcvjpZOdWrk+v9 wOokSeHqpCtmViddWrg6ufa+R/cAq5Mu2bQ6WdHHVyfAQuj5x+kE0ynmhJNJ vHOOYtuV7jqdlJIaxuXTCer76aRO9Z3ycuqmU+j9wHRSpb5TashNJ1XsO6W8 75TyvlPK+06pjb5Tqsh3ymMh9EzujuWjud7pFBmASExYi4P9XOodzdqXCkov +Ly9lQFIMWAA0g+FDEAwJk0NAxC0sf0482NJMrGrpAsnPDgj4XB/LXujH1fw c6UXaB+33hPdxMne3hNWZoVxPA5Ryb21r227iVkUZTEQ0d3ECDsDABkui2M4 dIGd3tAQ2sQbmiQRslwjEEovEIFidLwldDcEGoleZmW+biar83lCK9tdzL9V 5EHx5jN5NjimhKMqybAoMynhXOnVLsH691fFhOF+MKpcJ6CN7QkYcF+/+nvj hOH3H1q/1qIkmbYiycEpm8lT7e2p2FK9W25luR3C1fdR0ghNk7ijU2tOCl2n mrbABAEi3IONSLVHJ4SJzEakPncQjmrqc3f27szCYvrshYYA9yDoIBaVdTfP D09jP95/HqEh8saGru/6AMpQy/Q16L4eHt49je1gGtHBKO7QRJcMbW/H3/8U IMI1Md3im+Fhun8/gojwg62l+fOeFREbaSGSuxll/vycCgltJeaj+T48zitb 2VwtNTfzvm0jdw8Vlbd/XZ6LwHWyd51V60ll3mC+e2j6tllcPA1kSeA70OPJ PFETc+OqZO+gsnsHdZl7B0Y7h3S1X74RJ5OB1Lr9gx2mDc5HXoTtGzYTr6t4 T6t6kck8mVDj8pb0RGck1NAIV5VsNDLOwq70AuGKZec2Cs1+2XGMSOeMJJra 3e5WTn4vw3YOOxJ0DK/N5TojaWSt8HqKMxJXKqKV8ISqLeuMdIm8lmdwRvJU qUKBM5J5YO6hiqYtyHl7zkgU4WGJwJOckbgSCSmbSEjZMuu7K935IrwlQ1WY tq3vrxqm00PlnJzai3Do/cBVw1QYKmcq2qsGzEkrw1XDVBoqB+19j+4Brhqm baFyTnSJX4nfgUyyxK8kbokJY+5igbEzJbof+bDLPZ2ePJEyTshk8mQIkFzp BZs1vrAnH3x/Axhe4MkXbRJn8dsTmO3it6chEs9PQiUQyVgkXOnejkaK1IUi m/pBv57qGeHlVDsaud4P6ddSz4iJZPVrsWfE5D0jJu8ZMXnPiGmjZ8RU5hkB WAg9kzvxNerXaDYOuVvM0GQ8pV3p3n4QSlRsTqB+cHqdTveDsHKq/SBc74ec XqdSp9cpN3l0aanT6+SdXifv9Dp5p9dpo9PrVDp5EEp6/ko3J/FwKXHiMZ4h wXCle688Td3O3tYPk6c/feVpTtnZQ++HJk9fOnn67OTpiydP7ydP7ydP7ydP v3Hy9KUe40DA5Hr+eiZPcBnScydGWwQCGUNRnKFfcqUXvLHfeF9JrHkbHspc hvyY1LgM+Ta2n4prywvyGWJkbRc8yWeIK8Yi9WSTRClmQr5d6QWasR3jCtnf Z8jKrAmoDUNU4qnha9tu4HKlL/AZOq+3ULuGXoW30Ax6QfURgRPW0wzZBRpb 6m5kUYOoatGdGOzPxZTWQIfg+PlpnH7a8GZsVNPfUUY5xWS6Y1g/NPoL6mXe cP2SO6qooBIWfdPK2AjkqxdAXCUs/oQmJvUM7aQrvcCZM7XYWqan3WaOkchA Zt3MsUNU5+vkW9nugC1GXbav07iePif6OpmrrphLL8kjkfG2g9Ir3ju01tfJ f9HCvYMdkxqXJ9/Gdggq+/Wc34u9w5kcn1jmIrHC8SnR2g1l0ckYRydjvA7A gtKrBV03WR13N7QlcPOjgbkhSBcdK3Jvh0a2L4c3k0unhCEdXxg1eieLrdrB KUijLZgWkAgu7bLPRVS40gtcZKlg+rSvv26n9tugWpkMpNa4tcMwYXa6V5CX YTsHVPIiL4tLcwiiu7ETaaiG7Sxm4SSFREYxQuklQrUXnV7cEN6RvNKItA5B RmrNlhBGaYtDkJdhO4cNIn6dPSs55md43s7tEUS20RMlCzlv4pUHSjKK5s4v rvQC8SoGe37p9mO7NBIZyKwBKwwRvwONUXR8gUa2N0h/gptXOVcXSUWRSb0z IXopi7xiKyge8vyNzmm8SSgyZEKRkUk75kqv2DmtbUpS1cMw6NFtIOGyfWDu odw5LZXjTPBH04FnnNP6Xf0mfjCmrGiF5yxGc5DECprhXYXSqz3U9MS67cJD oRUexoTVWOGhje0HrPAFB5sLMsJvDNxN946cRt9IjuNarDJ7R1d6gWsxVsL+ nMOOzuRGJAOhdauxHaQ67mnfynYHy3EJ93TA5NtkoE73hCTatGlkWJWZPItQ eoE4dLdBFLe73wYZmVX0qn6IitAHtW03Dn2DvHr+/ZlBmzVJCkaZwG/twgil 17sMUyyKg3f9YFRZsqGN7cnBTcmvk/ecUxbVXjTdTHLMXKS40gtUe6QTIzVr 17TfZZ6TyUBqneqzw9Rv4T13ImzfsEHsjwBUXm7o4Y6WRhp9NjBGCc3Q2mcD Si8Qrk3jcmbuGChrRWIvtcYmDqO0xdLoZdjOgQe95Gbw6uyKNOYwITyEGko8 ZjyKXOmu6By6caqhlIP64A1K0KnJbL2cOm/Q0HveG1S/Tpk3qKlovEGVSTdP vTeoKS3zBoX2vkf34LxBTckWb1An2jZ7lfAUsBB6rkvHKemwrz/HD537TM+b 6M3BkrPXmD17jXufvVSvMKsJQXD1/byZTvWi9nIqQxB87wfmzVToRW0qZubN VOpFDe19j+4B5s20zYvaiT4+bwALoWc9b1TlxKFve+KgSAlMWGK8zRjPXOn1 nhqJ6Ms9UvxoaLyUe6T4RrYvt89BZQ4pAW4XY6ZYw63AAYqieFfAEiPFmDVS jHsbKYZeGIqL8v2Nqx/09Kn5Ebycyv2N7/2Qni7Mj2Aq5vR0aX4EaO97dA9e T2/Lj+BEF+lpLJOe6xImm3mD37iaDsY9HP2lEeeZSBdXuu+8afQRvGJ/A/Xd vOmmSZw6b0BO5bzxvWfnjXmdonljK67mjS0tmje+ve/RPdh5Y0s2zBsQfXze ABZCz+SurZw3u56nf5h5E50jSML8QFFiE8+46bjSr945AoZBL/gEnCPsA3MP 5c4RqZzlifSAc0QwOa7Mj9fhKEESkj6SXFSLzObHlV7xXltycJTQD+Xhiv6i piZcETYOkoOz7duKVtyN4ZyTGDJGGUn23hkaM1d6gZZvuJ9G+/kshvtpVOez GIao8H56hJwPyGfm7urup3clMfvB88NzQhP0JUvxmF2Kx8v0mMV0GO2l7373 LlYkA6GV+Dsh5g9a2e7AS4dWeem8eZZzjmWyKVTJpjDjMetKr3cZpphVOUqg ygTxvo3tCfDGTowgeJuOEskCjCJdBYkqsBEkY2t1pbtnM2wrsxm2STbDUw/x Xk59NsP2tWyGZYd4W9Ed4kmDaR+yGRYe4n1736N78NkMNx3iQfTxQzxgIfRM jNG4iOrF6ApD9aL/eyaql8xJvl0SnI/dUYJzjqJ3G45OvnpGZbyMXOklbh8m MdpwKrSfl5GTyUBqZYRYmiDlJDcjkGE7h23t0fPV2gXuylyMEjJ+wknixJE5 aLnSC8SqRlVr/Qn2C7u1IjECqTVQhVHaFMwIMmznANWxMJjxeuMYEYpQRcF5 k2XVKjuXWr0Malz//fUyzAZHjdtcMDXutpT20YSOUPSsoYnVaMpajabrJr8v NqGDrYcob0JX3oReQX6fylleen498YVMJVmrSTyvG+7QNQJt6QXrqK3ndUqc 2dw8FJrNYUyq4guhje2n3E/lGs3mTCW3NpQlCjBz9e5KL3A3B2Zzsl9axmA2 J1VpGeMQlYZ1QZI8AukYcXeM5G9xuLiG3KBM8RjchUnCN5HRga70AkFIWEvM /rtF+8XYGJEMhFYyTphBqrSeQyvbXUzo9Yr1XJpUrrkESW/fjs4UDr58JMa7 NoJmrrNd6fWuy1ihcjs6DEaVHR3a2J7Ajn6UdvdKLOjBCMhEzBtKAle68anN nFZd6QVqQcy60SbEaob9jIBWJgOplcyh1gjYbDACggzbOWjF4dhu8UKNgP1e RkCN1XjLiFni7JNlpRCXyUrRU4bN76r2owOwIp0RUNURAsAoNWyDERBk2M4h zrA7BtXLpDIbN5kAg32HCZToVJTo1CyH+RdIxXlJ9p3i5IYQbCeQT26IfHJD VJXcMMgptO/k1ebCUfJc6Q53s/g0SsSLcppclGeO3K70ineWYqzZWZLqhA7Q xvYER2z8lbpIsiamgSNMJdchGSc1V3qBi7az9WC+3x2zt/UYmTUrdhiiosM1 1LbdgKvuVJDQ4QIMPX1mMT7R0NNEPweiZFyOcyltXOkFIrDnlkuF8/12jRyY VDivTSni8mpXJkbwOW44OI2TrjAxwpskMZuZdRoSTY0opdPLRinsngrzohZf 0uPyxRcGozIjAuSP1D3B4nuC/8zbtOsk6y6P4Y02ZMuvuyhD3+BKd8WcSX9R ExYM9b1nJDmVvsHLqfOMDL0f8IwkhfQNpqL1jGwa1gLTnist9IwkQN/genQP 4BlJttE3ONG22auekYCF0DOx06fENfKLJHgoDW/M5b9bJ3hoj9pDmUryjyU5 bDJZ4aH0AjcLShIbzd6L3XYLViQDoZXMp8x5A51uDQUZtnPwM2vvCC7geLgy CyhTJMasoyRmPZfTwZZeIDpJS4h1b93xztKIdDkdUN2lJYzStpwOTobtHHYc JgLoTbpBbrOBJvsPRiNUZaBdI4PMOLm50uvc80qDi0GaPS8t2vPCYFBpSHCk aIs2vdDIdgV3ma/a4IleqlcAtAQFoiMXlqipghYn2uAZCYmaSJPkcGAZs5Mr vWIbfGkOBwbGor6BHA7mgbmHmhwOUY7bQTbHbPDEU6ReJ00BYykHZZOEL2R2 la70OpWhxdI0OH9L81DobwljUuVvCW1sP1+jv+Vs3xg9zomIXEcjyoV62dJL 3DcyZU41SLEdfd2UO9UYoVXbRjdIlb5u0Mp2F706Ljk77F6ZHBhVKG4Hm2Q7 mMlo40ovEIHuGggN+xnh/TWQkVmDvzBERbiD2rYbOKBMX1UmB0bjaUSjIy7A Q5YEejgPRfkPtQCPpNwCD4MhjAVeFFrgoY3tCdQcrVl6L8n2ToqVXbQhouhZ jgJFmuSMZVISu9IL1HWTVv/8bpRYyv1ysVuZDKTWEOLDMIkNOWJBhO0bUPn6 Gfmy0zfsZ1REPHpoiCS2esgclV3pBcKVUyrsXn8/GiErEiOQWhdbbUdpk1sl yLCdO7iO7RG4Nvm4iCuwKwa7DtXrXwSrSnwrs84ccn9njkuy6xT7VoLrhaDe t5J630pa5VsZ5Jyem/ONelLGowxVMl4RYpncrGcuYVzp3pxDHZVVnEOmvr9Z p+PpnENWTjXnkOv9wM06HQtv1nVFe7OuGiqFJ9w2pYU3666979E9wM06Hbfd rFvRRTfrPUp61vNHVDAHC0nfInNwMIJSJULQOW6iEWqYMmcwV3q9ZzAklDOC modCIyiMiagxgkIb2w9sepujgUSrDS95y2bQfz7/7X1AYPSJkqknaMYnypXu m9IGjXjglTtdaBQ2D8LMPdw2d7Jw8+AFaA3SMKRVt1PfRhKjxgCV2UI8j++e 9E/RPo9xJPQUZ9YjCN9Fjp+kpoV+XPpNrDbc6EhG3M6UYUf9uCeKqFzDKHmr GZY4HTlPKFz0i9FJygglW9CzSiSp5MyUMWe60n2R1CHVViPJNdqAJBCQR9KB W8YZlGAojGVIBiiBHfIwlNQwWvz4/8Y7Gg0o/XS36031FkB1E+75MM2Uky4Z aaVyUolvD8s4TLjSH5VTGAm9qR0mhyhSp5xaKQKW1CUpJ/1iw0w52YJa5aRS g07mjOxKr3ejhUdLiu+/aKnN29p/wHpz+G5vYfSGmK+Rh+tmdvhq7xWlRvju q2TZXotPGRY80Sz3WuKQG+0hEFKcUFlk1Jkr3ROE+mdoSY+LQejrRxsNV8Md 5e0dOow+UGKhbUaJmcuz9QHZwej+u6AY4xgQvV3nq1u9pKoWQVF3k29tX8UR 6cWFddG66Y5jsJWyNycMvXpNzdTs6n9DGV9jMXnFpVLU+mC2wE7NOEekecVD bLcH92wiWWCzCZ/Y3mrRgANTWbnAukYbFlgQkMOmvBOcHt2zwVCYFVbFPVt2 hSW4bM9moCV3zR62bdOmpnGaG6NNScHdCU2YzAhJCHtYlrCHnSey69jdibGn Gc0x7nZ1YiR6mTUXJzBElW410Mp2B0aO9quikPoewMiiy3UMdEVjJg87lO6r 4Fgz6R+ieN8H9aNuY0rDb0JBVx23SXsR7kHG+xE9n8eDKy+smTAEiTUaKdFL FmhrQ2W7aoob88hiQ1vf4M0st/7MYeuYztoDlyDK3K03u6JMrEBm32Lh3SAG vMSYXN1/yKng/oOo6Fqd2j4yxHmu9AJ1HkT0D83+Ef1aZuVlMSp35YLathtw 9JdX78r1+PQwRfih6NnPReJLnTHiutILhJ/ZeNm7/f1YoKxIBkIrmeDNIOHo rFCEQ8jyrXuDNZfX4DBoXd/pGVDZ08yyi4udElIHQyp5wq9DEn6djEHYlV6x zUXaEH8jbpiEKLK5wJhUEjgSsCZLcJGh6muJ9L//0HqFmFA76bOadzeU3bRW iFC677ZPiRF3LMLIAWlAwtAuHHOVgb0YyLAX/GIkhN112Pkm4JEtsWh+1Cbu AdP+zRaSmxdoEBZSrraAQt20/d8+3T+NPx27UZFWV9YKuLHU3HF4bCuoqJuJ 5sbci3/47il2p+uR+La+qXNFcHUt9sabaXp+B9mLTYet3fBCU7NddcW9+QJs Ui0YW3wr17vxK8jlLHYCg+tB4ncgxc3nj+/A8wB6cv2mbwpVjJ9Cr7/iw18/ PbrX7GFPbob/LhkZM8hobPz3NA1044HcfGw/jPfztmbu3zUdsY1UNGnaqsaM pbwl7KV9idjUU4NTG/XopAmW6AFd07TkN/M2tuaKrQBq4269FdedNJQ5b7ze f5+9/CqM0X6pAfSrzAmOOB/HRTYJy3kxm/99fyibxGz+NzG0QiWhFZngHlf6 4/w3879HfT+f/2F46uc/NH11/tsO1/PfFp80/0Fg3fxP3zQ7/43U5fz3I3Ns /qdtK+e/7yKZ/1baa/Pft7E13fwn+JX5T1QTLv6iRfKqdEH0TSQ8sUdmdIEr vcDDUa+3c53Z1nX7Rfo5mQykVtokrWXJ4mMgh7emC5MkBJ92EOmH+atuVyka 5/tTgeQ5NqisIasN6oCXfn8DOWQwmoEynthZk5yNMid2V3qRoCTMkYfuSMFn ZXqpdaAk8cxeDkoCZ3bhwwBfDykI26VrwGC0jTcocT7NedcMXyDn1k6KURjF iCTZUzEKpxiN1KoYaDdMdRiERrY3sBvhq8ZgYjhvYtYtHAOt0DDmLqBt6fXa iBC3HMxDW2QdgtHArIYTBxrZvsA8dDS/xxdksttgKs8w2ZXsBWWgoUfhnkbK PhOnAqU/ngudXahf2YVgeE6xC9mmR+xCfd4u1J9sF+pPsQvFNz1gF+ozdiE3 MsftQv3pdiHXxcwu1B+zC7k2tibYhdRXYRcKUeh6+sejYCQdZgJnw9TwZUah j3zChvhaw3S3HY+TyUBqJfm6GaZpA5UliLB9Rx7sVxalryQKXcM1bNCR9NFh sp3Y+gINSi8QrkJSZjzl0H5nRCsSI5Baw5kAo7SF2tLLsJ3DkRHxMmrL645D bxCLHB9xcyUyfEZQ+uPmymyulFaBy80VDM8pmyvb9NXNle1wvbmyxSdtrkBg 7eYqvml2c2Wk9uAGFIakb9t+kEQe2lX5RqzXs5x3o1E5uD+6n3LCJWIjl8Md fKUj+ynXxtZ0+ylRsp0Cv0XQN0O3LzV4yX4Kmym/zNrerll9jocv84R5giam dZo1rdPr5nBUDXA46ofC8GUYkyoOR2hj+/kqORyT8AUeGfRIsGBq6RnrEZTu ij+pTyGsq9wgQaPTwxe8AOvg2xgOlTQ+kMD7HI5e8CMxDqxD5cHLHkfUxyxQ cd7YQE5nIQuqHcksNtAW9AWxgTMU+VPhqI+Ya7InKP0RRWEk9ER11B34Dheg SLUBPrABTvB03kD4BZ70C3WLQHhdUIcnjJh3PpsIyeRkhdKrXRUH0Qjn99ig QfRjyarox2SAM1qR46NvZHssiTVdq7PhTBGmDV7fpoxixSYjWN2CiGOqlkaw TLiLK933CCa1BphqA+Zdow3xfCAgr8pKOBhgKIxrgijnYAhbemVOQWflXFjo Lr3X69mCc0GXFHEuzFbDNFI+y8s+7LynN0EcU12Qsq1/YpCya5sBTnmQMozB iUHK0Nq+igtS5iVByqtVFLkC/QFubZAymvhZg5Q5XQQp6xdaBCmbVywJUk4R yZPgqjEbXDXuHVxlwCF4Jb8hNNqg1EBADptlQcowFCYchZUHKcdrH70hO3NQ 8kqrnR6UzGPKXSxY4meQY/sfzpRt4ijbvx4Pe3e/H/2wFclAaJ2ny3gK2/8A CSh0d18X2z/lTZL8SSQu6RlPF1e6N0UmUnUUmaY+UGSigZxOkWnlVFNkut7z FJn6dcooMk1FoMgcKeuBItOUllFkQnvfo3twFJmmZAtFphMdTOYHKTIBC6Fn csfwq8knZdOs/bkJF4gj+1+8s8m5iDKTdhnKzE6tfHj6kokUjM6Y88hZwjPc 3K70go/XtHtln/r68VprRB+Vvz5RPz7onzB8f5OGj7rtZZJi2tQxu9JOJUmn mt4BhvaLkMB9g6QJUivUmPeZg2ZAQ7u8qMiA5pDjxww0ycE4zfaTA40t3Vf7 KmyWyHLt6+p77ds2p2pfkFOpfX3vB7Rv2xRqX10xo311aaH2de19j+4BtK8u 2aR9rejj2hewEHqeBdMcJii+TsXLI8kFS277SPa2j+y9hzZ7Ala5g2GR5FvI DTsYdtIOhr1C8i1kIcm3rrieQ6a0kOTbtfc9ugcg+dYlm0i+rejjcwiwEHom dxS9voMRjhyX+IcrnU4yHkmT8IsxG34x7h1+oQHaElY1nUx9vyQ17PTpZOVU TyfX+4ElqWGFS5KumFmSdGnhkuTa+x7dAyxJumTTkmRFFyxJDguhZ70k9a9O J+KpXddED29+PnmeL57wfIU7XBNZk+EacaX72giJuUcqn0xQP8fz5cx9x+eR F+EeDIthDc+XG4J0BompiOfLNbT1Hc8Xe43n6/UEPGJid8NwGbxf66xmBy/c Uh1OkvwNSfjSlA1fms4TvlSYwlHs504eUjiKOmfyMESlcXNgGRHgN65Vjj7B Hr3zDbxfEwsr4A8aP4fLUnofJDdMWZaYiCdbHKhu+h6vd+VQesHmkG3eBt0k UHEaRz8YNfRKvo3tCXy/+4L4uTdOrJRepFAW4dY0icbLsLu60gvUeLKT9iJF w2U3elcjsgehlTrPDBIfNyTGAxm2c4AlEYXcClcYknD/cXwB7Ugi+QemEa6C ZiK+XOnVasce0d7x/rsvWqIk/Zg0sGGTZVHGrpHtMbooF1zyead4fA4lyTJK shlXSvLQrjDGwRARMRf9FfQczWHOll5xPsa899UyHyMMg5nS3OVjtA+OgoGX 52NM5bizcXtCPsZd3WZ+uHyMMS6DxLtmpHjcE6JMJJYrvVqt1028s3EZ9qEs LsOPSU1aOd/G9gOuDeT1tHJpTMYVJZdLNouEJixHSSoAkk0FQC5zs9hgaW3X +/HLGIkMZFYyHJ2UCoBAKgDh6WXUNfvczE7HOBJ+kOCLb4Yk6xBNrjrBJhbd KRzEzQkcxOBNLUATMnL9h+SX98+BZwI1kWeC0iQuMmMWdKUXqPf03hWx3gYa 7mcZBKEMxNZpPztQuA2HBFCDyj/gAl1IISOZ6qP/YckavToi6y1m6P8cq/Sg VjG83XqveCgt2d8SrMYYXsKiX6LKnFZc6QVitR+5Sx08qf1Y4KxML7UGqTBM WGwgRQEZtnOH1BYfIUURl0uKwpo1Wk8kRUHRCwXzeG0ucC6jjy29QLx2qLUG SLzfptKKxAikVlkg3Sg1/RYLpJNhO/enn9cTD6wvoy/KBEnlGrEVJsjkjhDR GL5Ckpg8mnE9dKVXvAVtZQXFIYwGbmooDqGR7Qts4bKMTZOxTjefyDmZDts1 6jIXg4f2oMEGSVRCek1RArrMqt58Cbv327NBNt5qjVuwQdoHB9sKG2Qqx9kg +RuyQVJkSMG32yCJiuRlhOBkX5lxb3Ol16v20ATcMOahkBsGxqSKGwba2H5A 970tbhhG1vqvwvYYV1094cKqq/cmCdNrjozsXCbwIs+cbux298yxMmuI88IQ lZgcfW3bDXjmNG8gI19u8S3PyJccUojicc9HE7MjzZod6WUeUjAR1lVd7Xem tiIZCK00/phBwrLS9E3BEqngEE2aV03fWgW187OIaevy4DZ3zTmM4WPGznOa MZxImVxMN0kQVM53x5Ze8ZIsx2pjOIxJlTEc2tgOwRjevHou1m/UeYvj+Yzh TGUMNuXG8GBeJILFwHscSEG7Sa63gVB6gZqwp6xrzdUupfuZF61MBlJr1mIY Jm//PsW86GXYzkEzijuCCwzhB8w1V8O6rBEbLq1xyF9vWH/XWhJKLxCxhIzE 7L+m/ZI5W5GWdXmcqtI5+1Hayrps9ajpHI42dKi5VbwEo+JGv8bkeCNwEs+c nK5lZil3pVe8lPdNhVERRgOTGqMiNLJ9OfQ1r1N+R26wO3WOo8y2jCkJ0JJM uhjLZP3OZExxpbsCbegF5hVRilDfRSnqxe3UwHkvpy5KMfSejVI0r1MUpWgr 2ihF3rdKQJSiLS2KUvTtfY/uwUYp2pINUYog2jZ7LUrRYyH0DFGKbsYcDpwP Zvj+i5jhy4ISMcsEJWbM8IcIsqMZvhFJ7slghmeG6TSTcATtTV12WWb4RqgC MzwMgz53kwbM8OaBuYdyM3wqxwFQFpjh9ckus7m1FvnuTBb5vbyCSZN6ekQO FM6yxDnsmi8i9YDx4kgxPxg17sC+je3pa6RpT7cQNG4hJElugjJK0JVe4IEK gmRNyo29g2S1zErvIlRsive1bTdgf0JvwBSfC5A9zRTfkKj1EI9LcM5fiF2q v5DWfYNZyvh+AYtWJAOhlRm/rCm+zgudeQch3V00OF2vF7rJNAP6jyc5TolM onEyBiVXeoEIpCMZzWrG9ryL1CIZCK2xJ8EgYYhK7BswI5lsP0cNSdDY9hpD uI+yBlhVeI51uGkyOFwRpPSHcu3OLoB4E6MhgjHe7JSzuhBddzQEJeU7QBgM ac4HDJVFwUIb2xNovNfz3Ufq5csJgGiWaTYPp4WKdz6MJFS3qetP1jipLlPh dUI2bt/E9vPRtTIZSK3c9FmVR7e5lIMRc2QOkPx1QErU5mMfzn3Z0+122cNI dBOSydqM15E6UHqBUOWys+ZFsd9ljxXpUmyKusseGKVNlz0gw3YOazR7PSXs 4Tidc1/5DPtk1ySUR+eNGKeDOM/FPdjSKzYlFrIKuGHQMNJ7PWNKdA/MPVSw CiRynCmxf0MevbvZD2nKsZfkUJiyORSma2aa6pHwHr2i2KMXxqTKoxfa2H6+ cjMiZQnvu0zglzNf29LdKbybGr5UV9/zpcqT6YdBTj2Fd/MKX6ospB82Fe1N JJtaOiDPlypL6Yehve/RPQBfqtxGP+xEH72J9FgIPZO7ib16E0mk4MleYrTP 7lZSK443eyuZpFQielpGQ4A/ofVcZVQ5lO6cUkkQwWvzxLlGW1IqOQHmgVrG 1HnKS5HZUqQZlfxIjL3oIOVlU5DyspXSIqgVPjCX+exdeDpvClU6zhIstVIM s5SXtqA/nvJyjieSbE5pdnNKd96c9qofGyqLdTPUByjpvd00iTs6tUYZdZ1q 2uNq2YtwDwYMXLp070Rm6XefO8e9a+rz0d0M2ulr+uwFMRsDQEIHxLusu3l+ eBr78f7zCA0VuILopl0fLZK+lulr0H09POgfvB1+2rdYr7ZKxibGI3kgdvz9 TwEiXBPTLb4ZHqb796MT4X8wSu/W4vyaYmXEVlqK5G77Y/78PJMSGrctsjlf kyzrtrZuTZubee+2EWTIY8Fe69+Yx9nWoqi7seM21GXEfGXob9fptpps5pXm s2zSe7jZFgg3dJzTDZuSQzcJB+eZv8Jvuc1duphnUPqj3g4jMfaMT05v8wK9 7VnTraYmQWOfN0nxQmPrF6OLJMW6oFpjN8lVQIYw3ZXuiqRWDH3blB/moP4W je1FuAeKijW2rY+sJxKVNRrbNFRWTbumZRoboa4bkiYzje1+imMaG34wvflf iyvX2FFKaNyqrj2qsaGdbeQ0tvHUPqyx1eC0tOpgfwQRV62S0qpt1+n51bZi S7WtS6rVdmK7YzlGUFu6u9qm1WmZXaNtaptOh9R2SVpmGAqz9JMT0jIbbT2d NS3zQltrwPR8kZZZl5SkZZ5DKM16l4vds6VXa3yzjhiVSeX9mHC4lTjstDJ3 4uPgKzB2JUnlk30CqLLGH/UIP1N6ea3HMrdlzdJsIA4xhR0CIaLJpiEDQle6 c25woupyg9v6J+YGd20z2osW5waHMTgxNzi0tq/i1lFckBs8qL9Wyl7aXOBY w/CcucDpuMgFrl9okQvcvGJBLvC5Gkwd6jNGYFe690pK8VFDw3olNY02raRW QA6LZbnAYSg0lBg+KRc4ns6cC3y1lJ6cC5xQEgM8aVxKs4Rc6FyEXMfu/IVl JUZ02u3KXwArsZFZRx/nWLrqqBmQp+nS3YEzyuvUDIubrXPRMWzkJv4eIIji XZZI0pWN2XRl4/7pyhhqSPluDupn05VZjXT89O1FuAfjE1CVrmxcpitrcFm6 shHSlTXYpSujr6Urm9/aK5MpZto17Ofk9GRydWEvD3l8JlemJLJfYxRyQ/EJ ZcgXXOkFajobeaG6fj/nJoi8sDJrXJvCEBWRIEFt2w34f+Krj7yYuRuTJDue EgnfTC47ni292jNrj1R7Ct+MOIFvBpLiqRZc50Z6hDg4E/L4honYox8yxpF7 hopko5fLsGtLL1D9td0wuK3efjRcTiYDqZWbvdaGQp7uhgwibN+A0NdzlX0l zNYarsm5JM3kmFmtXekFwlX2o70e3jGbqBUJvsi1gUJ2lBq2zRcZmJJ8ltGR HYHrazlvr4XWmqCETE6lZHK5I8y4+wVirwY29OXueFDfu+Op4UR3PC+nzh0v 9H7AHU8Nhe54uqJzx0O8kyF9uS4tdMdz7X2P7gHc8XTJJnc8K9o2e90db4Tb QeiZJKaovDceRKEYZTufUM4nr6Hn9Mkb+bDBJ282n6L2VyhhdMq4ULnSfd1b p0H2Ne6trr6fT7061b0V5FS6t/reD8ynXhXOJ10xM590aeF8cu19j+4B5pMu 2TSfrOjj8wmwEHom5v/9OJ/0fEqCEJO8NhniKijd2V1csOBbV+Qubuv7+TR0 J7uLOzm17uLQ+4H5NHSF80lXzMwnXVo4n1x736N7gPmkSzbNJyu6aD71KOmZ 2Fu3H+cTkgmPBkl4NDKHaVd6vcYczFUF4yCMBu5rGAehke2rhMrfYA2OHe0P h8IfJq3JDIUJ7yVPTh05k864u0Vb7ztMDHXNLsnFbTuN0qLTd0k+TL5ul6SA KCOr1VtUqNV1xYxW16WFWt219z26B9DqumSTVreii04dYHRyPVsm269Wrceo YsSSTNEk4aZZ34VD6dceVeyHYeymxkcVNz6quCmPKp7JKcwT5E31r7AUvvm8 QUm6NKwStjiZZYuT52GL+8GYjWk5Rw0MRlOXMEgCO1xP4y6j2Anj/OHF+yUM QijelQcmEDNAGX4FV3qB1ndgKez38woKLIV9nVdQGKJClkIJ6SN78AYi7Ru4 K98vYZCehVHrsWRfm4sQsKUXiD4iMLZbrP2yZFiRDIRWXVS6Qar1SnOtbHeV LIVvMj1QZCnEKrIDI5XcPuZ8hVzpBSKQ0tHGl/JxPwVoRDIQWslS2G5hKYRb Rw5pg4ZLJikUKAPD00gKtfprIhBFAsT1QgylV7sB1L9+OU21H4wakkLfxvbk mbbqCGYuJj3VKVSFWCYuQsTfYpvkBZnzryu9QK3XIjRim2phRxchK5OB1Mr0 VGaYhm3ZqeBo7F2ESGEO50twCdovF5WGZ7wUDgFXxrM0k33FlV4gPDV6iHWD 3Q+dViRGILXSh9eM0iZ6QpBhOweXoNdz+nl7zaV5A+2WjwqLxBuIqsTVMufq a0uvdtHukc3nV3o7BKOBec3tEDSyfTkEtq/qx2DEPmTNpuyc10M5n/MTst7j NNkkCmyueinJJH12pVdszS5Kt+OHQS+1SoA12zww91BuzU7lOGt2cwJH5lvP sYMFjXpQqGhFVBmOTFd6xXpwbIEjUz+UZ71ntal2oI3tx+8Wjx5iVs7k5CpY MrHA0e1JJGZslTVjq4s2Y4/DF0i2M9TyrleZsRWYsccBkNi/ATP2bsl2sEAJ +mgS15ojqbalF4i+UbbmJ+TdbugzEhnIrDJiuyGqTLUDrWx3gMKuKrT6TSbc mdkQGx43gqJJcJhjy7GlV7wMc1IfeejGpC7y0LWxHcZMYyWc/St3hrcZeJis wjzJgMKjHhQ4hz9buiv+5IBJr1jEkkPTgIQxox07oLigey9DNzWP5hftsHNZ wyNbAtL8sk04ksz6N1R73LH26R2JXDmtCXXT9n/7dP80GlcxpPQp1CCnsek7 4/DYVlBRNxPNjXGL+vDdU+yOIkTi2/qmtiHUtQAcb6bp+Z33TdMdtpabBZr2 1DD9meLefAE2qRa4c3wr17txN8t6pFmBtkFaRTeS4ubzx3eQHxd6cv2mbwpV zAmr11/x4a+fHt1r9l58x+RdMjKuTDD4nqaBbjyQG3O5dx/bBjAQd0hsx/FO n3vghKar6lZUeSKjl/YlYlMSivpJ3kFnvUj4/0xN05LfzNvYmnASbO8IBj3g auMMX5HpZCDSd7bn/MeGInOpAPSbzKe/ouM6Nq5fTv/2OO+Cnv6R3gOLxA6x 9mGC0n29VAeh53qFl6qr75NmS36qlyrIqfRS9b0fSJoteWHSbF1RWW01DJyH pNm6tMhL1bf3PboHSJqtSzYlzbaig044mDQbsBB6JneyC+eHV5Nmizux64Q5 nZE+k2b+ELVcOmPSe7iU3jCXW8SW7kuIQxFhFdFvUN/PmAmfOGO8nLoZE3o/ MGMmXDhjdMXMjNGlhTPGtfc9ugeYMbpk04yxoo/OGI+F0DO5a6eyGbOzv84P M2PixTVLwkUDH6hRIOtwUSi9wJO2YoYSyqi7/c7aTqaXWnM1CMOEuw031yDD du4OQUIduRpsLjLHHhN78VpoqMbdEEtoWHKRY+hckWNHMzBTan0b8X5ItSIx Aql1LCyO12LDJbaXYTsHz592LD2vXyKzRcYlqOIu+/7j+AJ7ERY5RjFOYmIy GcOh9GqNR90k7F22/6IlxiM/JuD3KEod0TA4oomKSARrM3dWGXwOixHP+aGN K4sRO3pzzZL9L2eJjsxEvbjSK765Lszu6IbB2Bkae3PtHph7qMjumMgpvLle U6VdYSQWZijeZTOc+PTkzmS29Gr1YI/IUB6JBYNRFYkFbWxPYD3/SiOxME2Y O5DHnZQiEwEIpRe4X3Sspb0ku7OWGpk1x5owREWspVDbduNw2FVeYZ/h7nDH SCxMRTxYs2QlptmVmF4m+rBC9rRC9stdb0UyEFpJGYlOuMR2rWx3cIlNCiOx znR9vS0S6/HpYYoasGniCaRJTiDZqHx8mVEJDR2ENYTspwKtSAZCK4kgLUd9 PC8XxWBhiELwqpCgGlUYTLK+0zMoxn7IoBKf4uFNm3BCQU0wOLYTzRgcXemP V9rmSrszHmezK+0wPPVX2tD01Stt2+H6StsWn3SlDQLrrrTTN81eaRupvRcP V9p+ZFzZ4Stt3/aEK23fhSS0d0uRk/balfbstdwR0Zwoiq60+34YfWdv7kp7 5lNFEzZ3lvi00KxPC71unyoiqo6D9c5Uro3tya099HUW90sicM9FZ55C4I6t BzOsOVLENYdl1xx2mZdcUijFje6Y9ot/czIZSK3ZCcEwjRvuuLwI0zfsi0pi hi/kYmvH6EzrWuq36TSJVM/A05VeIDz1xqIxe1y2H2eMFekI21kVa4wfpUZs Imz3V7AMuGSm14Pj5vB82yGZ8UYBRz4jxFSwonVThs/Dlf64X3f79RYv9ut+ eE7Yr7umR/brusPcfl0Xn7hftwIr9+vJmx7Yr7e4BztiGJJeyaFr+v7wRt01 YrqbgZBe//YM934oD23RQbhEJrvycAdf6fUtOrSxNeMtDjm2QwejjL9E7M7g dmqm/GqPToq5LOJ9jWVL8bulJtktre9roPTHGe9m/NSb2NXZCd0Nz0kndNP0 yIzXHfLMjNfF4rQZbwVWn9DDmx6Y8VPf9b0dUOXs3GFk7FqvjyiHJ75vG4/l sbX9uIW0gakW0O/x8Dh+fNc/jUMUYh/MFa95gZEPrdki+PcO9c3P2kxeRLZ1 E94nbe32NVat2JbhNe2tFhsmM03SIxs06pqbeX3bE2TqlYGuyXexTDM4vzJm o/wSl3frNL3mdRZbDr1TWioguiJvYuKAApqexufv+/ftB9BCyZktREAbRpfM 7Z0r/VELWS004XGhhfzwnKCFXNPXtZDpMKOFTPFpWsgJrNRCyZvmtZCWaqax USDJoPiDSk73QIuF7oGG9uMC3QNC7IPRHhpMZpQU7cLC8Kr2ybVHhfrHf0eJ J73BcvpHt39FA6VfLuYKf10BGfIP3Qcxjh4/tNLBIy9ROrQ/dM7R+sZve8KF LW4CR9JE9G5zpXCgdF+F02s1ripP4dDo9JTgXoA57hImUZISnNFDHlRpSnA/ FOPQDDElOMqmBB+i55PhkzdrlsLeBVRMvkC1aGd7Y02GcEzZLEO4wqKZzAbc A8oW9KwKT8QvYKNkan35CqU/4ikOxThIp4Fwkmr5MJ4sJRHBc7O1RDxZ+C4A S/qF+hmWbEEllpC/NNWjKdauxFB6px+EvW0qgpSvXbY1EgOibfENCtQHUDXG eV/vFth4V5Du27e15wSzDcPc4Wmc2j4X39T2/fj4guM4aCAxe9nmH6mFtmHN F7Ahsi1Mv4xA+0xzanAIW3FXybRARxE4GgTq/3JC9sXh2pHTvdbCo6khZDrK cCkOZng4gEGUYHBtFoDSnfVZTzg/Flq30me20RZ95gRk9BmVd4LTo/oMhsLg SIb1UWX1GYnhZXJw9Gr+vwFRZn0023uJL0WpdZPSs3FuWjYlJTcfiIvoookS F831XTCUXuLNB1PO0ZHvd/NhRDIQWumkaTP1VDnJ+Va2O7iJU5ftJLeN4yVx R9KrUTR24sTYmWFGdaW7h9irmkRQrr4PGEYnp/cDOfUh9upgIijzOoUBw6jL BQyjwvR+vr3v0T1AwDDalN4PRAfbw8EQe8BC6NnQyHavZoKKh2XDlMn7Zt+Z syFw+KREfnrmJJzCTRI5nJk5rnTvFGpdTeJmqO9nzsmJm72c6hRq3eHEzeZ1 CmcOJG5ezJzSxM2+ve/RPcDM2Za4GUQfnzmAhdAzuRt45cShb3zixFxpTeKN lIkMgNIfLdvgAcvXHrCnWrZd0yP3a7rDrAcsP9kDlp/kAfu6ZVtL9R6wPPGA RaHsVQ9YvsEDFiEgdQoesPyoB2x4LWCm4aWkTuABiy7GA7ZjK8KNQ5dbs+kf aQyCLcdwwWfIpV3pztO/l2roN05/J8NOf/2j6nGomP6xfzTJ8umvup4q0afT 3w/Pq9PfdUdgDru39U1fnf62w4ElTZVkd654QidMfxB4fPq7nqBf+JKz4rUy +Pzd+HKoqe24dW7LQz/BtDYtzG9LbvpW4+odqJOo50yrHsM31gubO4Umdc3M Zu3NZ/3dZyJsgw6zu4UsIt1DZ01wbBTem24pQQvWJ1s3RL//rz9/mxlHLT4Z R1/JjWT6Gn1oAIoxHZOVYmTN6DWjb3yKZoQ+tLIioBmttFc1Y/peTjMKVqgZ CWhG8uY1Y0heh4hINGPGGuRK9z5RiLYuKbNo/VlcdR07/UQh2lOSMov24Fnc vE7RicJWXJ0obGnRicK39z26B3uisCUbThQg+viJArAQenabiqoTxb7z5gc/ UUSGBSRY4iuzzpoCpRdoRrWR7t1EdidrtzIrM08B20yJ8RRq224gxIZfPVl7 GtGlWERfk/iLZgK6oPRqA7r0sUaWJ9qDwagJ6PJtbE+lAV0XEMq1kRK7f/7e Qk3imNMxkCpImY2UkftHykjZjYyVnJHg+tHVj8xGXA13TLZ36PiuwLd1D8nN Y8u7Lrc5cKC5/+750/Pj+HGII0BWeixUMusovck10gDrkLuvVDHqJW1IaQmP kf7FKEEuFEYrxX2vwNl6nY2vuGDYEu1yl0rUcrElih7zjpfJfVHITGHWgMzp 3ZVer7KbKHKkboMYejAdHNN5MCbOSdnEZdn/ygLNBy1tt07z8eFYPNYajxCh wZtzXFtmuY1WNG/8EAiDFkRRCwqRYDCjBV3p7gbkYUKbDchGBhiQR5PUuMaA HPpv9Rwud40mbGFB8sNzxIBsuiPBCmze1jd93YBsOkwsSFqQkneu+CQLEggs MSCbnkhwjaYI3c2KD1uQck1tx+UWpBZj8AEnzFqQ7EONBck0cBYkkAXvsNV0 BHKPmo7sC4coNT+AiLWtaLqDNiPfymjJETEYgc7dFXTdIFv/0dptPLUfQX96 26Qkkv67v24/Sn8pdwhO9oWvBq61Y2uSluGG4P4McWs9k3TuodayccEz2HJ8 yH6kjyH3LlS1YdF8JFXCdpQNo8a7q8W+MxG25ZtDVz/6phmfHzJZX7NuQE2J dySIcA+Grwv4L8eJjgf3iKCBYQgosWHbzdBLNt8mguZtOnFjHllsY+sbkLE7 EUBm65h+DgYowdo7tbvmGBArjNk3mYEMjRJ1S1vL0K7OH4fCBLSie/mnAxkN 7CVIoQRkmcOuK90XZA3TUsttlFDf+966+Dvz87Wqc7mczB1sAdJAjnHAVXa1 1TqM5yCmByptY9cd/xLrpr62aYx126exHWJL+6J914fK5mOjcuVk+gmV1bwy PGKrdgXjlPu+oD3R28r+YGu3r2nDQbn3rcjNd/ftx5d3B1viO19qW8bapvVw M4xmtTJ/v5vMSWughi4jtO8lp70zPHnsWDFpMzMfyc3wMN2/H+E1AsrWEr09 2IkJjcxSx50uMH9+ToWEtnZCjFoz46gRbG2z6jQ3885tq+AlDbYv/2PxHNmy 1Hsf2e57HFwpAvMGC5tr0zbLHfi44jEbDxEtp3oghicqnOiBjBOHK91bDzSs Tg+Y+ms9IKr1gJVTqQf00uz0gHuJCj1gW9oXLdED3awyPBbrgUXrCj2waAl6 oCvWA+0kY/ulHvDOH8f1gA+uXkqs0gNOSGhbrAcCopweIF+LHohkCVwmxu8M xaYr3VsPMFSnB0z9pR4YJ1StB6ycSj3AEOgB9xIVeoCFFy3RA+2sMjwW64FF 6wo9sGgJeqAt0wP9II2NN7Sf6QGHnRI9EFC2lliuB4KQ0LZMD0A728rpAfS1 6IFok+MooUnK2IVd6e7ngsr9QO/3A+yurTwJnLAD6P0OoK/dAfRuBzCqsWTm q1lleCye+YvWFTN/0RJmvircAfTMJGYI7Wcz36GlZOYHXK0lls/8ICS0LZv5 0M62iswBX8XMj4TGnCczPxfDZkt3n/mVO4A+twOQU71F4IQdQO93AH3tDqAP L1qiB+SsMjwW64FF6wo9sGgJekCW6gEO67Vrv9QDhRaBgLK1xCo94C0C0LZY D4CDgpy+Mj0Qb4YZSXwTMum+XOneeqCr1ANdTg90TbUe6E7QA53XA12tHujC i5boATGrDI/FemDRukIPLFqCHhDFFgHBk/ZzPWAHqkgPeJStJVboAS8ktC3U A66dbfWVnQRodIdDiUUgQ5jqSvfWA23lDUGbuSEYx/obgvaEG4LW3xC0tTcE be9ftEQPNLPK8FisBxatK/TAoiXogaZ4PyCJjO2XFoG22CLQxv3ATGKVRaD1 +4Gx4oYA2tlWX5keSMI8SaIHMk7ZrnT3/UClHuiyeoDV7wdO0AOd1wNdrR7w 2T9GVqIH+KwyPBbrgUXrCj2waAl6gBfvBxSTsf1SD4hiPSDiTeFMYpUeEEEP sCo9IEAPsK9ADwQCdR4TrCPBE2e9zLHAle7sMHpJGVkboRZ6IJOR1Q+DcWVq e8d9aR6cH1lbnJF1JgdC6o5lZJ0Teo8T0s97Im9j/tVxFR40HvRYHj8OH9r7 9w6EIt5SUZnwLOVI/G3pzn7zQjRclq9Frv6JfvOurXswIK73m/cjUOU37xqN qlfC+c2To37zi+TTAzqbf7yJCFq6Jg9oibYBFaINR0tIyuqV2fm40gsMR5Pc /Zh4v2Q7HDi9tMxKTi/ncW9+gp6TUkovAXDEQOlFj0Wlrb3lsf9Zfkg3eTJ1 Kzf5ni0jivVkORarwZNUgyxNAJyzyIkvsPReTqyG6uVoYjXcg5Aefa/GasCY KEcoPxbFp0Eb2w/kn+7kqwFqae7pOfoY8j3/8CDMxmrwlcfoqA6A8NOjmdi9 wyGLJ0GukpNglmOO7s2UtY8+HJlNPjbuF55rJDKQWZd6zA4Rd3u0RhbpQ2hk e3O4HI4xHJI1IPVhsyM+mVRHzxJJKda4RLyY+vDp798/gHZMaKh4k9xb5tKj 29J994Qt1SfCCvuEqx9YhNE0iTs6tS60QjXtYe0YtoYgwj0Y13tLJtwgTGTW Xf65A195Ux+7a7QeWB4UppzdMeJNDq6uVYc3zw9PYz/efx5dU5OvyDbt3ZW8 eegDaENle/Rv/Wm7/3z/EkeeQbsOkoqpecScq26VuLgpaAun7tDItpmeHj7E VraNmSl6MUoO6q6aMS70aw2+ykai9OmN73p+Upmju3un+TRBbBqWDv9qFXB8 UH0/Pf/zo1PeTCb5z0QyTTIOfq70ajcR3diWpyv1gwFqup/Ktg+uke3Kqemx ILpd/x/XWwVpKHTOoJJFZqvQr7F2KNfe/WP7abh/cWhLst5wnKAtd3SypTsf 1HtSF+Bu6594UHdt3cNpAe5+BKoO6q6RcVTqYsKKwoM6xhQx2Hjsi7WaYHZE V4f1sVmRdzTtIeX22Hf3H90ugKEYNNck/Mc047foSi9wb0o6Mdmtnegk24mB 24gknt36wL708UH/wGFc7AuAy0vkHzJ1DJjaDJqknuNU7UyhTdB6jTQvsYDQ hJd5c/phlTfnoHnbRK46AFGVkHaFww1nLLM+utKLBJDWWaPEstuPwt2IZCC0 5ngDg4RhtzYon1QSFxxzoLHtFcw+Jv9TQdLas/DC6N14ZunsVzA8aOpJaIgo ieeZkFfeuKFk0la60iveqHXUMnMYWoZJiLL9mhuT1mglhg6fqmfbNdfGdujg JsSx/ZoWv0yScjHZ5eUqX+p46CA9jJ8d7ohIPP9psmXL4c6WXjHuFLdWRvtQ amV0YwLnBDWUnhMAeAoyVqBj1m2J2NK47XLk8h8cfRKJlvMlH5aSK/AdIj2w wOkfPznFF/1OKU4W4MzdnivdE39mpbG/QJYNhuLShTkKcquXyYtlCTcUdaSY De5blF2W7RrojxWJGPciVJHpjo5ycZ7g/MYP4ruX762PAnQ8UEsUa7sW0bVj VteeSG6mh6e/vhv/YWwtoXaQYZuFGuYcglyDl6f2g96P3X8cfxrrxELjcmER pYse9U+JA2wiXFwfTYTLAZQ8TC/D+Di9/wTEQYlnIiUJUnLM07Z0T6QMvUSq x5uYp4MMa8RDHRvKmafn/RMSeIMIbdrVeTPlDdKjbfwP7jBJqKdhfGyzLHFQ 6E8fLnV38YV9Y9t0Th303fjSvbfpRXRVrM+m00So8S+6Y5Hn3lUyvwKZbjoD x49HWrhK5hSCXYOS+mYUkCUz+vQ4tC/jT/t2bHrjPegqxU9MTSItL+z9x7Z/ MYZPO2jWscq2MrQmvrn7iNjprU8Y4BKStjYCZWtZfH79u19886df/+VXCx4f kG5bLqvp1qq7+RxeJXQ8G/jPSWdyuPn8+OklqYmaTgriINog6z2iN1Kuoa5p 10Nx872eZe/Hd3/XM/j+Zfzw7mn88GA6HDuJZBjNfC0jAk03j08P/fj8bD99 f//88s5UMQscxSxIyFayi6leEt0kf7esk8hwE63hLbfWFtFIf3NxoK0Bch8k W/0B2pF47Qji5nJsTfNelM6Uo68cRHxp5UgKlOM/P/aQhixx1KQ0UYsZm5sr 3VctCmVusbapRZABRGjmqDiCCyVV7coYt9CL8QXaaRi1JuidXjTKKqMXu3mf SW2nPHwP4qb7NM3r4sRSBx+aYWtXaqzhVAh0SI2RplnqscMN1npMKUXcdVYT 3malzUyBwcjnjw9D0oaG2uFDo1e7MTSIE4/eBcCEMjJrb99NH9/147vJNtbo FRD71WLcjsg9dGN/5z4apNWbA4dclLGtXREcddx//PF//u6boDIZIejOCw4q M9Rx+tLKgS/re/SvHzvyXxijxk8N89YgPmydxqHBLN06+W+Lx2G+bYKaof0X 1gy6j6Oa4fPH90+ws45+TJQliiHjP+JK9/aaa3p2QDFU7KyDIBQUwp25ksxp h/ymOn2VDpltEIG9E22b0eyu4ZN2qS70NtsOp11iACZ9hEnXcb+diNV0u2Fa oMRVDM2/NEr64yjR6mto9UruvHxpNIJSniAlYwNwpbvbAAZ0YGddgxQvKFlH xNCGPwqQkryKfjAGdOaWB9Ki/DFMD+Q7N5KADxXwMUwadXG5gGpW/cg5QKBm aP+lAaKOA+Sx/W783+PTgzMSRdY42iSeaLlLZFu6Mz461fTbz+hBkMPHNHXk Tg3huQge4U06hVvLqgrtB40VRUcUP5v1klEsH975Mf6p83Qcwu5UNebABpol 1nN+C7OtKdQM7b8ocmwfxxegD4lmIfFCmIoEORnfMVe6O3II3pYszstAzm2G DF0MnLE/cM/4qzvURILbpjptktma6p86qhI92G0EBG8bGQERNAltFnBw9ULr Lw2HtkyRpICIrvw4Jslh2fRhbPf0YXZuDgfIn2tVCR7CJNcYuOOjOJCYe61E 4B2cokjXGExlZpEBHfCgD/l2kWhYggxB5FxVPNgTPmnQEhu2Zmj/hRcZ3cfx U+zf79HPb5/vYZWJNxFYJtDIHmTR5oPsvTOGGuZlF8THpTtoNNiMbigxl0QN Dtc8aTOz12vnS7mruhL3pQcbHx/s+6e/4Z/rLv7aDciNd/Qvx8nVt2V8KHm3 bBec//x2/IBdB9G0T1DSgdlWnt4BMx3AN4gWYZLcHeTyabjSfRGDRzXan5hL QIwrORExc3FfGDG6jxLEED3a9/dPMNzR0kQSA3w2wRnbnuBsNdzMuDeYd+d+ uG3JqcM9E/elh7vgwkMPt9ITtH+8h+GO53cSDXuT1YenTR89vM3Pb1/a57/e /u3T+Gl03SQeMCzpJmcmmLYTvyx+VT4yCnnXBverQslpv+pC3Jfd/5g+jv6q 5vd8Z4acuHRTcbDT7Km5k/a0u5eH5EpSuTH3BciAptykBcc2XacuV6v79/lW OLwA1L6D+Fp7zemLZWZrbAbQQvbdDD4mvqZp3O9td8uhxPjVSzT483e2vdlA j3McuTYruV8aRwX76IAjt7bGcxVpEhzlVr5p/0xS14wj8YVwJH4AHIkKHLlF Jh7HUNxz0ymHI1v6FnBkjuga9uMwojPBSGL6RdQRyP3CmxVaoI7c67sv4ghj IpBUAqTc3pDuTyOpfyiGtgPJXTivFRLDBQrJccS62jkkMVSBpMYYBNwvDgoJ SjYiaSH3SyOpQCHpH4T8/LZvP3RgB8Bxj4RRAqVMZJ8r3X1D2rsBYnFD2m/Z kCbivvR4lxld9Bn9X91Qx20ETp3v6MkmADcqiV5IjAyp01b2zMi+hF5odlhg mswCo0d77AoWmMYvME1+gWlqFpimEe1onZAE9WrBlmxWCzO5X/oCihbBtAkw TYzGqYsLOhmm/2yfnh7+7oQnZsfkmhxlI0DQ/pdbfJz6XSzSThC6I424C+9q jINDP8ycCw8apr2ExPcUMk3OzNFPegQfPrz7a+p52oTbK8a7ofFacl7VDJKc m6V97SDjS1tKC47s370bHv7uriuiBRMnF+Moc33lSvfGxqTkDi4UXpBrz2Tb 3zE6j3I8jAn/CnzSquqOsP51cHz37v7hnf32n96PdiDD4NjK6891Q97cuEG3 LhTdw/BPQFW4AmON3lb5i45FXSNgsfxC7SDjS6OqYMf83btPj87bImKqSTCV dXhHe5NZuR90l8t0J+hUTDHAVFuNKZuk0w1NBlE2qyUm4saM9xJOIoET7SKc kppZMNm6QcKXBlPBpvm7d+Pn8aOLuo5WeZTesuS2y7Z0fzyJXZx3nCBYConw 0DL0faWosu2Po8mO3QIbnKSqRkRszCtrGWpc6RoB8OA/gHswL3EP/vs9/vnt x9EBBMc9OMLJgSq3w6HbOSCWByqkfxY7OmyCA5UrOfFANRf3hQebFXhc6i9P f377+YMb67hjQCQZ6/7kraoWz/T52IRahKtyHNcQRJNecmuILd39F3U3lUzF X/Tki8+FuC/9ixY4v90P70c95I+fnI00oRpCLBntnM+KLb0L983N8UFvYm13 O85ZLDEv3PhQkeXP8qH9ZzdqzTSOHx5fwh23q5p+ZLpsIGLsXTsM8Trc9qSE lCh9CXcTnby5bmNk6HXxeXx5+vTRniwTKa5q/OhfLZnp/ceXJ9CeYXWGI4Pv 1cHkYD0tp/Ny/jH2n17Gdy4c5enZiuAK9TBEit3RBp6tkznvWipo0sFCgPlC WN68bx/veyh8Zyr+lDpPwNUHZtDHm/9hi++fnzDEVIa//9VybhgA6trj09On x5cYM9nr9VD1Ss2haF81BE36EotJa6Y3IXs9/mlYWzF8wUlaCmZORx8Lk1Q3 G5jY3ED5p7aV82tl+kcbFTxIGL2BMFdC+n4uzjS3Pz2+CdIOt70DwPpZnEgg 8sY8JZ7UtppbcJ04QIOvZb7Hwt0e6s07+YKqoqlQFe5aDsc7e8QTVZHzYaJV BDjLHZZoprxWWA4zPTrMsj88zD+ANYgVWIPuPwLFUDK+TTK+OWcFW7qzOZGO PatgAnb1c0nSZU+kKkmSDiLcQ4eqkqTDEHh6dPuDopJM6dDQ1neZ0nmPAxNH Jlf6mnx1TqU2EeAdmjB86R8qfbpEnLJ19vQVWczQHYhW/6tGb+9cZXB0lUEi QV/Oe4N+Aa6EBpmD6DZvZi9Do9FEy2Ey/yNvzwYWhPk7IH81Cp/a79Xd6PFy G0V36xHtgrLFIR7CV/pXG2k31z6uWmj8pa9MCgyCz39vHx8h3NJBwB+0zamz b5e/PpRu/PVhL/SkB1Li0RgX9X8gSTJiZOh6HqWbika04lb0S/v08unxp0Gw +9scXpubbvzu/qP7yD6a/vqbofu/bp+/f/i7jel+vhn/0b//9Hz/ebx9frz/ ePtBb53+YY8fT3aYfmq/e9c1hvPbtBiH2//X7X/79Pz0356f+v+m5+d/G8bP /003MP//Z/3PDVNU7EPPXdfNty5299ZoRnL70w/ts946/Yu/RdKdjA3Beo95 +1OMsJbxL+mL/eP207P+VT7onze+1dDp1zL27vxbff6g/++dbqLfiSLBkjfg EufeYGibVi/U5g2QYuL4G4zT1LKx/A3CqHz60N7czv79fx4+jvD4CzNiz/4D o/TCH7d/ftbd6H/ftBoKXsR//Mcfye1wb0IeoYTpAxdn/g9sE7vAP46Fsn8Q jBqaiMBzEfYfOv4Hil9EC7mtfwupRDIWf/x//+Lb3/7qT7+IJZw2Sb+SxmfG 4Q/CUhG3Ty/6hPH0z7SijH8QpeIfmPs/BJ3/Ip8+Pvadb6IVICbhDywwC/UI UiCcN2Qu4uk+irCvIQ/9EYazaRIRz23/1+8f3sdfhGCCkj9w8kX0V3H/oTQd i5denwzb5wAgTBlusn8kb0GpjCK+f3h+6Q3aYkcsjIX+x/X6GP4pvRWGJ55+ kX9+nImgenrR5A+K0+8BwrFc/CL6u7z8Pb674jT+IVH8RfQLwsBQrFYi4i9C JZfh61PRKB4rSuVfSYi5iPuPh0VwFocTm5QC8DpyAa0hESEEkyT5g6bTjPux YM1CX9zeP/4t/ZMe/APkETIX8WxU1otvgJUiKvzRSBHHgiI/hyll87f4r9/9 /k+/gmdMcKNI8kci4tbc69p/jOLFF/n21996EbeU0PAWut90muEGc19p9qP+ 7j/++Lvf//JXSUml1jISfvv7P//uTxtE3P7y13/4z1/88T/D3xSh+PVx8gtr jUPg56FLaP3uF7/91a/dR0r/Bv5HcH+w9C0oX4n4ze1ftPr9Jp1mnDAe3oLp HySK4MK/H47q948rEULoXzJoSEK1cgnyhHTfipj4l/hF/mJ+jW9//5vfpN8s p2Vmn2C2gNZfkh+VCSTDNGPYUBTEr4jcVySELQB++90742dk/2nkIopR/IOo VP16lcMbP1N/8c1vbv/821/c/u+4LK/f/TVcfDBxwP/r04fu4R1u/nqSiFSG qheRtDaxYs/3//vUpd1KMjshvV/yn+kfTKb6lyZLQsP9WkSWs92Igs8o4YaS Lv7BEhGGLMzJasJCYl/jsY1qSy+9ehfM4h8aKFECk/CJVkXpW/zlt3/89hff BIUhuN5vhj80upJFVQVg8PlU/fO33/wiQXhDklaNYakP//ScgS+E58vZf/3x V//9D9+GPzmScR3VKi5ZSIRfi/Bc893+6T//8Ktf/DK8u8A4zHbBCU+Up2y8 CKmW+vcPv/8mtsJxs6XHQiXDqfza1nA0F/Ef9+/9DlX/jExQ6f9g+lvFL6Ia WM4wI3zxFgyFb6w/FQiFP7Ag6VtIv5yp5YpIUNxScYTDWnTLlEwXVep3oVry QgQ2cTEgjTD/uvYPTJIflfs/6FLn3Np0BaEZifqSYM4SaGmNHmQvRZAAIP0S NGxX9QTRP3HyPbyIBoulCH2+D7WQ8gCnTdOwiAs9h5nw34guRdw2vqLUE9ov WreS6717VJ5KMQc6rHX0SkTQCvrbU/+6+pdqFIpjIZmAP/SArUSEHarQGkeE tUgfJ5pkwoTtecNnw/nh5d1chWN+aC0Kn+ixiyJ++e3t1P51fPzuQKuS3cG3 f7n91e/+9If/af+Qet9ujsjuD6T0r8r85MRSuL2rxp5ACbR++4tvExFGwXLk t1QNM98+DKfQsHADLbGIIv5rIcIAVQoR/+Aq2UETr9sbvMKFEZT8E+kfKPcJ TUT85be3v//3//tX38Bmy2w1mZ/fVA+MauLSrqFqvxUhPDnTGGT/+6dk72qU B4k7XsKTRQCHI+JteqbRyF6I0IoxhcLscBZAzBN06sKliFuRjkU62W/9bNRf KorQyF6LmO3+Zzto/wdNdafZo/xn+/x9UnG+2cqeCwgMp2n9h28+vvzxfdtF G4Me4USERLM1NezXkh/ViJmLUCxZwBqVHIsIh10oni3LRoQxgUQRif6x/1D2 E7QYi/8av6sVIaNZ5kNrTC8LwP/pn4+llhlo+bs//+Y3eiP94eHTx/S3vcUH /whfA5rO7DB6kpD8H5mW3y/AMO9m9kn4nr/9xS//dPuntntfukGMI2SvDx/H p6m6pWv7+Penw5Vf6bP/0LUvhyu/2ufz+CEpIQdHaLZ5NQ1tOG3yr+D31P++ /ebXt7+5/5i2zFpd4JMZ+uxXbcMLmXQx4Q+9nYj6gTRILb/nMH5OSnjW3uQ+ WSD+ZfzwCI+U6qMST/5I7W9aU8xa6g7D9t78YyIZFJyeuMjS2nb7//z21384 9IKv/J63t3PbVE1LY7T1b2sWorAz0H+wZKN1y1iqcj+O//j0PB/brMEFPkla /vbbE2eZ3seMH4bxuU8/L5nZt+/H79r+n8PT54OVXxmhX/7qL8YsHP+pg99T pd/z1//t97e/+PbX36SVy0ZIv7CeKWOqE2bqbmYco2T9trEbvbWdKUqcfoLX LRMVq/cT8Q+K0oV89j0tw8YCCXPlPPtkfvz70x+SQ6jZPh/6VfQns5aPT/fP Dx+TAnawT5baZX57+/jd0L60aeXCtzXm9IfHaFBPzkmLluaTtCU4hqXf5tCG UX8y+57/++FDdx/mijmNpsd0dQjxxtPh39qnsA3QhxzlLT/mD5JeJzRifviC WEf/QioYKOwfzWFNrfcei20Yns3PmfJNt06ZfQJJRyg1tes94Lzl3z49zH/P gplt2g33T7N9Ak2ND3qDkZouZ5caz+3n0dwShQKBGM//cTvTJh/Hv+tOu/ez 9ZMf/GOOeN3yKa7Z+lQQz3CM8mTXrY/bC/PGh7/qxrexdrII6WNTugwv17L7 p3YIuOWIR3sCRyzZ0C5s85PeFJqs9OGVlApXTPoPIRMk4JkeMi31AIUdpT4y 48R6oA/Nsa4+Ki37fGq/i5WTGxqsFI0aDLNk5bW73fuPyQgJ1cS3FVKpBIrN DAm22TA+hgIcbAn2DzrbJ4RZZrvULcc+IF7PwWjbbgRJoKgBn8yV7sNzO43m Btb/kzJ5QSmb+ZFr9ntqAEb06VHAiYlJIDW/SZt9T70VT74n5yKqHn0u5Qn6 EJ2tZZYPLbbEFEetielMhS50/NNj37//eML+9lELoj/D6aVj2T7B/Wu/e0z/ LOnzd0adONK3mj51s7/Q2+enz8tdTUGfpkvd0lxg1b6t/vfx/Yf7j9PD4cqH Wppu31f3aVr90uL9178/rc/lia6oTz24epY9TLXnMte0u/9uquwzvO7T+LfD lQ/1ueH31FN0SHVCcUvdLbtd7N7KWi6vs82/8ln21/Fj0ieenwXTA1O62q9v 4cv6vH989+Hh8eX+4ePzwcr57/mrfzw+PL3c/qfuuLKl6fbjuw+f3r/cp5+X 7ox16+8+nPB7Pj18ejEZJ0KB5NFD4FbqI2fSo1xg6Pn+u/tEJ9DUI4GmFxD6 Z7mx67tVXC8P+oTVDmO9ESPKCG8r4+5JsnRJwmJ9/a9VUfpXKfxavbQ8pOaP 8p+lf7+4Cy3oc3z5fnxaQ2G2G56JmR8B7ie9B5sdBg8eI5uFQeF++jgzrN4e tATeru5f/v3b/0j+mu1kyGy2zt72m1/89vZ/fJt4EYjUVsLVzBZCtk8zS3H/ oX1Kjsv6iNSQ9I/Xfs/5sQPj9AaX0mQ7LtT8V7Edp+pEHTRnzS7p/nKaefKE EYK76nfmuGIIuadkgtImPd2nf9zO9cnn6fkkLf/veqGf98n0FpzFP0TaJ5lb MQyI/vjr36aSK4CbuBU1kkQoNBKlVgzC55Pl+cGkyYTvgYg+sqDwB26Sgyye n6/shfxLO7saIwf/QLOW4z9e+nSHq/F34I/Ven/b9v0p9mb97/Hln7N1cLbt n7VcXpO/pC1Zk1wQ6XFOvQHX17nP36cKl6W/59zxbXXVNrdU1yDhw/PsV6lo ef/gdyf68IXiKYlrWMzm+bylyx13sJvDO4WH/uX9w2Ow1lClwmXZ7I9VS/Ov n+/fDlmlzCdJyz9+88df3/7xV39MK1eckn7zq1+mf5ai76/d8OHTP9KSV7yi Zi3//PH+JdhcMEfRLmD+SD0fUwy9fHr6+PwSfTNunY9MUjlxKSNaaOwzcMqc 8ra3zy/taTv5+/un2f1Bwa9i9GWvtd7qbY/3aUMfXMP6EXISZm9L0ktjwl7F 7dOHNjkvs9QQlXhAmt9XxO9psL76nkXbN9N63hKjxAy6MOcuLGH3z+1ilpXd mJl/f33o/lfyp5g53c22b9FaY172cXy6f0w2Cji9TcczFXrrT0k2rhRiPpOP 2cEtI5vpW/0dNXBnGqwY8bf//Ve/T9Zskm5T8ezSRMyR0H16/rfE/oFpcmLB FM+WiuWKZBrHLlViWCRMJK/O8fJ8ZXzs07/LT2afPrxEDabnymw4Z3Ml+Z4m hOvl/Us801HEonfs7A/7AsuWD/fx/gBLcmDNNp/MVyTbOHQjZXTCnf2x6FN/ yfthbiGi6Q0LxSmIF6v94/v7D/cBQ3pnED3yiD7fJb8njbbfx+n53eeFRcE4 +CR/sFdWXr0KPo2D71Gi4LxCGqH/X2xJqZz9ns+fOnNZ4v/UleMudX7DQvjS Pfc2bWmrpH8cxtDz+Px8H22FWKL4Q2CRvIAZ9eW99ON3T9GaKmmcZVioFIo0 vV02o7s8sJCDqwOZ7VJf/vHu8eHhfVq5dJ/w4cEEaiWfkoP3XmThvWevI+Of bK7BZvfSy/lpbgIOvuCBldd29+4Pf/5N6kNPD+6kFjEA94/Nx+EEa41t+fBY vGOcBa0N5gj6/H/c/h+L/xvdBze/ceFY7qB6c2NiN1uMe9obSvTvTArPu9sX 49bzl1/++g/2pT49j709D+O7278/3b/AX+ju9mmc3DN1J+Zx+H58GuG7TO/b 755vf/qXv7z7w+9//6d/sWWf3+lFz+yFdbdKsqnj0gjRX8i6YXucWFOyfQn9 Oj+//dX/+OY3tz+Fd/iX2+6fSVya7CZpI+MsHTRq/uUnyEYkMjlM/WApDGJ2 1nG4+Qm2H5ssIHpn0bo0fqbKv9rErz8h7uNhFIiaj02Wvd/8/pv/giR7Utz8 hLoOJtU2vany+aMX0PY3P2Hu03EYWiv/83ejCdfsyc1POHzUIMntR7prc+h/ 56pI/XYNvB1ukPBvBxL0VPiJgI/bvsHmY5Nw9enhwQadqpufSOhAsEG4r/7w VxvvKPR6/hPlu++wfTNzsL03fA2q1cMCwzbRwQ2bS9ytV31Tg+sKOFQQnQ24 dJ/hTn8Go9b3yHU8j2v+CXZDxrsWoelwTPPN/8Ncn5K7W60EzbZqaNEz/i5g tB2Rw6hL++lh+rvf/64UpuQwTP9liTzXyRHwudSKDnyUFGKPjZxyZQHw8KiH eAD06B3ijvDjDXW/RJLxcaQRhINeDZOo3JjaETDouCwyUccehPrHxP2hiGP3 ow2YDEpuUSzs2C+WahTZT6Ib+o0aZehk13uNojcNDfmX27/fv3yvV5fH8aPe /nz3BlQM6SZig9LNzuld0AOUteH3Hanx2wc1tKinSPiZh170yWv+/r/+/G3y okHjEERmGoc145vROFhKphVuVu9oCJetjVIdBLHxzqmB8dAJs5NOYYzqF0Y+ mcRhDsYmbNyjmFwajJuxaWbYGdK1Mged5ghyxGHgyNdxo6phg/Ow6aXe33yh LdUaMiNr6HIvVQ+ZycTy+OVMIGI4Xn7UfNeu+fRZ8hCEJdm0eNdBuCGKk60Q HnvGw46sURLRHyF85RBWQjb4gBYe+Zc72GYg3JJJq+KtEJZNE060Wgv/uP/8 0hDucBsg3PaGB8cQgbUpiNt2cIyA8Cnme596MTEhsVkYj5IjhFYw/sOv/vsC xuKVLWjVDnQkxFxvGiDrkXNIVlkk//E/f/GHX/0ywfIhqPYMzaGqd9wXAFWu pJom11Afki0dwJOXYMyP3iQjm1ZaRfb5w7up/fTemmQSm0zftW4ba4i23j36 Kv0Y95yd3qT5GvawnWw41dS1bsK8fw+f8wQaFGehoZTQU23TIl1jEzmqu3o+ DI3XXeborN6CPe5NKatzr7dNw/SSKw6hEfOS9Rahw5oKHUXkzIrc9B2W/eY1 lykWt42Mh5MPurRFd8Np+eA6F87LuWVuxxOzw072uKGUImXYOX2vVmcF7OMu zERpNz/uwq5/F6YBaiIgDwG0aBfGDgK0qVNsuGk6d5igp1+PLW4o3hqGucCU Y9+1v6XoccTvJHsSLjomX4M0EbpDq8Lb/ccf/+fvvoHXU11E7sDdF5xdl2DU RPQevi/xED54YQIAPnJj4gHICeEHAJi9pl0BkMvDCKwyRCu9uBoGEgNBLjwG aT0Ke9IP4UpFUEr98npxtujTgTghpVoPIf1ZFxF4SDXJOs3ECVY5YLRTL4qW Tnb4ioJXAWNQZNrhoo1w0nrdhGmDSy9QL3qTddYrCYEMq2z2Jkt13dT0Bepj vsHC6da8BiMtbkfRbd6Yi4kHzcEUb9ilYGTiTS+tfJjwqg+64tBP2VQZhBBG 8sBWhODcT3muU//YsC4xulPCL+VHuprN8blP/cSEu/AsGttRT4TMRdFKsRw+ 81ed+Ntx7LYrFrMxDtfj9C3eEm32Imta5NyQIL3P3/WuVP88H949jR8ePtt0 NUNYnZpGI8VUfnRM8bb2+/vnl3emiYGKnMJa1ehvbr/U88P0MowurWDayAxT H/Ct63dySutP7z892xwBlEaQH95fk+L9tdGqGspZHBteULE+4J1LqyrEI0K5 YvhHpXplSpWihgvOlmA07rw2r8vw0A6fPjze/FL/j0nEQbmkt7/999ufktv+ +08f//psQGWfbjVssfkEc+lU4r/c/uxnP7t9+GuogX9u25tKCgvir3X+RZc2 Qv+PPgFQTrn+H6z0/2iIUCb1B4aojBqubMqoMu7+5gOtVihV2BDqcxMQqwxx NDVUxeYDPYDUMKPpv5ShgaWG7lYYBnPzAeaWUt0EC1BDJ6Y/wKZzbDo3vP0U m84N7Y6hOTcc6/oDZDo3XJbUJJ0h+ixsGGO4/h/dOTGU+UQR84HunEjdOTGE qETqzonUnRNDjE2k7ly/lP7ABCAToTsnQndOBDUfYPOB7pw0unPS6M5JozvX 30CZgAXzgencxCtrVcENYaMyAQD6A24656ZzQz1HDG2rIajV/2M6Z6ZzZjo3 lLWEms6p6dycKYmJKNZjYz4wnRuWF0JM58R0TkznxHROTOfGmYxg07nJz0Cw 6dw40BvqVBN2oj9ApnNkOkemc2Q6N5mb9agrwzVH9f/ozrHSnWNFzQfYfKA7 x1J3bqhW9f/ozvVPpEz0iPlAd27plrHQnesXUCb2nhqmYPOB7hybLAH699Qf NLpz3OjOcUOx46fXb6s/MAjGBnDYAA4bwGEDOGwAhw3gDP+M4SblhihHGcZj 84Hp3AAOG8BhAzhsAIcN4LABHDaAwwZw2AAOG8BhAzhsAIcN4LABnKHWNPQR 2ATSmg9M5wZw2AAOG8BhAzhsAIcN4LABnMGbgZtBmwGbwZqBmkGaAZrBmYGZ QZkBmcGYgZhBmAGYwZeBl0GXAZfBloGWQZYBlsGVgZVBlQGVwZSBlEGUAZTB k4GTQZMBk8GSgZJBErXzF9vAdIMiCyKDIQMhbjF3a/FjBtH+gPbXMONrQy8M cJR5ZUMhYOap+WG8+rDKx6QAenw/vow3Jl3QZDXU0/g8vth0ePbp57d/fHl4 tGrqwRAb3H7z7Z+fb0yW2odPRoPCZ7r+c9roD6NNymM++vc/fpt+8h/t/ftx MCwST66OrXDzMr7/OL78X7d/+3T/cvPNw8ePeldogmb69w/P4/Czm8/jx0/P P7k1u4Ob/z9SmRXof+4NAA== --0-391559352-1153219912=:1799-- From owner-freebsd-stable@FreeBSD.ORG Tue Jul 18 19:08:18 2006 Return-Path: X-Original-To: stable@freebsd.org Delivered-To: freebsd-stable@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 35DEB16A529 for ; Tue, 18 Jul 2006 19:08:18 +0000 (UTC) (envelope-from uspoerlein@gmail.com) Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.184]) by mx1.FreeBSD.org (Postfix) with ESMTP id BB4E843D7F for ; Tue, 18 Jul 2006 19:07:53 +0000 (GMT) (envelope-from uspoerlein@gmail.com) Received: by nf-out-0910.google.com with SMTP id n29so1376nfc for ; Tue, 18 Jul 2006 12:07:52 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:date:from:to:cc:subject:message-id:mail-followup-to:references:mime-version:content-type:content-disposition:in-reply-to; b=rjiNdBji+fnmIJ28MD8uvctiiHZr3jfVg5yVIJYaDP/nnB56gKFk63Y0PrwNImTQxMm+Xax1KdSJ0+K2mjONh51WID744g/0hDtwq1ZpWQ8NEO8A5cdSAo8Mrhq+w7To4YgoepWMHtvkg3zl/yyAkRwlznI266Pu79ZhrrLrmSo= Received: by 10.49.55.13 with SMTP id h13mr985993nfk; Tue, 18 Jul 2006 12:07:52 -0700 (PDT) Received: from roadrunner.q.local ( [217.185.119.201]) by mx.gmail.com with ESMTP id a23sm1137331nfc.2006.07.18.12.07.46; Tue, 18 Jul 2006 12:07:52 -0700 (PDT) Received: from roadrunner.q.local (localhost [127.0.0.1]) by roadrunner.q.local (8.13.6/8.13.6) with ESMTP id k6IJ80sg003570; Tue, 18 Jul 2006 21:08:01 +0200 (CEST) (envelope-from uspoerlein@gmail.com) Received: (from q@localhost) by roadrunner.q.local (8.13.6/8.13.6/Submit) id k6IItErc003195; Tue, 18 Jul 2006 20:55:14 +0200 (CEST) (envelope-from uspoerlein@gmail.com) Date: Tue, 18 Jul 2006 20:55:14 +0200 From: Ulrich Spoerlein To: Niki Denev Message-ID: <20060718185514.GA998@roadrunner.buck.local> Mail-Followup-To: Niki Denev , stable@freebsd.org, net@freebsd.org References: <44BCB58E.8010707@cytexbg.com> <44BCB74E.5020307@cytexbg.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="2oS5YaxWCcQjTEyO" Content-Disposition: inline In-Reply-To: <44BCB74E.5020307@cytexbg.com> Cc: stable@freebsd.org, net@freebsd.org Subject: Re: ural(4) deassociates if no activity (possible wpa_supplicant problem) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jul 2006 19:08:18 -0000 --2oS5YaxWCcQjTEyO Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Niki Denev wrote: > Well, after a few more moments investigating the problem it seems that dh= client is to blame. > If i don't start it i don't get disconnected, and also i noticed that the= five minute interval > matches the dhclient renewal period of 300 seconds. >=20 > So the logical question is, why dhclient makes my ural(4) adapter deassoc= iate, and what i can > do to prevent this :) Hmm, interesting. I'm using ural(4) as an AP and connect to it via ipw(4) and simple WEP. It is very unstable and will wedge the AP (running 6.1) after several minutes. I can't give you more details, as it is a rather complex setup and I would have to isolate the problem first (is it WEP, is it bridge(4), etc.) Ulrich Spoerlein --=20 PGP Key ID: 20FEE9DD Encrypted mail welcome! Fingerprint: AEC9 AF5E 01AC 4EE1 8F70 6CBD E76E 2227 20FE E9DD Which is worse: ignorance or apathy? Don't know. Don't care. --2oS5YaxWCcQjTEyO Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.4 (FreeBSD) iD8DBQFEvS6S524iJyD+6d0RAlFdAJ9dGGQR0jUlqTdwLf7XVTIUSoF8cQCfXTFA sJM6X8DRuYqe1L377z+7Z/A= =aKQn -----END PGP SIGNATURE----- --2oS5YaxWCcQjTEyO-- From owner-freebsd-stable@FreeBSD.ORG Tue Jul 18 19:22:33 2006 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B696816A4E0 for ; Tue, 18 Jul 2006 19:22:33 +0000 (UTC) (envelope-from john@baldwin.cx) Received: from server.baldwin.cx (66-23-211-162.clients.speedfactory.net [66.23.211.162]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7665A43D45 for ; Tue, 18 Jul 2006 19:22:32 +0000 (GMT) (envelope-from john@baldwin.cx) Received: from localhost.corp.yahoo.com (john@localhost [127.0.0.1]) (authenticated bits=0) by server.baldwin.cx (8.13.4/8.13.4) with ESMTP id k6IJMTOt055737; Tue, 18 Jul 2006 15:22:30 -0400 (EDT) (envelope-from john@baldwin.cx) From: John Baldwin To: freebsd-stable@freebsd.org Date: Tue, 18 Jul 2006 15:12:02 -0400 User-Agent: KMail/1.9.1 References: <1968.195.12.22.194.1153141853.squirrel@mail.helenmarks.co.uk> In-Reply-To: <1968.195.12.22.194.1153141853.squirrel@mail.helenmarks.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200607181512.02580.john@baldwin.cx> X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (server.baldwin.cx [127.0.0.1]); Tue, 18 Jul 2006 15:22:30 -0400 (EDT) X-Virus-Scanned: ClamAV 0.87.1/1604/Tue Jul 18 11:41:03 2006 on server.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-4.4 required=4.2 tests=ALL_TRUSTED,BAYES_00 autolearn=ham version=3.1.0 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on server.baldwin.cx Cc: Dominic Marks Subject: Re: Two panics on recent 6.1-STABLE X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jul 2006 19:22:33 -0000 On Monday 17 July 2006 09:10, Dominic Marks wrote: > Two panics, I've just had: > > I had just installed a fresh world+kernel, booted and then received > the first panic. Then reset, booted again and shortly received the > second (although they look identical to me). At the moment everything > seems fine, sending this message from the machine in question. > > Rough description of the PC's life: > Gnome Desktop connected using nsswitch/winbind to Active Directory. > Low load. > > I can make the dumps available, but at a guess I'd say they don't look > very helpful. I'll recompile with debugging options enabled and see if > I can get some other info. If I do, I'll follow-up with it here. Actually, the dumps would be useful. Can you look at the contents of each of the chains in the pgrphashtabl array and see if you can find that pointer value? (I'm curious where it came from). Also, you can type 'show pgrpdump' in ddb to dump out the hash table as well. -- John Baldwin From owner-freebsd-stable@FreeBSD.ORG Wed Jul 19 02:00:07 2006 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id BF08B16A4DA for ; Wed, 19 Jul 2006 02:00:07 +0000 (UTC) (envelope-from ganbold@micom.mng.net) Received: from publicd.ub.mng.net (publicd.ub.mng.net [202.179.0.88]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3519643D49 for ; Wed, 19 Jul 2006 02:00:06 +0000 (GMT) (envelope-from ganbold@micom.mng.net) Received: from [202.179.0.164] (helo=[192.168.0.18]) by publicd.ub.mng.net with esmtpa (Exim 4.61 (FreeBSD)) (envelope-from ) id 1G31M3-0004ni-1W for freebsd-stable@freebsd.org; Wed, 19 Jul 2006 11:00:04 +0900 Message-ID: <44BD9222.5010006@micom.mng.net> Date: Wed, 19 Jul 2006 11:00:02 +0900 From: Ganbold User-Agent: Thunderbird 1.5.0.4 (X11/20060612) MIME-Version: 1.0 To: freebsd-stable@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: bcm4310 wireless in Dell lattitude D620 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jul 2006 02:00:07 -0000 Hi, Does FreeBSD 6.1-STABLE/7.0-CURRENT support Broadcom bcm4310 uart wireless card natively? PCI prob under FreeBSD 6.1-RELEASE: none4@pci12:0:0: class=0x028000 card=0x00071028 chip=0x431214e4 rev=0x01 hdr=0x00 vendor = 'Broadcom Corporation' device = 'BCM4310 UART' class = network If not does anybody make it work by using ndiswrapper? thanks in advance, Ganbold From owner-freebsd-stable@FreeBSD.ORG Wed Jul 19 04:31:20 2006 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A24F816A4E0; Wed, 19 Jul 2006 04:31:20 +0000 (UTC) (envelope-from freebsd@hub.org) Received: from hub.org (hub.org [200.46.204.220]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2935443D45; Wed, 19 Jul 2006 04:31:20 +0000 (GMT) (envelope-from freebsd@hub.org) Received: from localhost (wm.hub.org [200.46.204.128]) by hub.org (Postfix) with ESMTP id 6ED79291B09; Wed, 19 Jul 2006 01:31:18 -0300 (ADT) Received: from hub.org ([200.46.204.220]) by localhost (mx1.hub.org [200.46.204.128]) (amavisd-new, port 10024) with ESMTP id 75339-08; Wed, 19 Jul 2006 04:31:19 +0000 (UTC) Received: from ganymede.hub.org (blk-224-179-167.eastlink.ca [24.224.179.167]) by hub.org (Postfix) with ESMTP id E9EB4290C20; Wed, 19 Jul 2006 01:31:17 -0300 (ADT) Received: by ganymede.hub.org (Postfix, from userid 1027) id 86DDC5C699; Wed, 19 Jul 2006 01:31:17 -0300 (ADT) Received: from localhost (localhost [127.0.0.1]) by ganymede.hub.org (Postfix) with ESMTP id 85AA45C03D; Wed, 19 Jul 2006 01:31:17 -0300 (ADT) Date: Wed, 19 Jul 2006 01:31:17 -0300 (ADT) From: User Freebsd To: Kostik Belousov In-Reply-To: <20060718074804.W1799@ganymede.hub.org> Message-ID: <20060719012941.H1799@ganymede.hub.org> References: <20060705100403.Y80381@fledge.watson.org> <20060705234514.I70011@fledge.watson.org> <20060715000351.U1799@ganymede.hub.org> <20060715035308.GJ32624@deviant.kiev.zoral.com.ua> <20060718074804.W1799@ganymede.hub.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Robert Watson , freebsd-stable@freebsd.org Subject: Re: file system deadlock - the whole story? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jul 2006 04:31:20 -0000 Kostik/Robert ... does this provide enough (any?) information concerning the deadlock situation(s) that are being reported? is there anything else I should do the next time it happens? I tried to submit a GnATs report on this also, but fear that the attachment was a wee bit too big :( On Tue, 18 Jul 2006, User Freebsd wrote: > > 'k, had a bunch of fun tonight, but one of the results is that I was able to > achieve file system deadlock, or so it appears ... > > Using the following from DDB: > > set $lines=0 > show pcpu > show allpcpu > ps > trace > alltrace > show locks > show alllocks > show uma > show malloc > show lockedvnods > call doadump > > I've been able to produce the attached output, as well as have a core dump > that can hopefully be used to gather any that I may have missed this time > *cross fingers* ---- Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email . scrappy@hub.org MSN . scrappy@hub.org Yahoo . yscrappy Skype: hub.org ICQ . 7615664 From owner-freebsd-stable@FreeBSD.ORG Wed Jul 19 05:30:32 2006 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C8F5016A4E1; Wed, 19 Jul 2006 05:30:32 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from fw.zoral.com.ua (fw.zoral.com.ua [213.186.206.134]) by mx1.FreeBSD.org (Postfix) with ESMTP id ED66B43D55; Wed, 19 Jul 2006 05:30:31 +0000 (GMT) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (root@deviant.kiev.zoral.com.ua [10.1.1.148]) by fw.zoral.com.ua (8.13.4/8.13.4) with ESMTP id k6J5UP9k021091 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 19 Jul 2006 08:30:25 +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.13.6/8.13.6) with ESMTP id k6J5UPfV057948; Wed, 19 Jul 2006 08:30:25 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.13.6/8.13.6/Submit) id k6J5UN7k057947; Wed, 19 Jul 2006 08:30:23 +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, 19 Jul 2006 08:30:23 +0300 From: Kostik Belousov To: User Freebsd Message-ID: <20060719053023.GG1464@deviant.kiev.zoral.com.ua> References: <20060705100403.Y80381@fledge.watson.org> <20060705234514.I70011@fledge.watson.org> <20060715000351.U1799@ganymede.hub.org> <20060715035308.GJ32624@deviant.kiev.zoral.com.ua> <20060718074804.W1799@ganymede.hub.org> <20060719012941.H1799@ganymede.hub.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="RDS4xtyBfx+7DiaI" Content-Disposition: inline In-Reply-To: <20060719012941.H1799@ganymede.hub.org> User-Agent: Mutt/1.4.2.1i X-Virus-Scanned: ClamAV version 0.88.2, clamav-milter version 0.88.2 on fw.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=0.4 required=5.0 tests=ALL_TRUSTED, DNS_FROM_RFC_ABUSE,SPF_NEUTRAL autolearn=no version=3.1.3 X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on fw.zoral.com.ua Cc: Robert Watson , freebsd-stable@freebsd.org Subject: Re: file system deadlock - the whole story? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jul 2006 05:30:33 -0000 --RDS4xtyBfx+7DiaI Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Jul 19, 2006 at 01:31:17AM -0300, User Freebsd wrote: >=20 > Kostik/Robert ... does this provide enough (any?) information concerning= =20 > the deadlock situation(s) that are being reported? is there anything els= e=20 > I should do the next time it happens? >=20 > I tried to submit a GnATs report on this also, but fear that the=20 > attachment was a wee bit too big :( >=20 Marc, thank you for the report. It does contain useful information, I'm looking into it. I see at least one obvius deadlock (you shell becomes unresponible when you tried to make auto-completion, right ?). > On Tue, 18 Jul 2006, User Freebsd wrote: >=20 > > > >'k, had a bunch of fun tonight, but one of the results is that I was abl= e=20 > >to achieve file system deadlock, or so it appears ... > > > >Using the following from DDB: > > > >set $lines=3D0 > >show pcpu > >show allpcpu > >ps > >trace > >alltrace > >show locks > >show alllocks > >show uma > >show malloc > >show lockedvnods > >call doadump > > > >I've been able to produce the attached output, as well as have a core du= mp=20 > >that can hopefully be used to gather any that I may have missed this tim= e=20 > >*cross fingers* >=20 > ---- > Marc G. Fournier Hub.Org Networking Services (http://www.hub.or= g) > Email . scrappy@hub.org MSN . scrappy@hub.org > Yahoo . yscrappy Skype: hub.org ICQ . 7615664 --RDS4xtyBfx+7DiaI Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.4 (FreeBSD) iD8DBQFEvcNvC3+MBN1Mb4gRAvOjAKDQ2geVuR4DwtbUq7mPMZMAuQuEKwCgsiv4 Nj8vJIKbw5jTa4dQihByb+E= =FXfY -----END PGP SIGNATURE----- --RDS4xtyBfx+7DiaI-- From owner-freebsd-stable@FreeBSD.ORG Wed Jul 19 11:24:33 2006 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 534FB16A4E5; Wed, 19 Jul 2006 11:24:33 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from fw.zoral.com.ua (fw.zoral.com.ua [213.186.206.134]) by mx1.FreeBSD.org (Postfix) with ESMTP id 62E4B43D49; Wed, 19 Jul 2006 11:24:32 +0000 (GMT) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (root@deviant.kiev.zoral.com.ua [10.1.1.148]) by fw.zoral.com.ua (8.13.4/8.13.4) with ESMTP id k6JBORWi031490 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 19 Jul 2006 14:24: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.13.6/8.13.6) with ESMTP id k6JBORu1029147; Wed, 19 Jul 2006 14:24:27 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.13.6/8.13.6/Submit) id k6JBOOZk029146; Wed, 19 Jul 2006 14:24:24 +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, 19 Jul 2006 14:24:24 +0300 From: Kostik Belousov To: User Freebsd Message-ID: <20060719112424.GK1464@deviant.kiev.zoral.com.ua> References: <20060705100403.Y80381@fledge.watson.org> <20060705234514.I70011@fledge.watson.org> <20060715000351.U1799@ganymede.hub.org> <20060715035308.GJ32624@deviant.kiev.zoral.com.ua> <20060718074804.W1799@ganymede.hub.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="IJAclU0AInkryoed" Content-Disposition: inline In-Reply-To: <20060718074804.W1799@ganymede.hub.org> User-Agent: Mutt/1.4.2.1i X-Virus-Scanned: ClamAV version 0.88.2, clamav-milter version 0.88.2 on fw.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=0.4 required=5.0 tests=ALL_TRUSTED, DNS_FROM_RFC_ABUSE,SPF_NEUTRAL autolearn=no version=3.1.3 X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on fw.zoral.com.ua Cc: freebsd-stable@freebsd.org, Robert Watson Subject: Re: file system deadlock - the whole story? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jul 2006 11:24:33 -0000 --IJAclU0AInkryoed Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Jul 18, 2006 at 07:51:52AM -0300, User Freebsd wrote: >=20 > 'k, had a bunch of fun tonight, but one of the results is that I was able= =20 > to achieve file system deadlock, or so it appears ... >=20 > Using the following from DDB: >=20 > set $lines=3D0 > show pcpu > show allpcpu > ps > trace > alltrace > show locks > show alllocks > show uma > show malloc > show lockedvnods > call doadump >=20 > I've been able to produce the attached output, as well as have a core dum= p=20 > that can hopefully be used to gather any that I may have missed this time= =20 > *cross fingers* Marc, I seriously doubt that the problems machine experiencing is deadlock. At the http://people.freebsd.org/~kib/e1.gif is the graph of the locking dependencies for the vnode locks. The edge from process a to process b means that process a holds a lock and process b is waiting for the lock. Black edge means dependency by the vnode lock, red edge - by the buffer lock. As you see, graph is acyclic. Basically, there are two groups of the processes that a blocked: one hierarchy rooted in the pid 66575, this one includes shell 806. Second one is rooted in the process 32. What are they doing ? Pid 66575: Tracing command smtpd pid 66575 tid 101396 td 0xceb0a180 sched_switch(ceb0a180,0,1) at sched_switch+0x177 mi_switch(1,0) at mi_switch+0x270 sleepq_switch(dc5b5b20,c0661b60,0,c05fd078,20c) at sleepq_switch+0xc1 sleepq_wait(dc5b5b20,0,c0601d10,e59,8) at sleepq_wait+0x46 msleep(dc5b5b20,c06afde0,44,c061021d,0) at msleep+0x279 bwait(dc5b5b20,44,c061021d) at bwait+0x47 vnode_pager_generic_getpages(c8e85000,ed347c80,1000,0,c8e22000) at vnode_pa= ger_generic_getpages+0x777 ffs_getpages(ed347bbc,c8e85000,0,ed347be8,c0597c41) at ffs_getpages+0x100 VOP_GETPAGES_APV(c063c100,ed347bbc) at VOP_GETPAGES_APV+0xa9 vnode_pager_getpages(c8e22000,ed347c80,1,0) at vnode_pager_getpages+0xa5 vm_fault(c88da4a0,280bb000,1,0,ceb0a180) at vm_fault+0x980 trap_pfault(ed347d38,1,280bb000,280bb000,0) at trap_pfault+0xce trap(3b,3b,3b,8078d1c,807952c) at trap+0x1eb calltrap() at calltrap+0x5 --- trap 0xc, eip =3D 0x280baffd, esp =3D 0xbfbfe894, ebp =3D 0xbfbfe8d8 --- This process waits for the data to be paged in. Pid 32 (syncer) Tracing command syncer pid 32 tid 100033 td 0xc8544780 sched_switch(c8544780,0,1) at sched_switch+0x177 mi_switch(1,0) at mi_switch+0x270 sleepq_switch(dc79fe68,c0661b60,0,c05fd078,20c) at sleepq_switch+0xc1 sleepq_wait(dc79fe68,0,c0601d10,e59,c06039a0) at sleepq_wait+0x46 msleep(dc79fe68,c06afde0,4c,c06024dc,0) at msleep+0x279 bwait(dc79fe68,4c,c06024dc) at bwait+0x47 bufwait(dc79fe68,1,0,0,0) at bufwait+0x1a breadn(c8a0b414,6537700,0,4000,0) at breadn+0x266 bread(c8a0b414,6537700,0,4000,0) at bread+0x20 ffs_update(c9992000,0,6,0,0) at ffs_update+0x228 ffs_syncvnode(c9992000,3) at ffs_syncvnode+0x3be ffs_sync(c8831400,3,c8544780,c8831400,2) at ffs_sync+0x209 sync_fsync(e817fcbc,c8a11ae0,c8a11bec,e817fcd8,c04ed586) at sync_fsync+0x126 VOP_FSYNC_APV(c0634220,e817fcbc) at VOP_FSYNC_APV+0x9b sync_vnode(c8a11bec,c8544780) at sync_vnode+0x106 sched_sync(0,e817fd38,0,c04ed614,0) at sched_sync+0x1ed fork_exit(c04ed614,0,e817fd38) at fork_exit+0xa0 fork_trampoline() at fork_trampoline+0x8 --- trap 0x1, eip =3D 0, esp =3D 0xe817fd6c, ebp =3D 0 --- also waits for the data. What happens with blocks ? syncer (pid 32) locked block 0xc8a0b414 and waits for data (as shown before= ). Processes 33 (softdepflush), umount (pid 73338) waits for this block. You did not provided the output of "show lockedbufs", but, even without that data, I doubt that the buf subsystem deadlocked by itself. I make an conjecture that the problem is either with you disk hardware (i.e= ., actual hard drive or disk controller), or in the controller driver. At least, you could show us the dmesg. --IJAclU0AInkryoed Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.4 (FreeBSD) iD8DBQFEvhZnC3+MBN1Mb4gRAkBOAJ9PRADeaDsO6B4ugtqBgZrrsckMpACfRmnv JEX9eaQqtjmB2VRA0HsdV/Y= =pgP4 -----END PGP SIGNATURE----- --IJAclU0AInkryoed-- From owner-freebsd-stable@FreeBSD.ORG Wed Jul 19 11:25:27 2006 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D484516A4E0; Wed, 19 Jul 2006 11:25:27 +0000 (UTC) (envelope-from freebsd@hub.org) Received: from hub.org (hub.org [200.46.204.220]) by mx1.FreeBSD.org (Postfix) with ESMTP id 82D7B43D4C; Wed, 19 Jul 2006 11:25:26 +0000 (GMT) (envelope-from freebsd@hub.org) Received: from localhost (wm.hub.org [200.46.204.128]) by hub.org (Postfix) with ESMTP id A8735291B0A; Wed, 19 Jul 2006 08:25:21 -0300 (ADT) Received: from hub.org ([200.46.204.220]) by localhost (mx1.hub.org [200.46.204.128]) (amavisd-new, port 10024) with ESMTP id 44351-05; Wed, 19 Jul 2006 11:25:26 +0000 (UTC) Received: from ganymede.hub.org (blk-224-179-167.eastlink.ca [24.224.179.167]) by hub.org (Postfix) with ESMTP id 3B2DB291B09; Wed, 19 Jul 2006 08:25:21 -0300 (ADT) Received: by ganymede.hub.org (Postfix, from userid 1027) id E05445D4E5; Wed, 19 Jul 2006 08:25:28 -0300 (ADT) Received: from localhost (localhost [127.0.0.1]) by ganymede.hub.org (Postfix) with ESMTP id DF48A5D4D9; Wed, 19 Jul 2006 08:25:28 -0300 (ADT) Date: Wed, 19 Jul 2006 08:25:28 -0300 (ADT) From: User Freebsd To: Kostik Belousov In-Reply-To: <20060719053023.GG1464@deviant.kiev.zoral.com.ua> Message-ID: <20060719082450.P1799@ganymede.hub.org> References: <20060705100403.Y80381@fledge.watson.org> <20060705234514.I70011@fledge.watson.org> <20060715000351.U1799@ganymede.hub.org> <20060715035308.GJ32624@deviant.kiev.zoral.com.ua> <20060718074804.W1799@ganymede.hub.org> <20060719012941.H1799@ganymede.hub.org> <20060719053023.GG1464@deviant.kiev.zoral.com.ua> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Robert Watson , freebsd-stable@freebsd.org Subject: Re: file system deadlock - the whole story? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jul 2006 11:25:27 -0000 On Wed, 19 Jul 2006, Kostik Belousov wrote: > On Wed, Jul 19, 2006 at 01:31:17AM -0300, User Freebsd wrote: >> >> Kostik/Robert ... does this provide enough (any?) information concerning >> the deadlock situation(s) that are being reported? is there anything else >> I should do the next time it happens? >> >> I tried to submit a GnATs report on this also, but fear that the >> attachment was a wee bit too big :( >> > Marc, > thank you for the report. It does contain useful information, I'm looking > into it. > > I see at least one obvius deadlock (you shell becomes unresponible when > you tried to make auto-completion, right ?). Yup, that was when I first noticed it this time through, actually ... > >> On Tue, 18 Jul 2006, User Freebsd wrote: >> >>> >>> 'k, had a bunch of fun tonight, but one of the results is that I was able >>> to achieve file system deadlock, or so it appears ... >>> >>> Using the following from DDB: >>> >>> set $lines=0 >>> show pcpu >>> show allpcpu >>> ps >>> trace >>> alltrace >>> show locks >>> show alllocks >>> show uma >>> show malloc >>> show lockedvnods >>> call doadump >>> >>> I've been able to produce the attached output, as well as have a core dump >>> that can hopefully be used to gather any that I may have missed this time >>> *cross fingers* >> >> ---- >> Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) >> Email . scrappy@hub.org MSN . scrappy@hub.org >> Yahoo . yscrappy Skype: hub.org ICQ . 7615664 > ---- Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email . scrappy@hub.org MSN . scrappy@hub.org Yahoo . yscrappy Skype: hub.org ICQ . 7615664 From owner-freebsd-stable@FreeBSD.ORG Wed Jul 19 11:30:47 2006 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 801D616A4DF for ; Wed, 19 Jul 2006 11:30:47 +0000 (UTC) (envelope-from MH@kernel32.de) Received: from crivens.terrorteam.de (crivens.terrorteam.de [81.169.171.191]) by mx1.FreeBSD.org (Postfix) with ESMTP id AFC0143D4C for ; Wed, 19 Jul 2006 11:30:46 +0000 (GMT) (envelope-from MH@kernel32.de) Received: from localhost (localhost [127.0.0.1]) by crivens.terrorteam.de (Postfix) with ESMTP id E4B394395 for ; Wed, 19 Jul 2006 13:33:41 +0200 (CEST) X-Virus-Scanned: amavisd-new at unixoid.de Received: from crivens.terrorteam.de ([127.0.0.1]) by localhost (crivens.unixoid.de [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZL6++d+4VJnA for ; Wed, 19 Jul 2006 13:33:38 +0200 (CEST) Received: from [10.38.0.12] (unknown [213.238.63.253]) by crivens.terrorteam.de (Postfix) with ESMTP id 7485F431E for ; Wed, 19 Jul 2006 13:33:38 +0200 (CEST) Message-ID: <44BE17E2.6040203@kernel32.de> Date: Wed, 19 Jul 2006 13:30:42 +0200 From: Marian Hettwer User-Agent: Mozilla Thunderbird 1.0.2 (Macintosh/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: freebsd-stable X-Enigmail-Version: 0.93.0.0 Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 7bit Subject: Panic on 6.1 (panic: vm_fault: fault on nofault entry, addr: d6f3c0000:32) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jul 2006 11:30:47 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hej Ho, for quite a while my server (root server / dedicated server) goes completely dead - sometimes after several weeks, sometimes after 24h hours. I always thought it's the hosting company and not FreeBSD, but today I could see the panic. Looks like that: root@crivens:/root# panic: vm_fault: fault on nofault entry, addr: d6f3c0000:32 Uptime: 3h41m52s Cannot dump. No dump device defined. Automatic reboot in 15 seconds - press a key on the console to abort Rebooting... Unluckily it's not rebooting automatically... Any idea what the cause of this panic could be? And why it's not rebooting at all? Hm... Some more informations: ([rabauke@crivens] <~>)$ uname -a FreeBSD crivens.terrorteam.de 6.1-PRERELEASE FreeBSD 6.1-PRERELEASE #1: Tue Apr 11 14:58:58 CEST 2006 root@crivens.terrorteam.de:/usr/obj/usr/src/sys/CRIVENS i386 I'm actually updating to 6.1-STABLE as of yesterday. Kernel Config: http://crivens.terrorteam.de/~rabauke/FreeBSD/CRIVENS Any help is greatly appreciated. TIA, Marian -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (Darwin) iD8DBQFEvhfggAq87Uq5FMsRAiA1AJ9Kw2ZUlIwPSuPoBD90A16uUdzTLwCeNFnT O0/SYrykCIUXKOzx3CrOmjo= =j1FY -----END PGP SIGNATURE----- From owner-freebsd-stable@FreeBSD.ORG Wed Jul 19 14:11:43 2006 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7C22616A4DF; Wed, 19 Jul 2006 14:11:43 +0000 (UTC) (envelope-from freebsd@hub.org) Received: from hub.org (hub.org [200.46.204.220]) by mx1.FreeBSD.org (Postfix) with ESMTP id F337F43D49; Wed, 19 Jul 2006 14:11:42 +0000 (GMT) (envelope-from freebsd@hub.org) Received: from localhost (wm.hub.org [200.46.204.128]) by hub.org (Postfix) with ESMTP id 6CE11291B09; Wed, 19 Jul 2006 11:11:36 -0300 (ADT) Received: from hub.org ([200.46.204.220]) by localhost (mx1.hub.org [200.46.204.128]) (amavisd-new, port 10024) with ESMTP id 69607-03; Wed, 19 Jul 2006 14:11:42 +0000 (UTC) Received: from ganymede.hub.org (blk-224-179-167.eastlink.ca [24.224.179.167]) by hub.org (Postfix) with ESMTP id D6B63290C1F; Wed, 19 Jul 2006 11:11:35 -0300 (ADT) Received: by ganymede.hub.org (Postfix, from userid 1027) id DC7805D650; Wed, 19 Jul 2006 11:11:46 -0300 (ADT) Received: from localhost (localhost [127.0.0.1]) by ganymede.hub.org (Postfix) with ESMTP id DB6765D46B; Wed, 19 Jul 2006 11:11:46 -0300 (ADT) Date: Wed, 19 Jul 2006 11:11:46 -0300 (ADT) From: User Freebsd To: Kostik Belousov In-Reply-To: <20060719112424.GK1464@deviant.kiev.zoral.com.ua> Message-ID: <20060719082627.H1799@ganymede.hub.org> References: <20060705100403.Y80381@fledge.watson.org> <20060705234514.I70011@fledge.watson.org> <20060715000351.U1799@ganymede.hub.org> <20060715035308.GJ32624@deviant.kiev.zoral.com.ua> <20060718074804.W1799@ganymede.hub.org> <20060719112424.GK1464@deviant.kiev.zoral.com.ua> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-stable@freebsd.org, Robert Watson Subject: Re: file system deadlock - the whole story? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jul 2006 14:11:43 -0000 On Wed, 19 Jul 2006, Kostik Belousov wrote: > You did not provided the output of "show lockedbufs", Added to my debug list ... > but, even without that data, I doubt that the buf subsystem deadlocked by > itself. > > I make an conjecture that the problem is either with you disk hardware (i.e., > actual hard drive or disk controller), or in the controller driver. The problem that I have with this theory is that it isn't just one server doing this, or one type of hardware ... all three of the servers that I've upgraded to FreeBSD 6.x are doing it at some point or another ... I'm just getting jupiter (older Dual-PIII server) rebooted now :( Also note that under FreeBSD 4.x, all three of these machines were pretty much my more solid machines, with even more vServers running on them then I'm able to run with 6.x ... once I got rid of using unionfs, stability skyrocketed :( Hrmmmm ... but, your 'controller driver' comment ... that is one common thing amongst all three servers ... they are all running the iir driver ... not sure the *exact* controller, but pluto (older Dual-PIII) shows it as: iir0: mem 0xfc8f0000-0xfc8f3fff irq 30 at device 9.0 on pci1 iir0: [GIANT-LOCKED] Beyond that controller, jupiter/pluto are Dual-PIII with 36G Seagate drives, uranus is a Dual-Xeon with 72G Seagate drives ... > At least, you could show us the dmesg. I'll have to get that for you after next reboot, as /var/run/dmesg.boot shows: uranus# less /var/run/dmesg.boot WARNING: /tmp was not properly dismounted WARNING: /usr was not properly dismounted WARNING: /var was not properly dismounted And that's it :( ---- Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email . scrappy@hub.org MSN . scrappy@hub.org Yahoo . yscrappy Skype: hub.org ICQ . 7615664 From owner-freebsd-stable@FreeBSD.ORG Wed Jul 19 14:14:54 2006 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2241216A4DF for ; Wed, 19 Jul 2006 14:14:54 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [209.31.154.42]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8F85143D4C for ; Wed, 19 Jul 2006 14:14:53 +0000 (GMT) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [209.31.154.41]) by cyrus.watson.org (Postfix) with ESMTP id 4881146BDC; Wed, 19 Jul 2006 10:14:51 -0400 (EDT) Date: Wed, 19 Jul 2006 15:14:51 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: User Freebsd In-Reply-To: <20060719082627.H1799@ganymede.hub.org> Message-ID: <20060719151327.H5132@fledge.watson.org> References: <20060705100403.Y80381@fledge.watson.org> <20060705234514.I70011@fledge.watson.org> <20060715000351.U1799@ganymede.hub.org> <20060715035308.GJ32624@deviant.kiev.zoral.com.ua> <20060718074804.W1799@ganymede.hub.org> <20060719112424.GK1464@deviant.kiev.zoral.com.ua> <20060719082627.H1799@ganymede.hub.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Kostik Belousov , freebsd-stable@freebsd.org Subject: Re: file system deadlock - the whole story? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jul 2006 14:14:54 -0000 On Wed, 19 Jul 2006, User Freebsd wrote: > Also note that under FreeBSD 4.x, all three of these machines were pretty > much my more solid machines, with even more vServers running on them then > I'm able to run with 6.x ... once I got rid of using unionfs, stability > skyrocketed :( > > Hrmmmm ... but, your 'controller driver' comment ... that is one common > thing amongst all three servers ... they are all running the iir driver ... > not sure the *exact* controller, but pluto (older Dual-PIII) shows it as: Yes, this was going to be my next question -- if you're seeing wedges under load and there's a common controller in use, maybe we're looking at a driver bug. Bugs of those sort typically look a lot like what you describe: an I/O is "lost" and so eveything that depends on the I/O wedges waiting for it, leading to a lot of processes hanging around waiting for vnode locks, etc. Robert N M Watson Computer Laboratory University of Cambridge From owner-freebsd-stable@FreeBSD.ORG Wed Jul 19 14:23:18 2006 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2E18E16A4DF; Wed, 19 Jul 2006 14:23:18 +0000 (UTC) (envelope-from freebsd@hub.org) Received: from hub.org (hub.org [200.46.204.220]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9FD9C43D5C; Wed, 19 Jul 2006 14:23:17 +0000 (GMT) (envelope-from freebsd@hub.org) Received: from localhost (wm.hub.org [200.46.204.128]) by hub.org (Postfix) with ESMTP id 0B2E0291B0B; Wed, 19 Jul 2006 11:23:11 -0300 (ADT) Received: from hub.org ([200.46.204.220]) by localhost (mx1.hub.org [200.46.204.128]) (amavisd-new, port 10024) with ESMTP id 69607-08; Wed, 19 Jul 2006 14:23:17 +0000 (UTC) Received: from ganymede.hub.org (blk-224-179-167.eastlink.ca [24.224.179.167]) by hub.org (Postfix) with ESMTP id 83BE2291B0A; Wed, 19 Jul 2006 11:23:10 -0300 (ADT) Received: by ganymede.hub.org (Postfix, from userid 1027) id 0D8D95D15B; Wed, 19 Jul 2006 11:23:22 -0300 (ADT) Received: from localhost (localhost [127.0.0.1]) by ganymede.hub.org (Postfix) with ESMTP id 0700C4AAD1; Wed, 19 Jul 2006 11:23:22 -0300 (ADT) Date: Wed, 19 Jul 2006 11:23:21 -0300 (ADT) From: User Freebsd To: Robert Watson In-Reply-To: <20060719151327.H5132@fledge.watson.org> Message-ID: <20060719112208.Y1799@ganymede.hub.org> References: <20060705100403.Y80381@fledge.watson.org> <20060705234514.I70011@fledge.watson.org> <20060715000351.U1799@ganymede.hub.org> <20060715035308.GJ32624@deviant.kiev.zoral.com.ua> <20060718074804.W1799@ganymede.hub.org> <20060719112424.GK1464@deviant.kiev.zoral.com.ua> <20060719082627.H1799@ganymede.hub.org> <20060719151327.H5132@fledge.watson.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Kostik Belousov , freebsd-stable@freebsd.org Subject: Re: file system deadlock - the whole story? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jul 2006 14:23:18 -0000 On Wed, 19 Jul 2006, Robert Watson wrote: > > On Wed, 19 Jul 2006, User Freebsd wrote: > >> Also note that under FreeBSD 4.x, all three of these machines were pretty >> much my more solid machines, with even more vServers running on them then >> I'm able to run with 6.x ... once I got rid of using unionfs, stability >> skyrocketed :( >> >> Hrmmmm ... but, your 'controller driver' comment ... that is one common >> thing amongst all three servers ... they are all running the iir driver ... >> not sure the *exact* controller, but pluto (older Dual-PIII) shows it as: > > Yes, this was going to be my next question -- if you're seeing wedges under > load and there's a common controller in use, maybe we're looking at a driver > bug. Bugs of those sort typically look a lot like what you describe: an I/O > is "lost" and so eveything that depends on the I/O wedges waiting for it, > leading to a lot of processes hanging around waiting for vnode locks, etc. 'k, but how do we debug *that*? :( If it was one, I'd suspect hardware ... but *three*, and only acting up *after* upgrading to FreeBSD 6.x, and only acting up under load ... ---- Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email . scrappy@hub.org MSN . scrappy@hub.org Yahoo . yscrappy Skype: hub.org ICQ . 7615664 From owner-freebsd-stable@FreeBSD.ORG Wed Jul 19 14:43:20 2006 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4442A16A4DA; Wed, 19 Jul 2006 14:43:20 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from fw.zoral.com.ua (fw.zoral.com.ua [213.186.206.134]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3CE1D43D5A; Wed, 19 Jul 2006 14:43:14 +0000 (GMT) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (root@deviant.kiev.zoral.com.ua [10.1.1.148]) by fw.zoral.com.ua (8.13.4/8.13.4) with ESMTP id k6JEh6Mw037258 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 19 Jul 2006 17:43:06 +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.13.6/8.13.6) with ESMTP id k6JEh6af032818; Wed, 19 Jul 2006 17:43:06 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.13.6/8.13.6/Submit) id k6JEh5kQ032817; Wed, 19 Jul 2006 17:43:05 +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, 19 Jul 2006 17:43:05 +0300 From: Kostik Belousov To: User Freebsd Message-ID: <20060719144305.GM1464@deviant.kiev.zoral.com.ua> References: <20060705100403.Y80381@fledge.watson.org> <20060705234514.I70011@fledge.watson.org> <20060715000351.U1799@ganymede.hub.org> <20060715035308.GJ32624@deviant.kiev.zoral.com.ua> <20060718074804.W1799@ganymede.hub.org> <20060719112424.GK1464@deviant.kiev.zoral.com.ua> <20060719082627.H1799@ganymede.hub.org> <20060719151327.H5132@fledge.watson.org> <20060719112208.Y1799@ganymede.hub.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="j3zO+32zXj6UcJCE" Content-Disposition: inline In-Reply-To: <20060719112208.Y1799@ganymede.hub.org> User-Agent: Mutt/1.4.2.1i X-Virus-Scanned: ClamAV version 0.88.2, clamav-milter version 0.88.2 on fw.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=0.4 required=5.0 tests=ALL_TRUSTED, DNS_FROM_RFC_ABUSE,SPF_NEUTRAL autolearn=no version=3.1.3 X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on fw.zoral.com.ua Cc: freebsd-stable@freebsd.org, Robert Watson Subject: Re: file system deadlock - the whole story? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jul 2006 14:43:20 -0000 --j3zO+32zXj6UcJCE Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Jul 19, 2006 at 11:23:21AM -0300, User Freebsd wrote: > On Wed, 19 Jul 2006, Robert Watson wrote: >=20 > > > >On Wed, 19 Jul 2006, User Freebsd wrote: > > > >>Also note that under FreeBSD 4.x, all three of these machines were pret= ty=20 > >>much my more solid machines, with even more vServers running on them th= en=20 > >>I'm able to run with 6.x ... once I got rid of using unionfs, stability= =20 > >>skyrocketed :( > >> > >>Hrmmmm ... but, your 'controller driver' comment ... that is one common= =20 > >>thing amongst all three servers ... they are all running the iir driver= =20 > >>... not sure the *exact* controller, but pluto (older Dual-PIII) shows = it=20 > >>as: > > > >Yes, this was going to be my next question -- if you're seeing wedges=20 > >under load and there's a common controller in use, maybe we're looking a= t=20 > >a driver bug. Bugs of those sort typically look a lot like what you=20 > >describe: an I/O is "lost" and so eveything that depends on the I/O wedg= es=20 > >waiting for it, leading to a lot of processes hanging around waiting for= =20 > >vnode locks, etc. >=20 > 'k, but how do we debug *that*? :( If it was one, I'd suspect hardware= =20 > ... but *three*, and only acting up *after* upgrading to FreeBSD 6.x, and= =20 > only acting up under load ... Obvious step would be to replace controller by some different kind. --j3zO+32zXj6UcJCE Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.4 (FreeBSD) iD8DBQFEvkT5C3+MBN1Mb4gRAkNDAKCZORLzP9p4pyUCwPjj///jfwGC7ACg5UCP bGGFe0/owbW1Z5J1eN26Gbs= =2gY6 -----END PGP SIGNATURE----- --j3zO+32zXj6UcJCE-- From owner-freebsd-stable@FreeBSD.ORG Wed Jul 19 14:46:54 2006 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8834D16A4EB for ; Wed, 19 Jul 2006 14:46:54 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [209.31.154.42]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1207243D8C for ; Wed, 19 Jul 2006 14:46:50 +0000 (GMT) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [209.31.154.41]) by cyrus.watson.org (Postfix) with ESMTP id EED4546C7E; Wed, 19 Jul 2006 10:46:46 -0400 (EDT) Date: Wed, 19 Jul 2006 15:46:46 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: User Freebsd In-Reply-To: <20060719112208.Y1799@ganymede.hub.org> Message-ID: <20060719154447.K5132@fledge.watson.org> References: <20060705100403.Y80381@fledge.watson.org> <20060705234514.I70011@fledge.watson.org> <20060715000351.U1799@ganymede.hub.org> <20060715035308.GJ32624@deviant.kiev.zoral.com.ua> <20060718074804.W1799@ganymede.hub.org> <20060719112424.GK1464@deviant.kiev.zoral.com.ua> <20060719082627.H1799@ganymede.hub.org> <20060719151327.H5132@fledge.watson.org> <20060719112208.Y1799@ganymede.hub.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Kostik Belousov , freebsd-stable@freebsd.org Subject: Re: file system deadlock - the whole story? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jul 2006 14:46:54 -0000 On Wed, 19 Jul 2006, User Freebsd wrote: >> Yes, this was going to be my next question -- if you're seeing wedges under >> load and there's a common controller in use, maybe we're looking at a >> driver bug. Bugs of those sort typically look a lot like what you >> describe: an I/O is "lost" and so eveything that depends on the I/O wedges >> waiting for it, leading to a lot of processes hanging around waiting for >> vnode locks, etc. > > 'k, but how do we debug *that*? :( If it was one, I'd suspect hardware ... > but *three*, and only acting up *after* upgrading to FreeBSD 6.x, and only > acting up under load ... There are two normal approaches: (1) Switch controllers and see if the problem goes away, then blame the controller that was replaced. :-) (2) Debug the driver when the system is in the wedged state. When Scott Long helped me out with an identical problem with the 3ware driver a few years ago, he basically added debugging output for the driver in the debugger to list the state of outstanding I/Os, count the number of in-bound, out-bound I/Os, etc, to try and find where the missing one was leaked. My impression is that once he had confirmed the presence of the problem, it was fairly easy to fix, but that confirming it required quite a bit of paperwork. Robert N M Watson Computer Laboratory University of Cambridge From owner-freebsd-stable@FreeBSD.ORG Wed Jul 19 14:49:15 2006 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 345D716A4E2; Wed, 19 Jul 2006 14:49:15 +0000 (UTC) (envelope-from freebsd@hub.org) Received: from hub.org (hub.org [200.46.204.220]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0C7D843D67; Wed, 19 Jul 2006 14:49:06 +0000 (GMT) (envelope-from freebsd@hub.org) Received: from localhost (mx1.hub.org [200.46.208.251]) by hub.org (Postfix) with ESMTP id 17858291B0A; Wed, 19 Jul 2006 11:49:00 -0300 (ADT) Received: from hub.org ([200.46.204.220]) by localhost (mx1.hub.org [200.46.208.251]) (amavisd-new, port 10024) with ESMTP id 15275-03; Wed, 19 Jul 2006 11:49:06 -0300 (ADT) Received: from ganymede.hub.org (blk-224-179-167.eastlink.ca [24.224.179.167]) by hub.org (Postfix) with ESMTP id 8489E291B09; Wed, 19 Jul 2006 11:48:59 -0300 (ADT) Received: by ganymede.hub.org (Postfix, from userid 1027) id 7B0A34AB13; Wed, 19 Jul 2006 11:49:11 -0300 (ADT) Received: from localhost (localhost [127.0.0.1]) by ganymede.hub.org (Postfix) with ESMTP id 750F34AADF; Wed, 19 Jul 2006 11:49:11 -0300 (ADT) Date: Wed, 19 Jul 2006 11:49:11 -0300 (ADT) From: User Freebsd To: Kostik Belousov In-Reply-To: <20060719144305.GM1464@deviant.kiev.zoral.com.ua> Message-ID: <20060719114751.X1799@ganymede.hub.org> References: <20060705100403.Y80381@fledge.watson.org> <20060705234514.I70011@fledge.watson.org> <20060715000351.U1799@ganymede.hub.org> <20060715035308.GJ32624@deviant.kiev.zoral.com.ua> <20060718074804.W1799@ganymede.hub.org> <20060719112424.GK1464@deviant.kiev.zoral.com.ua> <20060719082627.H1799@ganymede.hub.org> <20060719151327.H5132@fledge.watson.org> <20060719112208.Y1799@ganymede.hub.org> <20060719144305.GM1464@deviant.kiev.zoral.com.ua> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-stable@freebsd.org, Robert Watson Subject: Re: file system deadlock - the whole story? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jul 2006 14:49:15 -0000 On Wed, 19 Jul 2006, Kostik Belousov wrote: > On Wed, Jul 19, 2006 at 11:23:21AM -0300, User Freebsd wrote: >> On Wed, 19 Jul 2006, Robert Watson wrote: >> >>> >>> On Wed, 19 Jul 2006, User Freebsd wrote: >>> >>>> Also note that under FreeBSD 4.x, all three of these machines were pretty >>>> much my more solid machines, with even more vServers running on them then >>>> I'm able to run with 6.x ... once I got rid of using unionfs, stability >>>> skyrocketed :( >>>> >>>> Hrmmmm ... but, your 'controller driver' comment ... that is one common >>>> thing amongst all three servers ... they are all running the iir driver >>>> ... not sure the *exact* controller, but pluto (older Dual-PIII) shows it >>>> as: >>> >>> Yes, this was going to be my next question -- if you're seeing wedges >>> under load and there's a common controller in use, maybe we're looking at >>> a driver bug. Bugs of those sort typically look a lot like what you >>> describe: an I/O is "lost" and so eveything that depends on the I/O wedges >>> waiting for it, leading to a lot of processes hanging around waiting for >>> vnode locks, etc. >> >> 'k, but how do we debug *that*? :( If it was one, I'd suspect hardware >> ... but *three*, and only acting up *after* upgrading to FreeBSD 6.x, and >> only acting up under load ... > > Obvious step would be to replace controller by some different kind. Unfortunately, that one isn't an option ... these aren't local machines that I can easily swap hardware in :( ---- Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email . scrappy@hub.org MSN . scrappy@hub.org Yahoo . yscrappy Skype: hub.org ICQ . 7615664 From owner-freebsd-stable@FreeBSD.ORG Wed Jul 19 15:04:13 2006 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1A92416A4DE; Wed, 19 Jul 2006 15:04:13 +0000 (UTC) (envelope-from freebsd@hub.org) Received: from hub.org (hub.org [200.46.204.220]) by mx1.FreeBSD.org (Postfix) with ESMTP id 481CA43D62; Wed, 19 Jul 2006 15:04:04 +0000 (GMT) (envelope-from freebsd@hub.org) Received: from localhost (mx1.hub.org [200.46.208.251]) by hub.org (Postfix) with ESMTP id 75ED7291B09; Wed, 19 Jul 2006 12:04:03 -0300 (ADT) Received: from hub.org ([200.46.204.220]) by localhost (mx1.hub.org [200.46.208.251]) (amavisd-new, port 10024) with ESMTP id 14919-06; Wed, 19 Jul 2006 12:04:03 -0300 (ADT) Received: from ganymede.hub.org (blk-224-179-167.eastlink.ca [24.224.179.167]) by hub.org (Postfix) with ESMTP id EB162290C31; Wed, 19 Jul 2006 12:04:02 -0300 (ADT) Received: by ganymede.hub.org (Postfix, from userid 1027) id 7F0B25D402; Wed, 19 Jul 2006 12:04:01 -0300 (ADT) Received: from localhost (localhost [127.0.0.1]) by ganymede.hub.org (Postfix) with ESMTP id 77B954AADF; Wed, 19 Jul 2006 12:04:01 -0300 (ADT) Date: Wed, 19 Jul 2006 12:04:01 -0300 (ADT) From: User Freebsd To: Robert Watson In-Reply-To: <20060719154447.K5132@fledge.watson.org> Message-ID: <20060719115948.M1799@ganymede.hub.org> References: <20060705100403.Y80381@fledge.watson.org> <20060705234514.I70011@fledge.watson.org> <20060715000351.U1799@ganymede.hub.org> <20060715035308.GJ32624@deviant.kiev.zoral.com.ua> <20060718074804.W1799@ganymede.hub.org> <20060719112424.GK1464@deviant.kiev.zoral.com.ua> <20060719082627.H1799@ganymede.hub.org> <20060719151327.H5132@fledge.watson.org> <20060719112208.Y1799@ganymede.hub.org> <20060719154447.K5132@fledge.watson.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Kostik Belousov , Achim_Leubner@adaptec.com, freebsd-stable@freebsd.org Subject: Re: file system deadlock - the whole story? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jul 2006 15:04:13 -0000 On Wed, 19 Jul 2006, Robert Watson wrote: > On Wed, 19 Jul 2006, User Freebsd wrote: > >>> Yes, this was going to be my next question -- if you're seeing wedges >>> under load and there's a common controller in use, maybe we're looking at >>> a driver bug. Bugs of those sort typically look a lot like what you >>> describe: an I/O is "lost" and so eveything that depends on the I/O wedges >>> waiting for it, leading to a lot of processes hanging around waiting for >>> vnode locks, etc. >> >> 'k, but how do we debug *that*? :( If it was one, I'd suspect hardware ... >> but *three*, and only acting up *after* upgrading to FreeBSD 6.x, and only >> acting up under load ... > > There are two normal approaches: > > (1) Switch controllers and see if the problem goes away, then blame the > controller that was replaced. :-) > > (2) Debug the driver when the system is in the wedged state. When Scott Long > helped me out with an identical problem with the 3ware driver a few years > ago, he basically added debugging output for the driver in the debugger > to > list the state of outstanding I/Os, count the number of in-bound, > out-bound I/Os, etc, to try and find where the missing one was leaked. > My > impression is that once he had confirmed the presence of the problem, it > was fairly easy to fix, but that confirming it required quite a bit of > paperwork. 'k, first question is with the core file provide any insight into this? ie. provide further confirmation that it looks like the driver vs file system? second question, who is currently maintaining the iir driver? I've CC'd Achim in this, as he's listed in the man page as being the maintainer ... Now, uranus has all the various kernel debugging enabled right now, and a serial console, so we're good for the debugging side of things ... and I believe that I can fairly easily "recreate" the issue by just moving a whack of vServers onto that machine to give it the load that seems to kill it ... *and* uranus is one of my newer machines, so the card that is in it is fairly new ... but, since I have a full BIOS serial console working on it, I should be able to get full model # and firmware version, which I take it will help some? ---- Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email . scrappy@hub.org MSN . scrappy@hub.org Yahoo . yscrappy Skype: hub.org ICQ . 7615664 From owner-freebsd-stable@FreeBSD.ORG Wed Jul 19 15:26:25 2006 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9ABD016A4DE for ; Wed, 19 Jul 2006 15:26:25 +0000 (UTC) (envelope-from vinny@tellurian.com) Received: from mail1.tellurian.net (mail1.tellurian.net [216.182.1.23]) by mx1.FreeBSD.org (Postfix) with ESMTP id D944443D46 for ; Wed, 19 Jul 2006 15:26:21 +0000 (GMT) (envelope-from vinny@tellurian.com) Received: from cactus.tellurian.com (cactus.tellurian.net [216.182.1.34]) by mail1.tellurian.net ([216.182.1.23] Tellurian Networks Mail Server version 3.7c-30) with ESMTP id 443707832 for multiple; Wed, 19 Jul 2006 11:26:21 -0400 Message-Id: <7.0.1.0.2.20060719112609.0abfb010@tellurian.com> X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0 Date: Wed, 19 Jul 2006 11:26:19 -0400 To: Martin Blapp ,David Wolfskill From: Vinny Abello In-Reply-To: <20060718161104.X36995@godot.imp.ch> References: <20060718152306.X36995@godot.imp.ch> <20060718155642.H36995@godot.imp.ch> <20060718140707.GG66891@bunrab.catwhisker.org> <20060718161104.X36995@godot.imp.ch> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Authenticated-User: vinny@tellurian.com X-Ultimate-Internet-Connection: Tellurian Networks Cc: freebsd-stable@freebsd.org Subject: Re: Please confirm: top(1) cpu time broken on FreeBSD 6.1 (RELEASE/STABLE) SMP ? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jul 2006 15:26:25 -0000 Disable hyperthreading in your BIOS. At 10:20 AM 7/18/2006, Martin Blapp wrote: >Hi, > >Ok, seems to be a HTT issue on a untuned system. > >On two boxes I get with 'sysctl -a | grep smp | grep kern.smp.cpus' >kern.smp.cpus: 4 > >Here I see CPU-IDs 0 and 2 in top. No other CPUs seem to be >used. Here I get the broken CPU usage. > >And yes, seeting hyperthreading_allowed=1 corrects the top usage. > >On two other boxes where it works I get 'sysctl -a | grep smp | grep >kern.smp.cpus' kern.smp.cpus: 2 > >Here I see CPU-ID's 0 and 1 in top. Here everything works as it should. > >Martin > >Martin Blapp, >------------------------------------------------------------------ >ImproWare AG, UNIXSP & ISP, Zurlindenstrasse 29, 4133 Pratteln, CH >Phone: +41 61 826 93 00 Fax: +41 61 826 93 01 >PGP: >PGP Fingerprint: B434 53FC C87C FE7B 0A18 B84C 8686 EF22 D300 551E >------------------------------------------------------------------ > >_______________________________________________ >freebsd-stable@freebsd.org mailing list >http://lists.freebsd.org/mailman/listinfo/freebsd-stable >To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" Vinny Abello Network Engineer Server Management vinny@tellurian.com (973)300-9211 x 125 (973)940-6125 (Direct) PGP Key Fingerprint: 3BC5 9A48 FC78 03D3 82E0 E935 5325 FBCB 0100 977A Tellurian Networks - The Ultimate Internet Connection http://www.tellurian.com (888)TELLURIAN "Courage is resistance to fear, mastery of fear - not absence of fear" -- Mark Twain From owner-freebsd-stable@FreeBSD.ORG Wed Jul 19 15:27:25 2006 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 68A6716A4DD; Wed, 19 Jul 2006 15:27:25 +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 1A8C843D8B; Wed, 19 Jul 2006 15:27:18 +0000 (GMT) (envelope-from scottl@samsco.org) Received: from [10.10.3.185] ([165.236.175.187]) (authenticated bits=0) by pooker.samsco.org (8.13.4/8.13.4) with ESMTP id k6JFR3Up008427; Wed, 19 Jul 2006 09:27:09 -0600 (MDT) (envelope-from scottl@samsco.org) Message-ID: <44BE4F31.9020606@samsco.org> Date: Wed, 19 Jul 2006 09:26:41 -0600 From: Scott Long User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.12) Gecko/20060206 X-Accept-Language: en-us, en MIME-Version: 1.0 To: User Freebsd References: <20060705100403.Y80381@fledge.watson.org> <20060705234514.I70011@fledge.watson.org> <20060715000351.U1799@ganymede.hub.org> <20060715035308.GJ32624@deviant.kiev.zoral.com.ua> <20060718074804.W1799@ganymede.hub.org> <20060719112424.GK1464@deviant.kiev.zoral.com.ua> <20060719082627.H1799@ganymede.hub.org> <20060719151327.H5132@fledge.watson.org> <20060719112208.Y1799@ganymede.hub.org> <20060719154447.K5132@fledge.watson.org> <20060719115948.M1799@ganymede.hub.org> In-Reply-To: <20060719115948.M1799@ganymede.hub.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=0.0 required=3.8 tests=none autolearn=failed version=3.1.1 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on pooker.samsco.org Cc: Kostik Belousov , Achim_Leubner@adaptec.com, Robert Watson , freebsd-stable@freebsd.org Subject: Re: file system deadlock - the whole story? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jul 2006 15:27:25 -0000 User Freebsd wrote: > On Wed, 19 Jul 2006, Robert Watson wrote: > >> On Wed, 19 Jul 2006, User Freebsd wrote: >> >>>> Yes, this was going to be my next question -- if you're seeing >>>> wedges under load and there's a common controller in use, maybe >>>> we're looking at a driver bug. Bugs of those sort typically look a >>>> lot like what you describe: an I/O is "lost" and so eveything that >>>> depends on the I/O wedges waiting for it, leading to a lot of >>>> processes hanging around waiting for vnode locks, etc. >>> >>> >>> 'k, but how do we debug *that*? :( If it was one, I'd suspect >>> hardware ... but *three*, and only acting up *after* upgrading to >>> FreeBSD 6.x, and only acting up under load ... >> >> >> There are two normal approaches: >> >> (1) Switch controllers and see if the problem goes away, then blame the >> controller that was replaced. :-) >> >> (2) Debug the driver when the system is in the wedged state. When >> Scott Long >> helped me out with an identical problem with the 3ware driver a few >> years >> ago, he basically added debugging output for the driver in the >> debugger to >> list the state of outstanding I/Os, count the number of in-bound, >> out-bound I/Os, etc, to try and find where the missing one was >> leaked. My >> impression is that once he had confirmed the presence of the >> problem, it >> was fairly easy to fix, but that confirming it required quite a bit of >> paperwork. > > > 'k, first question is with the core file provide any insight into this? > ie. provide further confirmation that it looks like the driver vs file > system? > > second question, who is currently maintaining the iir driver? I've CC'd > Achim in this, as he's listed in the man page as being the maintainer ... > > Now, uranus has all the various kernel debugging enabled right now, and > a serial console, so we're good for the debugging side of things ... and > I believe that I can fairly easily "recreate" the issue by just moving a > whack of vServers onto that machine to give it the load that seems to > kill it ... *and* uranus is one of my newer machines, so the card that > is in it is fairly new ... but, since I have a full BIOS serial console > working on it, I should be able to get full model # and firmware > version, which I take it will help some? > What exact version of FreeBSD are you dealing with? Scott From owner-freebsd-stable@FreeBSD.ORG Wed Jul 19 15:28:44 2006 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9CEA716A501 for ; Wed, 19 Jul 2006 15:28:44 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [209.31.154.42]) by mx1.FreeBSD.org (Postfix) with ESMTP id 40B4C43DAE for ; Wed, 19 Jul 2006 15:28:11 +0000 (GMT) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [209.31.154.41]) by cyrus.watson.org (Postfix) with ESMTP id AD95546C1D; Wed, 19 Jul 2006 11:28:02 -0400 (EDT) Date: Wed, 19 Jul 2006 16:28:02 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: User Freebsd In-Reply-To: <20060719115948.M1799@ganymede.hub.org> Message-ID: <20060719162705.P5132@fledge.watson.org> References: <20060705100403.Y80381@fledge.watson.org> <20060705234514.I70011@fledge.watson.org> <20060715000351.U1799@ganymede.hub.org> <20060715035308.GJ32624@deviant.kiev.zoral.com.ua> <20060718074804.W1799@ganymede.hub.org> <20060719112424.GK1464@deviant.kiev.zoral.com.ua> <20060719082627.H1799@ganymede.hub.org> <20060719151327.H5132@fledge.watson.org> <20060719112208.Y1799@ganymede.hub.org> <20060719154447.K5132@fledge.watson.org> <20060719115948.M1799@ganymede.hub.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Kostik Belousov , Achim_Leubner@adaptec.com, freebsd-stable@freebsd.org Subject: Re: file system deadlock - the whole story? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jul 2006 15:28:44 -0000 On Wed, 19 Jul 2006, User Freebsd wrote: > 'k, first question is with the core file provide any insight into this? ie. > provide further confirmation that it looks like the driver vs file system? Quite possibly, yes. > second question, who is currently maintaining the iir driver? I've CC'd > Achim in this, as he's listed in the man page as being the maintainer ... The last big change I see in there was from Scott Long in March, 2006, so quite recently. I'd give Scott a ping and ask him if he'd be interested in helping determine whether the source of a file system wedge might be an iir driver bug of some sort. Robert N M Watson Computer Laboratory University of Cambridge From owner-freebsd-stable@FreeBSD.ORG Wed Jul 19 16:02:19 2006 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2B98916A4DE for ; Wed, 19 Jul 2006 16:02:19 +0000 (UTC) (envelope-from turtle@loveturtle.net) Received: from loveturtle.net (loveturtle.net [216.91.90.11]) by mx1.FreeBSD.org (Postfix) with ESMTP id 13A3043D70 for ; Wed, 19 Jul 2006 16:02:15 +0000 (GMT) (envelope-from turtle@loveturtle.net) Received: from localhost (localhost [127.0.0.1]) by loveturtle.net (Postfix) with ESMTP id 482A71CC6E for ; Wed, 19 Jul 2006 12:02:15 -0400 (EDT) X-Virus-Scanned: amavisd-new at loveturtle.net Received: from loveturtle.net ([127.0.0.1]) by localhost (loveturtle.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 52F07WdWOGRV for ; Wed, 19 Jul 2006 12:02:09 -0400 (EDT) Received: from [216.89.228.114] (mini.loveturtle.net [216.89.228.114]) by loveturtle.net (Postfix) with ESMTP id 017DA1CC20 for ; Wed, 19 Jul 2006 12:02:08 -0400 (EDT) Message-ID: <44BE5772.2090608@loveturtle.net> Date: Wed, 19 Jul 2006 12:01:54 -0400 From: Dillon User-Agent: Mail/News 1.5.0.2 (Macintosh/20060314) MIME-Version: 1.0 To: freebsd-stable@freebsd.org References: <200607172111.08919.vsemionov@gmail.com> In-Reply-To: <200607172111.08919.vsemionov@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: ath driver transmits frames only after a low watermark is filled X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jul 2006 16:02:19 -0000 Sounds like what always happens when crappy power management stuff is enabled either on the station or the ap. I would investigate that first. Victor Semionov wrote: > Hello list, > > I have a wireless card with an Atheros 5212 chipset and I'm experiencing the > following behavior under FreeBSD 6.1: > > TCP connections that consist of small short bursts of one-way (transmission) > traffic often stall until traffic is received over another TCP connection. > For example, if I try to load a small web page, located on the FreeBSD box, > over the wireless link, it doesn't load completely, unless I hit return in a > concurrent terminal session, or until I request some other file hosted on the > FreeBSD box, or until I wait 20 seconds or so. The signal is not low, the two > wireless boxes are in the same room. > > Higher-bandwidth connections rarely stall. This makes me think there is some > kind of low watermark functionality in the hardware/driver that doesn't send > frames until a certain number of them have been queued for transmission, or > until a frame has been received. Also, I guess this is the reason that the > ath module caused the system to freeze at shutdown or when the module is > unloaded, unless I do an "ifconfig ath0 down" before unloading - the > unloading code is probably waiting for all queued frames to be transmitted, > but that never happens. > > Sorry for the weak conclusion that is based on assumptions. I'm not familiar > with the OS/driver internals and don't know how to investigate further. Is > there a sysctl or other setting that controls this behavior, or some other > workaround? Any help would be greatly appreciated. > > Best regards, > Victor Semionov > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" > From owner-freebsd-stable@FreeBSD.ORG Wed Jul 19 16:28:44 2006 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8741916A4DA for ; Wed, 19 Jul 2006 16:28:44 +0000 (UTC) (envelope-from mb@imp.ch) Received: from pop.imp.ch (mx2.imp.ch [157.161.9.17]) by mx1.FreeBSD.org (Postfix) with ESMTP id DCEB943D46 for ; Wed, 19 Jul 2006 16:28:43 +0000 (GMT) (envelope-from mb@imp.ch) Received: from godot.imp.ch (godot.imp.ch [157.161.4.8]) by pop.imp.ch (8.13.7/8.13.7/Submit_imp) with ESMTP id k6JGSYV5035377; Wed, 19 Jul 2006 18:28:36 +0200 (CEST) (envelope-from mb@imp.ch) Date: Wed, 19 Jul 2006 18:28:34 +0200 (CEST) From: Martin Blapp To: Vinny Abello In-Reply-To: <7.0.1.0.2.20060719112609.0abfb010@tellurian.com> Message-ID: <20060719182732.D36995@godot.imp.ch> References: <20060718152306.X36995@godot.imp.ch> <20060718155642.H36995@godot.imp.ch> <20060718140707.GG66891@bunrab.catwhisker.org> <20060718161104.X36995@godot.imp.ch> <7.0.1.0.2.20060719112609.0abfb010@tellurian.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Scanned-By: MIMEDefang 2.57 on 157.161.9.65 Cc: freebsd-stable@freebsd.org Subject: Re: Please confirm: top(1) cpu time broken on FreeBSD 6.1 (RELEASE/STABLE) SMP ? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jul 2006 16:28:44 -0000 Hi, > Disable hyperthreading in your BIOS. Off course this is a solution, but I don't like it. On a untuned, unmodified, unpatched system top(1) should display the correct values IMHO. Martin From owner-freebsd-stable@FreeBSD.ORG Wed Jul 19 17:11:47 2006 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7F3F916A4DA for ; Wed, 19 Jul 2006 17:11:47 +0000 (UTC) (envelope-from mike@jellydonut.org) Received: from mail.secureworks.net (mail.secureworks.net [65.114.32.155]) by mx1.FreeBSD.org (Postfix) with SMTP id D9E0543D64 for ; Wed, 19 Jul 2006 17:11:46 +0000 (GMT) (envelope-from mike@jellydonut.org) Received: (qmail 42031 invoked from network); 19 Jul 2006 17:11:46 -0000 Received: from unknown (HELO ?192.168.14.135?) (63.239.86.253) by 0 with SMTP; 19 Jul 2006 17:11:46 -0000 Message-ID: <44BE67D1.4090603@jellydonut.org> Date: Wed, 19 Jul 2006 13:11:45 -0400 From: Michael Proto User-Agent: Thunderbird 1.5.0.4 (X11/20060627) MIME-Version: 1.0 To: freebsd-stable@freebsd.org References: <20060718152306.X36995@godot.imp.ch> <20060718155642.H36995@godot.imp.ch> <20060718140707.GG66891@bunrab.catwhisker.org> <20060718161104.X36995@godot.imp.ch> <7.0.1.0.2.20060719112609.0abfb010@tellurian.com> <20060719182732.D36995@godot.imp.ch> In-Reply-To: <20060719182732.D36995@godot.imp.ch> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: Please confirm: top(1) cpu time broken on FreeBSD 6.1 (RELEASE/STABLE) SMP ? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jul 2006 17:11:47 -0000 Martin Blapp wrote: > > Hi, > >> Disable hyperthreading in your BIOS. > > Off course this is a solution, but I don't like > it. On a untuned, unmodified, unpatched system top(1) > should display the correct values IMHO. On some systems (like my Dell) it does work as expected on an untuned system, as hyperthreading defaults to off in the BIOS. -Proto From owner-freebsd-stable@FreeBSD.ORG Wed Jul 19 18:41:42 2006 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E66C016A4DD for ; Wed, 19 Jul 2006 18:41:42 +0000 (UTC) (envelope-from vsemionov@gmail.com) Received: from ug-out-1314.google.com (ug-out-1314.google.com [66.249.92.172]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1E93D43D5F for ; Wed, 19 Jul 2006 18:41:39 +0000 (GMT) (envelope-from vsemionov@gmail.com) Received: by ug-out-1314.google.com with SMTP id m2so464809uge for ; Wed, 19 Jul 2006 11:41:39 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:from:to:subject:date:user-agent:references:in-reply-to:cc:mime-version:content-type:content-transfer-encoding:content-disposition:message-id; b=pOsd4mrttwbkyUvPXV4K6cQXwEWq0pWvoGHASBOv+3tjxcSWkfDMMR33K0GfYg72e3U92ypxptUMFUYaBJwgqSSwe0GQbM+jdDuwe23ZgJeDRgugN9lbuZkVTzNm716X1WSsgSkNKQJIivDTtDCNZIFAkNJzG66tkX2aZKJGTn0= Received: by 10.67.93.7 with SMTP id v7mr1030635ugl; Wed, 19 Jul 2006 11:33:01 -0700 (PDT) Received: from neon.devian.bg ( [83.148.125.201]) by mx.gmail.com with ESMTP id j2sm963965ugf.2006.07.19.11.33.00; Wed, 19 Jul 2006 11:33:01 -0700 (PDT) From: Victor Semionov To: freebsd-stable@freebsd.org Date: Wed, 19 Jul 2006 21:35:04 +0300 User-Agent: KMail/1.9.3 References: <200607172111.08919.vsemionov@gmail.com> <44BE5772.2090608@loveturtle.net> In-Reply-To: <44BE5772.2090608@loveturtle.net> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200607192135.05016.vsemionov@gmail.com> Cc: Dillon Subject: Re: ath driver transmits frames only after a low watermark is filled X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jul 2006 18:41:43 -0000 How is data transmission related to power management? On Wednesday 19 July 2006 19:01, you wrote: > Sounds like what always happens when crappy power management stuff is > enabled either on the station or the ap. > I would investigate that first. > > Victor Semionov wrote: > > Hello list, > > > > I have a wireless card with an Atheros 5212 chipset and I'm experiencing > > the following behavior under FreeBSD 6.1: > > > > TCP connections that consist of small short bursts of one-way > > (transmission) traffic often stall until traffic is received over another > > TCP connection. For example, if I try to load a small web page, located > > on the FreeBSD box, over the wireless link, it doesn't load completely, > > unless I hit return in a concurrent terminal session, or until I request > > some other file hosted on the FreeBSD box, or until I wait 20 seconds or > > so. The signal is not low, the two wireless boxes are in the same room. > > > > Higher-bandwidth connections rarely stall. This makes me think there is > > some kind of low watermark functionality in the hardware/driver that > > doesn't send frames until a certain number of them have been queued for > > transmission, or until a frame has been received. Also, I guess this is > > the reason that the ath module caused the system to freeze at shutdown or > > when the module is unloaded, unless I do an "ifconfig ath0 down" before > > unloading - the unloading code is probably waiting for all queued frames > > to be transmitted, but that never happens. > > > > Sorry for the weak conclusion that is based on assumptions. I'm not > > familiar with the OS/driver internals and don't know how to investigate > > further. Is there a sysctl or other setting that controls this behavior, > > or some other workaround? Any help would be greatly appreciated. > > > > Best regards, > > Victor Semionov > > _______________________________________________ > > freebsd-stable@freebsd.org mailing list > > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" > > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" From owner-freebsd-stable@FreeBSD.ORG Wed Jul 19 19:33:49 2006 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6583F16A4E6 for ; Wed, 19 Jul 2006 19:33:49 +0000 (UTC) (envelope-from ghelmer@palisadesys.com) Received: from magellan.palisadesys.com (magellan.palisadesys.com [192.188.162.211]) by mx1.FreeBSD.org (Postfix) with ESMTP id 046AC43D49 for ; Wed, 19 Jul 2006 19:33:48 +0000 (GMT) (envelope-from ghelmer@palisadesys.com) Received: from [172.16.1.108] (cetus.palisadesys.com [192.188.162.7]) (authenticated bits=0) by magellan.palisadesys.com (8.13.6/8.13.6) with ESMTP id k6JJXcHY011898 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 19 Jul 2006 14:33:38 -0500 (CDT) (envelope-from ghelmer@palisadesys.com) Message-ID: <44BE8912.9010807@palisadesys.com> Date: Wed, 19 Jul 2006 14:33:38 -0500 From: Guy Helmer User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: freebsd-stable@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Palisade-MailScanner-Information: Please contact the ISP for more information X-Palisade-MailScanner: Found to be clean X-Palisade-MailScanner-SpamCheck: not spam (whitelisted), SpamAssassin (score=-4.399, required 6, autolearn=not spam, ALL_TRUSTED -1.80, BAYES_00 -2.60) X-Palisade-MailScanner-From: ghelmer@palisadesys.com Subject: Can't run newly-compiled RELENG_6 programs under RELENG_6_1: missing __res_state X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jul 2006 19:33:49 -0000 We just tried running programs under RELENG_6_1 that were compiled under RELENG_6 checked out 2006-07-19, and couldn't because of the undefined symbol "__res_state"l, which I would assume is a result of the recent MFC of the BIND 9 resolver library. Is this to be expected? It will cause a bit of a hassle... Guy -- Guy Helmer, Ph.D. Principal System Architect Palisade Systems, Inc. From owner-freebsd-stable@FreeBSD.ORG Wed Jul 19 20:00:36 2006 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6524016A4DD; Wed, 19 Jul 2006 20:00:36 +0000 (UTC) (envelope-from freebsd@hub.org) Received: from hub.org (hub.org [200.46.204.220]) by mx1.FreeBSD.org (Postfix) with ESMTP id 936EA43D6D; Wed, 19 Jul 2006 20:00:35 +0000 (GMT) (envelope-from freebsd@hub.org) Received: from localhost (mx1.hub.org [200.46.208.251]) by hub.org (Postfix) with ESMTP id C3973291B09; Wed, 19 Jul 2006 17:00:31 -0300 (ADT) Received: from hub.org ([200.46.204.220]) by localhost (mx1.hub.org [200.46.208.251]) (amavisd-new, port 10024) with ESMTP id 60957-01; Wed, 19 Jul 2006 17:00:34 -0300 (ADT) Received: from ganymede.hub.org (blk-224-179-167.eastlink.ca [24.224.179.167]) by hub.org (Postfix) with ESMTP id 3AEE4290C31; Wed, 19 Jul 2006 17:00:31 -0300 (ADT) Received: by ganymede.hub.org (Postfix, from userid 1027) id 0D3F55D96A; Wed, 19 Jul 2006 17:00:35 -0300 (ADT) Received: from localhost (localhost [127.0.0.1]) by ganymede.hub.org (Postfix) with ESMTP id 0C35F5D8B3; Wed, 19 Jul 2006 17:00:35 -0300 (ADT) Date: Wed, 19 Jul 2006 17:00:35 -0300 (ADT) From: User Freebsd To: Scott Long In-Reply-To: <44BE4F31.9020606@samsco.org> Message-ID: <20060719165945.A1799@ganymede.hub.org> References: <20060705100403.Y80381@fledge.watson.org> <20060705234514.I70011@fledge.watson.org> <20060715000351.U1799@ganymede.hub.org> <20060715035308.GJ32624@deviant.kiev.zoral.com.ua> <20060718074804.W1799@ganymede.hub.org> <20060719112424.GK1464@deviant.kiev.zoral.com.ua> <20060719082627.H1799@ganymede.hub.org> <20060719151327.H5132@fledge.watson.org> <20060719112208.Y1799@ganymede.hub.org> <20060719154447.K5132@fledge.watson.org> <20060719115948.M1799@ganymede.hub.org> <44BE4F31.9020606@samsco.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Kostik Belousov , Achim_Leubner@adaptec.com, Robert Watson , freebsd-stable@freebsd.org Subject: Re: file system deadlock - the whole story? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jul 2006 20:00:36 -0000 On Wed, 19 Jul 2006, Scott Long wrote: >> Now, uranus has all the various kernel debugging enabled right now, and a >> serial console, so we're good for the debugging side of things ... and I >> believe that I can fairly easily "recreate" the issue by just moving a >> whack of vServers onto that machine to give it the load that seems to kill >> it ... *and* uranus is one of my newer machines, so the card that is in it >> is fairly new ... but, since I have a full BIOS serial console working on >> it, I should be able to get full model # and firmware version, which I take >> it will help some? >> > > What exact version of FreeBSD are you dealing with? 6-STABLE from ~Jun 28th ... but, I can upgrade it to the latest -STABLE if you feel that that might either help, or at least make debugging easier ... ---- Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email . scrappy@hub.org MSN . scrappy@hub.org Yahoo . yscrappy Skype: hub.org ICQ . 7615664 From owner-freebsd-stable@FreeBSD.ORG Wed Jul 19 20:26:26 2006 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9459F16A4DE for ; Wed, 19 Jul 2006 20:26:26 +0000 (UTC) (envelope-from spork@bway.net) Received: from mail.bway.net (xena.bway.net [216.220.96.26]) by mx1.FreeBSD.org (Postfix) with ESMTP id 38D1E43DC1 for ; Wed, 19 Jul 2006 20:24:55 +0000 (GMT) (envelope-from spork@bway.net) Received: (qmail 11845 invoked by uid 0); 19 Jul 2006 20:24:54 -0000 Received: from unknown (HELO office-dhcp-32.bway.net) (spork@bway.net@216.220.107.32) by smtp.bway.net with (DHE-RSA-AES256-SHA encrypted) SMTP; 19 Jul 2006 20:24:54 -0000 Date: Wed, 19 Jul 2006 16:19:14 -0400 (EDT) From: Charles Sprickman To: freebsd-stable@freebsd.org In-Reply-To: Message-ID: <20060719161612.R34644@sporker.bway.net> References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Subject: Re: 6.1 quota issues X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jul 2006 20:26:26 -0000 Replying to myself and top-posting... A very helpful person contacted me off-list and pointed me to this PR that dates back to 2.2: http://www.freebsd.org/cgi/query-pr.cgi?pr=2325 I'm going to submit a followup to that so that whomever claims it can see that it persists into at least 6.1. In short, the machine I was rsyncing from had some very high UIDs and these seem to trip up the quota code. The big hint was the 4GB+ quota.user file. I'm still doing some more testing, but so far it looks very much like this bug was the root of all my problems. Thanks, Charles On Fri, 7 Jul 2006, Charles Sprickman wrote: > Hello all, > > I'm in the process of rolling out a new shell server and for numerous reasons > have decided 6.x is the best fit (jail improvements, SMP improvements, 3Ware > driver, pf). The shell server is within a jail, and the uids there are > unique so that quotas remain sane. There are about 5000 active accounts > using about 40GB of a 210GB partition. The quota.user file is about 4GB. > > I just started work on getting quotas setup for everyone after rsyncing all > the homedirs from the old server over. At first, all seemed well, then I ran > into a few issues on subsequent rsyncs. I had people with large (1GB+) > homedirs and quotas in the 1GB-4GB range and as rsync was chowning the files > to the users it was throwing errors about "quota exceeded". Here's a brief > example that illustrates what I was seeing: > > ot@beta[/home/staff/micro/tmp]# quota micro > Disk quotas for user micro (uid 5315): > Filesystem usage quota limit grace files quota limit grace > / 1630026 3000000 3100000 13393 0 0 > root@beta[/home/staff/micro/tmp]# chown micro index.html > chown: index.html: Disc quota exceeded > root@beta[/home/staff/micro/tmp]# > > I know in the past when I've seen inconsistencies indicating that I needed a > manual run of quotacheck, they would show up in the output of the quota > command; ie: the "quota" command would show the user had more usage than "du" > would indicate. The above example is a bit odd - "quota" shows that he's > well within his limits, but the kernel thinks otherwise. > > Thinking it would be a good idea to stop the jails, turn off quotas, umount > the partition, fsck it, mount it and then run quotacheck, I found more > problems. My first run of quotacheck ran for a few minutes, reported many > inconsistencies and then sat there for quite some time before spitting this > out: > > quotacheck: /jails/quota.user: seek failed: Invalid argument > > Trying again, it reported the same inconsistencies then sat there for more > than an hour taking up all the available CPU on the box until I killed it. > The mtime on quota.user had not changed during the run. > > Running it yet again now gives me this: > > /jails: fixed: inodes 27 -> 0 blocks 156 -> 0 > quotacheck: /jails/quota.user: seek failed: Invalid argument > THE FOLLOWING FILE SYSTEM HAD AN UNEXPECTED INCONSISTENCY: > /dev/twed0s1g (/jails) > > For now I can live without quotas, but if there's anything I can test from > -stable that might address this I'd like to try it. I'd say this thing is > still a good month from going live since we have lots of dependancy mess on > the old box to clean up before cutting over. > > Any ideas what's going on here? Is this related to the large number of users > and the size of the partition? I've seen some of the discussions about > snapshots + quotas, but that seems like an entirely different issue. For the > time being I've killed "background_fsck" and "check_quotas" in rc.conf, and > I'll avoid dumping that fs with the snapshot flag. > > What other information can I provide to help better define where this bug > lives? > > Thanks, > > Charles > From owner-freebsd-stable@FreeBSD.ORG Wed Jul 19 20:34:16 2006 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 516DB16A4E1 for ; Wed, 19 Jul 2006 20:34:16 +0000 (UTC) (envelope-from hugo@barafranca.com) Received: from mail.barafranca.com (mail.barafranca.com [67.19.101.164]) by mx1.FreeBSD.org (Postfix) with ESMTP id 85CB143D46 for ; Wed, 19 Jul 2006 20:34:14 +0000 (GMT) (envelope-from hugo@barafranca.com) Received: from localhost (localhost [127.0.0.1]) by mail.barafranca.com (Postfix) with ESMTP id 62C38C38EF for ; Wed, 19 Jul 2006 20:50:52 +0000 (UTC) Received: from mail.barafranca.com ([67.19.101.164]) by localhost (mail.barafranca.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 35884-09 for ; Wed, 19 Jul 2006 20:50:50 +0000 (UTC) Received: from [192.168.0.1] (unknown [81.84.174.38]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.barafranca.com (Postfix) with ESMTP id 24D8AC38DB for ; Wed, 19 Jul 2006 20:50:46 +0000 (UTC) Message-ID: <44BE973E.3080409@barafranca.com> Date: Wed, 19 Jul 2006 21:34:06 +0100 From: Hugo Silva User-Agent: Thunderbird 1.5.0.2 (X11/20060516) MIME-Version: 1.0 To: freebsd-stable@freebsd.org Content-Type: multipart/mixed; boundary="------------000103050601000907030208" X-Virus-Scanned: amavisd-new at barafranca.com X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Panic on 6.1-STABLE (fatal trap 19: non-maskable interrupt) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jul 2006 20:34:16 -0000 This is a multi-part message in MIME format. --------------000103050601000907030208 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi all, I've experienced a panic on a database server running 6.1-STABLE (Jul 3). Altough I don't have a dump, my co-worked managed to take a screenshot of the console thru DRAC. The text is all messed up as you'll notice. I had never seen this behaviour (nor a trap 19, to be honest). This server was up for around 12 days without any trouble. It's a heavily loaded database server. Without any other clue (dumps, etc), what would you bet on as being the cause for the panic AND the corrupted text (see attached screenshot) ? --------------000103050601000907030208-- From owner-freebsd-stable@FreeBSD.ORG Wed Jul 19 20:42:09 2006 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C741C16A4DE for ; Wed, 19 Jul 2006 20:42:09 +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 6D3F043D53 for ; Wed, 19 Jul 2006 20:42:05 +0000 (GMT) (envelope-from scottl@samsco.org) Received: from [10.10.3.185] ([165.236.175.187]) (authenticated bits=0) by pooker.samsco.org (8.13.4/8.13.4) with ESMTP id k6JKfw3P011160; Wed, 19 Jul 2006 14:42:03 -0600 (MDT) (envelope-from scottl@samsco.org) Message-ID: <44BE9902.3050900@samsco.org> Date: Wed, 19 Jul 2006 14:41:38 -0600 From: Scott Long User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.12) Gecko/20060206 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Guy Helmer References: <44BE8912.9010807@palisadesys.com> In-Reply-To: <44BE8912.9010807@palisadesys.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=0.0 required=3.8 tests=none autolearn=failed version=3.1.1 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on pooker.samsco.org Cc: freebsd-stable@freebsd.org Subject: Re: Can't run newly-compiled RELENG_6 programs under RELENG_6_1: missing __res_state X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jul 2006 20:42:09 -0000 Guy Helmer wrote: > We just tried running programs under RELENG_6_1 that were compiled under > RELENG_6 checked out 2006-07-19, and couldn't because of the undefined > symbol "__res_state"l, which I would assume is a result of the recent > MFC of the BIND 9 resolver library. Is this to be expected? It will > cause a bit of a hassle... > > Guy > No, it shouldn't be that way. I heavily advocated that the STABLE branches should be free from exactly these kinds of problems. Hopefully this gets resolved. Scott From owner-freebsd-stable@FreeBSD.ORG Wed Jul 19 20:43:41 2006 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7C8F216A4E2 for ; Wed, 19 Jul 2006 20:43:41 +0000 (UTC) (envelope-from hugo@barafranca.com) Received: from mail.barafranca.com (mail.barafranca.com [67.19.101.164]) by mx1.FreeBSD.org (Postfix) with ESMTP id 00C5143D94 for ; Wed, 19 Jul 2006 20:43:36 +0000 (GMT) (envelope-from hugo@barafranca.com) Received: from localhost (localhost [127.0.0.1]) by mail.barafranca.com (Postfix) with ESMTP id 3BE12C389B for ; Wed, 19 Jul 2006 21:00:15 +0000 (UTC) Received: from mail.barafranca.com ([67.19.101.164]) by localhost (mail.barafranca.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 39724-06 for ; Wed, 19 Jul 2006 21:00:14 +0000 (UTC) Received: from [192.168.0.1] (unknown [81.84.174.38]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.barafranca.com (Postfix) with ESMTP id F333AC388F for ; Wed, 19 Jul 2006 21:00:13 +0000 (UTC) Message-ID: <44BE9976.8000604@barafranca.com> Date: Wed, 19 Jul 2006 21:43:34 +0100 From: Hugo Silva User-Agent: Thunderbird 1.5.0.2 (X11/20060516) MIME-Version: 1.0 To: freebsd-stable@freebsd.org References: <44BE973E.3080409@barafranca.com> In-Reply-To: <44BE973E.3080409@barafranca.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: amavisd-new at barafranca.com Subject: Re: Panic on 6.1-STABLE (fatal trap 19: non-maskable interrupt) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jul 2006 20:43:41 -0000 panic @ http://67.19.182.100/panic.jpg , sorry for that. From owner-freebsd-stable@FreeBSD.ORG Wed Jul 19 20:51:41 2006 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id AB19516A4DA for ; Wed, 19 Jul 2006 20:51:41 +0000 (UTC) (envelope-from ghelmer@palisadesys.com) Received: from magellan.palisadesys.com (magellan.palisadesys.com [192.188.162.211]) by mx1.FreeBSD.org (Postfix) with ESMTP id EFBA243D6E for ; Wed, 19 Jul 2006 20:51:40 +0000 (GMT) (envelope-from ghelmer@palisadesys.com) Received: from [172.16.1.108] (cetus.palisadesys.com [192.188.162.7]) (authenticated bits=0) by magellan.palisadesys.com (8.13.6/8.13.6) with ESMTP id k6JKpaeJ015574 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 19 Jul 2006 15:51:36 -0500 (CDT) (envelope-from ghelmer@palisadesys.com) Message-ID: <44BE9B57.6090000@palisadesys.com> Date: Wed, 19 Jul 2006 15:51:35 -0500 From: Guy Helmer User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: Scott Long References: <44BE8912.9010807@palisadesys.com> <44BE9902.3050900@samsco.org> In-Reply-To: <44BE9902.3050900@samsco.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Palisade-MailScanner-Information: Please contact the ISP for more information X-Palisade-MailScanner: Found to be clean X-Palisade-MailScanner-SpamCheck: not spam (whitelisted), SpamAssassin (score=-4.399, required 6, autolearn=not spam, ALL_TRUSTED -1.80, BAYES_00 -2.60) X-Palisade-MailScanner-From: ghelmer@palisadesys.com Cc: freebsd-stable@freebsd.org Subject: Re: Can't run newly-compiled RELENG_6 programs under RELENG_6_1: missing __res_state X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jul 2006 20:51:41 -0000 Scott Long wrote: > Guy Helmer wrote: >> We just tried running programs under RELENG_6_1 that were compiled >> under RELENG_6 checked out 2006-07-19, and couldn't because of the >> undefined symbol "__res_state"l, which I would assume is a result of >> the recent MFC of the BIND 9 resolver library. Is this to be >> expected? It will cause a bit of a hassle... >> >> Guy >> > > No, it shouldn't be that way. I heavily advocated that the STABLE > branches should be free from exactly these kinds of problems. Hopefully > this gets resolved. > > Scott After looking more deeply, I've found it is because our own software plays with the semi-public _res structure to reduce the timeout and retries in the DNS resolver routines. I found the changes in /usr/include/resolv.h - references to _res.xxx are being changed via macros into function calls to make the operations thread-aware. Now that I know, I can work around it.. Guy -- Guy Helmer, Ph.D. Principal System Architect Palisade Systems, Inc. From owner-freebsd-stable@FreeBSD.ORG Wed Jul 19 20:57:38 2006 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 53F5416A4E5 for ; Wed, 19 Jul 2006 20:57:38 +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 BCDFB43D55 for ; Wed, 19 Jul 2006 20:57:37 +0000 (GMT) (envelope-from scottl@samsco.org) Received: from [10.10.3.185] ([165.236.175.187]) (authenticated bits=0) by pooker.samsco.org (8.13.4/8.13.4) with ESMTP id k6JKvUkr011251; Wed, 19 Jul 2006 14:57:36 -0600 (MDT) (envelope-from scottl@samsco.org) Message-ID: <44BE9CA6.9050007@samsco.org> Date: Wed, 19 Jul 2006 14:57:10 -0600 From: Scott Long User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.12) Gecko/20060206 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Guy Helmer References: <44BE8912.9010807@palisadesys.com> <44BE9902.3050900@samsco.org> <44BE9B57.6090000@palisadesys.com> In-Reply-To: <44BE9B57.6090000@palisadesys.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=0.0 required=3.8 tests=none autolearn=failed version=3.1.1 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on pooker.samsco.org Cc: freebsd-stable@freebsd.org Subject: Re: Can't run newly-compiled RELENG_6 programs under RELENG_6_1: missing __res_state X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jul 2006 20:57:38 -0000 Guy Helmer wrote: > Scott Long wrote: > >> Guy Helmer wrote: >> >>> We just tried running programs under RELENG_6_1 that were compiled >>> under RELENG_6 checked out 2006-07-19, and couldn't because of the >>> undefined symbol "__res_state"l, which I would assume is a result of >>> the recent MFC of the BIND 9 resolver library. Is this to be >>> expected? It will cause a bit of a hassle... >>> >>> Guy >>> >> >> No, it shouldn't be that way. I heavily advocated that the STABLE >> branches should be free from exactly these kinds of problems. Hopefully >> this gets resolved. >> >> Scott > > After looking more deeply, I've found it is because our own software > plays with the semi-public _res structure to reduce the timeout and > retries in the DNS resolver routines. I found the changes in > /usr/include/resolv.h - references to _res.xxx are being changed via > macros into function calls to make the operations thread-aware. Now > that I know, I can work around it.. > > Guy > That's good to know. Still it sounds like an unintended consequence that could cause problems for others. Scott From owner-freebsd-stable@FreeBSD.ORG Wed Jul 19 23:03:14 2006 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 52E6116A4DF for ; Wed, 19 Jul 2006 23:03:14 +0000 (UTC) (envelope-from stephen@math.missouri.edu) Received: from sccmmhc91.asp.att.net (sccmmhc91.asp.att.net [204.127.203.211]) by mx1.FreeBSD.org (Postfix) with ESMTP id CBE8A43D58 for ; Wed, 19 Jul 2006 23:03:13 +0000 (GMT) (envelope-from stephen@math.missouri.edu) Received: from [10.0.0.4] (12-216-254-44.client.mchsi.com[12.216.254.44]) by sccmmhc91.asp.att.net (sccmmhc91) with ESMTP id <20060719230312m910087ksne>; Wed, 19 Jul 2006 23:03:12 +0000 Message-ID: <44BEBA2F.3060403@math.missouri.edu> Date: Wed, 19 Jul 2006 18:03:11 -0500 From: Stephen Montgomery-Smith User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.13) Gecko/20060719 X-Accept-Language: en-us, en MIME-Version: 1.0 To: freebsd-stable Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Subject: Panic X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jul 2006 23:03:14 -0000 I just had a kernel panic. This happened seconds after I started a reboot using alt-ctl-del, at about the time just after it it said it was writing the entropy file. Here is the kernel config file, the results of the dump, and dmesg. Do you want anything else? I hope this info helps. include GENERIC ident HUB2 nooption INET6 options SMP device atapicam makeoptions DEBUG=-g hub2# cd /usr/obj/usr/src/sys/HUB2/ hub2# kgdb kernel.debug /var/crash/vmcore.196 [GDB will not be able to debug user-mode threads: /usr/lib/libthread_db.so: Undefined symbol "ps_pglobal_lookup"] 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: <118>. <118>. Fatal trap 12: page fault while in kernel mode cpuid = 0; apic id = 00 fault virtual address = 0x24 fault code = supervisor read, page not present instruction pointer = 0x20:0xc06acdc8 stack pointer = 0x28:0xeadd7ae0 frame pointer = 0x28:0xeadd7c68 code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 479 (mountd) trap number = 12 panic: page fault cpuid = 0 Uptime: 17h48m47s Dumping 3071 MB (2 chunks) chunk 0: 1MB (158 pages) ... ok chunk 1: 3071MB (786126 pages) 3055 3039 3023 3007 2991 2975 2959 2943 2927 2911 2895 2879 2863 2847 2831 2815 2799 2783 2767 2751 2735 2719 2703 2687 2671 2655 2639 2623 2607 2591 2575 2559 2543 2527 2511 2495 2479 2463 2447 2431 2415 2399 2383 2367 2351 2335 2319 2303 2287 2271 2255 2239 2223 2207 2191 2175 2159 2143 2127 2111 2095 2079 2063 2047 2031 2015 1999 1983 1967 1951 1935 1919 1903 1887 1871 1855 1839 1823 1807 1791 1775 1759 1743 1727 1711 1695 1679 1663 1647 1631 1615 1599 1583 1567 1551 1535 1519 1503 1487 1471 1455 1439 1423 1407 1391 1375 1359 1343 1327 1311 1295 1279 1263 1247 1231 1215 1199 1183 1167 1151 1135 1119 1103 1087 1071 1055 1039 1023 1007 991 975 959 943 927 911 895 879 863 847 831 815 799 783 767 751 735 719 703 687 671 655 639 623 607 591 575 559 543 527 511 495 479 463 447 431 415 399 383 367 351 335 319 303 287 271 255 239 223 207 191 175 159 143 127 111 95 79 63 47 31 15 #0 doadump () at pcpu.h:165 165 __asm __volatile("movl %%fs:0,%0" : "=r" (td)); (kgdb) list 0xc06acdc8 Function "0xc06acdc8" not defined. (kgdb) list *0xc06acdc8 0xc06acdc8 is in unp_connect (/usr/src/sys/kern/uipc_usrreq.c:992). 987 goto bad2; 988 } 989 unp = sotounpcb(so); 990 unp2 = sotounpcb(so2); 991 unp3 = sotounpcb(so3); 992 if (unp2->unp_addr != NULL) { 993 bcopy(unp2->unp_addr, sa, unp2->unp_addr->sun_len); 994 unp3->unp_addr = (struct sockaddr_un *) sa; 995 sa = NULL; 996 } (kgdb) backtrace #0 doadump () at pcpu.h:165 #1 0xc0668736 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:409 #2 0xc0668a5d in panic (fmt=0xc08ae2d2 "%s") at /usr/src/sys/kern/kern_shutdown.c:565 #3 0xc085895c in trap_fatal (frame=0xeadd7aa0, eva=36) at /usr/src/sys/i386/i386/trap.c:836 #4 0xc085869b in trap_pfault (frame=0xeadd7aa0, usermode=0, eva=36) at /usr/src/sys/i386/i386/trap.c:744 #5 0xc08582d5 in trap (frame= {tf_fs = -814350328, tf_es = -354615256, tf_ds = -1066794968, tf_edi = 0, tf_esi = -926606416, tf_ebp = -354583448, tf_isp = -354583860, tf_ebx = -928231144, tf_edx = -927683016, tf_ecx = 4, tf_eax = -814325048, tf_trapno = 12, tf_err = 0, tf_eip = -1066742328, tf_cs = 32, tf_eflags = 66178, tf_esp = -926077568, tf_ss = -927683016}) at /usr/src/sys/i386/i386/trap.c:434 #6 0xc08452ea in calltrap () at /usr/src/sys/i386/i386/exception.s:139 #7 0xc06acdc8 in unp_connect (so=0xc8cc1858, nam=0xcef36b60, td=0xc883f480) at /usr/src/sys/kern/uipc_usrreq.c:991 #8 0xc06ab308 in uipc_connect (so=0xc8cc1858, nam=0xcef36b60, td=0xc883f480) at /usr/src/sys/kern/uipc_usrreq.c:232 #9 0xc06a295e in soconnect (so=0xc8cc1858, nam=0xcef36b60, td=0xc883f480) at /usr/src/sys/kern/uipc_socket.c:558 #10 0xc06a82c8 in kern_connect (td=0xc883f480, fd=3, sa=0xcef36b60) at /usr/src/sys/kern/uipc_syscalls.c:536 ---Type to continue, or q to quit--- #11 0xc06a822f in connect (td=0xc883f480, uap=0xeadd7d04) at /usr/src/sys/kern/uipc_syscalls.c:505 #12 0xc0858ca3 in syscall (frame= {tf_fs = 59, tf_es = 59, tf_ds = 59, tf_edi = 1, tf_esi = 134598656, tf_ebp = -1077942152, tf_isp = -354583196, tf_ebx = -2011836128, tf_edx = -1, tf_ecx = -2011836128, tf_eax = 98, tf_trapno = 0, tf_err = 2, tf_eip = -2012021137, tf_cs = 51, tf_eflags = 582, tf_esp = -1077942500, tf_ss = 59}) at /usr/src/sys/i386/i386/trap.c:981 #13 0xc084533f in Xint0x80_syscall () at /usr/src/sys/i386/i386/exception.s:200 #14 0x00000033 in ?? () Previous frame inner to this frame (corrupt stack?) (kgdb) Copyright (c) 1992-2006 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 6.1-STABLE #0: Tue Jul 11 19:27:52 CDT 2006 stephen@hub2.montlan:/usr/obj/usr/src/sys/HUB2 ACPI APIC Table: Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: Intel(R) Xeon(TM) CPU 3.40GHz (3391.52-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0xf41 Stepping = 1 Features=0xbfebfbff Features2=0x649d> AMD Features=0x20000000 Logical CPUs per core: 2 real memory = 3221020672 (3071 MB) avail memory = 3142680576 (2997 MB) FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 cpu2 (AP): APIC ID: 6 cpu3 (AP): APIC ID: 7 ioapic0 irqs 0-23 on motherboard ioapic1 irqs 24-47 on motherboard kbd1 at kbdmux0 ath_hal: 0.9.17.2 (AR5210, AR5211, AR5212, RF5111, RF5112, RF2413, RF5413) acpi0: on motherboard acpi0: Power Button (fixed) Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x808-0x80b on acpi0 cpu0: on acpi0 acpi_throttle0: on cpu0 cpu1: on acpi0 acpi_throttle1: on cpu1 acpi_throttle1: failed to attach P_CNT device_attach: acpi_throttle1 attach returned 6 cpu2: on acpi0 cpu3: on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 pci0: at device 0.1 (no driver attached) pcib1: at device 2.0 on pci0 pci1: on pcib1 pcib2: at device 3.0 on pci0 pci2: on pcib2 pcib3: at device 4.0 on pci0 pci3: on pcib3 nvidia0: port 0xcf80-0xcfff mem 0xfb000000-0xfbffffff,0xd0000000-0xdfffffff,0xfa000000-0xfaffffff at device 0.0 on pci3 nvidia0: [GIANT-LOCKED] pcib4: at device 28.0 on pci0 pci4: on pcib4 em0: port 0xdf80-0xdfbf mem 0xfcfe0000-0xfcffffff,0xfcfc0000-0xfcfdffff irq 24 at device 2.0 on pci4 em0: Ethernet address: 00:0e:0c:63:34:14 twe0: <3ware Storage Controller. Driver version 1.50.01.002> port 0xdf00-0xdf0f mem 0xfc000000-0xfc7fffff irq 25 at device 3.0 on pci4 twe0: [GIANT-LOCKED] twe0: 2 ports, Firmware FE8S 1.05.00.068, BIOS BE7X 1.08.00.048 uhci0: port 0xbf00-0xbf1f irq 16 at device 29.0 on pci0 uhci0: [GIANT-LOCKED] usb0: on uhci0 usb0: USB revision 1.0 uhub0: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub0: 2 ports with 2 removable, self powered uhci1: port 0xbf80-0xbf9f irq 19 at device 29.1 on pci0 uhci1: [GIANT-LOCKED] usb1: on uhci1 usb1: USB revision 1.0 uhub1: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub1: 2 ports with 2 removable, self powered pci0: at device 29.4 (no driver attached) pci0: at device 29.5 (no driver attached) ehci0: mem 0xf9effc00-0xf9efffff irq 23 at device 29.7 on pci0 ehci0: [GIANT-LOCKED] usb2: EHCI version 1.0 usb2: companion controllers, 2 ports each: usb0 usb1 usb2: on ehci0 usb2: USB revision 2.0 uhub2: Intel EHCI root hub, class 9/0, rev 2.00/1.00, addr 1 uhub2: 4 ports with 4 removable, self powered pcib5: at device 30.0 on pci0 pci5: on pcib5 em1: port 0xee80-0xeebf mem 0xfeba0000-0xfebbffff irq 16 at device 3.0 on pci5 em1: Ethernet address: 00:0e:0c:3d:e1:6f pcm0: port 0xee00-0xee3f irq 21 at device 4.0 on pci5 pcm0: es1370_wrcodec: timed out pcm0: isab0: at device 31.0 on pci0 isa0: on isab0 atapci0: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xfc00-0xfc0f at device 31.1 on pci0 ata0: on atapci0 ata1: on atapci0 pci0: at device 31.3 (no driver attached) acpi_button0: on acpi0 atkbdc0: port 0x60,0x64 irq 1 on acpi0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] psm0: irq 12 on atkbdc0 psm0: [GIANT-LOCKED] psm0: model IntelliMouse Explorer, device ID 4 sio0: <16550A-compatible COM port> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 sio0: type 16550A sio1: <16550A-compatible COM port> port 0x2f8-0x2ff irq 3 on acpi0 sio1: type 16550A fdc0: port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on acpi0 fdc0: [FAST] fd0: <1440-KB 3.5" drive> on fdc0 drive 0 pmtimer0 on isa0 orm0: at iomem 0xcf000-0xcffff,0xd0000-0xd0fff,0xd1000-0xd1fff,0xd2800-0xd37ff on isa0 ppc0: parallel port not found. sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 ugen0: American Power Conversion Back-UPS RS 1500 FW:8.g9 .D USB FW:g9, rev 1.10/1.06, addr 2 Timecounters tick every 1.000 msec acd0: DMA limited to UDMA33, controller found non-ATA66 cable acd0: DVDR at ata0-master UDMA33 twed0: on twe0 twed0: 228944MB (468879104 sectors) SMP: AP CPU #3 Launched! SMP: AP CPU #1 Launched! SMP: AP CPU #2 Launched! cd0 at ata0 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 Trying to mount root from ufs:/dev/twed0s3a WARNING: / was not properly dismounted From owner-freebsd-stable@FreeBSD.ORG Thu Jul 20 00:13:53 2006 Return-Path: X-Original-To: freebsd-stable@FreeBSD.ORG Delivered-To: freebsd-stable@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2C22916A4DF for ; Thu, 20 Jul 2006 00:13:53 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (vc4-2-0-87.dsl.netrack.net [199.45.160.85]) by mx1.FreeBSD.org (Postfix) with ESMTP id BA97043D53 for ; Thu, 20 Jul 2006 00:13:52 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from localhost (localhost.village.org [127.0.0.1] (may be forged)) by harmony.bsdimp.com (8.13.4/8.13.4) with ESMTP id k6K0BxMu043697; Wed, 19 Jul 2006 18:12:00 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Wed, 19 Jul 2006 18:12:15 -0600 (MDT) Message-Id: <20060719.181215.63038086.imp@bsdimp.com> To: ghelmer@palisadesys.com From: "M. Warner Losh" In-Reply-To: <44BE8912.9010807@palisadesys.com> References: <44BE8912.9010807@palisadesys.com> X-Mailer: Mew version 4.2 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0 (harmony.bsdimp.com [127.0.0.1]); Wed, 19 Jul 2006 18:12:00 -0600 (MDT) Cc: freebsd-stable@FreeBSD.ORG Subject: Re: Can't run newly-compiled RELENG_6 programs under RELENG_6_1: missing __res_state X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jul 2006 00:13:53 -0000 In message: <44BE8912.9010807@palisadesys.com> Guy Helmer writes: : We just tried running programs under RELENG_6_1 that were compiled under : RELENG_6 checked out 2006-07-19, and couldn't because of the undefined : symbol "__res_state"l, which I would assume is a result of the recent : MFC of the BIND 9 resolver library. Is this to be expected? It will : cause a bit of a hassle... It is not officially supported by the project. You are running a binary compiled on a newer version of the system on an older version of the system. This has sometimes worked in the past, but is outside the area that's expected to work. There's been a number of breakages similar to this in past RELENG branches (there was one in 3.x and a lot on 4.x). Having said that, can someone track down the problem in more detail to see if there might not be something we can do to mitigate the problem in the older versions? What is __res_state? Warner From owner-freebsd-stable@FreeBSD.ORG Thu Jul 20 00:26:35 2006 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1F47A16A4E0 for ; Thu, 20 Jul 2006 00:26:35 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (vc4-2-0-87.dsl.netrack.net [199.45.160.85]) by mx1.FreeBSD.org (Postfix) with ESMTP id 57E1343D53 for ; Thu, 20 Jul 2006 00:26:34 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from localhost (localhost.village.org [127.0.0.1] (may be forged)) by harmony.bsdimp.com (8.13.4/8.13.4) with ESMTP id k6K0NgSL043964; Wed, 19 Jul 2006 18:23:42 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Wed, 19 Jul 2006 18:23:58 -0600 (MDT) Message-Id: <20060719.182358.1791030231.imp@bsdimp.com> To: ghelmer@palisadesys.com From: "M. Warner Losh" In-Reply-To: <20060719.181215.63038086.imp@bsdimp.com> References: <44BE8912.9010807@palisadesys.com> <20060719.181215.63038086.imp@bsdimp.com> X-Mailer: Mew version 4.2 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0 (harmony.bsdimp.com [127.0.0.1]); Wed, 19 Jul 2006 18:23:43 -0600 (MDT) Cc: freebsd-stable@freebsd.org Subject: Re: Can't run newly-compiled RELENG_6 programs under RELENG_6_1: missing __res_state X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jul 2006 00:26:35 -0000 In message: <20060719.181215.63038086.imp@bsdimp.com> "M. Warner Losh" writes: : In message: <44BE8912.9010807@palisadesys.com> : Guy Helmer writes: : : We just tried running programs under RELENG_6_1 that were compiled under : : RELENG_6 checked out 2006-07-19, and couldn't because of the undefined : : symbol "__res_state"l, which I would assume is a result of the recent : : MFC of the BIND 9 resolver library. Is this to be expected? It will : : cause a bit of a hassle... : : It is not officially supported by the project. You are running a : binary compiled on a newer version of the system on an older version : of the system. This has sometimes worked in the past, but is outside : the area that's expected to work. There's been a number of breakages : similar to this in past RELENG branches (there was one in 3.x and a : lot on 4.x). : : Having said that, can someone track down the problem in more detail to : see if there might not be something we can do to mitigate the problem : in the older versions? What is __res_state? Just saw Guy's followup note. I'm unsure if we need a technological fix for this, or just a documentation fix. How common is it for programs to use the semi-public interfaces that yours used? Warner From owner-freebsd-stable@FreeBSD.ORG Thu Jul 20 01:28:13 2006 Return-Path: X-Original-To: freebsd-stable@FreeBSD.ORG Delivered-To: freebsd-stable@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 772AF16A4E1 for ; Thu, 20 Jul 2006 01:28:13 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from mail2.fluidhosting.com (mx21.fluidhosting.com [204.14.89.4]) by mx1.FreeBSD.org (Postfix) with SMTP id 6486B43D46 for ; Thu, 20 Jul 2006 01:28:12 +0000 (GMT) (envelope-from dougb@FreeBSD.org) Received: (qmail 26653 invoked by uid 399); 20 Jul 2006 01:28:11 -0000 Received: from localhost (HELO ?192.168.0.7?) (dougb@dougbarton.us@127.0.0.1) by localhost with SMTP; 20 Jul 2006 01:28:11 -0000 Message-ID: <44BEDC33.4070909@FreeBSD.org> Date: Wed, 19 Jul 2006 18:28:19 -0700 From: Doug Barton Organization: http://www.FreeBSD.org/ User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: "M. Warner Losh" References: <44BE8912.9010807@palisadesys.com> <20060719.181215.63038086.imp@bsdimp.com> In-Reply-To: <20060719.181215.63038086.imp@bsdimp.com> X-Enigmail-Version: 0.94.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-stable@FreeBSD.ORG, ghelmer@palisadesys.com, Hajimu UMEMOTO Subject: Re: Can't run newly-compiled RELENG_6 programs under RELENG_6_1: missing __res_state X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jul 2006 01:28:13 -0000 M. Warner Losh wrote: > In message: <44BE8912.9010807@palisadesys.com> > Guy Helmer writes: > : We just tried running programs under RELENG_6_1 that were compiled under > : RELENG_6 checked out 2006-07-19, and couldn't because of the undefined > : symbol "__res_state"l, which I would assume is a result of the recent > : MFC of the BIND 9 resolver library. Is this to be expected? It will > : cause a bit of a hassle... > > It is not officially supported by the project. You are running a > binary compiled on a newer version of the system on an older version > of the system. This has sometimes worked in the past, but is outside > the area that's expected to work. There's been a number of breakages > similar to this in past RELENG branches (there was one in 3.x and a > lot on 4.x). > > Having said that, can someone track down the problem in more detail to > see if there might not be something we can do to mitigate the problem > in the older versions? What is __res_state? I forwarded ume the relevant info, since he's the architect of the change I think we should give him a chance to respond. Doug -- This .signature sanitized for your protection From owner-freebsd-stable@FreeBSD.ORG Thu Jul 20 02:05:13 2006 Return-Path: X-Original-To: freebsd-stable@FreeBSD.ORG Delivered-To: freebsd-stable@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7CA1016A4DE for ; Thu, 20 Jul 2006 02:05:13 +0000 (UTC) (envelope-from ume@mahoroba.org) Received: from ameno.mahoroba.org (gw4.mahoroba.org [218.45.22.175]) by mx1.FreeBSD.org (Postfix) with ESMTP id E512043D46 for ; Thu, 20 Jul 2006 02:05:11 +0000 (GMT) (envelope-from ume@mahoroba.org) Received: from localhost (IDENT:7yWLBihPzxY8VXFyQ1klwfCF+72RZgqK+so74//2uludcPos+SCOSt/oGpOm399C@localhost [IPv6:::1]) (user=ume mech=CRAM-MD5 bits=0) by ameno.mahoroba.org (8.13.6/8.13.6) with ESMTP/inet6 id k6K24xa3025370 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 20 Jul 2006 11:04:59 +0900 (JST) (envelope-from ume@mahoroba.org) Date: Thu, 20 Jul 2006 11:04:58 +0900 Message-ID: From: Hajimu UMEMOTO To: "M. Warner Losh" In-Reply-To: <20060719.181215.63038086.imp@bsdimp.com> References: <44BE8912.9010807@palisadesys.com> <20060719.181215.63038086.imp@bsdimp.com> User-Agent: xcite1.38> Wanderlust/2.14.0 (Africa) SEMI/1.14.6 (Maruoka) FLIM/1.14.8 (=?ISO-8859-4?Q?Shij=F2?=) APEL/10.6 Emacs/22.0.50 (i386-pc-freebsd) MULE/5.0 (SAKAKI) X-Operating-System: FreeBSD 6.1-RELEASE-p1 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 authentication, not delayed by milter-greylist-2.1.5 (ameno.mahoroba.org [IPv6:::1]); Thu, 20 Jul 2006 11:05:01 +0900 (JST) X-Virus-Scanned: by amavisd-new X-Virus-Status: Clean X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.3 X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on ameno.mahoroba.org Cc: freebsd-stable@FreeBSD.ORG, ghelmer@palisadesys.com Subject: Re: Can't run newly-compiled RELENG_6 programs under RELENG_6_1: missing __res_state X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jul 2006 02:05:13 -0000 Hi, >>>>> On Wed, 19 Jul 2006 18:12:15 -0600 (MDT) >>>>> "M. Warner Losh" said: imp> In message: <44BE8912.9010807@palisadesys.com> imp> Guy Helmer writes: imp> : We just tried running programs under RELENG_6_1 that were compiled under imp> : RELENG_6 checked out 2006-07-19, and couldn't because of the undefined imp> : symbol "__res_state"l, which I would assume is a result of the recent imp> : MFC of the BIND 9 resolver library. Is this to be expected? It will imp> : cause a bit of a hassle... imp> It is not officially supported by the project. You are running a imp> binary compiled on a newer version of the system on an older version imp> of the system. This has sometimes worked in the past, but is outside imp> the area that's expected to work. There's been a number of breakages imp> similar to this in past RELENG branches (there was one in 3.x and a imp> lot on 4.x). Yes, I believe running RELENG_6 binary on RELENG_6_1 is not supported by the project. imp> Having said that, can someone track down the problem in more detail to imp> see if there might not be something we can do to mitigate the problem imp> in the older versions? What is __res_state? __res_state is a function to initialize actual _res variable. The users usually use _res. _res is substituted with __res_state by the macro defined in resolv.h to support multi thread application. Though it used to be ___res, it is replaced by __res_state during resolver update. We have compatibility cruft for ___res to keep ABI backward compatibility. Sincerely, -- Hajimu UMEMOTO @ Internet Mutual Aid Society Yokohama, Japan ume@mahoroba.org ume@{,jp.}FreeBSD.org http://www.imasy.org/~ume/ From owner-freebsd-stable@FreeBSD.ORG Thu Jul 20 02:38:58 2006 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D9C5516A4DE for ; Thu, 20 Jul 2006 02:38:58 +0000 (UTC) (envelope-from emaste@phaedrus.sandvine.ca) Received: from gw.sandvine.com (sandvine.com [199.243.201.138]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6001B43D46 for ; Thu, 20 Jul 2006 02:38:58 +0000 (GMT) (envelope-from emaste@phaedrus.sandvine.ca) Received: from mailserver.sandvine.com ([192.168.1.10]) by gw.sandvine.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 19 Jul 2006 22:38:56 -0400 Received: from labgw2.phaedrus.sandvine.com ([192.168.3.11]) by mailserver.sandvine.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 19 Jul 2006 22:38:56 -0400 Received: by labgw2.phaedrus.sandvine.com (Postfix, from userid 12627) id 53825115E8; Wed, 19 Jul 2006 22:38:56 -0400 (EDT) Date: Wed, 19 Jul 2006 22:38:56 -0400 From: Ed Maste To: Marcelo Gardini do Amaral Message-ID: <20060720023856.GA65960@sandvine.com> References: <20060711190908.GC69272@registro.br> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060711190908.GC69272@registro.br> User-Agent: Mutt/1.4.2.1i X-OriginalArrivalTime: 20 Jul 2006 02:38:56.0518 (UTC) FILETIME=[A5BC6A60:01C6ABA5] Cc: freebsd-stable@freebsd.org Subject: Re: How to setup polling on 'bge' interface X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jul 2006 02:38:58 -0000 On Tue, Jul 11, 2006 at 04:09:08PM -0300, Marcelo Gardini do Amaral wrote: > Hi, > > I'm trying to setup polling in my box. [...] > But I always get some packet loss. A few points: - Polling and SMP are compatible in 6.1. In fact, they were compatible in earlier versions too; basically it's just the compile-time check that had to be "fixed." - You may have to adjust some parameters in the kern.polling sysctl tree - specifically, kern.polling.burst_max, kern.polling.each_burst and kern.polling.user_frac might need tweaking. - The polling feedback algorithm does not work very well if your workload is focused largely on per-packet tasks (such as routing or bridging). You'll find that there is still idle CPU time at the point you start dropping packets. I have some work in progress to address this, but it's not yet committed. - Polling's major advantage is the avoidance of livelock on UP systems, and not improved performance. What level of traffic are you putting through this box? Is it routing/ bridging, or an endpoint like a web server? Ed Maste From owner-freebsd-stable@FreeBSD.ORG Thu Jul 20 11:20:27 2006 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id BC77416A4E6 for ; Thu, 20 Jul 2006 11:20:27 +0000 (UTC) (envelope-from petefrench@ticketswitch.com) Received: from mail.ticketswitch.com (mail.ticketswitch.com [194.200.93.188]) by mx1.FreeBSD.org (Postfix) with ESMTP id 21DE943D49 for ; Thu, 20 Jul 2006 11:20:27 +0000 (GMT) (envelope-from petefrench@ticketswitch.com) Received: from [172.16.1.6] (helo=dilbert.firstcallgroup.co.uk) by mail.ticketswitch.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1G3WZp-000Gsa-NQ; Thu, 20 Jul 2006 12:20:21 +0100 Received: from petefrench by dilbert.firstcallgroup.co.uk with local (Exim 4.61 (FreeBSD)) (envelope-from ) id 1G3WZp-0009ty-DT; Thu, 20 Jul 2006 12:20:21 +0100 To: freebsd-stable@freebsd.org, vsemionov@gmail.com In-Reply-To: <200607192135.05016.vsemionov@gmail.com> Message-Id: From: Pete French Date: Thu, 20 Jul 2006 12:20:21 +0100 Cc: turtle@loveturtle.net Subject: Re: ath driver transmits frames only after a low watermark is filled X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jul 2006 11:20:27 -0000 > How is data transmission related to power management? They are pretty intimately related over a wireless link. If the power management at one end decided it can use less transmit power and gets it wrong then your data stops getting through. From owner-freebsd-stable@FreeBSD.ORG Thu Jul 20 11:26:18 2006 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6D02A16A4DE for ; Thu, 20 Jul 2006 11:26:18 +0000 (UTC) (envelope-from peterjeremy@optushome.com.au) Received: from mail05.syd.optusnet.com.au (mail05.syd.optusnet.com.au [211.29.132.186]) by mx1.FreeBSD.org (Postfix) with ESMTP id B724A43D46 for ; Thu, 20 Jul 2006 11:26:17 +0000 (GMT) (envelope-from peterjeremy@optushome.com.au) Received: from turion.vk2pj.dyndns.org (c220-239-19-236.belrs4.nsw.optusnet.com.au [220.239.19.236]) by mail05.syd.optusnet.com.au (8.12.11/8.12.11) with ESMTP id k6KBQET7020212 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Thu, 20 Jul 2006 21:26:15 +1000 Received: from turion.vk2pj.dyndns.org (localhost.vk2pj.dyndns.org [127.0.0.1]) by turion.vk2pj.dyndns.org (8.13.6/8.13.6) with ESMTP id k6KBQEUr001699; Thu, 20 Jul 2006 21:26:14 +1000 (EST) (envelope-from peter@turion.vk2pj.dyndns.org) Received: (from peter@localhost) by turion.vk2pj.dyndns.org (8.13.6/8.13.6/Submit) id k6KBQDuO001698; Thu, 20 Jul 2006 21:26:13 +1000 (EST) (envelope-from peter) Date: Thu, 20 Jul 2006 21:26:13 +1000 From: Peter Jeremy To: Ed Maste Message-ID: <20060720112613.GB716@turion.vk2pj.dyndns.org> References: <20060711190908.GC69272@registro.br> <20060720023856.GA65960@sandvine.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="hHWLQfXTYDoKhP50" Content-Disposition: inline In-Reply-To: <20060720023856.GA65960@sandvine.com> X-PGP-Key: http://members.optusnet.com.au/peterjeremy/pubkey.asc User-Agent: Mutt/1.5.11 Cc: freebsd-stable@freebsd.org Subject: Re: How to setup polling on 'bge' interface X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jul 2006 11:26:18 -0000 --hHWLQfXTYDoKhP50 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, 2006-Jul-19 22:38:56 -0400, Ed Maste wrote: >- You may have to adjust some parameters in the kern.polling sysctl > tree - specifically, kern.polling.burst_max, kern.polling.each_burst > and kern.polling.user_frac might need tweaking. Note that increasing kern.polling.burst_max and kern.polling.each_burst will also increase the number of soft interrupts. >- The polling feedback algorithm does not work very well if your > workload is focused largely on per-packet tasks (such as routing or > bridging). You'll find that there is still idle CPU time at the > point you start dropping packets. I have some work in progress to > address this, but it's not yet committed. I thought setting kern.polling.idle_poll would allow the CPU to utilise all idle time. The downside is that the system always shows as 100% utilised so it's very difficult to know how busy the system actually is. >- Polling's major advantage is the avoidance of livelock on UP systems, > and not improved performance. The limited testing I've done on a Sun V20z at work suggests that you can get better routing throughput in interrupt mode than polling mode. YMMV and this is before tweaking the polling parameters. (My testing also suggests that I don't really need to do any tweaking because the limiting factor is the gigabit interfaces rather than the V20z). --=20 Peter Jeremy --hHWLQfXTYDoKhP50 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.4 (FreeBSD) iD8DBQFEv2hU/opHv/APuIcRAsTAAJ9y5Z/S9h8+yljhGeqhkQ9fWUjJ+gCgjKaC 5hdp6wCuG2qeQwc15NJ2Mb4= =shpx -----END PGP SIGNATURE----- --hHWLQfXTYDoKhP50-- From owner-freebsd-stable@FreeBSD.ORG Thu Jul 20 11:51:38 2006 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A62F016A4DF for ; Thu, 20 Jul 2006 11:51:38 +0000 (UTC) (envelope-from nealie@kobudo.homeunix.net) Received: from neal.nelson.name (neal.nelson.name [82.139.192.177]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1978543D58 for ; Thu, 20 Jul 2006 11:51:33 +0000 (GMT) (envelope-from nealie@kobudo.homeunix.net) Received: from server.home (server.home [10.0.0.1]) (TLS: TLSv1/SSLv3,128bits,RC4-MD5) by neal.nelson.name with esmtp; Thu, 20 Jul 2006 13:51:29 +0200 id 000D4C4E.44BF6E41.0000FF6A From: Nealie To: freebsd-stable@freebsd.org Date: Thu, 20 Jul 2006 13:51:29 +0200 Message-Id: <1153396289.823.16.camel@server.home> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7bit X-Mailer: Evolution 2.6.2 FreeBSD GNOME Team Port Subject: NVIDIA 6600GT Freeze X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jul 2006 11:51:38 -0000 I have a problem with my system freezing when using an NVIDIA video card using the nvidia-driver port. All seems to work fine for a while but then the system freezes and won't even reply to a ping. This can happen regardless of whether I use openGL or not. Everything works fine using the "nv" driver, so it doesn't seem to be a hardware problem. My setup is as follows: uname: FreeBSD server.home 6.1-STABLE FreeBSD 6.1-STABLE #0: Wed Jul 19 11:19:16 CEST 2006 root@server.home:/usr/obj/usr/src/sys/SERVER i386 AGP NVIDIA 6600GT installed on an MSI K8T Neo-F V2.09 motherboard (VIA K8T800 Pro chipset) with an AMD Athlon 64 3500+ CPU. The NVIDIA driver is installed as per the instructions, with agp and dri removed from the kernel in order to use the NVIDIA agp interface, even though the sysctl settings suggest otherwise. If anyone has any ideas about this problem I'd be very grateful. From owner-freebsd-stable@FreeBSD.ORG Thu Jul 20 15:36:24 2006 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B9B6F16A4DA for ; Thu, 20 Jul 2006 15:36:24 +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 AF94343D49 for ; Thu, 20 Jul 2006 15:36:21 +0000 (GMT) (envelope-from scottl@samsco.org) Received: from [192.168.254.14] (imini.samsco.home [192.168.254.14]) (authenticated bits=0) by pooker.samsco.org (8.13.4/8.13.4) with ESMTP id k6KFaEVY016037; Thu, 20 Jul 2006 09:36:19 -0600 (MDT) (envelope-from scottl@samsco.org) Message-ID: <44BFA2EE.7060308@samsco.org> Date: Thu, 20 Jul 2006 09:36:14 -0600 From: Scott Long User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7.7) Gecko/20050416 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Peter Jeremy References: <20060711190908.GC69272@registro.br> <20060720023856.GA65960@sandvine.com> <20060720112613.GB716@turion.vk2pj.dyndns.org> In-Reply-To: <20060720112613.GB716@turion.vk2pj.dyndns.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-1.4 required=3.8 tests=ALL_TRUSTED autolearn=failed version=3.1.1 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on pooker.samsco.org Cc: freebsd-stable@freebsd.org, Ed Maste Subject: Re: How to setup polling on 'bge' interface X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jul 2006 15:36:24 -0000 Peter Jeremy wrote: > On Wed, 2006-Jul-19 22:38:56 -0400, Ed Maste wrote: > >>- You may have to adjust some parameters in the kern.polling sysctl >> tree - specifically, kern.polling.burst_max, kern.polling.each_burst >> and kern.polling.user_frac might need tweaking. > > > Note that increasing kern.polling.burst_max and kern.polling.each_burst > will also increase the number of soft interrupts. > > >>- The polling feedback algorithm does not work very well if your >> workload is focused largely on per-packet tasks (such as routing or >> bridging). You'll find that there is still idle CPU time at the >> point you start dropping packets. I have some work in progress to >> address this, but it's not yet committed. > > > I thought setting kern.polling.idle_poll would allow the CPU to > utilise all idle time. The downside is that the system always shows > as 100% utilised so it's very difficult to know how busy the system > actually is. > > >>- Polling's major advantage is the avoidance of livelock on UP systems, >> and not improved performance. > > > The limited testing I've done on a Sun V20z at work suggests that you > can get better routing throughput in interrupt mode than polling mode. > YMMV and this is before tweaking the polling parameters. (My testing > also suggests that I don't really need to do any tweaking because > the limiting factor is the gigabit interfaces rather than the V20z). > This might not apply to bge, but the adaptive polling + fast interrupt changes that I made to if_em earlier in the year were a huge win over the standard polling code in terms of CPU utilization and packets per second. I think it also survived a load that caused normal polling to essentially livelock the machine. And, it had the advantage of automatically adapting to bursty loads. Scott From owner-freebsd-stable@FreeBSD.ORG Thu Jul 20 15:42:34 2006 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2424816A4DE for ; Thu, 20 Jul 2006 15:42:34 +0000 (UTC) (envelope-from sam@errno.com) Received: from ebb.errno.com (ebb.errno.com [69.12.149.25]) by mx1.FreeBSD.org (Postfix) with ESMTP id 070C643D55 for ; Thu, 20 Jul 2006 15:42:23 +0000 (GMT) (envelope-from sam@errno.com) Received: from [10.0.0.248] (trouble.errno.com [10.0.0.248]) (authenticated bits=0) by ebb.errno.com (8.13.6/8.12.6) with ESMTP id k6KFgKSs050856 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 20 Jul 2006 08:42:22 -0700 (PDT) (envelope-from sam@errno.com) Message-ID: <44BFA45C.5050108@errno.com> Date: Thu, 20 Jul 2006 08:42:20 -0700 From: Sam Leffler User-Agent: Thunderbird 1.5.0.2 (X11/20060508) MIME-Version: 1.0 To: Pete French References: In-Reply-To: X-Enigmail-Version: 0.94.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: vsemionov@gmail.com, freebsd-stable@freebsd.org, turtle@loveturtle.net Subject: Re: ath driver transmits frames only after a low watermark is filled X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jul 2006 15:42:34 -0000 Pete French wrote: >> How is data transmission related to power management? > > They are pretty intimately related over a wireless link. If > the power management at one end decided it can use less transmit > power and gets it wrong then your data stops getting through. Your posting truncated the note but what the person was suggesting was the station was operating in power save mode and so deferring transmits to the ap. Unfortunately that's not possible as HEAD has no support for sta-side power save.mode for ath. The original posting didn't provide any basic info so there's little anyone can provide except wild guesses. There are debugging mechanisms for tracing what's going on at the net80211 layer and in the driver that have been referenced countless times in this forum. Sam From owner-freebsd-stable@FreeBSD.ORG Thu Jul 20 15:53:40 2006 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id CA8CD16A500 for ; Thu, 20 Jul 2006 15:53:40 +0000 (UTC) (envelope-from mime@traveller.cz) Received: from ss.eunet.cz (ss.eunet.cz [193.85.228.13]) by mx1.FreeBSD.org (Postfix) with ESMTP id D1D7743D45 for ; Thu, 20 Jul 2006 15:53:39 +0000 (GMT) (envelope-from mime@traveller.cz) Received: from localhost.i.cz (ss.eunet.cz [193.85.228.13]) by ss.eunet.cz (8.13.6/8.13.6) with ESMTP id k6KFrbqU062199 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Thu, 20 Jul 2006 17:53:37 +0200 (CEST) (envelope-from mime@traveller.cz) From: Michal Mertl To: freebsd-stable@freebsd.org Content-Type: text/plain Date: Thu, 20 Jul 2006 17:53:29 +0200 Message-Id: <1153410809.1126.66.camel@genius.i.cz> Mime-Version: 1.0 X-Mailer: Evolution 2.6.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Subject: Kernel panic with PF X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jul 2006 15:53:40 -0000 Hello, I am deploying FreeBSD based application proxies' based firewall (www.kernun.com, but not much English there) and am having frequent panics of RELENG_6_1 under load. The server has IP forwarding disabled. I've got two machines in a carp cluster and the transparent proxies use PF to get the data. I don't know much about kernel internals and PF but from the following backtrace I understand that the crash happens because rpool->cur on line 2158 in src/sys/contrib/pf/net/pf.c is NULL and is dereferenced. It probably shouldn't happen yet it does. The machines are SMP and were running SMP kernel. The only places where pool.cur (or pool->cur) is assigned to are in pf_ioctl.c. It seems there are some lock operations though so it is probably believed that the coder is properly locked. I have been running with kern.smp.disabled=1 for a moment before I put the old firewall in place and haven't seen the panic but the time was deffinitely too short to make me believe it fixes the issue. Can setting debug.mpsafenet to 0 possibly also help? I could probably bandaid this particular failure mode by returning failure instead of panicing but the bug is probably elsewhere. I've lost the debug kernel from which this backtrace is and can't therefore continue much :-(. Unfortunately so far I can only reproduce the problem in production and for obvious reasons I can't put it there. Fatal trap 12: page fault while in kernel mode cpuid = 0; apic id = 00 fault virtual address = 0x28 fault code = supervisor read, page not present instruction pointer = 0x8:0xffffffff801ab528 stack pointer = 0x10:0xffffffffb1ade650 frame pointer = 0x10:0xffffff004cc7cc30 code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 15 (swi1: net) trap number = 12 panic: page fault #0 doadump () at pcpu.h:172 #1 0x0000000000000004 in ?? () #2 0xffffffff803d5137 in boot (howto=260) at ../../../kern/kern_shutdown.c:402 #3 0xffffffff803d58a1 in panic (fmt=0xffffff007ba32000 "@\223{") at ../../../kern/kern_shutdown.c:558 #4 0xffffffff80543b3f in trap_fatal (frame=0xffffff007ba32000, eva=18446742976272241472) at ../../../amd64/amd64/trap.c:660 #5 0xffffffff80543e5f in trap_pfault (frame=0xffffffffb1ade5a0, usermode=0) at ../../../amd64/amd64/trap.c:573 #6 0xffffffff80544113 in trap (frame= {tf_rdi = 2, tf_rsi = -1098223465792, tf_rdx = -1098439497700, tf_rcx = -1 314002464, tf_r8 = 0, tf_r9 = -1314002776, tf_rax = 0, tf_rbx = 0, tf_rbp = -109 8223465424, tf_r10 = 1, tf_r11 = 257, tf_r12 = -1098439497700, tf_r13 = -1314002 776, tf_r14 = 2, tf_r15 = -1314002464, tf_trapno = 12, tf_addr = 40, tf_flags = 216171684640539392, tf_err = 0, tf_rip = -2145733336, tf_cs = 8, tf_rflags = 661 18, tf_rsp = -1314003360, tf_ss = 16}) at ../../../amd64/amd64/trap.c:352 #7 0xffffffff8052feab in calltrap () at ../../../amd64/amd64/exception.S:168 #8 0xffffffff801ab528 in pf_map_addr (af=2 '\002', r=0xffffff004cc7cac0, saddr=0xffffff003fe7681c, naddr=0xffffffffb1ade9e0, init_addr=0x0, sn=0xffffffffb1ade8a8) at ../../../contrib/pf/net/pf.c:2163 #9 0xffffffff801acab6 in pf_get_translation (pd=0xffffffffb1ade9c0, m=0xffffff0042ede900, off=20, direction=1, kif=0xffffff007b038a00, sn=0xffffffffb1ade8a8, saddr=0xffffff003fe7681c, sport=0, daddr=0xffffff003fe76820, dport=50881, naddr=0xffffffffb1ade9e0, nport=0xffffffffb1ade8b6) at ../../../contrib/pf/net/pf.c:2618 #10 0xffffffff801b315b in pf_test_tcp (rm=0xffffffffb1ade960, sm=0xffffffffb1ade950, direction=1, kif=0xffffff007b038a00, m=0xffffff0042ede900, off=20, h=0xffffff003fe76810, pd=0xffffffffb1ade9c0, am=0xffffffffb1ade968, rsm=0xffffffffb1ade970, ifq=0x2, inp=0x0) at ../../../contrib/pf/net/pf.c:3013 #11 0xffffffff801b5694 in pf_test (dir=1, ifp=0xffffff0000bee800, m0=0xffffffffb1adeaa0, eh=0xffffffffb1ade97e, inp=0x0) at ../../../contrib/pf/net/pf.c:6449 #12 0xffffffff801bafb2 in pf_check_in (arg=0x2, m=0xffffffffb1adeaa0, ifp=0xffffff004cc7cac0, dir=-1314002464, inp=0xffffffffb1ade9e0) at ../../../contrib/pf/net/pf_ioctl.c:3358 #13 0xffffffff80461c2e in pfil_run_hooks (ph=0xffffffff807e0920, mp=0xffffffffb1adeb28, ifp=0xffffff0000bee800, dir=1, inp=0x0) at ../../../net/pfil.c:139 #14 0xffffffff8048d225 in ip_input (m=0xffffff0042ede900) at ../../../netinet/ip_input.c:465 #15 0xffffffff8046180c in netisr_processqueue (ni=0xffffffff807df690) at ../../../net/netisr.c:236 #16 0xffffffff80461abd in swi_net (dummy=0x2) at ../../../net/netisr.c:349 #17 0xffffffff803bbd99 in ithread_loop (arg=0xffffff00000506a0) at ../../../kern/kern_intr.c:684 #18 0xffffffff803ba527 in fork_exit ( callout=0xffffffff803bbc50 , arg=0xffffff00000506a0, frame=0xffffffffb1adec50) at ../../../kern/kern_fork.c:805 #19 0xffffffff8053020e in fork_trampoline () at ../../../amd64/amd64/exception.S:394 #20 0x0000000000000000 in ?? () The firewall also reports lots of PF problems durings operation: Jul 20 10:44:11 fw1 kernel: Jul 20 10:44:11 fw1 HTTP[7607]: KERN-100-E [natutil.c:770] ioctl(): Invalid argument (EINVAL=22) Jul 20 10:44:11 fw1 kernel: Jul 20 10:44:11 fw1 HTTP[7607]: NATT-111-E add_rule(): PF ioctl DIOCADDRULE failed Jul 20 10:44:11 fw1 kernel: Jul 20 10:44:11 fw1 HTTP[7607]: NATT-701-E addnatmap out(): Adding TCP NAT MAP from [127.0.0.1]:60860 to [212.80.76.13]:80 -> [193.179.161.10]:60860 failed Jul 20 10:44:11 fw1 kernel: Jul 20 10:44:11 fw1 HTTP[7607]: NETL-210-E netbind(server,10): NAT binding failed Kernel often reports "pool_ticket: 1429 != 1430" (with increasing numbers over time). Thank you very much for any advice. Regards Michal From owner-freebsd-stable@FreeBSD.ORG Thu Jul 20 16:02:04 2006 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 440A916A4DA for ; Thu, 20 Jul 2006 16:02:04 +0000 (UTC) (envelope-from mike@jellydonut.org) Received: from mail.secureworks.net (mail.secureworks.net [65.114.32.155]) by mx1.FreeBSD.org (Postfix) with SMTP id B30B343D53 for ; Thu, 20 Jul 2006 16:02:03 +0000 (GMT) (envelope-from mike@jellydonut.org) Received: (qmail 24965 invoked from network); 20 Jul 2006 16:02:01 -0000 Received: from unknown (HELO ?192.168.14.135?) (63.239.86.253) by 0 with SMTP; 20 Jul 2006 16:02:01 -0000 Message-ID: <44BFA8F9.8010403@jellydonut.org> Date: Thu, 20 Jul 2006 12:02:01 -0400 From: Michael Proto User-Agent: Thunderbird 1.5.0.4 (X11/20060627) MIME-Version: 1.0 To: Michal Mertl References: <1153410809.1126.66.camel@genius.i.cz> In-Reply-To: <1153410809.1126.66.camel@genius.i.cz> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org Subject: Re: Kernel panic with PF X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jul 2006 16:02:04 -0000 Michal Mertl wrote: > Hello, > > I am deploying FreeBSD based application proxies' based firewall > (www.kernun.com, but not much English there) and am having frequent > panics of RELENG_6_1 under load. The server has IP forwarding disabled. > > I've got two machines in a carp cluster and the transparent proxies use > PF to get the data. > > I don't know much about kernel internals and PF but from the following > backtrace I understand that the crash happens because rpool->cur on line > 2158 in src/sys/contrib/pf/net/pf.c is NULL and is dereferenced. It > probably shouldn't happen yet it does. > > The machines are SMP and were running SMP kernel. The only places where > pool.cur (or pool->cur) is assigned to are in pf_ioctl.c. It seems there > are some lock operations though so it is probably believed that the > coder is properly locked. > > I have been running with kern.smp.disabled=1 for a moment before I put > the old firewall in place and haven't seen the panic but the time was > deffinitely too short to make me believe it fixes the issue. Can setting > debug.mpsafenet to 0 possibly also help? > ... Are you using user and/or group rules in your PF ruleset? If so, then you will want to set debug.mpsafenet to 0 as its a known issue with pf(4) currently. -Proto From owner-freebsd-stable@FreeBSD.ORG Thu Jul 20 19:25:19 2006 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id F1D1016A4DD for ; Thu, 20 Jul 2006 19:25:19 +0000 (UTC) (envelope-from vsemionov@gmail.com) Received: from ug-out-1314.google.com (ug-out-1314.google.com [66.249.92.169]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3568343D45 for ; Thu, 20 Jul 2006 19:25:18 +0000 (GMT) (envelope-from vsemionov@gmail.com) Received: by ug-out-1314.google.com with SMTP id m2so994965uge for ; Thu, 20 Jul 2006 12:25:17 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:from:to:subject:date:user-agent:references:in-reply-to:cc:mime-version:content-type:content-transfer-encoding:content-disposition:message-id; b=K6HIVaN6N/rKrh3CdYXuc+Hbma2Lywznc69BqaE2DD6qeXbZd8b6tYRNxjd2je4qu7KFAdQJqeqUrOwzS8DARfp/cVJ/i2KpYASTypSiK2WQH64CFVp6isQqpQ09q8IlwGbGsd51xUw54dwgSivwxHhTg70IIm0zYx014E16xs4= Received: by 10.67.89.5 with SMTP id r5mr2248043ugl; Thu, 20 Jul 2006 12:18:07 -0700 (PDT) Received: from neon.devian.bg ( [83.148.125.201]) by mx.gmail.com with ESMTP id e1sm759426ugf.2006.07.20.12.18.06; Thu, 20 Jul 2006 12:18:06 -0700 (PDT) From: Victor Semionov To: freebsd-stable@freebsd.org Date: Thu, 20 Jul 2006 22:08:35 +0300 User-Agent: KMail/1.9.3 References: <44BFA45C.5050108@errno.com> In-Reply-To: <44BFA45C.5050108@errno.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200607202208.35435.vsemionov@gmail.com> Cc: Subject: Re: ath driver transmits frames only after a low watermark is filled X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jul 2006 19:25:20 -0000 > The original posting didn't provide any basic info so there's little > anyone can provide except wild guesses. There are debugging mechanisms > for tracing what's going on at the net80211 layer and in the driver that > have been referenced countless times in this forum. Sorry, didn't know it could be hardware-related. What info do you need? From owner-freebsd-stable@FreeBSD.ORG Thu Jul 20 21:05:29 2006 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A438516A4E1 for ; Thu, 20 Jul 2006 21:05:29 +0000 (UTC) (envelope-from josh@tcbug.org) Received: from sccrmhc12.comcast.net (sccrmhc12.comcast.net [204.127.200.82]) by mx1.FreeBSD.org (Postfix) with ESMTP id 462E443D45 for ; Thu, 20 Jul 2006 21:05:29 +0000 (GMT) (envelope-from josh@tcbug.org) Received: from gimpy (c-24-118-173-219.hsd1.mn.comcast.net[24.118.173.219]) by comcast.net (sccrmhc12) with ESMTP id <2006072021052401200023k5e>; Thu, 20 Jul 2006 21:05:28 +0000 From: Josh Paetzel To: freebsd-stable@freebsd.org, nealie@kobudo.homeunix.net Date: Thu, 20 Jul 2006 16:05:23 -0500 User-Agent: KMail/1.9.1 References: <1153396289.823.16.camel@server.home> In-Reply-To: <1153396289.823.16.camel@server.home> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200607201605.23862.josh@tcbug.org> Cc: Subject: Re: NVIDIA 6600GT Freeze X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jul 2006 21:05:29 -0000 On Thursday 20 July 2006 06:51, Nealie wrote: > I have a problem with my system freezing when using an NVIDIA video > card using the nvidia-driver port. All seems to work fine for a > while but then the system freezes and won't even reply to a ping. > This can happen regardless of whether I use openGL or not. > > Everything works fine using the "nv" driver, so it doesn't seem to > be a hardware problem. > > My setup is as follows: > > uname: FreeBSD server.home 6.1-STABLE FreeBSD 6.1-STABLE #0: Wed > Jul 19 11:19:16 CEST 2006 > root@server.home:/usr/obj/usr/src/sys/SERVER i386 > > AGP NVIDIA 6600GT installed on an MSI K8T Neo-F V2.09 motherboard > (VIA K8T800 Pro chipset) with an AMD Athlon 64 3500+ CPU. > > The NVIDIA driver is installed as per the instructions, with agp > and dri removed from the kernel in order to use the NVIDIA agp > interface, even though the sysctl settings suggest otherwise. > > If anyone has any ideas about this problem I'd be very grateful. > This probably isn't very helpful but I have nearly the exact same setup and it works fine. The only differences I see is that I'm running 6.1-RELEASE and my motherboard is an asus based on the K8T800 chipset. -- Thanks, Josh Paetzel From owner-freebsd-stable@FreeBSD.ORG Thu Jul 20 22:08:38 2006 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DFDE516A4DF for ; Thu, 20 Jul 2006 22:08:38 +0000 (UTC) (envelope-from bsdbitbucket@gmail.com) Received: from ug-out-1314.google.com (ug-out-1314.google.com [66.249.92.172]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2FDD243D45 for ; Thu, 20 Jul 2006 22:08:37 +0000 (GMT) (envelope-from bsdbitbucket@gmail.com) Received: by ug-out-1314.google.com with SMTP id m2so1065014uge for ; Thu, 20 Jul 2006 15:08:37 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:mime-version:content-type; b=pYNUxQUDe180umfRxWadkDK633T3hsrkGJhgfhQGN3sTTaOXUtCqrAXjVfmCjFR1ojkG44pWL3pOFymuP2/sC8btOeefNrVFxATKWNwQ7YJ5MqbROVl2tTUULieM1B8nXmCoNzT/QVOc8EJ5sQhj7cuAE95JyycjZLz4RrgKdAc= Received: by 10.78.159.7 with SMTP id h7mr962444hue; Thu, 20 Jul 2006 15:08:36 -0700 (PDT) Received: by 10.78.141.17 with HTTP; Thu, 20 Jul 2006 15:08:36 -0700 (PDT) Message-ID: <39bc55550607201508h22def04cpecb99bf9fefc950b@mail.gmail.com> Date: Thu, 20 Jul 2006 18:08:36 -0400 From: "freebsd freebsd" To: freebsd-stable@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Major problem with make buildworld 6.1-STABLE X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jul 2006 22:08:39 -0000 I didn't like how my partitions were set up so I decided to reinstall 6.1from scratch, but now I cannot finish a buildworld no matter what I do. In order, I've: 1. Installed 6.1-RELEASE from ftp on fresh partitions 1a. installed cvsup and perl-5.8.8 from /usr/ports 2. edit cvsup11 into /usr/share/examples/cvsup/stable-supfile 3. cvsup /usr/share/examples/cvsup/stable-supfile 4. rm -rf /usr/obj/* 5. cd /usr/src/; 6. make clean && make clean 7. make buildworld and I get: cc -O2 -fno-strict-aliasing -pipe -DIN_GCC -DHAVE_LD_EH_FRAME_HDR -finhibit-size-directive -fno-inline-functions -fno-exceptions -fno-zero-initialized-in-bss -fno-omit-frame-pointer -fno-unit-at-a-time -I/usr/src/gnu/lib/csu/../../../contrib/gcc/config -I/usr/src/gnu/lib/csu/../../../contrib/gcc -I. -I/usr/src/gnu/lib/csu/../../usr.bin/cc/cc_tools -g0 -DCRT_BEGIN -c -o crtbegin.o /usr/src/gnu/lib/csu/../../../contrib/gcc/crtstuff.c In file included from /usr/src/gnu/lib/csu/../../../contrib/gcc/crtstuff.c:65: /usr/src/gnu/lib/csu/../../../contrib/gcc/unwind-dw2-fde.h: In function `const dwarf_cie* get_cie(const dwarf_fde*)': /usr/src/gnu/lib/csu/../../../contrib/gcc/unwind-dw2-fde.h:159: error: pointer of type `void *' used in arithmetic /usr/src/gnu/lib/csu/../../../contrib/gcc/unwind-dw2-fde.h:159: error: invalid conversion from `void*' to `const dwarf_cie*' /usr/src/gnu/lib/csu/../../../contrib/gcc/crtstuff.c: In function `void __do_global_dtors_aux()': /usr/src/gnu/lib/csu/../../../contrib/gcc/crtstuff.c:258: error: `_Bool' does not name a type /usr/src/gnu/lib/csu/../../../contrib/gcc/crtstuff.c:261: error: `completed' undeclared (first use this function) /usr/src/gnu/lib/csu/../../../contrib/gcc/crtstuff.c:261: error: (Each undeclared identifier is reported only once for each function it appears in.) *** Error code 1 Stop in /usr/src/gnu/lib/csu. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. This is the first time I ran just "make buildworld:. I've tried this several times with make -j4 buildworld, but the build always dies while making libgcc instead of crtstuff. I've reinstalled from ftp again (and again) and always the same. Is there a bug in the stable sources? Am I missing something? Thanks! From owner-freebsd-stable@FreeBSD.ORG Thu Jul 20 22:18:12 2006 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id AA22C16A4DA for ; Thu, 20 Jul 2006 22:18:12 +0000 (UTC) (envelope-from mime@traveller.cz) Received: from ss.eunet.cz (ss.eunet.cz [193.85.228.13]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1DF6443D45 for ; Thu, 20 Jul 2006 22:18:11 +0000 (GMT) (envelope-from mime@traveller.cz) Received: from localhost.i.cz (ss.eunet.cz [193.85.228.13]) by ss.eunet.cz (8.13.6/8.13.6) with ESMTP id k6KMI9hF019544 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Fri, 21 Jul 2006 00:18:09 +0200 (CEST) (envelope-from mime@traveller.cz) From: Michal Mertl To: Michael Proto In-Reply-To: <44BFA8F9.8010403@jellydonut.org> References: <1153410809.1126.66.camel@genius.i.cz> <44BFA8F9.8010403@jellydonut.org> Content-Type: text/plain Date: Fri, 21 Jul 2006 00:18:01 +0200 Message-Id: <1153433881.1173.3.camel@genius.i.cz> Mime-Version: 1.0 X-Mailer: Evolution 2.6.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org Subject: Re: Kernel panic with PF X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jul 2006 22:18:12 -0000 Michael Proto wrote: > Michal Mertl wrote: > > Hello, > > > > I am deploying FreeBSD based application proxies' based firewall > > (www.kernun.com, but not much English there) and am having frequent > > panics of RELENG_6_1 under load. The server has IP forwarding disabled. > > > > I've got two machines in a carp cluster and the transparent proxies use > > PF to get the data. > > > > I don't know much about kernel internals and PF but from the following > > backtrace I understand that the crash happens because rpool->cur on line > > 2158 in src/sys/contrib/pf/net/pf.c is NULL and is dereferenced. It > > probably shouldn't happen yet it does. > > > > The machines are SMP and were running SMP kernel. The only places where > > pool.cur (or pool->cur) is assigned to are in pf_ioctl.c. It seems there > > are some lock operations though so it is probably believed that the > > coder is properly locked. > > > > I have been running with kern.smp.disabled=1 for a moment before I put > > the old firewall in place and haven't seen the panic but the time was > > deffinitely too short to make me believe it fixes the issue. Can setting > > debug.mpsafenet to 0 possibly also help? > > > ... > > Are you using user and/or group rules in your PF ruleset? If so, then > you will want to set debug.mpsafenet to 0 as its a known issue with > pf(4) currently. Thank you. No, I am not using it and I am quite sure the proxies aren't doing it behind my back either. In fact there isn't a single entry in the rules tables - there are only rdr rules generated on the fly by the proxies. I will try to set this (in addition to running UP) to see whether it helps anyway. Thanks Michal From owner-freebsd-stable@FreeBSD.ORG Thu Jul 20 22:46:36 2006 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id F38C116A4DD for ; Thu, 20 Jul 2006 22:46:35 +0000 (UTC) (envelope-from henrik@brixandersen.dk) Received: from ns2.pil.dk (ns2.pil.dk [195.41.47.38]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7394443D4C for ; Thu, 20 Jul 2006 22:46:34 +0000 (GMT) (envelope-from henrik@brixandersen.dk) Received: from osgiliath.brixandersen.dk (osgiliath.brixandersen.dk [87.53.223.189]) by ns2.pil.dk (Postfix) with ESMTP id C85727BA8D7 for ; Fri, 21 Jul 2006 00:46:32 +0200 (CEST) Received: by osgiliath.brixandersen.dk (Postfix, from userid 1000) id 51C84A433D; Fri, 21 Jul 2006 00:46:32 +0200 (CEST) Date: Fri, 21 Jul 2006 00:46:32 +0200 From: Henrik Brix Andersen To: freebsd-stable@freebsd.org Message-ID: <20060720224632.GB31459@osgiliath.brixandersen.dk> Mail-Followup-To: freebsd-stable@freebsd.org Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="OgqxwSJOaUobr8KG" Content-Disposition: inline X-PGP-Key: http://dev.gentoo.org/~brix/files/HenrikBrixAndersen.asc User-Agent: Mutt/1.5.11 Subject: "scan stuck" with if_iwi(4) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jul 2006 22:46:36 -0000 --OgqxwSJOaUobr8KG Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi, I recently upgraded my IBM ThinkPad X31 from 6.1-RELEASE to 6.1-STABLE after which the if_iwi(4) driver started dropping the connection at regular intervals when connected to my hostapd-based AP using WPA2 PSK CCMP. The dmesg output with debug.iwi=3D4 is listed below - it fails regularly (every 3 mins or so) with the message "scan stuck" after which the adapter is reinitialized and the connection lost for some seconds. The connection drop seems to be caused by the adapter suddently entering the SCAN state. I have been unable to reproduce this problem with 6.1-RELEASE. $ uname -a FreeBSD fangorn.brixandersen.dk 6.1-STABLE FreeBSD 6.1-STABLE #2: Tue Jul 1= 8 11:16:02 CEST 2006 root@fangorn.brixandersen.dk:/usr/obj/usr/src/sys/= GENERIC i386 Jul 20 23:38:04 fangorn kernel: iwi0: mem 0= xc0200000-0xc0200fff irq 11 at device 2.0 on pci2 Jul 20 23:38:04 fangorn kernel: iwi0: Ethernet address: 00:0e:35:fd:81:94 =2E.. Jul 21 00:19:26 fangorn kernel: Beacon miss: 7 >=3D 7 Jul 21 00:20:24 fangorn kernel: Beacon miss: 7 >=3D 7 Jul 21 00:20:24 fangorn kernel: iwi_newstate: RUN -> SCAN flags 0x11 Jul 21 00:20:24 fangorn kernel: iwi0: link state changed to DOWN Jul 21 00:20:24 fangorn kernel: iwi_newstate: INIT -> SCAN flags 0x11 Jul 21 00:20:24 fangorn kernel: iwi_newstate: SCAN -> SCAN flags 0x13 Jul 21 00:20:24 fangorn kernel: Start scanning Jul 21 00:20:24 fangorn kernel: sending command idx=3D5 type=3D26 len=3D96 Jul 21 00:20:24 fangorn kernel: Beacon miss: 8 >=3D 7 Jul 21 00:20:24 fangorn kernel: Beacon miss: 9 >=3D 7 Jul 21 00:20:30 fangorn kernel: iwi0: scan stuck Jul 21 00:20:30 fangorn kernel: iwi_newstate: SCAN -> INIT flags 0x0 Jul 21 00:20:31 fangorn kernel: Setting MAC address to 00:0e:35:fd:81:94 Jul 21 00:20:31 fangorn kernel: sending command idx=3D0 type=3D11 len=3D6 Jul 21 00:20:31 fangorn kernel: Configuring adapter Jul 21 00:20:31 fangorn kernel: sending command idx=3D1 type=3D6 len=3D20 Jul 21 00:20:31 fangorn kernel: Setting power mode to 0 Jul 21 00:20:31 fangorn kernel: sending command idx=3D2 type=3D17 len=3D4 Jul 21 00:20:31 fangorn kernel: Setting RTS threshold to 2346 Jul 21 00:20:31 fangorn kernel: sending command idx=3D3 type=3D15 len=3D4 Jul 21 00:20:31 fangorn kernel: Setting fragmentation threshold to 2346 Jul 21 00:20:31 fangorn kernel: sending command idx=3D4 type=3D16 len=3D4 Jul 21 00:20:31 fangorn kernel: Setting .11bg supported rates (12) Jul 21 00:20:31 fangorn kernel: sending command idx=3D5 type=3D22 len=3D16 Jul 21 00:20:31 fangorn kernel: Setting .11a supported rates (8) Jul 21 00:20:31 fangorn kernel: sending command idx=3D6 type=3D22 len=3D16 Jul 21 00:20:31 fangorn kernel: Setting initialization vector to 1069254139 Jul 21 00:20:31 fangorn kernel: sending command idx=3D7 type=3D34 len=3D4 Jul 21 00:20:31 fangorn kernel: Setting wep key index 0 len 0 Jul 21 00:20:31 fangorn kernel: sending command idx=3D8 type=3D18 len=3D20 Jul 21 00:20:31 fangorn kernel: Setting wep key index 1 len 0 Jul 21 00:20:31 fangorn kernel: sending command idx=3D9 type=3D18 len=3D20 Jul 21 00:20:31 fangorn kernel: Setting wep key index 2 len 0 Jul 21 00:20:31 fangorn kernel: sending command idx=3D10 type=3D18 len=3D20 Jul 21 00:20:31 fangorn kernel: Setting wep key index 3 len 0 Jul 21 00:20:31 fangorn kernel: sending command idx=3D11 type=3D18 len=3D20 Jul 21 00:20:31 fangorn kernel: Enabling adapter Jul 21 00:20:31 fangorn kernel: sending command idx=3D12 type=3D2 len=3D0 Jul 21 00:20:31 fangorn kernel: iwi_newstate: INIT -> SCAN flags 0x5 Jul 21 00:20:31 fangorn kernel: iwi_newstate: SCAN -> SCAN flags 0x3 Jul 21 00:20:31 fangorn kernel: Start scanning Jul 21 00:20:31 fangorn kernel: sending command idx=3D13 type=3D26 len=3D96 Jul 21 00:20:31 fangorn kernel: Scan of channel 5180 complete (36) Jul 21 00:20:31 fangorn kernel: Scan of channel 5200 complete (40) Jul 21 00:20:31 fangorn kernel: Scan of channel 5220 complete (44) Jul 21 00:20:31 fangorn kernel: Scan of channel 5240 complete (48) Jul 21 00:20:31 fangorn kernel: Scan of channel 5260 complete (52) Jul 21 00:20:31 fangorn kernel: Scan of channel 5280 complete (56) Jul 21 00:20:31 fangorn kernel: Scan of channel 5300 complete (60) Jul 21 00:20:31 fangorn kernel: Scan of channel 5320 complete (64) Jul 21 00:20:32 fangorn kernel: Scan of channel 5745 complete (149) Jul 21 00:20:32 fangorn kernel: Scan of channel 5765 complete (153) Jul 21 00:20:32 fangorn kernel: Scan of channel 5785 complete (157) Jul 21 00:20:32 fangorn kernel: Scan of channel 5805 complete (161) Jul 21 00:20:32 fangorn kernel: Scan of channel 5825 complete (165) Jul 21 00:20:32 fangorn kernel: Scan of channel 2412 complete (1) Jul 21 00:20:32 fangorn kernel: Scan of channel 2417 complete (2) Jul 21 00:20:32 fangorn kernel: Scan of channel 2422 complete (3) Jul 21 00:20:32 fangorn kernel: Scan of channel 2427 complete (4) Jul 21 00:20:33 fangorn kernel: Scan of channel 2432 complete (5) Jul 21 00:20:33 fangorn kernel: Scan of channel 2437 complete (6) Jul 21 00:20:33 fangorn kernel: Scan of channel 2442 complete (7) Jul 21 00:20:33 fangorn kernel: Scan of channel 2447 complete (8) Jul 21 00:20:33 fangorn kernel: Scan of channel 2452 complete (9) Jul 21 00:20:33 fangorn kernel: Scan of channel 2457 complete (10) Jul 21 00:20:33 fangorn kernel: Scan of channel 2462 complete (11) Jul 21 00:20:33 fangorn kernel: Scan of channel 2467 complete (12) Jul 21 00:20:33 fangorn kernel: Scan of channel 2472 complete (13) Jul 21 00:20:33 fangorn kernel: Scan of channel 2484 complete (14) Jul 21 00:20:33 fangorn kernel: Scan completed (27, 1) Jul 21 00:20:38 fangorn kernel: iwi_newstate: INIT -> SCAN flags 0x1 Jul 21 00:20:38 fangorn kernel: iwi_newstate: SCAN -> SCAN flags 0x3 Jul 21 00:20:38 fangorn kernel: Start scanning Jul 21 00:20:38 fangorn kernel: sending command idx=3D14 type=3D26 len=3D96 Jul 21 00:20:39 fangorn kernel: Scan of channel 5180 complete (36) Jul 21 00:20:39 fangorn kernel: Scan of channel 5200 complete (40) Jul 21 00:20:39 fangorn kernel: Scan of channel 5220 complete (44) Jul 21 00:20:39 fangorn kernel: Scan of channel 5240 complete (48) Jul 21 00:20:39 fangorn kernel: Scan of channel 5260 complete (52) Jul 21 00:20:39 fangorn kernel: Scan of channel 5280 complete (56) Jul 21 00:20:39 fangorn kernel: Scan of channel 5300 complete (60) Jul 21 00:20:39 fangorn kernel: Scan of channel 5320 complete (64) Jul 21 00:20:39 fangorn kernel: Scan of channel 5745 complete (149) Jul 21 00:20:40 fangorn kernel: Scan of channel 5765 complete (153) Jul 21 00:20:40 fangorn kernel: Scan of channel 5785 complete (157) Jul 21 00:20:40 fangorn kernel: Scan of channel 5805 complete (161) Jul 21 00:20:40 fangorn kernel: Scan of channel 5825 complete (165) Jul 21 00:20:40 fangorn kernel: Scan of channel 2412 complete (1) Jul 21 00:20:40 fangorn kernel: Scan of channel 2417 complete (2) Jul 21 00:20:40 fangorn kernel: Scan of channel 2422 complete (3) Jul 21 00:20:40 fangorn kernel: Scan of channel 2427 complete (4) Jul 21 00:20:40 fangorn kernel: Scan of channel 2432 complete (5) Jul 21 00:20:40 fangorn kernel: Scan of channel 2437 complete (6) Jul 21 00:20:41 fangorn kernel: Scan of channel 2442 complete (7) Jul 21 00:20:41 fangorn kernel: Scan of channel 2447 complete (8) Jul 21 00:20:41 fangorn kernel: Scan of channel 2452 complete (9) Jul 21 00:20:41 fangorn kernel: Scan of channel 2457 complete (10) Jul 21 00:20:41 fangorn kernel: Scan of channel 2462 complete (11) Jul 21 00:20:41 fangorn kernel: Scan of channel 2467 complete (12) Jul 21 00:20:41 fangorn kernel: Scan of channel 2472 complete (13) Jul 21 00:20:41 fangorn kernel: Scan of channel 2484 complete (14) Jul 21 00:20:41 fangorn kernel: Scan completed (27, 1) Jul 21 00:20:41 fangorn kernel: iwi_newstate: SCAN -> AUTH flags 0x1 Jul 21 00:20:41 fangorn kernel: Configuring adapter Jul 21 00:20:41 fangorn kernel: sending command idx=3D15 type=3D6 len=3D20 Jul 21 00:20:41 fangorn kernel: Setting ESSID to "brix" Jul 21 00:20:41 fangorn kernel: sending command idx=3D0 type=3D8 len=3D4 Jul 21 00:20:41 fangorn kernel: Setting negotiated rates (4) Jul 21 00:20:41 fangorn kernel: sending command idx=3D1 type=3D22 len=3D16 Jul 21 00:20:41 fangorn kernel: Setting optional IE (len=3D24) Jul 21 00:20:41 fangorn kernel: sending command idx=3D2 type=3D31 len=3D24 Jul 21 00:20:41 fangorn kernel: Setting sensitivity to 39 Jul 21 00:20:41 fangorn kernel: sending command idx=3D3 type=3D42 len=3D4 Jul 21 00:20:41 fangorn kernel: Join bssid 00:02:6f:37:fc:68 dst 00:02:6f:3= 7:fc:68 channel 1 policy 0x2 auth 0 capinfo 0x31 li ntval 100 bintval 100 Jul 21 00:20:41 fangorn kernel: sending command idx=3D4 type=3D21 len=3D40 Jul 21 00:20:41 fangorn kernel: Authentication succeeeded Jul 21 00:20:41 fangorn kernel: iwi_newstate: AUTH -> ASSOC flags 0x1 Jul 21 00:20:41 fangorn kernel: Association succeeded Jul 21 00:20:41 fangorn kernel: iwi_newstate: ASSOC -> RUN flags 0x11 Jul 21 00:20:41 fangorn kernel: iwi0: link state changed to UP Jul 21 00:20:49 fangorn dhclient: New IP Address (iwi0): 10.0.0.56 Jul 21 00:20:49 fangorn dhclient: New Subnet Mask (iwi0): 255.255.255.0 Jul 21 00:20:49 fangorn dhclient: New Broadcast Address (iwi0): 10.0.0.255 Jul 21 00:20:49 fangorn dhclient: New Routers (iwi0): 10.0.0.1 Regards, Brix --=20 Henrik Brix Andersen --OgqxwSJOaUobr8KG Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.4 (GNU/Linux) Comment: GnuPG signed iD8DBQFEwAfHv+Q4flTiePgRAsm+AKCHxTLISuUThpBsVYs1fHmoaFRKqQCeNVwZ eanOB/qxTiC45sRNPOU9lWI= =zUUg -----END PGP SIGNATURE----- --OgqxwSJOaUobr8KG-- From owner-freebsd-stable@FreeBSD.ORG Thu Jul 20 23:00:11 2006 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 70F9A16A4E0 for ; Thu, 20 Jul 2006 23:00:11 +0000 (UTC) (envelope-from Mark_Andrews@isc.org) Received: from farside.isc.org (farside.isc.org [204.152.187.5]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9343143D49 for ; Thu, 20 Jul 2006 23:00:10 +0000 (GMT) (envelope-from Mark_Andrews@isc.org) Received: from drugs.dv.isc.org (localhost.isc.org [IPv6:::1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by farside.isc.org (Postfix) with ESMTP id 046E5E601F for ; Thu, 20 Jul 2006 23:00:09 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.13.6/8.13.6) with ESMTP id k6KN067d010753 for ; Fri, 21 Jul 2006 09:00:06 +1000 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200607202300.k6KN067d010753@drugs.dv.isc.org> To: freebsd-stable@freebsd.org From: Mark Andrews Mail-Followup-To: freebsd-stable@freebsd.org In-reply-to: Your message of "Fri, 21 Jul 2006 00:46:32 +0200." <20060720224632.GB31459@osgiliath.brixandersen.dk> Date: Fri, 21 Jul 2006 09:00:06 +1000 Sender: Mark_Andrews@isc.org Subject: Re: "scan stuck" with if_iwi(4) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jul 2006 23:00:11 -0000 The iwi code was recently MFC and it required a port change iwi-firmware -> iwi-firmware-kmod. Depending on when you upgraded the src and ports you may not have seen the ports change. Mark B.T.W. the new code is more stable for me. No more complete machine lockups. The WiFi led now binks though if you turn the radio off it stays lit / off depending apon the state it was in at the time. This is still better than not lighting at all. -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark_Andrews@isc.org From owner-freebsd-stable@FreeBSD.ORG Thu Jul 20 23:01:24 2006 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 851CC16A4DA for ; Thu, 20 Jul 2006 23:01:24 +0000 (UTC) (envelope-from sam@errno.com) Received: from ebb.errno.com (ebb.errno.com [69.12.149.25]) by mx1.FreeBSD.org (Postfix) with ESMTP id AE8B843D58 for ; Thu, 20 Jul 2006 23:01:22 +0000 (GMT) (envelope-from sam@errno.com) Received: from [10.0.0.248] (trouble.errno.com [10.0.0.248]) (authenticated bits=0) by ebb.errno.com (8.13.6/8.12.6) with ESMTP id k6KN1KAn053400 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 20 Jul 2006 16:01:22 -0700 (PDT) (envelope-from sam@errno.com) Message-ID: <44C00B40.2010901@errno.com> Date: Thu, 20 Jul 2006 16:01:20 -0700 From: Sam Leffler User-Agent: Thunderbird 1.5.0.2 (X11/20060508) MIME-Version: 1.0 To: freebsd-stable@freebsd.org References: <20060720224632.GB31459@osgiliath.brixandersen.dk> In-Reply-To: <20060720224632.GB31459@osgiliath.brixandersen.dk> X-Enigmail-Version: 0.94.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: "scan stuck" with if_iwi(4) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jul 2006 23:01:24 -0000 Henrik Brix Andersen wrote: > Hi, > > I recently upgraded my IBM ThinkPad X31 from 6.1-RELEASE to 6.1-STABLE > after which the if_iwi(4) driver started dropping the connection at > regular intervals when connected to my hostapd-based AP using WPA2 PSK > CCMP. > > The dmesg output with debug.iwi=4 is listed below - it fails regularly > (every 3 mins or so) with the message "scan stuck" after which the > adapter is reinitialized and the connection lost for some seconds. > > The connection drop seems to be caused by the adapter suddently > entering the SCAN state. > > I have been unable to reproduce this problem with 6.1-RELEASE. You will not be able to reproduce the problem because the code in 6.1R ignored beacon misses (and a lot of other things). The stuck scan is not fatal; the driver just resets the card. It's caused by a firwmare problem that I never got around to dealing with ('cuz it wouldn't change the overall operation of the driver). The basic problem is your card is losing sync w/ the ap. I don't know what the local conditions are but I've seen this a lot w/ iwi; there's nothing we can do in the driver if you want to be able to roam. Sam > > $ uname -a > FreeBSD fangorn.brixandersen.dk 6.1-STABLE FreeBSD 6.1-STABLE #2: Tue Jul 18 11:16:02 CEST 2006 root@fangorn.brixandersen.dk:/usr/obj/usr/src/sys/GENERIC i386 > > > Jul 20 23:38:04 fangorn kernel: iwi0: mem 0xc0200000-0xc0200fff irq 11 at device 2.0 on pci2 > Jul 20 23:38:04 fangorn kernel: iwi0: Ethernet address: 00:0e:35:fd:81:94 > ... > Jul 21 00:19:26 fangorn kernel: Beacon miss: 7 >= 7 > Jul 21 00:20:24 fangorn kernel: Beacon miss: 7 >= 7 > Jul 21 00:20:24 fangorn kernel: iwi_newstate: RUN -> SCAN flags 0x11 > Jul 21 00:20:24 fangorn kernel: iwi0: link state changed to DOWN > Jul 21 00:20:24 fangorn kernel: iwi_newstate: INIT -> SCAN flags 0x11 > Jul 21 00:20:24 fangorn kernel: iwi_newstate: SCAN -> SCAN flags 0x13 > Jul 21 00:20:24 fangorn kernel: Start scanning > Jul 21 00:20:24 fangorn kernel: sending command idx=5 type=26 len=96 > Jul 21 00:20:24 fangorn kernel: Beacon miss: 8 >= 7 > Jul 21 00:20:24 fangorn kernel: Beacon miss: 9 >= 7 > Jul 21 00:20:30 fangorn kernel: iwi0: scan stuck > Jul 21 00:20:30 fangorn kernel: iwi_newstate: SCAN -> INIT flags 0x0 > Jul 21 00:20:31 fangorn kernel: Setting MAC address to 00:0e:35:fd:81:94 > Jul 21 00:20:31 fangorn kernel: sending command idx=0 type=11 len=6 > Jul 21 00:20:31 fangorn kernel: Configuring adapter > Jul 21 00:20:31 fangorn kernel: sending command idx=1 type=6 len=20 > Jul 21 00:20:31 fangorn kernel: Setting power mode to 0 > Jul 21 00:20:31 fangorn kernel: sending command idx=2 type=17 len=4 > Jul 21 00:20:31 fangorn kernel: Setting RTS threshold to 2346 > Jul 21 00:20:31 fangorn kernel: sending command idx=3 type=15 len=4 > Jul 21 00:20:31 fangorn kernel: Setting fragmentation threshold to 2346 > Jul 21 00:20:31 fangorn kernel: sending command idx=4 type=16 len=4 > Jul 21 00:20:31 fangorn kernel: Setting .11bg supported rates (12) > Jul 21 00:20:31 fangorn kernel: sending command idx=5 type=22 len=16 > Jul 21 00:20:31 fangorn kernel: Setting .11a supported rates (8) > Jul 21 00:20:31 fangorn kernel: sending command idx=6 type=22 len=16 > Jul 21 00:20:31 fangorn kernel: Setting initialization vector to 1069254139 > Jul 21 00:20:31 fangorn kernel: sending command idx=7 type=34 len=4 > Jul 21 00:20:31 fangorn kernel: Setting wep key index 0 len 0 > Jul 21 00:20:31 fangorn kernel: sending command idx=8 type=18 len=20 > Jul 21 00:20:31 fangorn kernel: Setting wep key index 1 len 0 > Jul 21 00:20:31 fangorn kernel: sending command idx=9 type=18 len=20 > Jul 21 00:20:31 fangorn kernel: Setting wep key index 2 len 0 > Jul 21 00:20:31 fangorn kernel: sending command idx=10 type=18 len=20 > Jul 21 00:20:31 fangorn kernel: Setting wep key index 3 len 0 > Jul 21 00:20:31 fangorn kernel: sending command idx=11 type=18 len=20 > Jul 21 00:20:31 fangorn kernel: Enabling adapter > Jul 21 00:20:31 fangorn kernel: sending command idx=12 type=2 len=0 > Jul 21 00:20:31 fangorn kernel: iwi_newstate: INIT -> SCAN flags 0x5 > Jul 21 00:20:31 fangorn kernel: iwi_newstate: SCAN -> SCAN flags 0x3 > Jul 21 00:20:31 fangorn kernel: Start scanning > Jul 21 00:20:31 fangorn kernel: sending command idx=13 type=26 len=96 > Jul 21 00:20:31 fangorn kernel: Scan of channel 5180 complete (36) > Jul 21 00:20:31 fangorn kernel: Scan of channel 5200 complete (40) > Jul 21 00:20:31 fangorn kernel: Scan of channel 5220 complete (44) > Jul 21 00:20:31 fangorn kernel: Scan of channel 5240 complete (48) > Jul 21 00:20:31 fangorn kernel: Scan of channel 5260 complete (52) > Jul 21 00:20:31 fangorn kernel: Scan of channel 5280 complete (56) > Jul 21 00:20:31 fangorn kernel: Scan of channel 5300 complete (60) > Jul 21 00:20:31 fangorn kernel: Scan of channel 5320 complete (64) > Jul 21 00:20:32 fangorn kernel: Scan of channel 5745 complete (149) > Jul 21 00:20:32 fangorn kernel: Scan of channel 5765 complete (153) > Jul 21 00:20:32 fangorn kernel: Scan of channel 5785 complete (157) > Jul 21 00:20:32 fangorn kernel: Scan of channel 5805 complete (161) > Jul 21 00:20:32 fangorn kernel: Scan of channel 5825 complete (165) > Jul 21 00:20:32 fangorn kernel: Scan of channel 2412 complete (1) > Jul 21 00:20:32 fangorn kernel: Scan of channel 2417 complete (2) > Jul 21 00:20:32 fangorn kernel: Scan of channel 2422 complete (3) > Jul 21 00:20:32 fangorn kernel: Scan of channel 2427 complete (4) > Jul 21 00:20:33 fangorn kernel: Scan of channel 2432 complete (5) > Jul 21 00:20:33 fangorn kernel: Scan of channel 2437 complete (6) > Jul 21 00:20:33 fangorn kernel: Scan of channel 2442 complete (7) > Jul 21 00:20:33 fangorn kernel: Scan of channel 2447 complete (8) > Jul 21 00:20:33 fangorn kernel: Scan of channel 2452 complete (9) > Jul 21 00:20:33 fangorn kernel: Scan of channel 2457 complete (10) > Jul 21 00:20:33 fangorn kernel: Scan of channel 2462 complete (11) > Jul 21 00:20:33 fangorn kernel: Scan of channel 2467 complete (12) > Jul 21 00:20:33 fangorn kernel: Scan of channel 2472 complete (13) > Jul 21 00:20:33 fangorn kernel: Scan of channel 2484 complete (14) > Jul 21 00:20:33 fangorn kernel: Scan completed (27, 1) > Jul 21 00:20:38 fangorn kernel: iwi_newstate: INIT -> SCAN flags 0x1 > Jul 21 00:20:38 fangorn kernel: iwi_newstate: SCAN -> SCAN flags 0x3 > Jul 21 00:20:38 fangorn kernel: Start scanning > Jul 21 00:20:38 fangorn kernel: sending command idx=14 type=26 len=96 > Jul 21 00:20:39 fangorn kernel: Scan of channel 5180 complete (36) > Jul 21 00:20:39 fangorn kernel: Scan of channel 5200 complete (40) > Jul 21 00:20:39 fangorn kernel: Scan of channel 5220 complete (44) > Jul 21 00:20:39 fangorn kernel: Scan of channel 5240 complete (48) > Jul 21 00:20:39 fangorn kernel: Scan of channel 5260 complete (52) > Jul 21 00:20:39 fangorn kernel: Scan of channel 5280 complete (56) > Jul 21 00:20:39 fangorn kernel: Scan of channel 5300 complete (60) > Jul 21 00:20:39 fangorn kernel: Scan of channel 5320 complete (64) > Jul 21 00:20:39 fangorn kernel: Scan of channel 5745 complete (149) > Jul 21 00:20:40 fangorn kernel: Scan of channel 5765 complete (153) > Jul 21 00:20:40 fangorn kernel: Scan of channel 5785 complete (157) > Jul 21 00:20:40 fangorn kernel: Scan of channel 5805 complete (161) > Jul 21 00:20:40 fangorn kernel: Scan of channel 5825 complete (165) > Jul 21 00:20:40 fangorn kernel: Scan of channel 2412 complete (1) > Jul 21 00:20:40 fangorn kernel: Scan of channel 2417 complete (2) > Jul 21 00:20:40 fangorn kernel: Scan of channel 2422 complete (3) > Jul 21 00:20:40 fangorn kernel: Scan of channel 2427 complete (4) > Jul 21 00:20:40 fangorn kernel: Scan of channel 2432 complete (5) > Jul 21 00:20:40 fangorn kernel: Scan of channel 2437 complete (6) > Jul 21 00:20:41 fangorn kernel: Scan of channel 2442 complete (7) > Jul 21 00:20:41 fangorn kernel: Scan of channel 2447 complete (8) > Jul 21 00:20:41 fangorn kernel: Scan of channel 2452 complete (9) > Jul 21 00:20:41 fangorn kernel: Scan of channel 2457 complete (10) > Jul 21 00:20:41 fangorn kernel: Scan of channel 2462 complete (11) > Jul 21 00:20:41 fangorn kernel: Scan of channel 2467 complete (12) > Jul 21 00:20:41 fangorn kernel: Scan of channel 2472 complete (13) > Jul 21 00:20:41 fangorn kernel: Scan of channel 2484 complete (14) > Jul 21 00:20:41 fangorn kernel: Scan completed (27, 1) > Jul 21 00:20:41 fangorn kernel: iwi_newstate: SCAN -> AUTH flags 0x1 > Jul 21 00:20:41 fangorn kernel: Configuring adapter > Jul 21 00:20:41 fangorn kernel: sending command idx=15 type=6 len=20 > Jul 21 00:20:41 fangorn kernel: Setting ESSID to "brix" > Jul 21 00:20:41 fangorn kernel: sending command idx=0 type=8 len=4 > Jul 21 00:20:41 fangorn kernel: Setting negotiated rates (4) > Jul 21 00:20:41 fangorn kernel: sending command idx=1 type=22 len=16 > Jul 21 00:20:41 fangorn kernel: Setting optional IE (len=24) > Jul 21 00:20:41 fangorn kernel: sending command idx=2 type=31 len=24 > Jul 21 00:20:41 fangorn kernel: Setting sensitivity to 39 > Jul 21 00:20:41 fangorn kernel: sending command idx=3 type=42 len=4 > Jul 21 00:20:41 fangorn kernel: Join bssid 00:02:6f:37:fc:68 dst 00:02:6f:37:fc:68 channel 1 policy 0x2 auth 0 capinfo 0x31 li > ntval 100 bintval 100 > Jul 21 00:20:41 fangorn kernel: sending command idx=4 type=21 len=40 > Jul 21 00:20:41 fangorn kernel: Authentication succeeeded > Jul 21 00:20:41 fangorn kernel: iwi_newstate: AUTH -> ASSOC flags 0x1 > Jul 21 00:20:41 fangorn kernel: Association succeeded > Jul 21 00:20:41 fangorn kernel: iwi_newstate: ASSOC -> RUN flags 0x11 > Jul 21 00:20:41 fangorn kernel: iwi0: link state changed to UP > Jul 21 00:20:49 fangorn dhclient: New IP Address (iwi0): 10.0.0.56 > Jul 21 00:20:49 fangorn dhclient: New Subnet Mask (iwi0): 255.255.255.0 > Jul 21 00:20:49 fangorn dhclient: New Broadcast Address (iwi0): 10.0.0.255 > Jul 21 00:20:49 fangorn dhclient: New Routers (iwi0): 10.0.0.1 > > Regards, > Brix From owner-freebsd-stable@FreeBSD.ORG Fri Jul 21 00:05:55 2006 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4095A16A4DD; Fri, 21 Jul 2006 00:05:55 +0000 (UTC) (envelope-from max@love2party.net) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.177]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8438C43D46; Fri, 21 Jul 2006 00:05:54 +0000 (GMT) (envelope-from max@love2party.net) Received: from [88.64.184.76] (helo=amd64.laiers.local) by mrelayeu.kundenserver.de (node=mrelayeu2) with ESMTP (Nemesis), id 0MKwtQ-1G3iWf0DQe-000441; Fri, 21 Jul 2006 02:05:53 +0200 From: Max Laier Organization: FreeBSD To: freebsd-stable@freebsd.org Date: Fri, 21 Jul 2006 02:05:45 +0200 User-Agent: KMail/1.9.3 References: <1153410809.1126.66.camel@genius.i.cz> In-Reply-To: <1153410809.1126.66.camel@genius.i.cz> X-Face: ,,8R(x[kmU]tKN@>gtH1yQE4aslGdu+2]; R]*pL,U>^H?)gW@49@wdJ`H<=?utf-8?q?=25=7D*=5FBD=0A=09U=5For=3D=5CmOZf764=26nYj=3DJYbR1PW0ud?=>|!~,,CPC.1-D$FG@0h3#'5"k{V]a~.<=?utf-8?q?mZ=7D44=23Se=7Em=0A=09Fe=7E=5C=5DX5B=5D=5Fxj?=(ykz9QKMw_l0C2AQ]}Ym8)fU MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart2043876.unpcXM98FI"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200607210205.51614.max@love2party.net> X-Provags-ID: kundenserver.de abuse@kundenserver.de login:61c499deaeeba3ba5be80f48ecc83056 Cc: Michal Mertl , freebsd-pf@freebsd.org Subject: Re: Kernel panic with PF X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Jul 2006 00:05:55 -0000 --nextPart2043876.unpcXM98FI Content-Type: text/plain; charset="iso-8859-6" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline [CC'ing -pf] On Thursday 20 July 2006 17:53, Michal Mertl wrote: > Hello, > > I am deploying FreeBSD based application proxies' based firewall > (www.kernun.com, but not much English there) and am having frequent > panics of RELENG_6_1 under load. The server has IP forwarding disabled. > > I've got two machines in a carp cluster and the transparent proxies use > PF to get the data. Which proxies are you using? The "pool_ticket: 1429 !=3D 1430" messages yo= u=20 quote below indicate a synchronization problem within the app talking to pf= =20 via ioctl's. Tickets are used to ensure atomic commits for operations that= =20 require more than one ioctl. If your proxy app runs in parallel it might=20 screw up the internal state and thus leave it undefined afterwards. I give= =20 you that this shouldn't cause a kernel problem, but if we could fix the app= =20 we can probably find the right sanity check more easily. > I don't know much about kernel internals and PF but from the following > backtrace I understand that the crash happens because rpool->cur on line > 2158 in src/sys/contrib/pf/net/pf.c is NULL and is dereferenced. It > probably shouldn't happen yet it does. > > The machines are SMP and were running SMP kernel. The only places where > pool.cur (or pool->cur) is assigned to are in pf_ioctl.c. It seems there > are some lock operations though so it is probably believed that the > coder is properly locked. > > I have been running with kern.smp.disabled=3D1 for a moment before I put > the old firewall in place and haven't seen the panic but the time was > deffinitely too short to make me believe it fixes the issue. Can setting > debug.mpsafenet to 0 possibly also help? > > I could probably bandaid this particular failure mode by returning > failure instead of panicing but the bug is probably elsewhere. > > I've lost the debug kernel from which this backtrace is and can't > therefore continue much :-(. Unfortunately so far I can only reproduce > the problem in production and for obvious reasons I can't put it there. > > Fatal trap 12: page fault while in kernel mode > cpuid =3D 0; apic id =3D 00 > fault virtual address =3D 0x28 > fault code =3D supervisor read, page not present > instruction pointer =3D 0x8:0xffffffff801ab528 > stack pointer =3D 0x10:0xffffffffb1ade650 > frame pointer =3D 0x10:0xffffff004cc7cc30 > code segment =3D base 0x0, limit 0xfffff, type 0x1b > =3D DPL 0, pres 1, long 1, def32 0, gran 1 > processor eflags =3D interrupt enabled, resume, IOPL =3D 0 > current process =3D 15 (swi1: net) > trap number =3D 12 > panic: page fault > > #0 doadump () at pcpu.h:172 > #1 0x0000000000000004 in ?? () > #2 0xffffffff803d5137 in boot (howto=3D260) > at ../../../kern/kern_shutdown.c:402 > #3 0xffffffff803d58a1 in panic (fmt=3D0xffffff007ba32000 "@\223{") > at ../../../kern/kern_shutdown.c:558 > #4 0xffffffff80543b3f in trap_fatal (frame=3D0xffffff007ba32000, > eva=3D18446742976272241472) at ../../../amd64/amd64/trap.c:660 > #5 0xffffffff80543e5f in trap_pfault (frame=3D0xffffffffb1ade5a0, > usermode=3D0) > at ../../../amd64/amd64/trap.c:573 > #6 0xffffffff80544113 in trap (frame=3D > {tf_rdi =3D 2, tf_rsi =3D -1098223465792, tf_rdx =3D -1098439497700, > tf_rcx =3D -1 > 314002464, tf_r8 =3D 0, tf_r9 =3D -1314002776, tf_rax =3D 0, tf_rbx =3D 0, > tf_rbp =3D -109 > 8223465424, tf_r10 =3D 1, tf_r11 =3D 257, tf_r12 =3D -1098439497700, tf_r= 13 =3D > -1314002 > 776, tf_r14 =3D 2, tf_r15 =3D -1314002464, tf_trapno =3D 12, tf_addr =3D = 40, > tf_flags =3D > 216171684640539392, tf_err =3D 0, tf_rip =3D -2145733336, tf_cs =3D 8, > tf_rflags =3D 661 > 18, tf_rsp =3D -1314003360, tf_ss =3D 16}) > at ../../../amd64/amd64/trap.c:352 > #7 0xffffffff8052feab in calltrap () > at ../../../amd64/amd64/exception.S:168 > #8 0xffffffff801ab528 in pf_map_addr (af=3D2 '\002', > r=3D0xffffff004cc7cac0, > saddr=3D0xffffff003fe7681c, naddr=3D0xffffffffb1ade9e0, init_addr=3D0= x0, > sn=3D0xffffffffb1ade8a8) at ../../../contrib/pf/net/pf.c:2163 > #9 0xffffffff801acab6 in pf_get_translation (pd=3D0xffffffffb1ade9c0, > m=3D0xffffff0042ede900, off=3D20, direction=3D1, kif=3D0xffffff007b03= 8a00, > sn=3D0xffffffffb1ade8a8, saddr=3D0xffffff003fe7681c, sport=3D0, > daddr=3D0xffffff003fe76820, dport=3D50881, naddr=3D0xffffffffb1ade9e0, > nport=3D0xffffffffb1ade8b6) at ../../../contrib/pf/net/pf.c:2618 > #10 0xffffffff801b315b in pf_test_tcp (rm=3D0xffffffffb1ade960, > sm=3D0xffffffffb1ade950, direction=3D1, kif=3D0xffffff007b038a00, > m=3D0xffffff0042ede900, off=3D20, h=3D0xffffff003fe76810, > pd=3D0xffffffffb1ade9c0, am=3D0xffffffffb1ade968, > rsm=3D0xffffffffb1ade970, > ifq=3D0x2, inp=3D0x0) at ../../../contrib/pf/net/pf.c:3013 > #11 0xffffffff801b5694 in pf_test (dir=3D1, ifp=3D0xffffff0000bee800, > m0=3D0xffffffffb1adeaa0, eh=3D0xffffffffb1ade97e, inp=3D0x0) > at ../../../contrib/pf/net/pf.c:6449 > #12 0xffffffff801bafb2 in pf_check_in (arg=3D0x2, m=3D0xffffffffb1adeaa0, > ifp=3D0xffffff004cc7cac0, dir=3D-1314002464, inp=3D0xffffffffb1ade9e0) > at ../../../contrib/pf/net/pf_ioctl.c:3358 > #13 0xffffffff80461c2e in pfil_run_hooks (ph=3D0xffffffff807e0920, > mp=3D0xffffffffb1adeb28, ifp=3D0xffffff0000bee800, dir=3D1, inp=3D0x0) > at ../../../net/pfil.c:139 > #14 0xffffffff8048d225 in ip_input (m=3D0xffffff0042ede900) > at ../../../netinet/ip_input.c:465 > #15 0xffffffff8046180c in netisr_processqueue (ni=3D0xffffffff807df690) > at ../../../net/netisr.c:236 > #16 0xffffffff80461abd in swi_net (dummy=3D0x2) > at ../../../net/netisr.c:349 > #17 0xffffffff803bbd99 in ithread_loop (arg=3D0xffffff00000506a0) > at ../../../kern/kern_intr.c:684 > #18 0xffffffff803ba527 in fork_exit ( > callout=3D0xffffffff803bbc50 , arg=3D0xffffff00000506a0, > frame=3D0xffffffffb1adec50) at ../../../kern/kern_fork.c:805 > #19 0xffffffff8053020e in fork_trampoline () > at ../../../amd64/amd64/exception.S:394 > #20 0x0000000000000000 in ?? () > > The firewall also reports lots of PF problems durings operation: > > Jul 20 10:44:11 fw1 kernel: Jul 20 10:44:11 fw1 HTTP[7607]: KERN-100-E > [natutil.c:770] ioctl(): Invalid argument (EINVAL=3D22) > Jul 20 10:44:11 fw1 kernel: Jul 20 10:44:11 fw1 HTTP[7607]: NATT-111-E > add_rule(): PF ioctl DIOCADDRULE failed > Jul 20 10:44:11 fw1 kernel: Jul 20 10:44:11 fw1 HTTP[7607]: NATT-701-E > addnatmap out(): Adding TCP NAT MAP from [127.0.0.1]:60860 to > [212.80.76.13]:80 -> [193.179.161.10]:60860 failed > Jul 20 10:44:11 fw1 kernel: Jul 20 10:44:11 fw1 HTTP[7607]: NETL-210-E > netbind(server,10): NAT binding failed > > Kernel often reports "pool_ticket: 1429 !=3D 1430" (with increasing > numbers over time). > > Thank you very much for any advice. =2D-=20 /"\ Best regards, | mlaier@freebsd.org \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | mlaier@EFnet / \ ASCII Ribbon Campaign | Against HTML Mail and News --nextPart2043876.unpcXM98FI Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.4 (FreeBSD) iD8DBQBEwBpfXyyEoT62BG0RAgnrAJ4h0goY21wyFk8+rrdlnNAMcY9vQACfbT4Y fNf0Vs1dEldK2z5HktYUh+g= =I4KF -----END PGP SIGNATURE----- --nextPart2043876.unpcXM98FI-- From owner-freebsd-stable@FreeBSD.ORG Fri Jul 21 01:06:05 2006 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7039C16A4DA; Fri, 21 Jul 2006 01:06:05 +0000 (UTC) (envelope-from dhartmei@insomnia.benzedrine.cx) Received: from insomnia.benzedrine.cx (insomnia.benzedrine.cx [62.65.145.30]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6614343D69; Fri, 21 Jul 2006 01:06:03 +0000 (GMT) (envelope-from dhartmei@insomnia.benzedrine.cx) Received: from insomnia.benzedrine.cx (dhartmei@localhost [127.0.0.1]) by insomnia.benzedrine.cx (8.13.4/8.13.4) with ESMTP id k6L15x6d005288 (version=TLSv1/SSLv3 cipher=DHE-DSS-AES256-SHA bits=256 verify=NO); Fri, 21 Jul 2006 03:06:00 +0200 (MEST) Received: (from dhartmei@localhost) by insomnia.benzedrine.cx (8.13.4/8.12.10/Submit) id k6L15x5k025156; Fri, 21 Jul 2006 03:05:59 +0200 (MEST) Date: Fri, 21 Jul 2006 03:05:59 +0200 From: Daniel Hartmeier To: Max Laier Message-ID: <20060721010559.GB23227@insomnia.benzedrine.cx> References: <1153410809.1126.66.camel@genius.i.cz> <200607210205.51614.max@love2party.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200607210205.51614.max@love2party.net> User-Agent: Mutt/1.5.10i Cc: Michal Mertl , freebsd-stable@freebsd.org, freebsd-pf@freebsd.org Subject: Re: Kernel panic with PF X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Jul 2006 01:06:05 -0000 On Fri, Jul 21, 2006 at 02:05:45AM +0200, Max Laier wrote: > Which proxies are you using? The "pool_ticket: 1429 != 1430" messages you > quote below indicate a synchronization problem within the app talking to pf > via ioctl's. Tickets are used to ensure atomic commits for operations that > require more than one ioctl. If your proxy app runs in parallel it might > screw up the internal state and thus leave it undefined afterwards. I give > you that this shouldn't cause a kernel problem, but if we could fix the app > we can probably find the right sanity check more easily. This looks like a bug in pf_ioctl.c pfioctl() DIOCCHANGERULE if (((((newrule->action == PF_NAT) || (newrule->action == PF_RDR) || (newrule->action == PF_BINAT) || (newrule->rt > PF_FASTROUTE)) && - !pcr->anchor[0])) && + !newrule->anchor)) && (TAILQ_FIRST(&newrule->rpool.list) == NULL)) error = EINVAL; i.e. the pool must not be empty for routing and translation rules, except for translation rules that are actually anchor _calls_. The confusion is between translation rules within anchors (pcr->anchor[0] != '\0') and calls to anchors' translation rules (rule->anchor != NULL). If the proxy is using DIOCCHANGERULE (it must be the proxy, pfctl isn't using it at all), AND is trying to add/update a rule that requires at least one replacement address but contains an empty list, then this would cause the panic seen when that rule later matches a packet. This needs fixing in OpenBSD as well. Michal, can you please confirm that the patch above fixes the panic? The proxy will still misbehave and cause the log messages (one more EINVAL in this case ;), but the kernel shouldn't crash anymore. Thanks for the excellent bug report! Daniel From owner-freebsd-stable@FreeBSD.ORG Fri Jul 21 01:40:06 2006 Return-Path: X-Original-To: stable@freebsd.org Delivered-To: freebsd-stable@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 28BA016A4DA for ; Fri, 21 Jul 2006 01:40:06 +0000 (UTC) (envelope-from holtor@yahoo.com) Received: from web31708.mail.mud.yahoo.com (web31708.mail.mud.yahoo.com [68.142.201.188]) by mx1.FreeBSD.org (Postfix) with SMTP id 9B66543D49 for ; Fri, 21 Jul 2006 01:40:05 +0000 (GMT) (envelope-from holtor@yahoo.com) Received: (qmail 85741 invoked by uid 60001); 21 Jul 2006 01:40:04 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:Received:Date:From:Subject:To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=EYEHhS/DD8bAeVT5j+W7stkYbzO/9KCDx+hGNKkLNRwjHzVRs2wHePnNVSZCf25Zeh4y3+kQKGmlbous8bSu+fc8Si7AHlmxeI67ccnLKUNDe7P3ppPv+e34Y/G1/lBilcSVPsIz6Nvm0liysytPZ7lzccvumS6svKocdgsfP2w= ; Message-ID: <20060721014004.85734.qmail@web31708.mail.mud.yahoo.com> Received: from [68.197.167.249] by web31708.mail.mud.yahoo.com via HTTP; Thu, 20 Jul 2006 18:40:04 PDT Date: Thu, 20 Jul 2006 18:40:04 -0700 (PDT) From: Holtor To: stable@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Cc: Subject: Frozen Processes X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Jul 2006 01:40:06 -0000 Hello, Since upgrading some of our 5.4 servers to the latest 6.1-STABLE we've had some processes stuck in the *inp state as listed in 'top'. Those processes can't be killed and any resources they use up in terms of bound IP addresses or ports can't be freed. Does anyone know what this *inp state means or how to fix this problem? Holt G. __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From owner-freebsd-stable@FreeBSD.ORG Fri Jul 21 03:23:05 2006 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2B96D16A4E5 for ; Fri, 21 Jul 2006 03:23:05 +0000 (UTC) (envelope-from sam@errno.com) Received: from ebb.errno.com (ebb.errno.com [69.12.149.25]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9B53943D70 for ; Fri, 21 Jul 2006 03:23:00 +0000 (GMT) (envelope-from sam@errno.com) Received: from [10.0.0.248] (trouble.errno.com [10.0.0.248]) (authenticated bits=0) by ebb.errno.com (8.13.6/8.12.6) with ESMTP id k6L3MxV2054507 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 20 Jul 2006 20:23:00 -0700 (PDT) (envelope-from sam@errno.com) Message-ID: <44C04893.3070904@errno.com> Date: Thu, 20 Jul 2006 20:22:59 -0700 From: Sam Leffler User-Agent: Thunderbird 1.5.0.2 (X11/20060508) MIME-Version: 1.0 To: freebsd-stable@freebsd.org References: <200607202300.k6KN067d010753@drugs.dv.isc.org> In-Reply-To: <200607202300.k6KN067d010753@drugs.dv.isc.org> X-Enigmail-Version: 0.94.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: "scan stuck" with if_iwi(4) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Jul 2006 03:23:05 -0000 Mark Andrews wrote: > The iwi code was recently MFC and it required a port change > iwi-firmware -> iwi-firmware-kmod. Depending on when you > upgraded the src and ports you may not have seen the ports > change. > > Mark > > B.T.W. the new code is more stable for me. No more complete > machine lockups. The WiFi led now binks though if you turn > the radio off it stays lit / off depending apon the state > it was in at the time. This is still better than not > lighting at all. There are some sysctl you can tweak to play w/ the led's. I only had a dell d610 to test with. The more important issue w/ the radio on/off switch is that it doesn't hookup properly to wpa_supplicant. Sam From owner-freebsd-stable@FreeBSD.ORG Fri Jul 21 05:48:17 2006 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0560C16A4DA; Fri, 21 Jul 2006 05:48:17 +0000 (UTC) (envelope-from ganbold@micom.mng.net) Received: from publicd.ub.mng.net (publicd.ub.mng.net [202.179.0.88]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3A4E043D46; Fri, 21 Jul 2006 05:48:16 +0000 (GMT) (envelope-from ganbold@micom.mng.net) Received: from [202.179.0.164] (helo=[192.168.0.18]) by publicd.ub.mng.net with esmtpa (Exim 4.61 (FreeBSD)) (envelope-from ) id 1G3nro-000OUG-Pa; Fri, 21 Jul 2006 14:48:04 +0900 Message-ID: <44C06A94.5070909@micom.mng.net> Date: Fri, 21 Jul 2006 14:48:04 +0900 From: Ganbold User-Agent: Thunderbird 1.5.0.4 (X11/20060612) MIME-Version: 1.0 To: freebsd-stable@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: tbyte@otel.net, wpaul@freebsd.org Subject: ndisgen generated module load causes page fault, missing functions X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Jul 2006 05:48:17 -0000 Hi, I have FreeBSD-6.1-STABLE dell D620 laptop with Dell Wireless 1490 802.11a/g Dual-band Mini Card (which seems like bcm4310). # uname -an FreeBSD devil.micom.mng.net 6.1-STABLE FreeBSD 6.1-STABLE #2: Fri Jul 21 13:50:53 ULAST 2006 tsgan@devil.micom.mng.net:/usr/obj/usr/src/sys/DEVIL i386 none4@pci12:0:0: class=0x028000 card=0x00071028 chip=0x431214e4 rev=0x01 hdr=0x00 vendor = 'Broadcom Corporation' device = 'BCM4310 UART' class = network When I try to load bcmwl5_sys.ko module (generated by ndisgen) system faults: no match for strrchr no match for MmFreeContiguousMemorySpecifyCache no match for MmAllocateContiguousMemorySpecifyCache no match for MmGetPhysicalAddress ndis0: mem 0xdfdfc000-0xdfdfffff irq 17 at device 0.0 on pci12 ndis0: NDIS API version: 5.1 ntoskrnl dummy called... Fatal trap 12: page fault while in kernel mode cpuid = 1; apic id = 01 fault virtual address = 0x1a fault code = supervisor read, page not present instruction pointer = 0x20:0xc530108f stack pointer = 0x28:0xe7209938 frame pointer = 0x28:0xe720994c code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 559 (kldload) [thread pid 559 tid 100103 ] Stopped at 0xc530108f: cmpb 0(%edi),%al db> bt Tracing pid 559 tid 100103 td 0xc4e06a80 bcmwl5_sys_drv_data_start(c534e8f6,c52f9ddc,0,0,e7209980) at 0xc530108f bcmwl5_sys_drv_data_start(c4e2a000,c53d1000,c539d600,c53e2000,c4e2a000) at 0xc53070d3 bcmwl5_sys_drv_data_start(e7209ac8,c4e2a000,0,c53d1000,c539d600) at bcmwl5_sys_drv_data_start+0xe5d6 x86_stdcall_wrap_end(c521d000,0,c,0,0) at x86_stdcall_wrap_end+0x1e ndis_attach(c4bb9300,c4c305a0,5,13,4312) at ndis_attach+0x17c ndis_attach_pci(c4bb9300) at ndis_attach_pci+0x374 device_attach(c4bb9300,c4bb9300,c4bb9300,0,c4ba8700) at device_attach+0x58 device_probe_and_attach(c4bb9300,c4bb9300,c4ba8700) at device_probe_and_attach+0xc4 pci_driver_added(c4bba100,c5356244) at pci_driver_added+0xd1 devclass_add_driver(c4b08440,c5356244,c52df600,c535630c,c4c25070) at devclass_add_driver+0xb7 driver_module_handler(c52df600,0,c5356318,c0872440,0) at driver_module_handler+0x59 module_register_init(c535630c) at module_register_init+0x4b linker_file_sysinit(c51ece00,c51ece00,1,c51ece00,c4c25070) at linker_file_sysinit+0x7d linker_load_file(c4c25070,e7209ca0,400,0,c4bd9800) at linker_load_file+0xce linker_load_module(c4bd9800,0,0,0,e7209ccc) at linker_load_module+0xa3 kldload(c4e06a80,e7209d04,1,0,292) at kldload+0xeb syscall(3b,3b,3b,1,bfbfec88) at syscall+0x2bf Xint0x80_syscall() at Xint0x80_syscall+0x1f --- syscall (304, FreeBSD ELF32, kldload), eip = 0x280bab77, esp = 0xbfbfebfc, ebp = 0xbfbfec38 --- db> Did somebody successfully use ndisgen generated driver for Dell Wireless 1490 802.11a/g Dual-band Mini Card? thanks in advance, Ganbold From owner-freebsd-stable@FreeBSD.ORG Fri Jul 21 06:45:01 2006 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3739A16A4DA for ; Fri, 21 Jul 2006 06:45:01 +0000 (UTC) (envelope-from henrik@brixandersen.dk) Received: from ns2.pil.dk (ns2.pil.dk [195.41.47.38]) by mx1.FreeBSD.org (Postfix) with ESMTP id B7C4E43D55 for ; Fri, 21 Jul 2006 06:45:00 +0000 (GMT) (envelope-from henrik@brixandersen.dk) Received: from osgiliath.brixandersen.dk (osgiliath.brixandersen.dk [87.53.223.189]) by ns2.pil.dk (Postfix) with ESMTP id 1DD227BA8CB for ; Fri, 21 Jul 2006 08:44:59 +0200 (CEST) Received: by osgiliath.brixandersen.dk (Postfix, from userid 1000) id A590F1FBD7; Fri, 21 Jul 2006 08:44:58 +0200 (CEST) Date: Fri, 21 Jul 2006 08:44:58 +0200 From: Henrik Brix Andersen To: freebsd-stable@freebsd.org Message-ID: <20060721064458.GB4607@osgiliath.brixandersen.dk> Mail-Followup-To: freebsd-stable@freebsd.org References: <20060720224632.GB31459@osgiliath.brixandersen.dk> <200607202300.k6KN067d010753@drugs.dv.isc.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="opJtzjQTFsWo+cga" Content-Disposition: inline In-Reply-To: <200607202300.k6KN067d010753@drugs.dv.isc.org> X-PGP-Key: http://dev.gentoo.org/~brix/files/HenrikBrixAndersen.asc User-Agent: Mutt/1.5.11 Subject: Re: "scan stuck" with if_iwi(4) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Jul 2006 06:45:01 -0000 --opJtzjQTFsWo+cga Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Jul 21, 2006 at 09:00:06AM +1000, Mark Andrews wrote: >=20 > The iwi code was recently MFC and it required a port change > iwi-firmware -> iwi-firmware-kmod. Depending on when you > upgraded the src and ports you may not have seen the ports > change. Yeah, I know - I have the new iwi-firmware-kmod installed. Regards, Brix --=20 Henrik Brix Andersen --opJtzjQTFsWo+cga Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.4 (GNU/Linux) Comment: GnuPG signed iD8DBQFEwHfqv+Q4flTiePgRAkOwAKCIbWTHJ4RJLC0dBOzrfdfpbKs0CgCfUBxe cInlU/KN+b+CRt8fiTfwQC8= =lSXw -----END PGP SIGNATURE----- --opJtzjQTFsWo+cga-- From owner-freebsd-stable@FreeBSD.ORG Fri Jul 21 06:49:55 2006 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id BD5B016A4DF for ; Fri, 21 Jul 2006 06:49:55 +0000 (UTC) (envelope-from henrik@brixandersen.dk) Received: from ns2.pil.dk (ns2.pil.dk [195.41.47.38]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2B87A43D62 for ; Fri, 21 Jul 2006 06:49:55 +0000 (GMT) (envelope-from henrik@brixandersen.dk) Received: from osgiliath.brixandersen.dk (osgiliath.brixandersen.dk [87.53.223.189]) by ns2.pil.dk (Postfix) with ESMTP id 607A57BA849 for ; Fri, 21 Jul 2006 08:49:54 +0200 (CEST) Received: by osgiliath.brixandersen.dk (Postfix, from userid 1000) id E8B4E1FBD7; Fri, 21 Jul 2006 08:49:53 +0200 (CEST) Date: Fri, 21 Jul 2006 08:49:53 +0200 From: Henrik Brix Andersen To: freebsd-stable@freebsd.org Message-ID: <20060721064953.GC4607@osgiliath.brixandersen.dk> Mail-Followup-To: freebsd-stable@freebsd.org References: <20060720224632.GB31459@osgiliath.brixandersen.dk> <44C00B40.2010901@errno.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="eJnRUKwClWJh1Khz" Content-Disposition: inline In-Reply-To: <44C00B40.2010901@errno.com> X-PGP-Key: http://dev.gentoo.org/~brix/files/HenrikBrixAndersen.asc User-Agent: Mutt/1.5.11 Subject: Re: "scan stuck" with if_iwi(4) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Jul 2006 06:49:55 -0000 --eJnRUKwClWJh1Khz Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Jul 20, 2006 at 04:01:20PM -0700, Sam Leffler wrote: > You will not be able to reproduce the problem because the code in 6.1R > ignored beacon misses (and a lot of other things). I see. > The stuck scan is not fatal; the driver just resets the card. It's > caused by a firwmare problem that I never got around to dealing with > ('cuz it wouldn't change the overall operation of the driver). Well, losing the connection for 30 seconds every 3 minutes is rather annoying - if not fatal. > The basic problem is your card is losing sync w/ the ap. I don't know > what the local conditions are but I've seen this a lot w/ iwi; there's > nothing we can do in the driver if you want to be able to roam. The problem should be solvable in software - the Linux ipw2200 driver doesn't have these problems when using the same AP. Regards, Brix --=20 Henrik Brix Andersen --eJnRUKwClWJh1Khz Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.4 (GNU/Linux) Comment: GnuPG signed iD8DBQFEwHkRv+Q4flTiePgRAjV6AKCveTaKh89RoLJ4Zuko8YD9Er//fACff5KW QbVaLFQfeXCcdYMU3RyJqy4= =IXqD -----END PGP SIGNATURE----- --eJnRUKwClWJh1Khz-- From owner-freebsd-stable@FreeBSD.ORG Fri Jul 21 08:57:39 2006 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D19EA16A4DE; Fri, 21 Jul 2006 08:57:39 +0000 (UTC) (envelope-from mime@traveller.cz) Received: from ss.eunet.cz (ss.eunet.cz [193.85.228.13]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4732C43D49; Fri, 21 Jul 2006 08:57:38 +0000 (GMT) (envelope-from mime@traveller.cz) Received: from localhost.i.cz (ss.eunet.cz [193.85.228.13]) by ss.eunet.cz (8.13.6/8.13.6) with ESMTP id k6L8vaF8030088 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Fri, 21 Jul 2006 10:57:36 +0200 (CEST) (envelope-from mime@traveller.cz) From: Michal Mertl To: Max Laier In-Reply-To: <200607210205.51614.max@love2party.net> References: <1153410809.1126.66.camel@genius.i.cz> <200607210205.51614.max@love2party.net> Content-Type: text/plain; charset=ISO-8859-2 Date: Fri, 21 Jul 2006 10:57:28 +0200 Message-Id: <1153472248.1140.13.camel@genius.i.cz> Mime-Version: 1.0 X-Mailer: Evolution 2.6.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 8bit Cc: freebsd-stable@freebsd.org, freebsd-pf@freebsd.org Subject: Re: Kernel panic with PF X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Jul 2006 08:57:39 -0000 Max Laier pí¹e v pá 21. 07. 2006 v 02:05 +0200: > [CC'ing -pf] > > On Thursday 20 July 2006 17:53, Michal Mertl wrote: > > Hello, > > > > I am deploying FreeBSD based application proxies' based firewall > > (www.kernun.com, but not much English there) and am having frequent > > panics of RELENG_6_1 under load. The server has IP forwarding disabled. > > > > I've got two machines in a carp cluster and the transparent proxies use > > PF to get the data. > > Which proxies are you using? The "pool_ticket: 1429 != 1430" messages you > quote below indicate a synchronization problem within the app talking to pf > via ioctl's. Tickets are used to ensure atomic commits for operations that > require more than one ioctl. If your proxy app runs in parallel it might > screw up the internal state and thus leave it undefined afterwards. I give > you that this shouldn't cause a kernel problem, but if we could fix the app > we can probably find the right sanity check more easily. The proxy in fact runs in parallel (according to "pfctl -s info" it did about 50 inserts and removal in the state table per second - some 10Mbit of traffic, probably mostly HTTP) and it is quite possible that your explanation is correct. I will forward your suspicion to the vendor. This functionality of the software (using PF with anchors) is quite new - they used different mechanisms in previous versions so it may well have some bugs. Thanks Michal From owner-freebsd-stable@FreeBSD.ORG Fri Jul 21 09:05:50 2006 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 28B4E16A4DA; Fri, 21 Jul 2006 09:05:50 +0000 (UTC) (envelope-from mime@traveller.cz) Received: from ss.eunet.cz (ss.eunet.cz [193.85.228.13]) by mx1.FreeBSD.org (Postfix) with ESMTP id A7FA943D46; Fri, 21 Jul 2006 09:05:49 +0000 (GMT) (envelope-from mime@traveller.cz) Received: from localhost.i.cz (ss.eunet.cz [193.85.228.13]) by ss.eunet.cz (8.13.6/8.13.6) with ESMTP id k6L95YBY031301 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Fri, 21 Jul 2006 11:05:37 +0200 (CEST) (envelope-from mime@traveller.cz) From: Michal Mertl To: Daniel Hartmeier In-Reply-To: <20060721010559.GB23227@insomnia.benzedrine.cx> References: <1153410809.1126.66.camel@genius.i.cz> <200607210205.51614.max@love2party.net> <20060721010559.GB23227@insomnia.benzedrine.cx> Content-Type: text/plain Date: Fri, 21 Jul 2006 11:05:26 +0200 Message-Id: <1153472726.1140.23.camel@genius.i.cz> Mime-Version: 1.0 X-Mailer: Evolution 2.6.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: Max Laier , freebsd-stable@freebsd.org, freebsd-pf@freebsd.org Subject: Re: Kernel panic with PF X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Jul 2006 09:05:50 -0000 Daniel Hartmeier wrote: > On Fri, Jul 21, 2006 at 02:05:45AM +0200, Max Laier wrote: > > > Which proxies are you using? The "pool_ticket: 1429 != 1430" messages you > > quote below indicate a synchronization problem within the app talking to pf > > via ioctl's. Tickets are used to ensure atomic commits for operations that > > require more than one ioctl. If your proxy app runs in parallel it might > > screw up the internal state and thus leave it undefined afterwards. I give > > you that this shouldn't cause a kernel problem, but if we could fix the app > > we can probably find the right sanity check more easily. > > This looks like a bug in pf_ioctl.c pfioctl() DIOCCHANGERULE > > if (((((newrule->action == PF_NAT) || > (newrule->action == PF_RDR) || > (newrule->action == PF_BINAT) || > (newrule->rt > PF_FASTROUTE)) && > - !pcr->anchor[0])) && > + !newrule->anchor)) && > (TAILQ_FIRST(&newrule->rpool.list) == NULL)) > error = EINVAL; > > i.e. the pool must not be empty for routing and translation rules, > except for translation rules that are actually anchor _calls_. > > The confusion is between translation rules within anchors > (pcr->anchor[0] != '\0') and calls to anchors' translation rules > (rule->anchor != NULL). > > If the proxy is using DIOCCHANGERULE (it must be the proxy, pfctl isn't > using it at all), AND is trying to add/update a rule that requires at > least one replacement address but contains an empty list, then this > would cause the panic seen when that rule later matches a packet. > > This needs fixing in OpenBSD as well. > > Michal, can you please confirm that the patch above fixes the panic? > The proxy will still misbehave and cause the log messages (one more > EINVAL in this case ;), but the kernel shouldn't crash anymore. I am afraid I can't test it at the moment. I am going to get one of the machines to my lab and will experiment with it there. I am afraid I will have problems generating enough traffic for the problem to appear but I will try. > Thanks for the excellent bug report! Thank you. I don't think is was that good as I now see that you had to guess there are anchors used. The rules look like this (except the rules seen by 'pfctl -s nat' they are generated by the proxies when they start): fw1#pfctl -s rule fw1#pfctl -s nat nat-anchor "/kernun/*" all rdr-anchor "/kernun/*" all fw1#pfctl -s Anchors -v kernun kernun/4026 kernun/4039 kernun/4088 kernun/4112 kernun/4134 kernun/4164 kernun/4197 kernun/4257 kernun/4296 kernun/4338 kernun/4383 kernun/4431 kernun/4482 kernun/4590 kernun/4649 fw1# pfctl -a kernun/4039 -s nat rdr on em0 inet proto tcp from any to any port = http label "HTTP" -> 127.0.0.1 When the system was under load I saw ~5000 states in 'pfctl -s state'. Thank you again. I will let you know when I get a chance to test your patch and or find out anything new. Michal From owner-freebsd-stable@FreeBSD.ORG Fri Jul 21 09:15:54 2006 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7E75616A4DE; Fri, 21 Jul 2006 09:15:54 +0000 (UTC) (envelope-from dhartmei@insomnia.benzedrine.cx) Received: from insomnia.benzedrine.cx (insomnia.benzedrine.cx [62.65.145.30]) by mx1.FreeBSD.org (Postfix) with ESMTP id C0C4C43D45; Fri, 21 Jul 2006 09:15:53 +0000 (GMT) (envelope-from dhartmei@insomnia.benzedrine.cx) Received: from insomnia.benzedrine.cx (dhartmei@localhost [127.0.0.1]) by insomnia.benzedrine.cx (8.13.4/8.13.4) with ESMTP id k6L9FnPA012187 (version=TLSv1/SSLv3 cipher=DHE-DSS-AES256-SHA bits=256 verify=NO); Fri, 21 Jul 2006 11:15:50 +0200 (MEST) Received: (from dhartmei@localhost) by insomnia.benzedrine.cx (8.13.4/8.12.10/Submit) id k6L9FnxU003713; Fri, 21 Jul 2006 11:15:49 +0200 (MEST) Date: Fri, 21 Jul 2006 11:15:49 +0200 From: Daniel Hartmeier To: Michal Mertl Message-ID: <20060721091549.GC23227@insomnia.benzedrine.cx> References: <1153410809.1126.66.camel@genius.i.cz> <200607210205.51614.max@love2party.net> <1153472248.1140.13.camel@genius.i.cz> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1153472248.1140.13.camel@genius.i.cz> User-Agent: Mutt/1.5.10i Cc: Max Laier , freebsd-stable@freebsd.org, freebsd-pf@freebsd.org Subject: Re: Kernel panic with PF X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Jul 2006 09:15:54 -0000 On Fri, Jul 21, 2006 at 10:57:28AM +0200, Michal Mertl wrote: > The proxy in fact runs in parallel (according to "pfctl -s info" it did > about 50 inserts and removal in the state table per second - some 10Mbit > of traffic, probably mostly HTTP) and it is quite possible that your > explanation is correct. I will forward your suspicion to the vendor. > This functionality of the software (using PF with anchors) is quite new > - they used different mechanisms in previous versions so it may well > have some bugs. Anchors were introduced for this purpose, i.e. splitting the ruleset into separate pieces, over each of which a single process can have authority, so different processes don't stomp on each other's toes with ruleset modifications. Ask them if they really need to still use DIOCCHANGERULE, as the idea with anchors is generally to only operate within one anchor, and usually flush or replace the (smaller) ruleset within. Each anchor has its own ticket, so if you're seeing ticket mismatches, that means there are concurrent operations on the same anchor, even. Daniel From owner-freebsd-stable@FreeBSD.ORG Fri Jul 21 10:03:56 2006 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id EA2ED16A4DA; Fri, 21 Jul 2006 10:03:56 +0000 (UTC) (envelope-from mime@traveller.cz) Received: from ss.eunet.cz (ss.eunet.cz [193.85.228.13]) by mx1.FreeBSD.org (Postfix) with ESMTP id 59B9043D55; Fri, 21 Jul 2006 10:03:56 +0000 (GMT) (envelope-from mime@traveller.cz) Received: from localhost.i.cz (ss.eunet.cz [193.85.228.13]) by ss.eunet.cz (8.13.6/8.13.6) with ESMTP id k6LA3mt2039954 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Fri, 21 Jul 2006 12:03:48 +0200 (CEST) (envelope-from mime@traveller.cz) From: Michal Mertl To: Daniel Hartmeier In-Reply-To: <20060721091549.GC23227@insomnia.benzedrine.cx> References: <1153410809.1126.66.camel@genius.i.cz> <200607210205.51614.max@love2party.net> <1153472248.1140.13.camel@genius.i.cz> <20060721091549.GC23227@insomnia.benzedrine.cx> Content-Type: text/plain Date: Fri, 21 Jul 2006 12:03:40 +0200 Message-Id: <1153476220.1140.34.camel@genius.i.cz> Mime-Version: 1.0 X-Mailer: Evolution 2.6.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: Max Laier , freebsd-stable@freebsd.org, freebsd-pf@freebsd.org Subject: Re: Kernel panic with PF X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Jul 2006 10:03:57 -0000 Daniel Hartmeier wrote: > On Fri, Jul 21, 2006 at 10:57:28AM +0200, Michal Mertl wrote: > > > The proxy in fact runs in parallel (according to "pfctl -s info" it did > > about 50 inserts and removal in the state table per second - some 10Mbit > > of traffic, probably mostly HTTP) and it is quite possible that your > > explanation is correct. I will forward your suspicion to the vendor. > > This functionality of the software (using PF with anchors) is quite new > > - they used different mechanisms in previous versions so it may well > > have some bugs. > > Anchors were introduced for this purpose, i.e. splitting the ruleset > into separate pieces, over each of which a single process can have > authority, so different processes don't stomp on each other's toes with > ruleset modifications. They (the Kernun authors) run multiple processes for each proxy. Originally they used slightly modified Apached core for their proxies I believe. Thus there are probably more processes using the same anchor. I don't really understand what they do inside - I would think that when there are no traffic blocking rules, there's no point in doing anything with PF except initial setting of the rdr rule to the proxy. > Ask them if they really need to still use DIOCCHANGERULE, as the idea > with anchors is generally to only operate within one anchor, and usually > flush or replace the (smaller) ruleset within. > > Each anchor has its own ticket, so if you're seeing ticket mismatches, > that means there are concurrent operations on the same anchor, even. I see. It would be better if they were part of this communication because I don't know the internals (although I have the source code). I have problems reaching them at the moment though. > Daniel > From owner-freebsd-stable@FreeBSD.ORG Fri Jul 21 11:02:13 2006 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D17AC16A4E0 for ; Fri, 21 Jul 2006 11:02:13 +0000 (UTC) (envelope-from joao@matik.com.br) Received: from msrv.matik.com.br (msrv.matik.com.br [200.152.83.14]) by mx1.FreeBSD.org (Postfix) with ESMTP id DF41843D6A for ; Fri, 21 Jul 2006 11:02:07 +0000 (GMT) (envelope-from joao@matik.com.br) Received: from ap-h.matik.com.br (ap-h.matik.com.br [200.152.83.36]) by msrv.matik.com.br (8.13.6/8.13.1) with ESMTP id k6LB1qSF085000; Fri, 21 Jul 2006 08:01:53 -0300 (BRT) (envelope-from joao@matik.com.br) From: JoaoBR Organization: Infomatik To: freebsd-stable@freebsd.org Date: Fri, 21 Jul 2006 08:02:12 -0300 User-Agent: KMail/1.9.3 References: <44BFA45C.5050108@errno.com> In-Reply-To: <44BFA45C.5050108@errno.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200607210802.13697.joao@matik.com.br> X-Filter-Version: 1.11a (msrv.matik.com.br) X-Virus-Scanned: ClamAV version 0.88, clamav-milter version 0.87 on msrv.matik.com.br X-Virus-Status: Clean Cc: vsemionov@gmail.com, turtle@loveturtle.net, Pete French Subject: Re: ath driver transmits frames only after a low watermark is filled X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Jul 2006 11:02:13 -0000 On Thursday 20 July 2006 12:42, Sam Leffler wrote: > The original posting didn't provide any basic info so there's little > anyone can provide except wild guesses. =A0There are debugging mechanisms > for tracing what's going on at the net80211 layer and in the driver that > have been referenced countless times in this forum. I think it could be useful if you could provide clear instructions what you= =20 need exactly.=20 Even if it was once in a while referenced that there are tools for debuggin= g=20 there are no instructions how to use them and it is already hard to find th= em=20 and then when found there seems to be no readme and no help at all.=20 So since we are forced to guess how to use them then we are probably forced= to=20 guess results too ... I am also sure that the actual ath problems do have nothing to do with=20 powersaving features because they appear also when this features are turned= =20 off on both, the ap and the stations(all). the last modification regarding the mcast issue definitly made the driver=20 better and more stable but still it stops transmitting from time to time=20 without any usefull message and appearently it is related to some kind=20 broadcast traffic. It is no question of quantity, for example I can run=20 dhclient gain and again on one machine on the same network and I get an ath= =20 down and up event in messages what then sometimes causes tx to stop until I= =20 do manually ifconfig up. So since I am on my own here I simply block any ki= nd=20 of broadcast to the AP and the card stands. But if you could tell me what you exactly need to find out what it is it wo= uld=20 be easy for me to help because I have lots of this setups running. =2D-=20 Jo=E3o A mensagem foi scaneada pelo sistema de e-mail e pode ser considerada segura. Service fornecido pelo Datacenter Matik https://datacenter.matik.com.br From owner-freebsd-stable@FreeBSD.ORG Fri Jul 21 12:24:40 2006 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0443A16A4DD for ; Fri, 21 Jul 2006 12:24:40 +0000 (UTC) (envelope-from nealie@kobudo.homeunix.net) Received: from neal.nelson.name (neal.nelson.name [82.139.192.177]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1EB5443D46 for ; Fri, 21 Jul 2006 12:24:38 +0000 (GMT) (envelope-from nealie@kobudo.homeunix.net) Received: from server.home (server.home [10.0.0.1]) (TLS: TLSv1/SSLv3,128bits,RC4-MD5) by neal.nelson.name with esmtp; Fri, 21 Jul 2006 14:24:37 +0200 id 000D4C4E.44C0C785.00012AF8 From: Nealie To: freebsd-stable@freebsd.org In-Reply-To: <1153396289.823.16.camel@server.home> References: <1153396289.823.16.camel@server.home> Date: Fri, 21 Jul 2006 14:24:36 +0200 Message-Id: <1153484676.902.3.camel@server.home> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7bit X-Mailer: Evolution 2.6.2 FreeBSD GNOME Team Port Subject: Re: NVIDIA 6600GT Freeze X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Jul 2006 12:24:40 -0000 On Thu, 2006-07-20 at 13:51 +0200, Nealie wrote: > I have a problem with my system freezing when using an NVIDIA video card > using the nvidia-driver port. All seems to work fine for a while but > then the system freezes and won't even reply to a ping. This can happen > regardless of whether I use openGL or not. > > Everything works fine using the "nv" driver, so it doesn't seem to be a > hardware problem. > > My setup is as follows: > > uname: FreeBSD server.home 6.1-STABLE FreeBSD 6.1-STABLE #0: Wed Jul 19 > 11:19:16 CEST 2006 root@server.home:/usr/obj/usr/src/sys/SERVER > i386 > > AGP NVIDIA 6600GT installed on an MSI K8T Neo-F V2.09 motherboard (VIA > K8T800 Pro chipset) with an AMD Athlon 64 3500+ CPU. > > The NVIDIA driver is installed as per the instructions, with agp and dri > removed from the kernel in order to use the NVIDIA agp interface, even > though the sysctl settings suggest otherwise. > > If anyone has any ideas about this problem I'd be very grateful. Just a quick reply to myself: The problem seems to be that the the IRQs of the motherboards on board network interface and the AGP card are the same. This works for a while but then something goes horribly wrong and all comes to a halt. Why the IRQ is shared I have no idea as there are nine free IRQs. Unfortunately there is no way to change either of the IRQs in the BIOS, so I've had to resort to replacing the on board gigagit network interface with an add on 100Mb interface. All seems to be working properly now with the NVIDIA driver. From owner-freebsd-stable@FreeBSD.ORG Fri Jul 21 13:00:31 2006 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 47F4116A4E2 for ; Fri, 21 Jul 2006 13:00:13 +0000 (UTC) (envelope-from feargal@fbi.ie) Received: from mail03.svc.cra.dublin.eircom.net (mail03.svc.cra.dublin.eircom.net [159.134.118.19]) by mx1.FreeBSD.org (Postfix) with SMTP id 0D3CF43D45 for ; Fri, 21 Jul 2006 13:00:11 +0000 (GMT) (envelope-from feargal@fbi.ie) Received: (qmail 53633 messnum 275578 invoked from network[82.141.233.46/unknown]); 21 Jul 2006 13:00:10 -0000 Received: from unknown (HELO alatar.edhellond.fbi.ie) (82.141.233.46) by mail03.svc.cra.dublin.eircom.net (qp 53633) with SMTP; 21 Jul 2006 13:00:10 -0000 Received: from mablung.edhellond.fbi.ie (mablung.edhellond.fbi.ie [192.168.0.14]) by alatar.edhellond.fbi.ie (8.13.1/8.13.1) with ESMTP id k6LD05DC081440 for ; Fri, 21 Jul 2006 13:00:10 GMT (envelope-from feargal@fbi.ie) Date: Fri, 21 Jul 2006 14:00:05 +0100 From: Feargal Reilly To: freebsd-stable@freebsd.org Message-ID: <20060721140005.5365e4b7@mablung.edhellond.fbi.ie> Organization: FBI X-Mailer: Sylpheed-Claws 2.1.1 (GTK+ 2.8.7; i386-portbld-freebsd5.4) Mime-Version: 1.0 Content-Type: multipart/signed; boundary=Sig_hglNb74cQOwLb8iTICNIkiC; protocol="application/pgp-signature"; micalg=PGP-SHA1 Subject: filesystem full error with inumber X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Jul 2006 13:00:31 -0000 --Sig_hglNb74cQOwLb8iTICNIkiC Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable The following error is being logged in /var/log/messages on FreeBSD 5.4: Jul 21 09:58:44 arwen kernel: pid 615 (postgres), uid 1001 inumber 6166128 on /data0: filesystem full However, this does not appear to be a case of being out of disk space, or running out of inodes: ttyp2$ df -hi Filesystem Size Used Avail Capacity iused ifree %iused Mounted on /dev/amrd0s1f 54G 44G 5.4G 89% 4104458 3257972 56% /data0 Nor does it appear to be a file limit: ttyp2$ sysctl kern.maxfiles kern.openfiles kern.maxfiles: 20000 kern.openfiles: 3582 These reading were not taken at exactly the same time as the error occured, but close to it. Here's the head of dumpfs: magic 19540119 (UFS2) time Fri Jul 21 09:38:40 2006 superblock location 65536 id [ 42446884 99703062 ] ncg 693 size 29360128 blocks 28434238 bsize 8192 shift 13 mask 0xffffe000 fsize 2048 shift 11 mask 0xfffff800 frag 4 shift 2 fsbtodb 2 minfree 8% optim time symlinklen 120 maxbsize 8192 maxbpg 1024 maxcontig 16 contigsumsize 16 nbfree 563891 ndir 495168 nifree 3245588 nffree 19898 bpg 10597 fpg 42388 ipg 10624 nindir 1024 inopb 32 maxfilesize 8804691443711 sbsize 2048 cgsize 8192 csaddr 1372 cssize 12288 sblkno 36 cblkno 40 iblkno 44 dblkno 1372 cgrotor 322 fmod 0 ronly 0 clean 0 avgfpdir 64 avgfilesize 16384 flags soft-updates=20 fsmnt /data0 volname swuid 0 Now the server's main function in life is running postgres. I first noticed this error during a maintainence run which sequentially dumps and vacuums each individual database. The are currently 117 databases, most of which are no more than 20M in size, but there are a few outliers, the largest of which is 792M in size. The chunk of this is stored in a single 500+M file, so I can't see this consuming all my inodes, even if soft-updates weren't cleaning up, perhaps I'm wrong. It has since been happening outside of those runs as well. I have searched through various forums and list archives, and while I have found a few references to this error, I have not been able to find a cause and subsequent solution posted. Looking through the source, the error is being logged by ffs_fserr in sys/ufs/ffs/ffs_alloc.c It is being called either by ffs_alloc or by ffs_realloccg after either of the following conditions: ffs_alloc { ... retry: if (size =3D=3D fs->fs_bsize && fs->fs_cstotal.cs_nbfree =3D=3D 0) goto nospace; freespace(fs, fs->fs_minfree) - numfrags(fs, size) < 0) goto nospace; ... nospace: if (fs->fs_pendingblocks > 0 && reclaimed =3D=3D 0) { reclaimed =3D 1; softdep_request_cleanup(fs, ITOV(ip)); goto retry; } ffs_fserr(fs, ip->i_number, "filesystem full"); } My uninformed and uneducated reading of this is that it does not think there are enough blocks free, yet that does not tally with what df is telling me. Looking again at dumpfs, it appears to say that this is formatted with a block size of 8K, and a fragment size of 2K, but tuning(7) says: FreeBSD performs best when using 8K or 16K file system block sizes. The default file system block size is 16K, which provides best performance for most applications, with the exception of those that perform random access on large files (such as database server software). Such applica- tions tend to perform better with a smaller block size, although modern disk characteristics are such that the performance gain from using a smaller block size may not be worth consideration. Using a block size larger than 16K can cause fragmentation of the buffer cache and lead to lower performance. The defaults may be unsuitable for a file system that requires a very large number of i-nodes or is intended to hold a large number of very small files. Such a file system should be created with an 8K or 4K block size. This also requires you to specify a smaller fragment size. We recommend always using a fragment size that is 1/8 the block size (less testing has been done on other fragment size factors). Reading this makes me think that when this server was installed, the block size was dropped from the 16K default to 8K for performance reasons, but the fragment size was not modified accordingly. Would this be the root of my problem? If so, is my only option to back everything up and newfs the disk, or is there something else I can do that will minimise my downtime? Any help and advice would be greatly appreciated. -Feargal. --=20 Feargal Reilly, Chief Techie, FBI. PGP Key: 0x105D7168 (expires: 2006-11-30) Web: http://www.fbi.ie/ | Tel: +353.14988588 | Fax: +353.14988489 Communications House, 11 Sallymount Avenue, Ranelagh, Dublin 6. --Sig_hglNb74cQOwLb8iTICNIkiC Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (FreeBSD) iD8DBQFEwM/VrrAVkRBdcWgRAvZaAJ4p/vatKGlHei+NMAp3kxHMixiGoACdHUNR oAC1HR5jhXUjJN2r0/phGys= =Qm1f -----END PGP SIGNATURE----- --Sig_hglNb74cQOwLb8iTICNIkiC-- From owner-freebsd-stable@FreeBSD.ORG Fri Jul 21 13:01:45 2006 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 202A116A4DF for ; Fri, 21 Jul 2006 13:01:45 +0000 (UTC) (envelope-from feargal@helgrim.com) Received: from mail03.svc.cra.dublin.eircom.net (mail03.svc.cra.dublin.eircom.net [159.134.118.19]) by mx1.FreeBSD.org (Postfix) with SMTP id 2A75A43D46 for ; Fri, 21 Jul 2006 13:01:43 +0000 (GMT) (envelope-from feargal@helgrim.com) Received: (qmail 58731 messnum 276464 invoked from network[82.141.233.46/unknown]); 21 Jul 2006 13:01:42 -0000 Received: from unknown (HELO alatar.edhellond.fbi.ie) (82.141.233.46) by mail03.svc.cra.dublin.eircom.net (qp 58731) with SMTP; 21 Jul 2006 13:01:42 -0000 Received: from mablung.edhellond.fbi.ie (mablung.edhellond.fbi.ie [192.168.0.14]) by alatar.edhellond.fbi.ie (8.13.1/8.13.1) with ESMTP id k6LD1fjB081443 for ; Fri, 21 Jul 2006 13:01:42 GMT (envelope-from feargal@helgrim.com) Date: Fri, 21 Jul 2006 14:01:41 +0100 From: Feargal Reilly To: freebsd-stable@freebsd.org Message-ID: <20060721140141.3fb27c01@mablung.edhellond.fbi.ie> Organization: www.helgrim.com X-Mailer: Sylpheed-Claws 2.1.1 (GTK+ 2.8.7; i386-portbld-freebsd5.4) Mime-Version: 1.0 Content-Type: multipart/signed; boundary="Sig_.m8u=+20sa5qp5S8=X3lg3h"; protocol="application/pgp-signature"; micalg=PGP-SHA1 Subject: filesystem full error with inumber X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Jul 2006 13:01:45 -0000 --Sig_.m8u=+20sa5qp5S8=X3lg3h Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable The following error is being logged in /var/log/messages on FreeBSD 5.4: Jul 21 09:58:44 arwen kernel: pid 615 (postgres), uid 1001 inumber 6166128 on /data0: filesystem full However, this does not appear to be a case of being out of disk space, or running out of inodes: ttyp2$ df -hi Filesystem Size Used Avail Capacity iused ifree %iused Mounted on /dev/amrd0s1f 54G 44G 5.4G 89% 4104458 3257972 56% /data0 Nor does it appear to be a file limit: ttyp2$ sysctl kern.maxfiles kern.openfiles kern.maxfiles: 20000 kern.openfiles: 3582 These reading were not taken at exactly the same time as the error occured, but close to it. Here's the head of dumpfs: magic 19540119 (UFS2) time Fri Jul 21 09:38:40 2006 superblock location 65536 id [ 42446884 99703062 ] ncg 693 size 29360128 blocks 28434238 bsize 8192 shift 13 mask 0xffffe000 fsize 2048 shift 11 mask 0xfffff800 frag 4 shift 2 fsbtodb 2 minfree 8% optim time symlinklen 120 maxbsize 8192 maxbpg 1024 maxcontig 16 contigsumsize 16 nbfree 563891 ndir 495168 nifree 3245588 nffree 19898 bpg 10597 fpg 42388 ipg 10624 nindir 1024 inopb 32 maxfilesize 8804691443711 sbsize 2048 cgsize 8192 csaddr 1372 cssize 12288 sblkno 36 cblkno 40 iblkno 44 dblkno 1372 cgrotor 322 fmod 0 ronly 0 clean 0 avgfpdir 64 avgfilesize 16384 flags soft-updates=20 fsmnt /data0 volname swuid 0 Now the server's main function in life is running postgres. I first noticed this error during a maintainence run which sequentially dumps and vacuums each individual database. The are currently 117 databases, most of which are no more than 20M in size, but there are a few outliers, the largest of which is 792M in size. The chunk of this is stored in a single 500+M file, so I can't see this consuming all my inodes, even if soft-updates weren't cleaning up, perhaps I'm wrong. It has since been happening outside of those runs as well. I have searched through various forums and list archives, and while I have found a few references to this error, I have not been able to find a cause and subsequent solution posted. Looking through the source, the error is being logged by ffs_fserr in sys/ufs/ffs/ffs_alloc.c It is being called either by ffs_alloc or by ffs_realloccg after either of the following conditions: ffs_alloc { ... retry: if (size =3D=3D fs->fs_bsize && fs->fs_cstotal.cs_nbfree =3D=3D 0) goto nospace; freespace(fs, fs->fs_minfree) - numfrags(fs, size) < 0) goto nospace; ... nospace: if (fs->fs_pendingblocks > 0 && reclaimed =3D=3D 0) { reclaimed =3D 1; softdep_request_cleanup(fs, ITOV(ip)); goto retry; } ffs_fserr(fs, ip->i_number, "filesystem full"); } My uninformed and uneducated reading of this is that it does not think there are enough blocks free, yet that does not tally with what df is telling me. Looking again at dumpfs, it appears to say that this is formatted with a block size of 8K, and a fragment size of 2K, but tuning(7) says: FreeBSD performs best when using 8K or 16K file system block sizes. The default file system block size is 16K, which provides best performance for most applications, with the exception of those that perform random access on large files (such as database server software). Such applica- tions tend to perform better with a smaller block size, although modern disk characteristics are such that the performance gain from using a smaller block size may not be worth consideration. Using a block size larger than 16K can cause fragmentation of the buffer cache and lead to lower performance. The defaults may be unsuitable for a file system that requires a very large number of i-nodes or is intended to hold a large number of very small files. Such a file system should be created with an 8K or 4K block size. This also requires you to specify a smaller fragment size. We recommend always using a fragment size that is 1/8 the block size (less testing has been done on other fragment size factors). Reading this makes me think that when this server was installed, the block size was dropped from the 16K default to 8K for performance reasons, but the fragment size was not modified accordingly. Would this be the root of my problem? If so, is my only option to back everything up and newfs the disk, or is there something else I can do that will minimise my downtime? Any help and advice would be greatly appreciated. -Feargal. --=20 Feargal Reilly, Chief Techie, FBI. PGP Key: 0x105D7168 (expires: 2006-11-30) Web: http://www.fbi.ie/ | Tel: +353.14988588 | Fax: +353.14988489 Communications House, 11 Sallymount Avenue, Ranelagh, Dublin 6. --=20 Feargal Reilly. PGP Key: 0x847DE4C8 (expires: 2006-11-30) Web: http://www.helgrim.com/ | ICQ: 109837009 | YIM: ectoraige Visit http://ie.bsd.net/ - BSDs presence in Ireland --Sig_.m8u=+20sa5qp5S8=X3lg3h Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (FreeBSD) iD8DBQFEwNA1Hfl+zYR95MgRAu3CAJ99e4vq9IyBcLRLcJth03RLX1l6EQCeIDmz RoTHGFBxGHmm6obbg8x3sXA= =nQbi -----END PGP SIGNATURE----- --Sig_.m8u=+20sa5qp5S8=X3lg3h-- From owner-freebsd-stable@FreeBSD.ORG Fri Jul 21 13:16:07 2006 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DC80116A4DE for ; Fri, 21 Jul 2006 13:16:06 +0000 (UTC) (envelope-from anton@nikiforov.ru) Received: from vika.newlines.ru (anna.newlines.ru [195.246.218.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1C23543D45 for ; Fri, 21 Jul 2006 13:16:05 +0000 (GMT) (envelope-from anton@nikiforov.ru) Received: from localhost (unknown [127.0.0.1]) by vika.newlines.ru (Postfix) with ESMTP id 533BF1177B for ; Fri, 21 Jul 2006 17:16:03 +0400 (MSD) Received: from vika.newlines.ru ([127.0.0.1]) by localhost (anna.newlines.ru [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 03807-01 for ; Fri, 21 Jul 2006 17:15:54 +0400 (MSD) Received: from [192.168.100.10] (nata.newlines.ru [195.246.218.100]) by vika.newlines.ru (Postfix) with ESMTP for ; Fri, 21 Jul 2006 17:15:53 +0400 (MSD) Message-ID: <44C0D388.3040205@nikiforov.ru> Date: Fri, 21 Jul 2006 17:15:52 +0400 From: Anton Nikiforov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: ru, en-us, en MIME-Version: 1.0 To: freebsd-stable@freebsd.org Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms030309030809070603000709" X-Virus-Scanned: By amavis at office-gw.newlines.ru Subject: gmirror problems X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Jul 2006 13:16:07 -0000 This is a cryptographically signed message in MIME format. --------------ms030309030809070603000709 Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: 7bit Dear All, I have the following gmirror configuration: server1 ggated ggatec create -u 10 -o rw 192.168.100.110 /dev/da1s1d gmirror label -v -b split -s 2048 geom1 /dev/da1s1d /dev/ggate10d ggatec create -u 11 -o rw 192.168.100.110 /dev/da1s1e gmirror label -v -b split -s 2048 geom2 /dev/da1s1e /dev/ggate11 ggatec create -u 12 -o rw 192.168.100.110 /dev/da1s1f gmirror label -v -b split -s 2048 geom3 /dev/da1s1f /dev/ggate12 ggatec create -u 13 -o rw 192.168.100.110 /dev/da1s1g gmirror label -v -b split -s 2048 geom4 /dev/da1s1g /dev/ggate13 ggatec create -u 14 -o rw 192.168.100.110 /dev/da1s1h gmirror label -v -b split -s 2048 geom5 /dev/da1s1h /dev/ggate14 server 2 ggated When I'm starting from scratch. (currently by manually running all commands/daemons) Everything is fine, until I'm trying to mount gmirrored device from server2. What I'm doing listed below 1. Unmounting all file systems 2. stooping all devices (all, but i need only one to start it on another host) 3. stopping daemons 4. Starting daemon on server1 5. Trying to create ggatec device on server2 with the same command, but with IP of server1 getting error: ggatec: ggatec: ioctl(/dev/ggctl): Invalid argument. ggatec: Exiting. 6. looking into gmirror status device list i have all devices in DEGRADED state on server 2 (there was no devices in the list while everything was up) 7. longing into gmirror status device list i have all devices in COMPLETE state and next time gmirror hangs forever. Could you please help me or direct to the right manual? I have found a lot of sources of how to setup (and I'm done with this). But what should i do with failure? How to mount disk on another node or start it after failure? And one more question: is there any way to get gmirror to re mirror devices before carp interfaces become up? I want to get data mirrored before moving services from backup firewall to main one (in case main was failed) And one more thing..... after some manipulations with gmirror devices i have server crushed while booting kernel. At the moment it initialize GEOM_MIRROR device - kernel panics. When i remove the disk that was containing gmirror devices - server just booted normally. But insertion of that disk back and running camcontol rescan all - bring it back to panic... so, i cannot use this disk anymore (i know, that i can rewrite it's last sector on machine without GEOM compiled into the kernel) -- Best regards, Anton Nikiforov --------------ms030309030809070603000709 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJBzCC At4wggJHoAMCAQICED5iPRHTm8oxoqEN/9ixjGgwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UE BhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMT I1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA2MDcyMDA1NTEzM1oX DTA3MDcyMDA1NTEzM1owRDEfMB0GA1UEAxMWVGhhd3RlIEZyZWVtYWlsIE1lbWJlcjEhMB8G CSqGSIb3DQEJARYSYW50b25AbmlraWZvcm92LnJ1MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A MIIBCgKCAQEAzi4dy65s7w6qdSSOecwDqfaU2CVDXGShsD4l89gadJAiIWSSH7kjo8wJIJEK WGRsPfM8zJk5V7EBxNFM3X89g3phBbA+sLYc4+dRJoLLPLAKgsDUWQ3iXUvihNYLwnaLBCiZ 1of+AVIdlZ0A/XN5ZWX9iHqkwFTxfOXG5LGSlBMgeWQQXwz9aDhlSPfgnhjSAMKNI+XxFV/a sVAGfv3YUNDqwRno4HQI7YcSHJh3ozA+m8sWLm5mW8D2wKb0XGKD8Ldm1Mz4sH/mAj+PvsSi bryaq/Se3XuOnvO5IhZGUcLMqfW+bpzgyUsjBPGkKbyOs9ujQZUoFXS71ozQ3sDRaQIDAQAB oy8wLTAdBgNVHREEFjAUgRJhbnRvbkBuaWtpZm9yb3YucnUwDAYDVR0TAQH/BAIwADANBgkq hkiG9w0BAQUFAAOBgQCTvdT0nAzuDCmAa37GaUKw41Ywlp2yxc4wN9g2/CXut9140xMZTfCm Hzsks7pGVZUiGzfZrXx2byVW3uA4r/LFPcGv19dWVx/j3OHBGagfFDVtSkfC/vdGiCG6/Kh/ 3o/0Jf+0TOzBiQv1FznkVN6StXOs7dIQ8ZZIspbcuJzhhTCCAt4wggJHoAMCAQICED5iPRHT m8oxoqEN/9ixjGgwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRo YXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBG cmVlbWFpbCBJc3N1aW5nIENBMB4XDTA2MDcyMDA1NTEzM1oXDTA3MDcyMDA1NTEzM1owRDEf MB0GA1UEAxMWVGhhd3RlIEZyZWVtYWlsIE1lbWJlcjEhMB8GCSqGSIb3DQEJARYSYW50b25A bmlraWZvcm92LnJ1MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAzi4dy65s7w6q dSSOecwDqfaU2CVDXGShsD4l89gadJAiIWSSH7kjo8wJIJEKWGRsPfM8zJk5V7EBxNFM3X89 g3phBbA+sLYc4+dRJoLLPLAKgsDUWQ3iXUvihNYLwnaLBCiZ1of+AVIdlZ0A/XN5ZWX9iHqk wFTxfOXG5LGSlBMgeWQQXwz9aDhlSPfgnhjSAMKNI+XxFV/asVAGfv3YUNDqwRno4HQI7YcS HJh3ozA+m8sWLm5mW8D2wKb0XGKD8Ldm1Mz4sH/mAj+PvsSibryaq/Se3XuOnvO5IhZGUcLM qfW+bpzgyUsjBPGkKbyOs9ujQZUoFXS71ozQ3sDRaQIDAQABoy8wLTAdBgNVHREEFjAUgRJh bnRvbkBuaWtpZm9yb3YucnUwDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUFAAOBgQCTvdT0 nAzuDCmAa37GaUKw41Ywlp2yxc4wN9g2/CXut9140xMZTfCmHzsks7pGVZUiGzfZrXx2byVW 3uA4r/LFPcGv19dWVx/j3OHBGagfFDVtSkfC/vdGiCG6/Kh/3o/0Jf+0TOzBiQv1FznkVN6S tXOs7dIQ8ZZIspbcuJzhhTCCAz8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAwgdExCzAJ BgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEa MBgGA1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2Vy dmljZXMgRGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTEr MCkGCSqGSIb3DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0wMzA3MTcw MDAwMDBaFw0xMzA3MTYyMzU5NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUg Q29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1h aWwgSXNzdWluZyBDQTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV+065ypla HmjAdQRwnd/p/6Me7L3N9VvyGna9fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FW y688Cwfn8R+RNiQqE88r1fOCdz0Dviv+uxg+B79AgAJk16emu59l0cUqVIUPSAR/p7bRPGEE QB5kGXJgt/sCAwEAAaOBlDCBkTASBgNVHRMBAf8ECDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2 oDSGMmh0dHA6Ly9jcmwudGhhd3RlLmNvbS9UaGF3dGVQZXJzb25hbEZyZWVtYWlsQ0EuY3Js MAsGA1UdDwQEAwIBBjApBgNVHREEIjAgpB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxhYmVsMi0x MzgwDQYJKoZIhvcNAQEFBQADgYEASIzRUIPqCy7MDaNmrGcPf6+svsIXoUOWlJ1/TCG4+DYf qi2fNi/A9BxQIJNwPP2t4WFiw9k6GX6EsZkbAMUaC4J0niVQlGLH2ydxVyWN3amcOY6MIE9l X5Xa9/eH1sYITq726jTlEBpbNU1341YheILcIRk13iSx0x1G/11fZU8xggNkMIIDYAIBATB2 MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQu MSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQPmI9EdOb yjGioQ3/2LGMaDAJBgUrDgMCGgUAoIIBwzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwG CSqGSIb3DQEJBTEPFw0wNjA3MjExMzE1NTJaMCMGCSqGSIb3DQEJBDEWBBT9sSmXVTiPPhMl 1ITf6kNGg5slFzBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIA gDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBhQYJKwYBBAGCNxAE MXgwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkg THRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECED5i PRHTm8oxoqEN/9ixjGgwgYcGCyqGSIb3DQEJEAILMXigdjBiMQswCQYDVQQGEwJaQTElMCMG A1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBl cnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECED5iPRHTm8oxoqEN/9ixjGgwDQYJKoZIhvcN AQEBBQAEggEAFRrKyB8HDvI8fzlUlfCwBqZ5ZC+JqDk5jQfLXhfDvvSLUfGWxJglZx2YSr6O TbseMVMe0gkCiSCgH0tv52BEKpqe9Z+JBJZRBW8LIhqM5EE06RHmcUO2xrDl8hz7VRA4bj5k Ot2dEUo3k1cIz4Hrx1crt+FGjNoyKMCM4jRvN0r+IqGxfoxwAzgDsViPmBeVle0YS6kFOExa zn9k3FrmCH4dndglECxnC/y+RQUu2jjh9nNga4bxwPPgTGA8+DxdJxpysw6mOqyUOBLywOYt teDZ/DUNdBfkOkO1K/F2ESIvywLieE7td5xx4UeUv9+WJHzrIlasdM7XBBVoKfoE8AAAAAAA AA== --------------ms030309030809070603000709-- From owner-freebsd-stable@FreeBSD.ORG Fri Jul 21 14:24:23 2006 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C848916A4E8; Fri, 21 Jul 2006 14:24:23 +0000 (UTC) (envelope-from GMcCaughan@synaptics-uk.com) Received: from mx2.synaptics-uk.com (mx2.synaptics-uk.com [194.203.111.209]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3945143D55; Fri, 21 Jul 2006 14:24:16 +0000 (GMT) (envelope-from GMcCaughan@synaptics-uk.com) Received: from firewall.synaptics-uk.com ([194.203.111.212] helo=ukexchange2k.synaptics-inc.local) by mx2.synaptics-uk.com with esmtp (Exim 4.62) (envelope-from ) id 1G3vvL-0007Cn-Ps; Fri, 21 Jul 2006 15:24:15 +0100 Received: from lists.synaptics-uk.com ([172.20.11.6]) by ukexchange2k.synaptics-inc.local with Microsoft SMTPSVC(5.0.2195.6713); Fri, 21 Jul 2006 15:24:10 +0100 Received: from [172.20.11.5] (unknown [172.20.11.5]) by lists.synaptics-uk.com (Postfix) with ESMTP id 92C4417011; Fri, 21 Jul 2006 15:04:35 +0100 (BST) From: Gareth McCaughan To: freebsd-questions@freebsd.org, freebsd-stable@freebsd.org Date: Fri, 21 Jul 2006 15:24:09 +0100 User-Agent: KMail/1.9.1 References: <200607132002.43637.gmccaughan@synaptics-uk.com> In-Reply-To: <200607132002.43637.gmccaughan@synaptics-uk.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200607211524.10033.gmccaughan@synaptics-uk.com> X-OriginalArrivalTime: 21 Jul 2006 14:24:10.0698 (UTC) FILETIME=[555DA2A0:01C6ACD1] Cc: Subject: Re: "swiN: clock sio" process taking 75% CPU X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Jul 2006 14:24:24 -0000 I wrote: > About 6 minutes after booting (on two occasions; I don't > guarantee that this doesn't vary), a process that appears > in the output of "ps" as "[swi4: clock sio]" begins to > use about 3/4 of the machine's CPU. I think it does so > more or less instantaneously. It continues to do so > indefinitely, so far as I can tell. So, here's the answer. Whether it's the same thing that's afflicted the other people who've reported similar problems, I don't know. (Thanks to John Baldwin on -hackers for pointing me in a useful direction.) Executive summary: If you see symptoms like the one above, are you running a syscons screen saver? (To check: run "kldstat | grep _saver".) If so, turn it off and the problem may go away. 1. The machine in question runs largely unattended. 2. I'd enabled the syscons screen saver and chosen one of the ones that puts the screen into a graphics mode. ("warp", as it happens; "fire" behaves similarly; the character-mode ones don't; I haven't looked at all of them.) 3. The screen saver kicks in 5 minutes after it gets turned on in /etc/rc.d/syscons, provided nothing's happening on the console. Which it isn't: see #1. 4. Now, how do those graphics-mode screen savers work? They write to the video card's frame buffer directly, but there's only a 64k block of RAM they can do this through. So, to cope with larger screens, there's a bank switching facility accessed by a BIOS call. 5. This BIOS call, on my machine, takes about 0.1ms; you need to do two of them for a bank switch, so the time actually taken is about 0.2ms. 6. The screen savers are written in a less than optimal way, and do that bank switching thing many times. For instance, the "fire" screen saver does it at least once for every screen line. Even when the entire screen actually fits into a single bank so that no switching at all should be needed. 7. So the screensaver eats up something on the order of half my CPU time; the exact figure depends on which screensaver and on more exact timings than I've given above, which is how it ends up actually being 75% for the "warp" screensaver. 8. The screensaver gets run in callouts from a kernel interrupt thread that happens to have a silly name like "swi4: clock sio". This is eminently fixable, in several different ways. I've offered to prepare a patch, or perhaps someone else will do so, so there's a reasonable prospect of later versions of FreeBSD not having this problem. For the time being, there's a simple workaround for anyone facing the same problem I did: *turn off the screensaver*, or replace it with one that doesn't use a graphics mode. For clarity: this is a problem with (some) FreeBSD syscons screen savers, the ones you might enable in /etc/rc.conf; not with the ones like xscreensaver that you might run in user mode under X. -- g From owner-freebsd-stable@FreeBSD.ORG Fri Jul 21 16:15:33 2006 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 51A4016A4E1 for ; Fri, 21 Jul 2006 16:15:33 +0000 (UTC) (envelope-from mb@tns.cz) Received: from web.net-online.cz (debian.net-online.cz [82.117.134.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6AC1843D62 for ; Fri, 21 Jul 2006 16:15:27 +0000 (GMT) (envelope-from mb@tns.cz) Received: from localhost (unknown [127.0.0.1]) by web.net-online.cz (Postfix) with ESMTP id EFD5C4280C2 for ; Fri, 21 Jul 2006 16:19:20 +0000 (UTC) Received: from web.net-online.cz ([127.0.0.1]) by localhost (web.net-online.cz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 07211-10 for ; Fri, 21 Jul 2006 18:19:18 +0200 (CEST) Received: from mb.tns.cz (unknown [82.117.134.24]) by web.net-online.cz (Postfix) with ESMTP id 21C3B4280C0 for ; Fri, 21 Jul 2006 18:19:17 +0200 (CEST) Received: by mb.tns.cz (Postfix, from userid 1205) id 92E09F1; Fri, 21 Jul 2006 18:15:22 +0200 (CEST) Date: Fri, 21 Jul 2006 18:15:22 +0200 From: Martin Beran To: freebsd-stable@freebsd.org Message-ID: <20060721161522.GA10111@mb.tns.cz> References: <200607210205.51614.max@love2party.net> <20060721010559.GB23227@insomnia.benzedrine.cx> <1153410809.1126.66.camel@genius.i.cz> <200607210205.51614.max@love2party.net> <1153410809.1126.66.camel@genius.i.cz> <44BFA8F9.8010403@jellydonut.org> <1153433881.1173.3.camel@genius.i.cz> <1153410809.1126.66.camel@genius.i.cz> <44BFA8F9.8010403@jellydonut.org> <1153410809.1126.66.camel@genius.i.cz> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060721010559.GB23227@insomnia.benzedrine.cx> <200607210205.51614.max@love2party.net> <1153433881.1173.3.camel@genius.i.cz> <44BFA8F9.8010403@jellydonut.org> <1153410809.1126.66.camel@genius.i.cz> User-Agent: Mutt/1.4.2.1i X-Virus-Scanned: amavisd-new at net-online.cz Subject: Re: Kernel panic with PF X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Jul 2006 16:15:33 -0000 Hello, I am the author of the proxy code you have been discussing here. I have done some investigation today and I will try to summarize the results. > Thank you. No, I am not using it and I am quite sure the proxies aren't > doing it behind my back either. In fact there isn't a single entry in I can confirm that the proxies do not use any user/group rules. > the rules tables - there are only rdr rules generated on the fly by the > proxies. Depending on configuration, the proxies can install rdr and/or map rules. The rdr rules are used for "incoming transparency", i.e., to catch clients' connections going through the firewall, but with the target server's destination address, not the firewall's. The map rules are used for "outgoing transparency", i.e., for changing the source address of connections to servers (for example, the original client source IP can be used instead of the firewall's IP). > Which proxies are you using? The "pool_ticket: 1429 != 1430" messages you > quote below indicate a synchronization problem within the app talking to pf > via ioctl's. Tickets are used to ensure atomic commits for operations that This should be only a transient error. The proxies detect this situation and retry the failed operation. The idea behind this behavior was that the ruleset manipulation is done by a small number of ioctls called quickly one after another by a single function, hence the collisions should not occur too often. But maybe I can add exclusive locking of the PF device, which should remove all collisions among several proxy processes trying to change PF rules at the same time. > If the proxy is using DIOCCHANGERULE (it must be the proxy, pfctl isn't > using it at all), AND is trying to add/update a rule that requires at > least one replacement address but contains an empty list, then this > would cause the panic seen when that rule later matches a packet. I think this is not the case. The proxy uses either DIOCXBEGIN + DIOCBEGINADDRS + DIOCADDADDR + DIOCADDRULE + DIOCXCOMMIT or DIOCCHANGERULE(PF_CHANGE_GET_TICKET) + DIOCBEGINADDRS + DIOCADDADDR + DIOCCHANGERULE(PF_CHANGE_ADD_TAIL). The first method is used in the first call to create the ruleset. In the subsequent call, the second method is used to modify the ruleset. But the list is never empty. If it was, the panics would occur always, which is not happening - there are other installations (but probably not 64bit SMP) working well. I can imagine the list becoming empty only if some other process deletes it by DIOCBEGINADDRS during pfioctl processing, after the "pcr->pool_ticket != ticket_pabuf" check. But this should be guarded by PF_LOCK. Of course, I could make some mistake in the calling sequence of PF ioctl. I wrote this piece of code by trial and error, using pfctl as a source of ideas, because I have not found a detailed manual for the PF API. > Michal, can you please confirm that the patch above fixes the panic? > The proxy will still misbehave and cause the log messages (one more > EINVAL in this case ;), but the kernel shouldn't crash anymore. Yes, the patch should fix the panics, but it does not solve the problem. > This functionality of the software (using PF with anchors) is quite new It is not so new, it is now about 9 months in production use. > Anchors were introduced for this purpose, i.e. splitting the ruleset > into separate pieces, over each of which a single process can have > authority, so different processes don't stomp on each other's toes with > ruleset modifications. In fact, the possibility to split the ruleset into anchors owned by individual processes was one our major reasons to move from IPF to PF. > Ask them if they really need to still use DIOCCHANGERULE, as the idea > with anchors is generally to only operate within one anchor, and usually > flush or replace the (smaller) ruleset within. DIOCCHANGERULE is useful for us, because each proxy process can have several redirections or mappings and it creates/deletes them incrementally, as it opens/closes individual network connections. It seems to me unnecessary to always replace the whole ruleset. > Each anchor has its own ticket, so if you're seeing ticket mismatches, > that means there are concurrent operations on the same anchor, even. But the conflicts are on the pool_ticket which is, as I understand it, only one for all operations. > They (the Kernun authors) run multiple processes for each proxy. > Originally they used slightly modified Apached core for their proxies I > believe. Thus there are probably more processes using the same anchor. No, there are not. The anchors are even named by the owner process ID. > I don't really understand what they do inside - I would think that when > there are no traffic blocking rules, there's no point in doing anything > with PF except initial setting of the rdr rule to the proxy. As I have mentioned above, there are dynamicaly created rules for outgoing transparent connections (source-address in the configuration) and for some special cases, e.g., handling FTP data connections. -- Martin Beran Senior Developer Trusted Network Solutions, a.s. [ www.tns.cz ] From owner-freebsd-stable@FreeBSD.ORG Fri Jul 21 16:23:46 2006 Return-Path: X-Original-To: stable@freebsd.org Delivered-To: freebsd-stable@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id AB10616A4DD for ; Fri, 21 Jul 2006 16:23:46 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [209.31.154.42]) by mx1.FreeBSD.org (Postfix) with ESMTP id 14F1B43D4C for ; Fri, 21 Jul 2006 16:23:46 +0000 (GMT) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [209.31.154.41]) by cyrus.watson.org (Postfix) with ESMTP id 8479946CAF; Fri, 21 Jul 2006 12:23:45 -0400 (EDT) Date: Fri, 21 Jul 2006 17:23:45 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Holtor In-Reply-To: <20060721014004.85734.qmail@web31708.mail.mud.yahoo.com> Message-ID: <20060721172221.Q79560@fledge.watson.org> References: <20060721014004.85734.qmail@web31708.mail.mud.yahoo.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: stable@freebsd.org Subject: Re: Frozen Processes X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Jul 2006 16:23:46 -0000 On Thu, 20 Jul 2006, Holtor wrote: > Since upgrading some of our 5.4 servers to the latest 6.1-STABLE we've had > some processes stuck in the *inp state as listed in 'top'. Those processes > can't be killed and any resources they use up in terms of bound IP addresses > or ports can't be freed. Does anyone know what this *inp state means or how > to fix this problem? Processes in state '*inp' are waiting for an inpcb lock, suggesting a deadlock or lock leak. Can you compile your kernel with invariants, witness, ddb, etc, and do a bit of kernel debugging? You can find basic instructions in the handbook; what I'm particularly interested in is the output of "alltrace", "show alllocks", "show allpcpu". Robert N M Watson Computer Laboratory University of Cambridge From owner-freebsd-stable@FreeBSD.ORG Fri Jul 21 18:30:18 2006 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id F37AA16A4E2 for ; Fri, 21 Jul 2006 18:30:17 +0000 (UTC) (envelope-from ubm@u-boot-man.de) Received: from mail.upper.net (mail.upper.net [62.75.224.33]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5DD7543D45 for ; Fri, 21 Jul 2006 18:30:17 +0000 (GMT) (envelope-from ubm@u-boot-man.de) Received: from greatsheep.marines (p54981D79.dip0.t-ipconnect.de [84.152.29.121]) (authenticated bits=0) by mail.upper.net (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k6LIUGF9006540 for ; Fri, 21 Jul 2006 20:30:22 +0200 Date: Fri, 21 Jul 2006 20:29:43 +0200 From: Marc "UBM" Bocklet To: freebsd-stable@freebsd.org Message-Id: <20060721202943.00b05a55.ubm@u-boot-man.de> X-Mailer: Sylpheed version 1.0.6 (GTK+ 1.2.10; i386-portbld-freebsd6.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: linux-firefox does not run on FreeBSD 6.1 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Jul 2006 18:30:18 -0000 Hiho! :-) When trying to start linux-firefox on: FreeBSD greatsheep 6.1-RC FreeBSD 6.1-RC #5: Tue May 2 20:33:32 CEST 2006 root@greatsheep:/usr/obj/usr/src/sys/SUBMARINE_SMP i386 it complains about: /usr/X11R6/lib/linux-firefox/firefox-bin: error while loading shared libraries: /usr/lib/libm.so.6: ELF file OS ABI invalid I've installed the newest linux_base-fc-4_6 from ports and I also have the newest linux-firefox. Question now is if there is anything I can do about this? :-) Thanks in advance. Bye Marc From owner-freebsd-stable@FreeBSD.ORG Fri Jul 21 18:50:47 2006 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4EFB216A4E1 for ; Fri, 21 Jul 2006 18:50:47 +0000 (UTC) (envelope-from vinny@tellurian.com) Received: from mail1.tellurian.net (mail1.tellurian.net [216.182.1.23]) by mx1.FreeBSD.org (Postfix) with ESMTP id 13EC443D46 for ; Fri, 21 Jul 2006 18:50:38 +0000 (GMT) (envelope-from vinny@tellurian.com) Received: from cactus.tellurian.com (cactus.tellurian.net [216.182.1.34]) by mail1.tellurian.net ([216.182.1.23] Tellurian Networks Mail Server version 3.7c-30) with ESMTP id 444898998 for multiple; Fri, 21 Jul 2006 14:50:37 -0400 Message-Id: <7.0.1.0.2.20060721144338.0a320808@tellurian.com> X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0 Date: Fri, 21 Jul 2006 14:50:36 -0400 To: Nealie ,freebsd-stable@freebsd.org From: Vinny Abello In-Reply-To: <1153484676.902.3.camel@server.home> References: <1153396289.823.16.camel@server.home> <1153484676.902.3.camel@server.home> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Authenticated-User: vinny@tellurian.com X-Ultimate-Internet-Connection: Tellurian Networks Cc: Subject: Re: NVIDIA 6600GT Freeze X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Jul 2006 18:50:47 -0000 At 08:24 AM 7/21/2006, Nealie wrote: >On Thu, 2006-07-20 at 13:51 +0200, Nealie wrote: > > I have a problem with my system freezing when using an NVIDIA video card > > using the nvidia-driver port. All seems to work fine for a while but > > then the system freezes and won't even reply to a ping. This can happen > > regardless of whether I use openGL or not. > > > > Everything works fine using the "nv" driver, so it doesn't seem to be a > > hardware problem. > > > > My setup is as follows: > > > > uname: FreeBSD server.home 6.1-STABLE FreeBSD 6.1-STABLE #0: Wed Jul 19 > > 11:19:16 CEST 2006 root@server.home:/usr/obj/usr/src/sys/SERVER > > i386 > > > > AGP NVIDIA 6600GT installed on an MSI K8T Neo-F V2.09 motherboard (VIA > > K8T800 Pro chipset) with an AMD Athlon 64 3500+ CPU. > > > > The NVIDIA driver is installed as per the instructions, with agp and dri > > removed from the kernel in order to use the NVIDIA agp interface, even > > though the sysctl settings suggest otherwise. > > > > If anyone has any ideas about this problem I'd be very grateful. > >Just a quick reply to myself: The problem seems to be that the the IRQs >of the motherboards on board network interface and the AGP card are the >same. This works for a while but then something goes horribly wrong and >all comes to a halt. Why the IRQ is shared I have no idea as there are >nine free IRQs. On most machines I have seen, IRQ's are shared between certain "slots". You can change the IRQ that is being used but not the devices sharing it. I believe this is inherent to the current PC architecture and motherboard design. Being that the NIC is integrated and you have so many other IRQ's free, I'm not sure why they chose that route for your board. Perhaps NICs can generally share with video cards without problems. In general (not guaranteed), devices *should* be able to share IRQ's if the drivers are written properly and if the hardware isn't designed horribly. This is just a generalization of my own experiences. I in no way write drivers for hardware for any operating system. YMMV. :) Vinny Abello Network Engineer Server Management vinny@tellurian.com (973)300-9211 x 125 (973)940-6125 (Direct) PGP Key Fingerprint: 3BC5 9A48 FC78 03D3 82E0 E935 5325 FBCB 0100 977A Tellurian Networks - The Ultimate Internet Connection http://www.tellurian.com (888)TELLURIAN "Courage is resistance to fear, mastery of fear - not absence of fear" -- Mark Twain From owner-freebsd-stable@FreeBSD.ORG Sat Jul 22 06:26:44 2006 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 358EB16A4DF for ; Sat, 22 Jul 2006 06:26:44 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from mail2.fluidhosting.com (mx24.fluidhosting.com [204.14.89.7]) by mx1.FreeBSD.org (Postfix) with SMTP id 73E0443D46 for ; Sat, 22 Jul 2006 06:26:43 +0000 (GMT) (envelope-from dougb@FreeBSD.org) Received: (qmail 18005 invoked by uid 399); 22 Jul 2006 06:26:42 -0000 Received: from localhost (HELO ?192.168.0.3?) (dougb@dougbarton.us@127.0.0.1) by localhost with SMTP; 22 Jul 2006 06:26:42 -0000 Message-ID: <44C1C51D.2040201@FreeBSD.org> Date: Fri, 21 Jul 2006 23:26:37 -0700 From: Doug Barton Organization: http://www.FreeBSD.org/ User-Agent: Thunderbird 1.5.0.4 (X11/20060604) MIME-Version: 1.0 To: Ganbold References: <44C06A94.5070909@micom.mng.net> In-Reply-To: <44C06A94.5070909@micom.mng.net> X-Enigmail-Version: 0.94.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: tbyte@otel.net, freebsd-stable@freebsd.org, wpaul@freebsd.org Subject: Re: ndisgen generated module load causes page fault, missing functions X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Jul 2006 06:26:44 -0000 Ganbold wrote: > Hi, > > I have FreeBSD-6.1-STABLE dell D620 laptop with Dell Wireless 1490 > 802.11a/g Dual-band Mini Card (which seems like bcm4310). In my experience, you should try various versions of the Windows driver. I have a 1400, and the very latest version of the driver does not work with NDIS, but the version previous to that does. hth, Doug -- This .signature sanitized for your protection From owner-freebsd-stable@FreeBSD.ORG Sat Jul 22 09:38:48 2006 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id EB02F16A4DD for ; Sat, 22 Jul 2006 09:38:48 +0000 (UTC) (envelope-from me@hawei.net2.nerim.net) Received: from hawei.net2.nerim.net (hawei.net2.nerim.net [213.41.129.28]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8513C43D46 for ; Sat, 22 Jul 2006 09:38:48 +0000 (GMT) (envelope-from me@hawei.net2.nerim.net) Received: by hawei.net2.nerim.net (Postfix, from userid 1001) id 0475E450C3; Sat, 22 Jul 2006 11:42:15 +0200 (CEST) Date: Sat, 22 Jul 2006 11:42:14 +0200 From: Harald Weis To: freebsd-stable@freebsd.org Message-ID: <20060722094214.GA1498@hawei.net2.nerim.net> Mail-Followup-To: freebsd-stable@freebsd.org References: <20060718143012.GA92325@hawei.net2.nerim.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060718143012.GA92325@hawei.net2.nerim.net> User-Agent: Mutt/1.4.2.1i Subject: Re: Canon PIXMA support X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Jul 2006 09:38:49 -0000 On Tue, Jul 18, 2006 at 04:30:12PM +0200, Harald Weis wrote: > On Tue, Jun 27, 2006 at 07:27:50PM +0300, Ivan Asmer wrote: > > Hello everyone. > > > > I'm interesting how to run my canon pixma iP 1500 under my honest freebsd. > > As I found in internet this is impossible. Who can say more? > > I got my iP 5000 working with cups and gimp-print (WITH_CUPS). > > I haven't tried apsfilter yet which I would prefer because cups disallows a2ps. For your information: apsfilter has just nicely installed my PIXMA iP 5000 (device node /dev/ulpt0). Bye Harald Weis -- FreeBSD 6.1-RELEASE #0: Sun May 7 04:42:56 UTC 2006 From owner-freebsd-stable@FreeBSD.ORG Sat Jul 22 11:56:47 2006 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D795616A4DF for ; Sat, 22 Jul 2006 11:56:47 +0000 (UTC) (envelope-from nikolas.britton@gmail.com) Received: from ug-out-1314.google.com (ug-out-1314.google.com [66.249.92.171]) by mx1.FreeBSD.org (Postfix) with ESMTP id 41FA743D46 for ; Sat, 22 Jul 2006 11:56:46 +0000 (GMT) (envelope-from nikolas.britton@gmail.com) Received: by ug-out-1314.google.com with SMTP id m2so1708633uge for ; Sat, 22 Jul 2006 04:56:46 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=RK8lzLt47f2AQiHuAzoSWCjfOg1sicTPrL4ixtNJdM+v6SbCae3AgFVrY8CBDBT2s1IEE0LDTqN9j3iwBQIito2ujrlxlL/mlyFHnFsoTc2TY/qnLUJfrQa/4LJuyK0O+3tBxEcHSCwq2xehCbA8ZbN55ivi1xVQG5Na+xbvY1Q= Received: by 10.78.179.12 with SMTP id b12mr801026huf; Sat, 22 Jul 2006 04:56:44 -0700 (PDT) Received: by 10.78.143.13 with HTTP; Sat, 22 Jul 2006 04:56:44 -0700 (PDT) Message-ID: Date: Sat, 22 Jul 2006 06:56:44 -0500 From: "Nikolas Britton" To: "FreeBSD Stable List" MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Subject: Xen dom0 support? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Jul 2006 11:56:47 -0000 Does FreeBSD support Xen 3 dom0 yet??? What's the current status of domU support? Does Net/Open BSD support Xen 3 dom0? -- BSD Podcasts @: http://bsdtalk.blogspot.com/ http://freebsdforall.blogspot.com/ From owner-freebsd-stable@FreeBSD.ORG Sat Jul 22 12:47:22 2006 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E84C716A4DA for ; Sat, 22 Jul 2006 12:47:22 +0000 (UTC) (envelope-from lopisaur@gmail.com) Received: from wx-out-0102.google.com (wx-out-0102.google.com [66.249.82.199]) by mx1.FreeBSD.org (Postfix) with ESMTP id 20EA843D68 for ; Sat, 22 Jul 2006 12:47:21 +0000 (GMT) (envelope-from lopisaur@gmail.com) Received: by wx-out-0102.google.com with SMTP id i31so568624wxd for ; Sat, 22 Jul 2006 05:47:20 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:subject:from:reply-to:to:cc:in-reply-to:references:content-type:date:message-id:mime-version:x-mailer:content-transfer-encoding; b=kyNmhk0B+3EheDKuLo94EOzWQ2vi66Wp/0yaAGZHVZ1lY1wTCdgkrN4AYCC/VMr/6JPIdjwCzwG4vEfG0DUZb0VrbrDeP3sGfOUe2P2svb3log4snDrwBx0G5hiBbBah8yEaFyuJrJiAuUkp4HOA/jwAyXxfCdjOn1hUENreI2I= Received: by 10.70.45.18 with SMTP id s18mr2470814wxs; Sat, 22 Jul 2006 05:47:20 -0700 (PDT) Received: from hellion.clcw ( [200.105.130.182]) by mx.gmail.com with ESMTP id i35sm1648631wxd.2006.07.22.05.47.18; Sat, 22 Jul 2006 05:47:20 -0700 (PDT) From: Christian Lopez de Castilla Wagner To: freebsd-stable@freebsd.org In-Reply-To: <20060722120047.843B316A663@hub.freebsd.org> References: <20060722120047.843B316A663@hub.freebsd.org> Content-Type: text/plain Date: Sat, 22 Jul 2006 08:51:24 -0400 Message-Id: <1153572684.87441.6.camel@hellion.clcw> Mime-Version: 1.0 X-Mailer: Evolution 2.6.2 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: Subject: Re: linux-firefox does not run on FreeBSD 6.1 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: lopisaur@gmail.com List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Jul 2006 12:47:23 -0000 On Sat, 2006-07-22 at 12:00 +0000, ubm@u-boot-man.de wrote: > Hiho! :-) > > When trying to start linux-firefox on: > > FreeBSD greatsheep 6.1-RC FreeBSD 6.1-RC #5: Tue May 2 > 20:33:32 CEST > 2006 root@greatsheep:/usr/obj/usr/src/sys/SUBMARINE_SMP > i386 > > it complains about: > > /usr/X11R6/lib/linux-firefox/firefox-bin: error while loading > shared > libraries: /usr/lib/libm.so.6: ELF file OS ABI invalid > > > I've installed the newest linux_base-fc-4_6 from ports and I > also have > the newest linux-firefox. > > Question now is if there is anything I can do about this? :-) > > Thanks in advance. > > Bye > Marc > Even though this is the wrong list for this (use qestions or ports), this is a quickie: brandelf -t linux That ought to do the trick. From owner-freebsd-stable@FreeBSD.ORG Sat Jul 22 13:20:28 2006 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 108CF16A4DF for ; Sat, 22 Jul 2006 13:20:28 +0000 (UTC) (envelope-from nikolas.britton@gmail.com) Received: from ug-out-1314.google.com (ug-out-1314.google.com [66.249.92.171]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2D34743D46 for ; Sat, 22 Jul 2006 13:20:26 +0000 (GMT) (envelope-from nikolas.britton@gmail.com) Received: by ug-out-1314.google.com with SMTP id m2so1728393uge for ; Sat, 22 Jul 2006 06:20:25 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=C2v5DdejUbuGflXVGy/8bj0Xi/YU68be8X7bRHa7SZ9nstIN7Ca1KsaN0+lu78loTFzff+hYZFCjkSgtoTcwFMlhc5sjSlzmCxCcuDbFUHN3/fjFvvRwM5Qk+V20SHTyw2U+XEz5C38JTj07l6KyNkVzRiCJJiOVsGAy1MjUySY= Received: by 10.78.193.5 with SMTP id q5mr830182huf; Sat, 22 Jul 2006 06:20:25 -0700 (PDT) Received: by 10.78.143.13 with HTTP; Sat, 22 Jul 2006 06:20:25 -0700 (PDT) Message-ID: Date: Sat, 22 Jul 2006 08:20:25 -0500 From: "Nikolas Britton" To: "FreeBSD Stable List" In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: Subject: Re: Xen dom0 support? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Jul 2006 13:20:28 -0000 On 7/22/06, Nikolas Britton wrote: > Does FreeBSD support Xen 3 dom0 yet??? > What's the current status of domU support? > Does Net/Open BSD support Xen 3 dom0? > NetBSD has Xen 3 dom0 support: http://mail-index.netbsd.org/port-xen/2006/07/03/0000.html -- BSD Podcasts @: http://bsdtalk.blogspot.com/ http://freebsdforall.blogspot.com/ From owner-freebsd-stable@FreeBSD.ORG Sat Jul 22 13:44:35 2006 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 562A716A4DE for ; Sat, 22 Jul 2006 13:44:35 +0000 (UTC) (envelope-from daniel@copyleft.no) Received: from mail9.copyleft.no (mail9.copyleft.no [82.117.37.109]) by mx1.FreeBSD.org (Postfix) with ESMTP id F1E7B43D46 for ; Sat, 22 Jul 2006 13:44:34 +0000 (GMT) (envelope-from daniel@copyleft.no) Received: from 212.80-202-72.nextgentel.com ([80.202.72.212] helo=[10.0.0.170]) by mail9.copyleft.no with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1G4Hmq-000FjK-85 for freebsd-stable@freebsd.org; Sat, 22 Jul 2006 13:44:56 +0000 Message-ID: <44C22BB6.8010104@copyleft.no> Date: Sat, 22 Jul 2006 15:44:22 +0200 From: "Hr. Daniel Mikkelsen" User-Agent: Thunderbird 1.5.0.2 (X11/20060522) MIME-Version: 1.0 To: freebsd-stable@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Slow RAID1 with gmirror X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Jul 2006 13:44:35 -0000 Hi. I've been setting up some gmirror based software RAID1s lately, and I keep running into some odd behaviour. Writing to the RAID1 runs at near to normal rates, as expected. But reading from the RAID1 runs at half the normal rates, while I expected to get double rates. I've tested this on 6.0, 6.1, with PATA and SATA drives, and I consistently get the same results. I've tested with the same hardware running Linux 2.6 with software RAID1 and there I get the expected double rate. I've tried all the available balance algorithms, and none of them help. I haven't tried with SCSI disks. I'm thinking that it might be the test I'm running that's a corner case, I simply dd to or from the filesystem with various settings for bs=. Is this a know issue? Is it an issue at all? -- Daniel Mikkelsen Copyleft Software AS -- Daniel Mikkelsen Copyleft Software AS From owner-freebsd-stable@FreeBSD.ORG Sat Jul 22 18:23:45 2006 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D81F716A4DE for ; Sat, 22 Jul 2006 18:23:45 +0000 (UTC) (envelope-from rblayzor@inoc.net) Received: from mx0-b.inoc.net (mx0-b.inoc.net [64.246.130.28]) by mx1.FreeBSD.org (Postfix) with ESMTP id B9C2443D6D for ; Sat, 22 Jul 2006 18:23:41 +0000 (GMT) (envelope-from rblayzor@inoc.net) Received: from [172.16.16.40] (cpe-24-29-66-248.nycap.res.rr.com [24.29.66.248]) by mx0-b.inoc.net (build v6.3.3) with ESMTP id 71376800 for ; Sat, 22 Jul 2006 18:23:40 +0000 (UTC) Message-ID: <44C26D28.4000304@inoc.net> Date: Sat, 22 Jul 2006 14:23:36 -0400 From: Robert Blayzor Organization: Independent Network Operations Consortium, LLC User-Agent: Thunderbird 1.5.0.4 (Macintosh/20060516) MIME-Version: 1.0 To: freebsd-stable@freebsd.org X-Enigmail-Version: 0.94.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Sun X86 servers X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Jul 2006 18:23:45 -0000 I'd like to know if anyone is using the Sun X86 servers with 6.x. If so, how is it preforming? I'm looking at possibly using them in a diskless environment (and a couple possibly with disks) I've read in the past that the disk controllers were not supported yet, I'm not sure if that's changed (or changing). What about network controllers? Please contact me off-list (unless others are interested as well). TIA! -- Robert Blayzor, BOFH INOC, LLC rblayzor\@(inoc.net|gmail.com) PGP: 0x66F90BFC @ http://pgp.mit.edu Key fingerprint = 6296 F715 038B 44C1 2720 292A 8580 500E 66F9 0BFC To define recursion, we must first define recursion. From owner-freebsd-stable@FreeBSD.ORG Sat Jul 22 18:45:36 2006 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 857CB16A4DE for ; Sat, 22 Jul 2006 18:45:36 +0000 (UTC) (envelope-from ajsbsd@gmail.com) Received: from py-out-1112.google.com (py-out-1112.google.com [64.233.166.181]) by mx1.FreeBSD.org (Postfix) with ESMTP id E194243D46 for ; Sat, 22 Jul 2006 18:45:35 +0000 (GMT) (envelope-from ajsbsd@gmail.com) Received: by py-out-1112.google.com with SMTP id b36so1545590pyb for ; Sat, 22 Jul 2006 11:45:35 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:references; b=mXDYU4V6lKIzkCnMAGwu7trC9Yj4ZMZQeucKvFyTzhP0ehSwjIX3t7ufyX96NfIp6aTqMl8DAxFwHLsE5aOnam/R89aQ+z93KPclrRI3qKnu+3nO3UmKXPbMMXFxZ+n2S4RnSUIamsLut+GSz7t0jB9sYW9VU/8ljLnzLuCubIE= Received: by 10.35.70.2 with SMTP id x2mr3832165pyk; Sat, 22 Jul 2006 11:45:35 -0700 (PDT) Received: by 10.35.79.20 with HTTP; Sat, 22 Jul 2006 11:45:35 -0700 (PDT) Message-ID: Date: Sat, 22 Jul 2006 14:45:35 -0400 From: "Aaron Summers" To: freebsd-stable@freebsd.org In-Reply-To: <44C26D28.4000304@inoc.net> MIME-Version: 1.0 References: <44C26D28.4000304@inoc.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Re: Sun X86 servers X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Jul 2006 18:45:36 -0000 We have about a dozen Sunfire X2100's in production running RELENG_6 The only problem we have had was with the nve driver, but bge works fine. The boxes are web and database servers. On 7/22/06, Robert Blayzor wrote: > > I'd like to know if anyone is using the Sun X86 servers with 6.x. If > so, how is it preforming? I'm looking at possibly using them in a > diskless environment (and a couple possibly with disks) I've read in > the past that the disk controllers were not supported yet, I'm not sure > if that's changed (or changing). What about network controllers? > > Please contact me off-list (unless others are interested as well). > > TIA! > > -- > Robert Blayzor, BOFH > INOC, LLC > rblayzor\@(inoc.net|gmail.com) > PGP: 0x66F90BFC @ http://pgp.mit.edu > Key fingerprint = 6296 F715 038B 44C1 2720 292A 8580 500E 66F9 0BFC > > To define recursion, we must first define recursion. > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" > From owner-freebsd-stable@FreeBSD.ORG Sat Jul 22 19:13:36 2006 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 48D0616A4E0 for ; Sat, 22 Jul 2006 19:13:36 +0000 (UTC) (envelope-from jamesog@starbug.netinertia.co.uk) Received: from starbug.netinertia.co.uk (starbug.netinertia.co.uk [217.147.82.211]) by mx1.FreeBSD.org (Postfix) with ESMTP id E7CD543D46 for ; Sat, 22 Jul 2006 19:13:35 +0000 (GMT) (envelope-from jamesog@starbug.netinertia.co.uk) Received: from jamesog by starbug.netinertia.co.uk with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1G4Mxj-000BS3-RD for freebsd-stable@freebsd.org; Sat, 22 Jul 2006 20:16:31 +0100 Date: Sat, 22 Jul 2006 20:16:31 +0100 From: James O'Gorman To: freebsd-stable@freebsd.org Message-ID: <20060722191631.GB122@netinertia.co.uk> References: <44C26D28.4000304@inoc.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <44C26D28.4000304@inoc.net> User-Agent: Mutt/1.5.11 Sender: James O'Gorman Subject: Re: Sun X86 servers X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Jul 2006 19:13:36 -0000 On Sat, Jul 22, 2006 at 02:23:36PM -0400, Robert Blayzor wrote: > I'd like to know if anyone is using the Sun X86 servers with 6.x. If > so, how is it preforming? I'm looking at possibly using them in a > diskless environment (and a couple possibly with disks) I've read in > the past that the disk controllers were not supported yet, I'm not sure > if that's changed (or changing). What about network controllers? > > Please contact me off-list (unless others are interested as well). Actually I'd be quite interested to know how they perform as well. I've been contemplating the new Ultra 20 workstation to try and learn Solaris on (but be able to run FreeBSD as well). James From owner-freebsd-stable@FreeBSD.ORG Sat Jul 22 21:22:37 2006 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 91F5016A4DA for ; Sat, 22 Jul 2006 21:22:37 +0000 (UTC) (envelope-from freebsd-stable@m.gmane.org) Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id A428243D53 for ; Sat, 22 Jul 2006 21:22:30 +0000 (GMT) (envelope-from freebsd-stable@m.gmane.org) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1G4OvX-0005Un-6W for freebsd-stable@freebsd.org; Sat, 22 Jul 2006 23:22:23 +0200 Received: from cmung1666.cmu.carnet.hr ([193.198.134.142]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 22 Jul 2006 23:22:23 +0200 Received: from ivoras by cmung1666.cmu.carnet.hr with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 22 Jul 2006 23:22:23 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-stable@freebsd.org From: Ivan Voras Date: Sat, 22 Jul 2006 23:22:14 +0200 Lines: 19 Message-ID: References: <44C22BB6.8010104@copyleft.no> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: cmung1666.cmu.carnet.hr User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en In-Reply-To: <44C22BB6.8010104@copyleft.no> Sender: news Subject: Re: Slow RAID1 with gmirror X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Jul 2006 21:22:37 -0000 Hr. Daniel Mikkelsen wrote: > But reading from the RAID1 runs at half the normal rates, while I > expected to get double rates. Some possible things to check are: - What did you use for bs= argument to dd? You should use sizes of 64KB or more (for example, a common size is 1MB) - Did you use dd on a raw mirror device or on a file system built on the device? Try both :) The difference you're seeing might be because Linux buffers raw device I/O and FreeBSD doesn't. - If you're using it on the filesystem you could try increasing vfs.read_max sysctl variable - Try using stripe size of 64K or 128KB with gmirror ("-s" argument) and bs=X (of dd) with twice that size In any case, please post results you get from experiments such as these (also from Linux) to this list. From owner-freebsd-stable@FreeBSD.ORG Sat Jul 22 23:11:50 2006 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9ED7916A4DD for ; Sat, 22 Jul 2006 23:11:50 +0000 (UTC) (envelope-from peterjeremy@optushome.com.au) Received: from mail20.syd.optusnet.com.au (mail20.syd.optusnet.com.au [211.29.132.201]) by mx1.FreeBSD.org (Postfix) with ESMTP id D17E343D62 for ; Sat, 22 Jul 2006 23:11:49 +0000 (GMT) (envelope-from peterjeremy@optushome.com.au) Received: from turion.vk2pj.dyndns.org (c220-239-19-236.belrs4.nsw.optusnet.com.au [220.239.19.236]) by mail20.syd.optusnet.com.au (8.12.11/8.12.11) with ESMTP id k6MNBlOu009571 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Sun, 23 Jul 2006 09:11:48 +1000 Received: from turion.vk2pj.dyndns.org (localhost.vk2pj.dyndns.org [127.0.0.1]) by turion.vk2pj.dyndns.org (8.13.6/8.13.6) with ESMTP id k6MNBliQ013964; Sun, 23 Jul 2006 09:11:47 +1000 (EST) (envelope-from peter@turion.vk2pj.dyndns.org) Received: (from peter@localhost) by turion.vk2pj.dyndns.org (8.13.6/8.13.6/Submit) id k6MNBlY3013963; Sun, 23 Jul 2006 09:11:47 +1000 (EST) (envelope-from peter) Date: Sun, 23 Jul 2006 09:11:47 +1000 From: Peter Jeremy To: Nikolas Britton Message-ID: <20060722231147.GH728@turion.vk2pj.dyndns.org> References: Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="9s922KAXlWjPfK/Q" Content-Disposition: inline In-Reply-To: X-PGP-Key: http://members.optusnet.com.au/peterjeremy/pubkey.asc User-Agent: Mutt/1.5.11 Cc: FreeBSD Stable List Subject: Re: Xen dom0 support? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Jul 2006 23:11:50 -0000 --9s922KAXlWjPfK/Q Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, 2006-Jul-22 06:56:44 -0500, Nikolas Britton wrote: >Does FreeBSD support Xen 3 dom0 yet??? It looks like work is in progress. See http://www.fsmware.com/ >What's the current status of domU support? See http://wiki.xensource.com/xenwiki/OSCompatibility --=20 Peter Jeremy --9s922KAXlWjPfK/Q Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.4 (FreeBSD) iD4DBQFEwrCz/opHv/APuIcRAtdOAJictTfWmytJmjRTxUv+1mglbpuRAKCYsi5A aKjHAo5QCPmnEsOy3uAEvg== =6aht -----END PGP SIGNATURE----- --9s922KAXlWjPfK/Q--