From owner-freebsd-hackers@FreeBSD.ORG Sun Feb 19 00:03:43 2012 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx2.freebsd.org (mx2.freebsd.org [IPv6:2001:4f8:fff6::35]) by hub.freebsd.org (Postfix) with ESMTP id 40D09106566C for ; Sun, 19 Feb 2012 00:03:43 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from 172-17-197-151.globalsuite.net (hub.freebsd.org [IPv6:2001:4f8:fff6::36]) by mx2.freebsd.org (Postfix) with ESMTP id A5341155CD4; Sun, 19 Feb 2012 00:03:42 +0000 (UTC) Message-ID: <4F403C5E.4000104@FreeBSD.org> Date: Sat, 18 Feb 2012 16:03:42 -0800 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (X11; FreeBSD i386; rv:10.0.2) Gecko/20120218 Thunderbird/10.0.2 MIME-Version: 1.0 To: perryh@pluto.rain.com References: <4F3E8225.9030501@FreeBSD.org> <4F3E8C26.3080900@FreeBSD.org> <4F3EA5F2.9070804@gmail.com> <4F3EAE5F.6070903@gmail.com> <20120217.220802.988.2@DOMY-PC> <4F3EDEBC.7040703@gmail.com> <4F3EFB70.5000102@FreeBSD.org> <4f3ff151.FznGzC6RC0a5qBKx%perryh@pluto.rain.com> In-Reply-To: <4f3ff151.FznGzC6RC0a5qBKx%perryh@pluto.rain.com> X-Enigmail-Version: 1.3.5 OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: rank1seeker@gmail.com, sendtomatt@gmail.com, hackers@freebsd.org Subject: Re: 8 to 9: Kernel modularization -- did it change? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Feb 2012 00:03:43 -0000 On 02/18/2012 10:43, perryh@pluto.rain.com wrote: > Doug Barton wrote: > >> loading modules through loader.conf is >> veeeeeerrrrryyyyyy sssssllllloooooowwwwww ... > > Is it noticeably slower to load (say) a 6MB kernel + 2MB of > modules than to load an 8MB kernel? I don't know, that wasn't the problem I was trying to solve. If your question is, "6 + 2-in-loader-conf" then I imagine that it would be about the same speed, maybe a little slower due to extra file open-read-close cycles. If it's "6 + 2-in-kld_list" then I imagine it would be quite a bit faster than an 8 M kernel, but I look forward to the results of your testing. :) Doug -- It's always a long day; 86400 doesn't fit into a short. Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ From owner-freebsd-hackers@FreeBSD.ORG Sun Feb 19 03:42:49 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 21097106566B; Sun, 19 Feb 2012 03:42:49 +0000 (UTC) (envelope-from mavbsd@gmail.com) Received: from mail-wi0-f182.google.com (mail-wi0-f182.google.com [209.85.212.182]) by mx1.freebsd.org (Postfix) with ESMTP id 839C68FC23; Sun, 19 Feb 2012 03:42:48 +0000 (UTC) Received: by wibhn14 with SMTP id hn14so3596521wib.13 for ; Sat, 18 Feb 2012 19:42:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=KCvprXBcf8T22f4yb3FMicX2y5uFeV/N6FAYET98ByI=; b=vHtfa3jltjEVEQLPdaqsXoFcSuV8pYcUwElYAHFjVUyZs2nQDqxKBXgCAG6ODOZ9dC TqpFMc6UXH7fPZR6xR6hlMkzqs7wPNn6V951b2mJoIIrUbkRZyfpA77jMGHtDHKb4vfw DRVR+FX8wRNeZBm6QOce+v5wO29VXvjIlg4cs= Received: by 10.181.12.106 with SMTP id ep10mr7303403wid.8.1329622967513; Sat, 18 Feb 2012 19:42:47 -0800 (PST) Received: from mavbook.mavhome.dp.ua (95-109-204-113.dialup.umc.net.ua. [95.109.204.113]) by mx.google.com with ESMTPS id ec3sm7109707wib.1.2012.02.18.19.42.42 (version=SSLv3 cipher=OTHER); Sat, 18 Feb 2012 19:42:46 -0800 (PST) Sender: Alexander Motin Message-ID: <4F406FA2.4040502@FreeBSD.org> Date: Sun, 19 Feb 2012 05:42:26 +0200 From: Alexander Motin User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:9.0) Gecko/20120116 Thunderbird/9.0 MIME-Version: 1.0 To: Andriy Gapon References: <4F3FF690.5050600@FreeBSD.org> <4F3FFF33.2050700@FreeBSD.org> <4F400CC1.8030504@FreeBSD.org> In-Reply-To: <4F400CC1.8030504@FreeBSD.org> Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@FreeBSD.org Subject: Re: callouts precision X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Feb 2012 03:42:49 -0000 On 18.02.2012 22:40, Andriy Gapon wrote: > on 18/02/2012 21:42 Alexander Motin said the following: >> On 18.02.2012 21:05, Andriy Gapon wrote: >>> Just want to double-check myself. >>> It seems that currently, thanks to event timers, we mostly should be able to >>> schedule a hardware timer to fire at almost arbitrary moment with very fine >>> precision. >>> OTOH, our callout subsystem still seems to be completely tick oriented in the >>> sense that all timeouts are specified and kept in ticks. >>> As a result, it's impossible to use e.g. nanosleep(2) with a precision better >>> than HZ. >>> >>> How deeply ticks are ingrained into callout(9)? Are they used only as a measure >>> of time? Or are there any dependencies on them being integers, like for >>> indexing, etc? >>> In other words, how hard it would be to replace ticks with e.g. bintime as an >>> internal representation of time in callout(9) [leaving interfaces alone for the >>> start]? Is it easier to retrofit that code or to replace it with something new? >> >> Pending callouts are now stored in large array of unsorted lists, where last >> bits of callout time is the array index. It is quite effective for insert/delete >> operation. It is ineffective for getting next event time needed for new event >> timers, but it is rare operation. Using arbitrary time values in that case is >> very problematic. It would require complete internal redesign. >> > > I see. Thank you for the insight! > > One possible hack that I can think of is to use "pseudo-ticks" in the callout > implementation instead of real ticks. E.g. such a pseudo-tick could be set > equal to 1 microsecond instead of 1/hz (it could be tunable). Then, of course, > instead of driving the callouts via hardclock/softclock, they would have to be > driven directly from event timers. And they would have to use current > microseconds uptime instead of ticks, obviously. This would also require a > revision of types used to store timeout values. Current 'int' would not be > adequate anymore, it seems. I don't think it will work. With so high frequency it will make callouts distribution over the array almost random. While insert / remove operations will still be cheap, search for the next event will be 1000 times more expensive. Unless you propose increase array size 1000 times, it will not be better then just using single unsorted link, > It looks like Timer_Wheel_T from ACE has some useful enhancements in this direction. > > BTW, it seems that with int ticks and HZ of 1000, ticks would overflow from > INT_MAX to INT_MIN in ~24 days. I can imagine that some code might get confused > by such an overflow. But that's a different topic. Probably you are right. I've seen few dangerous comparisons in ULE code. -- Alexander Motin From owner-freebsd-hackers@FreeBSD.ORG Sun Feb 19 09:20:40 2012 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 768FA1065672; Sun, 19 Feb 2012 09:20:40 +0000 (UTC) (envelope-from perryh@pluto.rain.com) Received: from agora.rdrop.com (unknown [IPv6:2607:f678:1010::34]) by mx1.freebsd.org (Postfix) with ESMTP id 2DE428FC08; Sun, 19 Feb 2012 09:20:40 +0000 (UTC) Received: from agora.rdrop.com (66@localhost [127.0.0.1]) by agora.rdrop.com (8.13.1/8.12.7) with ESMTP id q1J9KdKZ055593 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sun, 19 Feb 2012 01:20:39 -0800 (PST) (envelope-from perryh@pluto.rain.com) Received: (from uucp@localhost) by agora.rdrop.com (8.13.1/8.14.2/Submit) with UUCP id q1J9KdnM055592; Sun, 19 Feb 2012 01:20:39 -0800 (PST) (envelope-from perryh@pluto.rain.com) Received: from fbsd81 ([192.168.200.81]) by pluto.rain.com (4.1/SMI-4.1-pluto-M2060407) id AA08578; Sun, 19 Feb 12 01:15:00 PST Date: Sun, 19 Feb 2012 08:13:48 -0800 From: perryh@pluto.rain.com To: dougb@freebsd.org Message-Id: <4f411fbc.5xpQwqtOGVzi8G4D%perryh@pluto.rain.com> References: <4F3E8225.9030501@FreeBSD.org> <4F3E8C26.3080900@FreeBSD.org> <4F3EA5F2.9070804@gmail.com> <4F3EAE5F.6070903@gmail.com> <20120217.220802.988.2@DOMY-PC> <4F3EDEBC.7040703@gmail.com> <4F3EFB70.5000102@FreeBSD.org> <4f3ff151.FznGzC6RC0a5qBKx%perryh@pluto.rain.com> <4F403C5E.4000104@FreeBSD.org> In-Reply-To: <4F403C5E.4000104@FreeBSD.org> User-Agent: nail 11.25 7/29/05 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: sendtomatt@gmail.com, rank1seeker@gmail.com, hackers@freebsd.org Subject: Re: 8 to 9: Kernel modularization -- did it change? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Feb 2012 09:20:40 -0000 Doug Barton wrote: > On 02/18/2012 10:43, perryh@pluto.rain.com wrote: > > Doug Barton wrote: > >> loading modules through loader.conf is > >> veeeeeerrrrryyyyyy sssssllllloooooowwwwww ... > > > > Is it noticeably slower to load (say) a 6MB kernel + 2MB of > > modules than to load an 8MB kernel? > > I don't know, that wasn't the problem I was trying to solve. Given the context of the thread, this: > >> loading modules through loader.conf is > >> veeeeeerrrrryyyyyy sssssllllloooooowwwwww ... seemed to be an objection to modularizing the kernel. Hence my question: is it in fact noticeably slower to load a minimal kernel plus needed modules than to load a kernel that had all those modules built in? Based on the below, I think we agree that the answer is likely to be no, even if all the modules in question were loaded via loader.conf (and the modular version might well load noticeably _faster_ if a sizeable fraction of the modules could be loaded via kld_list instead). > If your question is, "6 + 2-in-loader-conf" then I imagine that > it would be about the same speed, maybe a little slower due to > extra file open-read-close cycles. If it's "6 + 2-in-kld_list" > then I imagine it would be quite a bit faster than an 8 M kernel > ... That is what I would expect, also. > but I look forward to the results of your testing. :) You're asking me to test _your_ assertion? I had expected that you would already have the data to back it up. From owner-freebsd-hackers@FreeBSD.ORG Sun Feb 19 09:23:47 2012 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx2.freebsd.org (mx2.freebsd.org [IPv6:2001:4f8:fff6::35]) by hub.freebsd.org (Postfix) with ESMTP id B98D3106566C for ; Sun, 19 Feb 2012 09:23:47 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from 172-17-197-151.globalsuite.net (hub.freebsd.org [IPv6:2001:4f8:fff6::36]) by mx2.freebsd.org (Postfix) with ESMTP id 6AFCD1502A6; Sun, 19 Feb 2012 09:23:46 +0000 (UTC) Message-ID: <4F40BFA1.4090107@FreeBSD.org> Date: Sun, 19 Feb 2012 01:23:45 -0800 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (X11; FreeBSD i386; rv:10.0.2) Gecko/20120218 Thunderbird/10.0.2 MIME-Version: 1.0 To: perryh@pluto.rain.com References: <4F3E8225.9030501@FreeBSD.org> <4F3E8C26.3080900@FreeBSD.org> <4F3EA5F2.9070804@gmail.com> <4F3EAE5F.6070903@gmail.com> <20120217.220802.988.2@DOMY-PC> <4F3EDEBC.7040703@gmail.com> <4F3EFB70.5000102@FreeBSD.org> <4f3ff151.FznGzC6RC0a5qBKx%perryh@pluto.rain.com> <4F403C5E.4000104@FreeBSD.org> <4f411fbc.5xpQwqtOGVzi8G4D%perryh@pluto.rain.com> In-Reply-To: <4f411fbc.5xpQwqtOGVzi8G4D%perryh@pluto.rain.com> X-Enigmail-Version: 1.3.5 OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: sendtomatt@gmail.com, rank1seeker@gmail.com, hackers@freebsd.org Subject: Re: 8 to 9: Kernel modularization -- did it change? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Feb 2012 09:23:47 -0000 On 02/19/2012 08:13, perryh@pluto.rain.com wrote: > Given the context of the thread, this: > >>>> > >> loading modules through loader.conf is >>>> > >> veeeeeerrrrryyyyyy sssssllllloooooowwwwww ... > > seemed to be an objection to modularizing the kernel. The only way you could come to that conclusion is if you didn't carefully read my post. -- It's always a long day; 86400 doesn't fit into a short. Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ From owner-freebsd-hackers@FreeBSD.ORG Sun Feb 19 09:46:59 2012 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4638F1065670 for ; Sun, 19 Feb 2012 09:46:59 +0000 (UTC) (envelope-from rank1seeker@gmail.com) Received: from mail-we0-f182.google.com (mail-we0-f182.google.com [74.125.82.182]) by mx1.freebsd.org (Postfix) with ESMTP id CEA058FC13 for ; Sun, 19 Feb 2012 09:46:58 +0000 (UTC) Received: by werm13 with SMTP id m13so4231597wer.13 for ; Sun, 19 Feb 2012 01:46:57 -0800 (PST) Received-SPF: pass (google.com: domain of rank1seeker@gmail.com designates 10.180.101.228 as permitted sender) client-ip=10.180.101.228; Authentication-Results: mr.google.com; spf=pass (google.com: domain of rank1seeker@gmail.com designates 10.180.101.228 as permitted sender) smtp.mail=rank1seeker@gmail.com; dkim=pass header.i=rank1seeker@gmail.com Received: from mr.google.com ([10.180.101.228]) by 10.180.101.228 with SMTP id fj4mr10099642wib.4.1329644817891 (num_hops = 1); Sun, 19 Feb 2012 01:46:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:from:to:subject:date:content-type :content-transfer-encoding:x-mailer; bh=bnFVMwTl5I3ILaSfKq1vq22jn/7ULOzYwV0c/lcCIr8=; b=C7rWDyx9INolKz2m55YrXMGviG+dmt/FnrEM7az6BX/cjF9Yt0aCrAmW8s1eGbaB39 G6bwoESZ5tfu+e+WnyLdXnQyCH4cCx+OYBVc7YjehbyYpxYOBBKxCQODAWnR+/YqRZVt MWz87bjFctlVK/WJhEgXZvPdkAa9uzQCCy3oI= Received: by 10.180.101.228 with SMTP id fj4mr8533222wib.4.1329644817859; Sun, 19 Feb 2012 01:46:57 -0800 (PST) Received: from DOMYPC ([82.193.208.173]) by mx.google.com with ESMTPS id m8sm21956979wia.11.2012.02.19.01.46.24 (version=SSLv3 cipher=OTHER); Sun, 19 Feb 2012 01:46:56 -0800 (PST) Message-ID: <20120219.094652.789.4@DOMY-PC> From: rank1seeker@gmail.com To: hackers@freebsd.org Date: Sun, 19 Feb 2012 10:46:52 +0100 Content-Type: text/plain; charset="Windows-1250" Content-Transfer-Encoding: quoted-printable X-Mailer: POP Peeper (3.8.1.0) Cc: Subject: 9.0 dialog and it's STDIN X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Feb 2012 09:46:59 -0000 In target port, this presents a dialog:=0D=0A/usr/bin/make = config=0D=0A=0D=0AInstead via keyboard, I want to send key sequence to = dialog(piped to STDIN of above = cmd):=0D=0ADown=0D=0ASpace=0D=0ADown=0D=0ASpace=0D=0AEnter=0D=0A=0D=0A--=0D=0A#!/bin/sh=0D=0A=0D=0Aecho = 'CODE_HERE' | /usr/bin/make config=0D=0A--=0D=0A=0D=0A=0D=0ADomagoj = Smol=E8i=E6=0D=0A From owner-freebsd-hackers@FreeBSD.ORG Sun Feb 19 21:47:17 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EF00C1065673; Sun, 19 Feb 2012 21:47:16 +0000 (UTC) (envelope-from vermaden@interia.pl) Received: from smtpo.poczta.interia.pl (smtpo.poczta.interia.pl [217.74.65.207]) by mx1.freebsd.org (Postfix) with ESMTP id 5ACC68FC0C; Sun, 19 Feb 2012 21:47:16 +0000 (UTC) Date: Sun, 19 Feb 2012 22:47:13 +0100 From: vermaden To: Hans Petter Selasky X-Mailer: interia.pl/pf09 In-Reply-To: <201202181409.08859.hselasky@c2i.net> References: <4F3EE186.4020801@gmail.com> <201202181409.08859.hselasky@c2i.net> X-Originating-IP: 85.89.187.172 Message-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=interia.pl; s=biztos; t=1329688033; bh=9/MNWYs7Ft6MAEHGeE9EwQnSnOeFjfXZh4BfC/b/IK8=; h=Date:From:Subject:To:Cc:X-Mailer:In-Reply-To:References: X-Originating-IP:Message-Id:MIME-Version:Content-Type: Content-Transfer-Encoding; b=I0ywxDhUIu/61lMN/0q9rgCmTaecSOhwOq2jcjXDYLF53uRlkNVnn5LfKKDCP4UU0 bCz19PNQYijxEeKxwhvOLPVvuff2eUtlidndqCqVS6uscFxPOKsCdUxs8gBQQ+9Ig8 QizOzo4n76GD3bMSh5zdaZ8JA+VIfMqhYu4W1DVE= X-Mailman-Approved-At: Sun, 19 Feb 2012 21:51:42 +0000 Cc: matt , gleb.kurtsou@gmail.com, freebsd-stable@freebsd.org, uffe@uffe.org, freebsd-hackers@freebsd.org, joe.culler@gmail.com, freebsd-current@freebsd.org, lars.engels@0x20.net Subject: Re: devd based AUTOMOUNTER X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Feb 2012 21:47:17 -0000 Hi, sorry for late response, but I currently have quite a lot 'weekend activities' that are definitely not near a computer ;) written by Gleb Kurtsou ...=20 >> __state_lock() { >> while [ -f ${STATE}.lock ]; do sleep 0.5; done >> :> ${STATE}.lock >> } > > Why not keep it stateless, unmounting by hand would kill integrity. The state file is needed for automatic umount of fuse-based mounts, the device that script would be triggered will be /dev/da0 for example while the 'virtual' device that was actually used for the mount was /dev/fuse0, that is why I need to track what is mounted and how. These functions are mostly to keep that 'state file' integral, to prevent two various event writing at the file simultanously, which would probable killed the information integrity. Unmounting the device does not kill integrity at all, I also thought about that, You may plug the device, do whatever You want, event change the filesystem there and mount it again, but when You umount it and unplug it, then the script will umount that device (yes pointless here at this moment) and remove the entry from state file. > Usage of `file` is a big security concern. Can You explain why? > I think geom config and list of mounted file systems should be > sufficient for collecting information at runtime. Although it may not be > that easy for disks without partitioning. geom config? I also make use of the list of mounted filesystems, but the problem with fuse-based devices remain as I stated earlier. > I'm using a python script for mounting/unmounting removable disks, > but having similar tool written in sh would be great. >=20 > https://github.com/glk/mmount Thanks for sharing, maybe I will find some ideas there ;) written by Uffe Jakobsen ... > Nice, Thanks. > Instead of requiring modification to /etc/devd.conf why not just > put a "plugin" conf-file in /etc/devd/ - well even better put in > /usr/local/etc/devd/ - that way your devd.conf modifications are > not lost upon patching/updating base os. Great advice, I will do that in the next 'release' ;) > There is an existing port called "automounter" by Dominic Fandrey > which is much similar to your work. Yes but its amd based. > His "automounter" also works with disk labels > (as found in /dev/ufs/ and /dev/msdosfs/ etc) The labels are only 'an addition' to appearing device nodes at /dev, Yes it would be nice to see that /dev/msdosfs/BACKUP is mounted instead of /dev/da0s1, but I will have to make a lot of additional check to see if that new label is part of that or other device etc. > You should consider make a port out of your work. I probably will try to do that, but I think it stil needs polish ;) written by Lars Engels ... > And please don't hardcode polish locales in mount_msdosfs :-) I already changed that, I also plan to create simple config file, it was just not 'the most important thing' that I was dealing with at that time, its easy to move options into variables, its harder to make script work the way it should ;) But thanks for suggestion, good point. written by Joe Culler ... > Thanks for working on it. It works great for me, thanks! Thanks, good to know ;) > I have a question, could you export a fusefs-exfat or > fusefs-ntfs share directory over NFS? I can't get it work. > If you have a solution, please let me know, thanks. I will try to do that tomorrow ane let You know. Regards, vermaden --- From owner-freebsd-hackers@FreeBSD.ORG Sun Feb 19 23:25:52 2012 Return-Path: Delivered-To: hackers@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E157B1065670 for ; Sun, 19 Feb 2012 23:25:50 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 10FC88FC22 for ; Sun, 19 Feb 2012 23:25:49 +0000 (UTC) Received: from porto.starpoint.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id BAA02043; Mon, 20 Feb 2012 01:07:47 +0200 (EET) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1RzFr9-000Fn9-CA; Mon, 20 Feb 2012 01:07:47 +0200 Message-ID: <4F4180A9.3070400@FreeBSD.org> Date: Mon, 20 Feb 2012 01:07:21 +0200 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:10.0.1) Gecko/20120215 Thunderbird/10.0.1 MIME-Version: 1.0 To: Alex Dupre X-Enigmail-Version: 1.3.5 Content-Type: text/plain; charset=X-VIET-VPS Content-Transfer-Encoding: 7bit Cc: hackers@FreeBSD.org Subject: outdated/dangerous code in databases/mysql50-server X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Feb 2012 23:25:53 -0000 Alex, sql/mysqld.cc has the following code: inline void setup_fpu() { #if defined(__FreeBSD__) && defined(HAVE_IEEEFP_H) /* We can't handle floating point exceptions with threads, so disable this on freebsd Don't fall for overflow, underflow,divide-by-zero or loss of precision */ #if defined(__i386__) fpsetmask(~(FP_X_INV | FP_X_DNML | FP_X_OFL | FP_X_UFL | FP_X_DZ | FP_X_IMP)); #else fpsetmask(~(FP_X_INV | FP_X_OFL | FP_X_UFL | FP_X_DZ | FP_X_IMP)); #endif /* __i386__ */ #endif /* __FreeBSD__ && HAVE_IEEEFP_H */ First of all the code seems to be rather ancient. Probably as a result of this it uses a rather potentially dangerous fpsetmask() calls. Second, I am not sure to what problem [with FreeBSD threads] the comment refers. I am quite sure that there is no such problem in the supported releases. Third, the default state of mxcsr (FPU/SSE control and status register) on FreeBSD is to have all those exceptions disabled. Last and the most important, the !__i386__ case omits FP_X_DNML, which means that on e.g. amd64 the denormalized floating point numbers can cause an exception. And that is not really expected by any code. Also, it is not guaranteed that this call (as a part mysql client initialization) would be made in some special dedicated mysql thread. In 5.1 and 5.5 this piece code looks a bit smarter: inline void setup_fpu() { #if defined(__FreeBSD__) && defined(HAVE_IEEEFP_H) && !defined(HAVE_FEDISABLEEXCEPT) /* We can't handle floating point exceptions with threads, so disable this on freebsd Don't fall for overflow, underflow,divide-by-zero or loss of precision. fpsetmask() is deprecated in favor of fedisableexcept() in C99. */ #if defined(FP_X_DNML) fpsetmask(~(FP_X_INV | FP_X_DNML | FP_X_OFL | FP_X_UFL | FP_X_DZ | FP_X_IMP)); #else fpsetmask(~(FP_X_INV | FP_X_OFL | FP_X_UFL | FP_X_DZ | FP_X_IMP)); #endif /* FP_X_DNML */ #endif /* __FreeBSD__ && HAVE_IEEEFP_H && !HAVE_FEDISABLEEXCEPT */ #ifdef HAVE_FEDISABLEEXCEPT fedisableexcept(FE_ALL_EXCEPT); #endif I guess that this version should be OK, because FreeBSD has fedisableexcept for a long time (I think) and so the safer call should be used on all archs. On mysql "client side" the setup_fpu call is made from init_server_components, which in turn is called from init_embedded_server, so the problem is relevant for embedded mysql case. It is relevant for mysql server too, of course. -- Andriy Gapon From owner-freebsd-hackers@FreeBSD.ORG Mon Feb 20 00:14:17 2012 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C24671065670 for ; Mon, 20 Feb 2012 00:14:17 +0000 (UTC) (envelope-from oliver.pntr@gmail.com) Received: from mail-yw0-f54.google.com (mail-yw0-f54.google.com [209.85.213.54]) by mx1.freebsd.org (Postfix) with ESMTP id 7C0678FC1C for ; Mon, 20 Feb 2012 00:14:17 +0000 (UTC) Received: by yhfs35 with SMTP id s35so2764486yhf.13 for ; Sun, 19 Feb 2012 16:14:17 -0800 (PST) Received-SPF: pass (google.com: domain of oliver.pntr@gmail.com designates 10.236.145.230 as permitted sender) client-ip=10.236.145.230; Authentication-Results: mr.google.com; spf=pass (google.com: domain of oliver.pntr@gmail.com designates 10.236.145.230 as permitted sender) smtp.mail=oliver.pntr@gmail.com; dkim=pass header.i=oliver.pntr@gmail.com Received: from mr.google.com ([10.236.145.230]) by 10.236.145.230 with SMTP id p66mr25292119yhj.27.1329696857060 (num_hops = 1); Sun, 19 Feb 2012 16:14:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:cc:content-type; bh=pkGWH2/2YDRlchL9G1yKHK3r5/U93qDPam2P/m0ezqs=; b=IGouaKNX9cZxR5m/VuNxh/YL4gUoVE0M6h2fQN0fxZQi3NwhuQMGk0zcuh/crt17il LC1aNyCRPo/b9oQmHHxdXczPHC2swiNM4Yz42mf/x7/5v/o2wcAZA5OzmXdDrwOUW3V5 wBEjExFZWsKNpnfnDBwdedjvK+cirGITfocrg= MIME-Version: 1.0 Received: by 10.236.145.230 with SMTP id p66mr19477084yhj.27.1329696857007; Sun, 19 Feb 2012 16:14:17 -0800 (PST) Received: by 10.236.22.138 with HTTP; Sun, 19 Feb 2012 16:14:16 -0800 (PST) Date: Mon, 20 Feb 2012 01:14:16 +0100 Message-ID: From: Oliver Pinter To: hackers@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Cc: Poul-Henning Kamp Subject: geom_aes X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Feb 2012 00:14:17 -0000 Hi all! What is geom_aes (sys/geom/geom_aes.*) (wherein differs form geli, besides useses fewer geom layer and has a compiled in key), and who can I find something from this geom module/layer? How can I use this geom layer? Only added option geom_aes to kernel config? From owner-freebsd-hackers@FreeBSD.ORG Mon Feb 20 10:07:37 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 706FD1065670; Mon, 20 Feb 2012 10:07:37 +0000 (UTC) (envelope-from fidaj@ukr.net) Received: from fsm1.ukr.net (fsm1.ukr.net [195.214.192.120]) by mx1.freebsd.org (Postfix) with ESMTP id 213A08FC12; Mon, 20 Feb 2012 10:07:36 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=ukr.net; s=fsm; h=Content-Transfer-Encoding:Content-Type:Mime-Version:References:In-Reply-To:Message-ID:Subject:Cc:To:From:Date; bh=6R2YKB35g3YxXyYRdDWy2kbxBVDpk9bEjzPKqKi3OWE=; b=XdF4tilzSQrlIjeNPxTakwmn1ssLmdakMRR8AqUf753YyWFci5M5dfUGX0UNiKOKxCI7UktVuW7TvL0hLGgxls3KQlDtcBFW/h55AJGm9hMlMu1AvQAKH1ZmdfNub+rHuwNgYIaS6N273Hp4bYLKCkCDSNggTL9jSVeyvLNcPAQ=; Received: from [178.137.138.140] (helo=nonamehost.) by fsm1.ukr.net with esmtpsa ID 1RzPro-000Hgk-Pa ; Mon, 20 Feb 2012 11:49:08 +0200 Date: Mon, 20 Feb 2012 11:49:07 +0200 From: Ivan Klymenko To: vermaden Message-ID: <20120220114907.59c76417@nonamehost.> In-Reply-To: References: <4F3EE186.4020801@gmail.com> <201202181409.08859.hselasky@c2i.net> X-Mailer: Claws Mail 3.8.0 (GTK+ 2.24.6; amd64-portbld-freebsd10.0) Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-hackers@freebsd.org, freebsd-current@freebsd.org, freebsd-stable@freebsd.org Subject: Re: devd based AUTOMOUNTER X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Feb 2012 10:07:37 -0000 =D0=92 Mon, 20 Feb 2012 09:43:59 +0100 vermaden =D0=BF=D0=B8=D1=88=D0=B5=D1=82: > Hi, >=20 > new version with new features (and BUGs ;p) >=20 > Added check if ntfsfix from sysutils/ntfsprogs is available, if Yes > then try to fix the NTFS filesystem before mouting it. >=20 > Added GPL3 License ... just joking ;) ... added FreeBSD License to > the file. >=20 > Added 'noatime' as a default mount option when possible. >=20 > Added TIMEOUT so when an 'orphan' STATE file lock remains, it will be > deleted after a TIMEOUT. >=20 > Added /usr/local/etc/devd/automount.devd file instead of messing with > the base system config at /etc/devd.conf. >=20 > Added config file to be used from /usr/local/etc/automount.conf file, > possible options are (these are defaults): MNTPREFIX=3D"/media" > LOG=3D"/var/log/automount.log" > STATE=3D"/var/run/automount.state" > ENCODING=3D"en_US.ISO8859-1" > CODEPAGE=3D"cp437" > DATEFMT=3D"%Y-%m-%d %H:%M:%S" > USERUMOUNT=3D"NO" >=20 > Mine config currently has only these: > ENCODING=3D"pl_PL.ISO8859-2" > CODEPAGE=3D"cp852" > USERUMOUNT=3D"YES" >=20 > The USERMOUNT otions if set to YES (default to NO) will 'chmod > +s /sbin/umount', so You can click the ^ button on the devices list > in NAUTILUS. >=20 > These newly mounted devices appear on NAUTILUS sidebar (only > with /media prefix). >=20 > But THUNAR and PCMANFM does not do that, You know any other FMs that > display mounted thumb drives/devices? >=20 > EXAMPLE: http://i.imgur.com/qdKdl.png >=20 > First BUG: (not fixed yet, but workaround already is working) >=20 > TEST/BUG/CASE: > Plug in FAT32 and NTFS drives at the same time, when FAT32 device > will be detected first, it will get mounted and the NTFS drive will > be mounted TWICE, so I added __check_already_mounted function to > check if it is not already mounted. Thank you so much! Could you update, please first post in the forum? http://forums.freebsd.org/showthread.php?t=3D29895 Thanks! From owner-freebsd-hackers@FreeBSD.ORG Mon Feb 20 08:44:02 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E9EBF1065676; Mon, 20 Feb 2012 08:44:02 +0000 (UTC) (envelope-from vermaden@interia.pl) Received: from smtpo.poczta.interia.pl (smtpo.poczta.interia.pl [217.74.65.207]) by mx1.freebsd.org (Postfix) with ESMTP id 206DA8FC14; Mon, 20 Feb 2012 08:44:01 +0000 (UTC) Date: Mon, 20 Feb 2012 09:43:59 +0100 From: vermaden To: freebsd-hackers@freebsd.org X-Mailer: interia.pl/pf09 In-Reply-To: References: <4F3EE186.4020801@gmail.com> <201202181409.08859.hselasky@c2i.net> X-Originating-IP: 194.0.181.128 Message-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=interia.pl; s=biztos; t=1329727440; bh=Y2RQtiVWb64sEd6ziEaKIGP2Phh1yUxw3chpfQYoeLM=; h=Date:From:Subject:To:Cc:X-Mailer:In-Reply-To:References: X-Originating-IP:Message-Id:MIME-Version:Content-Type: Content-Transfer-Encoding; b=HlMzE1bAx8j0q5mto4JZKu8gr2EtQJQJp2xx194Fr7JTHDxlwLWWbhDCJnKeJ6hbl /7iZc2gyvnbAe+IkYM/f0bod2rcbExM18ADAeDRlxeLmwIk60qz2ssdjD9DtsQ10G0 Tesr+04xfusR2W4jzLqGNqgWz/2IhlwHhbEOv2lI= X-Mailman-Approved-At: Mon, 20 Feb 2012 12:23:26 +0000 Cc: matt , gleb.kurtsou@gmail.com, freebsd-stable@freebsd.org, uffe@uffe.org, joe.culler@gmail.com, Hans Petter Selasky , freebsd-current@freebsd.org, lars.engels@0x20.net Subject: Re: devd based AUTOMOUNTER X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Feb 2012 08:44:03 -0000 Hi, new version with new features (and BUGs ;p) Added check if ntfsfix from sysutils/ntfsprogs is available, if Yes then try to fix the NTFS filesystem before mouting it. Added GPL3 License ... just joking ;) ... added FreeBSD License to the file= . Added 'noatime' as a default mount option when possible. Added TIMEOUT so when an 'orphan' STATE file lock remains, it will be delet= ed after a TIMEOUT. Added /usr/local/etc/devd/automount.devd file instead of messing with the b= ase system config at /etc/devd.conf. Added config file to be used from /usr/local/etc/automount.conf file, possi= ble options are (these are defaults): MNTPREFIX=3D"/media" LOG=3D"/var/log/automount.log" STATE=3D"/var/run/automount.state" ENCODING=3D"en_US.ISO8859-1" CODEPAGE=3D"cp437" DATEFMT=3D"%Y-%m-%d %H:%M:%S" USERUMOUNT=3D"NO" Mine config currently has only these: ENCODING=3D"pl_PL.ISO8859-2" CODEPAGE=3D"cp852" USERUMOUNT=3D"YES" The USERMOUNT otions if set to YES (default to NO) will 'chmod +s /sbin/umo= unt', so You can click the ^ button on the devices list in NAUTILUS. These newly mounted devices appear on NAUTILUS sidebar (only with /media pr= efix). But THUNAR and PCMANFM does not do that, You know any other FMs that displa= y mounted thumb drives/devices? EXAMPLE: http://i.imgur.com/qdKdl.png First BUG: (not fixed yet, but workaround already is working) TEST/BUG/CASE: Plug in FAT32 and NTFS drives at the same time, when FAT32 device will be d= etected first, it will get mounted and the NTFS drive will be mounted TWICE= , so I added __check_already_mounted function to check if it is not already= mounted. Below are current script and config files. /usr/local/etc/devd/automount.devd ---------------------------------------------------------------------------= ---- notify 0 { match "system" "DEVFS"; match "type" "CREATE"; match "cdev" "(da|mmcsd)[0-9]+"; action "/usr/local/sbin/automount.sh $cdev attach"; }; notify 0 { match "system" "DEVFS"; match "type" "DESTROY"; match "cdev" "(da|mmcsd)[0-9]+"; action "/usr/local/sbin/automount.sh $cdev detach"; }; ---------------------------------------------------------------------------= ---- /usr/local/etc/automout.conf (can be empty) ---------------------------------------------------------------------------= ---- MNTPREFIX=3D"/media" LOG=3D"/var/log/automount.log" STATE=3D"/var/run/automount.state" ENCODING=3D"en_US.ISO8859-1" CODEPAGE=3D"cp437" DATEFMT=3D"%Y-%m-%d %H:%M:%S" USERUMOUNT=3D"NO" ---------------------------------------------------------------------------= ---- /usr/local/sbin/automount.sh ---------------------------------------------------------------------------= ---- #! /bin/sh # Copyright (c) 2011 Slawomir Wojciech Wojtczak (vermaden) # All rights reserved. # # Redistribution and use in source and binary forms, with or without # modification, are permitted provided that the following conditions are me= t: # 1. Redistributions of source code must retain the above copyright # notice, this list of conditions and the following disclaimer. # 2. Redistributions in binary form must reproduce the above copyright # notice, this list of conditions and the following disclaimer in the # documentation and/or other materials provided with the distribution. # # THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS 'AS IS' AND ANY # EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED # WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE # DISCLAIMED. IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE FOR A= NY # DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGE= S # (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVIC= ES; # LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED A= ND # ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TOR= T # (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF # THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. PATH=3D/bin:/sbin:/usr/bin:/usr/sbin:/usr/local/bin:/usr/local/sbin [ -f /usr/local/etc/automount.conf ] && . /usr/local/etc/automount.conf : ${MNTPREFIX=3D"/media"} : ${LOG=3D"/var/log/automount.log"} : ${STATE=3D"/var/run/automount.state"} : ${ENCODING=3D"en_US.ISO8859-1"} # /* US/Canada */ : ${CODEPAGE=3D"cp437"} # /* US/Canada */ : ${DATEFMT=3D"%Y-%m-%d %H:%M:%S"} # /* 2012-02-20 07:49:09 */ : ${USERUMOUNT=3D"NO"} # /* when YES add suid bit to umoun= t(8) */ [ "${USERUMOUNT}" =3D "YES" ] && chmod u+s /sbin/umount # /* WHEEL group me= mber */ __create_mount_point() { # /* 1=3DDEV */ MNT=3D"${MNTPREFIX}/$( basename ${1} )" mkdir -p ${MNT} chown 1000 ${MNT} } __check_already_mounted() { # /* 1=3DMNT */ mount | grep " ${1} " 1> /dev/null 2> /dev/null && { __log "${I}:already mounted (ntfs)" continue } } __state_lock() { TIMEOUT=3D60 COUNT=3D0 while [ -f ${STATE}.lock ] do sleep 0.5 [ ${COUNT} -gt ${TIMEOUT} ] && break COUNT=3D$(( ${COUNT} + 1 )) done :> ${STATE}.lock } __state_unlock() { rm ${STATE}.lock } __state_add() { # /* 1=3DDEV 2=3DPROVIDER 3=3DMNT */ __state_lock grep -E "${3}" ${STATE} 1> /dev/null 2> /dev/null && { __log "${1}:duplicated '${STATE}'" return 1 } echo "${1} ${2} ${3}" >> ${STATE} __state_unlock } __state_remove() { # /* 1=3DMNT 2=3DSTATE 3=3DLINE */ BSMNT=3D$( echo ${1} | sed 's/\//\\\//g' ) # /* backslash the slashes ;) = */ sed -i '' "/${BSMNT}\$/d" ${2} } __log() { # /* @=3DMESSAGE */ echo $( date +"${DATEFMT}" ) ${@} >> ${LOG} } case ${2} in (attach) for I in /dev/${1}* do case $( file -b -L -s ${I} | sed -E 's/label:\ \".*\"//g' ) in (*NTFS*) dd < ${I} count=3D1 2> /dev/null | strings | head -1 | grep -q "N= TFS" && { __create_mount_point ${I} which ntfsfix 1> /dev/null 2> /dev/null && { ntfsfix ${I} # /* sysutils/ntfsprogs */ } __check_already_mounted ${MNT} which ntfs-3g 1> /dev/null 2> /dev/null && { ntfs-3g -o noatime ${I} ${MNT} # /* sysutils/fusefs-ntfs */ } || { mount_ntfs -o noatime ${I} ${MNT} } __log "${I}:mount (ntfs)" } ;; (*FAT*) dd < ${I} count=3D1 2> /dev/null | strings | grep -q "FAT32" && { __create_mount_point ${I} fsck_msdosfs -y ${I} __check_already_mounted ${MNT} mount_msdosfs -o large -L ${ENCODING} -D ${CODEPAGE} ${I} ${M= NT} __log "${I}:mount (fat)" } ;; (*ext2*) __create_mount_point ${I} fsck.ext2 -y ${I} mount -t ext2fs -o noatime ${I} ${MNT} __check_already_mounted ${MNT} __log "${I}:mount (ext2)" ;; (*ext3*) __create_mount_point ${I} fsck.ext3 -y ${I} __check_already_mounted ${MNT} mount -t ext2fs -o noatime ${I} ${MNT} __log "${I}:mount (ext3)" ;; (*ext4*) __create_mount_point ${I} fsck.ext4 -y ${I} __check_already_mounted ${MNT} ext4fuse ${I} ${MNT} # /* sysutils/fusefs-ext4fuse */ __log "${I}:mount (ext4)" ;; (*Unix\ Fast\ File*) __create_mount_point ${I} fsck_ufs -y ${I} __check_already_mounted ${MNT} mount -o noatime ${I} ${MNT} __log "${I}:mount (ufs)" ;; (*) case $( dd < ${I} count=3D1 2> /dev/null | strings | head -1 ) in (EXFAT) __create_mount_point ${I} __check_already_mounted ${MNT} mount.exfat -o noatime ${I} ${MNT} # /* sysutils/fusefs-exfat= */ __log "${I}:mount (ufs)" ;; (*) continue ;; esac ;; esac __state_add ${I} $( mount | grep -m 1 " ${MNT} " | awk '{printf $1}' = ) ${MNT} done ;; (detach) MOUNT=3D$( mount ) __state_lock grep ${1} ${STATE} \ | while read DEV PROVIDER MNT do TARGET=3D$( echo "${MOUNT}" | grep -E "^${PROVIDER} " | awk '{pri= nt $3}' ) [ -z ${TARGET} ] && { __state_remove ${MNT} ${STATE} ${LINE} continue } umount -f ${TARGET} & unset TARGET __state_remove ${MNT} ${STATE} ${LINE} __log "${DEV}:umount" done __state_unlock __log "/dev/${1}:detach" find ${MNTPREFIX} -type d -empty -delete ;; esac ---------------------------------------------------------------------------= ---- From owner-freebsd-hackers@FreeBSD.ORG Mon Feb 20 13:27:19 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0CAD0106566B; Mon, 20 Feb 2012 13:27:19 +0000 (UTC) (envelope-from vermaden@interia.pl) Received: from smtpo.poczta.interia.pl (smtpo.poczta.interia.pl [217.74.65.207]) by mx1.freebsd.org (Postfix) with ESMTP id B8B308FC17; Mon, 20 Feb 2012 13:27:18 +0000 (UTC) Date: Mon, 20 Feb 2012 14:27:17 +0100 From: vermaden To: freebsd-hackers@freebsd.org X-Mailer: interia.pl/pf09 In-Reply-To: References: <4F3EE186.4020801@gmail.com> <201202181409.08859.hselasky@c2i.net> X-Originating-IP: 194.0.181.128 Message-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=interia.pl; s=biztos; t=1329744437; bh=eGPVCiTg2TrYYocs0g18zqWUvpG1TOTXPQw7BC0c598=; h=Date:From:Subject:To:Cc:X-Mailer:In-Reply-To:References: X-Originating-IP:Message-Id:MIME-Version:Content-Type: Content-Transfer-Encoding; b=k+vRDkwAFtNmVAwhkRuKIUi1g1yI6Zf4we4zLt71I+NvqFBjXUMiaZXyW73QxyqeY oFLj8mv30VMQIJtkD45DADDpCUXzOEaZQ1IwtAQ2S4Iivp8WdTYv29BI5hHj3qjhvN OwHOwDk2VUSMpC705elVU8Xkgit8gi6kJkXn023Q= X-Mailman-Approved-At: Mon, 20 Feb 2012 13:39:36 +0000 Cc: freebsd-current@freebsd.org, freebsd-stable@freebsd.org Subject: Re: devd based AUTOMOUNTER X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Feb 2012 13:27:19 -0000 written by ${ME} ... > First BUG: (not fixed yet, but workaround already is working) >=20 > TEST/BUG/CASE: > Plug in FAT32 and NTFS drives at the same time, when FAT32 device > will be detected first, it will get mounted and the NTFS drive will be > mounted TWICE, so I added > __check_already_mounted function > to check if it is not already mounted. This BUG is fixed, I was in wrong assumption, that the script would be only executed for /dev/da0 but it was executed for every device/partition node that appeared separately, like /dev/da0, /dev/da0s1, /dev/da0s2 etc. Currently there is no knows bugs, but the prepared earlier 'workaround functions' remain just in case. As I written before its now available here: https://github.com/vermaden/automount Regards, vermaden --- From owner-freebsd-hackers@FreeBSD.ORG Mon Feb 20 15:12:50 2012 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EAA371065673; Mon, 20 Feb 2012 15:12:50 +0000 (UTC) (envelope-from tevans.uk@googlemail.com) Received: from mail-vw0-f54.google.com (mail-vw0-f54.google.com [209.85.212.54]) by mx1.freebsd.org (Postfix) with ESMTP id 8EB298FC08; Mon, 20 Feb 2012 15:12:50 +0000 (UTC) Received: by vbbfa15 with SMTP id fa15so5199425vbb.13 for ; Mon, 20 Feb 2012 07:12:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=WnIYKptjHmQzoEjBKDIVbjrqyNgyRayoTDJRCF/cMgc=; b=Ff1sv250t4oTQysut6uIav/3QkpUQrftzh2AX3gi+Tfb9ZXST8f2aGTVCZDTsdieeC p+N5p2/BHPNN4r8wOPAfVlLzVnfnOkNqsXaNRT06OPuhPZ/UbnB/k+Oh5NstNOH/Mlnk GdIUHcuwGfnjrz2cdxO8b6XdaWZ8IFU7X/yos= MIME-Version: 1.0 Received: by 10.52.26.197 with SMTP id n5mr8039007vdg.81.1329749049803; Mon, 20 Feb 2012 06:44:09 -0800 (PST) Received: by 10.52.91.210 with HTTP; Mon, 20 Feb 2012 06:44:09 -0800 (PST) In-Reply-To: <4F3EFB70.5000102@FreeBSD.org> References: <4F3E8225.9030501@FreeBSD.org> <4F3E8C26.3080900@FreeBSD.org> <4F3EA5F2.9070804@gmail.com> <4F3EAE5F.6070903@gmail.com> <20120217.220802.988.2@DOMY-PC> <4F3EDEBC.7040703@gmail.com> <4F3EFB70.5000102@FreeBSD.org> Date: Mon, 20 Feb 2012 14:44:09 +0000 Message-ID: From: Tom Evans To: Doug Barton Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: hackers@freebsd.org Subject: Re: 8 to 9: Kernel modularization -- did it change? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Feb 2012 15:12:51 -0000 On Sat, Feb 18, 2012 at 1:14 AM, Doug Barton wrote: > Because loading modules through loader.conf is > veeeeeerrrrryyyyyy sssssllllloooooowwwwww I added an rc.d script called > kld that will load the specified modules after disks are mounted. This > is at least an order of magnitude faster. Come off it, loading modules from loader.conf takes seconds off disk, out of the 2+ minute total boot up. There may be benefit on slow media, but in the general case I see no benefit (which might explain why not many people are bothering to change their working configs to save <2s on bootup). wrt to sound drivers no longer being built as modules, I wonder why this change has been made. I don't recall a mass of people complaining that they couldn't load drivers, or adding 'sound_enable=3D"YES"' to loader.conf being particularly onerous. As has been pointed out, this change makes it hard to load/unload the snd_hda code, which is useful to wire the outputs to the appropriate pins. I suppose if we have to "boot, test, change, reboot, test change, reboot=E2=80=A6" ad infinitum to do this in future, saving 2s on bo= ot would be *super* useful. Whatever happened to POLA? This change surprised me, wasn't mentioned in /usr/src/UPDATING, and I still don't understand what benefits this change is supposed to bring. Cheers Tom From owner-freebsd-hackers@FreeBSD.ORG Mon Feb 20 15:26:03 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 49E5F106564A; Mon, 20 Feb 2012 15:26:03 +0000 (UTC) (envelope-from olivier@gid0.org) Received: from mail-lpp01m010-f54.google.com (mail-lpp01m010-f54.google.com [209.85.215.54]) by mx1.freebsd.org (Postfix) with ESMTP id 990CB8FC14; Mon, 20 Feb 2012 15:26:02 +0000 (UTC) Received: by lagz14 with SMTP id z14so9486000lag.13 for ; Mon, 20 Feb 2012 07:26:01 -0800 (PST) MIME-Version: 1.0 Received: by 10.152.128.163 with SMTP id np3mr13310290lab.51.1329751561184; Mon, 20 Feb 2012 07:26:01 -0800 (PST) Received: by 10.152.29.234 with HTTP; Mon, 20 Feb 2012 07:26:00 -0800 (PST) In-Reply-To: References: <20120123215503.GA64787@geosci> Date: Mon, 20 Feb 2012 16:26:00 +0100 Message-ID: From: Olivier Smedts To: =?ISO-8859-2?Q?Edward_Tomasz_Napiera=B3a?= Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQkCRXygHH2t/mL3LKh753htae6wEZrHGFuKAL2XNXMTtIFAgNMkh4qSabRLV81GJx/eDQDD Cc: freebsd-hackers@freebsd.org Subject: Re: Speeding up the loader(8). X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Feb 2012 15:26:03 -0000 2012/2/6 Olivier Smedts : > 2012/1/23 Edward Tomasz Napiera=C5=82a : >> Some time ago I've spent some time on trying to speed up loading >> modules by the loader(8). =C2=A0Result can be found at: >> >> http://people.freebsd.org/~trasz/fast-loader-3.diff > > I use it successfully on my FreeBSD 9.0-STABLE amd64 with ZFS on root. > It sped up the loading time significantly, now booting on ZFS feels > nearly as speedy as on UFS. Some debug output on the loader screen since I use this patch : BIOS drive D: is disk1 BIOS drive E: is disk2 [bd_realstrategy: reading 0] [bd_realstrategy: reading 0] [bd_realstrategy:= read ing 0] BIOS 638 kB/3600049kB available Is it normal ? --=20 Olivier Smedts=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0 _ =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ASCII ri= bbon campaign ( ) e-mail: olivier@gid0.org=C2=A0 =C2=A0 =C2=A0 =C2=A0 - against HTML email & = vCards=C2=A0 X www: http://www.gid0.org=C2=A0 =C2=A0 - against proprietary attachments / \ =C2=A0 "Il y a seulement 10 sortes de gens dans le monde : =C2=A0 ceux qui comprennent le binaire, =C2=A0 et ceux qui ne le comprennent pas." From owner-freebsd-hackers@FreeBSD.ORG Mon Feb 20 14:14:34 2012 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 017E5106566C; Mon, 20 Feb 2012 14:14:34 +0000 (UTC) (envelope-from alexander@leidinger.net) Received: from mail.ebusiness-leidinger.de (mail.ebusiness-leidinger.de [217.11.53.44]) by mx1.freebsd.org (Postfix) with ESMTP id 8969C8FC14; Mon, 20 Feb 2012 14:14:33 +0000 (UTC) Received: from outgoing.leidinger.net (p5796D15A.dip.t-dialin.net [87.150.209.90]) by mail.ebusiness-leidinger.de (Postfix) with ESMTPSA id 862B084400E; Mon, 20 Feb 2012 15:14:17 +0100 (CET) Received: from webmail.leidinger.net (webmail.Leidinger.net [IPv6:fd73:10c7:2053:1::3:102]) by outgoing.leidinger.net (Postfix) with ESMTPS id C03A95551; Mon, 20 Feb 2012 15:14:14 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=leidinger.net; s=outgoing-alex; t=1329747254; bh=a0+2sPg20/SeNPfv0ATvMYN7AoZWZ1BnTBGOaXDFK4Y=; h=Date:Message-ID:From:To:Cc:Subject:References:In-Reply-To: Content-Type:MIME-Version; b=hsMzyQxvDkmve0Oq5Zp0cxT4eSu5YYi3uMysfv/1oZQRQirQ+o0t934ny3UbkUcto JqQNKiu0MG033M1XACeTduMJlYaDwY9aAxoR3ZvUf9lhoymYqXU59OrFDoD1haZKZK awpn8f2MCjXsBInpRXDP7lMx4YtY0oYqeB9ycwNiOIDoqvlvRL/LTO7TqRig7j2Cvd SXaEKmdV5v8scurQsmiqMKw8NNRWrTEpTRU06MQTol9f/s1M72JwoQ6MDLp1vjTj1Y xElcidCdUsUbC6XPhDOyhPvmoRoc762qr+OPC1QcmU8hc6SrOCOrprgH16FO2I+TNI dboQp/osh7lhA== Received: (from www@localhost) by webmail.leidinger.net (8.14.5/8.14.4/Submit) id q1KEECkm051165; Mon, 20 Feb 2012 15:14:12 +0100 (CET) (envelope-from Alexander@Leidinger.net) X-Authentication-Warning: webmail.leidinger.net: www set sender to Alexander@Leidinger.net using -f Received: from 85.94.224.19 ([85.94.224.19]) by webmail.leidinger.net (Horde Framework) with HTTP; Mon, 20 Feb 2012 15:14:12 +0100 Date: Mon, 20 Feb 2012 15:14:09 +0100 Message-ID: <20120220151409.Horde.NYT-HpjmRSRPQlUxo1tMYtA@webmail.leidinger.net> From: Alexander Leidinger To: perryh@pluto.rain.com References: <4F3E8225.9030501@FreeBSD.org> <4F3E8C26.3080900@FreeBSD.org> <4F3EA5F2.9070804@gmail.com> <4F3EAE5F.6070903@gmail.com> <20120217.220802.988.2@DOMY-PC> <4F3EDEBC.7040703@gmail.com> <4F3EFB70.5000102@FreeBSD.org> <4f3ff151.FznGzC6RC0a5qBKx%perryh@pluto.rain.com> <4F403C5E.4000104@FreeBSD.org> <4f411fbc.5xpQwqtOGVzi8G4D%perryh@pluto.rain.com> In-Reply-To: <4f411fbc.5xpQwqtOGVzi8G4D%perryh@pluto.rain.com> User-Agent: Internet Messaging Program (IMP) H4 (5.0.18) Content-Type: text/plain; charset=ISO-8859-1; format=flowed; DelSp=Yes MIME-Version: 1.0 Content-Disposition: inline X-EBL-MailScanner-Information: Please contact the ISP for more information X-EBL-MailScanner-ID: 862B084400E.A088E X-EBL-MailScanner: Found to be clean X-EBL-MailScanner-SpamCheck: not spam, spamhaus-ZEN, SpamAssassin (not cached, score=-0.325, required 6, autolearn=disabled, AWL -0.81, DKIM_SIGNED 0.10, DKIM_VALID -0.10, DKIM_VALID_AU -0.10, J_CHICKENPOX_74 0.60, T_RP_MATCHES_RCVD -0.01) X-EBL-MailScanner-From: alexander@leidinger.net X-EBL-MailScanner-Watermark: 1330352059.86295@wKZsiY7uu9BWNqU3x+eDgA X-EBL-Spam-Status: No X-Mailman-Approved-At: Mon, 20 Feb 2012 15:40:28 +0000 Cc: sendtomatt@gmail.com, rank1seeker@gmail.com, dougb@freebsd.org, hackers@freebsd.org Subject: Re: 8 to 9: Kernel modularization -- did it change? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Feb 2012 14:14:34 -0000 Quoting perryh@pluto.rain.com (from Sun, 19 Feb 2012 08:13:48 -0800): > Doug Barton wrote: >> On 02/18/2012 10:43, perryh@pluto.rain.com wrote: >> > Doug Barton wrote: >> >> loading modules through loader.conf is >> >> veeeeeerrrrryyyyyy sssssllllloooooowwwwww ... >> > >> > Is it noticeably slower to load (say) a 6MB kernel + 2MB of >> > modules than to load an 8MB kernel? >> >> I don't know, that wasn't the problem I was trying to solve. > > Given the context of the thread, this: > >> >> loading modules through loader.conf is >> >> veeeeeerrrrryyyyyy sssssllllloooooowwwwww ... > > seemed to be an objection to modularizing the kernel. Hence my Looks more like an opinion. In fact, I work on a modularized kernel config which I want to commit to -current at some point (for those which do not care how long it takes to boot the system). The goal of my work is to produce something like GENERIC+more, just as much as possible loaded as kld's (the "+more" part is the result of a poll I did on stable@, it contains only stuff which can not be loaded as a kld, and I provide a loader.conf which disables the parts which would cause a major change in behavior). Currently I'm doing some compile testing, I should be able to provide something for review soon (on current@). Bye, Alexander. -- WORK: The blessed respite from screaming kids and soap operas for which you actually get paid. http://www.Leidinger.net Alexander @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137 From owner-freebsd-hackers@FreeBSD.ORG Mon Feb 20 14:37:32 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 97B2C106566B for ; Mon, 20 Feb 2012 14:37:32 +0000 (UTC) (envelope-from freebsd-hackers@herveybayaustralia.com.au) Received: from mail.unitedinsong.com.au (mail.unitedinsong.com.au [150.101.178.33]) by mx1.freebsd.org (Postfix) with ESMTP id 139AF8FC16 for ; Mon, 20 Feb 2012 14:37:31 +0000 (UTC) Received: from mail.unitedinsong.com.au (bell.herveybayaustralia.com.au [192.168.0.40]) by mail.unitedinsong.com.au (Postfix) with ESMTP id 3A89E5C28 for ; Tue, 21 Feb 2012 00:50:57 +1000 (EST) Received: from laptop1.herveybayaustralia.com.au (laptop1.herveybayaustralia.com.au [192.168.0.177]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mail.unitedinsong.com.au (Postfix) with ESMTPSA id C25AB5C22 for ; Tue, 21 Feb 2012 00:50:56 +1000 (EST) Message-ID: <4F425987.6010506@herveybayaustralia.com.au> Date: Tue, 21 Feb 2012 00:32:39 +1000 From: Da Rock <9Phackers@herveybayaustralia.com.au> User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:7.0.1) Gecko/20111109 Thunderbird/7.0.1 MIME-Version: 1.0 To: freebsd-hackers@freebsd.org References: <4F3A9266.9050905@freebsd.org> <20120214170533.GA35819@DataIX.net> <4F3A9907.8000903@gamozo.org> In-Reply-To: <4F3A9907.8000903@gamozo.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Mon, 20 Feb 2012 15:40:50 +0000 Subject: Re: OS support for fault tolerance X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: freebsd-hackers@freebsd.org List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Feb 2012 14:37:32 -0000 On 02/15/12 03:25, Brandon Falk wrote: > On 2/14/2012 12:05 PM, Jason Hellenthal wrote: >> On Tue, Feb 14, 2012 at 08:57:10AM -0800, Julian Elischer wrote: >>> On 2/14/12 6:23 AM, Maninya M wrote: >>>> For multicore desktop computers, suppose one of the cores fails, the >>>> FreeBSD OS crashes. My question is about how I can make the OS tolerate >>>> this hardware fault. >>>> The strategy is to checkpoint the state of each core at specific intervals >>>> of time in main memory. Once a core fails, its previous state is retrieved >>>> from the main memory, and the processes that were running on it are >>>> rescheduled on the remaining cores. >>>> >>>> I read that the OS tolerates faults in large servers. I need to make it do >>>> this for a Desktop OS. I assume I would have to change the scheduler >>>> program. I am using FreeBSD 9.0 on an Intel core i5 quad core machine. >>>> How do I go about doing this? What exactly do I need to save for the >>>> "state" of the core? What else do I need to know? >>>> I have absolutely no experience with kernel programming or with FreeBSD. >>>> Any pointers to good sources about modifying the source-code of FreeBSD >>>> would be greatly appreciated. >>> This question has always intrigued me, because I'm always amazed >>> that people actually try. >>> From my viewpoint, There's really not much you can do if the core >>> that is currently holding the scheduler lock fails. >>> And what do you mean by 'fails"? do you run constant diagnostics? >>> how do you tell when it is failed? It'd be hard to detect that 'multiply' >>> has suddenly started giving bad results now and then. >>> >>> if it just "stops" then you might be able to have a watchdog that >>> notices, but what do you do when it was half way through rearranging >>> a list of items? First, you have to find out that it held >>> the lock for the module and then you have to find out what it had >>> done and clean up the mess. >>> >>> This requires rewriting many many parts of the kernel to remove >>> 'transient inconsistent states". and even then, what do you do if it >>> was half way through manipulating some hardware.. >>> >>> and when you've figured that all out, how do you cope with the >>> mess it made because it was dying? >>> Say for example it had started calculating bad memory offsets >>> before writing out some stuff and written data out over random memory? >>> >>> but I'm interested in any answers people may have >>> >> How about core redundancy ? effectively this would reduce the amount of >> available cores in half in you spread a process to run on two cores at >> the same time but with an option to adjust this per process etc... I >> don't see it as unfeasable. >> > The overhead for all of the error checking and redundancy makes this idea pretty > impractical. You'd have to have 2 cores to do the exact same thing, then some > 'master' core that makes sure they're doing the right stuff, and if you really > want to think about it... what if the core monitoring the cores fails... there's > a threshold of when redundancy gets pointless. Make no mistake here, I'm not really up with the guts of what this would require (the dog may not hunt at all). Consider me as the little boy throwing rocks at a hornets nest :) That out of the way, how about this scenario: why can't the master be dynamic amongst the cores? 1 core be the master of any 2 cores (not itself). Another thought (probably more scifi then anything else) is about using the cores as individuals which work as a team and fire a weak team member that is failing. I have absolutely no idea how to accomplish this, but I thought it might fire a few neurons in someone who does... :) > > Perhaps I'm missing out on something, but you can't check the checker (without > infinite redundancy). > > Honestly, if you're worried about a core failing, please take your server > cluster out of the 1000 deg C forge. > > -Brandon From owner-freebsd-hackers@FreeBSD.ORG Mon Feb 20 15:44:11 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 51FE9106564A for ; Mon, 20 Feb 2012 15:44:11 +0000 (UTC) (envelope-from papowell@astart.com) Received: from astart2.astart.com (99-111-96-109.uvs.sndgca.sbcglobal.net [99.111.96.109]) by mx1.freebsd.org (Postfix) with ESMTP id F2B7D8FC12 for ; Mon, 20 Feb 2012 15:44:10 +0000 (UTC) Received: from laptop_81.private (localhost [127.0.0.1]) by astart2.astart.com (8.14.4/8.14.4) with ESMTP id q1KFNrEI081436 for ; Mon, 20 Feb 2012 07:23:53 -0800 (PST) (envelope-from papowell@astart.com) Message-ID: <4F426588.7090104@astart.com> Date: Mon, 20 Feb 2012 07:23:52 -0800 From: Patrick Powell Organization: Astart Technologies User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.15) Gecko/20110312 Thunderbird/3.1.9 MIME-Version: 1.0 To: freebsd-hackers@freebsd.org References: <4F3E8225.9030501@FreeBSD.org> <4F3E8C26.3080900@FreeBSD.org> <4F3EA5F2.9070804@gmail.com> <4F3EAE5F.6070903@gmail.com> <20120217.220802.988.2@DOMY-PC> <4F3EDEBC.7040703@gmail.com> <4F3EFB70.5000102@FreeBSD.org> In-Reply-To: <4F3EFB70.5000102@FreeBSD.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: 8 to 9: Kernel modularization -- did it change? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: papowell@astart.com List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Feb 2012 15:44:12 -0000 On 02/17/12 17:14, Doug Barton wrote: > On 02/17/2012 15:11, matt wrote: >> We have a modular kernel. It makes best-practices-sense to keep the >> kernel true to what's required to boot and initialize the hardware >> required to come up multiuser. I am actually against having sound in >> there at all. > I think the question is not, "What should be in the kernel?" but rather > "What should be on by default?" *How* those things are provided is a > different question. > > One could argue that an intelligent installer combined with a more > modular kernel would be the right answer. > >> However, as a compromise, if it must be in there, then put it in >> loader.conf and not the kernel. > I keep hoping that if I repeat this enough times that people will get > the word. :) Because loading modules through loader.conf is > veeeeeerrrrryyyyyy sssssllllloooooowwwwww I added an rc.d script called > kld that will load the specified modules after disks are mounted. This > is at least an order of magnitude faster. Look for kld_list in > rc.conf(5) if you want the details, but the short version is that you > just do something like, kld_list="umass coretemp ichwd linux nvidia". > This is in all the -stable branches (including 7), is already in 9.0, > and will be in 8.3. > > Obviously you have to have everything in kernel and/or loader.conf > that's necessary to get your local disks available, and the system to > the point where it can start running rc. But everything else can go in > kld_list. > > > hth, > > Doug > Oooh! Ahhh! Just what I was looking for. l will extract this from 9 and put it on my system. Much better than having to edit the loader.conf and/or having to create a rc.local script. -- Patrick Powell Astart Technologies papowell@astart.com 1530 Jamacha Road, Suite X, Network and System El Cajon, CA 92019 Consulting 858-874-6543 Web Site: www.astart.com From owner-freebsd-hackers@FreeBSD.ORG Mon Feb 20 15:48:06 2012 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 13F2E106564A for ; Mon, 20 Feb 2012 15:48:06 +0000 (UTC) (envelope-from olivier@gid0.org) Received: from mail-lpp01m010-f54.google.com (mail-lpp01m010-f54.google.com [209.85.215.54]) by mx1.freebsd.org (Postfix) with ESMTP id 843378FC14 for ; Mon, 20 Feb 2012 15:48:05 +0000 (UTC) Received: by lagz14 with SMTP id z14so9520758lag.13 for ; Mon, 20 Feb 2012 07:48:04 -0800 (PST) Received-SPF: pass (google.com: domain of olivier@gid0.org designates 10.112.101.198 as permitted sender) client-ip=10.112.101.198; Authentication-Results: mr.google.com; spf=pass (google.com: domain of olivier@gid0.org designates 10.112.101.198 as permitted sender) smtp.mail=olivier@gid0.org Received: from mr.google.com ([10.112.101.198]) by 10.112.101.198 with SMTP id fi6mr8232474lbb.18.1329752884303 (num_hops = 1); Mon, 20 Feb 2012 07:48:04 -0800 (PST) MIME-Version: 1.0 Received: by 10.112.101.198 with SMTP id fi6mr6813974lbb.18.1329751277009; Mon, 20 Feb 2012 07:21:17 -0800 (PST) Received: by 10.152.29.234 with HTTP; Mon, 20 Feb 2012 07:21:16 -0800 (PST) In-Reply-To: <4f3ff151.FznGzC6RC0a5qBKx%perryh@pluto.rain.com> References: <4F3E8225.9030501@FreeBSD.org> <4F3E8C26.3080900@FreeBSD.org> <4F3EA5F2.9070804@gmail.com> <4F3EAE5F.6070903@gmail.com> <20120217.220802.988.2@DOMY-PC> <4F3EDEBC.7040703@gmail.com> <4F3EFB70.5000102@FreeBSD.org> <4f3ff151.FznGzC6RC0a5qBKx%perryh@pluto.rain.com> Date: Mon, 20 Feb 2012 16:21:16 +0100 Message-ID: From: Olivier Smedts To: perryh@pluto.rain.com Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQlYS91wdMBrW7FvEkrN6nBpjaz3BBBFjwRDwJw1nT0ouZZ1VDfkZF2oQnmoGW5uWOlruPAt Cc: rank1seeker@gmail.com, sendtomatt@gmail.com, dougb@freebsd.org, =?ISO-8859-2?Q?Edward_Tomasz_Napiera=B3a?= , hackers@freebsd.org Subject: Re: 8 to 9: Kernel modularization -- did it change? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Feb 2012 15:48:06 -0000 2012/2/18 : > Doug Barton wrote: > >> loading modules through loader.conf is >> veeeeeerrrrryyyyyy sssssllllloooooowwwwww ... > > Is it noticeably slower to load (say) a 6MB kernel + 2MB of > modules than to load an 8MB kernel? =A0If so, any idea why? It has been *really* slower to load many files (modules) since I switched to ZFS on root. I had to build a monolithic kernel to save 10-15s of loading time. Now I use trasz@'s (CC'ed) patch to speed up the loader, and it seems maybe as fast as with UFS. I don't know if the patch speeds up things with UFS, but with ZFS it made a big difference. --=20 Olivier Smedts=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=A0 _ =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 ASCII ribbon campaign ( ) e-mail: olivier@gid0.org=A0 =A0 =A0 =A0 - against HTML email & vCards=A0 X www: http://www.gid0.org=A0 =A0 - against proprietary attachments / \ =A0 "Il y a seulement 10 sortes de gens dans le monde : =A0 ceux qui comprennent le binaire, =A0 et ceux qui ne le comprennent pas." From owner-freebsd-hackers@FreeBSD.ORG Mon Feb 20 16:38:30 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 49CB91065672 for ; Mon, 20 Feb 2012 16:38:30 +0000 (UTC) (envelope-from fjwcash@gmail.com) Received: from mail-vx0-f182.google.com (mail-vx0-f182.google.com [209.85.220.182]) by mx1.freebsd.org (Postfix) with ESMTP id EDFB58FC1B for ; Mon, 20 Feb 2012 16:38:29 +0000 (UTC) Received: by vcmm1 with SMTP id m1so5317400vcm.13 for ; Mon, 20 Feb 2012 08:38:29 -0800 (PST) Received-SPF: pass (google.com: domain of fjwcash@gmail.com designates 10.52.76.165 as permitted sender) client-ip=10.52.76.165; Authentication-Results: mr.google.com; spf=pass (google.com: domain of fjwcash@gmail.com designates 10.52.76.165 as permitted sender) smtp.mail=fjwcash@gmail.com; dkim=pass header.i=fjwcash@gmail.com Received: from mr.google.com ([10.52.76.165]) by 10.52.76.165 with SMTP id l5mr4823285vdw.24.1329755909430 (num_hops = 1); Mon, 20 Feb 2012 08:38:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=GOIONmwfIpBn8+emc+dK2II/K6MfFe84UpcSR28CgJo=; b=DBrbsW7kMRi4qMUm2ZXiEB1OJHptKxCbqmcmeUtHdu/trtmzAEb2mQ7LFRbXlBjpsu vRAVNlcE8dOGFlEe4Qf7p5ohpvt58tvemYkPwerFyTwvvIGTGq0BKmPN7ubEHIj04sPF MbwCu+11+TmwArIpztXrU/bQzRm9CT9/har+g= MIME-Version: 1.0 Received: by 10.52.76.165 with SMTP id l5mr3901728vdw.24.1329755909364; Mon, 20 Feb 2012 08:38:29 -0800 (PST) Received: by 10.220.192.135 with HTTP; Mon, 20 Feb 2012 08:38:29 -0800 (PST) In-Reply-To: References: <4F3EE186.4020801@gmail.com> <201202181409.08859.hselasky@c2i.net> Date: Mon, 20 Feb 2012 08:38:29 -0800 Message-ID: From: Freddie Cash To: vermaden Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-hackers@freebsd.org Subject: Re: devd based AUTOMOUNTER X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Feb 2012 16:38:30 -0000 On Mon, Feb 20, 2012 at 12:43 AM, vermaden wrote: > new version with new features (and BUGs ;p) > > Added check if ntfsfix from sysutils/ntfsprogs is available, if Yes then > try to fix the NTFS filesystem before mouting it. > > Added GPL3 License ... just joking ;) ... added FreeBSD License to the fi= le. > > Added 'noatime' as a default mount option when possible. > > Added TIMEOUT so when an 'orphan' STATE file lock remains, it will be del= eted after a TIMEOUT. > > Added /usr/local/etc/devd/automount.devd file instead of messing with the= base system config at /etc/devd.conf. > > Added config file to be used from /usr/local/etc/automount.conf file, pos= sible options are (these are defaults): > =C2=A0MNTPREFIX=3D"/media" > =C2=A0LOG=3D"/var/log/automount.log" > =C2=A0STATE=3D"/var/run/automount.state" > =C2=A0ENCODING=3D"en_US.ISO8859-1" > =C2=A0CODEPAGE=3D"cp437" > =C2=A0DATEFMT=3D"%Y-%m-%d %H:%M:%S" > =C2=A0USERUMOUNT=3D"NO" > > Mine config currently has only these: > =C2=A0ENCODING=3D"pl_PL.ISO8859-2" > =C2=A0CODEPAGE=3D"cp852" > =C2=A0USERUMOUNT=3D"YES" > > The USERMOUNT otions if set to YES (default to NO) will 'chmod +s /sbin/u= mount', > so You can click the ^ button on the devices list in NAUTILUS. > > These newly mounted devices appear on NAUTILUS sidebar (only with /media = prefix). > > But THUNAR and PCMANFM does not do that, You know any other FMs that disp= lay mounted thumb drives/devices? Konqueror (KDE 3.x and 4.x) and Dolphin (KDE 4.x mainly, but I believe there's a KDE 3.x version) also show automatically mounted and removable media in the sidebar. Works nicely with HAL. Haven't tested your script yet, but am intrigued by it. Will see if I can test it sometime this week. Native solutions are so much nicer than ported ones. :) --=20 Freddie Cash fjwcash@gmail.com From owner-freebsd-hackers@FreeBSD.ORG Mon Feb 20 16:54:42 2012 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F12A1106566B for ; Mon, 20 Feb 2012 16:54:42 +0000 (UTC) (envelope-from alex-goncharov@comcast.net) Received: from qmta12.westchester.pa.mail.comcast.net (qmta12.westchester.pa.mail.comcast.net [76.96.59.227]) by mx1.freebsd.org (Postfix) with ESMTP id 97F9F8FC0C for ; Mon, 20 Feb 2012 16:54:42 +0000 (UTC) Received: from omta21.westchester.pa.mail.comcast.net ([76.96.62.72]) by qmta12.westchester.pa.mail.comcast.net with comcast id cE2o1i0021ZXKqc5CGuiol; Mon, 20 Feb 2012 16:54:42 +0000 Received: from hans3 ([66.30.197.229]) by omta21.westchester.pa.mail.comcast.net with comcast id cGui1i01z4xSlmi3hGuilB; Mon, 20 Feb 2012 16:54:42 +0000 Received: from algo by hans3 with local (Exim 4.77 (FreeBSD)) (envelope-from ) id 1RzWVd-000MHj-AD; Mon, 20 Feb 2012 11:54:41 -0500 From: Alex Goncharov To: Tom Evans In-reply-to: (message from Tom Evans on Mon, 20 Feb 2012 14:44:09 +0000) References: <4F3E8225.9030501@FreeBSD.org> <4F3E8C26.3080900@FreeBSD.org> <4F3EA5F2.9070804@gmail.com> <4F3EAE5F.6070903@gmail.com> <20120217.220802.988.2@DOMY-PC> <4F3EDEBC.7040703@gmail.com> <4F3EFB70.5000102@FreeBSD.org> Message-Id: Sender: Alex Goncharov Date: Mon, 20 Feb 2012 11:54:41 -0500 Cc: hackers@freebsd.org, dougb@freebsd.org Subject: Re: 8 to 9: Kernel modularization -- did it change? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Alex Goncharov List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Feb 2012 16:54:43 -0000 ,--- You/Tom (Mon, 20 Feb 2012 14:44:09 +0000) ----* | On Sat, Feb 18, 2012 at 1:14 AM, Doug Barton wrote: | > Because loading modules through loader.conf is | > veeeeeerrrrryyyyyy sssssllllloooooowwwwww I added an rc.d script called | > kld that will load the specified modules after disks are mounted. This | > is at least an order of magnitude faster. | Come off it, loading modules from loader.conf takes seconds off disk, | out of the 2+ minute total boot up. There may be benefit on slow | media, but in the general case I see no benefit (which might explain | why not many people are bothering to change their working configs to | save <2s on bootup). Seconded. As many have noticed, the "veeeeeerrrrryyyyyy sssssllllloooooowwwwww" and "order of magnitude faster" claim has not been supported by empirical evidence in this discussion. If instead of .002 sec the module loading takes .02, nobody cares. The fact that one can spread configuration and initialization parameters across several non-hierarchically-related entities (rc.conf, loader.conf, device.hints) somewhat arbitrarily, seems not right to me. Personally, I don't care about winning 10 seconds on a boot, but I do care a lot about the consistent maintenance and knowing what configuration piece has to go where. On none of my machines, I had a perception of slow FreeBSD bootup, with the (few) modules listed in loader.conf. -- Alex -- alex-goncharov@comcast.net -- From owner-freebsd-hackers@FreeBSD.ORG Mon Feb 20 17:25:10 2012 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 94E1F1065670; Mon, 20 Feb 2012 17:25:10 +0000 (UTC) (envelope-from m.e.sanliturk@gmail.com) Received: from mail-tul01m020-f182.google.com (mail-tul01m020-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id 461978FC17; Mon, 20 Feb 2012 17:25:10 +0000 (UTC) Received: by obcwo16 with SMTP id wo16so9619150obc.13 for ; Mon, 20 Feb 2012 09:25:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=5YnD6ICdAjjIArSbGTNFOeEJhLohb94X1/NYgdQ0Ai4=; b=p7uS2MYdE40EtHmuw2uJKfDw+DPlyIEJneWC0tRKl3PP6Q/kzLyRtbtc9l8hQazDPM nzAVW8d+l2FpkIk0s0cJML99JrivFit16h7a9TVSJtkSKliDU7CE5K+XMXDqczX6HLqc ocvtgSHir6BNV1Dmnvap0atXvVRDFtwwdknKw= MIME-Version: 1.0 Received: by 10.182.118.34 with SMTP id kj2mr11640683obb.37.1329757021005; Mon, 20 Feb 2012 08:57:01 -0800 (PST) Received: by 10.182.38.38 with HTTP; Mon, 20 Feb 2012 08:57:00 -0800 (PST) In-Reply-To: <20120220151409.Horde.NYT-HpjmRSRPQlUxo1tMYtA@webmail.leidinger.net> References: <4F3E8225.9030501@FreeBSD.org> <4F3E8C26.3080900@FreeBSD.org> <4F3EA5F2.9070804@gmail.com> <4F3EAE5F.6070903@gmail.com> <20120217.220802.988.2@DOMY-PC> <4F3EDEBC.7040703@gmail.com> <4F3EFB70.5000102@FreeBSD.org> <4f3ff151.FznGzC6RC0a5qBKx%perryh@pluto.rain.com> <4F403C5E.4000104@FreeBSD.org> <4f411fbc.5xpQwqtOGVzi8G4D%perryh@pluto.rain.com> <20120220151409.Horde.NYT-HpjmRSRPQlUxo1tMYtA@webmail.leidinger.net> Date: Mon, 20 Feb 2012 11:57:00 -0500 Message-ID: From: Mehmet Erol Sanliturk To: Alexander Leidinger Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: sendtomatt@gmail.com, rank1seeker@gmail.com, dougb@freebsd.org, perryh@pluto.rain.com, hackers@freebsd.org Subject: Re: 8 to 9: Kernel modularization -- did it change? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Feb 2012 17:25:10 -0000 On Mon, Feb 20, 2012 at 9:14 AM, Alexander Leidinger < Alexander@leidinger.net> wrote: > Quoting perryh@pluto.rain.com (from Sun, 19 Feb 2012 08:13:48 -0800): > > Doug Barton wrote: >> >>> On 02/18/2012 10:43, perryh@pluto.rain.com wrote: >>> > Doug Barton wrote: >>> >> loading modules through loader.conf is >>> >> veeeeeerrrrryyyyyy sssssllllloooooowwwwww ... >>> > >>> > Is it noticeably slower to load (say) a 6MB kernel + 2MB of >>> > modules than to load an 8MB kernel? >>> >>> I don't know, that wasn't the problem I was trying to solve. >>> >> >> Given the context of the thread, this: >> >> >> loading modules through loader.conf is >>> >> veeeeeerrrrryyyyyy sssssllllloooooowwwwww ... >>> >> >> seemed to be an objection to modularizing the kernel. Hence my >> > > Looks more like an opinion. In fact, I work on a modularized kernel config > which I want to commit to -current at some point (for those which do not > care how long it takes to boot the system). > > The goal of my work is to produce something like GENERIC+more, just as > much as possible loaded as kld's (the "+more" part is the result of a poll > I did on stable@, it contains only stuff which can not be loaded as a > kld, and I provide a loader.conf which disables the parts which would cause > a major change in behavior). Currently I'm doing some compile testing, I > should be able to provide something for review soon (on current@). > > Bye, > Alexander. > > -- > WORK: > The blessed respite from screaming kids and > soap operas for which you actually get paid. > > http://www.Leidinger.net Alexander @ Leidinger.net: PGP ID = B0063FE7 > http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137 > > I think , inclusion of a scheduler ( 4BSD , ULE , etc. ) selection facility into loader.conf will be a useful improvement , because it seems that schedulers are not equivalent . In that way , it will be possible to select a scheduler for compute intensive processing , or input/output intensive processing , or user interaction intensive processing . My choice would be to have options in boot menu as a best approach . Thank you very much . Mehmet Erol Sanliturk From owner-freebsd-hackers@FreeBSD.ORG Mon Feb 20 17:42:48 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CF0CF106566B for ; Mon, 20 Feb 2012 17:42:48 +0000 (UTC) (envelope-from egoitz@ramattack.net) Received: from proxypop04.sare.net (proxypop04.sare.net [194.30.0.65]) by mx1.freebsd.org (Postfix) with ESMTP id 925708FC0C for ; Mon, 20 Feb 2012 17:42:48 +0000 (UTC) Received: from www.saremail.com (unknown [194.30.0.100]) by proxypop04.sare.net (Postfix) with ESMTPSA id 8CCD09DC49C for ; Mon, 20 Feb 2012 18:24:54 +0100 (CET) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Date: Mon, 20 Feb 2012 18:24:54 +0100 From: egoitz@ramattack.net To: Message-ID: X-Sender: egoitz@ramattack.net User-Agent: Saremail/0.6-svn Subject: Jumpstart on FreeBSD 9.0 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Feb 2012 17:42:48 -0000 Hi all, I'm trying to upgrade my Jumpstart services for provisioning machines, but I'm founding that in FreeBSD 9.0 things are become slightly different than in previous releases. For example... tar -C ... -pxvf does not work with some files (althout you can mount iso and later do an rsync preserving file flags....), another change is that you don't see a mfsroot for using in the service... perhaps in this release you need to create by you're own... has anyone see this problems I'm talking about in this new release?? If I rebuild the release isos... (from source) could I pass something (or can do something) for getting the commented mfsroot?. Any experience on this area you could comment out... please? Thanks a lot for you're time. Regards, From owner-freebsd-hackers@FreeBSD.ORG Mon Feb 20 18:26:48 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DCACA1065673 for ; Mon, 20 Feb 2012 18:26:48 +0000 (UTC) (envelope-from tim@kientzle.com) Received: from monday.kientzle.com (99-115-135-74.uvs.sntcca.sbcglobal.net [99.115.135.74]) by mx1.freebsd.org (Postfix) with ESMTP id A28328FC13 for ; Mon, 20 Feb 2012 18:26:47 +0000 (UTC) Received: (from root@localhost) by monday.kientzle.com (8.14.4/8.14.4) id q1KIQkh2085906; Mon, 20 Feb 2012 18:26:46 GMT (envelope-from tim@kientzle.com) Received: from [192.168.2.119] (CiscoE3000 [192.168.1.65]) by kientzle.com with SMTP id cwyzikgt6qagitki2f8a9qcx72; Mon, 20 Feb 2012 18:26:46 +0000 (UTC) (envelope-from tim@kientzle.com) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=us-ascii From: Tim Kientzle In-Reply-To: Date: Mon, 20 Feb 2012 10:26:44 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <756376BE-7AF5-44C0-A7C1-80C652504D5F@kientzle.com> References: To: egoitz@ramattack.net X-Mailer: Apple Mail (2.1257) Cc: freebsd-hackers@freebsd.org Subject: Re: Jumpstart on FreeBSD 9.0 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Feb 2012 18:26:48 -0000 On Feb 20, 2012, at 9:24 AM, egoitz@ramattack.net wrote: >=20 > For example... tar -C ... -pxvf does not work with some files (althout = you can mount iso and later do an rsync preserving file flags....),=20 The FreeBSD ISOs are now being built with a tool that builds ISO images differently than before. tar has some restrictions in what ISO images it can read, and the FreeBSD ISOs no longer meet those restrictions. Tim From owner-freebsd-hackers@FreeBSD.ORG Mon Feb 20 18:56:41 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 12DFB106564A; Mon, 20 Feb 2012 18:56:41 +0000 (UTC) (envelope-from fernando.apesteguia@gmail.com) Received: from mail-lpp01m010-f54.google.com (mail-lpp01m010-f54.google.com [209.85.215.54]) by mx1.freebsd.org (Postfix) with ESMTP id 2513D8FC19; Mon, 20 Feb 2012 18:56:39 +0000 (UTC) Received: by lagz14 with SMTP id z14so9803374lag.13 for ; Mon, 20 Feb 2012 10:56:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=VkG3S8yeRiyCDUkbWLfUqPnE/9PntwquzUJ1FS0q7DY=; b=i0Jm5vGK3PyCdEG22urQge/pTpR1GNTCrS6JZXG3JObrH1G1X0rjqoK0XgYazZWIF9 DC9yVA7T9a/ZuLvTl/6OQT8mKc973Hglr6HYEh+xDb8WfRtUX78efkqrPYd+lNHg4Ecg 0D0A2VOfa4HCB1B99Bz8bm6+YUftmeFvf92jw= MIME-Version: 1.0 Received: by 10.152.147.1 with SMTP id tg1mr13743934lab.22.1329762687569; Mon, 20 Feb 2012 10:31:27 -0800 (PST) Received: by 10.152.13.72 with HTTP; Mon, 20 Feb 2012 10:31:27 -0800 (PST) In-Reply-To: References: <4F3EE186.4020801@gmail.com> <201202181409.08859.hselasky@c2i.net> Date: Mon, 20 Feb 2012 19:31:27 +0100 Message-ID: From: =?ISO-8859-1?Q?Fernando_Apestegu=EDa?= To: vermaden Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-hackers@freebsd.org, freebsd-current@freebsd.org, freebsd-stable@freebsd.org Subject: Re: devd based AUTOMOUNTER X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Feb 2012 18:56:41 -0000 On Mon, Feb 20, 2012 at 2:27 PM, vermaden wrote: > written by ${ME} ... > > > First BUG: (not fixed yet, but workaround already is working) > > > > TEST/BUG/CASE: > > Plug in FAT32 and NTFS drives at the same time, when FAT32 device > > will be detected first, it will get mounted and the NTFS drive will be > > mounted TWICE, so I added > __check_already_mounted function > > to check if it is not already mounted. > > This BUG is fixed, I was in wrong assumption, that the script would > be only executed for /dev/da0 but it was executed for every > device/partition node that appeared separately, like /dev/da0, > /dev/da0s1, /dev/da0s2 etc. > > Currently there is no knows bugs, but the prepared earlier > 'workaround functions' remain just in case. > > As I written before its now available here: > https://github.com/vermaden/automount > What a nice piece of work. I just downloaded it and try it on a FreeBSD 9.0-RELEASE with custom kernel. It works like a charm. I tried three different USB devices without noticing any problems (and I was very impolite when I unplugged them). Thanks for this script. > Regards, > vermaden > > > > > > > > > > > > > > > > > > > --- > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" > From owner-freebsd-hackers@FreeBSD.ORG Mon Feb 20 18:58:26 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9200C1065670 for ; Mon, 20 Feb 2012 18:58:26 +0000 (UTC) (envelope-from dieterbsd@engineer.com) Received: from mailout-us.gmx.com (mailout-us.gmx.com [74.208.5.67]) by mx1.freebsd.org (Postfix) with SMTP id 3E9A18FC0A for ; Mon, 20 Feb 2012 18:58:26 +0000 (UTC) Received: (qmail 12473 invoked by uid 0); 20 Feb 2012 18:58:25 -0000 Received: from 67.206.161.80 by rms-us018 with HTTP Content-Type: text/plain; charset="utf-8" Date: Mon, 20 Feb 2012 13:58:21 -0500 From: "Dieter BSD" Message-ID: <20120220185822.300970@gmx.com> MIME-Version: 1.0 To: freebsd-hackers@freebsd.org X-Authenticated: #74169980 X-Flags: 0001 X-Mailer: GMX.com Web Mailer x-registered: 0 Content-Transfer-Encoding: 8bit X-GMX-UID: mfIwb/UU3zOlNR3dAHAhBpF+IGRvbwAj Subject: Re: OS support for fault tolerance X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Feb 2012 18:58:26 -0000 Rayson writes: > The question is, are we planning to handle >95% of the errors for >99% > of the hardware we run on, or are we really planning to spend years > trying to design something that would require special hardware > support? I assume this started as: "Oh look, most CPUs have multiple cores these days, maybe we could play with fault tolerance".  Which could be useful if CPU cores failed a lot, but in reality what fails is disks, disks, controllers, disks, random other things, and disks.  Assuming you have avoided the garbage-quality stuff, and have the system on a UPS.  If you have enough ports you can add more disks and mirror or some other version of RAID. The next step is to duplicate everything.  Not by looking for a mainboard with redundant everything, but by simply adding another computer.  And rather than getting two of the same machine, you're better off if they are different, so that they don't have the same bugs. The problem then is how to feed both machines the same inputs, and compare the outputs.  Do we need a third machine to supervise? Which then leads to the issue of how to avoid problems when *it* breaks. Can we have each machine keep an eye on the other, avoiding the need for a third machine? From owner-freebsd-hackers@FreeBSD.ORG Mon Feb 20 19:17:26 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C95731065670; Mon, 20 Feb 2012 19:17:26 +0000 (UTC) (envelope-from vermaden@interia.pl) Received: from smtpo.poczta.interia.pl (smtpo.poczta.interia.pl [217.74.65.207]) by mx1.freebsd.org (Postfix) with ESMTP id 8001D8FC0A; Mon, 20 Feb 2012 19:17:26 +0000 (UTC) Date: Mon, 20 Feb 2012 20:17:23 +0100 From: vermaden To: Freddie Cash , fernando.apesteguia@gmail.com X-Mailer: interia.pl/pf09 In-Reply-To: References: <4F3EE186.4020801@gmail.com> <201202181409.08859.hselasky@c2i.net> X-Originating-IP: 85.89.187.172 Message-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=interia.pl; s=biztos; t=1329765444; bh=uMYrSnlaRG9ek8YMAgsT8vbd52OexD3LRy6eEC9BVjo=; h=Date:From:Subject:To:Cc:X-Mailer:In-Reply-To:References: X-Originating-IP:Message-Id:MIME-Version:Content-Type: Content-Transfer-Encoding; b=B9jfS8mYmxD+kO+8tg/2zIHZvojmdcM5v8h6HN3DCTpeZgAJvAY/ylRNwhUhPZSVm rRmK4tUb5YC9NQN0CoHV9r/jq98j0jGWTnWy2Kdw3lHqzm6ZJEWORJXgG1Wp4p2BBr udXzBYjvpKe1def6q4PDWPg93UmECufpl4J7qWQU= X-Mailman-Approved-At: Mon, 20 Feb 2012 19:24:31 +0000 Cc: freebsd-hackers@freebsd.org, freebsd-current@freebsd.org, freebsd-stable@freebsd.org Subject: Re: devd based AUTOMOUNTER X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Feb 2012 19:17:26 -0000 Hi, I removed the state_lock and stat_unlock mechanisms as they appeared to be not needed, I have shufled with 3 drives all the time and the 'integrity' has not been lost, at it was a lot faster, because the lock always had to wait for the 'slowest' drive (in term of initializing the device, like USB hard drive). I simplified the 'attach' section a lot, now each filesystem contains only check/fsck (if possible), mount and log info. I also simplified and improved the 'detach' section a little. I have added an option to automatically launch the set-up in config file manager (Yes, like in Windows ;p).=20 These are options that I currently successfully use for NAUTILUS file manager, You need to set-up all three of them to make it work. | POPUP=3DYES | FM=3D"nautilus --browser --no-desktop" | USER=3Dvermaden My whole config looks like that now: | USERUMOUNT=3DYES | POPUP=3DYES | FM=3D"nautilus --browser --no-desktop" | USER=3Dvermaden | ENCODING=3Dpl_PL.ISO8859-2 | CODEPAGE=3Dcp852 All latest updates are available at GITHUB: https://github.com/vermaden/automount written by Freddie Cash ... > Konqueror (KDE 3.x and 4.x) and Dolphin (KDE 4.x mainly, but I > believe there's a KDE 3.x version) also show automatically > mounted and removable media in the sidebar. Works nicely > with HAL. Haven't tested your script yet, but am intrigued by it. > Will see if I can test it sometime this week. >=20 > Native solutions are so much nicer than ported ones. :) Thanks, looking forward to hear some more input about it from You ;) written by Fernando Apestegu=C3=ADa ... > What a nice piece of work. Thanks mate. > I just downloaded it and try it on a FreeBSD 9.0-RELEASE with > custom kernel. It works like a charm. I tried three different > USB devices without noticing any problems (and I was very > impolite when I unplugged them). >=20 > Thanks for this script. Good to know, try the latest new version from repo, should be even better ;= ) Regards, vermaden From owner-freebsd-hackers@FreeBSD.ORG Mon Feb 20 20:09:11 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B27E2106564A for ; Mon, 20 Feb 2012 20:09:11 +0000 (UTC) (envelope-from emaste@freebsd.org) Received: from mail1.sandvine.com (Mail1.sandvine.com [64.7.137.134]) by mx1.freebsd.org (Postfix) with ESMTP id 792938FC16 for ; Mon, 20 Feb 2012 20:09:11 +0000 (UTC) Received: from labgw2.phaedrus.sandvine.com (192.168.222.22) by WTL-EXCH-1.sandvine.com (192.168.196.31) with Microsoft SMTP Server id 14.1.339.1; Mon, 20 Feb 2012 15:09:10 -0500 Received: by labgw2.phaedrus.sandvine.com (Postfix, from userid 10332) id 990B933C02; Mon, 20 Feb 2012 15:09:10 -0500 (EST) Date: Mon, 20 Feb 2012 15:09:10 -0500 From: Ed Maste To: Message-ID: <20120220200910.GA46212@sandvine.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline User-Agent: Mutt/1.4.2.1i Subject: tftpd: avoid logging error for pxeboot option negotiation? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Feb 2012 20:09:11 -0000 After upgrading a diskless boot server from FreeBSD 6 to 8 I see an error message logged each time a diskless client boots: Feb 20 00:56:38 TPC-D4-35 tftpd[55229]: Got ERROR packet: TFTP Aborted It turns out that the pxeboot client (from Intel) first performs a TFTP read request with the tsize option to which it receives an acknowledgement containing the size of the file to be transferred. Then it sends back an error response to abort the transfer, and sends the read request again (without the tsize option). The sequence of packets is: 1. C->S TFTP Read Request, File: pxeboot, Transfer type: octet, tsize=0 2. S->C TFTP Option Acknowledgement, tsize=239616 3. C->S TFTP Error Code, Code: Not defined, Message: TFTP Aborted 4. C->S TFTP Read Request, File: pxeboot, Transfer type: octet, blksize=1456 5. S->C TFTP Option Acknowledgement, blksize=1456 6. C->S TFTP Acknowledgement, Block: 0 7. S->C TFTP Data Packet, Block: 1 ... I'd like to avoid logging the error here, for the sake of this pxeboot client and any other tftp clients that might check options without actually starting a transfer. Anyone opposed to removing it? (A proposed patch is at http://people.freebsd.org/~emaste/tftpd.diff). -Ed From owner-freebsd-hackers@FreeBSD.ORG Mon Feb 20 20:33:06 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E20FB106564A for ; Mon, 20 Feb 2012 20:33:06 +0000 (UTC) (envelope-from nwhitehorn@freebsd.org) Received: from adsum.doit.wisc.edu (adsum.doit.wisc.edu [144.92.197.210]) by mx1.freebsd.org (Postfix) with ESMTP id B175E8FC08 for ; Mon, 20 Feb 2012 20:33:06 +0000 (UTC) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII; format=flowed Received: from avs-daemon.smtpauth1.wiscmail.wisc.edu by smtpauth1.wiscmail.wisc.edu (Sun Java(tm) System Messaging Server 7u2-7.05 32bit (built Jul 30 2009)) id <0LZP00302IB52X00@smtpauth1.wiscmail.wisc.edu> for freebsd-hackers@freebsd.org; Mon, 20 Feb 2012 13:33:05 -0600 (CST) Received: from wanderer.tachypleus.net (pc2.sgchiba-unet.ocn.ne.jp [220.110.182.82]) by smtpauth1.wiscmail.wisc.edu (Sun Java(tm) System Messaging Server 7u2-7.05 32bit (built Jul 30 2009)) with ESMTPSA id <0LZP00GLKIAXSB20@smtpauth1.wiscmail.wisc.edu>; Mon, 20 Feb 2012 13:32:58 -0600 (CST) Date: Tue, 21 Feb 2012 04:32:56 +0900 From: Nathan Whitehorn In-reply-to: To: egoitz@ramattack.net Message-id: <4F429FE8.303@freebsd.org> X-Spam-Score-Internal: ******* X-Spam-Report: AuthenticatedSender=yes, SenderIP=220.110.182.82 X-Spam-PmxInfo: Server=avs-15, Version=5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2012.2.20.192414, SenderIP=220.110.182.82 References: User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:10.0.2) Gecko/20120220 Thunderbird/10.0.2 Cc: freebsd-hackers@freebsd.org Subject: Re: Jumpstart on FreeBSD 9.0 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Feb 2012 20:33:07 -0000 On 02/21/12 02:24, egoitz@ramattack.net wrote: > Hi all, > > I'm trying to upgrade my Jumpstart services for provisioning machines, > but I'm founding that in FreeBSD 9.0 things are become slightly > different than in previous releases. For example... tar -C ... -pxvf > does not work with some files (althout you can mount iso and later do an > rsync preserving file flags....), another change is that you don't see a > mfsroot for using in the service... perhaps in this release you need to > create by you're own... has anyone see this problems I'm talking about > in this new release?? If I rebuild the release isos... (from source) > could I pass something (or can do something) for getting the commented > mfsroot?. To get tar to extract the ISOs, I think you need a newer tar. There was some conformance issue in makefs. With respect to the mfsroot, this was something that slipped before the 9.0 release. If you want it, the easiest way is to build new media that use sysinstall (which also makes things identical to 8.x releases), which you can do by: cd /usr/src make -f Makefile.sysinstall release There are some environment variables you can read about here: http://www.freebsd.org/cgi/man.cgi?query=release&apropos=0&sektion=7&manpath=FreeBSD+8.2-stable&arch=default&format=html This situation should be corrected for 9.1. -Nathan From owner-freebsd-hackers@FreeBSD.ORG Mon Feb 20 20:40:57 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 26530106564A; Mon, 20 Feb 2012 20:40:57 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from mx1.sbone.de (mx1.sbone.de [IPv6:2a01:4f8:130:3ffc::401:25]) by mx1.freebsd.org (Postfix) with ESMTP id CC9408FC16; Mon, 20 Feb 2012 20:40:56 +0000 (UTC) Received: from mail.sbone.de (mail.sbone.de [IPv6:fde9:577b:c1a9:31::2013:587]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.sbone.de (Postfix) with ESMTPS id 029E625D3A00; Mon, 20 Feb 2012 20:40:55 +0000 (UTC) Received: from content-filter.sbone.de (content-filter.sbone.de [IPv6:fde9:577b:c1a9:31::2013:2742]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPS id 354FBBDBC84; Mon, 20 Feb 2012 20:40:55 +0000 (UTC) X-Virus-Scanned: amavisd-new at sbone.de Received: from mail.sbone.de ([IPv6:fde9:577b:c1a9:31::2013:587]) by content-filter.sbone.de (content-filter.sbone.de [fde9:577b:c1a9:31::2013:2742]) (amavisd-new, port 10024) with ESMTP id UJzbaftdkpBW; Mon, 20 Feb 2012 20:40:54 +0000 (UTC) Received: from orange-en1.sbone.de (orange-en1.sbone.de [IPv6:fde9:577b:c1a9:31:cabc:c8ff:fecf:e8e3]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPSA id E0537BDBC82; Mon, 20 Feb 2012 20:40:53 +0000 (UTC) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: "Bjoern A. Zeeb" In-Reply-To: <20120220200910.GA46212@sandvine.com> Date: Mon, 20 Feb 2012 20:40:52 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: <7DCFF8A0-D54F-4846-97BE-BA6BE33C92C7@lists.zabbadoz.net> References: <20120220200910.GA46212@sandvine.com> To: Ed Maste X-Mailer: Apple Mail (2.1084) Cc: freebsd-hackers@freebsd.org Subject: Re: tftpd: avoid logging error for pxeboot option negotiation? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Feb 2012 20:40:57 -0000 On 20. Feb 2012, at 20:09 , Ed Maste wrote: > After upgrading a diskless boot server from FreeBSD 6 to 8 I see an = error > message logged each time a diskless client boots: >=20 > Feb 20 00:56:38 TPC-D4-35 tftpd[55229]: Got ERROR packet: TFTP Aborted >=20 > It turns out that the pxeboot client (from Intel) first performs a = TFTP > read request with the tsize option to which it receives an = acknowledgement > containing the size of the file to be transferred. Then it sends back > an error response to abort the transfer, and sends the read request = again > (without the tsize option). >=20 > The sequence of packets is: >=20 > 1. C->S TFTP Read Request, File: pxeboot, Transfer type: octet, = tsize=3D0 > 2. S->C TFTP Option Acknowledgement, tsize=3D239616 > 3. C->S TFTP Error Code, Code: Not defined, Message: TFTP Aborted > 4. C->S TFTP Read Request, File: pxeboot, Transfer type: octet, = blksize=3D1456 > 5. S->C TFTP Option Acknowledgement, blksize=3D1456 > 6. C->S TFTP Acknowledgement, Block: 0 > 7. S->C TFTP Data Packet, Block: 1 > ... >=20 > I'd like to avoid logging the error here, for the sake of this pxeboot > client and any other tftp clients that might check options without = actually > starting a transfer. Anyone opposed to removing it? (A proposed = patch is > at http://people.freebsd.org/~emaste/tftpd.diff). Rather than completely ignoring it, can we log it in a different = category, so that one would actually still have a chance to see real "abort" = errors? --=20 Bjoern A. Zeeb You have to have visions! It does not matter how good you are. It matters what good you do! From owner-freebsd-hackers@FreeBSD.ORG Mon Feb 20 21:04:05 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7EE4A106564A; Mon, 20 Feb 2012 21:04:05 +0000 (UTC) (envelope-from kabaev@gmail.com) Received: from mail-qw0-f47.google.com (mail-qw0-f47.google.com [209.85.216.47]) by mx1.freebsd.org (Postfix) with ESMTP id 1A5558FC0C; Mon, 20 Feb 2012 21:04:04 +0000 (UTC) Received: by qadz30 with SMTP id z30so3950429qad.13 for ; Mon, 20 Feb 2012 13:04:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=date:from:to:cc:subject:message-id:in-reply-to:references:x-mailer :mime-version:content-type; bh=cBbPtTy0RZt3QMxtemUdp7EUfTe3AKZsdrtyFwwRPao=; b=OFZlsd1A9HteMpe1hyaj0F146sHuyiYxtuEHJ0OGgUoLKdyvYMn/gtqEzzgPgb58CJ vDH+xhpefpg0ex1xjpEI5cZRU8LnbG3tHlMThNetny6vFji2RwQs21FdUWUhFvx+udxW yVR4Yg6EFs1nSLbwaMzma0oCvMvMsKqaA7qFg= Received: by 10.229.135.131 with SMTP id n3mr14448363qct.101.1329770410374; Mon, 20 Feb 2012 12:40:10 -0800 (PST) Received: from kan.dyndns.org (c-24-63-226-98.hsd1.ma.comcast.net. [24.63.226.98]) by mx.google.com with ESMTPS id hi8sm52387249qab.3.2012.02.20.12.40.09 (version=SSLv3 cipher=OTHER); Mon, 20 Feb 2012 12:40:09 -0800 (PST) Date: Mon, 20 Feb 2012 15:39:59 -0500 From: Alexander Kabaev To: Ed Maste Message-ID: <20120220153959.70f57bf4@kan.dyndns.org> In-Reply-To: <20120220200910.GA46212@sandvine.com> References: <20120220200910.GA46212@sandvine.com> X-Mailer: Claws Mail 3.8.0 (GTK+ 2.24.6; amd64-portbld-freebsd10.0) Mime-Version: 1.0 Content-Type: multipart/signed; micalg=PGP-SHA1; boundary="Sig_/JVnoVZ=Ct_9Tz8NV_Qhja.R"; protocol="application/pgp-signature" Cc: freebsd-hackers@freebsd.org Subject: Re: tftpd: avoid logging error for pxeboot option negotiation? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Feb 2012 21:04:05 -0000 --Sig_/JVnoVZ=Ct_9Tz8NV_Qhja.R Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable On Mon, 20 Feb 2012 15:09:10 -0500 Ed Maste wrote: > After upgrading a diskless boot server from FreeBSD 6 to 8 I see an > error message logged each time a diskless client boots: >=20 > Feb 20 00:56:38 TPC-D4-35 tftpd[55229]: Got ERROR packet: TFTP Aborted >=20 > It turns out that the pxeboot client (from Intel) first performs a > TFTP read request with the tsize option to which it receives an > acknowledgement containing the size of the file to be transferred. > Then it sends back an error response to abort the transfer, and sends > the read request again (without the tsize option). >=20 > The sequence of packets is: >=20 > 1. C->S TFTP Read Request, File: pxeboot, Transfer type: octet, > tsize=3D0 2. S->C TFTP Option Acknowledgement, tsize=3D239616 > 3. C->S TFTP Error Code, Code: Not defined, Message: TFTP Aborted > 4. C->S TFTP Read Request, File: pxeboot, Transfer type: octet, > blksize=3D1456 5. S->C TFTP Option Acknowledgement, blksize=3D1456 > 6. C->S TFTP Acknowledgement, Block: 0 > 7. S->C TFTP Data Packet, Block: 1 > ... >=20 > I'd like to avoid logging the error here, for the sake of this pxeboot > client and any other tftp clients that might check options without > actually starting a transfer. Anyone opposed to removing it? (A > proposed patch is at http://people.freebsd.org/~emaste/tftpd.diff). >=20 > -Ed > _______________________________________________ IIRC, PXE sends an error packet with zero error code. Could you supress the error message in that case and avoid propagation of the 'ignore error' flag? PXE client is not alone doing that - custom TFTP implementation in pxeloader does that as well now, so suppressing errors in this case is a good idea. --=20 Alexander Kabaev --Sig_/JVnoVZ=Ct_9Tz8NV_Qhja.R Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (FreeBSD) iD8DBQFPQq+nQ6z1jMm+XZYRAuBJAJ0TUp++8E9qn+JX++cP0HsEl2rYtgCfVfWm Y6lM0w2P48Ho6eyc9eNR8OY= =xQAM -----END PGP SIGNATURE----- --Sig_/JVnoVZ=Ct_9Tz8NV_Qhja.R-- From owner-freebsd-hackers@FreeBSD.ORG Mon Feb 20 21:08:53 2012 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx2.freebsd.org (mx2.freebsd.org [IPv6:2001:4f8:fff6::35]) by hub.freebsd.org (Postfix) with ESMTP id 7AAB51065670 for ; Mon, 20 Feb 2012 21:08:53 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from 172-17-197-151.globalsuite.net (hub.freebsd.org [IPv6:2001:4f8:fff6::36]) by mx2.freebsd.org (Postfix) with ESMTP id 1844D150090; Mon, 20 Feb 2012 21:08:53 +0000 (UTC) Message-ID: <4F42B664.4070400@FreeBSD.org> Date: Mon, 20 Feb 2012 13:08:52 -0800 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (X11; FreeBSD i386; rv:10.0.2) Gecko/20120218 Thunderbird/10.0.2 MIME-Version: 1.0 To: Alex Goncharov References: <4F3E8225.9030501@FreeBSD.org> <4F3E8C26.3080900@FreeBSD.org> <4F3EA5F2.9070804@gmail.com> <4F3EAE5F.6070903@gmail.com> <20120217.220802.988.2@DOMY-PC> <4F3EDEBC.7040703@gmail.com> <4F3EFB70.5000102@FreeBSD.org> In-Reply-To: X-Enigmail-Version: 1.3.5 OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Tom Evans , hackers@freebsd.org Subject: Re: 8 to 9: Kernel modularization -- did it change? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Feb 2012 21:08:53 -0000 On 02/20/2012 08:54, Alex Goncharov wrote: > ,--- You/Tom (Mon, 20 Feb 2012 14:44:09 +0000) ----* > | On Sat, Feb 18, 2012 at 1:14 AM, Doug Barton wrote: > | > Because loading modules through loader.conf is > | > veeeeeerrrrryyyyyy sssssllllloooooowwwwww I added an rc.d script called > | > kld that will load the specified modules after disks are mounted. This > | > is at least an order of magnitude faster. > > | Come off it, loading modules from loader.conf takes seconds off disk, > | out of the 2+ minute total boot up. In my testing, which I posted around the time that I wrote and added the kld script, each module takes "a second or two" from the boot loader, whereas the 5 modules I load routinely take less than a second in total. > | There may be benefit on slow > | media, but in the general case I see no benefit (which might explain > | why not many people are bothering to change their working configs to > | save <2s on bootup). So don't make the change. I don't really care how much time you want to waste while your system boots. :) > Seconded. > > As many have noticed, the "veeeeeerrrrryyyyyy sssssllllloooooowwwwww" > and "order of magnitude faster" claim has not been supported by > empirical evidence in this discussion. That's because I already posted it a long time ago, and it's been confirmed by others on many occasions. Short version, the mechanism used by the loader to pull the bits off the disk is *always* going to be slower than reading them from the booted disk. I understand that you guys are new to this topic, so I'm happy to give you time to catch up, test it for yourself, etc. > If instead of .002 sec the module loading takes .02, It's closer to 1.5 seconds per module, on average. > nobody cares. And here's where you're making the biggest mistake. You're assuming that the only use case that's important is the one that you're familiar with. This isn't even close to true. For embedded systems speeding up the boot is critical. It's also important for people who use FreeBSD systems to make money, where every second of downtime translates to dollars lost. > The fact that one can spread configuration and initialization > parameters across several non-hierarchically-related entities > (rc.conf, loader.conf, device.hints) somewhat arbitrarily, seems not > right to me. A) It's not arbitrary, and B) That's an emotional response to a technical topic. Take a step back and try to understand the system, and why it's designed the way it is, separate from your emotions about it. That will help you make better technical decisions. > Personally, I don't care about winning 10 seconds on a boot So, don't use kld_list. It won't hurt *my* feelings one bit. :) Doug -- It's always a long day; 86400 doesn't fit into a short. Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ From owner-freebsd-hackers@FreeBSD.ORG Mon Feb 20 21:11:45 2012 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx2.freebsd.org (mx2.freebsd.org [IPv6:2001:4f8:fff6::35]) by hub.freebsd.org (Postfix) with ESMTP id 7CEE61065672 for ; Mon, 20 Feb 2012 21:11:45 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from 172-17-197-151.globalsuite.net (hub.freebsd.org [IPv6:2001:4f8:fff6::36]) by mx2.freebsd.org (Postfix) with ESMTP id BB73B177B51; Mon, 20 Feb 2012 21:10:49 +0000 (UTC) Message-ID: <4F42B6D9.9000400@FreeBSD.org> Date: Mon, 20 Feb 2012 13:10:49 -0800 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (X11; FreeBSD i386; rv:10.0.2) Gecko/20120218 Thunderbird/10.0.2 MIME-Version: 1.0 To: Tom Evans References: <4F3E8225.9030501@FreeBSD.org> <4F3E8C26.3080900@FreeBSD.org> <4F3EA5F2.9070804@gmail.com> <4F3EAE5F.6070903@gmail.com> <20120217.220802.988.2@DOMY-PC> <4F3EDEBC.7040703@gmail.com> <4F3EFB70.5000102@FreeBSD.org> In-Reply-To: X-Enigmail-Version: 1.3.5 OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: hackers@freebsd.org Subject: Re: 8 to 9: Kernel modularization -- did it change? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Feb 2012 21:11:45 -0000 On 02/20/2012 06:44, Tom Evans wrote: > wrt to sound drivers no longer being built as modules, I wonder why > this change has been made. I don't recall a mass of people complaining > that they couldn't load drivers, Then you haven't been paying attention. :) > Whatever happened to POLA? This change surprised me, wasn't mentioned > in /usr/src/UPDATING, You're supposed to compare your existing kernel config to the new GENERIC every time you do a major version upgrade. That would have made the change quite obvious. Doug -- It's always a long day; 86400 doesn't fit into a short. Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ From owner-freebsd-hackers@FreeBSD.ORG Mon Feb 20 21:54:43 2012 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9CF48106566C; Mon, 20 Feb 2012 21:54:43 +0000 (UTC) (envelope-from sendtomatt@gmail.com) Received: from mail-pz0-f54.google.com (mail-pz0-f54.google.com [209.85.210.54]) by mx1.freebsd.org (Postfix) with ESMTP id 602AB8FC1B; Mon, 20 Feb 2012 21:54:43 +0000 (UTC) Received: by daec6 with SMTP id c6so6907649dae.13 for ; Mon, 20 Feb 2012 13:54:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:content-type :content-transfer-encoding; bh=1jeDOKgyu0jodUAySTjvwo/vqxMQXJeCYR5s0jd6n8U=; b=HFc1YKG1MHp4wqO49+hVfEjZEMm6eCeFvYE7+NJOeJ3LRV8OW5oKC6YYBj2P0zQGgU Jr7Q0pbTuhXsqxhlm0GNK/QFtlW3fApDshMzE7OoJPJavN06UXEwiaxozjn2VDf8Co60 KH8lahXV0Oky1Z7xjLlITEoH+tILR75uU2pOY= Received: by 10.68.220.162 with SMTP id px2mr6448289pbc.47.1329774883112; Mon, 20 Feb 2012 13:54:43 -0800 (PST) Received: from bakeneko.local ([75.101.87.90]) by mx.google.com with ESMTPS id m3sm14160598pbg.44.2012.02.20.13.54.40 (version=SSLv3 cipher=OTHER); Mon, 20 Feb 2012 13:54:41 -0800 (PST) Message-ID: <4F42C0DF.6090604@gmail.com> Date: Mon, 20 Feb 2012 13:53:35 -0800 From: matt User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.1) Gecko/20120217 Thunderbird/10.0.1 MIME-Version: 1.0 To: Alex Goncharov References: <4F3E8225.9030501@FreeBSD.org> <4F3E8C26.3080900@FreeBSD.org> <4F3EA5F2.9070804@gmail.com> <4F3EAE5F.6070903@gmail.com> <20120217.220802.988.2@DOMY-PC> <4F3EDEBC.7040703@gmail.com> <4F3EFB70.5000102@FreeBSD.org> In-Reply-To: X-Enigmail-Version: 1.3.5 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Tom Evans , hackers@freebsd.org, dougb@freebsd.org Subject: Re: 8 to 9: Kernel modularization -- did it change? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Feb 2012 21:54:43 -0000 On 02/20/12 08:54, Alex Goncharov wrote: > ,--- You/Tom (Mon, 20 Feb 2012 14:44:09 +0000) ----* > | On Sat, Feb 18, 2012 at 1:14 AM, Doug Barton wrot= e: > | > Because loading modules through loader.conf is > | > veeeeeerrrrryyyyyy sssssllllloooooowwwwww I added an rc.d script ca= lled > | > kld that will load the specified modules after disks are mounted. T= his > | > is at least an order of magnitude faster. > > | Come off it, loading modules from loader.conf takes seconds off disk,= > | out of the 2+ minute total boot up. There may be benefit on slow > | media, but in the general case I see no benefit (which might explain > | why not many people are bothering to change their working configs to > | save <2s on bootup). > > Seconded. > > As many have noticed, the "veeeeeerrrrryyyyyy sssssllllloooooowwwwww" > and "order of magnitude faster" claim has not been supported by > empirical evidence in this discussion. If instead of .002 sec the > module loading takes .02, nobody cares. > > The fact that one can spread configuration and initialization > parameters across several non-hierarchically-related entities > (rc.conf, loader.conf, device.hints) somewhat arbitrarily, seems not > right to me. > More options are better...since some things are needed for boot, and some things are needed once the machine hits multiuser, it makes sense to not put your eggs in one basket as far as latency, reliability etc. I might want Vbox loaded, but not so early that it could hose the boot process prior to single user, etc. Matt From owner-freebsd-hackers@FreeBSD.ORG Mon Feb 20 23:02:06 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9A21F106566B for ; Mon, 20 Feb 2012 23:02:06 +0000 (UTC) (envelope-from emaste@freebsd.org) Received: from mail1.sandvine.com (Mail1.sandvine.com [64.7.137.134]) by mx1.freebsd.org (Postfix) with ESMTP id 55E028FC0A for ; Mon, 20 Feb 2012 23:02:06 +0000 (UTC) Received: from labgw2.phaedrus.sandvine.com (192.168.222.22) by WTL-EXCH-1.sandvine.com (192.168.196.31) with Microsoft SMTP Server id 14.1.339.1; Mon, 20 Feb 2012 18:02:05 -0500 Received: by labgw2.phaedrus.sandvine.com (Postfix, from userid 10332) id 63C4233C02; Mon, 20 Feb 2012 18:02:05 -0500 (EST) Date: Mon, 20 Feb 2012 18:02:04 -0500 From: Ed Maste To: Alexander Kabaev Message-ID: <20120220230202.GA59361@sandvine.com> References: <20120220200910.GA46212@sandvine.com> <20120220153959.70f57bf4@kan.dyndns.org> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline In-Reply-To: <20120220153959.70f57bf4@kan.dyndns.org> User-Agent: Mutt/1.4.2.1i Cc: freebsd-hackers@freebsd.org Subject: Re: tftpd: avoid logging error for pxeboot option negotiation? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Feb 2012 23:02:06 -0000 On Mon, Feb 20, 2012 at 03:39:59PM -0500, Alexander Kabaev wrote: > IIRC, PXE sends an error packet with zero error code. Could you supress > the error message in that case and avoid propagation of the 'ignore > error' flag? > > PXE client is not alone doing that - custom TFTP > implementation in pxeloader does that as well now, so suppressing errors > in this case is a good idea. Thanks for the suggestion, that makes a much simpler patch: Index: tftp-io.c =================================================================== --- tftp-io.c (revision 231851) +++ tftp-io.c (working copy) @@ -463,7 +463,8 @@ } if (pkt->th_opcode == ERROR) { - tftp_log(LOG_ERR, "Got ERROR packet: %s", pkt->th_msg); + tftp_log(pkt->th_code == EUNDEF ? LOG_DEBUG : LOG_ERR, + "Got ERROR packet: %s", pkt->th_msg); return (RP_ERROR); } From owner-freebsd-hackers@FreeBSD.ORG Mon Feb 20 23:02:54 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx2.freebsd.org (mx2.freebsd.org [IPv6:2001:4f8:fff6::35]) by hub.freebsd.org (Postfix) with ESMTP id 37740106566B for ; Mon, 20 Feb 2012 23:02:54 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from 172-17-197-151.globalsuite.net (hub.freebsd.org [IPv6:2001:4f8:fff6::36]) by mx2.freebsd.org (Postfix) with ESMTP id C665C150598; Mon, 20 Feb 2012 23:02:33 +0000 (UTC) Message-ID: <4F42D109.4090802@FreeBSD.org> Date: Mon, 20 Feb 2012 15:02:33 -0800 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (X11; FreeBSD i386; rv:10.0.2) Gecko/20120218 Thunderbird/10.0.2 MIME-Version: 1.0 To: papowell@astart.com References: <4F3E8225.9030501@FreeBSD.org> <4F3E8C26.3080900@FreeBSD.org> <4F3EA5F2.9070804@gmail.com> <4F3EAE5F.6070903@gmail.com> <20120217.220802.988.2@DOMY-PC> <4F3EDEBC.7040703@gmail.com> <4F3EFB70.5000102@FreeBSD.org> <4F426588.7090104@astart.com> In-Reply-To: <4F426588.7090104@astart.com> X-Enigmail-Version: 1.3.5 OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@freebsd.org Subject: Re: 8 to 9: Kernel modularization -- did it change? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Feb 2012 23:02:54 -0000 On 02/20/2012 07:23, Patrick Powell wrote: > Oooh! Ahhh! Just what I was looking for. l will extract this from 9 > and put it on my system. Glad you like it. :) One thing though, you're actually better off updating to the latest -stable of whatever branch you're using, some work has gone into making the rcorder come out right for this. > Much better than having to edit the loader.conf and/or having to create > a rc.local script. -- It's always a long day; 86400 doesn't fit into a short. Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ From owner-freebsd-hackers@FreeBSD.ORG Tue Feb 21 07:13:18 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0BED2106564A for ; Tue, 21 Feb 2012 07:13:18 +0000 (UTC) (envelope-from perryh@pluto.rain.com) Received: from agora.rdrop.com (unknown [IPv6:2607:f678:1010::34]) by mx1.freebsd.org (Postfix) with ESMTP id DC5488FC0C for ; Tue, 21 Feb 2012 07:13:17 +0000 (UTC) Received: from agora.rdrop.com (66@localhost [127.0.0.1]) by agora.rdrop.com (8.13.1/8.12.7) with ESMTP id q1L7D5YT047043 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 20 Feb 2012 23:13:05 -0800 (PST) (envelope-from perryh@pluto.rain.com) Received: (from uucp@localhost) by agora.rdrop.com (8.13.1/8.14.2/Submit) with UUCP id q1L7D51F047042; Mon, 20 Feb 2012 23:13:05 -0800 (PST) (envelope-from perryh@pluto.rain.com) Received: from fbsd81 ([192.168.200.81]) by pluto.rain.com (4.1/SMI-4.1-pluto-M2060407) id AA16997; Mon, 20 Feb 12 23:06:22 PST Date: Tue, 21 Feb 2012 06:05:09 -0800 From: perryh@pluto.rain.com To: dieterbsd@engineer.com Message-Id: <4f43a495.h+USsCyXrPm0omOx%perryh@pluto.rain.com> References: <20120220185822.300970@gmx.com> In-Reply-To: <20120220185822.300970@gmx.com> User-Agent: nail 11.25 7/29/05 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@freebsd.org Subject: Re: OS support for fault tolerance X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Feb 2012 07:13:18 -0000 "Dieter BSD" wrote: > The problem then is how to feed both machines the same inputs, and > compare the outputs. ??Do we need a third machine to supervise? > Can we have each machine keep an eye on the other, avoiding the > need for a third machine? A pair would work as long as the only failures are "obvious" (e.g. crashes). If they simply disagree as to the result, how would we determine which one was right? > Which then leads to the issue of how to avoid problems when *it* > breaks. For some reason, this reminds me of a Dr. Seuss story: http://www.goodreads.com/review/show/49519038 From owner-freebsd-hackers@FreeBSD.ORG Tue Feb 21 08:23:02 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 493D5106577F for ; Tue, 21 Feb 2012 08:22:57 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from vps1.elischer.org (vps1.elischer.org [204.109.63.16]) by mx1.freebsd.org (Postfix) with ESMTP id D40978FC0A for ; Tue, 21 Feb 2012 08:22:56 +0000 (UTC) Received: from julian-mac.elischer.org (adsl-68-126-134-16.dsl.scrm01.pacbell.net [68.126.134.16]) (authenticated bits=0) by vps1.elischer.org (8.14.4/8.14.4) with ESMTP id q1L8MrpH058495 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Tue, 21 Feb 2012 00:22:54 -0800 (PST) (envelope-from julian@freebsd.org) Message-ID: <4F435458.9020204@freebsd.org> Date: Tue, 21 Feb 2012 00:22:48 -0800 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X 10.4; en-US; rv:1.9.2.27) Gecko/20120216 Thunderbird/3.1.19 MIME-Version: 1.0 To: freebsd-hackers@freebsd.org References: <4F3A9266.9050905@freebsd.org> <20120214170533.GA35819@DataIX.net> <4F3A9907.8000903@gamozo.org> <4F425987.6010506@herveybayaustralia.com.au> In-Reply-To: <4F425987.6010506@herveybayaustralia.com.au> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Da Rock <9Phackers@herveybayaustralia.com.au> Subject: Re: OS support for fault tolerance X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Feb 2012 08:23:02 -0000 On 2/20/12 6:32 AM, Da Rock wrote: > On 02/15/12 03:25, Brandon Falk wrote: >> On 2/14/2012 12:05 PM, Jason Hellenthal wrote: >>> On Tue, Feb 14, 2012 at 08:57:10AM -0800, Julian Elischer wrote: >>>> On 2/14/12 6:23 AM, Maninya M wrote: >>>>> For multicore desktop computers, suppose one of the cores fails, >>>>> the >>>>> FreeBSD OS crashes. My question is about how I can make the OS >>>>> tolerate >>>>> this hardware fault. >>>>> The strategy is to checkpoint the state of each core at specific >>>>> intervals >>>>> of time in main memory. Once a core fails, its previous state is >>>>> retrieved >>>>> from the main memory, and the processes that were running on it are >>>>> rescheduled on the remaining cores. >>>>> >>>>> I read that the OS tolerates faults in large servers. I need to >>>>> make it do >>>>> this for a Desktop OS. I assume I would have to change the >>>>> scheduler >>>>> program. I am using FreeBSD 9.0 on an Intel core i5 quad core >>>>> machine. >>>>> How do I go about doing this? What exactly do I need to save for >>>>> the >>>>> "state" of the core? What else do I need to know? >>>>> I have absolutely no experience with kernel programming or with >>>>> FreeBSD. >>>>> Any pointers to good sources about modifying the source-code of >>>>> FreeBSD >>>>> would be greatly appreciated. >>>> This question has always intrigued me, because I'm always amazed >>>> that people actually try. >>>> From my viewpoint, There's really not much you can do if the core >>>> that is currently holding the scheduler lock fails. >>>> And what do you mean by 'fails"? do you run constant diagnostics? >>>> how do you tell when it is failed? It'd be hard to detect that >>>> 'multiply' >>>> has suddenly started giving bad results now and then. >>>> >>>> if it just "stops" then you might be able to have a watchdog that >>>> notices, but what do you do when it was half way through >>>> rearranging >>>> a list of items? First, you have to find out that it held >>>> the lock for the module and then you have to find out what it had >>>> done and clean up the mess. >>>> >>>> This requires rewriting many many parts of the kernel to remove >>>> 'transient inconsistent states". and even then, what do you do if it >>>> was half way through manipulating some hardware.. >>>> >>>> and when you've figured that all out, how do you cope with the >>>> mess it made because it was dying? >>>> Say for example it had started calculating bad memory offsets >>>> before writing out some stuff and written data out over random >>>> memory? >>>> >>>> but I'm interested in any answers people may have >>>> >>> How about core redundancy ? effectively this would reduce the >>> amount of >>> available cores in half in you spread a process to run on two >>> cores at >>> the same time but with an option to adjust this per process etc... I >>> don't see it as unfeasable. >>> >> The overhead for all of the error checking and redundancy makes >> this idea pretty >> impractical. You'd have to have 2 cores to do the exact same thing, >> then some >> 'master' core that makes sure they're doing the right stuff, and if >> you really >> want to think about it... what if the core monitoring the cores >> fails... there's >> a threshold of when redundancy gets pointless. > Make no mistake here, I'm not really up with the guts of what this > would require (the dog may not hunt at all). Consider me as the > little boy throwing rocks at a hornets nest :) > > That out of the way, how about this scenario: why can't the master > be dynamic amongst the cores? 1 core be the master of any 2 cores > (not itself). > > Another thought (probably more scifi then anything else) is about > using the cores as individuals which work as a team and fire a weak > team member that is failing. > > I have absolutely no idea how to accomplish this, but I thought it > might fire a few neurons in someone who does... :) There are so many reasons this would be ineffective on standard hardware I have no idea where to begin, but see my email above.. >> >> Perhaps I'm missing out on something, but you can't check the >> checker (without >> infinite redundancy). >> >> Honestly, if you're worried about a core failing, please take your >> server >> cluster out of the 1000 deg C forge. >> >> -Brandon > > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to > "freebsd-hackers-unsubscribe@freebsd.org" > From owner-freebsd-hackers@FreeBSD.ORG Tue Feb 21 09:45:28 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 89051106567B for ; Tue, 21 Feb 2012 09:45:28 +0000 (UTC) (envelope-from egoitz@ramattack.net) Received: from proxypop04.sare.net (proxypop04.sare.net [194.30.0.65]) by mx1.freebsd.org (Postfix) with ESMTP id 8AD128FC12 for ; Tue, 21 Feb 2012 09:45:27 +0000 (UTC) Received: from www.saremail.com (unknown [194.30.0.100]) by proxypop04.sare.net (Postfix) with ESMTPSA id AAD9E9DC464; Tue, 21 Feb 2012 10:45:25 +0100 (CET) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="=_48c3bc13d5e7b91fb36721a79011320b" Date: Tue, 21 Feb 2012 10:45:25 +0100 From: egoitz@ramattack.net To: Nathan Whitehorn In-Reply-To: <4F429FE8.303@freebsd.org> References: <4F429FE8.303@freebsd.org> Message-ID: <2302656984477a6b671f298f965fcb88@ramattack.net> X-Sender: egoitz@ramattack.net User-Agent: Saremail/0.6-svn Cc: freebsd-hackers@freebsd.org Subject: Re: Jumpstart on FreeBSD 9.0 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Feb 2012 09:45:28 -0000 --=_48c3bc13d5e7b91fb36721a79011320b Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=UTF-8; format=flowed > > To get tar to extract the ISOs, I think you need a newer tar. There > was some conformance issue in makefs. > > With respect to the mfsroot, this was something that slipped before > the 9.0 release. If you want it, the easiest way is to build new > media > that use sysinstall (which also makes things identical to 8.x > releases), which you can do by: > cd /usr/src > make -f Makefile.sysinstall release > > There are some environment variables you can read about here: > > http://www.freebsd.org/cgi/man.cgi?query=release&apropos=0&sektion=7&manpath=FreeBSD+8.2-stable&arch=default&format=html > > This situation should be corrected for 9.1. > -Nathan Good morning, So for generating new ISOS working with Sysinstall and the previous mfsroot and so but in 9.0-RELEASE... I should do something like (I paste the steps I follow for generating updates isos of a release, and here I apply the change suggested) : /usr/src and /usr/obj are empty... /usr/local/bin/cvsup /var/cvsup/cvs-supfile cd /usr cvs -R -d /expert/ncvs co -r RELENG_9_0 src cd /usr/src make buildworld mkdir /expert/RELENG90RELEASE /etc/rc.d/adjkerntz start adjkerntz -i cd /usr/src/release/ make -f Makefile.sysinstall release CHROOTDIR=/expert/RELENG90RELEASE CVSROOT=/expert/ncvs RELEASETAG=RELENG_9_0 MAKE_ISOS=1 This should generate a freebsd releng_9_0 isos with sysinstall and mfsroot.... and all tools for installing Jumpstart in previous ways, wich basically where like the pdf I attached, isn't it??... and that I have sent some time to these lists in order it could help someone else... And finally.... How should then the proper way to extract the content of an iso file... as I said before... I just do (till now and worked fine) : "tar -C /expert/netboot/freebsd8 -pxvf 8.0-RELEASE-amd64-disc1.iso"... Thanks a lot for all you're great help!!!. Best Regards, --=_48c3bc13d5e7b91fb36721a79011320b Content-Transfer-Encoding: base64 Content-Type: application/pdf; name=freebsdpxehowto.pdf Content-Disposition: attachment; filename=freebsdpxehowto.pdf JVBERi0xLjQKJcOkw7zDtsOfCjIgMCBvYmoKPDwvTGVuZ3RoIDMgMCBSL0ZpbHRlci9GbGF0ZURl Y29kZT4+CnN0cmVhbQp4nM1YTavsNgzd31+RdeFNLfkrgWEgkzuz6O7BQBelu35AF4W+Tf9+j+TY ceKZ5N5CoYSbXDseSzqSjuSYE3V/v/3VGVx+8CfX9Y67b792P37X/TnPm+7b72/Xx5sPp76L0Z1C 9/il+/5OHXH3+O2ns6HLFzobNvaCh96c8ToXLl/4bKLpdTToaLzoVFqgg+ult2czLW+veP+uw5ve 79iTzIV6mfj58cPb7fH29al6weC+Vo+gnv1/3XdNsPbETxEmFmyYrGBCTmEkTwH3KAD1mNFbnghp kXqE50k8Qu0qGub9xurNPAU3qEyaKpmtrPePLdPZa5IcaaQr3WTJHQP92awnm0XhO3nYmyxl0scu dmFwCGjFjjsywA7QiU0SkAZA4dmbAc8RI4c4m/Cfw4p3rOvNzdzJ4M0E2ST3y+OP18JCn1MhCyM4 hxx+aKH4FRuNGAfAag3hDnwQ63tbctx4nrlgufalgK74ecAeFH+27LJra4BpZF+txTt1i/4kzMs/ gq4fBhDEJrnWbibPMaU84srjclkSTVCv39+/9w23fGj/+9HGkVpWkI3ZzVGpcaZquhXeCaQUkUdC nGvyFgreKwgAvzrG81CkzNiM8IxqNBQvR76+SlVYPCWdRO/yu0rvxQxxPAcW2Ta/5uuRMda0rn5m jCoEGIfV9mOlTlqBqON3vuHyzfPQfRTauBiTuJD92GerAWWfMaw0SHCNlVcrpK2BEodqGG6iaLGT p38lmIDCsWjXD439NGa+BdxOsnxDE5C50LHlRblcHkYWjkjUcKRA9G1wzwlpsU1YYi1FR2GYWXom nZmISlYDgAPJgdpIfLoVzwAAmXUZS25AXQXOPv/ZIzZyqMMNaTwN9+3WLCWtTodPJQN2c/uKsdm2 BxFX4gGh2Rxba3tJt17PHeeeM6HtRmKxj6eccy9K+CdBtwM33lZxYQmrBOxn6NJ6G+TXS8lI48yi 1YtDZrSxbxvgqI1Yw47wSdkXnF3R81XUVSUyjPcZskq9KoQa1V9aemxAcJu4PtvdPsfa2OY+2o9U iat0T30esqOKhW3bp6OQy/bLsMlleWG03O0sHs95XeuRwX2FD8IQV65b5EvnuvyzYL5tmz7SI1kz NOFhexU21RZUZkzZwNlm1SPb9gGR3LuT3TS9oEI0tj36znSB/cVo4nmMWla9tQIQwBjLTESTPFTj 0j7Ddx78OpG0zoT5LImX3XBVs2Sk/5W2+lWQgWKGp1bYvbDkuF3uVK1e+nbt6rW7h7Jqyu5Wzudj QxXhEhRLiibviAfXaVtOKJ9yGcWT30bJSzbAnuO2Dx5Xh0E7CNXourruxDnIWSpOzcSy8nNVadcc 6ofTtkGx42WI60TNVXmu0pJV2gLwJcRzycwpd/XXcm4o+YpuJbd6clwdMvOnM0HdwbslvXJmyeZe T0hRj0xZq8aT6XdjfcBym2xlvw9I4BzMCyDX5I1ygOlXoWWnulcRbcCPs62b41/8TwrH54hUzzEL UylSEmMa/7vQoJpsj+goA+IHMMWkXLOTxmAgaXYmrJEjPKMQCbf0CA0i2eOd9BAP8CQeEProT0FU yn3MDpRuNFeCIQ500/+GPXIgMPq2/DW+FE3m0lRqi4RawqVOgn23D3D5UlAF5Sc9Su7fJ13wLEJ4 dT4uKpVD4dwjFrFBYv/5mf1FWFQJVJrie5VDBwminxqfYZo++JG5lA+FM5/CsU/wKuepmohjW1X9 UV+y7zPFzFQH9qE9Ta2KeH5z9Fls86UhtY1Vb5ByDGE7h1b62reWocc3oTVe9xMVwSuPXZcO55Vr WCpx45vz/newntrTeW6q6thJShS2rrArH63qilWzP2CR2jB/BvXlYyZ84tO6sV5+18a78lGCoiRZ VfUq1daesbxOszFLSiI2FWrhbRVdOLmubwvqX7t/ALf4Ad0KZW5kc3RyZWFtCmVuZG9iagoKMyAw IG9iagoxNDQ2CmVuZG9iagoKNSAwIG9iago8PC9MZW5ndGggNiAwIFIvRmlsdGVyL0ZsYXRlRGVj b2RlPj4Kc3RyZWFtCnicxVnJiuRGEL33V+hs6HJG5CZBUaBSVR18G2jwwfhmj8EHg+fi33dE7ouW 7unpGQpUUq6Rsb6IFCcY/nv6dxD005M+qWFUOHz5c/j1p+Gf0C6GL389XV+etDmNg7XmNA0vfww/ P3AAMbx8PqMVUoBAeiqhhRGW/vkJ/I8jvSuYxUS/+fLy99P95enT6tJGn0y/NCBIUGLZnaoEHaSe SvvBRNONWMSMM1HBVE5iJIokWNCuh1tncQN+SnpaanNP7gWglqvrsTSTiQnnAC2uQOvgVchdwkCt nYkIYSK0uMMNFbFphKvbEh3z/FfYyrF1oZaRSLP0rYgkOlLqV0Qck80zaAW4ZXYLtUuckCc8Ji4t 9qjeP4wsM8GGiq2ShUvxbj6QrFGc9FeStXwgWWZ6lRCRlrPp/+PIUXCSnhwYgAj7/NtZPC7WnMlQ 4Cws3OmPjO8hSdfhwazhhomaNKgLniUZWvGJj6ZBynbEjT4tL8LUWpyojSwfL3o8o+Yf9fMYHgxX QP5bkD0U+s3d5JGb+eEIKwmgTzfH7b5cnulV8pPalzCIX/1afDz/JvNIt4NAv3Ie55pRhdU8f9CG j99fflnlMk7E4J7NNHVXLmij9ia5IOuHZa8D2nFtXSDCypunyrPBUX6NTAmckHdmVThKZMkjMBiF H6vTWYMwdCPZePxmIyca7cU0xxVIIwVvM4UFq0GemcxuQ5tg7HadjrjUX68ddENur+dHbEtHn+wK s4+kA5Km1dKpNFw+UG/uySvo0cQImFaQV8dLHVQqmd7imR/OqnrDLNnAr96kHsxJPzVYWxCz8ePH yNcoIQTXv0+3Hju9pJmY1loxusqDzJWGJetDnSzdkxwnR33I3C1P611ENEUTxB5te7xsaBr7HZhk p0+t2jROKNIUja72O/pNfPD2BNtaAoJUrGf3gWZqpXrNlEGvpmRJ1vkQVfIznmhLO2rL7Dgmb4VP T2NN1kF2DJ6Qa5aOd+CPKiB457spmSBBE53xGF19y+clHMUpSnuqI/OEaQ08UDRWzDkHLQVH7PfE ZTrOQsBWCoa21L8rVzF2iDnBhh0cTyQLREXKqRyavhJBCm/UOJENPvBObLoTntYON2+RIGn3aY2G fTStJn7WE97LLyBSQbyGaE/CyEnS2/lWEjQ5UpkUQzmKZDJYyxI/v6kS7MM1ZdVXqcErjkMqwq3f 8zAGo696/2Goh/STfq7lhxxHqpgHbYf0m48JAb55V7Z4z4XsWrrYVmAgK01yXwuBtRDsXKQx2Yf7 iQVMc30mYLuIFr0rnqX23e3wNefrATrtePcOOkFCTySKGEKqqMwxIPv6yIoOuRVB6C14RImpTdid WwBgfUBXHSg1ZkXl92QqpzHi9uTBSBVc4WG3OCKtiH6nzKuUbLFyCIkuGjtGzCnnOE4+VsVEaqRz yK2ASy2YPQSeFtgACgUqaANryOCKgF5vq6vvDLbKXIRClj903lczHHMpUNh/E9IbCt09/w+Ak6Sn aYFT0vDqBJvYaTUZmjwnZNO1ksOupk2r5rmKdD3nd61FYuugHGJdy7MSAN72BAXQ2kgoc9JYu4Za K99j/xQtOjvz6Y8Jy2BinYKGxXB5lme8ytkNnHk3fXkmHb7u7omj7VRlZ08nNQz+Ou5ZjafMOM84 2tzKiKles/ni3UZC/unMq2q1sc4RSUa0BIm4iosXOUXyO7D1hDQvFzMSZ1SaCykcxayxIHPGxxFd EjvdIFlPdiXt5RykNN+gp9HO131nYdh+kMLorVXwCJHUEDMLQdQ5eR/smw038uaiAOWG+cJVZW3J 06Apo64NVaN8wt1QVEUen+OVdahE7JZACBzpFYkceGWEsffK/hi0e+VrpmjczBuuFsLUCq92O9WH TpBIF6lvdomFQ9xEUpGpOTTa6E2r9lsPmarK5pyroIH+oJlkS2iS2nbaGsoR+SOf/3V0bYdUIKDe y+JIeEL1rspwDTbC4dWgkSs+NloTmnBaT3iOjiEExYJXMh/Pliljk6IijBdjM0wJQv8W1u9J3Y/A YG0s/28nCbUCprPOkHFVeIkwJHCgjuPOSt1kiSX+WBq/EOpkrwm3oKbeHu9hr++QnuzSJsf2ZgVG 5Cro6Ko16Oo31qWT/lLwzv17GgwgutuRDdgcTRSWUPWLbqn0zMFJVe5ZO9+61Joc/UFxJ1HeatTw euOyo19B5pADWKnAfqH1QKdH7EqOnUqn1T0RfRxa48uxir9JwYODiMlNtvSYX3RkLdmEQNcuo90x O4J+34L7gYCQHazWV48WjMDbrBQ2N6MvnqCX09Etx9jVM9q6eJER5Zs1rpa0pfmEewICDJdr68Vm WYX2NEu4GyoSRABBbS1/E74GwW31t1jA7pI8F4MdzGjPcFAq35aR4auolueljD4N/wPO/TX/CmVu ZHN0cmVhbQplbmRvYmoKCjYgMCBvYmoKMTgwOAplbmRvYmoKCjggMCBvYmoKPDwvTGVuZ3RoIDkg MCBSL0ZpbHRlci9GbGF0ZURlY29kZT4+CnN0cmVhbQp4nL1YS4+kNhC+96/gHGmIq/wApFFLwDQr 7W2TlnKI9pSXFGUjZS/791Ouso3BQDObyU5LDA121Vevr8qtaqi+XP6pFH1sZ2tTtQarz79VP31X /R2eq+rzH5fhfrGubqumMbWr7r9W309QAVb3339+BnPFZ7CqgU7pKzzTTUP/oIOWXsRHadHAb1Hl a1WjnV/bwCTfUdajv8x3Fka0/kML9fVJBGLj76K0UW78BfpcLUMySR5/vfnLQC+TnvUO+tezMFSy 6Balk+Iumsd3tAc1+g2ykgGiowfOv4qSh7jbyQ0GyOKsgHOE/vrx/v5yu18+rMOATd1sxIH2Xu9/ bu7gwDlF11Xg2uQJkyKFwTCwaAhH7pQhW3vo0Oj9sx7KfMQSLEwaZc2IeuU5XGRUdGdYHdJiRsQm +gtake1YoJP1WYIisFm7bmcnal3jyolsGbpgk7eBUxmm5D7yZBeydwamb1E1QT7UCR2V5YZO0hic NQZzvGXYh7ylGwkUZe5Ii/poZw8ulhtHZoQpZqLfIOhDTjLcjnbb7J2LIdBS5eLyXlt5vVouWJ2s Ih3xpUeChq4vOOF07AJlC9Ipc1S0x2rNdPei4q0D45p1PekXyqyXkuJIoU4cNbNSYoIAj3LdCKAu lSJ0tFnsC15fpTXXU6IvPXIsRFvj62jJnvNm8gZ696WSIz2tOLDhfAlVLsGVDJGVLMt5vRJAwkef jLmWfCr0PJdb5Dlv4557QdVd4d8HBOecKWrzDEfNfL/kExfqOWMU/zTP/cQ6WexiKaVmkbvcc1ws RNxtAedYUx/XjNOubNSMJxVCK0kxg1ymivWcTAGOiCNnBqz9Q8ZNfCvqXkXQb1yqqlu7oveiQhQN /YUG8MCrtoWCjPUgk0iYQ041Emt12Y1vISPJ9sO9Rq250Oyx4Vs50KIristYttstZweRFsLM2ZO1 8R2e8iALCyTJ0riXOvXG/lCTUUSaLDl7ebo4M6v8l2IUmMcuBHxlH+9f0SJNa4qEUtO1cZGpirgs GOykTxlSxueBMU+lvLHN9uy0a397LA9sYfG6FBNlbTXNo4wqEWUum2cncYBfK8+Q7yOR8Xbuwm5O RirJSDvZUKAwZi1ms3Aaz7kqJF/zcloaVQhcHViSbUFizgor+l/2reSyM2HWdM5Y9x3jjB/y2+sT QekYRX8O8KEmbWstmrACxRMCqhcFqqUaVWpUA2jw0+6oQVMXQuUvRzOEphp1+yIpkgSZvo3KeZH0 baA307FQbBs6ZS+EUnwHEtJ/LU46bhQ4yb8KfFsj0RtisWXUx2J1W3crpKg65UVuYj0lFFLrSFhp PqZtSpEYSgLvz+brhEPbPuzHUsCc5hMPYHMLkFYTe0zJbNyPwuTnB4biRJo1gfhM+qGfsvbqO+gh egikY+aJ+OGvJ4nR+oxLsjOXdNM0ZO5VkLGGiqd034MhGzZ+/vl2R0lmoCNKANNsDlVDnH24pVI2 N1TpN7z9T+fgY4wbh1lQkk2JhlfdaE30YVR9MHEU59MwsY1hgPHJ3YlpQdHySCglkn5gw+xUt/4B LMvQAlJtFXQuAKPj1BYyiYCOJeZlGa/eUM8wXnWTZpG9Uc4PYXO4MhDAMKBKqn/5dFF1U31ZwPvh 3UVVT0BM/YlDZOTLX9WPhXM1dMRo69MpBSMWzofqX7adjdEKZW5kc3RyZWFtCmVuZG9iagoKOSAw IG9iagoxMjU3CmVuZG9iagoKMTIgMCBvYmoKPDwvTGVuZ3RoIDEzIDAgUi9GaWx0ZXIvRmxhdGVE ZWNvZGUvTGVuZ3RoMSAzMTc0ND4+CnN0cmVhbQp4nOx9eXwUVbbwvVXV+1ZdXb1Ur1W9ZelOOlsn gc5SEEAEWUS2AJE1QDAQAkFFHcGZURRcUNRRwJEZt1FcQgIYQMVR3EYRZ8R1nAF9iI6K20PH9yDd 37nVnZBEnW/e7/vv+70Ode+5S926y7lnu6eKjlVrmpERrUc0khcun7+ycfj8KQih1xDC3MJLO8Tz WtRvAnwcIc2Ni1cuWT7uwj9+jJCuFSFV65LWtYvLrAs9CJnfRWjyM0ub5y/afhdnRmjuXdBG5VLI 2Nb7iBrSb0A6vHR5x+XjuM9UkD4N6WWtbQvnf2A74kNo3jySXj7/8pVvq2Ua0vB8JK6Yv7z54bOf fQFpuNi6lW2rOxB0FKH2OClfuap5ZdeWh62QvgAh/S7Iw/BHfkYA1SRN0YxKrdHq9AajyWxhrZyN tzucLsHt8fr8AVEKhsKRaF5+QWEsXlScKCktK0f/X/2YT+C6DXkg9tMLkB+hzLHc9VH66mx5ujeT od6BylNzV/Y3Ff7uUMKpeEI2RovQUbQc3Yp+A3nl+HX0MJKRBfKPIhqmfiaqQVvQZegtNC3zDeRK 6D70FYqjYWhpJo2saB1K41+g+zCFKLirGr2JmtFmqoaOMZ/DuhXiEnon/iUqglamojuREx2BFgsz ekh3Uz6qBu6ail6l52rjmZLMt/hZ5pXMAvR7XEO9zTwOGHsKBxmU/lVmU2ZbZjsyo9O0r/f5TGlm Odw1Dc1Da9BV0IP16LfoMG6kaqmDmRugTzOhD+vQk+hVHGMQMw9xaArU/jW6C+1Dz6Aj6F30McbY gvPxevwmPqpCvYfShzLnZxZk2tBoNBFNRuuh1IcjeAQ1i55FP0a/0/sf6eMZP7Q9FV2KLkdXolvQ ZrQTvYPeQ3/FNKWnplLT6MeQB9WiWWgBzOYW6NPD6BV0DGtxBR6OZXwdfpS6lKF7DwG6M8gOMzhW mf1b0TaY0wfQE+gQegP9Gdr8BuaUxgKO4Wl4Dv4FvhbfjG/HD+BH8eP4c0pFvUvT9DXMi8zn6bcz +szWzMPwXA/yIhEVwMpUowtgPQ+jz2B8hTiO6/FfqBgVpzFj7E2nyzPnZdZlXsi8g0IoD+rWolEw 5gloBvR6LfoVOoBehHsPo9fRSfRPmCUa6zEHcyHiEJ6CL8JroBeP4a9wL+WA9aumWqku6igdow8z M5jHe3en7emu9FfpTGZnpjPzfOY1ZX0r4TkNsAJNaCVarazYHnjOC+gE+gf6Dp6hxgHo61g8HsZ7 F7R/DJ8FdNJSV1OPUhm6lt5Mv8IIzF3pienl6bvS3ZmKzATALRqpkIAq4G84YNM01Aht/xJm8z70 CKxMN2DP2+hL7MJ+XILPx9PxTDwPL8VteCVux1fiq2BWH8a78QH8Nv4r/pJiKDVlh3mKUQupX1Jb qN3UIept6gSN6IvomXQ7fSW9hd5Nv0F/yrBMnClhJjDzmLXMFSqkotUO7WtnnWeX9y7o3dr7fLo4 PSp9SXpT+o/pt9MfZQyZg5mPkRqVQB8b0RLo4y9g/Nehm9G9gB+PQB8/RJ+gz2HNv4W5oLEOu6HH AWXdGqDfE6DnM3AjXgx/S/EymP/1eCfuwk/hZ/Ef8Sv4VfwX/AH+isLQ+2L4S8EumEYthjFspXZS ndR78Pcd9V90lI7TZXQ5XUfPg9FsoK+H8fyG/oD+mKEYO1PKXMSsY15S0apFqjtV21SHVC+rPlOz 6tk5GjF1IP2hX6P+yNTRrWgHmkzR9GfUX6ga/AvqDH6I8uE/wtN89GR6MtVApRCFDwCWL0e8Zpta UksUj1jNPNIGdTdVRM9gorQRdcB+Q9Qs6jpqHnoQP4XOUGMB0y6lD1M7qLn0NuY2pg6/g9bBMxFl wt+jEWgEroO1exO1wwoV0U8wr5MWVVr6rGo5ZcpsYD5RUfRfgA7WAqv4E56FT+HJlANmK0XdjEKQ ZvEpiM+HHfgeYP4+PANVM8fpG6lx1F8hrxVtwX+EMR5ArdQB/HtYl2rYj6vwZLydLkVX43aYjWFo GXU7ClIrqSDg8zT0n/iX2A479wysTZhajBjaRC1ER6lGWPU3MEcV46sBT5ejTXgjiuNe/Cx6jboV VeJm+pmzQm8+hc+ewrvosWgXPsO8wrxCMdDSH2E2S4B6yIAh9wGNmAY7U6KjgDXVSEXFAf+bgAJe gKzUd/gqqhW14Lvof+AHqBFoEmqmV1Nj8J3p75gRdDnM2H6gJg3qYVqkqlH5mApY8U9QHWDjEoTU S5ljql8SmH6TPp1pzEjpuSpz+gN0BczOWKBum2AvjUXvYwe+GF/IZKjxTCYzHe2knmA+yDixEUvo zxnYYek9uAaHMyJuzxjwhYDhF6sf7r2b2cRcy6xhrgLedAao5nXoNrQVPQfc5H7gW3kwjxfAbM4B 2tMCPKIElaEkjK4OjQSqdD6UTUbTgZ7OAyq5GK1A7UB570GPol3AocbDfFwM9y1GyyB/NXCoK9HV sP83oBuBBtyJHkR/ph6h7qUl6nrqBepSqgW9j96nX6JlPB0dZW5g1qGLUBhdiG3w5CpYpQDcd2Pm TXhaAfIA9a+AXQp4n/k883bmD71HoL0Hoe+3qUeiz9UNKB9Nwt8zbqySR0yV6+tqa1LDh1VXJSvK y0pLEsVF8VhhQX5eNBIOBSUx4Pd5PW7B5XTYeRtnZS1mk9Gg12k1ahVDUxjFR4fGzBM7o/M6mWho 7Ngikg7Nh4z5AzLmdYqQNWZwnU5xnlJNHFxThpqLh9SUszXl/pqYFWtQTVFcHB0SOw+PCok9eNaF MwG+aVSoUew8pcATFHizApsAliS4QRztWjpK7MTzxNGdYy5dunH0vFHQ3C6DviHU0KwviqNdegOA BoA6naGVu7CzDisA5Rw9fBeFtCboVKc7NGp0pxAaRXrQSUdGz1/UOfnCmaNHeSSpsSjeiRsWhhZ0 otDITktMqYIalMd0qhs6NcpjxBYyGrRJ3BV/duONPSxaMC9mXBRaNH/OzE56fiN5hjUGzx3V6bzi hOtcEhrnGmZuGFjqoTeOdrWIJLlx4waxc8eFMweWSiRsbIQ24F4qMmbexjHw6BthEsdfJMLTqGsb Z3bia+GRIhkJGVV2fM2h0SRn3jKxUxcaGVq6cdk8WBr3xk40Za3U5XbL+zLHkXu0uHHqzJDUWe8J Nc4f5d3Fo41T1nYLsigMLimK72Kt2YndZbbkAKNpINDcX6ZASnUCjZ/SP7OY9Ch0PiBEp7hQhJ7M DMGYqknQXI02LqyGavBrxHBX5yJYkZZOXcO8jexwkk/u71RF2JC48TsEGBA69cXgnPm5HHWE/Q4R kOBJP6pBeR/cGYt1FhYSFNE0wJpCH+uUdLIofmkP1RJayYoQwfShyTC38xuHJ2D6JYks8KYeGS2A ROf6C2dm0yJa4OlCciLW2EnNIyXP9pXYp5GS9X0l/bfPCwEm71YUC3unNtr/z8I6bKOXDu/Ejn9R 3JwtH39RaPyFs2aKozfOy83t+KmDUtny6v6yHNRpa5hJe6gcRHlopRSQck5/ZZKYaexkIvBPrSD1 oh6NFrBSycHimE523ths2KiXpH/zpp7M1+QuJTp3W66bncNjg9OpQelB3TNupKHDTJQaP3XWxo36 QWVjgAJt3DgmJI7ZOG/j/J7M+gUhkQ1t3AcCSHTjytHz+la0J7N/k6dzzI2NMIileDhgK4VG7grh 6y/cJePrL5o1cx8L6uD1U2d2gWjTMG9kY2MRyJLAr5glKqIwatCYXWpNDzbuBhKqYghAI71aBcBe mqbcOg3J24uRoJ10pSs2kT1dM6G3ZiL7fc0EtrcG1df01pCrtKTcKlkjklVawqCzIv3sWVmFziCR eRZWf2fmGDOeXo8K0dd7JL3BUm/vyXwvxwF4yf5B5L2844Hj0ueRz/I0YXueY5Q4ITIhb5rYFJmV t8yyTGiJ3CAYHT2Zb+XVNr7RNt1+SWRx3vduldotsHZ3AVvARdwb2W3sna473A/YH4C6oShntQi8 B0RbrVnwOi0mRFsN6HqrVKAxdDNq7++dUshgTmkbdwTw5sCzASrgjvNSVLbo6ndEsSUaiG6GWRZi h2529eD4tWTQTe04NuEUDLupfcLpU6j+1Kl6+Dth5ZzDrNwwTGJu2DArSZSWoPam6mrc3oRjMZys qCwvc9jtanUoGM2LRkNBtZ13lJdVVin5vAbyUbIClZfRL7g4mws7bVYnpX7i9gPPvf3Iglen2Fmr s/m+l19Nn8GGV/9Im7wBtzvwTMDt9Jy3/rPf3Hd07GTeaY2NvATTL72KQbWn0NUw2zuJTgvz/eHe 8wuXFoIK0EM9LpuRCqsSWKWicFDrd5Es1pNwejwuZ9CvdwTzdU36HrywO1+C+cYLZTEo8X5kNPAa 2L/YGdCJ64m2h7E7HpHWs5jtwTd2xwrXZyeJ/b49Nz+9NTUsYEZ9PVvDnjoB/07DrAxje2u5YQkX Zr87fQidSzSdPlRaMr7TcdH4zjBsl26zltNWVzei8Z3GXNY+0HO/6BL5vP2ZH1A080l3SBsWqpVf I2rCVmUa1aFQksxwFOYbJtZpBZhMva3i3Iwz1EoyeS/c9uGqP69d++fVH9yppFe+e8ed77575x3v Mp+cWe60ca6HXl57/LLLj13xMn7fBcmzL+/44IMd9/7tb4DJJzMz6M9UyxGLlsvDdToHFnR0NRqm G4PP183WXaK7FF+uu0F7g+5OfLfuAfywbi/ai1/Cr+jexifxP3Tf4x90ToMOG3rwy3toQx2arevB XbIez9Y+naAx/Y61Bx/Y9ZQrBvjWe+r0qRMocaq0BBCpCXQ7ZUBVuDKLNvTx3jlWj1XQU/cZeLNV UIX/e2ZEsBjtqj84zYLFAH2dDXjQSC9AedguG/XMHgeV78BurUVHFt5gTGiNRp02aMkigsEzMYcI eRJJF6EwDo8Rw2FJDOZhh4UXpRTK0ztdqYDfb9HqUqxFzUu0QRQRcjp6qPtkXQFrFbVHNBiIyefd +efN70OLJiAPQDUAF2DbEFoBaJGjGoPxomkQYgxJ7FJTDVNnwlzJnnAFFq3uChSLNZaWNKyVWc7G qFURG2MNIE7NBxCKwc675hrAIVsOh55G9swXyJH5CHGZj7KI0y4RhMmLJvtQpdxKsKTqXDKHWPR1 j758pXxRu9/t9r+wdOLhndsI9NV5JLxye8PMNZSfoEnvTVOWPZUFz35L0IhY3I5kjtFpoHyj8Dfy 9Xy9dwTFXQDqa8uoR8VHq35X/ZrtlZF/t73teLvuryM/t52o+HTkWdvpih9Gcgab2qGq040M2OwO e51n5KbgHRUHLIYZtlnVLdXLUldUX526ofqG1AN8F6+/ObUnQF2ojRWEoqVybU2F22Uxa+zGYaii rCTEFFdazEZaDxRQSNXWAn1ugD2e3E2Lxbi4B98pe6OVkoRSmmnDpEn+uf42P+13jymdGkoV2CW5 J/Os7LAI9XJjWwEuEEY3aGh1VC8ZLs7tebLJ6zEhjxNO49gptvcEoQATentPIfYUe6oJgl7rsMQp WGeFUDoJpcyCw4YRSgmrV101khO9EVvEWWcPoJRnWABXiRBwIyHpqHcFkNNVVzvcVxPAHneqpjpQ GUD8CGsAw/oTTMoGsODkpyy6Nbfou1N8hd77VOYT5ITFHwVEpI6v6sl80R101Hir+36NuKkdCDbw /H2oOvOFrDM56lM8BNVQVXaxdkhBMIq38BAYWQiAcXlJOzAzpNKTECOeBLH+H6FMOcrPZyl/HhAi DVAip4P8KZgVzOMVtpDMMQkoI3QqWZEXDSuUDJjCVYQpuBSeUD1lw00TU2NKrnti1Py5r7/00jqt 3cS5ANUEZ+jutvt3XDgl/dL1Fxzd8jgd8wFd2+x3O4SavOphsWRNvtdic4WuGnvJQ81B3uz2P+Z3 C/biQEn9FaMmJhJixdKa1nUEX3eCXDCLvgw2kF3mrzLjuG6Sfhm3lruBu1N9j03jDSq0IvByKBAI hoJej30/9ThyYVnW8S6XnQ96YhFSY1L+xHB+fiQcjBnMvKKkqTQmUBF5M6sPR1IoptbXsxKjsac8 wZTX69FbNF9rKI27CPFi2BKaHFof2hzaEfo6pA4J8d6bFbGjKSt3nGwCmWMCwS7Cg7M0hGBTFrmG Dft5CvIT5GQfwplnuwlB6ckc7+qnKQNwaI+NNzs4r0Iy2nE7tufo7zlurrFK2Qypj27kCAhF3X/f 6PHXCDa92RaqEKq2HcQdhN/0LofJD7y6jYT0gqO3T2t22wSNLeSeuTNdQQiHk4PVfooQEuDmRemr mRlAQSKoFBfJ9aV6y7A8uJJFF+JpVJNpEW6mmtWXmDrwlYWrig3Pq5/Vv6d5T/d+3nulJ9Uf67UC Haev1NxI300/SqsdXmX5hIRPELy+oMNuUdLcy2aOs5iD9kiApEcEE/5gMOAPRrCpIGFJ2b0pQFdz QjLoCyS8hdGgQCqijkoWLda6y+PILPotvkm+ub42H+MTyi4eIDSRJatRSAKh/TX1J4jUVEMW719I BEMSynL0yQJd+caS/ZnTqChzenfMaBLxfiDppZm/7coLndvP7U2wVCB6ZdcK1gbBTuuj5kNXCQ8Q EHDh+EfXXPWX1enepz+88TVC39NtJGxXaD99z5t33X306N2/OUovuHv2nI4jq/akM0+m1cqS2WxO JkWWLN1y65E3Nt/6xhFYu1uBA9fA2hmQE4+VqzkH44AtTr+CXzG8Rf1V9TfNWwb1JZoWKwVryLRo W/TLTK3WZttip9Yu0RZJRxt0GqOEgAoTUqPEZqcSyyZ7shNhFpWgeSDE91AbZBcnqWWoppahTpv6 oPqI+rj6a7VK3YM/6nYVPtbPjmFqTvU2tROSCatST1ZDmWNDbo4PAJ88jXiYYZY3804yw7bMR90m v9XfP8dA3cgsA9GUDQ6e9dTzJLASsd5m8dcbeAi0egg0JLASSurjDPUa3sBBIQQO3uqs40lgI4QV ahySOQD0eqCwWhJQtCVQg2MDaGqWsGKynFmJGWkGSnc16VPPHUp/iblDz2HbtA937PiQXPiJZ9Nf Y+vBZ7E1/fUff/v3Y/dsP34MKN1tsDYp5jYUR6/I4TMebPK4PdT9+j365/Rv6k/oVZearzPfYX7Q /KLhbYPaqcUaQukYvEq2axlGow1iltfZreTUjFcJxoIefJ9s9afCYU0KY6Q2SoKBvx40p4dlPh7X 6sSo9CLysl7Ru9J70KuCffhxdxGsCVmPEzVEYD59AmX3Rg3beyqrThBeOWQrAL80uz16g8GtCyC9 x5iVdYDrtZMFwX2UyDpYw1B4TL9ck2M2eD9+WUHx6jXt016s4k2syyT+s33L44p4s42wHXqBItj8 +fwF5aJJsFpM0oSNa6gEyfyBVCIcoxU4BqFP1XiDXPWW+i0tdUh9SEvdp+1Sd2npds16DbVQs0i7 yENv8zygpq4MdOPdFO0NLAtQCDMU5ddyWU3EYg/YKfsYwW53CUGuIKGQpvickng8URIssBqyGowZ m8fozWaDPmjNV5gRiyJshIrMkSKRoBTMry4jmabkmNJksqw0WJaqVsNAjyMR9BmbD1hOQX4+x1n1 Or3oPiZggUiu7HAkiaWbS3aUUCXCMBBc+2kXiRQll8gY9b2ngXz9rBbzs6mhRf+S9cAC8x6vSqvR qrWU2qtyg9Sj9RFhB8cKFenG00cKAzzc+vddHj7LnNoJCoCq0JSle0TE6FeN+mheRZZh/RwpnDHz 5sZ5k6pnK6Lth4RXjfnl8ouuaJ+r4MmXJJyrlNEL1jWOKvBvOr/3K0L9AFecFN14ZcO1vd/0p/cp DAyo4HrYaQnAEAGJ6A25Re+4206VUSOpKdRC6kXqRdufhPe594UPPP/h+jjw3w6T4C30VlDV/nGe CwJzPLMCbZ7WwNWeGz13e+/2P6myrHHs9x6iD3GveF/xq7UvWN2ggWBs9UlODSNZDcap7tQOhFcC Zvbgj2VnUEzh1A4et/EH+SP8MZ7hBanw0QFq/YRTp4jSekrZfqdglYiCcmow03Hw6p7M17s9fMBP ASnrI4HtIDliyTF0q/XRpqx0wBSd/YPj44cvfn2Ezcy62JLvrnk3fQxbXn4d62cIb23ZctSN77nv pbpyi2C1smUzsOeVJ7E6/Z/XbHr80ZvI/poG+2s5aPPVQHqK7nafESkG2/Ei9Rr1Znw7tQPfT3Xi bkr/gPpBzW7VHs2Lmnc1x9wat9bqzO4qPsBT/BwXzztdQevQXcXqs7vKhE1zdCaTXhdks7vKMGRD hZKJ7IaqxmKBV2JgF0F3qxGjYfVA3YRjLuwiW8mgbKWDJUdgKxE1cNhQNTC7nxTTAPk7Zf33xID/ tx3Fuj0qjTriUQkB7NZ4s7spqytw/UYGdeb0HtEY4P2OnFZAaKo1J0L8aMtUKNL8z2+lKZO3zF5w w5yLA4IQSH9FttLFv1ozZ0SideBeUsQK5pPeMzPOG33LpN5/nttLs68oEi/r/aIvg6lTNhNGz2c+ YrBKBdhg7W6tBhzPfCuXl5UlrcPD54fHRRqqVyH1Oum66juYLck7qx9IPli9z7bf+artVf6w86+2 vzm/sP23M5Owkvv2gLQergDG+3fZC0CB1mKI5VvphOR3u5Aq5EWCX8yPxoUePLtbFLl4D76pO1pb boZ4D1erDtVW9mCTrLfX0l7vMNo9PLEfm5CXuuZJgzCsXKU2fbEfrwfVIKslEh1xwgnQDk/CqoH0 fhoUxN4T8I/LaYfDrDkjGuiGWb3QW5EMR2w8o4pUhGRsU9llHE5GZcwznAxcL7uC11wDUXVTezWq bseOfrlcYXHOrC5FtqGS4VRSZE+qc8aUnChP2zqu+K6n9dNii5Nl+W2P3fbC/L1NIJ0LY9u3bL1q xm1x1mqwumas3XrvawuonRV7FvzmkzklLMe6LKufXDl+80VklfDG2RdvrqngdU42v3bawV9PvRMo 38eZj+hPVeR0PYEf6+YofWh/5ltEZ053FWkLRugAzgdJKy/zT5C4/onsmX/u9Zp1Zq2ZIpYuNvNt l89cRO4ohFUOFai85oA5yC3X+r0cKsZ5KlMwZJZquXitilOpTO5aEANf21sarjULJb/bj9XZyScT DxSuT9JTNKWsnTI7zbOoYjbqEpyCQ7ALvKBSez0+j98T8DDqvGh+tCBaGGXUBqPeqDNqjRqjSk1H g9awjESbW8YxdURGRUxCxiGLJGOPAEHUGJdRMQUBEdeyenkh/GLXoD7xEVcP/BEh0m7124R63m91 1ltJ4PD7ufpgT+aMLAOQx3utEHhYCAQLBE5zfYgEebzDBBAENA/1aD/ImEV6CBwE8gGtJ418ITsB sPDOALkrUE/pWWudkwQ49uMfUoRMO6vJqXiATUlWQRVgqU4HiJxZXZ4CzV5R5cvLuCT96TXNW8f9 qtg32uIEaPwvi/2jWMfUhkIhf9h5N+1oiLnyh429cQf11zfS3/z2qlRSuq12+uo3MEvg4G0109dd drg2JITSx5/dd9nrtUEhjKVnCfXfT2kYG7UORHy3bETPUsitogRm4U4iopxgT6LEBGIgtEtJxnb2 IWrd5ZfDPSni1UQvQCE8Vy7diXdyj9poUS8aRKNoEs2iRQR5J4WrueG2xdQSawvfEnoCKj1i4+QA 1rOE2ttNyMSaEibaNNFqMrHWoN7KZVV/awAFcGBOTv0PIR2tMBC1eg6lVtNUUEdhj51k1bssroCL ck3M2QV4m5XCWOSsPEhffAgB/vC8zcbbOIz0xAZgT3k8bEpPp/Q6dSjF9+BlssFGpRLWeusTVtq6 Hy9DNqyTTTKHS7g2bgf3BsdwT+MnUBhHsAS4vuhaYjZtP3m66RRLLPQ1p4gsTf7V1yQSG1TFsQ2/ OLSh2EUiF9L2M5BvmhLATwakhySHFpO0YpRFTVII52hLTvAO4fKhOVTnzemHphNCj1Mk3IQrIrj4 RiWjhnCHabSJEHdF0j4vKzW5ctZDO6zkQZCcxlCFco2lylJtHmYZbqmx1FpkS4NltI6LGiuNuz1d cSYPV2JqmneBZoG3Q9PhVVVqyryjNaO90zSqEm1VrbJIx4bj4WPqhg+vrQtWZTV/v8jhyTCRx7mv OQZxLCdzNDdmkDGARUE2SAXH5CwClSXZzHK2nCofkygvL0kEK8fIJLP5WANuGFPf0CDXB4sSan+0 uCjf51VjTWGVnEJj1IUS7ZZ0OlpTVVkZidj1JrPodMiBZIljvYNynI36/GJelKSj66NU9GwdSoj1 dbLJUY/qDtYdqaPrhPOIwkSENhzLCeexmv6oT0hXrAuw+P3GxmHo35LSh6Sa2n9OyFCDkOFQhIyh wkZO2hDzC1yC3sioDJECJi+AVWpB7wzgfFVhALuMbsVwiWNsTZZ/oaamAUL9CD3SZ75EDFyazPvw rPdBqHkzJ3C243bFSqkhPXDXqXuyMelJF8RZwtVksyu0KqsDnFMBhsj+oaESTGiIBPPpJa0jFkjV q4fPrjxPkfm3TSwvXjxijAJOKi2K1zYo2R+R4LycVjBt9egxY0anLpjVu4cwReo38tTRzb1vKvCt DTN8BYuyiQEKAoU2g34wHbA8H1XiBfKFj2juDzxSTEc1kUCK6bBd5r7Us56/1n0bf4d7p2YHf7/7 8cQezVPmXfxu9z7/q+bTpXY9FnAhprdab3dTVxZvLN5W/Ih5Z/ELpW+Vflyqzcqz7kgiJ89yPpuz oFJClQWYLjfq4iDFHJdn4evzkb5cog06CcXZ+Mo4HS9IGY35/HZW8mlIgQmJokTQ0SLhhFQvTZLm SvdKT0gHpWOSVnJXO28pkdSkvE19r/qg+piaUQtVhQfOaRo4NqH3pHJAlkVfRd8gCsepRJNiFjud M5PjrHHcOlT3BzQRcmhyEHDgB1SR+Rol4RIyp7s5bbG23zbTnrPm8Io1xw9VbJlnFQxqwk3KsUdW QnI4k1ksyIlDWYGo/9wjmrNYKwoOPfPJN37zyPF3hl8/af36BbtEHevUmxdun3xvV/ZQLfXr859c MvGyVcsPLFy79e62K/Za2OtHLx6md4GybXEX3rOw96giJ/3eyk5KTblg6Yy5hMIdBAq3BbSbJNWz DxUQfDbVFxC85o1KLE8CPr7E9qCNOlSBC/nCSHFBYUV+cli4PlJbUF+xjF8WMiy24ZCt0kbF+EkF 70Xeq/gi8kXFmciZCu3wyPCKZeFlyZ38zpA6nAyFEKVVlBtVQqdSaXVBSmFquwlLC5CHGtl6Esus wVI/gMkVlSv0s6RkTEVJSXlFsKgimTVHGMyJnC0iy/RsWZ7nuruf6cWjJP+8goI5kYKCaCQYj4Qj 4bCYrOCTyYoQcD+biEI8QiFkS4Z5VQjnWKE6moqXp4qK4nHKkOKsSJvClJ4nqKprA6azNRKeltyP d6AI5JhWVqyvoMSKkop5FXQF0cJ8VTaEOCzqV+rW6yhWJ+pKANih69SpdULlAXwPWp9lmIoGXJM9 sCUgyOUQKcyT8E9FQyOGdogU6XwDUxxTSJAtc7TbX1Nv64HYW5WNhbJs7CxS4i4+P3cg0og3qID1 moH3qn7BDma+Q3nvjxS9n68LwtuPqmvMbE1NH6W2ZY53u8MVPFDobou1wkYoNcQ5So0HnjCHMl90 8doIEbYrMt/3m5Fhr0INqDU5V+uH7ohQIfadGhFTagxbh5LOcuuPxAI8RE/E+KkXzlmWX8DNMUUg MJGtND/dg++dT6D01yQ3lf4NvjS98ZweePa/cTx7KsS50l+mG/soKl4N1PRp2FEOlRUkRi9aJxcG hTJBFqYIC4UO4deCxmZiZ/J80KQ26maqVEGjwyvcYbcHvfQLVA++fa9XbTLqET6A58L9FOCWmWFU on0Sj3nBd+G6AYax3izLrf8e8ANm/mgNGhLDBDdheyhpG3I8IvUfj2y+ah0epxyIuJTBj/vO73EH VNb33ktfmD1BzbEJGCqhFQdgZDzQChdqkisW2Ffbf2WnLTrjTJYFsVOrmolxUMu57HdYrUEX0mlh HKKVZSexB1maFYSBvScd/xe9/tke3zq4v9+S/vY5DQxQ06Gv75BzNOhrBXpVjsjGyar1ql8Zrynd Yewy7o49Fzsa0zu10PeXSd8rilEpLu2hmL0IBYthJD1Ylt1kNOH8IIo0FUg+2M2iUFzkUsOwgj34 RllfieJYdB9RnDDukE0Ju2xfaX/DztiF5Jp9+DWUHewExd5SA4oCjLimhpy6955Q+MvggTcNnAFi Yy6MebyF3ngAxTwFWXMJaNo/mpnywTbl/lNNxShvz9WlElhB8l7lKOXVvSTc++jNl20ot7t4re03 S1dchm9QxAdT73mDhYN1y7Y7tA6Oc9LO1tHr+uyJv0hfzVwN8kIeKsd+uXQ0v5KnPpDejHwhnYic kU6H1ZcULC9amFhYfoXpqoL28hsL1pffU3Br+c6CHeX7/eYsC1iguMLkuADyx0pdIusUrVbW7N9S Kon6mIS2RDXaFKXGapzvE4GW6lmFggLKTdLN1T2hO6JT6dzJYil7VNkZYg6GjoSOh74OMSGhonD+ IBOjwvbJqSUsBijip5SDsBM/dRLWNOTA6wDyZE4jd+Z0V6G2rCfzQ5dfi3ogFdeWkKjAWE4yixyJ nsxnA5XqLK/HyX5xj9eYqdA5S0hVZZLIAVSygisvG+gkQ1+TJUxh18o5ExQz1TfjLstzbHjrsTNn Hntrw6s33fSnP91006vUy1sVUrRv6sj4xflOm82FLzi/cMTZfRjv2YNRevztrx3ecvvhw7AXqjMZ 5nbQR/PpuPxAviPPeR39iOMBZw+1z7HbqUUUS61z3OJ4wvGM45gj7dDuoDqpIxStZbR2F+Oy51MF TL49z1nNVNvHMmPtM5gZ/Ez7TGFm/mJ8CbPUvsS5RFiSfyVzuf0ux53OB6mdzB/sO5x7qANMj73T +aTwZP4rjpecf3Ucdf7DccIZMzg8jhgVc8ScG4QN+Y86DjheVL3If+D4FH/q/IE64/jBaTXZFHbP sgmeZW1ALHm7lEey4ivDGIXFsBymvybQjvAbYXpleH2YYsOTw1Q4fHd+OJyXH5TykVFNbiiYq1un u4WgTACQhv5Kh5/QHdQdIxlYp7tbpdOpgQarGNGt6NY+X0Lw+dxCUBRcd1AOp9iTGSeX2Rla5FUM I9p53m7n80F1dgkgYAgUpmgsupwAOymawrRod0ANB3UQH0dO3AEs/jhRIoGMhxg0FWN6KqPPS0nu lGhLmdQpoySKJpNR3ebCrucFTMhKFG0R5JKkIOfHKgQ5kgeBzw+B4IYAWKeQkufl4/wD+CHYh068 SXY6plFy6bAKitSjSD1KZq0VwEwekk0qcZ4d25/nmS18SkWUlJIkibqrh1UoyVg2CY9RYmhBieF+ JYbGSCxzDmeFSrYn16luUVFINUlFqZ7GH6GCAXr/901N/fabUycE9kSTm+0liV7XSYHtbXK7TmUL T58khchVX9Mn3CgCzuka9gQBek8RO4EWhBSIXecAEmctB7HYvxZfQHFs/3HejzMVG8K5M9c9+VpB y7Dn3FHwKklD03l0H4HNbWObrdxmG5JHX790X8/SxwvIXv2EBJfc0b2o55ZlhDudJPwqH1NeIPsD 7AyLKb73C2rrOVsDhYpAC5sBHMuL8nF4V3YPGPq3gNehyLdCwi4IDpAX/BoaG8SoscnQgxfuiUo6 UcLEZbCQ9iJEa3QGn2QBHYhSuwtDU5ERcJc4V1r4Nv4YT/NCwUAngaw6dKLPTaC+vgbWyAWrIZxw nci6dvz8GcEgYilPXabDJYaS8Hn50/MX5T8cfCD8JN5neMq/N++Q6lXtUeYD7QnVZ1qrgynFZapa QwOeZDjfPx1PUzVpmgyL8GJVq2ENdaX+Sv/awA3+/YGng3siDlCvv+4ysPlAYHdlzwaUw9ZGbAWW h7LOBfahIuBgr4K73unB6vQ/93ywZYDQR//2/dtue59czCe9b76Y/u65Q+mvX3xggJj38r1/+9u9 Wb/DZpAnlgENbaBuk+8IWAMcxVVbZ1gpD/EBCATn4eVcm9QWmtfwPH6efZ17XXot9FrZcxXPNVi0 IC/dFaRRGeYarFxDiA2GWKmivAxLFWUhlmNFXMZjXFbRwHGcKFXwklRBpXDKkmJTeluKS0kpMeUu TZWlwqlQqnBkqiGVTFWkUnJDQ311dX0olFdcnFffqKrowcW7xYat9SxRUjwYq4yS5DAaVciBHQ4f 3mpRtcHGdY8ug/Lu0NY8Tqknbc1rtPgSOfcRlU8Ypde79YXqlPrkfqzpPz7oczI7IZx2nRJYCAi2 CBNOuAARmqzDEgJcVoIUUHrCfcrFniCZJCMXu5GLPQW/IYFqQ06h4TJ/IgoMl1NgIH60GxQYiL/v 5kIk/oj4XkD89y5PTV3OFyFnUSQW7BBbCfezcbiZleFOVg+3sX64h/WbHPVssP8u5TYL/LJ6yh6r y2SpADb+aRfE2TOrrO6hdKw885GsAyXY6jdw9VDrI3kcAFa9w1ln1Vu5uoYRfq4ek6ChymutxyRo qPKwAEHQQOzlmASS3ifWVVggKOMFTx1LfNrKiBMbxFwubujJHOpmeWJROiSbAAjVQCCR4Ccs5ajf 0Q2XOYZoN4PUHdgOOOuZ20+zMB5ExEBK3IGvifIW0Hm+JSRrU3pf+oBiJE1/5XdbbFF8TfqRsA3K PyY200XYg32LCIH7mJSG8QvpWzQOU04NGpZ+KStHmhwa3I7HapUSoix9ha1Zmmd0aGFXrQOadwHz GKpGx+TLi3icQPVoEqJVDrtjurOZX+RoKV7Jr3asdO126qu8lSXjHOMqZztnJ5c5lyav9d6d0JeX WkRPUPEzdzirysSQn/iac4bQ7hgXqTJsYvyRWBXNUDGdOaqdJ0Wj7uGeqKU0UJoorS9lSoVhG9ae o4OKmKj4TtZnz2qy0qHiLEnI4Dkn80HuOvuQF5RXK4/2Z75AvswXexwOp9flGOjdCGpsnxv6IGdE 8gdZaMgBdl4xnQS5kHgfvkscmxSPdNX0jtvnT5ejI/O8mN3dunOy1c45YlMOt8y+eOzFN5Rd+8mG N5iAYuH+R8Dt8kwd0RgLFE2cO2bmlqfSn1881+6wOhNzmkKesTtvnbHzKkxvAg3zk8xH9CfK+Rjx btsgj+IeCv4JfYm+NDJuxmePFc2INVMqg5lxecy8a6PrdrxVu9WwJe/e2Paih/F9eXuog/r9xv2x w/o/xWxr8QMSVcoXAS53eUP+nszfukpCxfszf0P2zA+7rdr8/DDJK8wPkomKZD7rygtK5HCIi+XL 2lBtQYHaV2tTJWrVplAPfk9mCwocbLSW/tBdW++Y5KAcPfiUbCgXa9kP47U6oWzIEVvWcqLY8BIn +3wJTinaVElRqSdgtTNaPyfKyMu7ZVysicuoRBWVccDqk7HHDkGRNiGjUiYx4OBMMRD/6NQMdhyR ERTyEMt82g17HwbyabfTrMRyicNUr3JBSuUCCBMIu5Q83lhvd0F1O8mzkzw7yRu0uRv7z1EBZ6r6 DlMV3KgawNUG6Qy2lkuO79hx/JJlcwqHv3Xnb44OLzD9bk3H7+699LJ7nY+uX//oY+vWPUZtKn9o 3h3vv3/H3IcqksMuXLDxyJGNCyYP/0frtu3LFmzZkta03X//ilV/+APC+DDgBUbfIBPyynrcpTUw 7xoE8/J92J/VaxVvwtKSyCDTNTUtXD35wioSfDOpevhEcoFcMxM45zPMbagIVeHf7UMSULaJolQX 452uutnJxaVrSmlNbHjpuNJZ7pmlHWJH/PLkTckHCh8pPRJ9K/CmeCz6VtFXUaslqisdHRgjXR6/ NrAxfmvg94Gd8ZfFV6STMZP/QOYHpEMW6n7ZYIyxRqOF9enICxeQVpUrb1v4tC6OpFP2mNVu56w+ VzwgFsYkdbAoHgoUo8qoIHBRF1WE/IliGcg7BJb64mKtqyAULSzU6bTawH7qClRE7ZBNCAbiZ8sj XhTF0R7ctGed9xYv5e3B+VAWxJODO4JvBL8OMsEeygcyu8ziBPs1S7FC9bjWAUopyFxN7SeaTig+ 2jU1ygmxIhITh9oEoCAxFhDDn3KGotCef9O1FthX9QDPiq6AUSQum5Lispl0BICldlWIpecUVpQz thGfzZ9zqMgaEzRA2/oWnYrmAQJUKmf6Ep62TTGY7TgnX+Gz97xz7fZZ62+SSWrl9p1t6e8+XtF9 4cNr069S+vS4PlMD/RmhcS/9Yta9ybrtitkJO59JTp3cWj31LuARBH8SgD9JzMnuuYE29To1bTWY YxznMwS9gWQo5PPSOuUsxuKvJ7EcJ16Y0ynKp+PdzpjN5nNXFBOiT5XGkklfcV4RKmQLqcJYNOor CvTgVrnGTeGoIRSOupMoGvEjZHBTBm0wavHir7wZWNwRdBTp8GTdDt0buuO6r3UqXTIaLUZFbBFV 1IPrZEckEkbYr5tiS3BfcV9zNCdUjmvrM3gRq0PO9YYlNl64gMXAeimvYijGPGL8OYUUQ1A/kDMI KclYrK+gPx+YEDEI5aiD9UcLZs3SkKR0rk4uB0+jriNzfnb+AGl4NcnpfRAXubLr4qKS6YDiZZje fW6Z0sdIzuH0+IFuNLBK62GVZsIqSahVroblSZLlkTz+JEI+DyzPX3OrkSSrQUUNHjLBRAt3h2De bJwQfGDtgJfbiJN5zsv83Bz0j3yAsdAqWX9u/Fk0xW9RxYowP4909WXF4xJ/rPj91J114InECTx9 8bkBkguolpWc/MJ4ClEx3ivHKq2wBz118aqi87jz3RfExxRN5iY75rrnxicX/VBoiaHCwngxpqgi cn5/v+ww3WK610QdM2FTgXKA7wNJMVRAiszRaHlhNFpQ6AsVxsnp/f3k9L5cOb336agiwaZkORzT OYfDxvkEzhr0kqyxARRYH9gcoN8I4ECBJxDwenxBj9sdLywEOYz3eNyc1eqninjoRTgU0utAwPLH LMWBYqq4WCcUxaNuW9QtUO79eCaKA87yhVEPUQqRFVs8Ac9xz9cexgP0aW8JFbUWRbn9uA5ZYVdZ 9cQ7+FmZJQqkFSPrJOtX1oyVsULd7sTo1n7/MuLzfZoITQrYm/MBUF4QSDQpLxwBuhP9/pw2P9gP oP1fOwL8X9wEyN0atqaGXIoZWaKHGv37UGPoaQBNh2j6yt5323+nYPWLJByBVyvYjx/CW0co2S8R Crdjy6eBD/GG9OHB5OvMc/2HABuohb33EBv0PpBueZBuR6G/yoW15Rd4JpU3lV/muM6xwX2D58Zh d4/Uny+OGUERZvbwiD+MfMt50vmdU+Mh5NnmqiR+YY0xuaA25XZZVDzCVeaykhBdXJF9m1KI1tRU WCMNIOMWb8qriEgNIObmaSVF0K2KkBeJKL97DB+RS6OhqDyirWBdwS0F9xY8UaAqEEbfsx8H+mUn UOuINtb/5lD9OfE39/LQuVeHcu8OAe0hApHiojdEss1KJX5qwEs2OWkmd+SZe8VGEYJzwg29Jbv1 OCdW3ffrTfcXXzBv8c4RMxpPPv/XX2W9+0nJgd/+9skxo0vu+vOcOW8+1snUecmqvO0nwu51t8wv m1IesHp9eRsv3vzqDSWk6FMiB8/5zW9bRy7x292hsWOv/fUzCFGYy3zEuEHqDaES/IhsLA7y4Yqg P+aX/NH9me/Jx4dkc5JJaRuY8dppzCytOgJrQVwNxFwcVOJQBcizR2U98d2Du8NaE1EO1zEMo+UZ XhtlotpC23DbeNts2zLbWtv1tmvDB2x7wu8b3uc+N9kMWKXViOqoYAmLEalZXCitldbmr06sLOkO Hih82/iR/qSRm6UNWSTWyok2PmD3O3xOgXWZgihsMkYMUT0uSVDFcSZfW6CJFaqcarMpXIp6qAf2 FNXStA628t9lR6CWV+XV6kyuD9W1hOuJhSWFTOHT1GFURl4wREbqwSeDtSVmbBZKD+BqfM0ArCAi dW9T74lzB+XK0UUfOmSdBCNxUWJsrMVq4Sy02mgymCh1nCmUsWgL9uBHZTuK6sMyioTztZAZUxXJ WLIESIkBR0x5MirQ5CnuhH0+GbHCQuJVSN7gra5W1FwFqo7hQW/+JCuq6ijFw6LvxAOde31LUa5w 68QHmq9745mHlj9d2VBfsuOtq6ZWuxxWE1dQ+3z6oBC9r23lvTua58+qoWyrVxy7/87/um7TY3/5 7fUt9zYHLQLn1PPpXZ9If967/Ykbf/XoRVXAE95GiH6H+QT5gMv9GWQ9GomUX1L5Al6H0INP7vX5 nnFY7FwPnidzZvMzdlGSllA00GOakgJiD579JE0zKslv8gPchcywVt92+XzeA3g2ciAL5DnswBB+ JVuwyrzE5wsgix8jP/bvp1YgCc+WDSCaYyHIMHYjKD9/gaUK9zt3tk/oJUccNYowcQKxCuVlv1Qc sGqyYoZ1GLG2KAfAQxippbSkHUtJXH7OO2WoGGgNYZrufRO/+cQYxS9dCdMvk/CeeHoGnjufzjv7 Gtms6e/6SeFc6livBJTwBMzcp8wPyIN2dXFaoHA/gGCsRlqdR/YAI/UwOst+6mFkxNtknSLAPwMC PMlRQQ6niPDPaHMfHtFwHn4/9Q6yUkueRCqd1ihQ/AHqGuDYTup1WY+WWK14CWIx+zS1EnnR7/Dr WZQG6qa82pH1TQOE/r+I1ES8UrS+H51GqvrdNajNWFSO1loVTiGmv+R1FkGvFZgfzszpP5Qsma4m 725odYBDBzJXM1bVSHQeGo/Hy+WTbZO99/L3ep7gn3A/4dGch8ZGI+ePkKviRZWzz5dtyfP3lqZK KTw+FB6n1XE+r232OGK4DyaVKJyNfEq015kct9dpcmaNWh65VrUDj9ohF+woEneE8ezxaPZYeXZV /ezquqqKsRXjKzj9bKtutrWOkwvvrODkYJKTHcMBsCTnchi0pcly0YTi2cmi2ZWR2eeHZ49L1lVW nF8xeRweV2HzzOY3u3a4KO/syfxmfgdP83U2IiIYoCnWttm2w0bbnqK+QRegb/CFSHmdOvZFk/I6 6umm06e/6DOukHz4faGAp0+f7cs+kf1rRIlE7hihhvxYJVTyBmYozJ7ut8ar1SHiMmrrg6r67fXn ACAlgEwaegCUW+QQXU6LnCIHPCRRTqtVkJ4RKRfLCVh8guTu4bYTpP+9lMt8WqnlxlK3IiT859O2 Z6gT6R8UYTnudzEWtwW/fg4i+VirhEd9AsO62HTZOUi56wfYMXekr2buohegMvyUXO9CLs4VjJkk ZxInrZNMsvOM7b+CBh3wlnHBpXip9XLb5cHrbdcH91mftu0Pvhh8J2gm30gs46xltqxHqd9kSvS7 knqC/vVAVu4O+v3BoCcYipUSL5ziEuWNZKdsKCsuLi0LxspsuuxnC1Squ7MfLdBh5OaVozJniRM7 E8CzeVvQbSsrDJPc5Xl5iVBeXjgULAwFbWVlYijIh0JBK8eJCPOIsyFcBgUcCJFav4rTEcdTj4dP ud1sSk8Rx9NwqrA0BSzAjPyT/dRK/3H/1+R96IrJKoxUrEpUrVQdV32tUquE8sL9yumTwqxONLWD ytDe/2LqANfTnOq8QVus+L5syB4m/aszpH/XHbUvyQ6trdGyNdoaxYgs5UTOf2F4HSKLSlRr+grB 7zbZHScV7QzPwFMUDe3jgJvli3u/+JWCZ4rwgzW0ycWZ7DrlUGkStStrXDU5NGde6HsrkkiixaDN XEPetcNtskNLYZ1X8FIvUdiA1R4PdngYg1Uxl5gLgHFZQXOLxBQtBOXj/IJ4fn4s7ovoGaWKppzW aBjapyeIAGnQrwkS+NxhP0kHpXKfJPl9vrAHBC3s93p4r9eDPcgWi0Yi/mg4DCh1xV4PHwUNEPSa K2Q9Nuj1WOvz+jEoErIHobgcSVrik+Jz423xW+LH4uq4u5ii/ZyHVLdxc21ttltsX9sYiw3bhKLh l/QbVdqJrs0qH0dpigEqnOzzSh2IEYoUmz11AEar5fPrMW/1QsB6FDtco6KW/HuWln/xgkxpiWL3 lUI/a1Epx0NU1RBDtfbekbWjvKowWWXdP6BalVeVcaXi6ck4z9YO0T0+oV/oV11BRPiQuoX6HOQU LSqQWdVeyHqcug09fos2o6W0T1ETkA6l8USUffdREe8AVyU6+4EU/CHWj1FLLkFUM5/0/mehJBUS mVmxCAI9MgEPL5V1li6HQduF1NwB7EACYrBjj8EgCN5zJsLsTlRER2h9kKHQ9nNmw3MBvWByVWoi uXpv6bclKm/H0++A5B7DYpbNPekxxFQMjxBIVHv0Rr42qCKP7M3Kp559yAFaVBwk9LGWK8zX5V2X f13Bg/kPFhww7i7UmTi9I2msLmQKQoX+GJ/nzw8ZeQMxSJs+4045/pvrdYBs3SeHfPBkTgxRPY1P wAwasAmmevZunU5vdPfg/9qtPJuIcgaYrtm7tR9aayMjTFQbKkJOyPVDfQO1HLbgrX1ma/b70+TF kNPZeSLvnvaeIAJZFotQ/wun3kCYczkiYtQuuWRkC1ll7AzwMubCEPQbqnNiMjkdxe2xxqo+o49d SoZBVO578ybna9onS6s1SNNLXatYSI5i9G371MDjV654RFDrjKzV2bJv/j0fRWdfmn53/1SJYN+a q05+2bZ0Un7rg1c3uTR6J1ty/8Xvbxw+f3VH+oPfEUpD3jW8FnTeGhyVq28Ut4pUgq1nJ7H0+cYx 4emGJuP08IOGB8NPqfcbdUzIGYoa80LRcGVYXYmGbUbDhiFfZTJBCEm5pQyXVRaXlSWKfUm9NpDH Ftmw3+mqQ7iosjDgY2nJUxOtTEQrFyeTjE2KmGnQeFpkkedtVGGE0fkXFxcX+TFwrLq8qEUbANwX aje0DTnuUT6ixPa9+luvnB6cOHfsk9V5c+9HDXoZOLffswn20KAToRF6xGa+QKrMaRTPfIYK4MrP fLYn7Ag6Qn3nQv3+jVay74qp3IGPM7cygz5wQM6IGHJG1GfkUmXXjknMOzh3w+GbJ93w5Y2v3qhx mAlVsDqx+s9Xdhy4sBKjDy/45YysxQ7f7gfugbvSdyUrJ2/uumHrRqza2FbKW9z+ZwKC0zettfnm pkvv/vP3Yj6uUryJnISNwIp+DHvuH8A7AugduSjBFKtC5DUWXrQnvAl/narcWMKX2Ou99f6Jqgaj zMv28d5Jvkl+u86i8AdjZc4iLwSUtLcSeb0B5BP6LPSVgyz0efbKnIU+EBW4qOCiqKjWEiUWeIT9 1kkg1wvijccGuRL2s/z/MdFWbOU/4W8oDaLL1K1DpPzjJKZu7zMiDqbGfTz3FMzbl0Axnegfst5M XqjHWrOeejrzPTJlfkB6xBAHD01CYadBvUMR00bZEhYbaNNBhxlTHCWazLzJZDYZKTN2mCgjNltE 5FTTlGgw6nETk7Lo6/VtelrvFhxNbUZsFFxr1g/A8JxPx4n+r4TlvpVF3NuBBWLlBIvKug5TxILu LMrGwBUhfrfL7KzvOzB3DSJMQ6iUcjSGY9iO+8iOBtRJqc/wQ7/du4mqVtCqF1Grer/Pvtw+vre2 Q7HKjqeeW0WAl8iX6nqPMIfTIeA0pt2a2djAJBLZrzANWhTmjjP3KfPfFBCE3iMDLLfNeCPTQhsV TlXVpQnjHuoH2WMPWwyC28dM4jD8s3AJrp4Y6b25T6o1geoMxAAlQIv+0bPowU8uPavgAa2s/wCY erLPnSf95rn+YD31EP1H5i/Aja1o3i6zqoe6DmQevU4HY9W/o9tP3Q984RnZKFoPWo9Yj1m/sqqs +4GrUtQz3Vr8DoJdsadE26aw7rsRBxrV5CzrJtaZ78mJJ6rPuo/XDGTj/YCe8HNRAH6Olyigyy2q mL+k3dFAIIpPZmPoy0KQEZfCPi/D2/ehYOaTbmeAvLv3iZy0CfV7g1gX0pUJIaGsJdRSpp7FXeyY 65slMVppUfD24ANB5p/SDyFKLelCdkkIMX2bP5nb/G6RpE2+mOTziZLPLQWJznF/N0tUDuq5nMrh i5WhPrKQzJEFwUZmyEHq9BvEibYBHCIvpigbPlA2gpgNWhEt6MpCttJoLByNFYrRQrfEcYrNG6hH KDoZGEoPdXAPbM6oFXbbQdkiRRE3ibuFYEL5ADmSmL6yLzYppoLcF7NOsQqNqanps4UOEPsHO8r/ iOJoB/ONn6+Z9Txpz71pEiHfY0Muq6vPKw391AEdHuKOhodmUFveV8jXP4kU+X76lrJ+R7WL8HBc PoWImoquUUax6VH9xpunqOI+NE7n4ffO0TakfE9ShdC+UZ9Pmmup+U6r0yrfU74vcuH8c19XJvtY tRwAXe6798p95Fu6Az7BjNHgH2YOoyUg510N8Ek0Gx0BuAjdim5DrWg9moaeB360H6WQHW1GB9HT 6AB6B/0CVUMd8qX0T/BhNBP+1sNe24c59DY6ATXuQMUg1R6GltbD3UCXgUboCb7Drwp9ibfD37fU bsbIvKXqVl+jiWgrtW/pPtB3G44avjS+aR5jGQUCwSxrJ3exrdKus7/r/JWrQZgkrHHf4VnqecP7 re8Z//uBywJnJTZYFSoOzQxtC7dGpkW+id4UfSz6Xd75+XNzI61AFyj/RQDx92NRgnxbgL5XNQMx kEZoOPUMQrnyZdkPVCv3OZQUrdxlJidtCkyjWejmHMxAnU9zsAr5UToHq5EXe3OwBr2Iq3OwFpXg vjo65KWKc7CJ2kqN61+TJHMiB2NkUAk5mEIaVTgH06hIFcvBDNSZmYNVyKJamIPVyKxalYM1aKFq fQ7WIpfqP3KwDuqcycEmPEGtg5YxQ8OzjJrpCqwiM6ZZoMBqJX+VAmuU/KsVWKvANyuwjsyh5rc5 GOYQ5IcsDHOo9edgmENtPAfDHGqvy8Ewh9rtORjmULs/B8Mcat/OwTCHur46MIe613IwzKHuUwXW k34af6nABtI3Y7ZvRiU/2zezAj+iwCzpm3GvAtsA5oyHFJhX6mSfa1fa+UiBHUr+twosKPemFdhD 6piMCuwjdUxeBQ4ocL4Ch0l9U4UCFyrwSAUm3yZFpskE1ir9z8HKs0xzCGzM5i9VYGUspg70MBJR GSqBv2qApqKlsB9FNAG1oRVwdaC1aKWS0wCpVQCTcD7ktyg1iqFkBOzwVoinQN4SuL8DrVZSzRA3 Q+1LIVwENUkLayDdouSKaCLElyn1lkB+K7S66kfPHf4zdw1XWl0FT8j2Q0RJeAIZhYjyoZUWoBKr oGQ1XIuhtYKfaWf6z7RSDHNy+ZB7sndMRhch8v9W/HR7IqTJ6OfD1aHM1CLIX66M7RLII735n88y aXWF0mL2vmmQaoEUmVcR+tOh1G3OPXkF5CaUFkSl7aW5Hi5UerxC6VeLUrv4f9yTsRBepoyGPHk8 1OyAv1blCY1K+6Iy2rUQr1HWP9vr7KwsVtroUHpJ0iuV+5YrY+kbzQLl3r6RjoaxXgAYlr131YCS lcr6LoKnLFRazM7QZcqzFkL408/NpkndhdDrNcrqLFLqtkG4SClfqeDi2v65zD6rJdfCwlxbzUpI 8F/80chJjVYFyof7CiAmOLCg/1k/1a8VP2r735+lc60vUlpaAnmrlBXOrvXC/vX76dGfw67B/UoN mAMykuxYOpTn9WEGaT871kUKbpCRtyl4/9Mjzc70/EGz2pzD1aEYS2a1A+qtUe4kvb1UGU1zfzuk ZivU+Jdr9LBYVlJSLU5d2ixOaFvR1rF2ZbPY0LZqZduq+R0tbSuKxRGtreKUliVLO1aLU5pXN6+6 tHlRcUPbmlUtzavEic2XTWlesqZ1/qq+e4cPKBp+afOq1dCGmCwuKRHzJ7QsXNW2um1xR8GAOtMH VCkuuzxXAgWTL5owdUA9sWW1OF/sWDV/UfPy+asuEdsW/2yXxZYVYgeUTVvR0tG8SLyoY35HM9y8 YlGibZXYBiWrxIVta1Z0QNOri3+ukbFtl81ftUgc39zR0dq8qrFtjbh8/lpxzepmaBq6srhtRYc4 f7W4snnV8pYO8pgFa5WHjp52wQgoXaUkVq5qW7RmYQfp0GVLWxYuHXAvxC0rFrauWQS3drSJi1pW r2yFB0Av4a4WqLAQajWv6CgWxb6Ht61oXSvmtxSIzcsXkLvOtbWir/ZPdkmpvqhlxRJxVfNqGPVC Mr4Bj1emK9dWSulBfgs8paN5OZmMVS3w1EVtl61obZs/8KHQ6fnZrsJ89k9s25qOlWs6xEXNl7Ys bCZ1lja3rhwyIuAGbcqena/sBtit2ATYuAzw8R8Kne0ry9JussMUmkpvpXfRT9MH4dpH76cf/V/u /L/c+X+58/9y5/+fufMgWnkOJqmWnyz7cFA9gt0DqWgW+3+6zVaos3ZgmvEzpcx45jymFsJhg56w Atr9uVYmQnipMovZXbkUd+LfgRpO1vbn7/lpuM9u8LO//Whq5ln62a5p5XIPRMOVqNscLltPYoNJ ibt05fUjEvSzaCVcT8B1BC4GzYVwXS6HRgEI6+Eiubco5TvoA6gTrmfhegMukrMfcvZDzn7I2Q85 9XQPwvST9N6ucAAevbtbCJd9NcJNd6MMXBR9K70JSdD2xbl4bi6+BeJCiDfn4pvoTV2pgGWEDtIY fQVhBi4Kxra967xJZfsUoKpGAbb15WzrhpzACIHeDr3aDr3aDr3aDr36CkIMrW6D/G2Qvw3ytyn5 28jHDKEpqSDXVA7Y3mVx5HIAGKGnG+npwEcC9MxcPIOe3lUWODhiHj0Nmn5CCXfQUyG8RQnnKuEk Jfw/jV1PUBNXGH9/ArsiW/6UwYyUbDZRk7hQHJyI1kA2YUNq0gqKrdmakUCHoT3puOCBg9B2nGkH I17amZ7s0emUYROdTmL/0GN78ualBz2059566IX+3ktUUA7m29/3vfd9v/e9t2/fLhCy2RUZXZHl K7J8RZaTspxsloUe2qF1qTuE5uf5NM5XnZ/jOWmneIYchp1EXdiz/Iy07/OstO/B74fNg9cNm+MT sn4GdRv2XdSFzfKJqq0fS11FfQYxhv6E38YYbIzJxiQJzzrwHfBEemagV4BHAJdMym3IOCTFU2hh IYeFiEU4tyBJyBgfQ2QU3FFoiyfkPibASqCnBOYqgcwJHJ4EDk+CKDwBHeRxcgywgCmgBLQgzwDa DWBcA+hhgA+SQ8hlsFukBzbYtDpbIwHYAFurBnQrtY89IFNACbgKrLIH1ZbujlQPeII7BEwCM8AK cBfYBFSSbESs/SzJknySTXIfVnfsfiIxLO3xEw37Vn/Dth8c7khd4zFMU4zcBTiGHMOQY9jVZzUd YFg6EbIFPAKeAGLCI5iMCCYjgh2MoH1Eslol7x9gG+BYRBHk381pka11YGhHFuGNwhNFLYo2UXCj 8D6BprKFiE8B68BWMxaSizkkF2cIuUIY7RB0UpY6oHUeqjLxT4C1Kn2nIzWCeZ8EEGRlzGYZ81YW K4SJk3gIkWSTsQ5sAi34zbXOY5AIJAoJQQxIEIIjyAM4encg65DbkDLkFmQNR6Nn09wy2Uz8Snwl vh6/G9+Mb8WVn9gspMRKVhvp7cUlsbtLPZjqZD5SJBr9T+oNqa9JbUl9wDpY1P4qar8XtW+L2tdF rVDUzha1iaI2VNRqdM46YGp/mtodU/vQ1E6YWtzUjptazNRSXdShF4lGfpU6LfWw1CGp++nFqkb2 /UwvEUPFiqeRB8Zn+t9GzUer+hdGTYX5vFG71DCnhfNH/ZixoA80PEca5pDxiw8ZyAf0B6JQ0xpQ /lBmFEs5pbytDCpRJaKEFV3pUbvVTvUNtV1tU1W1VfWpTCWq+HYeyxTv8fa0dgrT6hPaJ8udTGjW ePuaUZWRHPHe5HmWn07TvPfbxyQ/F/T+nQ7XaNu5j7yWcJp63XmSv5D2eyNmvqZsn/dOmnlv39Sl QoXS2w5qHvuyRsmFQo1uC9fNPvEYszqhdOBmua9pHUe0KVR8tFx2SO/1pD/ZPdZ1asLeQ5Waesct dP6d99OJkfR73+SnC973/Y43LArb/U4eMyeeelZnJ9mJjF1nI8I4hXrbKjuZOS/8bau284JHgvDb dWIII3kkKHgk+BIvwEYE77AwDV5A8gK7eJVRI2NXDOMZZ1RyRndzFnZzFiRnocnhDY6xg6M8JYbk GMrTVziB1+Ac3pOzYzbn03t8ZefzF62THH1cGV8Wj4wrhTPzQMlbu/6J31udCwbrZJw+bj5N7khp Dn/nw87O1+jj8LztjYftYCW3/GrcWxbhXNiukOXMhUJl2Zq3qzkrlwnP2s797OzRjV3dffWsu8rR 2T2SzYpkR0Vf2Y09whsinBV9bYi+NkRfWSsr+5KrHstSJWlnvNiw99n+NizgUp/hpHs7r47J1Xza 8N/oe+gj9B7ZbzpeezjtaYAIDaYGUyKEs0yE3hBPBmyG/DdOG30P6b1mqBPurnCa+DOf2thct1l4 zc113cXL7mVXWLm5i0uA/Ei9S9xFgj1ItcufbzquxuLavAbcktdo7rrOYuMGc3eJiGyLQr1I/ry0 hMzU3XVfuvvyS364nzSAdO4SlXevo9BcNi5FEGmIGGQzCyH/A2hE+/kKZW5kc3RyZWFtCmVuZG9i agoKMTMgMCBvYmoKMTk4NDgKZW5kb2JqCgoxNCAwIG9iago8PC9UeXBlL0ZvbnREZXNjcmlwdG9y L0ZvbnROYW1lL0NBQUFBQStDb3VyaWVyTmV3UFNNVAovRmxhZ3MgNQovRm9udEJCb3hbLTEyMSAt Njc5IDYyMiAxMDIxXS9JdGFsaWNBbmdsZSAwCi9Bc2NlbnQgODMyCi9EZXNjZW50IC0zMDAKL0Nh cEhlaWdodCAxMDIwCi9TdGVtViA4MAovRm9udEZpbGUyIDEyIDAgUj4+CmVuZG9iagoKMTUgMCBv YmoKPDwvTGVuZ3RoIDQ0Ni9GaWx0ZXIvRmxhdGVEZWNvZGU+PgpzdHJlYW0KeJxdk02PmzAQhu/8 Ch+3hxUwBrORIqRsspFy6Iea7Q8g4GSRNoAccsi/r995aSv1EPTYnhk944zT7WF3GPo5/RHG9uhn c+6HLvjbeA+tNyd/6YckF9P17bys9NtemylJY+7xcZv99TCcx/U6SX/Gs9scHuZp040n/yVJv4fO h364mKdf22NcH+/T9OmvfphNltS16fw51vnaTN+aq0816/nQxeN+fjzHlH8B74/JG9F1TpV27Pxt alofmuHik3WW1Wa939eJH7r/zsol5XRuP5oQQ/MYmmXO1pGFXICtsmTggrwHl8pVCXZkza3IAn4h a+6KNTV3w32t/8r9N/CWrDV35Bfwm7LV+nsyauYZfXZg+lcOvPjrPv1dDqa/ewXT363A9HdbMP2d 1qG/q8D0r5Tp79BjTv8Knjn9C3jm9Le6T39Bjzn9S+QK/Qv0K/Qv4CD0L+As9C9RU+hv4Sb0t7hD ob/VePqLxi/3jx6F/gUchP6CXoT+dgOmv1U3+hcaQ/9C69C/Qrylf4n/1NLf4s4t/QV17OK/0iFc pg3jiPfyZ8xNew8hjrg+Kp1tTHU/+L/vbhonZOnvN6BK4pkKZW5kc3RyZWFtCmVuZG9iagoKMTYg MCBvYmoKPDwvVHlwZS9Gb250L1N1YnR5cGUvVHJ1ZVR5cGUvQmFzZUZvbnQvQ0FBQUFBK0NvdXJp ZXJOZXdQU01UCi9GaXJzdENoYXIgMAovTGFzdENoYXIgNTEKL1dpZHRoc1s2MDAgNjAwIDYwMCA2 MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAKNjAwIDYw MCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAw CjYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAg NjAwIDYwMAo2MDAgNjAwIDYwMCA2MDAgXQovRm9udERlc2NyaXB0b3IgMTQgMCBSCi9Ub1VuaWNv ZGUgMTUgMCBSCj4+CmVuZG9iagoKMTcgMCBvYmoKPDwvTGVuZ3RoIDE4IDAgUi9GaWx0ZXIvRmxh dGVEZWNvZGUvTGVuZ3RoMSA1MTA5Nj4+CnN0cmVhbQp4nNS8e3xU1bk3vta+z33P/T6z99wnc01m JmRCIBvDHZEoiAkyEgQVFUuIiKIiab0gaCW11oqtQi/ePTUgYFBbY4u2tqXS1lq1x0r7UqvVtLSH etoDSd5nrUm49PzO+zn//rKz11p77dvaaz2X7/OsZ82GvhuuQEbUj1ikrbpuZe+9ex7dhhD6KULY tmrjBsX1XskP5aMIie9d2XvVdX3PvhtFSPcyQvyeq9ZuujI6d9UfELL0IvTA3jVXrFwdv+qEBaFv x+AZzWugYmBskwjHy+E4tua6DTcNu/9ghuN+eGZq7bpVK4f++nkBoceehPMPXrfypt4n+Ud4hB7X 4Fj53MrrrnjrthuscNyDkPVI77rrNyBoKEJDRXK+t++K3j+98WkBjjuhDbOgDsNG/oxQFMgxw3K8 IEo6vcFoMltkq83ucLrcHq/PHwiGwooaicbiiWQq3ZDJ5vKFYmNTqVxpntJSbZ3aNm16uzbjvI5Z s+fMnYf+//rH3wf7+SgMe4B9AMFYjv8O9mOwfzQ2f/wUfy2Kjl0zfpS1w8X/NrEjFEcPol0oho7j RvR9NIzmo8fRDNSJHkBz0JvoOWRGm/BPEIeiaCZ6EsVxGDFoNnJjHu1E76LlqA/9AR1FKbQA/Rbb 4DmzUC9yoer4x5AuQHePH4Sr9KgDfQe9iNfixagA5blMFmfgzTvGh5EbpcYPj78DR4+gP+DY+B40 F0ofIitKoi3oS8iGrkE/Hj8FLY2hy9ET+Fb8MVJRD7qHK3Pbx69FU9F+9Cu8AEoL0Sb+Hd1+tBbu +hZ24+HxD8b/iL7HYXQFPOkL6G5o8V40zOTZDn43UlACTUMXoJVw9hb0LrbjRlYbT46fN74Tap9A f2MyzOusCO3IoHloBfoi+gb0xtvoGPo7NuAKfgQ/A9vP8Z/5d6BtC9AN6GbgrUeg955Az6KDuBE3 Mm7GDb3lRml0MZzbgR6D9z+PjuAFuBsP41fZx/jiWPu4Y9w5/sfxcdSAuqCFu9Cr8I4TuAjXwBvY CLuBC3Eb+KbRz8MXrkZfR0fQz6Edv4V+/zv6B26A7XfMbcyW8UvGnxwHDkUSCqMWdCFahtahjehG 9E0Y1e+jQ+iv+CSjgyvf5F7jb+aPj98PfZtA50HbF8HVi+HZ98Ao7UVDsL0NX2nFCnxFC74AX4Sv wjvwg3gIv4vfZQRGZdYzf2IH2Z+w/8418/x4KzzJhULw3ii6BK2BEbgNevt++N4n0WvoDezECZyD L3ob7v+MmcrMhO1bzJvMb9k72R3cKf6usaNjn4ydHN+ORKCyOdAPN6CnoRf+gl3QhjS+Bl+P/w+0 fIDZx5pZmY2yFXYGu4TtZu9mH2B/xP6M6+Oe4d7j5/Er+WfElWOfG/v5+ILxOxCREgK0K4myqIym AP1cCdR0LbSvF7Y+dCv6PNqO7gN6uR/tRs/Ad7+C3kC/Qu+jT2EEEFahzVfD268DqrsT3wfbTvws fhW/ht/Av8OfkY2JwJZimpl2poOZzVzF3AnbA8wR5m3mIzbArmK3sP2wPcoeYN/lEMdx43wTbHP5 e/gnhJ+IKXGueLn001Mjow2j3aO/HUNjvrFLxx4ce3Xsj+NLxzdB++Moh/LQ0q3Qyp1Ag4/B9jRQ 4gH0OsjuX9O2/g0zmAeK9+AoUEMWRq0dz8HzYFuIL4TtYtguwctgW4kvx2tg24L78Rfw7fgO/EX8 Fbo9BN/2GH4KH4DtBfwibL/CH+AP8Z/w3xggYoYFao4zSabAVOFLO5g5zCLmItiuYtbB1sv0MRth hJ5gnmcOMm+zdjbO5tiV7Hp2J/sd9vvsW+w/OYbLcgWujVvKXcXdzr3J/Zx7hzvJh/lZ/Br+Uf77 gl8oCxcL1wgPCc8JHwmnREHsFC8XbxXfEselOEirH8J37z9H5BWEN/H1vIO7ifkA+MLD9vJb8cXQ YwKzhF3L3sf+gr8SH2cV/B7ezl7NXjv+LXY28w92HV7KvIIjbJhvZa9E96Jx/AzzO+YE80fOiZcw H+MU9yX8ArOO7WAEKld/yTm52/mPEGJ+jVqZzXiYeY29nb19/LuolX8Uf8A/yvwcKdxRxo4+AK7e ynwVbvoZczVzD+riyvxJdDX0+1P8TdDf05m7cQP7Fvco+gMbZf4DH8cPgtQ4jOdzMeYypoqfAYk7 ikNoBK9HvfgrSMMv4ffxEML4SfYJfD5jhNEaZEx4Cqi+w6yK32L1qJu0EScYJ+5kjjMXsy8LR9gK xiAlfoFuxiwuAu1M/o2hzwEHPMAkQabNAmnyS9yEPOirIO9PjL1MJDb/Dn8P0Nk32Cy6CBVRjfkJ agXe+ANsXegu1IReBBq8GxWZh9Ct4/14Ncj9hSA/GTSEr0EFbABp6Ya2bQF94WIiIAtXwFv/AfL/ xyD1F+A/oxuxApw1jFIcOXMvNwskUw/I33tgW41qcPR1dL+wn/8lWoTdCHHK2KNA5f+OLgOd83/g /T7UBu1bhr7BZaHVCkjm9XDH18fmIg22u9BPMIM2Q5unA593cnNB8j44fg184dWgo84HnfgGunr8 q6gDxu6i8dvH70Erxr8xvhxdhRaPPwnyd+P4XtSMtvLdzFI+w5VBxr6BD4E++g2+B+T2XPQeyKM4 9qA/wfYdaP90/iW0nfs1yM728XvHf4Wc0B8R6KHLQYseQ9ehP0O/zWWHUWnsAmbP+Gy2FzTUB+jC 8SfGw1iP1oyvBcn7MnpM5EH29KMQ/xjQ7j3clUwR2ptGLlyA2uX8LoS08y5eorVPn9Y2tbXaMqW5 Ui41NRYL+Vw205BOJRPxWDSiKuFQMOD3eT1ul8Nus8oWs8lo0OskUeA5lsEoOys6u0cZTPQMcono 3Lk5chxdCRUrz6roGVSgava51wwqPfQy5dwrNbjyyn+5UqtfqZ2+EstKG2rLZZVZUWXw8MyoMoSX XdgF5S/OjHYrgyO0vJCWB2jZBGVVhRuUWZ41M5VB3KPMGpy9cc32WT0z4XF7DPqOaMcV+lwW7dEb oGiA0qA72rsHu6djWmDcs1r3MEgyQaMGfdGZswa90ZmkBYNsfNbK1YOdF3bNmulX1e5cdhB3rIpe Poii5w1aMvQS1EFfMyh0DIr0NcrV5GvQPcqe7PD2e4dkdHlPxrg6unrl8q5BdmU3eYc1A++dOei+ +ZjnzCE83NbRtfXss352+yzP1Qo53L59qzK4+8Kus8+qJO3uhmcMMvHZPdtnw4vvhS5csFiBdzF3 dncN4jvhhQr5DvJN9a+7IjqL1PRcowzqoudF12y/pgcGxrd9EF20Sd3r82kHx48i3yxl+5KuqDrY 7o92r5wZ2ONA2y/a9LxXU7znnsll98jWerfuMVsmCkbT2YUrTp+jJXo5KS246HS/YtKi6Dwgh0Fl lQIt6YrCN7WQ5IoWtH1VC1wGf90Y7hpcDeNx9aCuo2e73Ar1Mrl/kI/LUWX73xGMf3Tk03NrVk7U CHH574gUCZWcJjQ4P1kezGQGGxoIgYgdMKLQxun0uJLLbhxiBqO9sgIZdB/qhL5d2d1agM5XVTK8 9wxp6HI4GOy/sKt+rKDL/XuRVsh0DzI95Mzw5BnnxeRM/+SZ07f3RIGO91E7xTkoJU7/W2SXfdaa 1kHs+n+cvqJ+fsHi6IILl3Ups7b3TPTtgiXnHNXPt5w+N1HC9RPQ4YNcHHpqXhRI76JlXaQC/vn4 7Oisq3vmAqtBGwftHV2sn+mulxg/Sx8F9Lv89JPJQZeRPIuLC5T+Vw+JEhAwrcHK7EG5Z2497dar 6v/ypqHx4+Qump25beKbBlsz5x5PPef4nOYZt7PQYC7BLFiybPt2/TnnZoOw2r59dlSZvb1n+8qh 8f7Lo4oc3X6Q7WK7tvfO6pkc/qHxF+/xD86+txs+Yg1uBdJm0Hl7ovjuC/do+O7Fy7oOymCK3r2k ay+DmY6e87rJFzIdS7rOHgNK2N05om0ZHAD0EOCJISuihXsY/BLzPcCjIvPKXsRzQ8z39rFIL5LC foy8ksC/AucZxOI00uFr8WXIk5E/axttu0A+0bZwtA21Q1k+BUljUbWq1jgkOMChUwo7fErj0UlA IcNATiroTWIF5nDDnlRhCIe0KfHVzTpOpx8ssA9lXsy8nnmX/WXmY+5j/UnupF7Xy/cKW8QtUj/f L+wQd0iSqNc1MKJqNA7hhGaS/GIw7HerEUFlGFKT5v2COex3qdFQ2J9Qo5lsSi8ZOZ5hcNRoMrlz KJpAKTnFpIaYX2rxZDLBuNxSMpN6FqUxShfTWro3zaUHBCEs4kUifkXE4hDer+WRWbDbmYvNRouF pCYTpJFQ0CjLzMVBWhn0kcrgo/mVqzwZ6JZMJgM9Q9ITtfV9bfJntfWjx6Cf2tvkP9fk0TZbtQDd ZbVV4R/DnslgeeRTJI9O5o1FtL6Ga+sz2Fpqap5SskbzTDRqdbhdblep5FQrpSZQt9ZyMpFMRKMV 1U7O42/958WLTPE4Ts6a+Z8mvZItNo6+WFyS8Jj04Uxjkf2rKeqbdcU1PDP6yYJ1Y5VF8+NjS69S vTZPPN6o3MyurZfH3l7RnSIWiglI5QX2OZTC+/cwhJ60VINGOkIIu61Jjnx30hPGVol8u5UeWwWj EdLw0PiJfeQYCp/tI6eh8GfNSjos7LDZIDWTB0HtKc1AL8Qy63F5X2J/D8Avwf5eMy9KrktuSbLJ lOgxgrnbfrjQ/n5tRB4dhu6q4kKG/r0P+7B86PWMfEg+1FjM+PcItKFR8rgE3LtOt0XH6OABHgFa CkMnQEtlWaBt/K995BgKf4LG1gsvkHPhcEMa3lKovwCejwrthw/X2t8/TN7dWPRr6xRGsTQxTRaN 0Sxf4EStAa9owOF0yJOMWNMh913RZFKZkQglZyK9ocHqUGTMefp1WFeVjdjYzQLjedz6FQLWBCzk w2ArI2ssHA4ruF8ZUBikyMqgMqwcUXilJ/345yhNEUJaCLQj9x1b31enpZG+kZrVTSmoiuS/j5zC f8/AQOO+9ajW3Y2dzaUml9MhRCOJaATMFkI+LkI8QDuUehKkPhnH51+/acrccix6idPmzBXtpvOm j2VmR7x6HggmnNRjJ/vcz37WkU02z3KkLxubd37SH4vFXHLU2olX7Z4WsMR6gVTQ+ePH2MXsIHKg ILt5kmIkl8OJjBYYeGSm2QT/OIsaAsxdhPuQTID6+PA+uwOugoJmtVqhhAz+uFVEoiwyIjlN7iaF /eQ6EE/jb9M7oPDjFwhNcY0GA2ofyWQOZTK19hE6gLVabYQQy/uZ4cLhYRi6CQIJOvvBsh5ELGmC Rjx6pBH1N0rkJVqMUIIsKuKgCKPVI/aLu0VOvJ/7JreXY8mrRPg0oHMtQYjI4QiH4DtJEb4WiIl8 LWRmF6kym8OhOkEReqKlw0cOQ1trh2q1TBNtK7T0MCEtr22Fp+btQT2Ot1neqwSqbthdWqAaJq3S d8wvS+EOU62ZHD6fSpVp9eKGfNkveHVd9stcK9zLPJf6RMzqBFEnGXnnPGEbc6+w1bhdvjP4LeYZ z377W8y7lvfkE8x/sHZbj9gj9cLXbdO9Kv7IclyUOCya7mBY3YsAz4Txo9r8Zt1sZo5uUXgJs0R3 OdjT2+zbvDvt39Z9Wz8k7dcN6n/I/JE5ajyhd0hHRIzEIyKznuSk7wag0waB8jZzDlR0OUlT7baq bYVzi3OX8wMn53T6f8lhGMEjex1VyD7aayfZO9pcW5X08XI/JiMi/lRypfxViwuvc21x7XCxrhMO R7+Ei9KAxBSlHdIHEitLmgRfIg1KRyVBetrs5NA2QldsVrMVzZq508wis2xWzOxxMzaTluigL80d oY4FdZG9vq9v4ej6Nnm0tr4G2QgIX3kExqiPkFSmzwpD1NG1d50T17ozROGdqAFHgjTANdTSQqR1 R9c+AWGGWd+9vq8unjKoD4DGQSTC2wzRqlHLVU2wS/D2vamqWM8EkvnrR/76uYkjff1IXz/S0SPN rKs6ZW/Vq1irJtgRqI4Mypz1193dbRdAS4DacAvA+0ylbCNyIK6CrgCGF97Dq1dvXXZnLuz88UOP ffLXAw+/ProVP8nL3lXNi29npv50w4ZVNzm2/Q7jdz/B4k+ebu2KtWifBxaJgP7+EPR3CKz0Fmaz VlyGloW2obtD20o7fY8kn/U9m/zY96fkHwvGFnRzclPp4aadpcdiT5fe8b2TfCel51qHmD8+b7mq uZVQbiBSJrn2f5zucklTs5B4Q+UmLZqCxB8sz4zNjG/zvYvfjr1X+kNc5GI4bmqSWafg9zlCrpgr 5Szmm2bF5pcvwV3eZckHGauM5NaL8bJYT2tva3/r7lbJV/Q1dSJWFn2xUMpb4ASGDblDi0p3xx6O vVsSlVattbN1FbOK7eF7BGCD4kbhet/1/t7Qhtj1yZtTdwh3+e8K7Sj1t/648F7hk9h/xbzdkiXs 16kRmaKMUgyxYO5XMuEYG0m3ZEtsPpKqVHSudMrtdjH5lCTppIEETpDRa63Q7DyS9T/fPqNMDp/v mE1zzQH1568IYH2oGGACF3OZcEu2kZyQZ1VsGrebYxAkR0HwUCFgspYRhxXCOfjnWjxL4UmWIpEs Fa/ZCJjZRF5aFHJoebTa+jL+OSCwldgD6C1zwQkCUAhdA7Vnaus7gEgb2dzHfpqNdGfktjZC4X0j lKSIupFHyE5k14jNDbgFdqJ43FWicTo2aTMK5WjKE8Kiz+/1M4KQiMWZeCmR8iRKuCA2lnA0lCix ZdxYYpP+dAkX+XwJxYOREgo1sZUSxkhuy7RlCDlP/DV8Hv4AA+G+vj4EKi0zcRLVUA0DDgLNJkTP QkIEBzWBhoP6uIvQf3OlTBSclZQrVNkJIrv3i7NX9n/wh9H+0sVxdzC5sMTM//aqBx+9dfSW+Irq /V++4Psvru7csH7/95Z+f8f0Lj+zL3Te8juvOHhxvDnax669Tc3GPbEXbrzyGxZRbP/CwhufdJ1c 5//WTYvuX8LxBDP1j/+O4/lrgT8uAUn+lSy2YAtjYJGFS6E0n1mEFzE6a+sQnq0daW5p9rF+boVn hXeFb4Vf4E28GTUMt3IbDBtMG8wbLb2h3nBvobe4TbrLsNW01XyHZWvmSe7JkmwzlUxlUyVYCpaD lQIuMDlOCSnhdDpXmo6nM+1c0VsMFcNFdVp5WmWuaW7DEsNS0yXy0vTSTDCMw4y/FK74m5d4lniX +LqblpeWl5dXljcvm2JmDYa03eBPRw1K69R0sbXP1mffFntIfKiws/hkYTj1asPrmeHW462OC6QW P1rH+J/Db2IGb8EYvwiSdoFmqjzcGPAH14X9odCLQVJT9j7saABiM5odRqM5Y2wwcwkdzYQoHkVI SDWy0ZRDxzyLtVCkjHGYMAyOanLB+oqV+cCKFetz1g+srHWI2fpC+NlQRgYYRS4I78rjV/J/yY/n 2bw2p6Ll34QDFuWVfDE/nOfyL+PZqIpnU4In8KkGEn7hSN+JESD5vtE+0MFEurePUKp212l5qzmf MW+WD3mQ/OmJEcDiJ0ZoqYbl9VCmhN4cK4r2VMKQ1ZVQ2gLUHbNDIhbhUJ8zlpDBmM0k5YYStpjT DXFbtISkglDCQL5yG5A4Teo0Tqgb9YFW0XSrDFearpJXZbhadw2D+kCA4EB1aEaDx1LlipZqCXbC Ad2YmgIRwUlsgRBD4V1drotRaynE1Gk9mYglEpUyAMC6JmCfidtqzy5fc3dm+sffu2fBX16eWg7/ wOcNivG4r2v/2s1fmtKaHPv2l88/+m9rN7W4faqev3Yss3X3ZVsunF5asPnK6x648OEPdHx7qIB/ fv+Xeu5Y1nRlNvSDDfcuuf+XFW+4QNBfFGzKTaAdXEjFrNZt8BuCd8lfkX8l8xvljY6t8kP2nc43 /G8E35Ilj9XmCIZY0Ym3+u4OMSlJCPuRGhHDfpMadavecMpsNjHelMuFpEDbIhtGNtmm2Io2zcbb hsZ/e4DINNu8KJGF09srgPaVKO6N7o4ejbJR1U2loZtKQzeVhm4Av9RYE2ilQI014dHIfzPWFspA GpnPMjUglDMirzop4gK+kMUpxx2JkCWwFPuckASt4aXYb/cuRROC6/OfR0Ri1daXzhVMCmdzyqKg JmE4EOgqkEvR0tKYK0AkUAoX8bRXn3117IbfbFn6EW4a+9nxZdfHp6jXs2u3KNn49rHv/XLsD997 6/IAkLMbe/HMIOlxoo8zZGYVZfFNB1EeeuPLrZVC/gbPBv+GwK2p3vxXAuImzwuxF1O/8f8m8F5M 8CblfCpRjVeTU1PF/LLk1cnefH/e8DrCvkA6sCDwa+9v/PyTKfzj2Lvu92Lvgtb+JCYEtGgwJYFh LakRHPaLahSUoFONoqCSbQim2qOLomCais4GGC8nI4mSDflk0L2ar9fH++blJ0YJ5bGWH8wzu4A5 jwDLZjEdJ0yHBNNxwhGLmY7ThKVNx8n8aC4/hG98XiWjRRXXv4xWbSHRXom69koQ7TVhHBFdVQNo XSX29cQIxtLugCeeSqTdhHEDkCS9wKpxP7DpmRGct2STJociajg6lYuElKlIVcIIU85Fmc/j9TW0 vg/3gRaqgX3u+FeLnOoh14ThlXSd0T4i/nYgsbA8+lJpadzhh4HHfz3wi4Hf/Kixb0blouCar869 Y0mpk7ll7Ib+cDYebwlvYNeS0oK9Nz9+xDxHr/9Gf9dXF9hBy1iA156DkW9ns3U7a5+VEz3+Ifb3 +4TWKak4FDQ5YVVRnkt4W5gE4wVIjNrhjwg5efTIkWH5FCS4QCwOeZMVm7y6RCu+Cd2o8jawKI5q Zku1IDuq8gwto81gZ5BB3BGOljeim6w3R3ozN+cejuyMPo4fl59Sn4o8FX0891ThpehL8ZcSL7Yc aP+R/Jr/NeVH1eEZv7L9Svmn4fiMgK0gK7aIEsuk8oXCNLloKypT1eZkMTMHmWxohjKjOOPIDO71 HN6Qu7VwZ2ZbgevIdBu7VVYX9UZd09tnLPB1JAWbI49j+SvUx9TH8tyEKRfhfDO0tDWRZ6xIzXP+ OOkKv0/wSaQr/ImWBEN4efS1116byEgn1KjR7NcW5JUCzqlKQY5Y5YitHeGcrV2QRb/gU+ApyVzK n6y2t/qrPOb8vNfm8XsTEfLUwhR/Sy4iyxGcc2CcK7TbbEPMG9p0peBQlEJetSKOJjhSbWkhviaf 1ysIvLSmHbdnEAZgoADXL8c9uBcP4mF8FB/HejzE/JdmmaksVlYrrNKEIrsjTGSI+cEBbcaD6rXb gQE+q52ogQI7ViPfBFs9pQqsrr62mjcfgtxDC6DHQIsN/+9TC/x1NxZRjdg60DO1bgyGKaikjq4D BZyOFKazoKGIxrpaXZ1ZV+iZQTRWBoPGyhB9ZbkyeXUL0+BxmdqjsqnKgEmn2Y3VqMdQzcMeneuq JoouUj98wFWNpFzE3Du611UFU/roAUPVI9vIyeOawVbNSbZqRLFVW4hdaKkm6xkogHcgU+pZpp5N h2yPpXoaOk7+1Q0j+hUIEuxyuYFTm6cQaJhMJFksgB49XTcF40QiWVGdpNZtt9evqteIAmDHmTi6 6YZloy+2Bpx+nVj8cOxYztZ8/li4FJ/eOxdrY3+/7qFVzPWdU4tH/tpgN1ryc/HvqrHmZRcxfxm7 YN8KPh7HBl3c7nZb5+DlYw+0Jp1KAxuP87Kv61L8AN66axUcsflAfM7YG7ixOeV0yk4rhiqL+4Kr CbpsAIm/D/i+hJu1dq1yVeDGwNeKT3meLb5UPFqRlnp7hV5xi7RF1y/0izukHTpdLOwPqpF42J9R o5JGRKukms1hnb/u41BJjagyTFjwiwHZz+Co2WIJltBjmTzKyTkmRzylajabAZzxWND/USAQlHTP SpLwbLu4RWSIkb9IZOFZH2qd9Fkb889mM+FcAW5d63tW8Wv+D/ysf3Fnpbeyu8JWkEyFvkzlu0yF vhyJx6jQj9HKGBX6sUfLRw/irdTRTEQ9lfdy7bPayInasVFQ0DUC2wgLfCqPEh4Yq7WddqsSzqZe 1L9PeFP/TsU/EdfYqhLfV8kapbawanWAeCb4COrYugg/I8Pt0QTxruJnccOGZFmIx81m20UXj70t p1o+vH5NcfqM1A0nPykWM4rbF1tS5JyWpLPUlLqCZ0Y/iuY3jKVWBaKpsRnLkm6lMH3z2LNxt6yt Ytd/PpSKj/362k6nZRI1rYERTaEyw2h7Yx7SB3HaE1sj2HZn4rXoazl2XuyJHOMJu/NXxlhAv/FE fA7qwuuYdbFb8C3M9eHrlY2Rm+Lb8Vblodwz+Jn4C4mXc+Mxp6Dcge+N3ZF8OPYY/jbzeOy53Cu5 d4p/yY3nQOS6sI+xpUBPN7bmW4tXxq4u6BskJhDAzrDfokZQPOVHUthvVqOusD+gRjUmG4/FIgx2 MAyOPcsojNiQfoySkZs0F0ihU+wRWeLyYUTkfzZQHsJf0ixNqWAwwFjMZrDwJJtKjOCuCsm0WYsq SH1OZRapu1VG3S83Y625t/lIM9tcliiZSLQfJEomUsTlpGTipJVOSibORysrD2Iv+hcYJ9f6ToBZ myG4oFDHBYUJXDAhMkdGZAAGtb5CZhQqvD55hIpMQP7YVvWBmKXCMLNV5jcfaix6CHLINYai4Xgu WijhxhAk+Ui2hKKxotJEsP0EpgdE3wfoAHbq94mDaDNWMcizvY5qikg4R5WRvaR4fL9cLcoE0+O6 oAIRlcmoKqag4f8FKkQixXDTBKwAVMGvGXtwrFJSTCE5kDi/QuGFk+BK/Od3Du/41jPY07N93alp 9oDu+6/tur11FXMzg/HYxnNBRvtTN2weSozdcleXkXkAP/mFLbvsROLYxn/Hf4dgTMa2T28RwswE 3nDhkGwCmPGCOcy4RDMMOCjAajuFFnVUYbTJKnZJhupTLkxH3UNH/flSpUzzbIHm2u1KtPwftpPh 4yr7ovug5yXfoPpPkX/K+6zvZf6AcFDkn+afEJ4Sn3Y+4eK/Jg5YBmwPuwZU/mrnavcGbpO+X+WX uS5xd6pXCFeL/KVit3Sp/jJzt5PX1E60hL2EXyzwilrmWpyz0TwzHxfSYkpKOVMuHkCdWlR71CMq P4EkAsisKnqXz9XgYl2iiXyi3wz9LUphM8EQ7bUJ+HAaPTgQj/0IjAK/xSzBxWF3yA/waatmdYmC IokiUC2IGCcvCAQcVFxuOHKHLcAOiBEF3Uk3dv+x6NJcA67jLs71UdGpOTudg87jTl5x9jh7nf1O zjnEfHJAUSf0P9ixXpCBNeRpn9D9W/m6zQq5hxYy/6PWB80O4PXMH6U8or2J6tbpPbaqRbNRP+wB uSpJduJ4fOeAvapP1d2yZ6nYbqBXTNSiiKM4kTxLb2JcN0CTFf47c+OV9FgyPsYlZe+86UzDZS15 3I21Quss3sifHzepjVecvI370jJHOAraUZePNV1z6g+sdUMuWDFgJk4okEjIR4ACZ+Eb67T3whyN 8D6KD41/tp+IiXiZTCPZSLFMxUKZioiyHS7Q7KTajiNGkkeoKIkQUEJlSYReGPHNkNnfoyDsWdgL sOeREVId7O2wtwGcNkxDsVh+GpMP6IEUCoTaC4dBjnz6KU3qE1LDhzP1SaNhMhelre+ds3vOkTlH 53D2OY8GtOZOKDK2sN+gRiJEpkbKYX9ejcwK+6erESbs16tRe9jvV6OgsHNqtBL2T1Oj0APRWMw/ fdo0g0HP5HO5QMAv2ewRRovgDyJYiRQjvQATj0SORgSAiormk+f0zBmewypz8JxZ8Uils9xTZsqP zl75757MQvlEH5myldf30fkkOnl7BkbW9eckeCKubYqd1DPzjE4ykSQ4/9tEpPo/T01O3IIfYzaa 9EqmWGRmUqVp0oezxeLoy8XFCe/odnqqcfSlielKOMPMgk4Me5hf4zvW1Ccp3fKM1ae+cmbGEj8y tuqs+ctrz7qM6Na5ILtu4q9FRuRHe7TGr9qeFJ/SPyVzN+JN4lZ8t8h1SKYUYp0pQedpC7MFlkGs zCpskdVYnp0XJNLJ115RglqQCVrbZJ2iYyy6sI7RzQusrrsOiKNgobweUDn1GIy0111ETdhviRsS voQ9YTZac8iPPTnsEKHk4qEk60057GUgsUnOHHJzkEw6N+uOIQDdWCFuApWkU5qJB8MqE1eOzSqD LTGCJXz72M1jn4x9NHb7v7/ynwc+t+2+655/5Z/bPsdfO7Zu7K2xn4ytwffhNtzx0z3ztj459vLY vufvxg14Bl7+zN2Eq/zjvxM3A1dV2VCdqw7ocEs64bAS09ECGDzJBHRFP2ewMQYJEXJ3V9upeD8t 4L06wSQaJb1O1OuLQlW0mT32qhF2PxHvkq7sJ55uyAOQax9BoVlXKczXdXNduid0QkLISFlDypiy p3xpf0Mq2dgsVH3l4hxhprjAMNe/ROgSu6RufZexy9dVXNJ4tbBaXGtY41vjv7a0kdsobBQ36m8y 3GK8xXeTf3PgJuWGwp3cvdL2wN2Fu4vbGu8Xdxq+bP+yZ6fvIf8Dqa8UHig+KT2te9rwtO9J/1OB p4NPFJ4Xn5de0A/59hV/WPyn9E/DqeA/lflrClcU1zRu03Et/rWhdeHP5bgrxCukNTp2ge788NzU ggLX7b+kcGGR7RQ7pWUGlhORnjUYAq5CQyAdbhSrBt3kBCOyTW31F3UBzmCt96zfJokGbJCqSRtR JqBN6tZo3R6dUChZXSAg6XR6YPJgKCQhAdSL3efw21OFtD9lM8JTkqEEmKSNLf7q0Hjv836DHkyh dZqjKImK0WCI+OFqvy8QCOn0eqJznP4AVAQKQUmKFAuOYrHQKIgiORMoNsJho92WTKWqVRtiDHq9 JIm6qY8KjzXCmO3VKo31qQs6FZHIFcvFxv7GgUZ2UeOKxp7GXnpwtPF4o9T4kfRH3UUG/36f4UVG QT78X5pBM3YajxhZ4xOtU4eYa56fNF9HjnnlYx559ASFaJnRD09LIJrV9Rk1YvkJI7ZekDafpeH+ ZxV3dirK5jYJNlFuI5pvUuuhGnX1ALcRtedIpcBYDZFEKUIS9tgM7XVfUDcRfs7IhJKb0HN1iUYV nT1JZByVc2cqJ7RftCJurpwXcmTG7koBNx6OjV2XMzpmTcWfeSotWWz4XUoBDGv3eu1pRo61lHOY w0w26EpMA72YKEfvOPkSu+rUI9yVt7kT8Xi8GIneNioyW/subUrYTTYJrJFiurRlNMx8cmvRnZLM VFdOB/twkHoE/6q1LsPLmGXBZaFr8bXMtcFrQ1JBbVcXqQ/xX/U/yT/uFxkcDAG0l9WIjiD+qOiJ AsyTLZI6xAxrdh3OIM1tbrdZ4HGd6DnEoSEmpfkkHcXmOqo6dVSh6iJuVzgTorOT5A4UkkMrQrtD XOhFJoVc459qBqJtXVQ5u+Dpzyura3XT7kSNgPQQUJmhQh6w12ApQ8dnjsltE+EzxNeANEMF9slT H1IHH1FUWH5DfoNOwdawvW7TRf8FO1PtI0bt3DcsCYM9fNWSV/yJRYXRV4tLY65vrUiV54sJmT9/ 7PtLYq1TTp7YHG6Ix8tKH2c029cux9OJHonj33DL2etptNStewRxiE0e4BdxKziG+x57PgmMYpMk Wg6k3NTWCkL9iOlEJLzgCDqKeCQIPM8wMsZHMC5iDe/GLMIyVjCLl+tEjmNZtFzquozGVFEO+KxG Y4ZgQ+3AI/Chn9VocJVdddItzk05+QbZ2esvOnERNKANminy9yEDijDz6vL8IIrBcASpp9xEI3RM qoeMgkpNTNXuYXVD43/eR8cSLBMapaMjMRV0XIfGf3aAXK0zeUgsD7kKCr+nV3nI5eQqKLy9n1zl UYjacC9S16lbVFaNrIPu6BGwoFF3OwzrCzRsKCLYwUx4O5OpHa7J79cDMzKZw/WURPFk5AyYW/h0 GI9JsZEoDJWm5Dn7FiyYKMyYUS9o3ilThIs1ASNht8CQlyKkqBHRTj7vMy1A7tTpYlETQ0omhgRl mGicBvmy4/tIrYdEKZETpOYFcs7jiUUnIoAOw16P2IC2v3+4/XCNzu6TZgLE8w7EcE+sNzYQ2x07 HuOVWGeM0UgSI0qwqalM85bWeg4SlObROM21vNdX9qRD9vkRUzpkmx9Vk94ZSkidafQa7QPwKVWE IkbRbtMPkNAhlvBHR4VkmqW9wl5rNJq8pphHy1Q9FKs0t5YHPLjTg3s8vZ4Bz27PcQ/v2Rvd+y1C W7TZI4SswFIeqQcQtY/0EV/JmcChCXfZ+hruA4A/GTxUKTfbqaeEhA5NOEgmIofSDVOnNjS0Tb3N 2zhjrKMj79eJIV8gZcYO/j5yoq2hYeqYOqosrQZiMV/bxXjlV7KKlwQMYbR6/BjzK/Y51MiVJ6KF kiUaX1bSDAbmYgZTesWUXrHF75OSRlKfVC2EAMk5C4m/aSLnLY2ilLSonC3D4008XstjPl7AGDeI 3htDeFUIh+KKD/f4en2Mz2ZA7YdqtZFarQA5ZDUCbggxAikefuuw/BaUAHueJsMm1ZKUuAZXyJbn mYZGsf4Yr20Bj6/lb+EZPt4gzgzh1aENISYUtxkwaeHfNB+hJIul1OSTzKQoJW0kSyZLTXWCyhyq 54dIJFCN7PKhQ7V2+RCNC4RGEZiV1mW9WcZmy2uGajZlqHoc3cZlia/JD8R4vahP6dM9pd5Sf0mw lIawom011Zp/YvqJ+VDsUPzX0bdj72Y/5D6Mfhj7OGuwtWdr2c/lNmd34B3MDrbf2e/r9/cHtuV2 5E1kllrP6oxCQJ/9UeSNqBRgXQ5bwBX0pv3Znbqd+q8pX45+OWawZUyp7PzsotKK0k3pm7J3mZ+M Plf6iP0wYExLjSH0XSaEw7iAGTyEM3vRd/ND2KdZGzwh73f9IV/Yh2WfAj1HTnq/6yInIzYb8KaB syRpxofwD1G+0NAIRh90qu82r9czxM7WHK4C6VjmpzaMbW+qH6h/ATEzxDo0Q68F91h6LQMW1jKE mzVv0ufNhyUsZXclcU+yN9mfZJVkMckkXwRA3YSVPQsmg+nIXDCN9hklvu5xFZR9tQCIYO84hiJB 88dOkClAyjPHzpokBo2kj4FRZjI4TCbD5JRxd33OuNZ3zqwxFOtEtC+v6ExllOmuz0Ol0mFFtgpi 2KoGsJCWAkiRQwEkpvgAroOPevAD0X4nxc/kz6wnUxygkT46MdyleXfhXcwudpfhYdOAc8A34B8I 7Ix8NborZ6Tu+PWoj7i/NEMhWojdk/1a7GtZvtZN4I41pXirupS3ijV9lYHdXw8x8lFZqq/moSpL d13VKIds7WaFJMSF5a/SzFuN1QO1ovXMSNwF9mp2AvnvtdWfBUYE1sCQgD2r2Mg9x0EdwGWWKiub 4D0m8oDjms0E7zHBNbB7rHQ/J5zpv/0RYEbDG61ROu1NJ8LdromJcDKvai1NTrrFkmdPgjMDauLG 5bOXKuEV9//kuzcsWas63SZVDTx6+axLVo79Npf72i3NC0tW2WZknxv70ZevmZ9rSaXzc1Z9c/PO kN6H59x734XVWZcNtFYvWf+Q22L2gAxzjP+VaeNeBQtvdEKGxYOaDWRYkHrbDUYPiUw0Ou2Yt9Oi nQa+2ofG/0FVqJ1oV6JU7aQvqFPCbpCyFpeDG8L+vWQJcfvh0SOHCyOHJmJe3x+WXy+cK5+8biNR Yy6aOs8qw3h8RDWcb7LgJb4PByn1gi1i8WPn1Q48z4Hp6zQgRXi3wY95qi15iShFnmpL3k7QAqkl LaXaEgr/RbWl3R4MnImXzdDIxvbRI7XasAxqvTapV2BY/QeRCRoww1hdgVcwTHtwp3Wn9xXnK64h 70decVcQb/PhRcZFphXGFaa/e3jB4/QkPazL6fH6WEwShx/gk7M40Vq2yDBYMFZIo11vOj9w/sXJ Oq9w+H+KDEP4Uy2rGLExXwgOgv2OMOY4PubotON+O0Z22T5oH7YfsR+1C/aewDPbJlQkCewjW+1E bUQeATkBGGz0GPEYyyNw6hi2uqsIdlu1HqG9vq8GrEaIseQE5EnJrESi7hIJgJ6VZjKzgOe//XYp pU63JqP9M/NdDV+acn3OneZeHfvl7NHvdE9Ppy5fVVqxilmjuq6em7iCIM5Z48fYg6AZLSjIGCfo KuAwCoQ8jBR4GynwNspEIRp9HKEicpIUNDup5OhlnDsuGeQ4AFfim6AUNAG3zoTC6sh5cp2P3Own A+rjHHTQHUaZDDTwJxwYOTovR4ocFzIa6yGtVhh2maAk+XBmwgHi12bZ+p34CdcB12v4Dd2h4Ls6 wfZHPZ6rm+W6xHknvle3zfKuXwxrTRWOhrLuCuPXnW/4GC2M50mTrbHRULcMGGOLOKxx+AhJO7ke rpcb4AY5gfvUqMFJzbjLyBhPR3H2ZRaOEPicWTCYWrxgsPPCZXuMoXl7wty8i5Z1fRcZx4cRB3t4 fLilpaW7o+tl5GObwLRxsE0fyx/7zzqEAe8+49FpxkFb3Jxg4oGEPi4krBaHgoLYp2CXDkoeEUp2 k6xgPwuJ0+BWkJeH5ByvDvHr9JHgnsx6TKJFNesNzA3CzfqbzTfbbnLd4LkhIIHwrsf96AKyteqH 3QmdvsdQD/0hkGwi7C1CBVuzO0JcrjYq7JIJBh257dqNb2558+arNv90ceXa83Z9YeVtV89hn3t0 63O3nOp/7J5/u+2fN85of/TWH439dvcPTtzbQ2zGRQixN/P3ogwjTUqwHJVdOYrec9TZ6gdLyyxg yZzG1JbANlAFf9JsRKKZbTRMox6yIbxY95tqeikWD7kRsqQtRJDZBAng88iwPNx+GHq2TorD75Pg evl1spHo/dMS7SCy0HsQYfNgWojBk6Q0pjSJBUKSmAoo2ox36jRppvVw/B6N4Tebc9kJmTRMVwnQ GP5JAp1+j7LTuTPBzmRnGud672TvNPIPc7iQ26IOCAPiLmmX7lH5UetgTicLssisaFiRYQKSeV9I uj+C94XAApS0cDS0K/QKAD5rLO7GmU4Zy8WGtM0qSKJe9mP/EL7o+R05nBtiPtuLGzJDWNZMqTS2 Wazy/RYLjpEQ5Od7eso0b22t5+3t9TzWSHPNFVDLA2ZMApdXmHvNw+YjZsHszb7ICqw4EdZWDzVe CCjlBBVdbZB9WDtWB/htbaN9be2j1mqtMBEBY4snHa5E3JmIu1IBlHTEAvhfZq6IMDtjQhO4H62U CLGVmia0LJ0WJZTnLDnx44H49MWj76dT53n37u3av/7qrtZyyF2aHw4n8lrgU/b80cf7I9lYLDXz cmbZ3LZt37thZq4lVFGvs9sbr3r7vLlE3s0bH2G3gbxrQtPYCftVU9op5bVTi8DpF/MgEwxkbpTU xpGxVI8SAAIsuajRMDT+WyoDS0SMOQk1lui1papIczFHQ5EUHdySL6EQl84Wy0ZNRySoFgyS1Ep0 9dD4W1qIXGQ0cls82ENrPfQKjxwPiW1ZDhWAjsgqgzqBgUwdJe67tzKHga7rAjYzTMjukPxWXVNr 6wyB7SXGtrgZ25Rwtb/9Sd0BPWvL2DajzaW70D2GeypC0OZqldv72zld4Hz+fGGWMityfqvWvi0o 6c2igiLz8AL9PMO8yoIpHa3zpl1iuMpwp+4O/R0GyxLX7S4m3L6inemRSqjclk/nyi9hPzISeXcA cByYDUZqIbZWZGOnkSGuuR4jq9Bso5EztnkIH6UN1UWeFZ51Hrbg2eJhPLeFgajhi4ttWhsDn92b 688xuQr0G8HkVs6QHwYC74mjksloLJeh409RhFB6CV+FYihO3miuong43h8fiHNa/Hic6Y/juEwu ir/EdIBecgJiDIOUw1dpIX+h2ihq5qoidor9IiuL+LiIO0UsdkzvOL0Ghkj4EyMZeTRDxHzbaGbC bQjqG3T1idFjNXlkPRi2JLAZ6J4a64W6WNnLGjEgx5H6uqsq5Yc5lamBKG+f0tLcwgg6SS8xghpR IoxQMVQVZA3aA8hmt4RNARyJTuWrAdQilRVcKRtsATmAzRFIWoW2AKLzzmQSmIZ4ZjINDSR8mch7 tB5kPgHte9ttNBKlvipgXyN8aZ4Ev8g0O2CuTlHMJK7lo71Gkh0FK7jqUQxVN+wBQu0+Q1UPQzkl RXI95HrIdZDr/htkJgg5Loh1652EttSnigWne9KiJ9wM/EztehIT4axPPJNAFyfBMcycL8aap624 JZT+yaeXLG6PJ5hCIl4Y3HXzBVMDNr3bIhudbb1XNrbir2YXzVzacv4d11m9X7imo3HmTUtj266M RLKt+aZybulAOnxe5s6xN26f6hBNbS0PzvwyrrV5sz3VuSuI9pkG7G/h70NO/KVJv5V7/LO63woA DxYn9A1dXYbp6jIMpPw36pEykpVbpMo46ZoyEgcWRUkgDfZToMR/FzSSBLuI7GQez+7QdOThTkTm rN/PNJ1WR3VfzyGikc5aSpa0U++Tg4JmO9yGkDihieo6iKP6yDjpTDLW177RQt2ZZDS6XWc5k+Ct 7e8frvuPXhhwD7uPu1k3Ff6zyyTXWqtTy9i917S6udONNXenu8fd6x5w74YLRWM6JM6P4HRISEYd SdMMe8gxE5okCnqEYybjxGPqzF6ZWh4w4k4j7jH2GgeMu43Hjbxxr+ssd1B9/q+97YwDCBAt1QfU /3Ouz2fS5XOLtzxnrL097zOHPb6UFVv5+07OWNoSpP4dVvvaHJ8cJevBxk8SFAtj60Ix/Iv66O4J 8UQ6y2SIeIcRefTUoQjt/XByRE9NDuQpaiCR7tRMdeDrcSOO0dmJr9F6ehT9cZ1B7WbqCBfGs26n 0/Ek8KJuK00OZgIewcIj4D5yD7k3xPOJOPLQEfXQESXN+QddGgiFP1M0YTQm4ucu4Do88b7D1gk/ zSY5gb8tHBD2i38Kc3yC4FolcQO7kbuL3co9zj4jiXNE3CpNDprHbUSc34VkFZ9uSWOYH+CZHr6f f45n+U+MLoQ8MSOg705Tr2nAxPVDMmhikUk2KaYiFIdNR0yiifhX2yqmnvj3J1YynV4pSNwbffV5 yb52sFroOFOxl/IqrEFMKGxIwT69J4C8HoMxIMFRmFMV7DX4Aygo+BWEKIKloa80NHY9kV9192B9 daFYlxuT5FGyWl1nQlMEPPXOh7/4i2/e80znY0stiifQYMb2XOm66qWPPLK6Ukkxnx38689PfKW/ tZXd//W5hHBGU6P/3lT60SuD3/U7ABnMHD/G8UBDYZRjFkwgg0SB4tO04KFx3BJ1Mtfju5ESdFGS chkUQjhWgg8UOvev0Kuh9h8ahaoK9S4qAQJYg0RNksW8YRsNnbVrOjMY4g4Uj+vEbJal+p7QVgH2 CVkB6v2QPFyo21KnpcVFNrgLKQaWJbcGeoNYC/aA+Rk2wGMMLkplLroAFVpIRYpC5YfCkDMkcDRN r6EfJ1wsCIX8hK9wEsyCCCED+n6tBmiWOC6JLCERTsD6c+aUC4T1z8vkyz2FW7lb+e1cf+G5wnBB 1Ar9BQYVXA3OzMX8xdKSzIOiOFfESmGKfo5+qf4h7omG3QVxuHA8wygKUlSy+s8AOmhWm7JIuUy5 Ur9WuVnZhXYpT4sHxdcbDAnJnjTOsIXsM53BpGtGIBScGYbbDFzWSXstnMXZbJg1hJFBNSpEvduc Pa5+13MuNuwacDGuT9KdAl3CmC/TGYI5FaEj37FlIpRr4choH5n0IH8gosgiPELAdVf1xFJXSsi+ RIaTkvGElAZri4MkJcYV3MBnKenWkS2qgbHXQsO2CcglllRcqKtBMJ3clTO0W1eGbj5asZJFFuKE KvxhR//8B4/+4webFgEN+zImbM1ZVJc/Zxg7nhfaVhW6Zl06uPbSq2ZPO/naa3jOwqceoaR88v1v zAlYo+vfwO/M7K0uWvOjH/+6vqqa/Q+g6GZmxwQ9B1s0Qqay3qqnyk7viZFjj29isuUfk5MtR+sO Ig91IXkSxAILk4qEWq4kc1jliC5U6TPUHPU25cgiZ1Kbm1yInZtcmg2FTzULNfTo83IYKHGGHrjB Bnsc9hTsSVQmAQEVKm0rzShpDWY5ImsLRHeO0NiXc9djk+XYTfKhzKRGPXdhdleZatMKTeGNyTI8 lDzSmtRT4aunZpyeMoF+Qh7TqgkJ7WmZglVardJqlVaruUn1myPggJyAwimqfnO5lilneaeGz1HF hQkZTtAgndAptGgNFX1LD4hvS9yS6G8ZaOEGW4ZbjrSwGQF3tvS09JIqrQUrkicdsg6xFs0ayaVD yfkRfTokz4+q6VBiiDVr+WglmZ9RDlVmYiXZjOhXJhMJq1XWez0x3YAeD+qxRd+r36V/U8/ph5jv guWN1Fg+nOvM9eR6c1x/biDHDOYwCcUdzh3JcbmeKY9vodp7wlU1em4Qz0h7m7VandDmEwafwxfg JSHuTwR4bwCLkk8MEpNvQp5TaEp+Z4D6sIiNVweFEwvFaWjshO4n68dPLx8/GxAsXPeFGRf0+u1m fVEbm+7UmvRseGax8Zr5zurssdZpUYfHEvY5C2Zs4+8bvfzmWUuXa0+PvXwJaINYLJmQL8AzH7ys UF40FrgsH47F7PqWpey0OgcRhGgEfvlPsA1LzC8n+MVdofxSpMzQWF8wIllcUcIPeXIUDcbSEmUD ieJGieJGyUXZamIWmuoE1yQzuCaNRxf5nYIEudyFgvTmIH1QkD4imKZclaYMk647RGnhOH1KepLJ oPBfmp7ckUYBJlYkSkXXqBEV09hk+h7wFQk4i9T5TNPFLLEm0ZetY5hCoR5VRpHMv/zSwUSZkC75 wYPJXz044wm+rOAiTFCk3t9GWqYNaKw/3xKTKLtIlIEkykCSi6oeF61yUY+vy1UpoyC9MkgrgvRk kH4o1U6T3AaFv71ArkinK+X/LZMBl7VWgMukCuGyYqWz0lPprQxU+ByHNVruh6PBijBYOVJhBiu4 ByqGK2xQcqVDljrDpdOh2PyIlA6Z50eD6VC0znCNyYYZxVDjzACKNpXoF8eiUYvFrHe7YuKAhAcl bJF6pV3SmxInEYbzp0vBWEM43ZnuIb/90Z8eSA+mWZSW00yaLhF3uMrpnnKd6TL/e6azebyswMW9 rDuAecHD+yZZrr6gtbaeQCjKc/8jx5GFq2dVnuG3El7wjfsXrFVcZkPjeWNT7VpJz81YeONGg7lx wdhUx+xG4LZA0oIdGWbk+wuWtt06tumSsJfymmURvnHz+i+MBWuuoD8Wm7MaL3lsrq8+G1sCyH4T jR15VVunUoSlUg+MqqUqXnWldXWzFPYzasQT9tvUiDfsx2pUF/Zb1ajNyjBY8ngZwhZeise8HLnV G9H1Sv3SUYkdJ4v1O6UeiV0hDUtHJHaCMykzSkTH0YDvofExLUiXKaxUetV+9ajKFtVOtUdlh9Uj KkNCGC+A3qfB3jAcBOfSMBFqxdR7n6Tx/yEKcTJukbnpXwINFye8NAAxfs4voZDyqQdomUii2WDP zAdJpOK/75U4POmnYnznLC6kvibBFbfoxB61V2VU+osV8HFqcGj8LfqLFVD48QEiSIKNBFqSH6yo tR+acM8fItaKja5tvL4hV0ZRYkm4TZfwTMC+hFvMLxaWiF3+roB4Fb+R70f96j7/a8oR5Sj6A6+b gufgpZ6LAyuiPZ6ewEZPX2C77T77gHXA8zj+NvNc9Hn8Kv6h+EPvx9KxwJ+UE9gjMPNtl9juCd+j 9EePR0Wrgl8G3KfAHh4/uhcFEXH0FMFG6YHBYJAqqwodjl51QN2tDqpkVI6qx1WTemXwAwu2/NAF 0C9I1uQ4qiTTWmxV+EiD+tOwES8y7jAyxoJMf3GjB/WiATSIhtFRpCMVDHr6et/tPqbTh3f5sG8I GzXbcRLWIQuKUBQ0gRc6Ih0HmS/V/Z596xeO1PrWj66vHVtPTZxMpn1kZD11ER2zTYhD/eLgquD1 QfbLQYxq67tB/BAcSJEg8B+dI13etQ/JHjJzefyAvcrLMgnXH94rEw/M8B65OuHCB05djyd+TQFN /qpKsu4InUCJU5qnsPPj79z+9Y8w3rf1O43ZqSGrIRqdvnrahd/YdvkFU8p4+f4fYOGDd7B5x8JE IeHcGA7Nv/wb3z7Zkd8E1vI/x+azLwJ1JVGViUzQVnoq9X426RtIRqARQYd2L1LYtJ3qJbtCnZ9K /cdsaKFuNyun7WaFTWVsnFnwEUvHTVwgHq8nHzc3dwtikmomRDUTwqB/QOsAthuhSugcQxosaVA2 hXOsnYOoafzUfqIQmvTEP0VNFr1+aiu0jmoPO9UbdqWuFwXSqD9rfmr1KHBVSjAnEfaaoTEG0hrS AGpVy3VtgU+b3EcmfjQlQyzt2/RTCU9U5XnypfI2K3dXFk/Ntk9dkL00e431muz10ibrpuwd0mPi x9I/dabi1K5Sd3ltmdOm4oLEptI2u5IOee+K2Mmv9URRUl2UDKGZjC2TYrm83IxJSxiRtMnrMTc1 hvUDeqZH369/Ts/qP1EYO7Fl/IrSSZi7X8WEKeqMwKs9rcQEr08kyqOT1jdRESTSxn060oY1k99X aKOqQilURJMULyeMiWK8IjYpuGCCpKRrVnCjIX/ajJmEa2DE1IAc2XjJOemSFyktJifhWcl1Fj7j 60qECMNynVgZ7EvM2bFo+/L1d/c+Pb851eSuLhhTvFOSdqccDXniuKwzX7d49fQLl2tdxUKMrfa9 vWnl2jveGvnaFqclN/bxZaVQPI5dhsbV7OXdRY95y9jT66KtXRdcefAX6y/w2IiktIKkHGEfQArz 6mR0sQ75bIKDQB8r7ArsDPv7PUgAzgW0016wVWlU8QTjNnr0Or+k00VUuM/goEDGYResDfSnm2wC Q2sYLCi0oJDnHM6c+a//qlbh/cMytY41nW2xvstzqZf1EtlkqESIeF3prDi8Dl9UF9GrVsUW8yhe xdeqq+pbbVVPxdvqmy/N083Uz/LM8s7zXS19Xdqpe8T3sH9X5Cn0pPSY7pveb/qe9H9P2q87oD/g ecH7ou8l/3DkV57P9J95Tvpyu3Q4QmPAeso0zzTW81C6noOtTvNksp5Ho/XcaqW5pnkDZUvkVtSH +5he/lbl8/yd1h0RXatU1pdBXr0uDKvv+MS79ds8W73sFNtcD2P3OEJ25FdCyKa3hmxD43dpWZ3P q3i83qJO79Dp9H6fL6aToER/fJOTmBC222wYhKzPa/AM4aBmW6HHsj4GNskB/Vt6Xr9Z5yf0LmtC Ybd0UPoZKO7NOu8NPjK9oCAdtNdiK+tIu71Bmu9tqpDsBWMF6YZ1jG4Iv3JAjuD+SL034CqSH7DY yyqZdPfKmQxZi0DI2zfq+dALAtxzwjdC8j7PCJpc5CKPkJn3rf+LlS71QN/1k45wuki7vsJlv15x mdoBY3z0AuS6mIGEzR3da6/qiWmtt1clxV71wz6xIgvXf0tnMrLXbq8vB43Wl4PSdS8k+NeKnwsk 085fve2WDJEyzpQd0cDYS+mxg65U2NrEPhBPKNHimMCYWoJmncUQj3PW0OxTf2b55oKsk0DvDY4f wwPsIDIgNzpvD5AojmtB01XNA97dXkbQkEgmui2ak9V05QHnbifjfBnHkQf9AiO6QLJ2YkSeXHxA VmycHbZ3Vhmr+Rkz8rBnCzPOIzk7SA9hH7WfVy+dR7g3jRD3AiBBBQ2CsEYyVpCCtcglzFXMjcx2 ZafylHJQMcJ44vu0knl188XM8hADSJBVI64pfuu0iJ5EFUeV8ORva/0xYJWZQJRhJfQsXssMMYe0 guv/62cagEQplNLTWj0Fh/pH1ZW1Mwv85HpY8AlCGuTnGY7VqvXV/YCncQ272X9ZM+dMTCxXoes8 m7kH1Q0nP5xcIMdcufYSRTY23b7q67etwTeKYwPxFmUDey350YU4btA2nXp2cdjpyN8AHzFtbDb7 G9DPU9E81M1+VfuCzdX51cTOZhas80uZjQ0bFzOoQcgLF92jcO1TFl26bsoNid5Ld3A7+Nvdd3h2 VLZPv33WjgV3LfqK+yuenYuGuIP8Pvc+zxvlNxYMX3rk0qOXHr/U71OcJbniaA5fyj8hzW9u9yMX 26zO9yNvx5nfzdXZ7Q6d1B/HtjgxWv9ve18eH8VxJVzV3XMf3XNobs30aE5ppJnRrRECtYQkDklI gDiELQuBBMgcurGxYZGdEIxjGxI7vteQw3Yc7EVINgiTxEew4xyOye4mcbJJTBLi2IlJ2CxxfKDh e1U9I2TH2f329/t+v++fjFRVr6teHV1dx3tVr16ZgZ4MkZ5l1dcSV9KZdbWHQ8dCz4XY0DR+5Jm1 MZikgAj9pWQguObD/mP+54j0nByHuhDFD7iS49BSvFQC36VEtGJpIaFRl7ZbsXUaqyXLgBrvVQNg gmTU5coHFuKF02yxpHcu1SacuN057mSc32D+FcZiDduKaiBIq1Q5l+PlhYV86zfZJLQGL9gp1Mom JZ+QxAPJg8nDSTbpIJqKZJ41WZ6Ks+MduIO8mwEaAQDffVqwUuCXlOfsIKSG1gBMZ0fIF8VRuk9u d5UdjOK26GD0+ejZKBc1Esxolr2PErrDTFpWdEy8JnmNdM0RqHPFNSSqR6cvu8Z48N4m3ET3JZuK RRvmbYO212ysjYhxUq2FNj1RSSdLVdkI52h5oBbXFifZdpZpZzE5OMSwmQGOupAqm5WcJsBJ8o5s /7prnsU3AgehPX6AnIaQ2ZjhC8MzFLgQGz4vxIbepQ8xWfnSkHAeWj4QEsKFjDqymTeJcrJa4QLh g7q6wCH4gNy1cO3TRDiS6eqMDV+6QAZV4hN6IwQ+w1k9AYSyyqidTGV3QW9qXlPdGCz35NodWBEO lRSXFpcVs8q6cFs4HioIrw51eLBnnteDmstbRVSPa0U0X1HrQe1FrR60ItYh4gZHkweviqzx4NVr cqvdgO6eh1qKl4q4eWl5hcQsFMn5BK7Gg5cllnvQyvzlImq0L/TQDYZYVi9Oxop95CB/AZWFJJup XVTkim6fStq4AG20XDCT3dOLx80Z7ThZrTcyWw2kkTIQyFDr8ll/+jdLNJHNUfijsbAsS5gRpqGq AWaf4Lm8Y92rRz61/sWYkVUqWD52Q9WZRxsWFfr8Sc/gD+Z3DVz/8Icv7GvWmcpV3WWxFM5Z2ttQ 1t6yobE0/V4iWd37jaePlpY9+Cu8LP/uztvOSAqlxu7SKpSLB8dPWMMpq0lUcaxCYxhcMbTx82tK KhyOUL1mo6/YF7iO2b/zpkfW1A/fdHhd/eVbSteGksEFexeX2WycEuqUAVprBmitEJPMcA22CF0f U2e2TnVilO6CzOraFL0ZTuG8ZKEMgosiuswegmfOLjibszwFAJeomL85mGUhjI6QUicaHcrcQqNO RfTSPUNYCLUWJX4RI1I20LCggWaORcqnIumOyZyl4DUqWWEfq9bqRJ3DGAzZIVU5SR1W0wVirby3 SndbRRfdKXHR3ROXlsqpmdXqsEiXqESlvIESNpMFYIJizkr1E4CuBJvNkXBmYYqIrRFLoGtpxHqe zKC1wqsCZT1qfyFrYyzHEbJIJUaILPFEhCvTVfqqxcW+xaLCpba0EQ7C3+YNRQLqCK5TedUNoi6U q57GjZJFi0Ihp5O+j1Gr0+p0froNYkQTRPnHID6MX8Mcpsu+ZqcraDa3Ww5ZmHGwJiwsEVAUMyKK Ssv68It7P6oDdKZriOyOCDVZNUWURiIln93LhW4tuD28ycO7PEgwuYVcD6KLUGRDBHfFshu88n5H VmYRuAZVuT8jyQhPkXJ2I++3+SLG9B+Ldu5ubB0q9FQuxnWdtbHtzal17D0zPzpMdzleHK/vvGMc P1BX4sahmYfG2ytaGNWySiYEbfRzQOEMoBeBwolJHiQpdUDKSNXlGqm2vFuDD2uOAaG4T3/9TYSa occUEKFlQnOJF5SQKLXyokyzJCTKZwClolfchSrZ5zJtP+aiBIST2iIlK0yybiFqgw9RQWsjdpjI xBJPAkgxeSOlIhL34cwWCl2h8tOFX3+cLvnGbaSHxLPLvPHs/BLPLgXHyQKWQL0EbPJxYa3dFYrS jMg0RNTbhlE5dCBzBd1RqahEYWdGlhNY8RMavYGevgHWSEtYo9iFWGajZQZY8OevcuSZZdaXhTMv k+NwxcmMphOyuHqKT/lSjFkpYPi/W/MF7SHdIf1D/IOmh8wP+g6nprTalDPl6ha6Td2+bcKAacD3 EKP5g/eCjxnX3GJ8mX2Zf5t5m79g+pNZXWuqddT6qsTaVBM/rB3j1QmmQBBDYjiRqsJVgipHWIVX CB0iFxDW4DX8m8JfBMUS02Lfi5oXtb/RKuwam+DL9fkamXpeqTPxFoNLn8t7jT7lSnYVt1LRKXSY OixKJ5+b6/WtZLIafRIVDsrVYYHVRsqhjnbrsf5mDdZolc6IXg9ZZ3aAqIpVf5xID5DneFYyOZ6V TI7HU1VzNPkSkCxHv9qV0eZrpyvSbmmVwGPGZLZYBKfP5XXG872RSJ6W0Xi1ZDcnEqiIJOrKvRUN KIF0MGYGRZ9VxIzo4wUgYxgrxgwhkn0WzEUYXisIDm0lQnYig9zi0H9fp9MqgXGAwUCrS+rH9cxF PT6rP6dnBvXPkxUxu/2wAztcvhRO+YNxFEwkUFyIT1BFWYr2OB6PH4oz8fVVqWl845SfqAOOLbs0 NNwFQwHQBMuE4XcJeImwPXPOc18g44KTvDKZ6KHhCDU1VMsFZaHUGQABgiOzLiErvaD2fhJ2RqUi 5yaHh4fIgtlw5gAlGkJDVLuFQETJYQ72RYGaAJMrQcOL8lS5z6QupSOOKcXLjkZ2iGTKcVOWw8qs rRGpKBNVSVyWUSOgUlnoPE2WM6gWHjpU2T9BdXHb20v1an8Y37Vie90f/rAhLxl0LkgvDLuj6d85 463peFMgR8cbRVdOgQkLirsuD/6owazXW3MZUWTi836a/snN/oRRGwziHIu9FG9On+2scuBg0KSz +5ez9YcXuU0BsjpuuHJe8TTMsoXsq5kVjbDfazIyhWQBzYg0YYeai4Z8Sl5JliJqaxMJWc9W9rR0 dsEsDHXWQDcyPXQjhtoOSniqZdsR1nAoShPfVYgL0VgIh3RjQOfq5NQLC4v8/nhRRvaaKvXqqiXH 6WhmcpOmFes+bqYCj57acltEFERTKCLGu+P9msH426G3o++F3ovqCcKkpZziveL2lfnj8fzeilyn 0+cOCHFOG84NF4ZT4VX2x+2POx4Pq3WhymBlpA214FbVEvWiYFOkNdqaf5tqXBg33Rm6LXpb/nj8 QeEeghw6LZwKnYo+F38l9Er0p6GfRs/GfUjBqZQ5nF0TUkU0UWV+uX2hsNDUrlihWu1YkX9Ad1C4 zXHAeSBwW+i28Hjcvl/zGfv+MGvQdOIbhBtMnEajBo47FNJiFePFgt3kFcSA3yui/EIv4rVGL+9z er2+6SufmVJHI0Dg7JEkRygoqlVqjSqYH7Xm50eBkgtFkmqNVa3WOHIczpygNmTVakOBYDDpcFod Dmd+OOB02MkFJVr4DqfxO8AIe/E7Uz7Mm8iTgIzQr4EyEQSfTxQRQzwxKgQUjJSO0/h6FEJq/JjE RyUobDAY1YmX+T4tnsbHn34e9eUHCDeVI7kT7U58xIm/4XzN+YaTdX4+mHBMY/dJkQ9hAT56hosI ncYCTBo5QDroJW2iO4yl8HiYCcPg8rRmTyShfha7ITu3pBVRFI9HLxL99kCPQdToERVdrGzPx+NE w72QL+ZL+RP5z+efzVflry+aPfVwgcgMOV0XZs4D1zCUWX8BLxd4QLDjvOuCcImYC5nhxSWPLoQn yYpfyvAF+ZzUrE4SMt6os0s26rk+/9dnuMkJbrqoM0SP+RJ5TqBeyHpOWABWlRwsIoyshazl5Kbs cxwrcS5O2lMh4uTQp+M5V7WEyas7GWVf9CC3vLSTXezJPOMAK6/1GPA4kEZnXipzRGw1+OnFXqv6 7AvWSAr71+Snf5D/2/RfQumf5VbVsPeEOK/HVzjzn/ip/TV2I9HqZRcC1pyZP+MPK0SLlwmFDP2X /8AsmTnJMktKiaJ9dFf6KJ5mjwONFEAbJbc/9IJpc8XL/Jk8Rm9wW3IEjf6EQ09Wg6zT7DLJ55Uc QEXJ6igq3EI17/f5x4Gtf8XtDBJCCojF1pkucoIFvtkMWdQnh1eyLB8e+sgyESsPsnR5OCsdSkKx K7NkdN3mIY1KpQuZrcXVzRX1mw+yxyV5xUj64IPCvIPtFoPGqqkuLW4a6d58XKbMlEn2GFrDzu7a d1KupJPuKdozlwasaklmaagkEeYkNBTxkXhCbiVjFCtWXNmUxWrKYhEfyU+wmuoW1VG8Okqw1VGC ra6FXjPQko3XkqXZWrIJtJA9eifBbdGSZFpiNHqMRo9VUuly4lEpkGiVRCqcnmKvpFxSJRW+IaiV DA2ne5+VH7kFgYjyZjiuZIbjelFOQyzIcGQ/k3QEVWSyezeSjm7n2JyJksbFZG4RF3WskghOYhVu WzWwau8qdtVq5aJiR6hQp6opVMhyjwlCJXZ1xV4VZp4nvyyRSDbg/xbMiLnKUgQx6r5MT15fFSSo geQhdZ1KoepYtVrlKF5koiSXSaTslxijsgMx6herrKNPdfSprkUk9yjI3NjaSsJNEu9Kma2kwJ9p aGXl2hZCNxPPlqxAAQDv0dCWls61c3k1ahNGjRp4BUTf+VVg2WDMgRY9YWjuWPscarryFmoEkwCT vPLWMy6H0+FwVMm/TrfkKVOd7fyTjR0HkqOTsHYxAz7UiUW1mO91TDOXn86rzPcWAyDp8lryvYuW 0vscplnj04FYvjc5zRqeDtTle5sAkBYEVkVa6zq8qxrU+ZWtUio/qkaq0KLVa8iHCRXqtTqVklOo FjUVJ2FC6bTbXYIp6E+KeFCcEBngBsslvjI/HgtWJSvxYOVEJVNJ/Gyta+qCLS2+1vZWZrz1UCuD WoVWppUsm1ttZa3r13ZOM+uADtwL00XvPqoTdZYvvEREE87LTs2yxr4GoiuB/GrpfysdtrP6RtCs 0EJWVigvqOcNoUA4qPd7sJHPM4bmygoNE11R9IAI0ZZIVlg+QWAoQ5/REyIqlf2qDPGst2qOJNFH TpOX4vZec9GW0tW7czbf1bxkyG8zaCvmp2ss8/x2LeeOrC7f2sIwOdVN6eKWlE7hL2yrKF9Z5CRi D7UlLnryXJZ7eKeXDxf0dt/Y3Lyqend652rR5gsG7fS+itsH41L5Yl0s3UyljYDSWwF+xVJuYWU6 Z12FOxh0z1uFr7uv0J85pb4SjzNrGTtiUa0kMorx3N6KvQqMybo9yyJGwO14PT6Ej+CzWAlTfNkz aJzrWEcm1pkuwp8nyPlhujBP1DesZBQzHzL2+8iIv48NMF9XbEUG5EIPn5x2vuL8q54lssdEPwB1 i5JlGAaRqYLyMjR95RUpFwCnAyxXFVh/1WOV3q5ntJ59xs0VBjSNO6ZUrMsI7qSVRdNsOYx4Ws4I gGRzuewm7XbuW/btyIRN+9yee/xkmoi92zXzrqzVnVowV9TUEl0T5EPLLQMPYzYyOyeoWD8754GR KmxMVTyWsqTSGypt5UWF1a4KNoCDu5zO2urq4lUb0/+BozcVStXziiN3pX9KdQ8hxP4OaOkq9s+Z uUEf1jrKwlwRgkkzQbTYFlkEpoowxKjIa5JJ6kRC1ls7k6FyZSVE+82NWnzQcNB40LQ/vL/sx7of 238W+Vmpho+HtSFdUA9Mq+7NEpWnOs6vq+DitYpaodZUFa6NpsqS1Ut0bUKbqcm7JNwSbS6Tqlc7 V4faq8dUe3V7hb2mvba99i+oDguHTY87Toe9RgUv8Ca+0Cf4TL7CfG2+PVGtFapXadZVtFdnOdcg lHsXcMbkRXYmcCIeLnNoORQn7+CN5+am4vHqVJZ0h/FL1sdLaPfnZZu805fCQIVCf4qUlZVrYX4o dWhh8nWGy8rLSstD5oO2BHzBcr3BYNPn7nG2e7E3ERoI7A0wgYMBHHCGgOktLfpzfn6ktB1qe085 LlcoVCGnShUsD1nLy0N6WySSLNVbS0v1QOM4NHp7aSTk1FUlwg4tqy9TlfMe7PHBl0jEyWfwIrPJ RPYI41wRLiryenO1+mnc+MyADdvioWlsnBKd2Ek4CL1QLjknnOecF50c8SB7g87TTAUqRSq8ebI8 HgHKdwqV4tLTzAsohaqZ1in/qwdktUCXyBpHV2zoAqVY6Bnc7N4fEQMW6GoX1btHj+CaP0HbLXaY U3sSjneE812kjs/TijanuhJd4CPQR2H3OwCp1EKNEZhhoWbPmTPEOaM+owJHDb6U4+2iQu5ZRlcH 1KOW8LPvndSk7OQ8vI70SnBzyBSv8ZhqDZJbqHUQX3hwUK23dmOtgmyjqIhCoQoCkQsvToKbD0yy jgic8KmQyJPtR6LDVkVIVj5VQs4CGSDAQH3IOfqwSIwJ/Ewk3uvAXJMty0mz7JjkDUy3ISVABZjA 2CVzShD4lAlMoZSTssj0r012zITpyyGn9C9KlpxUhTonFU1aU/lgTGob4dQhMVsqXzKByUmVEAM5 20nuYMxzWPi//X38IBL+SAAluLNH9im/n91NBYY/y98DJRpRzdHLW1lJJgg3PpbvD+hsdc2L88K4 ojhYvGrP+Y7FqXR7kdMifebuhqKi9I+C7vC65/9l6fL5QIJ77I4SIW/Llo2unFwgwB15w4+np3cV s8Gg1Wi3d505c43JEWGCQYU194Yrl7dVEh4ORqajii3A7m2RblU5dCm7wzO/zCGB5SQW77XZ8lU1 qiWqJ1RKSbyGW6e+xr7OsVU9aho1P6z7Z+MDpid1Txq/o/iO/RXHT+0/dZwT3+fet+fk4FzOqXDn OG1Oe65DpbHrHLrcMuci5wH7QVHlcDKM3eXUO5UG1skolA66cWHhDNNQDI2G7MeRq6Om2VLoYQrX QSc+7DzmZJzPsqWIxXdOYUbvncZ3Sgak/HWbpdsyYNlr4SzTWCVZJHgpFxIlcVxk14tHgOhwnsbv w1xmwJJk7WYGmL3MQeY55jXmDeZPjJpx+p7Fd0FflxebW8/XXFgmdA2929VKj8OTLVey8Fw7MySP dycPavBzmtc0DJGuip3P7C5RNoMRMnov9jjvdEJ4J/Q3ok3VSBT8ECmWLixvsrP+coToaRGlKlCR PVOiYlR+IA4q2aPdl8/hHiw+sqP3cDjkfO2hR3+RXPrY+wvwhm1rmlxYkf4whOvx/U/c8tjY0KmX //3Q5s1feiZ9sUooLoJX33DlLZbcSeDHXmnhVzhs7vT2e/cq9ir35t7B3ZmrKmfK/UBPi2v8Wz07 Fbs8+5nbXbd7vsx+VUPuEuBRANP72nNsdrXVwLDsNPZIJtFvFVlO9LvcHlbl4BTge3hKFP2WZ6Fm HaxFgpEZ/xoxv/b7EYeexQuQGy96ZpyqxZ3Gf5G0UgBLgfUwXNum8fsnBOaIH/tJIpJGlIQjAiM4 857FX8Bv069wvoss8nURzpp8iAvnUWZp7wK5NOoCNtGrWPar4zGFvJpnT2WVJxHJkWHxVnwrc6uo hC9AlX/Kx8t1W7kBc693UDGYqyBHErHKr+Lko+VzOMDM7hdhjDG7a1l6SyfWPLRvzaeXj+y6aSAe cEUSza1jxx/57PavY07R8rUTkUdum956YjxSubLEExP8Zcf33vyj6iIVQzUdL4VvcRL6loCC6NnJ HjWQv8pJhSKHOAaDaxrzklnjQmEpzEjh9eEj4XNhLmwi3sZuNID2ooPoCFIgZ+hZ7L3aQuX2OVf3 YgsOBoJ5QUbJYBYzSlXI4851e92s0hImOhlhZnUySj9n2oB8StcGbDUCZNMDFMTiBuxWg2UWcjYg pxas2RGsgJqCglssZeZKKnZlsjJ0B7FSkJWLVGRkTYmE1dI7Rtetf3j3Q7f924YXb9l+pjE1VDHq jSeDqfzqhvLFZcwjb+G2FXWHX0ofeyd94gu/feGv6beOf6Fn+EmceuuhkaR//sr0w1Bja6HGjkON OVAUXZYKxjQ7tTcYb9X8NPR2SKlk8R72Ju4m2z47V6OOKhVswBl1KlmxW43V03jhCTGMw2EeCNI7 pxxIQSp7ijdgaI4SadUwG7lQgVTASAXrC44UnCvgCpxyS4Ugee8paZEshyxHLCqLM/9qlV/uap05 n6nzSzWk1mvo5WUXhrPacTLdXqd0Kxna6OCbFHpCGnOux+thlKaQIRzSBDZgn+DegPxGgILa8Abs MYsbUJ4eLDQ7axTQnaqhLpxjZFVXT5tFwqYyc7CiFMv7udnDZkr23k8//uWtwUOf++z3N+/+/md7 vvl5zL+3deb75kVNpUvWHLhtT3iNYkvI0Palbx/YeG7ia3d87dopnHsCL06vnWnYv3L9r+oTX7n/ 6Adkn5rcZPcojBs69MIpxF05N2VxL1CQaTEGgFONFWyBph5JhvWGI4bv4u8wr+PXmXMGqFKsw8gg GVhGwXHT+G7JxTJWlmU41qCQFpUrfo2V4Ch/jYkyPfzAiSM6rHPqFc8ybyGW+Z2kR5zAESUXRzgF 93XmTaTP1LtAOj5t75fIGBwTLsRqZ/UkZtV4jCpGlZ9WfFrJZbo60UwC9QgTLg5gP+G6Ij9gfpKu GcRfSH92KNlRmqtoCX/wTe4ld3y9jp60SDexl4AuL5mVP7VqNLECFt0YwZFcs9JKT8xZCVluoiBR FnqCoSBDwBIKlkxnBftiF2LvwF9t4tWuLMGeKaxXE0O5VhNzUwkuQWYgjgM3kTx4q7UUobLS2cXt X3SdAQafUsby8YEJAbj8byD3lfeQ88pF5Lpy8bhWyLD2RzVEIsAY+0I+YymL23orPqXYp2Q0GoVZ 7VS7NDGrK6wJmoOucKwKV5jL3YvMWzRbtP3OTa6N7i2FN6p3aXc5b3CNum8sPKA94Lwf3a+5z3Vv 7DQ6W/ZbZUCjUcdihQUFWkyl5pxE1K6wJCNqF1aLTpcrWaC1AkJhLEaF7GIFEKXApeG06kJwnVqN Wh3IiNtFqK5EKG0kEUjl8mV2mP/JqrD7oBa/ob1IBE4HtX/Ssto9tZo2TbeG1eyBXm2UcmM/5kXM i4dhJj/YXYgThbWFTKGztOwJshxAlgK6hlvPdw2dn7nURe6nm8ksAUCnjWVU/GZvOlLPWaEles/J PtD/vAiLhwhhHPt7YnFULk4554Q5GRkrsawlU4+P5hQV+d941aRS58VwQSjq0DjTn604tnxeS2XS n4pqvYuCdemTvN8p2EuBgovkRhrTJfiD/KhZozOEQpzDb6y9vGPfbQ2FBaU2fkHnYWbKFw/oBT20 3otAuylhtLSh+ySr5FjvOOI45+CQQ3IwO9FnEGOss+B+XIc0+AjKA7qJwGqAA9D030M87kc28EH4 z5IR8zyjYbBCo9YzLAyZfwX0JZLZaOQlU3mS38sf4o/wHO+0P8sE8fnMVERk0y6cF+SjCJQKml1f oXcPDHVZ5AOGhKpdwMwue1zES/2WmmvTzPoqm1YVcoXquW9/8cP9w1VklZjJLb6J+fk9BaLXB0XD buihSxR3oTC6VWq5kR2MMtewHeatbK+51zJqVnp1Wwa0WKvVaXO2WE1oC7Z4n9Jpd3NVwaBDVeX3 G6vcC0xVjqkcSMpqFXNkbeODOYqcZ3EIRfHW43QHvkvmui4BS1ZDF/VnLtXIE6x8o04qc5dCDpWa ocvk9Ko1eKikq+lUSz3VVQ8wu+TxH8Z3bd26K/7Dx8e2F91z96H7iran+wP2Xx1Y/Fz54j3GfOPu JeXfXHLbr20Bz96WeS809H2zrPzFvoYX5rXsBUp1N8yCt8N3dcJbl+KbpGc7MdaU+koLIgOlN+WN 68b1RI/draHx8O2lTzgedT0emtI/7ToZPh15SfuS7icGmwppsdLAuDQRm8HuChlCxmZ8B/6UYZ/x CWSch6pxM2rGS6Ld+JrItaXXo+txP7M5fH1kS+nNeHdkZ+HuUiLDN64aV99qutV80HrQdj93r/oe 073mh2yPhZ+KPFU6zZ1Qv637vf5t49uRt0vyVQZNpBqlcFWJokGN9K4IRy3BTikepaKIOBZDbp0G 89AaJWqSAAt4kySgcqmcIaegjpSfK+fKA1+HABZm5gKYmbVJu2Q/ZGftzrJn8R8zBCIhgi5R4vDC +UvZz0Rvg5FVUccS3jyTjVPnhPyKABA9qtwNuNBasAHFzckNOI8DesdLiJ6YrWgDSpiK5Al49oay W+TrjshcEr66MaCyzSpcA79Q5qY9Oh9bMvojZCGqA1/s+v4TX3ll29GJVMvPjr+wbfUuXHyjtHPT pvHy4oqV7Xdu33ZreBFz9NNHVn/6ucnhlke23rZs09DB7+3qGVl3/Mfb9rT137CzrWxLIv27pkfX 3/LQTWsWp66Hvs5eOc8sgH7AohWSBim+59tcAU16mo1IQKVbGaDUyS3XOphjfZKVKPRezw6yR9hz rJI9jZ9ivgdz88DxN0hbz6w2yLPpHnqajij6ZRakc9rxHxR3fbBa8TUyNx5PNzFv0J43Li29wYxD 6nwN08FeY+5j+tidzBj7Xq7Kq90i6vBZmNN1Vuh8JuiE0AGhO+42/U0XtGKErFYgfkNTkX/9xVXd r1c73QWiz0f+nqTXDcndbgh3WcqzXct+tbdd7YHZTnl8breLf+HuQ/fHtyu2Bmy/un3xN+Vut2dx +XOLb/u1PZD7T63zXli4aU63gzfWXTmnOA40UBx/6hRKXnl+qiBRliSLOmKQulKHzVMWVVYrW5S7 eC4UCEVKAiWRxkBj5NGIKj+SijDtyVHdzfyDkeci74WVNUb59JjP53b68wro6TGLz+3wB5wOB8Ng JhQ1aAryp6/8Z/ZM5ZvZM5VvZs5UMt+RBJiGJX1KLdWWi+qkmlHTQ/5WIpBKD3SqqYo04ntCPl5G S9pQWy4k8WDySHIieS7JJX0ilT0WZT0AsmBQntm814IHLNgiK+EzUu18VFLO4kxc+lJWArmrKyuD TKjgjATnVcFkShFntCXAuN+8fNfxSjV0w7A/qjXl+QN+RsmHIqGgUSxCgimszy/COq1fCBWhqC5E tMDjjP4YQvzSc4JoiHRFfPUEG51eI1RUa+7BNnrzX2aJnf0hPlfaHstZfuH7v3wzKTaSSy7LOoLO 3JaDW/b9a6sn0qqIhEILfUMzP/v+r7744K2df2HMe5aFQuXB4Znjbd8fXjr6zOtMaK9YCO1gR/oo vh+9guxopRTpZDrtZ2ysxr7eedbJajBScRyvNqMTZkmv46r5HF/OeA4LzbpA0vn4bp7hnY6Hv5IZ pma6qFJNs0yAyNSE5e/sPO74+IZj+ujfbjNC6SwIKZ6grfRHTysQNtPv/dXacil5neM6Z3uSK7Tf bN8V3hX5rP1AROlUOIEpSeaocqJisj2pUCiAYInmMJwfiTioikaC0VA8mWzCUnI5Xqta510bbU+O KEdUI9GRgsHkOB5Xflr16eh4wXjycMGX8ZeZI8kzuT/KPZcU9yn3q/ZHWaxi3FhWqu0Li24fisbd SFav7XUAGxoMO+x2GDStkUhYpVaTJp0XicJT1BG2J6KqpDqqioQdCp8A44PP5yXquO02Ioj58ePK lySenmPOk9QaJqOy+dJJqsT5SZGSl2ZDOdF8KkXaqRrUQxFVZJq5fypB9LCT4xUxF7TYGpfj6gHK 2ZvEMiLCqf1chkjkMtJCeJZIjM0hD2U4w/hVh6sjMuNHtuyHED3qimN0IVVBLpazGWpxlOhYJ5ZD Vnekkh1yxddxfSrLAZKFCUpmAlH5Ma3e9OjFx7WuQ8M/i3/qcvWuqEmf8oRXFM48T7R8p++oTyy1 hpkGb6JtPnZjbU1uRYWiJRRf3TMzk34yq/Ib1zFVvSUBbShUWBi8Lt2Mv3Rd3FPohFZ25bdXfq/4 GrSyCH5Bar7djM0HMWaktvKDDDbnMjjCFFmqLDda7mfeYK4wKktenlkgt3nk+cltHnksuTM4YPW5 Xf6A2WzCDJNnzrOazXl50/hLEh95Ems1Gsy4XWqzhmVIm9CbV5pMopAUJIEViLJjInwuZL8+AegV mMIj9JCyAM09H4v5+Ej+uXwm32Klav/9/mQefj4P58k3nVChxDxZdJ7cgeKM9lwd04bo5mH29kvw APhNcsI50youXNifWV+CzptykLFNRTa1UNfwwrVSVGN2mvNxLUqZ29BSczdaZx5A15tvMj+En8Cn 8TPm7+EPsPlPDCZUYycaimF5WZ258lWyhk7ExaagUZiJHllofJKHLDG/NZlx3NQ54UxhtYNe/kZW xM02c4oRcuhlShZ5RZwhl4hT571nrClGuqpGNrsEjahaLNaPZ8+GyENn4OONi7YtNx5k53tC7Qn8 OmlEwcu3usNtyXQ0sSZomzd/Xu48RctlFWvMtp4PD3ANl7+RfWKPNRZaNDA+LWcD2EXvIFkuubXG ce/mCh3ZwNOTDbxp3Su613Vv6Tg92bs7qWSNwAdqyMYdUR6g2c6OGzq+QqmUVOLCMiHLytXQwy7A 2c/diHukwl5WVDSPbr5Fb45J1fOSoc/J+20d6aXMbqBdLKhaCtxretzEfEZ/wMRo79eY0P3YAiON VvNVY167EivHrR3XycsNGeFiuqqWofYjYaZcQITEZ6DLeRlm9319hx7GJe/e/Mgyv2vpnvRAqGXT 5/Dt/44r8JUdBQ3vpO996cfHbn/8QfjSG9NN+KDiINKhfHwms7qgi1roMXOLj+hqv/Q0kYnQZPXh arJK5jXkk1tkXfSyHnst8Tb4pq+kaRQA3qFRAPg5jeIjUTQkig8p8+kZV32UnnGN5tvcPxBQ4sKr RJOP8ONXswLqsawS+tjLxUn3iYddWOnEMdK7aivLDbFJQ1eFFGuPHYp91fjV3CMxpQgP4zFWAJ+z MdZFxM3qIt5og5O8knKVxaUpcLrFfL3KRth2g4CQXgU584eBwCAyWTUFskp3aVE5G4/BZ9frMxrq qZA7eVOwgz7fIcLuY7J2f1FkRZEKX0xf+YtkoAIWkwWxH/qJQi96MWpGCkAmTkhrab0UuzAsXOii ou3y+DyhfNX9NNUtf2G4kwgDyNd4p8yxDLsqC457vEY+N+ThfR7sNbrJKQ2c1REJHWmo6+PK4eew /LbSj+mIj8ZqamIFNTXjrxy5Zm2x3+U29fgdcdtVTfEHaXBBrCYtXt70h/P1gUCJQbUmtOZzzB33 xbL78HFoxatpK05JwXyuQL1YwULzNUEztgDxr9FCE5YPirPK8Zy1X/nbZkxJZ7vNnCMgQi+bge6I M/H7+w4+nH7trzcfbvU7m3creguaN30+fcOP0t9N4x2hxj/grS/9aOL2x6ANIxEh9hRwolpkQD+R ojYDsGaNBolnJR4X6HGOCjNKzGoUSszpdQbE6Q0c0QZANg3MKrVVBRM+y6mUejXyGbDhNH4YKZEO H5YMCqzUqJVKtYLT67nTeAnwNWrgBXUaDc/iw+wxcrQI/1VywBBLtnOIxvMj/Dme5ZWSCqucxjl7 NkM1dJugpvUSDOrCmwIdxFOJjITezHCNKfO9YUDnMss+PM9DHx8mamCGcU7AFDD5y3EpOJg9deLR mReZsR2PpoP40l3pB/GmcfbWy3cwX5wh2vuu/CndxJnTD0J5RRjOCfuFeBZVKBi8mVu0GL7AX4hW UirMj/3lfs784S+4QLqpg+wHLGQ3sythZLShInSrFMXIyDnsIbcvmqc26aJS3gm7SdKdQHYWsQno HzzVIkmOtBVIvLv6CLTHb/FGn3HcyBqJn4arPmbFVmc8MY1Hp/xEAoOshrVemCG3Rs50ZRbCaluB xYJ/WQXkLKED5cuZPe9TOqdphz7ZGzetbdFqDIZCc/78pZULt+1jrumTdDq9rtCWP7+1qv76zyi2 5sd75wUMRn5+YbJxdFXvU+Fw9bULPEajMC9WvHh4Vf9T6MqVbC1gFjUgxH0ZwTuTa3UYhJkCNh96 XRetq/QZdiWlwRPos9L8h90Px59ITCdeSbydUN5kHLPfbtxn5xxOTwRhjverC/SOEwVSUCeT5cW1 nur2IswX+YrGi9giWoFHIjjyrY/Q61O8M1k8t+oIuf5uFznBfp5Q7fCfPZKfrbGhrr9HvSv+jv9I X61WZ9DabLaCmtbK+q378cY1rVqt3mCzm6AiKxq27UufKUh1zYdqUqtrYsnFw2v6/yVYUNQ3L2A0 qNULYsmmMahKUifnr5zHL9OZ1YG2nGa+hpzkOLKkqagqQ5JUV0YOJUlWr79M63rPuLkCSTDhPo5O IgZPs0tOGlSsQbLoMJlrDTABcoJkK9NK3HtOsiaQlYW5UCu8SYUl5a3KpgYcmDvnzm0QW8JrlQsT iTpuR0ZkEm9mC8pdtS0tzY7Y5WRdEfEuqiMlh8lAMQEl9yAf48jMhWYMxL43F3m8HpTrw14PQ8/K 24neSjBacr2KmvF4WV7tseUi3yAexwzGap5R05sXE12vnn01kaDiJBcu/PEdnJB/wp79Z84IYIhg iVsNXK1B0Ho1vna/Moe3CC6Ty+32OHKV9IbGkHxDY3KtfENjLE7dyXzZWwzL3i6v7G2n3pM58mWe 9wmWMgOvg8RT/FK+SVjibfN38muEVda13uv5zcIW705hnNtvvJ3fL+w3H/De5nuIf0h4wPSQ9xR/ SviG65T3e/x3hVdyv+v9D/514Q/8W8Jb3vf594T3c9/3Fmr4Zjfj82JSSSjX6/VojFq3xuaxu21q RuVWA/vrzrnRywvkEgVPnkmwmgZNmByZNRJa2MR4rQzj9eU+ipBccdP4GUmvFng2x2ZTqzVqzzT+ QNLwEId51CiZppnkVJsXe6eZdySjKBnbjRdhmHlcJKwTzCpOF/QNB5GBzoqqEDL5Er2ClgilEEp5 fxeVSlHs+W+uY9wv7DlTo6qBf9qbrspMDJNL9z4iAoFLs3cXk46lY9gnZv7r2rx5G9KrVjlLF+Bf BPDrqa6VM28vT0V3vPkOfvnHbRFfQhUK8Y7k3dy1H95/23JFKMTF/YXd2MAEZ35O7zW6cp79D2iH buTD10nXqhUqs0NhN3Nmo11p4lWC0e41OJQmvUpwGHxat9KkUwlurUKDlCa1BqkEp8HB5FhYq91o sxuZnFzW6jC4mBy31uPWslaMNEwOx1qRRut2k6U5DdJYEdIAjUueIE2rw2GA+nc6XS5gp4innbVa LLm5Hg/HsSdVJrPZ6/X5gEknYUUqYGH0ep1OrVYpjQaDVqtBdofD7UZawWSyWnNqjfvtTxn2k7tv GMc0Y5Ds2v1uzX73U6iWUSmVLM9g5lpRJgyGauTFtvPC+Xe7zs9cupS5bmnOXYi1NbOi7TNXwUuf 5JtZO9wv76TwH/sRwsNuCZSXWmAKtJSyxJTmBMD42YDFz1r8Fv9I19HTjVcQtlyz8hq8vGdl99dO NV1JX+xafk36qe4deOXi9FEP/vYKvKYdfzudIqY9/cQKGWKceI18ap/dxt6DcvATUsKs5hzcYe6w 4bDxCW6aUx22Y4N9zFBc0Y7W8u05rJuzGy38ddwK/g3uLK/K7MpFMWu3QT0ZFfpmBb5ZgdsV6xWM IqlXNvB4lMfd/ADP8ElGi2pnhru6qDVnInXDJ35XEOpyvOT6haBUolA8rfXqOBh0gixnZVmO1TEc j/VGu4HkwrUrsCJp0CuFbh7zScxo+dPMAmREHLNAKmRx/DAh+9oNOGmQDIMG1uBK2GvtbXbWro/r ymEgZ5w2+xdlAbJll4ZaL5GNaXIT46Uu+K4CkZQg2s+JlS1jZvYC4mf/njOOzO3QGYcKfqHhGNBB lD01XjkraYA/ZZNg0csIDADwEnkK2si5pp+fsKW4qJWAr5+wprhBMwEPnTCnOEcOAd86kQMgT8GP X09OuFEi/IL99IK5QKU/B/vpTdTstbrLrzPr0//eU2Nxc1Eli2YexMv6m+2CDjvTvwuyBc5AydJ0 6PK/BwrFzaQn96SbVIVAG9ejDvwL6frH0GN179SxMCN6BGeOp925yrPTpsICir6Ffl93bvW7jdza 9sdyHrOdXc2J7eJycUW3gy6BiYzYxm1Bfczm3P2I24VuRx/WscfVdfX1pfWobUVxfR2DOB3nKmir K2W4hW5gVeuBr1qAF2xBVBtA/cl6vimM6lWe02w95O9mFz3TckuFtwn6/HKpQtUUL6vQrtjMVRUX r1qtayqodT0lusnMxLpdq1NV/JLxJcySr1qqya2mUl57HpfnXLV6Gv90yv/wdY5pXLlvlqgDfvhd uvNBpuqZ3xLN30SC8E3ht7W1F4S/AOHyW7qUZU5lpJKE7+wXjLLKnXkNzZXzFclFi5sWNy5mlfOq a6oZZWFYE8oJiyFTKBiOhgzhhvlLRlFz5ZJcpExwuUhdpBvFNh8wb2NTyJHrAvck9ridLiFE/KRc ZIwAxuLqhaN4aVVLLlIkVblIG1ONIqvfTmM5PbJrDvDgPoP1+fwonpWXw7Gslt05P1mJuHxlb1UV Wf5ns9srwL4wwUAeB7y4mSsVkaWUQf68ILDoZlRawplzqHwKOeCeVXVaSWV6KlVEFCCTiHzmTjE+ VueJiUte/fyj6X878bv06O++hwf/HavwE6PV69Lh9A//mN7y6/fwcx++hlv/5cuXD7S0mu+ZbFi0 4xsPj1yzsFPwv9jcOtQ+b1Fh9fgdYtUS9pvpoXM3BsXCz+PFk0dx3kN/SZe992b6thewC/PpP6af /BX+5/ewGn8H46Ppk6dOph/4yuK6qmumrt97/efwlqGVjY07LG2jLx1aW9u29uS1h3vrlyGyigFE E3PwxtdnBrr5mr+onWpEfl/6Te6LKPMjawyqPYqDAGooPpLjqfzpRrQmizUbkv0tVaawhxtBfiAh DeydqEWxGuXB87ji2yjAAALAeQDz3G9QAYQFADaTMDCLVXciN/gv4D6FQkwK1bC5qBdcK4dQI6TX Buktgef5HLryIfg1gDGA0UNYKYQ1gf/78GwCnAlIJx9gwEUM5Ps54g95GCDsLmUKcL6GVrINaB/4 u8EUgtkAZimYtWBaSLpgLrI/wSR8N8Rj2Z+g45CGDtLbAa5F8e0rv8VDaDmk1cGkrmwENw64IpTj T1CehVkD/ucBX4CwEDznq65DPVAV87CFiXFuxVOqAtVvVL9Rn9P+XPeSIce4mh8RsOkd833mt6wL bY/azzqVrsWextxS7yrfN/2rA9rAQ8HvhpORb0f56IMFbxZWFfbGH0h+t7i49N7Sb5XVVtxROVpV XfVvqUPVunnXz/t5zer56+c/sMBca6vtk+6ve6bur/WphesWPtQQbKhveKnh9cYNjc8tYhf9fvFb SzszX3QpWgdcaBLGQkJfJ9BqaC6/5v6AFIh8wmrmm2Cz9HtfT22WxvPSJwIzMO3cloFZNIzuzcAc 8mJ1BlYAHM7ASpSHGzKwCv0Ab8rAapRkyjKwBn2G6c3ABuZB5vezba9c8ekMjBGvOJWBGaRSvJKB WZRSvJaBOcQr1RlYAbA9AyuRSRnOwCq0WVmZgdXIoXwkA2vQQuWJDGzArUoi+4k5FvLSq5soTGpI UK+gsJL6b6CwivrvoLCawv9EYQ2pQ/VdGRjqUP1eBoY61NgyMNShJpiBoQ4192ZgqEPN0xkY6lDz rxkY6lBzKQNDHWpfzMBQh9o/Z2CoQ92NFNaSchrNFNaRshm9FNZT/ziFjRSuprBAymaU39cCsNnY QWErxdlE4RyazjCFbdT/Vgo7aVz5fd0U52EK51KcJynso/A0hYMU/wyFCygsv2MRhc8RWC2X/48U lvP6gMB66s8rKUzeBfFm9AQSUQkiynMqAOpAMD2D24oG0A4wo2gXGqQ+C+FpGGBi94B/P8WIQ0gd 2gZ/IloBfpsh/igaoU994PYB9k6wewGzA8K3U18RLQP3Boo1AH49kBLB34zGIKUeiPPx/Kv/h9ji x+JXQw8leY9kyimicihBEhUDFIXU+9FGCB2A8AG0CXLJ/x/S/3upxVEpunFOXDnm1XjtaCXk1vE/ lr6fhvSAGaX12ws42+mbbAU/Usb//bchqe6gKcrxVsFTPzyRryFCuUYpbl8m5x3gm6ApiDTtLfSN RainAajVHbRc/RQ7/r8uyd/idcxCDRTzBlrWzfDcBu+6iX4fElo0W9Id8GX7IJac6zCtMZJqIfis pvijmdK30HojNUhKLcJXSsFXKkGd9E1EWq8knTHaPuX6ket/E01xlNYHeR6kdbCd1lq23jbQuNk6 bYRabYEeIMcdnhMySNtXL+SykaYof4sbaF4bwf7kfOVngrsR3neMvkUvxR0Au5eGD9I2vmv2q8l5 9WdS2JhJS3570j/Fv3nzAVqbu2hf6Ie2L9LWtmE2r08q146/Sfv/vpaupt47+52HaVuSW9XG2Zby yW9/tR1/tFzz5tQBeRP5XUZpftk2SNKX37UXfG6gbz5Ae9gnv6lc0z0fqdW+TK/4eN8gtToKeGM0 JintztmWK6dDMLcBxn/7jZ4QS5LJCrFjS5/YOrBjYHTXYJ+4cGB4cGC4Z7R/YEdcrNu2TVzRv3nL 6Ii4om+kb3hnX2+8o39734i4rO8GccXA9p4dK/o2j23rGc7Gr/5YsJgJr17dNzwCaYrl8WSxGG3t 3zg8MDKwaTT/Y/hz0eKlN9JQCKRh7StbOz6efP+I2COODvf09m3vGd4qDmz6u28j9u8QRyFs1Y7+ 0b5eceVozyik1LOjNzEwLA5AyLC4cWBsx+hwf99I/O8lMuvXQayG4Z4b+ndsFts2berf2CcWkUR3 bOvbBVGH+0cGdhSKq/s3jkLyLT3DvX07RsXiVGlJ58CYuL1nlzg20gflgfJvGoCQnhFxsG94e/8o KduGXbSkjata6iB0mD4MDg/0jm0cJW9xw5b+jVvmxAW3f8fGbWO9EHV0QOztHxncBhnAq0GsfkDY CFiQfVwUs5kP7Ni2S4z254t92zeQWFfT2pHF/sQiUfRe8s7DfSNQVRtJpczJntZxJq15tATRfshl tG87qcHhfsi1d+CGHdsGeuZmCoXukYsKH2H2awyMjQ6OjYq9fTtJ5QLOlr5tgx97I5jTBugY0EN7 F/R+bIDWfT2077fpyJ8Ny47lvfIYzT7IHme/wT4H5hT7LPvkP6iRf1Aj/6BG/kGN/IMa+f9HjXxk LL8Kk6f+Twz71UfwSL+YO8rLrf+T09wGOLvmPnNerphr5hZx88FOfSSHHZDu30tlGdg7aS3K/XoL nsBfZBH9tnWANZwZM3r+mxSuwiz6b3+nUAf7zhRb4Kuty2HPo/Xs2+gw+1v0BhgOCeAjAFQLZhDg K2AUV55nfzXV2FgiTYMbi1N3MppfcooETLo8Jd9gf8U8iSLk2mD2jUmbm4b8crK+PgNUVMnAVEFR yRt1WvaX6E9gGPaX7BvQ0misqWi85GKdATww+0+Ixxj50BH2F2gCDIMk9mdTwXDJ4efY70P4d9nv QFWRaN+ZNJhKIMFvsyeRGfnYE+wzmZBnpoymElQ3wt6JMHoe7LNgzoG5CIZDA+zjaC+Yg2COgeEQ D7YPTAJMG/Fhj7JHoZyPkjUosBNgBsAcBMNBFX4N/LcSm/0qez3Kg7h3kN0lcD/L3k3dr4DrAvdL 4O8F94vwTNzDmeeHwCXhD2b8H4BnG7j3Z9z7wN8N7r3wTNwvZJ53smM03mjGPcKOTHp9Qp0XwkUw STAsQPcAdA9U3T2kRYCN2U+x22hOx8EtAXe77EJ17Zn0B+g32jNld5YcgSrdA1W/B2puD9TcHnIp NLs7i7NbxilidwPObsDZDTi7oVaS7AjkN0JWZsAWwIhgWKj3Eaj3EaoTZATwRwCf+H8a7ENgjpAn 9gaox3wo1QH2+smoDxrZ5qmUVFJ7mt0EVS2xm6acuSUHrz5ptKQhgmvMuDzB7aOhfVMaPfHtm3Ll yi5gba0zshvRzWAYZAU7CKYMTAMYjt04GUz4nmWXoe1qJBl9e5m97F5ur4JLNmDzc2wJalcjaJJm tgjVAEK+r7sGV67XDGrGNaygETVJjaRp1ygG2L3sQZb1sQm2lm1ju1kFkQFQVZeS/bFFyurSQ7oj ugnd87qzOsWE8nnlWeU55UWlQhbMaleuVw4qx5WHlEeUGnLRMrNeN6gb17GCTtQldZKuXafwqfCR un3sBrJmCbYAZhDMITAc1HE3+IvsdWC64Wt0Q1VcB/4IbARPApizAJ8DVwFPPODxgMeDLw++PPgi sElIO5j1YAYzocrZkGwcgn+RhICJQKgRfMmq4jmwLxIIzFJ4MsCTAZ4MgHWWuQwlFMAWwbSDYanf OTDQasDOhiUz4evBKGn4RYqTDZNIXOay1BN5Ph9PEOFefCgfSzW1dSVSHlhms7k70B3qjnY/yg0E BkID0YFHubZAW6gt2vYoVxuoDdVGax/lEoFEKBFNPMr5Ar6QL+p7lDvYcqzluZbXWrjuloGWvS1s JRHqmIwlS6ibFyLuM5NOV0klXzePOQav0w32YTBvgGGRD+wEmFowA2A45hjYPuYp8CV77U+hNjDd YBQQ4ykyvIDty4QR/8M0jEAknPlIOAsv/uRkdWlb3VIYcrvBHGbIImsC7FowBFuGjlH/CbDPUf+2 DP4R6u8DOxuHhQFuHR3m1kH3WweD/zrUDWYQjAK9xq6ByWENSRlsH5hBMMfAcOw6+FvDrmGegr8n mSfZQslQnONDNhvMM2aTWqgTGD20AQP+KrXvp/YBatdSOygZlxreXWr45lLDZ5YaIgAwUZjyDPge avslXZ3h6TpDW50hv84AqdmRHxmYHGoriY3/QO1l1C6UrH7D+37Df/kN/+k3/LPfMOQ3zPeTeB7o uwbGSm0dsfG91F5K7bCk8xle9hnW+AyVPkOdAT+CIXdUT20vtd3Exn9+mm/gkeY0/jNQ2gYGT9bk +6YZRB18ZbKmDpz0ZM0icGYmax4B54PJmrt9X8fvYzql4Xcng+d9dTn4El7Ckef/yrj/iZego+Be BHczuI+hGhwC9yuTNbcQ/C9D/Afh+UsoT03wv4jaabzDeAn1/+dMvIcnCzdArg9NFu6CXB9EhTTX +yYLz4Pv3ZOFB8D5/GThNnAOToZIAa+frCnw1ZnIjdQMwd2IQgwpSUsmx8WQ8jZwF8mRGycLSawG ksE0XjgZKAYnQkr5dRxA7TQ732SAvmQuCtAkPChAC+1GIeoaMU8Lb0B51FVPBm6BVJRPh877/lpz mrw4+gvmJx/x/ebr8H6r4fHXeMnkUd8PT5HqmvS9VjiNQyd8Pwic9r0UnMarJ33PF06rIeC5wmkG P+M7DpU8AbgMPuE7VrjZ91SAhj4agFD41IdrinwPBdb5HgjB86TvlsKvk2Kg7fDGqyG4s3CBr6Xm qK8pNI0hWKohF05ofdWBYV8KvKum8ZKpo77i4DQpShLSOHrCVwA5hgO0KKsqn2XKkQqPSYWqUdUG 1WrVctU8VamqSCWqclUelVVtVgtqo1qv1qrVaqWaUzNqpLbS4/Nkw8uqFIij5IjNUVhgiM3Ie3kM VjPQdyYsbDPTvLIeT5ibUXNH/URlrHladWXFRFWseULdfs3a4xjf1QlPE8xt0xh1rIUGSrz2uSfM C9eeQhgn9t3pJu7ufXd2duLmiec3ouYN4sS7K+E9tMvXTSgC9Q5k21nrqDUvMKWaGj7BWp+x52zJ Oz6yQe/Inbi3eeXaia/ldk6UEOBKbmfzxKKV4rVrTzFDzEBjwylmkDida0/hm5ihxhXEH9/U0DmL hvKYQUBDNcQhaFMoj6ChPDxF0VooGjTTvMaG43l5MtKLeAlBgubzIkXaLKcVhCwgrXbiABrjRUGa VpDxEjRoD3Ji/NzE9AjzNDFej2hiHoJ0PBQClMIQQTleGQKE46FKGnz0anAgJBenE4VoPiHcSfPB +CpOVMaBVpDBYdSAE/t/+eur/18g46men/dubOwLNK4PNPaBWT/x2Z1bHBPjG0TxeO/PSYA4wYbX b9i4hbg9fRM/D/Q1TPQGGsTjPRs/IXgjCe4JNBxHGxs71h7fKPU1TPZIPY2BnobOqcf2Lmz+SF4H ZvNauPcTEttLEltI8nqs+ROCm0nwYySvZpJXM8nrMekxmlfzinrc3L72uBrVdy68VnanGJ0W+sN6 t7+z3iYMLqCdY57f8U/uZzkE05Yu1jmhD9RPGMCQoKK6ojoSBL2TBBnBm88EOf5pnt/9LP5qJkgA b1OgHsWQo7G/YfZ/ZGRklJixsRjYo2MO6jcKnda/snmiafm6tRM1EzWNE9L6hk4qEDWW+S1cKwnP 1bxWwwzU7K05WHO45liNYmysE7zNz+W9lsd05w3k7c07mHc471iekgRcu/aEVHM470957Bi0JjwK v8YGmucYuPBPHkfHRsgPQQYjYOTsYmOxhWvr8tBGlmgJYsG2gAmAKQWzEowCfQvsfwPzGzD/BYZD nwL7bjBfBjNFfNgitqjR0d9AcuyMkUHHwZZMJctLqqbB7dkkuyvXyW7jMtmtqStxgDtZW6qt44Hw xuhZsL8L5mdgfg/mAzAKtoQtoYmPya22cwSNxDAUn0gMjRJrJDaKiRgZJtU9OhKLoRFZzRaGL0Av cf9ou0d4ZAxBVcAHAQeQqO8IiTZG3OyPBMBQ/H8AEltMlgplbmRzdHJlYW0KZW5kb2JqCgoxOCAw IG9iagozNDgyOQplbmRvYmoKCjE5IDAgb2JqCjw8L1R5cGUvRm9udERlc2NyaXB0b3IvRm9udE5h bWUvQkFBQUFBK1RpbWVzTmV3Um9tYW5QU01UCi9GbGFncyA2Ci9Gb250QkJveFstNTY4IC0zMDYg MjAwMCAxMDA3XS9JdGFsaWNBbmdsZSAwCi9Bc2NlbnQgODkxCi9EZXNjZW50IC0yMTYKL0NhcEhl aWdodCAxMDA2Ci9TdGVtViA4MAovRm9udEZpbGUyIDE3IDAgUj4+CmVuZG9iagoKMjAgMCBvYmoK PDwvTGVuZ3RoIDUzNi9GaWx0ZXIvRmxhdGVEZWNvZGU+PgpzdHJlYW0KeJxd1M2OmzAUBeA9T8Fy uhiB73XMjBRFyiQTKYv+qJk+AAEnRWoIImSRty/nHreVupjRwVz7fpiYYrPf7vtuKr6N1+YQp/zU 9e0Yb9f72MT8GM9dnznJ266Z0pX9by71kBXz3MPjNsXLvj9dl8us+D7fu03jI39at9dj/JQVX8c2 jl1/zp9+bA7z9eE+DL/iJfZTXmarVd7G07zO53r4Ul9iYbOe9+18u5sez/OUfwUfjyHmYteOlOba xttQN3Gs+3PMlmW5ype73SqLffvfvUo45XhqftbjXOrm0rL0YTVnsVwJsloOC2TPGhtfWF4ocuC4 R64sS4n8whrLr8wvyGvW25pvHLc1N8xm2LLG6t+Zd8g71lRzdiUz+jr6dYtMf3hFpr+C09FfWT39 AWs6+gP6OvqDQ6Y/bJDpD3A6+oOtQ3+A09Ef3pGT3wz0BzPQX2FPhP4KfSX518j0e/SVtP94Xkl+ 7JvQL+glyf+GTH9l9fSrjSc/9kfoF8v0C55L6K/wLEK/2jj9an3pV/iVfoVfkx99Nf1+8OxKv2I/ NfnhUfoVvZR+wbvQ5IdN0+8HfZV+wZ4o/Qtbn36PfVD6xQz0i62f9h97q/QL5vrkx3v09C9g8PBL 6dDLKzM8nn7Bs3j6veXkx/v1yY9env65DQ5gOmk4ivhW/DnieXMfx/l42wfFzjVOdNfHv9+c4Tpg lv39BoNKE/sKZW5kc3RyZWFtCmVuZG9iagoKMjEgMCBvYmoKPDwvVHlwZS9Gb250L1N1YnR5cGUv VHJ1ZVR5cGUvQmFzZUZvbnQvQkFBQUFBK1RpbWVzTmV3Um9tYW5QU01UCi9GaXJzdENoYXIgMAov TGFzdENoYXIgNzIKL1dpZHRoc1s3NzcgNTU2IDMzMyA0NDMgNjY2IDU1NiA3MjIgMjUwIDU1NiA3 MjIgNjEwIDY2NiA3MjIgNzIyIDcyMiA5NDMKNjEwIDU2MyAyNzcgMzg5IDI3NyA1MDAgMzMzIDQ0 MyAyNzcgNTAwIDUwMCA1MDAgNTAwIDMzMyA0NDMgNTAwCjUwMCAyNzcgNjEwIDUwMCA1MDAgMjUw IDUwMCA3MjIgMjc3IDc3NyAzMzMgNDA4IDUwMCA1MDAgNTAwIDUwMAo1MDAgNTAwIDUwMCA1MDAg NDc5IDUwMCAyNzcgNDc5IDcyMiAyNTAgNzIyIDcyMiAxODAgMzMzIDI3NyAzMzMKNTAwIDUwMCA0 NDMgNDQzIDMzMyA3MjIgNTAwIDQ0MyA5MjAgXQovRm9udERlc2NyaXB0b3IgMTkgMCBSCi9Ub1Vu aWNvZGUgMjAgMCBSCj4+CmVuZG9iagoKMjIgMCBvYmoKPDwvRjEgMjEgMCBSL0YyIDE2IDAgUgo+ PgplbmRvYmoKCjIzIDAgb2JqCjw8L0ZvbnQgMjIgMCBSCi9Qcm9jU2V0Wy9QREYvVGV4dF0KPj4K ZW5kb2JqCgoxIDAgb2JqCjw8L1R5cGUvUGFnZS9QYXJlbnQgMTEgMCBSL1Jlc291cmNlcyAyMyAw IFIvTWVkaWFCb3hbMCAwIDU5NSA4NDJdL0dyb3VwPDwvUy9UcmFuc3BhcmVuY3kvQ1MvRGV2aWNl UkdCL0kgdHJ1ZT4+L0NvbnRlbnRzIDIgMCBSPj4KZW5kb2JqCgo0IDAgb2JqCjw8L1R5cGUvUGFn ZS9QYXJlbnQgMTEgMCBSL1Jlc291cmNlcyAyMyAwIFIvTWVkaWFCb3hbMCAwIDU5NSA4NDJdL0dy b3VwPDwvUy9UcmFuc3BhcmVuY3kvQ1MvRGV2aWNlUkdCL0kgdHJ1ZT4+L0NvbnRlbnRzIDUgMCBS Pj4KZW5kb2JqCgo3IDAgb2JqCjw8L1R5cGUvUGFnZS9QYXJlbnQgMTEgMCBSL1Jlc291cmNlcyAy MyAwIFIvTWVkaWFCb3hbMCAwIDU5NSA4NDJdL0Fubm90c1sKMTAgMCBSIF0KL0dyb3VwPDwvUy9U cmFuc3BhcmVuY3kvQ1MvRGV2aWNlUkdCL0kgdHJ1ZT4+L0NvbnRlbnRzIDggMCBSPj4KZW5kb2Jq CgoxMSAwIG9iago8PC9UeXBlL1BhZ2VzCi9SZXNvdXJjZXMgMjMgMCBSCi9NZWRpYUJveFsgMCAw IDU5NSA4NDIgXQovS2lkc1sgMSAwIFIgNCAwIFIgNyAwIFIgXQovQ291bnQgMz4+CmVuZG9iagoK MTAgMCBvYmoKPDwvVHlwZS9Bbm5vdC9TdWJ0eXBlL0xpbmsvQm9yZGVyWzAgMCAwXS9SZWN0WzIx MyA3NC45IDMxOS44IDg4LjddL0E8PC9UeXBlL0FjdGlvbi9TL1VSSS9VUkkobWFpbHRvOmVnb2l0 ekByYW1hdHRhY2submV0KT4+Cj4+CmVuZG9iagoKMjQgMCBvYmoKPDwvVHlwZS9DYXRhbG9nL1Bh Z2VzIDExIDAgUgovT3BlbkFjdGlvblsxIDAgUiAvWFlaIG51bGwgbnVsbCAwXQovTGFuZyhlcy1F UykKPj4KZW5kb2JqCgoyNSAwIG9iago8PC9BdXRob3I8RkVGRjAwNDUwMDY3MDA2RjAwNjkwMDc0 MDA3QTAwMjAwMDQxMDA3NTAwNzIwMDcyMDA2NTAwNkIwMDZGMDA2NTAwNzQwMDc4MDA2NTAwNjEw MDIwMDA0MTAwNzUwMDcyMDA3MjAwNjU+Ci9DcmVhdG9yPEZFRkYwMDU3MDA3MjAwNjkwMDc0MDA2 NTAwNzI+Ci9Qcm9kdWNlcjxGRUZGMDA0RjAwNzAwMDY1MDA2RTAwNEYwMDY2MDA2NjAwNjkwMDYz MDA2NTAwMkUwMDZGMDA3MjAwNjcwMDIwMDAzMzAwMkUwMDMyPgovQ3JlYXRpb25EYXRlKEQ6MjAx MDA0MTIwNjUzMTkrMDInMDAnKT4+CmVuZG9iagoKeHJlZgowIDI2CjAwMDAwMDAwMDAgNjU1MzUg ZiAKMDAwMDA2MjEzOCAwMDAwMCBuIAowMDAwMDAwMDE5IDAwMDAwIG4gCjAwMDAwMDE1MzYgMDAw MDAgbiAKMDAwMDA2MjI4MiAwMDAwMCBuIAowMDAwMDAxNTU3IDAwMDAwIG4gCjAwMDAwMDM0MzYg MDAwMDAgbiAKMDAwMDA2MjQyNiAwMDAwMCBuIAowMDAwMDAzNDU3IDAwMDAwIG4gCjAwMDAwMDQ3 ODUgMDAwMDAgbiAKMDAwMDA2MjcwMCAwMDAwMCBuIAowMDAwMDYyNTg4IDAwMDAwIG4gCjAwMDAw MDQ4MDYgMDAwMDAgbiAKMDAwMDAyNDc0MSAwMDAwMCBuIAowMDAwMDI0NzY0IDAwMDAwIG4gCjAw MDAwMjQ5NjAgMDAwMDAgbiAKMDAwMDAyNTQ3NiAwMDAwMCBuIAowMDAwMDI1ODQyIDAwMDAwIG4g CjAwMDAwNjA3NTggMDAwMDAgbiAKMDAwMDA2MDc4MSAwMDAwMCBuIAowMDAwMDYwOTgxIDAwMDAw IG4gCjAwMDAwNjE1ODcgMDAwMDAgbiAKMDAwMDA2MjA0MCAwMDAwMCBuIAowMDAwMDYyMDgzIDAw MDAwIG4gCjAwMDAwNjI4NDQgMDAwMDAgbiAKMDAwMDA2Mjk0MiAwMDAwMCBuIAp0cmFpbGVyCjw8 L1NpemUgMjYvUm9vdCAyNCAwIFIKL0luZm8gMjUgMCBSCi9JRCBbIDxFNDgzODc2MDU2RDU4OTI2 NTUyQTkzOUQzREJFNTJDNT4KPEU0ODM4NzYwNTZENTg5MjY1NTJBOTM5RDNEQkU1MkM1PiBdCi9E b2NDaGVja3N1bSAvNTBBMzk4QTAzMTAyODkzNTZFNEI5QkQ3QkVBNUQ1MkEKPj4Kc3RhcnR4cmVm CjYzMjQzCiUlRU9GCg== --=_48c3bc13d5e7b91fb36721a79011320b-- From owner-freebsd-hackers@FreeBSD.ORG Tue Feb 21 09:47:41 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B5466106566B for ; Tue, 21 Feb 2012 09:47:41 +0000 (UTC) (envelope-from egoitz@ramattack.net) Received: from proxypop04.sare.net (proxypop04.sare.net [194.30.0.65]) by mx1.freebsd.org (Postfix) with ESMTP id 719788FC08 for ; Tue, 21 Feb 2012 09:47:41 +0000 (UTC) Received: from www.saremail.com (unknown [194.30.0.100]) by proxypop04.sare.net (Postfix) with ESMTPSA id 3E9DD9DC55C; Tue, 21 Feb 2012 10:47:40 +0100 (CET) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Date: Tue, 21 Feb 2012 10:47:40 +0100 From: egoitz@ramattack.net To: Nathan Whitehorn In-Reply-To: <2302656984477a6b671f298f965fcb88@ramattack.net> References: <4F429FE8.303@freebsd.org> <2302656984477a6b671f298f965fcb88@ramattack.net> Message-ID: <429cc77aeae02a144039b5129d926f18@ramattack.net> X-Sender: egoitz@ramattack.net User-Agent: Saremail/0.6-svn Cc: freebsd-hackers@freebsd.org Subject: Re: Jumpstart on FreeBSD 9.0 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Feb 2012 09:47:41 -0000 Should say too... that I thank a lot to all people who is helping me... thanks a lot mates... From owner-freebsd-hackers@FreeBSD.ORG Tue Feb 21 10:49:44 2012 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 742621065672; Tue, 21 Feb 2012 10:49:44 +0000 (UTC) (envelope-from tevans.uk@googlemail.com) Received: from mail-vw0-f54.google.com (mail-vw0-f54.google.com [209.85.212.54]) by mx1.freebsd.org (Postfix) with ESMTP id 0C8998FC1C; Tue, 21 Feb 2012 10:49:42 +0000 (UTC) Received: by vbbfa15 with SMTP id fa15so5936151vbb.13 for ; Tue, 21 Feb 2012 02:49:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=laWO2ASevVpt+5UENmxb5yvyH1UoCjEbrB6XV0+dtMU=; b=jMbz+MXmnHHcU9lbQgavBrWDIK9X1PEgz+fwNXvz3NgGc20zWamL/hjYJ7cZMjSMzb Dv8HkL/K8qh1+FhoR0vFeTYTC37oifnyyIZ08wI9+WY5JpAWIr4QqaelvNyY3vMYWM30 xIk66jpJbwsmuQ37bZGchdIh0Vt5qPZP4Foug= MIME-Version: 1.0 Received: by 10.52.94.33 with SMTP id cz1mr9350775vdb.132.1329821382375; Tue, 21 Feb 2012 02:49:42 -0800 (PST) Received: by 10.52.91.210 with HTTP; Tue, 21 Feb 2012 02:49:41 -0800 (PST) In-Reply-To: <4F42B6D9.9000400@FreeBSD.org> References: <4F3E8225.9030501@FreeBSD.org> <4F3E8C26.3080900@FreeBSD.org> <4F3EA5F2.9070804@gmail.com> <4F3EAE5F.6070903@gmail.com> <20120217.220802.988.2@DOMY-PC> <4F3EDEBC.7040703@gmail.com> <4F3EFB70.5000102@FreeBSD.org> <4F42B6D9.9000400@FreeBSD.org> Date: Tue, 21 Feb 2012 10:49:41 +0000 Message-ID: From: Tom Evans To: Doug Barton Content-Type: text/plain; charset=UTF-8 Cc: hackers@freebsd.org Subject: Re: 8 to 9: Kernel modularization -- did it change? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Feb 2012 10:49:44 -0000 On Mon, Feb 20, 2012 at 9:10 PM, Doug Barton wrote: > On 02/20/2012 06:44, Tom Evans wrote: >> Whatever happened to POLA? This change surprised me, wasn't mentioned >> in /usr/src/UPDATING, > > You're supposed to compare your existing kernel config to the new > GENERIC every time you do a major version upgrade. That would have made > the change quite obvious. > "Dumb stupid user" - great argument Doug. As I am just a dumb stupid user, all I looked at were the kernel release notes for 9: http://www.freebsd.org/releases/9.0R/relnotes-detailed.html#KERNEL Where none of this is mentioned. At all. I guess as this only affects dumb stupid users, its not a big deal. Tom From owner-freebsd-hackers@FreeBSD.ORG Tue Feb 21 11:06:55 2012 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx2.freebsd.org (mx2.freebsd.org [69.147.83.53]) by hub.freebsd.org (Postfix) with ESMTP id 696A0106566C for ; Tue, 21 Feb 2012 11:06:55 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from 172-17-197-151.globalsuite.net (hub.freebsd.org [IPv6:2001:4f8:fff6::36]) by mx2.freebsd.org (Postfix) with ESMTP id BA1B41502C2; Tue, 21 Feb 2012 11:06:54 +0000 (UTC) Message-ID: <4F437ACE.3070907@FreeBSD.org> Date: Tue, 21 Feb 2012 03:06:54 -0800 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (X11; FreeBSD i386; rv:10.0.2) Gecko/20120218 Thunderbird/10.0.2 MIME-Version: 1.0 To: Tom Evans References: <4F3E8225.9030501@FreeBSD.org> <4F3E8C26.3080900@FreeBSD.org> <4F3EA5F2.9070804@gmail.com> <4F3EAE5F.6070903@gmail.com> <20120217.220802.988.2@DOMY-PC> <4F3EDEBC.7040703@gmail.com> <4F3EFB70.5000102@FreeBSD.org> <4F42B6D9.9000400@FreeBSD.org> In-Reply-To: X-Enigmail-Version: 1.3.5 OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: hackers@freebsd.org Subject: Re: 8 to 9: Kernel modularization -- did it change? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Feb 2012 11:06:55 -0000 On 02/21/2012 02:49, Tom Evans wrote: > On Mon, Feb 20, 2012 at 9:10 PM, Doug Barton wrote: >> On 02/20/2012 06:44, Tom Evans wrote: >>> Whatever happened to POLA? This change surprised me, wasn't mentioned >>> in /usr/src/UPDATING, >> >> You're supposed to compare your existing kernel config to the new >> GENERIC every time you do a major version upgrade. That would have made >> the change quite obvious. >> > > "Dumb stupid user" - great argument Doug. Umm ... I didn't call anyone dumb, stupid, or any other names. It's been the common practice for major version upgrades since day 1. The whole reason we bump the major number is so that we can make changes that are incompatible with the previous major version. > As I am just a dumb stupid user, all I looked at were the kernel > release notes for 9: > > http://www.freebsd.org/releases/9.0R/relnotes-detailed.html#KERNEL > > Where none of this is mentioned. At all. I have nothing to do with the release notes, you should talk to hrs@ if you find them deficient. OTOH, some things are so fundamental that I can see how it wouldn't occur to him to include the detailed procedure in the release notes. Meanwhile, one could argue that this topic should be mentioned in more detail in the handbook. Feel free to create a PR for this and if no one else gets to it, I will. Doug -- It's always a long day; 86400 doesn't fit into a short. Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ From owner-freebsd-hackers@FreeBSD.ORG Tue Feb 21 08:16:44 2012 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1EC131065675; Tue, 21 Feb 2012 08:16:44 +0000 (UTC) (envelope-from alexander@leidinger.net) Received: from mail.ebusiness-leidinger.de (mail.ebusiness-leidinger.de [217.11.53.44]) by mx1.freebsd.org (Postfix) with ESMTP id AAABE8FC0C; Tue, 21 Feb 2012 08:16:43 +0000 (UTC) Received: from outgoing.leidinger.net (p5796D1ED.dip.t-dialin.net [87.150.209.237]) by mail.ebusiness-leidinger.de (Postfix) with ESMTPSA id 4F77A844855; Tue, 21 Feb 2012 09:16:26 +0100 (CET) Received: from webmail.leidinger.net (webmail.Leidinger.net [IPv6:fd73:10c7:2053:1::3:102]) by outgoing.leidinger.net (Postfix) with ESMTPS id 6864556BF; Tue, 21 Feb 2012 09:16:23 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=leidinger.net; s=outgoing-alex; t=1329812183; bh=Oo8ZFZl/ESjILIyMoMOwi2pkpQqiDjKLlmihQCbsNHA=; h=Date:Message-ID:From:To:Cc:Subject:References:In-Reply-To: Content-Type:MIME-Version; b=X9inFLt1FdbDTVyAfkmg9OPs9I6saED2W8wKhJS7NGUGFtWRjFXktxBDZVZzBBfbc IjK0iPVJvMVmusfCaKYPRvK40cb86CKGVI2hDrf/sNc+iSBp+3x8mfJTj3m6nQJsIw zgVEwgJ8Ch5hj8dMXuSMLcJmXmpXzmo3/6264+oGMF1Z7p4Tv3xjRUVPbN6CQvJ+7J 9k58YRNVMfhET2/Zdg/8O+9tcu0i3vEVJoOfSqalu9DVvRt/vDO9buIlP0hMgE7DDW EfHnoI1PGyvklHRSUjwbYvYvnsTOAYQaMOBKwKqmB7JrpLjDUIV4YaAMidsYOHRZtK OTuW+GxJwOCqw== Received: (from www@localhost) by webmail.leidinger.net (8.14.5/8.14.4/Submit) id q1L8GHun020018; Tue, 21 Feb 2012 09:16:17 +0100 (CET) (envelope-from Alexander@Leidinger.net) X-Authentication-Warning: webmail.leidinger.net: www set sender to Alexander@Leidinger.net using -f Received: from 85.94.224.20 ([85.94.224.20]) by webmail.leidinger.net (Horde Framework) with HTTP; Tue, 21 Feb 2012 09:16:17 +0100 Date: Tue, 21 Feb 2012 09:16:17 +0100 Message-ID: <20120221091617.Horde.mjVXN5jmRSRPQ1LRKcRkg0A@webmail.leidinger.net> From: Alexander Leidinger To: Mehmet Erol Sanliturk References: <4F3E8225.9030501@FreeBSD.org> <4F3E8C26.3080900@FreeBSD.org> <4F3EA5F2.9070804@gmail.com> <4F3EAE5F.6070903@gmail.com> <20120217.220802.988.2@DOMY-PC> <4F3EDEBC.7040703@gmail.com> <4F3EFB70.5000102@FreeBSD.org> <4f3ff151.FznGzC6RC0a5qBKx%perryh@pluto.rain.com> <4F403C5E.4000104@FreeBSD.org> <4f411fbc.5xpQwqtOGVzi8G4D%perryh@pluto.rain.com> <20120220151409.Horde.NYT-HpjmRSRPQlUxo1tMYtA@webmail.leidinger.net> In-Reply-To: User-Agent: Internet Messaging Program (IMP) H4 (5.0.18) Content-Type: text/plain; charset=utf-8; format=flowed; DelSp=Yes MIME-Version: 1.0 Content-Disposition: inline X-EBL-MailScanner-Information: Please contact the ISP for more information X-EBL-MailScanner-ID: 4F77A844855.A058B X-EBL-MailScanner: Found to be clean X-EBL-MailScanner-SpamCheck: not spam, spamhaus-ZEN, SpamAssassin (not cached, score=0.447, required 6, autolearn=disabled, AWL -1.66, DKIM_SIGNED 0.10, DKIM_VALID -0.10, DKIM_VALID_AU -0.10, J_CHICKENPOX_74 0.60, RCVD_IN_SORBS 1.00, RCVD_IN_SORBS_WEB 0.61, T_RP_MATCHES_RCVD -0.01) X-EBL-MailScanner-From: alexander@leidinger.net X-EBL-MailScanner-Watermark: 1330416989.2586@dEPbEkqmgf7Uv+PNRvQChw X-EBL-Spam-Status: No X-Mailman-Approved-At: Tue, 21 Feb 2012 12:29:21 +0000 Cc: sendtomatt@gmail.com, rank1seeker@gmail.com, dougb@freebsd.org, perryh@pluto.rain.com, hackers@freebsd.org Subject: Re: 8 to 9: Kernel modularization -- did it change? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Feb 2012 08:16:44 -0000 Quoting Mehmet Erol Sanliturk (from Mon, 20 Feb 2012 11:57:00 -0500): > On Mon, Feb 20, 2012 at 9:14 AM, Alexander Leidinger < > Alexander@leidinger.net> wrote: >> The goal of my work is to produce something like GENERIC+more, just as >> much as possible loaded as kld's (the "+more" part is the result of a poll >> I did on stable@, it contains only stuff which can not be loaded as a >> kld, and I provide a loader.conf which disables the parts which would cause >> a major change in behavior). Currently I'm doing some compile testing, I >> should be able to provide something for review soon (on current@). > I think , inclusion of a scheduler ( 4BSD , ULE , etc. ) selection facility > into loader.conf > will be a useful improvement , because it seems that schedulers are not > equivalent . The scheduler as is currently a compile time option and can not be loaded as a module, as such I can not provide such a solution within my current work (= creating a kernel config which loads everything as a module what is available as a module _now_). Bye, Alexander. From owner-freebsd-hackers@FreeBSD.ORG Tue Feb 21 09:05:24 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6DCF2106564A; Tue, 21 Feb 2012 09:05:24 +0000 (UTC) (envelope-from vermaden@interia.pl) Received: from smtpo.poczta.interia.pl (smtpo.poczta.interia.pl [217.74.65.207]) by mx1.freebsd.org (Postfix) with ESMTP id 1EAE08FC18; Tue, 21 Feb 2012 09:05:23 +0000 (UTC) Date: Tue, 21 Feb 2012 10:05:22 +0100 From: vermaden To: freebsd-hackers@freebsd.org X-Mailer: interia.pl/pf09 In-Reply-To: References: <4F3EE186.4020801@gmail.com> <201202181409.08859.hselasky@c2i.net> X-Originating-IP: 194.0.181.128 Message-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=interia.pl; s=biztos; t=1329815122; bh=kmwOHtHR5bhiMVZuwRExLZKoT5Rqmfon/cKRsOSPsWE=; h=Date:From:Subject:To:Cc:X-Mailer:In-Reply-To:References: X-Originating-IP:Message-Id:MIME-Version:Content-Type: Content-Transfer-Encoding; b=VfYJxUC0c4Xej3WV0V/5cC2PPcfl5l3sVhKdiCbEDAnn5d+PYBpOJyzuy96JJhyLl 5YuNBKP36PErjTHdF96Rni2GLjMV07wNIIx87fksMhbqQbCPtXwF3U3CnjZ3RHb8ud qQu5hc2vvrmKLZPILuKcI/ZqiQXLP30Kjl/Tg+so= X-Mailman-Approved-At: Tue, 21 Feb 2012 12:29:30 +0000 Cc: freebsd-current@freebsd.org, freebsd-stable@freebsd.org Subject: Re: devd based AUTOMOUNTER X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Feb 2012 09:05:24 -0000 Hi,=20 I have created a PORT at last, its in the 'port' directory in the usual pla= ce: https://github.com/vermaden/automount/ Its my first PORT so feel free to bash me about my mistakes ;) After latest 'commits' I think that its ready for day-to-day use. To make 'full advantage' of *automount* install these ports: sysutils/ntfsprogs sysutils/fusefs-ntfs sysutils/fusefs-ext4fuse sysutils/fusefs-exfat I will try to add these ports as OPTIONS in the Makefile later. I will have to think about creating a man page through ... Feel free to submit Your propositions about next changes/development, because I think that I already created everything 'I' needed.=20 Regards, vermaden --- =20 From owner-freebsd-hackers@FreeBSD.ORG Tue Feb 21 13:01:17 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AC61E106564A for ; Tue, 21 Feb 2012 13:01:17 +0000 (UTC) (envelope-from freebsd-hackers@m.gmane.org) Received: from plane.gmane.org (plane.gmane.org [80.91.229.3]) by mx1.freebsd.org (Postfix) with ESMTP id 64C7C8FC13 for ; Tue, 21 Feb 2012 13:01:17 +0000 (UTC) Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1RzpLB-0007kn-Aa for freebsd-hackers@freebsd.org; Tue, 21 Feb 2012 14:01:09 +0100 Received: from lara.cc.fer.hr ([161.53.72.113]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 21 Feb 2012 14:01:09 +0100 Received: from ivoras by lara.cc.fer.hr with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 21 Feb 2012 14:01:09 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-hackers@freebsd.org From: Ivan Voras Date: Tue, 21 Feb 2012 14:00:51 +0100 Lines: 35 Message-ID: References: Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigA41A7810DDA9E7CA5F07396D" X-Complaints-To: usenet@dough.gmane.org X-Gmane-NNTP-Posting-Host: lara.cc.fer.hr User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:10.0) Gecko/20120213 Thunderbird/10.0 In-Reply-To: X-Enigmail-Version: 1.3.5 Subject: Re: geom_aes X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Feb 2012 13:01:17 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigA41A7810DDA9E7CA5F07396D Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 20/02/2012 01:14, Oliver Pinter wrote: > Hi all! >=20 > What is geom_aes (sys/geom/geom_aes.*) (wherein differs form geli, > besides useses fewer geom layer and has a compiled in key), and who > can I find something from this geom module/layer? >=20 > How can I use this geom layer? Only added option geom_aes to kernel con= fig? It is an old, example GEOM module, and should not be used at all, ever. The same is true for geom_bde. --------------enigA41A7810DDA9E7CA5F07396D Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk9DlYMACgkQldnAQVacBcgOAQCg0fm1ciNKtFraJTwNdiay0tjI boQAniMLrM143Ag6nf1t5gEadwUXo5Ze =IRXf -----END PGP SIGNATURE----- --------------enigA41A7810DDA9E7CA5F07396D-- From owner-freebsd-hackers@FreeBSD.ORG Tue Feb 21 18:43:27 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 875EC106566C for ; Tue, 21 Feb 2012 18:43:27 +0000 (UTC) (envelope-from lacombar@gmail.com) Received: from mail-ww0-f50.google.com (mail-ww0-f50.google.com [74.125.82.50]) by mx1.freebsd.org (Postfix) with ESMTP id ECEC48FC16 for ; Tue, 21 Feb 2012 18:43:26 +0000 (UTC) Received: by wgbdq11 with SMTP id dq11so5816470wgb.31 for ; Tue, 21 Feb 2012 10:43:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=Ry0t7VG34xFjeCTHKFpLHtRr+dd504BvZ4q6Q7m11w0=; b=EOZLfK8WZT3jYdxzrZ8q5SbGtTmT/fmwCNj4l9p48/cKUBKB6Cp5iTdoz4mHNoyHJv /V34xY31DMcuHRqa1HGIvMpOxihuZo0Kuy1GqZwdLqBPNS7WpBIiwhzJOKyDHi28TSut TVFNvmer7v3JQBU9hGnARJgjnGXY/QYfkVj7U= MIME-Version: 1.0 Received: by 10.180.24.202 with SMTP id w10mr23397104wif.9.1329849805939; Tue, 21 Feb 2012 10:43:25 -0800 (PST) Received: by 10.216.158.133 with HTTP; Tue, 21 Feb 2012 10:43:25 -0800 (PST) In-Reply-To: References: Date: Tue, 21 Feb 2012 13:43:25 -0500 Message-ID: From: Arnaud Lacombe To: Ivan Voras Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-hackers@freebsd.org Subject: Re: geom_aes X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Feb 2012 18:43:27 -0000 Hi, On Tue, Feb 21, 2012 at 8:00 AM, Ivan Voras wrote: > On 20/02/2012 01:14, Oliver Pinter wrote: >> Hi all! >> >> What is geom_aes (sys/geom/geom_aes.*) (wherein differs form geli, >> besides useses =A0fewer geom layer and has a compiled in key), and who >> can I find something from this geom module/layer? >> >> How can I use this geom layer? Only added option geom_aes to kernel conf= ig? > > It is an old, example GEOM module, and should not be used at all, ever. > The same is true for geom_bde. > why ? - Arnaud From owner-freebsd-hackers@FreeBSD.ORG Wed Feb 22 09:42:53 2012 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B31E9106564A for ; Wed, 22 Feb 2012 09:42:53 +0000 (UTC) (envelope-from ivoras@gmail.com) Received: from mail-ee0-f54.google.com (mail-ee0-f54.google.com [74.125.83.54]) by mx1.freebsd.org (Postfix) with ESMTP id 366C48FC19 for ; Wed, 22 Feb 2012 09:42:52 +0000 (UTC) Received: by eekb47 with SMTP id b47so3271601eek.13 for ; Wed, 22 Feb 2012 01:42:52 -0800 (PST) Received-SPF: pass (google.com: domain of ivoras@gmail.com designates 10.213.35.9 as permitted sender) client-ip=10.213.35.9; Authentication-Results: mr.google.com; spf=pass (google.com: domain of ivoras@gmail.com designates 10.213.35.9 as permitted sender) smtp.mail=ivoras@gmail.com; dkim=pass header.i=ivoras@gmail.com Received: from mr.google.com ([10.213.35.9]) by 10.213.35.9 with SMTP id n9mr4645196ebd.106.1329903772200 (num_hops = 1); Wed, 22 Feb 2012 01:42:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=sender:user-agent:mime-version:content-type :content-transfer-encoding:subject:from:date:to:message-id; bh=tA9REDsbY2EVQJCsTfU94MN8LVPGdXkgx7aBaWXvPk4=; b=GQ1WsorKDKGnnIVBlmjAlaYDP6JWIOhDQoud5kwxWNp054mvog4LRO25T7IyeilvS/ uiT+7Cxtw/KK+6yqTWUlmSNpf4DVDBqWYXA87I9/toEuEwhWqFdESkKfIvDW2zKo0Tpo G4f30zZxNid0JN1887atAfVus+ENMa5I8SXMA= Received: by 10.213.35.9 with SMTP id n9mr3707420ebd.106.1329903772068; Wed, 22 Feb 2012 01:42:52 -0800 (PST) Received: from mintaka.cosmos (cpe-188-129-77-255.dynamic.amis.hr. [188.129.77.255]) by mx.google.com with ESMTPS id y14sm71394398eef.10.2012.02.22.01.42.48 (version=SSLv3 cipher=OTHER); Wed, 22 Feb 2012 01:42:51 -0800 (PST) Sender: Ivan Voras User-Agent: K-9 Mail for Android MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit From: Ivan Voras Date: Wed, 22 Feb 2012 10:42:44 +0100 To: "hackers@freebsd.org" Message-ID: Cc: Subject: PostgreSQL benchmarks (now with Linux numbers) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Feb 2012 09:42:53 -0000 The Dragonfly team has recently liberated their VM from the giant lock and there are some interesting benchmarks comparing it to FreeBSD 9 and a derivative of RedHat Enterprise Linux: http://leaf.dragonflybsd.org/mailarchive/kernel/2011-11/msg00008.html Other developments are described in their release notes: http://www.dragonflybsd.org/release30/ -- Sent from my mobile phone . Please excuse my brevity. From owner-freebsd-hackers@FreeBSD.ORG Wed Feb 22 09:40:25 2012 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3E2E6106564A for ; Wed, 22 Feb 2012 09:40:25 +0000 (UTC) (envelope-from ivoras@gmail.com) Received: from mail-wi0-f182.google.com (mail-wi0-f182.google.com [209.85.212.182]) by mx1.freebsd.org (Postfix) with ESMTP id BE75E8FC1F for ; Wed, 22 Feb 2012 09:40:23 +0000 (UTC) Received: by wibhn14 with SMTP id hn14so6500747wib.13 for ; Wed, 22 Feb 2012 01:40:22 -0800 (PST) Received-SPF: pass (google.com: domain of ivoras@gmail.com designates 10.181.13.113 as permitted sender) client-ip=10.181.13.113; Authentication-Results: mr.google.com; spf=pass (google.com: domain of ivoras@gmail.com designates 10.181.13.113 as permitted sender) smtp.mail=ivoras@gmail.com; dkim=pass header.i=ivoras@gmail.com Received: from mr.google.com ([10.181.13.113]) by 10.181.13.113 with SMTP id ex17mr33461754wid.15.1329903622841 (num_hops = 1); Wed, 22 Feb 2012 01:40:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=user-agent:mime-version:content-type:content-transfer-encoding :subject:from:date:to:message-id; bh=tA9REDsbY2EVQJCsTfU94MN8LVPGdXkgx7aBaWXvPk4=; b=jVBZ46J4GeHvdi+nMa/0Km+M8YO15tx6p680xprKOjJbg4GBIM3hr6h9/RnaC7QYW1 eRU3Bo52GbDKF5bmaqxs3QEmYNkF4u6g+krH15aQPdTtiUS8NrfBcK1RayoY3yj5Zj0n t87r3+5t84lSNAUscCYZbKdRa3eo1Tx6pMIyo= Received: by 10.181.13.113 with SMTP id ex17mr27547231wid.15.1329902211977; Wed, 22 Feb 2012 01:16:51 -0800 (PST) Received: from mintaka.cosmos (cpe-188-129-77-255.dynamic.amis.hr. [188.129.77.255]) by mx.google.com with ESMTPS id s8sm27892898wiz.8.2012.02.22.01.16.50 (version=SSLv3 cipher=OTHER); Wed, 22 Feb 2012 01:16:50 -0800 (PST) User-Agent: K-9 Mail for Android MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit From: Ivan Voras Date: Wed, 22 Feb 2012 10:16:45 +0100 To: "hackers@freebsd.org" Message-ID: X-Mailman-Approved-At: Wed, 22 Feb 2012 12:16:54 +0000 Cc: Subject: PostgreSQL benchmarks (now with Linux numbers) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Feb 2012 09:40:25 -0000 The Dragonfly team has recently liberated their VM from the giant lock and there are some interesting benchmarks comparing it to FreeBSD 9 and a derivative of RedHat Enterprise Linux: http://leaf.dragonflybsd.org/mailarchive/kernel/2011-11/msg00008.html Other developments are described in their release notes: http://www.dragonflybsd.org/release30/ -- Sent from my mobile phone . Please excuse my brevity. From owner-freebsd-hackers@FreeBSD.ORG Wed Feb 22 17:54:41 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DAC771065672 for ; Wed, 22 Feb 2012 17:54:41 +0000 (UTC) (envelope-from svetlin.manavski@itrinegy.com) Received: from eu1sys200aog116.obsmtp.com (eu1sys200aog116.obsmtp.com [207.126.144.141]) by mx1.freebsd.org (Postfix) with SMTP id ED7988FC1A for ; Wed, 22 Feb 2012 17:54:40 +0000 (UTC) Received: from mail-iy0-f172.google.com ([209.85.210.172]) (using TLSv1) by eu1sys200aob116.postini.com ([207.126.147.11]) with SMTP ID DSNKT0Ur32lRh6bWa1c5rcNINGRqihD3Gy1h@postini.com; Wed, 22 Feb 2012 17:54:41 UTC Received: by mail-iy0-f172.google.com with SMTP id f6so331683iag.3 for ; Wed, 22 Feb 2012 09:54:39 -0800 (PST) Received-SPF: pass (google.com: domain of svetlin.manavski@itrinegy.com designates 10.50.140.101 as permitted sender) client-ip=10.50.140.101; Authentication-Results: mr.google.com; spf=pass (google.com: domain of svetlin.manavski@itrinegy.com designates 10.50.140.101 as permitted sender) smtp.mail=svetlin.manavski@itrinegy.com Received: from mr.google.com ([10.50.140.101]) by 10.50.140.101 with SMTP id rf5mr28097851igb.27.1329933279581 (num_hops = 1); Wed, 22 Feb 2012 09:54:39 -0800 (PST) MIME-Version: 1.0 Received: by 10.50.140.101 with SMTP id rf5mr22628656igb.27.1329931457970; Wed, 22 Feb 2012 09:24:17 -0800 (PST) Received: by 10.50.156.232 with HTTP; Wed, 22 Feb 2012 09:24:17 -0800 (PST) Date: Wed, 22 Feb 2012 17:24:17 +0000 Message-ID: From: Svetlin Manavski To: freebsd-hackers@freebsd.org X-Gm-Message-State: ALoCoQl7FYcSkR6ki1Ow7Pk5KsHvyuUh6vlKLmrwWrPLPfnJx51qHKTASMTmBjj7aOvHjpVu/JnP Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: How to access kernel memory from user space X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Feb 2012 17:54:41 -0000 Hi all, I have a very similar problem as described in this thread back in 2009: http://lists.freebsd.org/pipermail/freebsd-hackers/2009-January/027367.html I have a kernel module producing networking stats which I need to frequently read from the user space. A copy of the data structure would be too expensive so I need to access the kernel data directly from the user space. Unfortunately Alexej's code crashes in the following area: vm_map_lookup(&kmem_map, addr, VM_PROT_ALL, &myentry, &myobject, &mypindex, &myprot, &mywired); /* OUT */ vm_map_lookup_done(kmem_map, myentry); I am using 64bit FreeBSD 8.2 on Intel Xeon hardware. Any idea how to make a stable implementation on my platform? Thank you, Svetlin From owner-freebsd-hackers@FreeBSD.ORG Wed Feb 22 18:21:13 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AD034106566B; Wed, 22 Feb 2012 18:21:13 +0000 (UTC) (envelope-from egoitz@ramattack.net) Received: from proxypop04.sare.net (proxypop04.sare.net [194.30.0.65]) by mx1.freebsd.org (Postfix) with ESMTP id 6F3CA8FC15; Wed, 22 Feb 2012 18:21:12 +0000 (UTC) Received: from www.saremail.com (unknown [194.30.0.100]) by proxypop04.sare.net (Postfix) with ESMTPSA id 994A39DC4E9; Wed, 22 Feb 2012 19:21:11 +0100 (CET) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Date: Wed, 22 Feb 2012 19:21:11 +0100 From: egoitz@ramattack.net To: Nathan Whitehorn , In-Reply-To: <2302656984477a6b671f298f965fcb88@ramattack.net> References: <4F429FE8.303@freebsd.org> <2302656984477a6b671f298f965fcb88@ramattack.net> Message-ID: X-Sender: egoitz@ramattack.net User-Agent: Saremail/0.6-svn Cc: Subject: Re: Jumpstart on FreeBSD 9.0 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Feb 2012 18:21:13 -0000 I have done : > > /usr/local/bin/cvsup /var/cvsup/cvs-supfile > cd /usr > cvs -R -d /expert/ncvs co -r RELENG_9_0 src cd /usr/src > make buildworld > mkdir /expert/RELENG90RELEASE > cd /usr/src/release/ > make -f Makefile.sysinstall release CHROOTDIR=/expert/RELENG90RELEASE > CVSROOT=/expert/ncvs RELEASETAG=RELENG_9_0 MAKE_ISOS=1 > > In the release man of freebsd 9.0-release sais... that you should now need to do a make buildworld AND a make buildkernel before than running the make release.... In previous releases... the make buildkernel was not needed... in fact in Makefile.sysinstall which is which I am using according to steps I have described have done.... there's a part which sais : # # Build and package both GENERIC and SMP kernels if the target # has both configuration files. Otherwise only GENERIC is done. # .if ${TARGET_ARCH} == "powerpc64" KERN_GENERIC?= GENERIC64 .else KERN_GENERIC?= GENERIC .endif which in default Makefile for /usr/src/release (/usr/src/release/Makefile) is not... in fact in this default Makefile of this dir (not in the Makefile.sysinstall)... we can see... system: packagesystem # Install system -mkdir ${.OBJDIR}/release cd ${WORLDDIR} && ${IMAKE} installkernel installworld distribution \ DESTDIR=${.OBJDIR}/release WITHOUT_RESCUE=1 WITHOUT_KERNEL_SYMBOLS=1 So it's obvious... you should have done this (the make buildkernel) before make release if you use the /usr/src/release/Makefile, so the question is... (just for ensuring) when using Makefile.sysintall everything should be fine although you don't have done the buildkernel before isn't it?... for the moment is doing the make release... has not ended... but was just for sure and relaxed by the way :) :)... althout I suppose too that if this buildkernel is a needed step make release will fail basically.... So should then be ok in this way I'm generating the release isn't it? Thanks a lot for you're time, Best regards. From owner-freebsd-hackers@FreeBSD.ORG Wed Feb 22 19:15:45 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 12C08106566B for ; Wed, 22 Feb 2012 19:15:45 +0000 (UTC) (envelope-from freebsd@damnhippie.dyndns.org) Received: from qmta08.emeryville.ca.mail.comcast.net (qmta08.emeryville.ca.mail.comcast.net [76.96.30.80]) by mx1.freebsd.org (Postfix) with ESMTP id ED8298FC16 for ; Wed, 22 Feb 2012 19:15:44 +0000 (UTC) Received: from omta05.emeryville.ca.mail.comcast.net ([76.96.30.43]) by qmta08.emeryville.ca.mail.comcast.net with comcast id d7CU1i00S0vp7WLA87Fk3G; Wed, 22 Feb 2012 19:15:44 +0000 Received: from damnhippie.dyndns.org ([24.8.232.202]) by omta05.emeryville.ca.mail.comcast.net with comcast id d7Fj1i00q4NgCEG8R7FjAp; Wed, 22 Feb 2012 19:15:44 +0000 Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by damnhippie.dyndns.org (8.14.3/8.14.3) with ESMTP id q1MJFfQg005108; Wed, 22 Feb 2012 12:15:41 -0700 (MST) (envelope-from freebsd@damnhippie.dyndns.org) From: Ian Lepore To: Svetlin Manavski In-Reply-To: References: Content-Type: text/plain; charset="us-ascii" Date: Wed, 22 Feb 2012 12:15:41 -0700 Message-ID: <1329938141.21804.4.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@freebsd.org Subject: Re: How to access kernel memory from user space X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Feb 2012 19:15:45 -0000 On Wed, 2012-02-22 at 17:24 +0000, Svetlin Manavski wrote: > Hi all, > I have a very similar problem as described in this thread back in 2009: > > http://lists.freebsd.org/pipermail/freebsd-hackers/2009-January/027367.html > > I have a kernel module producing networking stats which I need to > frequently read from the user space. A copy of the data structure would be > too expensive so I need to access the kernel data directly from the user > space. > > Unfortunately Alexej's code crashes in the following area: > > vm_map_lookup(&kmem_map, addr, VM_PROT_ALL, &myentry, &myobject, &mypindex, > &myprot, &mywired); /* OUT */ > vm_map_lookup_done(kmem_map, myentry); > I am using 64bit FreeBSD 8.2 on Intel Xeon hardware. > Any idea how to make a stable implementation on my platform? > > Thank you, > Svetlin > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" I've never done this, but if I needed to, I think the first thing I'd try is to use an mmap(2) of /dev/kmem to map the memory you need into userspace (of course your userspace app will need to be running with root privs to do this). That leaves the interesting problem of locating what offset within the kernel virtual address space you need to map to get at your data. Two things come to mind... have your kernel module export the address in a sysctl (that feels kind of hack-ish but it should be quick and easy to do), or use libkvm's kvm_nlist() function to locate the symbol within your module (I think that should be possible; again I've never actually done any of this). -- Ian From owner-freebsd-hackers@FreeBSD.ORG Wed Feb 22 22:57:42 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 00F631065670 for ; Wed, 22 Feb 2012 22:57:42 +0000 (UTC) (envelope-from uffe@uffe.org) Received: from mail.starion.dk (mx0.starion.dk [93.162.70.34]) by mx1.freebsd.org (Postfix) with SMTP id 33DD88FC0A for ; Wed, 22 Feb 2012 22:57:39 +0000 (UTC) Received: (qmail 98037 invoked by uid 1004); 22 Feb 2012 22:58:04 -0000 Message-ID: <4F4572D5.7070009@uffe.org> Date: Wed, 22 Feb 2012 23:57:25 +0100 From: Uffe Jakobsen X-Mozilla-Draft-Info: internal/draft; vcard=0; receipt=0; DSN=0; uuencode=0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: freebsd-hackers@freebsd.org References: <4F3EE186.4020801@gmail.com> <201202181409.08859.hselasky@c2i.net> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: vermaden Subject: Re: devd based AUTOMOUNTER X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Feb 2012 22:57:42 -0000 On 2012-02-21 10:05, vermaden wrote: > > I have created a PORT at last, its in the 'port' directory in the usual place: > > https://github.com/vermaden/automount/ > > Its my first PORT so feel free to bash me about my mistakes ;) > It is not found on http://freshports.org/ I guess that you haven't submitted it as a real port yet ? /Uffe From owner-freebsd-hackers@FreeBSD.ORG Thu Feb 23 01:06:22 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7AE3D106566C for ; Thu, 23 Feb 2012 01:06:22 +0000 (UTC) (envelope-from rysto32@gmail.com) Received: from mail-ww0-f50.google.com (mail-ww0-f50.google.com [74.125.82.50]) by mx1.freebsd.org (Postfix) with ESMTP id D37448FC13 for ; Thu, 23 Feb 2012 01:06:21 +0000 (UTC) Received: by wgbdq11 with SMTP id dq11so574972wgb.31 for ; Wed, 22 Feb 2012 17:06:20 -0800 (PST) Received-SPF: pass (google.com: domain of rysto32@gmail.com designates 10.216.137.147 as permitted sender) client-ip=10.216.137.147; Authentication-Results: mr.google.com; spf=pass (google.com: domain of rysto32@gmail.com designates 10.216.137.147 as permitted sender) smtp.mail=rysto32@gmail.com; dkim=pass header.i=rysto32@gmail.com Received: from mr.google.com ([10.216.137.147]) by 10.216.137.147 with SMTP id y19mr328654wei.5.1329959180811 (num_hops = 1); Wed, 22 Feb 2012 17:06:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=2EbzRYbNw/g7GOhOH6cG9zyP/nDgZbz9BboofwvdOnU=; b=VGNeaJWTn+9vq4o0PhyLRV3YZCKUVoO1R8Q0hJyY0y53uDDZf5ew6nQhQjAW2ASDSe GyYmdceae4jA9GgpVopI0p298Xz0NOL/rQFei8zdTG/9wIBebhWx4X1zyjLRekVONIJL aseNZD9DetRKHOqSYUMgtA3wkmCF9pzZBZMYk= MIME-Version: 1.0 Received: by 10.216.137.147 with SMTP id y19mr271904wei.5.1329959180717; Wed, 22 Feb 2012 17:06:20 -0800 (PST) Received: by 10.180.75.41 with HTTP; Wed, 22 Feb 2012 17:06:20 -0800 (PST) In-Reply-To: <1329938141.21804.4.camel@revolution.hippie.lan> References: <1329938141.21804.4.camel@revolution.hippie.lan> Date: Wed, 22 Feb 2012 20:06:20 -0500 Message-ID: From: Ryan Stone To: Ian Lepore Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-hackers@freebsd.org, Svetlin Manavski Subject: Re: How to access kernel memory from user space X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Feb 2012 01:06:22 -0000 On Wed, Feb 22, 2012 at 2:15 PM, Ian Lepore wrote: > I've never done this, but if I needed to, I think the first thing I'd > try is to use an mmap(2) of /dev/kmem to map the memory you need into > userspace (of course your userspace app will need to be running with > root privs to do this). > > That leaves the interesting problem of locating what offset within the > kernel virtual address space you need to map to get at your data. =A0Two > things come to mind... have your kernel module export the address in a > sysctl (that feels kind of hack-ish but it should be quick and easy to > do), or use libkvm's kvm_nlist() function to locate the symbol within > your module (I think that should be possible; again I've never actually > done any of this). A far easier way to do this is to have the module create its own device in /dev that exports the memory by implementing the mmap interface in the cdev. From owner-freebsd-hackers@FreeBSD.ORG Thu Feb 23 02:59:09 2012 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx2.freebsd.org (mx2.freebsd.org [69.147.83.53]) by hub.freebsd.org (Postfix) with ESMTP id 8B983106566C; Thu, 23 Feb 2012 02:59:09 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from 172-17-197-151.globalsuite.net (hub.freebsd.org [IPv6:2001:4f8:fff6::36]) by mx2.freebsd.org (Postfix) with ESMTP id 4CE7F1570AF; Thu, 23 Feb 2012 02:59:03 +0000 (UTC) Message-ID: <4F45AB76.5050201@FreeBSD.org> Date: Wed, 22 Feb 2012 18:59:02 -0800 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (X11; FreeBSD i386; rv:10.0.2) Gecko/20120218 Thunderbird/10.0.2 MIME-Version: 1.0 To: Ivan Voras References: In-Reply-To: X-Enigmail-Version: 1.3.5 OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "hackers@freebsd.org" Subject: Re: PostgreSQL benchmarks (now with Linux numbers) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Feb 2012 02:59:09 -0000 On 02/22/2012 01:42, Ivan Voras wrote: > The Dragonfly team has recently liberated their VM from the giant lock and there are some interesting benchmarks comparing it to FreeBSD 9 and a derivative of RedHat Enterprise Linux: > > http://leaf.dragonflybsd.org/mailarchive/kernel/2011-11/msg00008.html > > Other developments are described in their release notes: http://www.dragonflybsd.org/release30/ The 4.5 times improvement by enabling kern.ipc.shm_use_phys is pretty notable, what prevents us from enabling that by default? Doug -- It's always a long day; 86400 doesn't fit into a short. Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ From owner-freebsd-hackers@FreeBSD.ORG Thu Feb 23 08:57:12 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2C4B7106566C; Thu, 23 Feb 2012 08:57:12 +0000 (UTC) (envelope-from egoitz@ramattack.net) Received: from proxypop04.sare.net (proxypop04.sare.net [194.30.0.65]) by mx1.freebsd.org (Postfix) with ESMTP id DE8F08FC1A; Thu, 23 Feb 2012 08:57:11 +0000 (UTC) Received: from www.saremail.com (unknown [194.30.0.100]) by proxypop04.sare.net (Postfix) with ESMTPSA id 76FD39DC54E; Thu, 23 Feb 2012 09:57:10 +0100 (CET) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Date: Thu, 23 Feb 2012 09:57:10 +0100 From: egoitz@ramattack.net To: Nathan Whitehorn , In-Reply-To: References: <4F429FE8.303@freebsd.org> <2302656984477a6b671f298f965fcb88@ramattack.net> Message-ID: <02ecca7da4040dd42657f432c6b86596@ramattack.net> X-Sender: egoitz@ramattack.net User-Agent: Saremail/0.6-svn Cc: Subject: Re: Jumpstart on FreeBSD 9.0 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Feb 2012 08:57:12 -0000 ave done the buildkernel > before isn't it?... for the moment is doing the make release... has > not ended... but was just for sure and relaxed by the way :) :)... > althout I suppose too that if this buildkernel is a needed step make > release will fail basically.... > > So should then be ok in this way I'm generating the release isn't it? > > Thanks a lot for you're time, > Best regards. > The make release has failed in : test -f /usr/src/release/install.cfg && cp /usr/src/release/install.cfg /R/stage/mfsfd *** Error code 1 (ignored) Have corrected Makefile.sysinstall to take install.cfg from : /usr/src/usr.sbin/sysinstall/install.cfg although later has continued and finally has ended with : Setting up FTP distribution area 0 blocks touch ftp.1 Building CDROM live filesystem image 0 blocks 0 blocks 0 blocks 0 blocks 0 blocks 0 blocks 0 blocks 0 blocks 0 blocks Building DVD filesystem image as well as CDROM 0 blocks 0 blocks 0 blocks 0 blocks 0 blocks 0 blocks 0 blocks 0 blocks 0 blocks Copy GENERIC kernel to boot area Setting up CDROM boot area touch cdrom.1 Building CDROM disc1 filesystem image 0 blocks Building CDROM disc2 filesystem image 0 blocks Building CDROM docs filesystem image touch cdrom.2 Building bootonly CDROM filesystem image touch cdrom.3 Creating ISO images... /usr/src/release/amd64/mkisoimages.sh: cannot create /R/cdrom/bootonly/etc/fstab: No such file or directory rm: /R/cdrom/bootonly/etc/fstab: No such file or directory *** Error code 1 Stop in /usr/src/release. + umount /dev *** Error code 1 Stop in /usr/src/release. /usr/src/release/amd64/mkisoimages.sh cannot create fstab because etc dir does not exist inside /expert/RELENG90RELEASE/R/cdrom/disc1 or /expert/RELENG90RELEASE/R/cdrom/bootonly.... have done an mkdir $4/etc as the first line of /usr/src/release/amd64/mkisoimages.sh script... I'll tell you if with this two changes... everything finishes without problems... Gonna launch it like before : generarelease90# pwd /usr/src/release generarelease90# generarelease90# generarelease90# generarelease90# generarelease90# generarelease90# make -f Makefile.sysinstall release CHROOTDIR=/expert/RELENG90RELEASE CVSROOT=/expert/ncvs RELEASETAG=RELENG_9_0 MAKE_ISOS=1 variables specified are OK too for Makefile.sysinstall by the way I've seen... I'll tell you if this works.... Thanks!! Best regards, From owner-freebsd-hackers@FreeBSD.ORG Thu Feb 23 10:20:20 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 24867106564A; Thu, 23 Feb 2012 10:20:20 +0000 (UTC) (envelope-from egoitz@ramattack.net) Received: from proxypop04.sare.net (proxypop04.sare.net [194.30.0.65]) by mx1.freebsd.org (Postfix) with ESMTP id D44828FC16; Thu, 23 Feb 2012 10:20:19 +0000 (UTC) Received: from www.saremail.com (unknown [194.30.0.100]) by proxypop04.sare.net (Postfix) with ESMTPSA id 18B7F9DC4B6; Thu, 23 Feb 2012 11:20:18 +0100 (CET) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Date: Thu, 23 Feb 2012 11:20:17 +0100 From: egoitz@ramattack.net To: Nathan Whitehorn , In-Reply-To: <02ecca7da4040dd42657f432c6b86596@ramattack.net> References: <4F429FE8.303@freebsd.org> <2302656984477a6b671f298f965fcb88@ramattack.net> <02ecca7da4040dd42657f432c6b86596@ramattack.net> Message-ID: <427cede96581e9d928ddc38b3f3da3ca@ramattack.net> X-Sender: egoitz@ramattack.net User-Agent: Saremail/0.6-svn Cc: Subject: Re: Jumpstart on FreeBSD 9.0 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Feb 2012 10:20:20 -0000 And by the way... the previous question made about the need of doing a buildkernel after the buildworld using Makefile.sysinstall seems not to be needed because it does during make release proccess.... From owner-freebsd-hackers@FreeBSD.ORG Thu Feb 23 14:34:14 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 87EB0106564A; Thu, 23 Feb 2012 14:34:14 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 5B5B98FC14; Thu, 23 Feb 2012 14:34:14 +0000 (UTC) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [96.47.65.170]) by cyrus.watson.org (Postfix) with ESMTPSA id 1384846B17; Thu, 23 Feb 2012 09:34:14 -0500 (EST) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 7E574B974; Thu, 23 Feb 2012 09:34:13 -0500 (EST) From: John Baldwin To: freebsd-hackers@freebsd.org Date: Thu, 23 Feb 2012 08:02:04 -0500 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p10; KDE/4.5.5; amd64; ; ) References: <20120217.074355.853.1@DOMY-PC> In-Reply-To: <20120217.074355.853.1@DOMY-PC> MIME-Version: 1.0 Content-Type: Text/Plain; charset="windows-1250" Content-Transfer-Encoding: 7bit Message-Id: <201202230802.05083.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Thu, 23 Feb 2012 09:34:13 -0500 (EST) Cc: rank1seeker@gmail.com, Roman Divacky Subject: Re: BUG: 9.0 stage 2 boot (/boot/boot) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Feb 2012 14:34:14 -0000 On Friday, February 17, 2012 2:43:55 am rank1seeker@gmail.com wrote: > Anyway, after upgrading to 9.0, my USB stick, when created, started to hang at stage 2 boot. > I have a custom setup, where BSD label 'a', has a content of /boot/* > So when 'a' is being hit by stage 2 boot, there is boot.config waiting for it. > After it reads it and displays it's content, it echos 'No' and hangs. > > I stare at it and can't believe as boot.config's information is correct! > I hit '?' and it list all files in 'a'. > Then I simply RE-type what is displayed on screen (content of boot.config -> path to loader) > And loader kicks in! > > I do this a few times more and EACH time I have to RE-type correct info! > Tested on other machine, same thing. > > However, this same custom layout works for HDD's, but NOT for USB stick. > > I've extracted binary installs of 8.2 and 9.0 R: > MD5 (8_boot) = adb1e84e96bd434e51cafaaa0ef22584 > MD5 (9_boot) = 40f3f6403ebd5e131259d1336b4b50ad > > Then: > # gpart bootcode -b 8_boot da0s2 > And sudenly that USB stick boots, without ANY other change! > Just an "old" stage 2 boot code, from R8 was enough. Looks like it is thinking that 'kname' is empty. Ah, I think Roman broke this in 219186: @@ -474,11 +461,7 @@ parse() ? DRV_HARD : 0) + drv; dsk_meta = 0; } - if ((i = ep - arg)) { - if ((size_t)i >= sizeof(kname)) - return -1; - memcpy(kname, arg, i + 1); - } + kname = arg; } arg = p; } Before it only set kname if it wasn't an empty string. Now it always sets kname. Try this change: Index: boot2.c =================================================================== --- boot2.c (revision 231983) +++ boot2.c (working copy) @@ -457,7 +457,8 @@ parse() ? DRV_HARD : 0) + drv; dsk_meta = 0; } - kname = arg; + if (*arg != '\0') + kname = arg; } arg = p; } -- John Baldwin From owner-freebsd-hackers@FreeBSD.ORG Thu Feb 23 14:34:15 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7E91D106566B for ; Thu, 23 Feb 2012 14:34:15 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 4FAB38FC08 for ; Thu, 23 Feb 2012 14:34:15 +0000 (UTC) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [96.47.65.170]) by cyrus.watson.org (Postfix) with ESMTPSA id 078C046B2A; Thu, 23 Feb 2012 09:34:15 -0500 (EST) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 5FB1EB948; Thu, 23 Feb 2012 09:34:14 -0500 (EST) From: John Baldwin To: freebsd-hackers@freebsd.org Date: Thu, 23 Feb 2012 08:12:43 -0500 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p10; KDE/4.5.5; amd64; ; ) References: <1329938141.21804.4.camel@revolution.hippie.lan> In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201202230812.43126.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Thu, 23 Feb 2012 09:34:14 -0500 (EST) Cc: Ian Lepore , Ryan Stone , Svetlin Manavski Subject: Re: How to access kernel memory from user space X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Feb 2012 14:34:15 -0000 On Wednesday, February 22, 2012 8:06:20 pm Ryan Stone wrote: > On Wed, Feb 22, 2012 at 2:15 PM, Ian Lepore > wrote: > > I've never done this, but if I needed to, I think the first thing I'd > > try is to use an mmap(2) of /dev/kmem to map the memory you need into > > userspace (of course your userspace app will need to be running with > > root privs to do this). > > > > That leaves the interesting problem of locating what offset within the > > kernel virtual address space you need to map to get at your data. Two > > things come to mind... have your kernel module export the address in a > > sysctl (that feels kind of hack-ish but it should be quick and easy to > > do), or use libkvm's kvm_nlist() function to locate the symbol within > > your module (I think that should be possible; again I've never actually > > done any of this). > > A far easier way to do this is to have the module create its own > device in /dev that exports the memory by implementing the mmap > interface in the cdev. Yes. Another option you can do if you want to let userland "donate" a buffer to the kernel is to let userland create a buffer using shm_open() (probably with SHM_ANON) and then use shm_map() in the kernel to map that into KVA. -- John Baldwin From owner-freebsd-hackers@FreeBSD.ORG Thu Feb 23 14:34:16 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4A014106566C; Thu, 23 Feb 2012 14:34:16 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 1C8368FC0C; Thu, 23 Feb 2012 14:34:16 +0000 (UTC) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [96.47.65.170]) by cyrus.watson.org (Postfix) with ESMTPSA id C9AA846B0A; Thu, 23 Feb 2012 09:34:15 -0500 (EST) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 406B5B94F; Thu, 23 Feb 2012 09:34:15 -0500 (EST) From: John Baldwin To: freebsd-hackers@freebsd.org Date: Thu, 23 Feb 2012 08:22:16 -0500 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p10; KDE/4.5.5; amd64; ; ) References: <4F45AB76.5050201@FreeBSD.org> In-Reply-To: <4F45AB76.5050201@FreeBSD.org> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201202230822.16304.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Thu, 23 Feb 2012 09:34:15 -0500 (EST) Cc: "hackers@freebsd.org" , Doug Barton , Ivan Voras Subject: Re: PostgreSQL benchmarks (now with Linux numbers) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Feb 2012 14:34:16 -0000 On Wednesday, February 22, 2012 9:59:02 pm Doug Barton wrote: > On 02/22/2012 01:42, Ivan Voras wrote: > > The Dragonfly team has recently liberated their VM from the giant lock and there are some interesting benchmarks comparing it to FreeBSD 9 and a derivative of RedHat Enterprise Linux: > > > > http://leaf.dragonflybsd.org/mailarchive/kernel/2011-11/msg00008.html > > > > Other developments are described in their release notes: http://www.dragonflybsd.org/release30/ > > The 4.5 times improvement by enabling kern.ipc.shm_use_phys is pretty > notable, what prevents us from enabling that by default? It makes all your SYSV SHMs wired. That's fine if you are running a dedicated server using SYSV SHMs where you want that process to use all the RAM in the machine (e.g. a pgqsl server). It's not so great for a general purpose load where you would like an otherwise-idle process using SYSV SHMs to have the SHMs paged out to swap if other processes on the machine need memory and the box is under memory pressure. -- John Baldwin From owner-freebsd-hackers@FreeBSD.ORG Thu Feb 23 14:34:16 2012 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4A014106566C; Thu, 23 Feb 2012 14:34:16 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 1C8368FC0C; Thu, 23 Feb 2012 14:34:16 +0000 (UTC) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [96.47.65.170]) by cyrus.watson.org (Postfix) with ESMTPSA id C9AA846B0A; Thu, 23 Feb 2012 09:34:15 -0500 (EST) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 406B5B94F; Thu, 23 Feb 2012 09:34:15 -0500 (EST) From: John Baldwin To: freebsd-hackers@freebsd.org Date: Thu, 23 Feb 2012 08:22:16 -0500 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p10; KDE/4.5.5; amd64; ; ) References: <4F45AB76.5050201@FreeBSD.org> In-Reply-To: <4F45AB76.5050201@FreeBSD.org> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201202230822.16304.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Thu, 23 Feb 2012 09:34:15 -0500 (EST) Cc: "hackers@freebsd.org" , Doug Barton , Ivan Voras Subject: Re: PostgreSQL benchmarks (now with Linux numbers) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Feb 2012 14:34:16 -0000 On Wednesday, February 22, 2012 9:59:02 pm Doug Barton wrote: > On 02/22/2012 01:42, Ivan Voras wrote: > > The Dragonfly team has recently liberated their VM from the giant lock and there are some interesting benchmarks comparing it to FreeBSD 9 and a derivative of RedHat Enterprise Linux: > > > > http://leaf.dragonflybsd.org/mailarchive/kernel/2011-11/msg00008.html > > > > Other developments are described in their release notes: http://www.dragonflybsd.org/release30/ > > The 4.5 times improvement by enabling kern.ipc.shm_use_phys is pretty > notable, what prevents us from enabling that by default? It makes all your SYSV SHMs wired. That's fine if you are running a dedicated server using SYSV SHMs where you want that process to use all the RAM in the machine (e.g. a pgqsl server). It's not so great for a general purpose load where you would like an otherwise-idle process using SYSV SHMs to have the SHMs paged out to swap if other processes on the machine need memory and the box is under memory pressure. -- John Baldwin From owner-freebsd-hackers@FreeBSD.ORG Thu Feb 23 14:41:21 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 78110106566C for ; Thu, 23 Feb 2012 14:41:21 +0000 (UTC) (envelope-from ml@my.gd) Received: from mail-bk0-f54.google.com (mail-bk0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id F146C8FC0C for ; Thu, 23 Feb 2012 14:41:20 +0000 (UTC) Received: by bkcjg1 with SMTP id jg1so1454104bkc.13 for ; Thu, 23 Feb 2012 06:41:19 -0800 (PST) Received-SPF: pass (google.com: domain of ml@my.gd designates 10.204.156.77 as permitted sender) client-ip=10.204.156.77; Authentication-Results: mr.google.com; spf=pass (google.com: domain of ml@my.gd designates 10.204.156.77 as permitted sender) smtp.mail=ml@my.gd Received: from mr.google.com ([10.204.156.77]) by 10.204.156.77 with SMTP id v13mr857022bkw.112.1330008079964 (num_hops = 1); Thu, 23 Feb 2012 06:41:19 -0800 (PST) Received: by 10.204.156.77 with SMTP id v13mr702490bkw.112.1330008079747; Thu, 23 Feb 2012 06:41:19 -0800 (PST) Received: from dfleuriot-at-hi-media.com ([83.167.62.196]) by mx.google.com with ESMTPS id w15sm3205342bku.0.2012.02.23.06.41.18 (version=SSLv3 cipher=OTHER); Thu, 23 Feb 2012 06:41:19 -0800 (PST) Message-ID: <4F46500D.3070609@my.gd> Date: Thu, 23 Feb 2012 15:41:17 +0100 From: Damien Fleuriot User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: freebsd-hackers@freebsd.org References: <4F45AB76.5050201@FreeBSD.org> <201202230822.16304.jhb@freebsd.org> In-Reply-To: <201202230822.16304.jhb@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Gm-Message-State: ALoCoQnV6gFn25wLzl9ECTLaey4Ak6HMgBYbCeP+9sL96hu09WJVJxxzIS2+4pHfG0HMQ3r+mIzH Subject: Re: PostgreSQL benchmarks (now with Linux numbers) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Feb 2012 14:41:21 -0000 On 2/23/12 2:22 PM, John Baldwin wrote: > On Wednesday, February 22, 2012 9:59:02 pm Doug Barton wrote: >> On 02/22/2012 01:42, Ivan Voras wrote: >>> The Dragonfly team has recently liberated their VM from the giant lock and there are some interesting benchmarks comparing it to FreeBSD 9 and a > derivative of RedHat Enterprise Linux: >>> >>> http://leaf.dragonflybsd.org/mailarchive/kernel/2011-11/msg00008.html >>> >>> Other developments are described in their release notes: http://www.dragonflybsd.org/release30/ >> >> The 4.5 times improvement by enabling kern.ipc.shm_use_phys is pretty >> notable, what prevents us from enabling that by default? > > It makes all your SYSV SHMs wired. That's fine if you are running a dedicated > server using SYSV SHMs where you want that process to use all the RAM in the > machine (e.g. a pgqsl server). It's not so great for a general purpose load > where you would like an otherwise-idle process using SYSV SHMs to have the SHMs > paged out to swap if other processes on the machine need memory and the box is > under memory pressure. > John, any chance we can get that in layman's terms ? I'm totally no coder, but I'd really like if we could do this at my work place to increase our firewalls' performances. From owner-freebsd-hackers@FreeBSD.ORG Thu Feb 23 15:18:21 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BAB131065670 for ; Thu, 23 Feb 2012 15:18:21 +0000 (UTC) (envelope-from dudu@dudu.ro) Received: from mail-gy0-f182.google.com (mail-gy0-f182.google.com [209.85.160.182]) by mx1.freebsd.org (Postfix) with ESMTP id 6AE268FC14 for ; Thu, 23 Feb 2012 15:18:21 +0000 (UTC) Received: by ghbg15 with SMTP id g15so723146ghb.13 for ; Thu, 23 Feb 2012 07:18:20 -0800 (PST) Received-SPF: pass (google.com: domain of dudu@dudu.ro designates 10.50.155.231 as permitted sender) client-ip=10.50.155.231; Authentication-Results: mr.google.com; spf=pass (google.com: domain of dudu@dudu.ro designates 10.50.155.231 as permitted sender) smtp.mail=dudu@dudu.ro; dkim=pass header.i=dudu@dudu.ro Received: from mr.google.com ([10.50.155.231]) by 10.50.155.231 with SMTP id vz7mr2315434igb.26.1330010300691 (num_hops = 1); Thu, 23 Feb 2012 07:18:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=dudu.ro; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=ZCzEs60V/gUAmWEuwTYU8asbaOKuqBtRWhXHYxoATWk=; b=OSDgcWCCW7ndJUKzlBa2B2q1fTxK2wO9x4Yb0YaSSO3MAorWf+kQso83K3nIBgAY9g 3IVIufIMqsEJZWpR0trBV6EngWj1UhWNji9MJPlxVzMfHMAIPAAAeqcoGXBGgCD9Cpwy cP+BvqiZcBuR2duiMYpMBAGdgbJMBFdvykD1s= Received: by 10.50.155.231 with SMTP id vz7mr1790758igb.26.1330008404801; Thu, 23 Feb 2012 06:46:44 -0800 (PST) MIME-Version: 1.0 Received: by 10.42.223.69 with HTTP; Thu, 23 Feb 2012 06:46:04 -0800 (PST) In-Reply-To: <4F46500D.3070609@my.gd> References: <4F45AB76.5050201@FreeBSD.org> <201202230822.16304.jhb@freebsd.org> <4F46500D.3070609@my.gd> From: Vlad Galu Date: Thu, 23 Feb 2012 14:46:04 +0000 Message-ID: To: Damien Fleuriot X-Gm-Message-State: ALoCoQnLm1764jvPl6ISwhPO+q7NrlByTskxjtS75ugjLSTR7vcWqQcWvXFkCEX3HgS7I7f7uROQ Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-hackers@freebsd.org Subject: Re: PostgreSQL benchmarks (now with Linux numbers) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Feb 2012 15:18:21 -0000 On Thu, Feb 23, 2012 at 2:41 PM, Damien Fleuriot wrote: > > > On 2/23/12 2:22 PM, John Baldwin wrote: > > On Wednesday, February 22, 2012 9:59:02 pm Doug Barton wrote: > >> On 02/22/2012 01:42, Ivan Voras wrote: > >>> The Dragonfly team has recently liberated their VM from the giant lock > and there are some interesting benchmarks comparing it to FreeBSD 9 and a > > derivative of RedHat Enterprise Linux: > >>> > >>> http://leaf.dragonflybsd.org/mailarchive/kernel/2011-11/msg00008.html > >>> > >>> Other developments are described in their release notes: > http://www.dragonflybsd.org/release30/ > >> > >> The 4.5 times improvement by enabling kern.ipc.shm_use_phys is pretty > >> notable, what prevents us from enabling that by default? > > > > It makes all your SYSV SHMs wired. That's fine if you are running a > dedicated > > server using SYSV SHMs where you want that process to use all the RAM in > the > > machine (e.g. a pgqsl server). It's not so great for a general purpose > load > > where you would like an otherwise-idle process using SYSV SHMs to have > the SHMs > > paged out to swap if other processes on the machine need memory and the > box is > > under memory pressure. > > > > John, any chance we can get that in layman's terms ? > > I'm totally no coder, but I'd really like if we could do this at my work > place to increase our firewalls' performances. > Hi Damien, The above setting prevents the SYSV shared memory from being swapped by the pager. It is useful in a database context, where you want the pages to be available imediately, without having to wait until they are loaded back from disk (in a memory constrained environment). I won't help your firewall at all. -- Good, fast & cheap. Pick any two. From owner-freebsd-hackers@FreeBSD.ORG Thu Feb 23 16:44:32 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0D1D8106566C for ; Thu, 23 Feb 2012 16:44:32 +0000 (UTC) (envelope-from yanegomi@gmail.com) Received: from mail-tul01m020-f182.google.com (mail-tul01m020-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id BEB4A8FC0C for ; Thu, 23 Feb 2012 16:44:31 +0000 (UTC) Received: by obcwo16 with SMTP id wo16so2182939obc.13 for ; Thu, 23 Feb 2012 08:44:31 -0800 (PST) Received-SPF: pass (google.com: domain of yanegomi@gmail.com designates 10.182.144.68 as permitted sender) client-ip=10.182.144.68; Authentication-Results: mr.google.com; spf=pass (google.com: domain of yanegomi@gmail.com designates 10.182.144.68 as permitted sender) smtp.mail=yanegomi@gmail.com; dkim=pass header.i=yanegomi@gmail.com Received: from mr.google.com ([10.182.144.68]) by 10.182.144.68 with SMTP id sk4mr867504obb.4.1330015471245 (num_hops = 1); Thu, 23 Feb 2012 08:44:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=Qi4juOhwfEcyo13zpePXamVkEqTSObFPWFFZCSWYPNA=; b=a0zPmU/pLLHyQkL8lY/xYVbRL5zlisQikegFW3xPrgiGOp/WcCPcZr2os23RewEUvc 3hQO9Ip6SW0gGKRMhhGYj0EyI93KVnyK1NUYAibJeo3bbEa4E7IbYFv0Kus62Ej91JWu nivcFCu8auBFgqLP10zsGM9AXMF3qwJ3zkjio= MIME-Version: 1.0 Received: by 10.182.144.68 with SMTP id sk4mr746051obb.4.1330015471168; Thu, 23 Feb 2012 08:44:31 -0800 (PST) Received: by 10.182.80.200 with HTTP; Thu, 23 Feb 2012 08:44:31 -0800 (PST) In-Reply-To: <4F46500D.3070609@my.gd> References: <4F45AB76.5050201@FreeBSD.org> <201202230822.16304.jhb@freebsd.org> <4F46500D.3070609@my.gd> Date: Thu, 23 Feb 2012 08:44:31 -0800 Message-ID: From: Garrett Cooper To: Damien Fleuriot Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-hackers@freebsd.org Subject: Re: PostgreSQL benchmarks (now with Linux numbers) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Feb 2012 16:44:32 -0000 On Thu, Feb 23, 2012 at 6:41 AM, Damien Fleuriot wrote: > > > On 2/23/12 2:22 PM, John Baldwin wrote: >> On Wednesday, February 22, 2012 9:59:02 pm Doug Barton wrote: >>> On 02/22/2012 01:42, Ivan Voras wrote: >>>> The Dragonfly team has recently liberated their VM from the giant lock= and there are some interesting benchmarks comparing it to FreeBSD 9 and a >> derivative of RedHat Enterprise Linux: >>>> >>>> http://leaf.dragonflybsd.org/mailarchive/kernel/2011-11/msg00008.html >>>> >>>> Other developments are described in their release notes: http://www.dr= agonflybsd.org/release30/ >>> >>> The 4.5 times improvement by enabling kern.ipc.shm_use_phys is pretty >>> notable, what prevents us from enabling that by default? >> >> It makes all your SYSV SHMs wired. =A0That's fine if you are running a d= edicated >> server using SYSV SHMs where you want that process to use all the RAM in= the >> machine (e.g. a pgqsl server). =A0It's not so great for a general purpos= e load >> where you would like an otherwise-idle process using SYSV SHMs to have t= he SHMs >> paged out to swap if other processes on the machine need memory and the = box is >> under memory pressure. >> > > John, any chance we can get that in layman's terms ? > > I'm totally no coder, but I'd really like if we could do this at my work > place to increase our firewalls' performances. (simplifying things... If postgres is the only man in town, then having SYSV SHM (system 5 shared memory) wired down in the kernel would be fine. However, if postgres's not the only man in town, postgres will starve other applications (say Firefox) so they can't get the resources they need to work. A good real life example -- similar to the above -- of memory starvation situations is ZFS v28 on boxes where vfs.zfs.arc_max isn't tuned and the system RAM is overcommitted, such that ZFS will starve userland of all available RAM in the right scenarios. Granted, this scenario uses KVM (kernel virtual memory), not SYSV SHM (this is a subset of KVM), but the general concept (limited resources -> consumer doesn't give up resources -> other waiters starve) is very much the same. HTH, -Garrett From owner-freebsd-hackers@FreeBSD.ORG Thu Feb 23 18:23:13 2012 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 89561106566B for ; Thu, 23 Feb 2012 18:23:13 +0000 (UTC) (envelope-from vijju.singh@gmail.com) Received: from mail-vw0-f54.google.com (mail-vw0-f54.google.com [209.85.212.54]) by mx1.freebsd.org (Postfix) with ESMTP id 3EDAB8FC08 for ; Thu, 23 Feb 2012 18:23:12 +0000 (UTC) Received: by vbbfa15 with SMTP id fa15so1456068vbb.13 for ; Thu, 23 Feb 2012 10:23:12 -0800 (PST) Received-SPF: pass (google.com: domain of vijju.singh@gmail.com designates 10.220.151.5 as permitted sender) client-ip=10.220.151.5; Authentication-Results: mr.google.com; spf=pass (google.com: domain of vijju.singh@gmail.com designates 10.220.151.5 as permitted sender) smtp.mail=vijju.singh@gmail.com; dkim=pass header.i=vijju.singh@gmail.com Received: from mr.google.com ([10.220.151.5]) by 10.220.151.5 with SMTP id a5mr1758366vcw.8.1330021392558 (num_hops = 1); Thu, 23 Feb 2012 10:23:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; bh=Az/YaUB5sKzjta5yNZctQnrkCkPLxbH0Nd1EhPeKhro=; b=e2u+ZU8JWubUHjH1CZDzgN03YQJnxdwxub3zMDPSGQCj7AC5vfrsrSba7j4VnpKMDa 5xYZf4I+621VtPz58HCz96ERxIeqDuQAbuuJsSJJeaiahnB2s6lxp4hdR0arVLRO0sBL WmIEVZQXp8C3VszyJ2vtmEF6A62bXKTAJlkCM= MIME-Version: 1.0 Received: by 10.220.151.5 with SMTP id a5mr1403025vcw.8.1330019570459; Thu, 23 Feb 2012 09:52:50 -0800 (PST) Received: by 10.220.179.131 with HTTP; Thu, 23 Feb 2012 09:52:50 -0800 (PST) Date: Thu, 23 Feb 2012 09:52:50 -0800 Message-ID: From: Vijay Singh To: hackers@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Cc: Subject: USB issue on 8.2 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Feb 2012 18:23:13 -0000 Hi hackers. I am seeing an issue where the USB controller is generating a large number of interrupts. last pid: 6639; load averages: 1.39, 1.48, 2.46 up 0+01:07:14 12:35:05 2590 processes:9 running, 462 sleeping, 3 zombie, 2116 waiting CPU: 0.2% user, 0.0% nice, 11.5% system, 10.6% interrupt, 77.7% idle Mem: 277M Active, 425M Inact, 241M Wired, 2704K Cache, 7488K Buf, 1017M Free Swap: 1024M Total, 1024M Free PID USERNAME PRI NICE SIZE RES STATE C TIME WCPU COMMAND 10 root 171 ki31 0K 64K RUN 3 34:37 89.40% {idle: cpu3} 10 root 171 ki31 0K 64K CPU2 2 33:56 85.94% {idle: cpu2} 10 root 171 ki31 0K 64K CPU0 0 37:20 76.27% {idle: cpu0} 10 root 171 ki31 0K 64K RUN 1 25:09 55.27% {idle: cpu1} 11 root -64 - 0K 480K WAIT 1 14:40 33.40% {irq16: ehci1} interrupt total rate irq16: ehci1 488177801 114166 Is this known? Any patches I can test? -vijay From owner-freebsd-hackers@FreeBSD.ORG Thu Feb 23 20:40:45 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D37E2106564A for ; Thu, 23 Feb 2012 20:40:45 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe01.c2i.net [212.247.154.2]) by mx1.freebsd.org (Postfix) with ESMTP id 65A308FC13 for ; Thu, 23 Feb 2012 20:40:45 +0000 (UTC) X-T2-Spam-Status: No, hits=-0.2 required=5.0 tests=ALL_TRUSTED, BAYES_50 Received: from [176.74.208.111] (account mc467741@c2i.net HELO laptop002.hselasky.homeunix.org) by mailfe01.swip.net (CommuniGate Pro SMTP 5.4.2) with ESMTPA id 245579832; Thu, 23 Feb 2012 21:40:42 +0100 From: Hans Petter Selasky To: freebsd-hackers@freebsd.org Date: Thu, 23 Feb 2012 21:38:53 +0100 User-Agent: KMail/1.13.5 (FreeBSD/8.3-PRERELEASE; KDE/4.4.5; amd64; ; ) References: In-Reply-To: X-Face: 'mmZ:T{)),Oru^0c+/}w'`gU1$ubmG?lp!=R4Wy\ELYo2)@'UZ24N@d2+AyewRX}mAm; Yp |U[@, _z/([?1bCfM{_"B<.J>mICJCHAzzGHI{y7{%JVz%R~yJHIji`y>Y}k1C4TfysrsUI -%GU9V5]iUZF&nRn9mJ'?&>O MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201202232138.53830.hselasky@c2i.net> Cc: Vijay Singh Subject: Re: USB issue on 8.2 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Feb 2012 20:40:45 -0000 On Thursday 23 February 2012 18:52:50 Vijay Singh wrote: > Hi hackers. I am seeing an issue where the USB controller is > generating a large number of interrupts. > > last pid: 6639; load averages: 1.39, 1.48, 2.46 up 0+01:07:14 > 12:35:05 2590 processes:9 running, 462 sleeping, 3 zombie, 2116 waiting > CPU: 0.2% user, 0.0% nice, 11.5% system, 10.6% interrupt, 77.7% idle > Mem: 277M Active, 425M Inact, 241M Wired, 2704K Cache, 7488K Buf, 1017M > Free Swap: 1024M Total, 1024M Free > > PID USERNAME PRI NICE SIZE RES STATE C TIME WCPU COMMAND > 10 root 171 ki31 0K 64K RUN 3 34:37 89.40% {idle: cpu3} > 10 root 171 ki31 0K 64K CPU2 2 33:56 85.94% {idle: cpu2} > 10 root 171 ki31 0K 64K CPU0 0 37:20 76.27% {idle: cpu0} > 10 root 171 ki31 0K 64K RUN 1 25:09 55.27% {idle: cpu1} > 11 root -64 - 0K 480K WAIT 1 14:40 33.40% {irq16: > ehci1} > > interrupt total rate > irq16: ehci1 488177801 114166 > > Is this known? Any patches I can test? Hi, There are some knobs under: sysctl hw.usb.ehci Which you can set to one in /boot/loader.conf hw.usb.ehci.lostintrbug: 0 hw.usb.ehci.iaadbug: 0 --HPS From owner-freebsd-hackers@FreeBSD.ORG Fri Feb 24 00:17:11 2012 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx2.freebsd.org (mx2.freebsd.org [IPv6:2001:4f8:fff6::35]) by hub.freebsd.org (Postfix) with ESMTP id 5C30F106566C; Fri, 24 Feb 2012 00:17:11 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from 172-17-197-151.globalsuite.net (hub.freebsd.org [IPv6:2001:4f8:fff6::36]) by mx2.freebsd.org (Postfix) with ESMTP id E6E9C1577E1; Fri, 24 Feb 2012 00:17:10 +0000 (UTC) Message-ID: <4F46D706.1060903@FreeBSD.org> Date: Thu, 23 Feb 2012 16:17:10 -0800 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (X11; FreeBSD i386; rv:10.0.2) Gecko/20120218 Thunderbird/10.0.2 MIME-Version: 1.0 To: John Baldwin References: <4F45AB76.5050201@FreeBSD.org> <201202230822.16304.jhb@freebsd.org> In-Reply-To: <201202230822.16304.jhb@freebsd.org> X-Enigmail-Version: 1.3.5 OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@freebsd.org, "hackers@freebsd.org" , Ivan Voras Subject: Re: PostgreSQL benchmarks (now with Linux numbers) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Feb 2012 00:17:11 -0000 On 02/23/2012 05:22, John Baldwin wrote: > On Wednesday, February 22, 2012 9:59:02 pm Doug Barton wrote: >> On 02/22/2012 01:42, Ivan Voras wrote: >>> The Dragonfly team has recently liberated their VM from the giant lock and there are some interesting benchmarks comparing it to FreeBSD 9 and a > derivative of RedHat Enterprise Linux: >>> >>> http://leaf.dragonflybsd.org/mailarchive/kernel/2011-11/msg00008.html >>> >>> Other developments are described in their release notes: http://www.dragonflybsd.org/release30/ >> >> The 4.5 times improvement by enabling kern.ipc.shm_use_phys is pretty >> notable, what prevents us from enabling that by default? > > It makes all your SYSV SHMs wired. That's fine if you are running a dedicated > server using SYSV SHMs where you want that process to use all the RAM in the > machine (e.g. a pgqsl server). It's not so great for a general purpose load > where you would like an otherwise-idle process using SYSV SHMs to have the SHMs > paged out to swap if other processes on the machine need memory and the box is > under memory pressure. I see, thanks for that explanation. Doug -- It's always a long day; 86400 doesn't fit into a short. Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ From owner-freebsd-hackers@FreeBSD.ORG Fri Feb 24 00:17:11 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx2.freebsd.org (mx2.freebsd.org [IPv6:2001:4f8:fff6::35]) by hub.freebsd.org (Postfix) with ESMTP id 5C30F106566C; Fri, 24 Feb 2012 00:17:11 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from 172-17-197-151.globalsuite.net (hub.freebsd.org [IPv6:2001:4f8:fff6::36]) by mx2.freebsd.org (Postfix) with ESMTP id E6E9C1577E1; Fri, 24 Feb 2012 00:17:10 +0000 (UTC) Message-ID: <4F46D706.1060903@FreeBSD.org> Date: Thu, 23 Feb 2012 16:17:10 -0800 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (X11; FreeBSD i386; rv:10.0.2) Gecko/20120218 Thunderbird/10.0.2 MIME-Version: 1.0 To: John Baldwin References: <4F45AB76.5050201@FreeBSD.org> <201202230822.16304.jhb@freebsd.org> In-Reply-To: <201202230822.16304.jhb@freebsd.org> X-Enigmail-Version: 1.3.5 OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@freebsd.org, "hackers@freebsd.org" , Ivan Voras Subject: Re: PostgreSQL benchmarks (now with Linux numbers) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Feb 2012 00:17:11 -0000 On 02/23/2012 05:22, John Baldwin wrote: > On Wednesday, February 22, 2012 9:59:02 pm Doug Barton wrote: >> On 02/22/2012 01:42, Ivan Voras wrote: >>> The Dragonfly team has recently liberated their VM from the giant lock and there are some interesting benchmarks comparing it to FreeBSD 9 and a > derivative of RedHat Enterprise Linux: >>> >>> http://leaf.dragonflybsd.org/mailarchive/kernel/2011-11/msg00008.html >>> >>> Other developments are described in their release notes: http://www.dragonflybsd.org/release30/ >> >> The 4.5 times improvement by enabling kern.ipc.shm_use_phys is pretty >> notable, what prevents us from enabling that by default? > > It makes all your SYSV SHMs wired. That's fine if you are running a dedicated > server using SYSV SHMs where you want that process to use all the RAM in the > machine (e.g. a pgqsl server). It's not so great for a general purpose load > where you would like an otherwise-idle process using SYSV SHMs to have the SHMs > paged out to swap if other processes on the machine need memory and the box is > under memory pressure. I see, thanks for that explanation. Doug -- It's always a long day; 86400 doesn't fit into a short. Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ From owner-freebsd-hackers@FreeBSD.ORG Fri Feb 24 01:34:04 2012 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 57FF71065674 for ; Fri, 24 Feb 2012 01:34:04 +0000 (UTC) (envelope-from delphij@delphij.net) Received: from anubis.delphij.net (anubis.delphij.net [IPv6:2001:470:1:117::25]) by mx1.freebsd.org (Postfix) with ESMTP id 280B68FC1A for ; Fri, 24 Feb 2012 01:34:04 +0000 (UTC) Received: from delta.delphij.net (drawbridge.ixsystems.com [206.40.55.65]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by anubis.delphij.net (Postfix) with ESMTPSA id D0BC4FD54; Thu, 23 Feb 2012 17:34:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=delphij.net; s=anubis; t=1330047243; bh=axC1BKHb4pvUL8FuM6TryvB6rG8sp0EHTE1zd5uodiY=; h=Message-ID:Date:From:Reply-To:MIME-Version:To:CC:Subject: References:In-Reply-To:Content-Type:Content-Transfer-Encoding; b=AWVn3aXRd8oeJR5mfpaXdcurAkFFLH4FAUjEVULLDq3UmNwfnhnP35xfu9k00zdMd wpImwm2qMK+1aZeswxNTbV+khyUXYMoHypMOJ6z2Qxu0MX/nVlF8/a6vTJEThrdr5O AF43B2nikqQThbjeNTnhTcOH9AOUhMd9XEkzxLOs= Message-ID: <4F46E90B.2050407@delphij.net> Date: Thu, 23 Feb 2012 17:34:03 -0800 From: Xin Li Organization: The FreeBSD Project MIME-Version: 1.0 To: Bernard van Gastel References: <1BDAF8C6-66A5-4F4F-A2CD-3928A0B10D48@bitpowder.com> In-Reply-To: <1BDAF8C6-66A5-4F4F-A2CD-3928A0B10D48@bitpowder.com> X-Enigmail-Version: 1.3.5 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: hackers@freebsd.org, d@delphij.net Subject: Re: memmem small optimalisation X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: d@delphij.net List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Feb 2012 01:34:04 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Hi, On 02/14/12 10:25, Bernard van Gastel wrote: > Hi all, > > I was looking through the sources of memmove at [1], and saw a > (very) small optimization opportunity. The 'memcmp' also compares > the current character, but the current character is already > checked (first part of the condition). As we already know the size > of the string is greater as 1 (it is checked before the loop), it > is possible to replace the memcmp with (possible doing the decrease > of s_len once outside the loop): memcpy(&cur[1], &cs[1], s_len-1) > > Am I missing something? E.g. is readability more important as > speed? This made me wonder what generally the tradeoff is that has > to be taken into account in these cases? Did you benchmarked the change? Changes like this has to be done very carefully since it's possible that the extra time spent on addition and subtractions, when multiple by the length of the "long" string, may actually defeat the benefit of one less byte worth memory compare because the effect of CPU's data cache. I think it would be worthy to explore if we could use a more advanced algorithm here by the way. Cheers, - -- Xin LI https://www.delphij.net/ FreeBSD - The Power to Serve! Live free or die -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (FreeBSD) iQEcBAEBCAAGBQJPRukLAAoJEG80Jeu8UPuzKlcIAJP+1tL4HfHfAOou39azwBwC DvTOw6XJziv3Pau0GmemE27cWRYHJDGiUzUI95IPFuoCfF/UuHwA8FV5x+wo7dId 3sYyNsqc2Hk9HGw0O5SifaJ5182/2jdJGbMVLl7z1tRlw29HRjubYnvAEizvrMpa IE0O2kvm9LhRlpy8Grnd4sa8WxJ4AGUpCDcAGcDrqM+GcDC5jvd+qO5HgD/yRNqd sXzNfDXtY6vIPND4hyLMJpsTTReTfsWJGL8pYI8T9IqK+/vy2+AzalL9FKoBgOAE z1qkl565J6S4au6v60smNNb0+rIvrPoQrYs8ot4Dl2g8vMKDetj7rGTH3zorKvM= =2Nw3 -----END PGP SIGNATURE----- From owner-freebsd-hackers@FreeBSD.ORG Fri Feb 24 08:12:15 2012 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B79771065670; Fri, 24 Feb 2012 08:12:15 +0000 (UTC) (envelope-from joerg@britannica.bec.de) Received: from mo-p00-ob6.rzone.de (mo-p00-ob6.rzone.de [IPv6:2a01:238:20a:202:53f0::1]) by mx1.freebsd.org (Postfix) with ESMTP id 205B78FC17; Fri, 24 Feb 2012 08:12:14 +0000 (UTC) X-RZG-AUTH: :JiIXek6mfvEEUpFQdo7Fj1/zg48CFjWjQv0cW+St/nW/avgusCdvwXOZ/NA7x/bslx4UOSLYuW7Bwv8PtjkoBcppeXE= X-RZG-CLASS-ID: mo00 Received: from britannica.bec.de ([2001:6f8:13f0:0:224:d7ff:fe63:d530]) by smtp.strato.de (cohen mo38) (RZmta 27.7 AUTH) with (DHE-RSA-AES128-SHA encrypted) ESMTPA id j03f64o1O7CS8B ; Fri, 24 Feb 2012 09:12:00 +0100 (MET) Received: by britannica.bec.de (sSMTP sendmail emulation); Fri, 24 Feb 2012 09:11:51 +0100 Date: Fri, 24 Feb 2012 09:11:51 +0100 From: Joerg Sonnenberger To: freebsd-hackers@freebsd.org, hackers@freebsd.org Message-ID: <20120224081150.GB23692@britannica.bec.de> Mail-Followup-To: freebsd-hackers@freebsd.org, hackers@freebsd.org References: <1BDAF8C6-66A5-4F4F-A2CD-3928A0B10D48@bitpowder.com> <4F46E90B.2050407@delphij.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4F46E90B.2050407@delphij.net> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Subject: Re: memmem small optimalisation X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Feb 2012 08:12:15 -0000 On Thu, Feb 23, 2012 at 05:34:03PM -0800, Xin Li wrote: > Did you benchmarked the change? Changes like this has to be done very > carefully since it's possible that the extra time spent on addition > and subtractions, when multiple by the length of the "long" string, > may actually defeat the benefit of one less byte worth memory compare > because the effect of CPU's data cache. More importantly, if the input was originally aligned, the additional byte is ~free. Joerg From owner-freebsd-hackers@FreeBSD.ORG Fri Feb 24 08:12:15 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B79771065670; Fri, 24 Feb 2012 08:12:15 +0000 (UTC) (envelope-from joerg@britannica.bec.de) Received: from mo-p00-ob6.rzone.de (mo-p00-ob6.rzone.de [IPv6:2a01:238:20a:202:53f0::1]) by mx1.freebsd.org (Postfix) with ESMTP id 205B78FC17; Fri, 24 Feb 2012 08:12:14 +0000 (UTC) X-RZG-AUTH: :JiIXek6mfvEEUpFQdo7Fj1/zg48CFjWjQv0cW+St/nW/avgusCdvwXOZ/NA7x/bslx4UOSLYuW7Bwv8PtjkoBcppeXE= X-RZG-CLASS-ID: mo00 Received: from britannica.bec.de ([2001:6f8:13f0:0:224:d7ff:fe63:d530]) by smtp.strato.de (cohen mo38) (RZmta 27.7 AUTH) with (DHE-RSA-AES128-SHA encrypted) ESMTPA id j03f64o1O7CS8B ; Fri, 24 Feb 2012 09:12:00 +0100 (MET) Received: by britannica.bec.de (sSMTP sendmail emulation); Fri, 24 Feb 2012 09:11:51 +0100 Date: Fri, 24 Feb 2012 09:11:51 +0100 From: Joerg Sonnenberger To: freebsd-hackers@freebsd.org, hackers@freebsd.org Message-ID: <20120224081150.GB23692@britannica.bec.de> Mail-Followup-To: freebsd-hackers@freebsd.org, hackers@freebsd.org References: <1BDAF8C6-66A5-4F4F-A2CD-3928A0B10D48@bitpowder.com> <4F46E90B.2050407@delphij.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4F46E90B.2050407@delphij.net> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Subject: Re: memmem small optimalisation X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Feb 2012 08:12:15 -0000 On Thu, Feb 23, 2012 at 05:34:03PM -0800, Xin Li wrote: > Did you benchmarked the change? Changes like this has to be done very > carefully since it's possible that the extra time spent on addition > and subtractions, when multiple by the length of the "long" string, > may actually defeat the benefit of one less byte worth memory compare > because the effect of CPU's data cache. More importantly, if the input was originally aligned, the additional byte is ~free. Joerg From owner-freebsd-hackers@FreeBSD.ORG Fri Feb 24 11:45:43 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D4D66106566B for ; Fri, 24 Feb 2012 11:45:43 +0000 (UTC) (envelope-from asmrookie@gmail.com) Received: from mail-lpp01m010-f54.google.com (mail-lpp01m010-f54.google.com [209.85.215.54]) by mx1.freebsd.org (Postfix) with ESMTP id 4B84D8FC1A for ; Fri, 24 Feb 2012 11:45:42 +0000 (UTC) Received: by lagz14 with SMTP id z14so3894268lag.13 for ; Fri, 24 Feb 2012 03:45:42 -0800 (PST) Received-SPF: pass (google.com: domain of asmrookie@gmail.com designates 10.152.130.234 as permitted sender) client-ip=10.152.130.234; Authentication-Results: mr.google.com; spf=pass (google.com: domain of asmrookie@gmail.com designates 10.152.130.234 as permitted sender) smtp.mail=asmrookie@gmail.com; dkim=pass header.i=asmrookie@gmail.com Received: from mr.google.com ([10.152.130.234]) by 10.152.130.234 with SMTP id oh10mr1664635lab.35.1330083942131 (num_hops = 1); Fri, 24 Feb 2012 03:45:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=u0Dr0VmATbfy0qEZ8y2XAMmYZY7kS63rHd31mzVaQ3Y=; b=AAtLoCp/0N3JlvwsehwCpzfCos1yQDXAAbbYd5DUvPUz2I+qJZxqA+4sXMkdyoahr/ z3jilvvGJjpHsV92L8UyngOhxUq9QAu4za2DAy4hUI6QmIdRN0ezxu16Wi2EkqNEdILv YOJv7JyBNUKuSa/6D2Kazdz4A4TThW/l3kVFg= MIME-Version: 1.0 Received: by 10.152.130.234 with SMTP id oh10mr1374305lab.35.1330083942030; Fri, 24 Feb 2012 03:45:42 -0800 (PST) Sender: asmrookie@gmail.com Received: by 10.112.41.5 with HTTP; Fri, 24 Feb 2012 03:45:41 -0800 (PST) In-Reply-To: <4F4772AD.5030406@rdtc.ru> References: <4F4772AD.5030406@rdtc.ru> Date: Fri, 24 Feb 2012 11:45:41 +0000 X-Google-Sender-Auth: YqxmkBE6pgKGSRpnqTVN02n4G4Q Message-ID: From: Attilio Rao To: Eugene Grosbein Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-hackers@freebsd.org Subject: Re: Kernel threads inherit CPU affinity from random sibling X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Feb 2012 11:45:43 -0000 2012/2/24, Eugene Grosbein : > 28.01.2012 20:22, Attilio Rao =D0=BF=D0=B8=D1=88=D0=B5=D1=82: > >> 2012/1/28 Ryan Stone : >>> On Fri, Jan 27, 2012 at 10:41 PM, Attilio Rao >>> wrote: >>>> I think what you found out is very sensitive. >>>> However, the patch is not correct as you cannot call >>>> cpuset_setthread() with thread_lock held. >>> >>> Whoops! I actually discovered that for myself and had already fixed >>> it, but apparently I included an old version of the patch in the >>> email. >>> >>>> Hence this is my fix: >>>> http://www.freebsd.org/~attilio/cpuset_root.patch >>> >>> Oh, I do like this better. I tried something similar myself but >>> abandoned it because I misread how sched_affinity() was implemented by >>> 4BSD(I had gotten the impression that once TSF_AFFINITY is set it >>> could never be cleared). >> >> Do you have a pathological test-case for it? Are you going to test the >> patch? > > I have the pathological test-case for it: > http://www.freebsd.org/cgi/query-pr.cgi?pr=3D165444 > A fix has been committed as r230984, it should apply to STABLE_9/8 too, can you try it? Attilio --=20 Peace can only be achieved by understanding - A. Einstein From owner-freebsd-hackers@FreeBSD.ORG Fri Feb 24 12:00:14 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0AA911065672; Fri, 24 Feb 2012 12:00:13 +0000 (UTC) (envelope-from eugen@grosbein.pp.ru) Received: from eg.sd.rdtc.ru (eg.sd.rdtc.ru [IPv6:2a03:3100:c:13::5]) by mx1.freebsd.org (Postfix) with ESMTP id 9269F8FC17; Fri, 24 Feb 2012 12:00:12 +0000 (UTC) Received: from eg.sd.rdtc.ru (localhost [127.0.0.1]) by eg.sd.rdtc.ru (8.14.5/8.14.5) with ESMTP id q1OC0BsE082379; Fri, 24 Feb 2012 19:00:11 +0700 (NOVT) (envelope-from eugen@grosbein.pp.ru) Message-ID: <4F477BCB.4020000@grosbein.pp.ru> Date: Fri, 24 Feb 2012 19:00:11 +0700 From: Eugene Grosbein User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; ru-RU; rv:1.9.2.13) Gecko/20110112 Thunderbird/3.1.7 MIME-Version: 1.0 To: Attilio Rao References: <4F4772AD.5030406@rdtc.ru> In-Reply-To: Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: 8bit Cc: freebsd-hackers@freebsd.org Subject: Re: Kernel threads inherit CPU affinity from random sibling X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Feb 2012 12:00:14 -0000 24.02.2012 18:45, Attilio Rao ÐÉÛÅÔ: >> I have the pathological test-case for it: >> http://www.freebsd.org/cgi/query-pr.cgi?pr=165444 >> > > A fix has been committed as r230984, it should apply to STABLE_9/8 > too, can you try it? > > Attilio > > I will try but I already run my patch for netisr, so it would be difficult to see what helps :-) From owner-freebsd-hackers@FreeBSD.ORG Fri Feb 24 12:05:44 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F1FFA106566C for ; Fri, 24 Feb 2012 12:05:44 +0000 (UTC) (envelope-from asmrookie@gmail.com) Received: from mail-lpp01m010-f54.google.com (mail-lpp01m010-f54.google.com [209.85.215.54]) by mx1.freebsd.org (Postfix) with ESMTP id 610428FC20 for ; Fri, 24 Feb 2012 12:05:44 +0000 (UTC) Received: by lagz14 with SMTP id z14so3923624lag.13 for ; Fri, 24 Feb 2012 04:05:43 -0800 (PST) Received-SPF: pass (google.com: domain of asmrookie@gmail.com designates 10.112.27.199 as permitted sender) client-ip=10.112.27.199; Authentication-Results: mr.google.com; spf=pass (google.com: domain of asmrookie@gmail.com designates 10.112.27.199 as permitted sender) smtp.mail=asmrookie@gmail.com; dkim=pass header.i=asmrookie@gmail.com Received: from mr.google.com ([10.112.27.199]) by 10.112.27.199 with SMTP id v7mr803809lbg.36.1330085143196 (num_hops = 1); Fri, 24 Feb 2012 04:05:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=kTK0f6M4z/hDH4ItE6TsX0DAJ8PIZrWJ2RhqlF9d3kQ=; b=tTRQQbcVQlpMRzQHZd1YXdT0Cg5LttqVG5nY+KDJ9eFw8/YMc0QWU3wtsgm+sMOj4X RAqLB+JbLpTP3TzJl+dZpiFrguUcIozQOJxHsJ6gvaqDxdvsbACFz5xk6S0OrT3PqgzG GJUMItl89xQBunXJV/YiYaGtLHz8Y/lZZvDAA= MIME-Version: 1.0 Received: by 10.112.27.199 with SMTP id v7mr666969lbg.36.1330085143067; Fri, 24 Feb 2012 04:05:43 -0800 (PST) Sender: asmrookie@gmail.com Received: by 10.112.41.5 with HTTP; Fri, 24 Feb 2012 04:05:43 -0800 (PST) In-Reply-To: <4F477BCB.4020000@grosbein.pp.ru> References: <4F4772AD.5030406@rdtc.ru> <4F477BCB.4020000@grosbein.pp.ru> Date: Fri, 24 Feb 2012 12:05:43 +0000 X-Google-Sender-Auth: M3xafbwuULiBGIjLd83iujYFkLM Message-ID: From: Attilio Rao To: Eugene Grosbein Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-hackers@freebsd.org Subject: Re: Kernel threads inherit CPU affinity from random sibling X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Feb 2012 12:05:45 -0000 2012/2/24, Eugene Grosbein : > 24.02.2012 18:45, Attilio Rao =D0=BF=D0=B8=D1=88=D0=B5=D1=82: > >>> I have the pathological test-case for it: >>> http://www.freebsd.org/cgi/query-pr.cgi?pr=3D165444 >>> >> >> A fix has been committed as r230984, it should apply to STABLE_9/8 >> too, can you try it? >> >> Attilio >> >> > > I will try but I already run my patch for netisr, so it would be difficul= t > to see what helps :-) Yes, I mean, can you back your patch out? Attilio --=20 Peace can only be achieved by understanding - A. Einstein From owner-freebsd-hackers@FreeBSD.ORG Fri Feb 24 11:21:19 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 537891065670; Fri, 24 Feb 2012 11:21:19 +0000 (UTC) (envelope-from egrosbein@rdtc.ru) Received: from eg.sd.rdtc.ru (eg.sd.rdtc.ru [IPv6:2a03:3100:c:13::5]) by mx1.freebsd.org (Postfix) with ESMTP id AA28D8FC14; Fri, 24 Feb 2012 11:21:18 +0000 (UTC) Received: from eg.sd.rdtc.ru (localhost [127.0.0.1]) by eg.sd.rdtc.ru (8.14.5/8.14.5) with ESMTP id q1OBLHXO081913; Fri, 24 Feb 2012 18:21:17 +0700 (NOVT) (envelope-from egrosbein@rdtc.ru) Message-ID: <4F4772AD.5030406@rdtc.ru> Date: Fri, 24 Feb 2012 18:21:17 +0700 From: Eugene Grosbein User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; ru-RU; rv:1.9.2.13) Gecko/20110112 Thunderbird/3.1.7 MIME-Version: 1.0 To: Attilio Rao References: In-Reply-To: Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: 8bit X-Mailman-Approved-At: Fri, 24 Feb 2012 12:10:09 +0000 Cc: freebsd-hackers@freebsd.org Subject: Re: Kernel threads inherit CPU affinity from random sibling X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Feb 2012 11:21:19 -0000 28.01.2012 20:22, Attilio Rao ÐÉÛÅÔ: > 2012/1/28 Ryan Stone : >> On Fri, Jan 27, 2012 at 10:41 PM, Attilio Rao wrote: >>> I think what you found out is very sensitive. >>> However, the patch is not correct as you cannot call >>> cpuset_setthread() with thread_lock held. >> >> Whoops! I actually discovered that for myself and had already fixed >> it, but apparently I included an old version of the patch in the >> email. >> >>> Hence this is my fix: >>> http://www.freebsd.org/~attilio/cpuset_root.patch >> >> Oh, I do like this better. I tried something similar myself but >> abandoned it because I misread how sched_affinity() was implemented by >> 4BSD(I had gotten the impression that once TSF_AFFINITY is set it >> could never be cleared). > > Do you have a pathological test-case for it? Are you going to test the patch? I have the pathological test-case for it: http://www.freebsd.org/cgi/query-pr.cgi?pr=165444 Eugene Grosbein From owner-freebsd-hackers@FreeBSD.ORG Fri Feb 24 12:13:55 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A47BA106566C; Fri, 24 Feb 2012 12:13:55 +0000 (UTC) (envelope-from eugen@grosbein.pp.ru) Received: from eg.sd.rdtc.ru (eg.sd.rdtc.ru [IPv6:2a03:3100:c:13::5]) by mx1.freebsd.org (Postfix) with ESMTP id 04DCB8FC0A; Fri, 24 Feb 2012 12:13:54 +0000 (UTC) Received: from eg.sd.rdtc.ru (localhost [127.0.0.1]) by eg.sd.rdtc.ru (8.14.5/8.14.5) with ESMTP id q1OCDpFh082490; Fri, 24 Feb 2012 19:13:51 +0700 (NOVT) (envelope-from eugen@grosbein.pp.ru) Message-ID: <4F477EFF.1030105@grosbein.pp.ru> Date: Fri, 24 Feb 2012 19:13:51 +0700 From: Eugene Grosbein User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; ru-RU; rv:1.9.2.13) Gecko/20110112 Thunderbird/3.1.7 MIME-Version: 1.0 To: Attilio Rao References: <4F4772AD.5030406@rdtc.ru> <4F477BCB.4020000@grosbein.pp.ru> In-Reply-To: Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: 8bit Cc: freebsd-hackers@freebsd.org Subject: Re: Kernel threads inherit CPU affinity from random sibling X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Feb 2012 12:13:55 -0000 24.02.2012 19:05, Attilio Rao ÐÉÛÅÔ: > 2012/2/24, Eugene Grosbein : >> 24.02.2012 18:45, Attilio Rao ÐÉÛÅÔ: >> >>>> I have the pathological test-case for it: >>>> http://www.freebsd.org/cgi/query-pr.cgi?pr=165444 >>>> >>> >>> A fix has been committed as r230984, it should apply to STABLE_9/8 >>> too, can you try it? >>> >>> Attilio >>> >>> >> >> I will try but I already run my patch for netisr, so it would be difficult >> to see what helps :-) > > Yes, I mean, can you back your patch out? Ok, I will. The effect is random, so it will take some time to make sure it works. Eugene Grosbein From owner-freebsd-hackers@FreeBSD.ORG Fri Feb 24 14:05:58 2012 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2FE44106568B for ; Fri, 24 Feb 2012 14:05:58 +0000 (UTC) (envelope-from rank1seeker@gmail.com) Received: from mail-ey0-f182.google.com (mail-ey0-f182.google.com [209.85.215.182]) by mx1.freebsd.org (Postfix) with ESMTP id 5A9118FC1C for ; Fri, 24 Feb 2012 14:05:56 +0000 (UTC) Received: by eaan10 with SMTP id n10so1050673eaa.13 for ; Fri, 24 Feb 2012 06:05:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:from:to:subject:date:content-type :content-transfer-encoding:in-reply-to:references:x-mailer; bh=9fOowzpFrd1R+muoyquGGut4tMQzMNkhhStgdlIcRvo=; b=L7gSUIiZe646iunhgfEDEdtdmlCSLL3ZubifEMZwG5bmtwMzE7I7N/WDWrBmQlgdOW RrHQKSuMcGaSkClJc/6018jrhH63EJ0b8hbZrIc61tWOJiN6XlqAxbZsvCFh2dJShq2S ZYcULxPY8oMi7iTlEQcs7Qe154n3+x/2tMPUs= Received: by 10.14.100.142 with SMTP id z14mr1214485eef.58.1330092356058; Fri, 24 Feb 2012 06:05:56 -0800 (PST) Received: from DOMYPC ([82.193.208.173]) by mx.google.com with ESMTPS id n17sm18537374eei.3.2012.02.24.06.05.52 (version=SSLv3 cipher=OTHER); Fri, 24 Feb 2012 06:05:54 -0800 (PST) Message-ID: <20120224.140554.554.1@DOMY-PC> From: rank1seeker@gmail.com To: hackers@freebsd.org, "John Baldwin" , "Roman Divacky" Date: Fri, 24 Feb 2012 15:05:54 +0100 Content-Type: text/plain; charset="Windows-1250" Content-Transfer-Encoding: quoted-printable In-Reply-To: <201202230802.05083.jhb@freebsd.org> References: <20120217.074355.853.1@DOMY-PC> <201202230802.05083.jhb@freebsd.org> X-Mailer: POP Peeper (3.8.1.0) Cc: Subject: Re: BUG: 9.0 stage 2 boot (/boot/boot) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Feb 2012 14:05:58 -0000 ----- Original Message -----=0D=0AFrom: John Baldwin = =0D=0ATo: freebsd-hackers@freebsd.org=0D=0ACc: = rank1seeker@gmail.com, Roman Divacky =0D=0ADate: = Thu, 23 Feb 2012 08:02:04 -0500=0D=0ASubject: Re: BUG: 9.0 stage 2 boot = (/boot/boot)=0D=0A=0D=0A> On Friday, February 17, 2012 2:43:55 am = rank1seeker@gmail.com wrote:=0D=0A> > Anyway, after upgrading to 9.0, my = USB stick, when created, started to hang =0D=0A> at stage 2 boot.=0D=0A> = > I have a custom setup, where BSD label 'a', has a content of = /boot/*=0D=0A> > So when 'a' is being hit by stage 2 boot, there is = boot.config waiting for =0D=0A> it.=0D=0A> > After it reads it and = displays it's content, it echos 'No' and hangs.=0D=0A> > =0D=0A> > I = stare at it and can't believe as boot.config's information is = correct!=0D=0A> > I hit '?' and it list all files in 'a'.=0D=0A> > Then I = simply RE-type what is displayed on screen (content of boot.config -> = =0D=0A> path to loader)=0D=0A> > And loader kicks in!=0D=0A> > =0D=0A> > = I do this a few times more and EACH time I have to RE-type correct = info!=0D=0A> > Tested on other machine, same thing.=0D=0A> > =0D=0A> > = However, this same custom layout works for HDD's, but NOT for USB = stick.=0D=0A> > =0D=0A> > I've extracted binary installs of 8.2 and 9.0 = R:=0D=0A> > MD5 (8_boot) =3D adb1e84e96bd434e51cafaaa0ef22584=0D=0A> > = MD5 (9_boot) =3D 40f3f6403ebd5e131259d1336b4b50ad=0D=0A> > =0D=0A> > = Then:=0D=0A> > # gpart bootcode -b 8_boot da0s2=0D=0A> > And sudenly that = USB stick boots, without ANY other change!=0D=0A> > Just an "old" stage 2 = boot code, from R8 was enough.=0D=0A> =0D=0A> Looks like it is thinking = that 'kname' is empty. Ah, I think Roman broke this=0D=0A> in = 219186:=0D=0A> =0D=0A> @@ -474,11 +461,7 @@ parse()=0D=0A> ? = DRV_HARD : 0) + drv;=0D=0A> dsk_meta =3D 0;=0D=0A> }=0D=0A> - = if ((i =3D ep - arg)) {=0D=0A> - if ((size_t)i >=3D = sizeof(kname))=0D=0A> - return -1;=0D=0A> - memcpy(kname, arg, i + = 1);=0D=0A> - }=0D=0A> + kname =3D arg;=0D=0A> }=0D=0A> = arg =3D p;=0D=0A> }=0D=0A> =0D=0A> Before it only set kname if it = wasn't an empty string. Now it always sets=0D=0A> kname. Try this = change:=0D=0A> =0D=0A> Index: boot2.c=0D=0A> = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=0D=0A> = --- boot2.c (revision 231983)=0D=0A> +++ boot2.c (working copy)=0D=0A> @@ = -457,7 +457,8 @@ parse()=0D=0A> ? DRV_HARD : 0) + drv;=0D=0A> = dsk_meta =3D 0;=0D=0A> }=0D=0A> - kname =3D arg;=0D=0A> = + if (*arg !=3D '\0')=0D=0A> + kname =3D arg;=0D=0A> }=0D=0A> = arg =3D p;=0D=0A> }=0D=0A> =0D=0A> -- =0D=0A> John Baldwin=0D=0A> = =0D=0A=0D=0A=0D=0AIt still doesn't work!=0D=0A=0D=0AAnd please, next time = attach patch in a file (unified format), so I would have a less hassle = (to avoid manuall patch application)=0D=0AThx in = advance.=0D=0A=0D=0A=0D=0ADomagoj Smol=E8i=E6=0D=0A From owner-freebsd-hackers@FreeBSD.ORG Fri Feb 24 16:03:26 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A24C2106564A for ; Fri, 24 Feb 2012 16:03:26 +0000 (UTC) (envelope-from freebsd-hackers@m.gmane.org) Received: from plane.gmane.org (plane.gmane.org [80.91.229.3]) by mx1.freebsd.org (Postfix) with ESMTP id 582058FC08 for ; Fri, 24 Feb 2012 16:03:26 +0000 (UTC) Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1S0xc5-0002lW-Ns for freebsd-hackers@freebsd.org; Fri, 24 Feb 2012 17:03:17 +0100 Received: from lara.cc.fer.hr ([161.53.72.113]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 24 Feb 2012 17:03:17 +0100 Received: from ivoras by lara.cc.fer.hr with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 24 Feb 2012 17:03:17 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-hackers@freebsd.org From: Ivan Voras Date: Fri, 24 Feb 2012 17:03:00 +0100 Lines: 40 Message-ID: Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig1753D0189C70973BDF8F1B3F" X-Complaints-To: usenet@dough.gmane.org X-Gmane-NNTP-Posting-Host: lara.cc.fer.hr User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:10.0) Gecko/20120213 Thunderbird/10.0 X-Enigmail-Version: 1.3.5 Subject: Tracking memory, PCI(-E) bus usage? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Feb 2012 16:03:26 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig1753D0189C70973BDF8F1B3F Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable This is mostly idle wanderings than anything useful, but I've just redirected an application which creates a lot of temporary data to a tmpfs mount point and I'm happily observing disk bandwidth dwindling from a sustained many dozens of MB/s to merely hundreds of KB/s, which is the value the system was designed for. That got me thinking that I would also be happy if I could observe the bandwidth used by the memory file system, and even memory in total, and by extension, the traffic on various busses. So this is the question for people who twiddle with the hardware level: is there a way in which those quantities could be tracked in real-time? For the memory, I guess it would depend on the memory controller, but even memory controllers are built-in in recent CPUs, which means there could be a way. I'm vaguely recalling that PCI-E (at least) works in some kind of packet-based transaction mode so it seems possible that it could also offer some metrics. --------------enig1753D0189C70973BDF8F1B3F Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk9HtLQACgkQldnAQVacBcgF/gCePk6ZRdQ7QIo4pg9ymvOoZNmI tQ8AoKjMFnP77TvUx2oG3TyNIPywAurR =WJag -----END PGP SIGNATURE----- --------------enig1753D0189C70973BDF8F1B3F-- From owner-freebsd-hackers@FreeBSD.ORG Fri Feb 24 17:54:40 2012 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7B619106567B; Fri, 24 Feb 2012 17:54:40 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 4F2268FC19; Fri, 24 Feb 2012 17:54:40 +0000 (UTC) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [96.47.65.170]) by cyrus.watson.org (Postfix) with ESMTPSA id 0897246B2A; Fri, 24 Feb 2012 12:54:40 -0500 (EST) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 67F6AB967; Fri, 24 Feb 2012 12:54:39 -0500 (EST) From: John Baldwin To: rank1seeker@gmail.com Date: Fri, 24 Feb 2012 12:23:45 -0500 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p10; KDE/4.5.5; amd64; ; ) References: <20120217.074355.853.1@DOMY-PC> <201202230802.05083.jhb@freebsd.org> <20120224.140554.554.1@DOMY-PC> In-Reply-To: <20120224.140554.554.1@DOMY-PC> MIME-Version: 1.0 Content-Type: Text/Plain; charset="windows-1250" Content-Transfer-Encoding: 7bit Message-Id: <201202241223.45255.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Fri, 24 Feb 2012 12:54:39 -0500 (EST) Cc: Roman Divacky , hackers@freebsd.org Subject: Re: BUG: 9.0 stage 2 boot (/boot/boot) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Feb 2012 17:54:40 -0000 On Friday, February 24, 2012 9:05:54 am rank1seeker@gmail.com wrote: > ----- Original Message ----- > From: John Baldwin > To: freebsd-hackers@freebsd.org > Cc: rank1seeker@gmail.com, Roman Divacky > Date: Thu, 23 Feb 2012 08:02:04 -0500 > Subject: Re: BUG: 9.0 stage 2 boot (/boot/boot) > > > On Friday, February 17, 2012 2:43:55 am rank1seeker@gmail.com wrote: > > > Anyway, after upgrading to 9.0, my USB stick, when created, started to hang > > at stage 2 boot. > > > I have a custom setup, where BSD label 'a', has a content of /boot/* > > > So when 'a' is being hit by stage 2 boot, there is boot.config waiting for > > it. > > > After it reads it and displays it's content, it echos 'No' and hangs. > > > > > > I stare at it and can't believe as boot.config's information is correct! > > > I hit '?' and it list all files in 'a'. > > > Then I simply RE-type what is displayed on screen (content of boot.config -> > > path to loader) > > > And loader kicks in! > > > > > > I do this a few times more and EACH time I have to RE-type correct info! > > > Tested on other machine, same thing. > > > > > > However, this same custom layout works for HDD's, but NOT for USB stick. > > > > > > I've extracted binary installs of 8.2 and 9.0 R: > > > MD5 (8_boot) = adb1e84e96bd434e51cafaaa0ef22584 > > > MD5 (9_boot) = 40f3f6403ebd5e131259d1336b4b50ad > > > > > > Then: > > > # gpart bootcode -b 8_boot da0s2 > > > And sudenly that USB stick boots, without ANY other change! > > > Just an "old" stage 2 boot code, from R8 was enough. > > > > Looks like it is thinking that 'kname' is empty. Ah, I think Roman broke this > > in 219186: > > > > @@ -474,11 +461,7 @@ parse() > > ? DRV_HARD : 0) + drv; > > dsk_meta = 0; > > } > > - if ((i = ep - arg)) { > > - if ((size_t)i >= sizeof(kname)) > > - return -1; > > - memcpy(kname, arg, i + 1); > > - } > > + kname = arg; > > } > > arg = p; > > } > > > > Before it only set kname if it wasn't an empty string. Now it always sets > > kname. Try this change: > > > > Index: boot2.c > > =================================================================== > > --- boot2.c (revision 231983) > > +++ boot2.c (working copy) > > @@ -457,7 +457,8 @@ parse() > > ? DRV_HARD : 0) + drv; > > dsk_meta = 0; > > } > > - kname = arg; > > + if (*arg != '\0') > > + kname = arg; > > } > > arg = p; > > } > > > > -- > > John Baldwin > > > > > It still doesn't work! > > And please, next time attach patch in a file (unified format), so I would have a less hassle (to avoid manuall patch application) Do you still get 'No ' with no other message before it breaks? Can you show me the contents of your /boot.config file via hd? -- John Baldwin From owner-freebsd-hackers@FreeBSD.ORG Fri Feb 24 18:27:38 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 338D7106566C; Fri, 24 Feb 2012 18:27:38 +0000 (UTC) (envelope-from rysto32@gmail.com) Received: from mail-wi0-f182.google.com (mail-wi0-f182.google.com [209.85.212.182]) by mx1.freebsd.org (Postfix) with ESMTP id 98F498FC16; Fri, 24 Feb 2012 18:27:37 +0000 (UTC) Received: by wibhn14 with SMTP id hn14so2445250wib.13 for ; Fri, 24 Feb 2012 10:27:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=pokfPHEr9zknM6CJVJNmpHNliyVa7Gbniw/P9UVHdMs=; b=x9sOPA1/7hffZQj2NUwVM1IU+WuKzOSrstXAn7WQC4YK/GzRBFkmFw0HT9hVymLgQ5 zx+FwBDeuRRqwIZS2auxweJm2I7txE2MeUsLFPS4cScs1fcFoPLcaE9ressxtgOKnWdX fanE1ZOUfu4LfUo6zgMxcm3FNLvCsM2rqFHvc= MIME-Version: 1.0 Received: by 10.180.80.35 with SMTP id o3mr6134932wix.5.1330108056520; Fri, 24 Feb 2012 10:27:36 -0800 (PST) Received: by 10.180.75.41 with HTTP; Fri, 24 Feb 2012 10:27:36 -0800 (PST) In-Reply-To: References: Date: Fri, 24 Feb 2012 13:27:36 -0500 Message-ID: From: Ryan Stone To: Ivan Voras Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-hackers@freebsd.org Subject: Re: Tracking memory, PCI(-E) bus usage? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Feb 2012 18:27:38 -0000 I can't help you with PCI bandwidth usage(and personally I'd be very interested in being able to measure that), but I do know that Nehalem-based Intel Core i7s (and presumably more recent Intel CPUs) export PMCs for measuring memory bandwidth utilization. The PMCs for the Core i7 are: QMC_BUSY.WRITE.CH0 QMC_BUSY.READ.CH0 QMC_BUSY.WRITE.CH1 QMC_BUSY.READ.CH1 QMC_BUSY.WRITE.CH2 QMC_BUSY.READ.CH2 You can divide these by UCLOCK to get the percent utilization. If you hate doing math by hand I've written a simple curses-based utility for measuring PMC statistics like this: https://code.google.com/p/perfdb/ It outputs stats like this: Memory Channel Utilization: (hotkey m) GQ_Write_Nonempty: 0.11 GQ_To_L3_Busy: 0.00 GQ_To_QPI_Busy: 0.00 GQ_To_Core_Busy: 0.00 Chan0_Util_Write: 0.01 Chan0_Util_Read: 0.03 Chan1_Util_Write: 0.00 Chan1_Util_Read: 0.03 Chan2_Util_Write: 0.00 Chan2_Util_Read: 0.00 It's still very much a work in progress and there's zero documentation for it(hint: the left and right arrow keys are used to cycle between pages of stats, and the q key quits) but I thought that I'd mention it. From owner-freebsd-hackers@FreeBSD.ORG Fri Feb 24 19:11:55 2012 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6DED9106566C; Fri, 24 Feb 2012 19:11:55 +0000 (UTC) (envelope-from rank1seeker@gmail.com) Received: from mail-ee0-f54.google.com (mail-ee0-f54.google.com [74.125.83.54]) by mx1.freebsd.org (Postfix) with ESMTP id 974728FC13; Fri, 24 Feb 2012 19:11:54 +0000 (UTC) Received: by eekd17 with SMTP id d17so396616eek.13 for ; Fri, 24 Feb 2012 11:11:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:from:to:subject:date:content-type :content-transfer-encoding:in-reply-to:references:x-mailer; bh=/C7pc8dPKzpwqpY9CKbtNHN3jgl6ReOCVg0nksTzb28=; b=v7/N0f4OyjoqZ0pPHRzveqCTzAGuBhCVzd/na9bg79/kJcvWNakeEYSZlxxxvTTlOX LFYgz5qgSroGaLv4ZvQ//hagZYF3GkocySOb3+CieDtIFI7aETXX+30wjUy18UHuYsni +gKJsyEhFzAl7EH54mNAwuA7xbDvttXmTNwys= Received: by 10.14.95.135 with SMTP id p7mr1655574eef.62.1330110713402; Fri, 24 Feb 2012 11:11:53 -0800 (PST) Received: from DOMYPC ([82.193.208.173]) by mx.google.com with ESMTPS id w60sm21314780eeb.4.2012.02.24.11.11.49 (version=SSLv3 cipher=OTHER); Fri, 24 Feb 2012 11:11:52 -0800 (PST) Message-ID: <20120224.191152.168.2@DOMY-PC> From: rank1seeker@gmail.com To: hackers@freebsd.org, "John Baldwin" , "Roman Divacky" Date: Fri, 24 Feb 2012 20:11:52 +0100 Content-Type: text/plain; charset="Windows-1250" Content-Transfer-Encoding: quoted-printable In-Reply-To: <201202241223.45255.jhb@freebsd.org> References: <20120217.074355.853.1@DOMY-PC> <201202230802.05083.jhb@freebsd.org> <20120224.140554.554.1@DOMY-PC> <201202241223.45255.jhb@freebsd.org> X-Mailer: POP Peeper (3.8.1.0) Cc: Subject: Re: BUG: 9.0 stage 2 boot (/boot/boot) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Feb 2012 19:11:55 -0000 ----- Original Message -----=0D=0AFrom: John Baldwin = =0D=0ATo: rank1seeker@gmail.com=0D=0ACc: = hackers@freebsd.org, "Roman Divacky" =0D=0ADate: = Fri, 24 Feb 2012 12:23:45 -0500=0D=0ASubject: Re: BUG: 9.0 stage 2 boot = (/boot/boot)=0D=0A=0D=0A> On Friday, February 24, 2012 9:05:54 am = rank1seeker@gmail.com wrote:=0D=0A> > ----- Original Message -----=0D=0A> = > From: John Baldwin =0D=0A> > To: = freebsd-hackers@freebsd.org=0D=0A> > Cc: rank1seeker@gmail.com, Roman = Divacky =0D=0A> > Date: Thu, 23 Feb 2012 08:02:04 = -0500=0D=0A> > Subject: Re: BUG: 9.0 stage 2 boot (/boot/boot)=0D=0A> > = =0D=0A> > > On Friday, February 17, 2012 2:43:55 am rank1seeker@gmail.com = wrote:=0D=0A> > > > Anyway, after upgrading to 9.0, my USB stick, when = created, started to =0D=0A> hang =0D=0A> > > at stage 2 boot.=0D=0A> > > = > I have a custom setup, where BSD label 'a', has a content of = /boot/*=0D=0A> > > > So when 'a' is being hit by stage 2 boot, there is = boot.config waiting =0D=0A> for =0D=0A> > > it.=0D=0A> > > > After it = reads it and displays it's content, it echos 'No' and hangs.=0D=0A> > > > = =0D=0A> > > > I stare at it and can't believe as boot.config's = information is correct!=0D=0A> > > > I hit '?' and it list all files in = 'a'.=0D=0A> > > > Then I simply RE-type what is displayed on screen = (content of =0D=0A> boot.config -> =0D=0A> > > path to loader)=0D=0A> > > = > And loader kicks in!=0D=0A> > > > =0D=0A> > > > I do this a few times = more and EACH time I have to RE-type correct info!=0D=0A> > > > Tested on = other machine, same thing.=0D=0A> > > > =0D=0A> > > > However, this same = custom layout works for HDD's, but NOT for USB stick.=0D=0A> > > > = =0D=0A> > > > I've extracted binary installs of 8.2 and 9.0 R:=0D=0A> > > = > MD5 (8_boot) =3D adb1e84e96bd434e51cafaaa0ef22584=0D=0A> > > > MD5 = (9_boot) =3D 40f3f6403ebd5e131259d1336b4b50ad=0D=0A> > > > =0D=0A> > > > = Then:=0D=0A> > > > # gpart bootcode -b 8_boot da0s2=0D=0A> > > > And = sudenly that USB stick boots, without ANY other change!=0D=0A> > > > Just = an "old" stage 2 boot code, from R8 was enough.=0D=0A> > > =0D=0A> > > = Looks like it is thinking that 'kname' is empty. Ah, I think Roman broke = =0D=0A> this=0D=0A> > > in 219186:=0D=0A> > > =0D=0A> > > @@ -474,11 = +461,7 @@ parse()=0D=0A> > > ? DRV_HARD : 0) + drv;=0D=0A> > > = dsk_meta =3D 0;=0D=0A> > > }=0D=0A> > > - if ((i =3D ep - = arg)) {=0D=0A> > > - if ((size_t)i >=3D sizeof(kname))=0D=0A> > > - = return -1;=0D=0A> > > - memcpy(kname, arg, i + 1);=0D=0A> > > - = }=0D=0A> > > + kname =3D arg;=0D=0A> > > }=0D=0A> > > arg = =3D p;=0D=0A> > > }=0D=0A> > > =0D=0A> > > Before it only set kname = if it wasn't an empty string. Now it always sets=0D=0A> > > kname. Try = this change:=0D=0A> > > =0D=0A> > > Index: boot2.c=0D=0A> > > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=0D=0A> = > > --- boot2.c (revision 231983)=0D=0A> > > +++ boot2.c (working = copy)=0D=0A> > > @@ -457,7 +457,8 @@ parse()=0D=0A> > > ? = DRV_HARD : 0) + drv;=0D=0A> > > dsk_meta =3D 0;=0D=0A> > > = }=0D=0A> > > - kname =3D arg;=0D=0A> > > + if (*arg !=3D = '\0')=0D=0A> > > + kname =3D arg;=0D=0A> > > }=0D=0A> > > arg = =3D p;=0D=0A> > > }=0D=0A> > > =0D=0A> > > -- =0D=0A> > > John = Baldwin=0D=0A> > > =0D=0A> > =0D=0A> > =0D=0A> > It still doesn't = work!=0D=0A> > =0D=0A> > And please, next time attach patch in a file = (unified format), so I would =0D=0A> have a less hassle (to avoid = manuall patch application)=0D=0A> =0D=0A> Do you still get 'No ' with no = other message before it breaks?=0D=0A=0D=0A=0D=0AI get 'No ' with no = other message before it HANGS waiting for manual input?=0D=0AManual input = makes it work.=0D=0AI simply RE-type outputed contest of boot.config = file.=0D=0A=0D=0A=0D=0A> Can you show me the contents of your = /boot.config file via hd?=0D=0A=0D=0A=0D=0ABoth USB stick and HDD have a = same boot.config file, = contents:=0D=0A---=0D=0A/loader=0D=0A---=0D=0A=0D=0A =0D=0A> -- =0D=0A> = John Baldwin=0D=0A =0D=0A=0D=0A=0D=0ADomagoj Smol=E8i=E6 From owner-freebsd-hackers@FreeBSD.ORG Fri Feb 24 20:31:13 2012 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9E247106566B; Fri, 24 Feb 2012 20:31:13 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 5E1DB8FC1A; Fri, 24 Feb 2012 20:31:13 +0000 (UTC) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [96.47.65.170]) by cyrus.watson.org (Postfix) with ESMTPSA id 10D2346B0C; Fri, 24 Feb 2012 15:31:13 -0500 (EST) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 68990B941; Fri, 24 Feb 2012 15:31:12 -0500 (EST) From: John Baldwin To: rank1seeker@gmail.com Date: Fri, 24 Feb 2012 15:31:11 -0500 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p10; KDE/4.5.5; amd64; ; ) References: <20120217.074355.853.1@DOMY-PC> <201202241223.45255.jhb@freebsd.org> <20120224.191152.168.2@DOMY-PC> In-Reply-To: <20120224.191152.168.2@DOMY-PC> MIME-Version: 1.0 Content-Type: Text/Plain; charset="windows-1250" Content-Transfer-Encoding: 7bit Message-Id: <201202241531.11281.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Fri, 24 Feb 2012 15:31:12 -0500 (EST) Cc: Roman Divacky , hackers@freebsd.org Subject: Re: BUG: 9.0 stage 2 boot (/boot/boot) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Feb 2012 20:31:13 -0000 On Friday, February 24, 2012 2:11:52 pm rank1seeker@gmail.com wrote: > ----- Original Message ----- > From: John Baldwin > To: rank1seeker@gmail.com > Cc: hackers@freebsd.org, "Roman Divacky" > Date: Fri, 24 Feb 2012 12:23:45 -0500 > Subject: Re: BUG: 9.0 stage 2 boot (/boot/boot) > > > On Friday, February 24, 2012 9:05:54 am rank1seeker@gmail.com wrote: > > > ----- Original Message ----- > > > From: John Baldwin > > > To: freebsd-hackers@freebsd.org > > > Cc: rank1seeker@gmail.com, Roman Divacky > > > Date: Thu, 23 Feb 2012 08:02:04 -0500 > > > Subject: Re: BUG: 9.0 stage 2 boot (/boot/boot) > > > > > > > On Friday, February 17, 2012 2:43:55 am rank1seeker@gmail.com wrote: > > > > > Anyway, after upgrading to 9.0, my USB stick, when created, started to > > hang > > > > at stage 2 boot. > > > > > I have a custom setup, where BSD label 'a', has a content of /boot/* > > > > > So when 'a' is being hit by stage 2 boot, there is boot.config waiting > > for > > > > it. > > > > > After it reads it and displays it's content, it echos 'No' and hangs. > > > > > > > > > > I stare at it and can't believe as boot.config's information is correct! > > > > > I hit '?' and it list all files in 'a'. > > > > > Then I simply RE-type what is displayed on screen (content of > > boot.config -> > > > > path to loader) > > > > > And loader kicks in! > > > > > > > > > > I do this a few times more and EACH time I have to RE-type correct info! > > > > > Tested on other machine, same thing. > > > > > > > > > > However, this same custom layout works for HDD's, but NOT for USB stick. > > > > > > > > > > I've extracted binary installs of 8.2 and 9.0 R: > > > > > MD5 (8_boot) = adb1e84e96bd434e51cafaaa0ef22584 > > > > > MD5 (9_boot) = 40f3f6403ebd5e131259d1336b4b50ad > > > > > > > > > > Then: > > > > > # gpart bootcode -b 8_boot da0s2 > > > > > And sudenly that USB stick boots, without ANY other change! > > > > > Just an "old" stage 2 boot code, from R8 was enough. > > > > > > > > Looks like it is thinking that 'kname' is empty. Ah, I think Roman broke > > this > > > > in 219186: > > > > > > > > @@ -474,11 +461,7 @@ parse() > > > > ? DRV_HARD : 0) + drv; > > > > dsk_meta = 0; > > > > } > > > > - if ((i = ep - arg)) { > > > > - if ((size_t)i >= sizeof(kname)) > > > > - return -1; > > > > - memcpy(kname, arg, i + 1); > > > > - } > > > > + kname = arg; > > > > } > > > > arg = p; > > > > } > > > > > > > > Before it only set kname if it wasn't an empty string. Now it always sets > > > > kname. Try this change: > > > > > > > > Index: boot2.c > > > > =================================================================== > > > > --- boot2.c (revision 231983) > > > > +++ boot2.c (working copy) > > > > @@ -457,7 +457,8 @@ parse() > > > > ? DRV_HARD : 0) + drv; > > > > dsk_meta = 0; > > > > } > > > > - kname = arg; > > > > + if (*arg != '\0') > > > > + kname = arg; > > > > } > > > > arg = p; > > > > } > > > > > > > > -- > > > > John Baldwin > > > > > > > > > > > > > It still doesn't work! > > > > > > And please, next time attach patch in a file (unified format), so I would > > have a less hassle (to avoid manuall patch application) Hmm, our mailing lists each attachments, so you are less likely to get the patch that way. > > Do you still get 'No ' with no other message before it breaks? > > > I get 'No ' with no other message before it HANGS waiting for manual input? > Manual input makes it work. > I simply RE-type outputed contest of boot.config file. > > > > Can you show me the contents of your /boot.config file via hd? > > > Both USB stick and HDD have a same boot.config file, contents: > --- > /loader > --- Hmm, you didn't pass it to hd(1) like I asked. Anyway, I hacked up a test program to run the parse() routine from boot2.c and it DTRT. Do you only see the "No " message? Do you see the '/boot.config: /loader' message? (Do you have RBX_QUIET enabled perhaps? (-q)) Do you get the actual boot2 prompt at all? Hmm, I think the problem is that 'opts' has garbage instead of being initialized to zero. Try this (also at www.freebsd.org/~jhb/patches/boot2_opts.patch): Index: boot2.c =================================================================== --- boot2.c (revision 231983) +++ boot2.c (working copy) @@ -224,6 +224,7 @@ uint8_t autoboot; ino_t ino; + opts = 0; kname = NULL; dmadat = (void *)(roundup2(__base + (int32_t)&_end, 0x10000) - __base); v86.ctl = V86_FLAGS; -- John Baldwin From owner-freebsd-hackers@FreeBSD.ORG Fri Feb 24 21:10:15 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6913D1065678 for ; Fri, 24 Feb 2012 21:10:15 +0000 (UTC) (envelope-from dieterbsd@engineer.com) Received: from mailout-us.mail.com (mailout-us.gmx.com [74.208.5.67]) by mx1.freebsd.org (Postfix) with SMTP id 103C48FC13 for ; Fri, 24 Feb 2012 21:10:15 +0000 (UTC) Received: (qmail 15887 invoked by uid 0); 24 Feb 2012 21:10:14 -0000 Received: from 67.206.184.146 by rms-us018 with HTTP Content-Type: text/plain; charset="utf-8" Date: Fri, 24 Feb 2012 16:10:09 -0500 From: "Dieter BSD" Message-ID: <20120224211011.300960@gmx.com> MIME-Version: 1.0 To: freebsd-hackers@freebsd.org X-Authenticated: #74169980 X-Flags: 0001 X-Mailer: GMX.com Web Mailer x-registered: 0 Content-Transfer-Encoding: 8bit X-GMX-UID: 5Jk1b/QU3zOlNR3dAHAhujh+IGRvb4Dc Subject: Re: OS support for fault tolerance X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Feb 2012 21:10:15 -0000 >> The problem then is how to feed both machines the same inputs, and >> compare the outputs. Do we need a third machine to supervise? >> Can we have each machine keep an eye on the other, avoiding the >> need for a third machine? > > A pair would work as long as the only failures are "obvious" (e.g. > crashes).  If they simply disagree as to the result, how would we > determine which one was right? Depends on what sort of work the machine is doing.  If the job is something that can be done again, you could simply try again, if you still get different answers try a third machine or wade in and start manually inspecting things until you find the problem. If the job is time critical or you can't get the same inputs again, then the machine needs to get it right the first time.  How many 9s of reliability do you need and how many resources can you throw at it?  2x hardware can be good for better than 5 9s. (high quality hardware and software, and technicians standing by with cold spares) I've heard that mil gear uses 3x hardware. Building a 5 9s system is... non-trivial.  So I'm wondering what sort of reliability we can get with 2x off the shelf commodity hardware and a bit of software?  Similar to mirroring/RAID but with whole computers rather than just disks.  Classic Unix technique of doing 10-20% of the work and getting 80-90% of the result. >> Which then leads to the issue of how to avoid problems when *it* >> breaks. > > For some reason, this reminds me of a Dr. Seuss story: > http://www.goodreads.com/review/show/49519038 *grin*  Gotta love Dr. Seuss. From owner-freebsd-hackers@FreeBSD.ORG Fri Feb 24 21:39:13 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 155C4106566C for ; Fri, 24 Feb 2012 21:39:13 +0000 (UTC) (envelope-from rysto32@gmail.com) Received: from mail-we0-f182.google.com (mail-we0-f182.google.com [74.125.82.182]) by mx1.freebsd.org (Postfix) with ESMTP id 995168FC14 for ; Fri, 24 Feb 2012 21:39:12 +0000 (UTC) Received: by werm13 with SMTP id m13so2558664wer.13 for ; Fri, 24 Feb 2012 13:39:11 -0800 (PST) Received-SPF: pass (google.com: domain of rysto32@gmail.com designates 10.180.92.165 as permitted sender) client-ip=10.180.92.165; Authentication-Results: mr.google.com; spf=pass (google.com: domain of rysto32@gmail.com designates 10.180.92.165 as permitted sender) smtp.mail=rysto32@gmail.com; dkim=pass header.i=rysto32@gmail.com Received: from mr.google.com ([10.180.92.165]) by 10.180.92.165 with SMTP id cn5mr8964594wib.2.1330119551721 (num_hops = 1); Fri, 24 Feb 2012 13:39:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; bh=NmRbrXULm1fHcnW5Lry7q9CM0pNXnyE40ogWhBP9lhI=; b=fwbkfi/13EN8rqHh41BUl5/JxPY2ajWtwgccyXHKBaibdD8791PGFyBWMocCgPMFCW R/jsBdqCy7RHWcGyFFHdSjz+yEMd9WailXtea+RS7FArU7H8CVfUZDqYm2xF4R8kQnqH lDCxfDVf/MWck0rV5tUYhb8Zow/wrJivZrPFA= MIME-Version: 1.0 Received: by 10.180.92.165 with SMTP id cn5mr7127127wib.2.1330119551671; Fri, 24 Feb 2012 13:39:11 -0800 (PST) Received: by 10.180.75.41 with HTTP; Fri, 24 Feb 2012 13:39:11 -0800 (PST) Date: Fri, 24 Feb 2012 16:39:11 -0500 Message-ID: From: Ryan Stone To: freebsd-hackers@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Subject: vm_pageout_page_stats() calling pmap_remove_all() on pages that it deactivates X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Feb 2012 21:39:13 -0000 Near the end of vm_pageout_page_stats() there is the following code: if (m->act_count == 0) { /* * We turn off page access, so that we have * more accurate RSS stats. We don't do this * in the normal page deactivation when the * system is loaded VM wise, because the * cost of the large number of page protect * operations would be higher than the value * of doing the operation. */ pmap_remove_all(m); vm_page_deactivate(m); } I question how useful it is to remove m from every pmap. The stated reasoning in the comment above is that it makes for more accurate RSS statistics. However, vm_pageout_page_stats() only does anything at all when there is a shortage of inactive+cache+free pages, so I find the assertion that this leads to a "more accurate" RSS accounting a bit specious when the rest of the VM subsystem isn't trying to provide accurate RSS stats at all. Besides, the page is still resident in memory if we've only deactivated it. This code seems to be conflating "resident set" with "working set". The page still being resident in memory is why I think removing the page from the pmap is the wrong thing to do here. The situation that lead me to looking at this code was pretty simple: I had a daemon running on a swapless system leaking memory. I was running a script that logged the output of top periodically. What I saw was the VSS and RSS of the daemon growing steadily over time until all of a sudden, its RSS dropped dramatically and the system's inactive page count dropped(this was vm_pageout_page_stats() kicking in due to the memory shortage). I was mislead into thinking that the daemon had just freed a lot of memory and that malloc had called madvise(..., MADV_FREE) to free the pages back to the kernel. Of course the newly deactivated pages could never be freed and I spent a day going in the entirely wrong direction before I figured out what vm_pageout_page_stats() was doing and stopped looking for bugs in madvise. In investigating this I did stumble upon one situation where removing the pages on deactivation lead to very bad behaviour. I had a system with a lot of wired memory and about 200MB free. I ran a test program to allocate nearly all of the free memory and then sit there sleeping, never touching it again. vm_pageout_page_stats() duly kicked in and deactivated the test program's memory, bringing its resident set down to a couple of KB. However that didn't actually succeed in freeing any memory, and so the next time I tried to ssh to it or something the OOM killer ended up having to be invoked. It went on a mass killing spree, but never even considered killing my test program because its RSS was so small(despite the fact that it was holding on to most of the memory in the system). It's a bit of a corner case: I think that you have to have a ton of wired memory, no swap and just the right amount of free memory(the fact that most of the unwired-but-allocated memory on that system was allocated to daemons that restarted themselves automatically probably didn't help the situation at all, as they kept running the system back to the edge). Anyway, given that I can't see any value to removing a page from a pmap just because we are deactivating it, and it seems to cause confusion and even less-than-ideal (and arguably incorrect) behaviour in certain corner cases, should it just be removed? Or is there some subtly to this that I'm missing? From owner-freebsd-hackers@FreeBSD.ORG Fri Feb 24 21:59:25 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0ACC7106564A for ; Fri, 24 Feb 2012 21:59:25 +0000 (UTC) (envelope-from amvandemore@gmail.com) Received: from mail-we0-f182.google.com (mail-we0-f182.google.com [74.125.82.182]) by mx1.freebsd.org (Postfix) with ESMTP id 8A0A88FC0A for ; Fri, 24 Feb 2012 21:59:24 +0000 (UTC) Received: by werm13 with SMTP id m13so2569439wer.13 for ; Fri, 24 Feb 2012 13:59:23 -0800 (PST) Received-SPF: pass (google.com: domain of amvandemore@gmail.com designates 10.180.99.7 as permitted sender) client-ip=10.180.99.7; Authentication-Results: mr.google.com; spf=pass (google.com: domain of amvandemore@gmail.com designates 10.180.99.7 as permitted sender) smtp.mail=amvandemore@gmail.com; dkim=pass header.i=amvandemore@gmail.com Received: from mr.google.com ([10.180.99.7]) by 10.180.99.7 with SMTP id em7mr8866882wib.7.1330120763510 (num_hops = 1); Fri, 24 Feb 2012 13:59:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=FY/uwovC3n4T/aVz9IOSyud/ffyrxrQ1t6ES2vxeIqU=; b=MZvzIdBNf/MZ57UKZnbE7s514GeGwCX4Xc+C76beDaJkFcGBagEflh/qlumEpqljDD /paW0hz7ayTyD0Wg7Jtw9u8sIa2PSEwqmgmsYP9eC020H8Tqi+8lZpcycvtcwkOtERa7 3G6b/f/tJxXR7+RVdhd/B5wSBDBcWL93WN75s= MIME-Version: 1.0 Received: by 10.180.99.7 with SMTP id em7mr7016348wib.7.1330118930638; Fri, 24 Feb 2012 13:28:50 -0800 (PST) Received: by 10.223.93.138 with HTTP; Fri, 24 Feb 2012 13:28:50 -0800 (PST) In-Reply-To: <20120224211011.300960@gmx.com> References: <20120224211011.300960@gmx.com> Date: Fri, 24 Feb 2012 15:28:50 -0600 Message-ID: From: Adam Vande More To: Dieter BSD Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-hackers@freebsd.org Subject: Re: OS support for fault tolerance X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Feb 2012 21:59:25 -0000 On Fri, Feb 24, 2012 at 3:10 PM, Dieter BSD wrote: > Depends on what sort of work the machine is doing. If the job is > something that can be done again, you could simply try again, if > you still get different answers try a third machine or wade in and > start manually inspecting things until you find the problem. > If the job is time critical or you can't get the same inputs again, > then the machine needs to get it right the first time. How many > 9s of reliability do you need and how many resources can you throw > at it? 2x hardware can be good for better than 5 9s. (high quality > hardware and software, and technicians standing by with cold spares) > I've heard that mil gear uses 3x hardware. > > Building a 5 9s system is... non-trivial. So I'm wondering what sort > of reliability we can get with 2x off the shelf commodity hardware > and a bit of software? Similar to mirroring/RAID but with whole > computers rather than just disks. Classic Unix technique of doing > 10-20% of the work and getting 80-90% of the result. > I don't have anything particularly insightful to add to this conversation, but it is something I've looked into a bit. The solution which seemed most promising to me is Remus. I don't know if any have heard of it so I offer a link: http://static.usenix.org/event/nsdi08/tech/full_papers/cully/cully_html/ I understand this doesn't correlate exactly with the OP's point but there is good material there regardless. -- Adam Vande More From owner-freebsd-hackers@FreeBSD.ORG Fri Feb 24 22:42:10 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B31CC1065672 for ; Fri, 24 Feb 2012 22:42:10 +0000 (UTC) (envelope-from freebsd2@toyingwithfate.com) Received: from attila.screenminded.com (willmc-1-pt.tunnel.tserv8.dal1.ipv6.he.net [IPv6:2001:470:1f0e:1d0::2]) by mx1.freebsd.org (Postfix) with ESMTP id 6C6688FC17 for ; Fri, 24 Feb 2012 22:42:10 +0000 (UTC) Received: from mail.toyingwithfate.com (localhost [127.0.0.1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by attila.screenminded.com (Postfix) with ESMTPSA id EF21E204161 for ; Fri, 24 Feb 2012 22:42:09 +0000 (UTC) MIME-Version: 1.0 Date: Fri, 24 Feb 2012 22:42:08 +0000 From: Will McCutcheon To: Message-ID: X-Sender: freebsd2@toyingwithfate.com User-Agent: RoundCube Webmail/0.3.1 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=UTF-8 X-Mailman-Approved-At: Fri, 24 Feb 2012 22:45:09 +0000 Subject: Kernel stalling at "pci0: on pcib0" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Feb 2012 22:42:10 -0000 Hello everybody, I originally posted this at freebsd-questions and was referred over here. I recently got a HP t5700 thin client that I wanted to turn into a firewall using pfSense. For reference, this system uses a Transmeta Crusoe TM5800 CPU with a VIA chipset that I'm having difficulty identifying. My issue is that about half of the time the kernel will stall during startup after the following: Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 9.0-RELEASE #0: Tue Jan 3 07:15:25 UTC 2012 root at obrian.cse.buffalo.edu:/usr/obj/usr/src/sys/CENERIC i386 CPU: Transmeta(tm) Crusoe(tm) Processor TM5800 (997.69-MHz 586-class CPU) Origin = "CenuineTMx86" Id = 0x543 Family = 5 Model = 4 Stepping = 3 Features= 0x84893f real memory = 270532608 (258 MB) avail memory = 226930688 (216 MB) kbd1 at kbdmux0 acpi0: on motherboard acpi0: Power Button (fixed) acpi0: Sleep Button (fixed) acpi0: reservation of 0, a0000 (3) failed acpi0: reservation of 100000, eef0000 (3) failed acpi_timer0: couldn't allocate resource (port 0x4008) cpu0: on acpi0 acpi_button0: on acpi0 pcib0: port Oxcf8-0xcff,0x4000-0x407f,0x4080-0x40ff,0x500 0-0x500f on acpi0 pcib0: Length mismatch for 4 range: f00 vs eff pcib0: Length mismatch for 4 range: aff0 vs afef pciO: on pcib0 If I power the system off and on again there's about a 50/50 chance it will start up properly, whereupon it will run for days without issue. It's just during startup that I see any problems. I've tried two separate systems of the same model but they both exhibit the same issue, thus suggesting it's not a one-off hardware defect. I tried both pfSense 2.0.1 (which is FreeBSD 8.1-based) and FreeBSD 9.0-RELEASE from a USB stick, but they exhibited the same issue. I do see some acpi0 and pcib0 messages in there that seem possibly problematic, but I'm a bit out of my depth here. Could anyone spare a moment to suggest any further troubleshooting steps I might try? Thanks so much for your time! Will From owner-freebsd-hackers@FreeBSD.ORG Sat Feb 25 14:41:51 2012 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DB2D7106564A; Sat, 25 Feb 2012 14:41:51 +0000 (UTC) (envelope-from rank1seeker@gmail.com) Received: from mail-ee0-f54.google.com (mail-ee0-f54.google.com [74.125.83.54]) by mx1.freebsd.org (Postfix) with ESMTP id 17BF58FC13; Sat, 25 Feb 2012 14:41:50 +0000 (UTC) Received: by eekd17 with SMTP id d17so663702eek.13 for ; Sat, 25 Feb 2012 06:41:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:from:to:subject:date:content-type :content-transfer-encoding:in-reply-to:references:x-mailer; bh=yOIEaSSdVLpyxcyuO+TvIuf9X840Rzw/rVaUHsN+oF0=; b=a5pBcwQfs01si+Q/qtC+MfwDd2jQizL53iA0BBsxP+ZVTTMHjEOfSWLWn7u4pR3Vi/ 3bzoeiBUSaLOw6MaQzLnVdXZr9anrM7HpxOVLyrClcYWZUKgiGTGSHhFMvEuTTkyPpYh gO0qMabOaMNuubqcr++Q1P9FK+gYIDF3BuhDA= Received: by 10.14.127.195 with SMTP id d43mr2955153eei.102.1330180909752; Sat, 25 Feb 2012 06:41:49 -0800 (PST) Received: from DOMYPC ([82.193.208.173]) by mx.google.com with ESMTPS id a58sm32245103eeb.8.2012.02.25.06.41.28 (version=SSLv3 cipher=OTHER); Sat, 25 Feb 2012 06:41:47 -0800 (PST) Message-ID: <20120225.144148.466.1@DOMY-PC> From: rank1seeker@gmail.com To: hackers@freebsd.org, "John Baldwin" , "Roman Divacky" Date: Sat, 25 Feb 2012 15:41:48 +0100 Content-Type: text/plain; charset="Windows-1250" Content-Transfer-Encoding: quoted-printable In-Reply-To: <201202241531.11281.jhb@freebsd.org> References: <20120217.074355.853.1@DOMY-PC> <201202241223.45255.jhb@freebsd.org> <20120224.191152.168.2@DOMY-PC> <201202241531.11281.jhb@freebsd.org> X-Mailer: POP Peeper (3.8.1.0) Cc: Subject: Re: BUG: 9.0 stage 2 boot (/boot/boot) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Feb 2012 14:41:51 -0000 ----- Original Message -----=0D=0AFrom: John Baldwin = =0D=0ATo: rank1seeker@gmail.com=0D=0ACc: = hackers@freebsd.org, "Roman Divacky" =0D=0ADate: = Fri, 24 Feb 2012 15:31:11 -0500=0D=0ASubject: Re: BUG: 9.0 stage 2 boot = (/boot/boot)=0D=0A=0D=0A> On Friday, February 24, 2012 2:11:52 pm = rank1seeker@gmail.com wrote:=0D=0A> > ----- Original Message -----=0D=0A> = > From: John Baldwin =0D=0A> > To: = rank1seeker@gmail.com=0D=0A> > Cc: hackers@freebsd.org, "Roman Divacky" = =0D=0A> > Date: Fri, 24 Feb 2012 12:23:45 = -0500=0D=0A> > Subject: Re: BUG: 9.0 stage 2 boot (/boot/boot)=0D=0A> > = =0D=0A> > > On Friday, February 24, 2012 9:05:54 am rank1seeker@gmail.com = wrote:=0D=0A> > > > ----- Original Message -----=0D=0A> > > > From: John = Baldwin =0D=0A> > > > To: = freebsd-hackers@freebsd.org=0D=0A> > > > Cc: rank1seeker@gmail.com, Roman = Divacky =0D=0A> > > > Date: Thu, 23 Feb 2012 = 08:02:04 -0500=0D=0A> > > > Subject: Re: BUG: 9.0 stage 2 boot = (/boot/boot)=0D=0A> > > > =0D=0A> > > > > On Friday, February 17, 2012 = 2:43:55 am rank1seeker@gmail.com wrote:=0D=0A> > > > > > Anyway, after = upgrading to 9.0, my USB stick, when created, started =0D=0A> to =0D=0A> = > > hang =0D=0A> > > > > at stage 2 boot.=0D=0A> > > > > > I have a = custom setup, where BSD label 'a', has a content of /boot/*=0D=0A> > > > = > > So when 'a' is being hit by stage 2 boot, there is boot.config = =0D=0A> waiting =0D=0A> > > for =0D=0A> > > > > it.=0D=0A> > > > > > = After it reads it and displays it's content, it echos 'No' and =0D=0A> = hangs.=0D=0A> > > > > > =0D=0A> > > > > > I stare at it and can't believe = as boot.config's information is =0D=0A> correct!=0D=0A> > > > > > I hit = '?' and it list all files in 'a'.=0D=0A> > > > > > Then I simply RE-type = what is displayed on screen (content of =0D=0A> > > boot.config -> = =0D=0A> > > > > path to loader)=0D=0A> > > > > > And loader kicks = in!=0D=0A> > > > > > =0D=0A> > > > > > I do this a few times more and = EACH time I have to RE-type correct =0D=0A> info!=0D=0A> > > > > > Tested = on other machine, same thing.=0D=0A> > > > > > =0D=0A> > > > > > However, = this same custom layout works for HDD's, but NOT for USB =0D=0A> = stick.=0D=0A> > > > > > =0D=0A> > > > > > I've extracted binary installs = of 8.2 and 9.0 R:=0D=0A> > > > > > MD5 (8_boot) =3D = adb1e84e96bd434e51cafaaa0ef22584=0D=0A> > > > > > MD5 (9_boot) =3D = 40f3f6403ebd5e131259d1336b4b50ad=0D=0A> > > > > > =0D=0A> > > > > > = Then:=0D=0A> > > > > > # gpart bootcode -b 8_boot da0s2=0D=0A> > > > > > = And sudenly that USB stick boots, without ANY other change!=0D=0A> > > > = > > Just an "old" stage 2 boot code, from R8 was enough.=0D=0A> > > > > = =0D=0A> > > > > Looks like it is thinking that 'kname' is empty. Ah, I = think Roman =0D=0A> broke =0D=0A> > > this=0D=0A> > > > > in = 219186:=0D=0A> > > > > =0D=0A> > > > > @@ -474,11 +461,7 @@ = parse()=0D=0A> > > > > ? DRV_HARD : 0) + drv;=0D=0A> > > > > = dsk_meta =3D 0;=0D=0A> > > > > }=0D=0A> > > > > - if ((i =3D ep = - arg)) {=0D=0A> > > > > - if ((size_t)i >=3D sizeof(kname))=0D=0A> > > = > > - return -1;=0D=0A> > > > > - memcpy(kname, arg, i + 1);=0D=0A> = > > > > - }=0D=0A> > > > > + kname =3D arg;=0D=0A> > > > > = }=0D=0A> > > > > arg =3D p;=0D=0A> > > > > }=0D=0A> > > > > = =0D=0A> > > > > Before it only set kname if it wasn't an empty string. = Now it always =0D=0A> sets=0D=0A> > > > > kname. Try this change:=0D=0A> = > > > > =0D=0A> > > > > Index: boot2.c=0D=0A> > > > > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=0D=0A> = > > > > --- boot2.c (revision 231983)=0D=0A> > > > > +++ boot2.c (working = copy)=0D=0A> > > > > @@ -457,7 +457,8 @@ parse()=0D=0A> > > > > = ? DRV_HARD : 0) + drv;=0D=0A> > > > > dsk_meta =3D 0;=0D=0A> > > > > = }=0D=0A> > > > > - kname =3D arg;=0D=0A> > > > > + if = (*arg !=3D '\0')=0D=0A> > > > > + kname =3D arg;=0D=0A> > > > > = }=0D=0A> > > > > arg =3D p;=0D=0A> > > > > }=0D=0A> > > > > = =0D=0A> > > > > -- =0D=0A> > > > > John Baldwin=0D=0A> > > > > =0D=0A> > = > > =0D=0A> > > > =0D=0A> > > > It still doesn't work!=0D=0A> > > > = =0D=0A> > > > And please, next time attach patch in a file (unified = format), so I =0D=0A> would =0D=0A> > > have a less hassle (to avoid = manuall patch application)=0D=0A> =0D=0A> Hmm, our mailing lists each = attachments, so you are less likely to get the=0D=0A> patch that = way.=0D=0A> =0D=0A> > > Do you still get 'No ' with no other message = before it breaks?=0D=0A> > =0D=0A> > =0D=0A> > I get 'No ' with no other = message before it HANGS waiting for manual input?=0D=0A> > Manual input = makes it work.=0D=0A> > I simply RE-type outputed contest of boot.config = file.=0D=0A> > =0D=0A> > =0D=0A> > > Can you show me the contents of your = /boot.config file via hd?=0D=0A> > =0D=0A> > =0D=0A> > Both USB stick and = HDD have a same boot.config file, contents:=0D=0A> > ---=0D=0A> > = /loader=0D=0A> > ---=0D=0A> =0D=0A> Hmm, you didn't pass it to hd(1) like = I asked. Anyway, I hacked up a test=0D=0A> program to run the parse() = routine from boot2.c and it DTRT.=0D=0A=0D=0A=0D=0A# hd = boot.config=0D=0A00000000 2f 6c 6f 61 64 65 72 0a = |/loader.|=0D=0A00000008=0D=0A=0D=0A=0D=0A> Do you only see the "No " = message? Do you see the '/boot.config: /loader'=0D=0A> message? (Do you = have RBX_QUIET enabled perhaps? (-q)) Do you get the actual=0D=0A> boot2 = prompt at all?=0D=0A=0D=0AI don't have RBX_QUIET enabled nor any other = flags=0D=0A=0D=0ALet the pic tell a = story:=0D=0Ahttp://www.starforce.biz/stage2boot.jpg=0D=0A=0D=0AIt is also = valid for your latest patch=0D=0A=0D=0A=0D=0A> Hmm, I think the problem = is that 'opts' has garbage instead of being=0D=0A> initialized to = zero.=0D=0A> =0D=0A> Try this (also at = www.freebsd.org/~jhb/patches/boot2_opts.patch):=0D=0A=0D=0A=0D=0APatch = eliminates possible error, of manual "intervention"=0D=0AThat is, a = perfectly valid patch being classified as invalid.=0D=0A=0D=0A=0D=0A> = =0D=0A> Index: boot2.c=0D=0A> = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=0D=0A> = --- boot2.c (revision 231983)=0D=0A> +++ boot2.c (working copy)=0D=0A> @@ = -224,6 +224,7 @@=0D=0A> uint8_t autoboot;=0D=0A> ino_t = ino;=0D=0A> =0D=0A> + opts =3D 0;=0D=0A> kname =3D NULL;=0D=0A> = dmadat =3D (void *)(roundup2(__base + (int32_t)&_end, 0x10000) - = __base);=0D=0A> v86.ctl =3D V86_FLAGS;=0D=0A> =0D=0A> =0D=0A> -- = =0D=0A> John Baldwin=0D=0A> =0D=0A=0D=0A=0D=0ADomagoj Smol=E8i=E6 From owner-freebsd-hackers@FreeBSD.ORG Sat Feb 25 14:49:33 2012 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 57757106564A for ; Sat, 25 Feb 2012 14:49:33 +0000 (UTC) (envelope-from rank1seeker@gmail.com) Received: from mail-ey0-f182.google.com (mail-ey0-f182.google.com [209.85.215.182]) by mx1.freebsd.org (Postfix) with ESMTP id 9DE1E8FC08 for ; Sat, 25 Feb 2012 14:49:32 +0000 (UTC) Received: by eaan10 with SMTP id n10so1462643eaa.13 for ; Sat, 25 Feb 2012 06:49:31 -0800 (PST) Received-SPF: pass (google.com: domain of rank1seeker@gmail.com designates 10.213.28.19 as permitted sender) client-ip=10.213.28.19; Authentication-Results: mr.google.com; spf=pass (google.com: domain of rank1seeker@gmail.com designates 10.213.28.19 as permitted sender) smtp.mail=rank1seeker@gmail.com; dkim=pass header.i=rank1seeker@gmail.com Received: from mr.google.com ([10.213.28.19]) by 10.213.28.19 with SMTP id k19mr2011200ebc.24.1330181371568 (num_hops = 1); Sat, 25 Feb 2012 06:49:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:from:to:subject:date:content-type :content-transfer-encoding:x-mailer; bh=baHfpsx6Ty/ZO75lnKHDtpWcGcW1uWP+sZmzC2xa0Qo=; b=JHT9239VWMY4fdCh8IWy4hAG3vd+1bGm62jRu7Plyv3TzyHVxLIGyK1AxmcHrnrOl9 ZlUT3mqT503HcDMJp00DkkB3n0W0xpWOTnF/FmVAv4obto5TBWKJpa/xCCzpMNH80dWG J5u+36XibNn3rjNwBUs//rVRDfgip1N18juog= Received: by 10.213.28.19 with SMTP id k19mr1519411ebc.24.1330181371379; Sat, 25 Feb 2012 06:49:31 -0800 (PST) Received: from DOMYPC ([82.193.208.173]) by mx.google.com with ESMTPS id u9sm32299347eem.11.2012.02.25.06.49.27 (version=SSLv3 cipher=OTHER); Sat, 25 Feb 2012 06:49:30 -0800 (PST) Message-ID: <20120225.144930.392.2@DOMY-PC> From: rank1seeker@gmail.com To: hackers@freebsd.org Date: Sat, 25 Feb 2012 15:49:30 +0100 Content-Type: text/plain; charset="Windows-1250" Content-Transfer-Encoding: quoted-printable X-Mailer: POP Peeper (3.8.1.0) X-Mailman-Approved-At: Sat, 25 Feb 2012 14:52:58 +0000 Cc: Subject: Smarter/Shorter mount X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Feb 2012 14:49:33 -0000 As more and more bins work without a need to specify /dev/, could we also = make a mount bin to behave same? (Of course we can.)=0D=0AThat is, to = make this work:=0D=0A# mount da0s2a /tmp/MP=0D=0A=0D=0A=0D=0ADomagoj = Smol=E8i=E6 From owner-freebsd-hackers@FreeBSD.ORG Sat Feb 25 16:32:25 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 29E99106566C for ; Sat, 25 Feb 2012 16:32:25 +0000 (UTC) (envelope-from wojtek@tensor.gdynia.pl) Received: from tensor.gdynia.pl (tensor.gdynia.pl [89.206.35.72]) by mx1.freebsd.org (Postfix) with ESMTP id 867D48FC15 for ; Sat, 25 Feb 2012 16:32:24 +0000 (UTC) Received: Received: from 127.0.0.1 (localhost [127.0.0.1]) by tensor.gdynia.pl (8.14.4/8.14.5) with ESMTP id q1PG64Nd002292; Sat, 25 Feb 2012 17:06:04 +0100 (CET) (envelope-from wojtek@tensor.gdynia.pl) Received: (from wojtek@localhost) by tensor.gdynia.pl (8.14.5/8.14.5/Submit) id q1PG64Yx002291; Sat, 25 Feb 2012 17:06:04 +0100 (CET) (envelope-from wojtek) Newsgroups: Date: Sat, 25 Feb 2012 16:45:52 +0100 (CET) From: Wojciech Puchar To: freebsd-hackers@freebsd.org Fcc: sent-mail Message-ID: User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) X-Cursor-Pos: : 0 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=UTF-8 Status: X-Status: X-Keywords: X-UID: 1 X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.2.6 (tensor.gdynia.pl [89.206.35.72]); Sat, 25 Feb 2012 17:06:04 +0100 (CET) Cc: Grzegorz Kulewski Subject: improving VM - questions X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Feb 2012 16:32:25 -0000 it is easy to see that VM settings are not fine for MODERN hardware. We have gigabytes, not megabytes of RAM, hard disks can be efficient only if average I/O size is in order of megabyte or so, not tens of kB. In spite of having gigabytes of RAM, sometimes we DO NEED swapping. often we have process taking lots of RAM that is not used for a long etc. For now swapping generates too small I/Os i tried that patch --- swap_pager.c.orig 2012-02-25 16:22:25.000000000 +0100 +++ swap_pager.c 2012-02-25 13:19:51.000000000 +0100 @@ -119,7 +119,7 @@ * The 32-page limit is due to the radix code (kern/subr_blist.c). */ #ifndef MAX_PAGEOUT_CLUSTER -#define MAX_PAGEOUT_CLUSTER 16 +#define MAX_PAGEOUT_CLUSTER 256 #endif #if !defined(SWB_NPAGES) --- vm_fault.c.orig 2011-10-12 22:08:25.000000000 +0200 +++ vm_fault.c 2012-02-25 13:20:02.000000000 +0100 @@ -114,8 +114,8 @@ static int vm_fault_additional_pages(vm_page_t, int, int, vm_page_t *, int *); static void vm_fault_prefault(pmap_t, vm_offset_t, vm_map_entry_t); -#define VM_FAULT_READ_AHEAD 8 -#define VM_FAULT_READ_BEHIND 7 +#define VM_FAULT_READ_AHEAD 128 +#define VM_FAULT_READ_BEHIND 127 #define VM_FAULT_READ (VM_FAULT_READ_AHEAD+VM_FAULT_READ_BEHIND+1) struct faultstate { --- param.h~ 2011-06-08 05:45:40.000000000 +0200 +++ param.h 2011-06-15 19:00:32.000000000 +0200 @@ -131,7 +131,7 @@ #define DFLTPHYS (64 * 1024) /* default max raw I/O transfer size */ #endif #ifndef MAXPHYS -#define MAXPHYS (128 * 1024) /* max raw I/O transfer size */ +#define MAXPHYS (2048 * 1024) /* max raw I/O transfer size */ #endif #ifndef MAXDUMPPGS #define MAXDUMPPGS (DFLTPHYS/PAGE_SIZE) ----- param.h patch works great for filesystem I/O with big files. i use it for a long. vm_fault.c patch seems to make starting big programs faster as well, systat/vmstat confirms I/O sizes are larger. but swap_pager.c patch seems not to work. i observe 64kB pageouts, no more. what is wrong in it? Other question - tmpfs, it not in memory, seems to ALWAYS generate exactly one page sized I/Os at pagein (no matter what i do). What is wrong in it? From owner-freebsd-hackers@FreeBSD.ORG Sat Feb 25 17:51:56 2012 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1E928106564A for ; Sat, 25 Feb 2012 17:51:56 +0000 (UTC) (envelope-from rank1seeker@gmail.com) Received: from mail-ee0-f54.google.com (mail-ee0-f54.google.com [74.125.83.54]) by mx1.freebsd.org (Postfix) with ESMTP id 9DEE78FC0C for ; Sat, 25 Feb 2012 17:51:55 +0000 (UTC) Received: by eekd17 with SMTP id d17so751986eek.13 for ; Sat, 25 Feb 2012 09:51:54 -0800 (PST) Received-SPF: pass (google.com: domain of rank1seeker@gmail.com designates 10.14.131.145 as permitted sender) client-ip=10.14.131.145; Authentication-Results: mr.google.com; spf=pass (google.com: domain of rank1seeker@gmail.com designates 10.14.131.145 as permitted sender) smtp.mail=rank1seeker@gmail.com; dkim=pass header.i=rank1seeker@gmail.com Received: from mr.google.com ([10.14.131.145]) by 10.14.131.145 with SMTP id m17mr4218524eei.115.1330192314630 (num_hops = 1); Sat, 25 Feb 2012 09:51:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:from:to:subject:date:content-type :content-transfer-encoding:x-mailer; bh=dYZkldtMACuNRxDdMj/WoMqELd0fwd9nsibOypUzK+g=; b=KetBc6R1pPa4btaMYvLj1Cvv9cV+R5dPKqzlroP5E3//mC+p19GCyT2xBCwV360oqj hv0omgwW0qgLyVHm8PcxQmMTXhn3uv7oco4qNU1QYH40QoZfKJVY9Lb4vP/nVa8t/1Av 3FVJdYI6TPYdhyg91/oVPBD1v4w9bOGLfVGkc= Received: by 10.14.131.145 with SMTP id m17mr3167547eei.115.1330192314384; Sat, 25 Feb 2012 09:51:54 -0800 (PST) Received: from DOMYPC ([82.193.208.173]) by mx.google.com with ESMTPS id z47sm34158385eeh.9.2012.02.25.09.51.48 (version=SSLv3 cipher=OTHER); Sat, 25 Feb 2012 09:51:53 -0800 (PST) Message-ID: <20120225.175151.884.3@DOMY-PC> From: rank1seeker@gmail.com To: hackers@freebsd.org Date: Sat, 25 Feb 2012 18:51:51 +0100 Content-Type: text/plain; charset="Windows-1250" Content-Transfer-Encoding: quoted-printable X-Mailer: POP Peeper (3.8.1.0) Cc: Subject: BUG: 9.0 DESTIR-ed ports, loose theirs vars X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Feb 2012 17:51:56 -0000 ----=0D=0A#!/bin/sh=0D=0A=0D=0ADESTDIR=3D/usr/TZONE; export DESTDIR=0D=0Acd = /usr/ports/devel/gmake=0D=0Amake -V UNIQUENAME -V = PORTNAME=0D=0A----=0D=0A=0D=0ANow run above code again, BUT delete or = comment out DESTDIR line.=0D=0AUNIQUENAME will have a = value.=0D=0A=0D=0AWe need an unique name for port = OPTIONS!=0D=0A=0D=0A=0D=0A=0D=0ADomagoj Smol=E8i=E6